Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Large Scale Deployment of SOA-P

994 Aufrufe

Veröffentlicht am

Large Scale Deployment of SOA-P Real World Lessons

Presentation by
Steve Millidge

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

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;org.jboss.internal.soa.esb.services.security.User 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?