Tag Archives: soap

WS-I closes its doors–the end of WS-* web services?

The Web Services Interoperability Organization has announced [pdf] the “completion” of its work:

After nearly a decade of work and industry cooperation, the Web Services Interoperability Organization (WS-I; http://www.ws-i.org) has successfully concluded its charter to document best practices for Web services interoperability across multiple platforms, operating systems and programming languages.

In the whacky world of software though, completion is not a good thing when it means, as it seems to here, an end to active development. The WS-I is closing its doors and handing maintenance of the WS interoperability profiles to OASIS:

Stewardship over WS-I’s assets, operations and mission will transition to OASIS (Organization for the Advancement of Structured Information Standards), a group of technology vendors and customers that drive development and adoption of open standards.

Simon Phipps blogs about the passing of WS-I and concludes:

Fine work, and many lessons learned, but sadly irrelevant to most of us. Goodbye, WS-I. I know and respect many of your participants, but I won’t mourn your passing.

Phipps worked for Sun when the WS-* activity was at its height and WS-I was set up, and describes its formation thus:

Formed in the name of "preventing lock-in" mainly as a competitive action by IBM and Microsoft in the midst of unseemly political knife-play with Sun, they went on to create massively complex layered specifications for conducting transactions across the Internet. Sadly, that was the last thing the Internet really needed.

However, Phipps links to this post by Mike Champion at Microsoft which represents a more nuanced view:

It might be tempting to believe that the lessons of the WS-I experience apply only to the Web Services standards stack, and not the REST and Cloud technologies that have gained so much mindshare in the last few years. Please think again: First, the WS-* standards have not in any sense gone away, they’ve been built deep into the infrastructure of many enterprise middleware products from both commercial vendors and open source projects. Likewise, the challenges of WS-I had much more to do with the intrinsic complexity of the problems it addressed than with the WS-* technologies that addressed them. William Vambenepe made this point succinctly in his blog recently.

It is also important to distinguish between the work of the WS-I, which was about creating profiles and testing tools for web service standards, and the work of other groups such as the W3C and OASIS which specify the standards themselves. While work on the WS-* specifications seems much reduced, there is still work going on. See for example the W3C’s Web Services Resource Access Working Group.

I partly disagree with Phipps about the work of the WS-I being “sadly irrelevant to most of us”. It depends who he means by “most of us”. Granted, all this stuff is meaningless to the world at large; but there are a significant number of developers who use SOAP and WS-* at least to some extent, and interoperability is key to the usefulness of those standards.

The Salesforce.com API is mainly SOAP based, for example, and although there is a REST API in preview it is not yet supported for production use. I have been told that a large proportion of the transactions on Salesforce.com are made programmatically through the API, so here is one place at least where SOAP is heavily used.

WS-* web services are also built into Microsoft’s Visual Studio and .NET Framework, and are widely used in my experience. Visual Studio does a good job of wrapping them so that developers do not have to edit WSDL or SOAP requests and responses by hand. I’d also suggest that web services in .NET are more robust than DCOM (Distributed COM) ever was, and work successfully over the internet as well as on a local network, so the technology is not a failure.

That said, I am sure it is true that only a small subset of the WS-* specifications are widely used, which implies a large amount of wasted effort.

Is SOAP and WS-* dying, and REST the future? The evidence points that way to me, but I would be interested in other opinions.

A useful Windows Phone 7 app in a couple of hours – Where’s my Train

I was interested to see that National Rail Enquiries has published a web service for its live departure boards. These give you reports on the next trains to depart from any given station, including information on late running.

Given that this is Windows Phone 7 week, I could not resist trying it out. I have a minimalist UI – you type in a station and hit Go. In version two you will just press Enter. It fetches the live train departures and displays them in a list. Version two might have a scrollbar too. Still, I’m pleased with the results, which could actually prove useful when I am running for a train.

image

Confession: it is currently hardcoded for just a few stations. That’s because you need to look up the station code in this table. I need to embed this database in my app somehow.

The coding is pretty simple though. It may help that the National Rail Enquiries web service is based on .NET, which is also why it does SOAP and WSDL, to the disappointment of those looking for REST. All the hard stuff is done by Add Service Reference in Visual Studio. The web service call is asynchronous, but there is a code completion wizard to add the necessary event handler.

Could be a money spinner if I can get it out quickly – but unfortunately the terms and conditions appear to prohibit its distribution:

This Web Site is for your personal and non-commercial use. You may not at any time modify, store, copy (including for example screen scraping), extract, reutilise, distribute, transmit, display, perform, reproduce, publish, license, create derivative works from, transfer, or sell, distribute or create any information, products or services obtained from, linked to or using this Web Site and any data therein or that may provide users with the ability to do the same.

These terms are bit puzzling, because on one interpretation they do not permit any use of the web service, even though it is stated that:

For the purposes of these Terms & Conditions the term Web Site also includes the web services, XML and any other data source supplying the Web Site.

Oh well. It still shows how quickly you can knock together a client for a web service and make something useful, although mine is really only a proof of concept. I reckon it would be almost as easy in Adobe AIR too – and then it would run on Android.

There is a National Rail Enquiries app for iPhone which costs $7.99 and likely uses the same web service.