This post originated from an RSS feed registered with .NET Buzz
by Frans Bouma.
Original Post: Does SOA require Object-Message mappers? It depends.
Feed Title: Frans Bouma's blog
Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/fbouma/Rss.aspx
Feed Description: Generator.CreateCoolTool();
Steve Eichert blogs about the question if we need an Object-Message mapper (O/M mapper he calls them) in a Service Oriented Architecture (SOA) world. It's my understanding that he thinks we need an O/M mapper when we're going to use SOA. I beg to differ.
A couple of months ago, in the microsoft.public.objectspaces newsgroup a lengthy discussion was held about the topic 'Is an O/R mapper useful in a SOA world?'. The reason for this discussion was of course: how will O/R mappers be affected once SOA is widely accepted as a solid architecture for building software systems. It turned out that the Domain Model-followers (let me call these 'Fowler followers') said that SOA would affect O/R mapper usage and the people who see advantages in the Manager Model (separate classes which solely process data passed in, like an 'OrderManager'. Often mimicing business processes on a rough 1:1 basis) didn't see that happen.
When you use the Domain Model, you (generally speaking) define business logic in your entity classes through inheritance and/or aggregation. This means that you add for example business logic related to customer entities to the customer entity itself. The average result of this is that the vast majority of your application's business logic layer's API is formed by the set of Domain Model classes ('Domains') you've defined. A problem arises when you want to make this API a service which has to be used by other tiers in your application, for example a set of GUI tiers on desktops and webservers. Communication between these tiers and the 'service' requires that you can map messages used to communicate between client and service (or service and service) onto the entity objects defined. In a sense, this can require a tool to make this an easy task: an O/M mapper.
When you use the Manager Model, you don't have to. The reason for that is simple: a 'Manager' in the Manager Model acts as a service by itself, it's the task of the Manager in a Manager model to provide a service. This means that you use the service in a more procedural way, like you are doing today with a webservice. Data passed between client and service (in this case the Manager or for example a 'Manager manager' or 'Manager dispatcher') or service and service can contain entity objects, but also data which will be transformed into entities inside Managers. Does this require an O/M mapper per se? No, not at all. A tool to connect method call to method definition is more appropriate, thus a tool which will be used to design the SOA architecture.
It thus depends on how you design your software in general: do you want to use your entity objects 'by value' (and thus do you want to apply logic on them by passing them to a service object like a Manager) or do you want to use a rich Domain Model where the entities are used 'by reference' because they form the service?
Thinking about this, I come to the conclusion that the question is not: do we need O/M mappers in the SOA world, but: do we need the Domain Model in the SOA world? With the advantages of easy projection of functional descriptions of business processes on Manager Model classes in the hand, with the absence of the necessity of yet another tool to map data to objects (because in the Manager Model, the SOA architecture tool will be sufficient), I can only say: for me, we don't need the Domain Model in the SOA world. We can do just fine using the Manager Model approach, which doesn't suffer from the disadvantages the Domain Model brings to the table in a SOA approach. This doesn't mean the Domain Model doesn't have a place in the software world, it's my conclusion that the Domain Model (and thus O/M mappers) do not fit SOA and if you want to use a SOA-oriented approach, it's thus best to use the Manager Model instead of the Domain Model
Previous Topic
