Examining CommerceNet's eCo Framework

October 27, 1999

Edd Dumbill

XML is having a big impact on the world of e-commerce. Many recent initiatives in e-commerce interchange protocols are based on XML. These protocols tend to concentrate on solving the problems of a particular industry, providing solutions for "vertical" markets.

One example of such an initiative is the ICE protocol. Although originally geared to syndication between content providers, ICE has applicability not only for networks of publishers, but also for other syndication markets, such as the syndication of vendor product catalogs to resellers.

Another initiative is RosettaNet, which is particularly focused on creating electronic business interfaces in the IT supply chain.

These initiatives are great news for companies involved in those particular segments. However, if you look at each of these applications, there are certain things they've got in common: the notion of parties wanting to trade or exchange, the notion of a product, and so on. In each of these efforts the implementation of these notions is different. If you wanted to start such an initiative in your own industry, you'd have to reinvent a lot of these basic concepts as well.

In addition to having commonality in entities, many of the existing e-commerce initiatives share common processes: the registration of a new customer/trading partner, the exchange of product data, etc. Processes like these would also have to be re-implemented if you were to start an e-commerce protocol for your own industry.

This is where the recently announced eCo Framework comes in. Its aim is to provide basic framework specifications for identifying, defining, and implementing common entities and processes, in order to provide a foundation on which vertical e-commerce applications can be built.

The eCo Framework

Over thirty-five companies have contributed to the eCo work. Ranging from software companies like Microsoft and Netscape, to hardware vendors 3Com and Cisco, to financial organizations such as American Express and Mondex International. The eCo Working Group forms a part of CommerceNet, an e-commerce industry consortium.

Their goal is to make e-commerce "more affordable and easy to implement" by providing the framework to make online businesses interoperable at a more fundamental level than current initiatives allow.

The eCo Working Group has tackled the interoperability problem by looking at three key areas in which to provide a platform for e-commerce services:

  • Semantic integration of multiple databases: enabling businesses and markets to integrate and use data from each other
  • Trusted open registries: enabling, for example, the "discovery" process of the capabilities of a particular business, and their products or services
  • Agent-mediated buying: the aiding of the buying process by a software agent, for instance in aggregating prices from different suppliers

As a result of their work, the group has produced two documents: the eCo Semantic Recommendations, and the eCo Framework Specification.

Semantic Recommendations

As we've already seen, different industries have different semantics. For instance, ICE has a notion of the content syndicator, while RosettaNet's PIPs have a notion of a partner company.

No one schema could practically define all the roles needed by e-businesses. Yet if there is no integration between multiple semantic spaces, there's no scope for semantic re-use and integrating business across these spaces becomes a costly exercise.

The purpose of the eCo Semantic Recommendations is to pave the way for the development of interoperable specifications for the semantics of vertical industries. The eCo group points to the vast potential of schema repositories, which could serve as "semantic registries", if the guidelines for creating such schema definitions can be agreed upon.

The recommendation document presents important design approaches for semantic definitions, drawing on an analysis of the good and bad points of existing business semantics. The initial aim of the group was to provide XML schemas which expressed the semantics of business documents: but they realized this was a task which required more time and a broader representation than they possessed. So instead, they laid the foundations for a successor work in that area.

The key recommendations to come out of this exercise were:

  • The use of XML Schemas for the expression of business semantics, on the basis of their validation and extensibility.
  • Schemas should be modular: to facilitate reuse, and extension in vertical applications.
  • Best-practice in use of XML:
    • Readable, understandable XML documents, based on the user point of view, rather than the programmer's.
    • Use of schema-validation, rather than reliance on XML well-formedness
    • Use of markup to denote sub-structures: for instance, don't say <name>Firstname Surname</name>, say <name> <firstname>Firstname</firstname> <surname>Surname</surname> </name>.
    • Use of well-known data types
    • Use of external references to specify custom code-lists: don't design them direct into the schema
    • Expression of relationships between data elements in different classification schemes in the schema.

eCo Architecture for Electronic Commerce Interoperability

The second document from the eCo working group presents an architecture in which business can begin to interoperate and work with each other.

Broadly, the specification divides up the space of e-business into the following hierarchy:

  • Networks, such as the Internet, via which business can interconnect
  • Markets, the so-called "vertical" collections of businesses who trade in a common area
  • Businesses, who provide and use:
  • Services, which conduct:
  • Interactions, exchanging:
  • Documents, containing:
  • Information items

The framework addresses itself to each of these levels, adding at each level the notion of a type registry, in which item-types are stored. It is intended that applications use sub-classing, so a type for a data-communications device market might be refined by modem markets, ISDN TA markets, and so on.

These varying levels of complexity allow businesses to get involved in an eCo marketplace at a level appropriate to their current resources. At a high level, which most businesses should be able to fulfil, registering a business in a marketplace is a process which merely involves the creation of one simple XML document.

In the next section, we'll see how these levels can be used in practice to connect businesses.

Layers in the eCo Architecture

As stated in the previous section, the eCo architecture divides the space of e-commerce into the following layers:

  • Networks, such as the Internet, via which business can interconnect
  • Markets, the so-called "vertical" collections of businesses who trade in a common area
  • Businesses, who provide and use:
  • Services, which conduct:
  • Interactions, exchanging:
  • Documents, containing:
  • Information items

This section will look at these layers, how they can be implemented, and their relation to each other. It will not present full details of each layer: you should refer to the full specification for complete details.

The eCo specification defines document types for the description of each of the layers: they are presented as DTDs, XML schemas and XDR (XML-Data Reduced Set—for BizTalk compatibility).

Additionally, the implementation of each layer requires the exposure of a published interface, which is the point of interaction for applications that wish to query the layer.

As a prelude to examining each of the layers, we'll first cover the basic conventions for communication within an eCo architecture.

Network transport and interaction conventions

As mentioned above, a point of interaction with an eCo layer on a server is called a published interface. These interfaces are identified by a unique URI, to which queries can be passed.

HTTP is used as the basic query transport within eCo, as it is a widely understood and supported protocol. Parameter passing and encoding is performed using the same procedures as apply to HTTP.

As an example, a query to a company's public interface, to retrieve a list of services it offers, may be an HTTP GET of the following URL:

Extensions to the set of eCo-defined queries are denoted by query names with a preceding underscore.

eCo implements a "bootstrapping" mechanism—analogous to robots.txt for search engines—to enable visitors to establish that a particular site has eCo interfaces available. This consists of an XML file called eco.xml, placed in the document root: this file establishes basic administrative information and includes a specification for each publicly available interface.

eCo documents

eCo requires some basic conventions in XML documents used as part of interactions. The first of these is the use of the URI to define the eCo namespace. The second is a mandatory header section which provides, amongst other information, an interface URI and a time-to-live (TTL). The TTL specifies how long the document in question should be treated as valid, thereby solving the problem of eCo implementations hanging on to old information about interfaces and other items of data.

An example header might look like this:

<?xml version="1.0"?>

<acmeYoYoCoDoc xmlns = ''>







<Description>This document contains blah...</Description>

<Label>Acme YoYo Document</Label>




The use of the eCo namespace and the <Head> element defines an eCo document.

Common queries and document types

eCo mandates the implementation of a few basic queries and document types to facilitate the operation of the framework as a whole.

The queries GetSupportedVersions and QueryInterface provide support for negotiating the level of eCo support and enumerating the queries supported by a particular interface.

To support these, and other, queries, the following document types are defined (available as schemas and DTDs within the eCo spec):

  • EcoVersionsList: to indicate which versions of eCo an interface supports
  • EcoInterfaceList: presents information about published interfaces
  • EcoInterfaceDefinition: provides an enumeration of the queries supported by an interface and the parameters each query requires
  • EcoTypeList: used to represent a list of references to document types held in a type registry

Looking at the layers: Start at the top

The highest level layer in the eCo architecture is the "Commerce Network" layer. A network, such as the Internet, contains many interacting and trading communities. These communities are identified as Markets.

The eCo Network published interface provides queries for discovering the markets within a network: NetworkGetMarkets, NetworkGetMarketTypes, NetworkGetMarketsByType. The first and third queries return an EcoInterfaceList document as defined above. The second query returns an EcoTypeList. You can see that each layer in the architecture is represented by an interface—essentially, it extends the basic eCo document—and that the type indicates a particular refinement of a layer. Thus the need for the two basic mechanisms in eCo, published interfaces and type registries.

The other query available on a network is NetworkGetProperties. The ...GetProperties query is common over the eCo layers and follows a convention of appending a query name onto a layer name "stub", to form the final query name. This query returns a document of the type NetworkPropertySheet, which describes the network.

It is important to note that many networks other than the Internet can and will exist.

The eCo Market Layer

Most of today's e-commerce initiatives can be said to exist within a single market type. The eCo Market layer provides the framework to embrace these existing communities. Essentially, an eCo Market can be thought of as a portal to businesses involved in a particular market.

Closely following the pattern established in the Network layer, the published interface to a Market provides mechanisms to discover businesses and business-types within a particular market. Typing allows a Market to define a particular area of trading—say communications devices—and then to identify the areas of service of particular businesses within the market by means of their type.

The property sheet for a Market provides many definitions of conventions and types used within a particular market. It enables the discovery of the registries for types used in the subordinate layers of this market, the administrators of the market, and business process definitions common to the market. Additionally, facility for MarketSpecificProperties is provided, essentially enabling custom properties to be implemented for a particular market.

The adaptability and sufficiency of the Market layer will be an important factor in eCo's integration with existing e-commerce markets and mechanisms.

The eCo Business Layer

Most relevant to an organization seeking to enter an eCo market place is the Business layer. This layer enables the description of a business and the services it offers. As with the other layers, a GetProperties query is required. Additional queries supported facilitate the discovery of business services, and also the markets that a business is listed in.

The Business property sheet allows the definition of address and contact details for the business, plus similar properties to those allowable for markets: the definition of type registries for subordinate layers, and specific business properties.

A minimal implementation of eCo compliance for a business would involve the construction of a BusinessPropertySheet document, and the placing of this document on a web server at the path BusinessGetProperties, so implementing the query of that name. In general, the GetProperties queries are the only ones that are mandatory in the eCo spec. Obviously, only implementing those methods would provide limited functionality: yet it would enable the discovery of your business within a network and market place.

A walkthrough of the creation of such a document is given on the eCo web site.

The eCo Service and Interaction Layers

It is at the Service layer where the implementation of e-business can really get started. Service, in the eCo sense of the word, means an interface to a business process. Examples of services for an online music retailer might be:

  • Buy a CD
  • Retrieve the R&B catalog
  • Discover on which media types a particular title is available
  • Become a reseller

Each of these particular services will then be composed of interactions which, when executed, will lead to the fulfillment of the service. In most cases, interactions will be ordered in a particular manner to fulfill a service: this ordering is defined as a Service Choreography. Within the Business and Market layers we referred to the ability to define business processes: such definitions may be used to express the ordering of interactions within a service.

The Service interface itself supports the expected queries: retrieving a property sheet, enumerating subordinate interactions. It also provides the ability to have SubService definitions. Briefly, sub-services allow the encapsulation of multiple services in one. For example, if Business A is ordering $20,000 worth of equipment from Business B, and in so doing seeking to establish a credit account, a sub-service would be the establishment of that credit account. A sub-service may optionally be "masked" within a service: so Business B could hide the mechanics of credit application from Business A and perform it implicitly.

Interactions provide a minimal interface themselves, with the real value being in the information contained in their property sheets. Within an InteractionPropertySheet is defined the possible input and output documents to that interaction, along with the URI to which those documents must be sent to perform the interaction.

One of the real benefits of eCo for businesses with existent EDI systems is that Services and Interactions can be used to wrap these systems, with no re-implementation of the existing system necessary. This provides the opportunity for businesses to move relatively rapidly into an eCo market place.

eCo Documents and DataElements

These remaining two layers allow the description and re-use of document and data types within interactions. It is here that the power of reusability and extensibility can be exercised, with extensions to document types permitted on a Network, Market and Business specific level.

Type registries

Type registries perform the function of cataloging document types, and the relationship between those types. In a manner similar to the eCo Layers, they are accessible via a URI. For example, an application may want to discover all the refinements of a "product specification": on issuing a query to retrieve descendants from the registry, it might receive "technical product specification", "manufacturing specification", "performance specification" and so on.

Type registries are used at the various layers to provide Market registries, Business registries, Interaction registries, Service registries and Document and Information Item registries. Each of these perform type-directory services for their particular layers.

Other questions an application might ask of a registry include "what kinds of shipping are available?" and "what kinds of manufacturer are available in this registry?".

Schema repositories such as and could be given eCo registry interfaces to enable them to expose their document types for use in eCo market places. This is, of course, conditional on the use of the Semantic Recommendations in the construction of those schemas.

eCo compliance

In the Business layer we saw that the minimal implementation of a property sheet for a business is all that is required to fulfil the requirements of that layer. In fact, the implementation of the Business layer itself is all that is absolutely required to conform to the eCo Architecture spec. So, there's no reason you can't be eCo-compliant in a few minutes time!

Throughout the specification various queries are marked as mandatory (generally facilitating the retrieval of property sheets), and if layers over and above the Business layer are implemented, they must include these queries.

Although access to eCo facilities may be provided via protocols other than HTTP and HTTPS, they are not allowed to be the sole protocols supported. This way, interoperability is assured.

Summary—Implementing eCo

We have seen the various levels of interfaces and basic mechanisms used within eCo. One of the qualities of eCo that makes it a good candidate for widespread adoption is the simplicity of the basic structure and conventions used. If that is considered along with the stepped levels of compliance possible, there's no reason why eCo-enabled market places should not be with us soon.

The implications of conformance to the specification are many, and provide a whole new arena for application support and tool development. The administration of a market place, for instance, would practically require a dedicated tool. As we've seen with ICE, it could take some months before this tool support is readily available.

In general, the eCo specification is to be praised for its embracing of the extensible nature of XML and associated standards, and its flexibility in enabling both the development of new e-commerce solutions based entirely on eCo, and the leveraging of existing systems.