GOVERNMENT SERVICES INTEGRATION INDUSTRY SOLUTION

Today it is more critical then ever for government agencies to leverage existing assets, collect and analyze information from a variety of sources and redistribute it as quickly as possible to other organizations that need it, and provide citizens with convenient access to information and services. In the most complex government environments to streamline processes, improve service to citizens, optimize information sharing, and provide real-time visibility into events that affect security or the effectiveness of government operations and services. GOVERNMENT INDUSTRY IT CHALLENGE

Myths endorsed by current process- driven Integration solutions Reality: The Message-Driven ESB Effect Adding a new service takes 2-4 weeks Zero-latency service modifications enabled by re-usability of message-driven Services ‘Certified Delivery’ of messages consumes valuable networking bandwidth Peer-to-peer data transport obviates any penalties of networking bandwidth Process changes necessitate service downtime and hence lost productivity Dynamic service replacements without downtimes – no productivity disruptions typically tied to particular platforms - Java or Microsoft’s.NET Standards-based, interoperable with either Java or.NET platforms Expensive solutions, often over $1,000,000 Equivalent benefits at a fractional cost, typically less than $200,000 MESSAGE-DRIVEN SOA

 The agency’s warehouse management was facing a big challenge in extending its services for its users, owing to complexity of integrating its existing systems.  Managing Inventory across different locations was getting increasingly cumbersome.  Increasing Cost of maintenance owing to:  Significant manual work relating to data manipulation and processing  Lack of transactional visibility  Extended ‘time-to-go-live’ deterring much needed changes in existing business processes SUBSET OF THE BUSINESS PROBLEM FOR ANALYSIS

 Ability to query or “lookup” parts information (lookup request) and validate an inventory or collection of parts (validate request), which are exposed as Web Services.  The inventory requests arrive as flat file attachments or as requests from a Web application; these need to be transformed to XML and published on a JMS topic.  All inbound and outbound XMLs need to be validated for conformance and routed to appropriate JMS Queues.  The transformed inbound messages invoke appropriate Web Services.  The response message needs to be published onto appropriate destinations based on an Oracle database lookup.

FIORANO SOLUTION (1)  Fiorano implemented the solution using out-of-the-box services shipped with the installation. Fiorano ’ s solution is illustrated below:

FIORANO SOLUTION (2)

FIORANO SOLUTION (3)  STEP 1: HANDLE INBOUND REQUESTS  Component(s) Used: POP3, XSLT, Text2XML  Inbound requests in the form of flat file attachments are extracted from the mail server using the POP3 adapter and published onto a pre- defined JMS destination.  The text2XML adapter picks these messages, converts them to XML and publishes them on another JMS destination for further processing

FIORANO SOLUTION (4)  STEP 2: VALIDATE REQUEST XML  Component(s) Used: XMLVerification, CBR (Content Based Router)  Inbound XMLs (and Outbound Response XMLs) are picked from the relevant JMS Queues and validated for conformance by the XMLVerification component.  The CBR component routes the messages to appropriate data channels depending on the nature of the message (Request / Response); the same flow is reused to handle both requests as well as responses.

FIORANO SOLUTION (5)  STEP 3: EXECUTE BUSINESS LOGIC  Component(s) Used: CBR, XMLSplitter, WSConsumer, Aggregator, XSLT  The Lookup / Validate requests are routed to appropriate data flows by the Content Router (CBR).  The requests are split (using XMLSplitter) and the business logic, which is deployed as a remote Web service is invoked using the WSConsumer.  The response messages are grouped (using the Aggregator), transformed (XSLT) and published to respective JMS destinations.

FIORANO SOLUTION (6)  STEP 4: HANDLE OUTBOUND RESPONSE  Component(s) Used: DB, Cache, JMSIn  The response from the Web Service is dynamically routed to an appropriate JMS destination (using the JMSIn component), depending on a lookup in real-time.  The lookup is done via a Cache component (based on values populated from a database) to enhance performance, avoiding expensive DB lookups for every response message.

WHY FIORANO?  ARCHITECTURAL FIT The agency’s existing infrastructure required extensive communication over JMS. The Fiorano SOA platform, with an embedded peer-to-peer JMS implementation was a natural fit in their environment. The Fiorano platform does not require a separate / third party JMS server for message brokering.  COMPLETENESS OF THE POC IMPLEMENTATION Competing products lacked completeness and required several external tools, making the integration infrastructure very complex to maintain. Fiorano completed the POC requirement with no solution compromise well ahead of time.  FIORANO SUPPORT Highly responsive support from Fiorano was a significant plus

BENEFITS WITH FIORANO SOA PLATFORM  TRANSACTIONAL VISIBILITY One comprehensive view of the entire system from a central location.  MAXIMUM SCALABILITY The unique peer-to-peer architecture offered maximum scalability and optimized usage of hardware resources, allowing the agency to extend services to newer locations in a phased manner.  SIGNIFICANTLY REDUCED DEVELOPMENT TIME Intuitive Tools and comprehensive set of pre-built components Ability to easily debug the flow of distributed events across multiple service components Ability to adapt to change dynamically  OPEN SYSTEM ARCHITECTURE To realize the full benefits of new technologies and ensure adaptability to future needs.

THANK YOU! VISIT