This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: On Service Definition, Responsibility, and Decomposition
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Late one night over drinks at TechEd Developers in Barcelona, discussion among the Israeli delegation (Noam King, Alon Fleiss, Yosi Taguri, and myself) turned to SOA. I swear I didn���t force them into it. Anyway, after some debate over what does and does not constitute a service (we all agreed that functions that accept or return XML over HTTP do not), Alon proposed his own definition.
���A service is software hosted on a service host that gives value or functionality that can not be part of the client software. The client & service has to partly understand each other to get the value.���
I understand where Alon is coming from but every definition I���ve ever heard for a service, or SOA for that matter, seems to focus on the service pretty much in isolation from other services. One of the main challenges I encounter when designing large-scale systems is what services there should be, what they should each be responsible for, and how they should interact. I have yet to see a definition that helps me out in that respect. I focus a lot more on inter-service interaction than client-service interaction. And it���s not that I don���t get involved in the architecture and design of client-side software, I feel that it is absolutely necessary to get hard problems like threading right before we get started.
I���ve written a lot about inter-service interaction already so I���ll just give a short summary of my thoughts here. Asynchronous, message-based communication with the common case being publish/subscribe has been much more successful in my experience than synchronous request/response. Furthermore, when ACID transactions are kept entirely in the scope of a single service, I have found that those services are often responsible for a coherent fracture of the business domain.
The problem with client-service interaction occurs when viewing the client as something other than a service. If the client is not a service by design, then that would make it part of a different service, and thus more tightly coupled and not required to use the above-mentioned communication patterns. The purpose of a ���client-service��� is to enable the user to send commands to, and receive notifications from the services with which he interacts.
It is probably for this reason that I have a hard time analyzing examples like that given in Alon���s post. I don���t think that it���s possible to reach valid conclusions about the division of responsibilities in a domain without having the entire context. Web services like those exposed by Amazon and Google are, in my opinion, components exposed over HTTP using XML and SOAP. In order to judge their validity, we���d need to focus on the use of those components in a larger solution.
It looks like we���ll never be able to reach an agreement on these topics due to the kinds of problems each of us face in our projects, and the kinds of solutions we attribute to the term SOA. The truth, as always, is somewhere in the middle.
Previous Topic
