Network Deployment (Distributed operating systems), v8.0 > Applications > Web services > WS-ReliableMessaging > Use patterns for WS-ReliableMessaging
Assured delivery for B2B web services: point-to-point use pattern
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 WAS 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 WAS.
The manufacturer implements requests for update in two different ways:
- Use 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 WAS 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 WAS 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:
- Use 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.
- Use SOAP over JMS:
- Although requiring the use of WAS 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.
- Although requiring the use of WAS 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 WAS, 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.
Assured delivery for B2B web services: hub-and-spoke use pattern
Interoperation with other WS-ReliableMessaging providers: use pattern
Use patterns for WS-ReliableMessaging
WS-ReliableMessaging
Add assured delivery to web services through WS-ReliableMessaging
Detecting and fixing problems with WS-ReliableMessaging
Concept topic