Building Entity EJBs that Span Federated Data

While a number of development tools can help programmers build a single entity EJB that maps to a single table, it's harder to find tools that help programmers create an entity EJB that maps to nonrelational data or to data managed by multiple data sources . This article describes how a DB2 federated DBMS presents a virtual database that masks differences in the APIs required by remote data sources.

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.


developerWorks Professional author
        level

17 September 2002

Introduction

It's not unusual for developers of entity Enterprise JavaBeansTM (EJBs) to find themselves faced with challenging data modeling issues. Because entity EJBs typically represent data managed by a relational DBMS, programmers often must decide how to map existing data in tables to new server-side JavaTM objects needed to support Web applications. While a number of development tools can help programmers build a single entity EJB that maps to a single table, it's harder to find tools that help programmers create an entity EJB that maps to nonrelational data or to data managed by multiple data sources (possibly both relational and nonrelational).

In this article, we'll investigate how an IBM® DB2® federated database management system (DBMS) can help EJB programmers cope with some of these issues. This technology provides programmers with a single-site image of disparate data, presenting a virtual database that masks differences in the application programming interfaces (APIs) required by remote data sources. This is one characteristic of a federated DBMS that enables EJB programmers to work with disparate data in a transparent and efficient manner.

A previous article, Coping with Disparate Data in Web Applications, introduced federated DBMS concepts and explained how they can complement Web application server environments. Another article, Building Web Components that Access Federated Data , reviewed design requirements for building session EJBs and Web services that work with federated data. Here, we'll explore a more aggressive use of federated DBMS technology: using it as a basis for creating entity beans with container-managed persistence (CMP). But before we delve into the technical details, it's important to understand when federated database technology may be beneficial to entity EJB programmers.


Where's the benefit?

CMP entity beans represent a fairly sophisticated use of DB2 federated database technology, because the database access code -- that is, the code that implements persistence -- is automatically generated when the EJB is deployed. By contrast, programmers building session EJBs that access persistent data write their own JDBC statements to establish database connections and issue SQL statements.

In subsequent sections, we'll discuss how to build a variety of CMP entity beans that use federated DBMS technology. IBM's WebSphere® Studio Application Developer Integration Edition (WSADIE) will be our Java development platform. First, though, it's important to understand when using DB2 federated technology may be beneficial to entity bean programmers. Federated technology can:

  • Expand the breadth of data sources represented by your EJBs. Although popular Java programming tools -- such as IBM's WSADIE -- provide native support for a wide range of data sources, DB2's federated technology provides ready-made access to some additional data sources, including nonrelational sources. Furthermore, DB2 programmers can build wrappers, if desired, to enable DB2 to access any desired data source, including "legacy" DBMSs, file systems, prototype software, etc.
  • Support automated development and deployment of CMP entity beans for many commonly used DBMSs without requiring that client software for these DBMSs be installed on the platform running WSADIE or IBM's WebSphere Application Server.
  • Support automated development and deployment of a single CMP entity bean whose attributes map to data from multiple data sources. In this scenario, a DB2 view is created that joins or unions data from multiple data servers. Because of the "view update" problem common to any relational DBMS, such CMP entity beans are developed to be read-only.

Overview of entity EJBs

EJBs are server-side software components that adhere to certain programming specifications. Entity EJBs represent persistent data that is typically stored in a relational DBMS. Developers can manage the persistent aspects of their beans themselves (via bean-managed persistence or BMP), but most choose to delegate this responsibility to the container (via container-managed persistence or CMP). This article focuses on CMP entity beans.

The EJB specification places certain coding requirements on developers. These requirements vary somewhat, depending on the EJB specification level you want to support. For this article, we'll focus on EJB 1.1, which is the level supported by WebSphere Application Server Version 4 (our target deployment platform). At deployment, each CMP entity bean has several code modules, including:

  • The home interface, which defines client methods for creating, finding, and removing instances of the bean.
  • The remote interface, which defines the business methods associated with the bean. "Getters" and "setters" are commonly used to get and set individual attributes of 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.
  • The primary key class, which identifies the attribute (or set of attributes) that uniquely identifies each instance of this bean and provides methods for creating and manipulating the key.

After developing an EJB, the programmer must set deployment descriptors that govern characteristics of the bean, such as its transaction isolation level. 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 described earlier. An appropriate Java development environment (such as WSADIE) can be of considerable help when developing, deploying, and testing EJBs.


Setting up the software environment

Before building Java components that access federated data, you must configure your DBMS client and server environment. An earlier article described how we configured a DB2 V7.2 client to interface to a DB2 Version 8 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 overall tasks to refresh your memory. For more information, see the previous article or consult the DB2 product manuals.

To begin, basic connectivity must be enabled between your DB2 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:

  1. Installing a DB2 Version 8 server instance on a UNIX® or Windows® platform.
  2. Updating database manager configuration properties for SVCENAME and FEDERATED.
  3. Creating a DB2 database (rdjdb in our environment) to manage federated access.
  4. Installing any prerequisite software required by our target data sources, and configuring network access to the systems on which these data sources reside.
  5. Creating wrapper, server, and user mapping objects for each data source we wished to access.
  6. 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 client platform. This involved:

  1. Installing the DB2 client software.
  2. Specifying information about the remote node on which our federated database resides.
  3. 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 WAS 4.0.2, making it easy to deploy and test our entity EJBs. 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).

Working with entity beans and federated data

In the next several sections of this article, we'll present step-by-step instructions for creating various CMP entity beans that work with federated data using WSADIE. These sections are intended for programmers already familiar with the basics of WSADIE. If you find you don't know how to perform a given step -- such as how to create an EJB project or how to deploy an EJB in the WebSphere test environment -- consult the product's online documentation or visit the WebSphere Developer Domain, http://www.ibm.com/webshpere/developer, and follow some of their product tutorials.

Creating a CMP entity bean for an existing nickname

As we mentioned in earlier articles, nicknames represent remote data to DB2. EJB programmers can use WSADIE to create CMP entity beans to map to nicknames that have already been created with DB2 federated technology. In our test environment, we created individual entity beans that map to nicknames associated with individual Oracle, Sybase, and Microsoft SQL Server tables. Of course, DB2 federated technology supports access to other data sources (including nonrelational data sources); the process for creating CMP entity beans that map to nicknames representing data from these other sources is the same. However, if DB2 imposes any data access restrictions on a given data source, you may need to do some additional work. For example, DB2 supports read-only access to certain data sources. If you build CMP entity beans on nicknames involving these data sources, you should modify your bean code to avoid write attempts. We'll see how to do this in a later section when we discuss how to build a CMP entity bean that maps to a view that joins or unions data from multiple data sources. Such views are inherently read only.

In WSADIE 4.1, top-down modeling is the only approach that will support development of CMP entity beans over federated data. While using top-down modeling tools to work with existing data may seem counterintuitive, it is actually a straightforward process that will achieve the desired result: generating a working CMP entity bean for a nickname.

Follow these steps to develop such a CMP entity bean:

  1. Switch to the Java 2 Enterprise Edition (J2EE) perspective. If necessary, create an EJB project for your entity bean following WSADIE's standard process.
  2. Create a CMP entity EJB following the standard process.
    • Give your bean the same name as your nickname.
    • Add attributes to correspond to each of the columns in your nickname, being careful to specify appropriate data types for each and to designate the appropriate attribute as the key field (which should map to the primary key column of the nickname). Again, your attribute names should correspond to your column names.
  3. Invoke the EJB data modeling wizard and elect top-down modeling.
    • Highlight your EJB, right mouse click, Open With -> Mapping Editor. Select top-down modeling.
    • Click Next, and ensure that the database name and schema names are set properly. The database name should map to the federated database known to your DB2 client. (In our environment, this was djdb.) The schema name should map to the authorized federated database user. (In our environment, this was user1.)
    • Uncheck the Generate DDL box, then click Finish.
  4. Verify that your EJB-to-database mapping completed successfully
    • Highlight your EJB, right mouse click, Open With -> Mapping Editor.
    • Inspect the Tasks panel to ensure that no errors have been reported.
  5. Bind your EJB to the appropriate data source you created earlier for your federated database.
    • Highlight your EJB, right mouse click, EJB Quick Links -> Bind Data Source.
    • Enter a valid JNDI name, user name, and password in the Datasource area of the panel. For example, in our test environment, we entered jdbc/Federated as the JNDI name, as the user name, and pass1word as the password.
    • Save your changes (Control-S), then close the editor.
  6. Generate deployed code for your bean as usual. (Highlight your EJB, right mouse click, Generate Deploy Code.)

Creating a CMP entity bean for a new nickname

If a nickname doesn't already exist for data that you'd like to represent as a CMP entity bean, you can still use WSADIE to build and deploy your bean. The process is nearly identical to that described in the previous section. You'll still use the top-down modeling support of WSADIE's EJB development wizard to model your bean. However, you'll need to create a DB2 nickname for the remote data before you actually attempt to use your bean. If your remote data source doesn't already have the necessary data object or table created, you'll need to create it beforehand as well. You may perform these tasks manually, following instructions in the DB2 manuals. Or you can partially automate the process using DDL generated by WSADIE. We'll describe the latter option here.

DB2's federated technology features SQL data definition language (DDL) transparency for relational DBMSs. This means that you can use DB2's CREATE TABLE .... OPTIONS syntax to perform two separate tasks with one statement: creating a table at the desired remote data source and creating a corresponding DB2 nickname for this table. Using the DDL transparency feature simplifies your work, as DB2 performs any necessary SQL translation to properly construct the remote table; you needn't learn the specific SQL syntax of that data source to create a valid table. We'll use this DDL transparency feature to create a new table at a remote source and a new nickname for this table, which will ultimately be used by a CMP entity bean.

Follow these steps to develop the CMP entity bean:

  1. Switch to the J2EE perspective. If necessary, create an EJB project for your entity bean following WSADIE's standard process.
  2. Create a CMP entity EJB following the standard process.
    • Give your bean the same name as the nickname you intend to create.
    • Add attributes to correspond to each of the columns in your nickname, being careful to specify appropriate data types for each and to designate the appropriate attribute as the key field (which should map to the primary key column of the nickname). Again, your attribute names should correspond to your column names.
  3. Invoke the EJB data modeling wizard and elect top-down modeling.
    • Highlight your EJB, right mouse click, Open With -> Mapping Editor. Select top-down modeling.
    • Click Next, and ensure that the database name and schema names are set properly. The database name should map to the federated database known to your DB2 client. (In our environment, this was djdb.) The schema name should map to the authorized federated database user. (In our environment, this was user1)
    • Leave the Generate DDL box checked, then click Finish.
  4. Verify that your EJB-to-database mapping completed successfully
    • Highlight your EJB, right mouse click, Open With -> Mapping Editor.
    • Inspect the Tasks panel to ensure that no errors have been reported.
  5. Bind your EJB to the appropriate data source you created earlier for your federated database.
    • Highlight your EJB, right mouse click, EJB Quick Links -> Bind Data Source.
    • Enter a valid JNDI name, user name, and password in the Datasource area of the panel. For example, in our test environment, we entered jdbc/Federated as the JNDI name, user1 as the user name, and pass1word as the password.
    • Save your changes (Control-S), then close the editor.
  6. Generate deployed code for your bean as usual. (Highlight your EJB, right mouse click, Generate Deploy Code.)
  7. Any time before you deploy and attempt to test your bean, create the nickname and remote data object. Review the Table.ddl file generated by WSADIE. This file can be found in the J2EE perspective's Navigator panel under your bean project's name. Expand ejbModule -> META-INF -> Schema to see the file. This file provides a good starting point for the DDL you'll need to issue. Modify the generated DDL in the following manner:
    • Remove the CREATE SCHEMA statement.
    • Modify the CREATE TABLE statement so that the primary key constraint is defined at the column level. For example, if the statement originally read
                 	CREATE TABLE MYTABLE (COL1 INT,COL2 INT)

      Modify the statement to read something like this
                  CREATE TABLE SCHEMANAME.MYTABLE 
                 (COL1 INT PRIMARY KEY NOT NULL, 
                   COL2 INT)
    • Add an OPTIONS clause to the CREATE TABLE statement, specifying remote server and remote schema information. The remote server must reference the data source name you specified in a CREATE SERVER statement at configuration time. The remote schema name must correspond to a valid schema name at the data source, which is typically the REMOTE_AUTHID you specified in a CREATE USER MAPPING statement at configuration time. For example, given our environment's configuration, we would add an OPTIONS clause to the CREATE TABLE statement to read:
      CREATE TABLE SCHEMANAME.MYTABLE 
                  (COL1 INT PRIMARY KEY NOT NULL, COL2 INT) 
                  OPTIONS (REMOTE_SERVER 'ORACLE8', REMOTE_SCHEMA 'ORACLEUSER1')
    • Remove the ALTER TABLE statement.

Here is a complete example from the author's test environment:

-- Generated by Relational Schema Center of WSADIE 
 
CREATE SCHEMA user1; 
 
CREATE TABLE user1.FOOBAR 
  (ID INTEGER NOT NULL, 
   NAME VARCHAR(250)); 
 
ALTER TABLE user1.FOOBAR 
  ADD CONSTRAINT FOOBARPK PRIMARY KEY (ID); 
 
 
-- Revised DDL 
 
CREATE TABLE user1.FOOBAR 
  (ID INTEGER PRIMARY KEY NOT NULL , 
   NAME VARCHAR(250)) 
   OPTIONS (REMOTE_SERVER 'ORACLE8', 
            REMOTE_SCHEMA 'ORACLEUSER1')

Execute the revised DDL statement in a DB2 Command Window, on the DB2 Command Line, or via the DB2 Command Center (which is accessible through the DB2 Control Center).

Creating a CMP entity bean that spans multiple data sources

A particularly interesting aspect of federated DBMS technology involves its ability to present data from multiple remote data sources as though this data were part of a single, locally managed object. Administrators can create views that join or union data from multiple tables (or other data representations) that reside on multiple data servers produced by different vendors. To the EJB programmer, this affords new data modeling opportunities. A single CMP entity bean can easily be built to span multiple data sources. Although such beans are inherently read-only because of view update restrictions that are common to relational DBMSs, they still provide a means of integrating disparate data through standard EJB technology. In this section, we'll discuss how programmers can build such beans in three steps using WSADIE:

Step 1: Create a view based on nicknames

Like any relational DBMS, DB2 enables administrators to create views of data spanning multiple tables. DB2's federated database technology extends the capabilities of views such that they may encompass data from multiple servers stored in different native formats. To build such a view, begin by creating the desired nicknames for your remote data objects. Then use SQL to create a view that joins or unions these nicknames.

In our environment, we used DB2's DDL transparency feature to create tables in Oracle and SQL Server databases and to create nicknames for these tables in our DB2 federated database.

  1. We issued the following statements:
                create table orarest ( 
    	id int primary key not null, 
    	name varchar(20), 
    	cuisine varchar(20), 
    	budget int) 
    	options (remote_server 'ORACLE8', 
    	         remote_schema 'ORACLEUSER1') 
     
               create table msrest ( 
    	id int primary key not null, 
    	name varchar(20), 
    	cuisine varchar(20), 
    	budget int) 
    	options (remote_server 'MSSQL', 
    	         remote_schema 'MSUSER1')

    This caused the following objects to be created:
    • ORAREST table in our remote Oracle database
    • ORAREST nickname in our DB2 federated database
    • MSREST table in our remote MS SQL Server database
    • MSREST nickname in our DB2 federated database.
  2. We created a view that unioned these two nicknames:
    create view multirest (id, name, cuisine, budget) as 
      select id, name, cuisine, budget from orarest 
      union 
      select id, name, cuisine, budget from msrest

    We then used this view as the basis for a CMP entity bean, which is described in the next section.

Step 2: Create a CMP entity bean for the view

After the view is created, you can build a CMP entity bean to represent this data using WSADIE. The process is very similar to the approach outlined in Creating a CMP entity bean for an existing nickname. However, as previously noted, such views are inherently read-only. If you accept all default settings and take no further action, runtime exceptions will occur when the EJB container attempts to execute methods associated with creating, removing, and finding the EJB. All such methods prepare for or attempt to execute database write activities, which are not valid for the types of views we're using. (By default, the generated findByPrimaryKey() method executes a SELECT ... FOR UPDATE, which implies that a write activity may occur in the future. This operation is invalid given the view definition.)

Furthermore, EJB business methods that attempt to set attribute values ("setter" methods) will cause runtime exceptions to occur because they, too, would initiate database write activities. In this section and the next, we'll see how to modify default values through the EJB programming wizard and how to customize generated EJB deployed code to prevent needless database write attempt from occurring and to throw exceptions that more readily explain why certain EJB operations aren't supported given the underlying data model.

To create the CMP entity bean:

  1. Switch to the J2EE perspective. If necessary, create an EJB project for your entity bean following WSADIE's standard process.
  2. Create a CMP entity EJB following the standard process.
    • Give your bean the same name as your nickname.
    • Add attributes to correspond to each of the columns in your nickname, being careful to specify appropriate data types for each and to designate the appropriate attribute as the key field (which should map to the primary key column of the nickname). Again, your attribute names should correspond to your column names.
  3. Invoke the EJB data modeling wizard and elect top-down modeling.
    • Highlight your EJB, right mouse click, Open With -> Mapping Editor. Select top-down modeling.
    • Click Next, and ensure that the database name and schema names are set properly. The database name should map to the federated database known to your DB2 client. (In our environment, this was djdb.) The schema name should map to the authorized federated database user. (In our environment, this was user1.)
    • Uncheck the Generate DDL box, then click Finish.
  4. Verify that your EJB-to-database mapping completed successfully
    • Highlight your EJB, right mouse click, Open With -> Mapping Editor.
    • Inspect the Tasks panel to ensure that no errors have been reported.
  5. Remove all "setter" methods from your bean's remote interface.
    • Expand your EJB in the J2EE panel and highlight the bean's remote interface. The Outline panel will display all methods within the bean's remote interface.
    • Highlight each set...() method, right mouse click, then Delete.
  6. Set the access intent for the EJB's findByPrimaryKey() method to read only.
    • In the J2EE panel, highlight your EJB, right mouse click, Open With -> EJB Extension Editor.
    • In the Methods panel of this editor, expand your EJB to show all methods in the bean's home interface.
    • Highlight the findByPrimaryKey() method, and change the Access Intent value to read-only.
    • Save your changes (Control-S), then close the editor.
  7. Bind your EJB to the appropriate data source you created earlier for your federated database.
    • Highlight your EJB, right mouse click, EJB Quick Links -> Bind Data Source.
    • Enter a valid JNDI name, user name, and password in the Datasource area of the panel. For example, in our test environment, we entered jdbc/Federated as the JNDI name, user1 as the user name, and pass1word as the password.
    • Save your changes (Control-S), then close the editor.>
  8. Generate deployed code for your bean as usual. (Highlight your EJB, right mouse click, Generate Deploy Code.)

Step 3: Modify the generated code

A small portion of the code generated for deployment of your bean must be modified to prevent the create() and remove() methods from attempting to insert and delete data from the view upon which the bean is based. Removing the create() and remove() methods from the bean's home interface isn't acceptable, because the presence of these methods is mandated by the EJB specification. Setting the access intent of these methods to read-only is nonsensical, because they are designed to issue INSERT and DELETE statements. Instead, you should modify the logic of these methods to throw a reasonable exception rather than attempt to write to the database. This section describes which generated methods should be modified and explains how to do so. Note, however, that these methods will need to be modified whenever you generate new deployed code for your bean. There is no way to instruct WSADIE (or WebSphere Application Server) to retain your changes when regenerating the code.

To modify the generated code, follow these steps:

  1. Rewrite the logic of the two remove(...) methods in the stub for your bean's home. This file will be called "_YourBeanNameHome_Stub". For example, we built a bean named MultiRest, so our bean's home stub is _MultiRestHome_Stub. Within this file, there are methods for remove(Object ...) and remove(Handle...). Comment out the implementation code that appears immediately after the methods' signature. Modify the methods' bodies to throw a new RemoveException with a reasonable error message. For example:
    public void remove (Object arg0) throws .... { 
       throw new RemoveException("This EJB is mapped 
       to a view and cannot be removed."); 
       // comment out generated code below 
    	... 
    } 
     
    public void remove (Handle arg0) throws .... { 
       throw new RemoveException("This EJB is mapped 
       to a view and cannot be removed."); 
       // comment out generated code below 
       ... 
    }
  2. Rewrite the logic of the create(...) method in the stub for your bean's home. This file will be called "_YourBeanNameHome_Stub". In our example, it is _MultiRestHome_Stub. (It is the same file that contains the two remove(...) methods discussed earlier.) Comment out the implementation code that appears immediately after the create() method's signature. Modify the method to throw a new CreateException with a reasonable error message. For example:
    public MultiRest create(...) throws ... { 
       throw new CreateException("This EJB is mapped 
       to a view.  New instances cannot be created."); 
       // comment out generated code below 
       ... 
    }
  3. Rewrite the logic of the remove() method in the stub for your bean. This file will be called "_YourBeanName_Stub". For example, we built a bean named MultiRest, so our bean's stub is _MultiRest_Stub. Within this file, there is a remove() method with implementation code that should be commented out and replaced with a reasonable exception. For example:
    public void remove() throws .... { 
       throw new RemoveException("This EJB is mapped 
       to a view and cannot be removed."); 
       // comment out generated code below 
       ... 
    }

Summary

This article, along with two earlier ones, described how federated DBMS and Web application server technologies can be combined to provide Java developers with new options for integrating data from a variety of sources. Potential benefits include the ability to:

  • Extend the reach of existing Web application servers to additional data sources that they don't natively support.
  • Implement new object models, including those in which CMP entity beans span multiple data sources.
  • Simplify development of Java server-side components and Web services that require accessing data from multiple data sources.
  • Minimize the DBMS-related software that must be installed and maintained on the Java development and EJB deployment platforms.
  • Exploit existing Java development tools.

This combination of technologies is best considered when data critical to your applications exists in a variety of data sources and database management skills are available to manage administrative issues.


References and related readings

Useful Web sites

Java tutorials, specifications, and news items:

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=14164
ArticleTitle=Building Entity EJBs that Span Federated Data
publish-date=09172002