Enable real-world trading partner collaborations in SOA

An introduction to the ebXML Collaboration Protocol Profile and Agreement standard

1 2 Page 2
Page 2 of 2

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.


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.

Leo Fernandez is a senior developer with SourceN. He has been actively involved in the design and development of XML-, middleware-, and SOA-based solutions for more than three years. Ash Parikh is the director of technology and development for the XML-Centric Applications and Platform Group at Raining Data Corporation. He is a named expert in the field of SOA and distributed computing and has presented and authored abstracts for OASIS Symposium 2005, Delphi BPX Summit 2004, Delphi Enterprise On-Demand 2004, JavaOne 2004, JavaOne 2003, BEA e-World 2002, and JavaOne 2002. Parikh has more than 15 years of IT experience and is an active member on a number of Java Specification Requests in the Java Community Process and in OASIS technical committees. He is also the president of the Bay Area Chapter of the Worldwide Institute of Software Architects and the cochair of the SDForum Web services SIG. Parikh has also authored several technical articles in journals such as JavaWorld, XML-Journal, Java Pro, Web Services Journal, ADTmag, Softwaremag.com, and Java Skyline. Varun Gupta is a product manager in the XML-Centric Applications and Platforms Group at Raining Data Corporation. He leads Raining Data's initiatives in product development and manages several Raining Data SOA and RFID software products. Gupta also leads the company's initiatives in several industry standards groups, such as EPCGlobal and MIT Auto-ID Labs' Web Services WANSIG. He is an expert in developing, deploying, and integrating SOA, RFID, and sensor network solutions. Prior to Raining Data, Gupta was at Sun Microsystems, where he was core member of Sun's RFID team. He has been involved with the MIT Auto-ID Center and EPCglobal standards development and implementation from inception.

Learn more about this topic

This story, "Enable real-world trading partner collaborations in SOA" was originally published by JavaWorld.

Copyright © 2006 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2