ects. Like any other application of technology to a problem, companies justify the expense of such a project claiming they will recoup their
costs over time.
The key to a successful middleware implementation is keeping these costs down. How do you do that? That's the $64 million question these days. Because there are no shrink-wrapped middleware solutions and because middleware covers a broad range of technologies, there's no simple answer. However, following some general guidelines should help you complete a middleware project successfully.
Changing Times
Middleware should do several things. First, it provides a way to get data from one place (say, a mainframe-based database) to another (say, a PC-based office application). Second, it should mask the differences between OSes, platforms, and network protocols. Third, it should conceal the complexity of the network transport process from the applications developer.
That's the theory. However, when undertaking a middleware project, what companies face is a slew of acronyms in a rapidly changing market. Adding to the problem is a lack of standa
rds. Perhaps even more troubling, you'll find very few skilled programmers with breadth and depth of knowledge about the variety of tools and technologies.
Large companies often employ dozens of applications, a handful of desktop platforms and OSes, and numerous database systems (many customer-written), running on a range of hosts. The idea that a simple piece of software can somehow tie all these disparate systems together (at the application layer, no less) is obviously absurd.
Middleware Goals
First, it's good to set some realistic goals before undertaking a middleware implementation. Understand at once: Middleware is an evolving technology.
We have moved beyond the original client/server notion of one client forever wedded to the same server. It used to be a one-to-one implementation--getting data from a DB2 database application running on an IBM mainframe into Excel spreadsheet cells on a user's Windows PC, for example. Today, as we move toward a more distributed c
omputing environment, it's more likely that a client will need to connect to multiple servers and hosts.
At the same time, there's a more mixed client environment. In the recent past, it was common for all nodes on a network to be identical (e.g., PCs all running DOS). Today, you are likely to find several platforms, including Macs, PowerPCs, PCs, and RISC-based workstations. Even if you have only a single hardware platform, you may be dealing with two or three OSes (e.g., DOS, Windows 3.x, and Windows 95 on PCs).
Multitier Middleware
Second, the business applications at the heart of a middleware project are becoming more complicated. In the past, companies might have been content with access to data--period. Today, access is a given, a starting point. Companies want decision-support systems and advanced data-mining capabilities that squeeze more useful information out of the mountains of data residing on their hosts and servers.
Because of these changes, there has been
a major
paradigm shift
in the way we use middleware. In the single-client-to-single-server days, you might use remote procedure calls (RPCs) from the client to the server. That portion of the middleware responsible for handling the transaction would reside on the client and the server. Such a system is called a two-tier middleware implementation.
Today, however, it is more common to see three- or even four-tier middleware implementations where intermediate servers also run part of a middleware program's code (see the figure
"Tiering Up the Corporation"
). The move to a multitier architecture addresses two important issues facing middleware implementers today: complexity and scalability.
In the past, you may have used a single middleware technology, RPCs, for example. Today, it is likely you will need multiple modes of operation within a single architecture. This adds complexity to the design of a middleware system.
For example, consider a trans
action where a customer makes a withdrawal at a bank's branch office. The withdrawal might involve a SQL query against a customer's balance. Middleware may have to interpret the syntactical differences between the SQL queries on the front-end and back-end systems.
Next, you need to make the actual withdrawal and must update the customer's account balance. You might do this using RPCs and a transaction monitor, which are well suited for such transactions.
Then, you might want to replicate the transaction to databases that are not on-line transaction processing (OLTP)--say, your decision-support system--which might not be available at the moment. To make the guaranteed modification would require a method such as that afforded by message-oriented middleware (MOM).
Skinny Clients
A third consideration pertains to the client hardware. One philosophy on performing all these application functions is to load the client up with the various stub programs required. However, industr
y sentiment is inclining more toward a thin-client approach to middleware--the client has the minimum amount of code possible, and the intermediate servers handle many of the tasks.
The thin-client approach is gaining favor because it centralizes the complexity of a middleware application to a few servers that an IS staff can easily access. Additionally, the thin-client approach is better suited to large-scale deployment of middleware applications. Consider an application that changes frequently--an order-entry system for a company with seasonal merchandise or a tax-preparation system, for example.
With fat-client implementations, the client does most of the processing. Typically, a client will send a request for data using such common techniques as a SQL query or an Open Database Connectivity (ODBC) driver. The server returns the data requested, and the client does something clever with the data.
On the surface, this approach makes sense. Typically, you have clients with much processing
power. Also, you have many users, perhaps hundreds of them, querying a single server. It makes sense not to burden the server with any additional tasks beyond data manipulation and processing SQL requests.
Still, there's a problem with such an approach to client applications design when the number of users grows. If you design most of the business logic into the front-end application that runs on the client, you will need to change the software on every client whenever there's a change in the business application (e.g., when the new season's products roll out or when they pass new tax laws). Software changes may even require souping up the client hardware with more memory or hard drive space. Updating every client is time-consuming, and the time required to perform this task grows as the number of clients grows--especially when you're dealing with geographically dispersed and mobile clients.
One way around this issue is to split the program logic between the client and an intermediate server (a
la the three-tier architecture) so that the part of the application that changes resides on the server. In that way, changes are easier to manage.
Servers Beef Up
Our fourth point relates to the server side of the equation. A thin-client approach means the intermediate servers in a multitier middleware implementation must do more. Moving tasks to centralized servers has several advantages.
For one thing, you can give your users access to higher-powered functions than they would ever have using a two-tier system. For example, a sales manager might need to find out who the top five buyers are for the last quarter. A common way to accomplish this task is to have the PC send a query to the customer database requesting a list of the buyers' names and the amount each one spent in each quarter. After receiving this information, the client must calculate the total sales for the year and sort the data to come up with the top five spenders.
However, if your end users are running o
lder PCs, they may not have the processing power or memory to carry out such a task. This is a simple example, but many applications require more data manipulation than a desktop--any desktop--can handle. For instance, you might need to join two large tables from different databases--a Microsoft SQL Server table on Windows NT and an Oracle database table on a Unix server, for example--to get at the information needed for a decision.
With a three-tier approach, you could design the system so that an intermediate server handles much of the heavy lifting. Such an approach has some practical business implications. You can make changes to an application quickly because it resides on only a single server and not on every client in the organization. Furthermore, you do not have to make changes on the system running the database (i.e., you do not need to rewrite custom applications running on mainframes).
Off-loading tasks from clients can also improve system performance by lightening the load on the ne
twork. You can, for example, reduce the number of times that large database files must pass over the network for processing by a client. Instead, you can pass these files to an intermediate server that processes the data and passes only the results to a client. That lets you optimize a network's design so that large files pass only between servers and hosts. So, you can, for instance, design the network so the servers link over a high-speed backbone and clients remain on a lower-speed network, such as a 4-Mbps Token Ring or 10Base-T Ethernet LAN.
That said, you can probably still imagine a scenario where you would want a fat client--say, when you have hundreds of users hitting a single server with some compute-intensive decision-support query. Then you might want fat clients that logged in, cached data, and left the back end alone as much as possible for the rest of the day.
Mapping Success
The fifth point hinges on planning. With any middleware implementation, there are severa
l logical steps to undertake (see
"Six Steps to Middleware Success"
), including such things as settling on a middleware technology and developing a pilot project.
Who should be in the planning process? Almost everybody. The approach that seems to work best when evaluating middleware is to form a team that includes the applications developers who will be using the middleware, the networking folks who must provide the infrastructure the applications will ride on, and, of course, the end users of the applications developed using middleware.
The final consideration? Cash, of course. Even with good planning, implementing middleware requires a substantial commitment of money. Because there are so many variations when it comes to implementing a middleware solution, getting firm cost numbers that would apply to every situation is difficult.
Ford, one of the major automobile makers, estimates that implementing a middleware project costs between $150,000 and $200,000 per app
lication. Of that amount, only 20 percent is for the actual product. The other 80 percent is for the labor of the developers.
Adding to the cost of implementing middleware is the cost of training. You'll find few workers with breadth and depth of knowledge across all middleware technologies to carry out a middleware implementation on their own.
Once a project finishes, you'll have to budget money for staffers to administer the middleware. Administering a middleware application is not trivial, yet most companies have no idea how much to budget when they are developing their implementation plans.
"When most users look at middleware, they typically underestimate the wherewithal it takes to effectively manage a middleware application," says John G. Senor III, vice president of the EDA Division of Information Builders. "There's no free lunch. Middleware requires a degree of administration like any other system software." Senor says a good rule of thumb is that it takes the same number of peopl
e to administer middleware as it does to administer a database.
The best advice? Set realistic goals for a middleware project. Remember that middleware still doesn't handle everything. Even the most elegant solutions cannot deal with every client platform, OS, application, and flavor of back-end system and applications. At least now you have one less reason to cringe when you scan your to-do list.
WHERE TO FIND
IBM
Armonk, NY
Phone: (800) 426-3333 or (914) 765-1900
Internet:
http://www.ibm.com
Middle(ware) Management
