eCo Architecture
by Edd Dumbill
October 27, 1999
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:
http://www.mycompany.com/BusinessGetServices
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
http://www.commerce.net/eCo 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 = 'http://www.commerce.net/eco'>
<Head>
<Identifier>http://www.acmeyoyo.com/acmeInterface</Identifier>
<Creator>http://www.acmeyoyo.com/~coyote</Creator>
<Date>19991028</Date>
<Version>1.0</Version>
<TimeToLive>86400</TimeToLive>
<Description>This document contains blah...</Description>
<Label>Acme YoYo Document</Label>
</Head>
...
</acmeYoYoCoDoc>
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 XML.org and Biztalk.org
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.
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.