[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC