WS-RM Goes to OASIS

Great news for anyone interested in the WS-ReliableMessaging specification — as we are — the spec has been submitted to OASIS and a new technical committee is being proposed to progress it.
Anytime a Web services specification as significant as WS-RM is submitted to OASIS or W3C is cause for celebration – or at least some applause. Especially when submitted (as this specification was) under royalty-free terms and conditions.
InformationWeek and News.com articles highlight the competition between WS-ReliableMessaging and WS-Reliability, which is now an OASIS standard. Yet many vendors, including Sun, Sonic, and IONA support both.
So what is going on?
We (IONA) co-sponsored the creation of the original WS-RM TC at OASIS about two years ago because reliability is a key enabling quality for Web services. Customers consistently have been telling us that certain applications, such as EDI replacement or electronic funds transfer, for example, just could not be considered without it. If WS-ReliableMessaging had been around at the time, and submitted to OASIS, we would have supported that instead.
Two years later, we are supporting the current submission (for more details see Robin Cover’s write up.) We think that WS-ReliableMessaging is a better specification, and because it’s supported by Microsoft and IBM it has better market traction than WS-Reliability. This is also the specification customers are asking us to support. We’ve implemented a subset version in our mobile device platform and plan to offer a complete implementation in an upcoming release of our core ESB product, Artix.
One good question is how one specification is different from the other. This is reflected in some of the discussion around this announcement, for example the statement about how WS-ReliableMessaging fits better into the WS-* stack (which actually brings up another whole discussion around which stack you mean, since there are multiple versions of the stack, and the WS-Reliability specification also composes well with other specifications such as WS-Security and ebXML Messaging).
Another key difference is that WS-Reliability defines reliable semantics including the application level, while WS-ReliableMessaging defines reliability only for the transport level. WS-Reliability defines semantics fo submitting and receiving the message, not simply for transporting the message reliably from point A to point B.
The inclusion of operations, albeit abstract operations (i.e. Submit, Deliver, Respond, and Notify) distinguishes WS-Reliability from WS-ReliableMessaging since these operations define the handshake between the sending application and the receiving application. WS-ReliableMessaging explicitly omits any specification of this handshake.
Otherwise the specifications are remarkably similar, except for terminology, in the way in which they accomplish reliability using a series of acknowledgements for a group of messages. The acknowledgements indicate whether a message was in fact received, or if not, whether one or more messages in a sequence need to be resent.
One other difference in the most recent version of WS-ReliableMessaging is that the RM policies are defined using a separate specification. This is consistent with one of the recommendations we made in our position paper at last October’s W3C Workshop on Constraints and Capabilities for Web Services (aka the Policy Workshop).
Returning to the topic of reliable messaging, however, a couple of final points.
First, it’s strange to have a reliable messaging specification defined at the same level as the other WS-* specifications, which are all designed to be transport independent. For example, one of the major justifications for WS-Addressing is that the addressing information needs to be included in the SOAP envelope so that routing and dispatching the SOAP message is not dependent upon the features of any underlying transport, as was the case with the SOAP 1.1 SOAP Action HTTP header (which has since been deprecated.)
But many popular transports natively include reliability features, including JMS, WebSphere MQ, CORBA Notification, IIOP, RMI-IIOP, DCOM, and .NET Remoting to name a few. Adding any kind of WS-ReliabilityMessaging on top of an already reliable transport doesn’t make much sense. WS-ReliabilityMessaging (if you’ll pardon the shorthand) is really only necessary for unreliable transports, such as HTTP. And of course reliability is one of those extended transport features intentionally left out of HTTP so it would scale.
The primary purpose is to create a reliablity layer for HTTP, which doesn’t have one. However for consistency with other WS-* specs it is still designed to be transport independent. This just seems a little strange overall – but I suppose another good application is to reliably bridge between HTTP and JMS (or any other) transports.
Overall the technical differences between WS-Reliability and WS-ReliableMessaging seem less significant than the marketplace dynamics surrounding them (and thus the news angle of conflict), at the high level they represent the inevitable result of two very different overall approaches. WS-Reliability evolved from ebXML messaging, while WS-ReliableMessaging was developed from the basic SOAP starting point.
Those of us who have been involved in this debate long enough remember that the ebXML and SOAP stacks originally had very different starting points and assumptions. During the past five years the two camps have drifted closer together, but the original ebXML architecture started with the business process and decomposed to the messaging layer, while SOAP started with a simple messaging layer and proposed a composition model that would extend upwards to the business process.
The current differences between these two very similar specifications remains rooted in that past time during which ebXML and SOAP were strongly competing.
Update May 10 With the original supporters of WS-Reliability joining the new WS-Reliable Exchange (WS-RX) TC, it looks as if the confict is finally over.

InfoWorld SOA Forum

Jon Udell posted some potential interesting discussion topics for the SOA Platform panel discussion at the InfoWorld SOA Executive Forum.
I am really looking forward to participating in this panel, not only because of the distinguished company I’ll be in, but also because for many businesses, investments in an SOA Platform based on Web services will solve significant IT problems and create strategic advantage. This is a great topic.
With respect to the question in Jon’s blog about standards and specifications, I am really not sure about the implication that the current Web services “stack” is designed for use in an SOA. (I put “stack” in quotes because the industry still does not have a single, consistent architecture for Web services. Microsoft and IBM are still promoting different versions, for example.)
Many of the specifications were developed before their application in an SOA was identified, and others were proposed more as features and functions needed for certain applications, whether part of an SOA or not. Many Web services applications need security, or reliabilty, even when they are solving a simple point to point interoperability problem.
I’d argue that most Web services technologies are generic, in other words, and not specific to their application in SOA infrastructure. It’s better to first define what’s needed for an SOA Platform based on the requirements of the SOA rather than working from what exists in current Web services specifications and assuming they provide what you need. This approach would also show us where the standards are insufficient for the purpose of an SOA platform, where features/functions are missing, etc.
Despite the fact that WSDL provides many of the things you need, it is not correct to assume that it is therefore equivalent to an SOA contract, for example.

The End of Rip ‘n’ Replace

When I talk about services and SOA in visits to customers and at conferences, I often hear about the need to achieve a better return on existing IT investments. In order for SOA to be successfully deployed, existing applications and systems need to be able to participate as equal citizens. They cannot consist only of just new code. In fact this looks to be a major consideration with respect to adoption.
Years ago we all expected the programs we were writing to be replaced. I know I wrote my share of non-Y2K compliant code. We never thought the applications we were writing back in the 70s and 80s would last for more than five years, never mind ten, twenty, or thirty. Things were changing so rapidly then – database management systems, transaction processing monitors, word processing systems were all coming out and it seemed like the code we were writing one day would be in a product the next.
As we know things didn’t turn out that way. Sure, some systems were replaced but the successful ones never were. Once a given area of business was successfully automated, whatever the solution, it was on to the next. More functions might be needed, or improvements made to performance, scalability, security, or GUIs or Web browsers added. The back end core functions, however, once well deployed, tended to stay in place.
With the advent of Web services, it seems that the software industry has finally reached a level of maturity at which existing investments are no longer questioned but rather accepted and embraced. You don’t hear things anymore like “Well, eventually you know you will have to recode everything in Java.” We don’t expect our IT environments to be replaced, we expect them to work better together.
This is in fact the essential role of the Enterprise Service Bus (ESB), to help preserve value in existing IT assets by service enabling them and allowing those services to easily communicate and share data. The ESB meets infrastructure requirements for business and government seeking to assemble meaningful architectures out of existing (and new) components.
In this context it is really strange to see the recent “markugment” (i.e. marketing agument – we’ve got marketecture, why not markument) between Sonic and Tibco, with Sonic offering to replace Tibco. And Tibco’s response seemed to have more or less taken the bait, claiming that they already have an “ESB plus plus” by another name.
But in either case I can’t really see the value to IT of proposing to take out an existing infrastructure and replace it with someting like Sonic’s JMS or Tibco’s Rendezvous, no matter what they add to it so they can call it an ESB. People have enough IT infrastructure – what they need is a good way to assemble what they already have into new applications. The industry needs a co-existence solution, not another rip ‘n’ replace approach.
Rip ‘n’ replace solutions are just too expensive, both in software and (especially) labor costs, and also implicitly assign less value to existing investments than they really have. The last thing IT departments need is another big investment in a bloated software system from the last century that doesn’t work well with existing infrastructure, networking, and language deployments.
ESBs are really all about adding just the right amount of incremental value (and therefore incremental code) to existing systems so that they work well together. ESBs are not about ripping out existing middleware, networking, messaging, languages, or applications in order to install new products. To be effective, ESBs must play well with the software that you already have, be as nonintrusive as possible, and expose as much value (i.e. existing data and functionality) as possible. As a former IONA colleague was fond of saying, “there are no ugly babies” when it comes to the IT environment.
ESBs help you create new applications out of existing applications. They are not systems in and of themselves. The IT environment has passed the stage at which a large investment makes sense. Now we need a sensible, realistic product that you can adopt in incremental stages, pay for as you go, and enable these core functioning IT assets to be appropriately and profitably reused.

Back to the Basics

The good thing about getting lost is that I found a good little Indian restaurant. I was wondering how something like that would be possible in the land of the chains – Orlando must have at least one of every restaurant chain in the world.
After me an Indian guy came in with two women, then a British couple, and then an Irish man and his son. So that would explain it…
I was there to teach the Introduction to Web Services and SOA at the OMG’s MDA, SOA, and Web Services conference.
This was a 3/4 day tutorial covering the basics of Web services technologies and SOA concepts. It is derived substantially from material from my first book, Understanding Web Services, and includes some material from my new book, Understanding SOA with Web Services.
The IONA Web services and SOA courses are technology independent, just as the books are. One advantage of working for IONA is that you don’t have to take side in things like the Java vs .NET competition.
It’s coming up on three years since the first book came out, and about five years since SOAP was submitted to W3C, which pretty much started the whole Web services thing (although it wasn’t called Web services then – all we really had was the SOAP proposal).
It’s important to stop and remember the basics from time to time. And even though I’ve been working recently more at the so called higher levels of the Web services stack in the WS-CAF technical committee at OASIS, it was good to have the chance to go over the foundational material once again.
For example, all Web services specifications are applications of XML. That means, at least in priniciple, that one should be able to work with Web services artifacts using off the shelf XML tools. It means Web services should inherit the properties and practices of the XML community. How much this really is or is not the case is worth keeping in mind as Web services progress.
Everything in Web services is an XML document. The original motivation for SOAP was as a way to use the Internet for business to business communication. Some of the original specifications, UDDI in particular, were oriented almost completely to the public Internet. Today’s UDDI suppliers are struggling to re-orient the standard toward the current application of Web services inside the firewall, and a very good question is whether or not the original specs were written too far in the other direction to be reasonably brought back.
A SOAP message is an XML document. An XML document by definition has one and only one root element. The fact that a SOAP message is an XML document presents an interesting problem when trying to use SOAP to send an existing XML document. Either you have to transform the document to add the SOAP envelope and body tags, or use SOAP with Attachments, which despite its early broad endorsement as a bridge across the political divide between Web services community and the ebXML community (each of which had different views of the starting point for the commercial use of XML over the Internet), remains controversial today – meaning not adopted by the entire Web services vendor list.
A WSDL file is an XML document. And XML documents have associated schemas. If you look inside a SOAP message or WSDL file you will see the XML namespaces that identify the version. Here for example is the SOAP 1.1 namespace URL: http://schemas.xmlsoap.org/soap/envelope/. It is a “dereferenceable” namespace, meaning if you click on it or type it into your browser address bar and do an HTTP GET on it, you will receive the SOAP schema, which is also (of course) an XML document.
An interesting relationship exists between XML document instances and types (i.e. DTDs or Schemas – DTDs of course not being valid for use in Web services specifications). A given document instance can have multiple types associated with it. This characteristic of XML derives from SGML (on which XML and its sibling HTML are based), which was purely a document processing language. The idea was that a given text might have multiple output formats — letter and A4 say, or letter and online help — and it’s easier if you can just change the “content model” (aka Schema) instead of having to edit the document every time you want to change the output format.
Does this mean for SOAP that a given message could have multiple associated schema formats? Yes, it does, since everything is XML. Does this happen much in practice? Not that I know of — but it somehow seems like it should. Then you could, for example, create all your messages in the document oriented style, using doc literal (i.e. Schema) encoding, and define one Schema for mapping the instance data into an RPC oriented object system and another for mapping the instance data into a message queue system.
SOAP and WSDL were originally designed to encompass both RPC oriented and message queuing style software systems, which today is becoming one of the benefits of ESBs. Web services are also designed to be transport independent. That’s why everything (the address, security headers, etc.) has to be put within the envelope – so the message can be delivered using whatever communication transport you want to use.
Some of these original characteristics of Web services still seem as if they are not entirely fulfilled within most current vendor implementations. It seems as if most software vendors have simply adapted Web services to their existing software environments, rather than developed new software environments capable of exploiting the full capability of XML.
As my friend Oisin Hurley likes to say, in theory, theory and practice are the same thing. In practice, however, they are not. As an industry we still have a ways to go to realize the original Web services vision.