Architecture

To help me jog my memory, I actually found the technical specification of the app. The provided images are taken from that document.

Overall

The application was designed in the EJB 2.x era. Several design decisions were taken to overcome the weakness in the Application servers.

The system was broken down two two logical parts Front-end and Middleware.  I keep calling it “Middleware” in the document, as that was the pseudonym we called it at then.

Middleware – Data loader

The data loaders were working on the “Backend” database, and were implemented in MQ Message Broker.  This was an excellent hub that made use of the various input filters of the product. We saved tons of time on using the IDOC, fix format, CSV inputs. It had incoming MQ messages, direct DB connections, text file inputs, with a single output: the backend database.

Since the message broker was used for nothing more than data collector, calling it a Middleware is an overstatement. In fact Message Broker was mostly used as an omnivore ETL solution, that was not available on IBM’s SW palette at the time.

Middleware – Front-end

That was not Middleware, nor Front-end. In fact that was the actual application server layer of the front-end application.

The application layer was implemented using web-services. Unfortunately at that time only JAX-RPC  was available, and we could only use the Apache Axis 1.3 library. This was quite problematic as the session management had to be implemented separately. This is now considered a huge potential security issue, as it makes session hijacking possible.

The web services were completely stateless  and nothing was stored about client sessions except for the session-id itself.

The most important part of the application layer were the “datasets” and “views”. Datasets were basically Hibernate queries mapped to the underlying Backend database.  Views defined how these datasets should be filtered/aggregated and displayed.

The report services provided access to the data and the report definitions. The data access was a simple variation of the view service itself.

Business logic services were data manipulation functions. Most data was overwritten upon updates, but there were some, that were only modifiable from the application itself. All business logic was implemented in the backend layer, so the client only dealt with display, input, and basic data validation.

Client

Most of the application was designed to use database based views. The tree structure on the left, the layout of the data sets, the views based on the data sets, and even the forms used to display the front-end were stored in the metadata database.

The client was deployed using WebStart, which made it easy to distribute new versions to all clients. The application itself was using Eclipse RPC, and the actual application was an OSGI plugin deployed in it. Using Eclipse enabled really fast Windows based software, that is compared to the “traditional” Swing based UI option.

The most sophisticated part of the application was the list view itself. It was an “owner-draw” component, based on a list component  originally written for Swing. It was extremely fast, supported all the listed features, such as icons, sorting, grouping or highlighting.

The “detail” view of the list items was hand coded in XML, and it used a number of pre-defined UI components that referenced the current DataSet’s fields.

The SWT application also incorporated BIRT to create very good looking reports in PDF as well as quite complex Excel sheets. The report definitions were in BIRT format, and used a custom data provider to use of the dataset concept.