The software technologies mentioned in the subject of this blog post (i.e RDBMS, Message queue, Message broker, ESB [enterprise service bus] & HTTP) are the primary 'vendor agnostic' application integration technologies (backbones). I wish to write in this blog post, the characteristics, and the differences between the mentioned application integration technologies, and the relevant use cases when each of the mentioned application integration technologies should be used. Below are the details,
1) RDBMS (relational database management system): This is the oldest, and perhaps the most robust of the mentioned four application integration technologies. It is defined on the notion that, "data" generated and consumed by a software application is persistent for a long time. With RDBMS, the fundamental storage primitives at an application layer are tables. Most of the RDBMS vendor products store their tables, in binary file system files as underlying platform storage. The application code, accesses the RDBMS tables (and may be other things like views, functions, stored procedures, triggers) via a SQL interface (for e.g jdbc in java, and ADO.Net in .NET).
2) Message queue: Message queue is an application storage type, where messages (i.e data) are pushed at the end of queue and retrieved from the front of queue. The message sending and receiving applications are usually different, but they may as well be same. A message until it is pulled by an application 'at most once' from the queue, remains in the queue. This essentially differs from the RDBMS style in a way, that in RDBMS database data remains in the tables no matter how many times it is read by applications. This fundamental difference between RDBMS and "message queue", point to the kind of uses cases where one of these technologies should be used.
For e.g, a search engine's database would be appropriate to be stored in RDBMS databases. Whereas, 'send and forget' or 'read and forget' kinds of messages would be appropriate to be stored in message queue.
Message queue can be further classified into linear queue, and publish subscribe storage. Both linear queue and publish subscribe storage, are managed by an underlying queue manager. With a linear queue, after any one receiver application retrieves message from a queue no other application will find that message in the queue (since it's deleted after the first retrieval). With publish subscribe storage, for a particular class of message (typically published by one application) one or more subscribers can register. Upon publication of a message by a sender application, all subscribers for that message type will receive the message and after which the message would be deleted from the underlying queue(s).
3) Message broker: With this storage type, the underlying storage data structure is same as for "Message queue". Unlike 'Message queue', the 'Message broker' is thought to be central (multiple sender and receiver applications, can connect to a central 'Message broker'). The 'Message broker' kind of a storage is more sophisticated than a 'message queue'.
To establish a simple application integration design, I'd perhaps use message queue (perhaps using multiple message queues for a complex scenario) instead of a message broker.
4) ESB (enterprise service bus): The ESB storage and distribution type, is somewhat like a message broker. But unlike message broker, the message distribution backbone of an ESB is linear rather than central as for the message broker. Just like message queue and message broker, the responsibility of an ESB is to allow multiple message senders to connect with multiple message receivers.
Unlike message queue, both message broker and ESB allow selective routing and transformation of the messages between applications (where routing and message transformation decisions take place at the message broker or on an ESB node).
The following site provides a nice documentation about how to build messaging applications: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q022830_.htm.
5) HTTP: As good as it was when it was introduced, the HTTP protocol and its implementations within web browsers and various programming libraries is a very good means to establish software application integration. An HTTP server can respond with information and can perform actions, as asked by the HTTP clients. For various needs these days, HTTP servers can respond with information stored within the HTTP server itself, or HTTP servers can interface with other backend systems like databases and fetch information from them or modify those information as asked by HTTP clients.
It is useful to know that, HTTP style of software application integration is inherently synchronous in nature (i.e, application clients keep waiting at the point of issuing a request until a response is received), while all other styles of application integration mentioned in this blog post are inherently asynchronous (i.e application clients can start doing something else after issuing a request and before getting a response).
Unlike message queue, both message broker and ESB allow selective routing and transformation of the messages between applications (where routing and message transformation decisions take place at the message broker or on an ESB node).
The following site provides a nice documentation about how to build messaging applications: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q022830_.htm.
5) HTTP: As good as it was when it was introduced, the HTTP protocol and its implementations within web browsers and various programming libraries is a very good means to establish software application integration. An HTTP server can respond with information and can perform actions, as asked by the HTTP clients. For various needs these days, HTTP servers can respond with information stored within the HTTP server itself, or HTTP servers can interface with other backend systems like databases and fetch information from them or modify those information as asked by HTTP clients.
It is useful to know that, HTTP style of software application integration is inherently synchronous in nature (i.e, application clients keep waiting at the point of issuing a request until a response is received), while all other styles of application integration mentioned in this blog post are inherently asynchronous (i.e application clients can start doing something else after issuing a request and before getting a response).
To build a messaging application, I'd perhaps start with a message queue for a simplistic design and gradually moving to message broker or an ESB for more complex requirements.
Any comments about subject matter of this blog post are welcome.
