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?

There’s a lot of interesting bloodletting debate going on about the different technical approaches to services development - RESTful versus ws-* (ws-splat). The great thing about this debate is that it helps expose fundamental requirements, preconceptions and trade-offs.

I’m currently on the sidelines…my own position is that while acknowledging that ws-* is overly complex and has led us down a lot of blind alleys in the standardization wars process, the fundamental aspects are useful and productive if used properly. REST approaches are conceptually elegant and simple in their use of and adherence to the “resource oriented” view of the world-wide-web, but I haven’t used them “in anger” yet and need to reserve judgement.

There is currently a very interesting discussion on the value of WSDL happening at TSS. One of the best contributions to the discussion from William Childers says:

WSDL is supposed to give us away of tying together the service, its address, its operations, the required message formats and the supported delivery channels. That’s very useful and is something that can be processed and used at either design time or run-time (e.g. WSIF).

If WSDL (and Schema) did not exist we’d have to invent them. You can argue about how good they are as solutions (not so great) but I don’t see how you can argue that solutions aren’t needed which I believe is one of Joseph O’s points.

On the other side…Stefan Tilkov at InfoQ gives a good defence of REST against the doubters.

Well reasoned discussion about these approaches will help to clarify each and also help to educate the wider user community. Currently the REST approach certainly dominates public web services (such as Google, Amazon, Facebook etc) and that ws-* dominates enterprise web services. I feel there is significant common ground between the two and we will see a middle way that bridges some of the differences and leads to both better ws-* implementations and better REST implementations.

An important force helping to push SOA up the slope of enlightenment is the sharing of knowledge, experience and validation from SOA “doers” rather than marketers. The SOA Consortium is one body set up by the OMG to try to help this along (although caveat emptor the consortium is sponsored by a bunch of vendors).

I read through the SOA Executive Insight Report which reports on the discussion between a number of CIOs who all apparently have extensive SOA experience. There are a couple of interesting comments of note.

The CIOs…

“expressed concern regarding the current industry focus on wire protocols and products, rather than business value generation and the necessary business and IT changes for sustainable SOA success. The industry – vendors, press and practitioners – must “elevate out of the technical weeds” in order to engage the business on SOA.”

This was written in April 2007, but is still so true today. In particular the arguments of ws-* versus REST are not about SOA and should not be confused with the viability or otherwise of service oriented approaches to providing functionality and value to IT users.

The second interesting comment is:

“CIOs noted the lack of common practices for

• service versioning,
• the complexity of testing shared services with multiple consumers,
• the challenge of identifying mission critical services,
• the reinvention of chargeback procedures,
• blind spots in capacity planning, and
• the need for ‘real-time releases’.

The CIOs want best practices for these issues. Specifically, they mentioned an ‘ITIL for SOA’.”

These are issues that I see creating many challenges for SOA adopters and there are no simple solutions. These are also issues I have run into in my own SOA work and I hope to write about them in the future.

One other comment on the SOA Consortium web site. There are a number of SOA “case studies” which is great to see, but very disappointing once you drill into them. They lack any real “meat.” We need more than just a few bullet points…details are needed on what challenges they faced and how they overcame them. As they stand the case studies look like a selection of vendor power-points.

Following from my last entry on metrics I do think it is important for metrics to be used to monitor and demonstrate continuous improvement as part of an SOA initiative (or any IT initiative, for that matter).

Key metrics should be built into your SOA organizational infrastructure so that they are maintained and reported as a by-product of your day-to-day SOA activities. So even though I don’t believe there is (currently) any absolute measure of SOA success, what is important is the relative measure and how that changes over time - “am I getting better at this?”

So what are some good metrics? ROI is the most fundamental metric. The reason we embark on an SOA and the reason that the business pays for it is to improve the bottom line - make IT more cost effective and more responsive to business needs. ROI is important to your CEO, your CFO, your CIO and your shareholders. The problem with ROI is that it can be difficult to measure…especially when dealing with less tangible measures such as opportunity cost around time-to-market (agility). What we need are some good proxies for ROI which can be easily measured on a day-to-day basis.

Cost to build a new service is a good metric. If services are provisioned as a project, then it should be relatively easy to measure the total cost of delivering a new service to the business. You should normalise this metric against the complexity of a service. Split services into simple, intermediate and complex if that makes sense. The total cost per new service should decrease over time.

Elapsed time to build a new service is also a good metric to monitor agility. This is a simple form of Nick Malik’s agility metric. Basically we want to ensure that we are delivering new services faster by leveraging off our SOA infrastructure. One of the commonest complaints I hear from businesses everywhere is that IT takes too long to deliver. As with the cost metric, you probably want to normalise against the complexity of a service in some way.

Service utilization is another good measure. Once a service is provisioned, how many business processes make use of that service? What is the daily throughput for the service? These can be objectively measured by service monitoring tools. But note that counting business processes requires some thought to meta-data in your service infrastructure.

Services with a high utilization will indicate what is of most value to your organization. Conversely, services with a low utilization may indicate a low value service or a function which shouldn’t have been made into a service in the first place. Perhaps your governance processes around service identification and prioritization could be improved here. Alternatively, services that used to have high utilization and now have low utilization may indicate obsolescence where it makes sense to retire that service.

Average cost per service, Delivery time for a Service and Service Utilization are easily measured, fundamental metrics for your SOA. There are other SOA costs that should also be accounted for.

Average cost to run a service is important. Add up the BAU costs (hardware, software, maintenance, monitoring, administration, power consumption etc) of your services infrastructure and divide by the number of services you are running. This measure will often be high when you start out and have few services, but should reduce over time.

Governance cost should also be tracked. What is the cost of the governance processes that you put in place to evaluate service candidates, prioritize and plan your services road-map. Usually this cost is made up of time and effort for the people involved in SOA governance. The governance cost per service will initially be high, but should hopefully reduce over time. [This raises an interesting question…how do you measure the effectiveness of governance in order to justify the additional cost? It is difficult to separate out the contribution of governance to the overall SOA benefits.]

These measures can be combined to give an overall ROI index for your SOA. If you can estimate the total business value of your processes and divide by the total cost of the services that support those processes, then you get an aggregate ROI measure

Finally a warning to be careful about how you define a service for inclusion into these metrics. True re-usable services come with a higher price-tag in terms of planning, governance and infrastructure, but the idea is that re-use amortizes the cost over multiple business processes ending up with a positive ROI for the service. There are probably many integration points/projects which do not justify treatment as a re-usable service. These “point integrations” should not be included in the SOA metrics because you are not comparing like for like.