Mainframe-web middleware<@VM>These 14 middleware products support a variety of standard scripts<@VM>These 14 middleware products support a variety of standard scripts (cont)
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:
' Access to legacy data
' Around-the-clock reliability
' 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.
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.Bridging the gap
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. Only then will you be able to fairly gauge your requirements against the potential costs and benefits.John McCormick, a free-lance writer and computer consultant, has been working with computers since the early 1960s.
|Product||Platforms||Web server interface||DBMS support|
|CGI, ISAPI, GWAPI, NSAPI||DB2, Informix, LDAP, Sybase, Oracle, SQL Server, OLE DB, ODBC|
|Bluestone Software Inc.|
|Total-e-Business||Windows, Unix, Solaris, Linux||NSAPI, ISAPI, CGI, Servlet, JavaServer Page||Oracle, Sybase, SQL Server, Informix, DB2|
|Ingres II||Windows, Unix||CGI||SQL Server, Sybase, Informix, Oracle, DB2, IMS, VSAM, CA-Datacom, CA-IDMS|
|EDBC (Enterprise Database Connectivity)||Client: Windows; server: OS/390||CGI||DB2, IMS, CA-Datacom, CA-IDMS|
|Data Access Worldwide Miami|
|DynaBase||Windows, Mac OS |
|ISAPI, NSAPI, Java Servlets||ODBC|
Santa Barbara, Calif.
|WebBase||Windows||Has integrated Web server||ODBC|
|Inline Internet Systems Inc.|
|iHTML Merchant||Windows, Linux, HP-UX, Solaris||ISAPI, NSAPI||Sybase, Lotus Notes, Oracle,|
|Metagon Technologies LLC|
|DQbroker||Windows NT, Unix, AIX, DG/UX, HP-UX, Linux, Solaris||C, C++, Java, COM/ActiveX||DB2, Informix, Oracle, Progress, SQL Server, Sybase, ADABAS, CA-IDMS, DMS, DMSII, IMS-DL/I, =KEYEDIO, NEON, VSAM, Sequential, ODBC|
|Pervasive Software Inc.|
|Tango 2000||Windows, Linux, Solaris, Mac OS||CGI, NSAPI, ISAPI, Apache Plug-in |
|Oracle, P.SQL, ODBC|
|Apptrieve/Super Nova||Unix, NT||Java, COM||Complimentary through app server|
Standard scripting supported
Server/application load balancing
Distributed component technology support
Server-level and application-level
XML, CORBA, Enterprise JavaBeans, COM, DCOM
Bluestone Software Inc.
XML, CORBA, COM, COM +, DCOM, MTS, JavaBeans, Enterprise JavaBeans
Server-level and application-level
CORBA, COM, DCOM, COM+, Enterprise JavaBeans
|None||Yes||Server-level||Via ODBC: MTS, ActiveX, ADO, COM, DCOM||$995 up|
COM, COM+ , DCOM
$10,000 per server; free for client
Data Access Worldwide
Server-level and application-level
Santa Barbara, Calif.
Inline Internet Systems Inc.
Metagon Technologies LLC
$40,000 per server
Pervasive Software Inc.
XML, COM, DCOM, COM+,
$3,500 per CPU
Java, Visual Basic, C++
Through client architecture
ActiveX: A Microsoft
Corp. architecture that lets components interact in a networked environment, regardless of the language used to create them.
ADO: Microsoft Active
Application server middleware:'
Software that lets users
access legacy programs either locally or remotely via a browser.
CGI: Common gateway
COM: Component Object
COM+: An extension
to COM that makes it easier to use C++ and avoid the complexities of the
Interface Definition Language.
Common Object Request Broker Architecture.
Software used to integrate database contents across an enterprise.
Software that adds routines to make applications network-cognizant.
Distributed object middleware:
Software that makes apps
on one part of a system available everywhere on the network.
EJB: Enterprise JavaBeans.
ISAPI: Internet Server
Java: Sun Microsystems
Inc.'s universal platform language, which is replacing
C++ for many apps on the
written in Java.
scripting language derived from Java.
JSP: JavaServer Page.
JDBC: Java Database
J2EE: Sun's Java
2 platform, Enterprise Edition.
Load balancing: Distributing
work to avoid overloading a system.
Complex software that manages data moving between disparate elements.
MTS: Microsoft Transaction
that connects disparate computers, operating systems and protocols.
NSAPI: Netscape API.
ODBC: Open Database
OLE: Object Linking
ONC: Open network
ORB: Object Request
Perl: Practical Extraction
RPC: Remote procedure
SGML: Standard Generalized
TP monitor: Transaction
VBScript: An extension
of Visual Basic used to create scripts.
Software that can be used to publish data on the Web.
XML: Extensible Markup