There are lot of frameworks which disappeared with time, also there are few 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. These days Java application development involves considerable use of proven frameworks. Below are some benefits we get by using these frameworks.
* Readymade components to speed up the development
* Developer community support to help
* As all are OpenSource, Everything comes free of cost
* Successfully Proven technology assuring success of project
Now, we will explore the architecture trends arising due to wide usage of these ready frameworks in application development, assuming readers 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 Layer:
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 Layer:
This layer 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 Layer:
In this layer, we take example of hibernate framework which accesses oracle database. 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).
From the above discussion, we can conclude that each (OpenSource) 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.
Kumar's Blog 