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.
Aspect=Annotation+Interceptor
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:
@Permission @Validate(name="..") @ExtensionPoint(type="Extension.PRE"...) //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....;)
4 Comments
