Download Highlevel Use Case - La Salle University

Attachment B
Message Broker Use Cases
16 January 2006
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
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.
Use Case 1 – Fan Out
Source
App B
Target
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.
Use Case 2 – Fan Out (JDBC Target)
Source
Target
DB
App A
App B
DB
Broker
AQ Q
App C
DB
Requirements:
MQ Q
• 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)
Use Case 3 – Fan-out (JDBC Source, File Target)
Source
File
App A
DB
Broker
App B
DB
Target
App C
MQ Q
Requirements:
• Routing
DB
• 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.
Use Case 4 – Split
Source
Target
App A
File
Broker
App B
MQ Q
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)
Use Case 5 – Request / Reply
Source
Target
App A
App B
DB
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.
Use Case 6 – Firewall Traversal + Broker as HTTP/S client
Target
Source
HTTPS Request
App A
Broker
MQ Q
WS Provider
Reply
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)