This section provides an overview of the general concepts for using ebXML in a B2B environment. The five modules described in this section make up an ebXML framework. They are very modular and can be used independently. The modules included provide the following capabilities:
Reliable messaging. ebMS and MSH
Rules for exchanging messages. CPP and CPA
Business process workflow and collaboration. BPSS
Discovery. Registry and repository
Data items to capture business concepts. Core components
The following figure describes the design time (green) and runtime (red) interaction between trading partners in a B2B interaction using ebXML. The interactions begin with the development of a BPSS and CPP XML description of a business process. These documents get published to the ebXML registry and repository. A trading partner looks up the documents from the registry, and a trading partner agreement is negotiated and saved as a CPA. CPA and BPSS are then shared with each trading partner and loaded into the runtime infrastructure. The runtime execution is then kicked off by a cron job or a trigger from a back-end application and ebXML messages flow from one trading partner to the other through the Message Service Handler (MSH). The flow of messages traverses the business process based on the state machine-like workflow described in the BPSS and constraints and service level descriptions of the CPA.
FIGURE 2 Using ebXML to Connect Business Applications at Trading Partners
The goal of ebXML is to provide an open XML-based infrastructure to enable enterprises to conduct business over the Internet. It offers a standardized set of APIs and technologies that promote ad-hoc business collaboration. ebXML builds on the experience of EDI, and takes advantage of XML and the Internet. ebXML consists of the following architectural modules.
ebXML provides an ebMS for environments that require a robust, low-cost solution to enable electronic business. It is a standard method for exchanging business messages among ebXML trading partners.
The ebMS is a closely coordinated definition for an ebXML MSH. It defines the message enveloping and header document schema used to transfer ebXML messages over a communications protocol such as HTTP or SMTP, and the behavior of software sending and receiving ebXML messages. The ebMS is defined as a set of layered extensions to the base SOAP and SOAP Messages with Attachments specifications.
FIGURE 3 Top-Level View of ebXML Messaging Service
SOAP with Attachments provides the ability to transport non-XML data, as required. An ebXML message contains structures for a message header (necessary for routing and delivery) and a payload section.
The ebXML message service provides security and reliability features that are not available in SOAP, but are necessary to support international electronic business. The ebXML message service is structured to enable messaging reliability, persistence, security, and extensibility.
The message service handler (MSH) provides the following functionality:
Message header processing
Message header parsing
Reliable messaging services
Partner Profile and Agreement
The business process specification serves as primary input for forming collaboration protocol profiles and agreements. This section describes the documents that are used to create the rules for exchanging messages.
Collaboration Protocol Profile
A collaboration protocol profile (CPP) describes the message-exchange capabilities between business partners that engage in business transactions. It describes business capabilities such as what business processes are available. Also, it describes the technical capabilities, including messaging exchange capabilities; as well as transport, messaging, and security constraints. The CPP is stored in the ebXML Registry.
The CPP, which enables the automation of business collaboration, is a machine-readable description that can be published and discovered. With the CPP, business collaboration is specified in a declarative, rather than a procedural, manner.
Collaboration Protocol Agreement
The message-exchange agreement between two business partners is described by a collaboration protocol agreement (CPA). The CPA is a technical, binding description: It specifies the exact requirements and mechanisms for the transactions through which two companies exchange messages electronically. The CPA references the CPP business process schema definition. The CPA can define delivery channels, abstract configurations of how messages are exchanged, and characteristics of message exchange on a message-by-message basis. By comparison, WSDL is just a common, shared endpoint.
The trading partners' computing systems use the CPA to set up a runtime environment. This enables the exchange of business messages through the MSH, which ensures message security and reliability. Along with process specification, the CPA defines a conversation between the two parties.
Business process models enable organizations to create software components that collaborate on behalf of business partners. Business processes are the verbs of electronic business and can be represented using modeling tools. The specification for business process definition enables an enterprise to express its business processes so that they are understandable by other enterprises. This enables the integration of business processes within an enterprise or between enterprises.
Business process models specify business processes that enable partners to collaborate. While practices vary from one organization to another, most activities can be decomposed into business processes that are generic to a specific type of business. This analysis, which utilizes business modeling, identifies business processes and business information metamodels that can likely be standardized. The ebXML approach looks for standard reusable components from which to construct interoperable processes.
The ebXML business process specification schema (BPSS) supports the specification and collaboration of business transactions into business collaborations. Each business transaction can be implemented using one of many available standard patterns. These patterns determine how business documents and signals between trading partners are exchanged to achieve the required electronic transaction.
The ebXML BPSS supports the specification of business transactions and the collaboration of business transactions into business collaborations using the unified modeling methodology (UMM). The ebXML BPSS is available in two stand-alone representations, a UML version and an XML version.
To help specify the patterns, UMM provides a set of standard patterns, and BPSS provides a set of modeling elements in support of those patterns.
Registry and Repository
The ebXML Registry provides a general purpose content management system that enables publishing and discovery of arbitrary content, as shared information between interested parties, for the purpose of allowing business process integration. Content submitted for sharing can include XML schema and documents, process descriptions, core components, context descriptions, UML models, information about parties, and even software components. Standardized metadata is stored in the registry to catalog the published content. This published content is stored in a corresponding repository, and is used to facilitate ebXML-based B2B partnerships and transactions.
The ebXML Registry can be used to store many types of content. In many ways, it plays a similar role in Web services as relational databases play in enterprise applications. Depending on the use case, the ebXML Registry can be used at design time, at runtime, or at both design and runtime. It is common in B2B integration to use an ebXML Registry to store a business process. In this prototype, the main goal of the repository is to enable the developer to download the schema for a business process at design time. The ebXML Registry provides a superset of functionality provided by UDDI. UDDI is suitable for use cases involving simple publish/discovery of organizations and services. The ebXML Registry is more appropriate when there is a need for more complex metadata, extensibility, ad hoc querying, and support for arbitrary content.
Core components represent a set of common data items that capture real-world business concepts. They use industry-neutral notation, which enables interoperability among industry domains. ebXML core components are similar to a catalog of XML schemas for business information entities. Core components can be assembled like building blocks, creating the intended message for a business process.
When a new trading partner message is created or an existing one is changed, it is done by creating new core components in the prototype. For our prototype, new core components were implemented using custom document type definition (DTD). A business process might contain multiple core components. However, an essential aspect of our Sun ONE Application Server B2B collaboration prototype is that the underlying infrastructureBPSS, MSH, and so onremains the same.
XML Grammars and Standards Initiatives
While they solve a large part of the problem, standard XML messages are not robust enough to provide traditional EDI functionality on the Web. A reliable XML messaging framework is also needed to implement the equivalent of EDI networks on the Internet. ebXML defines core components, business processes, XML Registry, messaging services, trading partner agreements, and security.
To facilitate convergence of data standards for electronic businesses, the universal business language (UBL) initiative with OASIS defines specific XML schemas for common business documents such as purchase orders, invoices, and shipping notices. Though still in its early stages, the UBL effort is rapidly gaining support from EDI organizations and consortia, representing industries as far ranging as electronics, IT, retail, insurance, and accounting.
The ebXML initiative is complementary to UBL, and neutral with regard to particular XML syntaxes. ebXML delivered three basic components of a first-generation infrastructure for XML-based electronic commerce: a specification for XML messaging, a specification for trading partner agreements, and a specification for registries and repositories. These specifications are designed in a way that allows businesses to use them separately or together. UBL is intended to provide standard documents that can be exchanged over standard messaging, after the partners have been looked up in a registry.
WS-I Basic Profile Standard
This section provides an overview of the general concepts for using WS-I Basic Profile. A profile is a named group of Web services specifications at specific version levels, along with conventions about how they work together. WS-I is developing a core collection of profiles that support interoperability for general-purpose Web services functionality.
Through the first phase of Web services adoption, four specifications have risen to prominence as providing the basic functionality required to start developing Web services. These specifications are XML Schema 1.0, SOAP 1.1, WSDL 1.1, and UDDI 2.0. The first profile proposed is WS-I Basic Web services.
This set of specifications is used to provide the basic XML schema, packaging, and enterprise service definitions. It provides a base building block that is leveraged and extended by the ebXML standards as described earlier.