In-Depth

E-business apps need middleware architecture

• By Stephen Swoyer
• July 1, 2001

"We're moving into an area where you don't need to make links across just your own enterprise, but you're beginning to do linking and integration across enterprises," suggested Judith Hurwitz, president of Framingham, Mass.-based IT consulting organization The Hurwitz Group. "And when you're linking to a certain set of customers, you don't necessarily have a good handle on how many you're going to be dealing with; it could be n number, so you really have to make some changes to the way that you approach application development to deal with that level of scalability."

Now more than ever, say Hurwitz and other industry watchers, enterprise application development teams must begin to think architecturally rather than in terms of task-specific development—especially with respect to development at the middleware layer. What this means, Hurwitz pointed out, is that development projects must not only become increasingly modular, but that middleware software itself must increasingly be written to open Internet standards.

"One of the key differences is that we typically don't take the architectural view, [but] we tend to say 'I've got a project and let's go develop it,'" she observed. "In this new world, we're beginning for the first time to move to distributed processing in a commercial sense, so you have to think architecturally—you can't think in terms of projects."

Andy Sherman, vice president of operations at TurboGenomics Inc., a New Haven, Conn. human bio-informatics research firm, said that an architectural design philosophy based on open standards was a top priority for his company when it launched the development process that culminated in its core product, TurboBlast, a bio-informatics platform for human genomics research.

"If you don't start with the architecture, and if you don't get it right from the start, you're not going to get it right at all," Sherman said. "If you're tempted to build an application like you might have even three years ago, for a single task or to solve a single problem, you've already miscalculated."

According to Sherman, the design and implementation of an architectural base for e-business collaboration was not beyond the scope of TurboGenomics' in-house development staff, but such a task was a far sight removed from the company's core competency. After all, TurboGenomics had an innovative idea for human genomics research: a massively parallel application that could distribute the computationally intensive processing associated with genomics data crunching to hundreds or even thousands of distributed workstations.

Sherman's company did not necessarily want to get distracted by the myriad ancillary tasks and design decisions associated with developing a middleware application layer that provided the distributed file management, user validation and content management services, among others, that were dictated by the e-business architecture that it required. "We have core expertise and competency in building high-performance distributed applications, and not in dealing with some of the things that we would have to design in the middleware layer," Sherman confirmed.

TurboGenomics' solution was a simple one: It implemented an application server as a middleware tier and wrote its own TurboBlast distributed computing application on top of it. The company settled on MetaServer from New Haven, Conn.-based MetaServer Inc., an application server that is optimized for distributed computing and massively parallel applications.

"It's the best of both worlds because it gives us much better performance at the middleware layer than we could ever have gotten ourselves, with integrated security and rapid response to users on things like account management and user authentication," Sherman concluded. "We were able to dedicate most of our energies to our own application and let MetaServer handle all of the management and other pieces."

A one-stop shop for middleware manageability
Application servers such as MetaServer are revolutionizing performance and management at the middleware layer. With a raft of application server platforms and vendors from which to choose—and with established enterprise players such as IBM Corp., Hewlett-Packard Co. and San Jose, Calif.-based BEA Systems Inc., among others, stepping up to the plate—enterprise application development teams have more choices than ever when it comes to developing scalable, manageable applications for e-business.

If the examples of TurboGenomics and of other organizations are any indication, enterprise developers are liking what they are seeing. And there is good reason for that, argued Hurwitz, who said that application vendors and IT organizations alike are increasingly looking at middleware as a kind of "separate middle-level operating system" to which applications can quickly and easily be written. In today's enterprise environments, she noted, middleware is the infrastructure.

"If you define middleware as a set of software services that sits between an end application and [which] ensures communication between different systems and different processes, then you're really talking about an infrastructure, aren't you?" Hurwitz asked.

Dave Miller, director of product management at the Non-Stop software division of Houston-based Compaq Computer Corp., concurred. "More and more companies are buying packaged applications, so we see over and over that people want to buy middleware solutions rather than build them themselves," he confirmed.

Mark Atchison, a client delivery executive at consulting and professional services firm EDS Corp., Plano, Texas, claimed to know a thing or two about the vagaries of middleware design and performance. Atchison, who said that he once oversaw the development of a proprietary Web application server intended to support an Internet banking application for one of his company's clients, claimed he would never go the do-it-yourself route again. "I suddenly found myself in the business of maintaining a Web application server" rather than managing and enhancing the Internet banking application itself, he explained. Unfortunately, Atchison acknowledged, he was devoting considerable time to problems of middleware security, communications and management—at the expense of time that could probably have also been spent augmenting the performance and manageability of his banking application.

"When we'd finally written our own Web application server, it was like I couldn't modify anything in the target app without having to touch the Web application server again," he said. When it came time to redesign his application and upgrade its middleware tier, he determined to go the packaged application server route, eventually settling upon the Sapphire Web application server from Bluestone Software, which has since been acquired by HP. On the management side of things, he allowed, Sapphire Web has been a developer's dream. "I don't have to worry about load-balancing, managing queues, restart and recovery, guaranteed delivery or managing sessions—I can focus on writing the application itself," he said.

To a large extent, application server middleware today is enabled—or broken—by virtue of its adherence to Internet standards, open or otherwise. In this respect, standards such as the ubiquitous Java programming language and the glue-like eXtensible Markup Language (XML) should be part of the lingua franca of any middleware development effort, stated Hurwitz.

Not surprisingly, then, application server middleware from vendors such as IBM, which markets the WebSphere application server; HP, which markets the Total E-Server; BEA, which markets the WebLogic application server; and Billerica, Mass.-based Silverstream, which markets the SilverStream Application Server, offer near uniform support for Java, XML and other emerging standards. But while technologies such as XML and Java are seen as a boon to e-business collaboration between companies, experts point out that they can also do much to simplify management and augment performance at the middleware layer.

"A big question is why would you want to use an application or build an application that locks you into any particular proprietary environment?" observed Scott Hebner, director of marketing at WebSphere software with IBM. "It certainly limits your ability to integrate with other businesses and other opportunities, and it also limits your ability to manage your application, particularly in highly distributed situations."

Vince Hunt, executive VP of engineering for Monterey, Calif.-based Altura International is a vendor that collects and consolidates merchant catalogue information from a variety of sources. He has experience with middleware performance management in highly distributed situations. When his company needed to shore up the scalability and manageability of its bread-and-butter e-commerce application, Hunt said that one thing seemed painfully clear: the application itself was not the only bottleneck. Managing more than 125 servers on an individual basis was no picnic.

In 1997, Hunt explained, Altura developed its Altura Merchant Operating System (AMOS) application using the ColdFusion development environment from the former Allaire Corp., which has since merged with San Francisco-based Macromedia Inc. "We quickly learned that we could not scale our site using ColdFusion as our application server," he said, noting that Altura's ColdFusion site had exploded to the size of more than 125 individual servers. But the bigger problem, Hunt recalled, was management, especially in his company's highly distributed ColdFusion environment: "Since ColdFusion doesn't provide any centralized management, we had to manage all these servers—and our application—on an individual basis."

Because it already had an on-staff team of development engineers who were fluent in the Java programming language, Altura made the decision to rewrite AMOS using Java—which also gave it the opportunity to be essentially hardware-independent from an application point of view. Once that decision was made, Hunt began to evaluate Java application servers for AMOS' middleware tier. He said that performance and manageability were his primary concerns in this area.

"Performance, stability and centralized management were the three most important benchmarks against which we weighed the vendors," Hunt recalled. "We wanted a very fast, reliable site that we could manage without hiring dozens of people."

Hunt reported that AMOS has been up and running on Sapphire Web for almost a year without a hitch. And thanks to Sapphire Web's Java support, he concluded, Altura has been able to quickly write code refreshes for AMOS on a weekly basis without having to worry about compatibility issues with its application software's middleware tier. "We never stop adding features or new malls, and we just write the Java and HP/Bluestone does the rest," he explained, noting that AMOS supports an average of 100,000 users per day.

Final thoughts
In the final analysis, contended IBM's Hebner, the application-server-as-middleware tier offers another strong selling point, as well: portability. "Today, it's possible to build [applications] for the Internet with less and less of an investment for any particular OS, because the OS no longer has to be the defining standard for applications," Hebner said.

More importantly, Hebner suggested, if enterprise developers build applications to standards such as Java and XML—and to emerging standards such as the Simple Object Access Protocol (SOAP), which defines a distributed object access protocol that is based on HTTP; and Universal Description, Discovery and Integration (UDDI), an XML-based specification that interoperates with SOAP—they can be ported, sometimes with little trouble, from one application server middleware layer to another. This kind of portability could be a big bonus, he suggested, if one application server vendor should offer competitive scalability or manageability advantages over another; developers could move their applications en masse to the better platform.

"If you build to the application server, you're really building to the open environment of the Internet, because the Web application server is sort of the center of gravity of the new e-business infrastructure," Hebner claimed. "If you build to WebSphere, for example, you don't get locked into an IBM control point, you're still able to integrate with other applications and you could even move to other application servers."

Finally, Compaq's Miller suggested that established enterprise players such as IBM and Oracle Corp., Redwood City, Calif., will also help to ease the pain of management at the middleware layer as they increasingly integrate their application server platforms with many of their other product offerings. "Some of the problems associated with middleware performance management can be solved because of vertical integration; [for example] Oracle will build its performance management tools and build pathlinks to its EJB server, and IBM will build its performance management tools where they've got their database and Web application server linked together," he said.