I had a great conversation yesterday with one of the IBM guys. He was very excited about aspect oriented programming, while I was promoting the service-oriented model. As we got deeper into the conversation, we realized that the concept of aspects were very applicable in the service oriented world.
In the SOA, we "apply" new functionality or "aspects" to a service via one of several mechanisms. For talking purposes, let's use the "logging" example. That is, an aspect that can be applied across a set of objects (or services) that log all the calls.
There are several ways that we can add functionality. Perhaps the most straight forward in the service oriented world is by using the pipe & filter. Here we simply pipe the output of our primary service into a new service (like logging) - and we've created a discrete, assembly line approach to adding functionality. The down side is that the each participant in the pipe chain must be explicitly called and the programmer is exposed to a significant amount of raw details that they may wish to avoid.
A second method for performing this feat is to create a "tightly coupled web service" - here we just hard code the stuff right into the web service. So service 1 is hardcoded to call service 2 (logging). Perhaps not the best idea, but likely the most common means in the first go-round of creating web services.
A third method is to describe the functionality at the protocol layer. Take WS-ReliableMessaging, this information gets baked into the stream and now both participants know that they should "apply" extra functionality to make it work. This is a great way to force the adoption of functionality with minimal impact on the programmer, but is really targeted at scenarios where 2 or more participants must engage in a conversation and have a minimal agreement. Dropping too many "aspects" into the protocol will create fat and rigid protocols that are hard to debug.
A fourth method for addind functionality to a service is to create a "composite web service". Here we have one web service front-end several services. A great example is using BPEL4WS. This allows you to call a single service and a script of services that it turns around and calls for you. BPEL is designed to be loosely coupled, where new services can easily be added. The neat thing is from the outside, a BPEL looks like web service - and it is. The BPEL method is a great way to create loosely coupled service composition, but it does it by standard flow-control mechanisms. Thus it takes on a loose coupled version of the pipe & filter model.
What I am looking for is the 5th way - and as far as I know, it doesn't exist (yet). I'm picturing a WSDL model that understands pre & post conditional apsects. Here the WSDL can have declarative aspects attached to it. The closest thing I've seen is "XL", see: http://xl.in.tum.de/publ/www2002.html
I'm not sure that this is the right way to do declarative, aspect based constructs for a service oriented world, but it sure the hell advances the thinking.
No comments:
Post a Comment