Message Broker Use Cases

1. Attachment B Message Broker Use Cases 16 January 2006

2. Background • These Use Cases attempt to depict “typical” integration patterns. • Many variations of these patterns are in use. No attempt has been made to capture all variations • Use Case Summary: • Use Case 1: Demonstrates a fan out requirements using MQ at the source and target • Use Case 2: Demonstrates a variation of the fan out requirement using Oracle AQ at the source and a database target. • Use Case 3: Demonstrates variation of the fan out requirement using a database source and a file target. • Use Case 4: Demonstrates a requirement to split a single input message into multiple output messages. Also demonstrates a file based source and MQ target. • Use Case 5: Demonstrates a synchronous (block/wait) requirement from the perspective of the source application. • Use Case 6: Demonstrates a synchronous (block/wait) requirement from the perspective of the broker. Also demonstrates the requirements for firewall traversal

3. Expectation of Supplier • Use Case 1 • Please perform as much of the development and implementation as possible during the technical session. • Obviously, some advance preparation is advisable to make sure things go smoothly and so we do not encounter any major technical snags. • However, we want to be sure you understand our goal is to understand the overall functionality and ease of use of your tools, more than merely demonstrating a final working solution • Refer to Attachment C for Use Case 1 technical specifications. • Use Cases 2 – 4 • For these use cases, please use Use Case 1 as a baseline, and then describe and demonstrate the unique components. • To optimize our time, pre-built components and short or partial demonstrations are acceptable. • Should be demonstrated or discussed during the Product Demonstration and Use Case portion of the agenda. • Use Cases 5 – 6 • For these use cases a discussion of the differences against the baseline of Use Case 1 is appropriate.

4. Use Case 1 – Fan Out Source Target App B MQ Q App A Broker App C MQ Q MQ Q App D DB MQ Q • Requirements: • Routing • Message originates in App A’s WebSphereMQ queue and is in XML format. • Message routed to App B target based on content of attribute (content based routing). • Message routed to App C and D unconditionally (context based routing). • Transformation / Augmentation / Interactions • Message routed to App B’s MQ Q in it’s original format. • Message routed to App C’s MQ Q in a flat file format (i.e. fixed width record). • Message routed to App D in a modified XML format. • A database query is performed to add (augment) data to the original message before it is delivered to the target.

5. Use Case 2 – Fan Out (JDBC Target) Source Target DB App B DB App A Broker AQ Q App C DB MQ Q • Requirements: • Routing • Message originates in App A’s Oracle Advanced Queue and is in flat file or XML format. • Message is routed to the target based on content of attribute (content based routing) or based on the source/type of message (context based routing). • Transformation / Augmentation / Interactions • SQL updates to multiple tables in App B’s Oracle database are made using SQL or PL/SQL. The SQL updates, associated with this single message, must be executed in a single unit of work. • Message routed to App C via MQ Q. • A database query is performed to add or modify (augment) the data in the original message before it is delivered to the target. • Messages should be sent to targets independent of each other (i.e. a failure in App B does not prevent a successful delivery to App C)

6. Use Case 3 – Fan-out (JDBC Source, File Target) Source Target File App B DB App A DB Broker App C MQ Q MQ Q • Requirements: • Routing • An App A business event causes information to be externalized to an event_table. App A is responsible for externalizing the event via “code” or DB triggers. • The event_table is polled, the needed information is extracted from the event_table and optionally App A tables. • The event_table is updated such that guaranteed once and only once delivery is provided. • Message is routed to target based on the content of attribute (content based routing) or based on the source/type of message (context based routing). • Transformation / Augmentation / Interactions • A database query is performed to add or modify (augment) the data in the original message before it is delivered to the target. • A file is delivered to App B’s file system. FTP may be required. • A message is routed to App C’s MQ Q in an XML or flat (fixed width record) format. • To facilitate efficient transport: • For flat or delimited messages: Multiple source messages are concatenated together (grouped), each separated by a new line, and delivered to the target as a single entity. • For XML messages: Multiple source messages are concatenated together (grouped), and wrapped by a root tag, and delivered to the target as a single entity. DB

7. Use Case 4 – Split Source Target File App B App A MQ Q Broker • Requirements: • Routing • Broker input originates in a file system on another server. • Broker FTPs the file to a local server from the external location. • Message is routed to target based on the content of attribute (content based routing) or based on the source/type of message (context based routing). • Originating file is moved, renamed or somehow modified to guarantee once and only once delivery. • Transformation / Augmentation / Interactions (situation 1) • Input is a single file consisting of multiple records. • Each record (line) in the file is delivered to the target as a separate MQ message. • Messages are routed to App B’s MQ Q in an XML format or modified flat file format (i.e. fixed width). • Transformation / Augmentation / Interactions (situation 2) • Input is a single file consisting of multiple records or elements that are preceded by a header block (e.g. Purchase Order header and Line Item details) • Each detail record is routed as an individual message to the target. The header information is included in each target message. (e.g. PO / Line Item in each message)

8. Use Case 5 – Request / Reply Source Target App B DB App A HTTPS Request Broker DB Reply • Requirements: • Routing • App A, during it’s processing, requires validation information from App B (User/Application A waits while validation occurs). • Broker accepts the request for service, initiates a request to target and returns response to source. • Transformation / Augmentation • Data is converted to format required by target. In this case, SQL or PL/SQL. • Interactions • A single source request may result in multiple target interactions (i.e. multiple sql calls). For example, a Purchase Order and Multiple Line Item rows may need to retrieved from the database (requiring multiple database SQL calls). • Broker correlates request with the reply. • Comments • Historically this type of integration has been done with SQL*Net or DB connectivity tools, bypassing a broker, with direct interaction between source and target.

9. Use Case 6 – Firewall Traversal + Broker as HTTP/S client Target Source HTTPS Request App A Broker WS Provider Reply MQ Q Firewalls • Requirements: • Routing • Message originates in App A’s WebSphereMQ Queue and is in XML format (optional formats are flat file, name/value pair or delimited). • Message is routed to target. • Transformation / Augmentation • Data is converted to format required by target. • Interactions • Broker accepts the request for service, initiates a request to target and receives response from target. • Comments • This use case demonstrates the: • need to bridge an asynchronous source with a synchronous target and to traverse firewalls. • broker acting as http client with firewall traversal (firewall traversal is optional). • ability to perform configurable firewall traversal (e.g. redirection and cookie setting)