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 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 */
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.
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:
The structure of WS-Policy, with assertions, alternatives and policy subjects, is showin in Figure 3.1.
Figure 3.1: 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.
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.
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
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 {_"http://fabrikam123.example.com/policies/DSIG",
05 _"http://fabrikam123.example.com/policies/SECTOK"}
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.
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
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
http://example.org/services/ticketService and
http://example.org/services/billingService.
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="http://example.org/services/ticketService"> 04 <wsml:capability name="ticketing"> 05 ... 06 </wsml:capability> 07 </wsml:webService> 08 <wsml:ontology 09 name="http://example.org/ontologies/ticketing/"> 10 <wsml:concept name="Ticket"/> 11 ... 12 </wsml:ontology> 13 <wsml:serviceReference> 14 http://example.org/services/billingService 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)" |
| wsml:webService wsml:goal ... | XML Element | other WSML/XML elements reused as a policy assertion "the embedded WSML description applies (to the policy subject)" |
| wsml:descriptionReference wsml:webServiceReference wsml:goalReference ... | XML Element | policy assertions that refer to WSMO definitions by their identifier URIs |
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.
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.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
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 Composition |
| Policy enforcement | Grounding Fault Handling Monitoring Choreography Composition |
| Policy mediation | Mediation |
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.
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 of a WSML document in a WS-MEX metadata section:
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
todo - conclusions to be written when all the rest is filled out
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
[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 http://www.wsmo.org/2004/d16/d16.3/v0.1/
[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.
[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 http://www.wsmo.org/2004/d2/v1.0/
[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 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/
[WSPolicy] J. Schlimmer (editor): Web Services Policy Framework, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policy.asp
[WSPolicyAssertions] A. Nadalin (editor): Web Services Policy Assertions Language, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policyassertions.asp
[WSPolicyAttachment] C. Sharp (editor): Web Services Policy Attachment, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policyattachment.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
[WSSecurityPolicy] A. Nadalin (editor): Web Services Security Policy Language, available at http://msdn.microsoft.com/ws/2002/12/ws-security-policy/
[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/
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 |
|---|---|---|
| 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 |
$Date: 2007/01/12 17:08:08 $