David Chappell writes about Reuse in Service Oriented Architectures. Aaron Skonnard jumps in, adding to the discussion. Aaron points to Benjamin Mitchell's sum of the note, which ties back in some of Clemens' elaborations on the four tenets, especially the autonomy tenet. I think Aaron's pulling Biztalk [or more generally, the business process solution space] into the discussion is pretty critical, because I think that is where the real long term value is with respect to reuse. And that is what this note is about to me. Futures. Promise. Hope. But I think it is still pretty early to consider this whole SOA == Reuse thing a done deal.
I think the gem of Chappell's piece is the following paragraph:
There’s no need for draconian enforcement of reuse rules. If a client needs to access the customer information this application maintains, the only way to do it (in a well-designed SOA environment, at least) is by going through the services the app exposes. As long as the underlying data can’t be accessed directly by any and all comers, a service-oriented approach requires reuse—there’s no other way to get to the information.
You definitely get a lot of benefit from taking a services approach, but standardizing on services as the fundamental unit of integration across the enterprise is a non-trivial task in and of itself, it is a largely political task, and it isn't easy. Turf wars, Not-Invented-Heres, goofball [or not] legacy dependencies, and the drive for new features are going to make it an uphill fight. A fight worth fighting, but definitely uphill. And the simple truth of the matter is that legacy, stovepipe apps are how they are because they got that way, and enterprise architecture patterns like entity aggregation exist because people, sometimes even purposefully, chose not to reuse the existing solution. In some cases, that was the best decision. In some cases, it still is. Services are about "loose coupling," but sometimes even a service isn't enough of a floozy. My personal prescription is as follows:
- When integrating systems, prefer using xml messaging over a standard, IP-based [application] protocol.
- Remain loyal to the four tenets of service orientation.
- Prefer transactions over batches.
- Focus on business services, and allow the services to partition the enterprise solution space.
I think the lump of mud in the piece is the following paragraph:
There’s no need for everyone to agree on a single definition of customer. Instead, any client that needs to access this application’s customers must conform to the definition of customer that the app’s services expose. If a client’s view of customer is different, it must somehow map that view into the definition exposed by the service it wants to access. While agreeing on a common notion of customer might be nice, it’s not required for the client to reuse this application’s services. Changes to the service can still be problematic, although only externally visible changes are a concern for clients. Unlike object reuse through inheritance, changing the guts of how a service is implemented won’t damage others who depend on this service.
Don't kid yourself on this one. David Chappell has been around the block a lot more than I have, and is a very smart guy, but he is wrong. You *most* *definitely* *are* going to have to agree on a single definition of customer, and it is going to be owned by the Customer service, and any changes consumer A wants to the defintion may have an impact on consumers B-Z, so you have to get the versioning right, and getting the versioning right is hard, I don't care who you are.
I think I may have said this before, but it bears repeating. When I was teaching OO many moons ago, we used to recommend the following rule of thumb with respect to reuse:It will take you at least three times to create a reusable (library | class | framework).
Jef's first corrollary: If this is your first time implementing an SOA, expect to screw it up at least one more time.
Jef's second corrollary: Be pragmatic: don't sweat the reuse. Sweat the value. Let reuse be a business problem. If business has a business case for reuse (agility, cost reduction, time-to-market), then implement reusable services.
Don't shoot yourself in the foot, of course. If there is an obvious reuse opportunity, take it. But I wouldn't sweat it too much. I think services, and more importantly, messaging, are the key to building interoperable systems. I think that the general architecture brings a lot to bear. But I think that reuse is still a bit Grailish.
Comments