The electronic business extensible markup language, better known as ebXML, aims to allow companies of any size to conduct business electronically via the Internet. Obviously, companies doing business together isn't a new idea. EDI (electronic data interchange) has been used between large businesses to conduct electronic business since the 1960s. However, EDI often requires the implementation of custom protocols and proprietary message formats between the individual companies.

Because of this, its use has been restricted to larger corporations that can absorb the initial costs required to do business in this fashion. The goal of ebXML is to provide a flexible, open infrastructure that will let companies of any size, anywhere in the world, do business together.

The ebXML effort is jointly sponsored by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and OASIS, the Organization for the Advancement of Structured Information Standards, along with approximately 30 other industry leaders. UN/CEFACT is also the standards body behind EDIFACT, an EDI standard used heavily throughout Europe and the Pacific Rim.

The ebXML group has delivered three key components of a next-generation B2B infrastructure:

• An XML messaging specification
• A trading partners agreement specification
• A registry/repository specification

A second initiative at OASIS has begun to create a Universal Business Language (UBL), essentially a standard set of XML business documents to be used for B2B transactions. UBL is based on xCBL 3.0, which is freely available and widely deployed.

In this article we'll explore the ebXML Registry/Repository, one of the cornerstone components of the ebXML architecture.

What Is the ebXML Registry?
The ebXML Registry serves as a central repository that enables businesses to share information. The ebXML Registry Services specification defines it as "a set of services that enable sharing of information between interested parties for the purpose of enabling business process integration between such parties based on the ebXML specifications." So, in addition to being a directory of content, it's a storage mechanism. Essentially, it's a place where people can locate, store, and retrieve objects with the intention of performing B2B transactions. Figure 1 illustrates the role of the registry in a typical B2B scenario.

What types of objects does the registry handle? Actually, the Registry Information Model (RIM) is described in its entirety in another specification (see Resources section). At its core are two key objects: the RegistryEntry and the ClassificationNode.

The RegistryEntry object is meant to contain an ebXML-specified object. For example, a Collaboration Protocol Profile (CPP), a Collaboration Protocol Agreement (CPA), a UBL document, or even a software component could be held within a RegistryEntry.

ClassificationNodes are used to create tree structures that are then used to define Classification schemes or ontologies. Most of the other registry objects are associated with one or more RegistryEntries and are described in Table 1.

Classifications
Before we discuss how to interact with an ebXML Registry, it's probably worthwhile to discuss the concept of Classifications. In an ebXML Registry a classification hierarchy exists independent of any objects to be classified. A classification hierarchy is described by a collection of ClassificationNodes.

For example, we may have a "Geography" classification tree, as depicted in Figure 2. This classification tree simply describes the hierarchy of possible classifications. For example, it indicates that "Korea" is a member of "Asia." Both Korea and Asia are ClassificationNodes.

When an object is stored in the registry, it can be associated with a number of ClassificationNodes. For example, a company submitting a document for a company in Korea could associate that document with the Korea ClassificationNode. This is called a Classification. Then, when someone queries for all the companies in Asia, the Classification hierarchy is used to determine that any entry with an association, or Classification, directly to the "Korea" ClassificationNode is also indirectly Classified by "Asia."

When operating with an ebXML Registry, it's important to remember the distinction between a ClassificationNode and an actual Classification. Both can be created, queried, and modified, so you need to know which one you actually intend to work upon.

The Public Interfaces
How do we access the objects described above? The ebXML Registry specification calls for two basic interfaces for interaction with the registry: the ObjectManager interface and the ObjectQueryManager interface. A UML diagram of these interfaces can be seen in Figure 3. The ObjectManager interface provides life-cycle methods for the objects maintained by the registry while the ObjectQueryManager interface provides methods for locating and retrieving objects from the registry.

While the specification doesn't explicitly describe an implementation technology, it does describe the exact functions provided by each of these interfaces. However, the recommended implementation technology is actually SOAP and XML. So every time you read something about a given method with certain parameters, think of a SOAP request as the method with an XML payload that represents the parameters.

The ObjectManager Interface
An object in an ebXML Registry can exist in one of four basic states. Figure 4 depicts the various object states in the registry and the ObjectManager methods that cause the various state transitions.

When an object is first introduced to the registry it exists in a Submitted state. From there the object can be moved into an Approved state. Once an object has reached that state, it's ready for use by the participating business parties. Objects in the Approved state can continue to be updated and modified. A time may come, however, when this object needs to be retired. At that time the object can be moved to a Deprecated state. Once in this state, the object continues to be accessible but may no longer be modified or updated. Eventually it may be moved to a Removed state where it is no longer accessible by the participating business parties. Effectively, the object has been removed from the registry.

The ObjectManager interface provides the methods to create new objects and affect state transitions on existing objects. However, all of these methods are not available to the general public. We'll take a look at the security restrictions placed on these methods later.

The ObjectQueryManager Interface
Now that we know how to create objects within the registry, we need a way to find and access those objects. That is the purpose of the methods provided via the ObjectQueryManager interface. Just as SELECT statements constitute the majority of requests processed by a database, these query methods are the most common requests of an ebXML Registry. In that light it accounts for why over 50% of the content of the ebXML Registry specification has been devoted to the query interfaces!

To support the various types of queries that users may want to execute, three different query methods have been defined. Any registry that claims to be ebXML compliant must support the first two, known as the Browse and Drill Down Query and the Filter Query. The third is a SQL Query interface, which isn't required by the ebXML specification. However, the specification makes it clear that if you do support a SQL Query type interface, it must meet the specifications described in the ebXML Registry specification. It's an optional, yet standardized, interface. Let's take a look at each of these in detail:

Browse and Drill Down Query
As you might imagine, the simplest type of query interface is an interactive query in which the user provides the "filtering" capabilities. The Browse and Drill Down Query of an ebXML Registry provides this capability. Three methods provide this functionality.

The first one is getRootClassificationNodes, which basically returns all ClassificationNodes in the registry that don't have a parent. The only parameter that can be specified, namePattern, works like a SQL-92 LIKE clause, allowing you to specify a wildcard pattern for the query.

Now that you have a collection of root ClassificationNodes, you may want to "drill down" into one of these nodes by retrieving all of its children. This is accomplished through the getClassificationTree method, which has two parameters, parent and depth. Parent is the parent for which the children are being retrieved. Depth is an optional element. If it isn't specified, it defaults to 1, and only the immediate children of the given parent are retrieved. Otherwise, depth refers to how many levels of the hierarchy of a given parent should be retrieved. A value of zero or less indicates that all children should be retrieved.

Once users have browsed their way down to a ClassificationNode that they're interested in, they'll most likely want to look at the RegistryEntries associated with that ClassificationNode. This request is made through the getClassifiedObjects method which is supplied with a list of ClassificationNodes that the user is interested in. The registry then returns all objects that are either directly classified by the supplied ClassificationNode or directly classified by a descendant of the supplied ClassificationNode, and thus indirectly classified by the parent ClassificationNode. If multiple ClassificationNodes are supplied, they are AND'ed together. That is, the object returned must be classified, either directly or indirectly, by each of the supplied ClassificationNodes.

It's easy to see how the Browse and Drill Down Query interface could be used to build an interactive GUI. This is exactly why it was created: to facilitate the creation of ebXML Registry browsers that a business could use to locate a particular service.

Filter Query
While the Browse and Drill Down Query interface is well suited for building a GUI, it isn't very powerful. To support more complex queries, the Filter Query interface is provided, which supports an XML syntax that describes a set of class filters. Each of these class filters is a predicate clause intended to restrict the result set.

The topmost restriction when performing a Filter Query pertains to the type of object you're looking for. For example, you may be interested in finding a RegistryEntry, an AuditableEvent, or a ClassificationNode. From there you specify various class filters to restrict the result set. A working example may be the best way to describe how this Filter Query interface operates. Take a look at the sample in Listing 1, which is taken from the ebXML Registry Specification.

• Line 1: This identifies this request as a request for a RegistryEntry. Other possible types of queries include the AuditableEventQuery, the ClassificationNodeQuery, the RegistryPackageQuery, the OrganizationQuery.
• Lines 2-4: This describes the first filter that's placed on our return items. In this case we place a restriction on the status attribute of the RegistryEntry in which the status must be equal to "Approved." A full set of string operators, such as EQUAL, STARTSWITH, and ENDSWITH, as well as numerous other operators for boolean and numeric values, exist.
• Line 5: This section begins a filter on the Classifications associated with this RegistryEntry.
• Lines 6-9: In this first section we specify that there must be a ClassificationNode that starts with, or has a parent identifier of, urn:ebxml:cs:industry. This indicates that we are placing a restriction on the industry of the result set. The next predicate furthers that restriction to the "Automotive" industry through an XPATH-like identifier.
• Lines 10-13: Similar to the previous clause, this clause restricts us to a particular geography, namely Japan.

Once the XML describing your query has been created, it can be executed by making a call to the submitAdhocQuery method of the ObjectQueryManager interface.

As you can see, the Filter Query provides the capability to execute rich and complex queries against an ebXML Registry. This query interface is mandatory for any ebXML registry. However, many people are familiar with a different query language, namely SQL. To provide a query interface that's already known by the masses, the ebXML specification also specifies an optional SQL Query interface.

SQL Query
A given ebXML Registry implementation may choose to support the optional SQL Query interface. This interface supports a basic subset of the SELECT statement as described by the SQL-92 standard. It's also been extended to allow for the calling of stored procedures. Although the ebXML Registry specification does supply a sample relational database schema for data storage, the data can be stored in any manner and still be ebXML compliant.

The specification essentially defines a binding between the RIM and a set of fictional database tables that are used in a given SQL Query statement. For example, if you wanted to find the global ID of any RegistryEntry with a name containing "Java" and a version number other than 2, you could issue the following SQL Statement to the SQL Interface:

SELECT id
FROM RegistryEntry
WHERE name LIKE '%Java%'
AND majorVersion > 2

When querying ClassificationNodes, the primary identifier is a unique ID created by the registry. Using these IDs you can query other nodes by parents and so forth. However, an alternative identifier has also been provided for use in SQL Queries. Each ClassificationNode can also be located by an XPATH-like expression describing this node. An example path for a ClassificationNode would be something like "/Geography/Asia/Japan/Tokyo".

To submit a SQL Query, the text of the SQL statement is passed as a parameter to the submitAdhocQuery method of the ObjectQueryManager, just as a Filter Query would be submitted.

Content Retrieval
The query methods we've examined don't return the actual content we're interested in. Rather, they return a unique identifier of the RepositoryEntries that we want to retrieve. The only thing left to do is to retrieve our actual data. To do this, we simply call the getContent method and supply a list of identifiers for the objects we wish to retrieve. If there are no errors in retrieving the data, a success response is returned along with the requested data. Each requested object is returned as a separate, additional payload. Keep in mind that you can store any type of data in the registry - not only XML, but other document types, object models, and even software components.

Security
While the Registry Information Model is capable of supporting quite a sophisticated security model, the current ebXML Registry specification calls for a minimalist approach to security. The basic philosophy is that "Any known entity can publish content and anyone can view published content."

To meet the above requirement, the specification defines three different types of users: RegistryGuest, ContentOwner, and RegistryAdministrator.

The RegistryGuest role describes any unauthenticated use of the registry. According to the basic security philosophy, anyone can view published content. Therefore there's no need to authenticate a large portion of the user community. A RegistryGuest should be able to call any read-only, getXXX(), methods on any registry objects.

The other two roles, however, require authentication to the registry. Since the registry doesn't support the concept of a session containing multiple messages, each message is treated as an independent request that potentially needs to be attributable to a particular principal. The specification requires that a registry use "a credential-based authentication mechanism based on digital certificates and signatures." Given an authentication mechanism, we can now determine who is making a particular request, if necessary, and which role that user has in the registry.

The ContentOwner role is implicitly granted to someone who is the submitter or owner of registry content. ContentOwners can access all of the methods available on the objects that they own. This includes the life-cycle methods of the ObjectManager interface. The RegistryAdministrator role is a super-user role assigned to the administrator of the registry. A RegistryAdministrator is able to call any method on any Registry object.

While the current registry specification describes a minimalist security model, the actual RIM can support a much richer security model. In the future, the Registry specification will most likely support more complex ACL and role-based security for individual objects.

What About UDDI?
While some people believe that the ebXML Registry and UDDI are in competition, they are actually complementary. A key distinction between the two that must be understood is that while UDDI contains a directory of references to Web services information, the ebXML Registry contains the objects themselves. Actually, the two technologies are best used in conjunction. A company interested in finding a new ebXML business partner would first use UDDI to locate a particular ebXML Registry/Repository. This search would return a reference to an ebXML Registry. The company could then access the ebXML Registry to discover the CPP for their new potential partner and then initiate a new CPA.

Implementations
If you're interested in gaining some hands-on experience with an ebXML Registry, there are two basic paths you can take. The first is to download and install an implementation of an ebXML Registry. Sun has a free J2EE implementation of the ebXML Registry specification available for download (see Resources section). Although it includes instructions for deploying on the iPlanet Application Server, it can be deployed on any J2EE application server.

The second path is to access an external ebXML Registry hosted by another company. Two companies currently working on public ebXML servers are the Korea Trade Network and the DISA Registry Initiative (DRIve). The Korea Trade Network provides an openly accessible registry service. However, most of the site is in Korean, so if you can't read it I suggest using something like AltaVista's Babel Fish to translate the pages in real time. The DISA Registry is currently under implementation. However, as ebXML gains momentum, more public ebXML Registries will begin to appear.

The Future
Several companies are working to provide commercial implementations of the ebXML Registry and other core technology components of ebXML. Over the next six to 18 months the UBL group will be producing business schemas that will be freely available to the public. While the ebXML and UBL technologies are still in their early stages, they have a huge amount of support in the industry. Given this amount of support and the clear opportunities in B2B transactions between companies of any size, this technology is one to watch this year.

Resources

• ebXML home page: www.ebxml.org
• OASIS home page: www.oasis-open.org
• Registry specification: www.ebxml.org/specs/ebRS.pdf
• Registry information model: www.ebxml.org/specs/ebRIM.pdf
• Using UDDI to find ebXML registries/repositories:www.ebxml.org/specs/rrUDDI.pdf
• Sun's ebXML registry/repository implementation: www.sun.com/software/xml/developers/regrep
• Korea Trade Network: www.ebxml.or.kr/registry/index.html
• AltaVista Babel Fish: http://world.altavista.com
• DISA registry initiative: www.disa.org/drive

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Source Code
• Figure 5