IT Architect

Planning your middleware strategy

Architecting the software that moves information around in your network

By Jason May

April  1998
[Next story]
[Table of Contents]
Sun's Site

So which architecture is better? Two-tier, three-tier, n-tier? This month's columnist, Jason May, calls this debate "ridiculous." According to him, architects should be thinking of greater things as they chart their middleware strategy for the 21st century.

Be sure to check out Jason's middleware taxonomy to get the big picture of what the various types of middleware -- from ftp to to DCE to object transaction monitors -- are really good for. (2,000 words)

Mail this
article to
a friend

Thanks to all of you who wrote in with comments on last month's column. There is obviously a great deal of interest in IT architecture out there, and it may take us a while to cover all the issues raised.

In last month's column, I mentioned the "band-aids" that are often deployed to glue together various application architectures within the enterprise. This month, Jason May expands on this idea, with an introduction to that oft-misunderstood technology known as middleware.

Different types of middleware can affect the design of an individual application, provide an infrastructure for groups of applications, or allow for enterprise integration between disparate technologies. All IT professionals work with applications and data, but architects are the ones who must make it all work together.

--Kara Kapczynski

Selecting the right middleware for your applications is a major decision for any enterprise. In fact, middleware is so important that people often mistakenly use it as a synonym for architecture.

Now, middleware is very important, but it isn't the same as architecture. I define middleware as follows:

Middleware is software that moves information from one place to another.

This definition covers a lot of ground. It includes message-oriented middleware (MOM), remote procedure calls (RPCs), transaction monitors, object request brokers (ORBs), replication technology, publish & subscribe, push technology, and all sorts of hybrid solutions.

Architecture, on the other hand, covers even more ground. Besides ensuring that your clients can talk to your servers, architecture encompasses many other issues, including data storage architecture, systems management architecture, fault tolerance architecture, security architecture and so forth. There's a lot more to the "A" word than defining your corporate MOM/RPC/DCE/CORBA/DCOM/whatever strategy.

A thorough discussion of all the available middleware options and when to use them would take up more space than is available for this column. But I have put together a few rules of thumb, based on my experience, that should help you decide which middleware options are most appropriate in a variety of situations. I call it my middleware taxonomy.

Tiered architectures
When client/server technology first started making inroads into corporate computing environments, your middleware architecture decisions pretty much ended once you had chosen between two-tier or three-tier middleware for your application.

This was a major decision because it was typically one of several firsts for the organization: first Unix server, first relational database, first graphical user interface, first line of code in a language other than Cobol. As we'll discuss later, this simplistic view of architecture no longer suffices in today's enterprise.

The majority of business applications today are implemented in either a two-tier or three-tier configuration, using a wide variety of software alternatives for the communications glue. A ridiculous debate has continued on and off for several years regarding the merits of two-tier "versus" three-tier, as if there was clearly a benefit to one over the other. Experienced architects realize that every middleware option has strengths and weaknesses and that neither one of these configurations is appropriate in every single situation.

Perhaps the most common client/server middleware architecture for business applications today is the two-tier architecture illustrated below.

The protocol stack shows a typical technology configuration for such an application. Note that this fairly simple example already employs technology components from at least four different vendors: Microsoft, Sybase, Sun Microsystems, and Oracle.

Two-tier architectures are great for a wide range of business applications. Most reporting applications are two-tier. Most transactional applications (e.g., reservations, customer service, order entry, inventory management) can be adequately implemented in this manner, provided they don't need to support more than a hundred or so concurrent users.

Another common configuration is a three-tier architecture.

The third tier adds more complexity, but in exchange you expect to reap benefits. The middleware component illustrated in this particular example, BEA's Tuxedo transaction monitor, provides database connection pooling (which reduces resource utilization on the database server), improved manageability of client connections, and the ability to place application logic elsewhere besides in the client or server.

For applications that have extensive or sophisticated internal functionality, or business logic that is not tied directly to the user interface, the three-tier option is usually preferred. For example, it would work well in a procurement system for a large aerospace firm, where there are numerous rules to be checked before a purchase requisition can be approved.

Often a two-tier application that works fine for a smaller firm won't scale up to handle more concurrent users and larger transactional loads. Three-tiered architectures typically suffer less from such scalability problems.


Spaghetti anyone?
For those organizations that are experienced at developing client/server applications, there is a dark side to the middleware selection process. Just as happened in the Bad Old Days of icky legacy mainframe Cobol code, many firms have found themselves in an environment where their strategic client/server applications are not integrated and don't share infrastructure.

Some large enterprises find themselves facing forests of applications developed using incompatible middleware software, much of which is gradually becoming obsolete. And as the need for increased communication between these applications evolves, additional back-end spaghetti is added making the whole mess even more confused, and causing support costs to go through the roof.

Question for the class: How many tiers does the following architecture have?

Five tiers? Seven? Let's say we add some front-end Java applets using CORBA connectivity directly to the application server. Or batch processes to draw off transaction history from the operational database server to a separate data warehouse environment, with custom and HTML clients accessing the warehouse environment through yet another n-tier protocol series.

When might you have something like this? Here's a possible scenario: Conglomerated Widgets (CW) has been in business for many years. Their widget manufacturing and inventory systems all run on the mainframe. Order entry has been developed in Oracle on Unix. It checks inventory at order time via the DB2 gateway. Now CW wants to allow their customers to place orders via the Web.

Presto! Middleware spaghetti.

While there might not be many applications that look like this today, this sort of configuration is perfectly reasonable for sophisticated business applications in today's complex technology environment. Development along these lines is underway within many large IT organizations.

The HTML front end can run with zero install on minimal end-user hardware, which means low maintenance costs on the desktop. You can provide sophisticated functionality through use of rich data types that can be supported by most browsers, and you can get satisfactory transaction throughput and latency if you design carefully and make the necessary investments in hardware and network infrastructure.

Note that two-tier and three-tier applications can nest comfortably within this larger middleware environment. A reporting application might run directly off the central database server. Customer service representatives might use a Windows GUI (graphical user interface) application that communicates via a transaction monitor to the same database. With careful design, all these applications should be able to share resources like databases, business logic, and security rules.

A sea change
Take a careful look. This type of middleware environment will be the norm for most large enterprises within five years. The sophistication of the corporate software portfolio -- including packaged enterprise applications such as SAP and PeopleSoft, custom business applications, data warehouses, internal and external Web services, and so forth -- will demand such a configuration.

Take another look. The technical skills required to design and administer this environment are different from those that most of us have on staff today. You can't just whip together something like this overnight; serious architectural planning and design is required.

It's not necessary to scrap your existing infrastructure and build a new architecture from scratch. Organic development from an existing base is a valid approach, but planning is critical.

But why would you build this sort of architecture? Well, it offers a host of benefits:

If you fail to think through your middleware environment from an enterprise standpoint, a dire future awaits you: IT budgets consumed by support costs for isolated applications linked by mazes of batch extracts and file transfers, risky dependence on the few individuals who actually know how the pieces hold together, and the inability to release new applications in a timely fashion because of the effort required to hook new systems into the existing environment.

Asking the right questions
We need to get past this "how many tiers" business, and focus developing a quality architecture for the business enterprise. The design process for a comprehensive middleware architecture should not be rushed. It requires input from all affected parties, and must be driven strongly from a clear business case.

Here are some questions to ask:

And most important of all:

When you have thorough, quantitative answers to these questions, business priorities become clear. Appropriate middleware configurations for individual application requirements should be driven by these business considerations. With this level of understanding, applications can be built to mesh with an overall enterprise design.

Middleware technology must be managed as a corporate IT asset, just like hardware, networks, and databases. Individual applications have a life cycle -- introduction, revision, maturity, obsolescence, and retirement -- but careful attention to enterprise architecture can allow applications to die quietly without leaving software litter throughout your systems.


About the author
[Jason May's photo] Jason May is a principal architect at Cambridge Technology Partners. Reach Jason at

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Sun's Site
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified:

SidebarBack to story

A brief middleware taxonomy

Middleware type Example Good for
Raw TCP/IP sockets Comes with operating system Custom performance-critical applications
HTTP Any Web browser or server Non-performance-critical apps that need to penetrate firewalls
Message-oriented middleware IBM MQseries Connectivity to mainframes
Publish & subscribe Tibco Rendezvous Streaming of data to large number of clients (e.g., stock quotes)
Remote procedure call DCE DCE is dead. Avoid.
Database connectivity APIs Oracle SQL*Net Simple database apps with limited numbers of users
Database gateways Sybase OmniConnect Applications that must cross vendor environments, esp. for mainframe connectivity
Distributed objects CORBA, DCOM Sophisticated distributed applications with complex data requirements
Transaction monitors Tuxedo High-volume transactional applications
Object transaction monitors (coming soon from several middleware vendors) Promises to combine the benefits of distributed objects and transaction monitors
File exchange ftp For scheduled exchange of large quantities of data
Replication Lotus Notes; RDBMS vendor; Praxis OmniReplicator An improvement over file exchange when data must be shared between many locations
Push technology Marimba Castanet For one-way replication of software and data to many client desktops

SidebarBack to story