Marco on CEP

As some of you already know we have spent lots of time on user interfaces lately. It’s a complete nightmare to decide how to create a gui these days. There are just too many options to choose from. Traditional client or web client? Flash or Silverlight? .Net or Java? Which Java framwork and so on ad infinitum…

For user interface work, we follow some guiding principles:

• All user interfaces as web based. Runnable in your favorite browser. The reason for doing only web based, as opposed to traditional fat clients, is that we like to have some flexibility on what kind of client the application runs on.
• The output should be plain html and javascript. This opens up creative mashups where our user interface is a part of a greater whole in ways we can not anticipate. Users (and children) tend to use everything in the most creative ways that we ourselves can not think of. So, we just assume that we are stupid and our users are smart.
• A system integrator using our GUI  should be able to change layout and the overall look and feel of the user interface.
• User interfaces should provide some real benefits. That is, they must be easy to use. No stupid things like popping up a editing window where the user have to write a script or enter some XML.

This lead us to the following approach for user interfaces:

We have a rather traditional three tier architecture. The data tier with a normal sql database sits and the bottom, providing data to the business logic tier which in turn response to request from the web tier. The database have other clients too. So its design looks like one would expect from a traditional relational model.

The business logic tier uses JPA with Hibernate to provide a nice object oriented model of the database. As there can be other clients to this data we need to be careful in keeping JPA in sync with all the other clients. This is an area where JPA needs to do more work. JPA seems to assume that it is the only client that accesses the database. So you need to be careful when letting other clients to access the database. But overall we a pleased with the JPA+Hibernate combo. We use a couple of Hibernate specific extensions as  plain JPA lacks some critical features.

We use Glassfish+PostgreSQL plus some own additions to provide a multi tenant database environment. All user’s data is protected at database level, so there is no risk of two users seeing others data as the user needs to be able log in into PostgreSQL in order for JPA to get access to the data. This is done using some home brewed connection management in Glassfish. The normal approach is to use one single db login from the app server and handle all the security in app server code. This is something I think is really a bad idea as a single bug can allow users to see each others data. That’s something we can’t risk.

In order to stich everything together we use SEAM from JBoss. It provides us with smart components both in the business and web tier. Seam provides us with server side state management, which is invaluable in a web application. In the logic tier there are a number EJB components that provides an API to get business data.

The visible parts of the web tier is done using JSF and UI components from Icefaces. The Icefaces components are usable as they are in most cases, but for some special cases we need to add other components. Mostly JQuery ui elements. For example, there is no Icefaces data picker component which allows you to pick more than one date. Very annoying. Overall Icefaces is a good choice for GUI work, but I would like to see a bit more mature components. I think Delphi had more mature components back in 1995.

Icefaces uses a lot of magic javascript to provide its smooth server driven updates and it takes some tricks to get it to work with other javascript frameworks such as JQuery. To get different frameworks to work together is the biggest problem with our setup. There are a number of things that can go wrong when you need to get JSF, Icefaces, JQuery, Hibernate, SEAM, JPA, JSP and a couple of other libraries to work together in one project. But when everything is in place, it gives us a very flexible environment to work in.

We rely heavily on CSS to do the layout and look and feel for our user interface. The idea is to give the css to our clients and allow them to move around different elements in the gui and changes colors and other layout elements. Normally all layouts start with a paper and pencil, from there its straight to a prototype in code. We do this back and forth a couple of times before the design starts to feel right. We don’t use any gui tools for doing the layout of the web pages. It’s all hand built using JSP, Icefaces and CSS. It would be nice to have a tool for this but we have not found anything that works with the setup we have.

Here’s an example on how it might look, this is a page from FleetNotice, the GPS real-time alert management system for fleet managers that we built ontop of ruleCore CEP Server:

The above example uses our standard Black&White theme. It’s the standard CSS that we base everything on. The idea is to first have something that is very clean and then start adding colors and other fancy graphics.

All components except from the date picker is Icefaces. In this example they look just like plain html input boxes. The benefits from Icefaces are apparent first when actually using the interface. For example the "Output" box is validated immediately when the user types something into it. Not when submitting the page. The data picker is a JQuery component. We prefer to use pre-built components and avoid creating our own gui components at all cost. We try to support most major browsers. But as we use Icefaces and JQuery we are basically supporting whatever they support.

Complex Event Processing