Geeks With Blogs
I'd Rather Be Coding Jay Glynn thinking out loud.

Without question the message from TechEd this year was services. How to migrate services, how to make services, how to use data in services etc etc etc. However, a comment was made in the BOF session I hosted that has me thinking. The question came up that since his organization is trying to move to service based architecture, he has found that the design of the application is changing. Instead of having a nice pluimp object model, he said he now is just pumping messages around. His problem was that he wasn't sure if that is what he should be doing. My first reaction was if that's what the situation calls for, then your doing the right thing. However as I thought this over for a while I'm starting to question that. I see where services are a “Good Thing”. But part of the reason for services is flexibility. In our organization flexibility means that the object or component might be implemented in a server based application or on a disconnected mobile device. In that case disregarding that nice plump object model may be a mistake. If I'm on that disconnected mobile devoce, services are worthless. I'll be saving data to a local database and forwarding changes later in batch mode. I'll need that object model. If that component is implemented on a server, a service facade could be placed over it. 

The point to all of this is that we are hearing a lot about why to do services and how to do services, but we aren't hearing alot about the design of the business entity that the service will be servicing. Are we supposed to change the design of the entity like the person at the BOF session was describing, or is it better to do business entities just as we have been doing and wrap them up in a service layer? I'm feeling that the later may be the better option.

Posted on Tuesday, June 14, 2005 4:09 AM Architecture | Back to top

Copyright © Jay Glynn | Powered by: