There's a few benefits, the main one being decoupling of the application and the back end. This way, rather than your application developers needing to know ho

There's a few benefits, the main one being decoupling of the application and the back end. This way, rather than your application developers needing to know how to talk to the database, they simply use an API to talk to the middleware, which never changes even if you replace the back end database software (moving from Oracle to DB2 for instance). Think of it like a translation service, in this regard. It also helps reduce overhead and latency. Imagine if you had to constantly write the actions of users to a database in real time for 50000 users, including all the metadata, just so your servers could communicate amongst themselves. The latency involved would be huge, even with today's vastly-better equipment. A fast middleware layer greatly helps to cut down on the data that needs to be written to the back end system, while also improving latency, for what's really not a lot of extra complexity. Two birds with one stone, so to speak. This approach also helps you scale - you can treat everything as a node, with the middleware data as distinct messages. Messages are created and consumed from queues, and so you can have multiple application servers and multiple database servers, with applications publishing messages onto queues for processing, with the database servers consuming these messages if they have the resources to do so. Adding more capacity to the system then becomes as simple as creating a new database server and telling the middleware it exists - the extra resources are automatically used. Most enterprises work this way.. The basic outcome is that you can start treating the components as a service, with easy separation of duty. There's more detail here: http://en.m.wikipedia.org/wiki/Middleware http://en.m.wikipedia.org/wiki/Middleware