IONA Technologies Position Paper Constraints and Capabilities for Web Services...
-
Upload
william-lea -
Category
Documents
-
view
215 -
download
0
Transcript of IONA Technologies Position Paper Constraints and Capabilities for Web Services...
2
Agenda
1. Motivation and History of Policy Usage
2. Most Important Characteristics
3. Use Case
4. Conclusion
5. Discussion
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
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> <Interface … > <Policy … > … </Policy> <Policy …> … </Policy> … </Interface></Service>
• Service• Interface• Interface Operation• Message Reference• Binding• Binding Operation• Binding Message / Fault Reference
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
<Kerberos />
<X509 />
</Policy>• 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)
1. Service2. Interface3. Interface Operation4. Message Reference5. Binding6. Binding Operation7. 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
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=“…” …> <Policy type=“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=“…” …> <Policy type=“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
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.
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