Examining CommerceNet's eCo Framework

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.

[1] [2] Next