SOA.WRK.

The { REST + Web 2.0 + Data Mashup } vs SOA debate: Part I

OK, after repeating these arguments so many times, I decided to write this series as a reference, since some parts are still unique personal opinion.

What is SOA?

For those who are not familiar with the concept of Service-Oriented Architecture (SOA), a definition I like to use is from Wikipedia, listed somewhere in the middle of the page: (O/T: There is too much spam in this Wikipedia entry. This is a good example why Wikipedia is losing the war on spam. Just like what happen to email today.)

"SOA can be regarded as a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services. These service inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service."

To summarize, SOA is a style of building applications using loosely coupled and interoperable services defined by a formal contract (WSDL) that hides the underlying implementation of the service.

The service contract is the cornerstone of SOA. Most services use the Web Services Description Language (WSDL) to define service operations and associated input/output data. The service data are represented in XML messages and can be transported using HTTP or other protocols between the service provider and its consumers. The name "Web Service" is used because services are accessible from the web using the URI as service addresses.

SOA is not a new technology, but an important step in the evolution of the application composition technology. SOA has its roots in the Unix toolbox philosophy of composable programs, Remote Procedure Call (PRC), and Interface definition language (IDL). The use of XML (derived from SGML) as the data representation format is important. It allows implementation specific data binding to be decoupled from interface definition making the WSDL specification possible.

       60       70     79     80-90    96          98           01   
...coroutine...Pipe...SGML...RPC/IDL...XML...XML-RPC/SOAP...XSD/WSDL -> SOA

WSDL defines not only the operations of RPC interfaces but also message exchange patterns between the service provider and its consumers. However, WSDL cannot define a service protocol completely by itself. Other standards exist for specifying additional service aspects, e.g., the interaction sequence of a service exchange involving multiple partners.

Round 1: REST vs. SOA

In 2000, after studying the Web and other distributed system architectures, Roy Fielding defined Representational State Transfer (REST) as a set of desirable architectural constraints derived from the web. REST is an architectural style that can be applied to improve the web and build a better Internet-scale distributed software system.

The web is also not new, but a step in the evolution of the hypertext technology popularized by Douglas Engelbart and Ted Nelson in the 60s. Tim Berners-Lee implemented a networked hypertext system which he called the "World-Wide Web" in 1990. The web expanded very quickly after the introduction of popular browsers and the standardization of HTML and HTTP. Fielding participated in the web development around that time and defined REST.

        60      79        85      90        93/95           95/96   
...HyperText...SGML...HyperCard...WWW...Mosaic/Netscape...HTML/HTTP -> REST

While working on REST, Fielding examined RPC and quickly dismissed it as a different technology from the web. He stated that:

"What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics..."

Fielding's argument has been used repeatedly in the REST vs. SOA debate by proponents of REST. However, according to the HTTP spec, HTTP was designed to be an application-level, generic, stateless, extensible, object-oriented protocol for transferring request/response messages between a client (browser) and the web server with possible intermediaries in the middle. HTTP defines a set of standard (remote) methods: GET, POST, and HEAD. For anyone familiar with RPC, the HTTP design is very similar to an object-oriented RPC interface with remote operations: getResouce, setResource, and isResource. I think it is valid to argue that HTTP was designed as an RPC interface. Not sure why Fielding (BTW, he is an author of the HTTP spec) changed his mind between 1995 and 2000.

Same Web, Different Views

Fielding did not discuss "XML", a word never referenced in his thesis. Consequently, technology like XML-RPC and SOAP were not considered in REST. I think Fielding, like many others, has taken a view that assumes the web is a distributed hypermedia system --- the Resource view. As the result of such an assumption, REST becomes an architecture style applicable more to the design of such systems. REST may not be appropriate for other classes of distributed client-server systems.

SOA, on the other hand, has a different view of the web. It uses the web as a distributed application infrastructure between service providers and consumers --- the Service view. For example, the semantic of HTTP methods GET/POST/HEAD can be interpreted as getServiceDefinition, postServiceRequest, and isService. This view also works well and can coexist with REST's view of the web without problems.

SOA and REST are architecture styles applicable to different application domains. It is not useful to argue which one is better without knowing the target application. REST works well with distributed resources and SOA does better with distributed services. Resource interactions are different from, but in general simpler than, service interactions.

Posted at 08:34AM Sep 20, 2007 by tientienli in Personal  |  Comments[4]