Real-world Java: Packaging processware with Java

In its three short years, Java has earned a reputation on the server-side of the enterprise as an exceptionally flexible development and deployment platform. Java has proven itself well-suited for bridging the gap between existing back-end systems or databases and a new breed of intranet and Internet-enabled applications.

CrossWorlds Software Inc. of Burlingame, CA, is looking to take this capability to a new level by packaging Java’s server-side prowess into something it calls processware. In short, CrossWorlds promises to deliver out-of-the-box information interchange capabilities between many of the most dominant applications on which businesses run their enterprise — Enterprise Resource Planning (ERP) systems from Baan, Oracle, PeopleSoft, and SAP; and customer interaction applications from Aurun, Clarify, Scopus Technology, Siebel Systems, Trilogy, and Vantive. Aside from showing that Java has what it takes for building industrial-strength apps, the company’s Java-based development effort has yielded many lessons that JavaWorld readers no doubt will find valuable.

Getting started

If financial backing is any indication, some very knowledgeable people in the computer industry think CrossWorlds is bound for success. Since its founding in April 1996, the firm has raised more than 0 million of capital, including corporate investments from Compaq, Intel, Ernst & Young, J.D. Edwards, Intel, and SAP, and private investments from 50 computer-savvy CEOs (including Michael Dell of Dell Computer Corp. and Dave Duffield of PeopleSoft Inc.).

Strikingly, CrossWorlds is building its processware vision on Java. One of the key people behind this decision, Prashant Gupta, joined CrossWorlds as chief technology officer after stints at Sybase and then Illustra. When he asked his C++ and C language-savvy developers to use Java he initially got a cool reception. Nonetheless, Gupta made the decision to prototype the system in Java and the revisit the decision in two or three months.

Initially, Gupta took up work on a Java project and assigned some of his reticent staff to components they could code in C++. But it did not take long for his staff to begin complaining that Gupta had the easy assignment, because while they “had to” work in C++, Gupta was coding in Java.

Once the C++ developers wanted to learn Java, they climbed the learning curve fairly quickly. Indeed, Gupta reports teaching himself the language and producing some working code within the first day.

Productivity boost

CrossWorlds does not maintain specific metrics that show how much more productive developers are when writing code in Java, but Gupta says he is convinced by his own experience, and similar work at other companies, that the boost is significant. After spending two hours looking over the syntax of the language, Gupta sat down to write one of the first collaboration prototypes and completed the task the same evening. In one day he had learned the language and produced 1,400 to 1,500 lines of code. Moreover, says Gupta, the next day — in only two hours — he entirely rewrote the collaboration prototype in a much more compact and optimized fashion.

The elegance and simplicity of Java’s object model is paying dividends, says Gupta. “We get all the power of objects — inheritance, reuse, etc. — without the complexity that comes with other languages. The exception handling is very nice and straightforward, and garbage-collection is taken care of for the programmer,” he says.

Gupta estimates Java enables his engineers to be three to five times more productive than they would have been using another language. The well-defined exception handling and freedom from most memory management concerns enable developers to produce much cleaner code, he says. Having built similar system software in C and C++, Gupta also says he sees far fewer bugs with Java.

CrossWorlds’ solution

CrossWorlds’ mission is to package what many integration teams are busy doing, and put it in a box. Rather than integrating best-of-breed applications on a case-by-case basis, why not take the most popular enterprise-class customer interaction applications and the dominant ERP applications, figure out which tasks or business processes would benefit from collaboration, and then deliver that infrastructure?

The firm says 95 percent of that functionality is delivered right out-of-box. The remaining 5 percent involves configuration and extension by the implementation team. Rather than integrate all possible business processes of a given application, CrossWorlds integrates only known applications and known processes — those that clearly need to interact with an outside application.

CrossWorlds’ runtime environment consists of three components: The InterChange Server, Collaborations, and Connectors.

Connectors provide a single interface point and are thus a gateway into a particular packaged application, with all the communication logic necessary to call its APIs. Approximately 80 percent of the code in connectors is written in Java. CrossWorlds originally used JDK 1.01 call-outs, but recently migrated to Java Native Interface (JNI) to call application-specific APIs. Connectors isolate application dependencies, such as whether the applications use DCOM or CORBA.

Collaborations, which are written completely in Java, contain the cross-application business logic generic enough to sit in between functional spaces. Collaborations use connectors as agents to interact with specific packaged applications.

The InterChange Server is written completely in Java, with no native platform extensions, but does include some embedded C++ code from third parties. CrossWorlds currently delivers its server on Windows NT only, but Gupta is considering platform alternatives. The server includes several third-party components, including an object request broker from Visigenics; a transformation engine from TSI Mercantor; drivers to various messaging infrastructures such as IBM’s MQ Series, MSMQ, Tibco, and BEA; and a rules engine from Neuron Data.

The CrossWorlds runtime environment does not add a new user interface to the application infrastructure, but rather sits in the background and delivers integration services.

CrossWorlds also provides a few Windows-specific tools to configure, monitor, and manage the environment, as well as tools to build custom collaborations and connectors for legacy applications.

CrossWorlds uses messaging, rather than remote method invocation (RMI) or the Internet Inter-ORB Protocol (IIOP), to communicate between the components, and uses IIOP to communicate between the tools and the runtime components. Since the runtime environment cannot guarantee the availability of all external applications, an asynchronous execution model is essential, says Gupta.

Performance concerns

Early on, CrossWorlds had significant concerns regarding server performance, but a little luck and a lot of work has delivered quite acceptable speed, the company says.

The development team thought long and hard on the kind of code that would be put into the server — code that would be executed over and over again. The just-in-time compiler (JIT) delivered an unexpected performance windfall, says Gupta. As soon as the JIT saw a class being executed or accessed a second time, it compiled it down to native code. As a result, he says, the performance difference between Java and a C/C++ server was greatly minimized or eliminated.

CrossWorlds now is working with Compaq and Intel to “tune the hell out the implementation” running on Windows NT. “We profiled the entire server and we cut it every way we could think of — where we were spending time, where the VM was spending time, which functions and which modules were taking the most time,” says Gupta. “We even went back to some of our vendors and asked them to write their Java code a bit differently so that the code we received was better optimized.”

Object creation is one example of an area where the team rethought how they were doing things, Gupta says. Early on they found it was so easy to create objects that the code was creating objects even for temporary storage. Certain VMs handle object creation much morely slowly than others, and there was no getting around the need to create objects. The team eventually hit on the idea of allocating memory and creating objects at start-up. Those objects can be recycled and reused across the various threads. Now the code allocates thread or thread pools for various tasks, and the start-up time now absorbs most of the cost for object creation.

Anywhere you abstract functionality to a higher layer, you ought to expect a performance impact, Gupta notes; this is a trade-off you have to make, at least from a server-centric perspective. The abstraction of the locking or the synchronization primitives to a simple verb, for instance, is going to have an impact, but now the number of contention points for resources (originally 50 million) has been reduced significantly.

Non-Java GUI

CrossWorlds chose not to use Java for the GUI portion of its application. When making this decision, they had only JDK 1.0 to evaluate, and there were several conflicting alternatives lining up to supplement the JDK’s then-challenged GUI. The firm wanted to deliver highly visual configuration tools with drag-and-drop capabilities and the ability to select and move objects, and determined JDK 1.0 was not up to the task. (CrossWorlds refuses to pass along products to its customers based upon code that is not yet released, so beta versions of the improved JDK wouldn’t do, either.) Thus, CrossWorlds decided to go with the Microsoft Foundation Classes, implementing the GUI in C++.

Gupta is quick to concede that Java’s GUI capabilities have come a long way since the Fall of 1996. That said, he is not planning on changing the GUI any time soon. “We still need to find out how much you can really do with an applet. We don’t want people to have to download huge applets to do remote management. Probably the middle of next year is when we’ll take a closer look at moving toward a Java-based browser GUI,” he says.

While CrossWorlds put its foot down firmly in the Windows camp for the GUI portion of its application, it anticipated that Java’s evolution would make it possible (and possibly desirable) to shift to a Java GUI in the future. Thus, the developer team designed the GUI architecture in a way that allows them to move toward a pure Java GUI, says Gupta. The tools, which are a small portion of what CrossWorlds delivers, let administrators configure server-side operations, and play a minimal role once things are up and running. CrossWorlds developed the tools with a very clearly defined interface between the presentation layer and the application logic, he says.

Other features

Over the last two years, a lot has changed besides Java’s ability to deliver more sophisticated and reliable user interfaces. Such changes present some interesting choices — what, why, and when should CrossWorlds upgrade code that may work fine as is, simply to take advantage of more standard Java-enabled infrastructures?

Among the things Gupta said would be far easier to build today than when CrossWorlds began working with Java, or that he would not have to build at all today, are persistency services, the two-phase commit piece of the transaction service, and the messaging service.

Since the CrossWorlds architecture roughly mirrors what has been done with the Enterprise JavaBeans specification, Gupta says it will be fairly easy to migrate toward the evolving server-side Java standards. The payoff: the firm can then off-load the responsibility for keeping pace with changes in the underlying technology. “We did all this because we had to build an enterprise-wide, mission-critical solution,” Gupta says. “If the underlying technologies can now provide that solution, then I am happy that my product teams will not have to be responsible for developing and enhancing those infrastructure components.”

Conclusion: a bet that paid off

CrossWorlds is reaping significant benefits from electing in 1996 to go with Java. In addition to programmer productivity, Gupta cites the example of potential delivery of the server on other platforms. He says he is “very impressed” that the company was able to take JAR files built on NT and run them successfully on Solaris. Aside from productivity gains for developers, Java offers another benefit: the elimination of one- or two-person porting teams would be dedicated to a specific server platform — a common investment among database companies. By eliminating such porting expenses and boosting developer productivity, Java greatly enhances the opportunities, letting the development team concentrate on adding features, fixing bugs, optimizing performance, and otherwise improving the product.