IONA Technologies Position Paper Constraints and Capabilities for Web Services Rebecca.Bergersen@iona.com
Agenda • Motivation and History of Policy Usage • Most Important Characteristics • Use Case • Conclusion • Discussion
Motivation and History of Policy Usage
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
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
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
Therefore… Conclusion? Policies are critical! Must be • Simple, maintainable • Easily and efficiently interpreted • Highly extensible for use in widely varying contexts
Most Important Characteristics
Keep it simple!
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!
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>
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
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
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
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
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
Use Case
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
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
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>
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
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” … />
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.
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” … />
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.
Conclusion
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.
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
