IONA Technologies Position PaperConstraints and Capabilities for Web Services

Rebecca.Bergersen@iona.com

2

Agenda

1. Motivation and History of Policy Usage

2. Most Important Characteristics

3. Use Case

4. Conclusion

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

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=“…” …> <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.

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