1 Web Services Policy Management Greg Pavlik Web Services Architect Oracle Corporation May 11, 2005.
-
Upload
collin-casey -
Category
Documents
-
view
212 -
download
0
Transcript of 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?