CommerceNet eCo Framework

CommerceNet eCo Framework

Given the preceding definition of the various components of an e-business system, there are a variety of models to show how these various components interact to comprise a complete e-business system. One of the most accepted models for e-business interaction is the CommerceNet eCo Framework for e-business architectures.

The eCo Framework provides an architectural framework that enables businesses to dynamically discover each other on the Internet and interactively determine how they can do business with each other. The main goal of the eCo Framework, as defined in 1998, is to bring e-commerce and e-business processes from a systematic, technical level to a business level by providing a means for businesses to present accurate and stable interfaces to their partners in a loosely coupled manner, abstracting possible changes in an organization’s internal processes, organization, or technology implementation. This allows potential trading partners in an e-business process to only describe what they do instead of agreeing on what they do or how they will do it.

The eCo Framework consists of an architecture and a set of semantic recommendations that serve to describe e-business systems in seven essential layers that answer the follow-ing critical business and systems issues:

   The location of other businesses and trading partners

   Determining whether partners want to do business with each other and how they can participate within a market

   The discovery of the services they offer

   The kinds of interactions to expect

   The protocols that will be accepted

   General issues that would prevent or allow systems to communicate

   Application interfaces

   Determining what modifications need to be implemented to ensure interoperability between systems

   Required information to exchange

The eCo Framework also provides guidelines and recommendations for creating e-busi-ness-focused semantic types and definitions to assist in automated processing. In addi-tion, this semantic recommendation provides a means through which information on e-commerce systems can be communicated, a method for querying that information, and a definition of the structure that will be used to return that information.

Therefore, the eCo Framework is more of a business-level framework rather than a tech-nical specification. The framework defined allows businesses to publicly define and expose their XML-encoded descriptions of their e-business systems in order to allow potential trading partners to get the information they need to enable interoperability. In order for this information exchange to occur between trading partners, a common under-standing is needed of the basic components that make up an e-business environment and how those components relate as well as a common means for exposing information about these components.

Many subsequent efforts, such as Web Services, have borrowed from the eCo Framework in order to structure and guide their work. It is important to note that the eCo Framework is a theoretical guide and approach to e-business systems and not a specific implementa-tion, per se. As such, it is up to efforts such as Web Services in the application-to-appli-cation realm and ebXML in the business-to-business realm to turn theoretical probability into practical reality.

The basic structure of the eCo Framework is outlined at http://eco.commerce.net/ how/index.cfm and is shown in Figure 20.2.

The architecture is related as a layered “stack” that represents a typical e-business envi-ronment. Each layer is dependent on the layer beneath it. In the case of the eCo Framework, the layers are defined separately through “type registries” that define some aspect of information about the e-business environment and enable trading partners to obtain information at each layer of offered services for potential use.

As in other models, the Network layer describes the physical networks (in our case, Internet) that contain various marketplaces, or “markets,” for supply chain interaction. Each market in the network is an independent aggregation of parties that are made up of one or more businesses described in the Businesses layer of the eCo Architecture. The Market layer is responsible for business aggregation and identification, such as a busi-ness’s location and other related information. A business can participate in multiple markets, and vice versa.

The Services layer provides a means for businesses to describe the types of business ser-vices they offer, the required interfaces, and other information needed to actually make use of a particular business service, such as product ordering, payment, catalogs, or any other specific business process. These processes have their interfaces described in this Services layer. Some of these services may be defined in a standard manner within an industry or may be specific to an individual company. Services may be comprised of  “subservices” that are also described in this layer. There also may be dependencies or invocations of other services in order for a given service to complete its execution.

The relationships and interactions between services are described in the Interactions layer, which describes the sequence, events, “choreography,” and types of interactions allowed between service and process components. Each of these interactions contains a set of documents needed to actually perform the interaction or services request. Services are composed of a set of document exchanges that can be defined in the context of “interactions.” Interactions are framed in a request/response mechanism that is event dri-ven when a party requests a particular document from another. These documents are defined in the Documents layer of the eCo Architecture. The documents are the actual units of business dialog and interchange, which are composed of atomic elements described in the Information Items layer. Finally, we arrive at individual data elements and attributes that comprise each type of document used by an interaction. These data elements may be defined by industries and standards organizations, independently defined by businesses themselves, or a combination of both of these possibilities.

The eCo Architecture also defines a mechanism to query and access the actual informa-tion and properties described at each layer. This query mechanism allows trading part-ners to obtain information about a particular implementation of that layer and use that information to determine the extent to which it can interoperate with the other party. By examining all the layers implemented by a fully eCo-compliant system, prospective trad-ing partners can make intelligent decisions about their interoperability with the system.

In addition to the architecture and mechanisms for querying that architecture, the eCo Framework defines “type registries” that are associated with each layer of the architec-ture and describe the various document and element type components in an e-business system. Type registries allow hierarchies of definitions to be asserted within a system, determine the equivalency of types in the same registry, and determine the relationships that exist between types. For example, a market for automotive parts might be further refined by breaking it down into markets for engines, tires, and so on. Registries also expose their interfaces in the same way that layers do so that their information can be accurately queried. As a difference with the previous definition of registries and reposito-ries, these eCo registries are only used to store type information and not business docu-ments, data dictionaries, or service descriptions. Each layer in the architecture is defined by referencing type definitions in one or more registries, with the notable exception of the Network layer. For example, businesses can type themselves by referencing a busi-ness registry, and documents can type themselves in a documents registry.

In this manner, a comprehensive architecture can be defined to enable the automatic interaction of business parties as required by e-business systems.