Policy Support for Businessoriented Web Service Management

1
Policy Support for Business-oriented Web Service
Management
Stephen Gorton and Stephan Reiff-Marganiec
Latin-American Web Congress, Cholula, Mexico,
25-27 October 2006
www.cs.le.ac.uk
Department of Computer Science, University of
Leicester University Road, Leicester LE1 7RH
United Kingdom
2
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.

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

4
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

5
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

6
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

7
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 ltandgt,
  ltandthengt, ltelsegt, ltorgt, or ltorelsegt

ltpolicy gt ltpreferencegt ltpolicyrulegt
lttriggersgt lttriggergt lttriggergt
lt/triggersgt ltconditionsgt ltconditiongt
ltconditiongt lt/conditionsgt
ltactionsgt ltandthen /gt ltactiongt
ltactiongt lt/actionsgt lt/policyrulegt lt/polic
ygt
8
Specifying requirements 1

• Local functionality
• System messaging
• (more applicable to triggers)

ltmessagegt ltsourcegt lt/sourcegt ltdestinationgt
lt/destinationgt ltdescriptiongt ltdescriptiongt
ltdatagt lt/datagt lt/messagegt
ltserviceTypegt ltdomaingt lt/domaingt
ltsubdomaingt lt/subdomaingt lt/serviceTypegt

• Service classification
• Domain, subdomain

• Service functionality
• Inputs
• Preconditions
• Postconditions
• Outputs
• Exceptions
• Side effects

ltfunctionalitygt ltinputsgt ltinputgt
ltinputgt ltpreconditiongt conditions
ltpostconditiongt conditions ltoutputsgt
ltoutput typelistgt display(this) ltexception
namedefaultgt function() lt/exceptiongt
ltsideEffectsgt ltpenaltygt ltbonusgt
lt/sideEffectsgt lt/functionalitygt
9
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

ltqualitiesgt ltqualitygt ltparametergtpricelt/para
metergt ltoperatorgtleqlt/operatorgt
ltvaluegt0lt/valuegt lt/qualitygt lt/qualitiesgt
10
Example usage train tickets
ltpolicy ownerstephen_at_mcs.le.ac.uk
applies_to_at_mcs.le.ac.uk idQuery for
cheapest train ticket (UK) enabledtrue
changed2006-05-08T155100gt
ltpreferencegtmustlt/preferencegt ltpolicy_rulegt
lttriggergt ltmessagegt
ltdatagtstartlt/datagt lt/messagegt lt/triggergt
ltconditiongt ltparametergtlocationlt/parametergt
ltoperatorgteqlt/operatorgt
ltvaluegtUKlt/valuegt lt/conditiongt
ltaction arg1promptUser(Departure Station)
arg2promptUser(Arrival Station)
arg3promptUser(Date of Travel)
arg4promptUser(Fast or Cheap)
arg5promptUser(Railcard)gt
ltserviceTypegt ltdomaingtTravellt/domaingt
ltsubdomaingtTicket Vendorlt/subdomaingt
lt/serviceTypegt Further actions
11
Example usage functionality specification
ltfunctionalitygt ltinputsgt ltinput
namefromgtfrom(arg1)lt/inputgt ltinput
nametogtfrom(arg2)lt/inputgt ltinput
namedategtfrom(arg3)lt/inputgt ltinput
namepreferencegtfrom(arg4)lt/inputgt
ltinput namerailcardgtfrom(arg5)lt/inputgt
lt/inputsgt ltpostconditionsgt
ltpostcondgt ltoutputgt ltor /gt
lttypegtlistlt/typegt
lttypegtemptylt/typegt lt/outputgt
ltpostcondgt lt/postconditionsgt
ltoutputsgt ltoutput typelistgtdisplay(this
)lt/outputgt ltoutput typeemptygtdisplay_em
pty()lt/outputgt lt/outputsgt
ltexceptionsgt ltexception
namedefaultgtdisplay_exception(this)lt/exceptiongt
lt/exceptionsgt ltsideEffectsgt
ltpenaltygt lttypegtdefaultlt/typegt
ltpermissiongtdisallowlt/permissiongt
lt/penaltygt ltbonusgt
lttypegtdefaultlt/typegt ltpermissiongtallowlt/
permissiongt lt/bonusgt
lt/sideEffectsgt lt/functionalitygt
12
Example usage quality specification
ltqualitiesgt ltqualitygt
ltparametergtpricelt/parametergt
ltoperatorgtleqlt/operatorgt
ltvaluegt0lt/valuegt lt/qualitygt
ltqualitygt ltparametergtavailabilitylt/param
etergt ltoperatorgteqlt/operatorgt
ltvaluegtnowlt/valuegt lt/qualitygt
lt/qualitiesgt invokeService(functionality,
quality) lt/actiongt lt/policy_rulegt lt/policygt
13
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

14
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 Science www.cs.le.ac.uk