Chapter 9 The principle of ebXML 9.1 The introduction of ebXML 9.1.1 What is ebXML? ebXML is a global electronic business standard that is sponsored by UN/CEFACT(United Nations Center For Trade Facilitation And Electronic Business)and OASIS(Organization for the Advancement of Structural Information Standards). ebXML thus defines a framework for global electronic business that will allow businesses to find each other and conduct business based on well-defined XML messages within the context of standard business processes which are governed by standard or mutually-negotiated partner agreement. The ebXML standard addresses each of the above points, as we shall see in the next section ebXML(Electronic Business using eXtensible Markup Language), is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes On one hand, ebXMl seems to promise a grand unification of everything businesses do to communicate with each other. On the other hand, one could be forgiven for thinking that ebXML amounts to little more than a pious, but vacuous, declaration that existing standards are worth following. As with every"next big thing, "the truth lies somewhere in the middle ebXML is a set of specifications that together enable a modular electronic business framework. The vision of ebXML is to enable a global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML-based messages Or in other words, ebXML hopes to succeed Electronic Data Interchange, more often known by its abbreviation, EDI (Official descriptions tend to emphasize learning from EDI rather than throwing it out. 9.1.2 Background ebXML is an initiative whose participants and endorsers consist of just about every big company and association of government standards worldwide that you can think of. Well, maybe not every one you can think of, but certainly hundreds of large companies and bodies Computer/technology companies are not the only entities that endorse ebXML; backers include a large number of industrial, shipping, banking, and other general-interest companies. The direct sponsors of ebXML are OASIs(Organization for the Advancement of Structured Information Standards) and UN/CEFACT (United Nations Central for Trade Facilitation and Electronic Business). Lots of standards bodies also have a finger in the pie, including NIST National Institute of Standards and Technology)and w3C (World wide Web Consortium) With such a collection of supporters, it would seem that ebXML is destined to take over the world. I tend to have a cynical attitude toward industry buzzwords and hype. In the case of ebXML, however, I mostly expect it to live up to its billing as a global protocol for most business transactions within the next five years In my opinion, ebXML will succeed in becoming universal by incorporating into the specifications more and more of what businesses do anyway as much as it will by actually getting businesses to do business differently. I'm not sure if my estimation is cynical or if it is encouragement at the openness of ebXML specifications, but the ebXML initiative clearly holds an embrace-existing-standards-and-methods attitude ebXml value Provides the only globally developed open XML-based Standard built on a rich heritage of electronic business experience
Chapter 9 The principle of ebXML 9.1 The introduction of ebXML 9.1.1 What is ebXML? ebXML is a global electronic business standard that is sponsored by UN/CEFACT (United Nations Center For Trade Facilitation And Electronic Business) and OASIS (Organization for the Advancement of Structural Information Standards). ebXML thus defines a framework for global electronic business that will allow businesses to find each other and conduct business based on well-defined XML messages within the context of standard business processes which are governed by standard or mutually-negotiated partner agreement. The ebXML standard addresses each of the above points, as we shall see in the next section. ebXML (Electronic Business using eXtensible Markup Language), is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes. On one hand, ebXML seems to promise a grand unification of everything businesses do to communicate with each other. On the other hand, one could be forgiven for thinking that ebXML amounts to little more than a pious, but vacuous, declaration that existing standards are worth following. As with every "next big thing," the truth lies somewhere in the middle. ebXML is a set of specifications that together enable a modular electronic business framework. The vision of ebXML is to enable a global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML-based messages. Or in other words, ebXML hopes to succeed Electronic Data Interchange, more often known by its abbreviation, EDI. (Official descriptions tend to emphasize learning from EDI rather than throwing it out.) 9.1.2 Background ebXML is an initiative whose participants and endorsers consist of just about every big company and association of government standards worldwide that you can think of. Well, maybe not every one you can think of, but certainly hundreds of large companies and bodies. Computer/technology companies are not the only entities that endorse ebXML; backers include a large number of industrial, shipping, banking, and other general-interest companies. The direct sponsors of ebXML are OASIS (Organization for the Advancement of Structured Information Standards) and UN/CEFACT (United Nations Central for Trade Facilitation and Electronic Business). Lots of standards bodies also have a finger in the pie, including NIST (National Institute of Standards and Technology) and W3C (World Wide Web Consortium). With such a collection of supporters, it would seem that ebXML is destined to take over the world. I tend to have a cynical attitude toward industry buzzwords and hype. In the case of ebXML, however, I mostly expect it to live up to its billing as a global protocol for most business transactions within the next five years. In my opinion, ebXML will succeed in becoming universal by incorporating into the specifications more and more of what businesses do anyway as much as it will by actually getting businesses to do business differently. I'm not sure if my estimation is cynical or if it is encouragement at the openness of ebXML specifications, but the ebXML initiative clearly holds an embrace-existing-standards-and-methods attitude. ebXML Value ▪ Provides the only globally developed open XML-based Standard built on a rich heritage of electronic business experience
Creates a Single Global Electronic Market Enables all parties irrespective of size to engage in Internet-based electronic business. Provides for plug and play shrink-wrapped solutions Enables parties to complement and extend current EC/EDI investment expand electronic business to new and existing trading partners Facilitates convergence of current and emerging XML efforts ebXML delivers the value by Developing technical specifications for the open ebXML infrastructure Creating the technical specifications with the world's best experts Collaborating with other initiatives and standards development organizations Building on the experience and strengths of existing EDI knowledge Enlisting industry leaders to participate and adopt ebXML infrastructure Realizing the commitment by ebXML participants to implement the ebXML technical specifications ebXMl was started in 1999 as an initiative of oasis and the United nations/eCe CEFACT. The original project envisioned and delivered five layers of substantive data specification, including XML standards for Business processes Core data components Messaging Registries and repositor 9.1.3 ebXML Delivera bles There are four categories of ebXMl deliverables Technical Specifications Technical Reports Reference materials White Papers Technical Specificati cluding ebXML Technical Architecture Specification Business Process Specification Schema Registry Information Model Registry Services Specification EbXML Requirements Specification Collaboration-Protocol Profile and agreement Specification Message Service Specification 9.2 The basic component of ebXML 9. 2. 1 Registry 1. What The ebXMl Registry Does The ebXML Registry provides a set of services that enable sharing of information between interested parties for the purpose of enabling business process integration between such parties based on the ebXML specifications. The shared information is maintained as objects in a repository and managed by the ebXML Registry Services defined in this document 2. How the ebxML Registry Work male his section describes at a high level some use cases illustrating how Registry clients may use of Registry Services to conduct B2B exchanges. It is meant to be illustrative and not interaction between Registry clients and the Registry. It is not a complete listing of the use cases that could be envisioned. It assumes for purposes of example, a buyer and a seller who wish to conduct B2B exchanges using the RosettaNet PlP3A4 Purchase Order business protocol. It is
▪ Creates a Single Global Electronic Market Enables all parties irrespective of size to engage in Internet-based electronic business. Provides for plug and play shrink-wrapped solutions. ▪ Enables parties to complement and extend current EC/EDI investment expand electronic business to new and existing trading partners. ▪ Facilitates convergence of current and emerging XML efforts. ebXML delivers the value by ▪ Developing technical specifications for the open ebXML infrastructure. ▪ Creating the technical specifications with the world's best experts. ▪ Collaborating with other initiatives and standards development organizations. ▪ Building on the experience and strengths of existing EDI knowledge. ▪ Enlisting industry leaders to participate and adopt ebXML infrastructure. ▪ Realizing the commitment by ebXML participants to implement the ebXML technical specifications. ebXML was started in 1999 as an initiative of OASIS and the United Nations/ECE agency CEFACT. The original project envisioned and delivered five layers of substantive data specification, including XML standards for: ▪ Business processes ▪ Core data components ▪ Collaboration protocol agreements ▪ Messaging ▪ Registries and repositories 9.1.3 ebXML Deliverables There are four categories of ebXML deliverables: ▪ Technical Specifications ▪ Technical Reports ▪ Reference Materials ▪ White Papers Technical Specifications including: ▪ ebXML Technical Architecture Specification ▪ Business Process Specification Schema ▪ Registry Information Model ▪ Registry Services Specification ▪ EbXML Requirements Specification ▪ Collaboration-Protocol Profile and Agreement Specification ▪ Message Service Specification 9.2 The basic component of ebXML 9.2.1 Registry 1. What The ebXML Registry Does The ebXML Registry provides a set of services that enable sharing of information between interested parties for the purpose of enabling business process integration between such parties based on the ebXML specifications. The shared information is maintained as objects in a repository and managed by the ebXML Registry Services defined in this document. 2. How the ebXML Registry Works This section describes at a high level some use cases illustrating how Registry clients may make use of Registry Services to conduct B2B exchanges. It is meant to be illustrative and not prescriptive. The following scenario provides a high level textual example of those use cases in terms of interaction between Registry clients and the Registry. It is not a complete listing of the use cases that could be envisioned. It assumes for purposes of example, a buyer and a seller who wish to conduct B2B exchanges using the RosettaNet PIP3A4 Purchase Order business protocol. It is
assumed that both buyer and seller use the same Registry service provided by a third party. Note that the architecture supports other possibilities(e. g. each party uses its own private Registry) (1) Schema Documents Are Submitted. A third party such as an industry consortium or standards group submits the necessary schema documents required by the RosettaNet PIP3A4 Purchase Order business protocol with the registry using the Object Manager service of the Registry described in Section 9.3 RosettaNet PIP3A4 Purchase order business protocol with the Registry using the reguired by they (2) Business Process Documents Are Submitted. A third party, such as an industry service o e Registry descr (3) Seller's Collaboration Protocol Profile Is Submitted. The seller publishes its Collaboration Protocol Profile or CPP as defined by [ebCPP] to the Registry. The CPP describes the seller, the role it plays, the services it offers and the technical details on how those services ay be accessed The seller classifies their Collaboration Protocol Profile using the registrys flexible Classification capabilities (4) Buyer Discovers The Seller. The buyer browses the Registry using Classification schemes defined within the Registry using a Registry Browser GUI tool to discover a suitable seller. For example the buyer may look for all parties that are in the Automotive Industry, play a seller role, support the RosettaNet PlP3A4 process and sell Car Stereos. The buyer discovers the sellers CPP and decides to engage in a partnership with the seller (5)(5)CPA Is Established. The buyer unilaterally creates a Collaboration Protocol Agreement or CPA as defined by [ebCPP] with the seller using the sellers CPP and their own CPP as input. The buyer proposes a trading relationship to the seller using the unilateral CPA. The seller accepts the proposed CPa and the trading relationship is established. Once the seller accepts CPA, the parties may begin to conduct B2B transactions as defined by [ ebMs Registry Architecture The ebXML Registry architecture consists of an ebXML Registry and ebXML Registry Clients. The Registry Client interfaces may be local to the registry or local to the user. Figure 9 I depicts the two possible topologies supported by the registry architecture with respect to the Registry and Registry Clients The picture on the left side shows the scenario where the Registry provides a web based"thin client "application for accessing the Registry that is available to the user using a common web browser. In this scenario the Registry Client interfaces reside across the internet and are local to the Registry from the user 's viaeB! The picture on the right side shows the scenario where the user is using a"fat client" Registry Browser application to access the registry. In this scenario the Registry Client interfaces reside within the Registry Browser tool and are local to the Registry from the users view. The Registry Client inter faces communicate with the Registry over the internet in this scenario A third topology made possible by the registry architecture is where the Registry Client interfaces reside in a server side business component such as a Purchasing business component. In this topology there may be no direct user interface or user intervention involved. Instead the Purchasing business component may access the registry in an automated manner to select possible sellers or service providers based current business needs
assumed that both buyer and seller use the same Registry service provided by a third party. Note that the architecture supports other possibilities (e.g. each party uses its own private Registry). （1） Schema Documents Are Submitted. A third party such as an industry consortium or standards group submits the necessary schema documents required by the RosettaNet PIP3A4 Purchase Order business protocol with the Registry using the ObjectManager service of the Registry described in Section 9.3. （2） Business Process Documents Are Submitted. A third party, such as an industry consortium or standards group, submits the necessary business process documents required by the RosettaNet PIP3A4 Purchase Order business protocol with the Registry using the ObjectManager service of the Registry described in Section9.3. （3） Seller’s Collaboration Protocol Profile Is Submitted. The seller publishes its Collaboration Protocol Profile or CPP as defined by [ebCPP] to the Registry. The CPP describes the seller, the role it plays, the services it offers and the technical details on how those services may be accessed. The seller classifies their Collaboration Protocol Profile using the Registry’s flexible Classification capabilities. （4） Buyer Discovers The Seller. The buyer browses the Registry using Classification schemes defined within the Registry using a Registry Browser GUI tool to discover a suitable seller. For example the buyer may look for all parties that are in the Automotive Industry, play a seller role, support the RosettaNet PIP3A4 process and sell Car Stereos. The buyer discovers the seller’s CPP and decides to engage in a partnership with the seller. （5） (5) CPA Is Established. The buyer unilaterally creates a Collaboration Protocol Agreement or CPA as defined by [ebCPP] with the seller using the seller’s CPP and their own CPP as input. The buyer proposes a trading relationship to the seller using the unilateral CPA. The seller accepts the proposed CPA and the trading relationship is established. Once the seller accepts the CPA, the parties may begin to conduct B2B transactions as defined by [ebMS]. 3. Registry Architecture The ebXML Registry architecture consists of an ebXML Registry and ebXML Registry Clients. The Registry Client interfaces may be local to the registry or local to the user. Figure 9. 1 depicts the two possible topologies supported by the registry architecture with respect to the Registry and Registry Clients. The picture on the left side shows the scenario where the Registry provides a web based “thin client” application for accessing the Registry that is available to the user using a common web browser. In this scenario the Registry Client interfaces reside across the internet and are local to the Registry from the user’s view. The picture on the right side shows the scenario where the user is using a “fat client” Registry Browser application to access the registry. In this scenario the Registry Client interfaces reside within the Registry Browser tool and are local to the Registry from the user’s view. The Registry Client interfaces communicate with the Registry over the internet in this scenario. A third topology made possible by the registry architecture is where the Registry Client interfaces reside in a server side business component such as a Purchasing business component. In this topology there may be no direct user interface or user intervention involved. Instead the Purchasing business component may access the Registry in an automated manner to select possible sellers or service providers based current business needs
ebXML Registry Registry egstry Interfaces The registry ovides the Client Registry Cent interfaces interfaces to a ers na aweb based Internet Registry Clent Interfa ng a Regsty browser ha contains the Client Figure 9-1 Registry Architecture Supports Flexible Topologies 9.2.2 Collaboration Protocol Profile( CPP)& Collaboration Protocol Agreement(CPA) To facilitate the process of conducting eBusiness, potential Trading Partners need a mechanism to publish infomation about the Business Processes they support along with specific technology implementation details about their capabilities for exchanging business information This is accomplished through the use of a Collaboration Protocol Profile(CPP). The CPP is a document which allows a Trading Partner to express their supported Business Processes and Business Service Interface requirements in a manner where they can be universally understood by other eb XML compliant Trading Partners A special business agreement called a CPA is derived from the intersection of two or more CPP's. The CPA serves as a formal handshake between two or more Trading Partners wishing to conduct business transactions using ebXML 1. Collaboration Protocol Profile(CPP) 1)CPP Formal Functionality The CPP describes the specific capabilities that a Trading Partner supports as well as the Service Interface requirements that need to be met in order to exchange business documents with that Trading Partner. The CPP contains essential information about the Trading Partner including, but not limited to: contact information, industry classification, supported Business Processes, Interface requirements and Messaging Service requirements. CPP's MAY also contain security and other implementation specific details. Each ebXML compliant Trading Partner SHOULD register their CPP(s) in an ebXML compliant Registry Service, thus providing a discovery mechanism that allows Trading Partners to(1)find one another, (2)discover the Business Process that other Trading Partners support he Cpp definition ShalL provide for unambiguous selection of choices in all instances where there may be multiple selections(e.g. Http or Smtp transport 2)CPP Interfaces A CPP SHALL be capable of referencing one or more Business Processes supported by the Trading partner owning the CPP instance. The CPP Shall reference the roles within a Business Process that the user is capable of assuming. An example of a Role could be the notion of a"Seller” and"Buyer” within a^ Purchasing” Business process The CPP ShALL be capable of being stored and retrieved from an ebXML Reg Mechanism A CPP SHOULD also describe binding details that are used to build an ebXml mess Header
Figure 9-1 Registry Architecture Supports Flexible Topologies 9.2.2 Collaboration Protocol Profile (CPP) & Collaboration Protocol Agreement (CPA) To facilitate the process of conducting eBusiness, potential Trading Partners need a mechanism to publish information about the Business Processes they support along with specific technology implementation details about their capabilities for exchanging business information. This is accomplished through the use of a Collaboration Protocol Profile (CPP). The CPP is a document which allows a Trading Partner to express their supported Business Processes and Business Service Interface requirements in a manner where they can be universally understood by other ebXML compliant Trading Partners. A special business agreement called a CPA is derived from the intersection of two or more CPP’s. The CPA serves as a formal handshake between two or more Trading Partners wishing to conduct business transactions using ebXML. 1. Collaboration Protocol Profile (CPP) 1) CPP Formal Functionality The CPP describes the specific capabilities that a Trading Partner supports as well as the Service Interface requirements that need to be met in order to exchange business documents with that Trading Partner. The CPP contains essential information about the Trading Partner including, but not limited to: contact information, industry classification, supported Business Processes, Interface requirements and Messaging Service requirements. CPP’s MAY also contain security and other implementation specific details. Each ebXML compliant Trading Partner SHOULD register their CPP(s) in an ebXML compliant Registry Service, thus providing a discovery mechanism that allows Trading Partners to (1) find one another, (2) discover the Business Process that other Trading Partners support. The CPP definition SHALL provide for unambiguous selection of choices in all instances where there may be multiple selections (e.g. HTTP or SMTP transport). 2)CPP Interfaces A CPP SHALL be capable of referencing one or more Business Processes supported by the Trading Partner owning the CPP instance. The CPP SHALL reference the Roles within a Business Process that the user is capable of assuming. An example of a Role could be the notion of a “Seller” and “Buyer” within a “Purchasing” Business Process. The CPP SHALL be capable of being stored and retrieved from an ebXML Registry Mechanism A CPP SHOULD also describe binding details that are used to build an ebXML Message Header
2. Collaboration Protocol Agreement (CPA) 1)CPA Formal Functionality A Collaboration Protocol Agreement(CPA)is a document that represents the intersection of two CPPs and is mutually agreed upon by both Trading Partners who wish to conduct busine using ebXML A CPA describes:(1)the Messaging Service and(2) the Business Process requirements that are agreed upon by two or more Trading Partners. Conceptually, ebXML supports a three level view of narrowing subsets to arrive at CPA's for transacting eBusiness. The outer-most scope relates to all of the capabilities that a Trading Partner can support with a subset of what a Trading Partner"will"actually support A CPA contains the Messaging Service Interface requirements as well as the implementation details pertaining to the mutually agreed upon Business Processes that both Trading Partners agree to use to conduct eBusiness. Trading Partners may decide to register their CPAs in an ebXML compliant Registry Service, but this is not a mandatory part of the CPa creation process Possibilities Capabilities Agreements Figure 9-2 Three level view of CPAs Business Collaborations are the first order of support that can be claimed by ebXML Trading Partners. This"claiming of support"for specific Business Collaborations is facilitated by a distinct profile defined specifically for publishing, or advertising in a directory service, such as an ebXML Registry or other available service. Figure 9.2 below outlines the scope for Collaboration Protocol greements within ebXML Collaboration Protocol Agreements Business in scope Collaborations for ebXMl Other Figure 9-3 Scope for CPAs The CPA-CPP specification includes a non-normative appendix that discusses CPA composition and negotiation and includes advice as to composition and negotiation procedures 2)CPA Interfaces A CPa governs the Business Service Interface used by a Trading Partner to constrain the Business Service Interface to a set of parameters agreed to by all Trading Partners who will execute such an agreement CPAs have Interfaces to CPP's in that the CPa is derived through a process of mutual negotiation narrowing the Trading Partners capabilities(CPP) into what the Trading Partner"will A CPA must reference to a specific Business Process and the interaction requirements needed to execute that business process A CPA MAY be stored in a Registry mechanism, hence an implied ability to be stored and retrie
2. Collaboration Protocol Agreement (CPA) 1)CPA Formal Functionality A Collaboration Protocol Agreement (CPA) is a document that represents the intersection of two CPP’s and is mutually agreed upon by both Trading Partners who wish to conduct eBusiness using ebXML. A CPA describes: (1) the Messaging Service and (2) the Business Process requirements that are agreed upon by two or more Trading Partners. Conceptually, ebXML supports a three level view of narrowing subsets to arrive at CPA’s for transacting eBusiness. The outer-most scope relates to all of the capabilities that a Trading Partner can support, with a subset of what a Trading Partner “will” actually support. A CPA contains the Messaging Service Interface requirements as well as the implementation details pertaining to the mutually agreed upon Business Processes that both Trading Partners agree to use to conduct eBusiness. Trading Partners may decide to register their CPA’s in an ebXML compliant Registry Service, but this is not a mandatory part of the CPA creation process. Figure 9-2 Three level view of CPA’s Business Collaborations are the first order of support that can be claimed by ebXML Trading Partners. This “claiming of support” for specific Business Collaborations is facilitated by a distinct profile defined specifically for publishing, or advertising in a directory service, such as an ebXML Registry or other available service. Figure 9.2 below outlines the scope for Collaboration Protocol Agreements within ebXML. Figure 9-3 Scope for CPA’s The CPA-CPP specification includes a non-normative appendix that discusses CPA composition and negotiation and includes advice as to composition and negotiation procedures. 2) CPA Interfaces A CPA governs the Business Service Interface used by a Trading Partner to constrain the Business Service Interface to a set of parameters agreed to by all Trading Partners who will execute such an agreement. CPA’s have Interfaces to CPP’s in that the CPA is derived through a process of mutual negotiation narrowing the Trading Partners capabilities (CPP) into what the Trading Partner “will” do (CPA). A CPA must reference to a specific Business Process and the interaction requirements needed to execute that Business Process. A CPA MAY be stored in a Registry mechanism, hence an implied ability to be stored and retrieved is present