This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Service Oriented Reuse
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.
Everybody seems to be talking about it. Services will enable reuse, the kind of which object-orientation and components never were able to give us. Cross-platform reuse - that appears to be the dream. In Nick Malik's recent post on Enterprise Architecture he describes a world that appeared so close after OO and components reached critical mass, each.
"I can say 'I've been working with this other team, and they built a bunch of apps based on shared services. Those services do the same things that you need done. The services catalog is at http://servicecatalog and I expect you to use those services. Take a look. I will review your design doc. If you aren't consuming those services, you will stop. If you are adding to the list, I'll be thrilled.'
Then I sit back, and watch the 'next generation web' launch itself into success."
Does the fact that something is called a service make it easier to reuse? I don't think so. I think that the easiest thing to reuse is a library, like the .net framework - I reuse that code everywhere. A component is a bit more difficult, especially if it runs out of process and I have to marshal calls. External apps are even harder, even if they run on the same machine. By induction, I'd think that a service, being larger than all of the above, would be harder to "reuse".
In fact, I think that if you're trying to reuse a service, your boundaries might be wrong. Let's consider why you'd want to reuse a service. It has some functionality you need, obviously. But is probably not some dinky little functionality like a math service, or a date transformation service. No, its a big piece of functionality, like a "Customer service" - the service in charge of everything dealing with customers. And now your Order service needs to do some complex validation of shipping addresses that already exists in the Customer service - that's what you want to reuse, right?
The short answer is that you probably shouldn't divide services up according to entities. Just to keep the suspense high, my reason for this will be found in the next issue (#8) of the Architecture Jounal.
Previous Topic
