D10 v0.1 WSMO Registry

WSMO Working Draft 29 March 2004

This version:

http://www.wsmo.org/2004/d10/v0.1/20040331/

Latest version:

http://www.wsmo.org/2004/d10/v0.1/

Previous version:

http://www.wsmo.org/2004/d10/v0.1/20040329/

 

Editors:

Reinhold Herzog

Holger Lausen

Dumitru Roman

Peter Zugmann

 

Authors:

Reinhold Herzog

Holger Lausen

Dumitru Roman

Michael Stollberg

Peter Zugmann

This document is also available in non-normative PDF version.
Copyright © 2004 DERI®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.

Table of contents

1. Introduction

2. Principles and Approach

3. Architectureal Overview

3.1 Role of Registry in WSMO

3.2 Retrieval Mechanism

  3.2.1 Syntactical and structural retrieval - UDDI

  3.2.2 Semantic Retrieval - Discovery

  3.2.3 Scalability

  3.2.4 Consistency

4. Using UDDI in WSMO

4.1 Supported WSMO Elements

4.2 Lifecycle of published information

4.3 UDDI Data Model Configurations

  4.3.1 UDDI Categories Schema

  4.3.2 UDDI TModel-Keys

  4.3.3 Mapping WSMO properties into the Registry

4.4 Interfacing UDDI

4.5 Publishing Interface

  4.5.1 Publish WSMO Service

  4.5.2 Publish WSMO Ontology

  4.5.3 Publish WSMO Goal

  4.5.4 Publish WSMO Mediator Service

4.6 Retrieval Interface

  4.6.1 Retrieval Methods

  4.6.2 Retrieval by non-WSMO aware Client

  4.6.3 Retrieve WSMO Elements

Acknowledgement

Related Publications

• UDDI-V2: http://www.oasis-open.org/committees/uddi-spec/tcspecs.shtml#uddiv2
• UDDI-V3: http://www.oasis-open.org/committees/uddi-spec/tcspecs.shtml#uddiv3
• UDDI-V4 Requirements: http://www.oasis-open.org/committees/uddi-spec/doc/req/uddi-spec-tc-req11-14-semantics-20040205.doc.doc

1. Introduction

This document describes how WSMO modelling elements can be published and retrieved using a Registry. WSMO elements can be retrieved using certain search criteria like business entity or selected WSMO properties.

The Registry is supposed to publish, store and retrieve the following WSMO elements:

• WSMO Services (including WSMO Mediator Services)
• WSMO Ontologies
• WSMO Goals

The document is structured as follows: Section 2 explains the principles and the approach for designing the WSMO Registry; Section 3 introduces the conceptual architecture of the WSMO Registry, and Section 4 specifies the usage of UDDI by defining the mappings for WSMO elements into UDDI technology.

2. Principles and Approach

Requirements for Registry are:

• Have a publish/retrieval procedure for WSMO Services, Goals and Ontologies
• Reuse and adapt existing and well accepted standard methods and tools opposed to specify a new Registry from scratch
• Provide the possibility to extend existing Web Services with WSMO Extensions
• Allow coexistence of existing Web Services and WSMO Services

According to the above criteria, UDDI was chosen as the basis. Major design decision criteria have been:

• Since there is no upper Ontology in WSMO that describes the Registry, it was decided not to define it here, but to use the formalism of UDDI as it is.
• The recommended approach is to store as little information as possible in the Registry itself (the minimum that is required to perform a structural query) and just refer to the WSMO Extensions stored elsewhere.

This document describes how UDDI should be used in WSMO and will show, how properties of WSMO elements can be mapped into the UDDI data model so that UDDI can be used for retrieval using its standard find functions.

A major assumption is that UDDI remains “Ontology agnostic”, i.e. all semantic related processing should be kept separate.

In its specification, UDDI V3 provides mechanisms to extend UDDI’s data model as well as its API. Since there is not real UDDI V3 implementation so far, an approach was taken to get along with the concepts and functions available in UDDI V2.

3. Architectureal Overview

3.1 Role of Registry in WSMO

For WSMO, semantic retrieval is required. The approach is to clearly separate Registration, Storage and Discovery:

• The Registrystores information about the publisher and selected data about WSMO elements. The Registry is “semantic agnostic” and links to the stored information, which itself contains the semantics. The Registry provides a non semantic retrieval interface.
• WSMO elements are physically storedaccording to a P2P approach (in most cases at the owner/provider of a WSMO element).
• Discoveryhas “semantic knowledge” to discover WSMO elements using the Registry to retrieve the physical elements. Discovery provides a semantic retrieval interface.

Figure 1. WSMO Architecture for Registry, Discovery and Storage

Since Discovery is key to WSMO, it is the driving point for a certain architecture. A two level approach is suggested:

1. Syntactical and structural retrieval (using standard UDDI functions)
2. Semantic retrieval (using Discovery)

The main reasons to separate into two steps are:

• Any number of discovery mechanisms can be provided, independent from the Registry; Discoveries may vary in capabilities, functions and performance. As well, the UDDI can be used by existing applications in a traditional, non semantic way to retrieve WSMO services.
• Reasoners, used by discovery mechanisms, will most probably need a different data organisation, at least in the current stage (there is no scalable Reasoner which is able to reason distributed data across the net)

3.2 Retrieval Mechanism

3.2.1 Syntactical and structural retrieval - UDDI

WSMO elements can be syntactically retrieved using UDDI´s standard API, taking into account the mapping that has been applied during publishing.

3.2.2 Semantic Retrieval - Discovery

The Discovery is responsible for the semantic retrieval of WSMO elements.

For an initial load from a Registry, the standard UDDI find and get calls will be used. Find qualifiers are used together with the find API to apply filters for technical and non-technical criteria.

For filtering information, only the explicitly stored information in the Registry can be used, definitely not the semantic content within the WSMO compliant service description.

Ontology and WSMO related information is referred to by overviewURL information. It is up to the user to understand the content of the referred documents and is transparent for the Registry. Such contents are WSMO Ontology descriptions, WSMO Service descriptions and WSMO goal descriptions.

Like the Discovery, other mechanisms used by the Discovery, e.g. Reasoners, will use the Registry in the same way as described above.

3.2.3 Scalability

The proposal allows centralized and distributed Registries, and it allows specialized Discovery services. Through partitioning, scalability can be achieved.

Nevertheless the overall design may not just count with the numbers, but must take into account the change frequency of the Registry content, especially if goals with short life cycles should be registered.

To improve scalability, the UDDI and the Discovery Service may be combined in a way that the UDDI persistence storage get implemented so that it can be directly shared by the Discovery.

Ontology and WSMO related information is referred to by overviewURL information. It is up to the user to understand the content of the referred documents and is transparent for the Registry. Such contents are WSMO Ontology descriptions, WSMO Service descriptions and WSMO goal descriptions.

Using the Registry, for a Discovery mechanism it will definitely be better to retrieve all WSMO elements in bulk from UDDI as opposed to issue a high number of single requests.

3.2.4 Consistency

Another major issue is the consistency and actuality of the Discovery service. It is up to the implementer of a discovery service to choose the strategy which fits best the balance between costs of requesting updates from the registry and dealing with potentially outdated or missing information.

4. Using UDDI in WSMO

As already stated, it is proposed to clearly separate Storage, Registry and Discovery components in WSMO. In this approach the Registry can be viewed as an “index” to the storage. Although some recommendations are given in this document, it is up to the implementation to decide how much information about the stored data is copied and stored in the Registry itself.

WSMO elements will be published to UDDI using standard functions. It is not necessary to extend the data model of UDDI (which is possible in UDDI V3), in fact necessary WSMO properties are mapped into existing data slots in UDDI (e.g. BusinessEntity) or in customized slots (Identifier bags). This keeps the Registry “semantic agnostic” and is not dependent on version 3 of UDDI.

4.1 Supported WSMO Elements

The WSMO Registry can be used to publish and retrieve the following WSMO elements:

WSMO Services

Both, the WSMO Extensions (Non Functional Properties etc.) and the Grounding (WSDL) can be published to the Registry. Separation of the Grounding from the WSMO extensions makes it possible to extend existing, already published Services with WSMO properties and to stay compatible with standard UDDI functions.

WSMO Mediator Service

WSMO Mediator Services will be treated as normal WSMO Services. However, they will be represented by a separate tModel implementation in UDDI which makes retrieval easier.

WSMO Ontologies

Ontologies can also be published and retrieved.

WSMO Goals

WSMO Goals have a much more “personal” flavour than other WSMO elements. A WSMO Goal in most cases expresses the “wish” of a user and therefore may contain sensitive or confidential data. Nevertheless some of these Goals may be reusable and provided as templates and therefore should be published using the Registry. It has to be taken into considerations that these Goals should not be subject to very frequent changes (especially in UDDI V3, with it’s replication facilities). Non reusable or frequently updated Goals should be stored at the Client side or other locations which is not elaborated here.

It has to be noted, that for Goals retrieval, all rules, limitations and effects regarding visibility and security apply as specified in UDDI.

4.2 Lifecycle of published information

Since information entries in the Registry have some dependencies on each other, special care has to be taken how to keep them consistent (e.g. WSMO Services refer to used Ontologies or Mediators that do not exist any more).

To allow deletion of all WSMO elements, all elements not owned by a specific business should have an identifier with scheme “WSMObusinessIdentifier”, a keyName "owner", and a keyValue "WSMOowner".

Ownership in UDDI is different for deletion and authority to change.

Ownership and re-publishing

In principle UDDI allows anyone who can find a key to re-publish anything. In practice only the owner, as established by the ‘authInfo’ of an object can re-publish it. There are protocols to transfer ownership and recover ownership. It is recommended no change to these protocols. The only clarification is that an ‘un-owned’ Ontology can be read after the publishing business has been deleted.

Ownership and BusinessEntity deletion

An Ontology is registered as tModel it therefore can then survive the removal of the Business who published the Ontology. As with all UDDI interactions, a publish action may require an ‘authInfo’ which, depending on the UDDI policy requires a registered Business relationship with the UDDI provider to edit the Ontology.

Published Services, and Mediators are unavailable after the Business Entity is deleted. Published Goals are still available after the Business Entity is deleted. This can be avoided in a future API wrapper.

4.3 UDDI Data Model Configurations

The UDDI standard data model without extensions is used.

4.3.1 UDDI Categories Scheme

UDDI version 2 does not allow to find a service by identifier. It’s proposed to add a Categorization scheme of WSMO elements. Import of the schema into the UDDI depends on the implementation of the UDDI.

As a starting point, the categorization scheme should look as follows (format depends on UDDI implementation, the one below is in the Microsoft UDDI format):

If a registry does not allow new categorizations to be created for WSMO, then some of the effects can be achieved by adding appropriate tModels to all objects.

4.3.2 UDDI TModel-Keys

For WSMO 5 new, required tModels are introduced:

• WSMOservice
• WSMOontology
• WSMOgoal
• WSMOmediatorService
• WSMObusiness

4.3.3 Mapping WSMO properties into the Registry

A meaningful set of WSMO properties have to be mapped into UDDI to meaningful retrieve WSMO elements in UDDI using UDDIs limited find capability.

Due to UDDI’s simple data model, the semantic context of the properties will get los during the mapping.

Mapping Methods

In principal there are several approaches to map WSMO properties into the Registry:

Automatic establish references:

This means establishing references from UDDI to WSDL for grounding and UDDI to WSMO for semantic specifications.

Manual Mapping:

This covers WSDL Groundings from WSMO interface and UDDI bags from WSMO capabilities and Non Functional Properties.

Semi-Automatic Mapping:

As long as there is no specification within WSMO for grounding, a WSDL must always be created on top, therefore there is no automatic or semi-automatic support. UDDI mapping can be semi-automated.

Automatic Mapping

Only for UDDI, not for WSDL.

Mapped Properties

It seems to be a good starting point to map the following WSMO properties into UDDI. Since there is no exact format of WSMO properties available, this is shown on a more abstract level. In the examples below for publishing it is shown in principle, how a WSMO property can be mapped into UDDI-Id-bags.

Figure 2. Mapping WSMO Service to UDDI

Figure 3. Mapping WSMO Goal to UDDI

Figure 4. Mapping WSMO Ontology to UDDI

To map WSMO properties into a UDDI bag, a transformation of the property value may be necessary. For example the NFP “Subject” as described in the WSMO Primer

would be split into 3 UDDI Identifier bags, each containing for example the key “WSMOnfpSubject” and one of the terms “travel”, “leisure” and “plane”.

In addition to the proposed properties, it is expected that publishers will include additional Category bags and Identifier bags. WSMO will not require any entries, but any publisher expecting their entries to be found directly as well as through Discovery should include as many entries as possible.

4.4 Interfacing UDDI

For a first implementation it is proposed to use native UDDI functions to publish and retrieve WSMO modelling elements.

In a later stage the native API calls can be wrapped into an API (e.g. “WSMO_store” and “WSMO_find”) to provide more convenience for the user and to shield the mapping from the caller. Also, this API could include some validation functions (e.g. check if used Ontologies in a WSMO Service do exist etc.).

Maintenance of the Registry can be done using UDDI’s set of functions.

4.5 Publishing Interface

In the described procedures below it is assumed that a Categorization scheme as described above has been created in or imported to the UDDI.

4.5.1 Publish WSMO Service

Publishing a WSMO Service in the Registry includes the following steps:

1) Define used Categorization Scheme

2) Define the Owner / Publisher of the Service

Owner of a service will be stored in the Identifier bag to be able to retrieve a service by owner. The owner is expected to be the publisher’s name.

For each WSMO property mapped into the UDDI, a Identifier bag has to be added. Here is an example for the NFP “language”:

Additional Identifier bag entries may be added to be found by non WSMO UDDI usage.

3) Create Binding Template for the Business Service

4) Create tModel

For each Service, a separate tModel must be created. Among other things, this will allow search by Identifier bag.

5) Create UDDI Business Service

6) Add HTTP WSDL Binding

Add HTTP WSDL Binding as normal. This is most important as non-WSMO aware clients will search for, resolve and invoke the service through this binding. This binding must be stand-alone not requiring any WSMO properties, probably this means registering another tModel – and most important cleaning it up. If required, WSMO can assist in cleaning it up if it is assigned a WSMO category and an WSMObusinessIdentifier id has been added to the Identifier bag.

Adding a binding is not described here in detail, but the following data to create the binding should be used:

• URL of WSMO Extension
• Location URL of WSDL location
• Category Bag as specified in step 1
• Identifier bag as specified in step 2

7) Add Instance for the WSMO Binding

Re-publishing a WSMO Service is similar to publishing a new service, but requires the Service key, and may require the preserved bags.

4.5.2 Publish WSMO Ontology

Publishing a WSMO Ontology in the Registry includes the following steps:

1) Define used Categorization Scheme

Additional Category bag entries may be added to be found by non WSMO UDDI usage.

2) Define the Owner / Creator the Ontology Goal Owner

The owner of an ontology can be stored in the Identifier bag to be able to retrieve an Ontology by owner. The owner is expected to be the publisher’s name.

Additional Identifier bag entries may be added to be found by non WSMO UDDI usage (example see section 4.5.1.)

3) Create tModel

For each Ontology, a separate tModel must be created

Re-publishing a WSMO Ontology is similar to publishing a new Ontology, but requires the Ontology key, and may require the preserved bags.

4.5.3 Publish WSMO Goal

It’s assumed, that Goals must have an Owner. Publishing a WSMO Goal in the Registry includes the following steps:

1) Define used Categorization Scheme

Additional Category bag entries may be added to be found by non WSMO UDDI usage.

2) Define the Owner / Creator the Ontology Goal Owner

The owner of a Goal will be stored in the Identifier bag to be able to retrieve a Goal by owner. The owner is expected to be the publisher’s name.

Additional Identifier bag entries may be added to be found by non WSMO UDDI usage (example see section 4.5.1.)

3) Create tModel

For each Goal a separate tModel must be created

Re-publishing a WSMO Goal is similar to publishing a new Goal, but requires the Goal key, and may require the preserved bags.

4.5.4 Publish WSMO Mediator Service

As WSMO Mediators are handled similar to WSMO Services, see section 4.5.1.) - WSMOservice has to be replaced with WSMOmediatorService.

4.6 Retrieval Interface

UDDI has some limitations regarding its query interface. Most of the limitations are due to the use of the OR bag qualifiers. Solutions to these limitations are not elaborated in this document.

4.6.1 Retrieval Methods

For retrieval, different methods serve different requirements:

Query

Selects a set of WSMO elements restricted by bags (Identifier bags, Category bags, tModel bags, BusinessEntity). It has to be taken into account, that bags used for retrieval have to use keys and values used during Publishing.

A query has the following input:

• ´authInfo´ (mandatory or optional depends on UDDI implementation)
• Category bag (optional)
• Identifier bag (optional)
• tModel bag (optional)
• business URI (optional)

If no input is provided, from a query point of view all WSMO services should be returned, but the actual number depends on the UDDI implementation.

Batch Retrieval

Makes available all WSMO elements. For high volumes, a subscription mechanism would be required, which is not worked out here in detail.

The standard UDDI query interface is used. Use of bags requires knowledge of what properties publishers use in them.

4.6.2 Retrieval by non-WSMO aware Client

As today such a client would retrieve by Category bag, tModel, partial name, and business provider. The client would select http (or fax, e-mail, etc.) binding. The binding would derive instances. The caller would call the WSMO service, unaware of it’s WSMO properties and binding.

4.6.3 Retrieve WSMO Elements

Retrieving published WSMO Goals and Ontologies is straight forward using standard UDDI find functions by any combination of name, business, categories, identifiers taking into account the specifications for Publishing.

The same is true for WSMO Services (including Mediator Services) unless it is required to search with identifiers (e.g. WSMO properties mapped into Identifier bags), since UDDI V2 does not allow to search for services by identifiers. The workaround to that is:

1) Select Categorization Scheme (mandatory)

Additional Category bag entries may be added.

2) Select Service Owner (optional) Define the Owner / Creator the Ontology Goal Owner

3) Search for tModels

UDDI find_tModel function is used, supplying name, Category bag Identifier bag as described above.

For each returned tModel, the tModel-detail contains the WSMO Service Extension URL.

To find the Service, for each tModel-Key, a find_service with the Category bag with exactly one entry as described above must be executed.

5. Conclusion

Although a customized solution for WSMO would provide some benefits, taking UDDI as a starting point for a Registry seems to be a good approach. The main advantage using UDDI as a first implementation for a WSMO Registry is, that a lot of mechanisms needed in a Registry (like access rights, administration, interfaces) are already defined, specified and implemented. Secondly, coexistence with existing Web Services is ensured and existing Web Services can be "upgraded" to WSMO by applying WSMO properties.

Mapping of the WSMO Non Functional Properties into the UDDI data model needs some more investigation and should be finalized as soon as the content and format of the NFPs are fixed and agreed.

For WSMO, UDDI will be used in a very specific manner. It is recommended to provide a wrapper API that shields the publisher and retriever from dealing with details of the mapping. As well, some validation features could also be added.

Acknowledgement

The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto, and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programme.

The editors would like to thank to all the members of the WSMO working group for their advice and input to this document.

webmaster