Lecture 3

Evolution of SI, Messaging

Source: Course Book, chapter 6 + complementing material

Systemintegration av IT-baserade affärsystem

SYSTINT
Jelena Zdravkovic
 Goal of the Lecture
To:

 describe message-oriented integration.

 explain the pattern-based solutions for message integration.

 Content
 Messaging
o Overview
o How/Process
o Elements
 Pattern-based message integration
 Overview
 Although providing a number of benefits, Distributed Objects and RPC
have not addressed two important aspects of integration:

o Both RPC and DO have employed a synchronous interaction between the

integrated applications. This means the client application is blocked from
doing further work until the server application completes its work and
returns control to the client application*.

o RPC and DO based-communication were not designed to be reliable in the

sense to guarantee that the input messages and return values will be
delivered to the intended destinations. Thus, the client application may
experience a “hung-up”.

*a benefit: supports real-time integration

 Overview
 Asynchronous messaging* integration overcomes these two major
problems.

 In this method, client application sends a message to the

destination application but does not wait for the response to
continue its work. In this way a higher degree of decoupling and
thereby scalability (high transaction volumes) is supported.

*A client sends a request, but does not wait for the answer.
Hence, the request does not have to be processed immediately.
 How Messaging Works?
 In messaging, applications do not communicate with each other
directly and do not have a dedicated communication link established
between them - they communicate indirectly through a queue.

Application A queue Application B

 A queue (channel) behaves as a collection of messages that can be

shared across multiple systems (applications).

 Application A sends a message to the queue. After, application B

retrieves the message from the queue.
 How Messaging Works? Cont.
 As with DO, in messaging the code for the communication and
marshalling is placed in a separate software component.
 This component is called Message-Oriented Middleware* (MOM).
Application A Application B
create process

send read

MOM transfer/delivery MOM

network

 An administrator configures MOM with the channels that define the

paths of communication between the applications. The messaging
system then coordinates and manages the sending and receiving of
messages. The main task is to move messages in a reliable fashion.
*A middleware (sve. ”mellanprogramvara”) is a software that enables communication between
distributed applications; it provides services to software applications beyond those available
from their operating systems. It can be described as "software glue“ or “broker”.
 Process in Details
1. Application A (Sender) creates a message and populates it with data
2. The message is sent (“send&forget”) to the queue (MOM)
3. MOM delivers (store&forward) the message to Application B
(Receiver)
4. Application B receives the message from its MOM;
5. Application B processes the message.

Application A Application B
create process

send read

MOM transfer/delivery MOM

network
Elements
 Main elements of a messaging system are:
o Queues (channels)
o Messages
o End-points (Sender, Receiver)
 Elements - Message
 A message consists of a header and a body.
o The header contains meta-information about the message—who
sent it, where it is going, date/time, etc.; this information is used
by the messaging system (MOM) and is mostly ignored by the
applications using the messages.
o The body contains the data being transmitted and is ignored by
the messaging system; the body is used by receiver’s
application. It can be interpreted simply as data, or as the
description of a command to be invoked on the receiver.
 Common message types:
o Text Message: most common, the body is a string like a literal text, or an XML
document. Example SOAP/XML message.
o Object Message: the body is a single object, like a Java object.
o Bytes Message: the body is a byte array.
 Elements – End Point
 End-points (Sender/Producer, Receiver/Consumer) is the part (code)
of the sending/receiving application that is to connect to the
messaging system and to send or receive a message. The rest of
the application uses the end points whenever it needs to send or
receive a message.
 Both the Sender and Receiver need the API of the messaging
system (middleware) to be able to:
o Connect to the MOM
o Look up to a (desired) queue*
o Connect to a queue
o Send/receive a message to/from the queue
o Close the connection
 Content
 Messaging
o Overview
o How/Process
o Elements
 Pattern-based message integration
 About Patterns
 The goal of patterns is to help to make decisions that lead to a good
solution for a specific problem.

“When you face this problem, apply this solution”

 In IS engineering, a pattern is a is a general reusable solution to a

commonly occurring problem within a given context (analysis, testing,
development/programming, integration, etc.)

 Pattern description should follow a consistent format:

o Name, Problem, Motivation, Solution (text/diagrams/example), Related
Patterns, and other (such as “Consequences”, “Code”, etc).
 Example: Patterns for Programming
 Name: Strategy

 Problem: How to design for varying, but related, algorithms or policies? How to
design for the ability to change these algorithms or policies?

 Solution: Define each algorithm/policy (strategy) in a separate class, with a

common interface.

 Consequences: “lighter” and less dependent responsibilities of classes.

getTotal()
{
return pricingStrategy.getTotal(this)
}

<<Interface>>
Sale
ISalePricingStrategy

getTotal() : Double
getTotal(s : Sale) : Double

PercentDiscount ThresholdDiscount

getTotal(s : Sale) : Double getTotal(s : Sale) : Double

 Patterns for System Integration
 System integration spans many problem domains and levels of
abstraction.

 Therefore it has made sense to classify solutions in the form of

patterns.

 It also helps to

o understand the solutions better (i.e. through pattern’s formatting), and

o standardize the offers of different SI tools/vendors.

 Patterns for Messaging
 Core integration pattern types for messaging:

1. Message routing patterns – discuss different mechanisms to direct

messages from a sender to the correct receiver.

2. Message transformation patterns – change the content of the message

due to different needs of the sender and the receiver applications. The
existing data may be removed, or changed, or replaced, or new data
may be added.

3. Message management patterns – they facilitate complex messaging

systems running by dealing with error conditions, performance
bottlenecks, etc.

More than 50 messaging patterns are documented!

 1. Content-based Router
 Problem: How to handle a situation in which business data (or
function) is spread across multiple systems?

 Motivation: in many enterprise integration scenarios more than one

inventory system exists with each system being able to handle only
specific items.

 Solution: Use a Content-based Router to route each message to

the correct message recipient based on the message’s content.

 Related patterns: “Pipes and Filters”, “Sequencer”, “Aggregator”…

 1. Content-based Router
 Example: a company is selling widgets and gadgets and has two
inventory systems, one for widgets and one for gadgets. Each item
is identified by a unique item number including its type. When the
company receives an order, it needs to decide which inventory
system to pass the order to based on the type of item ordered.
 2. Content Enricher
 Problem: How do we communicate with another system if the message
originator does not have all the required data available?

 Motivation: when sending messages from one system to another it is

common for the target system to require more information than the
source system can provide.

 Solution: use Content Enricher to add data (computation / environment

/ another system) in order to augment a message with missing
information.

 Related patterns: “Content Filter”, etc.

 2. Content Enricher
 Example: a hospital scheduling system publishes messages missing a
content necessary for the accounting system…
 2. Content Enricher
 …Content Enricher is inserted to retrieve the additional data from the
customer care system. This way, the scheduling system is decoupled
from having to deal with insurance information or the customer care
system. All it has to do is publish the “Doctor Visit” message. The
Content Enricher component takes care of retrieving the required data.
The accounting system also remains independent from the customer
care system.
 3. Message History
 Problem: How can we effectively analyze and debug the flow of
messages in a loosely coupled system?

 Motivation: message recipient generally does not know nor care which
application put the message on the channel. If we do not know which
application published a message it is difficult to correct a problem with
the message.

 Solution: attach a Message History to the message, listing all

applications that the message passed through since its origination.

 Related patterns: “Control Bus”, “Message Header”, “Test message”…

 3. Message History
 Example: The Message History maintains a list of all components
that the message passed through. Every system that processes the
message (including the originator) adds one entry to the list. The
Message History is a part of the message header.
 Conclusion
 Reliability: MOM can guarantee the delivery of a message to the
destination system by persisting the message and continuously trying
to complete the delivery.

 Loose-coupling: MOM also solves the problem of integrating the

applications designed to run disconnected from the network.

 Scalability: Due to a high decoupling of the source and destination

applications, there is no problem of overloading the receiver. MOM
delivers messages to the destination when it can process them. The
sender is unaffected, because the messaging is asynchronous.
 Conclusion
 In spite of the mentioned benefits, “messaging” is not suitable
in all situations:

o MOMs need to be understood, learnt; or developed.

o Not the best choice when synchronous communication is

desired.

o As with DO, the used middleware decreases the overall

reliability of the integration between applications.
To Answer

What are the

How main elements
messaging What is of messaging?
works? MOM?

What are Example(s) of

patterns, and messaging
what is their patterns?
role in SI?
Questions?
Tasks for the next session…