A question posed about the article I wrote on ESB vs. SOA was to compare a "message oriented architecture" (MOA) to a "service oriented architecture" (SOA).
There's no well recognized definition for MOA, frankly. Many people talk about it interchangeably with messaging middleware, but I think that's a mistake because middleware does not prescribe the architecture of the applications layered on top of it (you can do point-to-point, SOA, pub/sub, request/reply, etc. on top of a messaging middleware)
I would tend to describe it as follows...
MOA: An architecture for exchanging documents where there is no implied semantics about what should be done with a received document.
What does this definition mean? It basically means that MOA is for broad-scale information sharing. An example would be stock ticks. A financial ervices firm will have a MOA backbone (often TIBCO) to distribute changes in stock values to any application that is interested. It doesn't dictate what someone does once they know a stock has changed - it just informs them that it has happened.
By this definition, MOA is primarily used for data synchronization and event notification. As a result MOA would often be pub/sub based.
SOA, in contrast, is about execution of business processes through services. You are distributing documents with a purpose - you don't send out an order "just because" you send it out because it is to be processed or cancelled. With an SOA the consumer is interacting with a provider for a well defined purpose (e.g. processing an order). The end result is that SOA rarely leverages pub/sub - SOA is more focused on "directed messaging" (messages directed at a specific target for a specific purpose).
While there have been religious wars in software about which is "better" pub/sub or directed messaging - in the end, many organizations will need a combination of both approaches (SOA and MOA). There is always a need to have well defined business processes executed and there is usually a need to have certain types of information or events widely distributed.
That said, one aspect of the movement towards SOA is to avoid unnecessary data synchronization. Instead of having systems that have duplicates of common information, have one master data system - one logical source of truth - that is leveraged by the other applications. It's certainly not always possible, but the world has seen the challenges that duplication cause (brittle hard to change infrastructure) and it's not pretty.