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