Anda di halaman 1dari 12

A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.

html

A Matter of Style: Web Services Architectural


Patterns
Keywords: Design Patterns , Architecture , ebXML , Distributed Systems , Web Services , SOAP , UDDI
, Usage Scenarios , XML , webDAV

Kevin Mitchell
Chief Architect
Agogo Networks, Inc.
Vienna
Virginia
USA
kmitchell11@cox.net

Biography

Mr. Mitchell is a technologist with 9 years experience in architecture, design and


development of object-oriented enterprise and commercial applications and systems
integration. He has direct exposure to client/server, n-tier and web application architectures
and B2B/EAI integration utilizing web services, XML and commercial integration products.
Mr. Mitchell has industry experience in acquisition/procurement, mortgage secondary
markets and telecom verticals. Mr. Mitchell has participated in the W3C XML Protocol
Working Group, the Apache SOAP effort, and has authored a binding of WfXML to SOAP.

Abstract

Software engineers realize the power of employing common design patterns when building software
components. What is much less known, however, is that a similar technique may be applied to software
system architecture as well, including web services architecture, and with similar results. Software
architecture researchers call such patterns architectural styles. This paper compares and contrasts two
architectural styles for web services - RPC (Remote Procedure Call) and REST (Representational State
Transfer) - across several dimensions including scalability, flexibility and ease of implementation. The
paper also explores the applicability of each style to common usage scenarios via alternative
implementations of real-world web services such as ebXML (Electronic Business using eXtensible
Markup Language) and UDDI (Universal Description, Discovery and Integration) .

Table of Contents

1. Architectural Styles in a Nutshell


2. What are Web Services?
3. RPC Web Services Style

1 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

4. REST Web Services Style


5. Property-Based Comparison
6. Comparative Counter-Formulations
6.1 ebXML
6.2 UDDI
6.3 webDAV
Footnotes
Acknowledgements
Bibliography

1. Architectural Styles in a Nutshell


An architectural style is an abstract formulation of the common properties of similar architectures. For
example, UNIX shell programs and many compilers follow a pipe-and-filter approach. What is different
about these programs is the exact nature and capabilities of the filters. However, there are some
commonalities. One is that every filter has a consistent interface and is independent of other filters. An
architectural style expresses these commonalities.

To express an architectural style, one needs a common language for architectural elements. Perry/Wolf
[PW] define three types of elements: processing elements (components), data elements and connectors.
Components process data elements passed to them via connectors. In the pipe-and-filter style, filters are
components, the data passed between filters is the data element and pipes are connectors.

The client/server style is very popular with designers of distributed applications such as web services.
The client/server style includes two components: clients and servers. A server component offers
particular functionality, while a client component makes requests of the server component. Client and
server connectors handle the passing of requests and responses from clients to servers. In doing so, the
connectors form the interface between the client and server components. The request and response data
provided by the client and server components to the connectors form the data elements of the
client/server style.

Many different types of connectors have been employed in client/server systems. One of the most
prevalent is the RPC connector. This connector allows the server to expose functionality as a set of
named procedures or services, with specific input and output parameters. A client connector's interface
to a client component will include these same procedures and parameters. When the client component
invokes a procedure on this interface, the client connector will handle making the actual request by
communicating the procedure invocation over the network to a server connector. In turn, the RPC
server connector invokes the matching procedure deployed within the server component. One can see
from this how a connector defines the interface between components.

In most cases, to facilitate client-to-server RPC communication, a client connector must be configured
to communicate with a specific server connector prior to procedure invocation. Several schemes exist to
perform such configuration. For example, one may need to explicitly set the network address of the
desired server connector prior to invocation. Alternatively, one may specify a name or label for the
server connector. The client connector will then use that name to obtain an address, possibly with help
from some distributed naming service.

The major benefit offered by the client/server style is the separation of functionality between client and
server components. This allows each component to be simpler, as each only has to focus on a particular

2 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

function. Additionally, it provides for reuse of server functionality across client components.

2. What are Web Services?


What is a web service? There are myriad answers to this question, meaning there are many definitions of
a web service. This paper adopts a fairly high-level and abstract definition (in a relative sense), in
keeping with the focus on architectural style as an abstraction of concrete architecture. A web service is
basically some functionality offered to external applications, primarily so they can obtain or manipulate
information. What makes a web service different from other distributed application-to-application
mechanisms such as CORBA, DCOM and RMI is that it is based on Web standards for data formats and
application protocols. This allows distinct applications, either within an organization or outside an
organization, to interoperate more freely. The most common standards utilized are [XML] for data
format and HTTP (Hypertext Transfer Protocol) [HTTP] for application protocol. The fact that there
are many implementations of XML and HTTP increase the ease with which a web service solution may
be implemented. That is, in most cases, an organization will already have an HTTP infrastructure in
place, and can readily obtain an XML processor in almost any language.

In most cases, web services are about exposing existing functionality using web standards. It is about
re-purposing what already exists in a different form to get more financial "mileage" out of existing
"assets". Organizations have HTTP servers, so they use HTTP for web services. Organizations that
extend this philosophy to account for the full range of the massive existing HTTP infrastructure on the
Web will receive additional benefits.

Web services are also characterized by the distance, along two dimensions, between users of the
functionality and providers of the functionality. One dimension is network distance - the real promise of
web services is in the integration of distinct applications over a widely distributed network, the Internet.
Many components of the Internet are out of either party's control, and thus one cannot directly influence
and control their reliability. The longer distance stresses overall performance as well. The Internet is not
equivalent to a 100 megabit internal Ethernet LAN, either in speed or in reliability.

The other dimension is organizational distance. Web services are partly about connecting independent
parties rapidly. The key word here is independent. One party cannot completely influence the other, and
web service providers may not know all the consumers of their services. In such an environment,
"all-at-once" coordination between all parties involved with a web service is very difficult to achieve.
For example, a web service provider cannot expect to be able to alter the service interface and have all
the consumers simply follow suit.

Implementors of web services exposed over the Internet should also expect a larger population of
consumers than services exposed only within an organization. In fact, as the web services model matures
and adoption increases, implementors should expect consumer (and therefore transaction) volume to
reach or exceed typical web site volume. This adds scalability concerns and exacerbates the
performance and interface evolution concerns. Exposure over the Internet presents additional obvious
security considerations. This applies to the transport-level (firewalls) and to application level concerns
such as authentication and authorization.

3. RPC Web Services Style


The majority of web services efforts to date employ a basic client/server style, using an RPC connector,

3 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

but further constrained in three important ways. First, data elements (request and response data) must be
XML documents. Second, the web services RPC connector is constrained to utilize SOAP (Simple
Object Access Protocol) [SOAP] messages between client and server connectors. Third, the RPC
connector must abstract the underlying transport protocol to the component.

The XML constraint on data elements imparts several important properties. First, it allows further
independence between client and server components, because XML is an implementation-independent
format. This is in contrast to other formats that encode data in language-specific ways. For example, a
Java object serialized using Java language serialization will be completely unusable in a C++
environment. Second, XML document may be processed in a stream-oriented fashion, allowing
components and connectors to process requests and responses incrementally. Third, XML processors are
readily available in many languages, which should ease implementation.

SOAP messaging provides several important features in an RPC environment. SOAP defines a standard
XML message structure, allowing different connector implementations to communicate effectively.
Within this structure, SOAP also defines a standard RPC protocol, further enhancing connector
interoperability. Finally, SOAP defines a standard error representation, called a fault. Taken together,
these features allow for the development of many alternative connectors, which can be selected
independently by clients and servers without losing interoperability.

Perhaps more interesting is the RPC connector's hiding of the underlying transport protocol. A connector
may be capable of using several different protocols to transport the SOAP message from client to server
and vice-versa. The most common protocol employed is HTTP, but others such as SMTP (Simple Mail
Transport Protocol) may be used. HTTP-based RPC web services commonly establish a single HTTP
"service endpoint" that will receive procedure invocation messages via an HTTP POST. Regardless of
the transport utilized, the connector presents the same interface to the component. As with the overall
client/server style, this constraint offers separation of concerns between a component and a connector,
allowing each to evolve independently.

The various SOAP toolkits [1] provide concrete examples of RPC web services client and server
connectors. When using these toolkits, client-to-server communication functions much like basic RPC as
described in Chapter 1 . A web services client will invoke a "client-side version" of the procedure made
available by a remote server. On the server, the RPC web services connector receives the request, likely
from another connector that handles the underlying transport protocol. The RPC web services server
connector examines the procedure invocation message, invokes the corresponding procedure, and sends
back the response.

4. REST Web Services Style


While the REST style [REST] has received much attention lately in web services discussion groups and
standards bodies, its basic principles have been with us for some time. In fact, the REST style is a
distillation of the modern Web architecture to its core concepts, formed in order to analyze future
modifications to the Web against these core concepts. Like the RPC web services style, REST is based
on the client/server style. However, REST applies numerous constraints to architectural elements,
allowing a resulting architecture to exhibit properties not found in a traditional client/server style using
an RPC connector. These properties are important to fulfilling the requirements of a large distributed
system like the Web.

REST places a high degree of importance on data elements, and specifically a data element called a

4 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

resource. A resource is nothing more than a set of semantics, a concept. For example, "today's movie
schedule for my local movie theater" could be a resource. Note that a resource is not an implementation
of its semantics, or a means by which one may obtain information, or the storage mechanism for
information - it is just a concept. It is also important to note that while a resource, and therefore the
associated semantics, does not change over time, the resource's state will. In the preceding example, the
actual movie schedule will vary from day to day, but it will always be today's schedule.

REST defines two additional data elements that allow components to deal with resources: resource
identifiers and representations. A resource identifier serves one and only one purpose - it provides an
unambiguous label (i.e. identifier) for a resource. A resource identifier is unambiguous in the sense that a
single resource identifier labels one and only one resource. It is possible, however, for a single resource
to be labeled with many different resource identifiers. It is important to note that a resource identifier
only labels a resource - it is not an address for interacting with resource, but it may be used in such a
fashion. A representation is the state of a resource captured at a particular instant in time. It may contain
raw representation data and metadata such as the format of the raw representation data. In the modern
Web, URI (Uniform Resource Identifiers) [URI] are resource identifiers, and HTML documents, PNG
images and XML documents are examples of representations.

A REST application functions by transferring representations between components using a connector.


REST components include user agents and origin servers. These are analogous to the client and server
components of the RPC web services style. Origin servers are responsible for implementing resource
semantics - that is providing and consuming representations according to the semantics identified by a
resource identifier. User agent components interact with origin servers (through connectors, naturally) to
obtain representations and send revised representations to the server. Mozilla (http://www.mozilla.org)
and cURL (http://curl.haxx.se/) are examples of user agents in the modern Web; Apache
(http://www.apache.org) and Jigsaw (http://www.w3.org/Jigsaw/) provide examples of origin servers.

REST client and server connectors are critical elements of the REST style. They are constrained to be
uniform, abstract and stateless. The uniformity constraint ensures that clients interact with each and
every server component using a consistent interface. In RPC terms, this means that each and every
server exposes the exact same procedures with the exact same semantics and the exact same
parameters. Given that a REST interaction involves only a simple transfer of representations, one can
see how a consistent interface can be achieved - there are just not that many possible operations that are
needed to perform a simple transfer. Like the connector of the RPC web services style, a REST
connector is abstract, hiding the underlying communication protocol from the component utilizing the
connector and therefore separating concerns between the component and the connector. REST
connectors also ensure that all interactions are stateless, with each request and response carrying all
information necessary to fully understand the request or response independent of any preceding
interaction.

A REST client connector allows a component to identify a target resource (through a resource identifier)
and transfer a representation from or to an origin server responsible for that resource. A server
connector receives requests for representation transfer and allows for propagation of responses to those
requests. Various libraries such as libwww (http://www.w3.org/Library/), libcurl (http://curl.haxx.se/),
and Java's java.net (http://java.sun.com) package are examples of a REST client connector.
Server-side libraries such as libwww and the Java servlet API (http://java.sun.com) exemplify the REST
server connector. It should come as no surprise that all these concrete connectors can employ the HTTP
protocol for transfer, as HTTP is specifically engineered for transfer operations and is a critical piece of
the modern Web. However, it is important to note that a REST connector is not constrained to use only
HTTP - it may use any protocol it wishes so long as the interface remains uniform, abstract and stateless.

5 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

A REST client or server connector uses a resource identifier in a similar fashion - as an indirect means of
identifying handlers for different parts of the interaction. A client connector will use the resource
identifier to locate an appropriate handler to make the request and process the response. For example,
Java's java.net package allows for the lookup of a handler based on the scheme of the URI. The key
point here is that the REST client component does not specify the handler, it specifies the resource
identifier which is then used to determine the handler. A REST server connector goes through a similar
process, using the resource identifier to locate a handler to fulfill the request.

The REST style also requires server connectors to indicate the cacheability of responses to
representation transfer requests. In the modern Web, this is accomplished by the caching mechanisms
built into HTTP. REST defines a specific type of connector, called a cache connector, which can
examine the cache control data on a response and save the response for future use as appropriate. A
cache connector can be applied to a client connector (e.g. a web browser cache), allowing one to avoid
making a distributed request if the response can be fulfilled from the cache. The same process can be
applied to a server connector to avoid the generation of a response from scratch. REST also defines
specialized components called a gateways and proxies that can intercept requests to an origin server. A
gateway or proxy is both a client and a server, and contains both client and server connectors. A cache
connector may be applied to gateway or proxy server connector to form what is commonly called a
cache server. Squid (http://www.squid-cache.org/) provides a cache server example for the modern Web.
To the extent that responses can be cached, and cache connectors can be applied, REST's cache
constraints can improve an application's scalability and performance.

A web service architecture in the REST style will commonly apply two additional constraints. First,
resource representations will be in XML format to derive the benefits of XML as described in Chapter
3 . Second, REST connectors will utilize the HTTP protocol, since HTTP is quite prevalent on the
modern Web and helps meet the REST connector's uniformity and statelessness constraints.

5. Property-Based Comparison
This section compares the RPC and REST styles for web services by examining specific properties or
quality attributes in isolation. The strength or weakness of either style with respect to a given property
should be viewed relative to the importance of that property in a given situation. For example, style A
may be more scalable than style B, but this is of minimal consequence if scalability is not a concern for
the system under construction. The following properties are discussed in this section:

Scalability
Performance
Flexibility
Ease of Implementation (Implementability)

It is also important to realize that the subsequent analysis is based on constraints imposed by the
architectural styles and on common implementation patterns, not on a specific implementation. A
specific implementation may or may not meet all constraints of its style, and may not employ a common
implementation pattern. Additionally, there are concerns not specifically addressed by an architectural
style that can affect a system's properties. For example, no architectural style is going to prevent a
programmer from writing a slow algorithm, thereby decreasing performance. Consequently, one cannot
apply the subsequent analysis unilaterally - one must first examine how well a given system adheres to
its style, and then act accordingly.

6 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

Scalability pertains to a web service's ability to handle increases in activity without performance
degradation. REST's stateless interactions and cache constraints positively affect a REST-styled
application's ability to scale. Stateless interactions prevent a server connector from tracking requests
associated with a specific client connector over a period of time (session). In a highly distributed
application with an unknown, uncontrollable and potentially large number of clients, allowing for
tracking client requests can easily lead to scalability issues. A REST application avoids these issues by
forbidding the practice altogether. RPC web services can be stateless as well, but they can also be
stateful. In fact, JAX-RPC (Java API for XML-based RPC) [JAXRPC] , a standard Java API for RPC
web service client and server connectors, specifically requires such connectors to support stateful
interactions.

As mentioned in Chapter 4 , REST enables responses to be cached and subsequently served from a
cache. This improves scalability by indirectly reducing the number of requests that will require
processing by an origin server, which is usually the most resource-intensive processing in the application.
By placing cache servers close to the point of request origin, one can also reduce the number of requests
transmitted over a wide-area network such as the Internet, thereby improving the scalability of network
machinery such as routers and firewalls.

One might think that since RPC web services commonly employ HTTP, and HTTP includes
REST-friendly caching mechanisms, that RPC web services can enjoy these caching benefits as well.
Unfortunately, that is not the case because the RPC web service style utilizes HTTP as a transport
protocol, and not as an application protocol. HTTP's caching mechanisms rely on accuracy in a) the use
of HTTP methods to reflect application semantics and b) the allocation of distinct URI to distinct
information resources. RPC-styled web services fail to achieve such accuracy because they a) use POST
for both modification and retrieval requests and b) allocate a single URI to disparate resources.
Consequently, RPC web services cannot utilize the caching mechanisms of HTTP and therefore cannot
enjoy the resultant benefits. On the contrary, REST web services use HTTP as an application protocol
and correctly allocate distinct URI to distinct information resources. Therefore they can enjoy the
benefits of HTTP caching.

Performance pertains to the speed, both actual and perceived, of a given web service. REST's stateless
interactions can actually hamper performance by requiring all necessary information to be transferred
between components. Depending on the nature of the application, this may or may not be a significant
issue. REST web services may compensate for the additional information transmitted by employing
caching to eliminate the need to transmit information in the first place. RPC web services can be
stateful, and therefore can reduce the amount of information transferred between components by
maintaining state at the server and transmitting only state "identifiers". However, web service
implementors must balance this performance advantage with the scalability downside and other negative
properties associated with stateful interactions.

Flexibility is the ability of a web service to be implemented and consumed in different ways. The
numerous constraints of the REST style, especially on connector behavior, reduce the universe of readily
available implementation choices, thereby reducing implementation flexibility. To build a web service in
the REST style one needs a protocol capable of supporting a uniform interface, and there is really only
one available choice: HTTP. One could, for example, build a REST web service using SMTP, but one
would need to define a set of operations with application semantics. On the contrary, RPC web service
connectors only need the protocol for transport purposes because the procedures carry application
semantics. Any protocol is capable of transport of some sort, so RPC web service implementors have
numerous readily-available options.

7 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

On the service consumption front, REST web services excel in flexibility. In particular, REST web
services that perform information retrieval (i.e. HTTP GET operations) are readily and immediately
consumable from an enormous number of environments. Some environments in which a REST web
service can be readily consumed are:

Hyperlink from a HTML web page


Participation in XSLT processing via XSLT's document() function
Subject of an RDF (Resource Description Framework) assertion
Target of a VoiceXML submit or goto directive
Application of a P3P (Platform for Privacy Preferences) privacy policy

Implementability refers to the ease with which one can produce or consume a web service. Perhaps
more than any other, this property highlights the extensive differences between the RPC and REST
styles for web services. There are several factors that contribute to implementability; each will be
examined in turn.

Interface complexity contributes to web service implementability. As the complexity increases,


production costs associated with design and development increase. The costs of consuming the web
service also increase, as consumers must spend more time understanding a complex interface. The
number of operations, and their associated semantics, drive interface complexity. The RPC web services
style does not constrain the number and semantics of operations. Consequently, the associated
complexity is unbounded. This is especially true from the view of the consumer. In an RPC web service
model, a consumer should anticipate needing to digest a different set of operations for each web service
consumed.

On the contrary, REST constrains the number and semantics of operations. Every REST web service
exposes one or more operations from a uniform set of operations. So, there will be variability across
services, but that variability will be less than the RPC web services case because operations must be
drawn from a uniform set of operations. It stands to reason that a REST web service will present a
substantially less complex interface than an equally-functional RPC web service.

The availability of development tools also contributes to web service implementability. As mentioned in
Chapter 2 , web services commonly expose existing functionality through a more universally accessible
interface based on Web standards. There are numerous tools available that can take existing
RPC-oriented functionality and "automatically" make it available as an RPC web service. Additionally,
these tools generate the corresponding client connectors. These tools can dramatically increase the speed
at which one can produce and consume RPC web services. Such tools are not readily available for REST
web services.

Exposure to the architectural style also plays a role in web service implementability. Web services that
"feel" familiar will be easier to produce and consume. The RPC web services style will obviously be
quite familiar to web service producers and consumers, as it is the basis for most existing web services,
and it is simply a refinement of a very common distributed system style. REST should also be familiar to
most, as it reflects the properties and interactions associated with the Web. However, the use of the
REST style outside of "web browsing" is not familiar to most. This reduces the implementability of a
REST web service.

6. Comparative Counter-Formulations

8 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

As can be expected, existing web services employ either the RPC or REST style. Differences between
the two styles may be highlighted by devising an alternative REST-styled implementation of an
RPC-style web service and vice-versa. This section provides several such comparative counter-
formulations.

6.1 ebXML

ebXML (http://www.ebxml.org) is a multi-part specification that defines a business process specification


language [ebBPSS] , a business information registry [ebRS] , a business collaboration agreement
language [ebCPP] and a messaging protocol [ebMS] . In ebXML, a business process consists of a
sequence of business transactions conducted by organizations playing a set of roles. A business
transaction is an electronic exchange of business documents between two parties using the messaging
protocol. Parties exchange at most two documents during any transaction: at least one request document
and an optional response document. For various parties to conduct electronic business according to a
given process, they must first assert which roles each will play in the process and how each party will
receive documents using the messaging protocol. A business collaboration agreement is used to capture
these assertions.

The ebXML messaging protocol provides for the exchange of business documents between different
organization using Web standards such as HTTP and XML, and therefore provides a foundation for a
web service. An ebXML web service will accept a business document, a service identifier that targets
the document at a particular document handler, and an action identifier that indicates the business
transaction to be undertaken by the handler. ebXML defines a specific service/action pair that allows
access to the status of a previously submitted document. ebXML web services utilize various underlying
protocols, including HTTP and SMTP, to transport messages between client and server. The typical
mode of operation is to establish a single transport endpoint to receive all request messages.

While it will not use RPC terminology, an ebXML web service will follow the RPC web services style.
The service/action pair effectively identifies a procedure, and the supplied document provides a single
parameter. So, while all ebXML operations will share a common signature, the operations will vary from
organization to organization. For example, one organization might define a "createOrder" action, while
another might name a similar action "submitOrder". ebXML's use of an underlying protocol solely for
transport purposes is also representative of the RPC web services style.

An ebXML web service can be formulated in the REST style by viewing each business transaction as a
distinct information resource instead of a procedural invocation. One would commence a transaction by
transferring the business document to an origin server (likely using an HTTP POST), targeting the
appropriate transaction resource. The response representation would include (likely via a Location
HTTP header) an identifier for a distinct transaction status resource and a response business document
or business signals in keeping with transaction semantics. The transaction status resource's
representations (retrievable via an HTTP GET) would include information equivalent to that provided by
the ebXML message status service.

The above formulation, which models an ebXML transaction and associated status as distinct resources,
carries several attractive properties. One can attach a P3P privacy policy to the transaction, allowing
consumers to understand the privacy implications of engaging in the transaction. Transaction status
information can be cached (perhaps for long periods of time once the transaction is complete), linked to
and incorporated in XML stylesheet processing.

9 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

6.2 UDDI
UDDI (http://www.uddi.org) [UDDI] specifies a set of web services that provide for manipulation and
retrieval of information about businesses. Business information includes basic contact information,
product and service categories and web services offered by the business. UDDI's web services are
defined in terms of programming APIs, and are clearly based on the RPC web services style.

A UDDI registry will contain various types of objects, including business entities, business services, and
binding templates. UDDI web services basically allow one to create and alter objects, to obtain lists of
objects meeting certain criteria, and to obtain detailed information on specific objects. Additionally,
clients can register to be notified when specific objects change and modify the parameters associated
with such registrations over time.

A REST formulation of UDDI can be achieved by modeling the sets of objects of a given type, and each
individual object, as distinct resources. So, "all business entities" and "all binding templates" would be
distinct resources, as would each individual business entity and binding template. The same concept
would hold for subscriptions as well. To create a new object, one would simply transfer a representation
(using HTTP POST) of the new object to the "set" resource of the corresponding type. The response
representation would include an identifier for the newly-created resource. To alter an object, one would
transfer a representation (using HTTP PUT or POST) to a specific resource. Individual UDDI objects
(and entire sets) would be obtained by requesting (via HTTP GET) a representation of the appropriate
resource.

Object search functionality may be accomplished in a REST fashion by establishing resources that model
sets of objects meeting specific criteria. The number of such resources is effectively unbounded, as in
many cases the resource identifier will include highly variable information likely conveyed in the query
portion of the URI. For very complex criteria such as those involving arbitrary relational expressions
(e.g. nested or grouped AND/OR expressions), a different approach may be required. For these types of
searches, one can allow clients to establish resources that model the query itself. In the same way that a
client can create business entities or binding templates, a client can create a query resource given a
representation of the query. This would also result in the creation of a resource for the query's current
result set. Subsequently, the client simply requests a representation of the query result resource in order
to perform the search.

The preceding REST formulation of UDDI carries some obvious advantages, the primary one being the
ability to cache results of information retrieval operations using proven HTTP infrastructure. A UDDI
registry is effectively a directory, and in that capacity it will be queried far more often that it will be
modified. Additionally, as a centralized directory, a UDDI registry should expect an enormous number of
query requests. The REST formulation allows information retrievals to be cached close to client
components, or at the server, or in a distributed fashion using inter-cache coordination.

6.3 webDAV
webDAV (http://www.webdav.org) [webDAV] is an HTTP-based protocol for the remote authoring and
management of documents. In some functions, such as document creation, retrieval, update and
deletion, webDAV is indistinguishable from HTTP. In other functions, such as document property
management, webDAV extends HTTP with custom methods such as PROPFIND. Regardless of the
function, individual documents, collections of documents and properties of both are modeled as
information resources. Overall, webDAV follows the REST style, although it does extend the generic

10 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

interface with additional methods, increasing the complexity slightly.

An RPC formulation of webDAV can be achieved by defining procedural counterparts to the various
HTTP/webDAV methods, identifiers for documents and document collections, and a service endpoint to
receive the requests and provide responses. For example, webDAV's GET operation, used to retrieve a
document, would be replaced by a getDocument procedure. This procedure would accept a documentID
parameter and return the corresponding document. If the identifier were unknown, the procedure would
have to communicate that in some way, perhaps via the absence of a returned document.

Footnotes
1. A good list of SOAP toolkits may be found at http://www.whitemesa.com/interop.htm.

Acknowledgements
The author would like to thank Al Gough, Brendan Haggerty, Mala Mital, Robert Schettini and Mike
Stopper of AMS for many productive discussions on RPC and REST web services.

Bibliography
[PW]
Foundations for the Study of Software Architecture, Perry, D.E. and Wolf, A. ACM Sigsoft
Software Engineering Notes 17, 4 (Oct 1992), pp. 40-52.
[XML]
Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation,
http://www.w3.org/TR/REC-xml, 6 October 2000.
[HTTP]
Hypertext Transfer Protocol -- HTTP/1.1, Fielding, R., Gettys, J., Mogul, J.C., Frystyk, H.,
Berners-Lee, T., IETF RFC 2616, January 1997.
[SOAP]
Simple Object Access Protocol (SOAP) 1.1, W3C Note, http://www.w3.org/TR/2000/NOTE-
SOAP-20000508/, 8 May 2000.
[REST]
Architectural Styles and the Design of Network-based Software Architectures, Doctoral Thesis,
Fielding, R., 2000.
[URI]
Uniform Resource Identifiers (URI): Generic Syntax, Berners-Lee, T., Fielding, R., Masinter, L.,
IETF RFC 2396, August 1998.
[JAXRPC]
Java API for XML-based RPC (JAX-RPC 1.0), JSR-101, Java Community Process, Sun
Microsystems, 11 June 2002.
[ebBPSS]
ebXML Business Process Specification Schema, UN/CEFACT, OASIS, 11 May 2001
[ebRS]
OASIS/ebXML Registry Services Specification, OASIS, 6 December 2001
[ebCPP]
Collaboration-Protocol Profile and Agreement Specification, UN/CEFACT, OASIS, 10 May

11 of 12 4/12/2011 2:51 PM
A Matter of Style: Web Services Architectural Patterns file:///C:/home/post-transfer/rest-rpc-paper.html

2001
[ebMS]
Message Service Specification, OASIS, 1 April 2002
[UDDI]
UDDI Version 3.0, Accenture, Ariba, Inc., Commerce One, Inc., Fujitsu Limited, Hewlett-
Packard Company, i2 Technologies, Inc., Intel Corporation, International Business Machines
Corporation, Microsoft Corporation, Oracle Corporation, SAP AG, Sun Microsystems Inc.,
Verisign, Inc., 19 July 2002
[webDAV]
HTTP Extensions for Distributed Authoring - webDAV, Goland, Y., Whitehead, E., Faizi, A.,
Carter, S., Jensen, D., IETF RFC 2518, February 1999.

12 of 12 4/12/2011 2:51 PM