1.
TMM20: WebSphere Message Broker in Shared Runtime Environments Mårten Gustafson, Zystems [email_address]

2.
Point to Point Spaghetti Middleware Adoption EAI Focusing on Application Integration ESB Focusing on Reusable Services BPM Business Process Management

3.
Parts of an ICC (according to Zystems) Communication Delivery Governance Operations ICC

4.
Agenda Delivery Governance Operations

5.
<ul><li>Development Organizations </li></ul><ul><li>and their requirements on a shared runtime </li></ul>

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.
Typical shared services ICC BU Project / dev team BU Project / dev team BU Project / dev team BU Project / dev team ICC Governance Operations

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.
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.
Typical central services ICC BU BU BU BU ICC Delivery (project / dev team) Operations Governance

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.
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>

14.
<ul><li>Shared Runtime Environments </li></ul>

15.
Typical environment configurations Broker B Broker A Cluster or virtualization technique WMQ cluster / HTTP load balancer

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

17.
Isolation / Partitioning Broker Broker EG EG EG EG EG

18.
<ul><li>Examples of real world environments </li></ul>

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 …

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

21.
Customer example 3 LPAR LPAR AIX HACMP Broker A Broker A

22.
Customer example 4 MQ cluster Microsoft Cluster Services Broker A Broker B GW QM

23.
<ul><li>Active/Active Runtime Environments </li></ul><ul><li>and Implications on Development </li></ul>

24.
State

25.
Concurrency

26.
HTTP Broker A HTTP load balancer Broker B ? ! biphttplistener biphttplistener SupportPac IE01

27.
SOAP Broker B Broker A WMQ cluster / HTTP load balancer EG-embedded listener EG-embedded listener

28.
Heads up

29.
Timers / Schedules

30.
TCP/IP input

31.
<ul><li>Wrap up </li></ul>

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>

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>

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>