The distribution of business intelligence through a network of organizations within an enterprise requires the evolution of spontaneous networks, which in turn requires middleware that facilitates intelligent communication of information regardless of platform, device or application. In this context Java provides a natural platform-neutral object-oriented approach that supports a scalable messaging service, JMS (Java Messaging Service), now a standard part of the Java 2 Enterprise Edition (J2EE).

Leading the way with a JMS interface to their messaging service is SoftWired, whose iBus//MessageBus is the first of seven products that allow companies to build scalable electronic business systems more easily. iBus distributes messages and business events through various communication protocols to diverse applications. SoftWired decided to use Java for this product as early as 1996, when few tools were available to assist developers with this relatively new language.

Lightweight messaging middleware written entirely in Java is the core of SoftWired's iBus solution. This publish/subscribe middleware allows any type of computing device (PC, server, mainframe, PDA, cellular phone) to efficiently exchange information by any communication protocol (IP multicast, TCP/IP, HTTP, wireless).

Working as a unit of nine developers, SoftWired needed to ensure that MessageBus was fast and efficient enough to deliver business events in near real-time. When Silvano Meffeis, executive vice president of SoftWired, encountered a performance problem in the module that set up the network configuration, he used JProbe Profiler from KL Group to find the cause.

He had suspected that the problem lay in serialization/deserialization of the network objects. "That was only a guess until I ran Profiler, which pinpointed exactly where we needed to optimize." JProbe soon became an indispensable part of SoftWired's development: "JProbe Profiler enabled us to enhance the performance of our Java messaging middleware by 50%."

Meffeis also found performance bottlenecks in unexpected places. He found that using the "+" operator to concatenate strings was simple to code but expensive to run, since each concatenation actually created a StringBuffer object that was thrown away after use. Detecting performance problems related to string manipulation would have been difficult without tools such as Profiler, since the calls to these methods were distributed throughout the package. After witnessing the effects of the methods on the system's overall performance in Profiler, Meffeis decided to use them less often. By converting the strings to byte arrays before transmission and converting them back to strings only if required, Meffeis improved the performance of the module by 20%.

Using JProbe Profiler on MessageBus was just the beginning. JProbe's Memory Debugger (fully integrated with JProbe Profiler) enabled SoftWired engineers to find message objects that were no longer being used but still taking up precious memory. Once these objects were located, following the stack trace back to where these objects were created was easy, enabling the developers to manage them more effectively.

Senior software engineer Bill Kelly of SoftWired used JProbe Threadalyzer to look for race conditions or missing locks on data. "I ran some tests and it pointed out how a few messages should have been synchronized, things I'd never have found myself."

Threadalyzer also caught a race condition. Race conditions and other thread problems manifest themselves rarely, but when they occur, the results can be unexpected and catastrophic. "We hadn't noticed any symptoms," Kelly says. "We were lucky." Debugging thread problems without tools is notoriously difficult. "If [the race condition] had ever come up in practice, it would have been extremely complicated to try to find."

Kelly says, "If you're working on software that's already complex, the threading issues can have devastating consequences. Having performance-tuning and thread analysis tools to look over your shoulder is essential." He also found JProbe Coverage useful for establishing which parts of the system had not been executed and required testing. "Having a coverage tool can motivate you to test better. It's fun to see yourself getting closer to the coverage level you've set your sights on."

Working out the problems of the iBus//MessageBus modules early was important to SoftWired. Releasing iBus//JMS in September 1999 was a key milestone. With JMS a standard part of J2EE, application servers will need to upgrade to this level of service, and at present few application servers have a JMS implementation.

SoftWired's JMS interface means that their iBus solution can be combined with an application server and SoftWired add-on products to constitute a complete set of J2EE-compliant services. With an implementation in 100% Pure Java, accurately profiled and tested for performance, memory, and thread and test coverage problems, SoftWired's engineers are confident that these products form the ideal building blocks of large and complex networks, spanning platforms, systems and protocols.