Tough Choices

Ah, wouldn't life be wonderful if there was only one perfect middleware layer choice, one that provided all the features we needed, coupled with unexcelled performance? Well, wake up and smell the coffee. Life may be wonderful, but it's almost never that easy. Before hooking your application to any middleware technology, you need to examine all the technologies and carefully weigh their advantages and disadvantages as they apply to your particular situation.

RPCs are slow, but their blocking nature provides the best data integrity control. For example, while an asynchronous layer to access data may seem to be the best solution, there is no way to guarantee that an update will occur in a timely manner. It is not difficult (especially for us paranoid types) to envision a scenario where an update to a customer database is sitting in a queue, waiting for the database to free up while a data entry clerk is creating a sales transaction using the older data. RPCs may be slow, but they would never allow this kind of situation to occur. When using RPCs, updates are always applied in the correct order. In other words, if data integrity is more important than performance, RPCs may still be your best bet.

Still, as we move forward with application integration, we find that within most enterprises, RPCs are not the best choice. This is a direct consequence of the need for instantaneous processing. We never want to hold up an application while it waits for a trading partner application to respond. As a result, asynchronous middleware is the preferred solution within most enterprises, based on the fact that it does not block an application while it awaits a response from another system. Thus, it supports the notion of long transactions, which are critical to the world of application integration.

MOM vendors contend that synchronous middleware cannot support the needs of today's event-driven applications. Programs simply cannot wait for other programs to complete their work before proceeding. Yet RPCs could provide better performance than traditional store-and-forward messaging layers in some instances. Then again, messaging could provide better performance, because the queue manager offers sophisticated performance-enhancing features such as load balancing.

Middleware remains a great mystery to most people. It is difficult to use, and even more difficult to explain. Most users typically never see middleware plumbing, as they do application development and database products. However, as we go forward, we will see more user interfaces and business layers included with middleware products. The days of the "application program interfaces only" are almost over. Such is the case with newer middleware technologies such as application servers and integration servers that are created from the ground up for application integration. The presence of easy-to-use interfaces will take the power of middleware at one time, the exclusive domain of the developer and place it in the hands of the business user.

Clearly, middleware is headed in this direction. It is also how we will ultimately solve the application integration problem.