InformationWeek.com

Welcome Guest. | Log In| Register | Membership Benefits

July 6, 1998

Middleware Evolution

continued...page 2 of 3

Middleware is software that connects one system to another at some level--network, database, object model. Communications gateways are middleware, as are transaction-processing monitors. Open Database Connectivity and Java Database Connectivity are examples of database-access middleware. More recently, technologies such as Corba, Enterprise JavaBeans, and ActiveX/COM are being used as middleware for object-oriented development. So, too, are Web and Java application servers that connect Web clients to server-based applications.

Middleware falls into one of four categories: gateways, transaction-processing monitors, messaging, or object brokering. Any middleware architecture will have to support all four types of middleware if it's going to have any long-term value.

Consolidation and integration is the trend among vendors in the middleware market. A Web application server may combine a protocol or application gateway and transaction-processing monitor. The latest offering from BEA Systems Inc., which provides Tuxedo, a transaction-processing monitor, will incorporate an ORB and, eventually, messaging in a single product to be called M3. Other efforts are under way to combine ORBs with messaging, which entails bolting together both synchronous and asynchronous communications capabilities. "We see a lot of different technologies being melded together," says Sally Cusack, a market analyst for consulting firm SPG Analyst Services.

The demand for a coherent middleware architecture is driven by the requirements of the distributed component environment. In the multitier environment, objects and components call for services from other objects and components. Object brokers or ORBs find the appropriate objects and components an application needs, route the information, and perform the required transformations so the various pieces can communicate regardless of the language they were written in or the file format that was used. IS departments can't build these kinds of distributed applications without a lot of middleware.

ORBs are the fastest-moving middleware segment, growing at 65% a year, over a five-year period, according to Karen Boucher, VP of the Standish Group, a research firm. Messaging is also hot, expected to grow at 49% annually through 2001, when it will break the $1 billion mark. Transaction-processing monitors are the most mature form of middleware and are growing the slowest--12% a year through 2001.

Host Integration
While ORBs may be hot, the technology is not easy to use. In addition, ORB technology by itself doesn't buy the organization much unless all the pieces of an application are Corba-, Java-, or COM-enabled, which is rarely the case. "The problem is that you almost always have to go back to the data-center and host applications," says Richard Buckle, VP of Insession Inc., an ORB middleware vendor that specializes in host connectivity. The stuff in the data center probably isn't object-oriented, but ORBs require an object interface "so you're stuck trying to mix oil and water," says Buckle.

UMB Bank N.A. wrestled with this problem. UMB had new, object-based applications trying to work with legacy applications. "We had multiple types of middleware for use in E-commerce and home-banking applications. All the middleware was trying to access host data, but each front-end application was slightly different," says Bob Browne, senior VP of IS at UMB.

"Rather than wait for the day when the whole world will be Corba- or Java-compliant, I'm a realist," says Browne. "It took 30 years to build all this legacy stuff. It will be a long time before it's gone." UMB used Insession to create a reusable, shared-object middleware architecture that lets any new application connect to the bank's host systems through a single set of published interfaces. For any Web or home-banking application that needs host data or services, UMB's developers simply write to the Insession interface.

Most organizations, even those targeting the Web as their preferred development platform, are neither ready nor able to completely commit to object development. Instead, they need some sort of higher-level middleware that makes the connections between the Web and other platforms but shields them from working directly with Corba, JavaBeans, and COM objects. This is where Web application servers come in.

For example, Reliance Group, a $3 billion property and casualty insurance company in New York, is focusing all new development on the Web. The company initially did its Web development in C++, CGI, and Java scripts, coding each back-end connection by hand without the benefit of middleware. This worked for its first application, a simple Web-based company phone directory. However, middleware will be critical going forward to speed development work and standardize access methods, says Fred Kauber, the company's director of Internet and E-commerce solutions.

Reliance evaluated Corba and Java in its lab, but both technologies required a big investment in skills and architectural planning--one the company wasn't prepared to make, Kauber says.

Instead, Reliance adopted Bluestone Software Inc.'s Sapphire Web development environment. Reliance will take advantage of the middleware capabilities built into Sapphire, which includes Corba as its middleware architecture.