DIP
Data, Information and Process Integration with Semantic Web Services
FP6 - 507483
Deliverable
D6.3
DIP component APIs
Vesselin Kirov
Atanas Kiryakov
08 March 2016
DIP component APIs
1
EXECUTIVE SUMMARY
This deliverable provides an overview of the application programming interfaces (API)
of the components provided in the DIP architecture document (D6.2). The level of
granularity and maturity of the specification of the different interfaces varies across the
components. For some of them, there are fully-operational APIs defined in the
corresponding programming language (Java) or web service specification language
(WSDL). Other components are still not specified in such detail due to the need of
further developments of the conceptual framework or the architecture. Whenever
possible, this deliverable provides examples of how to use these components to
integrate the whole DIP execution environment.
This deliverable takes input from number of places: (i) the DIP Architecture, D6.2; (ii)
the different component specifications developed within workpackages WP1, WP2,
WP4, and WP5 and (iii) WSMX execution environment, which provides interface
specifications, not available elsewhere. The interfaces, defined here should be of
interest to the use-case partners and to technology providers which develop components
implementations. Document Information
IST Project
Number
FP6 – 507483
Full title
DIP component APIs
Project URL
http://dip.semanticweb.org
Acronym
DIP
Document URL
EU Project officer Brian Macklin
Deliverable
Number
Work package
Number 6
Title
Date of delivery
Contractual
M 12
Status
6.3 Title
DIP component APIs
Interoperability and Architecture
Actual
Version. 0.1
Nature
Prototype  Report  Dissemination 
Dissemination
Level
Public  Consortium 
Authors (Partner)
Vesselin Kirov (Sirma)
Responsible
Author
Vesselin Kirov
Email
Partner SIRMA
Phone +359 2 9768310
Deliverable 6.3
veskok@sirma.bg
1
DIP component APIs
Abstract
This deliverable provides an overview
(for
of the application programming
dissemination) interfaces of the DIP components
developed in WP1-5.
Keywords
SWS architectures, SWS
interoperability, SWS API
Project Consortium Information
Partner
Acronym
NUIG
National University of Ireland Galway
Monica Martinez Montes
Fundacion de la Innovation. BankInter
Paseo Castellana, 29
28046 Madrid,
Spain
Email: mmtnez@bankinter.es
Tel: 916234238
Berlecon
Dr. Thorsten Wichmann
Berlecon Research GmbH
Oranienburger Str. 32
10117 Berlin,
Germany
Email: tw@berlecon.de
Tel: +49 30 2852960
Berlecon Research GmbH
BT
British Telecommunications Plc.
EPFL
Dr John Davies
BT Exact (Orion Floor 5 pp12)
Adastral Park Martlesham
Ipswich IP5 3RE,
United Kingdom
Email: john.nj.davies@bt.com
Tel: +44 1473 609583
Prof. Karl Aberer
Distributed Information Systems Laboratory
École Polytechnique Féderale de Lausanne
Swiss Federal Institute of Technology,
Lausanne
Bât. PSE-A
1015 Lausanne, Switzerland
Email : Karl.Aberer@epfl.ch
Tel: +41 21 693 4679
Essex
Essex County Council
Deliverable 6.3
Prof. Dr. Christoph Bussler
Digital Enterprise Research Institute (DERI)
National University of Ireland, Galway
Galway
Ireland
Email: chris.bussler@deri.org
Tel: +353 91 512460
Bankinter
Fundacion De La Innovacion.Bankinter
Forschungszentrum Informatik
Contact
FZI
Mary Rowlatt,
Essex County Council
PO Box 11, County Hall, Duke Street
Chelmsford, Essex, CM1 1LX
United Kingdom.
Email: maryr@essexcc.gov.uk
Tel: +44 (0)1245 436524
Andreas Abecker
Forschungszentrum Informatik
2
DIP component APIs
Haid-und-Neu Strasse 10-14
76131 Karlsruhe
Germany
Email: abecker@fzi.de
Tel: +49 721 9654 0
UIBK
Prof. Dieter Fensel
Institute of computer science
University of Innsbruck
Technikerstr. 25
A-6020 Innsbruck, Austria
Email: dieter.fensel@deri.org
Tel: +43 512 5076485
ILOG
Christian de Sainte Marie
9 Rue de Verdun, 94253
Gentilly, France
Email: csma@ilog.fr
Tel: +33 1 49082981
Inubit
Torsten Schmale
inubit AG
Lützowstraße 105-106
D-10785 Berlin
Germany
Email: ts@inubit.com
Tel: +49 30726112 0
Institut für Informatik, Leopold-Franzens
Universität Innsbruck
ILOG SA
inubit AG
iSOCO
Intelligent Software Components, S.A.
OU
Dr. John Domingue
Knowledge Media Institute
The Open University, Walton Hall
Milton Keynes, MK7 6AA
United Kingdom
Email: j.b.domingue@open.ac.uk
Tel.: +44 1908 655014
SAP
Dr. Elmar Dorner
SAP Research, CEC Karlsruhe
SAP AG
Vincenz-Priessnitz-Str. 1
76131 Karlsruhe, Germany
Email: elmar.dorner@sap.com
Tel: +49 721 6902 31
The Open University
SAP AG
Sirma
Atanas Kiryakov,
Ontotext Lab, - Sirma AI EAD
Office Express IT Centre, 3rd Floor
135 Tzarigradsko Chausse
Sofia 1784, Bulgaria
Email: atanas.kiryakov@sirma.bg
Tel.: +359 2 9768 303
Tiscali
Dieter Haacker
Tiscali Österreich GmbH.
Sirma AI Ltd.
Tiscali Österreich Gmbh
Deliverable 6.3
Dr. V. Richard Benjamins, Director R&D
Intelligent Software Components, S.A.
Pedro de Valdivia 10
28006 Madrid, Spain
Email: rbenjamins@isoco.com
Tel. +34 913 349 797
3
DIP component APIs
Diefenbachgasse 35
A-1150 Vienna
Austria
Email: Dieter.Haacker@at.tiscali.com
Tel: +43 1 899 33 160
Unicorn
Unicorn Solution Ltd.
VUB
Vrije Universiteit Brussel
Jeff Eisenberg
Unicorn Solutions Ltd,
Malcha Technology Park 1
Jerusalem 96951
Israel
Email: Jeff.Eisenberg@unicorn.com
Tel.: +972 2 6491111
Carlo Wouters
Starlab- VUB
Vrije Universiteit Brussel
Pleinlaan 2, G-10
1050 Brussel ,Belgium
Email: carlo.wouters@vub.ac.be
Tel.: +32 (0) 2 629 3719
2
TABLE OF CONTENTS
1
EXECUTIVE SUMMARY.............................................................................................. I
2
TABLE OF CONTENTS .............................................................................................. IV
3
INTRODUCTION ........................................................................................................ 1
4
EXPOSED FUNCTIONALITIES OF THE DIP COMPONENTS ........................................ 1
4.1
Communication Manager ................................................................................. 1
4.2
Execution Manager ........................................................................................... 1
4.3
Event Listeners ................................................................................................. 1
4.4
Event Manager .................................................................................................. 2
4.5
Resource Manager ............................................................................................ 2
4.6
Discovery .......................................................................................................... 2
4.7
Invocation ......................................................................................................... 2
4.8
Mediation (Data)............................................................................................... 3
4.9
Semantic Repository ......................................................................................... 3
4.10
Service Registry................................................................................................ 4
4.10.1 Publishing ................................................................................................. 4
4.10.2 Retrieval ................................................................................................... 5
4.11 Choreography and Orchestration (ORCA) ....................................................... 5
5
DIP COMPONENT APIS ........................................................................................... 5
5.1
Communication Manager ................................................................................. 5
5.2
Execution Manager ........................................................................................... 5
Deliverable 6.3
4
DIP component APIs
5.3
Event Listeners ................................................................................................. 5
5.3.1
Interfaces .................................................................................................. 6
5.4
Event Manager .................................................................................................. 6
5.5
Resource Manager ............................................................................................ 6
5.5.1
Interfaces .................................................................................................. 6
5.5.2
Examples .................................................................................................. 7
5.6
Discovery .......................................................................................................... 8
5.6.1
Interfaces .................................................................................................. 8
5.7
Invocation ....................................................................................................... 11
5.8
Mediation (Data)............................................................................................. 11
5.8.1
Interfaces ................................................................................................ 11
5.8.2
Usage examples ...................................................................................... 11
5.9
Semantic Repository ....................................................................................... 12
5.10
Web Service Registry ..................................................................................... 13
5.10.1 Interfaces ................................................................................................ 13
5.10.2 Usage examples ...................................................................................... 14
5.11 Choreography and Orchestration .................................................................... 17
6
5.11.1 Interfaces ................................................................................................ 17
ADDITIONAL COMMON APIS ................................................................................. 18
6.1
WSMO API and Reference Implementation .................................................. 18
6.2
Ontology Management Tools ......................................................................... 19
7
CONCLUSION .......................................................................................................... 20
8
REFERENCES .......................................................................................................... 20
Deliverable 6.3
5
FP6 – 504083
Deliverable 6.3
3
INTRODUCTION
This deliverable provides an overview of the application programming interfaces (API)
of the components provided in the DIP architecture document (D6.2). The level of
granularity and maturity of the specification of the different interfaces varies across the
components. For some of them, there are fully-operational APIs defined in the
corresponding programming language (Java) or web service specification language
(WSDL). Other components are still not specified in such detail due to the need of
further developments of the conceptual framework or the architecture. Whenever
possible, this deliverable provides examples of how to use these components to
integrate the whole DIP execution environment.
This document is structured as follows: Section 4 contains the descriptions of the
functionalities exposed in each of the components in the DIP architecture; Section 5
presents the APIs of the components plus usage examples; Section 6 describes
interfaces of components which are not part of the execution environment architecture,
but still appear to be relevant to integration of the different software developed within
DIP.
This document contains a considerable volume of source-code listings integrated within
the corresponding sections of its main body. Although the good-looking layout requires
the listings to be provided as annexes, this is not appropriate in this case, as long, as
those represent an essential part of its content.
This deliverable takes input from number of places: (i) the DIP Architecture, D6.2; (ii)
the different component specifications developed within workpackages WP1, WP2,
WP4, and WP5 and (iii) WSMX execution environment, which provides interface
specifications, not available elsewhere. The interfaces, defined here should be of
interest to the use-case partners and to technology providers which develop
components implementations.
4
Exposed functionalities of the DIP Components
4.1 Communication Manager
The communication manager’s API is the external API for the DIP runtime
environment. It handles the incoming SOAP messages to and from web service
providers or requesters, validates them and in case they are not WSML descriptions it
invokes a message adapter to convert them to WSML.
4.2 Execution Manager
This is the central component in DIP. It holds the entire workflow of the execution
environment. The workflow could be static (hard-coded) or based on a declarative
description of the execution semantics of the system. In [6] the WSMO working group
will maintain a description of the execution semantics of WMSO/DIP.
4.3 Event Listeners
Each ‘first class’ component in the DIP architecture (for instance, discovery,
matchmaker, mediator, etc.) will have a corresponding event listener interface in the
execution manager (like the Event Listener components that reside in the WSMX
manager [5]). These listeners will be responsible to process the corresponding events
coming from the event manager. It will be the responsibility of the Execution Manager
1
FP6 – 504083
Deliverable 6.3
to register each of the listeners in the Event Manager. That might happen, for instance,
when a new component becomes available to the execution manager or when the
workflow rules change and new types of messages should be processed.
4.4 Event Manager
The event manager handles the event processing in the DIP execution environment. The
current implementation uses a fixed set of events and fixed rules for subscribing to
those events by a fixed set of worker components. A complete description of the
internals of the component, please look in [5].
4.5 Resource Manager
The resource manager is a component that abstracts the actual datastores/repositories
used in DIP. The idea is that each component needing to store or retrieve data needs
only to be concerned about calling this component’s operations in order to store/retrieve
DIP objects – all the implementation details about where and how to store the object is
up to the implementer of the resource manager.
The objects accessed/retrieved through the manager will be identified by a unique URI.
It is up to the resource manager implementation to map a logical unique URI to a
physical location (whether local or remote). One possible solution to that problem is to
expose an additional API to allow mapping of parts of the logical URI (f.e. the domain)
to a physical datastore. In the examples to the resource manager (section 5.5.2) we will
provide such an example.
4.6 Discovery
In DIP when we talk about semantic discovery of web services we mean the discovery
of abstract services [3] represented by formal service capabilities [1] which are part of
the semantic description of the web service published in the DIP registry by the
provider. The requesters on their part use a goal description to describe their service
requirements.
So in general the discovery process is defined as semantically matching the goal of the
requester to all known to the registry services capabilities and returning all abstract
services that match the goal ranked by a matching score similar to the one described in
[4]
4.7 Invocation
The DIP execution environment will implement two distinct types of Web Service
invocations.
Whenever the choreography/orchestration component needs to invoke a web service
that is known to be implemented through DIP/WSMX then the invocation can be
translated into a simple call to the remote DIP execution environment that would pass a
WSML document.
In cases when the service that has to be called is a traditional web service the invoker
needs to find a registered message adapter that can convert the WSML call into a call to
the traditional web service.
2
FP6 – 504083
Deliverable 6.3
The current implementation expects the WSDL description of the web service to be
available with the semantic web service description. In the future versions WSMO will
provide grounding directly from the web service description.
4.8 Mediation (Data)
There are two sorts of mediation needed when two components cannot communicate
directly but need to interact. On one hand, data mediation is required in the case when
one component is not capable to (correctly and fully) interpret the content of a message
sent by another component. On the other, process mediation is necessary in case the two
components cannot negotiate on a single interaction protocol. Here we address the datamediation component, because it is composition and function are still not clarified to the
end (see section 2.4 of D6.2, [8]).
The basic functionality of a data mediation module is to transform messages from
source format to a target one, which could require both syntactic and semantic
transformation.
4.9 Semantic Repository
The semantic repository (SEMR) is an ontology server which allows for storage,
retrieval, and querying of ontologies and other data: semantic web service descriptions,
instance data, etc. Within the architecture of DIP, there is no clear separation between
the functions of an ontology reasoner and a repository. As outlined in D2.2, [7], a key
role of the semantic repository is to provide an integrated and semantically uniform
access to data which originally comes from diverse data-sources.
It is the case that with most of the reasoning paradigms there are number inferencespecific tasks, e.g. satisfiability checking and realization (instance classification).
However, in the context of a semantic web services infrastructure, the components, not
directly involved in ontology management, are not expected to directly request these
tasks. The requests to the semantic repository will be for storage, retrieval, or querying.
The existence of a reasoner will only have an effect on the “quality” of the results of
these operations, but not to the interfaces required. For instance, suppose there are facts
asserted saying that
<partOf, type, TransitiveProperty>
<Sofia, partOf, Bulgaria>
<Bulgaria, partOf, Europe>
Than suppose a query is sent to the system asking for all parts of Europe. A repository,
which is equipped with a reasoner which “understands” the semantic of the transitive
properties, will return Sofia as an answer, while a “dumb” repository will not, because
this fact is not explicitly asserted.
Similar considerations can be applied to the different sorts of ontology management
tools. There is no doubt, that those are important part of an integrated solution, because
they allow for basic tasks such as ontology editing and mediation. However, this
functionality is not directly accessed in the context of a web-service execution
environment. The ontology tools help managing the ontologies and the data stored in
the repository, which is the access point for all the remaining ontology-aware
applications and tools. This is interaction schema is demonstrated at Figure 1.
3
FP6 – 504083
Deliverable 6.3
Clients
(Ontology-Aware Systems)
Ontology Management
Tools
Semantic Repository
(Repository and/or Reasoner)
Structured Data-Source
(Database, Ontology Server)
Figure 1. Interaction with Semantic Repository
The semantic repository component in DIP is required to serve at least the following
groups of tools:

Ontology management tools, those developed in WP1 and WP2;

Semantic Web Service development tools (WSMO Studio and others, WP4);

Semantic Web Service execution environment (WSMX and WP4).
SEMR should also provide a proper framework for execution of ontology-mappingbased semantic transformation in the course of data mediation, see [9].
4.10 Service Registry
This component is specified in D4.2 and provides to the other DIP components an API
that facilitates the publishing and non-semantic (syntactic and structural) retrieval of
DIP elements (ontologies, mediators, goals, DIP web services etc.). D4.2 states that the
registry will contain links to the semantic information about the published DIP elements
and that the retrieval process will be able to return these links based on search using
UDDI v2 query language. Two main use cases for the API have been identified in D4.2
– the discovery process and the (semi)automatic service composition.
4.10.1 Publishing
The publishing functionality of the DIP registry will be available as a web service that
has operations to publish a DIP Web Service, a Mediator Service, Ontology and a Goal.
In order to facilitate the retrieval of these elements through the standard UDDI find
functionality, some of the WSMO non-functional properties [1] will be stored directly
in the underlying UDDI registry (e.g. title, identifier, etc.). Then it would be possible to
find the DIP object based on these properties. The complete list can be found in D4.2,
chapter 4.
4
FP6 – 504083
Deliverable 6.3
4.10.2 Retrieval
The retrieval of DIP elements from the registry will be available as a web service that
provides operations to retrieve DIP Web Services, Mediator Services, Ontologies or
Goals according to certain search criteria. The search criteria is based on the WSMO
non-functional properties that are mapped into the underlying UDDI registry; the AND,
OR or LIKE find qualifiers and wildcards (limited to the title property).
4.11 Choreography and Orchestration (ORCA)
This component implements the choreography and orchestration in the DIP execution
environment as defined in WSMO.
As such, each message coming in to the DIP execution environment passes through
ORCA and each message going out is initiated by ORCA and passed through the
invoker.
Also, this component takes the responsibility to maintain the state of each conversation
with an external entity – through a choreography instance when the invocation is
incoming to the DIP environment or through the orchestration when the invocation is
outgoing from the DIP environment.
5
DIP Component APIs
5.1 Communication Manager
The APIs of the communication manager will be described in a separate deliverable
D6.4, [12], and they’ll be seen as the main entry point of the DIP execution
environment.
5.2 Execution Manager
The execution manager will manage the internal workflow of the DIP environment. In
the current WSMX implementation the execution semantics is hard-coded and as such
there is no need for APIs to this component.
In the future the internal workflow will be described declaratively and at that stage we
envision adding external APIs to the component.
The first interface we expect to have will be called Registrar and it will enable the
components doing the actual work in the execution environment to register/unregister
dynamically from the manager.
Another interface called Configuration will enable other components (f.e. an
administrative front-end) to change the workflow rules or the components to be used for
specific tasks.
Based on the current configuration and workflow rules the execution manager will
register the appropriate event types in the event manager and will also create and
register all the event listeners it will need to do its work.
5.3 Event Listeners
Event listener is common name for the set of interfaces a component should expose in
order to subscribe to events in the Event Manager of DIP. At the moment two main
components are identified that will expose such interfaces and respectively will receive
5
FP6 – 504083
Deliverable 6.3
events from the event manager – the Execution Manager and the Communication
Manager. The Execution Manager will register the event listeners for all the tasks
performed during the processing of a request to the DIP runtime (f.e. matchmaking,
discovery, mediation). The Communication Manager will register a listener for an end
of processing event so it will know when to return the results back to the original
requester.
5.3.1 Interfaces
The event listeners expose a single interface called EventListener with a single
operation called handleNewEvent(Event) that returns a status indicating whether the
event was consumed by the listener or not.
5.4 Event Manager
The current implementation of the event manager does not need any external APIs since
all the subscriptions and all the subscribed components are hard-coded.
In the next revisions of this document we may add an API that will enable dynamic
change of the subscription policies and the types of events.
In that case the API will expose two interfaces: the EventFactory interface that would
enable components to register/unregister types of events or to create events and
EventListenerFactory that will be the one the components would use to
subscribe/unsubscribe to events.
5.5 Resource Manager
The resource manager will be provided as a java component (possibly an EJB).
5.5.1 Interfaces
The manager will expose one interface called ResourceManager with two operations:
void store(DIPObject objectToStore,URI logicalURI)
DIPObject get(URI logicalURI)
One possible implementation of the mapping of a logical URI to a physical location is
to implement an additional interface called ResourceMapper with a single operation void
map(URI partialLogicalURI,URI physicalURI). An example of such a solution will be
provided in the next sub-section.
Similar mapping problem is also addressed with the Locator interface of the WSMO
API (section 6.1), which maps logical IDs to physical addresses for WSMO elements.
6
FP6 – 504083
Deliverable 6.3
5.5.2 Examples
The first example shows how to use the ResourceManager interface.
package org.semanticweb.dip.examples.ResourceManager;
import java.net.URI;
public class Manager {
public static void main(String[] args) {
try {
URI logicalCityURI = new URI(
"http://test.dip.org/ontologies/locations/city.wsml");
ResourceManagerInterface resourceManager
=resourceManagerHome.getManager();
resourceManager.store(cityOntology,logicalCityURI);
DIPObject cityOntologyCopy=resourceManager.get(logicalCityURI);
if(!cityOntologyCopy.equals(cityOntology)) {
System.out.println("Error storing the ontology");
}
} catch(Exception ex) {ex.printStackTrace();}
}
}
The second example shows a possible implementation of the mapping of logical URIs
to physical locations.
This is the interface declaration.
package org.semanticweb.dip.ResourceManager;
import java.net.URI;
public interface Mapper {
public void mapPhysicalURI(URI partialLogicalURI,URI physicalLocation) throws Exception;
public URI getPhysicalURI(URI fullLogicalURI) throws Exception;
}
7
FP6 – 504083
Deliverable 6.3
And this is a possible implementation:
package org.semanticweb.dip.ResourceManager;
import java.net.URI;
import java.util.Hashtable;
import java.net.URISyntaxException;
public class MapperImpl implements Mapper {
/**
* This class keeps mappings of logical domains to physical URIs
*/
Hashtable mappings=new Hashtable();
/**
* Maps the domain part of a logical URI to a physical store.
* @param logicalDomainURI - the logical URI (only the domain part is used).
* @param physicalLocation - a physical URI location
* @throws java.lang.Exception
*/
public void mapPhysicalURI(URI logicalDomainURI,URI physicalURI) throws Exception {
if(logicalDomainURI.isOpaque()) {
// We do not support opaque logical URIs since they don't have a domain.
throw new URISyntaxException("We support only hierarchical logical URIs","opaque");
}
assert logicalDomainURI.getHost()!=null;
mappings.put(logicalDomainURI.getHost(),physicalURI);
}
/**
*
* @param fullLogicalURI - the logical URI (only the domain part is used).
* @return the physical URI
* @throws java.lang.Exception
*/
public URI getPhysicalURI(URI fullLogicalURI) throws Exception {
assert fullLogicalURI.getHost()!=null;
return (URI)mappings.get(fullLogicalURI.getHost());
}
protected MapperImpl() {
}
}
5.6 Discovery
The discovery component will be available as a web service that exposes a single
interface – Discovery.
5.6.1 Interfaces
The discovery web service exposes two operations – DiscoverRankedServices and
DiscoverRankedServiceUrls. The first takes a WSMO goal and returns a ranked list of
web services represented by their semantic service descriptions. The second takes again
a WSMO goal and returns a ranked list of URLs to the semantic descriptions of the
services. The schema types of the goal, ranking and service descriptions are still work in
progress.
Listing 1: Discovery web service WSDL description
<definitions
name="DiscoveryService"
8
FP6 – 504083
Deliverable 6.3
targetNamespace="http://www.dip.semanticweb.org/discovery/DiscoveryService.wsdl"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.dip.semanticweb.org/discovery//DiscoveryService.wsdl"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsd2="http://www.dip.semanticweb.org/discovery//DiscoveryService.xsd2">
<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Describes a WSDL interface for DIP
semantic discovery service</documentation>
<types>
<xsd:schema
targetNamespace="http://www.dip.semanticweb.org/discovery//DiscoveryService.xsd2"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsd2="http://www.dip.semanticweb.org/discovery//DiscoveryService.xsd2">
<xsd:complexType name="RankedUrl">
<xsd:annotation>
<xsd:documentation>URL to a Web Service Description ranked by the discovery
service</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="url" type="xsd:string"/>
<xsd:element
maxOccurs="1"
minOccurs="1"
name="ranking"
type="xsd2:ToBeSpecified"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RankedService">
<xsd:annotation>
<xsd:documentation>A Web Service Description ranked by the discovery
service</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element
maxOccurs="1"
minOccurs="1"
name="serviceDescription"
type="xsd2:ToBeSpecified"/>
<xsd:element
maxOccurs="1"
minOccurs="1"
name="ranking"
type="xsd2:ToBeSpecified"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="Query">
<xsd:annotation>
<xsd:documentation>Query containing a goal to be send to the discovery
service.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="goal"
type="xsd2:ToBeSpecified"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="RankedServiceList">
<xsd:annotation>
<xsd:documentation>A list of ranked services discovered by the discovery
service</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element
maxOccurs="unbounded"
minOccurs="0"
name="rankedService"
9
FP6 – 504083
Deliverable 6.3
type="xsd2:RankedService"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ToBeSpecified">
<xsd:annotation>
<xsd:documentation>IMPORTANT: This type is used whenever further specification
is required.</xsd:documentation>
</xsd:annotation>
</xsd:complexType>
<xsd:complexType name="RankedUrlList">
<xsd:annotation>
<xsd:documentation>List of ranked Urls discovered by the discovery
service.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element
maxOccurs="unbounded"
minOccurs="0"
name="rankedUrl"
type="xsd2:RankedUrl"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</types>
<message name="DiscoverRankedUrlsRequest">
<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">InMessage for the
DiscoverRankedServiceUrls operation</documentation>
<part element="xsd2:Query" name="query"/>
</message>
<message name="DiscoverRankedServicesRequest">
<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">InMessage for the
DiscoverRankedServices operation</documentation>
<part element="xsd2:Query" name="query"/>
</message>
<message name="DiscoverRankedUrlsResponse">
<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">OutMessage for the
DiscoverRankedServiceUrls operation</documentation>
<part element="xsd2:RankedUrlList" name="result"/>
</message>
<message name="DiscoverRankedServicesResponse">
<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">OutMessage for the
DiscoverRankedServices operation</documentation>
<part element="xsd2:RankedServiceList" name="result"/>
</message>
<portType name="DiscoveryServicePortType">
<operation name="DiscoverRankedServices">
<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Takes a query containing a
goal and returns a ranked list of discovered Web Service Descriptions </documentation>
<input message="tns:DiscoverRankedServicesRequest"/>
<output message="tns:DiscoverRankedServicesResponse"/>
</operation>
<operation name="DiscoverRankedServiceUrls">
<documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">Takes a query containing a
goal and returns a ranked list of URLs to the discovered Web Service Descriptions </documentation>
<input message="tns:DiscoverRankedUrlsRequest"/>
<output message="tns:DiscoverRankedUrlsResponse"/>
</operation>
</portType>
<binding name="DiscoveryServiceBinding" type="tns:DiscoveryServicePortType">
<binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="DiscoverRankedServices">
<operation
soapAction="capeconnect:DiscoveryService:DiscoveryServicePortType#DiscoverRankedServices"
style="document"/>
<input>
10
FP6 – 504083
Deliverable 6.3
<body use="literal"/>
</input>
<output>
<body use="literal"/>
</output>
</operation>
<operation name="DiscoverRankedServiceUrls">
<operation
soapAction="capeconnect:DiscoveryService:DiscoveryServicePortType#DiscoverRankedServiceUrls"
style="document"/>
<input>
<body use="literal"/>
</input>
<output>
<body use="literal"/>
</output>
</operation>
</binding>
<service name="DiscoveryService">
<port binding="tns:DiscoveryServiceBinding" name="DiscoveryServicePort">
<address location="http://localhost:8000/ccx/DiscoveryService"/>
</port>
</service>
</definitions>
5.7 Invocation
The invocation component is implemented as a java interface called
exposes a single method called invoke:
Invoker
that
invoke(WebService webService, WSMLDocument document): InvokerResult
5.8 Mediation (Data)
TODO: to summarize the interfaces specified in D5.2 and WSMX
5.8.1 Interfaces
5.8.2 Usage examples
11
FP6 – 504083
Deliverable 6.3
5.9 Semantic Repository
To meet the diverse requirements towards it, the Semantic Repository component of
DIP is specified as a part of the Ontology Management System (OMS), which is
developed in the scope of the Ontology Management Working Group
(http://www.omwg.org). OMS is build around an implementation of the Ontology
Representation and Data Integration (ORDI) conceptual framework, presented in D2.2,
[7]. The ORDI implementation, on itself, is based on the ontology representation
package of the WSMO API, presented in section 6.1. This comprehensive dependency
schema was implemented in order to make sure that, “by design”, the web-service
related tools (WSMO Studio) and the OMS are interoperable. Further, it assures that all
the tools based on these interfaces will be able to use various reasoning and repository
implementations, which implement them.
WSMO4J
Reference Implementation
WSMO Studio
Ontology
Management Suite
SWS Integrated Development
Environment
WSMO API
Interface Definitions
ORDI
Ontology
Ontology Representation
& Data Integration
Repository
Reasoner
(Sesame,
YARS)
(KAON2)
Other
Datasources
Figure 2. Semantic Repository-related Interfaces
The interfaces for the Semantic Repository will be specified within an ORDI
implementation. Its main features can be specified as follows:

To extend the org.wsmo.IO sub-packages of the WSMO API with further
interfaces, supporting behaviors and use cases necessary in ontology
management and data integration. Whenever, necessary, the interfaces specified
in the www.omwg.Ontology and org.wsmo.Common packages will also be extended.

Implementations of the IO.Parser interface for (parsing of and serialization to)
different syntaxes and languages will be provided. The first candidates in this
direction are the RDF/XML syntax for RDFS and OWL and the XML WSML
Syntax.
12
FP6 – 504083
Deliverable 6.3

Wrappers of the different semantic repositories will be developed as
implementations of the IO.Datastore interface (and its extensions in ORDI). The
first candidates in this direction are Sesame and KAON 2. The later is the
reasoner developed within WP1. Sesame is one of the most popular, and
probably the most efficient, RDF repository, which got extended recently with a
partial OWL Lite support. YARS is a high-performance, distributed, semantic
repository which will be further extended and delivered as D2.5 of DIP. YARS
fits in the Sesame architecture as a specific storage and inference layer; thus, the
Sesame wrapper will meet number of goals:
o integration of YARS;
o access to a number of other storage and inference implementations,
ranging from point-and-click in-memory packages to MySQL and
ORACLE-based ones;
o access to a mature RDFS infrastructure with support for number of
syntaxes (XML, N-Triples, N3) and query languages (SeRQL, RDQL,
RQL).
Up until this phase of the project, the efforts were concentrated into development of the
WSMO API, which has a very central role in DIP and number of other WSMO-related
projects. This delayed a bit the implementation of ORDI, which is dependent on it. As a
result, ORDI implementation is still not available. The only semantic repository
interface, currently defined, is org.wsmo.IO.Datastore one within the WSMO API:
public interface DataStore {
void save (Identifiable object);
Identifiable load (URIRef objectID);
boolean contains (URIRef objectID);
}
This interface, allows for storage and retrieval of WSMO elements of arbitrary
granularity, including top-level ones (such as web services descriptions and ontologies),
but also elementary ones (such as concepts and attributes).
5.10 Web Service Registry
5.10.1 Interfaces
The interfaces of the two web services that offer the public API of the DIP registry are
documented respectively in chapters 4.2 and 4.3 of D4.2. We’ll provide here a brief
overview of them.
5.10.1.1 Publishing Interface
The operations dipPublishService, dipPublishMediatorService, dipPublishOntology,
and dipPublishGoal take as parameters the business entity that owns the element
(string), the set of non-functional properties that will be mapped to UDDI (set of
strings), the URI of the WSML document that represents the element and an
authentication
token.
In
addition
the
dipPublishService
and
dipPublishMediatorService operations take the WSDL of the corresponding web
service that is being stored (It seems this is not needed – at the moment the WSML
description for web services includes the grounding of the service, have to make a
13
FP6 – 504083
Deliverable 6.3
comment to D4.2). All of the four operations return the registry generated key of the
element. All the four operations may compile/store the WSML description locally or
just verify it and store a link to it.
There are four corresponding operations for deleting DIP elements stored in the
registry: dipDeleteService, dipDeleteMediatorService, dipDeleteOntology and
dipDeleteGoal. These take as a parameter the key returned from the corrseponding
publish operation and again an authentication token.
5.10.1.2 Retrieval Interface
There
are
four
operations
in
this
interface:
dipRetrieveService,
and dipRetrieveGoal. All of those
need two parameters – a find query type (AND, OR, LIKE) and the text of the query.
The text should obey the UDDI query syntax and roughly speaking consists of key
value pairs. The keys are the DIP element properties and the publisher information
listed in the Publishing Interface in chapter 5.10.1.1 of D4.2. The find query type might
be missing, AND is assumed in that case.
dipRetrieveMediatorService, dipRetrieveOntology
All the functions return a list of the corresponding type (retrieveServiceResultType for
service and mediator service, retrieveOntologyResultType for ontologies, and
retrieveGoalResultType for goals). Each of the elements of the list contains the set of
non-functional properties and the URI of the WSML description. The
retrieveServiceResultType type contains also the WSDL of the corresponding service.
5.10.2 Usage examples
The java code fragments below provide examples of using the DIP registry API through
Apache WSIF.
The first example is publishing an ontology to the registry, the ontology is the date/time
example ontology bundled with the WSMX environment.
package org.semanticweb.dip.examples.Registry;
import org.apache.wsif.util.*;
import javax.wsdl.*;
import org.apache.wsif.*;
import java.util.Iterator;
import java.util.Hashtable;
import javax.xml.namespace.QName;
public class Publishing {
public static void main(String[] args) {
try {
Definition def = WSIFUtils.getDefinitionFromLocation("file:///C:/publish/","publish.wsdl");
// Create WSIFService object using WSIFServiceFactory with WSDL definition as parameter.
WSIFServiceFactory factory=WSIFServiceFactory.newInstance();
WSIFService serv = factory.getService(def);
// Map the complex dipElementPropertiesAbstractType xsd type to a java class
// implementation
serv.mapType(
new QName("urn:dip-org:publish_v1", "dipElementPropertiesAbstractType"),
Class.forName(
"org.dip.ws.dipElementPropertiesAbstractType"));
// Create WSIFPort using WSIFService object with port name as parameter.
WSIFPort port = serv.getPort("PublishPort");
// Create WSIFOperation using WSIFPort with operation, input and output names as parameters.
WSIFOperation op = port.createOperation("dipPublishOntology", "publishOntologyDescription",
"publishOntologyKey");
14
FP6 – 504083
Deliverable 6.3
// Create container for the input message
WSIFMessage input = op.createInputMessage();
// Create container for the output message
WSIFMessage output = op.createOutputMessage();
// Create container for the fault message
WSIFMessage fault = op.createFaultMessage();
// Set parameter values for the input message, e.g.,
Hashtable inputParts=new Hashtable();
inputParts.put("authToken","{2C3E7212-D130-45C0-B250-57EC7AB3AF84}");
inputParts.put("serviceKey","{FFCD4A9A-89E5-48AE-AD00-895279CE906F}");
inputParts.put("businessEntity","DERI International");
org.dip.ws.dipElementPropertiesAbstractType descr=new
org.dip.ws.dipElementPropertiesAbstractType();
descr.setPublisher("DERI International");
descr.setCreator("DERI International");
descr.setDescription("generic representation of data and time including basic algebra");
descr.setTitle("Date and Time Ontology ontology");
descr.setDate("2004-07-06");
descr.setFormat("text/plain");
descr.setCoverage("World");
descr.setLanguage("en-US");
descr.setRelation("http://www.isi.edu/~pan/damltime/time-entry.owl,
http://www.w3.org/TR/xmlschema-2/");
descr.setSubject("Date, Time, Date and Time Algebra");
inputParts.put("descr",descr);
inputParts.put("wnfp","http://www.wsmo.org/2004/d3/d3.2/v0.1/20040607/resources/dt.wsml");
input.setParts(inputParts);
// Execute operation
boolean success = op.executeRequestResponseOperation(input, output, fault);
WSIFMessage toUse=fault;
if(success) {
toUse=output;
}
Iterator parts=toUse.getParts();
while(parts.hasNext()) {
System.out.println(parts.next());
}
} catch(Exception ex) {ex.printStackTrace();}
}
}
The second example retrieves from the registry all ontologies published by DERI.
package org.semanticweb.dip.examples.Registry;
import org.apache.wsif.util.*;
import javax.wsdl.*;
import org.apache.wsif.*;
import java.util.Iterator;
import java.util.Hashtable;
import javax.xml.namespace.QName;
public class Retrieval {
public static void main(String[] args) {
try {
Definition def = WSIFUtils.getDefinitionFromLocation("file:///C:/publish/","retrieve.wsdl");
// Create WSIFService object using WSIFServiceFactory with WSDL definition as parameter.
WSIFServiceFactory factory=WSIFServiceFactory.newInstance();
WSIFService serv = factory.getService(def);
// Map the complex retrieveOntologyResultType xsd type to a java class
// implementation
serv.mapType(
new QName("urn:dip-org:retrieve_v1", "retrieveOntologyResultListType"),
Class.forName(
"org.dip.ws.retrieveOntologyResultListType"));
15
FP6 – 504083
Deliverable 6.3
serv.mapType(
new QName("urn:dip-org:retrieve_v1", "RetrieveOntologyResultType"),
Class.forName(
"org.dip.ws.RetrieveOntologyResultType"));
// Map the complex dipElementPropertiesAbstractType xsd type to a java class
// implementation
serv.mapType(
new QName("urn:dip-org:retrieve_v1", "dipElementPropertiesAbstractType"),
Class.forName(
"org.dip.ws.dipElementPropertiesAbstractType"));
// Create WSIFPort using WSIFService object with port name as parameter.
WSIFPort port = serv.getPort("RetrievePort");
// Create WSIFOperation using WSIFPort with operation, input and output names as parameters.
WSIFOperation op = port.createOperation("dipRetrieveOntology", "QueryDipElements",
"retrieveOntologyResultList");
// Create container for the input message
WSIFMessage input = op.createInputMessage();
// Create container for the output message
WSIFMessage output = op.createOutputMessage();
// Create container for the fault message
WSIFMessage fault = op.createFaultMessage();
// Set parameter values for the input message, e.g.,
Hashtable inputParts=new Hashtable();
inputParts.put("authToken","{2C3E7212-D130-45C0-B250-57EC7AB3AF84}");
inputParts.put("dipFindOrLikeQualifier","AND");
inputParts.put("retrieveQuery","{creator=DERI International}");
input.setParts(inputParts);
// Execute operation
boolean success = op.executeRequestResponseOperation(input, output, fault);
if(!success) {
Iterator parts=fault.getParts();
while(parts.hasNext()) {
System.out.println(parts.next());
}
} else {
org.dip.ws.retrieveOntologyResultListType ontologies =
(org.dip.ws.retrieveOntologyResultListType)output.getObjectPart("tns:retrieveOntologyResultListBody
");
org.dip.ws.RetrieveOntologyResultType[] ontologyArr=
ontologies.getRetrieveOntologyResultList();
for(int i=0;ontologyArr!=null && i<ontologyArr.length;i++) {
org.dip.ws.RetrieveOntologyResultType ontology=ontologyArr[i];
System.out.println(ontology.getWnfp()+", creator:
"+ontology.getDipElementPropertiesAbstract().getCreator());
}
}
} catch(Exception ex) {ex.printStackTrace();}
}
}
16
FP6 – 504083
Deliverable 6.3
5.11 Choreography and Orchestration
The ORCA component is under development at the moment in WSMX [5]. It will be
implemented as a java component; below we present the preliminary version of the API
of the component.
5.11.1 Interfaces
The interface of the choreography engine is defined as follows:
public interface ChoreographyEngine {
private Choreography loadChoreography(ID id);
private ID getID(ID id);
public void send(Message message, ID id);
public void receive(Message message, ID id);
}
17
FP6 – 504083
Deliverable 6.3
6
Additional common APIs
In addition to the component APIs there are also number of other, in a sense lowerlevel, interfaces which are important for the interoperability across the tools and
components in DIP.
6.1 WSMO API and Reference Implementation
The WSMO API is a set of programming interfaces, which main function is to provide a
Java binding for the WSMO semantic web services framework. The current version of
the WSMO API (RC2) is compliant with WSMO version 1.0, [2]. The strucutre of the
API is depicted on Figure 3, where the dependency between the modules (Java
packages) goes from the bottom to the top.
WSMO Studio
WSMO4J
SWS Integrated Development
Environment
Reference Implementation
Ontology
Management Suite
WSML Parser
Editing and Browsing
File Datastore
Mediation
In-memory
Structures
WSMO API
Versioning
ORDI
Interface Definitions
Ontology Representation
& Data Integration
Mediator
Import/Export Parsers
Goal
Data Integration
Service
Ontology
Reasoner Wrappers
Common & IO
Repository Wrappers
Figure 3. WSMO API and WSMO4J
Here follows brief enumeration and short description of the packages:

Common: the most general primitives, e.g.: identifiers, literals, variables, and
non-functional properties.

IO: input and output related interfaces, namely:

Parser: taking care for parsing from or serialization to a particular
syntax;

Datastore: defining the basic store and load interfaces, see section 5.9.

Locator: interfaces that allow physical locators to be mapped to logical
identifiers in a flexible manner.
18
FP6 – 504083
Deliverable 6.3

Ontology: contains ontology-specific interfaces (ontologies, concepts, instances,
relations, axioms, logical expressions, etc.) This package represents the bridge to
ORDI and the ontology management tools developed within the Ontology
Management Working Group (http://www.omwg.org). For this reason, the
package namespace is org.omwg.ontology.*, in contrast to the other packages of
the WSMO API, which names start with org.wsmo.*.

Goal, Service, Mediator: interfaces modelling the corresponding primitives in
WSMO. These are all dependent on Common, IO, and Ontology packages.
WSMO API is a purely abstract set of interfaces. It means, that other programs may not
use it directly – they could only use a particular implementation of this interfaces.
WSMO4J is a reference implementation of the WSMO API, which allows its usage
without any further development. WSMO4J includes:

Implementations of the primitive-modelling interfaces from the Ontology, Goal,
Service, and Mediator packages (e.g. concept, instance, goal, service).

Implementation of the Parser interface (parsing and serialization) with respect to
the WSML user-friendly syntax, [10].

Implementation of the Datastore interface, providing persistency on top of
proprietary binary file storage.

Implementation of the Locator interface.
The WSMO API and WSMO4J are open-source, available together at the wsmo4j
SourceForge project, having its home page at http://wsmo4j.sourceforge.net/.
Documentation of the API is available there as a JavaDoc reference, as well as a
programmers guide, [10].
6.2 Ontology Management Tools
The different ontology management tools (apart from the semantic repository) are not
first-class citizens of the DIP architecture, as long as those are not directly involved in
web service execution. Still, it is the case that some of them could fit as components in
customized web-service development environments. Those are discussed in a bit more
detail in D6.4, [12] – here we only mention their existence.
The ontology management tools of DIP (WP2) are developed as part of the work of
OMWG. The roadmap of the group determines that an integrated extensible Ontology
Management System will be implemented on the basis of the Eclipse1 framework,
version 3.0. The particular tools are developed as separate plug-ins, which interoperate
through shared data models.
The same approach (Eclipse-based architecture) is agreed for the design of a semantic
web services development environment, named WSMO Studio. It will include number
of plug-ins, amongst which WSMO browser and editor.
As presented at Figure 3, WSMO Studio and the OMS will both use the WSMO API
(section 6.1). The later together with Eclipse, provides sufficient ground for
interoperability, even though, the two environments will be developed independently.
1
http://www.eclipse.org/
19
FP6 – 504083
Deliverable 6.3
7
CONCLUSION
This deliverable provided a roadmap towards the programming interfaces of the various
components of the DIP architecture. For many components, the interfaces are still not
specified in detail due to the fact that the corresponding aspects of the conceptual
framework are not finalized yet. Further, the level of granularity of the presented
interfaces is still quite different, which could be accounted to the early stage of the
development of the architecture.
8
WHILE THIS WAS AN EXPECTED SITUATION, THE PROJECT PLAN
ENVISIONS, A UPDATE OF THE APIS TO BE PRESENTED IN DELIVERABLE
D6.9 “REVISION OF THE COMPONENTS APIS”. IT IS THE
UNDERSTANDING OF THE AUTHORS, THAT THE CURRENTLY EXISTING
APIS PROVIDE SUFFICIENT LEVEL OF DETERMINISM TO ALLOW
REASONABLY SMOOTH SOFTWARE DEVELOPMENT IN THE MIDDLE
PHASE OF THE PROJECT.REFERENCES
TODO: there reference formatting has to be unified
[1] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard
(WSMO - Standard), 2004, version 0.2. http://www.wsmo.org/2004/d2/v02/
[2] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology (WSMO),
2004, version 1.0. http://www.wsmo.org/2004/d2/v1.0/
[3] Chris Preist and Dumitru Roman (eds.). D12v0.1. Web Service Modeling Ontology Full (WSMO - Full), WSMO Working Draft 24 June 2004. http://www.wsmo.
org/2004/d2/v03/.
[4] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, and Katia Sycara. Semantic
Matching of Web Services Capabilities. In Proceedings of the 1st International
Semantic Web Conference (ISWC2002), 2002.
[5] Michal Zaremba, Matthew Moran, Emilia Cimpian, Adrian Mocan, Eyal Oren,
Matthew Moran (eds.): WSMX Implementation (WSMO Working Draft), 2004, version
0.1; http://www.wsmo.org/2004/d13/d13.5/v0.1/
[6] E. Oren: WSMX Execution Semantics (WSMO Working Draft), 2004, version 0.1;
http://www.wsmo.org/2004/d13/d13.2/v0.1/
[7] Atanas Kiryakov, Damyan Ognyanoff, Vesselin Kirov. (2004) An Ontology
Representation and Data Integration (ORDI) Framework. Deliverable D2.2 of the DIP
project.
[8] Manfred Hauswirth, Roman Schmidt, Michael Altenhofen, Christian Drumm, Chris
Bussler, Matthew Moran, Michal Zaremba, Laurentiu Vasiliu, Joachim Quantz,
Laurent Henocque, Armin Haller, Brahmananda Sakpota, Edward Kilgariff, Simeon
Petkov, David Aiken, Eyal Oren, Manuel Ohlendorf, Adrian Mocan. DIP Architecture.
Deliverable D6.2 of the DIP project.
[9] Atanas Kiryakov, Christian Drumm, Lina Al-Jadir, and et.al. D5.2: Mediation Module
Specification: Business Data-Level Mediation. DIP deliverable. Dec. 2004
[10] Marin Dimitrov, Damyan Ognyanov. (2004). wsmo4j Programmer’s Guide.
http://wsmo4j.sourceforge.net/doc/wsmo4j-prog-guide.pdf
[11] J. de Bruijn, H. Lausen, and D. Fensel. The WSML Family of Representation
Languages,
v0.2.
DERI,
Nov
2004.
http://www.wsmo.org/2004/d16/d16.1/v0.2/20041126/.
20
FP6 – 504083
Deliverable 6.3
[12] Vesselin Kirov, Atanas Kiryakov. D6.4: Description of the external DIP APIs to be
used by the case studies. (Original name: Description of the mediation function
interface to be used by the case studies) DIP deliverable. Dec. 2004
21