Policy Support for Business-oriented Web Service Management

Stephen Gorton and Stephan Reiff-Marganiec

Department of Computer Science, University of LeicesterUniversity Road, Leicester LE1 7RH United Kingdom

Latin-American Web Congress, Cholula, Mexico, 25-27 October 2006

www.cs.le.ac.uk

SOC and web services

• Services are:– Loosely coupled units of software available over a network, exposed by well-

defined interfaces;– Based on open standards;– Composable, i.e. you can orchestrate two or more together to make a composite

service.

• Web services:– A popular implementation of SOA, incorporating open standards such as XML;– Are also optionally self-describing and discoverable;– Communicate via standard HTTP.

“Service-oriented computing (SOC) is an architectural approach to building loosely coupled applications.”

Abstract Web Service Protocol Stack

APPEL

Composition (BPEL, etc.)

UDDI, USML, etc.

WSDL, WSCM, etc.

Messaging (HTTP, HTTPS, SOAP, etc.)

Wizards, Display Managers, etc.Presentation

Policy

Enterprise

Description

Transport

Discovery

Service management

• Present:– Not huge uptake in WS;– Lots of “large” implementations;– Relatively few open access services;– Amazon, Ebay and Google provide public WS interfaces.

• Future:– Lots of WS?– “Smaller” WS capable of doing more atomic activities?– Composition of WS provides required functionality.

• Business needs:– Align IT objectives with business objectives;– Adaptability and flexibility of systems;– Business-oriented management?

“As a substantial number of Web Services become available, so the attention shift will be from service infrastructure to service management”.

Casati et al. Business-oriented management of Web Services. Comm. ACM, 46(10):55-60, 2003.

Corporate Space

Project Space

Service Space

TaskTaskTask

WSWSWS

Business Domain

Web Service Domain

WSWSWSWSWSWS

WSWSWS

TaskTaskRuleTaskTaskRule

Tasks map to (composite) servicesComposition /

Orchestration Mechanisms

Composition / Orchestration Mechanisms

How can we use policies?

• Express preferences– “I will only fly with British Airways on flights lasting over 8 hours”– “Given a choice, I prefer to use a supplier in my phone book”

– Options:• Modalities include must, should, prefer, and their negations.

• Express requirements– “Purchase a rail ticket from X to Y, with times T and S…”– “Quote for a holiday”

– Options:• Unbounded on what we can express• Restrictions are on classifications of requirements (tags).

• Express restrictions– “Services not allowed from originating country X”– Capping the maximum expense claim amount

• Not a web service policy but a management policy

Policies and web services

• Policies are:– “…information that can be used to modify the behaviour of a system.”

(Lupu and Sloman. Conflicts in Policy-based Distributed Systems Management. IEEE Transactions on Software Engineering, Nov 1999.

• Policy Examples:– WS-Policy

• Including WS-PolicyAttachment

– Access control:• Ponder• KAoS• Rein• XACML• WSPL

– Automatic negotiations Lamparter and Agarwal. Specification of policies for automatic negotiations of web services. In L. Kagal, T. Finin and J. Hendlerm, editors, SWPW, 2005.

• Our policies are:“a high level statement as to how business requirements

should be processed in the management system.”

Appel policy framework

• The Accent Project Policy Environment/Language;• A Policy Description Language (PDL), allowing users to write their own

policies;• Designed by Reiff-Marganiec et al at the University of Stirling;

S. Reiff-Marganiec, K. Turner and L. Blair. Appel: The Accent policy environment/language. Technical report CSM-164, University of Stirling, Jun 2005.

• Developed for the Accent project (telecommunications control).

• PDL allows for the definition of ECA policies or goals;• Appel defines an XML Schema based around:

– Triggers– Conditions– Actions

• Extended by functions:– Prompt

• to get information from the user

– Display • to output data in some visual format

Appel policies

• Triggers (adapted from the SENSORIA ontology):– Message events– Time events– Change events– Service events– Interaction events

• Conditions:– Checks on local or remote data values

• Includes standard operators

• Actions– Core information in the policy– Defines what service to invoke via different tags– Can specify more than one action with tags <and>, <andthen>, <else>, <or>, or

<orelse>

<policy …> <preference> … <policyrule> <triggers> <trigger> … <trigger> … </triggers> <conditions> <condition> … <condition> … </conditions> <actions> <andthen /> <action> … <action> … </actions> </policyrule></policy>

Specifying requirements 1

• Local functionality:– System messaging

(more applicable to triggers)

<message> <source> … </source> <destination> … </destination> <description> … <description> <data> … </data></message>

<serviceType> <domain> … </domain> <subdomain> … </subdomain></serviceType>

• Service classification:– Domain, subdomain

• Service functionality:– Inputs;– Preconditions;– Postconditions;– Outputs;– Exceptions;– Side effects

<functionality> <inputs> <input> … <input> … … <precondition> conditions … <postcondition> conditions … <outputs> <output type=“list”> display(this) <exception name=“default”> function() </exception> <sideEffects> <penalty> … <bonus> … </sideEffects></functionality>

Specifying requirements 2

• Quality:– Any identified qualitative value can be addressed, provided it is published in the

directory entry (UDDI or similar), or it is “testable”;– Qualitative checks based on similar condition checks;– Named parameters compared against values;– Operators include:

• Equal to• Less than• Less than or equal to• Greater than• Greater than or equal to

<qualities> <quality> <parameter>price</parameter> <operator>leq</operator> <value>0</value> </quality> …</qualities>

<policy owner=“stephen@mcs.le.ac.uk” applies_to=“@mcs.le.ac.uk” id=“Query for cheapest train ticket (UK)” enabled=“true” changed=“2006-05-08T15:51:00”>

Example usage – train tickets

<preference>must</preference> <policy_rule>

<trigger> <message> <data>start</data> </message> </trigger>

<condition> <parameter>location</parameter> <operator>eq</operator> <value>UK</value> </condition>

<action arg1=“promptUser(Departure Station)” arg2=“promptUser(Arrival Station)” arg3=“promptUser(Date of Travel)” arg4=“promptUser(Fast or Cheap)” arg5=“promptUser(Railcard)”>

<serviceType> <domain>Travel</domain> <subdomain>Ticket Vendor</subdomain> </serviceType>

Further actions…

Example usage: functionality specification

<functionality> <inputs> <input name=“from”>from(arg1)</input> <input name=“to”>from(arg2)</input> <input name=“date”>from(arg3)</input> <input name=“preference”>from(arg4)</input> <input name=“railcard”>from(arg5)</input> </inputs> <postconditions> <postcond> <output> <or /> <type>list</type> <type>empty</type> </output> <postcond> </postconditions> <outputs> <output type=“list”>display(this)</output> <output type=“empty”>display_empty()</output> </outputs> <exceptions> <exception name=“default”>display_exception(this)</exception> </exceptions> <sideEffects> <penalty> <type>default</type> <permission>disallow</permission> </penalty> <bonus> <type>default</type> <permission>allow</permission> </bonus> </sideEffects> </functionality>

Example usage: quality specification

<qualities> <quality> <parameter>price</parameter> <operator>leq</operator> <value>0</value> </quality> <quality> <parameter>availability</parameter> <operator>eq</operator> <value>now</value> </quality> </qualities>

invokeService(functionality, quality)

</action> </policy_rule></policy>

Further work

• Domain restriction or classification;

• Interaction of policies with task maps;• Refinement of policy functions and definition of further functions;

• Integration of this technology with service coordination technology;• Mapping of task maps to workflow languages (e.g. YAWL)

• Related work:– Task maps– SRML– YAWL

Summary and Conclusions

• With increasing numbers of web services, management will shift further into the business domain;

– Management of software will shift closer to the business analyst rather than the software engineer;

– Align IT objectives with business objectives.

• Appel extended as a PDL for SOC:– Users define their own policies to express goals, requirements and preferences;– Extension functions allow us to address the SOC domain.

• Trivial example of purchasing a ticket.

• Questions?

Department of Computer Sciencewww.cs.le.ac.uk