Building an Enterprise Scale Mass Market AJAX Web Site using echo2, EJB3 and ServiceMix ESB
By Matthew Brooks, Technical Architect, RDF Group mbrooks@rdfgroup.com Introduction
I work for RDF Group as Technical Architect and in February of 2006 it was our good fortune to meet mform, a start up company aiming to launch an innovative online mortgage search and application service. RDF Group delivered an enterprise scale public facing web based application to mform which went live on the 20th November at www.mform.co.uk. This is the story of the team’s journey through some of the most cutting edge technologies in the Java space to deliver a fully web 2.0 style application backed up by a Service Oriented Architecture.
The Brief
Attending Edinburgh with my colleagues from RDF it became apparent that this fledgling company was intending to provide a unique mortgage search service on line. We felt that by adopting some of the cutting edge technologies we could provide a significant USP for the client. Simply put the business requirement was to provide:
- A compelling user interface to allow people to enter their mortgage details and search the whole of market to find the products which are right for them.
- For users to select a mortgage product and provide as close an integration as is possible with mortgage providers to allow users to apply for their chosen product with the minimum of effort
The Technology
The technology stack adopted was intended to be cutting edge, whilst not compromising delivery by introducing too much risk. The vision was to have:
- A fully Ajax based UI, that moved away completely from the old http request/response cycle and only used the asynchronous XMLHttpRequest
- To provide scalability using an EJB3 based farm of application servers
- To minimise the pain of introducing new integration points with different lenders by utilising a Service Oriented Architecture.
Happily a number of key technologies had come close to maturity in all these areas and we adopted the following technology stack
The Process
Whilst this report is intended to cover the use of these technologies in delivering a fully fledged application, it is worth a brief mention of the work process we have at RDF. Our process is based around RUP and we have adopted some of the best tools from the agile movement to help facilitate this (unit testing, uniform build management, continuous integration etc).
Whilst many software houses talk about using RUP – they tend to fall into two camps:
- Those that pay lip service to the process – but don’t actually implement it
- Those that try to follow the process to the nth degree and as a result fail to make progress with kind of speed that customers require.
By contrast RDF uses a strong process that is based around delivering operational slices of functionality to demonstrate progress and to test the requirements.
On the project:
- Customer requirements were fully documented using use cases and UML model
- Design was undertaken based on the analysis
- Development was only undertaken on the basis of the design
As a result we were able to deliver an innovative product with fully traceable documentation and design artefacts that mean we can easily support it going forward.
User Interfaces and Echo 2
In the spring of 2006 the most extensive and well rounded Ajaxian type web framework in existence was, to my eyes, echo 2.
We implemented a great prototype of the UI and were confident of echo 2’s ability to deliver.
One of the key things about the echo 2 framework is the concept of an application.
There is one instance of an application per session and what the user sees in the browser is generated by constructing (or changing the state of) a widget lattice that is stored in the application instance.
Here is a high level sequence diagram showing the interactions between the browser and the echo 2 application
Fig 1: A sequence diagram showing the interactions between the browser and the echo 2 application
Echo 2 and CMS
One of the customer requirements was to be able to update the site content using a content management system.
We selected the Dutch based Hippo CMS system and built integration between echo 2 and Hippo CMS. Briefly we built a component that could display XHTML fragments (we could have used the one from echopointNG but in the end built our own) and the data to be displayed is pulled from Hippo using DASL.Echo 2 the challenges
Whilst using echo 2 we discovered that whilst it was the most advanced tool for the job (at least when we started, which was before GWT came out) we did find that we had to undertake the following:
- Adjust some of the java script in widget peers where it was not quite performing as we expected
- Subclass the echo 2 servlet to ensure that:
- We can trap non java script type clients and present a “non java script” type version of the page
- We can present a more polished start up page rather than the ||| presented as default by echo 2
- Some post back functionality does not work well with IE either under load or restricted bandwidth. Due to the way that IE polls for the post back other events on the browser were being missed.
- Develop our own widgets where necessary if there was no suitable one available from echo or echopointNG
Echo 2 a summary
Overall echo 2 provided a fantastic framework for delivering a fully Ajaxian web site.
Its swing style approach to UI’s provided a convenient and familiar development environment.
It provides good encapsulation of JavaScript which in general works well over multiple browser versions.
Echo 2 could well do with some standard approach to layout management, however, and this has caused us some work during development.
Here are some screen shots of the finished application
Fig 2: The polished start up screen
Fig 3: The first application screen
Fig 4: An example use of an accordion pane and a modal dialogue
EJB3 and JBoss
We were keen to use EJB3 and Java 5 and JBoss 4 gave us the opportunity to use this new technology.
We broke down the layers in the EJB space in a manner that should be familiar to most people working in the JEE space:
- A services façade layer: Consisting of EJB3 Stateless Session Beans providing coarse grain services used by the echo 2 presentation layer and transactional demarcation. All calls from the presentation tier go through this layer.
- An Application Services Layer containing
- Business components which encapsulate the fine grained business rules needed by the environment.
- Domain Object Managers encapsulate complex rules and relationships between a set of related domain objects.
- A Domain Layer containing Domain Objects mapped to the database using Hibernate.
How Spring Fits In
The only EJB’s involved in the application are in the service façade layer.
All the other layers are implemented using POJO’s wired together using Spring.
Hibernate freezes out EJB3 Entity Management
We used EJB3.0 annotations backed up by the Hibernate persistence mechanism. This bought the stability of the mature hibernate product along with some of the extra functionality that Hibernate provides.
Architectural Complexity and the new technologies
Some people could take the view that a multi layer approach as outlined above is no longer necessary in an enterprise scale app.
They ask:
- Why have Session Beans at all when you could use Spring remoting?
- Why have an Application Services Layer? Doesn’t this encourage the anaemic data model anti-pattern?
- Why have Domain Object managers when you can just make Hibernate calls on a lattice of Domain Objects directly?
Session Beans and Spring remoting
This is arguably more of a style issue than anything else.
We went down the Session Bean approach for the following reasons:
- Use of Session Beans allows for easy integration between JBoss-provided transaction management and the transactional boundaries we wanted for the system
- Use of Session Beans makes it easy to tune particular services by adjusting the maximum number of beans in the pool for that service.
- We were more familiar with Session Bean remoting than Spring remoting
Application Services and Anaemic Data Model.
There is an anti pattern being suggested at the moment which is the Anaemic Data Model.
This suggests that having “data carrying” objects and “data processing” components leads to a “functional” software development rather than proper object oriented development.
On the other hand, others would say that, ill used, a rich data model could lead to object bloat.
As ever we are in the architectural position of having to balance opposing forces. The solution we came up with was this.
- Objects may have methods that contain behaviour.
- These methods may only act on the objects own instance variables.
- When these methods wish to act on instance variables of other objects they must delegate their behaviour to methods on that objects
- That these methods should only ever be called (on a delegation basis) by Application Service managers.
This helps promote good encapsulation (points 1-3) and point 4 allows for easy post production code maintenance. If you know that business processes are kicked off by Application Service Managers (even if all they do is call a method on a Domain Object) then you always know where to look for the business behaviour of the system.
Domain Object Managers and Hibernate
In some ways it is arguable that, with a sophisticated object relational mapping tool such as Hibernate one can dispense with Domain Object Managers completely. After all, the job of a Domain Object Manager used to be to manage invariants between domain objects in a related logical area, a function now delivered admirably by Hibernate.
The argument for the continuing usage of Domain Object Managers is about decoupling.
Ideally I’d rather not have the Application Service Managers know anything about the persistence mechanism.
I would like to ensure that any calls to the Hibernate framework take place in one area of the code, the Domain Object Managers.
Also the mform application lends itself to very distinct, non-overlapping data domains.
This led us to use the Domain Object Manager approach – although it may well be that the decoupling of the Object Relational mapping services can, in future, be provided by a single infrastructural type class.
The mform application and the ESB
Part of mform’s key advantage is to be able to integrate with many lenders
We realised, however, that the costs of this integration could escalate and were keen that they were kept to a minimum. This is because each lender has different transport requirements. And each lender wants similar data delivered in different formats.
- Some want XML
- Some want a CSV file
and so on.
We were keen not to build all these integrations on a case by case basis, wanting to insulate, as far as possible, the central mform application from the services provided by lending institutions. An ESB is a key technology for delivering this.
We adopted ServiceMix ESB due to its comparative ease of configuration and its ability to be deployed within JBoss.
We defined a Web Service end point to be called by the core mform application. The Web Service definition contained as large a set of data as we could devise along with the end point for the message.
The configuration of ServiceMix was then set up to
- Inspect the incoming XML and decide which end point it should be forwarded to.
- Transform the XML into the format required by the Lender
- Transport the data to the Lender.
Every time we need to send mortgage applications to a lender we invoke this web service and let ServiceMix reformat and send the details to the lender.
This will minimise the disruption of adding additional lenders – changes to the central application will only need to be made if there is some crucial data that we are not passing to the ESB that is required by a specific lender
Conclusion RDF has been able to deliver a fully featured Web2.0 style enterprise application for mform rapidly. The technology stack of echo 2, JBoss, EJB 3 and ServiceMix ESB provides a powerful tool for providing scalable and reliable web based application with rich UI experience that users are coming to expect.
Labels: Ajax, echo 2, EJB3, ESB, J2EE, Java, JEE, Service Oriented Architecture
