Paul Butterworth Policy Based Approach

This Presentation Courtesy of the
International SOA Symposium
October 7-8, 2008 Amsterdam Arena
www.soasymposium.com
info@soasymposium.com

Founding Sponsors

Platinum Sponsors

Gold Sponsors Silver Sponsors

SOA Runtime Governance

A Policy-Based Approach

Paul Butterworth
Chief Technology Officer
AmberPoint, Inc

October 2008

1

Agenda

 SOA Characterization
 Policy-based Runtime Governance
 Some Examples

Based on our experiences with
~200 customers

© 2008 AmberPoint, Inc. 3

Typical Service Network Topology

 Services not
applications
Internal
Services
 Shared
Order Entry
 Dynamic
Accounting  Federated

Partner

Credit firewall

Shared
Services External
Services


2

Typical Service Network Infrastructure

Appliance

Web
Service

Network

Java
Service
Biz
Application

Service Bus

DBMS

Biz
Application Mainframe
Application

In all but the newest of environments, “SOA” ≠ “Just Web Services & XML”

© 2008 AmberPoint, Inc.

Keys to Successful Governance and Management
of SOA Applications

 Continuous SOA Discovery
 Service Management &
Security


3

Keys to Successful Governance and Management
of SOA Applications

 Business
 Architects & Development


 Operations

 Continuous SOA Discovery
 Service Management &
Security
 Business Transaction
Management
 Business System Validation
 Closed Loop Governance


SOA Runtime Governance and Life Cycle

SOA Runtime Governance automates real-time visibility and
control at each stage of the SOA lifecycle
Development Staging Production

Business Logic
IDE’s
Process Tools

Policies Diagnostics More Policies
• Performance • Security • Performance • Security
• Availability • Logging • Availability • Logging
• SLAs • Audit
Validation
Performance
Service
Levels
Capacity
Discovery Planning
• Automatically enforce Discovery
• Automatically discover
governance rogue services


4

Agenda

 Some Examples


Governance Constraints as Policy

 Declarative specification of system
characteristics as “Policies”
 Configurations
 Constraints
 Desired states

 Specify what must be accomplished as
opposed to “how”
 What are my service levels not how to measure them
 What are my faults not how to detect them
 What level of security do I require


5

Policy Benefits in Runtime Governance

 Improve Productivity and Increase Accuracy
 Simpler constraint specification
 Easier to understand
 Easier to change

 Eliminate Policy Obsolescence
 Decouple policy description from policy enforcement
 Remap and reassign policies as environment evolves
– New intermediaries and system architecture
– New phase of lifecycle – testing vs. production
– Different department / division – architectural choices

 Leverage intrinsic and increasing SOA capabilities of various
“intermediaries” whenever possible
 Platforms – Indigo, WebSpeher, WebLogic, NetWeaver, IONA, etc.
 ESBs – AquaLogic, WebSphere ESB, SAP XI
 XML-aware Appliances – Cisco AON, Forum, Datapower, Reactivity, etc.


Policy-based Runtime Governance Architecture

Policy Requests Runtime Service
Governance Network

Business Operations
- Track our contracted Runtime
service levels Policy policies

Systems Operations service
- Ensure reliability contract
Runtime
Policy & Analysis Enterprise Service Bus
Engine
Security Officer
- Enforce authentication

Developer Collected
- Feedback on Data
data
runtime errors

Runtime Policy
Execution Point (PEP)

Simple Policies Complex Policies
 Instrumentation
Load  Service level Exception
 Failover Balancing Management
agreements
 Load balancing data
PEP  Exception handling
 Content-based routing data
begin end
 Advanced security
 Transformations
 Validation
 Encryption
 Security checks S1 S2 S3 S4
S1 S2

6

Binding Policy to SOA

One-at-a-Time Dynamic
Approach Approach
Logging all
p1 p1 p1 p50 services
Security where Load-Bal where deployed
s1
Encryption “Accounting”
Weighted
on .NET app servers
s2

s3 s1 s5
100 svcs x 50 policies
s3
s6
5,000 s2
policy points s4

s100

 Apply p1 to s1  All production services
 Apply p2 to s2  All orders > $10,000
 Apply p1 to s2  All services in Accounting application
 …..
 All services deployed in WebLogic
containers

Detailed Metadata of Your SOA Environment

 Operational Info:
 When service was
discovered
 Availability
 Type of service
 Type of container
 Link to WSDL
Operational Info
 Business Info:
 Business owner
 Division
 Version
 Etc.

Custom: Business Info
 Chargeback info
 Risk assessment
 Links to URL‟s
 Etc.

7

Capability-based Delegation of Runtime Policies

AmberPoint  Gathers existing application
Runtime Governance knowledge and policies
Runtime Dependencies Policy  Assigns policies based on
Repository
capabilities
 Translates runtime policy into
Security
AuthN Monitoring
platform-specific interfaces
Logging
 Monitors execution
Load-Bal
Round-Robin  Agents to round out
capabilities and for other
components

Network

15

Agenda

 Some Examples


8

Universal Policy Library
Consistent enforcement regardless of SOA infrastructure

 Library of commonly used
runtime policies
 Instrumentation  Throttling
 Content-based Policies  Failover
 Versioning  Load Balancing
 Authentication – certificates,  Quality of Service
credentials, SAML, etc  Performance
 Availability
 Authorization
 Throughput
 Censorship  Service Level
 Credential Mapping Agreements
 Crypto – Signatures &  Exception Handling
Encryption  Validation

 Based on standards
 WS-Policy
 WS-SecurityPolicy
 WS-PolicyAttachment

 User-extensible
 Leverage the metadata
 “Apply Encryption to All Services where
Application_group = „Accounting‟”

 Synchronize with other
governance processes

Service Virtualization

 Abstracts service changes and versions behind a
published „façade‟ (a „virtual‟ service)
 Enables endpoint routing, load-balancing, failover,
transformations etc.
Before After

• Sees simpler interface
• Service changes don’t
show through.

Service Service Virtual •Load balance
A B •Route
Svc •Transform
(PEP) •Version
OrderLookup ScheduleShip
ChangeDate ChangePrior Service
Service
ChangeQty LookupETA A
B

OrderLookup ScheduleShip
ChangeDate ChangePrior
ChangeQty LookupETA


9

Service Level Management

 Real-time visibility into service
network performance and
availability
 Segmentation and
prioritization based on
business criteria
 Trigger preventative and
corrective actions
 Redirect traffic
 Make less critical requests wait

 Reporting
 Compliance Process Engine Service Bus

 Historical trends for capacity
planning


Transaction Management

 Visibility into technical and application-level errors
 “rejected”, “unknown”, “Error code: UUUEX32AF”, SOAP faults, no
response, transport-level errors
 Monitoring of business-level anomalies
 International travel ticket with price < $100
 IT & Business Operations Non-Compliance
 Order completed and shipped, but never invoiced
 Regulatory non-compliance (Privacy Act, HIPAA conditions etc. )

10

SOA Security

XML Encryption/Decryption
• Apply to parts of message, across multiple hops
• Independent of transport, language or vendor
<?xml version='1.0'?> env:Fault >
<Name>
<PaymentInfo xmlns='http://example.org/paymentv2'>
Unknown Servic
<Encrypted
<Name>John Smith</Name>
<EncryptedData "urn:ups -shipping
XML Signatures/Validation
Type='http
Type='http://www.w3.org/2001/04/xmlenc#Element'
Service Down
<CipherDa
xmlns='http://www.w3.org/2001/04/xmlenc#'>
• Apply to parts of message,
<CipherData>
server:8192/e
<Cipher
<CipherValue>A23B45C56</CipherValue>
across multiple hops
</CipherData>
</EncryptedData>
/soapenv :
</Ciphe • Transport, language & vendor
</PaymentInfo>
independent

Process Engine Service Bus

Last-Mile Security for Distributed SOA Integrate with Existing Security Solutions
• Local intermediaries enforce security for each
end-point
• Manage security events & exceptions across
distributed environments


Client Provisioning

AmberPoint
Management Svcs
policies
Registry Policy Data
Manager Collection
data
policies
data
service
contract

switch

 Provisions client with service contract requirements
 Looks up service endpoint and caches it for higher performance
 Provisions required security policies
 Automatically process request and response to match policy requirements
 Insertion of security info, acquire security tokens, etc.
 Collects client-side service level metrics
 Provides visibility into “first mile” SLA metrics
 Local logging of interactions, if requested

Reduces costs by eliminating coding.

11

Business System Validation

 Acceptance testing of
pending changes to SOA Validation Checklist
environment : Capacity Adequate
 New Versions of Services : Security Policies Functioning
 Policy Changes
: WS-I Compliant
 Bug Fixes
Unexpected Deviation for
 Infrastructure Patches, etc. B2B Partner Usage

 Uses knowledge of
dependencies and
observed interactions
 Simulates services that
Development Staging Production
can’t be replicated in
pre-production
environments
 External services
 Fee-based services
Process Engine Service Bus

 Gives Staging and
Operations a final check
before deploying changes

The “Preflight Check” for SOA Systems

Q&A

Paul Butterworth

pbutterworth@amberpoint.com
www.amberpoint.com
510.663.6300

24

12

Paul Butterworth Policy Based Approach

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (6)

Similaire à Paul Butterworth Policy Based Approach

Similaire à Paul Butterworth Policy Based Approach (20)

Plus de SOA Symposium

Plus de SOA Symposium (20)

Dernier

Dernier (20)

Paul Butterworth Policy Based Approach