Background
Select Managed Funds Limited ('Select') are a well established, innovative company with core skills in structuring, management, acquisition and integration of superannuation master trusts.
In 1998, to provide better customer service, they initiated a web-based system for advisers and members to view their superannuation account details online. The system proved successful and has had features slowly added over the years, as well as being integrated with new financial products that have been acquired, each with their own branding requirements.
The Problem
While the system has worked well, it has a few problems which are beginning to manifest themselves:
- It is difficult to change the layout and structure of the interface due to intermingling of business logic and presentation
- It will not easily integrate with other systems, such as a different relational database system
- It is not very scalable, which will be an increasing problem as more products and users are added to the system
- While many of the superannuation products that it manages are fundamentally similar, there are subtle differences which require changes spread throughout the code-base
- The next phase of providing better customer service via the web will involve capturing information from clients, which need to be communicated securely and reliably back to Select. The system is not robust enough to perform this task
The Solution:
Everyone has been happy with the system from the point of view of the end-user. The system is easy to use and informative, it is only the back-end components that require updating. It was therefore decided to take a staged approach to re-development:
- Stage 1 - Redevelop the site using Java/JSPs to provide existing functionality, but from a new code-base which is built to allow flexibility in supporting new look-and-feels, new products and new database schemas, as well as being highly scaleable and able to be distributed across different servers
- Stage 2 - Build new functionality into the system to provide more information, and provide a vehicle for two-way communication between SMF and their clients
Java was selected as a development environment primarily due to its familiarity, low cost for entry and ability to scale to higher performance application servers in the future. The existing website platform was already Red Hat Linux, which had proved to be stable and low-maintenance.
The existing back-end interfaced to a local MySQL database, which in turn was updated on a nightly basis from an internal legacy database. Select were already in the process of migrating internal systems to MySQL, and it is envisaged that the new back-end will interface directly with this database in order to provide real-time information. This is expected to happen in Stage 2, with the new system still communicating with the local replicated MySQL database.
It was decided that a full J2EE (Java 2 Enterprise Edition) solution was not required, but that there should be a migration path to it in the future. While this meant that Enterprise Java Beans were not used for example, other enterprise APIs such as JMS (Java Message Service) were used as necessary.
The application itself is currently running inside the Apache Tomcat servlet container.
Design Goals
While the problems existing in the current system were all explicitly addressed, numerous other opportunities were identified and catered for. The major design goals, and how they were satisfied are detailed as follows:
Separation of Logic and Presentation
To achieve the flexibility that was required to allow custom look-and-feels based on products and user level (dealers, advisers and members all see different options for example), we developed a light-weight and very pure Model-View-Controller architectural framework. By letting JSPs handle the presentation, and providing Factory methods to instantiate business objects, it has become extremely easy to add new products (with corresponding new business rules) to the system as well as customise the interface.
Highly Secure
Any financial services application needs to have security of client data as a highest priority.
The connection between end-user and webserver is protected by 128 bit SSL encryption. The application itself has a number of features that combine to protect unauthorised access:
- PreparedStatements are used throughout to help prevent SQL injection attacks, and improve the overall robustness of any database access
- A bare minimum of parameters are passed between pages to prevent giving to much information away
- Any attempt to access information about a Subject (such as an adviser, member etc) goes through an audit process which traces the target Subject back through the hierarchy of Subjects to meet up with the Subject representing the currently logged in User. Access is denied if there is no path
- All user actions are logged, whether they are successful or not
- Any attempt to access an unauthorised subject will raise an SMFSecurityAccess exception, and cause the logged in users' session to be terminated immediately, helping prevent a brute-force attack
- Security-related code is centralised, and subject to intense scrutiny
These features are in addition to standard hardening procedures on the web-server and database server themselves.
Highly Configurable
With the extra functionality being created, we needed a way to allow someone to monitor the status of the system, and make changes to its operation without requiring recompilation, restarting, or editing of obscure configuration files. Because the intention was always to allow different superannuation products to run off separate servers, any solution needed to allow distributed administration.
Because we were already using JNDI (Java Naming and Directory Interface) to store our JDBC DataSources, it was logical to extend this facility to store configuration data in the same repository. We settled on an LDAP repository for this purpose, but any repository with a JNDI Provider module available would have been suitable. At this stage we are using OpenLDAP, but this could change in the future.
There is a separate administration Web Application (smfadmin) that allows an administrator to login and control almost every aspect of the different products, including:
- Modify DataSource parameters
- Modify Product names
- Disable/Enable/Hide certain features, and provide an explanatory message if desired
- Link certain back-end content with our content management system: autopublish
New products and DataSources can be dynamically added and removed at any time. Also, products can be 'paused' to prevent users from logging in. A message will be displayed on every page to currently logged-in users warning them to logout as soon as possible. This allows applications and servers to be modified with minimal disturbance to end-users.
When a web application starts up for one or more products (depending on how they are distributed across servers), it needs to be able to access its configuration data. Each application instance contains a 'bootstrap' properties file which contains little else except details on how to access the rest of its configuration. These properties specify the JNDI Provider, and other details such as a username and password. If a connection cannot be made using these parameters, the application cannot continue.
Whenever a change is made to the configuration of a product, it is desirable that the application running that product is notified of the change, and reconfigures itself automatically. The LDAP specification provides the ability to send and receive events, but unfortunately this is not implemented in OpenLDAP at this time. Our original installation resorted to polling the directory to detect changes in data, and reloading that configuration if needed. We have now implemented a JMS (Java Message Service) solution to provide this notification. This has enabled us to use lower system resources by stopping unnecessary Threads, and also facilitates almost instant communication of any configuration changes, even when communicating between distributed machines.
Other Features
- Strong object-oriented architecture promoting re-use of components, and easy extension to cope with new products, database schemas and business rules
- Platform-independence. While targeted at a Red Hat Enterprise operating system, the Java-based system will run on most popular operating systems including Windows and Solaris
- Scaleable. Load can be distributed across different machines by default, and these machines could be load balanced using any commonly available system. Additionally, any instance of the SMF Product Application can control any number of Products, so a failed machine can have requests re-routed to a different server with no loss of functionality. Similarly database requests can be routed to a new database server via the administration interface
Summary
The system was deployed (a little prematurely) for a single product near the end of April 2004. Aside from some very minor issues, there has been no downtime since, and responses have been overwhelmingly positive. New products continue to go online under the new system, and Stage 1 is considered to be complete.
Last Updated 22-Nov-2005
