The piece I personally continue to struggle with is the luggage that comes along with the service boundary as depicted in the SO images. I realize there is no dictate that the service boundary most be realized with Web Services, but I think it is the generally implied boundary/interface. And once we describe the boundary in terms of loosely coupled SOAP messages, I think the dynamics of things really change; especially in terms of the design of Application A.

In the first three diagrams (object, component, distributed), we have an application that is tightly coupled with types A, B, and C, and/or components A and B. One might even make the argument that these types and components ARE in deed the application, or at very least make up its core functionality. Sure, the application will have some sort of interface edge, probably assumed to be a GUI. But the application itself is the interrelationship between the behaviors demonstrated by types A, B, C and components A and B and its edge interface. While, the mechanics of how these types and components are linked (direct in process, remoting, ES, etc) may change between the first three diagrams, I think the overall application is consistent.

As we move to the last three diagrams (the SO diagrams) this changes dramatically. Types A, B, C and components A and B are now parts and combinations of what I think are two new applications; Service A and Service B. At this point Application A and B are something altogether different and initially will not have all the behavior that the old Application A and B did (not without some significant duplication of effort). The two new applications (Service A and B) may provide some of the behaviors of types A, B, C and components A and B grouped up into some course grained service interface points (which in most implied cases will be realized with web services and SOAP). However, there are a few important (and drastic) things that happen.

The things that once were Applications A and B now have to account for an awful lot missing behavior. It’s fine to think that some of this missing behavior is provided through Services A and B, but I can’t assume that it all can. Additionally, what is provided will more then likely be packaged up into various degrees of coarseness. In order for Application A and Application B to provide the same functionality as they previously did, some thing(s) in Application A and B now need to make up for the missing behaviors between types A, B, C, components A and B and the new applications of Services A and B. More then likely to keep the functionality of Application A and B the same, I will need to create some things that look an awful lot like types A, B, C and/or components A and B. These like things will need to demonstrate all the missing behaviors between the real types and components and what is provided from the new service applications. More then likely, these new things built for Application A and B will be agents that help map the granularity difference between the missing behaviors of the old types and components with those of the new services.

If I’m building an application today, and I want to build it with cost (time, energy, effort) and performance metrics in mind, and if Services A and Service B do not yet exist, then I don’t think I would feel compelled to say that creating Services A and B (especially with a Web Service/Soap interface) would be in the best interest of Application A. At least not today. It would require way too much duplicated code and logic inside both. Maybe this landscape will change overtime and specific things like Indigo might make the fact that my interface between the application and the services it uses feels more like an application and its components/objects of today.

However, if I’m building Application A, and Services A and B already exist, then it would make all the sense in the world to use these services. And I might even feel compelled to suggest Web Services / SOAP as the interface point. If over time, my new Application A can provide value and benefits to other Applications, then it would make all the sense in the world to create another interface to Application A besides for its current GUI that will expose this added value behavior to other applications.

It’s the concept that types A, B, and C are always best served by being wrapped up in Components A and B, which are always best served by being wrapped up in Service A and B, which are always best served via a Web/Soap message interface that still has me concerned. I’m not suggesting that you are implying this. But many people I speak and work with are making this assumption. It’s the piece that I still don’t get.

I think Scott's comment touched on some of my own issues with SO methodologies. We're currently tossing around ideas with regard to a platform re-architecture and trying to incorporate SO into that architecture. We'd like to have at least one business tier that exposes its functionality through a series of services that can then be subscribed to by any number of consumers. We toyed with the notion that our own web UI would itself be a consumer of services exposed by the business tier with the goal being to not initialize any business objects locally. This would then serve as a role model for integrations with other parties. However the means of communication between the layers has proved challenging. To hide most or all business logic behind Web Services in a high volume web environment is just too slow. Remoting, though faster, presents challenges as well. We've found the overall cost of performing an operation via Remoting, for example calling a remoteable object X number of times to insert into a table, is twice that of a locally instantiated object. Another quirk is that you cannot use static methods on remoteable objects. If you do call a static method, the local assembly which provides your object stubs will in fact perform the operation.

In addition, SO by its very nature requires one to think about strategies to degrade gracefully in the case a service required by your operation is unavailable. This is implied in any architecture strategy really, but more so in SOA I think. Taking Scott's example, when you de-compose an application that used to self-contain types A,B, and C and then encapsulate each of them into their own service, you have to add code to each of them to specify what needs to happen when a hand-off is unsuccessful.

I'm just curious if anyone out there has published any tips with regard to inter-service communication for high volume and responsiveness. Perhaps SOA isn't the right approach for this particular part of our application infra-structure.

Where'd all the pretty picies go? I bookmarked your entry in my aggregator as a "must read all the time sometime later when I actually understand some of this stuff" but I figured it might be easier for me to throw the pics into a file and reference that. I come looking for them and the links are broken. I try to save as download them but no dice, then when I click on them I get a 403 error saying it's forbidden. It seems like the files are still there, but they're not given the correct permissions or something.

Anyways I thought that maybe there was a problem with the pics so you took them down, but from what I could see in the quick glance I took, they looked spot on. I'm a visual learner and those pics would have taught me more than a fleet of articles on the subject, and I'm probably not lying when I say it either.

Thanks again for the post though. I definately can use it to look at your older post on the subject but those pretty pictures are what kept me coming back.

I confess, I don't have enough comprehension of the underlying concepts to understand the pictures without more caption... yet.

Here we see the limitation of the aphorism -- the picture's only worth 1000 words if the viewer has enough of the artist's context... Without that context, each picture is worth 10, or 10,000, words -- and neither is useful to communicate what you hope to pass.

Perhaps you might add some more caption, and explain which of the several progressions visible here were intended to be highlighted?

vdhtcm rjtscdipz eaoqbpnfj cgnbyfqh dhlq fnvp iocntjzv