Skip to topic | Skip to bottom
Grimoires
Grimoires.UDDITechnicalCommitteeResponse

Start of topic | Skip to actions

Matthew,

Here are the ideas we developed for extending UDDI to allow for metadata to be attached to service adverts and be used in discovery, and how workflows are published and discovered. These ideas were initiated in myGrid and being developed in Grimoires. Feel free to distribute this to those that were at the UDDI meeting on Thursday.

First, we do not change the UDDI APIs/port types, so ensuring that clients aware of only the UDDI protocol can also use the registry. We introduce two new APIs for publishing metadata and discovering on the basis of metadata.

Using the publish interface, the client can add to (or update) metadata attached to a referenceable entity. A referenceable entity is an identifiable part of a service advert such as a service, a business, a WSDL operation, a WSDL message part (operation input/output). The operation is defined in the WSDL as follows:

  <portType name="PublishMetadataPort">
    <operation name="addMetadataToEntity">
      <input message="tns:addMetadataToEntity" />
      <output message="tns:MetadataInfo" />
      <fault name="error" message="tns:dispositionReport"/>
    </operation>
    ...

  <xsd:complexType name="addMetadataToEntity">
    <xsd:sequence>
      <xsd:element ref="meta:entityReference"/>
      <xsd:element ref="meta:metadata"/>
    </xsd:sequence>
  </xsd:complexType>

A referenceable entity is identified by the minimum information required to do so. For example, to attach metadata to a service, the service key is used. For a WSDL operation, because it is scoped by the port type it is defined as part of, requires the namespace and name of the port type as well as the operation name to uniquely identify it. Metadata can be attached to metadata (e.g. to provide comments on others comments on a service). Our current, draft definition of the entity reference is shown below.

  <xsd:complexType name="EntityReference">
    <xsd:sequence>
      <xsd:element name="entityType" type="xsd:string"/>
      <xsd:choice>
        <xsd:element ref="uddi:businessKey"/>
        <xsd:element ref="uddi:serviceKey"/>
        <xsd:element ref="meta:metadataKey"/>
        <xsd:element ref="meta:messagePartReference"/>
        <xsd:element ref="meta:operationReference"/>
        <xsd:element ref="meta:otherKey"/>
      </xsd:choice>
    </xsd:sequence>
  </xsd:complexType>

Influenced by the fact that myGrid wanted primarily to use metadata to attach semantic descriptions to services, operations and inputs/outputs, the form of a piece of metadata's value is one of the following: - A string - A URI (such as a term from a remote ontology) - A set of RDF triples forming a complex description as a labelled directed graph (we call this a triples assertion) A piece of metadata also has a type which scopes the value and defines how it should be parsed.

  <xsd:complexType name="Metadata">
    <xsd:sequence>
      <xsd:element ref="meta:metadataType"/>
      <xsd:element ref="meta:metadataKey"/>
      <xsd:element ref="meta:metadataValue"/>
    </xsd:sequence>
  </xsd:complexType>

  <xsd:complexType name="MetadataValue">
    <xsd:choice>
      <xsd:element ref="meta:triplesAssertion"/>
      <xsd:element ref="meta:stringValue"/>
      <xsd:element ref="meta:uriValue"/>
      <xsd:element ref="meta:author"/>
      <xsd:element ref="meta:date"/>
    </xsd:choice>
  </xsd:complexType>

Metadata is identified by a UUID metadata key generated on publishing, as with UDDI services. This allows it to be updated and deleted. As with UDDI services etc., updating is achieved by providing a valid metadata key to the save method (addMetadataToEntity). This is the delete operation:

  <operation name="deleteMetadata">
    <input message="tns:deleteMetadata" />
    <output message="tns:Void" />
    <fault name="error" message="tns:dispositionReport"/>
  </operation>

  <xsd:complexType name="deleteMetadata">
    <xsd:sequence>
      <xsd:element ref="meta:metadataKey"/>
    </xsd:sequence>
  </xsd:complexType>

The inquiry operations we currently have are of the following types: - An extension of the standard UDDI find_service operation which adds an extra parameter, MetadataInfoBag?, specifying the metadata that the discovered service must have - Find a given referenceable entity- service, business, operation, message part etc.- by the metadata attached to it - Get the metadata attached to a given referenceable entity

The first of the operations listed above is defined as follows:

  <operation name="find_service">
    <input message="tns:find_service" />
    <output message="tns:serviceList" />
    <fault name="error" message="tns:dispositionReport"/>
  </operation>

  <xsd:complexType name="find_service">
    <xsd:sequence>
      <xsd:element ref="uddi:findQualifiers" minOccurs="0"/>
      <xsd:element ref="uddi:name" minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element ref="uddi:categoryBag" minOccurs="0"/>
      <xsd:element ref="uddi:tModelBag" minOccurs="0"/>
      <xsd:element ref="meta:metadataInfoBag" minOccurs="0"/>
    </xsd:sequence>
    <xsd:attribute name="generic" type="string" use="required"/>
    <xsd:attribute name="maxRows" type="int" use="optional"/>
    <xsd:attribute name="businessKey" type="uddi:businessKey" use="optional"/>
  </xsd:complexType>

The form of a metadata query (MetadataInfo?) is either an exact match of the string or URI value, or an RDQL query to match an RDF graph or subset of it.

We also provide a workflow publishing and discovery API. A workflow is treated as a kind of service, and will be discovered by the standard UDDI find_service method. A piece of metadata is (internally) used to mark a service as being a workflow, and a method is provided to ask, for any given service key, whether that service is a workflow. The location of the workflow script is stored as the access point of the service. The workflow save operation records information similar to save_service, additionally allowing the publisher to specify the service keys of the services used by the workflow in case this is useful in discovery.

Thanks, Simon

-- SimonMiles - 28 Sep 2004
to top


You are here: Grimoires > NonUDDIFeatures > UDDITechnicalCommitteeResponse

to top

Copyright 2004 by the University of Southampton