1. IONA Technologies Position Paper Constraints and Capabilities for Web Services Rebecca.Bergersen@iona.com

2. 2 Agenda 1.Motivation and History of Policy Usage 2.Most Important Characteristics 3.Use Case 4.Conclusion 5.Discussion

3. 3 Motivation and History of Policy Usage

4. 4 Why Policies? Essential for expressing Quality of Service Configuration determined by Policies Behavior and Capabilities defined by Policies Choices and nature of transport Types and characteristics of security, reliability

5. 5 Policies have proven value Used in many computing infrastructures, most notably CORBA. –General model available since 1997 (CORBA v2.2) IONA a major contributor to standard, has years of experience designing, implementing and maintaining middleware using policies –Originally designed to provide separate configuration entities but now applied as above Standard for component or subsystem defines applicable policies and their interactions with other systems –Precedence, interleaving constraints, etc. –Provided flexible, robust system

6. 6 Assumptions and Requirements Many different standards groups and bodies will use W3C Policy framework to define their Policies. Policies are & will be used in widely differing ecologies for different purposes, but must –interoperate –process efficiently in any environ –be easily maintained –be easily extended

7. 7 Therefore… Conclusion? Policies are critical! Must be Simple, maintainable Easily and efficiently interpreted Highly extensible for use in widely varying contexts

8. 8 Most Important Characteristics

9. 9 Keep it simple!

10. 10 Policy must be simple Many uses – a Policy expresses –desired or actual behavior –constraint –capability –aspect of configuration Plays critical role in framework and plug-in architectures Therefore must be as simple and lightweight as possible!

11. 11 Policy must be a first order entity Directly addressable Directly manipulable … … … … Service Interface Interface Operation Message Reference Binding Binding Operation Binding Message / Fault Reference

12. 12 Policy must be lightweight Identified by type name <Policy type=“Security” Usage defined by single ‘required’ attribute required=“true” > Policy is parameterized; value is immutable Existence of Policy indicates support Required=“false” indicates usage is optional

13. 13 Lightweight policies (continued) Disassociate policies from their processing directives –Reusable policies may be processed very differently in different contexts or environments –Processing style should be based on needs of application –Including processing makes policy heavyweight –Removes need for extensive (but always incomplete) set of operators required for complex processing models

14. 14 Just to emphasize the point… Identifier needed to find & manipulate a Policy Existance implies support Support combined with usage (optional/required) sufficient Parameterization provides extensibility No processing info in policy framework provides –Efficient communication of policies –Enhanced efficiency of processing based on environ, application requirements and style –Maintainability

15. 15 Effective Policy Set Aggregation of Policies with overrides applied (lower overrides higher) 1. Service 2. Interface 3. Interface Operation 4. Message Reference 5. Binding 6. Binding Operation 7. Binding Message / Fault Reference

16. 16 Effective Policy Set (continued) Gather all Policies in service’s definition Apply overrides, resulting in Effective Policy Set Existence of Policy implies support Required attribute defines usage Use to –Determine if Policy requirements for particular feature or operation are satisfied –Get particular Policy, its value and required attribute’s value

17. 17 Use Case

18. 18 Scenario Web service stipulates –Clients must support reliable messaging protocol –Client must support WS-Security using X.509 or user name security token –Service has P3P policy associated with operations

19. 19 ReliableMessaging “ReliableMessaging” policy added to service definition –Type=“ReliableMessaging” –Required=“True” –Parameterized with list of supported protocols Policy or reference to it placed at Interface component level. Options, configurations, etc. for each protocol defined in separate policies

20. 20 Pseudo Definition Yes Yes

21. 21 Security “Security” policy added to service definition –Type=“Security” –Required=“True” –Parameterized with list of supported protocols Policy or reference to it placed at Interface component level. Reference to policy placed in binding for request messages

22. 22 Pseudo Definition Yes …

23. 23 Privacy “Privacy” policy added to service definition –Type=“Privacy” –Required=“False” –Parameterized with list of supported protocols Policy or reference to it placed at Interface component level.

24. 24 Pseudo Definition Yes …

25. 25 Processing – client sends request 1.Client retrieves server’s WSDL definition 2.Generates server’s Effective Policy Set (EPS) 3.Notices security required – matches with protocols it uses (from client’s EPS) 4.Notices ReliableMessaging required – matches with own protocols – chooses first match 5.Notices Privacy optional – sees that P3P used by server – if knows P3P, knows forthcoming interaction, else ignores.

26. 26 Conclusion

27. 27 Keep It Simple Use case shows that complicated indications of intention, requirement, support and use can be expressed in simple ways. More desirable than scheme involving complex processing models, order of precedence calculations, multiple selection criteria. Framework should be lightweight & flexible, allowing for efficient interoperability, maintainability, extensibility, & use in any environ.

28. 28 Next Steps We recommend chartering a WG for Policy. –Purpose: define a policy framework, but not specific policies themselves. –WSDL extensions, Constraints and Capabilities, etc. are viable means of implementation, but policy framework is separate concern – needs own WG. –Liaise with other WGs and TCs to ensure adoption of the framework, and consistency of the policy work across Web services