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

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 email 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 email 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 WWW.FIORANO.COM