Pete Lacey’s Weblog

Leonard is looking for a formal definition of SOA. My colleague, Anne Thomas Manes, is a thought leader on this subject, and Burton Group clients and the industry as a whole tend to line up behind her definitions. I’ll share them here:

Service oriented architecture (SOA) is a software design discipline in which application and infrastructure functionality are implemented as shared, reusable services.

SOA is more about design and behavior than technology.

SOA is something an organization does—not something it buys or something it builds.

Admittedly, this is all kinda loosey-goosey and can describe most anything. In fact, a core tenet of Burton Group’s stance is that SOA is technology agnostic: you can create a SOA with CORBA or RMI or DCOM or SOAP or, some say, REST. However, the first definition of SOA given above and the first word in “service-oriented architecture” demand a definition of what a service actually is. People might argue this, but the only reasonable definition of a service is a network available collection of related operations. And an “operation” is an action (function/method) offered by the service that takes in a message or parameter list and generally returns some response. To be clear, however, while you can conceivably create a SOA using, say, RMI, in reality SOAP web services is both the recommended and assumed underlying technology.

Plugging this definition of a service into the SOA definition gives us:

Service oriented architecture (SOA) is a software design discipline in which application and infrastructure functionality are implemented as shared, reusable network available, collections of operations.

And this is where I part company with those that think that REST can be used as the underlying technology of a SOA. Sure, in the sense that SOA implies changes to how you think about designing applications or modifications to your SDLC, then fine. But a resource is not a service. A resource does not have arbitrary operations (that, by the way, have to be specified somewhere in the incoming message—and not in the HTTP headers, because SOAP is supposed to be transport agnostic). Stefan Tilkov put this into brilliant perspective when he demonstrated the differences between how people think about resources and how they think about services.

From this, we can also put to rest the notion that the choice between SOAP and REST is an implementation detail. How REST systems are architected at the resource level is fundamentally different from SOAP. And how REST leverages HTTP (URIs, response codes, caching) is fundamentally different from how SOAP leverages HTTP (as a tunnel).

Back to Leonard then. You can drop the name “Message-Oriented Architecture.” It is, as you noted, too similar to message-oriented middleware and it doesn’t properly reflect that other architecture. The name “SOA” works fine, so long as the “S” is defined. Further, I was being generous when I said that a service accepts either a message or a parameter list. While sending messages is considered best practice, today’s tools and today’s programmers still lean towards sending serialized objects (though serialized as document/literal messages).

ROA, while it doesn’t quite roll off the tongue, is also fine.

Leonard asks “Is it useful to distinguish between the typical robotic SOAP/WSDL interfaces autogenerated from Java or .NET code at the touch of a button, and the in potentia SOAP architecture that can be anything, even RESTful?”

Yes. Yes. Yes.

Stefan and Sam have both noted that you can craft a SOAP message with vi, and that SOAP can be considered orthogonal to WSDL, and that one can leverage the SOAP envelope while ignoring all the other baggage. This is technically all true. But you cannot ignore how SOAP and SOA are being sold and practiced. I’ve been briefed by SOA vendors of all stripes. I’ve sat in vendor sales calls with my customers. Heck, I have myself advocated a web services-based SOA. And this version of SOA assumes SOAP and WSDL and UDDI, and XML Schema, and WS-Whatever, and web service management tools, and enterprise service busses, and web service platforms, and so on ad nauseum. I don’t want to harp on this, but it’s wishful thinking at best and disingenuous at worse to assume that SOAP and SOA can be divorced from this reality.

And to answer the final question about how to categorize those not quite RESTful, HTTP+POX services so commonly found out there. They should be classified as aberrations, as devoid of architecture, and as an example of how not to do things (while acknowledging they work). I direct you once again to Duncan Cragg’s coinage of the term STREST.