In this use pattern, a manufacturer sells its products through
a network of affiliated dealerships. This manufacturer has initiated a pilot
project to improve the IT integration between its own retail organization
and half a dozen of the largest, most important dealerships.
The existing technical solution
Historically, business-to-business
"e-commerce" has been conducted using Electronic Data Interchange (EDI). EDI
is a set of standards for the content and formatting of business-to-business
messages. For examples of these standards and messages, see the United
Nations Directories for Electronic Data Interchange.
If the identities
of communication partners are known and unchanging, the use of industry standard
message definitions is not strictly necessary. Although other XML-based standards
are available for conducting business-to-business e-commerce (such as the
OASIS Electronic
Business using eXtensible Markup Language (ebXML) specifications) the
manufacturer has decided to investigate the use of Web services technologies,
and is using WSDL documents from a variety of sources to define the service
interfaces.
The interactions between the manufacturer and its dealers
for the initial pilot project fall into two categories:
- Requests for information. The interaction is two-way, in that a request
message is sent requesting some information, and a reply message is sent in
the reverse direction containing the requested information. An example of
a request for information going from a dealer to the manufacturer might be
"getOrderStatus".
- Requests for update. These interactions are one-way, in that the sender
of a request for update is not dependent on receiving a response in order
to proceed with other work. An example of a request for update going from
dealer to manufacturer might be "placeOrder". An example of a request for
update going from manufacturer to dealer might be "deliveryConfirmed".
The manufacturer uses WebSphere Application Server to implement requests
for information using SOAP over HTTP and SOAP over JMS. Dealers are free to
choose their own implementation technology; they do not have to use WebSphere
Application Server.
The manufacturer implements requests for update
in two different ways:
- Using SOAP over HTTP. In this case the service is represented as a request
and reply interaction that is considered to have succeeded when the requestor
successfully receives a reply. The services have to be implemented to detect
and successfully respond to duplicate requests (this is termed an idempotent
operation), and the client has to be implemented to try again if the communication
is interrupted after the request has been sent but before the reply has been
received.
- To avoid the above limitations, the manufacturer also uses SOAP over JMS
support from WebSphere Application Server and WebSphere MQ. In this case the
request is represented as a one-way service, and the messages are delivered
reliably. The manufacturer uses WebSphere MQ as the JMS Provider, and makes
this solution available to all dealers that also use WebSphere Application
Server and WebSphere MQ. It is not required that the dealer and manufacturer
be connected in order for the message to be sent.
The messages are transmitted over Virtual Private Networks, to ensure
the integrity and confidentiality of messages transmitted between the two
businesses, and as a part of establishing the identity of the sender.
The business problem
Although both the manufacturer
and its dealers are happy with the implementation of the request for information
services, there are a number of issues in the request for update case:
- Using SOAP over HTTP:
- For the manufacturer, implementing idempotent services is complicated
and therefore more expensive in developer time. It increases the likelihood
of coding errors, reducing the robustness of the solution and introducing
the possibility of expensive dropped or duplicated orders.
- For dealers, implementing the retry logic is similarly complex, expensive,
and error-prone.
- For both the manufacturer and the dealers, the requirement for both to
be available in order to invoke the service is an issue. In particular, many
dealers do not maintain seven-day availability of their systems, whereas for
the manufacturer weekends are the ideal time to deliver price updates to the
dealers. Similarly, being unable to place orders when connectivity between
dealer and manufacturer is unavailable is a real business issue.
- Using SOAP over JMS:
- Although requiring the use of WebSphere Application Server and WebSphere
MQ is acceptable to the current collection of dealers, as the project expands
there might be other partners who are unwilling or unable to use a common
software platform.
The solution using WS-ReliableMessaging
With WS-ReliableMessaging
support in WebSphere Application Server, the manufacturer can replace their
existing custom-retry solutions for reliable one-way messaging with standard
SOAP over HTTP one-way messaging. The removal of the retry logic from the
application simplifies the application code, enabling simpler and quicker
application development.
With WS-ReliableMessaging, the dealer and
manufacturer do not need to be connected in order for the message to be sent.
The
WS-ReliableMessaging standard adds reliability to SOAP over HTTP
messaging, reducing the need to use SOAP over JMS.
Because WS-ReliableMessaging
with SOAP over HTTP is an interoperable standard, the network of dealers need
not use a common software platform.