1 / 28

IONA Technologies Position Paper

This position paper discusses the motivation, history, and most important characteristics of using policies in web services. It explores the need for policies in expressing quality of service, determining configuration, defining behavior and capabilities, and ensuring security and reliability. The paper emphasizes the importance of simplicity, lightweightness, and extensibility in policy design, and provides a use case scenario.

cruza
Download Presentation

IONA Technologies Position Paper

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Agenda • Motivation and History of Policy Usage • Most Important Characteristics • Use Case • Conclusion • Discussion

  3. Motivation and History of Policy Usage

  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. 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. 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. Therefore… Conclusion? Policies are critical! Must be • Simple, maintainable • Easily and efficiently interpreted • Highly extensible for use in widely varying contexts

  8. Most Important Characteristics

  9. Keep it simple!

  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. Policy must be a first order entity • Directly addressable • Directly manipulable <Service … > <Policy … > … </Policy> • Service • Interface • Interface Operation • Message Reference • Binding • Binding Operation • Binding Message / • Fault Reference <Interface … > <Policy … > … </Policy> <Policy …> … </Policy> … </Interface> </Service>

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

  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. 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. Effective Policy Set • Aggregation of Policies with overrides applied (lower overrides higher) • Service • Interface • Interface Operation • Message Reference • Binding • Binding Operation • Binding Message / • Fault Reference

  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. Use Case

  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. 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. Pseudo Definition <interface name=“…” …> <Policy type=“ReliableMessaging” required=“True” > <protocol1 /> <protocol2 /> </Policy> <Policy type=“protocol1” required=“False” > <OnceAndOnlyOnce>Yes</OnceAndOnlyOnce> <NegativeAckRequired>Yes</NegativeAckRequired> </Policy> <Policy type=“protocol2” required=“False” > <PreserveOrder>Yes</PreserveOrder> </Policy>

  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. Pseudo Definition <interface name=“…” …> <Policytype=“ReliableMessaging” required=“True” > <protocol1 /> <protocol2 /> </Policy> <Policy type=“protocol1” required=“False” > <OnceAndOnlyOnce>Yes</OnceAndOnlyOnce> <NegativeAckRequired>Yes</NegativeAckRequired> </Policy> <Policy type=“Security” required=“True” > <Kerberos /> <X509 /> </Policy> … <binding name=“…” …> <soap:binding style=“…” …> <soap:header use=“…” message=“…” policy=“Security” … />

  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. Pseudo Definition <interface name=“…” …> <Policytype=“ReliableMessaging” required=“True” > <protocol1 /> <protocol2 /> </Policy> <Policy type=“protocol1” required=“False” > <OnceAndOnlyOnce>Yes</OnceAndOnlyOnce> <NegativeAckRequired>Yes</NegativeAckRequired> </Policy> <Policy type=“Security” required=“True” > <Kerberos /> <X509 /> </Policy> <Policy type=“Privacy” required=“False” > <P3P /> </Policy> … <binding name=“…” …> <soap:binding style=“…” …> <soap:header use=“…” message=“…” policy=“Security” … />

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

  26. Conclusion

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

More Related