Tag Archives: hands-on

Introductory AOP (Aspect Oriented Programming)

11 Comments

I wrote this piece as part of my work….

Aspect Oriented Programming is one of the programming paradigms where secondary or supporting functions are separated from the main business logic. The major objective is to increase the modularity by separating the secondary functionalities as crosscutting concerns. The main driving force behind the AOP was Gregor Kiczales, who worked on AOP at Xerox Palo Alto Research Center (PARC) and developed AspectJ which is one of the most popular AOP packages available today.
Basic Concepts
The basic concepts involved in Aspect Oriented Programming are:
1) Cross Cutting Concern: This refers to the secondary functionality which needs to be separated from the main business logic. For example, logging needs to be performed by classes in our data access layer and also by classes within our UI layer. Even though the major functionality of classes in UI and data access layer is separate but the secondary concern (i.e. logging) is common to both. So, in this case logging functionality forms a cross-cutting concern (term cross-cutting is used as the functionality needs to be implemented in such a way that it cuts across the main functionality).
2) Advice: The additional code that needs to be implemented whenever a cross cutting concern is involved. For example, this can be the logging code which needs to be implemented.
3) Pointcut: The point of execution in the application where cross cutting concern needs to be applied. For example, pointcut is reached when we need to log information before entering a method and we need to log information after exiting out of method.
4) Aspect: Aspect is simply a combination of the pointcut and advice. So, if we continue with our logging example, then logging aspect involves the advice (logging code to be implemented) and pointcut (point where we need to execute our advice).
Support for AOP
AOP is supported by variety of frameworks, platforms and languages. As of now, nearly every major J2EE platform (JBOSS, Spring, Weblogic, Websphere) is supporting AOP. AspectJ and AspectWerkz are two most popular packages available for AOP for use with Java. Moving apart from Java/J2EE world, AOP is also supported by .NET framework (both C# and VB.NET), C, C++, Perl, Python etc.
Implementation
AOP can be implemented via a process called weaving, which involves the use of an aspect weaver reading the aspect oriented code and weaving it (or simply put as generating) appropriate object-oriented code with all the aspects integrated. The weaving methodology is language independent and the only factors which govern the choice of weaving are 1) implementation and 2) ease of deployment. Weaving process can be done in two ways:
1) Source-level weaving: Source level weaving can be implemented using preprocessors having access to modify source code files. For example, in case of Java programming language, source level weaving can be performed via bytecode weavers which can work directly on compiled .class files. Bytecode weavers can work during codebuild, or during class loading. However, this approach causes problems as some of the third party decompilers or debuggers are unable to process the woven code as they understand the code generated by Java compiler rather than the one generated by the aspect weaver. AspectJ uses source-level weaving to generated aspect oriented code.
2) Deploy-time weaving: In order to avoid the problem associated with source-level weaving, deploy-time weaving use post processing whereby instead of modifying the existing code, we subclass existing classes and any modification is carried out via method overriding. The existing code thus remains untouched. This approach is commonly implemented in Java EE application servers, such as Websphere by IBM.
Problems with AOP
The use of AOP involves proper understanding of crosscutting concerns which sometimes can be a difficult task involving clear knowledge of static as well as dynamic flow of a program. If a developer commits any logical error while implementing crosscutting, the effect may be widespread. Also, if joinpoints are modified again it might lead to breakdown across the application.

The New Service Layer Architecture.

2 Comments

I have been associated with 3 major softwares that were developed for corporates and large businesses. In each of them, I had seen somewhat common layered architecture where either a facade layer exists for the flow or did not.One of the three architectures had a dedicated facade layer on top of the service/business flows. Incidently it was the only application that was designed for the web.

That could be the reason where the architect might have envisioned mashups of business objects that might be requested from the client side.This decision seemed to be motivated by the controlled requests coming from the web vs the uncontrolled calls on a desktop application.But then, the speed with which the desktop applications have also started gaining back popularity since the past couple of years, it might not be incorrect to assume that the architecture of a web and a desktop application should overlap.The desktop applications are becoming more and more responsive and with an expert user the desktop application demand more challenging screens as compared to web applications.

It is with these understandings I propose the following layered architecture:
The core difference lies in the way the business service calls are divided into two sub layers namely:
1/Facade layer.:: Responsible for mashed-up/secondary business object screens.
2/Business Service layer.:: Responsible for manipulation of core business objects screens.

The process layer calls can go directly to the service layer and also can talk to the facade layer also.

For example, consider the problem domain of bicycles, where we are writing an application for selling of bicycles.

For the initial iteration, the service layer would be enough to cater to the needs of operations like getting a quote of bicycle from different sources, getting different color models, different frame sizes etc.

Later on the application owner might want to move to custom built bicycles where the complete bicycle is not the single object that is passed across the process and service layers, as wheels, frames,handle-bars,seat-posts all start bringing in different compositions for the custom build bicycle.
In this scenario, the facade would be a great place to assemble different parts of the bicycle bind them together and return to the process as the complete bicycle object.
Even later on when the bicycle sub parts are further broken down like the wheel composition can give multiple options to choose from, this structure can be extended further.

Some might argue that the facade layer can exist at the same level as the service layer. Quite true, but over a period of time when the service layer gets fat with lots and lots of business specific code being written, the objects that go in and out of this layer becomes unclear, as to the core set of objects around which the whole application revolves. This loss of focus from the core objects of functionality can result in a loss of a perspective in writing new code/flow for the application, the consequences of which can be differently dangerous in varied scenarios.

To conclude,I like this layout because:

1/ It keeps a unique object being passed across layers.

2/Multiple Do’s and Do not Do’s from design perspective get constrained for the developer.

3/Gives greater and cleaner objectivity to the flow of the objects in the complete application.The service layer can be controlled as one that caters to core business and the one that is responsible for supported objects.

4/Easy refactoring capabilities and pluggable architecture.

Is it fair to partition the service layer on primary objects?Does it limit the growth of the application(and business itself)?

What do you think?

Look Maa! No Tables Only Objects!

6 Comments

Databases are one topic that I have never had a chance to get deeper insights.

I started JDBC’ing when later I was surprised to know that one could connect to the database using ‘C’.

I had not worked enough to feel the pain of iterating over ResultSet and writing insert/update scripts that virtually went outside the screen when I saw the onset of “Hibernate-Relational Persistence for Idiomatic Java”. I never liked the writing/seeing/understanding XML, but I had no choice but to Well Hmmm!

And with most of the time spent in Hibernate, I never felt its features were intuitive to that of Java(in no specific order).

  • First and foremost in Java, Enum are first class citizens, in Hibernate, working with an Enum is not at all trivial.
  • Using composite keys asks you to maintain a seperate object for it.
  • Already there were two worlds of entities in Application(objects) and entities in DB(records), now to understand the two, one needed to know how Hibernate understands the two worlds.

For simple applications, Hibernate is way to work with, but with very large applications, I did not like the complexity that it brought in atleast two occasions, requiring extra time to keep the DB and the hbm files in sync.
It could be the incorrect way of not completely relying on hbm for schema generation, but because these applications had predefined schema’s, this was the only possible safe-path.

Issues with RDBMS:

  • Application<---->Mapping<---->DB
  • Cost of mapping conversion(second level cache’s are not enough!)
  • Transactions duplicates Locking- In general.

Tired of looking at xml, and with the option to write an application for fun, I have the option to evaluate the usage of Object Oriented Database.
I had found atleast a dozen implementation of such software, at the end it came down to db4o and Perst. And here is the summary of them:

db4o

  • Most commonly used OODBMS.
  • Easy to learn.
  • Supports intuitive Refactoring of persistent classes.
  • Support for Projections is not available(could not find).
  • Lazy initialization supported with default level of depth.

Perst

  • Has GIS Dataset
  • Fastest amongst all OODBMS.
  • Cryptic creation of indices for faster search.
  • Concept of Links for references pollutes domain.
  • No fixed DTD for import/export feature for refactoring.

Both the products have the following in common:

  • Support for Transactions.
  • Zero mismatch between object and saved data.
  • Confusing Licence!

At the end, I have to give in to db4o for simplicity and refactoring features.
And that’s where I would start looking at injecting it into the application.

Concerns about OODBMS:

  • Not Yet widely used – I wonder why?
  • Clustering – I do not need it.
  • Backup – RDBMS or File?
  • Optimization – Exotic feature than a requirement.

So I would look forward to working on the application on db4o and will update on the findings!

~rohit.

My JUnit Arsenal!

Writing unit tests for working on a piece of code is an exciting task that I enjoy.
To accomplish this with ease, for now my junit arsenal has the following approach:

1/ Mathematical Induction

2/ Boundary Value Analysis

3/ Permutation of the variables.

What’s yours?

Care to share?

White Code!

Today while working at my desk, I came across a situation where a colleague was writing some piece of code as a missing implementation when a module changed hands.
There was little time and so, the part had to be just written for the sake of it.
And that’s where I wanted to dis-associate myself from the partnership.
It so happened that the situation was getting complex and two heads were good at solving it.
I could not yet overcome my hesitation to help in a piece of code that would not be tested, so rather than saying this, I called it the white code: The one that was written on the white background of eclipse editor and never get through living in the main memory and get executed!
To my happy surprise, he got motivated and understood my hesitation and ensuring the missing implementation code was atleast working on a non matching scenario and breathe life into the code.
There we called it the green code:Simply because it was executed, not for complete scenarios, but it was executed!

Green is the way to go!