1.6.2 Services Oriented Architecture



The Web architecture and the  Web Services Architecture (WSA) are  instances of a Service Oriented Architecture (SOA).  To understand  how they relate to each other and to closely related technologies such as CORBA, it may be useful to look up yet another level and note that SOA is in turn a type of Distributed System. A distributed system, consists of discrete software agents that must work together to implement some intended functionality.  Furthermore, the agents in a distibuted system do not operate in the same processing environment, so they must communicate by hardware/software protocol stacks that are intrinsically less reliable than direct code invocation and shared memory. This has important architectural implications  because distributed systems require that developers (of infrastructure and applications) consider the unpredictable latency of remote access, and take into account issues of concurrency and the possibility of partial failure.  [Samuel C. Kendall, Jim Waldo, Ann Wollrath and Geoff Wyant, "A Note On Distributed Computing", http://research.sun.com/techrep/1994/abstract-29.html].

An SOA is a specific type of distributed system in which the agents are "services"  For the purposes of this document, a service is a software agent that performs some well-defined operation (i.e., "provides a service") and can be invoked outside of the context of a larger application.  That is, while a service might be implemented by exposing a feature of a larger application (e.g., the purchase order processing capability of an enterprise resource planning system might be exposed as a discrete service), but the users of that server need be concerned only with the interface description of the service.  Furthermore, most definitions of SOA stress that "services" have a network-addressable interface and communicate via standard protocols and data formats.


Figure 2, Generic Service Oriented Architecture Diagram

In essence, the key components of a Service Oriented Architecture are the messages that are exchanges, agents that act as service requesters and service providers, and shared transport mechanisms that allow the flow of messages. In addition, in public SOAs, we include the public descriptions of these components: descriptions of the messages, descriptions of the services and so on. These descriptions may be machine processable, in which case they become potential messages themselves: for use in service discovery systems and in service management systems.


1.6.3 SOA and REST archictures

The World Wide Web is a SOA that operates as a networked information system that  imposes some additional constraints: Agents identify objects in the system, called "resources," with Uniform Resource Identifiers (URIs).
Agents represent, describe, and communicate resource state via "representations" of the resource in a variety of widely-understood data formats (e.g. XML, HTML, CSS, JPEG, PDF ). Agents exchange representations via  protocols that use URIs to identify and directly or indirectly address the agents and resources. [W3C Technical Architecture Group, "Architecture of the World Wide Web"  http://www.w3.org/TR/webarch/]

An even more constrained architectural style  for reliable Web applications known as "Representation State Transfer" or REST has been proposed by Roy Fielding and has inspired both the TAG's Architecture document and many who see it as a model for how to build web services  ["Architectural Styles and the Design of Network-based Software Architectures" http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm].  The REST Web is the  subset of the WWW in which agents are constrained to, amongst other  things, expose and use services via uniform interface semantics, manipulate  resources only by the exchange of "representations",  and thus use "hypermedia as the engine of application state."

The scope of "Web services" as that term is used by this working group is somewhat different.  It encompasses not only the Web and REST Web services whose purpose is to create, retrieve, update, and delete information resources but extends the scope to consider services that perform an arbitrarily complex set of operations on resources that may not be "on the Web."  Although the distrinctions here are murky and controversial,  a "Web service" invocation may lead to services being performed by people, physical objects being moved around (e.g. books delivered). 

We can identify two major classes of "Web services":  REST-compliant or "direct resource manipulation" services in which  in which the primary purpose of the service is to manipulate XML representations of Web resources using
the a minimal, uniform set of operations operations, and "distributed object" or "Web-mediated operation" services in which the primary purpose of the service is to perform an arbitrarily complex set of operations on resources that may not be "on the Web", and the XML messages contain the data needed to invoke those operations.  In other words, "direct" services are implemented by web servers that manipulate data directly, and "mediated" services are external code resources that are invoked via messages to web servers.  [Ed note:  Lots of open terminology issues here, such as what we call these two types of services, and whether the "web service" is the interface to the external code or the external code itself].

Both classes of "Web services"  use URIs to identify resources and use Web protocols and XML data formats for messaging. Where.they fundamentally differ is that "distributed object" [Ed note: or "mediated services"]  use
application specific vocabularies as the engine of application state, rather than hypermedia.  Also, they achieve some of their benefits in a somewhat different way. The emphasis on messages, rather than on the actions that are caused by messages, means that SOAs have good "visibility": trusted third parties may inspect the flow of messages and have a good assurance as to the services being invoked and the roles of the various parties. This, in turn, means that intermediaries, such as fire-walls, are in a better situation for performing their functions. A fire-wall can look at the message traffic, and at the structure of the message, and make predictable and reasonable decisions about security. 

In REST-compliant SOAs, the visibility comes from the uniform interface semantics, essentially those of the HTTP protocol: an intermediary can inspect the URI of the resource being manipulated, the TCP/IP address of the requester,  and the interface operation requested (e.g. GET, PUT, DELETE) and determine whether the requested operation should be performed.  The TCP/IP and HTTP protocols have a widely supported set of conventions  (e.g. known ports) to support intermediaries, and firewalls, proxies, caches, etc. are almost universal today.  In non-REST [Ed. note: or "distributed object" or "mediated" ] but XML-based services, the visibility comes from the fact that XML is the universal meta-format for the data.  Intermediaries can be programmed or configured to use the specifics of the SOAP XML format, standardized SOAP headers (e.g. for encryption, digital signature exchange, access control, etc.), or even generic XPath expressions to make routing, filtering, and cacheing decisions.  XML-aware firewall and other "edge appliance" products are just coming to market as of this writing.