By  Kristian Cibulskis | Source Code for this Article

Figures: Click to Enlarge
Figure 1 | Figure 2 | Figure 3 | Figure 4 | Figure 5

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.

2 of 5

About the Author: Kristian Cibulskis is a freelance consultant focusing on Enterprise Java and XML solutions.

Other Recent Articles by Kristian Cibulskis

• An Introduction to BSML
• The ebXML Registry
• Epic Editor 4.2 by Arbortext

Reader Feedback | 2 Replies | Post Message

ebXML Registry English Version is now available by KTNET.
Posted by Chaemee Kim on Feb. 4 @ 12:14 AM

Dear Kristian,

This is ebXML Lead in KTNET.
I appreciate you quote KTNET's ebXML Registry in your article.

Now we're providing English Version of ebXML Registry 1.0 at http://www.gxmlhub.com/english/index.htm

Plz, revise it correctly.

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.

v good article

Post Feedback