Mainframe-web middleware

By John McCormickSpecial to GCNFederal 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.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, check out the International Middleware Association's Web site, at .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 .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.CORBA and DCOM have essentially the same client-server architecture, and at a deeper level both use an interface definition language structure that separates the interface from the implementation. The IDL level is where differences begin to show up.CORBA includes error handling in the IDL and supports C++ exceptions. DCOM doesn't manage errors at the IDL level.CORBA allows multiple inheritance. With CORBA, objects have a single client interface or reference, which arguably makes it a simpler architecture than DCOM. DCOM doesn't support multiple inheritance and instead uses multiple interfaces to clients; the interfaces are managed through globally unique identifiers stored in a registry.Originally, DCOM was a Windows-only product, making it unsuitable for enterprise use, but eventually Microsoft ported it to SunSoft Solaris and IBM OS/390. It now also works with Linux, Compaq OpenVMS, IBM AIX and Hewlett-Packard HP-UX.CORBA still holds an edge in the number of platforms supported, but DCOM has an advantage when there are numerous Microsoft platforms involved.Where do Enterprise JavaBeans fit into all this? EJB is another distributed object system. CORBA's infrastructure supports EJB.With Sun's release of Java Development Kit Version 1.1, Java got its own ORB, called the Remote Method Invocation, which was not CORBA-compliant. But CORBA and Java work well together.For some applications, Java's RMI is a good fit, but for others, Java can work through CORBA. Because Java is a programming language and CORBA is an integration technology, CORBA can be the interface between Java Web objects and C++ data in databases or other applications. CORBA manages the complex cross-language problems transparently.If you believe the hype, the Extensible Markup Language is the answer to all such problems. But really it's just a way to specify data presented on Web pages.Like HTML, XML is derived from the much older Standard Generalized Markup Language. Although SGML can provide both data content tags and page formatting tags, it has a 500-plus-page-long specification and is essentially too complex for easy use.XML document type definition lets programmers specify text or integer data types. XML creates documents that are easy to read, but the data is not convenient for computers to manage. So although XML will be important as a way to display data to people, it isn't a substitute for middleware.Ultimately, when you sit down to plan a strategy for making your data easily accessible via browser'either for internal or external use'you must do a major systems and software inventory for your agency. Only then will you be able to fairly gauge your requirements against the potential costs and benefits.XXXSPLITXXX-