The RDF Group has published a technical overview of their recent project for mform, which is a mortgage broker application communicating to multiple lenders via an ESB. This project uses many of the technologies discussed here on TSS such as echo 2, EJB3.0, Java 5, Spring and Hibernate. The technical overview focuses on the choices of technology more than the development process, but includes some architectural details. The requirements, simply put, were:

• 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 stack adopted incorporated many cutting edge Java technologies that are discussed here:

• User Interface: echo 2
• Application Server: JBoss 4 (with EJB 3.0)
• Integration with Mortgage Providers: ServiceMix
• Persistence Mechanism: MySQL
• CMS System: Hippo
• Object Relational mapping: Hibernate 3
• Dependency Injection: Spring

While it's not a full exploration of the architecture, it's an interesting look at why some of the choices were made. Message was edited by: joeo@enigmastation.com

Very interesting article and interesting architecture. Just a couple of questions:- Since you were already using Spring, why did you go for EJB 3? There does not seem to be any need for remoting. The services provided by EJB3(like transaction management, etc.) can also be done using Spring. Also, you mentioned that you had design artifacts for the whole application. Do you also update the design artifacts whenever you do any refactoring for the code? I have been following some form of RUP in my projects but this has always been a problem where after some time the design artifact goes out-of-sync with the code. Thanks, Robert

I think your question about why they chose EJB3 was answered in the text of the article. You may not agree with their choice, but they at least anticipated the question! (smile).

As I mentioned in my article it was more a matter of style and what we were familiar with. In the end we could have eliminated Session facades and used Spring remoting, transaction management and so on, but given the resource profile and delivery schedule it was easier and lower risk to undertake the project as we did. On the RUP question, bugs and enhancements go via the analysts and as a result changes are modeled before implementation. In general things are pretty much in sync, and we are just going through a QA process at the moment to make sure that our UML artefacts do accurately represent the working application. Regards Matt Brooks

Just to let you know that I will be at Javapolis in Antwerp 11-15th of this month. If anyone wants to meet up to discuss this project and technical architecture in general drop me a line at mbrooks at rdfgroup dot com Matthew Brooks

Could you give a brief synopsis of how you managed the security for the application?

It was good analysis, how ever the application breaks browser histroy and EJB3 entity beans would have been still better over hibernate.

Did you consuder combining the Seesion Facade and Application Services layer. Is your Session Facade a thin layer for declarative transaction boundary and security specification only?

I went through the demo..Looks good. I have earlier posted one comment on the TSS forum regarding ECHO2.It seems to be a very matured kind of framework to me.No Back Button Hassles etc. I am not sure of the Security Aspect of it though. Can you elaborate a little bit about it. Rgds Shashank

I like the UI etc. Actually, I like the echo 2 framework. However, the responsiveness from the UI is really poor. Takes like 1-2 seconds before a response comes back. dino