These are actually two separate things. The data would definitely be stored in a database on a SAN, and a NetApp SAN plus oracle DB would be just fine for that. This represents the database/storage layer of the operations.

The part I'm talking about is the behind-the-scenes communications layer for the application itself - how you pass information between servers in real time with low latency.

Think of things as a stack. You have the top layer which is the application. It runs on an individual server as a process, or set of processes. You then have middleware, which is software that handles communication between applications, whether it's on the same box, or between servers. Middleware is also responsible for handling communication with the database (oracle in this case possibly). This is the database or information storage layer.

Ie: application layer --> middleware --> database.

This middleware is the portion I'm postulating could be using XML, based on my general enterprise experience. It's not stored anywhere, it's simply a transport mechanism for data between applications when you don't need to store it. More than likely it would contain information such as 'this user is entering the battlegrounds, please create a slot for them with these details', or 'this player just caught the boat to another continent, I'm handing them from me to you and here is all their information'.

XML is great for this kind of 'live' data transportation, although I probably prefer json these days..

I don't understand, why wouldn't you just use the centralised database you already have as opposed to creating this XML communications middle-layer that seems to be redundant with a centralised data store?

What are your savings doing it that way? It just seems to cost more of everything (resources, man-power, etc).

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

It's important to note that I wouldn't recommend an ESB architecture for small scale.. You really only want to be looking at this sort of thing when your server count is 20+ and you have separate teams handling your application, databases and middleware.

I've observed some messaging behavior in the game -- selling at a vendor can take variable amounts of time, implying that the buy/sell transactions are via a service and not local to the gameplay server.

I expect they use a hybrid approach - some monolithic, some message-bus.