Morphing the Web service concept
Talking with various folks over the past couple of months, we surfaced the question of whether there is a fundamental difference between document and service based architectures. We spoke with several organizations that said that they were aggressively embracing XML as a document standard, and that this seemed to be in conflict with Web services architectures.
XML document vs. service architectures
For example in the financial sector many banks and financial institutions are implementing a broad range of XML based document standards, such as FinXML and SwiftXML. Now these standards apply to documents that need to be passed between institutions and front and back office, and are more like EDI in nature than a transaction. In fact the transport will generally be some form of messaging service such as MQSeries or similar. And for these organizations the question is highly pertinent, "Why do I need Web Services?" All I really need is an XML processing capability that allows me to transform and integrate the documents that I send and receive into my processes.
Although this situation exists in many different business sectors, I was talking to banking folk and so I asked IBM to comment on a banking case study. Their response is very interesting. They indicated they definitely recognize the issue, that organizations are evolving from message
WSDL based convergence
However, the explicit IBM strategy is based on a convergence of document and RPC based architectures, around WSDL. Their strategy is based on wrapping up everything as WSDL, which they regard as a unifying concept, which is neutral to event or message base.
Of course our own definition of Web service is actually neutral - "A Web service provides programmable access to a capability that can be used independently of its implementation via a self-describing interface based on open Internet standards" but the realization of a Web service is generally RPC oriented, and indeed the term "service" depicts (for me anyway) a two sided interaction. I request and you provide.
Now along with this approach goes another IBM strategy that is to make Web services available on all manner of transports. They fully accept that Web services will not be universally embraced if SOAP and HTTP are the sole pre-requisites, and IBM show evidence of good progress down this path with support for Web service bindings with JMS, EJB and JCA already available.
And we fully agree with this. IBM's WS Invocation Framework (WSIF) is designed to wrap existing non-SOAP based services such as these, as well as technologies such as CICS and CORBA in WSDL. The notion of alternative message transports, such as CORBA, is not new in WSDL: it's been there all along, but now WSIF exploits it and highlights the possibilities.
Also, we (and the industry) need to be careful about perceiving and positioning SOAP as always being RPC. SOAP is just an envelope, it doesn't have to be used RPC fashion. It is the application behaviour, the context it is used in, that makes it RPC. When you receive a SOAP message, you can still put it on a message queue, or process it and add it as a record to a file that is input to a batch programme. Even so, when these approaches are used there is the perception that SOAP messages will be dealt with as request/response pairs, and regardless of how the provider actually deals with them; the consumer will be waiting on an immediate answer.
Where's the justification?
The real issue however is why harmonize on WSDL because there is clearly a cost associated with this move. I asked IBM to consider an archetypal banking customer that is using SwiftXML and has an established batch process in place that transfers large numbers of documents between banking organizations and front to back office. Currently they are using straight XML, transported over MQSeries with Java code managing the translations, transformations and interactions with business logic. I asked what is the commercial justification for implementing WSDL on top of this batch process? The answer was that it's about standardization and potential flexibility. For IBM they are keen to promote the WebSphere single toolset environment, which provides a single IDE, single skills, common metadata layer and process definition environment that can be used for many different architectural alternatives. Clearly this can be an attractive message, but it does seem to me that there will be a transitional period during which architects will perhaps make haste slowly unless there is some compelling event that causes them to need to re-architect or to reengineer the process.
Notwithstanding this, the IBM intent potentially changes or at least morphs the Web service concept as it is currently widely understood. In fact everywhere you look, a service is described as a service request and response.
However the WSDL specification says:
A given WSDL definitions group MAY contain:
- at most one type description component, and
- zero or more message description components, and
- zero or more portType description components, and
- zero or more serviceType description components, and
- zero or more binding description components, and
- zero or more service description components
that confirms the interface related elements (portType, servicetype, binding, service description) are all optional.
Morphing the Web service concept
So just what is a service? Is it any form of (WSDL) self-describing resource? Should we care? Or alternatively is the WSDL concept going to become eventually the most important aspect of the new paradigm? We have certainly argued that it is self-description that is the breakthrough concept. Perhaps we should be realigning WSDL as a subset of RDL, a resource definition language. Certainly this is good advice in practice if not strictly necessary in a formal sense.
In practice many early message passing applications of XML document exchange will eventually be brought into more sophisticated business processes which take advantage of the request response architecture. Some readers of this newswire will smile as they get a sense of deja vu, as we were here before some thirty years ago as the world transitioned from batch to online processing. But just as a proportion of applications validly remained as batch architectures, so some XML applications will also validly remain as message based applications. But in time the majority will probably transition into a request response architecture where the real end user sees a straight through process that provides end to end visibility of the transaction or process.
The IBM position is also interesting because it indicates a convergence of multiple architecture support from a single toolset environment. With any new concept, it is simply practical that early tool support is fragmented and specific. However, very rapidly organizations need common skills and management environments that IBM and the other stack owners such as Sun and Microsoft clearly aim to provide. And not surprisingly IBM stresses the relevance of enterprise integration which is an important part of their tool bag.
At first sight it may seem that IBM is perhaps being somewhat evangelical, however for new applications particularly, we are of the opinion that it is eminently sensible to architect them with WSDL in order to have metadata based description of the artefact that provides a common description and asset management environment.
At the outset Web services was a single, simple concept that enabled distributed computing to be conducted in a loosed coupled manner across the web regardless of platform - this took the CORBA, DCOM, Java vision to a new level of practicality and applicability. It had two important benefits - providing a single set of standards for developers, and enabling dynamic real time B2C and B2B business processes. However, this is now changing. The protocols are becoming general descriptors of any interface or message. Whilst this still helps ensure the protocols are genuinely open, there is a danger that part of the original vision will become diffused and lost. Whilst this shift will aid developers by simplifying integration, customers need to understand that the original dynamic business vision of Web services is not going to be fully realized by giving batch processes a facelift, and compromises are usually sub-optimal.
IBM promotes the concept of 'Internal' and 'External' web Services to compensate for this. Internal services use enterprise technologies like CICS, JCA,etc. Wheras External services remain focused on SOAP and HTTP. Their new WS Gateway technology is designed to then join these two worlds together.
IBM's actions reflect the reality of the enterprise customer base and IBM is acting smart in recognizing that the standardized protocols will be an important enabler of technical and business integration across a broader range of technologies.
Please send your feedback to email@example.com.
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and Web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For More Information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.
This was first published in July 2002