Transcript Slide 1

Policy Support for Business-oriented Web Service Management
Stephen Gorton and Stephan Reiff-Marganiec
Latin-American Web Congress, Cholua, Mexico, 25-27 October 2006
Department of Computer Science, University of Leicester
University Road, Leicester LE1 7RH United Kingdom
SENSORIA
•
•
•
Software Engineering for Service-oriented Overlay Computers
IST project funded by the EU
http://sensoria.fast.de
“The aim of SENSORIA is to develop a novel comprehensive approach to the
engineering of software systems for service-oriented overlay computers where
foundational theories, techniques and methods are fully integrated in a
pragmatic software engineering approach.”
•
•
Work Package 1: Service Description
Task 1.3: Service-oriented business modelling
Outline
•
•
•
•
•
•
•
•
•
•
•
Service oriented computing and web services
Service management
Introduction to policies
The Appel PDL
Appel in telecommunications
How we use policies
The process execution engine
Specifying requirements
Example usage
Further and related work
Summary and conclusions
SOC and web services
•
Services are:
–
–
–
•
Loosely coupled units of software available over a network, exposed by welldefined 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.
•
The link with telecommunications:
–
–
–
–
Internet telecommunications based on components or features;
Features include call forwarding, call waiting, etc.;
SOC is similar in the sense of component composition;
Can we use telecoms technology for SOC?
Feature FA
Service SA
Feature FC
Feature FB
Service SC
Service SB
Service management
•
Present:
–
–
–
–
•
Future:
–
–
–
•
Not huge uptake in WS;
Lots of “large” implementations;
Relatively few open access services;
Amazon, Ebay and Google provide public WS interfaces.
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.
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
•
–
Access control:
•
•
•
•
•
–
Including WS-PolicyAttachment
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
•
–
Presentation
Wizards, Display Managers, etc.
Policy
APPEL
Enterprise
Composition (BPEL, etc.)
Discovery
UDDI, USML, etc.
Description
WSDL, WSCM, etc.
Transport
Messaging (HTTP, HTTPS, SOAP, etc.)
to get information from the user
Display
•
Abstract Web Service Protocol Stack
to output data in some visual format
Where policies fit in
Corporate Space
Project Space
Task
Task
Rule
Task
Task
Rule
Task
Task
Task
Tasks map to
(composite) services
Business Domain
Web Service Domain
Composition /
Orchestration Mechanisms
Service Space
WS
WS
WS
WS
WS
WS
WS
WS
WS
WS
WS
WS
The proposed architecture
User Interface Layer
Web-based
GUI
Policy Server
Layer
Context
Policy Server
Policy Server
Policy Store
Policy Server
Policy Store
Service
Layer
Service
Service
Service
Service
Service
Service
Service
The management runtime engine
Task Map
Workflow
Conflict
Policies
Correctness
Full
Composition
Skeleton
Composition
Stubless
Composition
Mediator
WS
Mediator
Discovery Engine
Mediator
Mediator
Mediator
Mediator
Mediator
Mediator
services located and composed using UDDI, WSDL, etc. or equivalent
WS
WS
WS
WS
WS
WS
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
•
•
Actions
–
–
–
Includes standard mathematical operators
<policy …>
<preference> …
<policyrule>
<triggers>
<trigger> …
<trigger> …
</triggers>
<conditions>
<condition> …
<condition> …
</conditions>
<actions>
<andthen />
<action> …
<action> …
</actions>
</policyrule>
</policy>
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>
Uses in telecommunications
•
•
•
•
•
Forward incoming calls;
Emergency call handling;
Announcing availability;
Using capability;
Controlling registration.
•
Example: “If Ken is busy, forward his incoming calls to Bob”
<policy owner=“[email protected]” applies_to=“[email protected]”
id=“Forward if busy” enabled=“true” changed=“2004-08-02T11:20:05”>
<policy_rule>
<triggers>
<and />
<trigger>connect_incoming</trigger>
<trigger arg1=“”>unavailable(arg1)</trigger>
</triggers>
<action arg1=“[email protected]”>forward_to(arg1)</action>
</policy_rule>
</policy>
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:
•
•
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
–
–
•
Modalities include must, should, prefer, and their negations.
“Services not allowed from originating country X”
Capping the maximum expense claim amount
Not a web service policy but a management policy
Specifying requirements 1
•
Local functionality:
–
System messaging
(more applicable to triggers)
•
Service classification:
–
•
Domain, subdomain
Service functionality:
–
–
–
–
–
–
Inputs;
Preconditions;
Postconditions;
Outputs;
Exceptions;
Side effects
<message>
<source> … </source>
<destination> … </destination>
<description> … <description>
<data> … </data>
</message>
<serviceType>
<domain> … </domain>
<subdomain> … </subdomain>
</serviceType>
<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>
Example usage – train tickets
<policy owner=“[email protected]” applies_to=“@mcs.le.ac.uk”
id=“Query for cheapest train ticket (UK)” enabled=“true”
changed=“2006-05-08T15:51:00”>
<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;
•
•
•
Mediation of user-defined and service requested data types;
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;
–
–
•
Similarities between telecoms and SOC:
–
–
•
Management of software will shift closer to the business analyst rather than the
software engineer;
Align IT objectives with business objectives.
Feature composition;
Management issues.
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?