A J2EE/C++ application server running on six different operating-system platforms.

In April 2000, I joined the Twister core team of the Brokat Server Technology Division (STD), where the J2EE Application Server “Twister” was being developed.

At the time, the server was sold as an independent product. Unfortunately, in 2001 the decision was made to stop competing with the big players and to use the server as a platform for internal customers only. That remained the state of the product until July 2004, when the final decision was made to discontinue development of the Twister J2EE application server and move to the BEA WebLogic platform instead.

Projects

The following list gives an overview of all the Twister-related projects I worked on.

Twister 6.0 (Codename: NEO)

At the beginning of 2004, a final attempt was made to develop a new major version of Twister. The idea was to get rid of all C++ legacy components and re-implement the functionality in Java.

In the Twister 5.x product line the following components were still implemented in C++:

• Launcher
• LoggingService
• NamingService
• LoadbalancinService

Support for RDOs and the LicenseService was not required anymore and thus could be dropped for Twister NEO.

Launcher

The Twister Launcher is responsible for starting the various processes and continuously checking them for availability. If an unavailable service is detected, the Launcher attempts to kill the hanging process and eventually restarts it to bring the service back to life. This functionality is nearly impossible to implement in pure Java, so a small native library was necessary to provide these process management features.

LoggingService

The C++ version of the LoggingService, like the NamingService, had many fault-tolerant features. The Twister version of the Java Logging API could detect an outage of the LoggingService and transparently switch to a fallback instance. When no service could be reached the client writes logging records into a local file and retransmits the records as soon as a LoggingService becomes available again. These key features had to be preserved for the pure java solution.

NamingService

In Twister NEO the fault-tolerant CORBA NamingService has been substituted by a NamingService interface directly in the Launcher. Each Service, started by the Launcher is registered in the service repository list and thus can be found by a client lookup. In the first version of the new NamingService, no fault-tolerance features were planned.

LoadbalancingService

The biggest challenge was the LoadbalancingService (LBS), which is responsible for instantiating RDO or EJB objects. The initial request to an object is sent to the LBS, which checks whether an instance of the object is already instantiated and creates one if not. Objects live in containers, and the old LBS had a sophisticated algorithm for distributing load across the configured number of containers. The new, pure Java solution features a plugin mechanism for load-distribution algorithms. By default, a round-robin algorithm is used, distributing requests evenly across the different containers.

An alpha version of the services had already been implemented. Unfortunately, the decision was made to completely stop development because the risk of switching to this new Twister version for the various projects was considered too high.

LoggingService - SNMP Trap Functionality

For the C++ LoggingService, I implemented an SNMP trap feature. A section in the configuration file config.xml contained a list of error ID ranges for which an SNMP trap should be sent to a configurable list of trap hosts. When the SNMP trap feature is enabled and an error with an ID from the configured range occurs, the logging service sends an SNMP trap to each of the trap hosts.

JSR-77 - J2EE Management Specification

For Twister 5.3 I evaluated the J2EE Management Specification and implemented the Managed EJB (MEJB) from this specification for the distributed Twister service framework. This implementation is based on a ManagementService component which provides the MEJB via a RMI-IIOP interface. MBeans can be registered at the ManagementService’s MEJB by configuration or programmatically.

The MBean hierarchy, as proposed by the JSR-77 specification, was planned for the next version of Twister and has not been implemented for Twister 5.3.

EJB 2.0 Local Interfaces

For Twister 5.3, I implemented EJB 2.0 Local Interface support for stateless and stateful session beans (EJBLocalObject, EJBLocalHome).

Testing

For performance testing, we used the J2EE test frameworks ECPerf and SPECjAppServer 2001/2002. I customized the latter to use them as a regression test suite that could be run automatically during nightly builds.

We used version 1.3 of the J2EE Compliance Test Suite (CTS, only available to Sun Java Partners) in an attempt to obtain J2EE 1.3 compliance certification for the Twister application server. We tried to automate the J2EE CTS test runner so we could use it during nightly regression tests, but unfortunately the 1.3 version of the CTS did not support this. The test runner had major flaws, forcing us to split the entire test run into many small steps. We never got it working reliably before the strict licensing conditions stopped us from proceeding. Version 1.4 had already been released, and licensees were required to finalize the licensing of a version at least 1.5 years after a new version was released. Due to resource constraints, we were unable to meet this deadline and ultimately gave up on the certification.

OpenORB

When the decision was made to use OpenORB as the basis for the Java components of the Twister application server, I started providing internal support for OpenORB-related issues.

In October 2001, I obtained CVS write access to the OpenORB CVS server hosted at Exolab. Around December 2002, Steve McConnell and I decided to fork the project to get the community more involved in decisions about its future. We chose the name “The Community OpenORB” for the project and moved the sources to SourceForge. The current status of the community effort can be tracked on SourceForge. I stopped contributing to the project in December 2004, after it was clear that the Twister project was finally dead.

A list of all my bug reports to the original OpenORB project can be found here (70 bugs). My contributions to “The Community OpenORB” can be found in SourceForge CVS and on the mailing-list archives.

Security

In Twister 4.x, the C++ Secure Socket Layer (SSL) implementation was not fully standards-compliant and caused incompatibilities when communicating with the standards-compliant Java Secure Socket Extension (JSSE) used by OpenORB’s SSL module. My task was to make our legacy C++ SSL implementation fully compliant with OpenORB’s SSL/JSSE implementation.

For Twister 5.3, I started a Common Secure Interoperability Version 2 (CSIv2) implementation in order to pass the interoperability category of the J2EE Compliance Test Suite (CTS). This effort was stopped when it turned out that J2EE certification was no longer a goal. A first draft of the implementation can be found here.

Build Process

As the Twister 4.x/5.x versions evolved, the software’s core functionality started spreading across many different CVS modules. As a consequence, maintenance became very time-consuming due to the dependencies. To address this, I created the Twister Meta-Project (TwiMP), which wraps the different CVS modules into a single Ant-based project, creating the impression that there is only one pure Java module and hiding the C++ legacy components behind the Ant build script.

For Twister 5.3 and Twister 6, we used a customized version of our internal CruiseControl system for continuous build integration on a TwiMP instance. Part of the customization involved making tools like FindBugs, PMD, and Checkstyle work on a TwiMP instance to generate code quality, test coverage, and bug-pattern detection reports for the Twister source code.

Fault-tolerant NameService and JNDI Service Provider

In Twister, the CORBA NameService is an integral part of the application server. The Twister 4.0 implementation provides a fault-tolerance mechanism that causes the service to violate the CORBA NameService specification. The goal for Twister 5.0 was to make the NameService compliant with the OMG specification while preserving the fault-tolerance features.

The previous NameService was written in C++. All bindings were stored in the root context, and creating sub-contexts was not possible. For the new version, I chose to implement the CORBA IDL interface defined by the NameService 1.2 specification and to provide the fault-tolerance mechanisms via an IDL interface extension.

The “CosNamingExtFT” extension interface was introduced for creating and manipulating fault-tolerant contexts and bindings. A context can be created in either normal mode or fault-tolerant mode. In fault-tolerant mode, CORBA object instances running on multiple nodes can be bound under a single name in a fault-tolerant context. Upon lookup, the NameService tries to return the entry for the local node first. If no local instance is available, the first entry from the list is returned. The NameService checks with a “ping” invocation whether the instance to be returned is available. If this check fails, another entry from the sub-context is pinged. Only if no object can be found is a NameNotFound exception thrown.

Additionally, a CosNaming Service Provider Interface (SPI) for the Java Naming and Directory Interface (JNDI) was written. This wrapper allows Java clients to access objects in the NameService via standard JNDI lookup mechanisms.

Base Toolkit

The base toolkit is the API for RDOs (Repository Defined Objects), Twister’s proprietary component model, used by application developers to interact with the application server. This API is available in the Twister 4.x and 5.x versions.

The API was designed with simplicity and consistency in mind. The goal was to minimize the differences between the C++ and Java programming languages. A developer switching between the two languages should not see any major differences, other than the inherent language-specific ones. This was especially important for projects that were migrating from C++ to Java, where many legacy components were still written in C++ while new components were already being developed in Java.

Examples

Implementing examples for the 4.0 version of the Twister application server was my first task on the new job. This gave me the opportunity to start learning about the application server internals.

The examples were shipped with the 4.0 version of the product and served as a starting point for application developers building projects on top of the Twister application server.

The examples are based on the factory pattern and use the classic Account scenario. The client applications and server objects are developed in all Twister-supported programming languages (Java, C++, TCL) and component models (CORBA, EJB, RDO).