« links for 2007-04-08 | Main | Always Be Closing »

Matchstick Men

Does anyone care?

Tim Bray:
"This happens over and over. New WS-* spec submission, check. Insanely huge charter locking down the conclusion and ensuring a rubber-stamp outcome, check. Loads of dependencies on WS-standards, WS-drafts, WS-submissions, and other WS-handwaving, check. Resolute obliviousness to other technologies that address the same problem, check."

Burton Group: "The WSFED charter gives lip service to working on convergence with SAML 2.0. Like other commenters, we find this less than convincing; the WSFED charter's invitation to other standards committees looks like a passive-aggressive maneuver. It puts the onus on SAML 2.0, which has already been standardized, to come to WSFED on their terms and make changes to an established standard to accommodate features of a specification which was not developed in an open forum and is not yet a standard."

Eve Maler: "UPDATE: The telecon was held this morning. TC convener Paul Cotton responded to the collected comments by reading from a prepared text that gave the same answer 30 times: “Proposed response: no changes to the WSFED TC charter are required.” The sole exception was to accept the comment noting extraneous characters. Message received loud and clear"

Paul Madsen: "No change is required"

I read what Tim, Eve, Paul and The Burton Group had to say. The criticisms lacked bite. I found myself strangely unmoved, unsurprised, unshocked, unconcerned. I saw that a firestorm has not been lit across weblogs, as would have been the case not even a year ago. It seems that no-one cares anymore, and WSFED will be consigned to irrelevance and along with it, much of the promotion around WS-*. WS-* as a process, as a technical means designing systems , as a way to generate 'future business value' now lacks credibility. This has less to the do with the technology involved and more to do with how the technology has be presented to the market, and consequently how it has evolved.

The Business of IT is Business

This apathy is bad news for the handful of vendors and OSS communities who are at least trying to get something done with WS-*, instead of managing incumbent revenue streams via standardisation. It's bad news for those technologists, consultants and analysts who promoted WS-* years ago, and now have to quietly disassociate themselves or reframe the past as a great learning. It's bad news for those with deployed WS-* systems, who might be facing yet another re-architecting exercise in the coming years.

The lessons to be learned from the heavy-handed promotion of WS-* are twofold.

First, both enterprise software and services organisations need to rein in their marketing and sales divisions, as strange as that might sound. In essence, they need to stop promising miracles. What has happened with WS-* promotion, and what is happening with SOA is bad for the industry, bad for shareholder value. Customers will come to reject the vendor/analyst/consultant triumvirate if it comes to appear to be nothing more than a racket. In effect, that would be a rejection of the entire market. This helps no-one, least of all customers, dependent as they are on software and related services. More realistic approaches to the market need to be found - "rip and replace" of IT assets isn't a sustainable model (ironically WS-* in the beginning was about avoiding such expense).

Second, and more important, one cannot cleave technology from business and expect good results in technological matters. This has afflicted the evolution of WS-* for years. There has been much talk since the dotbomb collapse about alignment and governance, yet what seems to have happened is that technology and delivery aspects have been given short shrift. In the meantime business people make uninformed technology bets that have to be honored with vigorish later by IT departments and project teams. The notion that the "business of IT is business", has been transformed into "IT doesn't matter", with the consequence that the valid concerns of IT people are not heeded.

IT is Business, Business is IT.

However good the slogan the "business of IT is business" might have sounded after the dotcom bubble, the gap has in fact widened. Critically the upkeep and maintenance of legacy systems has come to dominate business software spending. Most large enterprise IT divisions now have the equivalent of a pensions fund crisis, except that all the money is being spent on old systems instead of old people.

In software projects, the devil is truly in the details. IT projects tend flounder not due to big picture issues. They fail due to the details of delivery, which leads to gross cost under-estimations and to project death spirals. Getting into details "at another date", one which is always deferred, cannot be therefor considered a sound approach to project risk. Nor can the diversion of funds to new grand projects based on new architectural precepts away from upkeep and modernisation of existing systems that literally "run the enterprise".

By the same token, process models that encourage strong separation of software and business functions are arguably broken - just why can't your business analysts make initial assessments of the technical costs instead of drawing matchstick men? Why is it that VPs, well able to understand complex matters like logistics, options theory and even spreadsheet programming, get a pass when it comes to something conceptually simple like their intranet or email systems? The result is further cost and inefficiency as requirements and needs are transliterated back and forth between competing specialisations. That WS-* was pitched as an abstraction, as a way to not have to care about technical details has not helped.

What's next for IT?

Assaf Arkin correctly observes that REST is now the "cool by association" technology. That will be interesting - REST is technically grounded and puports to describe the as-is architecture of the Web. The grassroots that promote it and build in that style have made it clear they have no truck with the marketing spiel that currently surrounds WS-* and SOA. Indeed the growth and promotion of REST and Internet style has been done in sharp counterpoint to WS-* technologies. Expect a lot of people to get grilled, if not flamed, as they try and repurpose the REST label. Yet however curmudgeonly REST proponents like to act, some dilution seems inevitable, as has been the case with with business adoption of open source (both its software and its processes). And do not be surprised to see specific WS-* technologies and ideas with technical merit, such as SAML and payload encryption, make an appearance while the process that generated them is discarded.

April 8, 2007 04:17 PM


Dan Diephouse
(April 8, 2007 07:17 PM #)

WS-* has failed in its deliverance of abstracting away the details. But I think that people make the mistake of completely writing off WS-* because they assume that the motivations are bad (its those evil vendors!). However, it is quite important to realize that use cases such as SAML integration, message encryption, security token exchange, etc DO can be completely valid (although I will admit that most people can get by with something simpler). Whatever architectures we propose (message oriented or restful), we still need solutions.

I would like us to start focus on creating real solutions to these problems using RESTful principles. I think that this will definitely raise some concerns in the REST community though. For instance, there is considerable debate about whether you should need a description language for your services. Yet I would argue that WSDL is the "killer app" of SOAP. Can we make any progress if haven't even started a standardization process for a RESTful description language?

Bill de hOra
(April 8, 2007 07:51 PM #)

"But I think that people make the mistake of completely writing off WS-* because they assume that the motivations are bad (its those evil vendors)"

QOTD, Dan. I might have underemphasised that it's how the stuff was brought to market that really hurts - I have plenty of time for example, for payload encryption having worked with an expert on it a few years ago, and have been reminded recently by Gunnar Peterson of its value.

"I would like us to start focus on creating real solutions to these problems using RESTful principles. I think that this will definitely raise some concerns in the REST community though."

I think we need to talk about how "REST as in the HTTP Web, sucks", before it becomes another silver bullet. There are definite issues. Most people wouldn't pick out description in the first pass, but they certainly might point at authentication, collections and media types. The other issue is people force-fitting problems that REST isn't optimal at solving (such as eventing and notifications), because HTTP is ubiquitous.

David RR Webber
(April 9, 2007 09:16 PM #)

What people are realizing is that selecting communications infrastructure has to be cost effective and based on their real business needs.

WS-* is technology designed by OMG folks for DOD customers with spook-level information security and complex handling requirements. Notice while this is less than 10% of applications - DOD has trillion $ budgets to buy this stuff from OMG member companies.

Those use cases simply don't add up for average eBusiness, eCommerce and eGovernment applications.

Back to ebXML (again) - and REST - the cool new business tandem. Check out the killer success Helena Chemicals scored by combining ebXML with BPEL using Oracles solution mix (Google - B2B BPEL Oracle). Who would have thought Oracle would be showing the world how simple and cost effective this is? Similarly IBM is now shipping native ebXML support in the new WebSphere 6.1 - but best of all there are now three robust OSS implementations for ebXML available too.

This appears like a slam-dunk - any large site with Oracle AS or IBM WebSphere can now do ebXML - while their smaller partners can select an OSS tool.

So I confess - it did not take much to make me a AJAX/REST convert - and being able to combine this with Registry services to enable large scale rapid applications support services for eBusiness communities - well I may be hopping on the cool bandwagon - but this is one that I've always preached - just now the tools and business understanding are catching up with just what can now be accomplished.

Check out ebxmlforum.net for latest news and details on ebXML - you simply do not have to do WS-* - and now Oracle and IBM agree with you!

(April 9, 2007 09:54 PM #)

It's a good article I understand the business ideas is more useful to people the business ideas is more enjoy with this so who want to know about this type of information visit the site business">http://www.ideacenter.com/">business ideas

Phillip Toland
(April 11, 2007 02:59 PM #)

"I think we need to talk about how "REST as in the HTTP Web, sucks", before it becomes another silver bullet. There are definite issues."

Of course there are issues, but I think there is a problem in defining the discussion as "how REST...sucks". The WS-* discussion has eroded largely due to the attitude that technology is inherently "good" or "bad". It isn't. Is is appropriate or inappropriate for a given set of circumstances. So, lets talk about where REST is inappropriate, and then lets talk about what technology would be appropriate in those situations. Maybe it is WS-*, but maybe it is something that evolves from the principles of simplicity that REST embraces.

"Its better to light a candle than to curse the darkness."

David RR Webber
(April 11, 2007 08:43 PM #)

To help with the "is it appropriate for my needs?" - here's a PDF set of slides for comparison of WS-I / WSDL against a selection of other B2B / EDI transport stacks and technologies:


SWOT / Criteria matrix

Add you own weighted score card factors - and you should be close to knowing what makes best sense.

Bill de hOra
(April 11, 2007 08:45 PM #)

"It isn't. Is is appropriate or inappropriate for a given set of circumstances."

Phillip, here's the problem - that approach didn't work for WS. That WS is appropriate for a given set of circumstances I don't dispute, tho' I'm not sure what they are, (perhaps high throughput over a partner WAN), but it's a recent position to take - WS was being positioned at one point to fix our dependency on HTTP, and the Web. It's hoping too much that the industry will learn anything from overhyping approaches - after SOA collapses, either EDA or REST is next for the bandwagon, with P2P or Grid/Parallel being an outside shot.

The compromise seems to be - "REST as deployed in the HTTP web sucks - for this"

(April 24, 2007 07:03 PM #)

David Webber - "ebXML - you simply do not have to do WS-*"

David, ebXML is fundamentally based on the ebXML Messaging Services specification, which is itself entirely built on SOAP. The ebXML MessageHeader element depends on an existing SOAP implementation. Therefore it is expected to interoperate with the existing SOAP infrastructure.

If anything, ebXML shows the pain of not integrating with certain aspects of WS-*... the ebXML Security Core Module specifies that Signature is a top-level SOAP header, unlike WS-Security. This means that it completely fails to leverage all the message-level encryption and security token identification that has been laboriously built up in WS-Security implementations.

I have personally had to deal with ebXML implementations that were a horrible mishmash of SOAP, WS-Security, XML Signature, and S/MIME. XML Signatures containing references to encrypted S/MIME parts... meaning that you need to decrypt the part with S/MIME and hash the plaintext in order to validate the XML Signature. And this was a message from the dominant ebXML vendor.

The fact is, there are some very difficult problems when you start to integrate non-trivial business systems: persistent authentication, integration and confidentiality (i.e. beyond the scope of SSL); delivery to multiple audiences; and, of course, the never-ending need to interoperate with legacy systems.

WS-* isn't a silver bullet, but many WS-* vendors are at least trying to address these issues. REST may be fine for simple point-to-point exchanges with a contract that is simple enough to be described in text, but that doesn't begin to describe the kinds of interactions that exist in a modern business application network.

Post a comment

(you may use HTML tags for style)

Remember Me?

Trackback Pings

TrackBack URL for this entry: