This document is also available in non-normative PDF version.
Copyright © 2005 DERI®, All Rights
Reserved. DERI liability,
trademark, document use, and software licensing rules apply.
Web Services Modeling Ontology (WSMO, [Roman et al. 2004]) allows semantic description of Web Services. The current stack of Web Services specifications, on the other hand, consists of purely syntactic languages whose semantics is described in plain text. As WSMO is mostly complementary to the other specifications, it should be able to be deployed and used together with the others. Specifically, some of the Web Services specifications may want to carry or reference WSMO descriptions, and similarly WSMO descriptions may usefully include or reference elements from the current Web Services specifications.
This document is intended as a listing of those Web Services specifications that may use WSMO or be used by WSMO, together with a description of the mechanisms linking WSMO and the particular Web Services specifications.
Note that the word todo marks an unfinished part of the document.
Due to the modular nature of Web Services Specifications, various standardization bodies, industry alliances or even single vendors have been releasing many specifications relevant to Web Services, covering larger or smaller domains and purposes. It would be an enormous task to investigate the possible connection of WSMO with each of the specifications, but luckily we only need to focus on a small subset of the space.
Web Services specifications can be broadly categorized as description languages and protocols. Description languages are used to specify various (generally) static deployment and configuration aspects of Web Services. Protocols, on the other hand, specify the run-time behaviors necessary to achieve a specific purpose. As an example of this distinction we can take the domain of Web Services security which contains both description languages specifying the formats of security tokens like keys and encrypted data, and protocols specifying how those tokens are exchanged and used to achieve a confidential communication channel.
As WSMO falls into the category of description languages, this document focuses on relating WSMO to other description languages or to protocols that refer to or transfer pieces of descriptions. Initially we focus on standards (finised or under development) and on major finished non-standard industry specifications.
The following is a listing of the Web Services specifications that we have identified as potentially related to WSMO:
All specifications that are not discussed in a separate section (noted in the list above) are covered in section 6.
Note: relationship of WSMO with WSDL and XML Schema, while in scope of this document, is covered outside of this document, in the context of specification of WSMO grounding.
The Web Services Addressing specification [WSAddressing] defines a format for references to Web Services endpoints (so called endpoint references) and a set of message headers used for simple message routing and correlation purposes. Only the endpoint reference structure is directly relevant to WSMO.
The following is the structure of an endpoint reference in a pseudo schema:
01 <wsa:EndpointReference> 02 <wsa:Address>xs:anyURI</wsa:Address> 03 <wsa:ReferenceProperties> 04 ... 05 </wsa:ReferenceProperties> ? 06 <wsa:ReferenceParameters> 07 ... 08 </wsa:ReferenceParameters> ? 09 <wsa:PortType> 10 xs:QName 11 </wsa:PortType> ? 12 <wsa:ServiceName PortName="xs:NCName"?> 13 xs:QName 14 </wsa:ServiceName> ? 15 <wsp:Policy> 16 ... 17 </wsp:Policy>* 18 </wsa:EndpointReference>
Endpoint references contain several important pieces of data: address and reference properties (lines 2-5), which together uniquely identify the Web Service endpoint; reference parameters (lines 6-8) that are associated with the endpoint to facilitate a particular interaction; pointers to WSDL port type and service port (lines 9-14), also known as interface and service endpoint in WSDL 2.0; and finally a policy (lines 15-17).
When suitable, an endpoint reference can point to a WSDL interface (as in
the following example, lines 5-7) so that the recipient of this reference may
choose the appropriate code to use that interface. In similar spirit, we
introduce element wsml:serviceReference that refers to a WSMO
service description to be used in situations where the recipient of an
endpoint reference is able to tailor its behavior according to the semantic
description of the referenced endpoint (see the example, lines 8-10).
01 <wsa:EndpointReference> 02 <wsa:Address> 03 http://fabrikam123.example.com/acct 04 </wsa:Address> 05 <wsa:PortType> 06 fabrikam:InventoryPortType 07 </wsa:PortType> 08 <wsml:serviceReference> 09 http://fabrikam123.example.com/wsml/acct 10 </wsml:serviceReference> 11 </wsa:EndpointReference>
Regarding using WSMO as part of the policy in an endpoint reference, see section WSMO in WS Policy.
As described above, WS Addressing defines the XML structure of an Endpoint Reference. This structure is used in WS Addressing for routing information, but it it intended to be reused by any applications that require need to reference Web Services. In certain situations Endpoint References will be directly incorporated into messages passed between a Web Service and its client. In these scenarios the schema of the messages will refer to the Endpoint Reference, like in the following example:
01 <xsd:element name="ServiceCreationResponse"> 02 <xsd:complexType> 03 <xsd:sequence> 04 <xsd:element name="TTL" type="xsd:integer"/> 05 <xsd:element name="Endpoint" type="wsa:EndpointReferenceType"/> 06 </xsd:sequence> 07 </xsd:complexType> 08 </xsd:element>
Similarly, Semantic Web Services might need to exchange Web Service references. For this purpose we define a simple ontology for Endpoint References modeled after WS Addressing:
01 ontology <<http://wsmo.org/ontology/WebServices/>> 02 concept EndpointReference 03 hasAddress ofType (1) xs:anyURI 04 hasReferenceProperty ofType xmlLiteral 05 hasReferenceParameter ofType xmlLiteral 06 isWSDLPortType ofType xs:QName 07 isWSDLService ofType xs:QName 08 isWSDLPort ofType xs:NCName 09 isWSMOService ofType xs:anyURI /* because webService is not a concept */ 10 /* policy belongs to non-functional properties */
Web Services Policy Framework [WSPolicy] allows describing specific Web Services metadata (so called policies) used for expressing the capabilities, requirements, and general characteristics of Web Services.
WS Policy is a specification with significant industry backing. Interested parties are already creating policy assertions for various domains and the major commercial Web Services infrastructure stacks already have or are building support for policy-based Web Service invocations.
As detailed below, the WS Policy specification suite defines policies for simple general purposes like indicating languages and specifying general message preconditions, and more importantly it also defines policies for security requirements. While it is expected that Semantic Web Services will ultimately represent such policy assertions as logical conditions, it is crucial for the early adoption of WSMO that it does not require substantial changes in infrastructure that is already deployed. This section therefore proposes a way for WSMO descriptions to make use of the WS Policy specification suite.
The WS Policy Framework specification ([WSPolicy]) defines the following important terms:
The following is an example of a policy requiring the use of Kerberos or X509 security tokens:
01 <wsp:Policy> 02 <wsp:ExactlyOne> 03 <wsse:SecurityToken> 04 <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType> 05 </wsse:SecurityToken> 06 <wsse:SecurityToken> 07 <wsse:TokenType>wsse:X509v3</wsse:TokenType> 08 </wsse:SecurityToken> 09 </wsp:ExactlyOne> 10 </wsp:Policy>
Syntactically, WS Policy offers several ways of expressing policies, but all are equivalent to a single set of alternatives containing only atomic assertions.
WS Policy Framework is accompanied by further specifications:
WS Policy is meant "for expressing the capabilities, requirements, and general characteristics of entities in an XML Web Services-based system" [WSPolicy]. On the other hand, WSDL descriptions of Web Services are the entities to which policies are attached (see section 4 of WS Policy Attachment [WSPolicyAttachment]) while they would fit the above definition; this split indicates that not all capabilities, requirements and general characteristics qualify as policies.
In our position paper for W3C Workshop on Constraints and Capabilities for Web Services [Arroyo et al. 2004], we introduce a classification for capabilities and constraints on Web Services, most importantly the application-dependent distinction between functional and non-functional properties. For a meaningful use, the authors would constrain policy assertions to be only non-functional capabilities, constraints/requirements and other general characteristics, i.e. policies should not be used to describe the functional aspects.
From the point of view of aligning WSMO with WS Policy, the link between WSMO and WS Policy can go in two opposite directions - Policies can be used in WSMO descriptions of Web Services (see the subsection WS Policy in WSMO) or WSMO descriptions can be used (asserted) in WS Policy (see the subsection WSMO in WS Policy).
Because only non-functional properties should be modeled as policies, we present in this subsection a way to include policies as the non-functional properties in WSMO descriptions. In fact, the existing and future policy assertions could usefully complement the Dublin Core non-functional properties [DublinCore] currently used by WSMO.
[WSPolicyAttachment] defines in
section 3.3 an XML global attribute wsp:PolicyURIs that can
contain a list of URIs pointing to separate policies attached to the parent
XML element. In WSMO, we reuse the namespace-qualified name of the attribute
as a non-functional property name, with the value also being a list of URIs
of policies attached to the owner WSMO element.
01 service foo 02 nonFunctionalProperties 03 wsp:PolicyURIs hasValue 04 "http://www.fabrikam123.example.com/policies#DSIG 05 http://www.fabrikam123.example.com/policies#SECTOK" 06 endNonFunctionalProperties
In some cases it can be useful for manageability reasons to include the
whole policy in the WSMO description, especially when the policy is fairly
small. For this purpose we reuse the namespace-qualified name
wsp:Policy as the name of a non-functional property whose
content is the XML serialization of the whole Policy element.
This is illustrated by the following example:
01 service foo 02 nonFunctionalProperties 03 wsp:Policy hasValue 04 "<wsp:Policy> 05 <wsp:ExactlyOne> 06 <wsse:SecurityToken> 07 <wsse:TokenType>wsse:Kerberosv5TGT 08 </wsse:TokenType> 09 </wsse:SecurityToken> 10 <wsse:SecurityToken> 11 <wsse:TokenType>wsse:X509v3 12 </wsse:TokenType> 13 </wsse:SecurityToken> 14 </wsp:ExactlyOne> 15 </wsp:Policy>" 16 endNonFunctionalProperties
As a consideration towards composability of XML languages, WSML/XML should make sure that WS Policy syntax is preserved when a policy is a non-functional property of a WSMO description serialized as WSML/XML. The following example shows how this could presumably be done:
01 <wsml:webService name="foo"> 02 <wsml:nonFunctionalProperties> 03 <wsp:Policy> 04 <wsp:Policy> 05 <wsp:ExactlyOne> 06 <wsse:SecurityToken> 07 <wsse:TokenType>wsse:Kerberosv5TGT 08 </wsse:TokenType> 09 </wsse:SecurityToken> 10 <wsse:SecurityToken> 11 <wsse:TokenType>wsse:X509v3 12 </wsse:TokenType> 13 </wsse:SecurityToken> 14 </wsp:ExactlyOne> 15 </wsp:Policy> 16 </wsp:Policy> 17 </wsml:nonFunctionalProperties> 18 </wsml:webService>
The repeated, nested use of wsp:Policy element is caused by
the fact that the non-functional property is in fact named the same as the
root of the XML document it contains. Due to the way WS Policy Framework
handles different ways of writing policies, the nesting does not have any
negative effect on the meaning of the policy.
As future work it could be useful to represent the WS Policy Framework mechanisms of describing alternatives and conjunctions of policy assertions in a native WSMO logical language.
Since WS Policy can presumably also be used for expressing general characteristics of Web Services, in some applications we might use a policy assertion that points to a WSMO description of the Web Service, in effect associating that WSMO description with the policy subject.
From the point of view of the earlier claim that policies should only be used for non-functional properties, putting WSMO descriptions in WS Policy would be inappropriate, as WSMO describes both functional and non-functional properties of Web Service entities. On the other hand it can be easily envisioned that Web Services stacks will provide one major extensibility point that will allow plugins to handle specific policy assertions. Such an extensibility point may prove useful for extending the software to be able to process WSMO descriptions together with other policies. This could especially be useful for checking pre- and postconditions described in WSMO and for proper execution of mediators.
Because policy assertions must be XML elements, we can reuse WSML/XML
serialization format (see [de Bruijn 2004])
for representing WSMO descriptions as policy assertions in WS Policy. To
attach a whole WSMO description as a single policy assertion, we use the
element wsml. For finer granularity (e.g. only asserting
a single service or goal description) we can reuse the appropriate elements
like wsml:service and wsml:goal.
In some situations it may be beneficial only to refer to a WSMO
description (as opposed to including it inline as a policy assertion). For
refering to a whole WSML/XML file we introduce the element
wsml:ontologyReference that refers to a WSML/XML document, and
similarly we can introduce specific elements for referring to specific
elements of WSMO, for instance to refer to a service or a goal we can
introduce the elements wsml:serviceReference and
wsml:goalReference that would refer to the identifiers of the
WSMO service or goal descriptions.
The following is an example policy that claims the policy subject is described by the WSMO services http://example.org/services/ticketService and http://example.org/services/billingService:
01 <wsp:Policy> 02 <wsml:webService 03 name="http://example.org/services/ticketService"> 04 <wsml:capability 05 name="http://example.org/capabilities/ticketing" /> 06 </wsml:webService> 07 <wsml:ontology 08 name="http://example.org/ontologies/ticketing/"> 09 <wsml:concept 10 name="Ticket"/> 11 </wsml:ontology> 12 <wsml:serviceReference> 13 http://example.org/services/billingService 14 </wsml:serviceReference> 15 </wsp:Policy>
Lines 2-6 show a WSML/XML element wsml:webService that, in
this context, means a policy assertion assigning a WSMO service description
defined inline. Similarly, lines 12-14 show a reference to such a
description, using the new element wsml:serviceReference.
Finally, lines 7-11 contain an ontology, presumably used by the ticketService
definition.
The conclusion is that to represent a policy assertion like "the policy subject has the following WSMO description" we can use any global WSML/XML element as appropriate, and to represent a policy assertion only referencing a WSMO description we have to create specific elements for each type of WSMO entity that we want to reference.
Web Services have metadata to describe what their clients need to know to interact with them. Specifically, Web Services can have WS Policy [WSPolicy] policies, WSDL [WSDL] descriptions XML Schema [XMLSchema] schemata associated with them. WSMO [Roman et al. 2004] adds another form of Web Service metadata - their semantic descriptions.
To bootstrap communication with Web Services and to retrieve these and other types of metadata, Web Services Metadata Exchange (WS-MEX) [WSMEX] specification defines a protocol for requesting metadata from Web Services or from dedicated metadata endpoints, described shortly in section 4.1. It is natural for us to enable the retrieval of WSMO descriptions using WS-MEX, this is described in section 4.2.
From the point of view of WS-MEX, every Web Service can have multiple pieces of metadata in differing languages. To retrieve a service's metadata, a requester can use the Get Metadata request. As a part of the request message, the requester can specify the so-called dialect and identifier of the requested piece of metadata. The following illustrates the structure of the Get Metadata request message:
01 <soap:Body> 02 <wsx:GetMetadata> 03 [<wsx:Dialect>xs:anyURI</wsx:Dialect> 04 [<wxs:Identifier>xs:anyURI</wsx:Identifier>]? 05 ]? 06 </wsx:GetMetadata> 07 </soap:Body>
The response message contains zero or more so called metadata sections, as illustrated below:
01 <soap:Body> 02 <wsx:Metadata ...> 03 [<wsx:MetadataSection Dialect='xs:anyURI' 04 [Identifier='xs:anyURI']? > 05 [ 06 <dialectSpecificElementName>...</dialectSpecificElementName>+ 07 | 08 <wsx:Location>xs:anyURI</wsx:Location> 09 | 10 <wsx:MetadataReference ...> 11 endpoint-reference 12 </wsx:MetadataReference> 13 ] 14 </wsx:MetadataSection>]* 15 </wsx:Metadata> 16 </soap:Body>
Each metadata section uses the attribute Dialect (line 3) to
identify the language and version, in which the metadata is represented.
Appendix I of WS-MEX defines the dialect URIs for WSDL 1.1, XML Schema 1.0,
WS Policy and WS Policy Attachment and finally for WS Metadata Exchange
itself so that services can have nested metadata sets. The optional
dialect-dependent attribute Identifier (line 4) provides further
identification of this piece of metadata, usually its target namespace.
Each MetadataSection element contains either an actual
dialect-specific metadata element (line 6), for example
wsdl:definitions, or a pointer to another location, either on
the Web (wsx:Location, line 8) or in a dedicated Metadata Web
Service (wsx:MetadataReference, lines 10-12).
The element wsx:Location, when present, contains a URI on
which the piece of metadata with the specified dialect and identifier can be
obtained. This allows a service to point to its metadata available on the
Web.
The element wsx:MetadataReference, when present, contains a
WS Addressing ([WSAddressing]) endpoint
reference which identifies a service which will return the metadata upon a
simple SOAP request.
The following example demonstrates metadata received from a stock-quote service.
01 <wsx:Metadata> 02 <wsx:MetadataSection 03 Dialect='http://schemas.xmlsoap.org/wsdl/' 04 Identifier='http://server.example.org/stockquote'> 05 <wsdl:definitions 06 name='StockQuote' 07 targetNamespace='http://server.example.org/stockquote' 08 xmlns:tns='http://server.example.org/stockquote' 09 xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/' 10 xmlns:wsoap='http://schemas.xmlsoap.org/wsdl/soap/' > 11 <wsdl:import namespace='http://server.example.org/stockquote' 12 location='http://server.example.org/stockquote' /> 13 <wsdl:portType name='StockQuotePortType'> 14 <wsdl:operation name='GetLastTradePrice'> 15 <wsdl:input message='tns:GetLastTradePriceInput'/> 16 <wsdl:output message='tns:GetLastTradePriceOutput'/> 17 </wsdl:operation> 18 </wsdl:portType> 19 <wsdl:service name='StockQuoteService'> 20 <wsdl:port name='StockQuotePort' 21 binding='tns:StockQuoteBinding' > 22 <wsoap:address 23 location='http://server.example.org/endpoint' /> 24 </wsdl:port> 25 </wsdl:service> 26 </wsdl:definitions> 27 </wsx:MetadataSection> 28 29 <wsx:MetadataSection 30 Dialect='http://schemas.xmlsoap.org/ws/2004/09/policy' > 31 <wsx:MetadataReference> 32 <wsa:Address> 33 http://server.example.com/policyOfTheDay/stockQuote 34 </wsa:Address> 35 </wsx:MetadataReference> 36 </wsx:MetadataSection> 37 38 <wsx:MetadataSection 39 Dialect='http://www.w3.org/2001/XMLSchema' 40 Identifier='http://server.example.com/schemas/stockQuote'> 41 <wsx:Location> 42 http://server.example.com/schemas/stockQuote 43 </wsx:MetadataReference> 44 </wsx:MetadataSection> 45 </wsx:Metadata>
Lines 5 to 26 contain the WSDL description of the service, wrapped in a metadata section with the WSDL dialect (http://schemas.xmlsoap.org/wsdl/) and the identifier being the target namespace of this specific WSDL (http://server.example.org/stockquote).
Lines 29 to 36 contain another metadata section pointing to a policy (dialect http://schemas.xmlsoap.org/ws/2004/09/policy) available by accessing the Web Service at http://server.example.com/policyOfTheDay/stockQuote. Finally lines 38 to 44 contain a metadata section pointing to a schema (dialect http://www.w3.org/2001/XMLSchema) with the target namespace http://server.example.com/schemas/stockQuote which is available on the Web at the same URI (compare lines 40 and 42).
In order for WS Metadata Exchange to be able to carry WSMO descriptions, WSMO must simply provide a dialect URI identifying this language and optionally also a mechanism for assigning identifier URIs to different WSMO descriptions. In a way similar to WSDL, the dialect URI can be the namespace of WSML/XML [de Bruijn 2004] elements, http://wsmo.org/2004/wsml , but since WSML/XML files don't have any single identifying property (in particular, they don't have any targetNamespace notion), we cannot provide any value to the Identifier. The following is a simple example:
01 <wsx:Metadata> 02 <wsx:MetadataSection 03 Dialect='http://wsmo.org/2004/wsml' > 04 <wsml:wsml xmlns:wsml="http://wsmo.org/2004/wsml" > 05 <wsml:ontology 06 name="http://example.org/ontologies/ticketing/"> 07 <wsml:concept 08 name="Ticket"/> 09 </wsml:ontology> 10 </wsml:wsml> 11 </wsx:MetadataSection> 12 </wsx:Metadata>
todo
todo - WS Discovery, WSRF, BPEL4WS, WS-CDL, ebXML, WSPL
The sections above present their own conclusions, but in general we can say that WSMO descriptions can use WS Policy policies as non-functional properties, and that WS Addressing Endpoint References can point to WSMO descriptions in a similar fashion as they point to WSDL definitions. Additionally, the WS Metadata Exchange protocol can be used to discover and transfer WSMO descriptions of Web Services.
To that end, this document has introduced several new XML elements:
wsml:serviceReferencewsml:ontologyReferencewsml:goalReferenceFuture work (the todos) will focus on whether UDDI can be used for storing WSMO descriptions, or whether WSMO can usefully point to data stored in a UDDI repository. Later we will analyze whether (and how) other Web Services specifications can be combined with WSMO. For instance, security specifications were not reviewed yet.
todo
[Arroyo et al. 2004] S. Arroyo et al. (2004): Web Service Capabilities and Constraints in WSMO, position paper for W3C Workshop on Constraints and Capabilities for Web Services, available at http://www.w3.org/2004/08/ws-cc/wsmo-20040903
[WSAddressing] D. Box, F. Curbera (editors) (2004): Web Service Addressing, W3C member submission, available at http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
[WSDL] R. Chinnici, M. Gudgin, J-J. Moreau, J. Schlimmer, S. Weerawarana (editors): Web Services Description Language Part 1: Core Language, W3C Last Call Working Draft available at http://www.w3.org/TR/wsdl20/
[WSMEX] F. Curbera, J. Schlimmer (editors) (2004): Web Service Metadata Exchange, available at http://msdn.microsoft.com/ws/2004/09/mex/
[de Bruijn 2004] J. de Bruijn (editor): WSML/XML - An XML Syntax for WSML, available at http://www.wsmo.org/2004/d16/d16.3/v0.1/
[WSSecurityPolicy] A. Nadalin (editor): Web Services Security Policy Language, available at http://msdn.microsoft.com/ws/2002/12/ws-security-policy/
[WSPolicyAssertions] A. Nadalin (editor): Web Services Policy Assertions Language, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policyassertions.asp
[WSSecurity] A. Nadalin, C. Kaler, P. Hallam-Baker, R. Monzillo (editors): Web Services Security, available at http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf
[Roman et al. 2004] D. Roman, U. Keller, H. Lausen (editors): Web Service Modeling Ontology - Standard (WSMO - Standard), version 1.0 available at http://www.wsmo.org/2004/d2/v1.0/
[WSPolicy] J. Schlimmer (editor): Web Services Policy Framework, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policy.asp
[WSPolicyAttachment] C. Sharp (editor): Web Services Policy Attachment, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policyattachment.asp
[XMLSchema] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn (editors): XML Schema part 1: Structures, W3C Recommendation, 2001, available at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
[DublinCore] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: Dublin Core Metadata for Resource Discovery, IETF RFC 2413, September 1998, available at http://mirror.switch.ch/rfc/2413.txt.
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.
| Date | Author | Description |
|---|---|---|
| 2005/1/17 | jacek | Reorganized section on Addressing, added ontology for endpoint references |
| 2005/1/17 | jacek | dropped sections on WSDL and XML Schema, pointed to a future grounding document instead |
| 2005/1/17 | jacek | added examples in section on Policy |
| 2005/1/14 | jacek | changed reference style for specifications Rationale: names of authors or editors of specifications are irrelevant, what is relevant is name of specification (which is unique and descriptive) or names of author companies. I don't think anybody will want to mention company names as reference. |
| 2005/1/14 | jacek | Added changelog |
$Date: 2005/01/20 15:18:57 $