Sample chapter from:
Web Services Implementation Guide

Authors:
Brian Travis and Mae Ozkan

About the book:
Getting value from stuff you don't own is a compelling idea. Just think, someone else has created something that has value, and has made it available to you. You can now leverage its value in ways that makes all parties richer. That's the promise of web services. You need to know about web services. The advent of standards-based web services marks a new era of system development. First mainframe, then client-server, the Web, now web services makes it possible to leverage every legacy system of the past and do so much more with your information assets.

This book will show you what a web service is, and how you can align your systems to take advantage of this new concept in system integration. This book covers the concepts and technologies of web services.

Web Services Implementation Guide is a multiple-volume set. Volume 1 shows you how to align your thinking and systems to get the most of web services. Volume 2 is a technical treatise for developers. Volume 3 discusses real-life implementations of web services solutions.

ISBN:
0964960230

In this chapter:

Introduction to SOAP
Message Transport
The Two Personalities of SOAP
Why Do We Care About SOAP?
SOAP in Real Life
Summary

Chapter 7 Simple Object Access Protocol (SOAP)

The Simple Object Access Protocol is a standard that has provided a simple solution to a complex problem. The problem is that integrating systems is difficult. That's not really news, but it is a fact that many I.T. professionals are well aware of. The main area of incompatibility arises because information and objects are distributed all over the place.

The SOAP standard provides a set of tags and an environment that allows systems to request information from other systems by sending self-describing messages over any network.

SOAP is really just an envelope, but its simplicity means that it is easy to use and very flexible. In this chapter, you will learn about this most important standard for web services.

Integrating systems are difficult. First, there are systems running on different physical machines. Getting information from one to another is not as easy as getting two programs on one machine talking to each other. There are networks between any two machines, and these networks complicate the process.

Next, these different machines might be running different operating systems. This could entail just different versions of the same operating system (Linux vs. AIX or Windows 98 vs Windows XP), or they could be entirely different platforms (Sun Solaris Unix vs. Windows 2000).

Finally, there are differences in computer languages and the interfaces they expose. One machine might be using Java programs exposed through CORBA, another machine might be running COM objects written in Visual Basic.

Integrating all of these is difficult, even if there was only a single variable. Adding variables increases the complexity logarithmically. Getting a CORBA object running on a Unix box talking to a COM object running on Windows 2000 Server is very difficult to do because of these problems. Objects are tightly coupled to their programs because of the way object architecture has developed over the past years.

Then there is the problem of firewalls. Getting method calls through firewalls is quite a chore. Not just technically, but also politically. Firewalls are protected by people called "firewall administrators". Have you ever asked a firewall administrator to open a special port for you? "Mr. Firewall Administrator, can you please open port 1234?" And what was the answer? I'm not sure you even got that far. Here is a more typical exchange: "Mr. Firewall Administrator, will you please...", at which time, he cuts you off, and says "No!". God bless these people, for they have a very difficult job in maintaining security while still allowing commerce to happen.

Another issue, after you have opened your firewall, is the problem that platform specific "standards" are not compatible. For example, your CORBA objects work great as long as everyone is speaking this "standard" interface language. But try to get a COM object or some other proprietary object talking to your CORBA objects and you will have problems.

There are gateways that allow you to access different objects across heterogeneous environments, but these are pretty flaky and bring their own problems. The SOAP committee addressed these problems and came up with a vision that they should use XML packets to allow disparate systems to communicate. Because SOAP is based on XML, then any operating system or program that can read an XML document can be accessed.

Let's see how SOAP works. First, we have an object, as illustrated in Figure 72, An Object.

This object is not necessarily a modern programming construction. It can be anything that provides some service to an implementation. In fact, when we think of this object, we think of "the four ‘C's": COM, CORBA, COBOL, or a closet full of monkeys. This last one might seem a bit flippant, but our point is that the requestor does not care anything about the implementation details of the server giving the request. If the server has some unique implementation that can get value from a closet full of monkeys, the client should be no wiser.

This object, program, or collection of primates does its processing the same way it has been processing things since it was born. It interacts with its environment, opens databases, interrogates other objects, etc. Our goal will be to get this object to give us information with as little disruption (preferably none) as possible. The reason for the fear of disruption is that this object might be providing for us a valuable service in other areas of the organization.

Let's say this "object" is a COBOL program that has been running in our enterprise for decades. There is still a ton of data that is maintained by old COBOL programs running on various mainframe computers around the world. The entire worldwide airline reservations system, for example, is maintained by such programs. There are production-control and reporting systems, inventory tracking systems, and lots of other private systems running COBOL. One of the main benefits of COBOL is that it has been around so long that COBOL programs have been optimized and fixed for years, and much of it is reliable, scaleable, and bug-free.

If we want to provide the output of this COBOL program to new processes, we need to teach it some new tricks. This would involve modifications to the code, which might be difficult¹. Or we could re-write it. This is not usually a viable alternative. When is the last time a programmer told his boss that he has some spare time and would like to re-write that old COBOL program in C?

Another problem with modifying the existing code is that we would need to go through thorough testing, which might upset our business operations. Worse, any changes we make to the object might break other parts of the object that already work.

So how can we use SOAP to solve this problem? Let's put some network between the object and us, then create a thing called a "SOAP client". A SOAP client is called a client, not because it is used by some end-user human, but just because it creates a thing called a "SOAP request document" In fact, most SOAP clients are applications or servers.

This SOAP request document is sent over the network, usually over HTTP, to a piece of code called a "SOAP server". This is illustrated in Figure 73, SOAP Request.

The SOAP server's main job is to act as a translator for the request. Consider a human translator. That person will listen to one language, say German, and speak another language, for example French, then will listen to the response in French and speak it in German. In this way, the translator allows two people who do not understand a common language to communicate with each other.

The SOAP server is like that. It listens to a language "spoken" by the SOAP client, and translates that into some language that is understood by object. It is up to each implementation to determine what each language is. For example, if the SOAP client wants to get the weather forecast, it will send a request to the SOAP server. If the Object is a COM object, the SOAP server will instantiate the object and invoke the appropriate method to get the weather.

If the object is a COBOL program, it is not quite so straightforward. COBOL programs running on mainframe computers usually interact with the outside world using a character-based terminal called a 3270. This is a terminal that weighs about as much as your car. Come to think of it, when they were made, they probably cost more than your car. These terminals have a keyboard attached to a screen that displayed green text in a 25 by 80-character grid². On the right hand side of the keyboard is a key marked "Enter". When a user fills in fields on the screen and presses the Enter key, the terminal sends a screenful of information to the mainframe. The terminal interface on the mainframe parses out the screen looking for information that it needs, and sends the appropriate characters to the program.

The program does its thing, and returns a screenful of data back to the terminal, where the human can make note of the information necessary. As we have said before, the program that reads this information is doing its job just fine. If we were to open that program in order to teach it how to interface with SOAP, it would be quite a system development task. We might break things that were working.

Instead, perhaps we can teach the SOAP server to pretend it is a 3270 terminal. That way, the COBOL program will not need to know anything new, and the SOAP server will get what it needs. There are products on the market that emulate mainframe terminals to get the interaction we desire.

An example of a SOAP request document is shown in Figure 74, SOAP Request Document.

The first thing we notice about this document is the first line. This document is an HTTP POST package. This is the type of document that your Web browser creates whenever you hit the "Submit" button on an HTML form. If you have seen HTML code, you might have seen the FORM element: <FORM METHOD="POST"... >. This is the same POST that is in the example above.

The POST method is nice, because it allows an arbitrary structure of data to be sent over the existing HTTP infrastructure. When your Web browser creates one of these packages, the body consists of a collection of information from the form, consisting of each field's name, an equal sign (=), and the value you typed in the field. Instead of shipping that information, SOAP has re-tasked the HTTP POST document to ship an arbitrary XML document. That XML document is subject to all of the well-formedness constraints of any XML document.

Why use HTTP? There are several reasons. The most important is that the HTTP infrastructure already exists. There are Web servers in every organization already, and HTTP has already proven to work well across networks. The second reason is that it uses the standard HTTP port of any TCP connection, port 80. This port is wide open in most organizations, because organizations want their employees to be able to access resources on the Web.

Put these together, and you get a compelling reason why SOAP should use HTTP.

This document is sent from the SOAP client to the SOAP server, where the SOAP server must parse it out and find the appropriate elements (listen to German). Then, the SOAP server must tell the object, in its language, what to do (speak French). When the object speaks back (listen to French), the SOAP server must translate that and return the results to the SOAP client (speak German).

If the object is a COM object that has been instantiated and a method invoked, it might set a series of properties, which the SOAP server can interrogate. If the object is a COBOL program, as described above, it might return a screenful of data to our terminal emulator object. When this screenful of data comes back, the SOAP server must parse the screen much like a human does, and find the data that is desired.

However it gets the information from the object, it is the SOAP server's job, then, to encapsulate this information into a thing called a SOAP response document and send it back to the SOAP client, as shown in Figure 75, SOAP Response.

A SOAP response document is shown in Figure 76, SOAP Response Document.

Notice that the SOAP response document is also an HTTP document. In this case, it is the same type of document that anyWeb server would send to your browser. The first line indicates the version of HTTP (SOAP only works with HTTP 1.1 and above), followed by the success code. In this case, 200 is OK. This is the same code that yourWeb browser gets. For example, 404 is file not found, 500 indicates a server error, etc. The HTTP body contains the XML document that the SOAP server created in response to the information provided by the object.

Now it is the job of the SOAP client to do something useful with the information in the XML response document.

That's about it for SOAP. This is a very simple example, but SOAP is a pretty simple protocol. It's a simple, object-access protocol.

Message Transport

Let's forget about doing remote procedure calls using SOAP for a minute, and look at another opportunity for automation.

Businesses need to get messages between themselves and their trading partners (customers and vendors) every day. Over the past two hundred years or so, an infrastructure has been built to handle such messages. Let's take a look at it.

If we want to send an invoice to you, all we need to do is render the appropriate information on a piece of paper, fold it, and put it in an envelope. This complex process is illustrated in Figure 77, Envelope and Paper, if you have never seen it before.

This process looks pretty simple, but let's take a look at what is actually happening. An envelope is a general-purpose carrier for documents. It can be used as a somewhat secure transport device for moving physical objects. An envelope does this because there are two distinct, special-purpose areas.

First, there is the inside of the envelope. This is where your payload goes. This payload can be an invoice, as shown above. Or it can be a picture, a love letter, or anything else that falls within certain size and weight guidelines.

Second, there is the front of the envelope, shown in Figure 78, Paper Envelope.

While the inside of an envelope is a general-purpose and largely free-form place, the front of the envelope must adhere to a specific structure in order for the envelope to get where it needs to go. It must have the destination address in the center and the return address in the upper left hand corner. A sufficient amount of postage is required, based on the origin and destination locations. If a postal worker encounters an envelope that does not have the required pieces, the envelope is likely to end up in the "undeliverable" bin, or marked "return to sender".

In order for us to do business, all you need to say is "Send an invoice to our address", and we know how to make that happen.

Imagine, now, if such a system did not exist. What if every time we wanted to do business, we had to invent paper.We also would need to create this envelope in a way that was acceptable to both parties and the transport intermediary. Speaking of the transport, we would also need to set up a worldwide postal service to get this document from one location to another.

Finally, we would need to specify the entire transaction in sufficient detail for all parties to do their part.

Fortunately, we do not need to do all of that, because standards have been developed over the years in various areas:

Paper is standardized. In the U.S., we use 8 1/2 x 11 inch paper, and paper mills all around the world supply this to us for our use. Most of the rest of the world uses A5 paper for the same purpose.
Envelopes are standardized. In the U.S., we use a #10 envelope to send an 8½ x 11 paper. The rest of the world uses a C5 envelope to do the same thing.
The postal system works worldwide with standardized addressing. Treaties have been put in place between countries to make sure that mail gets to where it needs to go.

The entire system leverages existing technology. The postal service did not invent roads or trucks. Rather, it uses those innovations in order to achieve its goals.

Now, let's replace paper with some electronic form. The 200-year history of the worldwide postal service is no good to us.We cannot leverage the standards and infrastructure that exists, because they are based on the physical world, and our problem is digital.

So, we need to do everything by hand. We need to specify the transport protocol.

Are we going to use something that exists, like HTTP or SMTP, or will we come up with our own protocol?We need to indicate the header, body, and trailer information to make sure our packages get to where they need to go over that transport protocol.

We need to write serializers that create the electronic documents and parsers that decompose them in to the information we need for our downstream processes.

Some efforts have been made to standardize these things in the electronic realm. Telephone call centers have been set up to allow an organization to order by phone from person to person. These work, because they can replace paper, but they are very expensive to set up and maintain, because they involve humans. Also, humans make mistakes and are slow.

The fax machine provides a great way to get paper from one place to the other, but that's really all it is. It does not replace paper with a more useful form, it just gets it there faster.

The Electronic Data Interchange standard (EDI) is useful as a paper replacement for many common business documents, but it is expensive and cumbersome to install and maintain, and still needs human interaction when something goes wrong³.

The best electronic solutions are based on those that have been proven to work well in the physical realm. Telephones work by allowing people to talk and listen as they always have, except that they are now farther apart. Faxes are probably the most successful computer equipment made, because they do not require complicated setup and maintenance. Just put the paper in the machine, key in a number, and paper comes out somewhere else in the world.

To automate the paper and envelope, then, the best place to start looking for ideas is the paper and envelope itself. What makes it so successful? What are the components that allow universal delivery? How can we create a transport and routing system as efficient as the one used to transport envelope-encrusted paper around the world?

We need some kind of standardized electronic envelope. This envelope should be something that all parties agree on, because all parties will be using it. It must be extensible because it will be used in a variety of ways for a variety of purposes. It must be easy to transport, because we do not want the transport protocol to get in the way of the message. And, it should leverage existing infrastructure, because creating a new infrastructure would be very expensive.

Let's use SOAP! Even though SOAP was designed for a slightly different purpose, it exists, and can be used to transport messages just as easily as it makes remote procedure calls.

The Two Personalities of SOAP

As we have already seen, SOAP provides a simple methodology for getting some procedure call package over HTTP to a destination. SOAP was originally designed to provide this functionality, and its name reflects that.

However, we think that SOAP has two distinct personalities. Both of these personalities use the exact same specification and the same methodology for getting a payload from one location to another. However, you should understand these two personalities of SOAP, because how you handle the SOAP documents may vary widely.

The two personalities are:

SOAP for RPC
SOAP for Messaging

Using SOAP for RPC, the SOAP envelope encapsulates a request in a standard way that is interpreted the same by all parties. Figure 79, SOAP for RPC shows the SOAP for RPC personality.

Using SOAP for RPC, the payload inside of the SOAP document is usually short, and the response is immediate. This is called "synchronous". The suggestion is that "I need a piece of information from you now, and I will wait until you give it to me".

SOAP for messaging, on the other hand, emulates the physical envelope-and-paper metaphor described above. A SOAP message will contain a complete document, encapsulated by the SOAP envelope structure and shipped over a reliable protocol.

SOAP for messaging usually requires more handshaking, because the results might not come back right away. In this way, SOAP for messaging is usually asynchronous. The suggestion here is, "Here is a purchase order. Let me know if you received it, and tell me in the next couple days if you can deliver the goods". See Figure 80, SOAP for Messaging (Initial request).

In this case, a purchase order is sent from an organization to one of its suppliers. The customer has requested that they receive some kind of confirmation a the physical layer. That is, that the packet was received. This is usually called a "delivery receipt". We discuss receipts in Chapter 10, Web Service Frameworks on page 219. The supplier responds back right away with a confirmation that the order was received. This confirmation is immediate, and appears as though it is synchronous, but it does not need to be.

In this case, the transaction is not complete, because the customer is expecting a "confirmation receipt", which means that the vendor has determined whether or not the request inside the original message can be fulfilled. This is shown in Figure 81, SOAP for Messaging (Follow up confirmation).

In this case, the confirmation states that the goods can be delivered by the dates they are required.

All of this interaction is carefully orchestrated to emulate what we know already works. This orchestration is not the job of SOAP itself, but of whatever framework we are using. A frameworks is a set of standards, protocols, and specifications that work together to achieve a particular task. You can learn more about these frameworks in Chapter 10, Web Service Frameworks on page 219 and Chapter 11, Turning a Protocol Into a Framework on page 251.

SOAP for Messaging (Follow up confirmation)

Why Do We Care About SOAP?

Six reasons why SOAP is an important protocol:

SOAP‘s beauty comes from its industry support. The software and hardware industry adopted SOAP protocol quickly and started developing applications with it.
SOAP is good because all the big players say it is good. Agreement means interoperability.
SOAP ensures the standardized message structure that is built on XML syntax. XML is cheap and so is SOAP. An organization does not need to spend millions of dollars to exchange SOAP messages.
Almost all of the SOAP implementations are free. These SOAP implementations parse and serialize a structured SOAP message according to the SOAP specification, which is a product of W3C.
As the SOAP specification is extended, the SOAP implementation will extend in the same manner, including such things as error handling mechanisms, security, reliability, routing, versioning, and all the other properties that will turn SOAP into a framework. This is discussed in Chapter 11, Turning a Protocol Into a Framework on page 251.
SOAP is just the envelope that delivers a message. The structure of the message in the SOAP body is open and extensible, but it must be in XML syntax. Users can create any language on XML syntax as they want, such as purchase order language, acknowledgment language, inventory request language, schedule change language, etc. And translation between requestors' and the respondents' language is easily accomplished by using XSLT.

SOAP in Real Life

In a typical transaction, many different internal and external systems are required. In this section, we will follow a transaction that involves three trading partners, each of which has a unique set of internal systems that all need to interoperate to achieve the desired result.

The three companies are:

Big Yellow Monster Corporation - A company that creates and maintains a fleet of monster trucks and participates in testosterone-rich automobile events, mostly in the Southern U.S.
Monster Supply, Inc. - A distributor of parts for the large truck industry.
Tires Tires Tires - A manufacturer of tires of all sizes for markets ranging from commercial vehicles to tractors to airplanes.

These three companies have been doing business with each other for a while, and have established relationships. Let's take a look at the internal systems architecture of each company.

Big Yellow Monster Corporation

Big Yellow Monster's systems are based on the Microsoft platform. They use Great Plains software as their accounting, inventory, and enterprise resource planning (ERP) systems. Internally, they use Microsoft servers to manage their intranet. See Figure 82, Big Yellow Monster Corporation.

Big Yellow Monster uses Microsoft CommerceServer 2000 to manage the procurement of direct and indirect goods. Direct goods are those that directly go into a product for sale or use. Indirect goods are everything else, such as paper clips and promotional hats that read "Say Hello to Big Yellow!".

Recently, they installed Microsoft's BizTalk Server 2002 to integrate internal systems and provide a way to talk to their external partners electronically. BizTalk Server provides automated workflow and integration (Microsoft calls this "Orchestration"), allowing Big Yellow Monster to integrate all of their internal systems and external trading partners.

Monster Supply, Inc.

Monster Supply, Inc. runs on several different platforms. They are mostly a Unix shop, with most Enterprise application written in Java's J2EE suite. They use SAP R/3 to manage their enterprise resources and provide a front end for their accounting system. See Figure 83, Monster Supply, Inc.

Recently, Monster Supply acquired a company and inherited a warehouse full of parts and a robust inventory management system. The inventory management system was uncanny in its ability to maintain the proper ratio of parts in stock to keep inventory moving. That was the good part.

The bad part is that the system was written in 1983 in RPG and runs on an IBM System/38 departmental mainframe. The system is so reliable that Monster Supply has kept the program and the hardware running.

In order to integrate the SAP system and the RPG programs, they installed webMethods Business Integration suite. webMethods uses XML-based proprietary technology to help systems work with each other.

Tires Tires Tires

Tires Tires Tires has been building tires for decades. They are a traditional "brick-and mortar" manufacturing company. They have a production management system that is based on proprietary systems that have been built over the years by internal I.T. staff. See Figure 84, Tires Tires Tires.

The production management system links into their production measurement and control systems by reading sensors on various manufacturing equipment. Like Monster Supply's inventory system, they work well, and keep the production running smoothly.

Their sales have traditionally been done by telephone and mail, but in 1981 they installed an electronic data interchange (EDI) system because their customers, also large brick-and mortar companies like auto and airframe manufacturers, would only do business electronically.

In order to receive EDI transactions, Tires Tires Tires installed GenTran by Sterling Commerce. They integrated this package into their production management systems. EDI transactions coming over the EDI value added network (VAN), which is expensive and difficult to maintain.

Recently, they installed BEA‘s WebLogic Server to act as a secure, reliable interface to the Internet. WebLogic feeds data to the existing GenTran system. This allowed Tires Tires Tires to eliminate their dependence on the VAN without re engineering their in house EDI implementation.

Transaction Scenario

For this scenario, we will be using the graphics shown in Figure 85, Scenario Legend.

This scenario starts with Big Yellow Monster needing some spare tires for an upcoming event.

Big Yellow Monster has purchasing agreements with several suppliers. These agreements stipulate everything from how items are priced to how payment is to be authorized and submitted. As these agreements are made and modified, the I.T. staff loads the information into their CommerceServer application.

Order Parts

A clerk sits down at aWeb browser and accesses the corporate intranet page for ordering supplies. This site was written by internal programmers to make it easier for authorized staff to place orders. The clerk selects the item and the quantity, 10 tires. See Figure 86, Big Yellow Needs Tires.

The ordering page is actually an application of Big Yellow Monster's CommerceServer installation. Since CommerceServer keeps track of all vendors the company does business with, it knows which are preferred for supplying each part. It knows that, for this particular part, Monster Supply has the best prices and delivery times.

In order to do business with Monster Supply, a purchase order must be generated. That is the job of the Great Plains accounting system. Big Yellow Monster uses Microsoft's BizTalk Server as an automated workflow and integration toolkit.

Buyer Orchestration

BizTalk Server is really just a suite of tools that can be used for system to-system integration and external trading partner management. In our scenario, CommerceServer invokes the orchestration API of BizTalk server. This starts in motion a series of events that will help to complete the transaction.

First, BizTalk Server needs to have Great Plains issue a purchase order for the parts. This integration is done with SOAP. BizTalk Server speaks SOAP natively, but Great Plains does not. However, the Big Yellow Monster I.T. department recently exposed their Great Plains functionality as a SOAP implementation. For more information on SOAP implementations, and to see why we use the graphics we do, see SOAP in Application-to-Application Integration on page 204.

The BizTalk Server sends a SOAP message to Great Plains, which invokes its own workflow for creating a purchase order. The details of this process are part of the Great Plains implementation. It is important to note that the automated process we are describing here does not change the way Great Plains has been doing this for years. Only now, we are automating the request. See Figure 87, BizTalk Speaks SOAP. Once the accounting system processes the purchase order, it sends the information back, via its SOAP implementation, to the BizTalk Server.

Now the BizTalk Server executes the next part of its orchestration. It sends a SOAP message over the Internet inside of an HTTP POST document. The details of this type of message are described in the previous sections.

Send to Distributor

The web services server at Monster Supply sends the message to the webMethods server, which reads the message and knows what to do. Monster Supply is depicted in Figure 88, Monster Supply Supplies Tires.

This type of message needs to be processed by the SAP enterprise resource planning system to fulfill the order. SAP has the workflow to process the request. The webMethods implementation's job is to get the message to SAP. SAP does not natively support SOAP, so a SOAP implementation has been wrapped around certain functions. The webMethods system creates a SOAP request document and sends it to SAP over the internal network.

Vendor Workflow

When SAP receives this document, its workflow starts. It has received an order for ten tires. SAP keeps trading partner agreements in its system. It needs to treat each trading partner according to the agreements that they have between each party. For Big Yellow Monster, the agreement says that Monster Supply must send an acknowledgment that it has received a purchase order. It must do this within five minutes of when the document was sent. Much of this functionality is taken care of by using a SOAP extension called "WS-ReliableMessaging". See Chapter 11, Turning a Protocol Into a Framework on page 251 for more information on SOAP extensions.

After sending the acknowledgment, the SAP system needs to check to see if there are enough tires in stock to fulfill the order. This is the domain of the mainframe programs that manage the inventory.

Unfortunately, the mainframe systems do not speak the language that SAP speaks, and SAP cannot communicate with the mainframe systems directly. In another era of direct application-to-application integration, I.T. architects at Monster Supply would have had to write complex interfaces to get the two systems speaking one language or another. These interfaces might have required that the code for the two systems be modified so they could communicate, or they could require complex bridges and translations.

Now, it is easier to wrap certain functionality with a SOAP implementation that exposes the required operations to internal applications so integration becomes message- based and loosely coupled.

Inventory Integration

Now, the SAP system sends a message to the SOAP implementation on the mainframe inventory control system, "How many tires do we have in stock". This runs a program on the mainframe, which checks its databases and recent transactions that might indicate new items have been received awaiting storage. See Figure 89, Accessing the Mainframe.

The answer comes back immediately, "Six".

Now the SAP system needs to do some complex math. It has an order for ten, and it has six in stock. How many does it need to order from the manufacturer?

a) 4
b) 0
c) 42
d) None of the above
e) All of the above

The answer seems like a) 4, because that's the shortage. However, if the answer were as easy as subtracting two small integers, they would not have needed to spend four million dollars on the SAP installation.

Instead, SAP‘s job is not just to subtract numbers, but to be a central part of the planning of enterprise resources. It keeps in its database information about each item and about each customer. In this case, the answer is d) None of the above. SAP has determined that this particular tire is very popular with several customers who usually need it right away. If the item is not in stock, these customers will buy it elsewhere. So the rule for this tire is that three must be in stock at all times for these customers.

Now that we have that information, we can calculate how many need to be ordered from the manufacturer to fulfill this order from Big Yellow Monster. The answer is seven.

Manufacturer Workflow

The vendor for this product is Tires Tires Tires. They are illustrated in Figure 90, SOAP Document to Manufacturer.

webMethods composes a SOAP document and sends it over the Internet to the manufacturer. The WebLogic server speaks SOAP natively, so when the WebLogic server was installed, a SOAP implementation was wrapped around the GenTran system so it could speak to the WebLogic server.

TheWebLogic server receives this as a SOAP document. It recognizes it as a purchase order request and sends it to the GenTran system as a SOAP message over an internal network. See Figure 91, Internal SOAP Implementation.

The GenTran system has been processing purchase orders for years, and knows how to interface with the in-house production management system. It gets an answer from the production system as an estimate of the time the products will be delivered. GenTran sends a SOAP response document to WebLogic, which sends a SOAP response to webMethods, which sends a SOAP response document to SAP. See Figure 92, Internal SOAP Implementation.

The tires will be shipped next Tuesday. Because SAP has the trading partner profile, it knows it needs to send a document back to Big Yellow Monster when it finds out when the goods can be shipped. This is called an "Advance Shipment Notice"(ASN).

Now SAP has everything it needs to be able to send the ASN. It sends a SOAP message to the webMethods server, which manages the connection to Big Yellow Monster. webMethods creates a SOAP document that it sends over the Internet to the BizTalk Server at Big Yellow Monster. See Figure 93, Advance Shipment Notice. The response is, "We will send three tires today and seven more next Wednesday." BizTalk Server responds with a SOAP response message saying the message was received without error.

The BizTalk server sends a SOAP message to Great Plains so it can update its status. It also instantiates a COM object and invokes a method updating the status of the order in CommerceServer. See Figure 94, Updating Internal Systems.

Summary

This scenario involved many different players and many different technologies and platforms. It seems a bit contrived, but this is the future of web services as we see it.

We see vendors supporting web services for both the integration of internal systems and managing external partners over any type of network. The companies mentioned here already support SOAP and web services in their products.

¹ There are not a lot of COBOL programmers left. It seems like they are all retired and living in Florida on their Y2K consulting income.

²The 3278 version had multiple shades of green for highlighting. Then there was a breakthrough: the 3279 terminal, which also had red and blue! These terminals cost as much as your house.

³Which is far more often than many would like.