Integrating Web Application Server and Multi-Database Server Technologies

Transcription

1 Integrating Web Application Server and Multi-Database Server Technologies C. M. Saracco IBM Santa Teresa Laboratory 555 Bailey Ave. San Jose, CA STL TR January 2000

2

3 Abstract This report describes an exploratory effort at IBM s Santa Teresa Laboratory to expand the reach of Enterprise JavaBeans (EJB) developers through the integration of Web application server and multi-database server technologies. This effort has demonstrated ways in which EJB developers can transparently work with multiple relational DBMSs (from multiple vendors) without installing a variety of client software, establishing direct connections to these data sources, or possessing detailed knowledge about the differences between these data sources. In addition, this effort demonstrated the feasibility of developing a single container-managed entity EJB whose attributes spanned multiple data sources residing on multiple servers. For customers who possess legacy data in multiple DBMSs and want to simplify development and deployment of EJBs that encompass one or more of these data sources, the technologies described in this report may be of help. Specific examples cited in this paper are based on code developed with the following software:! Java JDK 1.1.7b,! VisualAge for Java Enterprise Edition 3.0,! WebSphere Application Server Advanced Edition 3.0,! IBM HTTP Server (based on the Apache server),! DB2 V6.1,! DB2 DataJoiner V2.1,! Oracle DBMS,! Sybase DBMS,! Informix DBMS The author believes many of the benefits associated with integrating multi-database server and Web application server technologies are not confined to EJBs. In particular, those who prefer to include data access routines in their Java servlets or Java Server Pages (JSPs) may also benefit from transparent multi-database access. However, due to resource constraints, this project has focused strictly on data access issues that arise directly through EJB development and deployment, which is the more challenging scenario. Acknowledgments A number of people contributed their technical expertise to this project. In alphabetical order, these include Tu-an Cheng, Stefan Dessloch, Shivakumar Venkataraman, Dan Wolfson, and Dirk Wollscheid. However, any errors or omissions associated with this report are strictly the author s.

4

5 Contents Integrating Multi-Database Server and Web Application Server Technologies Problems Facing E-Commerce Application Developers Overview of a Potential Solution Introduction to Key Technologies Multi-Database Servers Web Application Servers Enterprise JavaBeans (EJBs) Software Architecture Involving WebSphere and DataJoiner DataJoiner Configuration DB2 Configuration IBM HTTP Server Configuration WebSphere Application Server Advanced Edition Configuration VisualAge for Java Configuration CMP Entity Bean Mapped to One Remote Data Source Developing the EJB Testing the EJB Deploying the EJB to WebSphere Advanced Edition CMP Entity Bean Mapped to Multiple Data Sources View-Based Approach Direct Mapping Approach Hierarchy of CMP Entity Beans Mapped to One Remote Data Source Tips for Successful Deployment Summary Bibliography and Related Readings

6

7 Integrating Multi-Database Server and Web Application Server Technologies By C. M. Saracco The increasing popularity of electronic commerce has prompted many firms to turn to application servers to deploy and manage their Web applications effectively. Quite commonly, these application servers are configured to interface with a database management system (DBMS) for storage and retrieval of data. This often means that new Web applications must work with legacy environments. As a result, Web application developers frequently find they have little or no control over which DBMS product is to be used to support their applications or how the database is to be designed. In some cases, developers may even find that data critical to their application is spread across multiple DBMSs developed by different software vendors. Problems Facing E-Commerce Application Developers Such a situation can produce several challenges. Consider a software architecture that calls for the use of Enterprise JavaBeans (EJBs), a component-based technology that has garnered significant interest from the e-commerce community. Entity EJBs are commonly used when persistence is required -- that is, when data associated with Java objects must continue to exist (or persist) beyond the boundaries of an application session. Most frequently, entity EJBs use a relational DBMS for such storage purposes. EJB developers can create one of two kinds of entity EJBs: those with container-managed persistence or those with bean-managed persistence. Container-managed persistence is often favored, as it relieves the bean developer from writing the data access code; instead, the system running the container in which the EJB resides will automatically generate and execute the appropriate SQL as needed. By contrast, entity beans with bean-managed persistence require the developer to code and maintain his/her own data access routines directly. This allows for more flexibility, but requires additional programming skills (such as greater knowledge of DBMS technology), increases labor requirements for bean development and testing, and potentially inhibits portability of the bean itself. Unfortunately, firms intent on using container-managed entity EJBs (hereafter referred to as CMP entity beans) for their e-commerce applications may encounter some stumbling blocks. The firm s Web application server of choice may not support the firm s DBMS of choice. Furthermore, if design requirements call for a CMP entity bean whose attributes must span multiple legacy DBMSs, this almost certainly will not be supported. While workarounds to each of these problems is possible, they can introduce additional headaches, ranging from compromising one s choice of Web application server to undertaking a costly data migration effort or implementing a data replication process that supports very low data latency. 1

8 Overview of a Potential Solution However, another alternative is available that can render such workarounds unnecessary in many cases. This alternative involves supplementing common Web application server technology with multi-database server technology. This report describes a project at IBM s Santa Teresa Laboratory that investigated the feasibility of such an architecture, with promising results. The project integrated a Web application server (in this case, IBM s WebSphere 3.0 Advanced Edition) with a multi-database server (in this case, IBM s DB2 DataJoiner V2.1) to support deployment of CMP entity beans that access multiple data sources. These data sources included locally managed data as well as data stored remotely in Informix, Oracle, and Sybase systems. To simplify development and testing issues, a Java integrated development environment (in this case, IBM s VisualAge for Java 3.0 Enterprise Edition) was used, also in conjunction with the multi-database server. The combination of these technologies afforded the following possibilities:! Automated development and deployment of CMP entity beans, each of which accessed one of the following data sources: Oracle, Sybase, and Informix. Such beans were developed and deployed without installing DBMS client software from Oracle, Sybase, or Informix on the workstation running VisualAge for Java and WebSphere.! Automated development and deployment of a single CMP entity bean whose attributes mapped to a single view that spanned Oracle, Sybase, and Informix tables. Because of the view update problem common to any relational DBMS, such CMP entity beans were developed to be read only.! Automated development and deployment of a single CMP entity bean whose attributes mapped directly to two tables, one managed locally by a DB2 DataJoiner system and the other managed remotely by an Informix system. This bean fully supported read/write activities, with DataJoiner automatically managing the two-phase commit process to ensure the integrity of the underlying transaction when a bean method caused database write activities to occur.! Automated development and deployment of a hierarchy of CMP entity beans whose attributes mapped to a single table managed by any of the following data sources: DB2 DataJoiner, Oracle, Sybase, or Informix. Note that a number of these capabilities are not otherwise available today without the compromises or workarounds alluded to in the previous section (see Current Problems Facing E-Commerce Application Developers ). Specifically, by combining WebSphere and DB2 DataJoiner technologies, EJB developers gain access to a greater variety of data sources. In addition, EJB developers can create and deploy a CMP entity bean that spans multiple databases residing in multiple data sources. 2

9 Furthermore, the benefits realized by combining a Web application server with a multi-database server can be expected to apply to other Java application design options, including other forms of EJBs, Java Server Pages (JSPs), and Java servlets. Programmers who employ these technologies write Java Database Connectivity (JDBC) calls to handle database interactions. A multi-database server can simplify the development task when programmers need to access data stored in multiple DBMSs. This is accomplished by providing a common SQL API, location transparency, and (in some cases) functional compensation. In addition, multi-database joins and unions can be performed without manually connecting to each data source, retrieving necessary data individually from each source, temporarily storing this data in some application-managed data structure, and coding the necessary logic to handle the data integration associated with a join or union operation. Such work is handled automatically by the multi-database server, which presents a single-site image of physically distributed and disparate DBMSs. Of course, as with any software architecture, the one described in this report has its advantages and disadvantages. Major advantages have already been summarized on the previous pages. Perhaps the chief disadvantage of this architecture is the added DBMS administrative complexity. In particular, the use of a multi-database server implies the need for a distributed database environment to be configured and maintained -- an effort best undertaken with staff skilled in database design, database management, and network management. However, for organizations that routinely employ multiple DBMSs to store critical corporate data, such skills are likely to be present anyway. The remainder of this report describes the project in greater technical detail, outlining the software environment and describing the steps necessary to develop and deploy the CMP entity beans discussed previously. However, before delving into such details, this report provides an overview of key technologies for readers unfamiliar with multi-database servers, Web application servers, and EJBs. Introduction to Key Technologies Understanding multi-database servers, Web application servers, and EJBs is critical to understanding subsequent sections in this report. The following sections provide a minimal overview of such topics; more detailed information can be obtained by consulting the references listed in the bibliography. Readers already familiar with these technologies are encouraged to skip this section and begin reading about the Software Architecture employed by this project. Multi-Database Servers A multi-database server, such as IBM s DB2 DataJoiner, provides a single application programming interface (API) to multiple data sources. These data sources may run on different hardware and operating system platforms, may be developed by different vendors, and may employ different native APIs (including different SQL dialects). Programmers use the multi-database server to work at a higher level of abstraction than would otherwise be possible, as the server presents a single-site image of physically disparate data. The use of nicknames for 3

10 tables offers programmers location transparency, eliminating the need for them to know precisely where the desired data resides. Functional compensation can mask differences between different vendors DBMSs and simulate capabilities that aren t natively supported by a given DBMS. Multi-site joins and unions promote integration of data from multiple sources, and two-phase commit processing can guarantee transaction integrity when write operations span multiple DBMSs. A sample multi-database server architecture is shown in the following figure. In this scenario, Java programmers can write JDBC-based applications that connect to the server. This server, in turn, interfaces to data sources supported by different vendors on different platforms. As a result, JDBC applications can reach any or all of these data sources without the application programmer needing to learn the native API of each data source. Furthermore, views can be created to span data across multiple sources to simplify data integration issues for read-only applications. JDBC Application... JDBC Application Common SQL API Multi-Database Server (e.g., DB2 DataJoiner) Oracle Driver DB2 Driver Sybase Driver Native API Oracle DB2 Sybase DBMS DBMS DBMS Sample multi-database server installation, configured for access to 3 different data sources. Data source support and product function can vary from offering to offering. DB2 DataJoiner V2.1, for example, supports all members of the IBM DB2 family, Microsoft SQL Server, Oracle, Oracle RDB, Sybase, Sybase Anywhere, Informix OnLine, and several others (including non-relational DBMSs). In addition, because DB2 DataJoiner is an extended version of the base DB2 product, it is capable of storing and managing its own local data objects, such as tables, views, and indexes. Its optimizer is designed to consider the disparate and physically distributed nature of its environment so that an efficient data access strategy can be selected for each query. 4

11 Web Application Servers Web application servers help firms manage and deploy server-side business logic. This logic, typically written in Java, is often crucial to supporting multi-tiered e-commerce applications. The logic can be expressed through a variety of server-side technologies, including Java Server Pages (JSPs), Java servlets, and EJBs. By planning to run appropriate business logic on the server, firms can help promote code reuse, gain greater security over critical business resources, exploit powerful servers for computationally intensive work, and employ tools to aid with workload balancing, performance tuning, and problem diagnosis. The following figure illustrates a sample Web application server architecture. In this scenario, clients running on a variety of platforms may access a shared application server system. Installed on this platform are both an HTTP Web server (such as the Apache server or the IBM HTTP Server) as well as a Web application server (such as IBM s WebSphere). The Web application server supports various Java-based technologies, such as EJBs, which perform relevant functions in support of client applications. Among these functions may be access to local or remote data sources from a variety of vendors; the configuration illustrates local data source access to one DBMS only. Web Client... Web Client HTTP Web Server (e.g., IBM HTTP Server) Web Application Server (e.g., IBM WebSphere) - EJB support - JSP support - Servlet support Local DBMS (e.g., IBM DB2) Sample Web application server installation, configured with a local DBMS As the reader might expect, capabilities of Web application servers vary from product to product. WebSphere Application Server Advanced Edition was used in this project. It supports servlets, JSPs, EJBs, XML services, access to DB2 or Oracle DBMSs, site usage logging and tracking facilities, and a variety of other functions. 5

12 Enterprise JavaBeans (EJBs) EJBs are server-side software components that conform to specifications developed by Sun Microsystems. These specifications outline a minimal set of behaviors for EJBs, encapsulating business logic in a way that simplifies application development and helps promote portability. EJBs may be accessed directly from client-side Java applications by using RMI/IIOP protocols or may be accessed indirectly from Web clients, which communicate to a Web server via HTTP and invoke a servlet or JSP that in turn accesses the EJB. The following figure illustrates both approaches. Web Client Java Application HTTP RMI/IIOP HTTP Web Server Servlet or JSP RMI/ IIOP EJB Server EJB EJB EJB DBMS Both HTTP-based clients (e.g., Web browsers) and "traditional" Java applications can make use of EJBs. At deployment, EJBs reside in containers that provide a variety of services, most of which won t be discussed in this report. However, we ve already alluded to one critical function that may be managed by containers: support for persistence. Certain kinds of EJBs -- specifically, container-managed entity beans, or CMP beans -- rely on the EJB container to implement and manage access to the target data source. This relieves EJB developers from writing data access routines and can help promote DBMS portability of their beans. WebSphere enables administrators to create multiple containers, each of which may host one or more EJBs. Each container may interface to one EJB server, and WebSphere enables administrators to create multiple such servers. Together, a container/ejb server combination provides such useful services as security, workload management, code generation, and persistence. 6

13 As mentioned earlier, the EJB specification describes multiple types of EJBs. Session EJBs are transient by nature, while entity EJBs are persistent. Session beans themselves can be stateless or stateful, and developers of such beans can employ JDBC for read/write access to supported DBMSs. Indeed, many session beans are written to perform some database operation or transactional work. However, if any data is associated with a session bean it is presumed to be transient; the container provides no automated support for persistence. Entity EJBs, by contrast, are presumed to possess data that is persistent. Developers can manage this persistence themselves (via bean-managed persistence) or they can delegate this responsibility to the container (via container-managed persistence). The different types of EJBs place different coding requirements on EJB developers and imply that minimal services available to clients will differ to some degree. CMP entity beans will be the focus of this report. Each bean of this type will contain several components, 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/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 will uniquely identify each instance of this bean as well as provides methods for creating and manipulating the key. With an integrated development environment such as VisualAge for Java, much of the coding associated with CMP entity beans can be minimized. After developing and testing the bean, developers must set deployment descriptors that govern characteristics such as transaction support, isolation levels, and others. Finally, the bean must be packaged for deployment (in an EJB JAR file) 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. Again, an appropriate Java development environment (such as VisualAge) can be of considerable help for both the test and deployment phases. Software Architecture Involving WebSphere and DataJoiner The software environment used for this project involves multiple products, all of which are generally available. The complete list follows; due to limited machine resources, all software listed prior to DataJoiner was installed on the author s NT 4.0 workstation (which has 256 MB 7

14 RAM and 6 GB hard disk). The remaining products were installed on other machines, typically running AIX.! Java JDK 1.1.7b,! VisualAge for Java Enterprise Edition 3.0,! WebSphere Application Server Advanced Edition 3.0,! IBM HTTP Server (based on the Apache server),! DB2 V6.1 with current fix packs,! DB2 DataJoiner V2.1,! Oracle DBMS,! Sybase DBMS,! Informix DBMS The following figure illustrates key components of this environment and how they interact. Note that DB2 V6.1 was configured to manage WebSphere s administrative data. As we ll discuss, it was also configured to work with DataJoiner, affording VisualAge and WebSphere developers access to functions and data sources supported by DataJoiner. IBM HTTP Server WebSphere Application Server 3.0 EJB deployment VisualAge for Java Enterprise Edition 3.0 EJB test EJBs were developed and deployed on this workstation. DB2 V6.1 DataJoiner V2.1 Oracle Sybase Informix They transparently accessed data stored locally in this DataJoiner system, as well as data stored in these Oracle, Sybase, and Informix systems. Software architecture integrating WebSphere Application Server and DataJoiner for multi-database access. 8

15 DataJoiner Configuration DataJoiner should be installed and configured according to instructions specified in its product manuals. There are few additional steps required to enable VisualAge and WebSphere users to leverage DataJoiner s technology. We ll cover those in a moment. But first, we ll briefly review the basic steps necessary for DataJoiner configuration, in case the reader is unfamiliar with this product. Proper installation and configuration of DataJoiner involves connecting the product to any necessary data sources, such as Oracle, Informix, Sybase, Microsoft SQL Server, and so on. Software prerequisites and the configuration process vary depending on the data sources involved, so this report will not describe the steps in detail. Generally speaking, however, the standard DataJoiner configuration process is as follows:! Create a local database whose catalog will be used to maintain information about remote data sources. (In this project, a SAMPLE database was created for this purpose.)! Install any necessary client software on the DataJoiner server.! Set up network communications.! Identify to DataJoiner on which node the target data source resides.! Update DataJoiner s catalog views to reflect information about the data source as necessary.! Verify that the data source connection is working. If two-phase commit support is necessary, additional configuration steps apply. Again, these vary from data source to data source, so consult the product manuals for details. (Two-phase commit processing is necessary to maintain the integrity of a transaction when changes to multiple data sources are required in a single unit of work. In a later example, this report will describe how this feature of DataJoiner was successfully used to support a CMP entity bean whose attributes mapped to two tables stored in different DBMSs.) However, none of these additional steps is peculiar to working with VisualAge or WebSphere. The DataJoiner system used for this project was configured to access Oracle, Sybase, and Informix DBMSs. The Informix DBMS was further configured for two-phase commit support. As a final step to enable transparent data access, create nicknames for the remote tables to be accessed. Again, this is a standard DataJoiner administrative activity. The CREATE NICKNAME command maps a remote object (such as a table stored in an Oracle database) to a nickname understood to DataJoiner. Thereafter, DataJoiner applications can reference the nickname to access data in the relevant Oracle table rather than manually connecting to the Oracle system (via a SET PASSTHRU statement) and referencing its table directly. Once the standard installation and configuration process is completed (as described above), additional steps are necessary to enable DataJoiner to be accessed as a server from another DB2 instance. As the reader will recall, this distributed database configuration was required to enable VisualAge and WebSphere users to exploit DataJoiner function, including the ability to access a variety of data sources. 9

16 The distributed database configuration process can vary depending on the communication software involved, but the general approach involves modifying entries in the database manager s configuration file via the UPDATE DATABASE MANAGER CONFIGURATION command. Since TCP/IP was used in the author s environment, an appropriate service name and associated port number were specified. This service name will be referenced when configuring the DB2 instance to support distributed database access to DataJoiner. For details on the changing the database manager s configuration to support this, consult the DB2 library (in particular, the DB2 Command Reference). DB2 Configuration DB2 V6.1 should be installed with appropriate fix packs (fix pack 2, as of this writing) according to the standard installation process. Assuming a DataJoiner system has been properly installed and configured as described in the previous section, an administrator must set up a distributed database environment. Again, this work is necessary to enable VisualAge and WebSphere users to exploit the functions of DataJoiner, including transparent access to a variety of data sources. The distributed database configuration process can vary depending on the type of network communications installed. For details, see the DB2 product manuals (in particular, the DB2 Command Reference and its sections on CATALOG commands) or use the Client Configuration Assistant shipped with DB2 as a guide. Since a TCP/IP connection was used in this project between the DB2 and DataJoiner systems, the following steps were necessary:! Add a TCP/IP node entry to the DB2 node directory via the CATALOG TCPIP NODE command. This node entry must reference the services name specified when DataJoiner s database configuration was modified to support distributed database access from this DB2 instance.! Add information about the remote DataJoiner database into the local system database via the CATALOG DATABASE command. Doing so provides DB2 applications with transparent access to the DataJoiner database and, in turn, any remote data sources DataJoiner was configured to support. (In this project, DataJoiner s sample database was known to the local DB2 system as urchin. Thus, a standard JDBC application written to this DB2 system could reference a URL of jdbc:db2:urchin to access the DataJoiner system and, in turn, Oracle, Sybase, and Informix.) Before moving on to EJB development, it s wise to test the DB2-DataJoiner connection. A simple way to do this is:! Invoke the DB2 command line processor.! Attempt to connect to the local database that is mapped to the DataJoiner system. This can be done by issuing a command such as CONNECT TO URCHIN USER CINDY PASSWORD ITSME. 10

17 ! Query remote tables, referencing appropriate nicknames in your SQL statements.! If desired, manually connect to the target data sources (via SET PASSTHRU) and query these same tables directly to compare results.! If necessary, create any additional tables, views, or other objects for your application in the appropriate data source. If these objects must reside on a system other than DB2 or DataJoiner, manually connect to the target data source and issue the appropriate SQL statements. Finally, create DataJoiner nicknames for these tables or views. IBM HTTP Server Configuration Standard product installation and configuration activities are all that s necessary to enable the IBM HTTP Server to function properly in this environment. Consult the product documentation for details. WebSphere Application Server Advanced Edition Configuration WebSphere was installed per standard product instructions, and a local DB2 V6.1 system was identified to store the administrative data. This DB2 system was configured for distributed database access to DataJoiner, as mentioned earlier. (As part of WebSphere s standard installation process, a DB2 configuration parameter was modified and a WebSphere administration database was created.) To enable access to DataJoiner and its data sources, a WebSphere administrator must:! Verify that the HTTP Server is up and running.! Start the WebSphere AdminServer service and open the Administrator s Console.! Create a JDBC Driver following the standard WebSphere process. (Select Types tab -> JDBCDrivers -> Right Mouse Click -> Create...) Specify a reasonable name (e.g., SampleJDBC), select COM.ibm.db2.jdbc.app.DB2Driver as the implementation class, and set JTA enabled to false.! Install the JDBC Driver following the standard WebSphere process. (Select Topology tab -> highlight new JDBC Driver -> Right Mouse Click -> Install.)! Create an appropriate data source following the standard WebSphere process. (Select Types tab -> DataSources -> Right Mouse Click -> Create...) Specify a reasonable name (e.g., DJDataSource). For the database name, specify the name of the DataJoiner-managed database as it was identified to the local DB2 system. For the author s 11

18 environment, this was urchin. Finally, identify the appropriate JDBC driver to be associated with this data source (SampleJDBC, in this case). Note that DataJoiner places no special requirements on the WebSphere configuration process. The steps outlined previously are all required to start WebSphere and enable it to access a supported DBMS. The only item unique to DataJoiner is specified in the last bullet, where the administrator must create at least one data source that references a DataJoiner-managed database rather than just a locally managed DB2 database. VisualAge for Java Configuration After installing VisualAge for Java per the product s instructions, little additional work was necessary to enable EJB development and testing using the distributed database environment supported by DB2 and DataJoiner. Key steps include:! Modify the workspace class path to include the location of the DB2 V6.1 db2java.zip file. This can be accomplished through Window -> Options -> Resources -> Edit workspace class path (specify file location) -> Apply.! Add appropriate features to the workspace. The author s workspace included features for the EJB development, WebSphere testing, and Persistence Builder access. Features can be added via File -> Quick Start -> Features -> Add Feature. Note that both these steps are required to enable EJB development to DB2. DataJoiner places no additional requirements on the VisualAge configuration process. Assuming the DB2 and DataJoiner environments were properly configured, VisualAge development tasks can proceed as usual, and EJBs can be developed to access any data source supported by the DataJoiner system. VisualAge s EJB development wizards and Persistence Builder tools can be of significant help here, guiding programmers through the process and generating much of the necessary code. In most cases, code generated for these CMP entity beans will run successfully without further effort. Exceptions to this rule are discussed later in this report. CMP Entity Bean Mapped to One Remote Data Source With the software environment properly installed and configured, developers can create, test, and deploy EJBs as desired. We ll consider a simple application requirement first: the need to build a single CMP entity bean that maps to a single legacy data source. Perhaps this data source is not directly supported by the intended Web application server, or perhaps the EJB developer lacks the appropriate client software on his/her workstation to directly access the data source. This might be the case for firms who want to minimize costs associated with purchasing, installing, and maintaining many separate DBMS client software licenses (one for each development workstation). 12

19 Our CMP entity bean exercise involved EJBs for Oracle, Sybase, and Informix. In keeping with the legacy data access theme, we created various tables in each DBMS and populated these tables with rows via applications external to our Web development environment. This simulated the notion that critical business data existed in these systems prior to development of our new e-commerce application, forcing the EJB development task to work with a predetermined database design. Such a scenario is not unusual for many e-commerce applications, as they may need to access existing legacy data shared with other corporate applications. For this exercise, we ll consider how to transparently develop a CMP entity bean that maps to a table for tracking data about local restaurants (perhaps in support of an entertainment guide or tourism application). The table s structure is: REST (table name) ID INT (primary key, no nulls) NAME VARCHAR(20) (nulls OK) CUISINE VARCHAR(20) (nulls OK) BUDGET INT (nulls OK) Because the exact SQL syntax for creating such a table varies slightly from DBMS to DBMS, it is not shown here. With the table created and subsequently populated with data, a DataJoiner nickname must be defined to afford transparent access during the development and deployment process of our EJB. Again, this is a standard DataJoiner administrative task and not unique to our e-commerce project. Perhaps the easiest way to create a nickname is through the DB2 command center, an option of the DB2 control center facility. This is because quotations marks must be used around parts of the full table name for certain DBMSs. The following statements were executed from the DB2 command center via its interactive scripting facility: connect to urchin user cindy password itsme create nickname orarest for oracle1.orauser1.rest create nickname sybrest for sybase11. sybuser1. rest create nickname infrest for informix2. infuser1. rest At this point, developers can create EJBs that reference the DataJoiner nicknames just as they would create EJBs that reference local DB2 tables. There are no special considerations or additional steps required. If using VisualAge for Java, the EJB development wizard, Schema Browser, and Map Browser function as usual. To test and deploy the bean in VisualAge for Java s WebSphere Test Environment, ensure that the properties associated with the Persistent Name Server are set to a local DB2 database (sample on our system) and not to a database managed by DataJoiner (such as urchin). In 13

20 addition, set the properties for the EJB Server to the locally mapped DataJoiner database (e.g., urchin). The bean can then be deployed and tested as usual. To deploy the bean in a standalone WebSphere Application Server, follow the standard process. No changes are required due to DataJoiner. Simply ensure that an appropriate JDBC Driver is used as well as an appropriate Data Source (which specifies the locally-mapped DataJoiner database -- urchin -- as the target of persistence for this bean). For readers unfamiliar with VisualAge for Java or WebSphere, the remainder of this section outlines the EJB development and deployment processes for creating a CMP entity bean (SybaseRest) that ultimately relies on the REST table in Sybase for persistence. This fact, of course, is hidden from the EJB developer via the use of DataJoiner and its nickname facility. Developing the EJB The following steps describe one way to create the SybaseRest bean: 1. Create a project for the bean, specifying a relevant name (such as DataJoiner Tests). From the workbench, right mouse click -> Add -> Project. 2. Create a package for the bean, specifying a relevant name (such as sybase). With the DataJoiner Tests project selected on the workbench, right mouse click -> Add -> Package. 3. Define a new EJB Group for the bean, specifying a relevant name (such as SybaseAccess). From the workbench, Select EJB Group Tab -> click on Enterprise Bean pane -> right mouse click -> Add -> EJB Group. Specify the appropriate project for the group (DataJoiner Tests) and create a new group named SybaseAccess. Click Finish. 4. Create the bean in the EJB Group, specifying a relevant name for the bean (such as SybaseRest). Highlight SybaseAccess EJB Group -> right mouse click -> Add -> Enterprise Bean. Specify SybaseRest for the bean name. Select Entity bean with container-managed persistence (CMP) fields for the bean type. Specify the appropriate project and package names (DataJoiner Tests and sybase, respectively). Click Next. Specify CMP fields for all desired table columns as follows: Add -> specify field name -> specify field type -> Finish. For this bean, follow these guidelines: Field Name id name cuisine budget Java Type int java.lang.string java.lang.string. int Key Field yes no no no Access with Getters, Setters yes yes yes yes Promote Getters, Setters to Remote Interface yes yes yes yes 14

21 Click Finish to complete initial phase of CMP entity bean creation. 5. Invoke the Schema Browser. Workspace -> Tools -> Persistence Builder Tools -> Browse Schemas. 6. Create a new schema (SybaseRestSchema) to be used later for mapping the database table to the CMP entity bean. Schemas -> Import/Export schema -> Import schema from database -> SybaseRestSchema. For the connection type, select COM.ibm.db2.jdbc.app.DB2Driver; for the data source, specify jdbc:db2:urchin; for the user ID and password, specify a valid DataJoiner account and password (cindy and itsme, following earlier examples). Test the connection. If successful, click OK. 7. From the Select Tables pane, select the appropriate user ID or qualifier (cindy) and Build Table List. Select the appropriate table from the list (SybRest). Note that the DataJoiner nickname for the Sybase table is displayed and that this table appears to the programmer as though it were a locally managed DB2 table. Click OK. 8. If necessary, fix the broken table associated with the new schema. An error will occur if VisualAge for Java cannot determine which column is the table s primary key. In the Tables pane, select SybRest -> right mouse click -> Edit table -> select ID column -> Select double arrow (>>) to add ID to primary key field -> click OK. Inspect the informational pane to ensure errors are no longer present. 9. Save the schema, specifying the appropriate project, package, and class names. Schemas -> Save Schema -> Project: DataJoiner Tests -> Package: Sybase -> Class: SybaseRestSchema -> Finish. 10. Invoke the Map Browser. Workspace -> Tools -> Persistence Builder Tools -> Browse Maps. 11. Create a new data store map (SybaseRestEJBMap) for the EJB Group. Datastore_Maps -> New EJB Group Map -> Name: SybaseRestEJBMap -> EJB Group: SybaseRest -> Schema: SybaseRestSchema -> OK. 12. Fix validation errors associated with the new map. Highlight SybaseRestEJBMap -> Table_Maps -> New Table Map -> Add Table Map with No Inheritance -> SybRest -> OK. Highlight SybRest in the Table Maps pane -> Edit Property Maps. Complete the mapping of EJB attributes to table columns following these guidelines: Attribute Name id name cuisine budget Map Type simple simple simple simple Table Column id name cuisine budget 15

22 Click OK. 13. Save the map, specifying the appropriate project, package, and class names. Datastore_maps -> Save Datastore Map -> Project: DataJoiner Tests -> Package : sybase -> Class: SybaseRestEJBMap -> Finish. 14. Return to the EJB development window. If desired, instruct VisualAge for Java to generate accessors (getter/setter methods) for your primary key field (ID). Highlight SybaseRestBean in the Types pane -> right mouse click -> Generate -> Accessors -> select id -> set Getter and Setter to public -> OK. Promote these methods to the EJB remote interface so application programmers will be able to make use of them. For each method (getid, setid), Highlight method in members pane -> right mouse click -> Add To -> EJB Remote Interface. 15. Add any business methods desired to the entity bean, and promote these to the remote interface as appropriate. To add a new method, modify the bean class (SybaseRestBean) as appropriate. To work from a method template, highlight bean class -> right mouse click -> Add -> Method. 16. Generate deployed code for the EJB. In the Enterprise Beans pane, highlight the EJB -> right mouse click -> Generate -> Deployed Code. 17. Generate the test client for the EJB. In the Enterprise Beans pane, highlight the EJB -> right mouse click -> Generate -> Test Client. Testing the EJB The following steps describe how to test the newly-created EJB using VisualAge for Java s built-in WebSphere Test Environment: 1. Add the EJB Group to the server configuration for the WebSphere Test Environment. Highlight SybaseAccess EJB Group -> right mouse click -> Add To -> Server Configuration. The EJB Server Configuration window appears. 2. Start the Location Service Daemon. Highlight the daemon -> right mouse click -> Start Server. 3. Configure the Persistent Name Server to access the local DB2 V6.1 system. This author used the sample database in her local DB2 system for VisualAge for Java. The user ID and password for this system were the same as those for the DataJoiner system. Highlight the server -> right mouse click -> Properties -> Data Source: jdbc:db2:sample -> Connection Type: COM.ibm.db2.jdbc.app.DB2Driver -> Database User ID: cindy -> Database Password: itsme -> OK. 4. Start the Persistent Name Server. Highlight the server -> right mouse click -> Start Server. 16

23 The Console window will appear. Wait until the EJServer reports that the Server is open for business before proceeding. 5. Configure the EJB Server to access the DataJoiner-managed database (urchin). Highlight the server -> right mouse click -> Properties -> Data Source: jdbc:db2:urchin -> Connection Type: COM.ibm.db2.jdbc.app.DB2Driver -> Database User ID: cindy -> Database Password: itsme -> OK. 6. To eliminate unnecessary database operations for getter methods, reset the default properties for each of these methods to read only. This prevents WebSphere from needlessly updating rows in the table (performing a store operation for each object) for each SELECT operation (after each getter method is executed). Expand SybaseAccess group in Enterprise Beans pane -> highlight SybaseRest bean -> right mouse click -> Properties. For each getter method, do the following: Select Method tab -> Add -> select one getter method -> check Const Method -> OK. When all getters have been thus modified, click OK. 7. Start the EJB Server. Highlight the server -> right mouse click -> Start Server. Check the Console. Wait until the EJServer reports that the Server is open for business before proceeding. 8. Run the test client to verify your EJB is working properly. Expand SybaseAccess group in Enterprise Beans pane -> highlight SybaseRest bean -> right mouse click -> Run Test Client. Deploying the EJB to WebSphere Advanced Edition (Outside VisualAge) After developing and testing the EJB, deploying it in a production Web application server is the final step. This section describes how the newly-created EJB can be deployed from VisualAge for Java into WebSphere Advanced Edition. 1. Shut down the Persistent Name Server and any EJB Servers active within VisualAge for Java. From the EJB Server Configuration window, highlight the server -> right mouse click -> Stop server. 2. If necessary, start the Web server (such as the IBM HTTP Server) and the WebSphere Admin Server services. Follow the procedure appropriate to your operating system. 3. Start the WebSphere Administrator s Console. Wait until the message WebSphere Administration server open for e-business appears. 4. Ensure that an appropriate JDBCDriver and DataSource have been created. If necessary, refer to the instructions outlined in WebSphere Application Server Advanced Edition Configuration. 5. From VisualAge, export the desired CMP bean (SybaseRest). From the workbench, select EJB tab -> highlight SybaseRest bean -> right mouse click -> Export -> Deployed JAR. Identify an appropriate directory for the export target. A good location is the deployableejbs subdirectory created by WebSphere (in the author s system, this was 17

24 c:\websphere\appserver\deployableejbs). Specify an appropriate name for the JAR, such as SybaseRest.jar. Click Finish. 6. Create the EJB within an appropriate container of WebSphere. From the WebSphere Administrative Console, select Topology tab -> select the appropriate container (e.g., Default Container) -> right mouse click -> Create -> EnterpriseBean. A new window appears with three tabs. Follow these steps to complete the deployment process: - From the General tab, specify an appropriate EJB name (e.g., SybaseRest). For the JAR file, click Browse -> select directory containing JAR file created in previous step -> locate SybaseRest.jar -> double click -> highlight the single item that appears in the window -> Select. The original window is displayed. - Select the DataSource tab -> Change -> Select appropriate data source (e.g., DJDataSource) -> Userid: cindy -> Password: itsme -> Create. Wait for the Console to display a message that the bean was successfully created. 7. Start the server in which the container for your bean resides. From the Topology tab, highlight appropriate server (e.g., Default Server) -> click Green light at top of window. Wait for the Console to display a message that the operation completed successfully. 8. Test the bean in this environment, using your production applications or servlets. For some simple EJBs, you may try to use the test client generated by VisualAge for Java as a starting point. If you do this, start the test client within VisualAge. Do not start the Persistent Name Server or EJB Server processes within VisualAge to do so. The bean should be running successfully in WebSphere, so the test client application should be able to interact with it there. In VisualAge, select EJB tab -> highlight SybaseRest bean -> right mouse click -> Run Test Client. CMP Entity Bean Mapped to Multiple Data Sources A more aggressive technical requirement involves creating a single CMP entity bean whose attributes are stored in multiple databases managed by different DBMSs. Without the use of a multi-database server, doing so may be impossible as most (if not all) EJB development and deployment offerings restrict CMP entity beans to a single database managed by a single data source. However, with a multi-database server such as DataJoiner, EJB developers can accomplish this goal in one of two ways:! create a view of nicknamed tables and map the CMP entity bean to this view.! map the CMP entity bean s attributes directly to nicknamed tables, taking additional steps with VisualAge s Persistence Builder Tools to specify a relationship between the nicknamed tables and create secondary table map(s). 18

25 Each approach has its tradeoffs. Using a DataJoiner view that spans multiple data sources is arguably the simplest approach. However, it implies a functional restriction of read-only access. Therefore, applications using this bean cannot expect to exercise certain standard CMP entity bean operations as such creating new instances, storing updated instances, or removing existing instances. This restriction is tied to the view update problem common to all relational DBMSs; for details on this problem, consult the sources listed in the bibliography on Database-Related References. If a read-only CMP entity bean is not acceptable, VisualAge developers can directly map individual bean attributes to DataJoiner nicknames, each of which may correspond to a different data source. Additional specifications must be made when using the Schema and Map Browsers. In addition, the distributed database environment must be configured to support two-phase commit processing between DataJoiner and the appropriate back-end data sources. The following sections describe each approach in more detail. View-Based Approach This approach calls for a DataJoiner programmer or administrator to create a view of nicknames, each of which maps to tables in different data sources. We ve already seen how to create nicknames in the section on CMP Entity Bean Mapped to One Remote Data Source. Creating a view involves one additional SQL statement. Once this view is defined, EJB programmers perceive it as though it were a single table managed by a single data source. As mentioned previously, database activities must be restricted to read (SELECT) operations. For our example, assume that identical tables for tracking restaurant data have been created in Oracle, Sybase, and Informix systems. Perhaps each of these systems resides in different cities and maintains local restaurant data. The task is to create a single CMP entity bean that presents a global view of this disparate data. This can be accomplished by creating a DataJoiner view that UNIONs data from each of these tables. Referring to the previous section on CMP Entity Bean Mapped to One Remote Data Source, we see that the nicknames ORAREST, SYBREST, and INFREST have been defined for the REST tables managed by Oracle, Sybase, and Informix. To create a DataJoiner view (ALLREST) spanning these tables, issue the following statement: create view allrest (id, name, budget, cuisine) as select id, name, budget, cuisine from orarest union select id, name, budget, cuisine from sybrest union select id, name, budget, cuisine from infrest Now, EJB developers can follow the standard process for creating a CMP entity bean. Finally, a few additional steps should be taken to prevent attempts to generate database write activities, which will fail. Doing so will eliminate the needless database overhead of attempting to execute 19