Enterprise Service Bus Proof of Concept To the

Enterprise Service Bus Proof of Concept To the service bus and beyond. . . Administrative Technology Services: Enterprise Applications

Project Goal Problem: We keep “inventing” different ways to accomplish similar integration tasks, leading to a variety of software that needs to be maintained, supported and enhanced by staff who understand that particular technique. Solution: Provide standard ways to achieve these common integration tasks, thereby simplifying our software base and making it more easily maintainable and accessible by our partners in a consistent manner. 2

ESB Functionality • JMS message queues • Host web services and call external web services • Monitor folders (local and remote) for incoming files • Transfer files to remote systems • Query and update databases • Query LDAP / AD directories • Send and receive email • XML parsing, searching etc. • Call shell scripts, Java bundles • Do SNMP queries • TCP sockets 3

Benefits • Faster to market. – Simple, URL-like, syntax – Code is provided for us, we just write the configuration • Large selection of integration libraries (DB, web services, LDAP & AD, etc. ) means we can do things we wouldn’t have attempted before. • Transformations become possible (both payload and transmission protocol) without modifying the source or target systems. • Asynchronous integrations will decouple applications. • We can move from batch to transactional: fresh data gets to users faster. 4

Benefits • Generic and modular coding style: many small reusable bundles of code. • Centralized – Improve operational transparency – Reduce security overhead (ACLs and logins) • Publish and Subscribe queues can eliminate the “daisy chain” method of obtaining information so that: – Fresh data gets to users faster – Subscribers don’t need to know much about the source systems – There is a single source of “truth” 5

Recommended Solution We looked at several products: – Mule ESB – Apache Service. Mix – Red Hat j. Boss Fuse three closely related and use Active. MQ – Red Hat j. Boss Fabric 8 – Informatica Our recommendation: ESB Message Queue – Fabric 8 for cloud deployment - Active. MQ – Service. Mix for conventional deployment • Free, open source, standards compliant, load balancing • Multiple vendors (Apache – free; Red Hat – QA and support) 6

Recommended Solution - Architecture Our recommendation: • Lowest cost and provides most benefit in terms of shared security, logging and auditing. • Reduced deployment time (infrastructure and ACLs are already in place). • Developer environment and deployables are the same regardless of which architecture we choose, so is possible to change architecture over time. • In the future we may need to move to a more complex architecture: – for performance reasons – to isolate populations (of developers, or systems, or even users) from one and other 7

Proposed ESB System Architecture For Amazon AWS 8

Next Steps Prepare Build Pilot Rollout 1. Prepare TEST Environ: months 0 -4 3. Rollout Pilot: months 8 – 18 – Install and configure bare-bones infrastructure – Upgrade infrastructure for fail-over / load balancing – Determine and document best practices – Build PROD environment 2. Build Integrations: months 2 -18 – Build and test internal integrations – Verify assumptions – Assess learning curve – Assess support issues – Deploy Pilot Integrations – Stabilize PROD environment and integrations – Refine training materials 4. Rollout to ATS: month 18 & beyond – Confirm low impact and minimized risk 9