Originally posted by John Ranaudo:
When your defining your service contract why create a strongly typed interface as opposed to something very generic?
as opposed to
<row name="NetSalesRevenue" value="100000.00"/>
<row name="CostOfGoodsSold" value="100000.00"/>
The first approach puts a data model on our service which is easy to understand
The second approach (they prefer) is easier to consume because it does not take much logic to translate the response.
The other argument for the second selection has been that since the clients of our service know what an income statement is then they don't need structure.
Now I have read books on SOA and I understand the value of putting a model on top of your service but can anyone help me explain this benefit in a more precise way?
The more complex data types and programming models you introduce, the more tightly coupled the systems will be.
Harmonizing data types over distributed systems is a common and natural goal, because it simplifies data sharing. Be careful, though - once you have introduced a new fundamental type, you will probably never be able to get rid of it. Note:In one project, we defined the generic list for future technical data having a key, a value, a type of information for the value, and some additional hints on dealing with this value (e.g. one attribute allowed to define that service providers should pass this data through when they call other services while processing a service call).
snakes are really good at eating slugs. And you wouldn't think it, but so are tiny ads:
Free, earth friendly heat - from the CodeRanch trailbosshttps://www.kickstarter.com/projects/paulwheaton/free-heat