Middleware Types

In the last chapter we introduced the notion of middleware, why we need it and how it turns integration easier. So today we are going to talk about the different types of middleware. And let us start with one vert used in point-to-point integration:

• RPCs (Remote Procedure Call) Middleware

RPC exists since the 1970s and are the oldest type of middleware and it is client/server based. One client can request a service from a program located in another computer in a network without having to understand network details. [1]. RPCs are synchronous; they are labelled as “blocking middleware” because the requesting program is suspended until the results of the remote procedure are returned [1]. As the RPC’s use a point-to-point communication, they are not scalable and consume a vast amount of resources during they processing [1]. Despite the simplicity, the complexity of their maintenance and performance issues, make this middleware not a viable solution in scenarios where there are many applications requiring integration.
 

Figure 1 RPC

• MOM (Message Oriented Middleware)

MOM is a type of middleware that uses messages as the method of integration [2]. In MOM the applications are decoupled. Sender and receivers are never aware of each other; instead they send and receive the messages from the messaging system. It is the responsibility of the MOM to get the messages to their destinations [4]. The messaging system uses channels that the applications can recognize and the messages can be sent and received asynchronously. The asynchronous paradigm allows the application to continue functioning after sending a request, so if the message is taking too much time it is possible to process other messages while is waiting, they can deal with down connections and queue messages until it’s viable to deliver them [3]. One established standard is the JMS (Java Message Service), which provides an API and a set of rules that govern message delivery [4].

Figure 2 MOM

• Distributed Objects

Distributed objects are small applications that use standard interfaces and protocols to communicate with one another. Because they are built over standards, two compliant objects should be able to exchange information and carry out application functions by invoking each other methods [3]. Two important distributed objects specifications exist, CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model). CORBA is an architecture and specification for creating, distributing, and managing distributed objects in a network. It allows different objects at different locations to communicate through an interface broker. CORBA uses the ORB (Object Request Broker). ORB allows an object to request services from other object without having to learn his location in a distributed network using the CORBA Interface repository to locate and communicate with a requested object. To enable interoperability between different ORBs, the GIOP (General Inter-ORB Protocol) and for the Internet, the IIOP Internet Inter-ORB Protocol) were implemented, both over TCP/IP [5]. DCOM (Distributed Component Object Model) is the Microsoft equivalent to CORBA. It is based on the DOM (Component Object Model) and provides a set of concepts and interfaces that allows client objects request services from server objects in a network. DCOM allows bridging with CORBA, mapping COM objects to appear as CORBA objects [6].

Figure 3 CORBA + ORB

• Database Middleware

Database middleware allows communications with a database from an application or between databases. It is used to extract information from either local or remote databases. It works with two database types, CLIs (Call level interfaces) and at-native database middleware [3]. CLIs provide access to any number of relational databases through a common interface. On the other way, native database middleware uses the features and functions of a particular data base, using only native mechanisms. Although only communicate with one database, it has as advantages, improved performance and access to all low features of a particular type of database [3].

• Transaction Processing Monitors

They are a type of middleware that preserves the integrity of a transaction. TP Monitors support features such rollback, failover, auto restart, error logging and replication to eliminate single points of failure [3]. They provide a location for application logic in addition to communication between two or more applications [3].

• Message Brokers

Message Brokers allow the information flow between applications. They can, regardless the type of application, join them using common rules and routing engines [3].
 

Ricardo Santos

EAI Consultant and IoT Evangelist at Polarising
 
References

1. Linthicum, D.S.: Next Generation Application Integration: From Simple Information to Web Services. Addison-Wesley, Boston (2004)
2. Ruh, W.A., Maginnis, F.X, Brown, W.J.: Enterprise Application Integration: A Wiley Tech Brief. John Wiley & Sons, Inc. (2001)
3. Linthicum, D.S.: Enterprise Application Integration. Addison-Wesley, Boston (2000)
4. Chappel, D. A.: Enterprise Service Bus: Theory in Practice, O’Reilly Media, Inc. (2004)
5. Common Object Request Broker Architecture, http://www.corba.org/
6. Pritchard, J.: COM and CORBA Side by Side: Architectures, Strategies, and Implementations. Addison-Wesley, Boston (1999)