Examining CommerceNet's eCo Framework
by Edd Dumbill
|
Pages: 1, 2
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:
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.
