Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WebSphere Message Broker In Shared Runtime Environments

3,490 views

Published on

WebSphere Message Broker in shared runtime environments.

Typical environment configurations and common set-ups with regards to high availability and workload balancing.

What kind of solutions do we see implemented on top of message broker what are the demands for these solutions in terms of availability and isolation?

How do we cater for these needs in a shared runtime environment?

Also takes a look at the organization developing solutions targeting a shared runtime environment and how different organizations pose different requirements and challenges.

Presentation given at IBM Transaction & Messaging conference in Barcelon 2008.

Published in: Technology, Business
  • Be the first to comment

WebSphere Message Broker In Shared Runtime Environments

  1. 1. TMM20: WebSphere Message Broker in Shared Runtime Environments Mårten Gustafson, Zystems [email_address]
  2. 2. Point to Point Spaghetti Middleware Adoption EAI Focusing on Application Integration ESB Focusing on Reusable Services BPM Business Process Management
  3. 3. Parts of an ICC (according to Zystems) Communication Delivery Governance Operations ICC
  4. 4. Agenda Delivery Governance Operations
  5. 5. <ul><li>Development Organizations </li></ul><ul><li>and their requirements on a shared runtime </li></ul>
  6. 6. ICC Organizational Models as defined by Schmidt & Lyle in “Integration Competency Center, An Implementation Methodology” © 2005, Informatica Project silos Best practices Standard services Shared services Central services Self-service
  7. 7. Typical shared services ICC BU Project / dev team BU Project / dev team BU Project / dev team BU Project / dev team ICC Governance Operations
  8. 8. Shared services runtime <ul><li>Characteristics </li></ul><ul><ul><li>Central operations </li></ul></ul><ul><ul><li>Used by project teams from disparate business units </li></ul></ul><ul><li>Key things </li></ul><ul><ul><li>Isolation </li></ul></ul><ul><ul><li>Auditing/Monitoring </li></ul></ul>
  9. 9. ICC Example - Customer Case 1 <ul><li>Shared Services ICC </li></ul><ul><ul><li>~10 headcount </li></ul></ul><ul><ul><ul><li>Architects and managers </li></ul></ul></ul><ul><ul><li>Operations as a separate entity </li></ul></ul><ul><ul><ul><li>~4 headcount </li></ul></ul></ul><ul><ul><li>~4 projects on their way into the runtime </li></ul></ul>
  10. 10. Typical central services ICC BU BU BU BU ICC Delivery (project / dev team) Operations Governance
  11. 11. Central services runtime <ul><li>Used only by the ICC </li></ul><ul><ul><li>Central control within a closed team </li></ul></ul><ul><li>Characteristics </li></ul><ul><ul><li>Central operations </li></ul></ul><ul><ul><li>Used only by the ICC </li></ul></ul><ul><ul><li>Central control within a closed team </li></ul></ul><ul><li>Key things </li></ul><ul><ul><li>Message tracing/tracking </li></ul></ul><ul><ul><li>Development guidelines/re-use/patterns </li></ul></ul>
  12. 12. ICC Example - Customer Case 2 <ul><li>Central Services ICC </li></ul><ul><ul><li>~50 headcount </li></ul></ul><ul><ul><ul><li>Developers, architects, process modelers, operations staff </li></ul></ul></ul><ul><ul><li>~330 flows </li></ul></ul><ul><ul><ul><ul><li>File transfer 48,5% </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Transformation 35,9% </li></ul></ul></ul></ul>
  13. 14. <ul><li>Shared Runtime Environments </li></ul>
  14. 15. Typical environment configurations Broker B Broker A Cluster or virtualization technique WMQ cluster / HTTP load balancer
  15. 16. QoS – Performance and Availability Cluster or virtualization technique WMQ cluster + HTTP load balancer <ul><li>High performance “zone” </li></ul><ul><li>Active/Active </li></ul><ul><li>Workload balancing </li></ul><ul><li>Continuous availability </li></ul>Broker A <ul><li>Low performance “zone” </li></ul><ul><li>One node </li></ul><ul><li>Failover delay </li></ul>Broker C Broker B
  16. 17. Isolation / Partitioning Broker Broker EG EG EG EG EG
  17. 18. <ul><li>Examples of real world environments </li></ul>
  18. 19. Customer example 1 MQ cluster Solaris zones + Veritas cluster Broker A Broker B GW QM HTTP Load Balancer Broker C Dedicated, per project Shared between projects (preferred) Broker C Broker … Broker …
  19. 20. Customer example 2 MQ cluster A MQ cluster B Broker B2 Broker B1 Broker A1 Broker A2 GW QM1 GW QM2 Extranet DMZ Intranet HTTP load balancer HTTP load balancer
  20. 21. Customer example 3 LPAR LPAR AIX HACMP Broker A Broker A
  21. 22. Customer example 4 MQ cluster Microsoft Cluster Services Broker A Broker B GW QM
  22. 23. <ul><li>Active/Active Runtime Environments </li></ul><ul><li>and Implications on Development </li></ul>
  23. 24. State
  24. 25. Concurrency
  25. 26. HTTP Broker A HTTP load balancer Broker B ? ! biphttplistener biphttplistener SupportPac IE01
  26. 27. SOAP Broker B Broker A WMQ cluster / HTTP load balancer EG-embedded listener EG-embedded listener
  27. 28. Heads up
  28. 29. Timers / Schedules
  29. 30. TCP/IP input
  30. 31. <ul><li>Wrap up </li></ul>
  31. 32. General lack of data and best pracices <ul><li>Why is there so little data, patterns and practices available out in the “wild”? </li></ul><ul><ul><li>In our experience </li></ul></ul><ul><ul><ul><li>Because the products “just work” </li></ul></ul></ul><ul><ul><li>Both good and bad </li></ul></ul><ul><ul><ul><li>Good: products proven as very stable for mission critical operation </li></ul></ul></ul><ul><ul><ul><li>Bad: if you break new ground or think “outside the box” there’s not much experience, best practices available, assets or patterns </li></ul></ul></ul>
  32. 33. Examples of mission critical deployments <ul><li>Manufacturing industry </li></ul><ul><li>Banking/Trading </li></ul><ul><li>Pension funds management </li></ul><ul><li>Construction </li></ul><ul><li>If the integration platform stop, </li></ul><ul><li>the business stop </li></ul>
  33. 34. Shared runtime - Key takeaways <ul><li>Isolate </li></ul><ul><ul><li>Execution Groups as the unit of isolation </li></ul></ul><ul><ul><li>Examine your OS ability to limit resources for processes and/or users </li></ul></ul><ul><li>Automate </li></ul><ul><ul><li>Broker and EG creation </li></ul></ul><ul><ul><ul><li>Permissions </li></ul></ul></ul><ul><ul><ul><li>File system structures </li></ul></ul></ul><ul><ul><li>Deployment </li></ul></ul><ul><ul><ul><li>Consider self-service deployment (at least for test/QA environments) </li></ul></ul></ul><ul><li>Govern </li></ul><ul><ul><li>Development guidelines / harvest patterns / document key concepts </li></ul></ul><ul><ul><li>Implementation patterns adapted to the runtime environment </li></ul></ul><ul><ul><ul><li>Req/Rep, Pub/Sub, Fan in/out, Collection, FTP, File transfer etc </li></ul></ul></ul><ul><ul><li>Make sure the people responsible for governance participate in projects themselves </li></ul></ul>

×