Trading Partner Profiles and Agreements

Companies need to know their trading partners and the rules of engagement before embarking on the exchange of business messages. ebXML builds these capabilities into its specifications. ebXML also connects the company profiles and agreements, so the capabilities of trading partners to engage in e-business are reflected in the agreements between the enterprises .

Background and Definitions

Since the exchange of business messages began with EDI, companies found they needed to establish ground rules for their interactions in advance, before the exchange of data actually started. These agreements, called trading partner agreements ( TPAs ), captured details such as the precise documents exchanged, networks used, points of contact in case problems developed, and in many cases the underlying assumptions ”often called boilerplate ”that governed the interactions between the parties.

The American Bar Association published a model TPA for EDI purchase orders, but many users found it adaptable to other transactions. As one would expect from an ABA document, it had authoritative legal references and offered a handy checklist that companies could use to make sure they covered all the bases before starting the flow of transactions. The model ABA document consisted of two parts : a) EDI communication terms, and b) underlying trade terms and conditions.

But some companies found the process for negotiating a formal legal agreement difficult and time-consuming . To shorten the process, some companies resorted to declarative letters , in which the company sent a letter to its trading partner stating terms; if the other party didn't respond, the originating company assumed they had no arguments with the terms.[40]

An IBM team led by Martin Sachs discovered that at least some of the conditions often included in TPAs lent themselves to capture and exchange in automated form, and in January 2000 proposed an XML vocabulary for trading partner agreements. Soon thereafter, IBM donated this work to ebXML.[41] Much of the ebXML specifications on TPAs is drawn from this earlier work by IBM.

TPAs represent one important document needed by companies engaging in e-business. Another kind of information exchanged is the capability of companies to conduct e-business, called a trading partner profile ( TPP ), used in the process of finding suitable trading partners. Many of these details on capabilities are made available in the registries described earlier.

ebXML defines some but not all of the details found in both trading partner agreements and profiles, and as a result introduces two new terms ” collaboration protocol profile ( CPP ) and collaboration protocol agreement ( CPA ) ”that make up the details found in ebXML specifications.[42] The following sections describe the CPP and CPA specifications, but the reader needs to remember that full trading partner agreements and profiles can comprise a good deal more information.

Overview of CPP and CPA Interactions

ebXML uses the term collaborative process for the business process used to exchange messages or establish e-business services. The ways that parties can exchange data are captured in an XML document called a collaboration protocol profile ( CPP ). As described earlier, ebXML registries often list these CPPs, and they become very useful in the process of discovering other trading partners.

CPPs are derived in part from the business process specifications that define the interactions among companies in an industry or business domain. The business process specifications are in most cases first defined in a modeling language but then implemented and stored in registries as XML documents. CPPs use XML extensions such as XLink that reference the precise elements in XML documents representing the business processes. As a result, a CPP indicates specific capabilities supporting business processes, with exact references in ebXML business process models. Also as a result, CPPs are processible documents citing specific capabilities and supporting specific business processes. CPPs can also identify specific business processes with unique identifiers.[43]

In addition to providing a discovery function, CPPs form the basis for constructing a CPA. Because the CPPs list the capabilities of companies seeking to do business electronically , the intersection of those capabilities among potential trading partners enables the companies to discover, at least in the beginning, those areas where they have common ground. This first interaction provides a starting point from which the companies can negotiate a CPA.[44]

At this stage, the ebXML developers could offer guidance on negotiating a CPA, but nothing solid enough for a standard. These guidelines are included in an appendix to the specifications document.[45]

The CPA provides a set of concrete and tangible interactions between the trading partners, and as a result each side can enforce the conduct of those interactions. The parties use the business process definitions in the CPAs to configure their e-business systems when exchanging messages. Since the contents of the CPA are based on the entries in each company's CPP and negotiated between the parties, each side has a stake in making certain that the contents of the CPPs and CPAs are accurate and current.

The CPA provides a set of concrete and tangible interactions between the trading partners, and as a result each side can enforce the conduct of those interactions.

Figure 8.7 shows two companies forming a CPA based on processes defined in a common industry repository. The industry has defined a series of processes: quotations, purchasing, shipping-receiving, invoices, and remittances.Two of the four companies with registered CPPs, Acme Industries and Consolidated Products, agree to do business electronically. Acme's CPP says its systems can support all of the industry processes except remittances, while Consolidated's CPP says it can handle everything but quotations. The companies negotiate a CPA covering the processes they have in common: purchasing, shipping-receiving, and invoices.

Figure 8.7. Creating a CPA from CPPs in an industry registry.

Figure 8.7 shows only the processes listed in the CPPs that contain other entries, such as message and transport protocols supported. Please note that while the registry lists the CPPs, the CPA is a document of interest and concern only to the two companies, and would not likely be indexed in an industry registry open to public view.

Companies will likely use software designed for conducting these interactions and set it up separately from the corporate databases. These kinds of software, known as middleware, will read the business processes, generate the appropriate messages, process incoming messages based on the contents of the CPAs, link to the company's back-end systems, and perform management services such as logging. Business processes, defined in a modeling language like UML but stored and processed in XML, contain references to a series of messages. These messages, in turn , contain the data elements needed by the parties and structured to conduct the business defined in the process.

A CPA can reference more than one business process, and therefore needs to clearly define where one process ends and the next process begins. The specifications recommend adding a way for the parties to request the start and end of these interchanges during the conversations.[46]

Collaboration Protocol Profiles

The collaboration protocol profile (CPP) describes three main functions of the company's e-business capability:

• Process specifications. Defines electronic business functions and services supported by the company.

• Document exchange. Specifies services provided to connect the process specifications to the transport functions for sending and receiving, including encryption and decryption, as well as addition of digital signatures.

• Transport. Identifies the services supported for sending and receiving e-business messages.

The document exchange and transport functions complement each other. For example, security features needed for e-business services can appear as part of the document exchange or transport functions, and will vary from one company to the next, depending on their implementation of these functions.

The CPP is an XML document, with the root element CollaborationProtocolProfile required in all instances. The root element references three XML namespaces for its content: the default ebXML tradePartner , XML Digital Signature from the World Wide Web Consortium (W3C), and XML Linking Language (XLink), also from the W3C.[47]

The root element has four immediate child elements. PartyInfo must appear at least once in the document. A Packaging element also must appear. An optional ds:Signature contains the digital signature. The fourth child element is Comments .

The Packaging element ”with a number of sub-elements of its own ”describes how the ebXML message headers and payloads are configured. It includes the document-level properties for security, including MIME capabilities.[48]

PartyInfo describes the company described in the CPP, which in turn has the following child elements, all of which are required in each CPP:[49][50]

• PartyId identifies the company with a unique string and is accepted by both parties as an identifier. Examples are UCC/EAN assigned company codes or D-U-N-S numbers . Some identifiers may work only in specific industries, such as carrier codes assigned in air travel (IATA) or company codes in book publishing (SAN).

• PartyRef points to more data about the company, and uses XLink syntax. PartyRef can point to an ebXML or UDDI registry, or other resources such as the company's web site.

• CollaborationRole identifies the part the company plays in business process specifications. This element contains the data that describes the business processes supported by the company, as well as its role in those processes. We provide more information about this element shortly.

• Certificate identifies the digital certificates used for non- repudiation or authentication, including an identifier for each certificate and data that describe the certificate, as defined by the XML Digital Signature specification.

• DeliveryChannel describes the transport and message protocols the company supports, as described in the Transport and DocExchange protocols (described shortly). A delivery channel consists of one Transport and one DocExchange , and a Characteristics element providing security details.

• Transport defines details of the transport protocols (web, email, FTP, and so on) supported for message transmission. This element includes the protocols for sending and receiving, an end point that identifies the company's address for receiving messages, and security information for each specific means of transport.

• DocExchange describes the properties of the messaging services used by the companies for exchanging documents. The specifications describe the interfaces or bindings with ebXML messaging services, but allow for future expansion to allow for other kinds of messaging that ebXML may support. This element includes child elements for the following:

  • Message encoding, if a specific or special syntax is needed for messages sent to the company.

  • Reliable messaging properties, if more than "best effort" practices are required by the company, and including retries, retry interval, degree of reliable messaging (once and only once, or best effort), detection and discarding of duplicate messages, and time duration of persistent storage.

  • Non-repudiation, to prove the identity of the sender using an XML digital signature.

  • Digital envelope, to provide message encryption.

  • Namespace, detailing the namespace extensions required to implement the message services used by the company.

CollaborationRole

The CollaborationRole element contains the data describing the parts or functions played by the company in business processes supported by that company. Figure 8.8 shows the components making up this element. The main CollaborationRole element has an identifier attribute (ID) used for reference by other elements in the CPP. All of the other data come under the four child elements: ProcessSpecification , Role , CertificateRef , and ServiceBinding .

Figure 8.8. CollaborationRole element and components.

The ProcessSpecification element describes the processes that the company supports for the conduct of electronic business. The processes refer directly to the business process models defined by the industry or industries in which the company operates, and often found in ebXML registries as described earlier in this chapter.

The element identifies the processes by name and version, using XML attributes. The element has two other attributes that use the XLink specification of XML to give XML documents direct access to other documents, in this case the business process models. One XLink attribute identifies its type, a locator, while the other gives the specific Internet address of the resource.

If the XML document with the business process model carries a digital signature, the ProcessSpecification element allows for a ds:reference child element to identify the digital signature and a separate attribute giving the Internet address for the signature. The ds:reference element cites rules defined by the XML Digital Signature specification with requirements and limitations that CPPs need to follow.

The Role element refers to the role played by parties in the business process models defined by the industries. In the CollaborationRole element, the role is described by a name attribute referring to the role name in the business process specification. This element also has the same two XLink attributes as ProcessSpecification , indicating locator type and Internet address for the part of the XML document with the role description.

The CertificateRef element carries an attribute, certId , that refers to the digital certificate in PartyInfo , and provides authorization to use the business process specification.

The ServiceBinding element names the delivery channels used for the messages sent to the company for this specific business process. This element has a name attribute that contains the name string to describe the specific services in ebXML message headers used as part of this business process. A channelId attribute identifies the default delivery channel for the messages in this business process.

The Override element, as the name implies, gives the company the ability to use a delivery channel different from the default channel identified for messages generated by this business process specification. The specifications note that the Override channel may not always be compatible with the capabilities of trading partners, and in those circumstances the parties need to resolve potential conflicts or revert to the default channels.[51]

Collaboration Protocol Agreements

Collaboration protocol agreements ( CPAs ) describe the agreement between two companies on technical characteristics that define the features, services, and processes in the electronic-business relationship between the two companies. As noted earlier, two companies create a CPA based on the capabilities in common in their respective CPPs, as well as any subsequent negotiations.

CPAs, like CPPs, are XML documents. The CollaborationProtocolAgreement element ”the root element in the document ”has a unique identifier (ID) attribute, assigned by one party but used by both. The specifications recommend that companies use a uniform resource identifier (Internet address, such as web or email address) for this identifier.This element also references four XML namespaces for ebXML trading partner specifications and business process models, as well as W3C specifications for digital signatures and XML Linking Language (XLink).[52]

The CPA has the following major child elements:

• Status is a required element indicating the state of progress in the development of the CPA, with choices of proposed , agreed ,or signed . The signed option can take the form of a digital signature, as defined by the ds:Signature element (described shortly).

• Start and End elements, both required, indicate respectively the date and time the CPA goes into effect, and the date/time by which the parties need to renegotiate the CPA. The range of time between the Start and End values is called the CPA lifetime. The specifications give rules for handling conversations or transactions underway after the End date/time value, but it seems advisable that companies renew their CPAs well before the End value.

• ConversationConstraints is an optional element citing limits affecting the processing of messages exchanged between the two parties:

  • An invocation limit gives an upper limit on the number of units of activity covered by the CPA. With no invocation limit, the companies can conduct any number of activities until the End date/time.

  • A concurrent conversations limit puts an upper limit on the number of conversations between the parties processed at any one time, which can occur due to limitations in the capabilities of backend systems.

• PartyInfo elements, one required for each company that is a party to the CPA. The PartyInfo element in the CPA is the same as the PartyInfo described earlier for the CPP. The actual business messages use the PartyId child element (also the same as described earlier) listed in the CPA in comparable entries as part of the ebXML headers.

• ds:Signature , at least one required, showing a digital signature. The specifications highly recommend meeting the requirements of the XML Digital Signature document. If the digital signature, itself an XML document, fails validation, the CPA is considered invalid. The specifications provide details for persistence of the digital signature, which apply to both the CPPs and CPAs.

• Comment , an optional element that gives added descriptive information in free-text form.[53]

With MIME packaging, SOAP (and ebXML) can send non-XML binary payloads, such as digitized graphics files, making the format more usable for business purposes.