Regardless whether you’re working on a BPM project or a fully fledged EAI project, it’s quite likely that you’ll need to get one system talking to another at some point. Middleware is an overused generic label for the grey area that is connecting systems (platforms and software). It can mean a plethora of different things and tends to be a misunderstood area of technology (‘Frank: our middleware takes care of that… Nancy: What middleware do you have?… Frank: don’t know’).
I’ve just finished reading a book named ‘Inter-Enterprise Application Integration’ that I must of picked up at some point when working in europe (can’t remember when). It’s a pretty good book and goes into some depth regarding middleware and what that actually means across different technologies. What I’m attempting to do here is to condense that down into my own words and summarize the major technologies used in implementing middleware.
So starting off with the main question… What is middleware? – The way I like to see Middleware is not as one particular technology, its more of ‘mechanism’ that allows one application (lets say software entity) to communicate and trade data with one or more software entities (normally across disparate platforms that don’t easily speak the same language). Middleware isn’t a server that you just install and applications can start chatting… it’s an approach. Ok so that’s quite a broad explanation… but hopefully by the end of this article the picture will be clearer.
Middleware comes in several flavours, most of which I’m going to cover here in limited detail. First the approaches followed by the communication types and finally middleware technologies.
Middleware Models (approaches)
Point to Point Middleware – Point to point as the name suggests emulates a sort of pipeline between 2 applications directly. Both applications communicate data down the pipe in most cases at the same time. Application A can shout down the pipe to application B and vice versa. Now this model of middleware is quite old now as it doesn’t quite fit in with the service based ‘loosely coupled’ approach that modern software developers take. Not only that, but there is no middle tier processing going on here, its direct only. An example of Point to Point middleware is some code in Application A that calls some code in Application B exclusively. RPC is a type of point to point middleware.
Many to Many Middleware – This model allows many systems to talk to many other systems. This model covers more of the newer middleware technologies including TP Monitors and Message Brokers. It is a more flexible approach to implementing middleware and for the most part is a more cost effective choice.
Middleware Communication Methods
Queued Communication – Queued communication generally requires some form of queue manager to place a message into a queue. The remote application is then able to connect to the queue and retrieve the message. If the sending system requires a response, the remote system will place that response in that (or another) queue for pickup. Most message orientated middleware use queued communications as it provides a way for applications to obtain messages even when the remote system is off-line.
Publish / Subscribe Communication – Pub/Sub as its known free’s an application from the need to understand anything about the system it is communicating with. All the sending system has to do is release a message to the pub/sub agent (not unlike marvel comics delivering their latest to the chap down at your local newsagent). The agent / broker then redistributes the message to all interested (subscribed) parties.
Request / Response – As it says on the tin, this communication method involves one application sending a request to a secondary system which would respond. Message brokers and application servers tend to utilize this approach.
Fire and Forget – This model deals with the sending system just firing off a message with no regard for a response.
Types of Middleware
Middleware like many other technology styles is evolving and these days its 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 RPC’s however is that they can carry a lot of processing overhead so perform isn’t 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 RPC’s. 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 doesn’t 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.