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 by 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 by 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 must
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 when 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 have 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.