Large Scale Deployment of SOA-P


Published on

Large Scale Deployment of SOA-P Real World Lessons

Presentation by
Steve Millidge

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Large Scale Deployment of SOA-P

  1. 1. Large Scale Deployment of SOA-P Real World Lessons Steve Millidge Director, C2B2 Tuesday 4 th May
  2. 2. “ 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
  3. 3. Fast Reliable Manageable Secure
  4. 4. FAST
  5. 5. Considerations when you have a Problem <ul><li>Performance Problem </li><ul><li>Single Item is not Fast Enough </li></ul><li>Scalability Problem </li><ul><li>Single Item Performance is OK
  6. 6. Multiple Items are Poor </li></ul><li>Capacity </li><ul><li>Systems Scales
  7. 7. Reached Limit of a single “node”
  8. 8. Add more “nodes” </li></ul></ul>
  9. 9. Service Review Service Invoker UDDI EPRs Protocol Gateway Listener Service Listener Action Pipeline Gateway Action1 Action 2 Action 3 Action 4
  10. 10. Tuning the pipeline <ul><li>Listener Threads are critical for throughput </li><ul><li>Remember Tune Gateway and Service Thread Pools
  11. 11. maxThreads property of the Listener
  12. 12. Match to your protocol </li></ul><li>InVM Transport </li><ul><li>Very Fast compared to JMS
  13. 13. InVM Scope attribute on your Service Tag
  14. 14. See Later </li></ul><li>Reuse Service Invokers </li><ul><li>Order of magnitude quicker </li></ul></ul>
  15. 15. Tuning the Pipeline (2) <ul><li>PreferLocalLoadBalance Policy (write one) </li></ul>Host 1 Host 2
  16. 16. Scalability <ul><li>Limit the number of services per Node </li><ul><li>Each Service has its own thread pool </li></ul><li>Ensure protocols suitable for Client->Server model </li><ul><li>HTTP is a many->few protocol suitable for many clients
  17. 17. JMS suitable for fan out to cluster from single or few clients </li></ul><li>Customer went from 7 messages per second to 200 by switching from HTTP to JMS </li></ul>
  18. 18. Make use of Heterogeneous Service Deployment Client UDDI EPRs Heavy Memory Services Heavy CPU Services Fast Response Services
  19. 19. Use Service Invoker Load Balancing <ul><li>Simpler than protocol clustering
  20. 20. Code Configurable – write your own LB Policy
  21. 21. Each ESB Node can be independent </li></ul>Client Service Invoker Service Node 1 Service Node 2
  22. 22. Reliable
  23. 23. Reliability <ul><li>High Availability Architecture </li><ul><li>Removing Single Points of Failure
  24. 24. Design for Failure
  25. 25. Design for Edge Conditions </li></ul><li>Recoverability </li><ul><li>System must recover to a KNOWN state
  26. 26. Careful design of transaction boundaries
  27. 27. Detailed analysis of “moving parts” </li></ul></ul>
  28. 28. 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)
  29. 29. SOA-P HA TA Key Features <ul><li>Service Invoker does Round Robin </li><ul><li>Customisable </li></ul><li>Local Database per Node (MySQL) </li><ul><li>JMS Queues, EJB Timers, Message Store etc. </li></ul><li>Centralised HA UDDI </li><ul><li>Can be HA database
  30. 30. Custom Registry Interceptor </li></ul><li>JON (JBoss Operation Network) </li><ul><li>Monitoring of JBoss Servers
  31. 31. Alert on potential failures </li></ul></ul>
  32. 32. Recoverability <ul><li>Fault Handling in the Bus requires Careful Design </li><ul><li>Transactionally
  33. 33. Routing (FaultTo, ReplyTo, DLQ etc.) </li></ul><li>Determine Quality of Service on Services </li><ul><li>Can you lose data
  34. 34. Can replies be lost for Request/Response
  35. 35. DO NOT Over Specify QOS </li></ul><li>REMEMBER THE SYSTEM IS ASYNCHRONOUS </li></ul>
  36. 36. Transaction Boundaries <ul><li>If you can't lose data use JMS </li><ul><li>Remove inVM from those services </li></ul><li>Make your service transactional </li></ul>JMS Queue Service Listener Action Pipeline Action1 Action 2 Action 3 Action 4 Single JTA Transaction
  37. 37. Compensating Transactions <ul><li>If you service can not be Transactional </li><ul><li>Invokes webservice, ftp file etc. </li></ul><li>FaultTo to route to an UNDO service </li><ul><li>Set FaultTo EPR in the message header </li></ul></ul>Non-transactional Service Compensating Service FaultTo msg
  38. 38. Manageable
  39. 39. Managability Considerations <ul><li>Runtime Visibility of the System </li><ul><li>JON provides detailed statistics of the Bus
  40. 40. Build custom business JMX metrics (trivial coding) </li></ul><li>Runtime Control </li><ul><li>JON provides single point of control of the system
  41. 41. May require custom JMX beans (simple to write) </li></ul><li>Upgrades and Patching </li><ul><li>JON can provide patch monitoring and installation </li></ul></ul>
  42. 42. Service Versioning <ul>In a SOA architecture not everything can be upgraded at the same time. <li>Address the problem NOW
  43. 43. Devise a Service Naming Strategy </li><ul><li>Category.Name.version
  44. 44. Purchasing.PlaceOrder.1 </li></ul><li>Clients can bind directly to the version required
  45. 45. Possible to write a Registry Interceptor to do version matching etc.
  46. 46. Isolate deployment classloaders </li></ul>
  47. 47. Secure
  48. 48. Security Basics <ul><li>Authentication </li><ul><li>Identifying user is who they say they are </li></ul><li>Authorisation </li><ul><li>Is the user allowed to do or see this </li></ul><li>Audit </li><ul><li>Recording what's been done </li></ul><li>Availability </li><ul><li>Is the system available for use </li></ul><li>Confidentiality </li><ul><li>Can somebody see data flowing through </li></ul></ul>
  49. 49. Security Approach <ul><li>Analyse all attack vectors </li><ul><li>Denial of Service
  50. 50. Breach of Confidentiality
  51. 51. Unauthorised operation </li></ul></ul>
  52. 52. What can you Do? <ul><li>Security Harden your JBoss installation
  53. 53. Secure all inbound protocols </li><ul><li>JMS, HTTP, FTP etc. </li></ul><li>Secure access to the Registry
  54. 54. Lock down deployment routes
  55. 55. Audit configuration file changes
  56. 56. Secure individual services
  57. 57. Enable Identity Propagation </li></ul>
  58. 58. Security Context Propagation SOA-P <ul><li>Moves Identity across service boundaries
  59. 59. Enables “deep” authorisation and audit </li></ul>Authentication Boundary Inbound Service Authorising Service Identity
  60. 60. Securing the Service <ul><security moduleName=&quot;messaging&quot; runAs=&quot;adminRole&quot; rolesAllowed=&quot;adminRole, normalUsers&quot; callbackHandler= &quot; PassCallbackHandler&quot;> </security> <li>ESB propagates a security context in the message
  61. 61. Recreated and JAAS login occurs before service called
  62. 62. Authorisation check performed </li></ul>
  63. 63. Fast Reliable Manageable Secure
  64. 64. Questions?