This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Re: SOA and Taking Services Further
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.
John Wood took me to task on my Common SOA Pitfalls post. Jeremy Miller's post on the same topic lead to quite an interesting discussion as well. In that discussion John seemed to propose SOA as a replacement for an OO implementation internal to a service as well.
Personally, I don't know any better way to implement business logic today than with OO techniques, also known as the Domain Model pattern. That's what's inside my services, among other things. If John has found a better, or different way, I'd be happy to hear it.
However, the issue of "internal services" is not something new to me. Arnon and I have been implementing exactly that in a current project - he wrote up some of our experiences here. Although we did dub them MicroServices, I stand by my original advice - Business Level Services. These micro services are really a different breed and thus I think that they should be given a different kind of name. Maybe "Independent Processing Unit".
These IPUs are the result of analyzing processes within a business service and identifying independent processing steps that can occur in parallel. See "parallelism" in "The Pragmatic Programmer". The trust boundaries that exist between services do not exist between IPUs. The creation of an IPU is often founded on increasing scalability by increasing the ability to run things in parallel - purely technical concerns.
One of the main points I make concerning scalability and SOA is that you don't scale out a service by running multiple instances of it. Rather, the service scales out internally, without anyone on the outside being aware of it. IPUs are a good way of achieving this.
Let's try not to overload the service concept more. It was too overloaded to begin with. For me, I'm going to replace that concept with the term Business Service for clarity.
Previous Topic
