Service Oriented Analysis

The roundtable on Service Oriented Analysis was interesting, because it showed the culture clash between 'Pure Object' guys and 'Service Oriented ' guys.

Martin Fowler was the OO guy and someone from the Indigo team whose name I cannot remember was the SOA guy.

Fowler was quite ironic about SOA. He said he did not know what does SOA mean, and that the meaning changes every 5 minutes. In his mind, SOA was about application integration. If you have a property layered application, then SOA is just adding another layer to adapt the inner interface to the Service Oriented one. Inside the application domain, you will keep using thightly coupled OO classes.

The Indigo guy view was that you can use SOA even inside applications (i.e., inside different teams), and it was a much more pervasive thing. The audience seemed to like Fowler's point of view, as there were applauses after some of his comments.

At least there is agreement that you should not expose your inner object model in the service layer, something that was not at all clear in the times of DCOM and CORBA.

I'm closer to the SOA guys than to the OO guys.

4 Comments

  • Interesting. But not important enough do post it two times :-)



    Ok, I am with Fowler. I LOVE SOA. But SOA is for system coupling, not for use within one application / system. It takes a lot more work and is way less stable against changes.



    Now, yes, serviecs are more stable WHEN a change is done, when this is planned etc., But with objects I make a change and the ocmpiler tells me what of my objects dont work anymore. Within one application this is more useful.

  • Was the SOA guy refering to using "Manager" classes only with static methods(i.e. service classes with service methods) inside the service itself ... which would mean that state is passed around(in the form of simple data transfer objects/structures/datasets) through all the layers?

  • "I'm closer to the SOA guys than to the OO guys"



    What are your arguments? Btw: I'm with Fowler btw.

  • I think that in most cases having the domain data and the behavior in different places is a good idea, even inside one application as a way to exchange data between layers.



    Most OO guys have one object model, they use it in the BL layer and they also use it in the presentation layer.



    I don't like that. I adds a lot of coupling between layers and makes the contract between the presentation layer programmer and the business logic programmer not clear (i.e., they really don't know the data the object has because sometimes the data is lazy-loaded).



    Inside one _layer_ I find less issues on using a full OO approach, but I still have some. I like the relational way of thinking about data. The relational database theory is the highest expression of having data independent from behavior. I like the idea of getting the data I need with the structure I need in each use case, and I cannot do that if I follow a full OO design.



    >Was the SOA guy refering to using "Manager"

    >classes only with static methods



    They support stateless and stateful services, even if they say stateless is the way to go.



    >It takes a lot more work



    This depends on the tools you use and Indigo makes it simple.

Comments have been disabled for this content.