InformationWeek
Defining The Business Value Of Technology
July 6, 1998
Middleware Evolution
continued...page 3 of 3Similarly, the Sabre Group is putting off making a commitment to Corba or Microsoft's COM middleware as it builds business travel applications for the Web. "There's still a shakedown occurring, and it's not clear who will be the winner," says Todd Cinnamon, development manager at Sabre, the IT arm of American Airlines.
Sabre develops three-tier client-server applications. Rather than build an overall middleware architecture, it uses Noblenet, RPC middleware, to connect pieces of the application between different tiers. Otherwise, Sabre's developers would have to write a remote procedure call for each connection and hard-code the RPC to each application. To accommodate Java calls, the company built its own RMI (remote method invocation) server last year. RMI is the Java object equivalent of RPC. A new Noblenet middleware product called Nouveau is expected to handle both Java/RMI and RPC.
While Corba, Enterprise JavaBeans, and COM promise to dominate architecture planning for the distributed component world, organizations face less-exciting but still-important development projects that require middleware. For these, traditional middleware continues to be preferred.
No Language Barrier
For example, Syntellect Interactive Services, a processor of pay-per-view and other cable services, needs to connect customers coming in via a wide range of systems--telephone, PC, and Web--to back-end applications running on HP 9000 servers and an Informix relational database. Syntellect opted for Tuxedo as the basis for its middleware architecture. Syntellect builds its front-end applications using Prolifics, a fourth-generation language that includes support for Tuxedo. Applications talk either Tuxedo or ODBC, notes David Campbell, director of engineering. By opting for Tuxedo, Syntellect feels it's positioned for whatever the future brings. "We'll progress to Corba and Java, and BEA's M3," Campbell says.
Fair, Isaac & Co. a provider of credit-scoring and risk-management information to the banking industry, must enable its host systems for use with the Web. Working with Concept 5, a middleware consulting firm, Fair Isaac built Java-based thin-client front ends to run against its MVS applications. Concept 5 developed a custom middle-tier architecture, which amounted to an ORB acting as an application server. The middle tier steers requests and information between the clients and the hosts while performing the necessary translation.
"We're using middleware primarily for communications between the front and back ends," explains Walter Nelson, Fair Isaac's VP of software development. Front-end development is Windows NT-based and COM-oriented. The company plans to migrate to Microsoft's MTS Transaction Server in the future and put more logic into the middle tier.
Similarly, the Colorado Integrated Criminal Justice System found itself under the legislative gun with its many information systems: AS/400, DB2, VAX, HP 3000, Sequent, relational and nonrelational databases. None of them could communicate and share information at any level. The IS groups of the five agencies involved in various aspects of criminal justice were ordered to make the systems work together and make them accessible to local police and courts via the Web.
To do so, the developers adopted Sybase's data and middleware architecture. Sybase's Omni Adaptive Server combines the database and middleware, explains Dave Usery, the department's CIO. "We originally considered using low-level middleware like NFS and DCE and doing it ourselves," he recalls. The technical difficulty of such a low-level approach, however, led them to the packaged middleware solution.
Now, each of the five agencies involved writes in its preferred development language for its existing platform. All calls go through Omni's open client. The middleware translates the request and fires off the appropriate stored procedures. "We ended up writing a lot of stored procedures, especially for the MPE and VAX machines," notes Usery. But the payoff from the middleware came from allowing each agency to continue to use its own technology.
All this new middleware presents a quandary for IS managers. An organization can easily find itself buying and managing different pieces of middleware for different applications, without a middleware strategy. The problem is particularly difficult when choosing an application server or an ORB. There are probably a dozen or more application servers on the market, each offering similar but not quite identical functionality, and ORB technology is still rapidly evolving.
The choice of object middleware--Corba, Enterprise JavaBeans, or COM--isn't really a problem now, unless you use the very newest technology. The tools are still too immature for mainstream business use. "They all lack general application services, scalability, integrity--all the things you get from transaction-processing monitors," says the Standish Group's Boucher. Although platform issues are a major consideration now, by the time this technology is ready for wide use, the platform constraints won't matter, he says. Corba and enterprise JavaBeans are already tightly wedded, and vendors are introducing products to bridge the Corba, Enterprise JavaBeans, and COM object models.
But one thing is certain: Unless you think the Web and distributed component systems are passing fads, organizations are going to need a flexible middleware architecture as they integrate new applications with existing systems.
return to page 1, 2
Read sidebars: "Best Practices For Building A Middleware Architecture," "Reduce Multitier Complexity," "Middleware Services Required For System Integration," and "Wall Street Middleware Group."
Illustration by John Bleck
Back to News In Review
Send Us Your Feedback
Top of the Page
Featured Microsite
