Skip to topic | Skip to bottom

Start of topic | Skip to actions

Draft Feta Interface

This is a draft proposal for the new Feta interface. (It has not been implemented).

Feta service representation

A seperate client side software is written to publish and reconstruct feta services. The software is based on the feta service schema attached.

All elements in this XML schema are mapped to existing entities in the registry's WSDL, metadata and UDDI interfaces. For each serviceDescription, a WSDL file is automatically generated to store the operations and parameters.

ServiceDescription? UDDI businessService
serviceName UDDI businessService name
organisation UDDI businessEntity (see *)
author service metadata
location URL binding template
interface WSDL tModel
serviceDescriptionText UDDI businessService description
operations WSDL operations
serviceType service metadata

* All s in a belong to the same business Entity.

ServiceOperation? WSDL operation
operationName WSDL operation name
operationSpec operation metadata
operationDescriptionText operation metadata
operationInputs WSDL message part
operationOutputs WSDL message part
operationTask operation metadata
operationResource operation metadata
operationResourceContent operation metadata
operationMethod operation metadata
operationApplication operation metadata

OrganisationType? UDDI businessEntity
name UDDI business name
description UDDI business description

InterfaceType? UDDI bindingTemplate
name binding metadata
description binding description
locationURI binding access point
operation tModelInstanceDetails -> tModelKeys

ParameterType? WSDL message part
name message part name
transportDataType message part type
description message part metadata
semanticType message part metadata
isConfigurationParameter message part metadata
formats message part metadata

service publication


This will be in the format of
<save_service serviceKey="">
Returns a serviceDetail with an assigned fetaServiceKey on success. If a serviceKey is supplied and already exist in grimoires, it will replace the existing entry. This can be used to update an existing fetaService.





This operation searches for a list of services matching certain specified criteria. Composite search is achieved by using more than one elements. The elements defined are those supplied by Pinar.
<complextType name="find_service">
    <element name="input" type="string" minOccurs="0" maxOccurs="unbounded">
    <element name="output" type="string" minOccurs="0" maxOccurs="unbounded">
    <element name="task" type="string" minOccurs="0" maxOccurs="unbounded">
    <element name="resource" type="string" minOccurs="0" maxOccurs="unbounded">
    <element name="method" type="string" minOccurs="0" maxOccurs="unbounded">
    <element name="application" type="string" minOccurs="0" maxOccurs="unbounded">
    <element name="name" type="string" minOccurs="0" maxOccurs="unbounded">
    <element name="description" type="string" minOccurs="0" maxOccurs="unbounded">

The query returns the hasServiceNameText and hasOperationNameText in the feta service. We could do something similar:


We already have the RDQLs for query by application, input, output, method, resource and task.


Returns a feta service with a given fetaServiceKey


Returns a list of all feta service registered. This is equivalent to GetAll?.

Ontology publication

A new Inference Model will need to be added to grimoires for RDFS type reasoning. This is how we could set it up in Jena:
   Model GrimoiresTripleStore;
   Model FetaOntology;
   InfModel InferenceModel = new InfModel(FetaOntology, GrimoiresTripleStore);
Triples added from the existing interfaces and feta services will be stored in the GrimoiresTripleStore? model. The FetaOntology? Model is for storing feta ontology files. Queries from the feta interface is done via the InferenceModel?, all queries in other interfaces are done via the GrimoiresTripleStore? Model. This means reasoning is not turned on in other interfaces.

Every time a new triple is added to GrimoiresTripleStore?, we need to call InfModel?::rebind() to reconsult the underlying data. I believe we only need to do the rebind only for publishing in the feta interface.

Changes in the ontology model is not re-read with a rebind(). A new InfModel? has to be created.

If we decide to store feta data in a separate Model (say FetaTripleStore?), and want the Model's data to be available to other interfaces, then a union operation of GrimoiresTripleStore? and FetaTripleStore? is needed whenever either model is updated. (We assume there will be more inquiries than publications).




Either or both:
  1. Clears all statements in the feta ontology model.
  2. Supply a URL of the ontology to remove. The ontology file must still exist as this operation involves removing triples contained in the file.

General metadata

The requirments document mentions the annotation of metadata to feta services. This can be achieved using grimoires metadata interface by adding a new entityReference type for it. Proposed entityType is (We may use the namespace we give for the feta.wsdl).

Client libraries and testing

We would provide the Java classes created by WSDL2Java as the client library. This should allow feta to call the new interface directly within Java. As such, I'd suggest writing junit tests using the Java classes as well.

-- SylviaWong - 22 Feb 2005
direct publication of feta services, ontology, general metadata, testing
-- SylviaWong - 23 Feb 2005
representation of feta services
-- SylviaWong - 24 Feb 2005 more ontology stuff
-- SylviaWong - 20 Apr 2005 feta XML schema and how it's mapped to grimoire's existing entities.

  • common.xsd: feta service description XML schema v1.4 2005/07/10

to top

I Attachment sort Action Size Date Who Comment
common.xsd manage 6.4 K 18 Jul 2005 - 12:53 SylviaWong feta service description XML schema v1.4 2005/07/10

You are here: Grimoires > InterfaceDocuments > FetaInterface

to top

Copyright 2004 by the University of Southampton