Recommended: Sing it, brah! 5 fabulous songs for developers
JW's Top 5
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 6
Figure 3. ebXML business process architecture. Click on thumbnail to view full-sized image.
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.
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.
Archived Discussions (Read only)