An engineer needs to purchase widgets for a project, finds the SmallCo offering in a catalog and initiates the purchase.

A typical transaction looks like this:

There are lots of other messages that might be sent in a purchasing scenario. This is just sort of a bare-bones illustrative example.

The messages that go from BigCo to SmallCo are generated automatically by the software systems in BigCo. SmallCo, on the other hand, is using a shareware web services module that implements the web services necessary for these commercial transactions in a generic way but knows nothing about the industry-specific business protocols involved.

Failure of the process at each step triggers appropriate actions, often involving flagging the transaction for attention by a person in the purchasing department of BigCo or raising an error condition in the web service facility of SmallCo.

The basic transactions take place via Asynchronous Messaging. However, each of the steps of this process must also be reliable. That is, there is a process in place by which when a message is sent the sender knows that it will either get through or create an error condition, and that there is a high probability of it getting through. Each message generates a confirmation of receipt message back to the sender, that is, Request with Acknowledgement. In addition, each message carries a unique identifier, a date-time stamp (showing the time at which the message was sent, not necessarily the delivery time), and information that allows the messages to be logically ordered. (These capabilities will be exercised in subsequent scenarios). The identification requirements may be part of Conversational Message Exchange, although this Usage Scenario has not yet included these capabilities explicitly.

We are requiring here that the messages be ordered but not sequenced, even though many of the VAN's on which this usage case is based do offer sequencing. Sequencing would imply that each message between two partners in a given direction has a sequential index and that no gaps are allowed. One could then, if desired, set up a process in which sequential receipt were enforced. That is, if BigCo gets message 22 from SmallCo and then receives message 24, BigCo would not accept message 24 (presumably holding it in some sort of buffer) until message 23 arrived, and probably would throw some sort of error if it did not arrive in some time period. We are not including this type of operation in the usage case because we feel that it is fairly unusual actually to make use of this logic. Moreover, if desired such sequencing could be made part of the payload and included in the business logic. The only reason we can think of to include sequencing in the enveloping mechanism would be to enforce sequencing across different types of business transaction, and we don't think that this is likely to be very useful. Would you want to hold up an invoice, for example, because a message involving HR had not arrived yet?

The usual security suspects (Accessibility, Authentication, Authorization, Confidentiality, Integrity and non-Repudiation) are all matters of concern. Non-Repudiation is of particular importance, although in practical terms less in terms of a legal process than simply the ability to say, "You got this invoice on March 24, and here is your signed confirmation of receipt". That is, by far the most common scenarios that require non-repudiation involve people in both companies trying, in good faith, to sort out what has gone wrong in some screwed up transaction. What is required in these cases is an unambiguous record, not rock-solid legal proof. Taking these issues to court is a very rare occurrence given an ongoing trading relationship between businesses. This is probably a less strong requirement than what is usually called "non-repudiation", but stronger than "auditing". Perhaps we can call this requirement "reconciliation". Various aspects of Reconciliation will be exercised in the use cases below.

Other aspects of security are also necessary. It must be possible for both BigCo and SmallCo to be sure that the messages they receive are actually from the company that they are supposed to be. That is, each company must be able to identify itself unambiguously (Authentication). In addition, there is the question of what actions the company is authorized to request from the web service. For example, BigCo needs to be able to query SmallCo's web service for a list of messages that have been sent between these two participants, but not for information about transactions with other companies that purchase widgets from SmallCo. Both companies need to be confident that the communications cannot be tampered with or observed by third parties, and that third parties cannot send communications pretending to be who they are not.

The SmallCo web service knows how to receive and send messages and will present these messages to users at SmallCo in a browser window. A SmallCo employee transfers information from the XML to their bookkeeping system via cut and paste. How does SmallCo generate the XML that goes into the messages that it sends? The web service knows how to generate the envelop (message ID, datetime, and so on), but not the message contents. To assist SmallCo's either BigCo or the industry standards body provides a web site that implements messages like "quote" and "invoice" in a web form into which a SmallCo person types information and which returns suitably formatted XML in the browser window.

BigCo has instituted an automated reconciliation procedure to check on a monthly basis that messages have not been lost by comparing transaction logs from BigCo and SmallCo. In this scenario a discrepancy is found and addressed.

Somebody from BigCo calls up SmallCo, apologizes, and explains why they have not been responding in a timely manner.

Reconciliation: the SmallCo web service must be able to respond to (authorized) requests for information about what messages have been received and/or sent in a time period or between marker messages. The web service must be capable of resending messages on request.

SmallCo thinks that it has not been paid because they did not get the payment advice. Well, they got it but didn't put it into their records so they think that they have not been paid. However, the payment was really made through the bank into their account. The objective here is to clean up the mess so everyone agrees what has happened.

SmallCo calls BigCo and says, "Oops. Looks OK now."

Reconciliation: the key here is to be able to retrieve messages by ID. The linkage of the messages into a transaction is beyond the scope of the web service itself and belongs in the definition of the business process.

SmallCo sent an invoice and this time they really didn't get paid. After a while they call BigCo as in the previous scenario. The objective here is to get SmallCo paid.

BigCo calls SmallCo and says, "Oops, sorry. My bad. The check is in the mail."

The requirements are really the same as for the last scenario. We just wanted to illustrate that there are all sorts of ways the business process can get screwed up, no matter what technical processes are in place, and that the fault may lie on either side of the transaction.