A Look at the ebXML Technical Architecture

To achieve the ambitious goals of ebXML and thus perform the steps in Figure 2.4 and the cases in Chapter 3, "ebXML at Work," ebXML needs a robust, yet flexible architecture. This overall design needs to take advantage of the distributed nature of the web, capture specific definitions of business processes, encourage interoperability through common core components , and provide a way for companies to interact with each other, even if they have never done business before. Later in the book, we describe these business requirements more fully, but as already described in Chapter 1, the needs of business (not just e-business) demand that they be met.

The ebXML technology consists of the following major features:

• Definition of business processes by capturing the business functions and the parties, message exchanges, terminology, and data elements representing business practices for industries.

• Creation of core components that identify common business terms, nouns, and concepts and give them a neutral name and unique identifier. With core components, different industries can relate their own terms and thus offer a way for companies in different industries to interact with each other.

• Establishment of machine-readable company profiles capturing capabilities of companies to support various industry processes and the technical features of their e-business systems. These profiles become the basis of technical agreements between companies to exchange e-business messages, as part of more comprehensive physical trading arrangements.

• A system of distributed standard registries that most companies will use to get started in ebXML, and that provide indexed access to repositories of industry processes, messages, and business data, as well as company profiles with their technical capabilities to exchange e-business messages.

• A standard message package that allows for transporting ebXML data over the web, email, or file transfers; allows for acknowledgments and recovery if problems occur; and provides for various levels of secure transmissions if the business needs demand them.

  The following sections discuss each of these features in more detail.

Business Processes and Objects

The business ideas and knowledge in ebXML are expressed in the business process models that describe the activities and interactions among businesses and in associated business terms. These processes define the overall business services and individual messages exchanged, as well as the data contained in the messages. Some processes may be nearly identical from one industry to the next ; for example, financial reporting functions for publicly traded companies. For most industries, however, business processes will vary to reflect the peculiarities of the industry. For example, the RosettaNet Partner Interface Processes (PIPs) described in Chapter 5, "The Road Toward ebXML," include detailed supply-chain processes that undoubtedly resemble supply-chain interactions in other industries. However, the PIPs for transactions specifically involving electronic components contain items that are likely to be unique to that business sector.

As shown by the scenario in Figure 2.4 in the preceding section, business processes contain the models of the interactions describing the services shared among trading partners. They identify the trading partners and their roles in the interactions, detail the associated messages exchanged among trading partners , including the data content within such messages, and indicate the sequence of the messages (called choreographies ).

The business processes used in ebXML can be captured as XML documents or represented in the UN's modeling methodology, which uses the Unified Modeling Language ( UML ) described further in Chapters 5 and 8. UML provides an alternate visual way to represent and portray the connections of the real-world business processes to the XML code exchanged among trading partners. This ability to connect the business process directly to the technology gives the ebXML specifications a great deal of power.[7]

Because ebXML provides the ability to consistently describe and apply these processes and transactions, businesses will probably learn to reuse them in similar situations as the opportunities arise. An example is a credit card billing process using one of the major credit card companies, which a company can extend to other credit card processors.

UML and other modeling techniques provide for a detailed analysis and description of business processes and objects. This extends down to the level of individual data elements expressed in messages exchanged between trading partners, and the related information objects needed to deliver the desired services.

Core components provide a way for the various industries to continue using their own terms in business messages, yet relate them to common business processes and neutral identifiers provided by ebXML.

Note that ebXML doesn't require the use of UML or any formal modeling methods for this purpose. Industries or organizations may derive simple business process definitions by creating the XML structures and content directly from existing established business processes. For example, existing EDI transaction-based business processes that are documented and well known can be directly rendered as ebXML business process definitions in XML, and then stored in an ebXML registry for access and use.

Core Components

As described in Chapter 1, the need for companies to do business in multiple industries has become an important requirement of any e-business technology. Therefore, ebXML gives special attention to business objects that appear in multiple business domains, and calls the common reusable data items that cut across many industries core components. It is these core components that help ebXML achieve much of its interoperability.

To illustrate the use of core components, consider how different businesses and industries use different terminology to represent the same idea, and in some cases even the same person. Imagine a typical traveler named Xerxes Melb. Surrendering his boarding pass at the gate and entering the plane, Mr. Melb is called a passenger. Buying a gift at a retail outlet within minutes of landing, he becomes a customer. When he sends the gift home with a package-delivery service, he's a shipper, with the help of a hotel concierge who calls Mr. Melb a guest. Each time, this same individual, with the same set of identification data (street address, telephone, email), may pay for these items with the same credit card.

Thus, the same person engages in several different transactions with several different businesses, and with much the same kind of data, but is called by a different name each time based on the business context. A common set of data items can help bridge these semantic hurdles when the various processes and messages need to interact with each other. Yet each industry still talks in its own language, and it would be highly unrealistic to expect industries to change. Core components provide a way for the various industries to continue using their own terms in business messages, yet relate them to common business processes and neutral identifiers provided by ebXML. As long as trading partners can relate their own terminology to neutral ebXML syntax, businesses have a basis for achieving interoperability.[8]

An important feature of core components is the context in which they are used. One important type of context is the role a company plays in a business process. In a supply chain, a wholesaler will purchase goods from a manufacturer, and thus be a buyer in one set of messages. But that same company will act as a supplier to retailers, selling the very same goods (although in smaller quantities ) in another set of messages. The wholesaler company and the goods involved stay the same, but the role in the process significantly changes the representation of that wholesaler, as viewed by the manufacturer and retailer.

In ebXML, the context for core components can be defined in various ways. In some cases, such as this example, the business domain can provide the context. In other cases, the context can be more complex, with the structure of components nested within other components, either sharing a context or having different contexts.

Core components can exist as individual pieces of data or be linked together in combinations. For example, a clock time and time zone together make up a time component. Note how the time zone also provides a context for the clock time. A data item with a value of 02:25:30 means something much different when followed by GMT or EST than when it measures a runner's time in a marathon. Aggregate components can take on more complex forms, depending on the relationships of the basic components to each other.[9]

Figure 2.5 shows how such core components are assembled to deliver the business transactional information required for ebXML business processes.

Figure 2.5. Assembling ebXML content using core components.

Another benefit of the neutral labeling and identification of commonly used quantities as core components is the ability to create basic transactions and map data between industry domains. The term basic (or lightweight ) transactions refers to the actual XML syntax used in creating the information structures that are exchanged electronically between businesses; they don't contain any unnecessary markup details. In fact, the message details are optimized by using reference codes that uniquely identify each individual piece of information in the transaction.

ebXML calls these reference codes Universal Identifier ( UID ) references, and relates them to pieces of business information about a product or service. Another non-technical term for this idea is Bizcodes. In Figure 2.6, we see how a pair of pliers is described in an ebXML catalogue transaction that a customer receives from a supplier. Each piece of information about the pliers has a UID associated with it, as a Bizcode. Note that suppliers of these kinds of items often use bar codes in a similar way to identify the product itself.

Figure 2.6. Labeling product information using UID descriptors.

Because each piece of information is labeled in this way, companies can consistently and accurately exchange information across industry domains. For example, an accounting system may generically refer to a price as Item Price, while the catalogue system may refer to various prices as Tools Price, Parts Price, or Product Price. Using the UID reference system allows the associations between equivalent items to be determined and implemented by software processes (see Figure 2.7 for an example). The ebXML registry services (described in more detail in the later section "Registries and Repositories") provide the means for lookups by software of such definitions that are stored into the registry itself, using the UID as a unique reference key. A further important note here is that by using the registry in this way, ebXML greatly simplifies the process of maintenance and updating the business semantics about information content when things inevitably change.

Figure 2.7. Cross-referencing data between industry domains with information content.

Now that we've described how core components are used to create units of business information and then referenced in XML-based business transactions, we're ready to proceed to the next piece of the overall ebXML architecture.

Trading Partner Profiles and Agreements

Before companies can do business, they need to understand the rules under which the parties interact with each other. The discussion of EDI in Chapter 5 outlines how trading partners need these agreements to spell out responsibilities, provide the common legal boilerplate language to which the parties can refer, and clear up any misunderstandings before the messages start moving. These same functions appear in ebXML, only ebXML automates the technical aspects of the overall agreement, in an XML document called the collaboration protocol agreement ( CPA ).

In ebXML, each company publishes a collaboration protocol profile ( CPP ) that contains a basic description of its capabilities in terms of the ebXML business processes it supports, along with details about its e-business system's points of access and technologies. For companies that haven't done business together, CPPs offer a way of outlining these capabilities in XML documents, and therefore are machine-readable and -processible. These profiles are essential to finding other companies with the needed capabilities to do e-business. They also provide the raw material for trading partners to develop and negotiate a CPA.

The CPPs list the business processes as defined by one or more industries and supported by the company. Companies developing a CPA will match the business processes they support to those of the prospective trading partner and agree on the common set of processes and messages that they will exchange.[10]

As a further extension of this model, the business process specifications provide an explicit business process specification schema ( BPSS ) in XML that gives the details needed to describe and create a binding agreement. Figure 2.8 shows how an interaction sequence plays out between two partners seeking to do business together. Notice that all relationships are reduced to sets of collaborations between two partners, even if they may actually be part of a broader marketplace and associated agreements.

Figure 2.8. The ebXML contract-negotiation process.

For these agreements to achieve the desired legal and economic effects, they must have the following:

• A computable success or failure state for every transaction

• Permitted means for parties to exchange legally binding statements and terms

• Permitted non-binding statements and terms

• Permitted ways of arranging messages into exchange patterns or sequences that allow for agreements about these patterns in a business process

This diagram has an annotated set of normal items encountered during a business negotiation that leads to a formal agreement of the terms and conditions. The BPSS structure then contains and stores those items and shows how they relate to the business process definitions and messages exchanged. As mentioned earlier, the ebXML registry provides the means to store and retrieve these items and to reuse them between partners.

Registries and Repositories

Web-based registries are perhaps the most critical parts of the ebXML architecture, as well as the ebXML functions with which companies have the most contact as they get started with ebXML. As Figure 2.4 showed earlier, the ebXML registry is the place for industries to file their business process models and objects, and for companies to file their collaboration protocol profiles. Thus, the registry serves as the main point of contact for companies with little or no experience in the industry to get these details.

The actual storage of the business models expressed in XML and profiles associated with the registry are referred to as the corresponding repository content.

Repositories may be physically part of the registry, or may refer to remotely located content stored separately. From the user's point of view, this is mostly just a technical nuance; the user connects to the registry only, and the physical storage associated with the registry is what returns the requested content.

The registry itself provides an index to the items in the repository as well as automated routines for human and machine access to the repository.[11] The registry can also refer to other registries that index related specifications or metadata used by those companies or industries. And it must have the capacity to be continuously updated with new processes, components, and profiles.

Physically, the registry can list any other static software objects and associated processes required to do business in that industry, such as the following items:

• XML document type definitions ( DTDs ) or schemas ("nouns")

• Software programs and scripts ("verbs")

• Tables and lists of values and codes, such as ISO country codes, currency codes, and special packaging or labeling specifications (for example, for hazardous materials)

• Definitions of unique terms

• Industry EDI implementation guides or earlier XML vocabularies

Repositories, on the other hand, store dynamic and transactional information, and retrieval of these objects occurs when using the registry as a lookup index.

Since each item referenced in a registry needs to be accessed by systems over the web, each of these items needs a unique identifier. As shown earlier, companies need to do business both within and outside their industries; therefore, they may access registries in multiple industries, and thus need to relate items from different domains.

Individuals and companies access ebXML registries through both automated and human-readable interfaces. Underneath these access points, the XML-based interactions with registries use the same kind of XML messages as those used to exchange business messages with trading partners. Also, because not all types of content are completely open to everyone, CPAs may be required between companies accessing the registries, as business needs demand. Figure 2.9 shows the functions provided by a registry in orchestrating the various pieces of the ebXML architecture.

Figure 2.9. Functional service view of the ebXML architecture.[12]

Defining specifications for a registry's index is tricky, because ebXML needs to support a wide range of businesses and picking one scheme over another may make the index difficult to use for entire industries or groups of industries. With ebXML, the registry stores metadata, which describes or identifies an object. The registry is connected to the actual items in the repository that contains the objects themselves . Since the metadata for an object includes a globally unique identifier, it provides a way of tracking each item stored. The specifications also list a set of data to describe each registry object, including name, identification codes, and various descriptions, as well as the organizations submitting the item and those responsible for maintaining it.

As noted earlier, ebXML defines the interactions with the registry system in somewhat the same terms as interactions using ebXML itself. It specifies a collaboration protocol agreement (CPA) between the party providing the registry and its clients . It also defines a set of processes for interactions with the registry and separate messages within the processes. And it specifies a mechanism for queries to a registry and responses to those queries. ebXML also outlines processes for registry-to-registry interactions, including a CPA between registries themselves. Finally, it identifies error conditions and messages with remedial actions.

The specifications recommend appropriate security features to limit access to authorized users, but they also note that registries are by nature public facilities. As a result, a company would want to register its overall generic business CPP, but certainly not the definitions of its own private arrangements with customers and partners. Security is needed particularly to control the ability to change the contents of a registry itself and provide librarian management facilities.

While companies need to keep their business CPP details current, registries need to restrict access to only those parties with proper authorization and ownership rights to update the actual profiles. The specifications also recommend digital signatures to provide non- repudiation of authenticity ”a guarantee that the filing took place ”and thus the company cannot claim that it's a forgery.

Registries need to support both human and machine queries. For human queries, registries need to provide the capacity to browse the items based on classifications and intuitive visual groupings, and then allow drill-down for more detail if needed, preferably using a simple web browser interface. Also, traditional webbased arbitrary keyword searching is required, such as the popular search engines already provide for web page content.

Machine queries, on the other hand, are likely to directly reference content itself, using the explicit ebXML unique identifiers or UIDs, either with or without its metadata, for retrieval to a remote computer application.

As a result, registry objects and their metadata need to be accessible as standard XML-based resources over the web. The proposed identification schemes for registry objects meet this requirement. With each registry object having a globally unique identifier, a valid query on that identifier should return that specific repository object, and no more.[13]

The remaining sections of this chapter focus on the specifications that provide the transport, security, and delivery functions in the overall ebXML technical architecture.

The ability of two or more parties to communicate in a distributed network using XML has become one of the hot topics in the XML community, and one from which we will hear much more.