mult.ifario.us

As I'm getting caught up on some blogs and industry news, I see that the new version of SOA is out, courtesy of Gartner analyst Yefim Natis:

[...] With SOA 2.0, an event-driven architecture is deployed in which software modules are related to business components, and alerts and event notifications are featured. The initial SOA concept has not been event-driven but instead has featured direct calls from one piece of software to another in a client-server process, Natis said. SOA implementations have focused on Web services and subordinates to clients, he said. [...]

As a dyed-in-the-wool pragmatist and skeptic, I've been kind of grumpy about buzzwords and analyst predictions for a while. (I wish that I'd titled that post "Overhype killed the WS-*", but I'm only that clever retroactively.) SOA is a style of decomposing a software system, not a vendor or an analyst property. (Note the lack of a conspicuous "™"...)

A quick search shows that Yefim has had similar views since the Paleolithic (stone tools, yuk yuk...) era of SOA as a buzzword in 2003:

A large part of the integration problem requires implementation of long-running offline business processes. Here, event-driven architecture (EDA), not SOA, is the industry best practice. Unlike SOA, EDA is the design vision for long-running asynchronous processes (SOA is best applied to real-time request/reply exchanges). In EDA, a process node posts an event (in SOA, a process node makes a targeted processing request). In EDA, posting an event reflects results of some past processing (in SOA, making a processing request directs future processing). In EDA, the poster of the event is disconnected from the processors of the event, if any (in SOA, the requestor of service knows the service and depends on its existence and availability).

If nothing else, this sounds like it confuses SOA with RPC and EDA with publish-subscribe. Yefim's on the right track that orchestration (effectively, BPM, once you add the trimmings) is a programming model for building applications in an SOA, but I disagree that SOA or even web services as a specialization of SOA is narrowly scoped to client-server interactions. My minimalist definition of SOA would be:

A service is an autonomous, opaque software unit that consumes and/or produces well-defined messages.

A service-oriented architecture for a software system is a decomposition into services.

Interaction patterns, delivery mechanisms, programming idioms, and data protocols are often aspects of an application of SOA but are neither controlling (in the sense of terminology in a contract) nor defining. That isn't to say that it isn't worthwhile to think about those aspects and approaches. For a detailed, broadly-scoped, pattern-driven perspective on SOA, compare the definition (and dozens of accompanying patterns) from Dragos Manolescu and Boris Lublinsky. (Among other things, they reference the repository of definitions of software architecture from the Software Engineering Institute at Carnegie Mellon.)

The important thing for people to realize is that both individually and collectively, the WS-* specifications are a work in progress. Wwork is ongoing by vendors, by end-users, by thought leaders, to figure out what is important (i.e., useful) through a mixture of implementation and experimentation.

A new specification should be looked at as a proposed experiment. The experiment should be based on a set of well-considered hypotheses and motivated by practical experiences. The history of the accepted standards in the space (e.g., the evolution of SOAP from the initial proposal to the refinements outlined by the WS-I Basic Profile) bears this out, and other experiments (e.g., BPEL4WS 1.1 becoming WS-BPEL 2.0) are being tempered by implementers and collective discussion. The questions in my mind are not so much about establishing the fundamental and forever immutable tenets of Web Services — always an impossible task for any effort — but rather about ensuring that the experiments that we are investing in are properly conceived, controlled, and executed.

To complement the Web Services Reliable Messaging specification currently in-progress in OASIS, Microsoft, IBM, BEA, and TIBCO just released WS-ReliableMessaging. (The WS-Addressing specification is in the same salvo, presumably to supply unambiguous identification of endpoints for the purpose of tracking acknowledgements.) The OASIS version (which I mentioned earlier in my weblog) was initially publicized as "WS-Reliability".

The OASIS version is backed (in terms of initial committee membership) by Hitachi, Fujitsu, WebMethods, Sonic Software, NEC, Oracle, IONA, SeeBeyond, WRQ, SAP, and Sun. The other version is backed (in terms of authorship) by IBM, Microsoft, BEA, and TIBCO.

The kicker in the Microsoft/IBM/TIBCO version is, as expected:

EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE [to reproduce the specification document], THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.

(Is "impliedly" a word?) OASIS has some more reasonable IP terms. At any rate, I'm not sure what "intellectual property" IBM/Microsoft/TIBCO could possibly be referring to (other than potentially spurrious patents), since sequence numbers, acknowledgements, endpoint identification, and timeouts are part of more messaging and communications protocols in the network domain, Internet domain (SMTP), and business domain (HL7, EDI, EDI-INT, etc.) than I could count.

There are a lot of "standards" floating around the web services and business process enactment space right now, including a pile of "standards" recently emitted by BEA. The BPEL4WS, WS-Transaction, and WS-Coordination specifications are also frequently and mistakenly referred to as "standards". Last time I checked, before something could honestly be referred to as a standard, it needed to be proposed to and subsequently approved by an (honest) standards body like the W3C, ISO, ANSI, OASIS, or IETF.

For instance, I like the IETF's perspective on announcing compliance with a proposal or submission:

An Internet-Draft is NOT a means of "publishing" a specification; specifications are published through the RFC mechanism — Internet-Drafts have no formal status, and are subject to change or removal at any time. Under no circumstances should an Internet-Draft be referenced by any paper, report, or Request-for-Proposal, nor should a vendor claim compliance with an Internet-Draft.

Perhaps it is now necessary for the community to move to a higher level and create an open standard for opens standards. Ideally, the specification for an open standard could serve as its own reference implementation, and, if a validator were to be implemented, the difference between marketing collateral, white papers, proposals, working drafts, and standards (as well as qualifiers such as "open") could be unambiguously determined.

Seriously, and on the bright side, seeing large vendors jockey for position with respect to "standards" is a good thing even if some of the "standards" are not. The software marketplace has validated the importance of open standards as starting points for interoperability and collaboration, and the rush to market "standards" shows that vendors recognize this importance. On the one hand, large vendors are not eager to pursue open standards because the accompanying interoperability and collaboration also drive innovation and competition. On the other hand, large vendors should favor honest, open standards because they create markets. Where's the John Maynard Keynes of technology when we need him?

Chris Peltz (from HP) has written an overview of web services orchestration that was cited by Floyd Marinescu on TheServerSide.com:

Review of Web Services Orchestration Tools and Standards. Today's web services platforms allow exposing application logic as web services, but there also needs to be a standard way to combine web services together to form business processes. In 2002, a number of new standards were introduced to address this including BPEL4WS and WSCI. A recent whitepaper from HP provides a review [of] standards, products, and intiatives related to ws orchestration.

Other than missing a couple of important vendors in the space (e.g., us), the report focuses on BPEL4WS, WSCI, and BPML.

The missing pieces of the report, in my view, are highlighted in the section called "early work" and the bibliography. The following sentence introduces the idea that any web services orchestration specification is fundamentally dependent on a notion of long-running transactions to support its execution:

Traditional transactional systems that are ACID-based are typically not sufficient for long-running, distributed transactions.

(BTP is comparable to WS-T/WS-C, but it surprising to see it given no coverage, considering that HP spinout Arjuna has been heavily involved in work on the BTP specification.) Nonetheless, the "early work" section picks up with WSFL (which is really just MQWorkflow done with web services), and the bibliography doesn't contain anything before 2000.

The fact is, there is a significant body of work starting from the late 1970's (i.e., Gray, "Notes on Data Base Operating Systems") and extending through the 1980's (e.g., J. E. B. Moss, "Nested transactions: an approach to reliable distributed computing", which you can buy on Amazon.com) and 1990's (e.g., Reuter/WÒ¤chter, The ConTract Model) on extended transaction models that doesn't even get a nod but is very much worthy of consideration. That isn't to say that there isn't interesting work ongoing, e.g., The CORBA Activity Service Framework for Supporting Extended Transactions from 2001.

Maybe this seems like heady or esoteric stuff at first glance, but if we honestly believe that service-oriented architecture and orchestration are the future of software, then any talk of "standards" or "specifications" with a less than fully rigorous consideration of the literature and previous implementations would be irresponsible.

OASIS just announced a TC for WS-Reliability. The specification is a reasonable 45 pages and has some real-world features like sequence numbering built into the specification.

The thing to do is see if it's reasonable by roughing out an implementation, but at first glance, it looks like good old reliable messaging with SOAP-based semantics.

It would probably be better to straighten out transport protocol (as opposed to data protocol) issues first, since reliable messaging over unreliable protocols doesn't make a lot of sense. It's still nice to have a simple and general specification to work with, and the ubiquity of HTTP is unassailable.

My response to a question from Simon St. Laurent on the xml-dev list provoked a couple of quotations by Kendall Clarke in an article on XML.com:

I would qualify the presence of UDDI [in the web services stack] -- "free love" on the business internet is a long way off. Security doesn't begin to cover trust, and that's far more important for business transactions.

The answer to the question "Is there a royalty-free specification of web services choreography that legitimately combines and acknowledges the established body of knowledge on long-running transaction models, business process semantics, and cross-domain implementation realities?" is "No."