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
3. CPP/CPA with ebXML Registry Part A Regi CPAY Pary B Figure 9-3 Overview of working architecture of CPP/C PAwith ebXML registry (1) Any Party may register its CPPs to an ebXML Registry (2) Party B discovers trading partner ching in the Registry and downloads CPP(A)to Party B server. (3) Party B creates CPA(A, B)and sends CPA(A, B)to Party a (4) Parties A and B negotiate and store identical copies of the completed CPA as a document in both servers. This process is done manually or automatically (5) Parties A and B configure their run-time systems with the information in the CPa (6 Parties a and b do business under the new CPA 9.2.3 ebXML Message Structure and Packaging Figure 9-4 below illustrates the logical structure of an ebXML Message Transport Envelope(smtp, Http, etc. ) bXML Message Envelope(MIME multipart/related) ebXML Header Envelope ebXML ebXML Header Document Header Manifest leader bXML Payload Envelope Payload Container Figure 9-4 ebXML Message Structure An ebXML Message consists of an optional transport Protocol specific outer Communication Protocol Envelope and a Protocol independent ebXML Message Envelope. The ebXML
3. CPP/CPA with ebXML Registry Figure 9-3 Overview of working architecture of CPP/CPAwith ebXML registry （1） Any Party may register its CPPs to an ebXML Registry. （2） Party B discovers trading partner A(Seller) by searching in the Registry and downloads CPP(A) to Party B server. （3） Party B creates CPA(A,B) and sends CPA(A,B) to Party A. （4） Parties A and B negotiate and store identical copies of the completed CPA as a document in both servers.This process is done manually or automatically. （5） Parties A and B configure their run-time systems with the information in the CPA. （6） Parties A and B do business under the new CPA. 9.2.3 ebXML Message Structure and Packaging Figure 9-4 below illustrates the logical structure of an ebXML Message. Transport Envelope (SMTP, HTTP, etc.) ebXML Message Envelope (MIME multipart/related) ebXML Header Envelope ebXML Header Document ebXML Payload Envelope ebXML Payload Document(s) Payload Container Manifest Header ebXML Header Container Figure 9-4 ebXML Message Structure An ebXML Message consists of an optional transport Protocol specific outer Communication Protocol Envelope and a Protocol independent ebXML Message Envelope. The ebXML
Message Envelope is packaged using the MImE multipart/related content type. MIME is used as a packaging solution because of the diverse nature of information exchanged between Partners in eBusiness environments. For example, a complex Business Transaction between two or more Trading Partners might require a payload that contains an array of business documents(XMl or other document formats), binary images, or other related Business Information 9.3 The operation of Business Processes 9.3.1 Business Processes and Business documents At a very basic level, a business process is the means by which one or more activities are accomplished in the conduct of business. Within the business process there could be one or more collaborations, each consisting of one or more transactions. Figure 9.5 below is a simple representation of a business process and an illustration of the types of business processes which might be needed between Customer and Supplier to complete an order for materials Business process Business Business Process Process Create Long Term Contract Collaboration Transaction Forecast Compon Transaction Send Planning Documen Collaboration Arrange Payment Figure 9-5 Business Collaborations, and Transactions Conceptual Vi 9.3.2 ebXML functional phases 1. Implementation Phase The implementation phase deals specifically with the procedures for creating an application of the ebXML infrastructure. A Trading Partner wishing to engage in an ebXML compliant transaction SHOULD first acquire copies of the ebXML Specifications. The Trading Partner tudies these specifications and subsequently downloads the Core Library and the business Library. The Trading Partner MAY also request other Trading Partners' Business Process information(stored in their business profile) for analysis and review. Alternatively, the Trading Partner MAY implement ebXML by utilizing 3rd party applications. The Trading Partner can also ubmit its own Business Process information to an ebXML compliant Registry Service Figure 9-6 below, illustrates a basic interaction between an ebXML Registry Service and a Trading Partner
Message Envelope is packaged using the MIME multipart/related content type. MIME is used as a packaging solution because of the diverse nature of information exchanged between Partners in eBusiness environments. For example, a complex Business Transaction between two or more Trading Partners might require a payload that contains an array of business documents (XML or other document formats), binary images, or other related Business Information. 9.3 The operation of Business Processes 9.3.1 Business Processes and Business Documents At a very basic level, a business process is the means by which one or more activities are accomplished in the conduct of business. Within the business process there could be one or more collaborations, each consisting of one or more transactions. Figure 9.5 below is a simple representation of a business process and an illustration of the types of business processes which might be needed between Customer and Supplier to complete an order for materials. Business Process Business Process Collaboration Transaction ... ... Transaction Collaboration Business Process Create Long Term Contract Forecast Component Requirements Send Planning Document Place Order Ship Materials Customer Arrange Payment Supplier Figure 9-5 Business Process, Collaborations, and Transactions Conceptual View 9.3.2 ebXML Functional Phases 1. Implementation Phase The implementation phase deals specifically with the procedures for creating an application of the ebXML infrastructure. A Trading Partner wishing to engage in an ebXML compliant transaction SHOULD first acquire copies of the ebXML Specifications. The Trading Partner studies these specifications and subsequently downloads the Core Library and the Business Library. The Trading Partner MAY also request other Trading Partners’ Business Process information (stored in their business profile) for analysis and review. Alternatively, the Trading Partner MAY implement ebXML by utilizing 3rd party applications. The Trading Partner can also submit its own Business Process information to an ebXML compliant Registry Service. Figure 9-6 below, illustrates a basic interaction between an ebXML Registry Service and a Trading Partner
ebXML Registry Meta models Trading Figure9-6 Functional Service View: Implementation Phase 2. Discovery and Deployment and Retrieval Phase The Discovery and Retrieval Phase covers all aspects of the discovery of ebXML related resources. A Trading Partner who has implemented an ebXML Business Service Interface can now begin the process of discovery and retrieval (Figure 9-7 below). One possible discovery method may be to request the Collaboration Protocol Prpfile of another Trading Partner Requests for updates to Core Libraries, Business Libraries and updated or new Business Process and Information Meta Models Should be supported by an ebXML Business Service Interface This is the phase where Trading Partners discover the meaning of business information being requested by other Trading Partners Meta Models Trading Partner iraling Partner Figure 9-7 Functional Service View: Discovery and Retrieval Phase 3. Run time phase The run time phase covers the execution of an ebXML scenario with the actual associated ebXML transactions. In the Run Time Phase, ebXML Messages are being exchanged between Trading Partners utilizing the ebXML Messaging Service For example, an ebXML CPA is a choreographed set of business Message exchanges linked together by a well-defined choreography using the ebXML Messaging Service(see Fugure9-8)
Trading Partner Request Receive Update ebXML Registry Business Process & Information Meta Models Core Library Business Library Collaboration Protocol Profiles Figure9-6 Functional Service View: Implementation Phase 2. Discovery and Deployment and Retrieval Phase The Discovery and Retrieval Phase covers all aspects of the discovery of ebXML related resources. A Trading Partner who has implemented an ebXML Business Service Interface can now begin the process of discovery and retrieval (Figure 9-7 below). One possible discovery method may be to request the Collaboration Protocol Profile of another Trading Partner. Requests for updates to Core Libraries, Business Libraries and updated or new Business Process and Information Meta Models SHOULD be supported by an ebXML Business Service Interface. This is the phase where Trading Partners discover the meaning of business information being requested by other Trading Partners. Request Receive Update Send Receive ebXML Registry Trading Partner Trading Partner List of Scenarios Messaging Constraints Security Contstraints Business Process & Information Meta Models Core Library Business Library Collaboration Protocol Profiles Figure 9-7 Functional Service View: Discovery and Retrieval Phase 3. Run Time Phase The run time phase covers the execution of an ebXML scenario with the actual associated ebXML transactions. In the Run Time Phase, ebXML Messages are being exchanged between Trading Partners utilizing the ebXML Messaging Service. For example, an ebXML CPA is a choreographed set of business Message exchanges linked together by a well-defined choreography using the ebXML Messaging Service(see Fugure9-8)
Trading Partne Recei gure 9-8 Fund 9.3.3 Business document Business document definitions are the specifications for the business document schemas and information components that compose the business document and contained information components. A schematic representation of a business document can be seen in Figure 9-9. beloy Example: Purchase Order Information component Order nformation Component rmation Componen Information component OrderDetail OrderDetail OrderSumma Figure 9-9 Document Conceptual View Documents such as Purchase Orders, Invoices, etc, exist at the business process level and are exchanged in business transactions by means of placing documents into document envelopes Documents are put into document envelopes. They are addressed with the business identifier (e.g. DUNS number)of the recipient and sender. This is analogous to the "Attention: "line on a standard mailing address. A document envelope is placed into a message envelope and is exchanged between business service interfaces. The message envelope might be addressed with the urn of the destination business service interface. messages have timeouts and other transaction control mechanisms associated with them. Message envelopes are placed into a transport/routing envelope for low level transmission across an e-business network. The target ddress on message envelope might be the URL of the destination's message-in-box service. A logical view of the nested envelope structure is shown in Figure 9-10
Send Receive Trading Partner Trading Partner Figure 9-8 Functional Service View: Run Time Phase 9.3.3 Business document Business document definitions are the specifications for the business document schemas and the information components that compose the business document and contained information components. A schematic representation of a business document can be seen in Figure 9-9, below. Figure 9-9 Document Conceptual View Documents such as Purchase Orders, Invoices, etc., exist at the business process level and are exchanged in business transactions by means of placing documents into document envelopes. Documents are put into document envelopes. They are addressed with the business identifier (e.g. DUNS number) of the recipient and sender. This is analogous to the “Attention:” line on a standard mailing address. A document envelope is placed into a message envelope and is exchanged between business service interfaces. The message envelope might be addressed with the URN of the destination business service interface. Messages have timeouts and other transaction control mechanisms associated with them. Message envelopes are placed into a transport/routing envelope for low level transmission across an e-business network. The target address on message envelope might be the URL of the destination’s message-in-box service. A logical view of the nested envelope structure is shown in Figure 9-10
Transport/Routing Envelope Message Envelope Document Envelope Business process Document Business service interface Document Transport/Routing Protocols Figure 9-10 Messaging and Enveloping Conceptual View 9.3.4 ebXML System Overview Figure 9-ll below shows a high-level use case scenario for two Trading Partners,first configuring and then engaging in a simple business transaction and interchange. This model is provided as an example of the process and steps that may be required to configure and deploy ebXML Applications and related architecture components. These components can be implemented in an incremental manner. The ebXML specifications are not limited to this simple model provided here as quick introduction to the concepts. Specific ebXML implementation examples are described in Appendix A. The conceptual overview described below introduces the following concepts and underlying architecture. b(A standard mechanism for describing a Business Process and its associated information (2)A mechanism for registering and storing Business Process and Information Meta Models so they can be shared and reused 3)Discovery of information about each participant including The Business Processes they support The Business Service Interfaces they offer in support of the Business Process The Business Messages that are exchanged between their respective Business Service The technical configuration of the supported transport, security and encoding protocols A mechanism for registering the aforementioned information so that it may be discovered and retrieved A mechanism for describing the execution of a mutually agreed upon business arrangement which can be derived from information provided by each participant from item 3 above.( Collaboration Protocol Agreement-CPA) A standardized business Messaging Service framework that enables interoperable, secure and reliable exchange of Messages between Trading Partners A mechanism for configuration of the respective Messaging Services to engage in the agreed upon Business Process in accordance with the constraints defined in the business arrangement
Transport/Routing Envelope Message Envelope Document Envelope Document ... Document Business Service Interface Transport/Routing Protocols Business Process Figure 9-10 Messaging and Enveloping Conceptual View 9.3.4 ebXML System Overview Figure 9-11 below shows a high-level use case scenario for two Trading Partners, first configuring and then engaging in a simple business transaction and interchange. This model is provided as an example of the process and steps that may be required to configure and deploy ebXML Applications and related architecture components. These components can be implemented in an incremental manner. The ebXML specifications are not limited to this simple model, provided here as quick introduction to the concepts. Specific ebXML implementation examples are described in Appendix A. The conceptual overview described below introduces the following concepts and underlying architecture: (1) A standard mechanism for describing a Business Process and its associated information model. (2) A mechanism for registering and storing Business Process and Information Meta Models so they can be shared and reused. (3) Discovery of information about each participant including: ▪ The Business Processes they support. ▪ The Business Service Interfaces they offer in support of the Business Process. ▪ The Business Messages that are exchanged between their respective Business Service Interfaces. ▪ The technical configuration of the supported transport, security and encoding protocols. ▪ A mechanism for registering the aforementioned information so that it may be discovered and retrieved. ▪ A mechanism for describing the execution of a mutually agreed upon business arrangement which can be derived from information provided by each participant from item 3 above. (Collaboration Protocol Agreement – CPA) ▪ A standardized business Messaging Service framework that enables interoperable, secure and reliable exchange of Messages between Trading Partners. ▪ A mechanism for configuration of the respective Messaging Services to engage in the agreed upon Business Process in accordance with the constraints defined in the business arrangement