Building Web Components that Access Federated Data

Federated DBMSs offer Web architects help in coping with disparate data. In this second of three articles, author C. M. Saracco explore ways in which Java-based components -- such as session Enterprise JavaBeans (EJBs) and Web services -- can be built to work with federated data.

C. M. Saracco, Senior Software Engineer, IBM Silicon Valley Lab

C. M. Saracco is a senior software engineer at IBM's Silicon Valley laboratory and a former software technology instructor for UC Santa Cruz extension program. She has lectured on a variety of technology topics throughout North America, South America, Europe and the Middle East.


developerWorks Professional author
        level

05 September 2002

Also available in Japanese

Introduction

JavaTM programmers who build components to support Web applications are often forced to confront troublesome data access issues. While working with data in a single, remote relational database management system (DBMS) is a fairly straightforward task, integrating data from multiple data sources isn't. Frequently, this data resides on different servers, is stored in different data formats, and is accessible only through different application programming interfaces (APIs) or Structured Query Language (SQL) dialects. These issues increase the complexity of the task at hand, lengthening development cycles and adding to long-term maintenance costs.

However, getting to the data is only part of the problem. Combining, filtering, sorting, and consolidating disparate data is a formidable and expensive task. Shortcuts can lead to poor use of computing resources, poor response times for users, and poor performance at the data servers. For these reasons, many Web component programmers would prefer to delegate data access and integration issues to someone else. And that someone else may actually be something else -- a federated data server.

Federated DBMS technology, which emerged commercially in the 1990s, provides programmers with a single-site image of disparate data. Programmers connect to a virtual database maintained by the federated DBMS and use its API to access data that may be managed -- or generated -- by a variety of sources elsewhere. The federated DBMS works behind the scenes to make access to this disparate data transparent and efficient. Such work includes automatic data transformations, API conversions, functional compensation, and optimization of data access operations.

In our previous article, Coping with Disparate Data in Web Applications, we presented a technology overview and provided a sample architecture for IBM's® WebSphere® and DB2® federated technology. In this article, we'll explore ways in which Java-based components -- such as session Enterprise JavaBeansTM (EJBs) and Web services -- can be built to work with federated data. In a later article, Building Entity EJBs that Span Federated Data, we'll see how to build entity EJBs that span federated data.


Understanding the Java component technologies

Java programmers who build components to run on mid-tier Web application servers may implement their data access routines using several different technologies, including EJBs, Web services, servlets, and Java Server PagesTM (JSPs). Each of these technologies is different, but all place some common coding requirements on Java developers. Accessing relational data -- or federated data managed by a relational DBMS -- implies the need to write JDBC or SQLJ code. JDBC is used most commonly today. And working with relational data requires programmers to establish a connection to the target database, issue SQL statements, and manage transactions. We'll discuss each of these issues shortly, paying particular attention to how they are handled when federated data is involved. But first, let's discuss the basics of session EJBs and Web services, as we'll be reviewing coding examples for each.

Session EJBs

Session EJBs are Java 2 Enterprise Edition (J2EE) components that adhere to certain programming specifications. These beans may work with persistent data but do not represent persistent data themselves. That is, any data associated with a session bean will not persist -- will not continue to exist -- after the bean's resources are released by the caller. Entity beans, which we'll discuss in a subsequent article, are persistent by nature. They represent data stored externally, typically in a relational DBMS.

EJBs are deployed in containers managed by a Web application server, such as WebSphere Application Server. These containers provide production services, such as support for security and transaction management, so that programmers needn't explicitly code such functions into their beans.

Session and entity EJBs have somewhat different coding requirements, and these coding requirements vary depending on the EJB specification level in use. This article focuses on EJB 1.1-compliant beans, which is the level supported by WebSphere Application Server 4.0.

At deployment, each session bean has multiple code modules, including:

  • The home interface, which defines client methods for creating and removing instances of the bean.
  • The remote interface, which defines the business methods associated with the bean.
  • The bean class, which contains business logic methods coded by the EJB developer as well as EJB life cycle methods used by the container. EJB clients don't access objects of this class directly, but instead work with the container-generated classes that implement the home and remote interfaces to indirectly employ services of this class.

Session beans may stateless or stateful. Stateless session beans don't maintain any conversational state across client calls; each method invoked by the client is handled independently and uses only data associated with its input parameters. Stateful session beans maintain conversational state throughout a client's session; one method may change a data value of a bean's attribute, which will in turn affect the behavior of subsequent methods that are called. In this article, we'll focus on working with stateless session EJBs.

After developing an EJB, the programmer must set deployment descriptors that govern characteristics such as transaction support, isolation levels, and others. Finally, the bean must be packaged and deployed in an EJB server. The deployment process causes additional classes to be generated, including those associated with the home and remote interfaces. A good Java development environment can speed development, deployment, and testing of EJBs; we used WebSphere Studio Application Developer Integration Edition (WSADIE) 4.1.

Web services

Web service technology is actively evolving as of this writing, although the World Wide Web Consortium (W3C) has published a number of working drafts related to various aspects of web services. Web services are not part of the Java specification, but Java is often the programming language of choice for developing Web services.

A Web service is a set of one or more business functions that can be invoked programmatically over the Internet by applications or by other web services. As such, Web services facilitate distributed computing and are designed to promote interoperability. Several underlying technologies play a key role in supporting Web services, including HTTP, Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Definition Language (WSDL), and Universal Description, Discovery and Integration (UDDI).

Web service providers publish their Web services so that clients can access them using SOAP over HTTP. This contrasts with EJB clients, who access beans using remote method invocation (RMI) over Internet Inter-Orb Protocol (IIOP).

Web services process requests from Web clients, invoking the appropriate business function and typically returning a response. The Web service itself is described by a WSDL document stored in a repository (such as a UDDI registry) or on the Web service provider's server. Storing the Web service description in an appropriate repository offers the potential for interested customers to discover its existence, potentially generating new business for the Web service provider.


Setting up the software environment

Before building Java components that access federated data, you must configure your DBMS client and server environment. In our earlier article, we presented a series of steps we completed to configure a DB2 V7.2 client to interface to a DB2 V8 federated DBMS, which itself had been set up to access data on remote Oracle, Sybase, and Microsoft® SQL Server DBMSs. We won't repeat all the details here; instead, we'll just outline the tasks to give you an idea of what's involved. For more information, see the previous article or consult the DB2 product manuals.

To begin, basic connectivity must be enabled between your client and server platforms (unless client and server software are installed on the same machine). We used TCP/IP for communications and added entries to the services files on each system to specify a service name and port number for our use.

With connectivity enabled, we set up our federated DBMS server. This involved:

  • Installing a DB2 V8 server instance on a UNIX® or Windows® platform
  • Updating database manager configuration properties for SVCENAME and FEDERATED
  • Creating a DB2 database (rdjdb in our environment) to manage federated access
  • Installing any prerequisite software required by our target data sources, and configuring network access to the systems on which these data sources reside
  • Creating wrapper, server, and user mapping objects for each data source we wished to access
  • Creating nicknames for remote data objects (such as a remote Oracle table) and views based upon these nicknames, as desired

After testing the server configuration locally to ensure that everything was working as expected, we configured our Java development client. This involved:

  • Installing the DB2 client software.
  • Specifying information about the remote node on which our federated database resides.
  • Specifying a logical database name for the remote federated database. In our environment, we used djdb as our local database name for the remote rdjdb database.

To simplify development and testing of our Java components, we installed a Java integrated development environment -- IBM's WSADIE 4.1 -- on our client as well. WSADIE comes with an embedded copy of WebSphere Application Server, making it quick and easy to deploy our session EJBs and publish our Web services within a test environment. Setting up WSADIE to work with our federated database involved:

  • Adding the db2java.zip file to the Java build path of our EJB and Web projects.
  • Creating a WebSphere DataSource object to correspond to our federated database. We specified a Java Naming Directory Interface (JNDI) name of jdbc/Federated with a JDBC URL of jdbc:db2:djdb. We also set the user ID and passwords to appropriate values (user1 and pass1word, respectively).

Establishing a database connection

After your environment is properly configured, you're ready to develop Java components that work with federated data. Any component you build must establish a connection to the federated database before attempting to access its data. When building session EJBs, Web services, servlets, or JSPs, you're responsible for writing this code. When building entity beans with container-managed persistence, you aren't -- this code is generated automatically for you by the EJB container. We'll discuss entity EJBs in a future article.

Java programmers creating application server components have two options for establishing database connections: They can use unpooled or pooled connections. Unpooled connections are based on the JDBC 1.0 specification and are the older of the two techniques. They are also the least desirable for production components, as each component incurs the overhead of creating a new database connection and releasing the connection. Pooled connections use DataSource objects introduced in the JDBC 2.0 specification. They are frequently less expensive to obtain than unpooled connections. They also allow for more efficient use of system resources, enabling administrators to automate such features as how long an application can hold an inactive connection, how long free connections remain in the pool before being closed, and how many connections the pool may contain before reaching its maximum state.

We built session EJBs and Web services using both kinds of connections, and we'll review code examples of each here. However, note that unpooled connections should rarely be used outside of test purposes. Performance and resource issues aside, unpooled connections can interfere with the transaction semantics automatically implemented by EJB containers, as you'll find out later in this article.

Because pooled connections are preferred, we'll discuss these first. As mentioned earlier, DataSource objects represent pooled database connections. In WebSphere Application Server and WSADIE, DataSources may be added to a Web application server using a graphical administrative tool. Once the server is started, programmers use JNDI services to look up the DataSource of interest and invoke methods associated with it for obtaining a pooled connection. Listing 1 shows how this is done. The technique may be used in any server-side Java component or Java-based Web service.

Listing 1. Obtaining a pooled connection

// import any necessary packages 
import java.sql.*; 
import javax.sql.*; 
import javax.naming.*; 
 
// sample method using a DataSource connection 
public void sampleDS()  throws Exception { 
 . . . 
 
// set the user ID and password. 
// these values must correspond to values valid at the target data source 
String userid = "user1"; 
String pwd = "pass1word"; 
 
// declare a variable for the connection 
Connection con = null; 
 
try { 
	// get the initial context using default values 
	Context ctx = new InitialContext(); 
	// look up the desired data source 
	DataSource ds = (DataSource) ctx.lookup("jdbc/Federated"); 
	// get a connection using a specific user ID and password 
	con = ds.getConnection(userid, pwd); 
	... 
} 
 
// handle any exceptions 
catch (Exception e) { 
... 
} 
// any acquired resources should be released here 
finally { 
	try { 
		// release the connection 
		if (con != null)  { con.close(); } 
		... 
	} 
	... 
} 
 
// end the sample method 
}

Unpooled connections are established without the use of JNDI services. Instead of obtaining an initial context from the Web application server and looking up a given name, programmers load the JDBC driver manager particular to their DBMS. Next, they obtain a connection from the DriverManager class. This logic is identical to that found in the sample DB2 Java applications that ship with the product. For completeness, we've provided a code sample in Listing 2 for establishing an unpooled connection using JDBC 1.0-style techniques. However, avoid using these types of connections when building production-level components for Web application servers. They can waste system resources, incur unnecessary overhead, and potentially interfere with built-in transaction support provided by EJB containers.

Listing 2. Obtaining an unpooled connection

// import any necessary packages 
import java.sql.*; 
.... 
 
// sample method using an unpooled connection for DB2 on UNIX or Windows 
public void sampleNoDS()  throws Exception { 
 
// specify the URL for the target database, as defined to the client 
String url = "jdbc:db2:djdb"; 
// specify a valid user ID for the target database 
String userid = "user1"; 
// specify a valid password for the target database 
String pwd = "pass1word"; 
 
// declare a variable for the connection 
Connection con = null; 
 
.... 
 
try { 
 
	// load the JDBC driver class 
	Class.forName("COM.ibm.db2.jdbc.app.DB2Driver").newInstance(); 
	// instruct the JDBC Driver Manager to get a new connection. 
	// note that we explicitly reference the desired database URL 
	con = DriverManager.getConnection(url, userid, pwd); 
	... 
 
} 
// handle any exceptions 
catch (Exception e) { 
... 
} 
// any acquired resources should be released here 
finally { 
	try { 
		// close the connection 
		if (con != null)  { con.close(); } 
		... 
	} 
	... 
} 
 
// end the sample method 
}

If you're an experienced JDBC programmer, you've probably noticed something by now: Working with federated data doesn't require any special programming. That's because a federated DB2 instance is designed to provide transparent access to remote data. After the environment is properly configured, programmers work with federated data in the same manner as they would work with locally managed DB2 data.


Accessing federated data

With a connection established, you're ready to select, insert, update, or delete data from federated data objects. The JDBC code for doing this work is the same as the code you would write to work with local DB2 data. Indeed, someone reading your code wouldn't know you're working with federated data, unless she or he happened to know that the "table" referenced in your SQL statement is really a nickname.

For example, assume we created a DINING nickname in our federated DB2 database to map to a remote table named REST (for restaurant) in an Oracle server known in our environment as Oracle8. We may have issued a SQL statement similar to this:

create nickname dining for oracle8.oracleuser1.rest

The SQL statements included in our JDBC code would simply reference DINING. The following code excerpt creates a query statement for the connection established earlier. Next, it updates data in the DINING nickname and closes the statement when completed.

Listing 3. Executing an SQL UPDATE against a nickname

// declare a Statement object for later use 
Statement stmt = null; 
... 
 
try { 
	// establish a connection to the federated database 
	... 
	// create the Statement object 
	stmt = con.createStatement(); 
	// update some data in a nickname 
      int output = stmt.executeUpdate("UPDATE dining set score=1 where id=12"); 
 
	... 
} 
// handle any exceptions 
catch (Exception e) { 
	... 
} 
// any acquired resources should be released here 
finally { 
	try { 
		// close the statement 
		if (con != stmt)  { stmt.close(); } 
		... 
	} 
	... 
}

Of course, more complex data access operations are possible. For example, we could have joined data from multiple sources simply by writing a single SQL statement that references multiple nicknames. Views can also be built that join or union data from multiple sources, which extends the data modeling potential of entity beans that use container-managed persistence. We'll explore that topic in a future article.


Managing transactions

While data access from server-side Java components and Web services is the same as from any JDBC application, transaction management warrants closer consideration. For example, the EJB programming model requires session bean developers to declare transaction attributes for their beans. Use of container-managed transaction attributes is most common, as it delegates transaction management responsibility to the EJB container. Thus, EJB programmers needn't hard-code begin/end transaction instructions (including commit/rollback instructions) in their beans. Instead, they declare such information by setting a deployment descriptor for the transaction attribute property of their bean. The EJB container automatically enforces the appropriate transaction semantic at runtime.

The EJB 1.1 specification defines several different transaction attributes for container-managed transactions to be supported, which are summarized below. For details, see the EJB 1.1 specification.

Required

The EJB method will be invoked within a valid transaction context. If the method is invoked by a client that already has a transaction context, the EJB method will execute within that transaction. If the method is invoked without an existing transaction context, a new transaction is started and the EJB method is executed. The EJB container automatically attempts to commit the transaction when the EJB method has completed.

RequiresNew

Similar to Required, in that the EJB method will execute within a transaction context. However, this method will always execute in a new context. Thus, if the method is invoked by a client that already has a transaction context, the existing transaction is suspended and a new transaction is started. When the EJB method completes, the container will automatically commit the transaction and resume the suspended transaction.

NotSupported

The EJB method will be invoked with an "unspecified transaction context." Transaction semantics may vary, depending on the container implementation (that is; vendor product) in use.

Supports

Specific actions will vary, depending on the transaction context of the EJB client. If the client has a transaction context, the case is handled in the same manner as Required. If the client lacks a transaction context, the case is handled in the same manner as NotSupported

Mandatory

The EJB method must be invoked within the client's transaction context. If the client lacks a transaction context, the container throws an exception. If the client has a transaction context, the case is handled in the same manner as Required.

Never

Specific actions will vary, depending on the transaction context of the EJB client. If the client has a transaction context, the container throws an exception. If the client lacks a transaction context, the case is handled in the same manner as NotSupported.

In addition, session bean programmers can declare their transactions to be BeanManaged and write code that employs the javax.transaction. UserTransaction interface (part of the Java Transaction API) to demarcate the beginning and end of the transaction. However, many EJB architects prefer to avoid using bean-managed transactions unless specific business needs dictate their use. Allowing the EJB container to automate transaction management can reduce coding and testing requirements. We'll consider only container-managed transactions here.

However, other Web application components don't have a means for automatic transaction enforcement. So if you're developing Web services, servlets, or JSPs, you'll have to manage transactions in your code.

As we mentioned earlier, it's best to use pooled connection (based on DataSource objects) for data access. Not only does this help improve performance and conserve system resources, it avoids problems with transaction semantics, particularly with EJBs. With unpooled connections, there can be conflicts between transaction work the EJB container expects to undertake and the work your EJB is performing "under the covers." While you won't notice any problems if you run your EJB in isolation, you may experience transactional inconsistencies if your EJB is participates in work involving other EJBs. It's best to have one component -- the EJB container -- take on all transaction management responsibilities than to try to split the work of coordinating a transaction among multiple components, some of which you may write yourself.

So what does all this mean? Here are a few guidelines we follow when developing Web application components that accesses persistent data:

  • Use pooled (DataSource) connections supported by your Web application server. Explicitly set the JDBC autoCommit() mode. This setting determines whether or not a commit statement is automatically issued after each SQL statement. By default, this is set to true. Explicitly setting the value avoids confusion and makes your code easier to maintain.
  • If writing session EJBs, set autoCommit() to false and allow the EJB container to manage the transaction on behalf of your bean. In addition, set the transaction attribute in the bean's deployment descriptor to Required or Requires_New.
  • If writing Web application components other than EJBs, set autoCommit() to either true or false, depending on your application needs. If you set it to false, be sure to explicitly commit() your work when necessary.

Finally, DB2 V8.1 currently restricts write activities to a single data source per transaction. If you wish to use its federated DBMS capabilities, you must develop your server-side Java components and Web services with this in mind.


Creating a session bean to access federated data

Now that you're familiar with the basic issues involved with accessing federated data from a Web application component, let's discuss how to create a session EJB to do so. We'll see how to build the session EJB using WSADIE, as well as review key portions of the generated code.

When working with WSADIE, switch to the J2EE perspective and create an EJB project and session EJB as usual. Consult the online documentation, if necessary, to help you with these tasks. With a stateless session bean created, you can now write code for a new business method to access the federated data. Listing 4 shows how a session EJB method was built to access federated data using a pooled connection. This code sample is provided to you AS IS as described in the References.

The QueryNickname session EJB contains our updateDining() business method. This method resides in the QueryNickname bean implementation class. The method obtains a pooled connection from a data source previously defined in the WebSphere Application Server test environment as jdbc/Federated, which maps to a JDBC URL of jdbc:db2:djdb. A simple UPDATE query is issued against a federated nickname, and a count of the changed rows is returned to the caller. (Although not shown here, SELECT, INSERT, and DELETE operations are coded similarly.) Finally, acquired resources are released. Note that no special coding requirements are necessary for working with federated data. Additional methods included in this example are generated automatically by WSADIE and conform to requirements of the EJB 1.1 specification.

Listing 4. Session EJB to access federated data

package session; 
 
import java.sql.*; 
import javax.sql.*; 
import javax.naming.*; 
 
/** 
 * Bean implementation class for Enterprise Bean: QueryNickname 
 */ 
 
  /*********************************************************************/ 
 
public class QueryNicknameBean implements javax.ejb.SessionBean { 
private javax.ejb.SessionContext mySessionCtx; 
/** 
 * getSessionContext 
 */ 
public javax.ejb.SessionContext getSessionContext() { 
return mySessionCtx; 
} 
/** 
 * setSessionContext 
 */ 
public void setSessionContext(javax.ejb.SessionContext ctx) { 
mySessionCtx = ctx; 
} 
/** 
 * ejbActivate 
 */ 
public void ejbActivate() { 
} 
/** 
 * ejbCreate 
 */ 
public void ejbCreate() throws javax.ejb.CreateException { 
} 
/** 
 * ejbPassivate 
 */ 
public void ejbPassivate() { 
} 
/** 
 * ejbRemove 
 */ 
public void ejbRemove() { 
} 
 
// test oracle nickname access via data source 
public int updateDining()  throws Exception { 
 
	// set values for DBMS user ID and password 
	String userid = "user1"; 
	String pwd = "pass1word"; 
 
	// declare variables for our Statement and Connection objects 
	Statement stmt = null; 
	Connection con = null; 
 
	// declare variable for return value:  number of rows changed 
	int output = 0; 
 
	try { 
		// get an initial context 
		Context ctx = new InitialContext(); 
		// perform JNDI look up of our federated data source 
		DataSource ds = (DataSource) ctx.lookup("jdbc/Federated"); 
		// establish a connection to the data source 
		con = ds.getConnection(userid, pwd); 
		// turn off auto commit mode 
		con.setAutoCommit(false); 
 
		// create a statement for our SQL query 
		stmt = con.createStatement(); 
		// execute an update statement 
		output = stmt.executeUpdate("update dining set score=2 where id=87"); 
		// return the count of changed rows 
		return output; 
	} 
	// handle any exceptions 
	catch (Exception e) { 
		... 
	} 
	// clean up resources 
	finally { 
		try { 
			// release the statement 
			if (stmt != null) { stmt.close(); } 
			// release the connection 
			if (con != null)  { con.close(); } 
		} 
		catch (Exception e) { 
			e.printStackTrace(); 
		} 
 
	}  // end finally block 
} // end updateDining 
 
}

The bean implementation class shown previously is only one software module required for a fully functioning session bean. In order for our updateDining method to be accessible to callers, it must be added to the bean's remote interface. In WSADIE, this is readily done through the J2EE perspective. Consult the product documentation, if necessary, for help with this step. When completed, the bean's remote interface looks like Listing 5.

Listing 5. Remote interface for QueryNickname Enterprise Bean

package session; 
/** 
 * Remote interface for Enterprise Bean: QueryNickname 
 */ 
public interface QueryNickname extends javax.ejb.EJBObject { 
// test oracle nickname access via data source 
public int updateDining()  throws Exception, java.rmi.RemoteException; 
}

The bean's home interface is unchanged by our work. Sample code generated by WSADIE is shown in Listing 6.

Listing 6. Home interface for QueryNickname Enterprise Bean

package session; 
/** 
 * Home interface for Enterprise Bean: QueryNickname 
 */ 
public interface QueryNicknameHome extends javax.ejb.EJBHome { 
/** 
 * Creates a default instance of Session Bean: QueryNickname 
 */ 
public session.QueryNickname create() throws javax.ejb.CreateException,  
  java.rmi.RemoteException; 
}

Creating a Web Service to access federated data

As you've seen, standard JDBC programming techniques can be used in session EJBs to access federated data. Web services, as well as other application server components, can also be developed to access federated data using standard JDBC programming techniques. Indeed, the Java source code required for a Web service is nearly identical to that required for a business method in a session bean.

WSADIE enables you to build Web services based on a variety of software components, including EJBs and standard JavaBeans. The latter differ from EJBs, although the names sound similar. (For details on JavaBeans, see the specification from Sun Microsystems.) Building a Web service derived from a JavaBean is arguably one of the easiest development techniques, and the one we'll discuss here.

When working with WSADIE, switch to the Web perspective and create a Web project as usual. Within this project, create a JavaBean of your choice and a business method suitable for use as a Web service. For test purposes, it's sufficient to create a Java class with a zero-argument constructor and a simple business method that returns a String or other primitive as output. Follow the standard WSADIE process for generating and testing a Web service from this JavaBean. (To invoke a wizard to guide you through this process, highlight the JavaBean class, right-click, then select New -> Web Service.) Consult WSADIE's online documentation, if necessary, to help you with this task.

Listing 7 shows a SimpleWebQuery class with an addRow() method, which we used as the basis for a Web service. Note that the method makes a pooled connection to a DataSource previously defined in the WebSphere test environment as jdbc/Federated. Our method merely inserts a single row into a nickname mapped to a Microsoft SQL Server table and then releases acquired resources. No special code is required for working with federated data.

Listing 7. Simple WebQuery class

// import required packages 
import java.sql.*; 
import javax.sql.*; 
import javax.naming.*; 
 
 
 
public class SimpleWebQuery { 
 
   // We need a zero-argument constructor 
   public SimpleWebQuery() { 
   		super(); 
   } 
 
   // This method will insert a single row into a nickname. 
   // For production applications, we'd want to make its INSERT 
   // statement more flexible. 
   public String addRow() { 
 
   	Connection con = null; 
	Statement stmt = null; 
	String reply = null; 
 
      String user = "user1"; 
      String pwd = "pass1word"; 
 
      try { 
   	  // get a pooled connection 
   	  InitialContext context = new InitialContext(); 
	  DataSource ds = (DataSource) context.lookup("jdbc/Federated"); 
	  con=ds.getConnection(user, pwd); 
	  con.setAutoCommit(true); 
 
	// insert a row into the database 
        stmt = con.createStatement(); 
	  stmt.executeUpdate("Insert into DINING values 
			(85, 'New Restaurant', 2)"); 
        reply = new String("Insert complete."); 
    	 } 
 
   	 catch (Exception e) { 
	   // handle any exceptions 
	   ... 
   	 } 
 
   	 finally { 
            // release all acquired resources 
   	 	try { 
   	 		if (stmt != null) { stmt.close(); } 
   	 	} catch (Exception e) { } 
   	 	try { 
   	 		if (con != null) { con.close(); } 
   	 	} catch (Exception e) { } 
   	 	return reply; 
   	 } 
 
   } // end addRow 
}

References and related readings

Useful Web sites

IBM DB2 manuals, articles, and white papers:

IBM WebSphere Application Server manuals, articles, and white papers:

IBM redbooks on a variety of topics:

Web services articles and papers:

Acknowledgments

The author would like to thank Vander Alves, Jordan Barnes, and Dirk Wollscheid for their technical contributions to this project.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management, WebSphere
ArticleID=13164
ArticleTitle=Building Web Components that Access Federated Data
publish-date=09052002