Personalised Service Discovery
Juri Papay, Simon Miles, Michael Luck and Luc Moreau
School of Electronics and Computer Science
University of Southampton
{jp,sm,mml,L.Moreau}@ecs.soton.ac.uk
Introduction
Public
Registry1
...
AFFYMAPPER
Notification when
services registered
BLAST
Personalised Registry2
copies information from
Personalised Registy1,
Selecting services with
a trust value > 0.6
Personalised Registry1
copies information from
multiple public
registries
Services without
metadata
Personalised
Registry1
Currently, there is a multitude of public and private Service Registries, with a wide variation in the
amount and quality of their contents. The availability of accurate and reliable information on the
services available to a scientist is important when constructing e-Science experiments. For any given
registry, the user faces a dilemma of whether to trust the accuracy and adequacy of the information
present. This can be resolved by creating registries whose contents are personalised to a user, so the
user can be sure the services are described in a way that is accurate and useful to them. Further, a
personalised service registry can be used in automatic service discovery in the knowledge that any
service found will be personally useful to the user. Personalised service registries operate by copying
information from public registries, possibly filtering the service adverts by some criteria, and allowing
the user to annotate the service adverts with personal judgements, extra useful information (including
semantic descriptions) and other metadata. A personalised service registry may also be used by a
group, such as an organisation rather than a single user. This poster illustrates a use case for myGrid
personalised service registries and provides details on the way in which this has been implemented.
Filtering based on
metadata
Notification message
Personalised
Registry2
OPENBQS
0.7
GOQUERY
0.8
XEML
OPENBQS
Query for details
Public
RegistryN
GOQUERY
Results
...
...
Use Case
Results
In the use case shown, there are several registries deployed. First, there are a set of public registries
(Public Registry 1 to N) with service adverts published by a range of service providers. The
information presented will sometimes be incomplete and contains no indication about whether a
service will be useful to a particular user. Next, within an organisation, the local domain expert has
their own personalised registry (Personalised Registry 1). This registry is automatically kept up-todate with the contents of the public registries, and the expert can then provide ratings to each service
(in a range from 0.0 to 1.0) specifying how reliable they have found the service to be in the past.
These ratings can represent the cumulative knowledge of the organisation and may be added by many
people. Finally, a new member of the organisation (a novice) is given their own personalised registry
(Personalised Registry 2), which is automatically kept up-to-date with the contents of the expert's
registry, but only includes those services that have been given a rating higher than 0.5. Therefore,
whenever the novice performs service discovery to find a service for their particular task, only those
services that the organisation has found to be reliable are returned. Keeping personalised registries
up-to-date with respect to other registries is achieved by subscription to notifications of change. An
intermediary myGrid notification service provides robustness through asynchronicity.
Query for details
Services with metadata
AFFYMAPPER
The information in
Personalised Registry1 is
curated: a curator is adding
a trust values to advertised
services
BLAST
0.4
XEML
0.5
OPENBQS
GOQUERY
AddMetadataTo_
BusinessService
AddMetadataTo_
MessagePart
AddMetadataTo_
Operation
Internal messages
API calls
0.8
ServiceUpdated
wsdlChanged
metadataChanged
ServiceDeleted
WSDLChanged
Notification
wsdlChanged
WSDLChanged
API calls
Internal messages
The overall design of the Personalised Service Registry is based on a
message-passing architecture, in which each operation call is processed by a
chain of message-handlers. Each handler can process a specific set of
messages, and can be replaced by any handler capable of processing the
same set. Using this architecture, the processing of every operation call can
be easily adapted by extending the chain of handlers or replacing one handler
with another performing a different function for the same messages. The
figure describes how the messages move around internally: the APIs,
handlers, sequence of method calls and messages that are used in the
implementation of the use case. The main functionality of methods in the
API is to generate various types of internal messages. The processing may
involve Personalised Registry 2 querying Personalised Registry 1 for more
service details so that the whole advertisement can be copied between
registries. After obtaining the service details, Personalised Registry 2
performs a selection operation, the outcome of which determines whether to
store the service details locally or to discard the downloaded information.
Semantic Service Registry Architecture
Information
model
Metadata Publish
Interface
Semantic Inquiry
Interface
addWSDLFile
Message Passing Architecture
addMetadataTo_
BusinessService
addMetadataTo_
MessagePart
addMetadataTo_
Operation
UDDI Publish
Interface
Metadata Inquiry
Interface
delete_service
MetadataChanged
UDDI Inquiry
Interface
Client
RegistryEventHandlerIncoming
serviceUpdated
save_service
RegistryEventHandlerOutgoing
UDDIPublishHandler
NewService
Registered
RegistryEvent (API)
ADDWSDLFile
newService
Registered
serviceDeleted
WSDLHandler
WSDL (API)
addMetadataTo_
BusinessService
addMetadataTo_
MessagePart
addMetadataTo_
Operation
DeleteService
MetadataHandler
UDDIPublishServer (API)
addWSDLFile
PublishMetadata (API)
delete_service
SaveService
0.7
...
Expert
save_service
0.3
Jena RDF Triple
Store
Database,
file or
memory
storage
Notifications
of Change
Semantic Find
Component
The current Grid and Web Service standards provide limited support
for semantic service descriptions. The service registry developed by
the myGrid team at Southampton provides support not only for UDDI,
DAML-S, BioMoby and WSDL service descriptions, but also a
mechanism for semantic annotation of services and a uniform way of
querying and navigating service information. The client interacts with
the registry through a set of interfaces, which allow services and
workflows to be published, discovered and annotated according to
known protocols. By attaching semantic descriptions to service
advertisements, users can discover services based on their domain
knowledge. The Semantic Find Component is an interface that
processes users’ semantic queries. Other features of the registry include
sending of notifications to other registries and policy-based content
management. The service and workflow descriptions are stored in an
RDF triple store which can be queried uniformly through the use of a
query language such as RDQL.