Bridging an application across companies is easier today than ever before, thanks to a multitude of options. The natural consequence of this bounty is a need for careful forethought and planning, particularly if you venture into the world of Web service applications and Web Services Description Language (WSDL). Web services and WSDL are designed to leverage your existing data transport resources, and they offer considerable cross-platform compatibility—if you diligently define all sides of the transaction your application is facilitating. I’ll look at the details of just such a cross-platform application.

A colleague of mine was asked to design a passive application linking a prominent national food manufacturer’s order processing system to that of a recently acquired junior manufacturer. The idea was to join the order entry systems transparently. A customer order would hit the parent company’s SAP system and then be handed off from the sending company’s system from an outbound IDoc format. The order would then become inbound EDI from the point of view of the receiving company.

My friend set about designing a Web service application to do the job and, more importantly, to lay the groundwork for future applications of the same general type. With WSDL, it was a simple matter to structure the business data being handed across as the database-portable, flat-file output of the receiving company’s EDI translator. (It was less simple to retroactively update the running logs of the EDI system so that the inbound Web service message would be logged as if it were EDI, but that’s another story.)

Once the high-level decisions were made, there were two main design phases: (A) defining the data transport configuration and choosing the tools for its implementation and (B) writing the Web service description.

The data transport to-do list
Once you’ve defined the platform and protocol resources, it’s fast and easy to create the to-do list to prepare the data transport side of the Web service application. Here are the steps:

  • Select and configure a mapping utility to format application data appropriately.
  • Select a utility to prepare and implement the Simple Object Access Protocol (SOAP) envelope.
  • Select a transport protocol—usually you’ll use whatever is already in place for Internet communications.

This is, of course, the easy part. Creating the service itself is the real hands-on portion of the project. But it’s fair to describe even that as short and simple.

Writing the Web service description
In part one of this series, we looked at the necessary information and components of data transport. The guts of a Web service application, however, are found in the service description.

The marriage of the transport technologies to WSDL, an XML-derived language, permits a surprising degree of automation in a communication chain that is complex out of necessity. That’s the point of the Web services paradigm: Not only does it leverage a rapidly growing technology base, but it also allows more automation than EDI and its cousins have ever provided, and with an ease of implementation that EDI can’t even approach. In Web services transactions, no intervention is required. Transactions are thoroughly automated. The service handles requests and responses, system-internal queries, relevant services, endpoint routing, transaction auditing—everything that conventional EDI offers, and more.

In the case of my example, my friend used WSDL to create a service description for purchase order remapping and routing, define its parameters and attributes, enable message delivery, and handle the application data. These key sections make up a typical service description:

  • Header—typical XML, including version ID
  • Services—schema definition (XSD) for element types used in the service description
  • Messages—contains mapping detail for element request and response
  • PortType—for routing and interface. It defines endpoints for the service
  • Binding—for SOAP binding, definition of I/O parameters
  • Security declarations

Required information for creating the service description
From an application standpoint, the most important service description was, in this case, the mapping of purchase orders. The front end of the application was a cakewalk, but the back end required some fancy footwork. However, most applications aren’t quite so finicky. As a general rule, you need the following:

  • A complete data description encompassing the full range of anticipated messages (and all included types) relevant to the application
  • Detailed data mapping
  • Routing information

In short, most of the information you need to write a Web service description is information you’d have on hand for any in-house data handoff between applications that involve data transport.

It’s hard to imagine a more flexible yet economical framework for passive B2B integration. Through WSDL, Web services are platformed to replace most of today’s prevalent data interchange systems. I’ll look at the growing number of tools that enable this transition in part three of this series on WSDL for B2B.