SOA and AOP
A while ago I wrote a post regarding the difference between SOA and CORBA. I saw this assertion on a few bulletin boards a few times and I felt I needed to write about it. Well, if SOA is different from CORBA then what would it be similar to?
Let’s say that you have an enterprise-wide service. Let’s say that a financial institution needs to apply taxes to every financial operation it makes. The enterprise-wide service would be the tax program and the actors would be the software programs that trade currencies, stocks, bonds, accrue interest, etc… Every trade that gets made has to get taxed so your tax service has to interact with all pretty much all the software in the enterprise.
Now suppose that you have this gigantic application that a financial institution uses for making stock trades, buying bonds, applying interest to accounts, etc… Obviously all the financial operations must be taxed. The easiest way to implement tax across all the financial operations would be thru AOP. You would define a tax cross-cutting concern and bind it to the appropriate methods.
The cross-cutting concern would exhibit the same relationship to the application as the SOA service exhibits to the enterprise: they are identical pieces of functionality that apply to very different actors. The cross-cutting concern applies to various methods in an applications, the SOA service applies to various silos in an enterprise information system. From a functional point of view a cross-cutting concern is very much like a service. There is a huge difference in scope between the two concepts, but at the bottom of it they are very similar.
One more thing. SOA is considered the domain of business analysts, the business analyst driving most of the interactions between different services and applications in an enterprise information system. Given the similarities between SOA and AOP it would seem that AOP would be best effective when the interactions between aspects (or services as they are known in SOA) and methods (or applications as they are known in SOA) are managed by business analysts rather than developers…
Good food for thought…
Later edit: I understand that currently the advices used mostly in AOP are concerned with infrastructure issues (concurrency, security, transactions, etc…). However, AOP leaves the door open to assembling applications so that you can bind a piece of functionality to another piece of functionality like the above example with taxes. In this case the usual pointcut semantics will probably not suffice (unless you use annotations) because the advices will not be applied to objects which are related by infrastructure issues (such as persistence or concurrency) and are grouped together by namespaces (such as package names), but rather to objects which are related by business-logic issues (such as manipulating funds). This grouping is probably harder to translate into pointcuts.
Anyway, I think the interesting development in AOP lies with applying advices because of business-logic affinity rather than because of infrastructure needs.
