This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: What you should really know about service contracts
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Buddhike from the thinktecture crowd yearns for automation in the mapping between service contract to service implementation - messages to model. It appears to be a worthy goal, doesn't it?
Well, I've been getting my hands dirty on about 3 projects or so over the past couple of years in this whole SOA mess. First of all, you have to understand that the contract isn't magical - it's a bitch to get something solid that communicates the intent of how to work with the service. Then, after understanding how the outside world will interact with the service, can you really iron out your domain model. Don't expect that to occur overnight either.
Finally, this idea of mapping messages to model, it glosses over the fact that you'll probably need to design/code a service layer over your domain model to encapsulate the workflow of using those domain objects to fulfill a given use case.
In the end, the only real thing left is to map messages to service layer calls, which is something of a waste of time. You'll only know what you're mapping after the code is "done" (whatever that means) for both the contract and the service layer - which means much of your domain model is coded up too.
Just write the code to translate message to service layer call. It's the least of your worries. Don't waste your time optimizing away the boring typing, although we developers do love trading boring work with more intersting work - if that more intersting work takes longer to do, so be it ;)
I guess I don't have very high hopes for what the tooling can bring to the table.
Previous Topic
