WebServices dot org

To share data successfully, companies and individuals need to start somewhere, and for many parties looking to exchange data that "somewhere" is a registry. Registries provide an index or description of the information held or maintained by an organization or community of interest, and the data used for indexing or description are called metadata, literally defined as data about data. The role of registries in Web services and related technologies attracted a good deal of attention at a recent industry meeting devoted to the subject.

The sixth annual Open Forum on Metadata Registries held 20-24 January 2003 in Santa Fe, New Mexico ( http://metadata-stds.org/OpenForum2003/ ) explored the role of registries and reported on new developments and applications. While not a large event (about 120 participants, many of which were speakers in the various sessions), the forum offered one of the few venues where participants could focus on registries, and evaluate various methods and options for representing metadata. But like so much in the Web services world, the need for various registries to work together was a continuing and critical topic heard at the event.

The University of California's Lawrence Berkeley Laboratory put on the forum, which attracted participants largely from government, academe, and the scientific community. Bruce Bargmeyer of Lawrence Berkeley National Laboratory organized and chaired the event, and set the tone early by calling for greater cooperation and interoperation among the various types of registries. Bargmeyer said the various registries could either need to consolidate - he showed a cartoon of big fish eating smaller fish in a form of registry food chain - or learn to work together.

Working together would not be easy, however. While registries often contain common content, Bargmeyer conceded that the issue is not as simple as it may look. The data may be common but they are often represented in different ways, which makes it all the more important for metadata to map across these different representations. He said the success of this effort will depend on how the community of registries manages the semantics of the metadata. Bargmeyer's statement prompted a forum participant to shout, " Metadata rules!"

Value of registries

Registries provide a good starting point for data sharing because they offer an authoritative place to find resources for exchanging or reusing data with business partners or colleagues, either inside or outside an organization, including the rules for data sharing and descriptions of the kinds of data shared. The objects referenced in a registry can include entire standards or specifications, components of the standards or specifications, XML schemas or schema components, software components, data elements, database structures, or related documentation, such as guidelines or best practices, depending on the task at hand.

Registries can likewise offer information about the parties exchanging data themselves. Organizations can use registries to list basic identification or location data, information about the products or services the organizations offer, their technical capabilities, and requirements for doing business such as message formats and security levels.

Registries have great potential value because they offer a common method for representing the characteristics about the registered objects - e.g., organizations, specifications, schemas, components, elements represented by common metadata. By devising standards for registries and their metadata, especially those accessible over the Web, designers can build registries into an overall architecture for exchanging data within or among organizations. Standards also enable registries to interact with each other, thus encouraging a distributed environment, which in turn encourages individual registries to become smaller, easier to develop, and easier to maintain.

The Standards Landscape

The first two days of the event featured introductions to and tutorials on different registry methods and standards:

• Metadata registries defined by ISO standard 11179

• Registries for software components and developments

• Universal Description, Discovery and Integration (UDDI) registries

• Electronic Business XML (ebXML) registries

• SQL database catalogs

• Dublin Core registries of information resources

Understanding the operation and features of the various registries was an important part of the conference and a foundation on which to discuss consolidation and co-operation.

ISO 11179

Much of the event featured presentations about ISO 11179 - officially ISO/IEC 11179, Specification and Standardization of Data Elements - a metadata standard with 10 years of experience and one with an extensive paper trail. The forum featured an introductory presentation the first day and a day-long tutorial on the second day. ISO11179 is an international standard for data elements, defining one of the basic building blocks in the development of knowledge. The standard covers the composition, classification, naming, identification, and registration of data elements, and over its history has contributed to many other technical and business standards.

As described by Larry Fitzwater of the U.S. Environmental Protection Agency (EPA) and one of the standard committee leaders, ISO 11179 is divided into six major sections:

The naming conventions in section 5 of ISO 11179 have been adopted by other standards efforts (e.g. ebXML core components, X12 reference model for XML design). Section 5 also provides guidance on creating unique identifiers for data elements, using both a straight string as the basic name, with context added to help make the name understandable.

Fitzwater noted that the newer e-business registry standards and specifications, such as UDDI and ebXML, deal with different kinds of objects and interactions. But because of ISO 11179's longevity and experience with metadata and registries, it offers lessons for registry federation and interoperability from which the newer initiatives can benefit.

Dublin Core

Another standard with a developed base of experience is Dublin Core Metadata Initiative ( http://dublincore.org/groups/registry/ ), represented at the forum by Harry Wagner of OCLC. The Dublin, in this case, refers to Dublin, Ohio (near Columbus), where OCLC is headquartered. Dublin Core offers a baseline set of data elements for describing information resources, a key function for many academic activities and library collections.

Wagner said the Dublin Core initiative established a metadata registry to offer authoritative information on the Dublin Core vocabulary and the relationships among the terms in that vocabulary. The registry needed to provide access to the core terms and qualifiers, offer a Web-based interfaced for both human and machine accessibility, be based on open standards, and offered open source to the world at large.

Wagner and his team based the Dublin Core registry on the Resource Description Framework (RDF) a schema for describing information resources developed by the World Wide Web Consortium (W3C). Because RDF paralleled the objectives of Dublin Core, it made a good fit for the registry. The search and navigation aspects of the registry - the key parts of the project, according to Wagner - generate XML output, transformed into HTML with XSLT stylesheets.

The first phase of the project provides the registry's Web interface for human navigation, and the second phase will generate APIs for machine interactions. Wagner said the long-term goal of the project was to develop a series of distributed Dublin Core registries. Because of Dublin Core's large international constituency - its vocabulary is translated into 23 languages - distributing its registry would help meet local conditions while still providing a common base of metadata. Wagner envisioned each local registry having its own set of terms, with a central directory to tie them together.

ebXML registries

Registries used as part of the ebXML framework ( http://www.oasis-open.org/committees/regrep/ ) had a significant presence during the first two days of the forum, including an opening overview presented by Kathryn Breininger of Boeing Aircraft and a tutorial led by Monica Martin of Drake Certivo.

Breininger used the library catalogue as an analogue to describe the role of a registry, in that it indexes and describes information stored elsewhere. In ebXML, registries offer organizations a way of publishing the standards, specifications, industry best practices, common vocabularies, official code lists, and other information, objects, and artifacts needed to conduct electronic business. Registries in ebXML are accessed through the Internet, where searchers locate the desired information, for subsequent retrieval.

Breininger outlined the architecture and basic features of ebXML registries, noting that the registries use a model that allows for the indexing of objects stored in multiple locations. Registries in ebXML also manage the complete lifecycle of metadata assigned to the objects, from first submission through obsolescence and removal.

Users can access ebXML registries through SOAP and ebXML message services, and the next version of the registry specifications (3.0) will support HTTP/URI messaging, similar to REST. Breininger said ebXML designed security features, such as access control and message encryption into the specifications, with enhancements to security promised in the upcoming version 3.0. EbXML registries also support internationalization and native language representations.

EbXML registries can list objects such as specific services, service bindings, and specification links. An associated repository can store these objects as Web Services Description Language (WSDL) files, business process, or collaboration protocol profiles (CPPs) defined in another part of the ebXML specifications. Version 3.0 of the specifications includes optional content management functions, including validation of XML objects and the cataloging of metadata upon submission.

EbXML divides the registry functions into two basic sets: lifecycle and queries. The lifecycle manager supports the registry's capture and cataloging, as well as change and version management. The lifecycle manager also allows registries to index, classify, and describe any kind of object. The registry can support any kind of taxonomy, such as industry codes, and can also associate objects in the registry to each other.

Objects in ebXML registries are listed in a hierarchical structure. EbXML registries can group objects together into packages, as well as link to external objects. Breininger said version 3.0 of the registry specifications will support cross-registration of objects that enable the federation of ebXML registries. Version 3.0 will also support alert services which allow subscribers to monitor changes in objects of interest in a registry.

As the name implies, the lifecycle processes manage the status and changes in objects during the period they provide service to users. These processes include submission of objects, individually or batch, The classification schemes of object, such as geographic or industrial codes, are also submitted in the same way. The lifecycle manager includes the approval processes, as well as steps for deprecation and removal of obsolete objects. Deprecated objects are those still in service, but scheduled for obsolescence.

Visitors to registries can browse through the objects, but the registries also provide search facilities through the query service, defined in the ebXML Registry Information Model. All ebXML registries provide filtered searches, while SQL searches are optional. Queries can retrieve the metadata about objects, and where the registry includes a repository or has an associated repository, they can retrieve the objects themselves.

The authorization features of ebXML registries give the registry owner the power to set policies for submission, approval, deprecation, and removal of objects. The owner can grant permissions to perform these functions on the basis individual roles, participation in groups, or specific identities. Another management feature is an audit trail that provides a record of events, such as changes in lifecycle status Version 3.0 will also provide a record of downloads and transfers. The subscription service mentioned above, another feature of version 3.0 will be based on the data generated by this audit trail.

Breininger described the federation features in the upcoming version 3.0 of the ebXML registry specifications. She said ebXML registries would cooperate in a loosely-coupled peer-to-peer model, where each registry operator would have authority over its own community of interest, but would enable registries to access resources in other registries. These capabilities would allow queries to form multiple federated registries, as well as permit an object to have references to multiple registries. Registries could also form federations where they could share resources and cross-reference their respective objects.

ebXML registry examples

In a tutorial the next day, a panel led by Monica Martin of Drake Certivo listed several ebXML registry implementations by standards bodies, companies, government agencies, and industry organizations in the U.S.A., Canada, Korea, and Australia. The tutorial also gave a more in-depth review of three specific implementations.

Martin discussed General Motors' use of an ebXML registry as part of its Software Factory Enabler Project. Martin said GM developed the registry to extend its service oriented architecture and create a reference implementation for complex integrated business-to-business interactions. The GM registry, uses software from Sun Microsystems and is compliant with version 2.0 ebXML registry specifications. The implementation has an associated repository, with a database following the ebXML registry information model in the specifications.

The registry and repository, as described by Martin, serve business processes governing interactions between GM and its retail dealer networks. In ebXML business processes are represented by XML schemas or UML models following the ebXML business process specification schema or BPSS. Individual data elements are mapped to ebXML core components that provide common references for semantic interoperability. GM stores the relevant BPSSs (the XML variety) and core components in the repository with corresponding indexes in the registry.

Martin said GM's registry and repository serve discovery functions for dealers to find the services and specifications needed to do business as part of the dealer network. The registry's functions enable trading partners to find, explore, and retrieve relevant electronic documents. And the registry allows GM to create and submit appropriate metadata for the objects stored in the repository.

GM builds its processes with business object documents (BODs) from the Open Applications Group. GM creates electronic business documents based on the BODs, business processes, and core components, all mapped to its overall service oriented architecture, and publishes these objects in the ebXML registry. The dealers find the relevant trading documents in the registry and download them from the repository, then use those objects to develop or buy the systems needed to do business with GM. The dealers then negotiate a collaboration protocol agreement or CPA with GM. A CPA represents the technical part of a larger trading partner agreement and can provide the precise run-time configurations of the trading partner systems.

Tony Weida of Apelon ( http://www.apelon.com ) described an ebXML registry developed for a medical documentation project called the Shared Active Guideline Environment or SAGE. Apelon is one of several health care companies and organizations taking part in SAGE, a three-year project funded by the National Institute of Standards and Technology.

This project develops an infrastructure for machine processable clinical guidelines that are interoperable across multiple platforms. Clinical guidelines, as described by Weida, capture best practices for providing medical care. An example in the tutorial showed guidelines for type 2 diabetes, presented in the form of a flow diagram. SAGE seeks to generate clinical practice guidelines in a standard computable format, and have those guidelines work in any clinical information system that meets the appropriate standards. SAGE's deliverables include an interoperable guideline model, interoperable guideline workbench or editor, a guideline deployment system, and a Web-based guideline registry, which Weida discussed in the tutorial.

The SAGE registry, now in an early prototype, follows version 2.1 of the ebXML registry specifications. It uses the open-source ebxmlrr software ( http://ebxmlrr.sourceforge.net/ ) and integrates Apelon's Distributed Terminology Server (DTS). Weida said the registry now supports submission, basic indexing, and guideline package retrieval functions.

A guideline registry client interacts with the ebXML registry and the Apelon DTS servers. The registry client is browser based for human-readable searching, but also includes an editor for publishing guideline packages and their metadata. Under the plan for SAGE, writers would use the guideline editor to create clinical guidelines, and assign metadata from standard vocabularies, which together with the guideline the writers would submit to the registry.

Health care providers can browse or query the registry to find guidelines of interest, and if found, retrieve the guidelines from a repository. While guidelines contain valuable clinical information, they still may need customization to meet local needs and practices. The SAGE project envisions the use of local registries to register these customized documents deployed in the health care providers' systems.

Weida said as next steps the SAGE project expects to add more elaborate metadata to its current prototype as well as support versioning for its guideline packages. It also plans to add a terminology service plug-in for the registry server.

Data Interchange Standards Association (DISA) has a working ebXML registry in use for the vertical industry standards groups it supports in the travel, financial services, chemical, and food products industries. The specifications developed by these groups are in electronic form and freely available, which makes them good candidates for registration. (Full disclosure: I gave the presentation about this registry.)

The DISA Registry Initiative or DRIve ( http://www.disa.org/drive/ ) is a registry only, since each of the industry groups DISA serves has its own Web site where it stores the standards, specifications, code lists, and best practices created. DRIve is compliant with version 2.0 of the ebXML registry specifications, and uses registry software donated by XML Global.

An example of a DRIve entry shown in the tutorial - version 2.1 of the Mortgage Industry Standards Maintenance Organization (MISMO) specifications - had separate registry entries for each individual document or schema published as part of that version release. Each entry was linked to its corresponding storage location on the MISMO Web site. DRIve also assigns each object a 32-bit unique identifier.

DRIve classifies each specification by two industrial classifications: (1) the North American Industrial Classification Systems (NAICS), the successor to the Standard Industrial Codes (SIC) used for years in U.S. government economic reporting, and (2) the UN Standard Product and Service Code (UNSPSC). Browsers or queries can search for individual specifications to see under which classifications they fall, or can search the classifications to see which specifications come under those codes. DRIve also cross-references each specification to its corresponding entry in the XML.Org registry operated by OASIS.

DRIve and ebXML registries in general show the relationship among individual registry entries. In the tutorial example, the XML schema specification for the Interactive Financial Exchange (IFX) Forum version 1.3. is shown as equivalent to the IFX version 1.3 DTD, related to the IFX version 1.3 documentation, and extending the IFX version 1.2 schema.

DISA is testing the registration of business processes and CPPs, as well as SOAP message access to the registry. Currently, the registry is human-readable only. DISA also plans to start including the cross-industry standards developed by ASC X12, the committee accredited by the American National Standards Institute for e-business messages and DISA's largest affiliate.

UDDI registries

Tom Bellwood of IBM and gave a comprehensive review of Universal Description Discovery and Integration (UDDI) registries ( http://www.uddi.org/ ), now in its third version. Bellwood also serves as the co-chair of the OASIS UDDI technical committee. (A tutorial on UDDI scheduled for the second day of the forum was cancelled.)

He noted that UDDI addresses the issue of Web services discovery, the act of finding specifications and choosing among alternatives. Other Web services specifications offer useful functions - Bellwood cited the service descriptions in WSDL and inspection functions of WSIL as examples - but UDDI allows for dynamic discovery and sophisticated searching of these services, which the other Web services do not.

UDDI registries act as reference points for Web services that allow for common descriptions and discovery of those services, based on XML standards and independent of platform. Bellwood noted that for the business users, the ultimate target audience for UDDI and Web services as a whole, UDDI offers a number of benefits. UDDI registries ease the management of large numbers of trading partners and open up market opportunities, which would otherwise go unnoticed. They also encourage the aggregation of data from multiple sources, and provide a common profile for electronic services, Web and others.

Bellwood outlined the main UDDI processes.

• UDDI registers specifications or taxonomies with objects called tModels (short for technical models, and described below), provided primarily by standards bodies, software companies, and programmers.

• Businesses register the services that they support.

• UDDI assigns each object in the registry a unique identifier key, which makes the object individually accessible and manageable.

• Business applications or their representatives (e.g., search agents, e-marketplaces) query UDDI registries to discover services at other enterprises.

• Companies then use the data retrieved from the registries to facilitate their business processes.

Businesses can provide three types of information about themselves and their services, using the telephone directory as an analog, with white, yellow, and green pages. The white pages in a UDDI registry contain straight descriptive data about the business such as the company name, contact information, brief descriptions, and business identifiers (e.g. DUNs number). UDDI yellow pages provide classifications of the company's services using U.S. government and UN industrial codes (NAICS, UNSPSC respectively), and geographic location based on ISO 3166 codes. UDDI allows for the use of other taxonomies as well. The green pages specify the technical data, in terms of the bindings to a service provider and a technical fingerprint, with references to other Web services specifications.

UDDI provides for five core data types:

• tModel that names and describes specifications, and links those specifications to classifications (taxonomies such as NAICS and UNSPSC listed above), and identifiers

• businessEntity that identifies, names, and describes a business

• businessService, a child of businessEntity that identifies, names, and describes the services provided by the business

• bindingTemplate, a child of businessService that links tModels with a service, and describes where and how to invoke the service

• publisherAssertion that identifies businesses having a relationship and defines that relationship

Companies can configure UDDI registries to run privately, to serve strictly internal functions or with selected high-volume business partners, in semi-private mode where some functions are opened to the public while others are restricted for internal or invited parties, or as a completely public resource if so required by business needs. Bellwood noted that there will likely be more private than semi-public or public registries.

An example of a public registry is the UDDI Business Registry ( https://uddi.ibm.com/ubr/registry.html ), a protoype offered by Microsoft, SAP, NTT, and IBM. Each registry operator serves as a peer of the others, sharing all registered records, with each supporting a common set of SOAP APIs.

UDDI supports three types of query patterns. Browse queries search for certain kinds of objects. The drill-down pattern retrieves details about an object, given its key. The third query pattern, invocation, is the most dynamic. With invocations, the requestor invokes a specific service from a cached bindingTemplate (see above). If the invocation fails from, for example, an incorrect location, the pattern allows for the requestor to get correct data from the appropriate UDDI registry and try it again.

Bellwood explained how UDDI has gone through three iterations, and listed the features of version 3, released in June 2002. Version 3 provides for operations across for multiple registries that address the need for unique identifier keys that are human readable, reproducible, and identifiable across registries.

To make human-readable key identifiers, version 3 ( http://www.uddi.org/specification.html ) allows for publisher-assigned key names based on domain names and URIs, rather than the cryptic machine-assigned keys. UDDI allows as well the reproduction of entries from one registry to another, while still preserving the publisher's original key.

To manage this entity-sharing operation, however requires a licensing process. For this purpose, version 3 uses keyGenerator tModels. This process establishes a key partition that generates a specific key across to another UDDI registry node, and is guaranteed unique.

UDDI specifies the relationship of root to affiliate registries as a way of sharing resources. The root registry acts as the authority for assigning key spaces, and can delegate key partitions to the affiliates. Version 3 also introduces a subscription service, like the subscription services to be offered by ebXML registries, that tracks changes in specific registry entries.

Bellwood listed the security enhancements in UDDI version 3. One enhancement is the use of digital signatures that not only allows for verification of its provider (and reducing the chance for repudiation), but also greater integrity and reliability of the data. Users can also query the registry with filters based on those signatures. The use of digital signatures also supports multiple-registry operations, in that the signature ensures the data shared among registries does not change.

Bellwood said UDDI published a technical note that recommends methods for using UDDI with ebXML. He said the note suggests ways of listing ebXML objects, such as collaboration protocol profiles (CPPs) and business process specification schemas (BPSSs) in UDDI registries that not only meet UDDI specifications, but conform to ebXML rules as well. The note gives methods for searching ebXML for ebXML objects and services.

The technical note also gives examples of UDDI registries working with ebXML objects. In ebXML company profiles (CPPs) refer to one or more business processes defined by BPSSs. UDDI can register templates for CPPs and BPSSs. A company can find and retrieve the CPP templates, complete one or more CPPs for itself, and register the CPP as well as its services in a UDDI registry. Another company looking for business partners can search UDDI registries for ebXML CPP profiles. If the search eventually results in a business relationship, the companies can combine their respective CPPs into a collaboration protocol agreement or CPA, which represents the technical part of a trading partner agreement.

Software component registries

Nobuhiro Matsutake of Fujitsu discussed his company's registry and repository of software components. Matsutake's presentation was unique in two respects:

1. It represented the only registry presented, at least in the first two days, that generated significant income on its own, and

2. It serves a community actively interested in reusing objects and artifacts, a central premise behind registries

Matsutake said Fujitsu started its Component Center ( https://business-bean.fujitsu.com/crc/ , a Japanese language site) in September 2001 to support its Interstage application server line. The Interstage server itself supports J2EE 1.3, CORBA and UML, ebXML, and the mainline Web services specifications - SOAP, UDDI, and WSDL. The operation offers software customization and maintenance services to Interstage customers. Fujitsu expects to have 300 customers to enroll this year, at an annual fee of $US 5,000. Members also pay nominal license fees for the components downloaded.

Much of the component center content is based on Enterprise Java Beans (EJB), which Matsutake said reflects a strong preference on the part of the company's Japanese customers. He cited surveys of developers in Japan that reported 85 percent using EJB components in their applications, but more notably, half (50%) of the respondents said they reuse EJB components. These statistics support the need and value of registries, which encourage sharing and reuse of objects.

Matsutake said the registry includes business EJB components and 11 EJB patterns, utility components, GUI components (e.g., calendars, checklists, spreadsheets), integration components, and developer environment tools. He said the component center can lead to a breakthrough in applications development, by providing practical tools that dramatically reduce development time. Matsutake also said Fujitsu plans to use UML models for translating user requirements into system designs using components from its registry.

Standard registry metadata

Karl Best of OASIS described a joint project of several standards bodies and industry groups to develop a set of metadata describing e-business standards ( http://www.ansi.org/internet_resources/standards_registry_committee/stdsreg.aspx?menuid=12 ). This project grew out of two Interoperability Summit meetings sponsored by OASIS and several other standards groups, where participants in the meetings identified the key factors inhibiting cooperation and convergence among standards groups. See http://www.xml.com/pub/a/2002/07/10/interop.html for a report on the last meeting.

Best noted that standards groups need better tools to share information about their work, as well as a common vocabulary for describing their standards. With these tools, standards groups could more easily find out about related work going on in the standards community, as well as offer developers better ways of finding the standards available that can help their work.

As a result of the Interoperability Summits, Best and participants from several other organizations began an ad hoc committee to develop a set of metadata to describe e-business standards. Using the Dublin Core as a model, the group identified 16 elements, with 10 attributes, as the minimum set of terms to describe e-business standards and specifications.

Best said the group has a work draft distributed to about 1,000 standards organizations affiliated with ANSI, NIST, and the European Standardization Bureau, which uses the French acronym CEN. The group is collecting final comments and plans to submit its work to ISO for consideration as a formal standard.

Can registries just get along?

An overriding theme of the forum, in both speaker presentations and participant questions, was the need for registries to interact, both with their own kind and with others. Bruce Bargmeyer, the forum chair and organizer, offered a scenario for cooperation, in the form of a division of labor among registries:

• ISO 11179 registries would manage semantic content and provide registration procedures

• UDDI registries would provide discovery mechanisms

• XML registries, such as ebXML, would register schemas

Bargmeyer described the desired state of affairs in terms of service to users and convenience to registry operations. Bargmeyer said, "It's time for the users to push developers and standards bodies to come up with a way to enter an idea once, and have it propagate among registries."

The pressure from the developer and user communities seems to be working. The UDDI technical note, discussed by Tom Bellwood, outlines one scenario for UDDI to register ebXML objects, and next version of ebXML registries will support federated registries, at least within the ebXML community. The Standards Registry Metadata initiative discussed by Karl Best has proposed common metadata to describe standards objects, which offers a uniform vocabulary for describing at least one important type of registry content.

Perhaps the most hopeful sign from the forum, particularly in these economic times, was the presentation by Nobuhiro Matsutake reporting on Fujitsu's software component registry/repository. Fujitsu found a way to use a registry that meets vital customer needs and thus generates significant income. The experiences of companies like Fujitsu making money with registries will probably get more executive level attention and priority focused on the value of registries than any other development.

-------------------------------------------------------------------
Alan Kotok is director of publishing at Data Interchange Standards Association (http://www.disa.org) and the author, with David R.R. Webber, of ebXML, The New Global Standard for Doing Business on the Internet, New Riders Publishing, August 2001 (http://www.ebxmlbooks.com/). The opinions and observations in this article are solely those of the author and do not represent the views or policies of DISA or its affiliates.