Spring / GWT Software Architecture for scalable applications – Part 1
During this article I’m willing to share with you a clean software architecture to build high scalable enterprise application based upon GWT (on the front end) and Spring (on the back end).
I’m going to start by showing the overall software architecture and describing all technologies and best practices I use, then on the next articles we will build a little application from scratch step by step, on each article we are going to concentrate on a precise part of the solution.
GWT/Spring Software architecture
The solution is composed from tow parts, the client side (GWT) and the server side (Spring/JEE).
Client side (GWT)
On GWT I use the MVP design pattern along with activities, and RequestFactory. On this solution the MVP is just an abstraction and it is implemented using activities, the presenter and RequestFactory.
On the table below I describe each letter of MVP and how is implemented in the solution :
On this architecture the objects creation and injection (this include views, remote interfaces, event bus…) is managed by an IoC framework (like Spring) called GIN and is based upon Google Guice. I’ll show you on the next article how to configure it and how I use it on this approach.
- View is a singleton configured using GIN (GWT IoC framework), most of the time a view is used by just one activity.
- Presenter is an interface implemented by a given view, to give a lightweight object which will be manipulated later by the activity to interact with the view.
- Activity It contains no Widgets or UI code and have a lifecycle. All the code about the UI business logic is written here. Activities manipulate both the view (by the intermediate of the presenter) and models (by calling the RequestFactory) and are started and stopped by an ActivityManager that is associated with a container Widget (a certain display area on the screen).
- Event Bus is a singleton configured using GIN and can be injected on activities and views, its function is to dispatch events to interested parties. An event bus eases decoupling by allowing objects to interact without having direct dependencies upon one another.
- RequestFactory is a factory exposing all your RequestContext. Each spring service you want to expose to the client must have its clone interface on GWT which extends the interface RequestContext.
- Proxy are the clones of the objects (business objects or VO’s) used on the spring services in the server side they are manipulated by the remotes interfaces (interfaces which extends RequestContext), activities and views on GWT.
Server side (Spring/JEE)
On the server side I use a simple service oriented architecture composed from DAO (data access object managed by Spring Data for JPA), services (transactional and secured service layer exposed to GWT through the RequestFactory API), and finally persistent entities or value objects (theses are manipulated by services and DAO).
- Spring Data JPA repositories : Interfaces that extends the Spring Data generic repository, this interface offer elementary DAO methods (save, update, find all…), we can also put here our simple DAO methods (only methods definitions no implementation required) see Spring Data documentation for more informations :
- Custom repositories : Here we put advanced DAO methods that needs some business logic code not just simple queries like JPA repositories (the implementation of the custom interfaces is required).
- NamedQueries XML File : Both Spring Data Repositories and Custom repositories loads queries from XML files instead of hard coding them in java classes.
- Spring services : Here we have all the functionality that our server side expose to the client. In order to manipulate data a service is composed from one or many DAO’s, also all the methods of the service must be transactional (so we can rollback if there is an accident) and secure.
Now that we know some foundations about the solution, I’m going to show you how is the project structured :
The project is divided in tow big packages, the server side and client side.
Structure of the server side
On the server side we have the following sub packages :
- repos: composed from tow other packages ‘simple’ which contain spring data DAO’s interfaces and ‘advanced’ which contain advanced DAO’s (this type of DAO’s uses the EntityManager and they perform some business logic on data).
- services: here we found the interfaces and implementation of services exposed to GWT client.
- rest: here we put REST controller to expose a REST API to build for example native iOS or Android application.
- business: here we have persistent entities and custom types (like enumerations or abstract classes).
- security: all classes related with security like authentication service, security filters… (I use spring security to manage the security of the application).
Structure of the client side
On the client side we have the following sub packages :
- activity: holds all activities, in each activity there is an inner interfaces which is the presenter implemented by the view.
- place: here we find the places, a place is used by the ActivityManaged defined for each display region on the GWT shell (or layout) to decided which activity to load. I’m going to talk about places on the following articles.
- UI: holds all the declarative XML files or java code to describe the UI (UI Binder). I also put in here the application layout (I called the shell). Every other files except layout related files are grouped on sub packages each one contain the UI’s that concern a certain module of the application.
- event: contain all the custom event we use on the EventBus. The event on here are used for example to update the content of a view when we receive some data, when another display managed by another activity trigger an event. Check this article
to learn more about how to use events on a MVP architecture.
- request: here we find RequestContext interfaces in relation with Spring services on the back end, the communication is done using a RequestFactory servlet, for more information about how to integrate Spring and GWT check the following article
. The sub package proxy holds the value object exchanged between the client GWT and server Spring, they are a representation of the remote objects (entities or VO’s) managed by Spring on the client side.
- ioc: holds infrastructure code to set up the IoC container on the client (configuration for GIN). The ‘MyAppModule’ file configure the beans managed by GIN container and theirs scope (Singleton, Provider…) this file is like the applicationContext.xml on Spring. The ‘MyAppInjector’ indicate which of the defined beans we want to get to explicitly (anywhere even if it is not a GIN bean) it is like a factory of beans. A given application can have multiples ‘Modules’ and ‘Injectors’ files.
- resource: here we host the custom style files and images, I use heavily the ClientBundle GWT API to learn more check
That’s it for this article, on the following article I’ll describe the example we are going to build step by step using this architecture.