Large Scale Deployment of SOA-P
0 likes619 views
This document discusses lessons learned from large-scale deployment of a service-oriented architecture (SOA) platform. It covers key considerations for building an infrastructure that is fast, reliable, manageable, and secure at an enterprise scale. Specific techniques discussed include tuning service pipelines, load balancing, high availability design, transaction management, monitoring, versioning, authentication, authorization, and security context propagation.
Large Scale Deployment of SOA-P
- 1. Large Scale Deployment of SOA-P Real World Lessons Steve Millidge Director, C2B2 Tuesday 4 th May
- 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. Fast Reliable Manageable Secure
- 4. FAST
- 5. Considerations when you have a Problem Performance Problem Single Item is not Fast Enough Scalability Problem Single Item Performance is OK
- 6. Multiple Items are Poor Capacity Systems Scales
- 7. Reached Limit of a single “node”
- 9. Service Review Service Invoker UDDI EPRs Protocol Gateway Listener Service Listener Action Pipeline Gateway Action1 Action 2 Action 3 Action 4
- 10. Tuning the pipeline Listener Threads are critical for throughput Remember Tune Gateway and Service Thread Pools
- 11. maxThreads property of the Listener
- 12. Match to your protocol InVM Transport Very Fast compared to JMS
- 13. InVM Scope attribute on your Service Tag
- 14. See Later Reuse Service Invokers Order of magnitude quicker
- 15. Tuning the Pipeline (2) PreferLocalLoadBalance Policy (write one) Host 1 Host 2
- 16. 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
- 17. 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
- 18. Make use of Heterogeneous Service Deployment Client UDDI EPRs Heavy Memory Services Heavy CPU Services Fast Response Services
- 19. Use Service Invoker Load Balancing Simpler than protocol clustering
- 20. Code Configurable – write your own LB Policy
- 21. Each ESB Node can be independent Client Service Invoker Service Node 1 Service Node 2
- 22. Reliable
- 23. Reliability High Availability Architecture Removing Single Points of Failure
- 25. Design for Edge Conditions Recoverability System must recover to a KNOWN state
- 26. Careful design of transaction boundaries
- 27. Detailed analysis of “moving parts”
- 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. 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
- 30. Custom Registry Interceptor JON (JBoss Operation Network) Monitoring of JBoss Servers
- 31. Alert on potential failures
- 32. Recoverability Fault Handling in the Bus requires Careful Design Transactionally
- 33. Routing (FaultTo, ReplyTo, DLQ etc.) Determine Quality of Service on Services Can you lose data
- 34. Can replies be lost for Request/Response
- 35. DO NOT Over Specify QOS REMEMBER THE SYSTEM IS ASYNCHRONOUS
- 36. 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
- 37. 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
- 38. Manageable
- 39. Managability Considerations Runtime Visibility of the System JON provides detailed statistics of the Bus
- 40. Build custom business JMX metrics (trivial coding) Runtime Control JON provides single point of control of the system
- 41. May require custom JMX beans (simple to write) Upgrades and Patching JON can provide patch monitoring and installation
- 42. Service Versioning In a SOA architecture not everything can be upgraded at the same time. Address the problem NOW
- 43. Devise a Service Naming Strategy Category.Name.version
- 44. Purchasing.PlaceOrder.1 Clients can bind directly to the version required
- 45. Possible to write a Registry Interceptor to do version matching etc.
- 47. Secure
- 48. 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
- 49. Security Approach Analyse all attack vectors Denial of Service
- 52. What can you Do? Security Harden your JBoss installation
- 53. Secure all inbound protocols JMS, HTTP, FTP etc. Secure access to the Registry
- 54. Lock down deployment routes
- 55. Audit configuration file changes
- 58. Security Context Propagation SOA-P Moves Identity across service boundaries
- 59. Enables “deep” authorisation and audit Authentication Boundary Inbound Service Authorising Service Identity
- 60. Securing the Service <security moduleName="messaging" runAs="adminRole" rolesAllowed="adminRole, normalUsers" callbackHandler= "org.jboss.internal.soa.esb.services.security.User PassCallbackHandler"> </security> ESB propagates a security context in the message
- 61. Recreated and JAAS login occurs before service called
- 63. Fast Reliable Manageable Secure
- 64. Questions?