OpenLink WhitePaper for Java

Contents

The Internet Revolution and Java - An Introduction
The Java Language Environment
Java Database Connectivity Standard
JDBC compared to ODBC
The OpenLink Multi-Tier ODBC Architecture
The OpenLink Architecture for JDBC™
Product Goals

Performance
Cross-platform Support
Ease of Use and Management
Consistency
Logical Security

Technical Guide to OpenLink Drivers for JDBC™

The mechanics of a JDBC session
JDBC URL Explained
Hostname, Port.
OpenLink URL Connection Attributes
DSN, Host, SVT, Database, ServerOptions, Options, FBS, UID, PWD, ReadOnly.
JDBC Connection URL Examples
Configuring  JDBC Connection Attributes
Environments with an ODBC Driver Manager, UNIX, VMS, or OS/2 server environments
OpenLink Data Source (DSN Attribute) Configuration Examples
JDBC Connection URL Translation Explained
Scenario 1, Scenario 2, Scenario 3.
OpenLink Agent for JDBC™ CommandLine Options
Database Engines Supported
Client Operating Systems Supported
Server Operating Systems Supported
Java™ to C - The Bridge

Figures

Figure 1 - ODBC Handle Architecture
Figure 2 - JDBC Object Architecture
Figure 3 - Differences between JDBC and ODBC
Figure 4 - SingleTier Architecture to Two Databases on Two Servers
Figure 5 - MultiTier ODBC Architecture to two datasources on two servers
Figure 6 - Embedded Server Implementation for JDBC
Figure 7 - Separated-Server Implementation for JDBC
Figure 8 - Multi-Server Implementation for JDBC
Figure 9 - Multi-Server Hybrid ODBC/JDBC Implementation suitable for Intranet
Figure 10 - Data Source Configuration File Section-Keys and JDBC Connection URL Attribute Correlation

Conventions

There are certain typographical conventions used within this document.

The Internet Revolution and Java - An Introduction

The meteoric rise of the Internet to the global community it is today has totally eclipsed that of any other technology in the history of computing. Things change so quickly in the world of the Internet that it is now referred to in corporate circles in the same time-frame as that of the canine lifespan. The Internet is the arena where companies can spring up overnight and die just as quickly.

This unique environment of development has given birth to a unique programming language - Java. Java, a product of Sun Microsystems Inc., has been able to address many of the issues that have consistently plagued users and developers alike. Whether Java lives on, or becomes another victim of corporate hype and fickleness among users and developers, it has laid the groundwork for the future of programming language technologies. It has already proven a fundamental functional requirement for the future of computing - Platform Independence. We are now at the beginning of an era where executable code can and must no longer rely on operating system and platform specific functionality. An executable compiled on a workstation should run with equal functionality on a Windows 95 PC - with no changes to the code or compiled binary. Platform independence and connectivity are the new idols and corporate bodies will worship elsewhere at their peril. New programming languages will come and go, but in this new world of enterprise computing, the tenets that Java has introduced will live on for ever, and the world has just got that little bit smaller.

The Java Language Environment

Java originated as part of a research project to develop advanced software for a wide variety of networked devices and embedded systems. The goal was to develop a small, reliable, portable, distributed, real-time operating environment. When the project started, C++ was the language of choice. But over time the difficulties encountered with C++ grew to the point where the problems could best be addressed by creating an entirely new language environment. Design and architecture decisions drew from a variety of languages such as Eiffel, SmallTalk, Objective C, and Cedar/Mesa. The result is a language environment that has proven ideal for developing secure, distributed, network-based end-user applications in environments ranging from networked-embedded devices to the World-Wide Web and the desktop.

The Java Language Environment is comprised up of a number of dynamically linked 'packages' that can be downloaded and linked dynamically at runtime. These 'packages' contain the runtime classes that make up the Java programming interface. The interface to the native operating system from the Java Virtual Machine is contained within the port of the Java VM to that particular operating system.

Some of the commonly used Java packages are java.awt (Abstract Window Toolkit), java.net (Java Networking), java.io (Java Input/output classes) and java.util (Utility classes).

The Java programming interface itself is being developed further along the lines of API's (Application Programming Interfaces). Some of the APIs that have already been developed and are currently under development are the Media API, Enterprise API and Security API.

Java™ Database Connectivity Standard

The Java Database Connectivity Standard™ (JDBC)™ is part of the Java Enterprise API. JDBC is an SQL based database access interface. It provides Java Programmers with a uniform interface to a wide range of relational databases, and also provides a common base on which higher level tools and interfaces can be built.

The JDBC API defines classes to represent constructs such as database connections, SQL statements, result sets, and database metadata. JDBC allows a Java-powered program to issue SQL statements and process the results.

In conjunction with JDBC, JavaSoft is releasing an JDBC-ODBC bridge implementation that allows any of the dozens of available ODBC drivers to operate as JDBC drivers. The JDBC-ODBC bridge can run on the server rather than client side using a JDBC driver that translates to a DBMS-independent network protocol.

JDBC compared to ODBC

JDBC is the natural evolution of ODBC - ODBC has the same relationship to the 'C' language as JDBC has to Java in providing a standard api for access to data. ODBC, as a standard, is mature and proven, so it seemed sensible to design JDBC around some of the concepts of ODBC, but presenting the interface as a Java 'Package' with a number of embedded classes. The internal structure of the JDBC architecture relates very closely to the internal architecture of the ODBC standard:

Figure 1 - ODBC Handle Architecture

Figure 2 - JDBC Object Architecture

The other major architectural similarity that is common to both JDBC and ODBC, is the use of a 'driver manager' coupled with 'drivers'. With an ODBC driver manager you would use an ODBC driver, and with the JDBC driver manager you would use a JDBC driver. Sun Microsystems has developed a JDBC/ODBC bridge which allows an ODBC driver to be used in place of a JDBC driver.

Where as ODBC is based around a 'C' API, and defines a number of 'C' functions calls, JDBC defines a navigational API that is object based - as is Java. ODBC presents 'handles' to its internal data structures to ODBC-enabled applications. This allows applications to manipulate the ODBC data structures and use the ODBC function calls correctly. They also provide an easily understood method of accessing the conceptual ODBC objects that are available - Environment (HENV), Connection (HDBC) and Statement (HSTMT). To allocate a Connection handle (HDBC) you first must have successfully allocated a single Environment handle, and must pass this handle to the function responsible for allocating the HDBC. In the same way, you must successfully allocate a connection handle before allocating a statement handle. In reverse, when deallocating ODBC object handles, you must free (drop) all statement handles, before freeing the connection handles before freeing the environment handle.

The same concepts hold true for JDBC, except that instead of passing handles you pass the objects themselves. Java takes care of the object pointers.

Both JDBC and ODBC make use of a 'Driver Manager', but these driver managers are in no way similar - you cannot use and ODBC driver with a JDBC driver manager and vice versa. It should also be noted that the above diagrams imply a similarity between the 'HENV' of ODBC and the 'Driver Manager' of JDBC. Although the 'Driver Manager' in ODBC and 'Environment Handle - HENV' are normally seen as separate entities, they are in fact closely related. When an ODBC aware application allocates a HENV, this is signalling the ODBC driver manager to get ready for action.

ODBC and JDBC are both based on different language technologies, although they can be used to access the same datasources. They only way to use ODBC with Java is to use the JDBC-ODBC bridge which allows an ODBC driver to be used as a JDBC driver. There is no ODBC-JDBC bridge, nor is there ever likely to be.

¹ Unless the JDBC-ODBC Bridge is being used, in which case the Java application as a whole maintains the same platform dependency as the odbc driver being used.

² See Footnote 1, reading database dependency in for platform dependency.

³ 'Single Tier' drivers are dependent on the database vendors communications layer, whereas OpenLink 'Multiple Tier' drivers use a database independent communications layer.

Figure 3 - Differences between JDBC and ODBC

The OpenLink Multi-Tier ODBC Architecture

The OpenLink Multi-Tier Open Database Connectivity Architecture, extends the commonly understood concept of an ODBC driver. The more commonly understood definition of ODBC, relating to client/server datasources is in terms of an 'ODBC Driver'. This ODBC driver, more often than not will be 'datasource dependent' in that when you want access to an Ingres database for instance, you go out and buy an 'Ingres ODBC Driver'. The software that you have purchased for your client computer cannot be used for anything more than accessing a particular type of datasource, and, more often than not, a particular version of that datasource. You have also bought software that is dependent on the availability of a particular version of a particular communications layer, and that can be only used to access the aforementioned datasource.

This type of architecture is known as 'Single-Tier' architecture. It is defined as an architecture implementing a datasource dependent data communications protocol.

Figure 4 - SingleTier Architecture to Two Databases on Two Servers

The OpenLink Multi-Tier Open Database Connectivity Architecture implements generic software at the client side, a generic data communications layer, with all the datasource specific software residing on the server. This means that if you have bought the OpenLink Multi-Tier ODBC software, your client software can be used to access any datasource on any accessible server. You only need one client driver and access to a Winsock-compliant network. All server datasource configuration takes place in a single area of the server making for an easy, trouble-free installation and easily maintainable configuration for data access. License control is maintained at the server on a concurrent connections basis.

Figure 5 - MultiTier ODBC Architecture to two datasources on two servers.

Connection from the server side to the datasource is achieved by using a particular datasource 'Agent' and a 'Request Broker' to handle connections, security and licensing. The Database Agent is specific to the datasource, but the Request Broker will handle all agents that conform to the OpenLink Agent API (internal). Once the Request Broker has been satisfied that the connection request is valid, the Broker will spawn the Agent process and the agent will then communicate directly with the Client software.

OpenLink Architecture for JDBC™

The OpenLink driver for JDBC™ architecture is based on the Multi-Tier architecture as described earlier. Generic Java-based client JDBC driver software is provided for the web server site, which is downloaded when the Java applet or application is initialized. The web server also implements an OpenLink Request broker, and a generic Agent for JDBC. When a valid connection request for JDBC services is received at the Request Broker, the JDBC agent is spawned to handle direct connection between the Java client classes and the datasource. The JDBC agent connects to the datasource via another OpenLink Database Agent. This Database Agent can either be resident on the same machine as the web server/JDBC agent (Figure 6: Embedded server architecture), or on a completely different machine, providing a 3-tiered approach (Figure 7: Separated-Server architecture). Each machine that utilizes the services of an OpenLink Database Agent must have a Request broker to control the agents.

Figure 6 - Embedded Server JDBC Implementation

Figure 7 - Separated-Server JDBC implementation

The security constraints of the Java programming environment must be considered when implementing this architecture. A Java applet has a limitation in that it can only open a connection to the server that it was downloaded from. This constraint is not placed on Java applications. Thus, it is a requirement for the server to implement the JDBC agent. This cannot in any circumstances be placed on a different server. It is, however, possible to place the Database Agent on any accessible server, as the original web server becomes responsible for the security of the system as a whole. The JDBC agent then behaves as a datasource proxy.

Figure 8 - Multi-Server JDBC Implementation

The Multi-Server architecture, depicted in Figure 8, outlines an architecture where the embedded server (Fig. 6) and separated server (Fig. 7) implementations are combined into a system that allows the JDBC client software to access two different datasources, one being on the web server itself, and the other being on a completely different server.

Figure 9 - Multi-Server Hybrid ODBC/JDBC Implementation suitable for Intranet

Figure 9 depicts a Multi-Server Hybrid architecture, where both generic ODBC and JDBC clients are used to access a mixture of differing datasources within an intranet.

Product Goals

OpenLink Drivers for JDBC™ have been developed with the following goals in mind: Performance, Cross Platform Support, Ease of Use, Consistency, and Security.

Performance

OpenLink Software is able to distinguish itself from its competition in the JDBC arena due to the following :-

• Driver Class Sizes - these have been kept to an absolute minimum (approx. 45K).
• Optimized JDBC Data Protocol - leveraging our existing Logical Message Assembly concept as exemplified by our high performance ODBC Drivers, we have devised an optimized transport protocol specifically for an industry accepted Data Access standard with the view to delivering high-speed data throughput in a Java environment.

Cross-platform Support

The OpenLink Multi-Tier architecture of our Drivers for JDBC™ (based on our Database Independent Communications Layer), gives us total control over the supported server operating systems that host our Agent for JDBC™.

The following server operating systems will be supported in the beta and commercial releases :- Solaris, Windows NT, Linux, SCO UNIX, AIX, HP-UX, Digital UNIX, Generic UNIX 5.4, Open/VMS (VAX & AXP) other server operating systems will be supported on demand.

Ease of Use and Management

The Drivers for JDBC™ are packaged with a native installation program for the host operating systems within which the OpenLink client for JDBC™ and server components will operate.

In similar fashion to existing OpenLink Database Agents, our Agent for JDBC™ is controlled by the OpenLink Request Broker providing a centralized infrastructure management to all JDBC based Java applications.

Consistency

Retaining the core architecture of our industry acclaimed Database Connectivity Technology has been central to our  Driver for JDBC™ development efforts. The obvious benefits to existing OpenLink customers is the leverage of existing investments in product knowledge and training. If you have successfully installed and configured OpenLink Enterprise or WorkGroup Edition ODBC Drivers, you can easily apply that knowledge to the configuration of our Agent for JDBC™.

Logical Security

Java has numerous in-built security features but none of these totally protect systems from security holes introduced by Database Driven Applications, especially in combination with the Internet and Open Data Access standards. The OpenLink `Session Rules Book' brings logical as opposed to physical fire-walling to database driven Java and non-Java Internet applications using OpenLink's Database Connectivity products (for JDBC & ODBC).

Technical Guide to OpenLink for JDBC™

The mechanics of an OpenLink Session for JDBC™

• One or more JDBC compliant JAVA applications or applets are instantiated loading the JDBC Driver Manager classes in the process.
• The Driver Manager loads the appropriate JDBC Driver based on the URL presented by the relevant JDBC compliant application or applet.
• OpenLink driver for JDBC™ requests a JDBC Agent service via the OpenLink Request Broker, typically resident on a server machine.
• The OpenLink Request Broker in standard OpenLink fashion instantiates or reuses an OpenLink Agent for JDBC™, based on `Session Rules' depicted in the OpenLink `Session Rules' Book.
• The JDBC agent requests Database Agent services via the OpenLink Request Broker .
• An OpenLink Request Broker instantiates or reuses an OpenLink Database Agent and then binds it to the OpenLink Agent for JDBC™ that requested the service.
• The OpenLink Request Broker returns to quiescent mode, while the OpenLink Driver for JDBC™, Agent for JDBC™, and Database Agent(s) in unison provide an OpenLink Session for JDBC™.

JDBC URL Explained

The URL for the OpenLink Driver for JDBC™ has the following form:

jdbc:openlink://<hostname>[:<port>][/<attribute>=<value>]… 

Hostname

The hostname parameter of the URL indicates the ip address or hostname, of the machine that provides an OpenLink Agent for JDBC™ service.

Note: There is a limitation imposed by the Java security model that states that applets can not open a socket to any other machine besides the one from which the applet was downloaded. The consequences of this are that if the OpenLink drivers for JDBC™ are being used within an applet, then the only valid value for the 'hostname' parameter is that of the server hostname.

This restriction is not imposed on Java applications.

Port

For purposes of class size management and session initialization overhead reduction, the OpenLink Driver for JDBC™ client components require specific identification of the port number at which the OpenLink Request Broker is listening. The default TCP port for the OpenLink Request Broker is 5000.

The OpenLink 'Session Rules' Book provides for setting Request Broker port ranges via the PortLow and PortHigh section keys located in the '[Protocol TCP]' section of this file.

Warning: You should not assign identical section key-values to both section keys as the OpenLink Database Agents also make use of the port assignments within the ranges designated. The OpenLink Request Broker generally makes use of the lowest port number within the range.

Only the OpenLink Request Broker's port number needs to be specified in the OpenLink Driver for JDBC™ connection URL.

To determine the Request Broker port number:

• Log on to your server machine and then start the OpenLink Request Broker in debug mode.

• Depicted below is the screen output that you will see:

$ oplrqb -d
OpenLink Request Broker
Version 2.4B (Release 1.5) as of Wed Jul 24 1996.
Compiled for Linux 2.0.0 (i486-linux)
Copyright (C) OpenLink Software.
Registered to OpenLink Internal Use
This is a 5 concurrent users license
oplrqb: using rulebook /home/openlink/bin/oplrqb.ini
oplrqb: including rulebook jdbc_sv.book
oplrqb: including rulebook generic.book
oplrqb: bound UDP protocol to 127.0.0.1.60001
oplrqb: bound TCP protocol to 127.0.0.1.5000

The TCP port is 5000 -------^ 

OpenLink URL Connection Attributes

Each connection attribute takes the form of a keyword and a value. The keyword and value are separated by an 'equals' sign, and each pair is preceded by a 'forward-slash'.

i.e.

/DSN=opltest/UID=scott/PWD=tiger

In the configuration examples shown below, it will be noted that each connection attribute has an 'ini-file' equivalent. The equivalent is the keyword used when setting up a JDBC datasource on the server side.

DSN

DSN: DataSource Name. This attribute is an identifier associating an OpenLink Driver for JDBC™ with a source of data, typically resident within an Database Management System. It is safe (on the surface at least) to deal with these values as being identical to ODBC Driver Manager Administered Data Sources in operating environments where an ODBC Driver Manager exists.

Host

This attribute identifies the network alias or IP address of the server machine hosting the OpenLink Request Broker, OpenLink Agent for JDBC™, and OpenLink Database Agents.

SVT

SVT: Server Type. This attribute identifies the database type of the data source your OpenLink Driver for JDBC™ will be connecting to, popular examples being Oracle, Informix, Sybase, MS SQL Server etc.

Database

This attribute identifies the actual database name of a given database type (SVT attribute), typically accessible to JDBC application users via the logical datasource name (DSN attribute) of a JDBC connection URL.

ServerOptions

This attribute holds key database Session Initialization Parameters specific to the various database engines supported by OpenLink.

Options

This attribute holds database specific Connection Initialization Parameters (values are obtainable from the systems administrators guide of the relevant database used by your organization, OpenLink software provides acceptable defaults).

FBS

FBS: Fetch Buffer Size. This attribute enables the optimization of record retrieval between the JDBC agent and the database agent. Greatest benefit will be seen here when a variation on the Separated-Server architecture is used. The number of rows applied to this attribute indicate the number of records transported over the network in a single network hop. Rows are fetched to the JDBC client software individually.

UID

UID: User ID. This attribute identifies the user-name to be associated with a JDBC session.

PWD

This attribute identifies the password of the associated user-name for an OpenLink session for JDBC.

Note: visually masking out the values associated with this attribute is the responsibility of the Java Application programmer. The OpenLink 'Session Rules' Book can be used to manage passwords remotely in a secure file accessible to your systems administrator only.

ReadOnly

The accepted values are either Y or N depending on if you want a read-only session or not.

OpenLink Connection URL Examples for JDBC™:

The two examples below provide examples of  JDBC connection URLs to an Oracle Database Engine .

jdbc:openlink://localhost/DSN=dsn_oracle/UID=scott/PWD=tiger 

jdbc:openlink://test.openlinksw.com:5000/SVT=Oracle 7/DATABASE=ora7/UID=scott/PWD=tiger 

Note: The OpenLink Request Broker enables partial JDBC connection URL attributes based on its ability to centrally store and enforce these values enterprise wide. Please see OpenLink ODBC Driver documentation for working examples illuminating the sophisticated configuration and logical security control features of the OpenLink 'Session Rules' Book.

Configuring OpenLink Connection Attributes for JDBC™

Environments with an ODBC Driver Manager

In operating environments where Microsoft's ODBC Driver Managers exists, our Agents for JDBC™ leverage the Data Source Configuration elegance of the ODBC Administrator. As a result the OpenLink DSN attribute for JDBC™ obtains its values directly from the pool of ODBC data sources configured via the ODBC Driver manager. The manner in which this is done is identical in mechanics to that of an ODBC compliant application operating within the same environment.

UNIX, VMS, or OS/2 server environments

In operating environments where an ODBC Driver manager interface is unnatural or sporadically implemented e.g UNIX, VMS, and to a fair degree OS/2, we make use of a text based Data Source Configuration file (located by the environment setting 'UDBCINI') or a special section of the OpenLink 'Session Rules' Book appropriately named '[UDBCINI]' for creating and managing OpenLink Data Sources. OpenLink Data Sources are responsible for linking OpenLink Driver for JDBC™ with the appropriate source of Attribute values should they not form part of the OpenLink connection URL for JDBC™, or should they be required for security and management purposes to reside on the server.

OpenLink Data Source (DSN Attribute) Configuration Examples

The examples below illustrate OpenLink 'Session Rules' Book (oplrqb.ini) or  Agent for JDBC™ Rule Book (jdbc.book) settings required for exposing OpenLink Data Sources to JDBC applications and applets.

Example 1 - this example points the OpenLink  Agent for JDBC™ an OpenLink Data Source configuration file called 'udbc.ini' located in the current directory (usually /usr/openlink/bin) for OpenLink Connection URL for JDBC™ attribute mapping.

[java_client] 
Program = jdbc_sv 
CommandLine = +udbcini udbc.ini 

Example 2 - this example points the OpenLink Agent for JDBC™ to an '[Environment]' section named "[Environment JDBC]" located in host operating environment variable settings portion of the OpenLink 'Session Rules' Book, the section-key value of 'UDBCINI' instructs the OpenLink  Agent for JDBC™ to resolve the location of OpenLink Data Source Configuration file from the environment variable 'UDBCINI' (note: this variable must have been set within the user shell initializing the OpenLink Server components).

[Environment JDBC] 
UDBCINI = udbc.ini

[java_client] 
Program = jdbc_sv 
CommandLine = +secure
Environment = JDBC

OpenLink Connection URL for JDBC™ Translation Explained

Scenario 1

If the OpenLink Connection URL for JDBC™contains a '/DSN=Accounts' Attribute, indicating a data source called 'Accounts'. The OpenLink   Agent for JDBC™ during initialization looks for a section header called '[Accounts]' in the OpenLink Data Source Configuration file (located via the UDBCINI environment variable setting or configuration file section). Once located all other OpenLink connection URL attributes will be assigned values from section-key values situated within the section named '[Accounts]'.

Scenario 2

If no DSN attribute is present in the OpenLink connection URL for JDBC™, then the "[Default]" section header within the OpenLink Data Source Configuration file is located and used to locate section-key values ultimately assigned to OpenLink Connection URL for JDBC™ attribute values.

Scenario 3

You can place attributes in the OpenLink connection URL for JDBC™ which by default override the attributes in the OpenLink Data Source Configuration file, on the other hand you can override OpenLink connection URL for JDBC™ attributes originating from remote or local client machines by applying the option +secure as a startup parameter for the OpenLink Agent for JDBC™ via the OpenLink Agent Configuration section of the 'Session Rules' Book (see example above).

Note: The OpenLink Request Broker can overrule some or all of the OpenLink Connection URL for JDBC™ Attributes, depending on the rules you wish to enforce globally throughout your enterprise.

OpenLink Agent for JDBC™ CommandLine Options

• +inifile <filename> - Use 'filename' for UDBC configuration
• +secure - Ignore all connection attributes from the JDBC client connection URL except the data source name (DSN attributes vales). This setting can also be used to override all of the matching settings in the 'OpenLink Session Rules' Book when the relevant OpenLink Database Agent session is being instantiated.

Database Engines Supported

The following database engines are supported by our Drivers for JDBC™ :

• Oracle (6/7.x)
• Informix (5/6/7)
• Microsoft SQL Server (4/6.x)
• Sybase (4.2/10.x/11.x)
• CA-Ingres (6.4, 7 CA-OpenIngres)
• Progress (6.3.x/7.x)
• Unify 2000 (2.4/2.5/3.0)
• Postgres95
• DB2 (4th Quarter 1996)

Client Operating Systems Supported

Any operating environment with a working portation of the Java Virtual Machine (VM) or Java enabled Web Browser.

Server Operating Systems Supported

Support server operating systems include:

Windows NT, Solaris (2.x), Linux, HP-UX, AIX, Open/VMS (VAX & AXP), SCO UNIX, Unixware, Digital UNIX, IRIX, DG-UX, Dynix/PTX.

Java™ to C - The Bridge

In order to interface a platform and datasource independent client module to a platform and language dependent datasource, there must conceptually be a bridge, or a language mapping interface between the two technologies - the language of the client application, and the language of the datasource interface. The datasource API is, more often than not, presented as a set of 'C' function prototypes in a similar way to ODBC. For a totally platform and datasource independent JDBC architecture, the client must retain no platform or datasource dependent code. This means that the JDBC client must be written totally in Java, written to Java connectivity standards, and totally generic in its concept with regard to the underlying datasource.

The position of the language bridge must therefore be carefully determined according to the concepts of the more stringent technology. So in order to retain the platform independent concept of Java, this bridging cannot therefore take place on the client, as this would involve bringing platform dependent code into the client environment.

The Java development tools provided by Sun Microsystems Inc provide utilities and libraries for linking C code to Java, though bridging between C and Java in code, limits the platform scope to platforms that both a) have a valid port of the Java Virtual Machine and b) can compile and Execute 'C' Code. This is a somewhat limited range of platforms, as the Java Virtual Machine has not yet been ported to the extent of 'C'. This limitation too inhibits the implementation of the Java/C bridge on the Web Server.

The most logical and efficient place for the implementation of a Java/C Bridge in a Distributed Environment is the network itself. Both Java and C have standardized and common access to a networking environment, which permits easy implementation of networking applications between the two technologies. A network packet transmitted between C code and Java code will be handled natively by both technologies. Effectively the Network itself becomes the common link between both C and Java.

Therefore, the OpenLink  Agent for JDBC™ is a 'C' based utility that connects the OpenLink Multi-Tier architecture a Java-based JDBC client across a network. Implementing the language mapping across the network also removes the performance and 'overhead' issues that so often pervade software-based language mappings.

Acknowledgements

Douglas Kramer, "The Java Platform, a White paper". JavaSoft, May 1996.
All Trademarks and Tradenames herein are the property of their respective owners and are hereby acknowledged

Kingsley Idehen
September 1996