Administrative Technology Services: Enterprise Applications Enterprise Service Bus Proof of Concept To the service bus and beyond... Lisa Justiniano 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. Lisa Justiniano Secondary goal: Get our feet wet on Amazon Web Services.

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 Bill Brickman

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

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” Bill Brickman

Recommended Solution We looked at several products: Mule ESB Apache ServiceMix Red Hat jBoss Fuse three closely related and use ActiveMQ Red Hat jBoss Fabric8 Informatica Our recommendation: ESB Message Queue Fabric8 for cloud deployment - ActiveMQ ServiceMix for conventional deployment Free, open source, standards compliant, load balancing Multiple vendors (Apache – free; Red Hat – QA and support) Mike Thomas

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

Proposed ESB System Architecture For Amazon AWS 8

Next Steps 1.Prepare TEST Environ: months 0-4 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 Deploy Pilot Integrations Stabilize PROD environment and integrations Build and test internal integrations Verify assumptions Refine training materials Assess learning curve 4.Rollout to ATS: month 18 & beyond Assess support issues Confirm low impact and minimized risk Lisa Justiniano Build & Test internal integrations – Enterprise Applications will do initial integrations Assess Support Issues – Performance, scalability , operational visibility, infrastructure Care/Feeding