TPAml spec

[john_ibbotson@uk.ibm.com]

Since we originally submitted the tpaml spec to OASIS in January, we have
done some further work on extending/clarifying/revising. I've attached a
copy of our latest (until now) internal version of the specification for
comment by the ebXML TRP WG. There was also a request for an HTML version
of the document I distributed yesterday.
(See attached file: TPAmlDoc.pdf)(See attached file: ebXML TRP and
TPAs.htm)
See you next week,
John

MQSeries Technical Strategy & Planning,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: +44 (0)1962 815188
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com

Adobe Portable Document

Title: A TPA contains:

The Role of TPAs within ebXML Transport

Authors:            John Ibbotson, IBM UK Ltd

                        Ian Jones, BT

 

For ebXML TRP purposes, a Trading Partner Agreement (TPA) is a contractual agreement that exists between two trading partners. This agreement contains configuration information required for the partners to interoperate for the purposes of electronic business. The TPA may be processed by a machine in which case it could be described by an XML structured document. Alternatively, the information in a TPA may used to set up interoperable systems manually.

Definition of Terms

A TPA contains:

• Participant information which defines the contact points in the two partners organizations. These include names, addresses, roles and URIs for electronic communication.
• A Business Protocol section that defines the state machine that exists between the partners interoperating business processes. These processes are public interfaces to their internal and private processes. The state machine is defined in terms of Request Messages that trigger public Actions in a partner’s business process. Each Action can create one or more Response Messages that in turn are returned to the other partner. The business protocol may also be referred to as an orchestration or choreography in describing the public interface to private business processes. An Action is a unit of work performed by a partner in response to a request message. The Action may generate one or more response messages.

·        One or more Document Exchange definitions, each with an identifier that is unique within the TPA. This provides information that the partners must agree on regarding exchange of documents between them. This information includes the message security definition.

·        One or more Transport definitions, each with an identifier that is unique within the TPA. The transport section of the TPA defines communication protocol, encoding, and transport security information.

·        One or more Delivery Channels, each with an identifier that is unique within the TPA. A delivery channel is a combination of a transport definition and a document exchange definition that specifies how messages from one party's business protocol layer are moved to the other party's business protocol layer

 

An instance of an exchange between two partners, governed by a TPA, is referred to as a Conversation. Example conversations may include the interchanges involved in RFQ negotiation, PO processing or interactive manufacturing scheduling. Conversations may be short or long running. A single request/response is the simplest conversation lasting for a few seconds. A complex negotiation process over days or weeks involving many different interchanges between the partners can also constitute a single conversation. There may be multiple, concurrent conversations between two partners. The TPA governs the maximum concurrent conversations allowed between the partners. Each conversation has an identifier which is unique within the scope of the two partners.

 

Actions within a business protocol may be bound to different Delivery Channels allowing for example, an initial HTTP business request to be responded via SMTP.

 

Multiple TPAs may exist between the two trading partners. Typically, each TPA will define separate trading relationships between the partners. These relationships may include purchasing, manufacturing information and catalogue interchange. Each relationship may include different Participant information.

 

Links to ebXML TRP Activities

Within the ebXML TRP context, the Document Exchange, Transport and Delivery Channel parts of a TPA can provide configuration information required to set up an interoperable link between trading partners.

 

Each ebXML message that flows between the partners constitutes a transition arc in the TPA Business Protocol state machine. In the case of a multipart ebXML message, each part may be a transition arc in different TPA governed state machines. A restriction is that to ensure the correct sequences of messages within a Business Protocol, a single multipart message must not include payload messages which are part of the same Conversation.

 

To allow the matching of each ebXML message payload part to an associated TPA governed conversation, we propose additional Server Routing information to be added to the ebXML Message Manifest document entries for each payload. Other possible places for this information were considered and rejected:

• Message Payload – We  must not alter the payload
• Message Header – Blurs the header and manifest roles
• Message Routing Information – This is used for transport multi-hop routing. The new information is for routing and processing at the recipient server.

 

This becomes a separate XML element within the manifest:

 

BusinessProcessRoutingInfo

• TPAId                          MANDATORY – The TPA this conversation is defined by.
• ConversationId            MANDATORY – The instance of the business protocol.
• ServiceInterface            OPTIONAL –             TPAs could have multiple protocols.
• Action                          MANDATORY – The TPA Action this message is for.

 

With this information in the message manifest, the communicating partners can manage the state of long running conversations between them.