mom middle ware v1.0

8/4/2019 MOM Middle Ware v1.0

1/14

BanXis Middleware

Version 1.0


2/14

Architecture 1.1

STATEMENT OFCOPYRIGHT

BanXis 2007. All rights reserved

All products names, company names or trade marks mentioned in thisdocument remain the property of their respective owners, no part of thisdocument may be reproduced in any form with permission from BanXis.

STATEMENT OF CONFIDENTALITY

The recipient of this document agrees to keep this document

confidential and not to use its content in any form or by means withoutpermission from BanXis. Moreover, the recipient agrees not to placethis document at the disposal of any third party without permission fromBanXis. If such permission is granted, it will be subject to the conditionthat the recipient ensures that any third party recipient of thisdocument, or of information contained therein, is held responsible toBanXis for the confidentiality of that document or information.

TRADE MARKS

All the trade marks used in this document remain the property of theirrightful owners.

Version 1.0 | 2007 BanXis | All Rights Reserved |Page 2 of 14 | Confidential


3/14

Architecture 1.1

DISCLAIMER

Although BanXis takes great care to ensure the accuracy and quality ofthe materials, all materials is provide without any warranty whatsoever,including, but not limited to, the implied warranties of merchantabilityor fitness for a particular purpose.

TRADEMARK NOTICES

All product names and services identified throughout this document aretrademarks or registered trade marks of their respective companies. The

product names and services are used throughout this document ineditorial fashion only and for the benefit of such companies. No suchuse, or the use of any trade name, is intended to convey endorsement orother affiliation with the document.

BanXis 2006. All rights reserved. This publication, or any part thereof,may not be reproduced or transmitted in any form or by nay means,electronic or mechanical, including photocopying, recording, storage inan information retrieval system, or otherwise, without the prior writtenpermission of BanXis.

INTENDED AUDIENCE

The target audience is all the technical members of the organization.This includes all the information needed by the technical team toenhance or upgrade this system.

SCOPE

This document defines BanXis components and discusses the creation of

BanXis components. The BanXis architecture compatibility withexisting Technologies is also addressed.



4/14

Architecture 1.1

TABLE OF CONTENT

1. MIDDLEWARE........................................................................................................................................5

1. MIDDLEWARE........................................................................................................................................5

1. MESSAGE ORIENTED MIDDLEWARE ............................................................................................6

2. MARKET ................................................................................................................................................. .9

2. MARKET ................................................................................................................................................. .9



5/14

Architecture 1.1

1. MiddlewareMany definitions of middleware exist in literature. For example,

Basically any type of software that facilitates communications between two or more

software systems

Software that makes it possible in practice to build distributed applications

The definitions are kept broad by both authors because of the various different

types of middleware available nowadays. The communication provided by the

middleware can be done in many ways, but it is clear that application designers

profit from the availability of middleware. Since applications depend more on inter

application communication at present compared to applications in the past.

Hence, the purpose of middleware is to provide a platform for applications to

exchange information. A platform abstracts from lower level programming issues by

providing a common interface to programs working on top of the platform.

Middleware provides in a need for a higher level of abstraction for communication

between applications.

Enterprises are often confronted with the growing need to exchange

information between applications. A network is a common instrument to achieve

this. TCP/IP networks are a very common platform for communication. When TCP/IP

is used as a communications platform by applications there still remain extra tasks to

be handled by the applications, tasks that are not part of the core functionality of

applications.

For example, for an application to exchange information with another application, it has

to:

Discover the other application,

Connect and negotiate the used protocol,

Encode the information and handle of error conditions.

These tasks, not being part of the applications functionality, are

commonly implemented using the services offered by TCP or UDP interfaces. The

applications use simple direct TCP or UDP connections to other applications. The

language protocol to use over the TCP stream is often predefined. The information

needed to connect is stored locally. Failures errors meant that the information

exchange had to be aborted. A common runtime error is failure to establish the



6/14

Architecture 1.1

connection.

The drive for developing middleware comes from the common set of extra tasks that

needs to be implemented while achieving enhanced communication

between applications. Those tasks are not part of the applications functionality and

thus not interesting to implement within those applications. Middleware is

implemented as a separate layer between the application and the network interface,

thus providing a new platform that facilitates the interaction between

applications. How this functionality is provided to the application by the

middleware layer differs for each middleware implementation. The underlying

concepts of middleware implementations are often different. This gives a number

of different dimensions to classify middleware.

Each middleware type mentioned aims at certain situations. Linthicum recognizes the

following types of middleware:

Remote Procedure Call (RPC)

Message-Oriented

Distributed Objects

Database-Oriented

Transaction-Oriented

TP Monitors

Application Servers

Message Brokers

1. Message Oriented Middleware

This type of middleware uses the concept of messages to communicate. In the

remainder of this thesis middleware refers to message-oriented middleware.

The communication provided by message-oriented middleware is asynchronous and

decoupled, providing independence among the interacting applications. One software

system, or application, can send a message without waiting for a direct response or

confirmation, thus it can move on, which is also known as non-blocking

communication. In contrast RPC middleware resembles a function call in a program,

but realized on a function that may execute on another computer node. The



7/14

Architecture 1.1

advantage of RPC is that it fits in procedural programming paradigm.

The calling program, however, has to wait until the called function returns. This

possibly takes a long time considering the extra work needed to complete the

request across the network.

The message transport system is the core of a message-oriented middleware

implementation. The transport is provided through the concept of message channels.

The applications use a programming interface or an adapter to utilize the middleware

channels. Applications send a message to a channel and applications listen to

a channel. The channels are also referred to as topics or subjects. The sending

applications are referred to as publishers and receiving applications as subscribers or

consumers. The terminology may differ for each product implemented by the

middleware suppliers.

The messaging system holds a message if it is not possible to deliver the message to a

consumer immediately. This situation occurs, for example, if the network is temporarily

down or the consumer is overloaded. Depending on the implementation, the messaging

system offers different levels of reliability for each channel. The highest level of

reliability is the transactional message channel.

A channel can be used for different forms of communication, depending on

the number of publishers and consumers connected to the channel, or the type

of messages on the channel. It is not necessary for the consumers on a

channel to immediately consume a message.

Point-to-point channel

A point-to-point channel has one sender and one consumer. The channel is

used to buffer the message flow between them. The benefit of buffering the

messages is that the consumer can be unavailable for a short moment.

Publish and Subscribe channel

A publish and subscribe channel has an undefined number of senders,called publishers, and consumers, called subscribers. Possibly there is one

publisher and many subscribers, or vice versa. Many-to-many are also possible.

A publisher posts a message on a channel. The message is received by all subscribed

consumers. The publisher is not aware of the number or location of subscribed

consumers, since it only posts messages on the channel. This opens up possibilities,



8/14

Architecture 1.1

such as for example; load balancing, redundancy, testing and monitoring.

Data type channel

In a data type channel only messages of a certain type are sent. Using

different channels for different kind of messages allows the consumer to

differentiate between the message types. This is most useful for messages

that do not contain self- description. However, another application of data

type channels is to assign different levels of reliability.

Message

Unlike object-oriented middleware, message-oriented middleware is not

concerned have with message content. Message-oriented middleware does

not have to understand the message content in order to function. In the past

responsibility of valid content lay with the applications. At present message

transformation and validation is often done at the middleware layer. This

enforces uniform data formats in the enterprise network.



9/14

Architecture 1.1

2. MarketThe cost of developing middleware for enterprise applications is high. The

middleware system is a complex distributed system connecting applications

throughout the enterprise. This requires the middleware system to be flexible, scalable

and robust.

It is important for an enterprise to quickly integrate a new application into the rest of

the enterprise system. Existing software middleware products are already prepared to

connect many kinds of applications. In many cases, however, the interface from the

legacy application to the middleware must be developed. Most vendors include an SDK

for their messaging system to allow customers to develop software that interacts

directly with the messaging system and thus with all components connected to thatmiddleware. Adapters are separate programs which connect to a wide variety of

applications.

The high cost of in-house development and the readiness and adaptability of off-the- shelf

middleware products are reasons why enterprises choose to use existing off- the-shelf

middleware suite instead of implementing middleware themselves. There are many

suppliers that offer a Message-Oriented Middleware solution. An overview table is given

of the major suppliers in the Message-Oriented Middleware market. There is a lot of

movement in this market. Products, and their names, change frequently; therefore

this is not a complete list. These products are based on the different techniques and

concepts discussed above.

Product name Supplier Products focuses on

TIBCO Rendevous TIBCO Pub/Sub

WebsphereMQ IBM Point-to-point

SonicMQ Sonic Pub/Sub

MSMQ Microsoft Point-to-point

iWay ESB iWay Software Adapters

Table 1: Message-Oriented Middleware suppliers

Table 1 is derived from various sources and is indicative because of the rapidly

changing suppliers and their products.

Each product is built using a particular technology for the transport of messages. The

message transport handles the routing and integrity of the messages. The message



10/14

Architecture 1.1

headers added by the messaging transport system to the payload provided by the

application are implementation specific and not compatible between different

vendors. The messaging transport systems depend on standard network protocols to

transport the messages. Apart from TCP, UDP broadcast or IP multi cast are often used

vendors. The choice for a certain transport infrastructure makes an

implementation suitable for different messaging concepts. The messaging system is not

concerned with the message payload and can be application specific. However message-

oriented middleware is broader than message transport.

Although message transport is the core of message-oriented middleware, other

functions are becoming more important. Middleware suppliers offer a range of

products often packaged as a suite. Four categories of products are recognized:

message transport, adapters, transformation and supporting tools. Not all suppliers offerthe complete package.

The term Enterprise Service Bus (ESB) is coined by vendors to denote a message-

oriented middleware system including the mapping and data transformation capabilities.

Data transformation is a crucial functionality of middleware. Two systems might

exchange messages, if they talk a different language this data exchange will be of no use.

There are a number of possibilities where the transformation of data should take

place, but common EAI practice is to not modify enterprise applications running on top of

middleware.

For the messaging system to be useful it must not only transport messages, but it must

connect to databases, applications and other middleware products to be able to receive

and deliver the messages from the publishers to the consumers. Adapters are therefore

very important, since they connect (adapt) all kinds of software products to the

middleware system allowing information to flow.

Middleware products also come with design tools that aid a designer in developing parts of

the system. These tools are often graphical or point-and-click oriented. Tools for

managing and monitoring middleware systems are also becoming more common, but are

usually specifically for one product. However, vendors are slowly adopting standards. For

example eclipse as the design tool runtime platform.

The standards are emerging slowly in this market. Standards are necessary for the market

to mature, providing better flexibility and interconnection between products. This is not

only true for message transport or the message structure itself, but also in the



11/14

Architecture 1.1

development and support processes of these systems, which is a crucial issue in this area.

Standardization efforts in the design process make it possible to compare designs

intended to be implemented with different products.

The J2EE platform contains JMS, which is an open standard for messaging in Java. JMS

relies on a central message broker and JMS clients which communicate through TCP with

the message broker. JMS is implemented in many commercial products. JMS does not

specify the message broker, only the client interface. The client interface is

compatible among different vendors making client application development independent

of vendor message broker. JMS is an example of a standard that improves the market in

terms of compatibility among JMS clients and reducing vendor lock-in.

Java Business Integration (JBI) is a specification for implementing service-oriented

architecture. JBI provides containers in which service consumer or producer

components are hosted. The container decouples service components from the

platform the components are running on. The benefit of JBI is that service

components can be deployed on different service engine platforms.

Extensible Mark-up Language (XML) is being adopted as the message format for

representing data exchanged between applications, with XML schema or DTD for

describing the data structure. The separation of the syntax and data structure of xml

documents greatly improves their use. Standard xml parsers check xml documents for

correct syntax. Parsers can validate xml documents if they are given the data

structure in the form of a DTD or XML schema. Applications using XML technology are more

flexible in handling changing data structures. Middleware products work with XML and

XML schemas off-the-shelf.

Asynchronous communication

In the previous sections different aspects of message-oriented middleware is explained.

The message channel concepts, the implementation technologies and the market in

message-oriented middleware products.

Message-oriented middleware is based on the concept of asynchronous message channel.

The aim of an asynchronous message channel is to decouple the

communication between applications as much as possible. Two applications

communicating do not need to know which application receives the message or

where the message is sent to. An application only knows that is has to send a certain

message on a certain channel. Confirmation of received messages is possible although not



12/14

Architecture 1.1

mandatory. The benefit of asynchronous communication is that applications are not

tied to each other. This provides flexibility, scalability and robustness.

This decoupled nature, however, has a downside. IT-

professionals develop applications that send and receive messages through

channels. At deployment time, the channels at which applications subscribe or publish are

specified. The actual implementation of the channels and application in the

enterprise system does not necessarily reflect the business processes supported by

these applications and channels. It is difficult to trace back the intended relation

between two applications by inspecting the implemented system.

The middleware layer responsible for providing the channels infrastructure does not have

to reflect the network of application relations that the channels form. The

middleware can, and often does, use different methods to distribute the message

across the physical network.

The relation between applications is therefore lost. There is no direct connection

between two interacting applications. The overview of all the relations between

different applications is not explicitly represented and cannot be derived from the

middleware.



13/14

Architecture 1.1

Figure 2: New MOM Application added to an Enterprise System



14/14

Architecture 1.1

Practical issues

Message-oriented middleware is a powerful tool for integrating applications and creating

enterprise applications based upon applications. The flexibility of message- orientedmiddleware, however, has a downside.

At present practical issues cause difficulties in managing system. These issues are a side

effect of the nature of message-oriented middleware. These issues are:

The paradigm of Message-oriented middleware is to decouple communicating

applications, making it harder to acquire insight in the relations between these

applications.

Message-oriented middleware integrates existing, running, applications,

limiting design possibilities. This often leads to scenarios where running applications need to

be described in order to be integrated.

This results in a system that is difficult to manage for IT-professionals.


mom middle ware v1.0

Documents