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.
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 difficult1. 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 grid2.
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 wrong3.
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.
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.
1 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.
2The 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.
