A Web Object Oriented approach Using Web Services and

REST
Cedric Ulmer Yohann Bonillo Gabriel Serme
SAP Research SAP Research SAP Research
Sophia Antipolis, France Sophia Antipolis, France Sophia Antipolis, France
cedric.ulmer@sap.com yohann.bonillo@sap.com gabriel@serme.net

Osvaldo Cocucci Florian Gilcher

SAP Research SAP Research
Brisbane, Australia Sophia Antipolis, France
o.cocucci@sap.com flo@andersground.net

ABSTRACT
Complex business applications require object orientation to model
1. INTRODUCTION
In the early seventies, the computing programming industry
systems that reflect reality and generate maintainable and modular
started its migration from functional programming to object
code. In this paper we present an object oriented architecture that
oriented programming with languages such as Smalltalk. This step
utilizes two predominant state of the art paradigms, namely Web
was important to allow the maintenance of large applications, with
Services standards and REST to drive communications and access
reusability in mind and focus on data. However all the
to resources. The objective is to provide means to enable object
development was done in a local environment, so it was con-
oriented programming using known standards in order to ensure
strained to single large applications which have been poorly
simplicity of usage. Such an architecture can be incrementally
integrated with other applications [18]. In parallel to the evolution
implemented based on devices capabilities, from simple external
from structural to object oriented programming, another trend was
resources access to complex exposure of its own objects. The
to evolve towards distributed programming. This aspect allowed
paper starts with an introduction on usage of programming
to leverage interconnected computers and to do a further step
languages, and why current trends in the industry are structured
towards exibility of resources location. The architectures were no
programming oriented. We then present a public security scenario
longer centralized, but opened for communication between many
used to demonstrate our approach. After explaining how we
entities. Early distributed technologies were designed as a
differentiate from existing object oriented technologies, we detail
structured distributed programming, like the Remote Procedure
our Web Objects Description Language (WODL) and how it
Call (RPC) paradigm [16]. The industry then combined both
extends WSDL. We then present our Web Object Oriented
branches into distributed object applications. This led to new
architecture (WebOO) that leverages REST, and give directions
standards, like Common Object Request Broker Architecture
on scalability mechanisms that suit it. We conclude on further
(CORBA) [14] defined by the Object Management Group
work needed to validate our approach, in terms of security.
(OMG), to interconnect at an object level multiple computers
through a network. The object distributed computing was also
Categories and Subject Descriptors supported by the main industry majors, with the Distributed
D.2.12 [Software Interoperability]: Interoperability – Component Object Model (DCOM) [9] by Microsoft or Remote
Distributed objects. Method Invocation (RMI) [15] by Sun Microsystems. Yet none of
these standards reached a critical mass of adoption by the
General Terms developers and business user community. One point of failure in
Your general terms must be any of the following 16 designated these technologies was the link between the solution used and the
terms: Documentation, Performance, Design, Reliability, Security, vendor, as CORBA with its multiple Object Request Brokers
Standardization, Languages, Theory. (ORBs) [8]. This brought a complex approach to write and deploy
applications.

Keywords The rise of interconnected machines through internet shifted the

Web Object Orientation, REST, Web Service, WSDL 2.0, focus towards interoperability between software solutions. After
WODL. local programming and distributed programming came "web-
operable 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
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.
2. USE CASE: SCENARIO DESCRIPTION
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.
3. DESIGN TIME
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.
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.
 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.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.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.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>
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.
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.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="http://www.w3.org/ns/wsdl/out-only ">
<output element="tns:string" messageLabel="out" />
</operation>
<interface name="Criminal" extends="Person">
<operation visibility="public" static="false" name="print_1"
pattern="http: //www.w3.org/ns/wsdl/out-only">
<output element="tns:string" messageLabel="out" />
</operation>
</interface>
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="http://www.w3.org/ns/wsdl/in-only">
<input element="tns:Criminal" messageLabel="criminal" />
</operation>
<operation visibility="public" static="false" name="add_2"
pattern="http://www.w3.org/ns/wsdl/in-only">
<input element="tns:Evidence" messageLabel="evidence" />
</operation>
</ interface>
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.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="http://www.w3.org /ns /wsdl /out-only ">
<output element="tns:string" messageLabel=" out " />
</operation>
</interface>
<description xmlns="http://www.sap.com/ns/wodl" xmlns:tns="http://www.sap.com/publicSecurity/Investigator"
targetNamespace="http://www.sap.com/publicSecurity/Investigator">
<import namespace=http://www.sap.com/publicSecurity/Person
location="http://research.sap.com:8080/WebOOManager/WODL/sap/com/publicSecurity/Person.wodl"/>
<types>
<attributes>
<attribute visibility="private" constant="false" static="false" type="xs:string" name="rank" />
</attributes>
<xs:schema xmlns="http://www.sap.com/publicSecurity/Investigator"
xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.sap.com/publicSecurity/Investigator">
<xs:element name="string" type="xs:string"/>
</xs:schema>
</types>
<interface name="Investigator" extends="Person">
<operation visibility="public" static="false" name="constructor1" pattern="http://www.w3.org/ns/wsdl/in-only">
<input element="tns:string" messageLabel="last name"/>
<input element="tns:string" messageLabel="firstname"/>
</operation>
<operation visibility="public" static="false" name="print_1" pattern="http://www.w3.org/ns/wsdl/out-only">
<output element="tns:string" messageLabel="out"/>
</operation>
</interface>
</description>

Figure 2 – Scenario based WODL example

4. RUNTIME
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.
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
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.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].
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].
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.
http://hostname:port/namespace/class/id
A client can manipulate directly an attribute of an instance adding
to the URI identifying the instance, the name of this attribute.
http://hostname:port/namespace/class/id/attribute
A client can execute a method within an instance adding to the
URI, the name of the method.
http://hostname:port/namespace/class/id/method
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 Figure 3 – WebOO Architecture Overview

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.
http://hostname:port/namespace/class
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.
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.
4.2.4.1 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 : research.sap.com
Accept : application/atom+xml; q=0.8,
application/rss+xml, text/xml
Response
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.2.4.2 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].
Request
GET /WebOOManager/sap/com/publicSecurity/Evidence/69
HTTP/1.1
Host : research.sap.com
If-None-Match : 8d7033
Response
HTTP/1.1 304 Not Modified
ETag : 8d7033
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.
4.2.4.3 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].
4.2.4.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="http://research.sap.com:8080/WebOOManager/
sap/com/publicSecurity/CriminalCase/90/criminals" />
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
<description xmlns="http://www.sap.com/ns/wodl" xmlns:wsoap=http://www.w3.org/ns/wsdl/soap
xmlns:tns="http://www.sap.com/publicSecurity/Investigator"
targetNamespace="http://www.sap.com/publicSecurity/Investigator">
<import .../>
<types>...</types>
<interface name="Investigator" extends="Person">...</interface>
<binding name="InvestigatorSoapBinding" interface="tns:Investigator" type=http://www.w3.org/ns/wsdl/soap
wsoap:protocol=http://www.w3.org/2003/05/soap/bindings/HTTP/
wsoap:mepDefault="http://www.w3.org/2003/05/soap/mep/request-response">
<operation ref="tns:_constructor_1"/>
<operation ref="tns:_print_1"/>
</binding>
<service name="InvestigatorService" interface="tns:Investigator">
<endpoint name="InvestigatorSoapEndpoint" binding="tns:InvestigatorSoapBinding"
address="http://research.sap.com:8080/WebOOManager/sap/com/publicSecurity/Investigator"/>
</service>
</description>

Figure 4 – Scenario based Communication Example

endpoints corresponding to their system. Figure 4 shows the <env:Body>
Investigator endpoint and its binding in the WODL format. <b:printResponse xmlns:b="http://research.sap.com:8080/
Then, with our framework, they generate class files from WODL WebOOManager/sap/com/publicSecurity/
Investigator/51">
on the server side. After having implemented the behaviour of the
objects, they expose a URL link to the WODL files. <b:out type="xs:string">
Investigator description...
On the client side, the other organizations can use our framework
with the provided link in order to generate the needed helper </b:out>
classes to use the remote objects. Doing nothing more they can </b:printResponse>
use these remote objects in their main class. The objects can be </env:Body>
used as local objects; it is transparent for the user. The example
</env:Envelope>
below shows the call of the print method on an Investigator
instance as a service following the SOAP binding defined in the If another organization needs to use or retrieve the attributes of
WODL. the objects, whatever the system they are using, they can use the
HTTP stack implementation of their language to reach this object
Request
and use the CRUD verbs to process operations. In one line they
POST /WebOOManager/sap/com/publicSecurity/Investigator/51 can retrieve this value. In order to check the value of the attribute
HTTP/1.1 they can use a web browser and get the associated ATOM feed.
Host : research.sap.com The example below shows the communication established by a
Accept : application/soap+xml client to access the public values of an Evidence instance.
<?xml version="1.0" encoding="UTF-8"?> Request
<env:Envelope GET /WebOOManager/sap/com/publicSecurity/Evidence/69
xmlns:env="http://www.w3.org/2003/05/soap-envelope"> HTTP/1.1
<env:Body> Host : research.sap.com
<b:print xmlns:b="http://research.sap.com:8080/ If-None-Match : 8d7033
WebOOManager/sap/com/publicSecurity/
Accept : application/atom+xml
Investigator/51" />
</env:Body> Response
</env:Envelope> HTTP/1.1 200 OK
Response ETag : 8d7055
HTTP/1.1 200 OK Content-Type : application/atom+xml
Content-Type : application/soap+xml <?xml version="1.0" encoding="UTF-8"?>
<?xml version ="1.0" encoding="UTF-8"?> <feed xmlns="http://www.w3.org/2005/Atom">
<env:Envelope <title>Public fields of an Evidence</title>
xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <link rel="alternate"
href="http://research.sap.com:8080/WebOOManager/
sap/com/publicSecurity/Evidence/69"/>
<entry>
 <title>xs:string : description </title>
<link rel="alternate"
href="http://research.sap.com:8080/WebOOManager/
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>
Now, every organization can contribute to the completion of a
criminal case in order to gather updated information.
5. CONCLUSIONS
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.
6. REFERENCES
[1] D. J. Armstrong. The quarks of object-oriented development.
Communications of the ACM, 49(2):123-128, Feb. 2006.
Magazine article.
[2] C. Barreto, K. Norsworthy, S. Weerawarana, and M.
Bechauf. Testimonials for wsdl 2.0 recommendation, June
2007. http://www.w3.org/2007/06/wsdl20-testimonial.
[3] J. Daly, M.-C. Forgue, and Y. Hirakawa. W3C Completes
Work on Critical Web Services Standard, June 2007.
http://www.w3.org/2007/06/wsdl20-pressrelease.
[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.
[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. http://www.w3.org/TR/soap12.
[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. http://msdn.microsoft.com/en-
us/library/ms809311.aspx.
[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.
http://www.infoq.com/news/2007/01/wsdl-2-importance.
[12] A. T. Manes. REST and SOAP and document-oriented
services, 2005. http://atmanes.blogspot.com/2005/09/rest-
and-soap-and-document-oriented.html
[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.
http://www.w3.org/TR/2007/REC-wsdl20-20070626.
[14] OMG. Common Object Request Broker Architecture
(CORBA) Specification, Version 3.1, Jan. 2008.
http://www.omg.org/spec/CORBA/3.1/
[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. http://www.w3.org/TR/esi-lang.
[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.