Enable real-world trading partner collaborations in SOA

XML and SOAP have opened the gates for e-business communication in the purest sense by allowing applications to truly interoperate. But they have proved insufficient in enabling a global electronic marketplace and making available information about the following key elements of a global e-business infrastructure:

• Business taxonomies
• Partners’ message-exchange capabilities
• Partners’ business-collaboration support

A global e-business infrastructure today is composed of a complex web of transactions and information exchanges among several diverse organizations. Each organization interacts in a unique way with another organization, introducing severe complexity for enabling this information exchange in an efficient and secure manner.

The two key standards that strive to overcome this challenge are Universal Discovery, Description, and Integration (UDDI) and Electronic Business using Extensible Markup Language (ebXML), both managed by the Organization for the Advancement of Structured Information Standards (OASIS). Both paradigms support the notion of the discovery of a business service provider, its Web services, and the available technical interfaces. However, while UDDI focuses more on the discovery of business service providers and their services, ebXML focuses on both the discovery and the collaboration of business service providers, as well as the discovery of their respective services.

This article concentrates on the ebXML implementation foundation, which is made up of four components: messaging, collaboration profiles, business process, and metadata registry.

The ebXML Collaboration Protocol Profile and Agreement (CPPA) standard plays a key role in an ebXML registry by providing a mechanism for specifying the details of how to support B2B integrations. It includes the details for transport, messaging, and security constraints and also specifies the bindings to a business-process specification document, which defines the business interactions between two partners. This bottom-up approach of including the business stakeholder in an integration right from the start enables any business entity to build a scalable and flexible system, ensuring information exchange occurs seamlessly. According to the specification:

“the objective of this specification is to ensure interoperability between two Parties even though they MAY procure application software and runtime support software from different vendors. The CPP [Collaboration Protocol Profile] defines a Party’s Message-exchange capabilities and the Business Collaborations that it supports. The CPA [Collaboration Protocol Agreement] defines the way two Parties will interact in performing the chosen Business Collaborations. Both Parties SHALL use identical copies of the CPA to configure their run-time systems. This assures that they are compatibly configured to exchange Messages whether or not they have obtained their run-time systems from the same vendor. The configuration process MAY be automated by means of a suitable tool that reads the CPA and performs the configuration process.”

This article will also showcase the advantage of using a flexible and high-performance native XML database management system along with XQuery to enable rapid and evolving loosely-coupled collaborations among trading partners within and across enterprises.

What are the relevant standards bodies pertaining to the CPPA standard?

The OASIS ebXML Collaboration Protocol Profile and Agreement Technical Committee is the author of the OASIS ebXML CPPA specification, one of the technical specifications of the OASIS ebXML suite of standards, a standardization effort lead by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and OASIS.

What is the status and industry adoption of the CPPA standard?

In December 2002, ebXML CPPA Version 2.0 was ratified and approved as an OASIS open standard. There is also an Editor’s Draft dated April 2005 for maintenance purposes.

Though ebXML is an extremely powerful approach, it has been relatively slow to attract wide industry adoption. In our opinion, organizations are still waiting for others to take the risk of trying emerging technologies. The project’s strongest support comes from Sun Microsystems. While it is an important member of the OASIS standards body, IBM has been somewhat noncommittal; and Microsoft does not even support the ebXML initiative.

What is CPP?

Collaboration Protocol Profile (CPP) defines the technical information about the interfaces, business capabilities, security constraints, messaging, and transport protocols the trading partner uses to do e-business. All trading partners register their CPP documents in an ebXML registry or similar repository so that other trading partners can discover them and understand the supported process. A trading partner can be represented by multiple CPP documents.

In a CPP, the ProcessSpecification, DeliveryChannel, DocExchange, and Transport elements define how a trading partner’s business unit can be processed. The ProcessSpecification element specifies the trading partners who can send requests to each other and the order of the requests. As shown in Figure 1, the DeliveryChannel element specifies a trading partner’s messaging capabilities. A trading partner can define any number of messaging characteristics supported in the CPP. The DocExchange element defines how a business document is processed, which includes encryption, digital signature, and reliable messaging. The Transport element defines the transport protocols to be used while sending business documents, the endpoint addresses, and other properties relating to the transport protocol used.

These pieces of information take into account, for example, the correct HTTPS port to access a company’s ERP (enterprise resource planning) system, the document standard used to exchange business information, and the sequence in which the business documents should be exchanged.

In this article, we provide only a brief overview of the CPP’s key elements, as shown in Table 1.

Table 1: Key elements

What is CPA?

The Collaboration Protocol Agreement (CPA) defines the system-level agreement for data interchange between trading partners. It narrows down a subset from what both trading partners can support to what both trading partners will actually support in the exchange. The CPA acts as a service-level agreement that, once agreed upon by both parties, can be then enforced by the ebXML system on both ends of the communication bridge.

As shown in Figure 2, the Status, Start, End, ConversationConstraints, PartyInfo, and Signature elements are the key elements that define the capabilities that two trading partners need to agree upon so they can engage in electronic business for the purposes of the particular CPA. The Status element records the state of the composition/negotiation process that creates the CPA. The Start element specifies the starting date and time of the CPA. The End element specifies the CPA’s ending date and time. The ConversationConstraints element places limits on the number of conversations under the CPA. The PartyInfo element specifies the parties’ selected terms for engaging in the business collaborations defined by the process specification documents referenced by the CPA. The Signature element, if present, is made up of one to three Signature elements.

The CPA can be signed by one or both trading partners, but both signatures are recommended. To obtain signatures for both trading partners, one trading partner initially signs, after which the other trading partner then signs over the first trading partner’s signature. The resulting CPA may then be signed by a notary. The Signature element is the root of a subtree of elements used for signing the CPP.

In this article, we provide only a brief overview of the CPA’s key elements, as shown in Table 2.

Table 2: CPA key elements

ebXML CPPA in a runtime environment

As shown in Figure 3, Trading Partner A creates the information to be placed in a repository for the discovery process, constructs a CPP that contains this information, and then enters it into an ebXML registry or similar repository along with additional information about the trading partner. The additional information might well include a description of the businesses that the trading partner engages in. Once Trading Partner A’s information is in the repository, other trading partners can discover Trading Partner A by using the repository’s discovery services. Trading Partner A and Trading Partner B can then use their CPPs to jointly construct a single copy of a CPA by calculating the intersection of the information in their CPPs. The resulting CPA defines how the two trading partners will interact in their business collaboration.

The OASIS ebXML Business Process Specification Schema (ebBPSS) is intended to provide the business process and document specification for the formation of ebXML trading-partner Collaboration Protocol Profiles and Agreements. The ebBPSS standard works with the ebXML CPP and CPA specifications to bridge the gap between business process modeling (BPM) and the configuration of ebXML-compliant e-business software; generally, it is referred to as Business Service Interface. ebBPSS also acts as an input for collaboration files by providing information on certain levels of security and reliability. Any trading partner can register its CPP to an ebXML registry. CPPs, in turn, act as configuration files for ebXML Business Service Interface software. Both the CPP and CPA are machine-readable XML documents. In particular, we are concerned with client and server software programs that engage in business transactions by sending and receiving messages. These messages convey business documents and/or business signals in their payload.

CPA creation

A trading partner defines the supported business processes and technical capabilities, such as supported protocols, by forming a CPP. The generated CPP document must be published to an ebXML registry, thus providing a global reach in an e-business environment. Any trading partner who would like to engage in e-business can then search the trading partner profiles using the registry’s discovery mechanism.

According to the CPPA Draft Version 2.1, there are two ways of forming a CPA: Trading partners can jointly form a CPA by calculating the intersection of the information in their CPPs. Or a trading partner can define a draft template CPA document, which is sent to the collaborating trading partner for input; eventually, it becomes the actual CPA document based on the drafts from both sides. A CPA template represents one party’s proposed implementation of a business process that uses placeholders as values for the identification aspects of the other party, such as PartyId or TransportEndpoint elements.

There are cases when the capabilities can be negotiated by either of the parties—for example, the software system can be changed if the collaboration agreement process is stopped. According to the CPPA Draft Version 2.1, a companion document called the Negotiation Descriptor Document defines the parameters that can be negotiated as well as the ranges or sets of acceptable values for those parameters. Both parties can then negotiate and store identical copies of CPA documents in both servers. This negotiation process can be automatic or manual.

The CPPA specification still does not define a clear picture of how to automate the CPPA formation process. Automating the CPA negotiation process is currently proposed for discussion in the CPPA Automated Negotiation Subcommittee.

On implementation of a CPA, as the business processes are wired through the middleware layer, the CPA is supported by both trading partners.

One of the most interesting quotes on CPPA was provided by Dale Moberg of Cyclone Commerce, chair of the OASIS ebXML CPPA Technical Committee, in “ebXML Collaboration Protocol Profile and Agreement Ratified as OASIS Open Standard” (Cover Pages, December 2002):

“ebXML CPPA ensures interoperability between two parties, even organizations that use software from different sources. The CPP defines a party’s message-exchange capabilities and the business collaborations that it supports. The CPA defines the way two business parties will interact in performing the chosen business collaborations. The OASIS Open Standard also facilitates the migration of both traditional EDI-based applications and other legacy applications to ebXML-based platforms.”

Real-world applicability of CPPA

The real-world applicability of CPPA can be seen in all forms of supply chain use-cases, ranging from manufacturing, pharmaceuticals, financials, insurance, etc.—wherever trading partners need to collaborate in a loosely-coupled environment. For example, CPPA can be extremely appropriate where physical goods, their information, and the associated financial transactions all need to be quickly exchanged among different trading partners. The complexity of information exchange, which is a key element of an efficient supply chain, can be greatly reduced by creating CPPs and hence enabling information to be seamlessly exchanged.

As we know, point-to-point integration is complex, error-prone, brittle, and inflexible. An organization’s business growth and flexibility should be supported by its IT systems and not undermined by it. CPP and CPA can greatly simplify this problem by establishing a trusted relationship and enabling information exchange among multiple trading partners.

How XQuery is useful in the extension and implementation of CPPA

Both CPP and CPA are XML based, and the persistence and lifecycle management of these files is a necessity in an e-business environment. Given the volume and complexity of any real-world inter-enterprise collaboration, it is our recommendation that CPPs and CPAs be stored and managed by a high-performance native XML database and XQuery engine that combine to supercharge the repository layer for the registry. XQuery can be used to enable the creation, manipulation, examination, and management of CPPA data. Specifically, XQuery can be widely used in the implementation of CPPA in a collaborative environment by:

• Providing automatic validation of CPPs and CPAs upon publishing to a registry
• Enabling a querying mechanism to discover CPPs based on criteria such as role or trading partner
• Governing, managing, and updating CPPs and CPAs in an ebXML registry-repository
• Defining comparison algorithms, using XQuery, to form a CPA out of multiple CPPs
• Defining negotiation algorithms, using XQuery, based on negotiation documents and business rules
• Correlating CPPA and business-process specification documents

An XML database can be widely used in the implementation of ebXML/CPPA for:

• Native persistence of XML documents
• Caching for performance
• Audit trail for governance
• Schema versioning for lifecycle management
• Schema evolution for lifecycle management

A flexible IT system enabled by efficient trading partner collaborations is key to adapting to changing business needs and leveraging partners for value differentiation and competitive advantage for an enterprise. As we have seen throughout this article, XML plays an important role in describing the key trading-partner collaboration standards for a service-oriented architecture (SOA). Persisting this XML data, including CPPs and CPAs described in XML, should be handled optimally by a high-performance native XML database. Why? Though Web services trading-partner collaboration standards are still evolving, a native XML database can enable the implementation of SOA collaboration standards today and minimizes disruption as the standards evolve. How? A native XML database can handle any type of XML data without prior knowledge of the XML schema structure. This powerful functionality proves highly advantageous when handling XML messages and CPP and CPA documents from federated systems. An XML database management system can persist these diverse documents, and, along with XQuery, lifecycle manage these artifacts. Additionally, XQuery also provides a simple yet powerful mechansim to rapidly query across these evolving documents. 

Additionally, a high-performance native XML database can offer the full power to manipulate, browse, search, integrate, and aggregate enterprise data in an SOA. Hence, a high-performance native XML database enabled by XQuery provides compelling benefits to enable collaborations in your SOA.

Conclusion

As you have seen in this article, the ebXML CPPA specification enables rapid deployment of a global e-business by providing a standard definition of the technical details for specifying the communication and security configurations that trading partners will need to agree upon for successful collaboration in an SOA. Representing these technical details in the standard format of the ebXML CPPA specification will greatly accelerate loosely-coupled integrations and provide better return on investment for inter and intra-enterprise collaborations.

We would like to thank Raining Data’s Ajay Ramachandran, CTO and vice president, XML-Centric Applications and Platforms Group; Premal Parikh, lead architect, XML-Centric Applications and Platforms Group; and Murty Gurajada, senior software engineer, XML-Centric Applications and Platforms Group for technically reviewing this article.