a comparison of service-oriented, resource … comparison of service-oriented, resource-oriented,...

Copyright © 2003 Jorgen Thelin / Cape Clear Software Inc.

A Comparison of Service-oriented,Resource-oriented, and Object-oriented

Architecture StylesJørgen ThelinChief Scientist

Cape Clear Software Inc.


AbstractThe three common software architecturestyles commonly used in distributed systemsand XML Web Services are compared andcontrasted. In particular, the key differencesbetween traditional SOAP and REST stylesare explored. Guidelines are presented onwhich style is most applicable for certainapplication scenarios, and when acombination of styles is necessary.


Setting the Scene– Architecture Patterns and Styles


What is a Pattern?Martin Fowler defines a “Pattern” as:

An “idea” that has been useful in one practicalcontext and will probably be useful in others”[Martin Fowler, “Analysis Patterns”, 1997]

The concept of patterns can be applied atmany levels in software projects:

Design / Code PatternsAnalysis / Model PatternsArchitecture Patterns / Architectural Styles


Pattern Levels – Design / Code PatternsLowest level of patterns in software

Based around a reusable chunk of code tosolve a particular problem

Typically implemented through source codetemplates and/or code generation

Provides a “template” for implementing asystem function, but requiring elaboration tocomplete


Pattern Levels – Analysis / ModelPatternsReusable object models (for example UML)

Typically implemented through UML modeltemplates or perhaps meta-models

Provides a “template” for a group of relatedsystem functions, but often within a specificdomain (for example Finance)


Pattern Levels – Architecture Patterns /Architecture StylesReusable system structures, interconnectionsand interactions

Typically implemented through architecturestandards and policies

Provides a “template” for subsystemstructure and communications betweensubsystems


What is Software Architecture?The software architecture of a program orcomputing system is the structure orstructures of the system, which comprisesoftware components, the externally visibleproperties of those components, and therelationships among them.

[Bass, Clements & Kazman, “Software Architecture inPractice”, 1998]


What is a Software Architecture Style?#1An architectural style defines:

a family of systems in terms of a pattern ofstructural organization

a vocabulary of components and connectors, withconstraints on how they can be combined

[Shaw & Garlan, “Software Architecture: Perspectives on anEmerging Discipline”, 1996]


What is a Software Architecture Style?#2An architecture style:

Describes a class of architectures or significantarchitecture piecesIs found repeatedly in practiceIs a coherent package of design decisionsHas known properties that permit reuse

[Clements, Kazman & Klein, “Evaluating Software Architecture”,2002]In other words, architecture styles are “designpatterns” for the structure and interconnection withinand between software systems.


Distributed SystemsArchitecture Styles


Distributed Systems Types

Two main types of distributed softwaresystems:

Request / Response (“Call & Return” or RPC) typesystemsMessage passing type systems


Distributed System Type #1– Request / Response (RPC) SystemsRequest / Response (RPC) type systems are:

Call oriented systemsUsually synchronous in natureOperations have input parameters and output / returnvaluesFocus is on:

The particular operation to be invokedThe set of input valuesThe set of output valuesThe correlation of replies with requests

No real focus on:How the individual values are marshalled as a unitHow the output values are produced from the input values(assuming the correct output is produced!)


Distributed Systems Type #2- Message Passing SystemsMessage passing type systems are:

Data oriented systemsUsually asynchronous in natureMessages are constructed and send to a destination

Focus is on:Constructing the message payload in the correct formatHow to dispatch the message (transport medium)Where to dispatch the messages to (endpoint)

No real focus on:What will happen to messages after they are dispatchedWhether there will be a corresponding reply message


Architecture Styles for DistributedSystemsFor “call-based” distributed systems, there are threemain architecture styles commonly used:

Object-oriented

Resource-oriented

Service-oriented

Service-oriented architecture styles are frequentlyused with “message-passing” systems too[but further discussion is outside the scope of this presentation]


Object-Oriented Architectures - 1Involve communicating with particular objectinstances

Objects have State, Behaviour and Identity.

Communications are implicitly stateful (talking to aparticular previously-created object instance)

Servers can use intelligent management mechanisms(such as EJB passivation policies) to better manageloading on the server from handling lots of individualobject instances


Object-Oriented Architectures - 2All state information is held on the server-side

Each access to the object involves a networkcall and round-trip communication

Design patterns have evolved to provideways to minimise network calls through bulkdata retrieval

For example “Value Objects” in EJB programminghttp://www2.theserverside.com/patterns/thread.jsp?thread_id=79


Object-Oriented Architectures - 3Usually use specific non-Internet-friendlyprotocols such as IIOP, DCOM or RMI forcommunication

Usually require pass-by-reference facilities

Marshalling object references generallyprecludes using different types of softwareon client-side and server-side


Resource-Oriented Architectures - 1Involve retrieving particular resource instances

Some examples are:Retrieving a HTML page using HTTP GET requestRetrieving a database table row using a SQL SELECT command

Resource instances are identified by some sort of“address” data included with the requestSome examples are:

A HTTP URLa WHERE clause in a SQL SELECT statement

Resources have State (current values of data), andIdentity (implicit from the input “query” data used tofind/select the resource)Encoding “parameters” into addresses can becomedifficult for complex query resources


Resource-Oriented Architectures - 2Retrieving a resource creates a (detached)snapshot of its current state on the client-side

“Master copy” of the resource data remainson the server

Usually can “cache” the resource data forlater reuse within specified expiration timeswithout having to re-retrieve the data


Resource-Oriented Architectures - 3Updates to resources typically involvereplacing the previous copy of the data witha new copy (for example HTTP PUT), butthere may also be some command verbs fordoing “partial updates” (for example HTTPPOST or SQL UPDATE)

Changes to the “master copy” of theresource on the server-side are notautomatically duplicated in the detachedcopies of the resource on the client-side


Resource-Oriented Architectures - 4Variations in this architecture style involve“distributed resource copies” where multiplecopies of the resource data are kept, andchanges and amendments are broadcast tokeep all copies in synchronization – oftenusing Publish/Subscribe messagingtechniques


Service-Oriented Architectures - 1Involve communicating with a specific applicationservice by sending all messages/requests for thatservice to a specified “endpoint”

Communications are implicitly stateless (all requestsare sent to the same service endpoint)

Servers can use intelligent call mechanisms (such assession “cookies”) to map between stateless servicerequests and stateful / session-oriented processinglogic


Service-Oriented Architectures - 2Endpoints may be specific to a service, or shared bymultiple services – so long as requests can beuniquely dispatched to the appropriate serviceoperation to handle that request

The service endpoint works out how to process therequest message by inspecting some of the messagecontent data – either an “envelope” or the actual“payload” itself

A separate interface description exists for the servicewhich defines the message and payload formats (forexample, a WSDL file)


REpresentational State Transfer (REST) - 1The REST approach is one of the majorresource-oriented approach to buildingdistributed systems using “pure” webtechnology (HTTP, HTML)

REST (REpresentational State Transfer) is aterm coined by Roy Fielding in his PhDdissertation describing a resource-orientedarchitecture style for networked systemshttp://www.ebuilt.com/fielding/pubs/dissertation/top.htm


REpresentational State Transfer (REST) - 2Roger Costello has written a useful Tutorial andIntroduction to REST:http://www.xfront.com/REST.html

Summary of a REST-style interaction:Find or work out the resource address or URLRetrieve the web resource using the URLA representation of the resource is returned (such as a HTMLpage or an XML document)The returned data is processed to place the client in a particularstate (perhaps by rendering the HTML page)Hyperlinks in the resource data can be used to retrieve relatedresources, which transfers the client to a new state (such asby rendering a different HTML page)

The client application changes state with each resourcerepresentation retrieval --> “Representation State Transfer”


SOAP vs. RESTSOAP is often seen as a direct rival to a REST-basedarchitecture, as SOAP v1.1 used a solely Service-orientedapproach, and the debate from both sides has been savage!http://lists.w3.org/Archives/Public/www-tag/2002Apr/0235.html

In fact, support for a more REST-based architecture stylehave been included in the SOAP 1.2 Specification with thenew SOAP Web Method facilities:http://www.w3.org/TR/soap12-part2/#WebMethodFeature

Using “RESTful SOAP” can be useful for exposing cacheable(typically read-only or idempotent) SOAP operationsSam Ruby has written an article comparing SOAP and RESTand showing how they can co-exist peacefully together:http://www.intertwingly.net/stories/2002/07/20/restSoap.html


Web Services vs. REST - 1There is no real conflict between the generalidea of Web Services and the REST approach

From W3C “Web Services DescriptionRequirements” document:

Definition:A Web Service is a software application identified bya URI [IETF RFC 2396], whose interfaces and bindingare capable of being defined, described anddiscovered by XML artifacts and supports directinteractions with other software applications usingXML based messages via Internet-based protocols.


Web Services vs. REST - 2Web Service standards already support many RESTfulfeatures, and are adding more:

HTTP GET bindings in WSDL v1.1SOAP Web Methods in SOAP v1.2

The total set of Web Service specifications provide asuperset of the REST approach – supporting Service-oriented as well as Resource-oriented mechanismsWSDL v1.2 should add facilities to allow the fulldescription of the payload formats for REST /Resource-oriented approaches based in URLsRoger Costello has written an article on “Building WebServices the REST way” :http://www.xfront.com/REST-Web-Services.html


Choosing an Architecture Style


Comparison of 3 DistributedArchitecture Styles

Specific to this service– description isprotocol specific (e.g.WSDL)

Generic to therequest mechanism(e.g. HTTP verbs)

Specific to thisobject / class –description ismiddleware specific(e.g. IDL)

Applicationinterface

Creation of requestpayloads

Request addressing(usually URLs)

Marshallingparameter valuesMain Focus

Yes – part of servicedescription (e.g. XMLSchema in WSDL)

No – nothing directlylinked to address /URL

Yes – usuallymiddleware specific(e.g. IDL)

Payload / dataformat description

NoYesNoAre repliescacheable?

One endpoint addressper service

Unique address perresource

Routed to uniqueobject instanceAddressing /

Request routing

Service instancesResource instancesObject instancesGranularity

Service-oriented

Resource-oriented

Object-orientedAttribute


Choosing Between Architecture StylesObject-oriented distributed system architectures areusually best for “closed” systems controlled by asingle organization.Generally involve tight coupling between client andserver due to object reference semantics

Resource-oriented approaches revolve around thecache-ability of resource data, so are only typicallyused for read-only, read-mostly or idempotentoperations, or results that have a “validity window” or“expiration period”

Service-oriented approaches are generally the mostflexible, especially with full interface and payloaddescriptions using WSDL


Combining Architecture StylesUsually best to stick to a single architecturestyle, but combinations are technicallypossible

For example, a Web Service application coulduse a combination of architecture styles:

Resource-oriented approach for simple data readsService-oriented approach for complex dataretrieval operations or data updates


How to avoid the Choice of StyleThere are many tools and utilities that allow us tosupport multiple architecture styles from a commonmeta-descriptionThis can allow us to use a higher level abstraction(“a call is a call is a call”)Can avoid the constraint of a single architecture style,and generate / reuse for many styles using the samecodebase / interface

One example is the SCOUT2 product from DeltaSoftware Technology Group

See website http://www.d-s-t-g.com


Summary and Conclusion


SummaryThe choice of architecture style is an important decision forany software systemChoice of architecture style can have implications on re-usability and ease of interconnection with other systemsTwo main system types are:

Request / Response (also known as “Call and Return” or RPC)Message passing

Three main Request/Response architecture styles are:Object-orientedResource-orientedService-oriented

Web Services can be written using both Resource-orientedor Service-oriented approaches – with SOAP v1.2 and WSDLv1.2 helping to unify this

a comparison of service-oriented, resource … comparison of service-oriented, resource-oriented,...

Documents