Home | Business News | Browse by Publication | X | XML Journal

Building a real-world Web service--part 4: the extended e-business scenario.

Article Excerpt
It's time for Web services to prove their worth. They've gained enough attention for people to stop and notice, to wait and expect, to speculate and argue ... now it's time to show people what the fuss is all about.

If the show fails to impress, Web services will slowly fizzle out like their predecessors. To make Web services succeed, the Web services community needs to choose winners from the competing Web services standards, vendors need to present a coherent message, and the community needs to keep stressing the true value of Web services: enabling e-business dialogue between business partners. This series of articles is focused on creating robust e-business dialogues using a mix of Web services standards and RosettaNet.

In Part 3 of the series, I showed you the components and tools necessary to construct and conduct the e-business dialogue, and how to install them. I constructed the public side of the e-business dialogue by building 6 of the 13 components necessary for the extended e-business scenario. In this article, I will show you how to build the private side of the process, thus completing the implementation of the extended e-business scenario. In this article I will also discuss the challenges of creating real e-business dialogues with Web services.

The Extended E-Business Scenario

The extended e-business scenario that we are building in this series is illustrated in Figure 1. To recap, the extended e-business scenario works as follows: after a particularly successful day of selling laptops, the Inventory Manager application at ACME realizes the inventories are running low, and it triggers the ACME PO requester process. The requester process then begins a public e-business dialogue with Laptops, Inc., placing a purchase order request.

[FIGURE 1 OMITTED]

Laptops, Inc., receives the purchase order request from ACME and immediately sends back a message acknowledging receipt of the request. The PO requester process at ACME receives the receipt acknowledgment and informs the Inventory Manager that the purchase order has been placed. The Inventory Manager returns to other activities and the PO requester ends the request process. Meanwhile at Laptops, Inc., the place PO process invokes the Sales Agent, an internal Web service, and passes ACME's purchase order request to the Sales Agent. The Sales Agent figures out which parts of the purchase order can be fulfilled and forms a purchase order confirmation that provides a detailed line-by-line account of the items it can provide. This confirmation is then passed from the Sales Agent back to the public place PO process at Laptops.

The process at Laptops then sends the purchase order confirmation to an ACME process that accepts purchase order confirmations. The ACME confirmation acceptance process invokes an internal Web service to inform the Accounts Service at ACME about the purchase. The ACME process next sends back a message acknowledging the receipt of the purchase order confirmation and concludes the purchase order e-business dialogue between ACME and Laptops, Inc. Laptops, Inc., receives this receipt acknowledgement and invokes an internal Web service to its shipping department so that the order can be shipped to ACME.

As you can see, there is a lot of activity taking place in this scenario. Before we get into the implementation end, it is important to explore how to create...

View this article FREE - Now for a Limited Time, try Goliath Business News
Free for 3 Days!