By  Kristian Cibulskis | Source Code for this Article

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

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.

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.

3 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