0161 975 6110 | recipes@cakesolutions.net
Spring Centre of Excellence
the recipe for successful enterprise application development
Our Work
The traditional approach to our work section is to identify the most important applications we have implemented. For each application in this list, we would include a screenshot and an impressive list of technology buzzwords. We do not think such approach would actually show our expertise in the technology or give you an appreciation for each application. Our aim is to demonstrate our system architecture, implementation and delivery skills. To do this, we will begin with a short explanation about how we design all applications, regardless of their size. Then we will pick four applications we have implemented and describe each application’s business requirement and most interesting aspects of its implementation.
We always strive to architect a system so that the impact of changes is as minimal as possible. This is in contrast to designing a system to be as flexible as possible from the outset. The latter approach will invariably result in a complicated and expensive system, yet it will not ensure that the system will be able to cope with future requirements.
Read on to find out about the lifecycle of the most notable systems we have implemented. You will find that we always work with the customer to evolve their system; we do not “wash our hands off” a system once we deliver it, we continue to support and enhance it.
ISW
We built the Internal Services Website (ISW) for UK Trade & Investment (UKTI), an organisation run by the Department of Trade and Industry. UKTI’s aim is to attract foreign investment in the UK. To do so, the UKTI make sure their public-facing website always shows the most relevant content to potential investors.
Since the first launch in 2006, we have implemented numerous improvements. The most important improvement was not visible to the users, but greatly simplified the work of the UKTI’s editorial team; the second crucial improvement was the introduction of custom analytics module. This module allowed the UKTI to accurately measure the impact of their work and ensure that the users see the content they are interested in.
Technology
The Spring Framework sits at the core of ISW’s implementation. We took advantage of the comprehensive Spring MVC framework to implement a lightweight web tier that uses the declarative transactional and second level caching support in the middle tier. We implemented the data access tier using Spring’s convenient Hibernate support.
We deployed the application in Bea WebLogic 9 application server with Apache HTTP server. We use Oracle 10g database to store the application’s data.
The route to today's ISW
Even though the visual layout of the ISW web system remained very similar from the first release, we have changed the system substantially behind the scenes. Whilst we expected that we would need to implement some changes, we did not expect that the required modifications would be so far-reaching.
Originally, the ISW system sourced its data from XML files. It was the responsibility of the London-based editorial team to produce these XML files. Even though this gave the team excellent control over the presentation of the data, it also put it under enormous stress. They had to collate all content from the contributors and transform it into the XML the system could understand. Approximately 8 months after we launched the system, the UKTI started using a complex knowledge management system. The knowledge management system holds the organisation’s content. We needed to modify the ISW system to use the data from the knowledge management system directly. We achieved this in record-breaking 4 weeks. From this moment, the editorial team in London could focus on managing the authors and contributors rather than dealing with the technical details of the system.
As time went on, the organisation needed to find out how much impact the editorial work has on their core business. They had to have meaningful statistical information about the usage of the system. The statistical information was far more detailed than what the current analysis services could offer. We implemented a custom metrics module, which can intelligently classify the visitors and measure the impact of the editorial work. Apart from monitoring the behaviour of the web users, the metrics system is capable of monitoring its own performance and it can learn from its mistakes.
Finally, the UKTI realised that they needed to align the ISW system with their knowledge management strategy. The strategy called for a service-oriented architecture (not ESB!). We are currently planning to make further enhancements to the ISW system to allow it to use the services that the knowledge management system provides.
BIM
In the section on ISW, we mentioned the knowledge management system. The UKTI have invited us to tender for the implementation of the Business Information Manager. Because of our good record of accomplishment in ISW implementation and our proven expertise in the Spring Framework and Java EE, the UKTI awarded us the contract to implement the BIM system.
The vision of the BIM system was to enable all employees in the organisation to share knowledge. In the first iteration, the shared knowledge was represented by the content the users create and the centrally managed taxonomy. See the taxonomy paper for more detailed discussion on the subject.
To manage the information, the BIM system provides a complex workflow module that routed the content throughout the organisation. We were one of the first software vendors to successfully manipulate binary Microsoft Office documents on the server using purely open-source technologies. Over time, we improved our understanding of the binary Microsoft Office document formats, which in turn allowed us to improve the accuracy and “intelligence” of the content manipulation and retrieval services.
Technology
Just like ISW, the core of the BIM system uses the Spring Framework. However, unlike ISW, BIM is a heavy transactional system. In other words, the ISW system performs mostly “reads”, while the BIM system performs equal number of “writes” and “reads”. We spent considerable amount of time making sure that the data structures are optimal. Whenever possible, we did not sacrifice the normality of the data in favour of performance or programming convenience. To achieve excellent performance, we took advantage of second-level caching; if the caching did not bring enough improvements, we turned to materialized views.
The remaining technologies included Bea WebLogic 9, Apache HTTP server and Oracle 10g.
Improving BIM
We started planning and implementing improvements to the BIM system as soon as we released it into production. The first round of changes focused on improvements to the Microsoft Office documents processing engine – the documents the users wanted to upload included features we never considered in the processing engine’s implementation. For example, we saw 10 – 20MB Microsoft Word files with embedded PowerPoint presentations and linked Excel spreadsheets.
The next set of improvements focused on simplifying the user experience with the taxonomy. While the users understood the concept of the taxonomy very well, they struggled with the strict rules the system enforced. Figure 1 shows an example of a piece of content with taxonomic tags in blue.
As you can see, the taxonomic tags (in blue) can be complex; the improvement allowed the system to intelligently correct many common mistakes the users were making.
However, these changes were insignificant compared to the architectural change we took a year ago. As the system grew in popularity in the organisation, other departments started to show interest in its functions. Very quickly, it became apparent that we needed to split the system into a collection of independent services that other applications can use. Thus, we implemented the BIM Publishing Bus – a service-oriented architecture that includes the functionality of the original BIM system, but adds a contact management service. The contact management service allows, for the first time, to unify the information the system holds about the content with the information it holds on the customers. This allows the system to intelligently direct the most relevant information to the UKTI’s customers.
When we integrated the metrics module into this system, we fully realised value of the information to the organisation. The authors and contributors know what content to write, because they have the information from the metrics service. The system then knows what to do with the information, because it can match it with the contact’s profiles.
We believe this forms the basis of truly revolutionary approach to information processing in any organisation. Together with the UKTI, we have come to realise that the BPB system is a social media system; a system that can encourage communication within the company and engage new or existing customers.
Neptune
National Union of Students Services Limited (NUSSL) use a system we developed four years ago to process the invoicing and billing processes. The current system, Mercury, is our last active .NET application. It performs complex calculations on the invoices NUSSL deal with as part of their services to the various student unions’ outlets.
Early in 2008, we started work on re-implementation of the system in Java. The reason for the rewrite was two-fold: first, we needed to implement new features that were becoming too difficult to express in the ageing data structures and .NET code. The second reason was that our preferred technology is Java EE.
Technology
Just like the UKTI systems, Neptune uses Spring Framework at its core; the middle tier makes heavy use of Spring AOP and Spring remoting. We have chosen Java RMI as our remote call infrastructure, because the clients are Swing-based applications and because at this moment, there are no additional integration requirements. However, the Spring remoting infrastructure allows us to declaratively add another remote call technology without affecting the system’s code.
The system performs substantial amount of transactional processing; we use Microsoft SQL Server 2005 running on Windows 2003 Server. We deploy our application in the JBoss 4.2.2 application server. To achieve optimal performance and to allow us to access all aspects of the physical architecture, all software components are 64bit.
For the first time, we have extensively used Spring AOP and AspectJ to implement some parts of the system. The nature of aspect-oriented programming lends itself to performance and health monitoring and security. The performance monitoring is particularly interesting. We collect statistical information in the integration tests. The integration tests ensure that the system meets the performance requirements, but the statistical information allows us to analyse the behaviour of the system. The system automatically notifies the administrators if its performance starts to degrade.
The client application is a Swing rich client application. We evaluated various client technologies, including .NET; but in the end, we decided that the performance of the Java RMI and our experience in modern Java applications outweighed the offering of the user interface libraries in .NET. Additionally, we felt that the latest user interface controls only increased the user interface friction. In our rich client application, we tried to keep in mind that users do not wait to see animated rows appearing and disappearing; the users use they application to help them with their work. If the application’s user interface slows the users down, then it is not helping them at all. With this concept in mind, we implemented rich client application shown in Figure 2.
As you can see, there are no animated wizards, colourful tabs or three-dimensional icons; however, the users can operate the application using only the keyboard and most input fields attempt to help the users enter the required data with as few keystrokes as possible.
QFI
QFI Consultancy provide process optimisation services to organisations that need to manage many dependent processes. A good example is a hospital ward. There are many patients; each patient needs specific care. In the QFI domain, a project is the process of discharging the patient, and the processes are the different tests and treatments that lead to the goal – discharge. The processes are constrained: for example, it may not be possible to start a particular treatment until some time after an operation.
Because QFI Consultancy can apply the same process management principle to many different environments, they needed a system whose core implements the theory of constraints principles. The applications for the specific environments then use the common core and provide only the additional functionality for each environment. Our task was to architect the application to allow for this programming and deployment pattern. When we completed our architecture work, QFI Consultancy asked us to help us with the implementation of the environment-specific applications.
The future
Throughout the architecture and implementation of the QFI core, it became apparent that the application would benefit from a highly modular, yet loosely coupled design. OSGi seems to be the best technology that satisfies these requirements. SpringSource – the company behind the Spring Framework – has just released the SpringSource Application Platform. The Platform is a complete implementation of the OSGi R4.1 specification, but includes many additional improvements. We believe that the Platform will be an ideal substrate for the QFI system.
What we Do
Team Blogs
The best of JEE of 2008 By Jan Machacek on 30th December 2008
Merry Christmas and mud By Jan Machacek on 26th December 2008
Debugging SQL statements in Spring JDBC By Jan Machacek on 28th November 2008
Sub-millisecond Java By Jan Machacek on 19th November 2008
Spring User Group November 5 Minutes By Jan Machacek on 16th November 2008