wsmo logo

D24.1v0.1 Aligning WSMO with existing Web services specifications

WSMO Working Draft 12 January 2007

This version:
Latest version:
Previous version:
Jacek Kopecký
Dumitru Roman

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.

Table of contents

1. Introduction
1.1 Relevant Web Services Specifications
2. Web Services Addressing
2.1 WS Addressing Overview
2.2 WS Addressing and WSMO
2.3 Ontology for Endpoint References
3. Web Services Policy
3.1 WS Policy Overview
3.2 Combining Policy with SESA and WSMO
3.2.1 Attaching Policies to Semantic Descriptions in WSMO
3.2.2 WSMO Assertions in WS-Policy
3.2.3 Policy in SEE components
3.2.4 Policy Tasks in SEE
3.3 Related Work
4. Web Services Metadata Exchange
4.1 WS-MEX Overview
4.2 Using WS-MEX to retrieve WSMO descriptions
6. Other Web Services Specifications
7. Conclusions and Further Work
Appendix A. XML Schema for elements introduced in this document
Change Log

1. Introduction

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.

1.1 Relevant Web Services Specifications

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.

2. Web Services Addressing

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.

2.1 WS Addressing Overview

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).

2.2 WS Addressing and WSMO

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>
04     </wsa:Address>
05     <wsa:PortType>
06       fabrikam:InventoryPortType
07     </wsa:PortType>
08     <wsml:serviceReference>
10     </wsml:serviceReference>
11  </wsa:EndpointReference>

Regarding using WSMO as part of the policy in an endpoint reference, see section WSMO in WS Policy.

2.3 Ontology for Endpoint References

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 <<>>
02    concept EndpointReference
03      hasAddress ofType (1) xs:anyURI
04      hasReferenceProperty ofType rdf:XMLLiteral
05      hasReferenceParameter ofType rdf: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 */

3. Web Services Policy

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.

The aim of this section is to investigate the potential relations between SESA and WSMO and the WS-Policy framework, and to offer a basis for further research on the use of policies in the context of semantically enriched service environments. Issues like policy conformance checking, policy-based semi-automatic negotiations between users and services, or policy-based matchmaking etc., are important in our context, however they are out of scope of this deliverable. The scope of this deliverable is limited to identifying the uses of WS-Policy in SESA, and proposing a concrete way for combining them.

The following subsection, i.e. Section 3.1 presents a brief overview of WS-Policy specifications. The concrete contributions of this section are presented in Section 3.2, and in short they are: the syntax for attaching WS-Policy policies to WSML components, the syntax for putting WSML descriptions as policy assertions inside policy alternatives, and the analysis of what WSMX/SEE components can include policy evaluation and for what tasks. Finally Section 3.3 talks about related work.

3.1 WS Policy Overview

In this section we give a brief overview of the Web Services Policy Framework ([WS-Policy]).

The Web Services Policy Framework provides a general purpose model and a syntax to describe the policies of a Web Service. The key feature of WS-Policy is its flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. In this context, WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements and capabilities.

At the core of WS-Policy stands the concept of policy expression which contains domain-specific, Web Service policy information. WS-Policy further defines a core set of constructs to indicate how choices and/or combinations of domain-specific policy assertions apply in a Web services environment. In the following we shortly describe the concepts of WS-Policy and the way they are related.

Policy. At the abstract level a policy is a potentially empty collection of policy alternatives. Alternatives are not ordered. They may differ significantly in terms of the behaviors they indicate, as well as conversely, they may be very similar. In either case, the value or suitability of an alternative is generally a function of the semantics of assertions within the alternative and is therefore beyond the scope of WS-Policy.

Policy Alternative. A policy alternative is a logical construct which represents a potentially empty collection of policy assertions, all of which apply in conjunction. The vocabulary of a policy alternative is the set of all assertion types within the alternative. The vocabulary of a policy is the set of all assertion types used in all the policy alternatives in the policy. Assertions that do not appear in an alternative, but whose type is in the vocabulary of the whole policy, are implied to be forbidden by the alternative.

Policy Assertion. A policy assertion identifies a behavior that is a requirement (or capability) of a policy subject. Assertions indicate domain-specific (e.g., security, transactions) semantics and are expected to be defined in separate, domain-specific specifications.

Additionally, WS-Policy defines the following terms:

Policy Assertion Type
represents a class of policy assertions and implies the structure of the assertion and its assertion-specific semantics.
Policy Assertion Parameter
qualifies the behavior indicated by a policy assertion.
Policy Vocabulary
of a policy is the set of all policy assertion types used in the policy.
Policy Subject
is an entity (e.g., an endpoint, message, resource, interaction) with which a policy can be associated.
Policy Scope
is a collection of policy subjects to which a policy may apply.
Policy Attachment
is a mechanism for associating policy with one or more policy scopes.

The structure of WS-Policy, with assertions, alternatives and policy subjects, is showin in Figure 3.1.

Figure 3.1: WS-Policy building blocks

WS-Policy building blocks

Syntactically, WS Policy offers several ways of expressing policies, but all are equivalent to a single set of alternatives containing only atomic assertions. For example, the following listing shows a policy requiring the use of Kerberos or X509 security tokens.

01    <wsp:Policy>
02      <wsp:ExactlyOne>
03        <wsse:SecurityToken>
04          <wsse:TokenType>
05            wsse:Kerberosv5TGT
06          </wsse:TokenType>
07        </wsse:SecurityToken>
08        <wsse:SecurityToken>
09          <wsse:TokenType>
10             wsse:X509v3
11          </wsse:TokenType>
12        </wsse:SecurityToken>
13      </wsp:ExactlyOne>
14    </wsp:Policy>

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". The distinction between "entity" and "general characteristic" is not defined in WS-Policy. WSDL descriptions of Web services are an example of the entities to which policies are attached (see Section 4 of WS Policy Attachment) even while they could also be assertions about "the capabilities, requirements and general characteristics" from the above definition; this split indicates that not all capabilities, requirements and general characteristics qualify as policies.

3.2 Combining Policy with SESA and WSMO

In this section, we intend to show how policies fit into WSMO and SESA.

In the first two subsections, we define the syntactical constructs necessary to bring WS-Policy together with WSML, the formal language for WSMO. Despite the differences in terminology, we can say that both WSMO and WS-Policy describe the capabilities and constraints of Web services. On one side, WSMO uses very clearly defined terms like Web service, Capability, Interface etc. to capture all the relevant properties of Web services. On the other side, WS-Policy talks about generic assertions, focusing on their combinations in whole policies, and then attaching these policies to various subjects, among which Web service endpoints are especially relevant for our work.

We can identify two generic concepts from the WS-Policy framework that could encompass elements from WSMO: Policy Subject and Policy Assertion. In other words, a policy can be attached to parts of a WSMO description, or parts of a WSMO description could be mentioned as assertions in some policy. We describe these two directions and the syntax realizing the actual connections in the sections 3.2.1 and 3.2.2.

Further in Section 3.2.3 we examine the SEE components of a SEE, in terms of whether their function should include policy manipulation of some sorts, and how. The policy-related tasks that the various components perform, are summarized in Section 3.2.4.

3.2.1 Attaching Policies to Semantic Descriptions in WSMO

WS-Policy defines an attachment mechanism that specifies how policies can be attached to WSDL service descriptions. WSMO uses WSDL for grounding (see WSMO deliverable D24.2), therefore policies present in a WSDL description will have effect also on Web services specified semantically in a WSML document that grounds to that WSDL description. However, WSMO need not be grounded only in WSDL (we envision also grounding to Triple Spaces, for example), and grounding is taken into account only in choreography, whereas policy can affect steps before that, therefore we introduce below a way to attach policies directly to WSMO constructs.

To analyze how policies can be attached to WSMO, we need first to introduce a distinction between functional and non-functional properties. In any application, the functional part of any data contains crucial information necessary for the application to do its job. Non-functional properties (NFPs), on the other hand, contain such additional data that may help the application do a better job, or to refine its functionality.

For example, one of the aims of WSMO is Web service discovery (we can see WSMO as an application for service discovery), and to enable discovery, WSMO describes client Goals and the Capabilities of the available service. Goals and Capabilities are the the necessary inputs to a matching algorithm, therefore they are functional aspects of WSMO descriptions. While pure Web service discovery only requires the Capabilities and Goals, the match maker can also take into account preferences and constraints over parameters like the price, availability or quality of a service. Because such parameters are not critical for the match maker, they are modeled as non-functional properties.

The distinction between functional and non-functional parameters depends highly on the application that uses the particular parameter — a functional parameter of one application can be non-functional in another. For instance, Semantic Web Services are an application that automates the use of Web services, and the price of a service is generally modeled as a non-functional property; however a shopping agent application will have price as one of its main functional parameters.

In WSMO, the distinction between functional and non-functional properties is made very clear: WSMO enumerates all the relevant functional properties (for example Web service has Capability and Interface as its functional properties) and it allows an extensible bag of NFPs everywhere. WS-Policy does not have any such distinction, so it can be used to express both functional and non-functional policy assertions, depending on the application that employs policies. Since WSMO enumerates in its conceptual model all the parameters that are functional for the aim of WSMO, policies can be treated as non-functional data, therefore when a WS-Policy is attached to a WSMO element, it is abstractly added to the non-functional properties of that element.

Figure 3.2 shows how WSMO elements can be used as policy assertions in a policy that is then attached to a particular policy scope. In particular, a policy is attached here to a WSMO Web service description, and it is treated as a non-functional property of that service. Due to the way policy attachment works syntactically, the policy is in fact embedded or referenced from within the non-functional properties block of the Web service description.

Figure 3.2: Attaching Policies to WSMO Elements

Attaching Policies to WSMO Elements

To summarize, WSMO elements can serve as WS-Policy Policy Subjects, and any policies attached to those WSMO elements are treated as non-functional properties. In the following, we present the syntax for including policies as non-functional properties in WSMO descriptions. Using this mechanism, the existing and future policy assertions can usefully complement the Dublin Core NFPs [DublinCore] currently used by WSMO.

To attach policies generically to XML elements such as WSDL descriptions, the WS-PolicyAttachment specification [WSPolicyAttachment] defines an XML attribute called PolicyURIs and an XML element called PolicyReference. Both the attribute and the element point to external policies using URIs. WS-PolicyAttachment introduces both of them because some XML languages restrict attribute or element-based extensibility.

In WSMO, we use the namespace-qualified name wsp:PolicyReference for an NFP; its value is one or more URIs of policies attached to the owner WSMO element:

01  service ACMEService
02    nonFunctionalProperties
03      wsp#PolicyReference hasValue
04        {_"",
05         _""}
06    endNonFunctionalProperties

Note that in WSML, namespace-qualified names are written with a hash-sign (i.e. wsp#PolicyReference) and not with a colon as in XML (i.e. wsp:PolicyReference).

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 ACMEService
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

To summarize, we allow attaching both external and embedded policies to WSMO elements, treating the attached policies as non-functional properties. For this, we reuse the WS-Policy element names ( wsp:PolicyReference and wsp:Policy) as NFP identifiers in WSMO.

3.2.2 WSMO Assertions in WS-Policy

WS-Policy is a mechanism of combining domain-specific policy assertions and attaching them to various policy subjects. WSMO descriptions can be viewed as policy assertions and combined with others in policy alternatives. Figure 3.3 shows how WSMO elements can be used as policy assertions in a policy that is then attached to a particular policy scope, for example a Web service endpoint. Such a policy would thus attach the WSMO Web service description to that endpoint.

Figure 3.3: Using WSMO Elements as Policy Assertions

Using WSMO Elements as Policy Assertions

We can envision, for example, a policy that ties the capabilities of a Web service with various security and Quality of Service (QoS) settings. A service may offer some basic functionality with strong authentication but weak communication channel encryption, and more advanced functionality can be available provided that strong encryption is employed.

WSMO currently does not have any specific mechanism for expressing that alternative WSMO descriptions are in effect in conjunction with various non-functional properties, and WS-Policy seems to be a widely-adopted mechanism for expressing exactly such alternatives, therefore even though WSMO descriptions would not normally be treated as policy assertions, such an approach may prove beneficial. In fact, WSMO descriptions captured as policy assertions would not know that they are policy assertions, i.e., the WSMO descriptions are oblivious to the policy context, but from the point of view of the policy, the chosen policy alternative would guide the processor in choosing the effective WSMO description, ignoring all others.

Because policy assertions in WS-Policy must be XML elements, we can reuse WSML/XML serialization format 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:wsml (the first wsml is a namespace prefix and the second is the name of the XML element container for WSML/XML syntax). For finer granularity (e.g. only asserting a single capability description) we can reuse the appropriate elements like wsml:capability.

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 referring to a whole WSML file we introduce the element wsml:descriptionReference that refers to a WSML document, and similarly we can introduce specific elements for referring to specific elements of WSMO, for instance to refer to a capability or an interface we can use elements wsml:capabilityReference and wsml:interfaceReference that would refer to the identifiers of the WSMO capability or interface descriptions.

The listing below is a policy that claims the policy subject is described by the WSMO services and Lines 2--7 show a WSML/XML element wsml:webService that, in this context, means a policy assertion assigning a WSMO service description defined inline. Similarly, lines 13--15 show a reference to such a description, using the new element wsml:serviceReference. Finally, lines 8--12 contain an ontology which is used by the ticketService definition.

01  <wsp:Policy>
02    <wsml:webService
03         name="">
04      <wsml:capability name="ticketing">
05        ...
06      </wsml:capability>
07    </wsml:webService>
08    <wsml:ontology
09         name="">
10      <wsml:concept name="Ticket"/>
11      ...
12    </wsml:ontology>
13    <wsml:serviceReference>
15    </wsml:serviceReference>
16  </wsp:Policy>

The conclusion is that to represent a policy assertion "the policy subject has the following WSMO description" we can use any global WSML/XML element as appropriate, and to represent an assertion only referencing a WSMO description we have to create specific elements for each type of WSMO entity that we want to reference.

The table below summarizes the syntax introduced both in this section and in the preceding one — the table shows all the syntactical ways in which WSMO can be combined with WS-Policy.

Name Type Description
wsp#PolicyReference NFP identifier non-functional property referring to an external policy file by URI
wsp#Policy NFP identifier non-functional property containing an XML serialization of a policy
wsml:wsml XML Element the root element of WSML/XML syntax, reused as a policy assertion "the embedded WSML description applies (to the policy subject)"
XML Element other WSML/XML elements reused as a policy assertion "the embedded WSML description applies (to the policy subject)"
XML Element policy assertions that refer to WSMO definitions by their identifier URIs

3.2.3 Policy in SEE components

In this section we attempt to analyze how policy frameworks with their known uses can be incorporated in the various components of the SEE. The following list explains how each component is affected by policies.

Formal languages:
As most of the components in SEE work with semantic descriptions of goals and Web services, the formal language used for those descriptions needs to include ways of attaching policies. In the Web Service Modeling Language (WSML), policies could be attached as non-functional properties wsp#Policy and wsp#PolicyReference, as we propose in Section 3.2.1. In this deliverable, we do not propose any further extension to WSML, which could have be similar in function to WS-Policy's All and ExactlyOne constructs. Such WSML extensions would fall into the realm of semantically representing policies, which is outside the scope of this deliverable.
This component provides inference and reasoning capabilities over logical formalisms, therefore while it may be used to evaluate policies, its function is not affected.
Storage and Communication:
Serving purely the internal purposes of the SEE, this component is also not affected by application policies. If the SEE itself is distributed over multiple administration domains, it would be natural to extend this component with policies, yet the application of policies in such a setting has little to do with the semantic functionalities of SESA. Therefore we propose that from the point of view of using policies in SESA, enhancing the Storage and Communication component with policies should be viewed as an implementation and deployment detail.
The purpose of the Discovery component in SESA is to perform functional matching between goals and Web services. Since we view policies as non-functional characteristics which are processed in the Adaptation component, we propose that the Discovery component is neither affected by policies.
As this component contains negotiation and non-functional property evaluation, it is a natural fit for policy evaluation as well. In particular, this component would use a WS-Policy evaluator to filter out the Web services whose policies conflict with the policy constraints of the user, with the additional possibility of ranking the services according to the user's policy preferences.
After it composes a set of Web services, this component can use their policies to verify that the composed services will be able to work with each other. Apart from the typical policy-match considerations like whether all the services support the required level of confidentiality, also higher-level policies come into play here, for example specifying that services from two given providers cannot be used together — for instance [Uszok2004b] presents a coalition policy against using aircraft from a given country in rescue operations. Similarly to the Adaptation component, the Composition component would use a WS-Policy evaluator to implement such considerations.
The choreography interface of a service prescribes (or limits) the steps that need to be followed by the client in order to successfully interact with the service. Choreographies in SESA are specified again on the level of functionality, independent of non-functional properties like policies. However, as choreographies are seldom completely strict (i.e., there can be optional and even parallel branches), the choreography engine should take operation-level policies as additional choreography constraints.
This component currently contains data mediation for handling heterogeneous data formats, and process mediation for resolving choreography mismatches. To address differences in policy specifications, we propose to add policy mediation (cf. [Galiasso2000], [Wohlstadter2004]) to this component's functionalities.
As this component is responsible for external communication, it is in the position to act as a policy enforcer. On one side, the SEE can have, for example, authorization and security policy affecting the clients who wish to invoke the SEE. On the other side, when the SEE communicates with Web services, it needs both to enforce its internal policy and to comply to the policies of the invoked Web services.
Fault Handling:
The functionality of this component can be completely or partially driven by policy specifications. In fact, fault handling policy can be specified both by the SEE and by the Web service that originated the fault (e.g. WS-Policy allows the specification of a policy on a WSDL fault description).
Similarly to fault handling, monitoring can also be controlled by policies, both an internal SEE policy and the policies of monitored Web services.
As part of the "Problem Solving Layer", this component is oriented towards the applications of the SEE. Domain ontologies that fall within this component can also be used for specifying the various policies evaluated by the components mentioned above, but the definition of the component is not affected by the introduction of policies into the SEE.
Any use case scenarios developed within this component should be able to use policies, however just as for the Ontologies component, the definition of the Applications component is not affected by the introduction of policies.
Developer Tools:
The SEE should provide a tool for creating and verifying policies. Such a tool should be adopted from existing policy frameworks (cf. [Bhargavan2004], [KAoS]), if available.
Execution Management:
All the policy evaluation and enforcement steps are incorporated in the appropriate SEE components, therefore the execution semantics of the system is not affected by the presence of policies.
Policies can be used for expressing and enforcing various security requirements, therefore on the implementation level, some of the functionality of this component will be preempted by policy evaluation and enforcement in the other components. However, the definition or functionality of this abstract component does not necessarily change.

We can see that introducing policies in SESA mainly affects the Adaptation and Grounding components, as policy evaluation and enforcement are major parts of the functionalities of these components. Also Mediation, as a crucial component for working in such a distributed environment as that of Web services, can be enhanced with the significant task of policy mediation.

Components like Composition and Choreography, use policies as additional inputs, whereas the Fault Handling and Monitoring components are policy-driven, i.e. the policies fully dictate what these components will do.

Finally, some components stay oblivious to policies, for example Execution Management, Reasoning and Discovery. Execution management is unchanged because we propose no new SEE execution steps, instead all policy evaluation happens in the pre-existing components. The reasoning task is on a lower level than that of policy evaluation, therefore a policy engine can use a reasoner, but not vice versa. The task of discovering suitable services, however, is not as clearly separated from policy evaluation. The definition of the Discovery component in our SEE model focuses on functional discovery based on a registry of Web service descriptions, and the Adapation component handles negotiation and non-functional properties; but in other models, the term "Discovery" can include what we call adaptation, and even composition, and therefore it would include policy evaluation as well.

The figure below shows that introducing policy to SEE affects mostly the Broker Layer components, with the language support in the Formal Languages component and tool support in the Developer Tools component. While, in the diagram, we could just add policy as another vertical service next to the Security component, we wanted to show in this deliverable how policy functionality would spread through the existing components.

Figure 3.4: SEE Components affected by policy

SEE Components affected by policy

3.2.4 Policy Tasks in SEE

In the previous section, we analyze all the SEE components and we show how they can involve policies. However, one can get lost in the enumeration of components, so this section summarizes the policy-related tasks that are implemented in the various components:

Creating policies is naturally the first task, before any other policy-related activities can occur. The Developer Tools component should provide a user tool for specifying, changing and verifying policies, so that they can be deployed into the SEE. Additionally, the WSML tools should support attaching policies to WSML descriptions, using the non-functional properties specified within the Formal Languages component.

Policy matching is done in the Adaptation and Composition components, where the Web service policies are matched for example against the policy of the SEE user for adaptation and against other services for composition.

Policy enforcement occurs in two different settings. First, user policy or an internal SEE policy governs the tasks of the Grounding, Fault Handling and Monitoring components, and here these components basically implement what the policies say. On the other hand, all these three components, together with the Choreography component, must also comply to policies of external services. To comply with all the appropriate policies, any component may use Composition to get help from external services.

Finally policy mediation, the new task of the Mediation component, can also be used in any of the other components, when mismatches are encountered.

The following table summarizes these policy-related tasks and the components that are involved:

Task Components
Policy creation Developer Tools
Formal Languages
Policy matching Adaptation
Policy enforcement Grounding
Fault Handling
Policy mediation Mediation

3.3 Related Work

To the best of our knowledge, this deliverable represents the first comprehensive analysis of how policy frameworks can be integrated with fully-fledged semantic execution environments, and especially how WS-Policy can be combined with WSMO. Nevertheless, there are publications that apply various policy frameworks in Web service systems, including Semantic Web Service applications, and then there are publications that apply semantic approaches for specifying and evaluating policies.

Policies have been applied in Semantic Web Service systems mainly to handle security, for instance Kagal et al. [Kagal2003] "mark up web entities with a semantic policy language" in order to "use distributed policy management as an alternative to traditional authentication and access control schemes." Similarly, Uszok et al. [Uszok2004b] use a policy framework (KAoS, also described below) for authorization in Grid computing, with policies of the form "It is permitted for actor(s) X to perform action(s) Y on target(s) Z." However, they use policies outside of security as well: for instance, in a system that uses a generic semantic matchmaker to help with organizing rescue operations, the policy framework is employed to enforce a coalition policy that rescue operations must not engage aircraft from a specific ficticious country. This approach additionally makes it possible to hide said coalition policy, so that the affected country is not aware of it. On top of this, Uszok et al. also use policy for verification of semantically-created compositions and contracts, and to ensure that at runtime, all interactions will comply to given policies.

Other works deal with combining policies and Semantic Web technologies in general. We can classify such works in such those that deal directly with WS-Policy, and those which take a more general approach to policies, and thus not commuting to WS-Policy as a framework for representing policies.

Works that deal directly with WS-Policy include [Kolovski05], [Verma05], and [SrihareeSVS04]. In [Kolovski05], Kolovski et al. provide a mapping of WS-Policy to the description logic fragment species of the Web Ontology Language (OWL-DL), and describe how standard OWL-DL reasoners can be used to check policy conformance and perform an array of policy analysis tasks. In [Verma05], Verma et al. describe how to use domain ontologies in OWL for creating policy assertions with semantics in WS-Policy; the aim there matching the non-functional properties of Web Services represented using WS-policy. Sriharee et al. propose an approach [SrihareeSVS04] to behaviour-based discovery of Web Services by which business rules that govern service behaviour are described as a policy. The policy is represented in the form of ontological information and is based on actions relating to the service and conditions for performing them. The standard WS-Policy is used to associate such a policy to the Web Service.

Works that do not deal directly with WS-Policy (but which takes into account semantic web based approaches to policies) focuses more on administrative policies such as security and resource control policies. KAoS [KAoS] is one of the first efforts to represent policy using a Semantic Web language (in this case OWL). KAoS services and tools allow for the specification, management, conflict resolution, and enforcement of policies within the specific contexts established by complex organizational structures represented as domains. While initially oriented to the dynamic and complex requirements of software agent applications, KAoS services have been extended to work equally well with both agent and traditional clients on a variety of general distributed computing platforms. In [Nejdl05], Nejdl et al. propose the use of ontologies to simplify the tasks of policy specification and administration, discusses how to represent policy inheritance and composition based on credential ontologies, and formalize these representations and the according constraints in Frame-Logic. Toninelli et al. classify in [Toninelli2005] approaches to policy specification as ontology-based approaches (that rely heavily on the expressive features of Description Logic languages), and rule-based approaches (that encode policies as Logic Programming rules), and proposes a hybrid approach that exploits the expressive capabilities of both DL and LP approaches.

Rein ([Kagal2006] and [Kagal2006a]) is a framework for representing and reasoning over policies in the Semantic Web; it exploits the inherently decentralized and open nature of the Web by allowing policies, meta-policies, and policy languages to be combined, extended, and otherwise handled in the same scalable, modular manner as are any Web resources. Resources, their policies and meta-policies, the policy languages used, and their relationships together form Rein policy networks. These networks are described using Rein ontologies and these distributed but linked descriptions are collected off the Web by the Rein engine and are reasoned over to provide policy decisions. Rein does not propose a single policy language for describing policies; it allows every user to potentially have her own policy language or re-use an existing language and if required, a meta policy. The ontologies and reasoning mechanisms work with any policy language and domain knowledge defined in RDFS, OWL, or supported rule languages.

Within DIP, there has been some work done on Quality of Service (QoS) support in discovery, e.g. in Deliverable D4.17 and the prototype D4.19. QoS conditions and constraints are often cited as example policy assertions, therefore we should mention here the relation of those DIP deliverable and D4.13, this deliverable. D4.17 defines QoS parameters semantically (as axioms) in the non-functional properties of Web service interfaces. Such descriptions could be combined with semantic approaches to representing policies, but such approaches are outside of the scope of D4.13. On the other hand D4.17 does not use WS-Policy, as that would be an unnatural detour between the QoS axioms and WSML. A similar situation occurs with deliverable D4.21 on security and trust, which could also use WS-Policy, in which case security and trust statements would be attached using the mechanisms from this deliverable.

4. Web Services Metadata Exchange

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.

4.1 WS-MEX Overview

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=''
04        Identifier=''>
05      <wsdl:definitions
06        name='StockQuote'
07        targetNamespace=''
08        xmlns:tns=''
09        xmlns:wsdl=''
10        xmlns:wsoap='' >
11        <wsdl:import namespace=''
12                   location='' />
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='' />
24          </wsdl:port>
25        </wsdl:service>
26      </wsdl:definitions>
27    </wsx:MetadataSection>
29    <wsx:MetadataSection
30        Dialect='' >
31      <wsx:MetadataReference>
32        <wsa:Address>
34        </wsa:Address>
35      </wsx:MetadataReference>
36    </wsx:MetadataSection>
38    <wsx:MetadataSection
39        Dialect=''
40        Identifier=''>
41      <wsx:Location>
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 ( and the identifier being the target namespace of this specific WSDL (

Lines 29 to 36 contain another metadata section pointing to a policy (dialect available by accessing the Web service at Finally lines 38 to 44 contain a metadata section pointing to a schema (dialect with the target namespace which is available on the Web at the same URI (compare lines 40 and 42).

4.2 Using WS-MEX to retrieve WSMO descriptions

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, 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 of a WSML document in a WS-MEX metadata section:

01  <wsx:Metadata>
02    <wsx:MetadataSection 
03        Dialect='' >
04      <wsml:wsml xmlns:wsml="" >
05        <wsml:ontology 
06            name="">
07          <wsml:concept 
08            name="Ticket"/>
09        </wsml:ontology>
10      </wsml:wsml>
11    </wsx:MetadataSection>
12  </wsx:Metadata>



6. Other Web Services Specifications

todo - WS Discovery, WSRF, BPEL4WS, WS-CDL, ebXML, WSPL

7. Conclusions and Further Work

todo - conclusions to be written when all the rest is filled out

Appendix A. XML Schema for elements introduced in this document



[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

[Bhargavan2004] K. Bhargavan, C. Fournet, A. D. Gordon: Verifying policy-based security for web services In CCS '04: Proceedings of the 11th ACM conference on Computer and communications security, 2004, Washington DC, USA.

[de Bruijn 2004] J. de Bruijn (editor): WSML/XML - An XML Syntax for WSML, available at

[DublinCore] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: Dublin Core Metadata for Resource Discovery, IETF RFC 2413, September 1998, available at

[Galiasso2000] P. Galiasso, O. Bremer, J. Hale, S. Shenoi, D. Ferraiola, V. Hu: Policy mediation for multi-enterprise environments. In ACSAC '00: Proceedings of the 16th Annual Computer Security Applications Conference, 2000, Washington, DC, USA.

[Kagal2003] Lalana Kagal, Tim Finin, Anupam Joshi: A Policy Based Approach to Security for the Semantic Web. In 2nd International Semantic Web Conference (ISWC2003), 2003.

[Kagal2006] L. Kagal, T. Berners-Lee, D. Connolly, D. J. Weitzner: Using Semantic Web Technologies for Policy Management on the Web. In 21st National Conference on Artificial Intelligence (AAAI), July 2006.

[Kagal2006a] L. Kagal, T. Berners-Lee, D. Connolly, D. Weitzner: Self-Describing Delegation Networks for the Web. In Proceedings of the Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY'06), 2006.

[KAoS] A. Uszok, J. M. Bradshaw, R. Jeffers, A. Tate, J. Dalton: Applying KAoS Services to Ensure Policy Compliance for Semantic Web Services Workflow Composition and Enactment, In International Semantic Web Conference, 2004.

[Kolovski05] V. Kolovski, B. Parsia, Y. Katz, J. A. Hendler: Representing Web Service Policies in OWL-DL. In International Semantic Web Conference, 2005.

[Nejdl05] W. Nejdl, D. Olmedilla, M. Winslett, C. C. Zhang: Ontology-Based Policy Specification and Management. In 2nd European Semantic Web Conference (ESWC), 2005.

[Roman et al. 2004] D. Roman, U. Keller, H. Lausen (editors): Web Service Modeling Ontology - Standard (WSMO - Standard), version 1.0 available at

[SrihareeSVS04] N. Sriharee, T. Senivongse, K. Verma, A. P. Sheth: On Using WS-Policy, Ontology,, Rule Reasoning to Discover Web Services. In INTELLCOMM, 2004.

[Toninelli2005] A. Toninelli, J. Bradshaw, L. Kagal, R. Montanari: Rule-based and Ontology-based Policies: Toward a Hybrid Approach to Control Agents in Pervasive Environments. In Proceedings of the Semantic Web and Policy Workshop, November 2005.

[Uszok2004b] A. Uszok, J. M. Bradshaw, R. Jeffers, M. Johnson, A. Tate, J. Dalton, S. Aitken: Policy and Contract Management for Semantic Web Services. In AAAI Spring Symposium on Semantic Web Services, 2004.

[Verma05] Verma, K., Akkiraju, R., Goodwin, R.: Semantic Matching of Web Service Policies. In SDWP Workshop, 2005.

[Wohlstadter2004] E. Wohlstadter, S. Tai, T. Mikalsen, I. Rouvellou, P. Devanbu: GlueQoS: Middleware to Sweeten Quality-of-Service Policy Interactions. In 26th International Conference on Software Engineering, 2004.

[WSAddressing] D. Box, F. Curbera (editors) (2004): Web Service Addressing, W3C member submission, available at

[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

[WSMEX] F. Curbera, J. Schlimmer (editors) (2004): Web Service Metadata Exchange, available at

[WSPolicy] J. Schlimmer (editor): Web Services Policy Framework, available at

[WSPolicyAssertions] A. Nadalin (editor): Web Services Policy Assertions Language, available at

[WSPolicyAttachment] C. Sharp (editor): Web Services Policy Attachment, available at

[WSSecurity] A. Nadalin, C. Kaler, P. Hallam-Baker, R. Monzillo (editors): Web Services Security, available at

[WSSecurityPolicy] A. Nadalin (editor): Web Services Security Policy Language, available at

[XMLSchema] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn (editors): XML Schema part 1: Structures, W3C Recommendation, 2001, available at


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.

Change Log

Date Author Description
2007/1/12 jacek put in content created for DIP
2005/2/9 jacek Decapitalized Web services, removed WSMX mention, hidden the conclusions, other editorial touches
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

Valid XHTML 1.1!

$Date: 2007/01/12 17:08:08 $