Additional Blogs by SAP
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

The 'Composition Application - Missing Manuals' initiative hosted on the SDN Code Exchange Platform aims to create a productivity starter kit and sandbox system for the development of Composites by providing technical libraries and an easy demo app documenting its features & how-to use them.

Links: Composition Application - Missing Manuals | Twitter

All of us have heard about "lowering the TCO" but what about "lowering the TCP"?

What is TCP and why should we care about it: Total cost of provisioning is the direct and indirect cost that is expended when you need to provide a service.By service provisioning I here really mean the effort(time,support infrastructure cost..) put in developing,maintaining,enhancing and supporting an application.It is imperative that we try to keep this cost low so that we can go and enjoy that movie which got released this Friday(read have fun!).

How do we do this?

The answer is always the same. By keeping the application architecture flexible.

Separation of concerns(#SoC) is one of the key pillars of achieving flexibility.The principle of #SoC states that each component of the application should really concentrate on one particular concern and there should be minimum overlap between different components.This can be achieved easily for  the "core concerns" .But there are some concerns that span accross multiple application components.Some of them being:

  • Authorization
  • Logging
  • Performance
  • Validation

These concerns are called cross cutting concerns.If not coded the "aspect way" the application code becomes cluttered with snippets of "conditional" and repetitive  coding.[something referred to as code tangling and code scattering in classical texts on AOP]

Let us take an example of a service operation that creates an employee the "non-aspectized" way:

 EmployeeCreateConfirmation createEmployee(EmployeeCreateRequest request){  

//log request structure

 //check user has permission to create employee

 //validate the user ID is valid

 //validate that the user does not already exist

 //create user


Other service operations would similarly need to have duplicate code to log the request structure,to check if the user has the valid permission and to validate the request against some semantic and static validations.Such a design clearly violates the principle of #SoC and over a period of time the code becomes difficult to read,manage and maintain.

Aspects to the rescue..

Aspects encapsulate the cross cutting concerns as modular units.They can be used to add behavior to an object in a non-obtrusive , clean and modularized way.

How do we realize these aspects ..

Aspects can be realized in composite applications by using annotations and interceptors.


The annotation specifies the metadata for the aspect and is used to "hook " the aspect coding in the normal flow of execution.The interceptor  invokes the code that centralizes the concern for the aspect.This usually involves detecting (via reflection) whether the operation has been annotated with the respective annotation and then passing some of the information captured in the annotation to the aspect invocation.

This is how the service operation would look like with aspects: 




//Interceptors for logging,time profiling

EmployeeCreateConfirmation createEmployee(EmployeeCreateRequest request){

//create user


@Permission,@Validate(name="..") and @ExtensionPoint(type="Extension.PRE"...) are custom annotations.As already visible we need to write lesser #loc and the principle of #SoC is clearly obeyed.What we could finally target to acheive is designing a highly loosely coupled system by leveraging  annotations and  wild card interceptor/s (* binding in ejb-jar.xml) 

What is interesting to note is  that combination of annotations and interceptors can also  be used to provide non-obtrusive extensibility to your application. @ExtensionPoint annotation can be coded to have three modes pre, post and substitute.Based on the mode the extension interceptor can decide to plugin additional code before or after the method call or simply substitute the method invocation.Some very interesting articles on such a technique can be found here.

Stay tuned....;)

0 Kudos
hi Shobbith,

Nice blog. Firstly Spring AOP was required to do this. Since EJB3.0 is adopted in Java5, it is part of standard Java. Although these techniques are not new; would love the idea of SoC with aspects be taken further forward.

Former Member
0 Kudos
Hi Shobhit,
Nice blog. We have been in the same boat for some time now, so understand the benefits of Aspects. But few things I wanted to share from my side.

1. Performance hit - I am not sure when does the code weave in our infrastructure(NWCE). But, I suspect it is during run time and hence people might face few unpexpected performance bottlenecks. Also, it would be harder to unit test if code is weaved at run time - The permission checks, entry code, exit code might have to be coded manually while unit testing

2. As a newbie, I find it difficult to debug the code. Suddenly a piece of code is executed and it becomes difficult to track which code is running - ofcourse one can read the configuration xml file - but it reduces the TCP little bit 😉

0 Kudos
Hi Puru,
Glad you brought this topic up.However having sailed in the same boat ...

As with any swiss army knife the aspects need to be used wisely.
For a noob they might be hard to understand and debug,however the learning curve is usually small as the apsects  really centralize a chunck of coding that would have otherwise been present  at several places.Understanding this should be a one time effort and will pay off in the long run.
Performance might be an issue but again there would be a performance hit not because of coding the aspect way but because of the coding that the aspect executed.This coding would be a bottleneck even if aspects were not used and then imagine fixing the performance bottleneck at several places in your code...

Best Regards,
Active Contributor
0 Kudos
Valid topics you bring up here.

From my point of view I have to admit that the combination of annotations and EJB interceptors result in a minor usage of reflection API, which may some attribute any potential performance loss.

If properly coded, such interceptors (especially if bound via wildcard mapping in the ejb-jar.xml) should first check for the existance of the annotation/cross-cutting aspect they handle. In case the interface/class (another interesting discussion!) is not annotated the process flow should immediately return out of the interceptor. [I'd also promote to not code in the interceptor anything that is specfic to the annotation/aspect -> the interceptor only intercepts and delegates to the aspect handler - SoC.]

Instead, I'd argue that this design caters to the fact that cross-cutting concerns (e.g. permission and data validation) are handled up front and as such avoid a lot of unnecessary processing that may would have occured otherwise. Consequently, the payload in total should decrease.

I yet have to see the benchmark that shows me the concrete overhead resulting out of it (Puru, want to give it a shot? -> Challenge!). From my xp, insufficient queries and unnesessary DB calls are far more common performance bottlenecks.

... and, at the end of the day, I'd take a performance decrease of up to 10% easily if I can get a clean/flexible design and trade the slightly higher hardware costs in for the long-term reduction of TCO (constant refactoring and maintenance.)

I agree with the documentation and expertise level though. You know my stance on it.. I think that proper software programming is a craft that takes time to develop and master (if that is actually possible!)

As such, aspects are just a tool/pattern for our toolebox. It's upon the user to know and pick the best suited tools 🙂

It kind of goes back to the downhill developer discussion...