EDABlog

Are OO code and SOA diametrically opposed ? In a lot of ways this is true services tend to produce very anemic object models however this merely reduces reuse which is a myth in OO for the majority anyway .

However services have a unique but familiar problem . The contract of the service is critical it needs to be designed for

 - The ease of use of the client 

- For performance  ( ie chunky calls , many small calls can bring many services down to its needs)

- To be upgradeable and allow backward compatibility.

- Compatible with an XML schema ( eg generics and interfaces create problems)

- Best to be compatible with WS standards and non Windows Communication Foundation clients ( eg nullable datetime ,  no char , long etc )

- Only sub object and collections needed for this call need to be propagated which is not all the objects and collections a object may contain.  eg Order GetOrder(..) may contain OrderItems which contain Products but no more information about the product such as supplier etc . This is best described as truncated trees.

( see how to write a good contract)

This is dramatically different from an OO structure  where ease of use is not high on the list else we would all be using statics , however its very similar to a relational database and its structure.

Does this mean services are similar to databases ( eg Procedural Programming)  ? From the outside yes and smaller services probably should remain Procedural and non OO . (A good example is in the LINQ and services article)

However larger services should retain a significant OO core with a focus on code quality , testability and maintainability however this requires a reverse ORM which maps from the messages to the internal logic.  Microsofts P&P Web service factory includes converterts exactly for this purposes and its a good pattern to follow.

Even in small services when mapping from a  DB to messages there is a case for such a conversion layer ( and DTOs)  . Take the case of LINQ for sql if you add a member to  a DB table for some new functionality meant to be visible to a select group do you want every client to now have this information in the data sent down  ?  If custom message contracts were used only the new operation and contract used by the select group would get the new information however all the logic would be common ( just the privileged data would not be copied to contract) . If custom message contracts are not used the team would be forced to create a new schema copy of the data for the same table which would be identical  except for the one member as can be seen over time this would reduce maintainability of the service .