October 18, 2003
@ 03:41 AM
Comments [3]
Service Oriented Architecture

Service Oriented Architectures is all the rage in popular distributed computing circles and is now eclipsing the XML Web Services hype. In trying to decipher what exactly this new buzzphrase means I've come across the following definitions

From Hao He's What is Service-Oriented Architecture?

SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners

While in Sayid Hashimi's Service-Oriented Architecture Explained we learn that

A service in SOA is an exposed piece of functionality with three properties:

  1. The interface contract to the service is platform-independent.
  2. The service can be dynamically located and invoked.
  3. The service is self-contained. That is, the service maintains its own state.

Then there's the quote from the Gartner Group's Service-Oriented Architecture: Mainstream Straight Ahead with the informative summary

Essentially, SOA is a software architecture that builds a topology of interfaces, interface implementations and interface calls. SOA is a relationship of services and service consumers, both software modules large enough to represent a complete business function." So, SOA is about reuse, encapsulation, interfaces and, ultimately, agility

So what exactly does this mean for those that have been have been flying the flag for XML Web Services or like me have been mildly curious about them at least. Well for one it is interesting to note that most discussions of SOA end up talking about XML Web Services technologies like XML, SOAP, HTTP and the like but also tend to them in the same breadth as they mention technologies like CORBA.

For one it seems many people have figured out what was interesting about XML Web Services wasn't the "XML" or the "Web" (more on this later) but the fact that instead of focusing on distributed objects it is more interesting to focus on sending data to end points for processing and retrieving the results. However you don't need XML or the Web to do this, although according to the theory of REpresentational State Transfer (REST) this is also how the Web works.

The way I see it the phrase "XML Web Services" already had the baggage of WSDL, SOAP, UDDI, et al so there a new buzzphrase was needed that highlighted the useful aspects of "XML Web Services" but didn't tie people to one implementation of these ideas but also adopted the stance that approaches such as CORBA or REST make sense as well.

Of the three words in the phrase "XML Web Services" the first two are implementation specific and not in a good way. XML is good thing primarily because it is supported by lots of platforms and lots of vendors not because of any inherrent suitability of the technology for a number of the tasks people utilize it for. However in situations where this interop is not really necessary then XML is not really a good idea. In the past, various distributed computing afficionados have tried to get around this by talking up the The InfoSet which was just a nice way of deprecating the notion of usage of the XML text format everywhere being a good thing. The second word in the phrase is similarly inapllicable in the general case. Most of the people interested in XML Web Services are interested in distributed computing which traditionally and currently is more about the intranet than it is about the internet. The need to justify the Web-like nature of XML Web Services when in truth these technologies probably aren't going to be embraced on the Web in a big way seems to have been a sore point of many discussions in distributed computing circles.

Personally I feel the same way about XML and the W3C, the W3C is about the Web and controls XML yet in truth XML usage is more widespread in local applications and intanets than it is on the World Wide Web, in fact its only major success on the Web has been RSS which isn't even a W3C technology. But I digress...

So where are we now? Well, it seems that XML Web Services are now passe and Service Oriented Architectures are in. To an XML guy like me, this is great because it means that I can now build RESTful XML Web Services and still be buzzword compliant. No more hiding XML behind objects that don't map properly to the data and clunky RPC-encoding schemes for me.

Anyway, I'm off to see Kill Bill:Vol. 1 with some friends. I'll probably write more on this if I get any interested comments and no angry email from fellow b0rg protecting their turf.

Disclaimer: The above comments do not represent the thoughts, intentions, plans or strategies of my employer. They are solely my opinion.


 

Categories: XML

« Pots, Kettles and Blackface | Home | Damned If You Do and Damned If You Don't... »
Saturday, 18 October 2003 03:58:39 (GMT Daylight Time, UTC+01:00)
I confess that this isn't an area I follow closely, but I've been under the impression that Service Oriented Architecture was a back-formation from SOAP, once REST became preferred over RPC in SOAP -- the new definition of SOA is a way to keep the SOAP acronym without having anything to do with accessing objects.

But I could be wrong, and that could just be a happy coincidence.
Mike Kozlowski
Saturday, 18 October 2003 22:57:14 (GMT Daylight Time, UTC+01:00)
Dare, what do you think about applying the REST addressing scheme to everything? It would have every resource addressable, all with the same operations. This looks great for simple "leaf resources" (for want of a better term) that can be mapped to a URI and can be manipulated directly. But what about resources that have more complex internal structures _wrt_the_other_resources_? I have in mind something like a database view: a query that selects some resources based on some criteria.

This query is not a resource like the other resources. For instance, the "one URI for one distinct entity" rule of REST is violated. Queries can be formulated in many ways yet yield the same result. Also, one query returns many entities.

I'm leaving this kinda open-ended to (hopefully) induce you to share your views on REST in a longer piece. :-)
VI
Monday, 20 October 2003 10:12:39 (GMT Daylight Time, UTC+01:00)
Here's my current definition, in short and long form:
SOA (short): A general purpose architecture, inspired by the Internet and the Web, for enabling extensible, federated interoperability based on network concepts such as protocols and intermediaries.

SOA (long):
A general purpose, extensible, federated interoperability architecture:
* It defines all processes as services delegated to service providers via generic envelope-based service interfaces.
* Such generic interfaces describe the interactions between providers and service consumers solely in terms of extensible identifiers, formats, and protocols (IFaPs).
* Such generic interfaces are intended to be dynamically bound to a diverse array of specific concrete network and endpoint service-provider technologies federated by envelope processing service intermediaries.

For more information, see my blog entry: http://radio.weblogs.com/0126951/2003/07/24.html#a19 .
Nick Gal
Comments are closed.