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

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

3. 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
XML parsing, searching etc.
Call shell scripts, Java bundles
Do SNMP queries
TCP sockets
Bill Brickman

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

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

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

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

8. Proposed ESB System Architecture For Amazon AWS8

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