The Use Case
VNU Publitec is the internal software house of VNU World Directories, a subsidiary of VNU, a leading media and information company. VNU World Directories produces classified telephone directories (Yellow/White Pages) and also provides similar services on the Internet in several countries. VNU Publitec provides the set of software referred as BiRDS, to support the core business of VNU World Directories business units.
BiRDS went through several iterations but the latest iteration was re-worked in 1999 using Microsoft Visual J++ to implement the business components and Visual Basic to implement the user interface. Since then, the product has been deployed to VNU World Directories business units in the Netherlands (Gouden Gids), Portugal (Paginas Amarelas), Ireland (Golden Pages), and Puerto Rico. At the time of writing, it was in the process of being deployed to South Africa.
The Business Problem: Replace J++ While Supporting Existing Customers with Existing Code
Due to the dispute between Microsoft and Sun, Microsoft had stopped supporting Visual J++. This left VNU Publitec with a choice of moving all the way to Microsoft (.NET), or all the way to Java, or preserving the current configuration. None of the choices were acceptable.
Going exclusively with .NET was not a choice because J2EE had been chosen for the server side architecture and quite a lot of services had been implemented on top of it, using hard to replace components like servlets, EJBs, and JMS. Also, .NET was still a new technology and due to incompatibilities between VB6 and VB.NET, moving to .NET was not an easy task even if only the user interface components were concerned.
Going exclusively with Java was not a choice because a wholescale migration of the UI components to Java was deemed unattractive. Rich client development in Java was still not at the same level that a native Microsoft implementation could offer.
Evaluating the Integration Options
These conditions forced VNU Publitec to find an alternative to Visual J++. Any solution had to fulfill the following criteria:
it needed to preserve compatibility while keeping all options open for the future
it needed to allow use of the existing VB code with minimal change
it had to support an eventual port to the .NET platform
There were quite a few options in the market. VNU Publitec did some investigation and even implemented a pilot using JavaBeans Bridge for ActiveX. When they discovered JuggerNET, it was a product at beta stage, but it looked very promising nevertheless.
Now, VNU Publitec has a corporate license for JuggerNET and is in the process of adapting the software to use it instead of Visual J++/ Microsoft JVM combination to expose Java components to COM clients.
Hear It Straight From the Customer
The following statements are taken from an email we received from the engineer in charge of the development project. They are dated, particularly with respect to the missing features which are all part of the current release, but they speak for themselves.
"Major factors that lead us to choose JuggerNET were the excellent support we got and the commitment of Codemesh to the product. Originally, COM support was not so strong but we worked together with Codemesh to bring it to a level where we could confidently start migrating our applications. In some areas (e.g. exposing Java exceptions to COM clients) JuggerNET is doing much better compared to what we use now."
"Another benefit is that you can use JuggerNET by only installing the .NET SDK. It generates all the required .NET project files and you can automate the build process, even using Ant."
"As a 1.1 product there is still some room for improvement. The user interface needs some improvements and a few fixes but the issues here are minor or cosmetic ones. We expect the UI to be improved with the coming releases. The only major concern we have is related to our desire to partition the proxy classes into several assemblies; JuggerNET works great if you have one set of Java classes to be used as a set by one or more COM/.NET applications. If you start using the same or intersecting sets of Java classes in multiple COM/.NET components that you then want to combine in one application, you currently need to generate a "mega proxy" that exposes all Java classes for all COM/.NET components. This may cause trouble in terms of packaging and release synchronization, as it would require re-testing and the re-release of everything even if there is only one Java class changed. An alternative is to expose the same set of Java classes several times. If there is no creator/user overlap among the Java classes used by different COM/.NET components, the only drawback is the pollution of your registry (i.e. the same Java class being registered several times with different GUIDs). If you have creator/user overlaps, then this is not an option."