1. 1 Web Services Policy Management Greg Pavlik Web Services Architect Oracle Corporation May 11, 2005

2. 2 Industry Perspective  High priority technology – Platform  Leading application server suite  Fusion provides SOA-based architecture for Applications – Policy Management  Oracle Web Services Manager ­Based on CoreSV product line from Oblix acquisition

3. 3 Industry Problem  Provide policy framework that is – Shared – Useful – Manageable

4. 4 Policies in Related Middleware  WWW – Heavily focused on questions of use  Whether to use ­Privacy ­Access control ­Cost  When to use ­Availability – Human to machine emphasis – Ad hoc, reputation driven

5. 5 Policies in Related Middleware  CORBA – System to system protocol stack – Heavily focused on system protocols  Security  Transaction processing  Web Services – Combine elements of system to system and Web based policies

6. 6 Combining Concepts?  Stove-piped policies – System services  Reliability, transactions, security – Informational Policies  Privacy – Rules based Based on existing systems and languages: Difficult to unify, reason over

7. 7 Middleware Stasis Has the application server evolved since CICS? Managed resources for: Network/Systems Connectivity Transaction Processing Availability Constrained evolution

8. 8 Web Services Policy Today  Critical milestone for deployments  Current challenges – No standards effort – Current proposals limited  WS-Policy ­Good for simple system services ­Lacks encapsulation of domain functions  F&P ­Tightly bound to WSDL ­Lacks basic logic operators

9. 9 Idealized Policy Framework  Allows different domains to utilize appropriate syntax and semantics – What’s good for transaction processing doesn’t translate to business agreements – Can we live with stovepipes?  Allows policy expectations to be expressed – Important for informational policies like privacy  Can evolve independent of WSDL

10. 10 Policy Management  Lifecycle – Create  Internal configuration/Internal policies ­Audit/Administrative rules  Policies targeted at external consumption  Mesh with global policies ­Centralized repositories ­Merging rules – Provision  Availability of service  Configure enforcement points ­Today: requires single vendor intervention – Version  Support non-disruptive evolution

11. 11 Enforcement Web Services Client Management Service Endpoint Client Transport HTTP, JMS SOAP Message SOAP Message SOAP Message SOAP Message Web Services Server Management WS- Security WS- Reliability Auditing/ Logging WS- Reliability Auditing/ Logging WS- Security Auditing/ Logging WS- Reliability WS- Security Auditing/ Logging WS- Reliability WS- Security Warning: Can wind up with complex flows!

12. 12 Enforcement  Agents – Deploy to participants – Synchronize with repository  Gateways – Sits between participants – Exploits loose coupling between policies and application logic Request Response GATEWAYAGENTS

13. 13 Governance  Visibility  Accountability – Auditing  Control GATEWAY AGENT

14. 14 Solution Topology Consumer application with AGENTS Web service (provider) with AGENTS GATEWAY Load Balancer POLICY MANAGER PM Load Balancer MONITOR MON OperationsOperations SecuritySecurity AdminAdmin AGENT GATEWAY Systems Mgmt Systems Management

15. 15 Observations  Enforcement driven by internal configuration – Still need to share  Consumers  Other infrastructure providers  Policy normalization now possible – Global policies – Support for protocols not native to platform  Liberty v. Federation

16. 16 Futures  Standardized policy framework – Unclear how it will wind up  Explicit support for policy management – Provisioning protocol – Systems management integrations  Conventional alerts – WSDM?