Monday Sep 02

Three tier architecture with Maven

Sébastien Dante Ursini
PDF Print E-mail
Tuesday, 05 April 2011 17:44
Written by Sébastien Dante Ursini
AddThis Social Bookmark Button

Introduction

Developping large Java applications generally requires a three tier architecture. We won't explain the benefits of three tier architecture in this article. A large number of websites describe these architectures but only a few of them describe how to implement it. We will describe a solution in order to enforce this architecture without needing the goodwill of any project members, because this architecture is implicating many developers or even offshore people, and resumes often by continuously enforce the rules.

To insure the tightness of each layer and to guaranty the good use of each one of them without requiring a perfect knowledge of the architecture by each contributor, can be reached by using Apache Maven . We will describe how to implement this paradigm in a defensive way.

Three tiers architecture diagram

Implementing a three tiers architecture

In order to guaranty the isolation , lets imagine that each layer is communicating with the upper layer only by his public API .

We will define our three layers in three distinct projects. The lower layer projects are only dependant of their upper layer, preventing any direct references to the upper layers implementation.We will define a pattern/filter allowing us to distinguish the classes belonging to the implementation from the classes belonging to the interfaces. The presentation layer is always referred as the lowest layer.

Sample classes description

Lets take the example of an account managing application. The customer layer, via the account controller requires the account manager to achieve basic operations linked to the account management. We will not linger on the control or service pattern notions. We will essentially look into the relation between the presentation layer tier and the logical layer tier .


As an example, the following classes from the business layer :

sample class in the tutorial about three tiers J2EE application

There are implementation classes ( AccountManager.java , A ccountModel.java ) and there are the inferfaces , exceptions classes or class types allowing the communication between the layers. The implementation classes should not appear in the packaged jar of your J2EE API, to avoid the lower layer to refer to it.

The GUI packages sits in the project Presentation (uiProject), the other packages are in the Business layer (businessProject). We will define the pom (Project Object Model) corresponding to both projects.

Once this defined, we can generate 2 artefacts per project.

  • One artefact containing the API and the implementation
  • One artefact containing only the API


Definition of theclientjar artifact of the business layer

We will create a filter allowing to distinguish the classes contained in the jar API of thebusiness layer. Here are the criteria :

  • **/client/**
  • **/exception/**
  • **/type/**

In the MavenPOM(Project Model) we will configure the plugin jar in order to create a jarcontaining only the API classes in accordance with the filter above. Our complete artefactbeing create by default, we now work on our artefact API definition. We will take forexample the business layer tier .

three tier application architecture pom

<project>
      ....
 <groupId>com.ubiteck.sample</groupId>  <artifactId>businessLayer</artifactId>   <packaging>jar</packaging>       <build>
		<finalName>Business Layer</finalName>
		<plugins>
			<plugin>
				<artifactId>maven-jar-plugin</artifactId>
				<version>2.3.1</version>
				<executions>
					<execution>
						<id>jar-api</id>
						<phase>package</phase>
						<goals>
							<goal>jar</goal>
						</goals>
						<configuration>
							<classifier>api</classifier>
							<includes>
								<include>**/client/**</include>
								<include>**/exception/**</include>
								<include>**/type/**</include>
							</includes>
						</configuration>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</project>

Packaging a three tier Maven application Then launch the Maven package command in the Business tierproject to generate our jar API.

cd ../businessLayer  
mvn package  

Eclipse configuration

Configure the eclipse plugin to not reference the project as references. If you don't define it your eclipse configuration will reference the Business layer project instead of your library giving you full access to the implementation

Maven Pom Eclipse plugin

 <plugin>   <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-eclipse-plugin</artifactId>
  <version>2.8</version>
  <configuration>
  <useProjectReferences>false</useProjectReferences>
  </configuration>
 </plugin>

Dependency management

We will now define in the presentation layer tier the use of the the business api

presentation tier reference to business tier

	<dependencies>
  		<!-- ****************************** -->
		<!-- * Business Layer Api Only * -->
		<!-- ****************************** -->
        <dependency>
            <groupId>com.ubiteck.sample</groupId>
            <artifactId>businessLayer</artifactId>
            <version>1.0-SNAPSHOT</version>
            <classifier>api</classifier>
        </dependency>
        ...
   	</dependencies>  


This done, we can now refresh our dependencies on the presentation project tier.
Eclipse configuration for three tiers architecture

cd ../businessLayer
mvn eclipse:clean eclipse:eclipse

Nous constatons maintenant que le projet uiLayer ne dépend plus du projet Business Layer mais seulement de la librairie business-Layer-api
UI layer dependency graph

Conclusion

We now notice that the presentation layer project doesn’t depend anymore on the Business tier project , but only on the business tier api library.

We now have 2 projects, one containing the user interface and another containing thebusiness logic. All references of the interface layer with a implementation of the Businesslayer will not be made without generating a compilation error. Our layers are isolated.

There can't be any circular reference, neither any reference going in the opposite direction,neither any other reference than the API.

Terminology used by Domain-driven design

  • Entity : An object which has a distinct identity. For example, a User entity has a distinct identity with an ID.
  • Value Object : An object which has no distinct identity, like numbers and dates. For example, if two Users have the same date of birth, you can have multiple copies of an object that represents the date 16 Jan 1982.
  • Factory : Used to create Entities. For example, you can use a Factory to create a Profile entity from a User entity.
  • Repository : Used to store, retrieve and delete domain objects from different storage implementations. For example, you can use a Repository to store the Profile your Factory created.
  • Service : When an operation does not conceptually belong to any object.

Maven Tutorial related articles

Sébastien Dante Ursini

Sébastien Dante Ursini

Java/Finance Specialist
17 Years of experience in Java
22 Year in Banking/Finance
Based in Geneva/Switzerland

Comments

0 #1 Lelala 2013-04-04 15:24
The dependency description is really nice & short & clean.
But, i think thats not only for very/ultra large projects - having a clean and self-speaking setup/code/environment even pays of for small-scale projects.
Quote

Add comment


Security code
Refresh

Java Tutorial on Facebook