prises to deliver traditional and new corporate applications to end users, adios to mu
ch of the middleware we depend on.
Steering the Middle Course
How ironic that the very indispensability of middleware guarantees its demise as a niche technology. That's the paradox of middleware: The better a middleware solution gets, the more invisible it becomes and the easier to swap for another variation. For middleware to succeed as a niche technology, it must call attention to itself. Yet calling attention to itself erodes its ultimate value. How inconvenient for middleware marketers, who, after all, must play a variation of the theme: "Buy us; you'll never know we exist."
Also, because middleware is constantly in a
state of flux
, it's hard to judge just where an application stops and the middleware begins. Thus, developers and users alike tend to project their frustrations and disappointments onto middleware.
"Some developers think of middleware as an ex post facto solution to design problems," says Peter Burris, director of
Open Computing and Server Strategies at the Meta Group (Stamford, CT). "People actually believe they can relax systems or database design because middleware will clean up after the fact." Middleware won't mask bad design. Substandard applications design will just become worse with a layer of middleware.
The temptation is to chuck middleware--but it makes everyone's life so much easier. If only there were some legitimate alternative.
The Web's Middle Ground
Many see the World Wide Web as that alternative. As the Internet becomes the platform of choice for day-to-day electronic business, it is likely that the Web will quietly assume most of the services now identified as middleware.
Think about it. Middleware aspires--with varying levels of success--to openness (interoperating across heterogeneous domains), scalability (without loss of function or performance), and integrity (data security plus auditability). The Internet already offers these features, without the added m
anagement and development burden of traditional middleware solutions. Also, the Web has a far better claim of transparency to users than middleware has.
Companies are also discovering that the Web offers a workable platform to deliver strategic applications to end users--both known and unknown. Web-based applications enable widespread connections between externally accessible Web sites and internal systems.
When Federal Express connected its package-tracking system to a publicly accessible Web page, its proprietary internal application metamorphosed into a Web-based customer contact system. At the front end, at least, middleware is nowhere to be found as companies begin using the Web to deliver increasingly robust and secure applications to users' off-the-shelf browsers.
Dozens of vendors, from Apple to Sun Microsystems, are embedding Internet access in their OSes. By doing so, they are creating an environment where individual users can have applications with parts on their desktops, on n
etworks, and--soon--anywhere on the Internet.
An even larger opportunity than the Internet is the intranet--the use of the Internet within an enterprise. Such private networks, isolated from the public network, empower an organization's working groups with unprecedented flexibility. Because you can control and secure applications more readily than on the Internet, intranets are ideal delivery vehicles for new applications (see the sidebar
"Rejecting Middleware"
).
The Web will not eliminate all need for middleware. In fact, it may create the need for a new class of object-oriented middleware. But the technology will integrate tightly and hide itself from users increasingly hostile to proprietary limitations.
"Companies with multiple, disparate, and heterogeneous data sources resist proprietary solutions because proprietary middleware interfaces complicate data access and maintenance," says Shaku Atre, president of Atre Associates (Port Chester, NY). Economic pressures will likely
push middleware further down the information-pipeline chain until it falls off the back end, unnoticed and unmourned by most.
How the Web Does Middleware
Users want middleware to deliver seamless data access across multiple platforms. The Web offers just this type of far-reaching connectivity. As the industry, including Microsoft and IBM, standardizes on Sun's Java cross-platform programming language, users will begin to enjoy new Web applications without middleware anxiety. With these services, programmers can write an application to a common API without worrying about the platform, other tool sets, or back-end databases.
The glue that may bind this new class of Web applications is, ironically, a kind of middleware itself: the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) 2.0. This technology offers developers their best hope to bridge multiple languages and OSes on the Web. Designing Web applications on CORBA's communications protocol makes
dynamic applications possible. Contrast this with static Hypertext Markup Language (HTML) pages on the Web.
Robust object management is one key to success for these dynamic Web applications. Object request brokers (ORBs) are the messaging middleware by which objects in heterogeneous distributed environments make and receive requests and responses transparently. The OMG's Internet Interoperable ORB Protocol (IIOP) puts any required middleware where it belongs: out of sight and out of mind.
Another benefit of applets constructed under the IIOP paradigm is that applications would bypass the Common Gateway Interface (CGI) or HTTP used in most Web applications communications. This bypass is desirable because it would eliminate an entire software layer and its resulting performance overhead.
Instead, the applet would talk with the server by way of IIOP, a protocol more capable than CGI in many ways. For example, under IIOP, a program session can stay open between calls. CGI must open and close
a session with each call.
In addition, CGI limits the kinds of information that can pass on the network. For instance, CGI does not support direct transmission of floating-point data, according to Suresh Challa, vice president of business development at PostModern Computing Technologies. The CGI protocol requires converting floating-point numbers into strings before transmitting and converting back to floating-point numbers at the other end. IIOP eliminates this unnecessary conversion and gains a performance boost, too, he says.
Tools such as PostModern Computing's BlackWidow are integrating the domains of networked ORBs and Java-based Web applications. BlackWidow's development environment links Web applets made with Java and CORBA 2.0, joining two fast-growing technologies: objects and the Web.
Now, users can develop CORBA-compliant Web clients and servers simply by defining the functions each object will expose. BlackWidow then generates skeleton code for these objects--Java for client
objects and Java C++ for server objects. The developer fleshes out the skeleton code with application logic. As with other Java applications, the user would connect to a Web page with a Java-enabled browser to download a Java applet.
Middleware Terminator?
Middleware vendors predictably downplay the Internet as a middleware terminator, although all acknowledge the inevitable dominance of the Internet for mission-critical computing. These vendors hope for a few good years before the Internet emerges as a ubiquitous and seamless information-delivery environment. Middleware--like platforms, data types, and OSes--will then become irrelevant to most participants.
"The Internet is certainly going to be a powerful influence over the coming years," says Dr. Bill Highleyman, chair of NetWeave (Wilmington, DE), "but its use will concentrate on individual users and electronic commerce, not much for the mission-critical systems that companies depend on. These critical applications must ti
e together disparate, incompatible legacy and open systems, and that is the true role of middleware. This need will not go away. Look for middleware providers to be providing access into the enterprise systems from the Internet via CGI."
Web-Wise Middleware
Not surprisingly, vendors with Internet-savvy middleware are more sanguine about the Web subsuming their services. "We foresee the Web becoming the platform of choice to conduct day-to-day business, enabling all the mission-critical distributed applications to be developed," says Challa.
John G. Senor III, vice president of the EDA Division of Information Builders (New York, NY), is also confident that middleware has a durable place on the Web. "I see the Internet as a new application-partitioning paradigm, not a replacement for middleware," he says. "We will still need middleware to provide SQL translation services, SQL processing, RPC [remote procedure call] processing, and messaging." (EDA data-access software provides a
uniform, relational view of data whatever its organization.)
Senor prefers a model like Unix's X Window System-terminal mode: Applications sit on a server and all that happens on the desktop is presentation management. The Internet, in this view, is a new presentation model. When the user clicks on a home page, an applet activates on the back end. That applet talks to the other layers necessary to resolve user actions into a SQL request or other processing.
In this type of scenario, EDA middleware is still critical for data access. At the back end of an extremely thin client, after the request crosses the Internet, middleware must still receive the request and process it against the appropriate database. "There's simply no way around middleware," Senor claims.
Middleware on Demand
As long as companies must reconcile the Web-based new world with old-world legacy systems, the need for middleware will never completely vanish--it will just appear so. Middleware will download
on demand over the Internet, just as all the other just-in-time applications, systems software, and data that users may need. The middleware will perform as needed--to connect, say, to a legacy database--and then go away. In this scenario, the prospects for middleware persisting as an independent entity are not strong.
Efforts to embed middleware services in the Web infrastructure are already under way. The explosive growth of the Internet makes it increasingly viable that every constituency--employee, partner, customer, supplier--is always a member of the network. The Internet is integrating frontware and backware so rapidly that there may be little opportunity or need for middleware of the type we know today. The result--for the user, the enterprise, and the developer--will be a simpler environment with goodies on both ends--but no middle at all.
WHERE TO FIND
PostModern Computing Technologies, Inc.
Mountain View, CA
Phone: (415) 967-6169
Fax: (415) 967-6212
illustration_link (33 Kbytes)
TOP:
BEFORE MIDDLEWARE
, developers had to write code to access each back-end database/platform combination. Client systems had to be powerful (i.e., expensive) enough to handle front-end processing.
BOTTOM:
With
TODAY'S MIDDLEWARE
, developers write to standard APIs. Client systems, freed from heavy-duty proc
essing, can be more modest (and inexpensive).
illustration_link (19 Kbytes)
John Kador, a freelance writer in Geneva, Illinois, reports on the business value of information technology. You can reach him on-line at
71321.1645@compuserve.com
.
The Ultimate Middleware
