Muddled definitions of services

The other day I got an email from a guy named Bill who was having some trouble understanding the state of the guidance around SOA coming from the different vendors. I thought that the back and forth I had with Bill would be valuable to others so I decided to relate it here.

Hi Udi,

WCF defines a service to be implemented as single .NET class which implements one or more interfaces (contracts). These contracts are then exposed as one or more endpoints.

It’s a technological view, but I don’t like it. A class, or its corresponding object, do not a service make.

Other definitions seem to indicate that a service exposes the functionality of a whole application. You indicated in your section in Jimmy Nilsson’s book that it would constitute one EXE or one Web application root. This would imply multiple ASMX or SVC (in WCF) files per service. This seems to be contradictory to the WCF definition of a service.

I have no problem contradicting Microsoft, considering the fact that they so often contradict themselves.

Moreover, general consensus is that in order to maximise autonomy between services, they should not share a common database. If we are to always implement an entire service using a single .NET class, then this would imply one database for every service component.

Agreed on the autonomy. A DB per class is obviously wrong.

Microsoft certainly does not make it easy to share data types between different “services” – which would make sense if we are to implement a separate database for each service component (since they operate on different data domains); but doesn’t make sense if we are to have multiple service components at different addresses sharing the same database as part of the same logical “service”.

All these service classes should be working against the same domain model. There should be very little logic in the service classes themselves – translate the message/call to calls on the domain model (within a transaction as necessary), then build the response and send it. You shouldn’t need much interaction among the service classes.

So does this mean that a “service” has a dual meaning – one is an individual service component and the other is a collection of service components constituting a single unit of deployment? If this is the case, then I think the industry needs to work towards clarifying this definition and perhaps describing the two concepts with different terms. For example, the 4 tenets of service orientation wouldn’t apply between individual service components as part of the same service – but reading the MS technical articles seems to imply that they do (since the word “service” is applied universally).

No dual meaning. The guidance that I’m putting out calls these kinds of classes “message handlers”. No room for confusion there. You could easily have multiple message handlers in the same service. A service could also, therefore, have numerous endpoints and support various transports. Microsoft has to do a better job in the guidance its putting out.

I thank you for your time and hope that you might be able to help clarify some of these loosely defined concepts in the community.

You bet. I hope that this makes better sense now. Don’t get too hung up on what Microsoft says, do what you think is right, and getting a second opinion is a great way to do that. Let me know how it all goes.

--

Many thanks to Bill for his great question. If you too have a question regarding SOA or Web Services, don't hesitate to fire off an email to Blog@UdiDahan.com, and you can always check out my site for more in depth information: www.UdiDahan.com.

Posted by Udi Dahan at 04:51 PM  Permalink