Types of Middleware

RPC-Based
Systems

RPC is the most basic form of middleware. It is used as a foundation for all
other types of middleware.

TP Monitors

TP Monitors are the oldest and best-known form of middleware. They are
also the most reliable, best tested, and most stable technology in the EAI
arena. TP Monitors can be seen as RPC with transactional capabilities and are
classified into TP-lite and TP-heavy systems.

Object Brokers

A middleware platform that supports the use of RPC in object-oriented

languages; aka RMI.

Object Monitors TP Monitors extended with APIs in object-oriented languages.

MessageOriented
Middleware

A middleware system built around the model of asynchronous RPC and

persistent message queues. Tools are provided to create a number of
transactional, persistent queues and allow programs to manipulate both local
and remote queues.

Message
Brokers

A specialization of MOM systems that can transform and/or filter messages

as they move through message queues. They can also dynamically select
message recipients based on the content of a message.

Types of Middleware
Middleware like many other technology styles is evolving and these days it is hard to
differentiate between features that different middleware packages tend to employ. Big
middleware products like Biztalk connect systems in many ways and so blur the distinctions
between middleware types. What follows is a list of types of middleware that you will be able to
identify with in your favourite middleware applications.
RPC Middleware This type of middleware has been around for a good while and is probably
the easiest to understand middleware. They provide developers with the ability to invoke a
method with one application and have it execute on a remote program somewhere else. To the
calling program user, the fact that the method is being executed on another machine is hidden.
The problem with RPCs however is that they can carry a lot of processing overhead so perform
isnt the best. DCE (Distributed Computing Environment) is a well known type of RPC as it
provides a good collection of RPC services to deal with application integrity and security.

Message Orientated Middleware MOM was created to address some of the short coming that
came with using RPCs. At its core MOM is just queuing software that uses messages (byte sized
units of information) to move data between applications (like mail between mail clients). This
approach is loosely coupled, meaning that the communicating software doesnt need to know
much about the other. The big plus for using MOM is that it follows an async model unlike RPC
which is synchronous. The queue manager manages message delivery and neither the sending or
receiving applications are blocked in any way from continuing processes (as occurs with RPC).
The messages being sent via the message queue are essentially a structure (schema) and content
(data). With this model there is less of chance of data being lost when connections to applications
go down. MSMQ from Microsoft and MQ from IBM are both message orientated middleware.
Distributed Object Middleware Middleware? you say?. Indeed, distributed objects are
classified as middleware because they facilitate inter-application communication. They are also
mechanisms for application development for providing company wide method sharing.
Distributed objects are just small chunks of code that expose interfaces that other chunks of code
can call. Two of the well known distributed object models are COM and CORBA.
Application Servers Probably the fastest growing type of middleware the application server is
nothing new. Most application servers are deployed as web enabled middleware that process
transactions from web enabled clients. Application servers are also adopting the very latest
languages like Java and .NET to allow further integration with back end systems to occur. App
servers provide not only a way to share and process application logic but also connect
applications to back end resources such as ERP systems, databases and even old legacy
applications (like traditional mainframes).
Message Brokers Message brokers facilitate information movement between two or more
applications and can account for differences in application semantics and platforms. For this
reason message brokers have become the choice technology for Business To Business
integration. Message brokers are a more advanced MOM as they implement business rule
validation and advanced message routing. They are able to transform the structure and content of
messages as they are routed via some kind of transformation service. Biztalk is a message broker
based server application.
As new technologies emerge, the middleware arena becomes even more blurred. Application
development is becoming easier by the day and connecting systems is becoming far easier than it
used to be with the aid of technologies named above.

Broad Functions

Middleware functions can be divided into three main categories: application-specific, informationexchange and management and support middleware.
Application-specific middleware provides services for various classes of applications such as distributeddatabase services, distributed-data/object-transaction processing and specialized services for mobile
computing and multimedia.
Information-exchange middleware handles the exchange of information across a network. It's used for
tasks such as transferring data, issuing commands, receiving responses, checking status and resolving
deadlocks.
Management and support middleware is responsible for locating resources, communicating with servers,
handling security and failures and monitoring performance.
Specific Types of Middleware
The types of middleware include database middleware, application server middleware, message-oriented
middleware, transaction-processing monitors and Web middleware.
While all middleware performs communication functions, the type of middleware - or the combination of
products - that a company chooses will depend on exactly what information needs to be communicated.
Consider kitchen knives, for example. Several types of knives are available, but a diner wouldn't use a
butcher knife to cut medium-rare filet mignon.
So if access to a database is a top priority for a particular company, then database middleware is the way
to go. However, it's more likely that the company will use database software with other types of
middleware.
Database middleware only enables applications to communicate with one or more local or remote
databases. It doesn't transfer calls or objects. And while database-oriented middleware is easy to deploy
and relatively inexpensive, it doesn't include features found in more complex software products.
Database middleware, for example, doesn't allow for two-way communication between servers and
clients. Servers can't initiate contact with clients, they can only respond when asked.
Application server middleware is a Web-based application server that provides interfaces to a wide
variety of applications and is used as middleware between browser and legacy systems.
Messaging-oriented middleware provides an interface between client and server applications, allowing
them to send data back and forth intermittently. Messaging middleware is similar to an e-mail system,
except that it sends data between applications. If the target computer isn't available, the middleware stores
the data in a message queue until the machine becomes available.
A transaction-processing monitor is middleware technology that sits between a requesting client program
and databases, ensuring that all databases are updated properly. It's a control program that manages the
transfer of data between multiple terminals and the application programs that serve them.

Finally, companies looking to succeed in e-commerce must have information systems with the ability to
respond to changing business requirements. And Web middleware allows those companies to more easily
integrate back-end applications with new e-commerce systems.

Object-Oriented Middleware
An object-oriented middleware focuses on the receiver.
Most of the effort in object-oriented systems goes into the management of concepts that are
directly related to the receiver of some message or stimulation. These concepts are:

Identity - how to name the receiver in a way that is unambiguous? How to ensure or verify that
two different identities (or "names") refer to the same object?

Lifetime - how and when individual objects are created and destroyed?

Location - strongly related with identity, solves the problem of object physical location or even its
dynamic migration. What to do if the boss moved to another office?

Behavior - how to describe our expectations with regard to the receiver's behavior? The notion of
interface and inheritance is related to this concept - is it OK to send the report to anybody who
happens to have the responsibility of one's boss at the give time?

The object-oriented middleware will try to solve such problems by focusing on the receiver of
the message and by introducing tools like remote object references or proxies so that the objectoriented "look and feel" is preserved at the call site. Even though not strictly necessary, that last
notion is taken very seriously and the effect is that typically remote invocation will not look
much different from the local one:
boss.process(myReport);

Above, the method invocation syntax does not reveal the distributed aspect of the whole
operation and this is done on purpose - to bring the boss and his behavior to the front and hide
unnecessary details behind his interface. The middleware platform will typically use some static
interface description in order to facilitate this level of integration with generation of appropriate
proxies.
An advantage of such encapsulated approach to communication is that the distribution of the
whole system becomes a deployment issue and is not necessary to deal with in the coding stage.
That is, the above line of code can be written the same way whether the system will be
distributed or not. On the other hand, isolating the programmer from the physical aspects of the
distribution at the coding level just makes it more difficult to properly handle those aspects.

Examples of object-oriented middleware systems are CORBA (omniORB, TAO, etc.) and ICE.

Service-Oriented Middleware
A service-oriented middleware shares a lot with object-oriented approach (also in terms of
physical workflow), except that there is less focus on the target of invocation and more on the
operation to be performed. In the case of weekly report problem, the service-oriented
middleware would put most of the effort on defining the operation (processing the report) and
perhaps the data structure that is being sent or received (the report itself) - but the user of such a
system would not be concerned that much with the receiver.
Service-oriented middleware can be expected to be a lot simpler than object-oriented one due to
the fact that lots of expensive problems - like identity and lifetime of remote objects - do not
have to be solved at all.
Thrift is an example of a service-oriented middleware.

Data-centric middleware
A data-centric middleware focuses not on "who is talking" but rather on "what we are talking
about" - that is, the focus is on the purpose and meaning of data that is subject to transmission.
In the data-centric middleware most of the effort is spent on ensuring effective routing of
information to all interested parties. In the case of weekly-report problem, the sender is
concerned only with publication of his content and the middleware takes care of the rest. That is,
the sender should not be concerned with who will ever receive his content - which might be
anything between zero and many receivers. Presumably there will be somebody (a boss,
perhaps?) interested in the weekly work report that was dutifully prepared and published by the
sender, but this assumption belongs rather to the configuration aspect of the whole system than to
the manner of communication. In this sense, the data-centric middleware is similar to how radio
stations operate - they just produce information and consumers tune themselves to the channel
that is of interest to them.
This decoupling of communicating components has both advantages and disadvantages. On one
side, decoupled components are less sensitive to individual failures and it is easier to construct
resilient architectures at the higher level. On the other hand, decoupling makes it inherently more
difficult to set up communication in the request-response manner (typical for client-server
interactions), which would be more natural for some problems.
A data-centric middleware does not have to be tied to the idea of hiding the physicality of
communication from the programmer, like in the object-oriented approach. The distribution is
already more or less explicit by the nature of publishing or broadcasting, and the middleware can
therefore offer quality of service control so that various physical aspects like time or bandwidth

can be properly managed. Still, the data itself remains at the center of this communication
paradigm.
Examples of data-centric middleware systems are all DDS implementations (OpenSpliceDDS,
OpenDDS, RTI DDS, etc.), AMQP brokers and JMS. They are frequently installed in those
distributed systems where potentially many receivers can be interested in data produced by
individual sources.

Message-oriented middleware
A message-oriented middleware differs in its focus from all previous ones. It is not the receiver,
not the operation and not the data that is being put in front as the communication paradigm, but
rather the fact of communication itself together with its physical aspects like size and time.
This difference in focus is very important, as it can influence the capability of the user to
properly handle the communication in the context of its physical limitations. The idea is that in
message-oriented middleware the communication is not hidden or encapsulated - which would
be typical for object-oriented approach - but exposed at least to the extent that allows it to be
managed. In particular, the fact that it actually takes time to send something to remote location is
visible in user code.
Message-oriented middleware has an analogy in the operation of traditional post office services.
Customers can send a mail or a package to some destination and get a receipt that allows them
later to track the delivery progress. It is this receipt that identifies the mail or package and it is
also what gives the focus on the process of delivery. This analogy allows to contrast the messageoriented approach with object-oriented one.
Again, the object-oriented code example:
boss.process(myReport);

The concept of delivery and physical aspects of the whole communication (like the passage of
time) are completely hidden from this syntax, as the syntax was intended for local invocations,
where the cost of delivery is negligible. As a result, the programmer has very limited capabilities
in managing the physicality of the message delivery - for example, it is not possible to track the
progress of sending big message this way. A simple time-out with an exception that forcibly
disrupts the call is probably the only thing that the object-oriented middleware will offer, as there
is simply no place in this local-like syntax for any more elaborate management of time.
A message-oriented approach to the same problem will instead focus on the message itself:
Message msg = middleware.send(boss, myReport);
// ...
msg.wait_until_confirmed();

The above syntax is artificial and might not correspond to any existing system, but highlights the
analogy with regular post-office services. The msg object is a handle or "receipt" that allows the
user to later track the delivery of the message - for example, to show the progress of transmission
in a graphical way or to check how much data was actually involved in the communication. Or,
to check in a completely asynchronous way whether the message was delivered and processed at
the target side. In any case, the user deals with the message as a primary artefact of
communication.
A very important consequence of exposing the physicality of messaging - in particular the
passage of time - is that it becomes easier to deal with. In the above example it is clearly visible
that something possibly lengthy is happening between two lines of code. By giving the user an
explicit handle to this process (instead of hiding it behind object-oriented syntax) the messageoriented middleware makes it easier to decide how these lines should be organized. The
following code examples show one possible way this freedom can be used.
Two messages can be processed in sequence (one completed after another):
Message msg1 = middleware.send(somewhere, something);
// ...
msg1.wait_until_confirmed();
Message msg2 = middleware.send(somewhereElse, somethingElse);
// ...
msg2.wait_until_confirmed();

Alternatively, the same two messages can be processed in parallel:

Message msg1 = middleware.send(somewhere, something);
Message msg2 = middleware.send(somewhereElse, somethingElse);
// ...
msg1.wait_until_confirmed();
msg2.wait_until_confirmed();

Above, a small coding difference can result in fundamental change in how the underlying
infrastructure is used, especially in the context of parallel processing and scalability - a subject
that is recently gaining a lot of attention.
It might be also interesting to note that message-oriented approach does not limit the other
aspects of communication and in principle can support both peer-to-peer interaction in the
request-response style (that would be traditionally associated with object-oriented or serviceoriented middleware) as well as with decoupled publish-subscribe data transfer. In this sense the
message-oriented approach allows to highlight the physicality of communication without any
loss of generality.

People can also think of middleware as an adapter device that would run from a new printer to an
older computer. The adapter connects the two devices, enabling communication and,
therefore, functionality between them. Common packages include the Distributed Computing
Environment (DCE) and the Common Object Request Broker Architecture (CORBA).
Without this software, certain kinds of network activity would be impossible. The more powerful
applications become, the more middleware will be needed.

Message Oriented Middleware

This type of middleware is an infrastructure that supports the receiving and sending of messages
over distributed applications. It enables applications to be disbursed over various platforms and
makes the process of creating software applications spanning many operating systems and
network protocols much less complicated. It holds many advantages over middleware
alternatives (e.g. hard coding logic) and is one of the most widely used types of middleware.

Object Middleware
Object middleware, also called an object request broker, gives applications the ability to send
objects and request services via an object oriented system. In short, it manages the
communication between objects.

Remote Procedure Call (RPC) Middleware

An RPC is exactly what it sounds like. It calls procedures on remote systems and is used to
perform synchronous or asynchronous interactions between applications or systems. It is usually
utilized within a software application.

Database Middleware
This type of middleware allows for direct access to databases, providing direct interaction with
databases. There are many database gateways and connectivity options and you simply have to
see what will best work for your necessary solution. This is the most general and commonly
known type of middleware. This includes SQL database software.

Transaction Middleware
This type of middleware includes applications like transaction processing monitors. It also
encompasses web application servers. These types of middleware are becoming more and more
common today.

Portals
This refers to enterprise portal servers. It is considered middleware because portals facilitate
front end integration. They are used to create interactions between a users computer or device
and back end systems and services.

Embedded Middleware
This type of middleware allows for communication and integration services with an interface of
software or firmware. It acts as a liaison between embedded applications and the real time
operating system.

Content-Centric Middleware
This type of middleware allows you to abstract specific content without worry of how it is
obtained. This is done through a simple provide / consume abstraction. It is similar to publish /
subscribe middleware, which is another type of this software that is often used as a part of web
based applications.

Today, there is a diverse group of middleware products as outlined in the following examples.

TP Monitors
The TP monitor (transaction processing monitor) was perhaps the first product to be called
middleware. Sitting between the requesting client program and the databases, it ensured that all
databases are updated properly (see TP monitor).
Messaging Middleware
Messaging middleware provides a common interface and transport between applications. If the
target machine is down or overloaded, it stores the data in a message queue until it becomes
available. The messaging system may contain business logic that routes messages to the
appropriate destinations and reformats the data as well. Messaging middleware is similar to an email messaging system, except that it is used to send data between applications. (see messaging
middleware).
Distributed Processing

Distributed object systems such as CORBA, DCOM and EJB enable processes to be run
anywhere in the network. They differ from messaging middleware in that they cause processes
(components/objects) to be executed in real time rather than sending data.
Database Middleware
Middleware provides a common interface between a query and multiple, distributed databases.
Using either a hub and spoke architecture (top) or a distributed architecture (bottom), it enables
data to be consolidated from a variety of disparate data sources (see EDA and DQbroker).
Distributed Database Middleware
Middleware provides a common interface between a query and multiple, distributed databases.
Using either a hub and spoke architecture (top) or a distributed architecture (bottom), it enables
data to be consolidated from a variety of disparate data sources (see EDA and DQbroker).

Common Interfaces
Common programming interfaces between applications are considered middleware. For
example, Open Database Connectivity (ODBC) enables applications to make a standard call to
all the databases that support the ODBC interface.
Application Server Middleware
A Web-based application server that provides interfaces to a wide variety of applications is used
as middleware between the browser and legacy systems. The browser can be used at desktops or
on laptops when traveling. A wide range of server-side processing has been supported by
appservers (see Java EE).
Universal Computing
One of the Holy Grails of computing, these examples link an application to an operating
environment. They enable the same program to run on any hardware platform without
modification. HTML pages can execute on any Web browser running under any operating
system. Java applications and applets are executed by a Java Virtual Machine, which can be
created for any operating system. Thus, the browser and Java negate the requirement for only
one operating system and hardware environment.
Network Logon
Middleware for networks includes a common approach for identifying users and network
resources, authorizing and authenticating users and setting up standardized directory schemas.
Using middleware in this fashion avoids the problems that occur when applications are
responsible for these tasks and incompatible versions arise. The Internet2 project was designed

to make advancements in this area. For more information, visit http://middleware.internet2.edu.

Enterprise Integration
ActiveWorks software was designed solely as an integration solution. Brokering messages
between a wide range of enterprise applications, it added processing where required.
ActiveWorks was later acquired by webMethods and folded into its BPM suite. (Image courtesy
of Active Software, Inc.)