If one wants to select an important technology trend in Java world over past few years, then it has to be the growth and wide acceptance of open source frameworks in application development. If we look back, there are examples of frameworks which got wiped out with time, also there are examples of frameworks which have changed the way applications are getting developed. These successful frameworks have contributed to give a new look to Java itself. There are many reasons behind continued success of different frameworks available in market. I am not going to list and analyze what is good with those which have succeeded, and what went wrong with those which have failed. But, the bottom line is – these days Java application development involves considerable use of proven frameworks. What benefits we reap by using these frameworks? Here is the list -

• Proven technology assuring success of project
• Ready components to expedite development
• Huge support community to help almost in each problem
• Everything comes mostly free of cost

In this article, we are going to explore the architecture trends arising due to wide usage of these ready frameworks in application development. In this discussion, I am assuming reader to be aware of different popular Java based open source frameworks e.g. Struts, Spring, Hibernate etc.

Layered Architectures:

Architecture definition involves identifying tiers and further different layers to separate each unit responsibility. Definitely the driver is business requirement, which makes us to separate presentation from business and business from data access. Let us take following simple example where we have three tiers – web tier, business tier and database tier. Each tier has clear responsibility.

Presentation tier also called as web tier handles presentation part along with navigation from one screen to other. Additional features like managing user session, caching information etc. will be additional expected features in presentation tier.

Business tier encapsulates complete business logic. Business validations, processing, calculations etc. gets handled in this layer. Transaction management, security etc. are the enterprise features expected in this layer.

Database tier involves implementation of database interaction and processing of retrieved or to be persisted data. Database session management, transaction propagation etc. are the features expected here.

When we select ready frameworks to implement each of these tiers, different layers in a tier are identified by the selected framework already. We can customize these layer but up to certain extend only.

Predefined Layers with Different Frameworks:

The word framework broadly means ready components and skeleton on which we can construct a larger program. Some amount of flexibility is available to choose better alternatives suitable to the application. To explore it further, let us take each tier and try to identify layer alternatives according when we use different framework.

Presentation Tier:

Take a look at diagram above; as we move from one framework to other, the type of objects we use go on changing. Here Action, Controller, and Page Components encapsulate navigation logic. This means that when we use these frameworks we have to have a layer that contains everything related to navigation. If you remember the days of servlet, everything related to navigation along with request data extraction and population in data object used to be inside servlet code. Now we get the request data populated in mapped pojos, and what we need to do is identify next navigation point in these action/controller/pagecomponent classes. Framework takes care of rest of the things. Thus we have limited options in this tier with usage of one of these frameworks.

Business Tier:

This tier contains everything related to business. An application might require exposing the business functions as a service, and we decide to use Spring Webservice for this purpose. This implementation will require following simple layers.

Here the first layer just deals with webservice request –response-fault handling including marshaling and un-marshaling, while the second class contains actual business function implementation. These two layer can be clearly indentified in with usage of Spring Webservices.

Database Tier:

In this tier, we take example of hibernate framework which accesses oracle database.

Here business is simple, we require a Dao (data access object) layer that offers create, read, update and delete (CRUD) operations on data objects (which map to database entities directly).

With above discussion we can conclude that each (open source) framework has it’s own requirement of layers, when we select the framework we also identify these layers directly in our architecture. We can leverage little flexibility provided by the framework to customize it according to our needs.

Framework Usage View:

With above preliminary discussion, We can clearly see a need of representation that shows how different frameworks in different tiers interact with each other. Not only interaction but interaction in following context –

• Thread management
• Transaction management
• Data transformation (e.g. if you are using struts then action form is required but it can not be directly passed to hibernate as it requires conversion into object that represents database table.)
• Exception management support
• Individual framework benefits and constraints

This list can be longer depending on application and frameworks considered. If I want to draw a framework usage view then it will be as below. We can also include transaction, exception management support, points of data transformation etc. in following diagram and include this diagram in architecture diagram stack.

More Related Posts in Java