History repeats itself in middleware debates

I had lunch with a client recently. After a pleasant conversation covering
everything from the weather (a permanent table discussion) to Clinton's troubles,
we got down to business -- a discussion of which middle-tier middleware would
be best for a specific three-tier showcase application his company wanted to
design. He wanted to use Java (though this was still under discussion) as a
language for server-side development, and was looking at browser and regular
client access to this middle tier. He reminded me that he is a strong believer
in applications that consist of objects and components.

On the plus side, his middleware did not have to support high transaction volume.
Most of his company's transactional activities, such as database updates, would
remain on the mainframe, where everything is simpler. Last but not least, he
wanted to build a real infrastructure along the lines of the application. Thus,
from a middleware perspective, many pieces could be reused for future applications.

However, his next statement gave me food for thought for weeks to come. I was
expecting to continue discussing subjects like whether Java is mature enough
as a server-side language and whether the project should use a commercial application
server, such as those from NetDynamics or Netscape, or a plain Java/Common Object
Request Broker (Corba) solution. Instead, he bent over the table and said, "There
will be no product decision at this time." He then listed a few reasons
for the decision: technology turmoil and overall confusion in the middleware
market, and some licensing issues resulting from a planned merger of his firm
and another company. For the next few months, he said, his firm would be focusing
on developing applications using less-glamorous but more pragmatic technologies
where a clear benefit to business could be easily quantified. For example, he
said, instead of trying to choose middleware for the middle tier, he was now
more interested in investing in technologies such as message brokers and workflow
engines.

While I was at first surprised by this turn of events, the subway ride back
to the office gave me ample opportunity to ponder his decision. I judged that
this client is not alone in his thinking. He and others like him are concluding
that "wait and see" is the best decision in I/S today. Fierce start-up,
merger and acquisition activity in the software industry fuels doubts about
which vendors will survive the long haul. Mergermania among large and small
corporations makes any serious technology decision very risky, if not impossible.
And the middleware arena is one of the most hotly contested software sectors
today. The selection of a middleware platform (yes, middleware is a platform)
is vital to a company, even more important than the choice of a middle-tier
OS.

Despite all this, some smart people recommend that I/S executives put a stake
in the middleware ground and move forward. In principle I agree with this strategy,
but I will also concede that history usually repeats itself and cannot be ignored.
It was much easier to make technology decisions in past years. Let's take a
look at the history of middleware debates for some guidance.

Apple pie, RPC and MOM

Just a few years ago, the middleware debate was framed around the very simple
question of Remote Procedure Call (RPC) vs. message-based products. Most middleware
products solved a couple of very basic problems, such as program-to-program
communication. And many middleware products furnished developers with higher
level APIs that completely alleviated the need for cumbersome network protocols
and APIs like TCP sockets or SNA LU 6.2.

RPCs, for example, allow functions to be called synchronously without regard
to whether these functions are local or remote. RPC-based middleware spares
developers the chore of writing custom program-to-program communication and
marshaling code. Both of these are generated from Interface Definition Language
(IDL) in the form of client and server stubs.

In turn, messaging-based products expand the otherwise synchronous and connection-oriented
style of program-to-program communication to different asynchronous approaches,
such as message queuing and publish/subscribe. In general, though, most messaging
products do not lift the burden of reconciling data representation between machine
types from the developer's shoulders. While messaging products can provide more
flexibility in the way application programs communicate with each other, this
middleware type cannot generate any communication code. On the contrary, programmers
have to write to messaging APIs provided by commercial messaging products to
enable program-to-program communication.

Looking back at the mix of products and firms that were part of that "great
debate," a couple of questions come to mind: a) How many of these products
and firms are still around, and b) How important is the RPC vs. messaging debate
today? The answer to the first question is simple -- not many such firms are
still around (substantial credit goes to the survivors). The answer to the second
question is more complex.

By now, we have already decided that a formidable middleware product should
be "best of breed." It should support synchronous, connection-based
communication promoted by RPC-based products as well as asynchronous, connectionless
communication supported by message-oriented middleware (MOM). In fact, there
are products sold today that incorporate these two distinct characteristics.
And more are on the way. The Object Management Group (OMG) is incorporating
capabilities found previously only in messaging products into its Corba 3 specifications.
In turn, capabilities found today in Microsoft's MTS, Component Object Model
(COM) and MSMQ technologies will be incorporated into Microsoft's COM+ specifications,
allowing any methods to be invoked synchronously or asynchronously without compromising
functionality. So the correct answer to the second question is that credible
middleware products must support capabilities previously available in either
RPC or messaging products.

The RPC vs. messaging debate ended with IBM's MQSeries MOM middleware declared
the winner and the Distributed Computing Environment (DCE) pronounced dead.
(IBM, equally committed to both technologies, could not win twice.) The debate
then moved on to object middleware, where Corba and a number of compliant products
clashed directly with Microsoft's COM.

Interestingly enough, the COM vs. Corba debate has overshadowed the continued
evolution of MOM in its own world. IBM's revenue from MQSeries continues to
grow aggressively. The Corba vs. COM debate has also had no affect on sales
of TP monitors. This reinforces the fact that when it comes to production applications,
stability, scalability and reliability are more important than any "religious
war," including COM vs. Corba and object vs. procedural middleware.

Nevertheless, giving developers the ability to define standard, high-level
interfaces to objects in a programming-language-independent fashion is very
appealing. Similarly, the concept of a standard infrastructure that spells out
how objects communicate is also appealing. These factors, combined with the
fact that many of us are in continuous pursuit of new challenges, gave stage
to the COM vs. Corba debate. While Corba and COM are different object models,
both pursue two important goals -- providing standard interfaces to define,
traverse and query object interfaces, and providing a solid infrastructure for
distributed objects.

The COM vs. Corba debate quickly became far more zealous and emotional than
the previous RPC vs. messaging contest. Because any large-scale application
requires I/S management to select a middleware technology, the stakes are always
high. And when one side is Microsoft, the stakes are even higher. Think about
it: I/S managers must not only decide whether object or more traditional middleware
will be used for a project, but also whether Corba or COM will be the backbone
of production applications. Often, this decision is made when an operating system
is selected. Since I don't know of many companies using Unix or Network Computers
(NCs) on the client side, the operating system battle generally takes place
in the middle tier, where NT and Unix usually clash.

In theory, middleware is indifferent to operating systems. One of the first
reasons middleware was created was to create a level playing field for application
developers where services (such as security, naming and transaction) and their
respective APIs are available on many operating systems. Even Microsoft's COM
is available on different Unix flavors and mainframe systems. In reality, COM,
Corba and operating system decisions are tightly coupled. Because Microsoft
believes that middleware functionality belongs to the operating system, it plans
to bundle them. As time passes by, we find more middleware integrated with Microsoft
operating systems.

Today, because of its scalability limitations, NT does not pose serious competition
to Unix for large-scale, mission-critical applications. Thus, Corba is the logical
middleware choice for proponents of object middleware. An NT decision makes
Corba harder to justify. The first problem is the additional cost. By bundling
COM, MTS and MSMQ with an OS, Microsoft redefined middleware pricing and total-cost-of-ownership
models. Corba requires additional license fees. Second, COM is part of, and
very well integrated with, popular development tools, including Visual Basic
and PowerBuilder. Choose Corba and additional development dollars will have
to be dedicated to solve the problem of accessing Corba objects from Visual
Basic clients.

Does this mean that if your middle-tier operating system is NT, COM is your
middleware of choice? Not quite yet. There are a number of reasons why Corba
should still be considered. These include avoiding operating system lock-in
and accommodating the existence of many Unix applications that must integrate
with newly developed NT applications. These reasons should be enough to justify
the additional cost of a Corba license. Remember, history repeats itself and
it appears that the COM vs. Corba debate is heading the way of the RPC vs. messaging
contest. It is inevitable that most large enterprises will end up with both
COM and Corba.

One-stop shopping?

No industry is more dynamic than information technology. There is never a dull
moment. In the best-case scenarios, the questions remain the same as the answers
change. In reality, both questions and answers constantly change. The arrival
of Java combined with the ambiguity of the Web produced a number of new, yet-to-be-answered
questions: Is Java the answer to all middleware decisions? and Is Java middleware?
No one can argue that the original existence of middleware was intimately linked
to the problem of portability. Further, Java's popularity combined with the
ambiguity of the Web fostered the new analyst term "Web-centric middleware."
Products like NetDynamics 4.0 (acquired by Sun), Netscape Application Server
(formerly Kiva), Tengah from WebLogic, and Oracle's just-announced Application
Server 4.0 are examples of Web-centric middleware.

Generally, these products provide some sort of one-stop shopping -- they offer
development, deployment and management environments. Although the marketing
efforts of these companies have so far focused on Web applications (HTML and
Java support for the client, and Java support for the server), there is no technical
reason why such products cannot participate in the battle for the middle tier
of non-Web applications. In fact, Microsoft has already positioned MTS as a
universal middleware technology capable of providing a home for middle-tier
components serving Web and non-Web applications.

As the sophistication of these products increases, so does the appetite of
the suppliers for "sphere of influence." To assume that the marketing
focus of these companies will be Web-only applications is simply naive. By the
same token, it would be wishful thinking to assume that well-established middleware
vendors, such as BEA Systems, would not attempt to extend the reach of middleware
products like Tuxedo and M3 to pure Java/Web applications.

The question is this: Can a single vendor's technology successfully convince
developers that its products cover all aspects of development, deployment and
management in applications spanning universal clients, servers and legacy access?
Look for the answers in a future column.