| Feature | RPC | Advantage | MOM |
| Client/Server model | Unlimited clients and servers with multiple brokers running anywhere in the network | RPC | Multiple clients with multiple servers restricted to limited number of queues on pre-determined servers in the network. |
| Client/Server relationship | Synchronous with Asynchronous possible. Clients and Servers designed to run concurrently. Clients can choose not to wait on Server response by using asynchronous option. | RPC | Asynchronous. Clients and Servers may operate at different times and speeds, response to Client is not guaranteed (synchronous not possible). Also, message queue backups can cause performance problems. |
| Platform Support | Unlimited; every vendor in the world supports RPC. | RPC | Limited platform support for MOMs |
| Communication | Listen, Connect, Accept | NA | Post a message then wait |
| Administration and Monitoring | Many different commercially available monitors. | RPC | None |
| Scalability | Easily done by starting additional servers based on load. | RPC | Very difficult to scale because there is no way to distribute queues dynamically. |
| Load-balancing | Can be accomplished with performance monitors and application management systems. | RPC | Requires a monitor to manage more than as single queue. Single queue can be used to implement FIFO or priority based policy. |
| Transactional Support | Yes; easily supported with RPC. | RPC | Limited (Some Products) Message Queue can participate in the commit synchronization |
| Message Filtering | No | MOM | Yes |
| Performance | Very Fast | RPC | Very Slow. An intermediate hop is required. |
| Asynchronous processing | Yes; easily implemented with callback. | NONE | Yes. Queues and triggers are required |
For many years, middleware engineers have argued the advantages of different middleware technologies as it applies to enterprise applications. The main categories of contemporary middleware tend to fall into four main groups: Message Oriented Middleware, RPC middleware, and Object Oriented Middleware. In each of these three middleware technologies, there are pros and cons to the technology and cases where one middleware technology serves certain types of applications better. The main areas of merit (in no particular order of importance) tend to be performance, scalability, adaptability, maintainability and ease of use. When weighing these merits of each middleware technology, we evaluated some of the vendor’s publicized advantages and tried to categorize each feature or advantage into one of these three main areas. First, let’s elaborate on our categories.
The performance of a middleware is usually tied to the response time the user (client) has to wait until his or her response is received. This is usually the time between when the execute button is pressed and the results of the remote server’s execution is received. Usually the user gauges the response time against trivial requests made to the local workstation’s operating system. Now there are a number of factors that can influence the response time, so our assumption will be that the client’s network is not overloaded, the client’s workstation is sufficient to do enterprise computing, the server is not overloaded with a good balance of available CPU, memory, disk and IO bandwidth for executing client requests and there are no significant network issues between client and server.
One major responsibility of middleware is to scale up the number of software services (providers) available to clients (consumers) based on past demand. The demand can be measured in different ways depending on the programming paradigm used and whether multi-threading is involved, but ultimately it is reflected in the time the user has to wait for results. The middleware’s responsibility is to provide sufficient capability to enable additional servers to be started to meet demand. In an enterprise environment, load leveling of the application servers across the enterprise is also important to prevent overtaxing computer resources on specific systems.
Adaptability is the virtue of middleware that enables it be used for different types of applications with differing resource requirements. In some cases this refers to computer languages and operating systems, sometimes it is adaptation to database technologies and sometimes it is the ability to adapt to the design of the application or adhere to its business rules. This measurement is difficult to measure sometimes because there are different ways to implement logic depending on the programming paradigm. In other cases, it is simply a case of “yes” it supports this or “no” it doesn’t.
As with many applications poorly designed, maintenance is a big consideration in choosing middleware. Middleware maintenance refers to the number of problems that occur with running enterprise applications. There are some cases where legacy middleware applications are problematic: multi-language, multi-platform and multi-database heterogeneous middleware environment always seem to have more problems that homogeneous ones. OS and database changes contribute to the maintenance problems of middleware, but in the end, the stability of the applications, middleware data passing, naming service functions, memory management functions, application monitoring and resource usage determine the viability of most middleware technologies.
Perhaps the most important factor in evaluation of middleware technologies is the ease of use. If understanding of how it works and configuration of the middleware is too difficult for administrators, engineers and users, then it will fail. Most middleware systems have an IDL compiler, a naming or broker service, runtime utilities and application monitors. The ability to use each of these components determines the ease of use.