This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Autonomous Services - a step beyond Service Orientation
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.
After starting to write a whitepaper on Workflow in Service Oriented Architectures, I wanted to reference some prior work published on autonomous services (so that the whitepaper wouldn't turn into a book). Anyway, after some futile googling, I've decided to give in and write it up myself. The tenets of Service Orientation as put forth by Microsoft include one about âautonomyâ. The tenet states that âServices should be autonomousâ. After some digging, I found out that the intent of the authors was âThe teams that develop different services should not be dependent on each otherâ, or in shortened form âAutonomous Teamsâ. This revelation was surprising to me since the real meaning of the tenet was less profound than what I had imagined â autonomous computing. The idea of autonomous computing has been around for some time and presents a view of the world in which computing units cooperate to achieve global goals yet are not dependent even on the existence of other computing units to function. (If youâre envisioning tiny robots playing soccer, youâre not far off.) So when I first saw the autonomy tenet, I was thinking of autonomous services: services so loosely coupled that the correct functioning of a service would not be dependent on the correct functioning of other cooperating services. Services loosely coupled in time as well as in code. Obviously this would mean that if Service A needed to cooperate with Service B, and Service B was not even available, Service A would continue to function, and live up to its service-level-agreement. But before we start drifting off into the outer reaches of business-IT alignment, letâs bring this down to earth. Before we get into a detailed analysis of the how, letâs first agree on the why. Despite being a historical trend, architectures these days tend to be more loosely coupled than before. Loose coupling being a good thing that enables us to better manage the complexity inherent in large software projects. The practical test of loose coupling in a system is changing the public interface of a class and seeing how much of the system doesnât compile any more (dynamic languages aside). Service Orientation brings us tenets that, when followed, lead to more loosely coupled architectures than if we actively did not follow them. I think that we can agree then that if we could somehow achieve the loose coupling in time mentioned above, without paying an arm and a leg, that would move our architectures another step forward. Looking back on the evolution of the field of distributed computing, we can see that, over time, less and less things are being assumed. It is now well understood that anything that goes over the network takes much longer than those calls that stay on the same machine, yet once systems were built that abstracted the network communication into looking just like local calls. The performance of those systems was matched only by their lifetime. With the advent of autonomous computing, the assumption that the...
Previous Topic
