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 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). 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. 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. 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. 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) 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.  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 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  Figure 9-3 Overview of working architecture of CPP/CPAwith ebXML registry Any Party may register its CPPs to an ebXML Registry. Party B discovers trading partner A(Seller) by searching in the Registry and downloads CPP(A) to Party B server. Party B creates CPA(A,B) and sends CPA(A,B) to Party A. 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. Parties A and B configure their run-time systems with the information in the CPA. 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.  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.  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.  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.  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).  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.  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.  Figure 9-11 a high level overview of the interaction of two companies conducting eBusiness using ebXML. In Figure 9-11, Company A has become aware of an ebXML Registry that is accessible on the Internet (Figure 9.10, step 1). Company A, after reviewing the contents of the ebXML Registry, decides to build and deploy its own ebXML compliant application (Figure 9.10, step 2). Custom software development is not a necessary prerequisite for ebXML participation. ebXML compliant applications and components may also be commercially available as shrink-wrapped solutions. Company A then submits its own Business Profile information (including implementation details and reference links) to the ebXML Registry (Figure 9-11, step 3). The business profile submitted to the ebXML Registry describes the company’s ebXML capabilities and constraints, as well as its supported business scenarios. These business scenarios are XML versions of the Business Processes and associated information bundles (e.g. a sales tax calculation) in which the company is able to engage. After receiving verification that the format and usage of a business scenario is correct, an acknowledgment is sent to Company A (Figure 9-11, step 3). Company B discovers the business scenarios supported by Company A in the ebXML Registry (Figure 9-11, step 4). Company B sends a request to Company A stating that they would like to engage in a business scenario using ebXML (Figure 9-11, step 5). Company B acquires an ebXML compliant shrink-wrapped application. Before engaging in the scenario Company B submits a proposed business arrangement directly to Company A’s ebXML compliant software Interface. The proposed business arrangement outlines the mutually agreed upon business scenarios and specific agreements. The business arrangement also contains information pertaining to the messaging requirements for transactions to take place, contingency plans, and security-related requirements (Figure 9-11, step 5). Company A then accepts the business agreement. Company A and B are now ready to engage in eBusiness using ebXML (Figure 9-11, step 6). 9.3.5 Three or more parties set-up a Business Process implementing a supply-chain and run the associated exchanges The simple case of a supply-chain involving two Trading Partners can be redefined in terms of the Scenario 1. Here we are dealing with situations where more Trading Partners are involved. We consider a supply chain of the following type: Figure 9-12 Three parties set-up a Business Process What fundamentally differs from Scenario 1 is that “Trading Partner 2” is engaged at the same time with two different Trading Partners. The assumption is that the “state” of the local portion of the Business Process is managed by each Trading Partner, i.e. that each Trading Partner is fully responsible of the Business Transaction involving it (“Trading Partner 3” only knows about “Trading Partner 2”, “Trading Partner 2” knows about “Trading Partner 3” and “Trading Partner 1”, “Trading Partner 1” knows about “Trading Partner 2”). In this scenario: Each Trading Partner defines its own Profile (CPP). Each Profile (CPP) references: One or more existing Business Process found in the ebXML Registry One of more Message Definitions. Each Message definition is built from reusable components (Core Components) found in the ebXML Registry Each Profile (CPP) defines: The Commercial Transactions that the Trading Partner is able to engage into. “Trading Partner 2” must be able to support at least 2 Commercial Transactions. The Technical protocol (like HTPP, SMTP etc) and the technical properties (such as special encryption, validation, authentication) that the Trading Partner supports in the engagement. As to “Trading Partner 2”, the technical requirements for the exchanges with “Trading Partner 1” and “Trading Partner 3” may be different. In such case, “Trading Partner 2” must be able to support different protocols and/or properties. The Trading Partners acknowledge each other profile and create the relevant CPA. (at least 2 in this Scenario). “Trading Partner 2” is engaged in 2 CPA’s The Trading Partners implement the respective part of the Profile. This is done: Either by creating/configuring a Business Service Interface. Or properly upgrading the legacy software running at their side. In both cases, this step is about: Plugging the Legacy into the ebXML technical infrastructure as specified by the Messaging Service Granting that the software is able to properly engage the stated conversations Granting that the exchanges semantically conform to the agreed upon ebXML Message definitions Granting that the exchanges technically conform with the underlying ebXML Messaging Service. “Trading Partner 2” may need to implement a complex Business Service Interface in order to be able to engage with different Trading Partners. The Trading Partners start exchanging Messages and performing the agreed upon commercial transactions. “Trading Partner 3” places an order at “Trading Partner 2” “Trading Partner 2” (eventually) places an order with “Trading Partner 1” “Trading Partner 1” fulfills the order “Trading Partner 2” fulfill the order 9.3.6 A Company sets up a Portal which defines a Business Process involving the use of external business services This is the Scenario describing a Service Provider. A “client” asks the Service Provider for a Service. The Service Provider fulfills the request by properly managing the exchanges with other Trading Partners that provide information to build the final answer. In the simplest case, this Scenario could be modeled as follows : Figure 9-13 Scenario describing a Service Provider This is an evolution of Scenario 2. The Description of this scenario is omitted. 9.3.7 Three or more Trading Partners conduct business using shared Business Processes and run the associated exchanges This Scenario is about 3 or more Trading Partners having complex relationships. An example of this is the use of an external delivery service for delivering goods. Figure 9-14 Scenario is about 3 or more Trading Partners In this Scenario, each Trading Partner is involved with more than one other Trading Partner but the relationship is not linear. The product or good that is ordered by the Client with a Service Provider is delivered by a 3rd party. In this scenario: Each Trading Partner defines its own Profile (CPP). Each Profile (CPP) references: One or more existing Business Process found in the ebXML Registry One of more Registry Definitions. Each Registry definition is built from reusable components (Core Components) found in the ebXML Registry Each Profile (CPP) defines: The Commercial Transactions that the Trading Partner is able to engage into. In this case, each Trading Partner must be able to support at least 2 Commercial Transactions. The Technical protocol (like HTPP, SMTP etc) and the technical properties (such as special encryption, validation, authentication) that the Trading Partner supports in the engagement. In case the technical infrastructure underlying the different exchanges differes, each Trading Partner must be able to support different protocols and/or properties. (an example is that the order is done through a Web Site and the delivery is under the form of an email). The Trading Partners acknowledge each other profile and create a CPA. Each Trading Partner, in this Scenario, must be able to negotiate at least 2 Agreements. Each Trading Partner is enagaged in 2 Agreements (CPA). The Trading Partners implement the respective part of the Profile. This is done: Either by creating/configuring a Business Service Interface. Or properly upgrading the legacy software running at their side In both cases, this step is about: Plugging the Legacy into the ebXML technical infrastructure as specified by the Messaging Service. Granting that the software is able to properly engage the stated conversations Granting that the exchanges semantically conform to the agreed upon Message definitions. Granting that the exchanges technical conform with the underlying ebXML Messaging Service. All Trading Partners may need to implement complex Business Service Interfaces to accommodate the differences in the CPA’s with different Trading Partners. The Trading Partners start exchanging Messages and performing the agreed upon commercial transactions. The Client places an Order at the Service Provider. The Service Provider Acknowledges the Order with The Client. The Service Provider informs the Mail Delivery Service about a good to be delivered at the Client The Mail Delivery Service delivers the good at the Client The Clients notifies the Service Provider that the good is received. 9.4 The implement of ebXML 9.4.1 The steps of the implement of ebXML The high-level activities related to business process and business information analysis is shown in Figure 9-15.  Figure 9-15 Activities Related to Analyzing Business Processes and Business Information As a first step, it is useful to develop a Statement of Intent, which clearly identifies the scope and purpose of the analysis activity and serves to focus the efforts of the team. The next step involves the gathering of requirements based on the Statement of Intent. Marketing and product management teams often perform this requirement gathering activity. The output of this activity may be a marketing requirements document or a product requirements document. In any case, the result SHOULD be a set of clearly defined requirements for the analysis. After the requirements have been defined and agreed, the actual analysis can begin. There can be many inputs to and aspects of the process required to produce the desired output. Inputs to the analysis process can come from requirements, customers and partners, standards, other existing models, and domain experts. Requirements MAY be in the form of product requirement documents, statements of work, customer change requests, etc. Customers, partners, and domain experts provide their input when they are being consulted during the requirement elaboration process and during documentation reviews. Existing standards (cross industry and industry specific) and other existing models (e.g. EDI message implementation guides) are also consulted. The controls for the analysis activities are the methodology (UMM), Meta Model, patterns, and other analysis techniques. These controls specify the process and information model REQUIRED for the business process and information analysis process to produce correct outputs. Patterns include transaction patterns and collaboration patterns. The mechanisms for the analysis activities are the analysts, tools, and reviewers. Analysts are the people who are defining the processes and documents based on the Meta Model. One of the key tools to assist with the analysis is the ebXML Business Process Analysis Worksheets, discussed in Section10, Analysis Aids: Worksheets and Tools. 9.4.2 ebXML Design Time and Run Time Reference Model In order to put Business Process and Business Information Analysis on its proper context, it is useful to consider the ebXML Technical Architecture. ebXML Technical Architecture is comprised of two basic components: Design Time and Run Time. Business Process and Business Information Analysis is a part of Design Time component. The Design Time component deals with the procedures for creating an application of the ebXML infrastructure, as well as the actual discovery and enablement of ebXML-related resources required for business transactions to take place. Business Process and Business Information Analysis is one way accomplishing the Design Time component of the Technical Architecture. The Run Time component covers the execution of an ebXML scenario with the actual associated ebXML transactions. The Design Time and Run Time components of the ebXML Technical Architecture are found in figure 9-16.  Figure 9-16 ebXML Design Time and Runtime Reference Model 9.4.3 Open source projects Early on in the history of ebXML, open source projects were started, which cover the technical infrastructure required to exchange business documents between business partners. This is unprecedented in history, establishing 'free beer'-software as competition for commercial products almost from the beginning. I shall discuss these projects and their importance to ebXML. In the past few years, open source projects have gained significantly in terms of reputation. For example, Linux, the Apache Web server, the Tomcat Servlet engine, to name but a few, are now considered stable and reliable products and are experiencing widespread deployment. Apache for one is the world's most popular web server. At this time, there are three open source projects which concentrate on providing the business collaboration infrastructure technology. OASIS ebXML Registry Reference Implementation Project (ebxmlrr). The goal of the ebxmlrr project is to deliver a functionally complete reference implementation for the OASIS ebXML Registry V2.0 Specification. The Phoenix Project.This was started by the University of Hong Kong's Center for E-Commerce Infrastructure Development (CECID), and will make available an implementation of the ebXML Message Service. The Open ebXML project.This project aims to provide a comprehensive ebXML-based business collaboration framework, primarily supporting the version 2 specification set. The project's scope is an end-to-end solution. It is organized into several subprojects (currently more than 10), each with a defined set of deliverables. STEEL24-7 is a European platform for the steel industry founded by Arcelor, Corus and ThyssenKrupp Steel. The company operates a communications hub for buyers and suppliers in the steel industry. By implementing the webMethods integration platform, STEEL24-7 can automate supply chain processes by enabling buyers and suppliers to seamlessly connect back-end ERP systems and communicate in real time. Integration with STEEL24-7 offers several benefits to steel buyers and suppliers. STEEL24-7 members have the ability to integrate directly with all of their business partners through a single connection to a neutral, industry-supported hub. This differs considerably from the traditional EDI technology that is typically used in the industry. Through STEEL24-7, buyers and suppliers can extend their EDI technology, thereby reducing the manual labor and high costs of point-to-point integrations. Reference Registry Services Specification v2.0. Internet: http://www.ebxml.org/specs/ebrs2.pdf Collaboration-Protocol Profile and Agreement Specification v1.0. Internet: http://www.ebxml.org/specs/ebCCP.doc ebXML Technical Architecture Specification v1.04. Internet: http://www.ebxml.org/specs/ebTA.doc Business Process and Business Information Analysis Overview v1.0. Internet: http://www.ebxml.org/specs/bpOVER.doc The National Office for the Information Economy. Promotion and deployment of ebXML . Internet: http://www.noie.gov.au/Projects/ecommerce/interop/eBus_paper/projects.htm freeebXML Website. freeebXML Website Launched to Host 'free' ebXML Development Projects. Internet: http://freebxml.org/pr.htm Webservice. ebXML is getting closer. Internet: http://www.webservices.org/index.php/article/articleview/713/1/24/ OASIS ebXML Registry Reference Implementation Project,ebxmlrr. Internet: http://ebxmlrr.sourceforge.net/ Center for E-Commerce Infrastructure Development, CECID. Internet: http://www.cecid.hku.hk/Activities-pheonix.htm Open ebXML Internet: http://openxml.sourceforge.net Editorial Staff. STEEL24-7 opts for webMethods ebXML based platform. Internet: http://www.webservices.org/index.php/article/articlestatic/699/1/22/