A fellow consultant asked me for help last fall after taking a quick-and-dirty application integration job. It involved a large Midwest manufacturer running SAP R/3. This company had absorbed a smaller manufacturer that was running MFG/Pro. Each had preestablished data communications with numerous customers, brokers, and distributors, so the parent company decided to leave its new acquisition’s in-house systems untouched. However, the parent company needed to pass on purchase orders transparently to the other company. My friend was thinking he had an ideal prospect for a WSDL application.

He called me for help with the EDI part, as that was the smaller company’s central way of communicating. The plan was to facilitate purchase order processing between the companies quickly and with minimal impact on both sides of the transaction. After we discussed it, he decided that on the big company side, the purchase order—a straight copy of the inbound document from the customer being stored in its system—needed to look like an outbound SAP IDoc on the sending side and like inbound EDI on the receiving side. And the kicker was that the entire transfer needed to be fully automated.

Not so long ago, achieving such transparency would have been a major undertaking. Since the advent of Web services, however, such B2B transactions have ceased to be intimidating, and they can actually be achieved quickly and inexpensively.

How many lanes does your bridge need?
In choosing a WSDL application as the best bridge for these applications, we had to answer a couple of questions. First, was it necessary to go to that much trouble? There are a number of third-party integration packages for Web-based applications that might have done the job.

What was needed, however, was a very specific repackaging of business documents that would require regular modification, sometimes very specific and tricky (those who have wrestled with EDI at the source code level will understand). Furthermore, it was anticipated by the parent company that this bridge was the first of many; additional smaller manufacturers would be acquired; and similar, customized, transparent application bridges would need to be constructed. Would a third-party integration package be sufficient, or would the company be better off plunging into the world of WSDL and building its own Web service applications?

If you’re facing a similar decision, this is the first high-level question that must be answered, and you must base your decision on a number of related questions:

  • Will the relationship be one-to-one, or one-to-many?
  • If one-to-one, will it be stable, or will format revisions (on either side) be required?
  • If one-to-many, will the flow of data be bidirectional?

An off-the-shelf integration package is probably the way to go if it’s a one-to-one connection that won’t require much tinkering. If any of these other scenarios exist, then building a Web service application may be the better choice.

A WSDL parts list and instruction sheet
Web services have come upon us quickly, promising a great deal and toting a lot of baggage. If you’re new to this detail-heavy technology, don’t let it put you off. Web services are built on flexible, familiar technologies and really do deliver what they promise.

Many B2B applications are candidates for Web service implementation where automation is desired. Supply chain management (inventory management in particular), updating of foreign databases, brokering of third-party services, and many other applications are ideal candidates.

The piece that you’ll actually be writing will be the service description. It’s important to understand where this fits in the scheme of things.

Once you know how the application will be functionally configured, you need to choose an application framework upon which both parties agree. In general, the application data you’re sending (which has been mapped into ebXML or some similar format) is wrapped in an envelope. The standard envelope is the XML-derived Simple Object Access Protocol (SOAP). SOAP is transport-protocol-independent, so you have your choice of transport protocols (SMTP, HTTP, HTTPS, etc.) See Figure A. SOAP binds your application data to your chosen transport protocol. This gets your data to the service.

The services directory provides a service name, describing the service appropriate to the application (this is the WSDL piece). This service is defined in WSDL, and included in that description is the application data’s destination. (Once the application data is processed by the service, the entire process reverses as the application data proceeds to the receiver.)

Figure A
Hierarchy of protocols in Web services data transfer

Choosing a framework
Choosing an application framework may be as simple as taking stock of what your company already has in place. The whole point of Web services is getting applications to communicate across the Internet, independent of platforms and languages, and the motivation for doing so is that most every company on the planet now has some Internet platform in place.

This has the added virtue of freeing both parties in a remote transaction, such as the two companies in my colleague’s application, to be completely framework-independent of one another, not only in application data formats and house systems (which was their goal), but in every aspect of Internet communications. The questions to be answered by each party, then, include the following:

  • What will be the format of the transport-ready application data?
  • What will the transport protocol be?

Remember that the idea here is to use what’s already in place, unless there’s a good reason not to. That’s where the convenience and economy of Web services are most obviously realized. It’s simply important to get these details down from each side of the transaction as you begin to configure your application.

Next steps
Once you have a handle on the business needs of the transaction being automated, how deeply you’re going to go in customizing your application, and the details of the existing platforms, you’re ready to proceed with configuring the application.

There are two major phases to the job: setting up data communications and writing the Web service description, which we cover in Parts 2 and 3 of this series.

Keep your client or senior management advised as you arrive at this point. This is the moment to stress how efficient this method of setting up B2B details can be, and how much money it’s going to save. The savings is built into the whole Web services paradigm, but there’s no reason you shouldn’t get a pat on the back for it!