- The Basics of Web Services
- A Simple Example: Searching for Information
- The Next Generation of the Web
- Interacting with Web Services
- The Technology of Web Services
- XML for Business Collaboration: ebXML
- Web Services versus Other Technologies
- Additional Technologies
- Vendor Approaches to Web Services
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Interacting with Web Services
The level of abstraction at which Web services operate encompasses such interaction styles as RPC (remote procedure call) emulation, asynchronous messaging, one-way messaging, broadcast, and publish/subscribe. Most major database management systems, such as Oracle, SQL Server, and DB2, support XML parsing and transformation services, allowing direct interaction between Web services and database management systems. Middleware vendors typically also provide a mapping of Web services to their software systems, such as application servers and integration brokers. To the user, therefore, interactions with Web services can appear as batch or online interactions, supporting synchronous or asynchronous communications patterns, and as user interfaces written using Java programs, VB (Visual Basic) programs, office applications, browsers, or thick clients to database management systems, to name a few, and can map down to any type of underlying software system.
Web services standards and technologies generally encompass two major types of application interaction patterns:
Remote procedure call (online)
Document oriented (batch)
These two types of interactions are described in the following subsections.
RPC-Oriented Interactions
In RPC-oriented interaction, the Web service request takes the form of a method or a procedure call with associated input and output parameters. In contrast to the document-oriented interaction, the RPC-oriented interaction sends a document formatted specifically to be mapped to a single logical2 program or database, as shown in Figure 1-4. Because the "real-time" or in-season order for skateboots depends on available inventory, for example, the program accesses the database to check the available supply of the ordered item. If everything is OK, the program returns an XML document to the distributor in the request/response format to indicate that the order has been accepted and will be shipped. If supply isn't available, the return message indicates a back order or rejects the order entirely. In contrast to the document-oriented interaction style, the request and the reply are modeled as synchronous messages. That is, the application sending the message waits for a response.
)
Figure 1-4 This Web service supports an interactive order request/response.
Document-Oriented Interactions
In the document-oriented interaction style, the Web service request takes the form of a complete XML document that is intended to be processed whole. For example, a Web service that submits a complete purchase order, such as a preseason order for skateboots, would submit the entire bulk order to the manufacturer at once, as shown in Figure 1-5. This is like submitting a message to a queue for asynchronous processing. The manufacturer would typically send an e-mail or other form of acknowledgment to the retailer to indicate that the order was received and would be processed according to a predefined flow of execution. The flow might include such steps as checking the database for previous orders from the same retailer to ensure that it is not exceeding its credit limit or agreed capacity or scheduling a ship date for the order. In a real process flow, of course, many more steps are likely before the order is shipped and the invoice sent out, but the example shows only the final step: sending the XML invoice to the distributor for payment after the order has been shipped and received.
)
Figure 1-5 This Web service processes a complete purchase order.
Document-oriented interactions often assume that the parties to a Web services conversation have agreed to share a common business document, such as a purchase order, a ship bill, or an invoice. These parties are often identified as trading partners, or collaborating partners. Trading partners also typically agree on a common process flow, or interaction pattern, for exchanging the shared document, such as requiring an acknowledgment on receipt of a purchase order, returning specific status information in reply to an order query, or sending an e-mail alert when an order has been shipped. During the execution of the business process, a complete document might be exchanged. If the document is already held in common, fragments of information required to fill in specific sections of the shared document, such as purchase price or promised delivery date, might be exchanged.
In the Skateboots Company example, preseason bulk orders are handled by using purchase orders submitted in batches according to predefined terms and conditions that help the manufacturer plan capacity. During the season, immediate restocking orders are handled by more interactive services that depend on filling orders from available inventory and that can immediately identify back orders. Thus Skateboots.com provides Web services supporting both major types of interaction.