Mainframe-web middleware

By John McCormick

Special to GCN

Federal agencies, under mandate from Congress and the Office of Management and Budget to reduce paperwork, need to collect information electronically and publish on the Web.

Officials took a step toward meeting the mandate during the last few years as they prepared systems for year 2000. The work they did on date code forced them to do away with many redundant systems and to move reams of data off of antiquated systems that seemed destined for disaster.

Despite these efforts, agencies still have vast amounts of data stowed on myriad mainframes and disparate network servers'and it is often inaccessible to users via the Internet or intranets.

The Web browser is today's interface of choice, and TCP/IP is by far the simplest, most widely accepted and least costly WAN protocol. The Internet or an intranet is the only practical way to provide wide access to the government's mountain of data.

Middleware, acting as a translator, integrator or converter'or all three simultaneously'is the glue that can connect legacy data or applications for use on the Web.

Just what is middleware? It's a broad category of software covering products ranging in cost from a few hundred dollars to a tens of thousands of dollars. Although the software can be complex, the concept is easy to understand.

Applications such as databases or spreadsheets are used by individuals to create, store and manage raw data. But people who need to see this data may be using different operating systems and applications. Middleware, in the form of relational database management systems, bridges this gap for users.

There are other kinds of middleware. The products that get the most attention are message-oriented middleware and software that lets users run apps remotely. MOM manages the exchange of data, and distributed object middleware manages the real-time execution of processes on remote systems.

Middleware products can also be divided into two meta classes, management and development. Broadly speaking, management middleware connects existing apps, and development middleware provides management tools and a development platform.

As is evident in the low prices of some relational database management software, merely publishing a single legacy data set on one system to the Web isn't very difficult.

The trouble starts when you need to connect that database to the variety of systems found in a typical enterprise, publish the data to the Web and build new applications.

Plus, most agencies do a lot more than just manage a single database; many need to integrate dozens of servers running a mix of database programs from Oracle and DB2 to Informix and Adabas.

Traditionally, middleware has been the software that connects clients and servers in an enterprise environment. Web middleware, meanwhile, connects data and apps on mainframes and local servers to the Internet. The creation of software that can make data available in a form accessible via a standard Web browser is a relatively recent development.

When trying to select the right middleware product for your organization, consider two approaches: tactical and strategic.

Publishing data to the Web from a single mainframe or network can be treated as a tactical situation. Just select the middleware that will bridge the different protocols most easily.

If you have bigger concerns than merely publishing a single set of data, choosing middleware is a strategic decision. Your program choice will affect every aspect of your network.

And though implementing any middleware across an enterprise is expensive, if you make a mistake, changing your middleware will be massively more expensive.

The software you choose must support not only what you are asking of it today but also what you will ask of it in five years. A manufacturer's promise that the features in a future release will solve your problems could prove worthless if that release never comes through.

Get just enough

On the flip side, because of the up-front investment and heavy management requirements, you must also be certain you aren't buying more middleware than you need.

There are 10 basic requirements you should rank when selecting middleware:
' Security

' Access to legacy data

' Around-the-clock reliability

' Scalability

' Fault tolerance

' Remote management

' Load balancing

' Protocol support

' Programming ease

' Standard scripting support.

You might think the requirements listed have more to do with business than government apps, but you would be wrong. Many agencies use advanced middleware and have the same requirements as any business. Allaire Corp.'s ColdFusion is an example of business middleware widely used in the government.

The IRS' Compliance Research Division uses ColdFusion to give 33 field offices access to a database of more than 2,000 reports. The Texas Public Safety Department uses the middleware to manage a criminal records database through a Web interface.

For more background information on middleware, take a look at the International Middleware Association's Web site, at www.moma-inc.org.

In the world of middleware, objects reign supreme. Put in the simplest terms, objects are program modules, and distributed object controls are the tools used to manage users' requests to run the modules on remote systems. They are essential components to providing remote access to services over high-speed networks.

There are a number of competing object architectures, the most prominent being the Distributed Component Object Model (DCOM) and the Common Object Request Broker Architecture (CORBA).

DCOM is an extension of Microsoft's Component Object Model for distributed architectures. It places requests on top of Distributed Computing Environment remote procedure calls.

COM is a binary level specification that allows components to be created in C++, Java, Visual Basic and other languages. COM began as Microsoft's Object Linking and Embedding technology, which integrates Windows desktop applications.

The Object Management Group developed CORBA. OMG, whose original members in 1989 included Data General Corp., Hewlett-Packard Co. and Sun Microsystems Inc., formed in part to compete against Microsoft in the development of standards. There are now more than 700 OMG members. For more information, visit www.omg.org.

Both CORBA and DCOM work at the top layer, managing client-server interactions and providing essentially the same services. There is debate about which is better, but it is important to note is that one is backed by Microsoft and the other by Sun. Most of the arguments are not based on absolute merits.

Microsoft creates and manages COM and DCOM, so there is only one basic, compatible implementation.

CORBA is a specification rather than a set of programs, so initially, different vendors' CORBA products had incompatibilities that prevented them from working with one other. But through OMG's efforts, most incompatibilities have been resolved.

Choosing and implementing an enterprise middleware strategy is probably the most complex task any systems department will ever face. Remote administration is vital for large installations. The middleware must support not only your data but also all your database management tools. Scripting control is vital. Focus more on what you plan to do in the future than what you do now.