You are on page 1of 9

A Web Object Oriented approach Using Web Services and REST

Cedric Ulmer
SAP Research Sophia Antipolis, France

Yohann Bonillo
SAP Research Sophia Antipolis, France

Gabriel Serme
SAP Research Sophia Antipolis, France Osvaldo Cocucci
SAP Research Brisbane, Australia Florian Gilcher
SAP Research Sophia Antipolis, France ABSTRACT
Complex business applications require object orientation to model systems that reflect reality and generate maintainable and modular code. In this paper we present an object oriented architecture that utilizes two predominant state of the art paradigms, namely Web Services standards and REST to drive communications and access to resources. The objective is to provide means to enable object oriented programming using known standards in order to ensure simplicity of usage. Such an architecture can be incrementally implemented based on devices capabilities, from simple external resources access to complex exposure of its own objects. The paper starts with an introduction on usage of programming languages, and why current trends in the industry are structured programming oriented. We then present a public security scenario used to demonstrate our approach. After explaining how we differentiate from existing object oriented technologies, we detail our Web Objects Description Language (WODL) and how it extends WSDL. We then present our Web Object Oriented architecture (WebOO) that leverages REST, and give directions on scalability mechanisms that suit it. We conclude on further work needed to validate our approach, in terms of security.

In the early seventies, the computing programming industry started its migration from functional programming to object oriented programming with languages such as Smalltalk. This step was important to allow the maintenance of large applications, with reusability in mind and focus on data. However all the development was done in a local environment, so it was constrained to single large applications which have been poorly integrated with other applications [18]. In parallel to the evolution from structural to object oriented programming, another trend was to evolve towards distributed programming. This aspect allowed to leverage interconnected computers and to do a further step towards exibility of resources location. The architectures were no longer centralized, but opened for communication between many entities. Early distributed technologies were designed as a structured distributed programming, like the Remote Procedure Call (RPC) paradigm [16]. The industry then combined both branches into distributed object applications. This led to new standards, like Common Object Request Broker Architecture (CORBA) [14] defined by the Object Management Group (OMG), to interconnect at an object level multiple computers through a network. The object distributed computing was also supported by the main industry majors, with the Distributed Component Object Model (DCOM) [9] by Microsoft or Remote Method Invocation (RMI) [15] by Sun Microsystems. Yet none of these standards reached a critical mass of adoption by the developers and business user community. One point of failure in these technologies was the link between the solution used and the vendor, as CORBA with its multiple Object Request Brokers (ORBs) [8]. This brought a complex approach to write and deploy applications. The rise of interconnected machines through internet shifted the focus towards interoperability between software solutions. After local programming and distributed programming came "weboperable programming". The main communication-channel in this paradigm is the Internet. Interfaces based on this "web-operable programming" are called Web services. They are built on standards, as Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL) which bring a standardized way to interconnect applications together. This set of standards has been accepted by the developers' community and by the main actors of the industry. But programming using Web

Categories and Subject Descriptors
D.2.12 [Software Distributed objects. Interoperability]: Interoperability –

General Terms
Your general terms must be any of the following 16 designated terms: Documentation, Performance, Design, Reliability, Security, Standardization, Languages, Theory.

Web Object Orientation, REST, Web Service, WSDL 2.0, WODL.

services can be seen as programming in a distributed fashion, with a focus on function calls. There is no notion of object orientation. Furthermore, these Web services require a complex library stack to handle the communication. In 2000, Roy Fielding proposed a different approach for communication between peers: REpresentational State Transfer (REST) [10]. REST propagates the idea that plain HyperText Transfer Protocol (HTTP) is already enough to have meaningful interactions between systems. From these considerations, we searched a way to enable object orientation in a "web-operable" world, while taking into consideration adopted standards and technologies. We propose a combination of Web services and REST to give a clear and elegant object orientation. We call it Web Object Orientation (WebOO). We introduce here several terms which will be used throughout the document: WebOO is the concept of a distributed computing through the Internet and with the support of major standards; WODL (Web Objects Description Language) is the description of the distributed objects structure; and Web Objects are remote instances that run on the server-side.

3.1.1 OMG Interface Definition Language (IDL)
IDL is a language used by CORBA and RMI to describe "the interfaces that client objects call and object implementations provide" [14]. "An interface consists of a set of named operations and the parameters to those operations." "IDL is the means by which a particular object implementation tells its potential clients what operations are available and how they should be invoked. the IDL definitions, it is possible to map CORBA objects into particular programming languages or object systems." Syntactically, IDL behaves similarly to common widespread object programming languages (e.g. Java and C++) for interface description. That's why this language is usually easy to write and understand.

3.1.2 Web Services Description Language v2.0
WSDL 2.0 is a language based on the XML format, which provides a model for describing Web services [13]. This description is done in two fundamental stages: an abstract and a concrete one. At an abstract level, WSDL 2.0 provides the structure description of the messages sent to and received by a Web service. "An operation associates a message exchange pattern with one or more messages. A message exchange pattern identifies the sequence and cardinality of messages sent and/or received as well as who they are logically sent to and/or received from. An interface groups together operations without any commitment to transport or wire format." At a concrete level, "a binding specifies transport and wire format details for one or more interfaces. An endpoint associates a network address with a binding. Finally, a service groups together endpoints that implement a common interface." WSDL 1.1 HTTP binding was inadequate to describe communications with HTTP and XML, so there was no way to formally describe REST Web services with WSDL. Designed with REST Web services in mind, WSDL 2.0 has resolved the issues of the previous version and was declared as a W3C recommendation in June 2007. Many industry leaders (e.g. Adobe, IBM, Microsoft, Oracle and SAP) have participated to the creation and the implementation of this new version [3]. This strong involvement allowed WSDL 2.0 to integrate anticipated features such as HTTP support. Thus, WSDL 2.0 has become one of the technologies that "provide a foundation for developers to build enterprise applications that are reusable, extensible, web-friendly" [2]. Yet architects such as Mark Little outlined that these changes have "added a lot of complexity" and that this new version has "a lack of backwards compatibility" [11]. Moreover, by definition, this language is purely service oriented.

We implemented a prototype based on this architecture. This section presents a homeland security scenario which will be used in the following sections to illustrate our concept explaining the steps to use the WebOO and the interactions among actors. In a scenario of criminal cases management, public security organizations need to share information about a criminal case. Investigators will contribute by searching evidences and criminal information in order to fill in a criminal case. Two police forces department need to collaborate, and each are using a different applications system. One of the police force is in charge of proposing a shared information system. This police force has to define its Person, Investigator, Criminal, Evidence and CriminalCase models [Figure 1]. In section 3.3, we will see how the police force de scribes these models in WODL files.

To enable WebOO, we first need to describe the objects interfaces to know how the objects are structured, with their methods and attributes. Then, we need to know where to send the requests, and how to build them. As we rely on Web services, there is already a standard designed to partially describe these information: the WSDL format.

3.1 State of the art
This chapter provides an introduction to the OMG Interface Definition Language (IDL) which is a recognized object description language, and this WSDL format which is the basis for the object description language that we propose in this paper. Although many languages exist for describing objects interfaces, we focus on IDL with regards to object description in a distributed environment. The concepts remain the same for other existing languages, we want to highlight here the key features.

Figure 1 – Use Case Class Diagram

3.2 Proposal: Web Objects Description Language
WODL is derived from the W3C recommendation WSDL 2.0. Its purpose is to represent a Web Object and to indicate how to interact with the described object. We have based WODL on WSDL 2.0 because the latter is a well-accepted standard when dealing with web-based interaction. Object oriented programming uses several concepts. For example, to describe an object, and furthermore a Web Object, we have to define the characteristics and the behaviors of this object, similar to what IDL does. Deborah J. Armstrong has identified the eight fundamental concepts of object oriented development [1]. WODL being a description language, it does not necessarily need to comply with all these fundamental concepts developed for programming languages. Structured around these concepts, this chapter details the parts of the WSDL 2.0 format that we have modified to suit our object orientation needs.

3.2.3 Encapsulation
This fundamental concept is "a technique for designing classes and objects that restricts access to the data and behavior by defining a limited set of messages that an object of that class can receive" [1]. To define this access, we added a visibility parameter in the attribute and operation tags. This parameter can take its value in the following range: public, package, protected or private.

3.2.4 Attribute
This concept is the representation of an object's information. To describe these object information, we added an attributes tag to the existing types tag. This attributes tag is composed of an attribute sub-tag for each object piece of information. Each attribute sub-tag has a visibility parameter for enabling the encapsulation concept, a constant parameter to indicate whether the attribute is invariant or not, a static parameter to indicate whether the attribute is a class-attribute or not, a type parameter to give the simple type, the Web Object type or the list type of the attribute and a name parameter to identify the attribute. Each public attribute will entail the generation of the corresponding getter and setter methods.
<types> <attributes> <attribute visibility="private" constant="false" static="false" type="xs:string" name="description"/> </attributes> </types>

3.2.1 Abstraction
This fundamental concept is "the act of creating classes to simplify aspects of reality using distinctions inherent to the problem" [1]. WODL describes a Web Object at the abstraction level. Indeed, our description language defines the data and behavior of an object without providing any implementation. is a language.

3.2.2 Class
This fundamental concept is "a description of the organization and actions shared by one or more similar objects" [1]. To enable this description, we used the existing interface tag that will contain the class behaviors. The name of the class is given by the existing name parameter of the interface tag.
<interface name="CriminalCase "></interface>

3.2.5 Inheritance
This fundamental concept is "a mechanism that allows the data and behavior of one class to be included in or used as the basis for another class" [1]. To define that a class inherits from another one, we used the existing extends parameter in the interface tag.
<interface name="Criminal" extends="Person"> </interface>

<interface name="Criminal" extends="Person"> <operation visibility="public" static="false" name="print_1" pattern="http: //"> <output element="tns:string" messageLabel="out" /> </operation> </interface>

3.2.6 Object
This fundamental concept is "an individual, identifiable item, either real or abstract, which contains data about itself and descriptions of its manipulations of the data" [1]. This concept does not apply to our description language as it concerns instances of objects. We have taken the decision to let users select their object representation (e.g. XML and JSON). Note that we are working on extending WODL for this purpose, by adding a value parameter to the attribute tags but this is not the purpose of this paper.

Because of the WSDL restriction - each operation name must be unique - we had to create a specification to enable the parametric polymorphism - to allow for multiple methods with the same name but not the same signatures. So, we put a suffix to the operation names composed by an underscore followed by a number identifying the operation.
<interface name="CriminalCase"> <operation visibility="public" static="false" name="add_1" pattern=""> <input element="tns:Criminal" messageLabel="criminal" /> </operation> <operation visibility="public" static="false" name="add_2" pattern=""> <input element="tns:Evidence" messageLabel="evidence" /> </operation> </ interface>

3.2.7 Message Passing
This fundamental concept is "the process by which an object sends data to another object or asks the other object to invoke a method" [1]. This concept addresses a run-time problematic that is not related to the WODL. We will address it in the section 4.2.

3.3 Use Case: Scenario Based WODL Example
After the definition of the Person, Investigator, Criminal, Evidence and CriminalCase models [Figure 1], the police force has to describe these models in WODL files. Figure 2 shows the Investigator description in the WODL format. In section 4.3, we will see how to install a central system to expose these WODL files and Web Objects. The police force will add the SOAP and/or HTTP bindings and the endpoints corresponding to their system to the WODL files to provide the run-time information needed by the clients to access the Web Objects.

3.2.8 Method
This fundamental concept is "a way to access, set or manipulate an object's information" [1]. To describe a method, we used the existing operation tag with its existing input and output sub-tags to define the inputs and outputs of the method. We added a visibility parameter for enabling the encapsulation concept and a static parameter to indicate whether the method is a class-method or not.
<operation visibility="public" static="false" name="print_1" pattern=" "> <output element="tns:string" messageLabel="out" /> </operation>

3.2.9 Polymorphism
This fundamental concept is "the ability of different classes to respond to the same message and each implement the method appropriately" [1]. This definition of polymorphism corresponds to the overloading. No modification to the WSDL 2.0 format was required to enable it. No modification to WSDL neither was required to enable the inheritance with polymorphism, also called overriding. The example below demonstrates it.
<interface name="Person"> <operation visibility="public" static="false" name="print_1" pattern=" /ns /wsdl /out-only "> <output element="tns:string" messageLabel=" out " /> </operation> </interface>

<description xmlns="" xmlns:tns="" targetNamespace=""> <import namespace= location=""/> <types> <attributes> <attribute visibility="private" constant="false" static="false" type="xs:string" name="rank" /> </attributes> <xs:schema xmlns="" xmlns:xs="" targetNamespace=""> <xs:element name="string" type="xs:string"/> </xs:schema> </types> <interface name="Investigator" extends="Person"> <operation visibility="public" static="false" name="constructor1" pattern=""> <input element="tns:string" messageLabel="last name"/> <input element="tns:string" messageLabel="firstname"/> </operation> <operation visibility="public" static="false" name="print_1" pattern=""> <output element="tns:string" messageLabel="out"/> </operation> </interface> </description>

Figure 2 – Scenario based WODL example

The architecture proposed in this paper is based on the usage of mainstream technologies, more specifically Web services and REST orientation. This technology association results in a system that offers a distributed view keeping the RESTful services interoperability and flexibility. is the Uniform Resource Identifier (URI) and the verbs are the standard HTTP methods as POST, GET, PUT and DELETE. The research community is having several opinions on how these methods can be mapped to the CRUD operations. For instance, these methods can respectively associated with the CREATE, READ, UPDATE and DELETE operations. Each method has clear defined semantics that can be relied upon. When looking at sophisticated applications, going for a purely REST oriented approach can become too complex. We mean here that considering only resources exposed through CRUD operations forces the developer to redesign his objects whenever he has operations or services in mind.

4.1 State of the Art
This chapter introduces the REST and Web services technologies, along with the ones related to CORBA.

4.1.1 REpresentational State Transfer (REST)
The term REST was coined by Roy Fielding in his PhD dissertation [5]. "REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems". R. Fielding describes the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles. In REST, everything is a resource. A resource can be thought of as a distant object one can interact with, but not manipulate directly. This is similar in spirit to object oriented programming where everything is an object, but the approach is fundamentally different. Every resource, identified by a unique name, is interacted with using a universally predefined set of verbs. These verbs are defined for every resource globally. On the web, the unique name

4.1.2 SOAP Version 1.2
SOAP is "a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols" [7]. SOAP is a protocol specification enabling the exchange of structured information in the implementation of Web services [7]. SOAP uses the HTTP for RPCs, hiding the HTTP semantics from SOAP applications. In fact, "SOAP treats HTTP as a lower-level communication protocol" and uses its own semantics [12].

4.1.3 General/Internet Inter-ORB Protocol (GIOP/IIOP)
The GIOP "specifies a standard transfer syntax (low-level data representation) and a set of message formats for communications between ORBs [...] and is designed to work directly over any connection-oriented transport protocol" [14]. The CORBA and RMI communications use the IIOP which is the implementation

of the GIOP for Transmission Control Protocol/Internet Protocol (TCP/IP). An Object Request Broker (ORB) is "responsible for all of the mechanisms required to find the object implementation for the request, to prepare the object implementation to receive the request, and to communicate the data making up the request. The interface the client sees is completely independent of where the object is located, what programming language it is implemented in, or any other aspect that is not reflected in the object's interface" [14]. These standards are maintained by the OMG. The addition of the IIOP layer for communication has negatively impacted the performance of CORBA [8]. In addition, security is one of the core features that CORBA failed to provide [8].

The Web Object identifier is based on the same combination, so host name, port number, namespace and class name with a local unique identifier - in our prototype we use a Universal Unique IDentifier (UUID). It allows the WebOO Manager to access the local matching instance. A list of the values of all the public attributes of this instance is accessible via an HTTP GET method.

A client can manipulate directly an attribute of an instance adding to the URI identifying the instance, the name of this attribute.

A client can execute a method within an instance adding to the URI, the name of the method.

4.2 Proposal: Web Object Oriented Architecture
To overcome the issues with existing distributed object orientation we suggest a Web Object Oriented architecture, which relies on accepted standards. In this section, we describe the architecture overview [Figure 3].

In this case, the WebOO Manager extracts the needed parameters from the incoming message, and then it passes them to the correct instance. The WebOO Manager gets the response from the instance - if existing - and serializes it using the communication protocol format described in the WODL file. It then sends the response to the client.

4.2.1 Server Components
The WODL files save the description of object interfaces with the WODL format seen in the previous section. The Web Objects are remote instances that are hosted on servers. A server stores also the WODL files associated with these objects. The WebOO Manager is a component running on the server. It exposes the currently running Web Objects through an interface and allows clients to access them.

4.2.2 Client Components
The WebOO Helpers are optional classes which are responsible for the requests sent by a client to communicate with the Web Objects. A WebOO Helper can be generated by our implemented framework from a WODL file. Any client with a Web service stack and a HTTP stack can access operations. The program component is a client application that can communicate with Web Objects. It can have its own implementation for this communication from the location information contained in the WODL files, or use directly the WebOO Helpers.

4.2.3 Communication
The binding part of WSDL 2.0 propagates how to access the server and how to serialize data. We keep this feature in our object orientation for call operations. As for the manipulation of attributes or Web Objects, we use the REST capabilities. Thus, they are identified by a URI and are interacted with using the HTTP methods. For example, we can use directly the DELETE method to delete a Web Object. The WebOO Manager is responsible for waiting for clients requests and determining the action to be executed. In the next paragraphs, we will describe how to identify the different resources. A client can get the collection of Web Objects belonging to the same model with an HTTP GET method thanks to the combination between the name of the host, the port number, a namespace given in the WODL file of the model and the class name.

Figure 3 – WebOO Architecture Overview We have seen that the methods of a Web Object are defined as operations of a Web service. So a client can call a method of an instance sending a message with the corresponding binding to the corresponding endpoint described in the WODL file. As we see in distributed oriented programming platforms, communication is often embedded in a new protocol layer, but the WebOO architecture only uses the HTTP protocol as a communication layer. Web Object information can be easily accessed through a standard web browser using a HTTP GET request to the corresponding URI. We used in our implementation an ATOM feed describing the data, as it is a widespread standard for web data feeds, together with the RSS format. This format is a simple way to write information on the web that is human readable.

The server could also communicate with another server as a client. It means usingWebOO Helper, on the server or the client side, one can use a remote object. As we have seen, the WebOO architecture is a combination of existing technologies, such as Web services, RESTful communication to enhance the performance and reduce the complexity, and the addition of distributed objects which process the remote calls.

GET /WebOOManager/sap/com/publicSecurity/Evidence/69 HTTP/1.1 Host : If-None-Match : 8d7033

HTTP/1.1 304 Not Modified ETag : 8d7033

4.2.4 Scalability
Using REST as a core technology opens up many interesting scalability options. Although REST is said to be very scalable [5], there are no comprehensive analysis to be found, especially not when it comes to business applications. In this part, we describe some of these scalability techniques.

ETags are widely used and supported by most clients - especially web browsers - and are easy to interact with on the client side. They can be used for preconditions. Clients not handling ETags remain compatible, as long as the server does not decide to make them mandatory. Content Negotiation
Contrarily to specifications associated with Web services, REST allows for different forms of documents to be returned for a given resource. These are usually identified by their Media Type (e.g. text/html, text/xml, application/json and application/atom+xml). Through the Accept HTTP/1.1 request header field, the client can specify his preferences towards the form of the returned data. On the other hand, the server can specify the type of the returned data in the Content-Type HTTP/1.1 response header field [4]. Request
GET /WebOOManager/sap/com/publicSecurity/CriminalCase HTTP/1.1 Host : Accept : application/atom+xml; q=0.8, application/rss+xml, text/xml Caching
"HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible" [4]. Edge Side Include (ESI)
ESI "is an XML-based markup language that provides a means to assemble resources in HTTP clients. Unlike other in-markup languages, ESI is designed to leverage client tools like caches to improve end-user perceived performance, reduce processing overhead on the origin server, and enhanced availability. ESI allows for dynamic content assembly at the edge of the network, whether it is in a Content Delivery Network (CDN), end-user's browser, or in a "Reverse Proxy" right next to the origin server." [17]. One of the biggest providers of a CDN is Akamai, which for that purpose defined ESI and submitted it to the W3C. The ESI specification has the status of a W3C note. ESI is simple, there is only one element of interest for our case, the include tag which specifies a fragment for assembly.
<esi:includesrc=" sap/com/publicSecurity/CriminalCase/90/criminals" />

HTTP/1.1 200 OK Content-Type : application/atom+xml <entity body>

This can be used in some non-obvious ways. All common JavaScript libraries request application/json (JavaScript Object Notation), saving a lot of wrap/unwrapwork to be done on the client. This is especially interesting for mobile clients where saving CPU cycles and memory still matters. Mashups can be served with prerendered fragments of the data they want to display, saving error-prone and semantic-changing conversions.

4.3 Use Case: Scenario Based Communication Examples
After the description of the models (see Fig. 1) in the WODL format, the police force installs a central system with a WebOO Manager that hosts the WODL files. The police force now provides the run-time information needed by the clients to access the Web Objects. For this purpose, within its WODL files, it fills in the SOAP and/or HTTP bindings and the Entity Tag (ETag)
An ETag is an identifier for the current resource state and it can be used to track changes. It is specified in the HTTP/1.1 standard where it is used in the If-Match, If-None-Match and If-Range request header fields and in the ETag response header field [4].

<description xmlns="" xmlns:wsoap= xmlns:tns="" targetNamespace=""> <import .../> <types>...</types> <interface name="Investigator" extends="Person">...</interface> <binding name="InvestigatorSoapBinding" interface="tns:Investigator" type= wsoap:protocol= wsoap:mepDefault=""> <operation ref="tns:_constructor_1"/> <operation ref="tns:_print_1"/> </binding> <service name="InvestigatorService" interface="tns:Investigator"> <endpoint name="InvestigatorSoapEndpoint" binding="tns:InvestigatorSoapBinding" address=""/> </service> </description>

Figure 4 – Scenario based Communication Example endpoints corresponding to their system. Figure 4 shows the Investigator endpoint and its binding in the WODL format. Then, with our framework, they generate class files from WODL on the server side. After having implemented the behaviour of the objects, they expose a URL link to the WODL files. On the client side, the other organizations can use our framework with the provided link in order to generate the needed helper classes to use the remote objects. Doing nothing more they can use these remote objects in their main class. The objects can be used as local objects; it is transparent for the user. The example below shows the call of the print method on an Investigator instance as a service following the SOAP binding defined in the WODL. Request
POST /WebOOManager/sap/com/publicSecurity/Investigator/51 HTTP/1.1 Host : Accept : application/soap+xml <?xml version="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env=""> <env:Body> <b:print xmlns:b=" WebOOManager/sap/com/publicSecurity/ Investigator/51" /> </env:Body> </env:Envelope> <env:Body> <b:printResponse xmlns:b=" WebOOManager/sap/com/publicSecurity/ Investigator/51"> <b:out type="xs:string"> Investigator description... </b:out> </b:printResponse> </env:Body> </env:Envelope>

If another organization needs to use or retrieve the attributes of the objects, whatever the system they are using, they can use the HTTP stack implementation of their language to reach this object and use the CRUD verbs to process operations. In one line they can retrieve this value. In order to check the value of the attribute they can use a web browser and get the associated ATOM feed. The example below shows the communication established by a client to access the public values of an Evidence instance. Request
GET /WebOOManager/sap/com/publicSecurity/Evidence/69 HTTP/1.1 Host : If-None-Match : 8d7033 Accept : application/atom+xml

HTTP/1.1 200 OK ETag : 8d7055 Content-Type : application/atom+xml <?xml version="1.0" encoding="UTF-8"?> <feed xmlns=""> <title>Public fields of an Evidence</title> <link rel="alternate" href=" sap/com/publicSecurity/Evidence/69"/> <entry>

HTTP/1.1 200 OK Content-Type : application/soap+xml <?xml version ="1.0" encoding="UTF-8"?> <env:Envelope xmlns:env="">

<title>xs:string : description </title> <link rel="alternate" href=" sap/com/publicSecurity/Evidence/69/description"/> <updated>2009-06-19T12:05:33Z</updated> <summary> Description:Assault rifle developed in the Soviet Union by Mikhail Kalashnikov. </summary> </entry> </feed>

[3] J. Daly, M.-C. Forgue, and Y. Hirakawa. W3C Completes
Work on Critical Web Services Standard, June 2007.

[4] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, and T. Berners-Lee. Hypertext Transfer Protocol HTTP/1.1. RFC 2616 (Draft Standard), June 1999. Updated by RFC 2817.

[5] R. T. Fielding. Architectural Styles and the Design of
Network-based Software Architectures. PhD thesis, University of California, Irvine, California, USA, 2000.

[6] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P.
Leach, A. Luotonen, and L. Stewart. HTTP Authentication: Basic and Digest Access Authentication. RFC 2617 (Draft Standard), June 1999.

Now, every organization can contribute to the completion of a criminal case in order to gather updated information.

This paper presented an architecture enabling an object orientation from a web-operable perspective. This architecture combines existing technologies and concepts, such as REST, Web services and distributed computing. We took a look at the history of computing and our assumption is that the current trends in programming models need to evolve from Web services to its distributed object oriented version called WebOO, similar to the evolution of local programming from procedural to object oriented. We proposed a way to do web object programming without breaking existing technologies. WebOO is to be considered as complementary to Web services. It is a technology which allows the reuse of Web services tools with slight modification for supporting WebOO support. We plan to investigate the security aspect, to allow our architecture to gain maturity. In fact, we use the HTTP protocol as the communication layer in our system. We assume HTTPS is a security protocol which can be used as a security layer for our communication. We also use capacity of the HTTP Authentication [6] to set the credentials for each instance. Yet HTTPS is securing only the communication layer, so we need to identify the complementary technologies to ensure a complete chain of security, up to the applications. We will look at access control policy mechanisms to complement HTTPS, before investigating in cascading objects level security. We implemented a functional prototype, as seen in the use case sections. It illustrates the concept of WebOO in a real case, with tools simplifying the development. In order to leverage community-based collaboration, we propose a WODL exchange platform that we have called ModelForge. Leveraging the principle of social collaborative websites, it enables developers communities to share, discuss, document and rate object models.

[7] M. Gudgin, M. Hadley, N. Mendelsohn, J.-J. Moreau, H. F.
Nielsen, A. Karmarkar, and Y. Lafon. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C, Apr. 2007.

[8] M. Henning. The rise and fall of corba. Queue, 4(5):28-34,
June 2006. Magazine article.

[9] M. Horstmann and M. Kirtland. DCOM Architecture.
Microsoft, July 1997.

[10] A. P. Kalogeras, J. Gialelis, C. Alexakos, M. Georgoudakis,
and S. Koubias. Vertical Integration of Enterprise Industrial Systems Utilizing Web Services. In WFCS'04: Proceedings of the 5th IEEE International Workshop on Factory Communication Systems, pages 187-192.IEEE Industrial Electronics Society and Vienna University of Technology, Sept. 2004.

[11] M. Little. Does wsdl 2.0 matter? InfoQ, Jan. 2007.

[12] A. T. Manes. REST and SOAP and document-oriented
services, 2005.

[13] J.-J. Moreau, S. Weerawarana, R. Chinnici, and A. Ryman.
Web services description language (WSDL) version 2.0 part 1: Core language. W3C recommendation, W3C, June 2007.

[14] OMG. Common Object Request Broker Architecture
(CORBA) Specification, Version 3.1, Jan. 2008.

[15] Sun Microsystems. Java remote method invocation home. [16] R. Thurlow. RPC: Remote Procedure Call Protocol
Specification Version 2. RFC 5531 (Draft Standard), May 2009.

[17] M. Tsimelzon, B. Weihl, J. Chung, D. Frantz,J. Basso, C.
Newton, M. Hale, L. Jacobs, and C. O'Connell. ESI Language Specification 1.0. W3C, akamai technologies edition, Aug. 2001.

[1] D. J. Armstrong. The quarks of object-oriented development.
Communications of the ACM, 49(2):123-128, Feb. 2006. Magazine article.

[18] J. Waldo, G. Wyant, A. Wollrath, and S. Kendall. A Note on
Distributed Computing. Technical Report TR-94-29, SMLI, Mountain View, CA, USA, Nov.

[2] C. Barreto, K. Norsworthy, S. Weerawarana, and M.
Bechauf. Testimonials for wsdl 2.0 recommendation, June 2007.