pushing soa up the slope (with a pointy stick)

There’s a pretty heated interesting active discussion going on at Steve Vinoski’s blog re RPC. You know a discussion is going downhill when people start quoting scripture at each other :-)  Here is my comment.

Just catching up on my reading for the last few weeks and I see that Google has open-sourced something called Protocol Buffers. A bit of a yawn really, but interesting from the perspective of adding a new animal into that endless zoo of rpc protocols. Actually, Protocol Buffers are not quite rpc, but actually very reminiscient of XDR which was invented about 12 years ago.

Mark Pilgrim gives a good overview and the comments are interesting to peruse.

Ted Neward writes a really nice discussion of Protocol Buffers (and binary representation in general) versus XML.

Meanwhile, Steve Vinoski begs Google to back off from the “gee we can do rpc with this…” perspective.

Ultimately I ask the question “why do you want yet another binary encoding format”? I think Ted Neward sums it up well:

In the end, if you want an endpoint that is loosely coupled and offers the maximum flexibility, stick with XML, either wrapped in a SOAP envelope or in a RESTful envelope as dictated by the underlying transport (which means HTTP, since REST over anything else has never really been defined clearly by the Restafarians). If you need a binary format, then Protocol Buffers are certainly one answer… but so is ICE, or even CORBA (though this is fast losing its appeal thanks to the slow decline of the players in this space). Don’t lose sight of the technical advantages or disadvantages of each of those solutions just because something has the Google name on it.

I had the pleasure of attending two conferences in recent weeks - the Australian Architecture Forum in Melbourne, and JAOO in Sydney. Both conferences held some surprises and in particular I was struck by the very different attitudes toward SOA.

The Architecture Forum was of course aimed at IT Architects and as a result it was about SOA, SOA and SOA…with a bit of SOA as well. Even when you tried to not talk about SOA (as one bold presenter attempted)…the conversation still swung around to SOA. By contrast, at JAOO, there was nary a mention of SOA. You don’t have to look far to understand why…JAOO’s by-line is “by Developers for Developers”…so the target audience and attendees were - Developers. Hence much of the content was around languages, platforms and agile methodologies.

What I enjoyed most about JAOO was the chance to meet and talk with the great lineup of speakers. Kudos to Dave Thomas for wrangling these people to this unfashionable side of the planet. Among the highlights were: Gregor Hohpe talking about the challenges of distributed systems, Martin Fowler expounding on the virtues of simplicity in design, Jim Webber trying to reconcile his two loves in life and Steve Vinoski on how a portfolio of languages helps us develop better solutions. All of this gave me the opportunity to consider the perspectives of architects versus developers. Gregor Hohpe captured the tone with his statement that an “architects dream is often a developers nightmare”.

An Enterprise Architect is generally focussed on the larger components in the IT infrastructure - how they are owned, sourced, maintained, combined and deprecated. And an architect considers not only machines and software but also data, processes and organizational structure. A key consideration for architects is how these things work together and therefore standards are important.

Developers care about delivering solutions for a particular business requirement. They care about the languages and platforms and methodologies that support their needs for correctioness, quality and maintainability. Developers have evolved techniques to deliver these qualities which are sometimes at odds with the needs of Architects and associated standards. From a developers perspective, many of the web-services standards conflict with their best practices. For example, XML is not really a language and cannot be completely treated like a language. Source-code management systems often have difficulty with XML. XML-based “languages” such as WSDL and BPEL are so complex that they require visual interfaces and complex IDEs that are at a higher abstraction than the XML “code”. The ability of these visual interfaces to “diff”, “merge” and debug are often pretty poor. Recently there has been a welcome move away from the masses of XML configuration files in J2EE in favour of java annotations. And perhaps there is further value in domain specific languages like Integration Flow Language in project Fuji.

Architects and Developers are in a symbiotic relationship which is definitely not frictionless. A good understanding on both sides of the needs and drivers of the other party will help to get everyone working in the same direction. Each should know the languages, techniques and platforms used by the other and a common understanding will lead to better ways of achieving what is ultimately a common goal.

So at lunch we were idly wondering whether the Hubble Telescope could resolve the Mars lander Phoenix.

The resolution of the HST is approximately 0.1 arcseconds.

The time delay to the Mars lander is 15 minutes.

So Google: “0.1 arcseconds * 15 light minutes” and the answer is 130.8 km…hence the lander is not resolvable at that distance (coulda guessed that).

Another one of my favourites is: “1 sidereal day in seconds”.

A little while ago I expressed my dislike for the term WOA on the grounds that it refers to a style of SOA and my feeling that new TLAs just lead to more confusion. Its good to see the ZapThink guys are in full agreement and state their case in their trademark inimitable style.

While the WOA concept does indeed provide deeper insights into how to best implement a Service and create an infrastructural approach for scaling Services, we simply don’t see a need to identify this as a truly separate architectural approach…

ZapThink believes that the term Web-Oriented SOA represents greater clarity than WOA, since it disambiguates the desire to position WOA as an alternative to SOA as well as more accurately positions the concept at a lower level of abstraction than the SOA concept. Going forward, hence, we will prefer the term Web-Oriented SOA over WOA, since it provides greater clarity. And clarity is exactly what companies today need to make SOA a reality.

My emphasis added - hear hear!

But I still have a problem with this terminology. It doesn’t exactly roll off the tongue and the use of “oriented” twice in the same term is really ugly. Moreover, we’re still mixing two levels of abstraction into the same term.

“Web Oriented” is a reference to the style of implementation of the Services which comprise the SOA. So wouldn’t it be better to use the terminology “Web Oriented Services”?

To take it a step further, I think we can do better than “Web Oriented” in categorizing the Service implementation. The two main Service implementation patterns that we have in the current debate are implementations based on Web Services standards (ws-*) and those based on REST. A key differentiator between these implementation styles is that Web Services are based on an “interface description” of the service, whereas REST is based on a “resource” as the key entity that we operate on.

Hence I propose the terminology “Interface-Based Services” to refer to the ws-* Service implementations and “Resource-Based Services” to refer to Services implemented in a RESTful manner.

So at the top of the ontology we have SOA - our architecture comprised of Services as first-order citizens. Those Services may in turn be Interface-Based or Resource-Based in their implementation. Note that an SOA could quite easily comprise a combination of Resource-Based and Interface-Based Services.

I think this nomenclature is clearer…but it won’t catch on because these are not TLAs!