• Save
Large Scale Deployment of SOA-P
Upcoming SlideShare
Loading in...5

Large Scale Deployment of SOA-P



Large Scale Deployment of SOA-P Real World Lessons

Large Scale Deployment of SOA-P Real World Lessons

Presentation by
Steve Millidge



Total Views
Views on SlideShare
Embed Views



2 Embeds 24

http://www.c2b2.co.uk 23 1



Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Large Scale Deployment of SOA-P Large Scale Deployment of SOA-P Presentation Transcript

  • Large Scale Deployment of SOA-P Real World Lessons Steve Millidge Director, C2B2 Tuesday 4 th May
  • “ The ease of use of modern SOA enabling tools hides the technical complexity of implementing a reliable SOA technology platform, but developing an enterprise-wide reliable, scalable, high performance, secure and manageable SOA infrastructure requires a level of technical command that few organisations have been able to develop.” Massimo Pezzini - Gartner
  • Fast Reliable Manageable Secure
  • FAST
  • Considerations when you have a Problem
    • Performance Problem
      • Single Item is not Fast Enough
    • Scalability Problem
      • Single Item Performance is OK
      • Multiple Items are Poor
    • Capacity
      • Systems Scales
      • Reached Limit of a single “node”
      • Add more “nodes”
  • Service Review Service Invoker UDDI EPRs Protocol Gateway Listener Service Listener Action Pipeline Gateway Action1 Action 2 Action 3 Action 4
  • Tuning the pipeline
    • Listener Threads are critical for throughput
      • Remember Tune Gateway and Service Thread Pools
      • maxThreads property of the Listener
      • Match to your protocol
    • InVM Transport
      • Very Fast compared to JMS
      • InVM Scope attribute on your Service Tag
      • See Later
    • Reuse Service Invokers
      • Order of magnitude quicker
  • Tuning the Pipeline (2)
    • PreferLocalLoadBalance Policy (write one)
    Host 1 Host 2
  • Scalability
    • Limit the number of services per Node
      • Each Service has its own thread pool
    • Ensure protocols suitable for Client->Server model
      • HTTP is a many->few protocol suitable for many clients
      • JMS suitable for fan out to cluster from single or few clients
    • Customer went from 7 messages per second to 200 by switching from HTTP to JMS
  • Make use of Heterogeneous Service Deployment Client UDDI EPRs Heavy Memory Services Heavy CPU Services Fast Response Services
  • Use Service Invoker Load Balancing
    • Simpler than protocol clustering
    • Code Configurable – write your own LB Policy
    • Each ESB Node can be independent
    Client Service Invoker Service Node 1 Service Node 2
  • Reliable
  • Reliability
    • High Availability Architecture
      • Removing Single Points of Failure
      • Design for Failure
      • Design for Edge Conditions
    • Recoverability
      • System must recover to a KNOWN state
      • Careful design of transaction boundaries
      • Detailed analysis of “moving parts”
  • SOA-P HA Technical Architecture Service Invoker Round Robin JMS EPR Custom HA UDDI lookup Client Host 1 Host 1 UDDI UDDI Local DB (MySQL) Local DB (MySQL)
  • SOA-P HA TA Key Features
    • Service Invoker does Round Robin
      • Customisable
    • Local Database per Node (MySQL)
      • JMS Queues, EJB Timers, Message Store etc.
    • Centralised HA UDDI
      • Can be HA database
      • Custom Registry Interceptor
    • JON (JBoss Operation Network)
      • Monitoring of JBoss Servers
      • Alert on potential failures
  • Recoverability
    • Fault Handling in the Bus requires Careful Design
      • Transactionally
      • Routing (FaultTo, ReplyTo, DLQ etc.)
    • Determine Quality of Service on Services
      • Can you lose data
      • Can replies be lost for Request/Response
      • DO NOT Over Specify QOS
  • Transaction Boundaries
    • If you can't lose data use JMS
      • Remove inVM from those services
    • Make your service transactional
    JMS Queue Service Listener Action Pipeline Action1 Action 2 Action 3 Action 4 Single JTA Transaction
  • Compensating Transactions
    • If you service can not be Transactional
      • Invokes webservice, ftp file etc.
    • FaultTo to route to an UNDO service
      • Set FaultTo EPR in the message header
    Non-transactional Service Compensating Service FaultTo msg
  • Manageable
  • Managability Considerations
    • Runtime Visibility of the System
      • JON provides detailed statistics of the Bus
      • Build custom business JMX metrics (trivial coding)
    • Runtime Control
      • JON provides single point of control of the system
      • May require custom JMX beans (simple to write)
    • Upgrades and Patching
      • JON can provide patch monitoring and installation
  • Service Versioning
      In a SOA architecture not everything can be upgraded at the same time.
    • Address the problem NOW
    • Devise a Service Naming Strategy
      • Category.Name.version
      • Purchasing.PlaceOrder.1
    • Clients can bind directly to the version required
    • Possible to write a Registry Interceptor to do version matching etc.
    • Isolate deployment classloaders
  • Secure
  • Security Basics
    • Authentication
      • Identifying user is who they say they are
    • Authorisation
      • Is the user allowed to do or see this
    • Audit
      • Recording what's been done
    • Availability
      • Is the system available for use
    • Confidentiality
      • Can somebody see data flowing through
  • Security Approach
    • Analyse all attack vectors
      • Denial of Service
      • Breach of Confidentiality
      • Unauthorised operation
  • What can you Do?
    • Security Harden your JBoss installation
    • Secure all inbound protocols
      • JMS, HTTP, FTP etc.
    • Secure access to the Registry
    • Lock down deployment routes
    • Audit configuration file changes
    • Secure individual services
    • Enable Identity Propagation
  • Security Context Propagation SOA-P
    • Moves Identity across service boundaries
    • Enables “deep” authorisation and audit
    Authentication Boundary Inbound Service Authorising Service Identity
  • Securing the Service
      <security moduleName=&quot;messaging&quot; runAs=&quot;adminRole&quot; rolesAllowed=&quot;adminRole, normalUsers&quot; callbackHandler= &quot;org.jboss.internal.soa.esb.services.security.User PassCallbackHandler&quot;> </security>
    • ESB propagates a security context in the message
    • Recreated and JAAS login occurs before service called
    • Authorisation check performed
  • Fast Reliable Manageable Secure
  • Questions?