Registries and Repositories

Registries are the parts of the ebXML technology with which companies will probably have the most early contact, when searching for specifications and trading partners . As early as ebXML's third meeting in May 2000, Klaus-Dieter Naujok, the chair of ebXML, called the registries and repositories "the key to the whole initiative."[17] As a result, this part of the ebXML initiative has received more attention and scrutiny during its development than most other aspects of the project.

Readers will see in this chapter and throughout the book both the terms registry and repository, which need to be clarified. According to the ebXML registry services specification:[18]

The ebXML Registry provides 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. The shared information is maintained as objects in a repository and managed by the ebXML Registry Services defined in the ebXML Registry Services Specification.

Most of this part of the chapter, therefore, focuses on the registries that perform these services, rather than the repository that stores the objects.

Registry Functions and Locations

Registries perform several important functions for ebXML, including, but not limited to the following:[19]

• Submission of industry-wide schemas or document type definitions (DTDs) that define the industry messages and vocabularies

• Submission of industry business process models, from which are derived message choreographies, core components and their industry context, and industry-specific data items used in messages and data services

• Submission of company collaboration protocol profiles (CPPs) that identify the company and describe the supported capabilities and services related to the content indexed in that registry

• Discovery of trading partners, resulting from searches, either human or automated, for companies meeting certain criteria, or from manual browsing through lists of CPP entries

There are few precedents for these kinds of services, but several suggestions have been made for their operation. The specifications list potential hosts to include public and private web sites, as well as application service providers, or virtual private network services.[20] As of March 2001, organizations began to announce their plans to develop or host ebXML registries, including Data Interchange Standards Association (DISA), which will include access to the X12 EDI standards as well as XML industry vocabularies supported by DISA.[21]

Registry Technical Architecture

Because many different kinds of companies and organizations will want to access ebXML registries, the technology proposed for them needs to be quite flexible. Registries will need to support access from normal web browsers, which don't have many builtin capabilities for accessing databases like those maintained by registries. As a result, the registries themselves will need to provide those capabilities as part of their host software.

At the same time, registries can expect some enduser software to have the capability to access the registries and work with the objects stored in the corresponding repositories. As ebXML begins to be implemented, some vertical market software or packages designed for registry management will likely appear on the market, with much more power than the routine web browser. These packages will have the registry interfaces built in, and registries will need to recognize their presence, such as through a logon script, and bypass these same interfaces provided at the host.

A third alternative implementation is through an automated interaction between the end- user 's server and registry, where the company has made arrangements in advance to access the registry on demand for specific services. For example, a company needing frequent competitive bids for goods or services would be a candidate for this scenario.

Companies communicating with the registry use the same message formats as they would use for other ebXML messages. The section of this chapter on message services describes those formats in detail.

When companies use ebXML for exchanging messages, they first need to establish a trading partner agreement, called a collaboration protocol agreement ( CPA ) in ebXML parlance. Companies making their first or infrequent queries to a registry are not likely to first get a CPA established. As a result, ebXML recognizes an implicit CPA between companies and registries covering the six potential types of interactions with registries listed in the following sections.[22]

Registry Interfaces

The specifications define six types of interactions with registries. The first three cover connections directly with the registry:

• RegistryService . This is the service that permits access to the registry's two main functions, ObjectManager and ObjectQueryManager .

• ObjectManager . With this function, a company can submit data objects (CPPs, schemas), edit or modify the object characteristics, or remove objects.

• ObjectQueryManager . This function allows searches of the objects listed in the registry, performing browse, drill-down, or ad hoc queries.

The next three interactions cover connections directly with the end-user client software:[23]

• RegistryClient . This is the service that connects the end-user client to the services needed by the client to use the registry.

• ObjectManagerClient . This service calls back the client after submission of requests to the ObjectManager service, with notification of the results of that query.

• ObjectQueryManagerClient . This function also provides callback service, but for previously submitted requests to the ObjectQueryManager service.

Submitting and Managing Objects in a Registry

To enable content management, ebXML has specified the rules for listing objects ”XML schemas or DTDs, business process models, collaboration protocol profiles (CPPs) ”in a registry, as well as managing those objects during the time of their registration. A registry object goes through four stages in its life-cycle: submission, approval, deprecation , and removal. The registry attaches XML attributes, called metadata, to the object that the registry uses to classify the object and manage it throughout its registration period.[24]

The two main types of metadata are called ExtrinsicObject and IntrinsicObject in the XML schema with the electronic registry rules. ExtrinsicObject applies to those items submitted from external sources to registries, such as schemas or CPPs, where the properties of the object are not automatically known or understood .

ExtrinsicObject metadata includes properties or characteristics such as external uniform resource identifiers (web or email addresses, for example) and MIME types. If the properties are encrypted or otherwise not readable, the registry can still accept them, but they are called opaque .

IntrinsicObject covers those properties and characteristics already defined by the registry, and are those normally attached to objects already registered.[25]

When submitted, an object becomes a RegistryEntry , and is associated with one item in the associated repository. Each entry in the registry has a number of properties or attributes, the most notable of which are described in the following list:

• Association . Defines the relationship between a registry entry and other objects, and can cover potentially complex many-to-many relationships. The registry information model has 15 predefined associations to describe these relationships.

• AuditableEvent . Provides the ability to generate an audit trail for the entry. This ability includes associating registered users as part of the audit trail.

• Classification , ClassificationNode . Defines ways of categorizing registry entries, and since the kinds of classifications can vary significantly from one industry to another, registries need the flexibility to use their own classification schemes. ClassificationNode is a branch in the tree structure making up that scheme, while a Classification associates the registry entry with the ClassificationNode .

• ExternalIdentifier . Offers an additional means of identifying the registered item, such as D-U-N-S or UCC/EAN company identifier.

• ExternalLink . Provides a way for an object to reference Internet-based resources outside the registry, for example a schema that calls other schemas or DTDs.

• Organization . Describes the entity submitting the entry to the registry, including references to parent organizations.

• Package . Provides a way of grouping entries together, and also allows for managing this group as a whole.

If the registry needs to add attributes to an entry, it can use the Slot capability. This property allows for dynamically adding characteristics (called slots, thus the name ) for an entry.[26]

Upon submission and approval, the registry gives each entry a unique identifier, unless the end-user's software has that ability. The specifications require a 128-bit Universal Unique Identifier ( UUID ) that provides a statistically unique identifier across registries.[27] The UUID is a contribution of the Open Group, formerly the Open Software Foundation. It consists of a network address, considered by definition unique, current time, and place that the ID was generated.[28]

Objects are submitted in the form of an ebXML message, using a Registry.dtd for validation. A registry entry submission includes a RegistryEntryList with the objects for submission.The entries can also reference other objects already registered.[29]

Registries have a set of messages for approval of objects submitted to registries. Once approved, an object becomes part of the registry's content and is open for use in the establishment of trading partnership or development of ebXML-compliant messages or services.

Registries also have the ability to deprecate a registered object. Deprecating an object means scheduling it for obsolescence, and thus it cannot be enhanced further through associations, classifications, or external links. However, registries will continue to list the object and otherwise operate it normally.[30]

A protocol in the registry allows for the removal of objects. This protocol gives the registry some flexibility in deleting only the repository item, but keeping the registry entry, in order to keep references to registry entry valid. A registry can also remove the object from both the repository and entry. This facility works only if references ”associations, classifications, external links ”have also been removed.[31]

Searching and Retrieving Registry Entries

ebXML envisions registries as open resources that companies or individuals can access at any time and find the objects they need to conduct business electronically . To make the experience working with registries as uniform as possible, the specifications provide detailed requirements for the operation of registry search features. ebXML requires each registry to offer both browse/drill-down and filtered query capabilities. Structured Query Language (SQL) search mechanisms are allowed as options on ebXML registries.[32]

The browse/drill-down query capability supports the following interactions:

• Get Root ClassificationNodes Request . A ClassificationNode is a branch in the tree structure of the scheme used to classify the content of the registry.This request retrieves a list of root ClassificationNodes , defined as those without parents, or the topmost nodes in the tree.

• Get Classification Tree Request . Each ClassificationNode has a sub-tree attached that represents part of the classification scheme for the substance of the registry's content. This request returns the classifications listed under this node. The request allows searchers to specify the number of layers to drill down in the tree structure; a value of 1 , for example, returns the immediate children and no more.

• Get Classified Objects Request . With this request, the searcher specifies a precise list of classifications for the registry to query. This request returns the entries matching the ClassificationNodes in the list and those in descendant branches of the tree structure under those nodes.[33]

ebXML registries must also support filtered queries, which provide for more precise and complex searches. Filtered queries use the semantics and structure of the Registry Information Model ( RIM ) rather than the classification scheme of the subject matter used in browse and drill-down queries. Registries use the RIM structure mainly for submitting and managing objects, as discussed earlier. However, the metadata assigned to objects for these management functions can also be used for queries. The specifications require registries to provide a profile of queries of the metadata that the registry supports.[34]

Each query to the registry database seeks entries that meet the criteria spelled out in filters based on the RIM metadata. The semantic rules used in these RegistryEntryQuery messages vary from one set of metadata to another, since they use different structures:

• Associations, either as source or target relationships of the object, as well as the specific registry entries associated with the object.

• Classifications, with subsequent ClassificationNodes identified.

• Organizations, either as the organization that submitted the object or the group currently responsible for it. In both cases, the query can include the contact for the organization.

• Auditable events, which can include a user and organization associated with that event.

• External links, which have no child elements in their filters.

Each RegistryEntryQuery XML element has a RegistryEntryFilter element with the desired filtering given in subsequent child elements representing the different types of RIM metadata.[35]

Once these queries have identified specific registry entries or repository objects, searchers can then use a similar approach to retrieve the metadata associated with the entries or the objects themselves. The ReturnRegistryEntry command allows for adding the filtering arguments used to search for the specific entries. It returns the metadata for the registry entry identified. The ReturnRepositoryItem command has a comparable but not identical set of arguments, since repository items have a different storage protocol than registry entries.[36]

Registries for ebXML objects may also provide support for more complex SQL queries, although this is not required, as is the case for browse/drill-down and filtered queries. ebXML specifies the syntax of SQL found in a subset of ISO/IEC standard 9075:1992, Database Language SQL. An appendix of the ebXML registry specifications provides predefined routines in template form.[37]

Retrieving Registry and Repository Content

Searchers can retrieve specific content from a repository using the GetContentRequest command. This request lists the references to the objects, perhaps generated through the queries described earlier. A successful request message returns a corresponding GetContentResponse message with the specified object as payload. Since the response may include multiple payloads, each item is individually identified in the manifest of the ebXML header for the response message.[38]

Registry Security

Registries used with ebXML must meet requirements to protect the integrity of their contents, authenticate the identity of authorized users, and control access for predefined roles. To protect the integrity of submissions, content sent from registry client software must have a digital signature that ensures that no one has tampered with the content en route or within the registry. Also, the signature verifies that content is associated with the submitting organization.

The ebXML registry specifications require authentication of parties seeking access on a per-request basis. However, the document leaves open future support for session-based authentications. Registries must implement authentication mechanisms using credentials based on digital certificates and signatures. Message headers may have digital signatures provided by the sender's ebXML messaging service, but, absent a signed header, a signature in the payload will suffice.

The specifications define three roles with different levels of access:

• Content owner. Submits content to the registry from an organization and has access to all procedures in the registry dealing with that content.

• Registry administrator. The party responsible for the management and operation of the registry, and with access to all procedures on all registry objects.

• Registry guest. Unauthenticated visitors to the registry who are entitled to read-only access to the registry objects.

Registries must implement default access-control policies that reflect these roles and privileges.

The one familiar type of security not required for ebXML registries is confidentiality. As indicated earlier, ebXML considers registries public resources, and all content submitted to an ebXML registry may be discovered and read by any visitor. As a result, registries must make their content available unencrypted.

Parties exchanging messages with registries may need the capability to encrypt the messages or at least the payloads. The specifications encourage but don't require encryption for these exchanges. However, registries will need the capability to decrypt content provided in protected messages.[39]