ebXML Trading-Partners Specification

1. Introduction

Within the emerging e-business environment, companies are facing a number of challenges when integrating their businesses. This integration may be within the enterprise or, more likely, in bringing together complex supply chain relationships between many different trading partners. In many cases, companies have not been able to tightly integrate their Web commerce applications to their back-end systems. These internal sets of applications may be constructed of dozens of complex ERP and business application systems. It is generally accepted that 90% of the Fortune 1000 companies run on at least three different operating systems, further complicating business integration.

Few e-commerce Web sites are fully integrated with existing business systems today with research indicating that as little as 2% of all e-commerce sites are linked to back end systems. Developing an integrated business is complex, and time-consuming with Gartner estimating that 70% of the cost of writing an application is writing and integrating the infrastructure.

The solution to this increasing complexity is the development of a standardised infrastructure which will allow us to streamline key areas of setting up and doing business between trading partners. This infrastructure should be based on open standards. The ebXML Trading Partner Agreement (TPA) specification provides such an infrastructure.

2. Inter-Enterprise Integration

The ebXML TPA specification builds on the best integration practices. It is assumed that partners in a trading relationship should not be forced to adopt a common set of hardware, operating system, middleware or application software in order to do business. This restricts the ability of each partner to react to their own business climate and update or change their business processes and systems as their requirements alter.

Secondly, we assume that there is a loose coupling between the partners systems. This means that each partner's business process implementations are independent of the others. One partner is therefore not allowed to lock any resources within the other partner's infrastructure and they can only interact with each other via a published set of actions within an interface. The TPA also establishes specific recourse actions that the partners can invoke rather than rely on the semantics of transactional two phase commit. For example, a TPA may include a specific Cancel Reservation action that a partner may invoke as part of the agreed shared business processes.

Thirdly, it has to be assumed that each partner's business applications are untrusted. This means that a framework of control and monitoring has to be part of the trading agreement. Only prescribed sequences of actions are allowed under the TPA which are checked by the supporting middleware. A Security framework is also defined as part of the agreement which defines the access and authentication schemes for partner interactions.

Under these constraints, the ebXML TPA specification proposes a standards based infrastructure which allows potential trading partners to negotiate an agreement, configure their IT systems to meet that agreement and interchange business information.

3. The Electronic TPA

Traditionally, a Trading Partner Agreement may be thought of as a legal document enforcing a trading relationship between two parties. In the e-business world, an electronic TPA specifies the rules of interaction between independent businesses. These rules are independent of any business processes at either party. The TPA is expressed as an XML document which contains a formal specification of the rules. The document may in turn be used to configure each party's IT systems so that they operate correctly under the agreement rules.

A TPA defines a conversation between the trading partners. This conversation is a unit of business under the TPA and there may be many conversations running concurrently between the partners. A conversation is a set of related business transactions each of which are represented by an interchange of messages between the partners. These messages may be interchanged synchronously or asynchronously and it is up to each party's IT infrastructure to ensure that the message exchanges adhere to the rules of the TPA. Each party is responsible for maintaining the correlation between messages within a conversation — in effect the conversation state. A party is also responsible for correctly invoking its own business process implementations upon receipt of a request message and generating an appropriate response which is returned to the other party.

4. Profiles and Agreements

IBM initially submitted its TPAml technology to ebXML for consideration. This concentrated on the agreement document and assumed that there was some mutual negotiation between the partners to create the document. The formation of an ebXML working group resulted in the architecture being expanded to include the concept of a Collaboration Protocol Profile (CPP) which describes a partner's IT capabilities. These capabilities include what communication protocols (HTTP, SMTP, FTP etc.) they support, what security requirements they place upon the message exchanges, and what business processes they support. A CPP describes all the things a partner can do.

Each party has a CPP which is a public description of their capabilities. The ebXML working group has adopted the term Collaboration Partner Agreement (CPA) to mean the same as a TPA. A CPA is created between two partners who wish to interoperate. The CPA is an intersection of the two party's CPPs with the results of negotiation variable parameters in the profiles. The CPA includes an agreed common set of IT capabilities together with a definition of what business processes are to be performed between the two parties.

5. CPA Information

A CPA contains the following key information.

Overall Properties — This section contains information relating to the overall CPA. It will include such things as the duration of the agreement.

Identification — This section identifies the parties to the agreement. It will include nominated contacts with their addresses together with other party identifiers such as their registered DUNS numbers.

Communication Properties — This section identifies what communication protocols the parties will support. It will also include where necessary parameters such as timeouts needed to ensure interoperability between the parties.

Document Exchange Properties — This section establishes the messaging protocol to be used in exchanging business documents. It will include a description of the set of messages that can be exchanged, their encoding, and any parameters associated with reliable delivery.

Security Properties — This section will include information needed to ensure a secure interchange of information between the parties. It includes parameters for nonrepudiation such as certificates, protocols, hash functions and signature algorithms. For digital enveloping it will include certificates and encryption algorithms.

Roles — This section associates a party with a role defied in the CPP. Generally, the description is defined in terms of roles such as "buyer" and "seller". The CPP identifies which role or roles the Party is capable of playing in each collaboration protocol referenced by the CPP.

Business Transactions — This section defines the Business Transactions or services that the parties agree to interchange. It describes the interfaces between the parties and the business application functions that actually perform the business transactions.

Comments — A free format section which can be used for additional information such as reference to any legal documents relating to the partner agreement.

6. Using the CPA to do Business

The CPA created by two parties from their respective CPPs may be thought of as configuration information for their B2B infrastructure. The middleware used to intercommunicate between parties, notably an ebXML TRP compatible message handler, will understand the elements within a CPA. A typical set of services provided by the middleware will include CPA registration, message routing. business state transition rule checking, document generation and parsing, security, correlation of conversation state, logging, auditing and recovery. Provision of such services will allow interoperation between the two trading partners.

7. Further Information

For further information, go to the following sites:

The ebXML Initiative: http://www.ebxml.org

XML base technical standards: http://www.w3c.org

XML standard vocabulary repository: http://www.xml.org

News on XML developments: http://www.xml.org/xmlorg_news/index.shtml

Design and Development by deepX Ltd.