Columns

Browsersoft lets developers write a little Java

• By Joel W. Willsey
• October 1, 2004

Browsersoft’s eQ! Foundation is one of those software products that is hard to classify. Not only is it a Java persistence layer, it is also a scripting engine. Browsersoft classifies it as “foundational software,” and that’s a label that works for me. Basically, eQ! is designed for Java developers who don’t want to reinvent the wheel.

Version 2 is designed to provide services for typical Java-based business components and applications. As Browsersoft puts it, “Instead of writing lots of Java code, you write a little Java code to describe your data and business rules, use XML to configure the pre-written eQ! modules and to script your application flow, and you are done.”

Although you must use proven design patterns to fulfill your clients’ needs, the product provides a simple persistence layer and an effective way to script the business logic using the scripting engine. It also provides adapters, which allows developers to use the foundation with frameworks like Struts and Swing.

As a senior member of my development team, I was charged with providing our company with salesforce automation tools that would be delivered to our sales and sales support personnel via Plumtree Portal. Our team consisted of experienced and new Java developers. We were developing relatively simple Struts apps running under WebSphere. We didn’t want to purchase a large and expensive persistence layer that we didn’t have time to learn -- we needed something that we could be productive with relatively quickly. Version 2 of eQ! Foundation gave us the simple persistence layer we were looking for, with a scripting engine to boot.

eQ! consists of several JAR files and XML configuration files, and so installation was fairly easy. For a Struts app, you must modify the struts-config file, replacing the action class with the eQ! adapter class. This class creates the scripting engine and persistence layer.

Configuring eQ! is a multistep process; there are several XML-based configuration files to modify. The persistence layer configuration file handles the database connections, data sources, and persisters and set persisters. The XML script file consists of as many named scripts as your app needs. The scripts are there to facilitate set-up, but this feature has benefits and drawbacks. You can instantiate objects and call methods on those objects from the script. The downside is flow control; you only have an tag for control, which is a real limitation. You can get around this in a couple of ways: create a very large script or code a helper class that contains the logic you need, instantiate it and then call the methods required. We chose the latter approach when we required more complex processing.

eQ! is designed to be used with any set of Java development tools, and it comes with a graphical tool to edit and maintain the eQ!-related Java and XML. The eQ! services can be used together or separately as needs dictate. In our project, most database Create, Read, Update, Delete (CRUD) operations were handled simply via an XML configuration file and canned scripts. Some of our more complex business rules were handled by custom helper classes that were called via custom written scripts. This allowed some of the inexperienced Java developers on the team to be productive in a few weeks. After the initial learning curve, we found we could roll out new portlets in less than a month -- a considerable time reduction over what it would have taken to write custom code for each portlet.

The persistence layer requires the developer to subclass the eQ! BusinessClass. This requirement was acceptable, but I would have preferred not to tie my domain data objects to a specific persistence mechanism. The object-relational mapping is not particularly explicit, consisting of an INTO clause on the end of each SQL statement. You must be very careful with this as the order must be exact; if problems arise, it’s difficult to debug. The persistence layer can handle some very complex relationships with a design called eQ! Collections. This feature allows for the typical one-to-many relationships, as well as one-to-n-many relationships. In our applications we didn’t need this type of relationship, but it was nice to know it was there if we had needed it.

eQ! is not perfect, nor did it provide everything we were looking for. Object-relational mapping is cumbersome and, as I mentioned, there’s a lack of comprehensive flow control in the scripting engine; in addition, there’s no support for Struts 1.1 in this version. Documentation was also not as strong as I would have preferred. Some of the finer points were not documented and took some time to figure out. An example application was included, but it didn’t provide the type of processing we were doing.

However, the product did perform well overall and took care of about 80% of our day-to-day needs. Its ability to script the business logic was a real plus in our shop.

Yes, there is always a trade-off between performance and maintainability, but in IT shops with a small number of very experienced Java developers, the ability for any member of the team to handle a change or problem is a big advantage. As our abilities as a team become more advanced, the need for simplicity became less of a factor.

Version 3 of eQ! Foundation is slated for release soon, and Browsersoft says that version should resolve some of the workarounds Version 2 required. I anticipate seeing a new scripting engine with better flow control in Version 3. I also expect to see a change to the format of the persistence configuration file that will make the object-to-relational mappings more straightforward.