Project Generali LifeAsia Integration
Architecture of MQSeries Environment
Page 1
Architecture of the MQSeries Environment
1.1
Requirements
There are two components that are communicating via MQSeries with each other:
MINSC Controller The MINSC Controller are IIS ASP applications running in the environment of an IBM
WebSphere Application Server.
LIFEASIA The LIFEASIA system are Smart 400 objects/SQL procedures running in an DB2 DBMS. The
MQSeries connection will be done through the IIS ASP of the DB2 DBMS.
MQSeries
MINSC
Controller
Send
- Datagrams
- Replies
- Requests
Receive
- Datagrams
- Replies
- Requests
LIFEASIA
Put
Put
Get
Get
Send
- Datagrams
- Replies
- Requests
Receive
- Replies
- Requests
- Datagrams
The MQSeries architecture must support the following scenarios:
Scenario 1 Synchronous Communication between MINSC Controller and LIFEASIA
The MINSC Controller should be able to send messages (requests) to LIFEASIA for requesting / sending
data and requesting actions via MQSeries. LIFEASIA should send a reply message to the MINSC
Controller with the requested data or the result of the action via MQSeries.
The MINSC Controller is waiting for the reply message from LIFEASIA.
Scenario 2 Asynchronous Communication between MINSC Controller and LIFEASIA
The MINSC Controller should be able to send messages (data grams) to LIFEASIA for sending data and
requesting actions (e.g. saving a quote) via MQSeries. There is no reply message expected.
Page 2
The following figure shows an overview of the scenarios.
MQSeries
1
MINSC
VOI
OPUSLA
Controller
2
The following issues must be considered:
It is possible that the MINSC Controller and LIFEASIA will be placed in different locations around the
country.
1.1.1 Message flow Scenario 1
Scenario 1 describes a synchronous communication between the MINSC Controller that starts the interaction
and the replying LIFEASIA system.
MINSC
VOI
Controller
Controller
MQSeriesSeries
MQ
MINSC
VOI Control
ler
Reply Queue queue
Reply
Msg. FormatterMsg
Formatter
Input Queue
Reply queue
Put Request Message
2
MQ
MQSeries
Series
LifeAsia
LifeAsia
InputOPUSqueue
Input Queue
Input
queue
Message
Formatter
Get
Request
Message
LifeAsia
OPUS
Format
Message
3
4
Put
Request
Message
Get
Request
Message
Do
Processing
6
7 Put Reply Message
Get
Reply
Message
Format
Message
9
11
Get
Reply
Message
10
Put Reply Message
This scenario requires the following steps:
Page 3
Generate
Reply Message
(1) The MINSC Controller puts a message of the message type REQUEST on the Input Queue of the
MQSeries Integrator. The MINSC Controller adds the name of the queue that should contain the reply
to the header of the request message. The MQSeries Queue Manager is generating a unique message
identifier for this message. This message identifier is saved by the MINSC Controller to identify the
specific reply.
The sending queue can be a local or remote queue for the Queue Manager of the MINSC Controller.
(2) The Message Formatter is listening on its Input Queue and waiting for messages. If a message arrives
on the queue, the Message Formatter gets the message and takes it from the queue.
This Input Queue must be a local queue for the Queue Manager of the Message Formatter.
(3) The Message Formatter determines what type of message was received (e.g. Obtain a quote, Accept a
Quote) and is doing the necessary processing:
Transform the message format for the target system in this case the LIFEASIA system.
(4) The Message Formatter puts the adjusted message on the LIFEASIA Input Queue.
The sending queue can be a local or remote queue for the Queue Manager of the Message Formatter.
(5) The LIFEASIA system is listening on the LIFEASIA Input Queue and waiting for messages. If a
message is on the queue, LIFEASIA gets the message and takes it from the queue.
The LIFEASIA Input Queue must be a local queue for the Queue Manager of the LIFEASIA system.
(6) After processing the message, the LIFEASIA system generates a reply message. Therefore the unique
message identifier of the request message is reused for the reply message.
(7) The LIFEASIA system puts the generated reply message on the Message Formatter Input Queue.
The sending queue can be a local or remote queue for the Queue Manager of the LIFEASIA system.
(8) The Message Formatter is listening on its Input Queue and waiting for messages. If a message arrives
on the queue, the Message Formatter gets the message and takes it from the queue.
(9) The Message Formatter determines what type of message was received (e.g. Answer to Obtain a quote)
and is doing the necessary processing:
Transform the message format for the target system in this case for the MINSC Controller.
(10) The Message Formatter puts the adjusted reply message on the Reply Queue of the MINSC Controller.
The MINSC Controller Reply Queue can be a local or remote queue for the Queue Manager of the
Message Formatter.
(11) The MINSC Controller is listening on its Reply Queue and waiting for the specific reply message. The
message identifier of that reply message must match the message identifier of the request message.
The MINSC Controller Reply Queue must be a local queue for the Queue Manager of the MINSC
Controller.
Page 4
1.1.2 Message Flow Scenario 2
Scenario 2 describes an asynchronous communication between the MINSC Controller and the LIFEASIA
system.
MINSC
VOI
Controller
Controller
MQSeriesSeries
MQ
MINSC
Reply queue
MQ
MQSeries
Series
Msg. FormatterMsg
Formatter
Input Queue
Reply queue
Put Datagram Message
2
LifeAsia
OPUS
Input
Input Queue
queue
Message
Formatter
Get
Datagram
Message
LifeAsia
OPUS
Format
Message
3
4
Put
Datagram
Message
Get
Datagram
Message
Do
Processing
6
This scenario requires the following steps:
(1) The MINSC Controller puts a message of the message type DATAGRAM on the Input Queue of the
MQSeries Integrator. The MQSeries Queue Manager is generating a unique message identifier for this
message.
The sending queue can be a local or remote queue for the Queue Manager of the MINSC Controller.
(2) The Message Formatter is listening on its Input Queue and waiting for messages. If a message arrives
on the queue, the Message Formatter gets the message and takes it from the queue.
This Input Queue must be a local queue for the Queue Manager of the Message Formatter.
(3) The Message Formatter determines what type of message was received (e.g. Obtain a quote, Accept a
Quote) and is doing the necessary processing:
Transform the message format for the target system in this case the LIFEASIA system.
(4) The Message Formatter puts the adjusted message on the LIFEASIA Input Queue.
The sending queue can be a local or remote queue for the Queue Manager of the Message Formatter.
(5) The LIFEASIA system is listening on the LIFEASIA Input Queue and waiting for messages. If a
message is on the queue, LIFEASIA gets the message and takes it from the queue.
The LIFEASIA Input Queue must be a local queue for the Queue Manager of the LIFEASIA system.
(6) The LIFEASIA system generates no reply message after processing the message.
Page 5
1.2
Architecture Overview
The architecture is based on the scenarios described before. Each component (MINSC Controller and
LIFEASIA) needs receiving queues, which must be a local queue for the Queue Manager of the component and
sending queues, which may be local or remote queues.
LIFEASIA
MINSC Controller
Send to LIFEASIA
-- Requests
-- Datagrams
Receive
-- Replies
Put
Get
Receive
- Requests
- Datagrams
Put
Send to
MINSC Controller
-- Replies
Message
Formatter
Get
MQSeries
Queues for the MINSC Controller:
Receiving Queue must be a local queue for the Queue Manager of the MINSC Controller
o One Reply Queue for receiving reply messages from LIFEASIA
Sending Queue can be a local or remote queue for the Queue Manager of the MINSC Controller
o All messages (requests and datagrams) will be sent to the MINSC Controller specific Input
Queue of the Message Formatter.
Queues for the LIFEASIA system:
Receiving Queue must be a local queue for the Queue Manager of the LIFEASIA system
o One Input Queue for receiving request and datagram messages.
Sending Queue can be a local or remote queue for the Queue Manager of the LIFEASIA system
o All messages will be sent to the LIFEASIA specific Input Queue of the Message Formatter.
Queues for the Message Formatter:
Receiving Queues must be local queues for the Queue Manager of the Message Formatter.
o One Input Queue for receiving all kind of messages of the MINSC Controller.
o One Input Queue for receiving all kind of messages of the LIFEASIA system.
Sending Queues can be local or remote queues for the Queue Manager of the Message Formatter.
o One Output Queue for sending all reformatted messages to the MINSC Controller.
o One Output Queue for sending all reformatted messages to LIFEASIA.
Page 6
1.2.1.1 MQSeries Queues
Overview of the needed MQSeries Queues for the Queue Manager QVAU:
MINSC
Controller
MINSC.CONTROLLER.SEND.A01
MINSC.CONTROLLER.REPLY.A01
MINSC.MSGFORMAT.CONTROLLER.REQUEST.
Q01
MINSC.MSGFORMAT.CONTROLLER.REQUEST.
A01
MINSC.CONTROLLER.REPLY.Q01
MINSC.MSGFORMAT.CONTROLLER.SEND.A01
Message Formatter
MINSC.MSGFORMAT.LIFEASIA.SEND.A01
MINSC.MSGFORMAT.LIFEASIA.REPLY.A01
MINSC.LIFEASIA.REQUEST.Q01
MINSC.MSGFORMAT.LIFEASIA.REPLY.Q01
MINSC.LIFEASIA.REQUEST.A01
MINSC.LIFEASIA.SEND.A01
LIFEASIA
Local Queue
Alias Queue
Local Queues
Local Queues (Queue Type = LOCAL) for Queue Manager QVAU:
Queue Name
Queue
Description
Type
SYSTEM.DEAD.LETTER.QUEUE
LOCAL
Dead Letter Queue
MINSC.CONTROLLER.REPLY.Q01
LOCAL
MINSC Controller Queue for receiving reply messages
MINSC.LIFEASIA.REQUEST.Q01
LOCAL
LIFEASIA Queue for receiving datagram and request
messages
MINSC.MSGFORMAT.CONTROLLER.REQUEST.Q01
LOCAL
Message Formatter Input Queue for receiving request
and datagram messages from the MINSC Controller
MINSC.MSGFORMAT.LIFEASIA.REPLY.Q01
LOCAL
Message Formatter Input Queue for receiving reply
messages from LIFEASIA
Inh. Get Inhibit Get Operations (Y=Yes; N=No)
Inh. Put Inhibit Put Operations (Y=Yes; N=No)
Def. Prio. Default Priority (0 to 9 max. priority)
Def. Pers. Default Persistence (P=Persistent; NP=Non Persistent)
Page 7
Inh.
Get
Inh.
Put
Def.
Prio
Def.
Pers
NP
NP
NP
NP
Alias Queues
Alias Queues (Queue Type = ALIAS) for Queue Manager QVAU:
Alias Queue Name
Base Queue Name
Description
MINSC.CONTROLLER.REPLY.A01
MINSC.CONTROLLER.REPLY.Q01
MINSC.CONTROLLER.SEND.A01
MINSC.MSGFORMAT.CONTROLL
ER.REQUEST.Q01
MINSC.LIFEASIA.REQUEST.A01
MINSC.LIFEASIA.REQUEST.Q01
Inh.
Get
Inh.
Put
Def.
Prio
Def.
Pers
MINSC Controller Queue
for receiving replies
NP
MINSC Controller Queue
for sending datagram and
request messages
NP
LIFEASIA Queue for
receiving datagram and
request messages
NP
NP
NP
NP
NP
NP
MINSC.LIFEASIA.SEND.A01
MINSC.MSGFORMAT.LIFEASIA.R
LIFEASIA Queue for
EPLY.Q01
sending reply messages
MINSC.MSGFORMAT.CONTROLLER.REQUEST.A01
MINSC.MSGFORMAT.CONTROLL
Message Formatter Queue
ER.REQUEST.Q01
for receiving messages
from the MINSC
Controller
MINSC.MSGFORMAT.CONTROLLER.SEND.A01
MINSC.CONTROLLER.REPLY.Q01 Message Formatter Queue
for sending messages to the
MINSC Controller
MINSC.MSGFORMAT.LIFEASIA.REPLY.A01
MINSC.MSGFORMAT.LIFEASIA.R
Message Formatter Queue
EPLY.Q01
for receiving messages
from LIFEASIA
MINSC.MSGFORMAT.LIFEASIA.SEND.A01
MINSC.LIFEASIA.REQUEST.Q01
Message Formatter Queue
for sending messages to
LIFEASIA
Inh. Get Inhibit Get Operations (Y=Yes; N=No)
Inh. Put Inhibit Put Operations (Y=Yes; N=No)
Def. Prio. Default Priority (0 to 9 max. priority)
Def. Pers. Default Persistence (P=Persistent; NP=Non Persistent)
1.2.2 MQSeries IIS ASP Framework
In the MQSeries IIS ASP Framework for the MINSC Controller one communication service will be defined:
(1) A communication service for sending datagram and requests messages and receiving the specific reply
messages. Therefore this communication service consists of the following two queues:
Page 8
Sending messages
Queue Name
MINSC.CONTROLLER.SEND.A01
Receiving messages
MINSC.CONTROLLER.REPLY.A01
Description
Sending datagram and request
messages to LIFEASIA via the
Message Formatter
Receiving reply messages from
LIFEASIA via the Message
Formatter
Page 9
Message Design
2.1
System Overview Diagram
Message Formatter
2.2
MINSC
Life Asia
VOI Controll
er
Controller
Obtain a Quote
OPUS
MSG1
yyy
Accept a Quote
yyy
to
LogLogon
on to My
Allianz
system
yyy
Payment Change
yyy
Payment for Buy
and Renewal
yyy
Change Policy
Profile and Policy
Information
yyy
Renewal
Customer
yyy
Process and Message Details
2.2.1 Process Relationship Table
Upstream and Downstream Processes This is an attribute of a relationship between processes, rather than of
processes themselves, but it is a piece of terminology, which it is convenient to define here. An upstream process
is one that sends messages to a downstream process, directly or indirectly. The words therefore describe the
relationship between two processes in terms of time sequence.
Upstream process
Obtain a Quote
Downstream process
xxx
Message name
MSG1
2.2.2 Process Attribute Summary
This section defines the following attributes of a process.
Repeatable and non-Repeatable Processes
The simplest example of a repeatable process is an inquiry. If the response does not come back in a
reasonable time, the user is quite likely to think that it got lost some-where, and to ask again. This may
not be good for system capacity, but is quite innocent as far as data integrity is concerned.
Page 10
The natural inference from this is that update processes are not repeatable. However, in many common
business processes, they can be (what damage does it do to the data base if the customer's change of
address is processed twice, because it was not clear whether the first one arrived?) By contrast, a
deduct 100:00 from customer balance message will do damage if it is presented twice (an add
100:00 message done twice might please the customer, but clearly won't please your share-holders).
Updating and non-Updating Processes
An update process is one that makes a permanent change at the same time as it sends/receives a
message.
Any update process that may subsequently be rejected by a later process indicates the need for a
compensating or back-out process to restore the prior situation.
Visible and Invisible Processes
A visible process is one that makes updates that can be seen subsequently and unambiguously. For
instance, a process that causes a record to be created containing the details of the action performed (e.g.
deduct 100), the date and time, and the UserID of the person responsible, could be considered a
visible process.
One that simply updates the balance in the customer record could not be normally considered visible:
even if the process stored the date/time and UserID of the latest updater, you would not really be able to
see whether another update had happened microseconds after yours had been committed, or whether
it happened just prior, and yours didn't take.
This attribute has implications on the design of the database, or possibly the Workflow Manager script,
to ensure that this level of information is maintained in a readily accessible form (and not on yesterday's
database Log).
Revocable and Irrevocable Processes
A process can be considered revocable if it is possible to back out its effects without impact on the
world outside. If it is not possible to back out its effects, then the process can be termed irrevocable.
This categorization is by no means confined to computerized processes.
This can be contrasted with the attribute of update described above. A process is updating if it can be
backed out by a compensating transaction. It is irrevocable. if it represents a change to the state of
the real world that cannot be reversed.
Compliant and non-Compliant Processes
A compliant process is one that accepts whatever messages are sent to it and accepts them. A noncompliant process is one that may reject a message. For instance, in a system where orders are filled
directly out of stock, an order entry reserve stock process might send an out of stock response to a
previous process. In a system where orders are taken even if stock is not immediately available, the
reserve stock process would always comply with the message.
Split and non-Split Processes
Also can be termed Fan-out and non-fan-out processes. The term Split is used to describe a process that
PUTs more than one message, in particular to more than one destination. It is important to be able to
identify such processes easily, since the analysis of the subsequent flows in terms of revocability and
compliance as defined above become significantly more complex.
Join and non-Join Processes
Also can be termed Fan-in and non-fan-in processes. The term Join describes a process that requires
more than one reply message in order to be able to perform its function. It is useful to identify these
processes because they require special treatment in the design of the triggering mechanisms involved,
especially in high volume systems where extensive use of the option to browse the queue for a related
set of messages is not viable. In practically all such cases, the process will need to be decomposed into
more primitive processes.
Page 11
Process name
Obtain a Quote
xxx
Rpt
Y
Updt
N
Vis
Rvc
Key Rpt = Repeatable: Updt = Updateable: Vis = Visible:
Rvc = revocable: Compl = Compliant
Page 12
Compl
Process notes
2.2.2.1 XXX - Process Detail Form
Process name
Business Owner
IT Owner
Downstream from
Upstream of
Description
Obtain a Quote
Date last updated
Biz User 1
IT User 1
NONE
Xxx
This process takes the data provided by the user / customer and requests a quote
for the unit link.
Queue Manager
QVAU
Client Subsystem
IIS ASP client
Attributes (Y=YES, N=NO, I=Inherited, N/A=Not applicable)
Attribute
Status
Notes
Repeatable
Y
Updating
N
Visible
N
Revocable
Y
Compliant
N/A
Split
N
Join
N
2.2.3 Message Attributes Analysis
For each message the following attributes are analyzed:
Reply-Wanted and no-Reply-Wanted Messages
A reply-wanted message is one that expects real information (not just a positive response) sent back to
the originator, or on to another process. A no-reply wanted message is one that is strictly for
information only.
Persistent and non-Persistent Messages
This terminology is secure and a recognized part of the MQ vocabulary. A persistent message is one
which is logged during its progress through the queue system, so that it can be re-created in case of
failure of the Queue Manager system, the processor system as a whole, or the application system or
program that was processing it.
Synchronized and un-Synchronized Messages
This attribute reflects the way the message is sent to its ultimate destination. For the designer, it is
important to be aware of which messages have been sent in a way that implies that a process is waiting,
either at its destination for it to arrive or at the point of origin for the response to return. This attribute
can be one that is propagated through several links, probably right round the message loop.
Local or Remote Messages
This attribute reflects the message path the message is sent. A remote message path involves
transmission through a network, or at least to another Queue Manager. A local message path is one that
never leaves its own Queue Manager.
Message name
MSG1
Page 13
Reply
wanted
Y
Pers
Synch
Remote
Comments
