Welcome!

Java IoT Authors: Liz McMillan, Craig Lowell, Carmen Gonzalez, Elizabeth White, Pat Romanski

Related Topics: Java IoT

Java IoT: Article

Understanding JCA

A Guide to J2EE Connector Architecture

For Java developers, Java Database Connectivity (JDBC) is the only standard interface to Database Management Systems (DBMSs). As JDBC has evolved, the number of ways to connect have increased. JDBC 2 added capabilities for compatibility with J2EE. JDBC 3 generalized the structure to support Enterprise Information Systems (EISs) other than DBMSs, including messaging services.

JDBC 3 introduced J2EE Connector Architecture (JCA). The initial release of JCA (1.0) standardized interfaces to DBMSs for Application Servers. With JCA, Application Servers can access a variety of DBMSs without DBMS-specific coding. JCA also provides local and distributed transaction control, generic deployment capabilities and access outside of DBMSs to general EISs.

Sun released the final spec on JCA 1.5 in Nov., '03. While adoption of 1.5 has been slow, it does round out JCA to a complete facility. JCA 1.5 introduces Inbound Communication for compatibility with messaging and similar services. It also adds capabilities for control of Resource Adapter lifecycle and thread usage by Application Servers and improves deployment structure.

This article gives an overview of the improvements to connection structures for JDBC. It finds common threads to tie the various capabilities together into an evolutionary path. It then concentrates on a deeper examination of the J2EE Connector Architecture (JCA).

Preliminaries

Basic Client Connections
Connecting to a DBMS through JDBC uses a standard pattern for Clients. The Client Application utilizes a Connection Factory and retrieves an active JDBC Connection from it. The client performs all database access through the connection and closes it when done.

Since different classes can perform as a JDBC Connection Factory, we will use the general term of Client Connection Factory reflecting its use by the client application. We will also call the resulting connection the Client Connection, though for database access it will always be a JDBC Connection (java.sql.Connection). These are the components utilized by the client. Figure 1 shows the basic structure for the client.

For JDBC 1, the following classes implement these components:

  Basic Standard Extension
Client Connection Factory java.sql.DriverManager javax.sql.DataSource
Client Connection java.sql.Connection java.sql.Connection

JDBC 2 Standard Extension extends DataSource with facilities for connection pooling and distributed transactions. These facilities work within Container Software, such as an Application Server.

Facilities for Application Servers
For connection pooling and distributed transactions in Application Servers, JDBC 2 introduced a second set of Connection Factory and Connection entities. The Application Server manages these entities rather than the Client Application. They are the Server Connection Factory and Server Connection. The portion of the Application Server that manages the Server Connection Factory and Server Connection is the Server Connection Manager. Figure 2 shows this structure for both the server and the client.

Unlike their client counterparts, Server Connection Factory and Server Connection interface directly with the Application Server. The server uses them to create and manage the underlying physical connection. The Server Connection Factory is a JavaBean that the Application Server configures with connection properties and retrieves the Server Connection. The resulting Server Connection object is an actual physical connection to the DBMS.

The Application Server uses the Server Connection object for storing in the connection pool and for managing distributed transactions. On client request, the Application Server retrieves a Client Connection from the Server Connection. This is a special connection object that is under control of the Application Server.

The server manages transactions for the Client Connection and the connection close. When the Client Application closes its connection, it does not actually close the physical connection. The Server Connection Manager for the server receives a notification from the Server Connection at close. It either returns the Server Connection to its pool of connections or physically closes the connection to the DBMS.

Connecting in an Application Server
The Client Application interacts with the Client Connection Factory to request a JDBC Connection with the getConnection() method. Instead of simply producing the Client Connection as before, the Client Connection factory interfaces with the Server Connection Manager, part of the Application Server. The Application Server retrieves the connection with the following steps:

  1. The Client Connection Factory calls the Server Connection Manager to retrieve a Client Connection.
  2. The Server Connection Manager looks in its pool for an associated Server Connection object.
  3. If the pool does not contain an appropriate Server Connection, the Server Connection Manager requests a new Server Connection from the associated Server Connection Factory.
  4. The Server Connection Manager uses the Server Connection to retrieve a Client Connection.
  5. The Server Connection Manager passes the Client Connection back to the Client Connection Factory which returns it to the Client Application.
Figure 3 shows these steps.

JDBC 2 Standard Extension includes two sets of Server Connection Factory and Server Connection components. One set for basic connection pooling and one for distributed transactions:

  Connection Pooling Distributed Transactions
Server Connection Factory javax.sql.ConnectionPoolDataSource javax.sql.XADataSource
Server Connection javax.sql.PooledConnection javax.sql.XAConnection

XADataSource and XAConnection extend their connection pooling counterparts.

The Server Connection Facility and Server Connection component are often part of the individual JDBC Driver which also includes the Client (JDBC) Connection. The Application Server supplies the Server Connection Manager and the Client Connection Factory. It creates and configures the Client Connection Factory using information from the Server Connection Factory.

JDBC 3 Extensions for Application Servers
JDBC 3 introduced the connector architecture as a replacement for the JDBC 2 DataSources. J2EE generalized it into the J2EE Connector Architecture (JCA). JCA removes the need for Application Server coding specific to each JDBC Driver by standardizing the components and interconnections. JCA also includes extended capabilities.

JCA uses the component structure from Figure 2. The Application Server supplies just the Server Connection Manager component. The JDBC driver, known as the Resource Adapter in JCA parlance, provides the rest -- the Server Connection Factory, Server Connection, Client Connection Factory, Client Connection components. The corresponding component to Server Connection Factory and Server Connection in JCA are:

  JCA
Server Connection Factory javax.resource.spi.ManagedConnectionFactory
Server Connection javax.resource.spi.ManagedConnection

JCA does not specify interfaces for Client Connection Factory and Client Connection, because the Resource Adapter need not encapsulate a JDBC Driver. The only requirement is the Client Connection Factory must be a JavaBean. When the Resource Adapter does encapsulate a JDBC Driver, the standard components are normally:

  JCA
Client Connection Factory javax.sql.DataSource
Client Connection java.sql.Connection

In JDBC 2, the Application Server used information from the Server Connection Factory to create a special Client Connection Factory for each JDBC Driver. JCA relieves the Application Server of this work by specifying methods in the Server Connection Factory for creation of Client Connection Factories. These are the createConnectionFactory() methods in ManagedConnectionFactory, which is the JCA version of the Server Connection Factory.

The Application Server retrieves the Client Connection Factory from createConnectionFactory() and makes it available to Client Applications through JNDI. Client Applications retrieve the Client Connection Factory with normal JNDI lookup. For JDBC access, the Client Connection Factory is a javax.sql.DataSource. The Client Application uses getConnection() method in DataSource to retrieve a JDBC connection.

Figure 3 shows the processing inside a Client Connection Factory in response to a getConnection(). The Client Connection Factory packages the connection properties and related information in a special connection request object and calls the Server Connection Manager to retrieve a new Client Connection. The Application server supplies the Server Connection Manager. For JCA, the Server Connection Manager must implement the javax.resource.spi.ConnectionManager interface.

The Client Connection Factory receives a reference to the javax.resource.spi.ConnectionManager instance when created via createConnectionFactory() in javax.resource.spi.ManagedConnectionFactory. Client Connection Factory uses that instance to call allocateConnection() in ConnectionManager. It passes the connection request object to allocateConnection() and receives a Client Connection. The connection request object is an instance of javax.resource.spi.ConnectionRequestInfo implemented by the Resource Adapter (JDBC Driver).

A Closer Look at JCA

This section will examine JCA 1.0, the initial release of the J2EE Connector Architecture. The subsequent version, JCA 1.5, though more complete, is not yet widely used. The next section will discuss the enhancements introduced by JCA 1.5

JCA 1.0 standardizes the components and their interconnections for both the Client Application and the Application Server (see Figure 2.) The scheme allows the Application Server to support connection pooling and distributed transactions. The Application Server only needs to supply the Server Connection Manager object. The Resource Adapter provides the remaining components.

For RDBMS interface, the Resource Adapter replaces (subsumes) the JDBC Driver. In JCA 1.0, Resource Adapter is a conceptual entity. JCA 1.5 defines Resource Adapter as a class implementing javax.resource.spi.ResourceAdapter. The JCA 1.5 Resource Adapter provides extended features.

JCA 1.0 is not limited to RDBMSs and JDBC Drivers. Other types of Enterprise Information Systems can use the JCA connection structure, allowing integration with Application Servers. Enterprise Information System (EIS) is the general term for any sub-system supplying information to Client Applications. Examples of non-JDBC EISs include:

  • Application Sub-systems, such as ERP, CRM
  • Report Servers
  • Administrative Interfaces, like for a database server.
The ManagedConnectionFactory in JCA is a JavaBean. The Container configures it with connection properties relating to the target EIS. ManagedConnectionFactory normally has hostname and port number properties, for instance. Properties for the actual user login, such as user name and password, are passed to the associated Client Connection Factory. JCA separates the connection properties so that the ManagedConnectionFactory can provide ManagedConnections for a variety of users and logins, all accessing the same EIS instance.

JCA provides basic password capabilities for connections plus extended authentication and authorization. JCA accepts JAAS (Java Authentication and Authorization Services) objects. The getManagedConnection() method in ManagedConnectionFactory receives an optional javax.security.auth.Subject object. A JAAS Subject represents an authentication entity, such as a person or device.

Client Application interface to a DBMS Resource Adapter running in an Application Server is identical to JDBC DataSources. The application uses a javax.sql.DataSource object as a Connection Factory to retrieve a JDBC Connection. It looks up the DataSource using JNDI and can configure it as a JavaBean. JCA 1.0 also supports direct client use of a Resource Adapter outside of an Application Server.

Client Application Interface
With JCA, client applications access a database connection in the same manner as JDBC 2 DataSources (javax.sql.DataSource). The DataSource is a JavaBean configured and deployed by the application server. The client application retrieves a deployed DataSource with JNDI. The DataSource serves as the connection factory for JDBC Connections.

JCA uses a DataSource as its Client Connection Factory. The getConnection() methods in javax.sql.DataSource return a JDBC Connection (java.sql.Connection). Internally, the Application Server often retrieves the JDBC Connection from a connection pool in response to a getConnection(). When the Client Application calls the close() method in java.sql.Connection, the JDBC Connection returns to the pool.

Following retrieval of the JDBC Connection and before closing the connection, the client application can perform JDBC operations, communicating with the database server. In JCA, the application server normally controls transactions, so the client application cannot issue commits or rollbacks.

Example application access to JDBC driver through JCA:


// Step 1: obtain the initial JNDI naming context

Context initctx = new InitialContext();


// Step 2: perform JNDI lookup to obtain connection factory (DataSource)

javax.sql.DataSource ds = (javax.sql.DataSource)
 initctx.lookup("java:com/env/eis/FirstSQL");


// Step 3: retrieve connection from connection factory with username, password

java.sql.Connection conn = ds.getConnection("tiger", "bright");

  ~

  ~ // access database server through JDBC without commits or rollbacks

  ~

conn.close(); // close connection

Transactions: Distributed and Local
JCA gives the Application Server capabilities to control transactions for Client Applications. The Application Server can start and commit/rollback transactions for a single Resource Adapter (JDBC Driver), or it can coordinate transactions between multiple Resource Adapters for a Client Application. The ManagedConnection interface provides methods for transaction control. When transactions are under Application Server control, the Resource Adapter must block commits and rollback issued by the Client Application.

When Client Applications are only accessing a single Resource Adapter, the Application Server can choose local transaction control. It uses the getLocalTransaction() method in the ManagedConnection interface to retrieve a Local Transaction object (javax.resource.spi.LocalTransaction). LocalTransaction contains methods to start and commit or rollback transactions for the associated physical connection. The Resource Adapter implements LocalTransaction.

When more than one Resource Adapter needs to participate in a single, global transaction, the Application Server uses distributed transaction control. The participants in a distributed transaction may be heterogeneous DBMSs and/or distinct instances of the same database server. Distributed transactions use the XA standard (see References).

XA is a language-neutral architecture for distributed transactions. A distributed transaction may encompass multiple data resources (such as, database servers). XA uses Two-phase Commit to coordinate transactions among data resources.

Java Transaction Architecture (JTA) is the Java specification for XA. JTA defines an Xid interface for identifying a distributed transaction and an XAResource interface for communicating with a data resource. XAResource contains methods for enlisting a resource session into a global transaction, for performing Two-phase Commit and for recovering global transactions after a server failure.

JCA supports JTA and XA by providing access to the XAResource object associated with a Resource Adapter connection. The ManagedConnection interface contains the getXAResource() method. The Resource Adapter implements ManagedConnection and XAResource.

Non-JDBC Connections
JCA generalizes the connection architecture to include access to other Enterprise Information Systems (EISs) besides JDBC connections to DBMSs. Support for non-JDBC EISs does not require any changes to JCA processing in the Application Server. The Application Server uses the same server components as Figure 2:

  JCA
Server Connection Manager javax.resource.spi.ConnectionManager
Server Connection Factory javax.resource.spi.ManagedConnectionFactory
Server Connection javax.resource.spi.ManagedConnection

The client components on the other hand do not have defined interfaces. The only requirement is that the Client Connection Factory is a JavaBean and provides a method for retrieving a Client Connection. Otherwise, the Client Connection Factory and Client Connection can take any form convenient to the EIS.

JCA does define a generic form for client components but does not require EISs to use it. This is the Common Client Interface (CCI). CCI defines specific interfaces for Client Components:

  JCA CCI
Client Connection Factory javax.resource.cci.ConnectionFactory
Client Connection javax.resource.cci.Connection

The CCI Connection Factory contains a getConnection() method for retrieving a CCI Connection. The CCI Connection provides a varied set of capabilities for communicating with an EIS. While capable, the CCI facilities are insufficient for complex interfaces like JDBC. CCI is also limited to Client/Server, request/response communications.

Using JCA outside of an Application Server
When an Application Server or Container utilizes a Resource Adapter, the adapter operates in a managed environment, controlled by the Container Software. In non-managed environments, Client Applications use JCA without an Application Server or Container. They directly access the Resource Adapter to retrieve Client Connections.

The Client Application retrieves a Client Connection by first creating a javax.resource.spi.ManagedConnectionFactory instance. The Resource Adapter includes a class that implements ManagedConnectionFactory. After instantiating that class, the Client Application configures it for the target EIS instance. Normally, the ManagedConnectionFactory will have setServerName() and setPortNumber() methods to set the EIS configuration.

The Client Application uses the createConnectionFactory() method in ManagedConnectionFactory to create a Client Connection Factory. For JDBC, the Client Connection Factory will be an instance of javax.sql.DataSource. The Client Application then retrieves the Client Connection (JDBC Connection) from the DataSource.

Example of Client Application retrieval of JDBC Connection directly through JCA:


// create ManagedConnectionFactory for specific Resource Adapter

ManagedConnectionFactory mcf = new EisManagedConnectionFactory();


// set configuration info

mcf.setServerName("mercury");

mcf.setPortNumber("8000");


// get DataSource (Client Connection Factory)

javax.sql.DataSource ds = (javax.sql.DataSource) mcf.createConnectionFactory();


// retrieve connection from connection factory with username, password

java.sql.Connection conn = ds.getConnection("tiger", "bright");

  ~

  ~ // access database server through JDBC

  ~

conn.close(); // close connection

The code snippet above uses the no-args form of ManagedConnectionFactory.createConnectionFactory(). With this form, the Resource Adapter supplies a default version of Server Connection Manager (javax.resource.spi.ConnectionManager) that it passes to the Client Connection Factory. When getConnection() in Client Connection Factory is called, it retrieves the Client Connection through the default Connection Manager (see Figure 3).

Client Applications can also provide their own implementation of javax.resource.spi.ConnectionManager. In this case, they call the form of ManagedConnectionFactory.createConnectionFactory() that receives a ConnectionManager instance.

Example of basic implementation of javax.resource.spi.ConnectionManager:


public class BasicConnectionManager implements ConnectionManager

{

  public Object allocateConnection(ManagedConnectionFactory mcf,
                   ConnectionRequestInfo info)

    throws ResourceException

  {

    ManagedConnection mc = mcf.createManagedConnection(null, info);

    mc.addConnectionEventListener(new ConnectionEventListener()

        { public void connectionClosed(ConnectionEvent e) { close(e); }

          public void connectionErrorOccurred(ConnectionEvent e) { close(e); }

          public void localTransactionStarted(ConnectionEvent e) { }

          public void localTransactionCommitted(ConnectionEvent e) { }

          public void localTransactionRolledback(ConnectionEvent e) { }

          protected synchronized void close(ConnectionEvent e)

          {

            if (e.getSource() instanceof ManagedConnection)

              try

              {

                ((ManagedConnection) e.getSource()).destroy();

              }

              catch (ResourceException ex) {}

          }

        }) ;

    return mc.getConnection(null, info) ;

  }

}

JCA 1.5 Improvements

JCA 1.5 introduces several enhancements to the original 1.0 release. The final spec on JCA 1.5 came out in November, 2003. JCA 1.5 defines a Resource Adapter object to give the Application Server more direct control. It also defines Inbound Communication for compatibility with messaging services and other similar services.

In JCA 1.0, the Resource Adapter is an abstract entity, not represented by any concrete class. JCA 1.5 defines an interface for the Resource Adapter, javax.resource.spi.ResourceAdapter. A JCA 1.5 Resource Adapter must include an implementation of this interface. The start() method initiates the Resource Adapter, and the stop() method terminates its processing. These methods give the Application Server control over the lifecycle of the Resource Adapter.

The start() method in javax.resource.spi.ResourceAdapter passes a javax.resource.spi.BootstrapContext instance. BootstrapContext supports Work Management by the Application Server. Work Management gives the Application Server control over any worker threads required by the Resource Adapter. This allows the Application Server to restrict thread use by the Client Application without inhibiting any Resource Adapter threads. The Resource Adapter uses Work Management to start any threads it may need.

javax.resource.spi.ResourceAdapter is a JavaBean that the Application Server sets with configuration information about the target EIS instance. When the Application Server creates a Server Connection Factory (javax.resource.spi.ManagedConnectionFactory instance), it attaches it to a started ResourceAdapter, using the setResourceAdapter() method in ManagedConnectionFactory. The ManagedConnectionFactory instance uses the configuration information from the ResourceAdapter as its defaults.

Inbound Communication
In JCA 1.0, connections are always initiated external to the Resource Adapter, either by the Application server or through direct use by the Client Application. This is known as Outbound Communication. JCA 1.5 adds Inbound Communication as a new facility. Control flows in the opposite direction with Inbound Communication. The Resource Adapter initiates the connection. JCA 1.5 Inbound Communications provides:

  • Message Inflow -- the Resource Adapter asynchronously delivers messages to message endpoints (message-driven beans) residing in the Application Server.
  • EJB Invocation -- the Resource Adapter calls session and entity beans residing in the Application Server.
  • Transaction Inflow -- the Resource Adapter imports an external transaction into the Application Server. The Resource Adapter can treat the Application Server as a Resource Manager participating in a distributed transaction initiated by the EIS.
An example of an EIS using Inbound Communication would be a messaging server. A more complete example would be administrative (non-JDBC) services for a database server. The database server would provide Outbound Communication for administrative control of the external server. It would use Inbound Communication for logging server status.

JCA Classes

JCA 1.0
javax.resource.spi.ConnectionManager (Server Connection Manager) A component that manages connection creation, close and pooling. Implemented in Container Software (Application Server).
javax.resource.spi.ManagedConnectionFactory (Server Connection Factory) A JavaBean used for creating a Managed Connection, configured with server connection properties (host, port, ...). Implemented in Resource Adapter.
javax.resource.spi.ManagedConnection (Server Connection) A JavaBean used to represent a physical connection to an EIS and used to retrieve a Client Connection and Local/Distributed Transactions. Implemented in Resource Adapter.
javax.resource.spi.LocalTransaction A component used to control local transactions (not distributed) for a Managed Connection. Implemented in Resource Adapter.
javax.resource.spi.ConnectionRequestInfo An object encapsulating connection properties, passed internally between various components (Managed Connection Factory, Managed Connection, Connection Manager, ...). Implemented in Resource Adapter.
javax.resource.spi.ConnectionEvent An event object for connection events produced by Managed Connection to Connection Event Listener registrants. Implemented in Resource Adapter.
javax.resource.spi.ConnectionEventListener A listener interface for Connection Events, registered with a Managed Connection. Implemented in Resource Adapter.
javax.resource.cci.ConnectionFactory (Client Connection Factory) A generic Connection Factory for non-JDBC access. Optionally implemented in Resource Adapter.
javax.resource.cci.Connection (Client Connection) A generic Connection for non-JDBC access. Optionally implemented in Resource Adapter.
JCA 1.5 Additions
javax.resource.spi.ResourceAdapter A JavaBean to provide lifecycle control and work management. Implemented in Resource Adapter.
javax.resource.spi.BootStrapContext A component supplying work management to Resource Adapter. Implemented in Container Software (Application Server).

Deployment

JCA provides a complete package for automatic deployment of a Resource Adapter into an Application Server. It defines the Resource Adapter Archive (RAR). The RAR contains everything needed to deploy the Resource Adapter. This includes JAR files with code for the Resource Adapter, deployment description XML, documentation and other required subsidiary files. JCA defines the following content for the RAR file:

Description File Name Required
Deployment descriptor ra.xml Yes
JAR files *.jar No
Documentation howto.html No
Auxiliary - image, locale, etc. files varied No
Platform-specific native libraries varied No

The ra.xml file contains configuration information for deploying the Resource Adapter:

  • General Information -- Resource Adapter name and version, EIS type, JCA version
  • Resource Adapter (1.5) -- name of Java class implementing javax.resource.spi.ResourceAdapter, list of configuration parameters
  • Managed Connection Factory -- name of Java class implementing javax.resource.spi.ManagedConnectionFactory, list of configuration parameters
  • Client Connection Factory -- name of Java interface and implementing class
  • Connection Factory -- name of Java interface and implementing class
  • Transaction Support -- none, local, distributed
  • Authentication Support -- basic password, JAAS
  • External Security Permissions -- list of required security permissions, e. g. tcp/ip sockets.
  • Inbound Communication (1.5) -- Message Inflow, EJB Invocation, Transaction Inflow
The RAR file enables automatic deployment of a Resource Adapter into an Application Server. The deployer performs the following steps:
  1. Deploy RAR into Application Server
  2. Configure Resource Adapter JavaBean (JCA 1.5)
  3. Configure Managed Connection Factory JavaBean

Summary

J2EE Connector Architecture (JCA) standardizes the interface between container software, such as Application Servers, and Enterprise Information Systems (EISs). An Application Server doesn't need custom code to support connectivity with a wide variety of EISs -- Database Servers, ERP Systems, Messaging Services. An EIS providing a standard Resource Adapter can plug into any container software supporting JCA.

Client Applications normally use EIS-specific interfaces. For database servers, this is JDBC. ERP systems on the other hand would provide proprietary interfaces for clients. The Connector Architecture also supports a standardized client with the Common Client Interface (CCI).

Like JDBC 2 DataSources, JCA supports connection pooling and distributed transactions (XA) for container software. It enhances this capability with:

  • Resource Adapter component, standardizing the interface between the container software (Application Server) and a full variety of EISs.
  • Managed environments under control of container software and non-managed environments under control of Client Applications.
  • Local transactions for efficient container control of transactions that are not distributed.
  • Authentication facilities, using JAAS.
  • Separation of server connection information from user connection information.
  • Standard packaging (RAR file) and deployment.

    JCA 1.5 adds:

  • Inbound Communication, connectivity to messaging servers.
  • Lifecycle and work management of Resource Adapter.

References

  • J2EE Connector Architecture (JCA) Specification, v 1.0: j2ee_connector-1.0-fr-spec.pdf
  • J2EE Connector Architecture (JCA) Specification, v 1.5: j2ee_connector-1.5-fr-spec.pdf
  • Java Transaction API (JTA) Specification. v 1.0.1: http://java.sun.com/products/jta/
  • X/Open CAE Specification -- Distributed Transaction Processing: The XA Specification: www.opengroup.org/public/pubs/catalog/c193.htm
  • JAAS Reference Guide for Java 2 SDK, Standard Edition, v 1.4: http://java.sun.com/j2se/1.4.1/docs/guide/security/jaas/
  • More Stories By Lee Fesperman

    Lee Fesperman is a software veteran who initially concentrated on Operating Systems and Programming Languages, implementing operating systems, compilers, interpreters and assemblers at IBM. In the mid 70s with the advent of Relational Technology, he began to move into the database arena. In the intervening years, he has implemented 3 complete RDBMSs, 2 with full SQL support. An important figure in relational database technology, he participated in the great "Null Debate" in the mid 90s and is a founder of the Database Debunkings site (http://www.dbdebunk.com), along with C. J. Date and Fabian Pascal. He authored a popular "SQL Tutorial" that is used by thousands of database developers worldwide and is a pioneer in ODBC drivers who participated in defining the ODBC 3.0 specification. He has developed JDBC Drivers for several leading database products and has built a number of database applications, working with many more leading database products

    Comments (3) View Comments

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


    Most Recent Comments
    Nancy 03/25/05 01:00:28 PM EST

    Very Clear description of JCA classes and the connection architecture. Thanks.

    Carlos Magno 09/13/04 08:08:05 PM EDT

    Very good, I like very much!
    Thank you

    Serguei Bakhteiarov 09/09/04 11:01:58 PM EDT

    JCA is a real thing. It is very useful and flexible. I appreciate the fact also, that it can be used outside EJB container. I am not sure EJB will be used (is used) as a technology for new projects, however some APIs out of App Servers (like JCA) are very solid and practical.

    @ThingsExpo Stories
    Extracting business value from Internet of Things (IoT) data doesn’t happen overnight. There are several requirements that must be satisfied, including IoT device enablement, data analysis, real-time detection of complex events and automated orchestration of actions. Unfortunately, too many companies fall short in achieving their business goals by implementing incomplete solutions or not focusing on tangible use cases. In his general session at @ThingsExpo, Dave McCarthy, Director of Products...
    Information technology is an industry that has always experienced change, and the dramatic change sweeping across the industry today could not be truthfully described as the first time we've seen such widespread change impacting customer investments. However, the rate of the change, and the potential outcomes from today's digital transformation has the distinct potential to separate the industry into two camps: Organizations that see the change coming, embrace it, and successful leverage it; and...
    Everyone knows that truly innovative companies learn as they go along, pushing boundaries in response to market changes and demands. What's more of a mystery is how to balance innovation on a fresh platform built from scratch with the legacy tech stack, product suite and customers that continue to serve as the business' foundation. In his General Session at 19th Cloud Expo, Michael Chambliss, Head of Engineering at ReadyTalk, discussed why and how ReadyTalk diverted from healthy revenue and mor...
    20th Cloud Expo, taking place June 6-8, 2017, at the Javits Center in New York City, NY, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy.
    You have great SaaS business app ideas. You want to turn your idea quickly into a functional and engaging proof of concept. You need to be able to modify it to meet customers' needs, and you need to deliver a complete and secure SaaS application. How could you achieve all the above and yet avoid unforeseen IT requirements that add unnecessary cost and complexity? You also want your app to be responsive in any device at any time. In his session at 19th Cloud Expo, Mark Allen, General Manager of...
    The 20th International Cloud Expo has announced that its Call for Papers is open. Cloud Expo, to be held June 6-8, 2017, at the Javits Center in New York City, brings together Cloud Computing, Big Data, Internet of Things, DevOps, Containers, Microservices and WebRTC to one location. With cloud computing driving a higher percentage of enterprise IT budgets every year, it becomes increasingly important to plant your flag in this fast-expanding business opportunity. Submit your speaking proposal ...
    DevOps is being widely accepted (if not fully adopted) as essential in enterprise IT. But as Enterprise DevOps gains maturity, expands scope, and increases velocity, the need for data-driven decisions across teams becomes more acute. DevOps teams in any modern business must wrangle the ‘digital exhaust’ from the delivery toolchain, "pervasive" and "cognitive" computing, APIs and services, mobile devices and applications, the Internet of Things, and now even blockchain. In this power panel at @...
    Major trends and emerging technologies – from virtual reality and IoT, to Big Data and algorithms – are helping organizations innovate in the digital era. However, to create real business value, IT must think beyond the ‘what’ of digital transformation to the ‘how’ to harness emerging trends, innovation and disruption. Architecture is the key that underpins and ties all these efforts together. In the digital age, it’s important to invest in architecture, extend the enterprise footprint to the cl...
    Bert Loomis was a visionary. This general session will highlight how Bert Loomis and people like him inspire us to build great things with small inventions. In their general session at 19th Cloud Expo, Harold Hannon, Architect at IBM Bluemix, and Michael O'Neill, Strategic Business Development at Nvidia, discussed the accelerating pace of AI development and how IBM Cloud and NVIDIA are partnering to bring AI capabilities to "every day," on-demand. They also reviewed two "free infrastructure" pr...
    Whether your IoT service is connecting cars, homes, appliances, wearable, cameras or other devices, one question hangs in the balance – how do you actually make money from this service? The ability to turn your IoT service into profit requires the ability to create a monetization strategy that is flexible, scalable and working for you in real-time. It must be a transparent, smoothly implemented strategy that all stakeholders – from customers to the board – will be able to understand and comprehe...
    Businesses and business units of all sizes can benefit from cloud computing, but many don't want the cost, performance and security concerns of public cloud nor the complexity of building their own private clouds. Today, some cloud vendors are using artificial intelligence (AI) to simplify cloud deployment and management. In his session at 20th Cloud Expo, Ajay Gulati, Co-founder and CEO of ZeroStack, will discuss how AI can simplify cloud operations. He will cover the following topics: why clou...
    "Dice has been around for the last 20 years. We have been helping tech professionals find new jobs and career opportunities," explained Manish Dixit, VP of Product and Engineering at Dice, in this SYS-CON.tv interview at 19th Cloud Expo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA.
    More and more brands have jumped on the IoT bandwagon. We have an excess of wearables – activity trackers, smartwatches, smart glasses and sneakers, and more that track seemingly endless datapoints. However, most consumers have no idea what “IoT” means. Creating more wearables that track data shouldn't be the aim of brands; delivering meaningful, tangible relevance to their users should be. We're in a period in which the IoT pendulum is still swinging. Initially, it swung toward "smart for smar...
    The Internet of Things will challenge the status quo of how IT and development organizations operate. Or will it? Certainly the fog layer of IoT requires special insights about data ontology, security and transactional integrity. But the developmental challenges are the same: People, Process and Platform and how we integrate our thinking to solve complicated problems. In his session at 19th Cloud Expo, Craig Sproule, CEO of Metavine, demonstrated how to move beyond today's coding paradigm and sh...
    In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life sett...
    We are always online. We access our data, our finances, work, and various services on the Internet. But we live in a congested world of information in which the roads were built two decades ago. The quest for better, faster Internet routing has been around for a decade, but nobody solved this problem. We’ve seen band-aid approaches like CDNs that attack a niche's slice of static content part of the Internet, but that’s it. It does not address the dynamic services-based Internet of today. It does...
    The WebRTC Summit New York, to be held June 6-8, 2017, at the Javits Center in New York City, NY, announces that its Call for Papers is now open. Topics include all aspects of improving IT delivery by eliminating waste through automated business models leveraging cloud technologies. WebRTC Summit is co-located with 20th International Cloud Expo and @ThingsExpo. WebRTC is the future of browser-to-browser communications, and continues to make inroads into the traditional, difficult, plug-in web ...
    20th Cloud Expo, taking place June 6-8, 2017, at the Javits Center in New York City, NY, will feature technical sessions from a rock star conference faculty and the leading industry players in the world. Cloud computing is now being embraced by a majority of enterprises of all sizes. Yesterday's debate about public vs. private has transformed into the reality of hybrid cloud: a recent survey shows that 74% of enterprises have a hybrid cloud strategy.
    WebRTC is the future of browser-to-browser communications, and continues to make inroads into the traditional, difficult, plug-in web communications world. The 6th WebRTC Summit continues our tradition of delivering the latest and greatest presentations within the world of WebRTC. Topics include voice calling, video chat, P2P file sharing, and use cases that have already leveraged the power and convenience of WebRTC.
    "We're a cybersecurity firm that specializes in engineering security solutions both at the software and hardware level. Security cannot be an after-the-fact afterthought, which is what it's become," stated Richard Blech, Chief Executive Officer at Secure Channels, in this SYS-CON.tv interview at @ThingsExpo, held November 1-3, 2016, at the Santa Clara Convention Center in Santa Clara, CA.