Jonathan's Pancheria: Tag SOA

The Mainstream realizes SOA is going the way of WS-*

Jonathan Altman — Mon, 11 Aug 2008 19:21:00 +0000

So I disagree with the way the argument in this post is framed, but I am glad to see the “mainstream” tech press realizing there’s a better way to get to SOA:

A growing number of companies are finding that lower-visibility Web-oriented architecture (WOA) developments, spawned through grassroots movements, are a better route to the service-oriented architecture. WOA, like SOA, is an architectural approach to system design, though WOA is resource-oriented rather than service-oriented. What’s the difference? While the core SOA design unit is a reusable service that fulfills a distinct business function, resource-oriented services are more limited and data-focused.

SOA and WOA work at different layers of abstraction. SOA is a system-level architectural style that tries to implement new business capabilities so that they can be consumed by many applications. WOA is an interface-level architectural style that focuses on the means by which these service capabilities are exposed to consumers. Governance, quality of service, security, and management are of equal importance, whether the functionality is being delivered via SOA or WOA.

I think the delineation between SOA design units as a service fulfilling a distinct business function and WOA as a resource-oriented service being more limited and data-focused is so much dissembling for SOA being an attempt to force a top-down, waterfall-based model on what services you offer in your architecture versus an iterative or even agile strategy of building the individual services and then gluing them together.

I think SOA was also overblown in the framework for tying them together, which is the root of this problem, and leads to the conclusion I made up above. Put a bunch of webservices out there that handle orthogonal responsibilities, make it easy to access them (personally, preferably with easy HTTP/POX or a light SOAP layer), rather than a huge management stack that services have to a priori fit into, with the up-front design and overhead that comes with it.

SOA for managers

Jonathan Altman — Mon, 06 Feb 2006 17:21:00 +0000

Finally, a description of good web service/SOA design that even pointy haired bosses can understand :-)

The graphics are designed to make it clear to non-technical users how to go about designing the boundaries of your web services/SOA!

More on toolkits reducing impedance mismatch by working with raw XML

Jonathan Altman — Fri, 09 Dec 2005 19:47:00 +0000

Earlier, I posted about how not forcing all access to web services to go through objects that were serialized into and back out of XML but instead were XML documents that were designed to stand on their own made it easier to implement both web services and web services clients.

Elliotte Rusty Harold sets out a nice short example of the nature of the problem. He summarizes the problem nicely in this quote

“don’t “help” users out by changing XML into something else, especially not objects. Don’t assume you know what they’re going to want to do with the data. Give them the XML and let them use the classes and objects that fit their needs, not the ones that fit your needs. XML is exchangeable. Objects are not.”

Again, for the record: if I work with your web service, you do not know what data, data structures, or code artifacts I will have in place to access your web service. Please don’t try to guess by forcing me through your view of how the software artifacts should look. Let me figure out how to make the raw message, and how to interpret what you send back. SOAP toolkits that closely map XML to particular language-specific data structure constructs and back make this hard.

Succinct description of what is wrong with web services that do hard-RPC

Jonathan Altman — Thu, 03 Nov 2005 19:08:00 +0000

Found this quote today from Eve Maler

The trend in distributed computing is towards service-oriented architectures (SOAs). Early in the life of this buzzword, some people said it should really be called a document-oriented architecture (except for the unpleasant acronym :-) because it’s really all about document-passing rather than a tightly coupled RPC paradigm, that is, if you want to be successful at reusing the components

The quote is part of a longer discussion that is partly tangential, but I have spent the last 4 years dealing with integration of services that are or could be called “web services” and they have taken various approaches to how the XML data is moved. Some have expected that we will use a SOAP toolkit that hides the XML behind objects that get serialized and de-serialized. Others came out of a more EDI-like world and are more message or data structure passing oriented.

The ones that are easier to deal with are the ones that move messages or data structures, not insist that I hide behind the de-serialized objects. In general the objects end up not serving my purposes well, and require large recompiles and test cycles to deal with. We end up having impedance mismatch between the software artifacts in the web services we consume, expressed in objects that I must use but which I did not define, and my own software artifacts. To fix this, I need to either write wedges that sit between the web service I consume and my software artifacts and do the mapping, or I need to build my software artifacts so that they have a “has-a” relationship with the web service’s artifacts. That just splits the wedge into per-object pieces where each of my objects that “has-a” needs to manage its map. The really intractable problem is when the object mapping that one toolkit makes is incompatible with another’s.

On the other hand, when someone changes an XML document that I can treat as an XML document, I can work in a script-based (not compiled) environment and update the mapping between the document and my software artifact the way I need to, and ship faster. I have variance between what you are sending me and what I expect, but since my entire system is built solely as a mapper between my artifacts and the web service’s documents, there is no impedance mismatch, just a version change to my mapper.

It’s faster to update, easier to maintain, and I don’t have to care about whether your web service’s underlying object model is any good or not. I have one system, the mapper between documents and my software artifacts, not 2 systems: your objects and my wrapping layer to handle the impedance mismatch. And I cannot end up in situations where my toolkit and yours cannot generate compatible object<->message bindings.

At the end of the day, I think you have to care about what’s in the angle brackets. Developers who just want to deal with objects see a false economy: you feel like you are working higher up the protocol stack because you do not observe the wire format—just your objects. Eventually, however, you end up working below the wire format because the underlying plumbing of the service you are talking to is exposed in the software artifacts (objects) you end up having to manipulate on your side. You either have to know details about how the objects on the other side were built, or you have to muck with the document format anyway to map away details from the other side you don’t care about or cannot handle, but usually both.