Entries from May 2008 ↓

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!

One of the original and fundamental tenets of the SOAP standard was that the SOAP message is independent of the underlying transport. Ostensibly you could use SOAP over HTTP, JMS, email, FTP etc. but the reality is that a standard binding has only ever existed for SOAP over HTTP. To paraphrase Henry Ford – “you can have any SOAP transport you like, as long as its HTTP”.

While HTTP is undoubtedly a good choice for SOAP – given its ubiquity – there is at least one other transport which demands attention. This is the JMS transport which is widely used inside the firewall of many organizations. Of all the companies that I work with, their SOA infrastructure heavily relies on JMS transports inside the firewall, with HTTP transports outside the firewall or to selected service end-points such as web pages. Of course my experience has significant selection effects, but nevertheless JMS is an important transport in many SOAs. Testament to this is that every major web-services product vendor (save Microsoft) supports SOAP over JMS (and even Microsoft now has SOAP over MSMQ as an important part of WCF).

The fly in the ointment is that there has never been a standardized binding for SOAP over JMS and as a result there is little interoperability between SOAP/JMS solutions provided by different platform vendors. If you happen to have any combination of different web-service platforms in your organization, then they cannot easily communicate with each other using SOAP over JMS without performing some unnatural acts.

Some of issues that need to be considered with a SOAP binding to JMS are:

• How do you represent the message content – text or binary? Most vendors have chosen a text message representation, but that has problems with multi-byte encodings, so other vendors have gone with a byte message representation.
• What headers do you define and what should their names be? How do you use the standard JMS headers? different vendors have different naming conventions and semantics.
• In the WSDL description, how do you represent the connection details to the JMS provider?
• How do your service endpoints manage the different message exchange patterns that are available with message-oriented transports?

Each of the vendors went their own way on many of these issues and as far as interoperability was concerned they basically ceded the field to HTTP. They made life difficult for large organizations with heterogeneous platforms and in my opinion didn’t do themselves any favours on the way. (Actually SOAP-encoding interoperability was so broken for a while that noone noticed the JMS issues…so maybe it wasn’t so bad).

Subsequently it was great to see some of the vendors get together a couple of years ago to agree on a standard SOAP binding for JMS that addresses most of the important considerations. The result was a Member Submission to W3C in September last year. My understanding is that this submission was previously circulated through most of the vendor community so hopefully it has general agreement on the technical details.

This has now taken its first steps to standardization with the initiation of a SOAP-JMS Binding Working Group who aim to publish a recommendation by April next year. Hopefully vendor support of the binding will be hot on its trail.

Note that the standard binding won’t address the fact that different JMS implementations do not interoperate. For example, a TIBCO JMS client will not be able to talk to a Websphere JMS provider because JMS is an API standard, not a wire-protocol standard. What the SOAP/JMS binding standard does mean is that once you have settled on a standard JMS provider for your services, you could define your service description in standard WSDL and your service provider (say Websphere or TIBCO or WSO2) and your service consumer (say TIBCO or WebLogic or Axis) would be able to communicate directly using SOAP over JMS “out of the box”.

Its been eight years (almost to the day) since SOAP 1.1 came out with the HTTP binding. Wouldn’t it be great if a standard JMS binding could be achieved within the decade! It’s been a very long wait. The JMS binding should have happened a lot sooner and I can’t say the “wait has been worth it” but it does fill an important hole in the Web-Services standards.

So what do we do in the meantime? You can eschew JMS altogether and stick with HTTP, but that requires another lot of hard work. You can stick with one and only one service platform, but that is difficult in large heterogeneous organizations – which is where SOA is supposed to provide maximum benefit. Or you can continue to do what many SOA implementers have done and deal with SOAP directly at the JMS layer – effectively using SOAP as plain-old-XML over JMS. I wrote more about this approach recently.

Another thing you can do in the meantime is ask your vendor when will they support the new SOAP/JMS binding?

From Bob Cringely, the 10 most frequent lies told by IT consultants:

1) “This can only be accomplished through a large custom development project.”

2) “Of course your data is safe.”

3) “We’ll need a day or two for optimization and debugging.”

4) “Yes, we’ve done this before. There are several companies using this product (or technology). They really like it.”

5) “Server consolidation and virtualization will save you money.”

6) “Storage consolidation and virtualization will save you money.”

7) “The upgrade (or change) will be seamless and will not affect production.”

8) “The upgrade (or change) will be transparent to users.”

9) “Yes, we tested this thoroughly before installing it.”

10) “If you install Tivoli it will solve all your support problems.”

In “Web 2.0 success stories driving WOA and informing SOA”, Dion Hinchcliffe writes about how enterprise SOA can learn from the successes of Web2.0 and WOA^*.

“…since there’s little question that the core ideas behind SOA seem to be the right ones. Rather, it’s been how we’ve gone about designing and implementing SOAs that appears to be at the crux of the issue. As we look at the most successful examples of SOA actually working, we keep being drawn back to the Web itself.”

Along the way Dion points out a couple of differences between the Web and the enterprise which I think are pretty salient and underscore the issue that its not the technology that divides the two hemispheres of the service-oriented world.

“One big issue…is that enterprises are often very much unlike the Web. Many of the aspects that make the Web successful…just don’t exist in the enterprise with it’s wilderness of relational databases, proprietary applications, and silos of every description, despite some success in adding a traditional SOA layer on them.

The article Dion references in the last quote has this great summary graphic:

But in addition to the technical differences between the Web and the Enterprise, I think it is worth mentioning some fundamental cultural differences:

• The participants: When it comes to Web APIs that have been so successful, the conversation is basically between technologists. By-and-large it is technologists that are writing the mashups that demonstrate the success of Web2.0. Conversely with SOA in the enterprise, the conversation is (supposed to be) between technologists and business – and plenty has been written about the lack of success there.
• The success criteria: There are different success criteria for Web2.0 versus enterprise SOA. Very few Web2.0 companies currently make money out of their APIs. Success for Web2.0 is “eyeballs” and VC funding. In the enterprise, SOA success is all about hard ROI.
• The legacy: Most enterprise services must build on legacy applications, whereas Web2.0 applications are mostly greenfields and purpose built for the Web. Legacy applications rarely expose “resources” directly. If you’re lucky, the application exposes API methods which encapsulate an awful lot of business logic around a resource.
• The standards: Also part of the legacy is that WOA is “an emergent set of best practices…not a formal set of standards.” Let’s face it, WS-* are a formal set of standards designed by disparate committees often with competing agendas and ulterior motives. The structure and evolution of these standards has not been optimal for the users.

Fundamentally, I agree that Web2.0 in the enterprise and REST approaches to SOA have a lot of value and can teach us how to do SOA properly. Conversely REST needs to address enterprise concerns more fully. The key is recognizing the commonalities and the differences so that we can hit the sweet spot in between.

* BTW I’m not a big fan of the term WOA to denote “Web Oriented Architecture” or REST-ful approaches to Services. While I understand that distancing REST from WS-* makes good marketing sense, ultimately I think we are all talking about Services – so WOA is really a style of SOA. Jockeying for market position/dominance/discrimination has already got us into such a mess.