Going With the Flow

How can companies simplify coordination of all their external interactions?

I'll save the details of both technologies for a later column, but essentially these are the basic steps that both platforms enable and follow: Developers create and deploy their Web services using whatever tools or platforms they prefer. A WSDL document, which is in XML, is created that describes a service in terms of a request message and a response message. Each request and response message also consists of an internal description of the operations to call that service and the parameters to pass to that service.

That document could then be registered in a UDDI registry. (UDDI is a registry API standard described in XML that lets you publish and edit a document to a registry and also lets others search that registry for that document or any other document.) If the described service is of interest, you can access that service's WSDL description by searching for that service in the UDDI registry. Using the WSDL description, you can create a SOAP message that binds your application to the described Web service and then send that message over HTTP to invoke the service itself. A SOAP-enabled interface on the service side translates the SOAP message and directly invokes the service, sending the response message (through SOAP) back to you. You then translate the SOAP response message as you see fit for your own uses.

Acting as One

Again, the amazing thing about both the J2EE and .NET technologies is that they can use all these standards and follow the same described flow of events. Thus, compatibility problems should be a thing of the past. However, this scenario only lets one company call one set of services from another company. What if you're an industrial fencing contractor and you interact with a raw materials provider to supply the metal, a manufacturing company to build the fence, a construction company to set up the fence, and a utility company to map where the fence can or can't be? Now you need to find a way to order the raw material and send it to the manufacturer and have this process coordinated with the construction company to actually set up the fences. On top of that, you need all these services rolled-back if the utility company says that the current blueprint for the fence crosses essential utility lines. Currently, in this system, you have no standard way of aggregating all those services together to act as one transaction and have them automatically stop or change in some way based on the responses from each or all of the mentioned services. This scenario is when IBM's new specification, Web services flow language (WSFL), comes into play.

IBM introduced the WSFL specification in May 2001. Currently, many companies, including IBM, are working toward implementing WSFL in their e-business platforms. Essentially, WSFL (described as an XML document) lets a company define all its external services it routinely deploys (in a WDSL format) and then map connections between its business processes so that the services are aggregated in a way that allows for either successful execution if everything goes right or coordinating the canceling of some or all of the services if things don't go right. In a very standard way, it allows complete flexibility for the coordination of services.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

If other companies you do business with also support the WSFL standard, they then know how to coordinate the services you request from them with your other needed services. For instance, the raw material company can coordinate with your packaging company of choice to send raw material to the manufacturing company. And using that one document, the manufacturing company can do the same exact thing when it has to ship the fencing material to the construction company. As long as the company supports WSFL, the coordination of tasks becomes commonplace.

The WSFL specification was just released in May and still has some time before commercial products fully support it. However, WSFL is the start of a new era of Web services that promises to further expand the ability of companies to simplify not only how they interact with individual businesses, but also how they coordinate all their external interactions. It is the promise that B2B interactions can happen without rewriting internal systems. At long last, Web services promise the reduction and simplification of the dreaded integration cycle. And finally, "Web services" is no longer just a buzzword, but the beginning of a new Internet architecture that ensures that the whole will be greater than the sum of its parts.

Michael J. Hudson [mhudson@blueprinttech.com] is a framework engineer for Blueprint Technologies, a software architecture firm based in Falls Church, Va. His current work includes developing XML-based architectural solutions for various clients including NASA. He has had extensive professional experience in developing and tying together multitiered information systems for a number of different companies.

RESOURCES

IBM's specification on WSFL: www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

Microsoft's vision of Web services: www.microsoft.com/net/whatis.asp

News and articles about the technology and state of Web services: www.webservices.org

OASIS specification on UDDI: www.oasis-open.org/cover/uddi.html

Sun's vision of Web services: www.sun.com/software/sunone/wp-arch

W3C specification on WSDL and SOAP: www.w3.org/TR/wsdl.html and www.w3.org/TR/SOAP

A Web services primer: www.xml.com/pub/a/2001/04/04/webservices