We have OR Mappers, now with SOA we need OM Mappers

Over the past several months there has been a lot of discussion surrounding O/R Mappers.  I've added my thoughts at various times as can be seen in the following posts:

Overall I think the community is beginning to see the value of an O/R Mapper.  There are certainly many people who still won't use one and don't see the value, which I certainly don't have a problem with. 

Over the course of the last several weeks I've been contemplating the way SOA will affect the way I write applications.  I've been challenged by a number of people on the way I've been approaching SOA (much appreciated!) and many have pointed out that OO and O/R Mappers just don't fit in with SOA because messages in our service oriented world don't map to our objects. 

It seems to be that SOA introduces another aspect into the development of our applications.  We currently struggle with how our objects are mapped to our data stores.  With ObjectSpaces, EntityBroker, LLBLGen, and WilsonORMapper we have some answers to how we can reduce the headache that comes with mapping our objects to our relational data store.  As I see it we have two options.  We can either change the way we write applications, ditch our O/R Mappers, and start anew OR we can continue developing our applications in a similar fashion utilizing our O/R Mappers, rich object model, while also introducing a new OM (object message) Mapper. 

A OM Mapper would take a approach very similar to what currently happens in the O/R Mapper space.  Rather then mapping our objects onto a database, our objects would be mapped onto a message.  This would allow us to work the way we currently work, in our nice OO world.  Our O/R Mapper would sit behind our objects and help with the persistence of our objects, and our O/M Mapper would sit in front of our objects and allow them to be transformed into the messages that our services layer uses to communicate with the outside world. 

I think I might have fallen off my rocker a bit with this thought, however, at this moment in time it seems like a valid concept.  Why do we have to change the way we do everything?  Perhaps I'm too attached to the way I write my applications.  Perhaps I need to take on a nice sized SOA project and see the ease at which it allows me to adapt.  Perhaps I need to stop trying to figure out ways to get my objects with behavior into the services world.  Perhaps not?

# re: We have OR Mappers, now with SOA we need OM Mappers

Friday, March 05, 2004 1:53 PM by douglasp    
you may get what you wish for one of these days... ;-)

# re: We have OR Mappers, now with SOA we need OM Mappers

Friday, March 05, 2004 2:30 PM by Steve    
Excellent! I guess I'm not as far off my rocker as I may have thought ;-) Any chance you an shed some light on when and in what form? Whitehorse?

# re: We have OR Mappers, now with SOA we need OM Mappers

Friday, March 05, 2004 6:46 PM by Frans Bouma    
The people who follow Fowler need an O/M mapper. The people who don't follow Fowler don't need an O/M mapper.

Blunt statement, but here's why:
People who use the Domain Model, don't have classes which consume entity objects, the entity objects are the only objects around. If you want to supply the service these entity objects provide together, you have to make sure you can communicate with these objects. In a sense: an O/M mapper is required.

People who use the 'manager' model don't have to use an O/M mapper. The reason for that is that the entity objects are not forming the service a client communicates with, the manager classes do. These manager classes accept and process entity objects. You 'call into' these manager classes like you do with a webservice. you pass entity objects to these methods, receive entity objects from these methods. No object-message mapping required, because it has no meaning in that context.

Now, what's left is: what's better: Domain Model or Manager model ;)

# re: We have OR Mappers, now with SOA we need OM Mappers

Friday, March 05, 2004 7:47 PM by Christian Weyer    
I guess Doug refers to the new serialization capabilities (which may be expressed as an enabler for your 'OM mapping' solution) in Indigo. E.g.
<a target="_new" href="http://microsoft.sitestream.com/PDC2003/WSV/WSV303_files/Default.htm">http://microsoft.sitestream.com/PDC2003/WSV/WSV303_files/Default.htm</a>
<a target="_new" href="http://benjaminm.net/PermaLink.aspx?guid=5ad85efe-27cd-4446-ba62-da387ce0cbab">http://benjaminm.net/PermaLink.aspx?guid=5ad85efe-27cd-4446-ba62-da387ce0cbab</a>


# re: We have OR Mappers, now with SOA we need OM Mappers

Sunday, March 07, 2004 4:59 PM by Paul Bartlett    
Have you looked at Zen, a new language coming out of MS Research. I've not looked at it in too much detail, but the idea is that it has support for objects, relational data and XML &quot;designed&quot; (referred to by MSR as programming with circles, squares and triangles - or by me as the unholy trinity ;)

# re: We have OR Mappers, now with SOA we need OM Mappers

Sunday, March 07, 2004 9:29 PM by Steve    
Paul, I have looked at it...and it could definitely bring some interesting things to the table.

# re: We have OR Mappers, now with SOA we need OM Mappers

Sunday, March 07, 2004 9:30 PM by Steve    
Christian, I think you nailed it with those links. It sounds like a lot of the new serialization will get us close (if not all the way) to where I think we need to be.

Post a Comment

 
 
Prove you're not a spammer: 
3 + 4 =