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

1

Web Services Policy Management

Greg Pavlik

Web Services Architect

Oracle Corporation

May 11, 2005

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

Industry Problem

Provide policy framework that is– Shared– Useful– Manageable

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

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

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

Middleware Stasis

• Has the application server evolved since CICS?

• Managed resources for:• Network/Systems Connectivity

• Transaction Processing

• Availability

• Constrained evolution

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

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

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

Enforcement

Web ServicesClient Management

Service Endpoint

Client

TransportHTTP, JMS

SOAPMessage

SOAPMessage

SOAPMessage

SOAPMessage

Web ServicesServer 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

Enforcement

Agents– Deploy to participants– Synchronize with repository

Gateways– Sits between participants– Exploits loose coupling between policies and application

logic

Request

Response

GATEWAY AGENTS

13

Governance

Visibility Accountability

– Auditing

Control

GATEWAY

GATEWAY

GATEWAY

AGENT

AGENT

AGENTAGENT

AGENT

14

Solution Topology

Consumer application with

AGENTSWeb service (provider) with

AGENTS

GATEWAY

Load Balancer

Load Balancer

Load Balancer

POLICY MANAGER

PM

PMPM

PMLoad Balancer

MONITOR

MON

MONMON

MON

Operations

Security

Admin

AGENT

AGENTAGENT

AGENTAGENT

AGENTAGENT

AGENT

GATEWAY

GATEWAYGATEWAY

GATEWAY

Systems Mgmt Systems Management

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

Futures

Standardized policy framework– Unclear how it will wind up

Explicit support for policy management– Provisioning protocol– Systems management integrations

Conventional alerts

– WSDM?