InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

July 6, 1998

Middleware Evolution

Building middleware architecture requires linking Web, client-server, and legacy systems. Tools that take the complexity out of application integration are arriving.

By Alan Radding

uilding a middleware architecture that unites Web, client-server, and legacy resources requires lots of discrete pieces to create a coherent whole capable of delivering real business value. IT departments often have to use a variety of experts skilled in Java, transaction monitors, message queuing, and object brokering to support the various types of applications that must be integrated.

In building a Web transaction application, the IT department must integrate a Web server, middle-tier application server, host application, and database. The middleware required will include a transaction-processing monitor, a Web gateway, an object broker, and some sort of application format translation.

If that seems too complex for a single programmer to handle, it probably is. Most of the middleware designed to carry out these procedures was written by and for engineers. Typical IT departments can no longer employ a cadre of experts to implement and manage all these middleware pieces. The business demand for new applications is too great for IT staffers to be implementing middleware in a piecemeal fashion.

That's why IT departments are demanding--and middleware vendors are starting to deliver--tools that take some of the complexity out of application integration.

Various types of middleware vendors are getting together to bundle their offerings into a single package with an easy-to-use interface that often doesn't even require users to write code. IBM's upcoming Web Sphere application server, for example, will include a Java development environment, Corba object-servicing, a transaction monitor, message queuing software, and other tools for building middle-tier applications and integrating them with the Web and legacy systems.

Active Software Inc.'s Integration System is another example of a product that bundles multiple types of middleware into a single product. The Integration System gives business analysts a rich set of tools for working at the business-process level, not the code level. Active's integration environment encapsulates and automates what in the past has been a repetitive process of coding and linking applications into reusable components that handle complex plumbing chores.

So rather than building a complex middleware architecture and choosing products that fit within it, IT departments are increasingly se-lecting a single product that meets most, if not all, of their application integration needs.

Brigham Young University in Provo, Utah, resolved its middleware problem with Sybase's Jaguar transaction server. The school keeps student admission applications and academic records in a variety of mainframe systems, but needed to make those records accessible to students, faculty, and administrators through the Web. Jaguar middleware lets users running client-server applications or browsers access applications running on the mainframes and Unix servers.

Imation Corp., a manufacturer of printing, publishing, and imaging products that was spun off from 3M last year, runs its core business systems on a variety of OpenVMS, Hewlett-Packard MPE, and Unix systems. Imation also wants to make information from those legacy systems available throughout the organization via a Web browser. Its middleware architecture: SuperNova, a fourth-generation-language development environment turned middleware that will let developers connect these systems in hours, not weeks or months.

With the advent of the Web, IS managers are left scrambling to connect systems that were never designed to talk to one another--systems that were developed and deployed long before anyone even imagined a World Wide Web or component-based applications. The need for speedy development is also a top criterion. Business users can't wait for the IS department to retrofit or rebuild systems.

Lots Of Options
When it comes to middleware, there's no lack of solutions. The problem may be too much middleware and no coherent strategy for pulling it all together. The situation is getting more complicated as vendors introduce a new generation of middleware such as object-component request brokers (ORBs) and application servers. "The new middleware isn't replacing existing middleware," says Ken Rudin, CEO of Emergent Corp., an IT consulting firm. "The new middleware represents additional functionality."