« Objects v Services: move along, nothing to see here | Main | RSS feed for the Apache WebServicesSpecifications list »

Spec Infected: why programmers hate writing web services

WebServices are mostly implemented in the most modern environments like Java and .NET. Can anyone point me to a C binding for SOAP, or even a more difficult one that's implemented for Cobol? Carlos Perez

No, but would we want ever expose such things via a direct binding? Legacy systems living deep in the enterprise, in general don't seem to require web service interfaces; they require web service gateways with data transformation pipelines that can be dynamically brought into the delivery channels. While I think there are avenues of exploration, deep integrations aren't yet something than can be push-button automated by tools. But there are ways to get the job done faster and better.

Consider this - exposing a 24x7 web interface into a mon-fri batch nightly COBOL job system. The COBOL system works correctly and is mission critical to the enterprise in question; not something to be tinkered with. Our answer to that scenario was to accept data and queries as async calls over HTTPS in XML form encapsulated by a standard XML envelope. The back of the web service is a series of pipelines. The pipelines entail auditing, structural validations, content validations, code mappings, pre-matching, data cleansing, statistical capture and conversion to the job a format before leaving the job in a repository. A second process running on a schedule uploads the jobs to VMS vis FTP. A third process collects FTP'd responses from the COBOL systems and proceeds to reconcille the responses with the submissions and fulfil those back the sender of the original XML message via another pipeline as well as publishing the results to other subscribers. The setup has proven flexible, and robust to changes in requirements and semantics.

The idea of blowing out the service from the COBOL; that would be problematic. Herein lies a key issue with the way middleware webservices toolsets prefer to be used - codifying a domain model, then generating web service stubs and wsdl descriptors for deployment to the DMZ tier is, in terms of software process, precisely backwards for deep integrations or repurposing for service oriented architectures. Neither the tools or the local object models should be driving the integration process, they should be supporting it. There are some subtle gotchas. Web interfaces and batch processes are working to different timeframes; this entails an asynchronous gateway, but also impacts system adminstration and operation. There is usually no canonical domain model in an enterprise and perhaps more importantly no time or possibility for agreement on one - I see this as being a serious issue for efforts like the OMG's MDA and the consequent modelling toolsets coming down the line.

Having built the web service, it would be fine to expose, say, WSDL if someone really wanted it, but this is driven from the service design, not the provisions in some RDB/OO/WSDL mapper. Personally, I would see generating WSDL as being a publication exercise more than a design exercise.

As for the Achilles heel of web services :) I've complained about toolkits, but it's not that (as understanding of enterprise integrations grows, the tools will get better). In early 2004, the Achilles heel of web services is the complexity resulting from the sheer volume and lack of coherence in the web services specs and a lack of architectural guidance from the folks generating them - hence the title of this blog. Witness the current ASF list.

[Update: Mark Baker laments the passing of the W3C Web Services Architecture group. Me too - there was some confort to be had by having the likes of Mike Champion, Eric Newcomer, and Frank McCabe thrashing this stuff out. ]

February 1, 2004 11:27 AM


Trackback Pings

TrackBack URL for this entry: