FW: Use Cases From XML Messaging

[David Burdett <david.burdett@commerceone.com>]

Sending this one again too ...

> -----Original Message-----
> From:	David Burdett 
> Sent:	Wednesday, February 16, 2000 9:57 AM
> To:	ebXML Transport (E-mail)
> Subject:	Use Cases From XML Messaging
> 
> Folks
> 
> The following are some use cases from XML Messaging. They've been taken
> straight from the XML Messaging Requirements spec with the page breaks
> removed
> 
> David
> 
> Advanced Technology, CommerceOne
> 1600 Riviera Ave, Suite 200, Walnut Creek, CA 94596, USA
> Tel: +1 (925) 941 4422 or +1 (650) 623 2888; 
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
> 
> 7.2 XML Messaging Examples
> 
> 
> 7.2.1 Simple Document Exchange
> 
>  At its simplest, a Transaction consists of just one Service that uses
>  just one Simple Document Exchange that consists of:
> 
>  o a Request Message sent from one party to a second party, and
> 
>  o the Response Message that is returned as a result.
> 
>  The figure below provides an example of what these messages could
>  contain and how they could be processed.
> 
>  Party 1
>      |  Party 2
> STEP |     |
>  1.          Party 1 generates the documents that need to be sent,
>              places them in an XML Message together with a Message
>              Header and (optional) digital signature and sends it to
>              the Party 2.
> 
>      1 --> 2 Request Message:
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 1)
>                - To (Party 2)
>                - Service Type
>                - Intent
>                - Authorization Data
>                - Message Manifest
>              o Message Routing Info
>              o Signature(s) (Optional)
>              o Document(s)
> 
>  2.          Party 2 that received the Request Message carries out the
>              following processes:
>              o checks the "To" data to check the Message intended for
>                them;
>              o checks the Service Type and Intent to make that they
>                can carry out the request;
>              o if required, checks the "From" data to make sure that
>                the sender is known
>              o checks the Authorization Data (if present) to make sure
>                the action is authorized (note some requests may not
>                need authorization);
>              o checks the Signature, if present, to make sure the data
>                has not changed and the sender can be identified, then
>              o if everything is OK, checks the Document(s) for errors,
>                then
>              o if no errors in the Document(s) then carries out the
>                requested action using the data contained in the
>                Document(s)
>              o once the action is complete, then generates a Response
>                Message and sends it back to Party 1.
> 
>      1 <-- 2 Response Message:
>              o Message Header:
>                - Message Type (Response)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 2)
>                - To (Party 1)
>                - Service Type
>                - Intent
>                - Message Manifest
>                - Status Data
>              o Message Routing Info
>              o Signature(s) (Optional);
>              o Document(s)
> 
>  3.          Party 1 that has received the Response Message then
>              carries out the following processes:
>              o Checks the Transaction Identity Data and Message
>                Identity Data to make sure the Response Message refers
>                to the Transaction/Request Message that they sent
>                earlier
>              o checks the Signature, if present, to make sure the data
>                has not changed and is the sender of the message can be
>                authenticated
>              o checks the Status Data to determine that the Service
>                was carried out by the anticipated Organization and
>                whether the service succeeded or failed
>              o if everything is OK, then checks the Document(s) for
>                Errors,
>              o if everything is still OK, then carries out whatever
>                processing of the Document(s) is necessary.
> 
>               Figure 2 Simple Document Exchange Message Flow
> 
> 
>  [Note]     In the above example the sequence of the processing by the
>             described for Party 1 or Party 2 is indicative of the
>             processing required. Sequences that provide the same result
>             are equally acceptable.
>  [Note End]
> 
> 
> 7.2.2 Simple Document Exchange with Errors
> 
>  In the previous example, it was assumed that no errors were found. If
>  errors are found then a slightly different message flow would occur.
>  The example below builds on the previous example in Figure 2 Simple
>  Document Exchange Message Flow.
> 
>  Party 1
>      |  Party 2
> STEP |     |
>  1.          Party 1 generates the documents that need to be sent,
>              places them in an XML Message together with a Message
>              Header and (optional) digital signature and sends it to
>              the Recipient.
> 
>      1 --> 2 Request Message:
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 1)
>                - To (Party 2)
>                - Service Type
>                - Intent
>                - Message Manifest
>              o Message Routing Info
>              o Signature(s) (Optional)
>              o Document(s)
> 
>  2.          Party 2 that receives the Request Message detects an error
>              and so sends an Error Message back to Party 1.
> 
>      1 <-- 2 Error Message:
>              o Message Header
>                - Message Type (Error)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 2)
>                - To (Party 1)
>                - Service Type
>                - Intent
>                - Message Manifest
>              o Message Routing Info
>              o Signature(s) (Optional)
>              o Document(s)
>                - Error Data
> 
>  3.          Party 1 that received the Error Message:
>              o Checks the Transaction Identity Data and Message
>                Identity Data to make sure the Message refers to the
>                Transaction/Request Message that they sent
>              o checks the Signature, if present, to make sure the data
>                has not changed
>              o determines that there was an Error and takes the
>                appropriate action.
> 
>           Figure 3 Document Exchange with Request Message Errors
> 
> 
>  Errors can also occur in a Response Message. In this case the Message
>  flow would be as below.
> 
>  Party 1
>      |  Party 2
> STEP |     |
>  1.          Party 1 generates the documents that need to be sent,
>              places them in an XML Message together with a Message
>              Header and (optional) digital signature and sends it to
>              Party 2.
> 
>      1 --> 2 Request Message:
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 1)
>                - To (Party 2)
>                - Service Type
>                - Intent
>                - Message Manifest
>              o Message Routing Info
>              o Signature(s) (Optional)
>              o Document(s)
> 
>  2.          Party 2 that receives the Request Message successfully
>              processes the Request Message and generates and sends a
>              Response Message back to Party 1.
> 
>      1 <-- 2 Response Message:
>              o Message Header:
>                - Message Type (Response)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 2)
>                - To (Party 1)
>                - Service Type
>                - Intent
>                - Message Manifest
>                - Status Data
>              o Message Routing Info
>              o Signature(s) (Optional);
>              o Document(s)
> 
>  3.          Party 1 that has received the Response Message identifies
>              an error in the some part of the Response Message and
>              therefore sends an Error Message back to the Sender of the
>              Response Message.
> 
>      1 --> 2 Error Message:
>              o Message Header
>                - Message Type (Error)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 1)
>                - To (Party 2)
>                - Service Type
>                - Intent (Error)
>                - Message Manifest
>              o Message Routing Info
>              o Signature(s) (Optional)
>              o Document(s) (Optional)
>                - Error Data
> 
>  4.          Party 2 that received the Error Message:
>              o Checks the Transaction Identity Data and Message
>                Identity Data to make sure the Message refers to a
>                Transaction/Request Message that they are aware of
>              o checks the Signature, if present, to make sure the data
>                has not changed
>              o determines that there was an Error in the Response
>                Message they had sent and takes the appropriate action.
> 
>          Figure 4 Document Exchange with Response Message Errors
> 
> 
> 
> 7.2.3 Canceling a Transaction
> 
>  Transaction cancellation occurs in a similar way to generating
>  errors. For example if a Recipient of a Request Message wants to
>  cancel a transaction they would do this as illustrated in the figure
>  below.
> 
>  Party 1
>      |  Party 2
> STEP |     |
>  1.          Party 1 generates the documents that need to be sent,
>              places them in an XML Message together with a Message
>              Header and (optional) digital signature and sends it to
>              Party 2.
> 
>      1 --> 2 Request Message:
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 1)
>                - To (Party 2)
>                - Service Type
>                - Intent
>                - Message Manifest
>              o Message Routing Info (Optional)
>              o Signature(s) (Optional)
>              o Document(s)
> 
>  2.          Party 2 that received the Request Message checks the
>              message but decides they want to cancel the Transaction
>              for some reason and so sends a Cancel Message back to the
>              Sender of the Request Message.
> 
>      1 <-- 2 Cancel Message:
>              o Message Header
>                - Message Type (Cancel)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Party 2)
>                - To (Party 1)
>                - Service Type
>                - Intent (Cancel)
>                - Message Manifest (Optional)
>                 o Message Routing Info (Optional)
>                 o Signature(s) (Optional)
>                 o Document(s) (Optional)
> 
> 
> 7.2.4 Transaction with Multiple Document Exchanges
> 
>  Transactions can also consist of multiple Document Exchanges as
>  illustrated in the following example that contains four Document
>  Exchanges that are part of three Services. The Services, the
>  associated Intent and the resultant Document Exchanges are as follows
> 
>  o Service: Supplier Order Processing
>    - Intent: Stock Availability Check
>        Document: Stock Availability Request
>        Document: Stock Availability Response
>    - Intent: New Purchase Order
>        Document: Purchase Order
>        Document: Invoice
>        Document: Payment Brand List
> 
>  o Service: Payment Service
>    - Intent: Make Payment
>        Document: Payment Request
>        Document: Payment Instrument
>        Document: Payment Response
> 
>  o Service: Delivery Goods
>    - Intent: Request Delivery
>        Document: Delivery Request
>        Document: Delivery Response
> 
>  Note that this example also illustrates how digital signatures can be
>  used to provide an Audit Trail and authorize the execution of each
>  Service.
> 
>  More details are provided below together with explanations on how
>  signatures are used to link each Document Exchange instance together.
> 
>  Buyer Supplier /
>      |  Payment Handler
> STEP |     |
>  1.          Buyer generates a Stock Availability Request, digitally
>              signs it, and sends it to the Supplier to check for
>              availability.
> 
>      B --> S Request Message (Stock Availability Request):
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Buyer)
>                - To (Supplier)
>                - Service Type (Supplier Order Processing)
>                - Intent (Stock Availability Check)
>                - Authorization Data:
>                    Buyer Data
>                    ref. to Signature1
>                - Message Manifest
>              o Message Routing Info
>              o Signatures
>                - Signature1, Signs:
>                    Message Header
>                    Stock Availability Request
>              o Documents
>                - Stock Availability Request
> 
>  2.          The Supplier checks the Stock Availability Request (see
>              example earlier for what is involved in checking a
>              request) and generates a Stock Availability Response to
>              send back to the Buyer. The response is digitally signed.
> 
>      B <-- S Response Message (Stock Availability Response):
>              o Message Header
>                - Message Type (Response)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Supplier)
>                - To (Buyer)
>                - Service Type (Supplier Order Processing)
>                - Intent (Stock Availability Check)
>                - Message Manifest
>                - Status Data (Stock Availability Check)
>              o Message Routing Info
>              o Signatures
>                - Signature2, Signs:
>                    Message Header
>                    Stock Availability Response
>                    Signature1 in Stock Availability Request Message
>              o Document
>                - Stock Availability Response
> 
>  3.          The Buyer checks the Stock Availability Response Message
>              and finds it OK. As a result generates a Purchase Order
>             Document and sends it to the Supplier. The Authorization
>              Data includes Status Data on the Stock Availability, to
>              indicate that the Purchase Order is linked to the earlier
>              Stock Availability Check Document Exchange.
> 
>      B --> S Request Message (Purchase Order):
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Buyer)
>                - To (Supplier)
>                - Service Type (Supplier Order Processing)
>                - Intent (New Purchase Order)
>                - Message Manifest
>                - Authorization Data:
>                    Buyer Data
>                    Status Data (Stock Availability Check)
>                    ref. to Signature3
>              o Message Routing Info
>              o Signatures
>                - Signature3, signs:
>                    Message Header
>                    Purchase Order
>                    Signature2 (on Stock Availability Check Response
>                    Message)
>              o Documents
>                - Purchase Order
> 
>  4.          The Supplier checks the Purchase Order Request Message and
>              generates an Invoice, and a list of Payment Brands that
>              the Supplier accepts, signs the documents and sends them
>              back to the Buyer.
> 
>      B <-- S Response Message (Purchase Order Response):
>              o Message Header
>                - Message Type (Response)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Supplier)
>                - To (Buyer)
>                - Service Type (Supplier Order Processing)
>                - Intent (New Purchase Order)
>                - Message Manifest
>                - Status Data (New Purchase Order)
>              o Message Routing Info
>              o Signatures
>                - Signature4, signs
>                    Message Header
>                    Invoice
>                    Brand List
>                    Signature3 (on Purchase Order Request Message)
>              o Documents
>                - Invoice
>                - Brand List
> 
>  5.          The Buyer checks the Purchase Order Response Message and
>              finds it OK. As a result generates a Payment Request,
>              provides information on the Payment Instrument to use,
>              digitally signs them sends them to the Payment Handler
>              (another Party) that is to accept the payment on behalf of
>              the Supplier.
> 
>      B --> P Request Message (Payment Request):
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Buyer)
>                - To (Payment Handler)
>                - Service Type (Payment)
>                - Intent (Make Payment)
>                - Message Manifest
>                - Authorization Data
>                    Buyer Data
>                    Supplier Data
>                    Status Data (New Purchase Order)
>                    ref. to Signature4 (from Purchase Order Response
>                    Message)
>                    ref to Signature5
>              o Message Routing Info
>              o Signatures
>                - Signature4 (copied from Purchase Order Response
>                   Message)
>                - Signature5, signs
>                    Signature4 (on Purchase Order Response Message)
>                    Payment Instrument
>                    Payment Request
>              o Documents:
>                - Payment Request (amount to pay, which Brand)
>                - Brand List
>                - Payment Instrument
> 
>  6.          The Payment Handler Checks the Payment Request including
>              the Authorization Data to check that they know the
>              Supplier, and on the Payment Instrument data to check that
>              the Buyer wants to make the payment. Accepts the Payment,
>              generates a Payment Receipt, digitally signs the
>              information and sends it back to the Buyer.
> 
>      B <-- P Response Message (Payment Response):
>              o Message Header
>                - Message Type (Response)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Payment Handler)
>                - To (Buyer)
>                - Service Type (Payment)
>                - Intent (Make Payment)
>                - Message Manifest
>                - Status Data (Payment Response)
>              o Message Routing Info
>              o Signatures
>                - Signature6, signs
>                    Message Header
>                    Payment Receipt
>                    Signature4 (on Purchase Order Response Message)
>                    Signature5 (on Payment Request Message)
>              o Document:
>                - Payment Receipt
> 
>  7.          The Buyer checks the Payment Response Message and finds it
>              OK. As a result generates a Delivery Request Document and
>              sends it to the Supplier to request delivery of the goods.
> 
>      B --> S Request Message (Delivery Request):
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Buyer)
>                - To (Supplier)
>                - Service Type (Supplier Order Processing)
>                - Intent (Make Delivery)
>                - Message Manifest
>                - Authorization Data
>                    Payment Handler Data
>                    ref to Signature6
>                    ref to Payment Receipt
>              o Message Routing Info
>              o Signatures
>                - Signature6 (copied from Payment Response Message)
>              o Documents
>                - Payment Receipt
> 
>  8.          The Supplier checks the Delivery Request including the
>              Authorization Data to check that payment has been made.
>              Checks that delivery is possible and therefore generates a
>              Delivery Response that confirms how delivery will occur,
>              digitally signs the information and sends the message back
>              to the Buyer.
> 
>      B <-- S Response Message (Delivery Response):
>              o Message Header
>                - Message Type (Response)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Supplier)
>                - To (Buyer)
>                - Service Type (Supplier Order Processing)
>                - Intent (Make Delivery)
>                - Message Manifest
>                - Status Data (Delivery Response)
>              o Message Routing Info
>              o Signatures
>                - Signature7, signs:
>                    Message Header
>                    Delivery Response
>                    Signatures6 (on the Delivery Request Message)
>              o Documents
>                - Delivery Response
> 
>  9.          The Buyer checks the Delivery Response Message and finds
>              it OK then logs the information and waits for the physical
>              Delivery of the goods.
> 
>              Figure 5 Multiple Document Exchange Transaction
> 
> 
>  [Note]     In the example above, signatures are used, to help provide
>             the audit trail and so that one Party, e.g. the Payment
>             Handler, can check the validity of the Payment Request
>             Message. Alternative approaches that avoid the need for
>             signatures are possible. For example:
>             o the Buyer and Seller use a secure Transport Mechanism
>               such as [HTTPS] to set up a secure channel between them
>             o the Seller authenticates the Buyer (perhaps using a
>               User/Server Authentication Transaction)
>             o the first two Document Exchanges occur over the secure
>               channel.
>  [Note End]
> 
> 
> 7.2.5 Relating Two Transactions
> 
>  XML Messaging allows two or more transactions to be linked together.
>  This example shows how a purchase transaction can be linked to an
>  earlier contract negotiation transaction.
> 
>  The first example is the contract negotiation transaction. Note that
>  this also illustrates a Multiple Round Trip Document Exchange.
> 
>  Buyer
>      |  Supplier
> STEP |     |
>  1.          Buyer generates a draft contract places it in an XML
>              Message together with a Message Header and sends it to the
>              Supplier.
> 
>      B --> S Request Message:
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Buyer)
>                - To (Supplier)
>                - Service Type (Contract Processing)
>                - Intent (New Draft Contract)
>                - Message Manifest
>              o Message Routing Info
>              o Document
>                - Draft Contract
> 
>  2.          The Supplier reviews the Contract, makes revisions and
>              places the revised contract in an Exchange Message and
>              sends it back to the Buyer
> 
>      B <-- S Exchange Message:
>              o Message Header:
>                - Message Type (Exchange)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Supplier)
>                - To (Buyer)
>                - Service Type (Contract Processing)
>                - Intent (Contract Amendment)
>                - Message Manifest
>              o Message Routing Info
>              o Document
>                - Revised Contract
> 
>  3.          The Buyer reviews the revised contract, amends it and
>              places it in an XML Message together with a Message Header
>              and sends it to the Supplier.
> 
>      B --> S Exchange Message:
>              o Message Header
>                - Message Type (Exchange)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Buyer)
>                - To (Supplier)
>                - Service Type (Contract Processing)
>                - Intent (Contract Amendment)
>                - Message Manifest
>              o Message Routing Info
>              o Document
>                - Revised Contract
> 
>  N-1.        The Supplier and Buyer keep on swapping drafts of the
>              contract in Exchange Messages until eventually they agree
>              and the Supplier sends the final version of the contract,
>              digitally signed, back to the Buyer in a Response Message.
> 
>      B <-- S Response Message:
>              o Message Header:
>                - Message Type (Response)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Supplier)
>                - To (Buyer)
>                - Service Type (Contract Processing)
>                - Intent (Final Contract)
>                - Message Manifest
>                - Status Data
>              o Message Routing Info
>              o Signatures
>                - Signature1, signs:
>                    Message Header
>                    Final Contract
>              o Document
>                - Final Contract
> 
>  N.          The Buyer carries out a final check on the contract and
>              stores it for later use.
> 
> 
>  Some time later, the Buyer wants to make a purchase under the terms
>  of the agreed contract. Now suppose that the contract negotiation
>  transaction had an identifier of "ACV-CN-1999/2456@example.com". Then
>  the Purchase Transaction could refer to the Contract Negotiation by
>  referring to the identifier in the Transaction Identity Data of the
>  Purchase Transaction. For example:
> 
>  Buyer
>      |  Supplier
> STEP |     |
>  1.          Buyer generates a Purchase Order places it in an XML
>              Message. The Transaction Identity Data refers to the
>              earlier Contract Negotiation transaction.
> 
>      B --> S Request Message (Purchase Order):
>              o Message Header
>                - Message Type (Request)
>                - Transaction Identity Data
>                - Message Identity Data
>                - From (Buyer)
>                - To (Supplier)
>                - Service Type (Supplier Order Processing)
>                - Intent (New Purchase Order)
>                - Message Manifest
>                - Related Transaction Data (refers to
>                   "ACV-CN-1999/2456@example.com")
>              o Message Routing Info
>              o Signatures
>                - Signature1, signs
>                    Message Header
>                    Purchase Order
>              o Document
>                - Purchase Order
> 
>  2.          Purchase continues ...
> 
> 
>  [Note]     Note that the digital signature is being used by the Buyer
>             to bind the Purchase Order to the earlier contract
>             negotiation.
>  [Note End]