Chapt er 19:Accessing XML Documents Using SQL -501 - cNum = rs.getString("CUSTOMER_NUMBER"); fName = rs.getString("FIRST_NAME"); lName = rs.getString("LAST_NAME"); street = rs.getString("STREET"); city = rs.getString("CITY"); state = rs.getString("STATE"); zip = rs.getString("ZIP"); phone = rs.getString("PHONE"); }catch (Exception e){ System.out.println(e); } } public static void serializeDocumentAsFile(Document xmlDoc,String UrlString){ String fileName = "XMLOut.xml"; try { URL url = new URL(UrlString); if(url.getProtocol().equals("file")){ fileName = url.getFile().substring(1); } OutputFormat fmt = new OutputFormat("xml",null,true); XMLSerializer serializer = new XMLSerializer(new FileWriter(fileName),fmt); serializer.asDOMSerializer().serialize(xmlDoc); } catch (Exception e){ e.printStackTrace(); } } } This test code creates the XML database shown in Listing 19-13. The createTable() method creates the XML document and inserts the first record. Calling the updateTable() method results in the insertion of the other records. Listing 19-13: XML database created using XMLDBTest class <?xml version="1.0"?> <CustomerDB> <CUSTOMER CUSTOMER_NUMBER="100"> <FIRST_NAME>Michael</FIRST_NAME> <MI>A</MI> <LAST_NAME>Corleone</LAST_NAME> <STREET>123 Pine</STREET> TEAMFLY Team-Fly ® Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapt er 19:Accessing XML Documents Using SQL -502 - <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> <PHONE>201-555-1212</PHONE> </CUSTOMER> <CUSTOMER CUSTOMER_NUMBER="101"> <FIRST_NAME>Vito</FIRST_NAME> <MI>Q</MI> <LAST_NAME>Corleone</LAST_NAME> <STREET>137 Main</STREET> <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> <PHONE>201-555-1213</PHONE> </CUSTOMER> <CUSTOMER CUSTOMER_NUMBER="102"> <FIRST_NAME>James</FIRST_NAME> <MI>J</MI> <LAST_NAME>Corleone</LAST_NAME> <STREET>123 Pine</STREET> <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> <PHONE>201-555-1214</PHONE> </CUSTOMER> <CUSTOMER CUSTOMER_NUMBER="103"> <FIRST_NAME>Raquel</FIRST_NAME> <MI>S</MI> <LAST_NAME>Corleone</LAST_NAME> <STREET>123 Pine</STREET> <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> <PHONE>201-555-1215</PHONE> </CUSTOMER> <CUSTOMER CUSTOMER_NUMBER="104"> <FIRST_NAME>James</FIRST_NAME> <MI>J</MI> <LAST_NAME>Witherspoon</LAST_NAME> <STREET>17 Oak</STREET> <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapt er 19:Accessing XML Documents Using SQL -503 - <PHONE>201-555-1216</PHONE> </CUSTOMER> <CUSTOMER CUSTOMER_NUMBER="105"> <FIRST_NAME>Fred</FIRST_NAME> <MI>Q</MI> <LAST_NAME>Bloggs</LAST_NAME> <STREET>22 Walnut</STREET> <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> <PHONE>201-555-1217</PHONE> </CUSTOMER> </CustomerDB> Note that although the SQL CREATE command specifies type VARCHAR (30) for most of the fields, this type specification defaults to String. The reason for this is that all data is stored as a String, and the only significance attached to data type is to check for the custom type ATTRIBUTE, which is used to denote that the field should be added to the row element as an attribute. Note also that the XML document must be saved after each update. The XML database actually exists as a DOM document in memory, so it must be serialized after changes are made. Tests are carried out using a variety of different queries. These queries include the following: SELECT * FROM CUSTOMER SELECT * FROM CUSTOMER WHERE FIRST_NAME LIKE 'M%' SELECT * FROM CUSTOMER WHERE FIRST_NAME NOT LIKE 'M%' SELECT * FROM CUSTOMER WHERE FIRST_NAME NOT = 'Michael' SELECT * FROM CUSTOMER WHERE FIRST_NAME <> 'Michael' SELECT * FROM CUSTOMER WHERE FIRST_NAME LIKE 'M%' OR FIRST_NAME LIKE 'F%' SELECT * FROM CUSTOMER WHERE (FIRST_NAME LIKE 'M%' OR FIRST_NAME LIKE 'V%') SELECT * FROM CUSTOMER WHERE ( FIRST_NAME LIKE 'M%' OR CUSTOMER_NUMBER = '102' ) In addition to supporting the ResultSet.getString() method used to set the String variables in Listing 19-12, the XMLResultSet can also be retrieved as an XML document. Listing 19-14 shows the XMLResultSet generated by running this query: SELECT * FROM CUSTOMER WHERE ( FIRST_NAME LIKE 'M%' OR CUSTOMER_NUMBER = '102' ) AND LAST_NAME = 'Corleone' Listing 19-14: XMLResultSet <?xml version="1.0"?> <RESULTSET> <CUSTOMER CUSTOMER_NUMBER="100"> <FIRST_NAME>Michael</FIRST_NAME> <MI>A</MI> <LAST_NAME>Corleone</LAST_NAME> Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapt er 19:Accessing XML Documents Using SQL -504 - <STREET>123 Pine</STREET> <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> <PHONE>201-555-1212</PHONE> </CUSTOMER> <CUSTOMER CUSTOMER_NUMBER="102"> <FIRST_NAME>James</FIRST_NAME> <MI>J</MI> <LAST_NAME>Corleone</LAST_NAME> <STREET>123 Pine</STREET> <CITY>New York</CITY> <STATE>NY</STATE> <ZIP>10006</ZIP> <PHONE>201-555-1214</PHONE> </CUSTOMER> </RESULTSET> The advantage of returning the entire XMLResultSet as an XML document is that many applications are designed to work with XML. In this form, the XMLResultSet can be transferred between applications or manipulated using an XSL transform. Since the target database is defined by a URL, you are not restricted to using local XML files as databases. Try substituting the URL http://www.moreover.com/cgi- local/page?o=xml&query=top+stories. Cross- Reference Chapter 17 discusses working with XML sources over the Internet.The examples are based on accessing the http://www.moreover.com/ Web site. Summary In this chapter, you learn to create a JDBC driver and a simple SQL engine. The examples can be expanded and modified to form the basis of any custom application requiring a JDBC API. The main topics covered included the following: § Detailed operation of a JDBC driver § A simple, String-oriented SQL query engine § Examples of working with XML documents This chapter ends Part IV. Part V explores persistence in the context of Enterprise Java Beans and JDO. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part V:EJBS, Databases, and Persistence -505- Part V: EJBs, Databases, and Persistence Chapter List Chapter 20: Enterprise JavaBeans Chapter 21: Bean-Managed Persistence Chapter 22: Container-Managed Persistence Chapter 23: Java Data Objects and Persistence Part Overview Part V is a discussion of the use databases in the context of J2EE applications using Enterprise JavaBeans. The first chapter gives a brief overview of Enterprise JavaBeans, including descriptions of: § The three types of Enterprise JavaBeans: session beans, entity beans, and message-driven beans. § Activation and passivation § Bean-managed persistence and container-managed persistence § Enterprise JavaBean transactions After reading this chapter, you should have a good understanding of Enterprise JavaBeans and of the ways they interact with databases. Subsequent chapters discuss bean-managed persistence and container-managed persistence, with extensive examples. They include sections on the use of JDBC and SQL in bean-managed persistence and of the Enterprise JavaBean query language (EJBQL). The final chapter in Part V covers Java data objects and transparent persistence. This is a new technology that handles persistence in a manner that is completely transparent to the developer. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 20:Enterprise JavaBeans -506 - Chapter 20: Enterprise JavaBeans In This Chapter This chapter gives a brief overview of Enterprise JavaBeans (EJBs). The features and purposes of three types of EJBs are discussed. The fundamentals of transaction and persistence management are reviewed. After reading this chapter, you should have a good understanding of Enterprise JavaBeans (EJBs) and of the ways they interact with databases. Enterprise JavaBeans Overview The Enterprise JavaBeans Specification defines EJBs as follows: "Enterprise JavaBeans is an architecture for component-based distributed computing. EJBs are components of the distributed transaction-oriented enterprise applications." In a nutshell, EJBs are server-side components that encapsulate the business logic of an application. The business logic is the code that fulfills the purpose of the application. For example, in an online shopping application, the EJBs might implement the business logic in methods called searchCatalog and checkOut. By invoking these methods, remote clients can access the online shopping services the application provides. An EJB typically communicates with Enterprise Information Systems (EIS) such as databases and legacy systems and other EJBs. At the same time, different types of clients access EJBs requesting services. The clients can be other EJBs, Web applications, servlets, or application clients. At runtime, an EJB resides in an EJB container. An EJB container provides the deployment and runtime environment for EJBs, including services such as security, transaction, deployment, concurrency management, and instance life-cycle management. The process of installing an EJB in an EJB container is called EJB deployment. EJB containers are typically part of an application server. EJBs by nature are portable components; therefore, the application assembler can build new applications from existing beans with minimum effort. These applications can run on any J2EE-compliant application servers. EJBs are designed to simplify the development of large, distributed applications. Because the EJB container provides system-level services to enterprise beans, the bean developer can concentrate on solving business problems. The EJB container, not the bean developer, is responsible for system-level services such as transaction management and security authorization. Furthermore, since the application's business logic is contained in EJBs instead of in clients, client developers can focus on the presentation of the client. The client developer does not have to code the routines that implement business rules or access databases. As a result, clients are thinner. This is particularly beneficial for clients that run on small devices such as cell phones or PDAs. EJBs are especially suitable for applications that have the following requirements and characteristics: § Scalablability. To accommodate a growing number of users, one may need to distribute an application's components across multiple machines. Not only can the EJBs of an application run on different machines, but their location remains transparent to clients. § Transactions-oriented. EJBs support transactions through container services, the mechanisms that manage the concurrent access of shared objects and ensure data integrity. § Multiple types of clients. With just a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous. The EJB 2.0 Specification specifies the three following types of EJBs: § Session beans § Entity beans § Message-driven beans The features, as well as the appropriate uses of each type of EJB, are discussed in more details in the following sections. Session Beans Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 20:Enterprise JavaBeans -507 - A session bean represents a single client inside the J2EE server and performs tasks on behalf of the client. This type of bean manages sessions (or conversations between the client and the server) on behalf of the client. A typical session is transient, and its state is usually not persistent. An example of a session is tracking your courier package using a Web-based status-query application. If, for some reason, the Web server dies or the session times out, the session terminates, and the user is required to start a new session. Most online transactions are session oriented, with the user initiating a session performing a set of actions and then terminating a session. Hence, a session bean generally stores its state in transient variables. Not all sessions are conversational. Some sessions involve only one interaction between the client and server. For example, getting a stock quote does not need the multiple invocations of the service the stock-quote server provides. These sessions are stateless, and their management can be significantly simplified. To address these different scenarios, the EJB specification specifies two types of session beans: stateful and session. In general, the use a session bean is appropriate if the following circumstances hold: § At any given time, only one client has access to the bean instance. § The state of the bean is not persistent, existing only for a short period (perhaps a few hours). Once the session bean is chosen, we still need to decide which one to use, stateless or stateful, based on whether a conversational state needs to be held in the session bean. Stateless Session Beans Stateless session beans are components that implement a single-use service. That service can be invoked many times, but since the component does not maintain any state, the effect is that each invocation provides a single use. In a lot of ways, stateless session beans provide a reusable single-use service. Although a stateless session bean does not maintain a conversational state for a particular client, it may contain a transient state in the form of its instance variables, as shown in the code example. When a client invokes the method of a stateless bean, the values of the bean's instance variables represent such a transient state but only for the duration of the invocation. When the method is finished, the state is no longer retained. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. Most of application servers take advantage of this feature and pool the stateless session beans to achieve better performance. Because stateless session beans can support multiple clients and usually are pooled in the EJB container, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients. At times, the EJB container may write a stateful session bean to secondary storage (called passivation, discussed later). However, stateless session beans are never written to secondary storage. This further makes stateless beans offer better performance than stateful beans. The major advantage of stateless session beans over stateful session beans is performance. A stateless session bean should be chosen if one of following is true: § The bean's state has no data for a specific client. § In a single-method invocation, the bean performs a generic task for all clients. For example, you might use a stateless session bean to retrieve stock quotes at any time. § The bean fetches from a database a set of read-only data that is often used by clients. Such a bean, for example, can retrieve the table rows that represent the inventory that currently below certain level. In general, the steps for developing EJBs include: 1. Write the remote interface. 2. Write the home interface. 3. Write the EJB implementation class. 4. Compile the EJB and all its supporting files. 5. Write the deployment descriptors. 6. Package and deploy. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 20:Enterprise JavaBeans -508- Note Many of the preceding steps can be performed automatically by a variety of IDEs. Don't write everything from scratch. Although your favorite IDE may complete many steps for you, let's go through these steps manually in the development of our stateless session bean example. To keep things less confusing, a naming convention should be adopted for all the Java classes involved. A commonly accepted naming convention is listed in Table 20-1. Table 20-1: EJB Name Convention Item Name Example Remote Interface <name> Customer Home Interface <name>Home CustomerHome Implementation Class <name>Bean CustomerBean EJB Name <name>EJB CustomerEJB EJB Jar Display Name <name>Jar CustomerJar Remember the first program you have ever written in Java? Is it the "Hello, world"? The first EJB example developed in this chapter is a stateless session bean called HelloEJB. When it is invoked, a welcome message is delivered to the calling client. Although the business logic is defined in the implementation class, the client can never directly access implementation-class instances. Instead, the client calls an EJB's remote interface to get its service. In other words, the remote interface defines the business methods that a remote client may invoke. The bean developer defines the types of the method arguments, the return type, and the exceptions the methods throw. The signatures of these methods must be identical to the signatures of the corresponding methods in the EJB implementation class. Remote interface Every EJB remote interface extends the java.ejb.EJBObject interface. Since EJBs are meant to work in a distributed system, the remote interface is a valid remote interface for RMI-IIOP, so each method must throw the java.rmi.RemoteException. The source code for the HelloEJB remote interface is shown in Listing 20-1. Three methods are defined by which a client can get all welcome messages, a specific welcome message, or the number of messages. Listing 20-1: Remote interface of HelloEJB package java_database.ch20.HelloSLBean; import javax.ejb.*; import java.rmi.RemoteException; public interface Hello extends EJBObject { public String[] getAllWelcomeMsgs() throws RemoteException; public String getWelcomeMsg(int i) throws RemoteException; public int getNumberOfWelcomeMsgs() throws RemoteException; } Home interface Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 20:Enterprise JavaBeans -509 - The home interface controls the life cycle of the EJB objects. For a session bean, the purpose of the home interface is to define the create methods that a remote client may invoke to create its reference to the EJB object. You may define multiple create methods with different signatures. The default method without any argument is used to instantiate EJB objects in the container. Note that create methods are different from constructors. A constructor is an initializer for an object (which may exist for a very long time). A create method is used by clients to initialize an EJB instance in an EJB container. An EJB instance may be composed of one object or a variety of objects over its life cycle. As such, it has different initialization mechanisms. Understanding the life cycle is critical in mastering EJBs. Unfortunately, that is beyond the scope of this book. The interested reader can find extensive discussions on EJB life cycles in numerous EJB books. Note Do not assume that create methods are the same as constructors. As is the case for the remote interface, the signatures of the create methods defined in the home interface must correspond to those of its corresponding ejbCreate methods in the implementation class. The throws clause of the create method must include java.rmi.RemoteException and the javax.ejb.CreateException. The home interface of the HelloEJB is shown in Listing 20-2. Only one create method is defined in this example. Listing 20-2: Home interface of HelloEJB package java_database.ch20.HelloSLBean; import javax.ejb.*; import java.rmi.RemoteException; public interface HelloHome extends EJBHome { public Hello create() throws CreateException, RemoteException; } Implementation class Most of the work that you have to do as a bean developer occurs in the bean class itself. There are a number of methods the bean class must provide. An important method, and perhaps the most confusing one, is ejbCreate. Because an enterprise bean runs inside an EJB container, a client cannot directly instantiate the bean. Only the EJB container can instantiate an enterprise bean. During instantiation, the example program performs the following steps: 1. The client invokes a create method on the home object 2. The EJB container instantiates the EJB instance. 3. The EJB container invokes the appropriate ejbCreate method in the implementation class; typically, an ejbCreate method initializes the state of the EJB instance. create and ejbCreate method guidelines Typically, an ejbCreate method initializes the state of the EJB instance. The guidelines for writing such methods are: § Each create method defined in the home interface must have a corresponding ejbCreate method in the bean-implementation class. § The number of arguments and argument data types between the ejbCreate and the corresponding create methods must be the same. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 20:Enterprise JavaBeans -510- § Since the ejbCreate is called by the container, there is nothing to return so its return type is void. § The create method returns the remote interface. The bean class extends the java.ejb.SessionBean interface, which declares the ejbRemove, ejbActivate, ejbPassivate, and setSessionContext methods. The HelloBean class does not use these methods, but it must implement them (as empty functions). Later sections on stateful session beans and entity beans explain the use of these methods. EJBExceptions The primary purpose of a session bean is to run business tasks for the client. The client invokes business methods on the remote object reference that the create method returns. From the client's perspective, the business methods appear to run locally, although they actually run remotely in the application server's EJB container. All the business methods declared in the remote interface need to be implemented. The signatures of these business methods are the same as those defined in the remote interface. However, since the bean object is running inside of the container, it does not need to throw the java.rmi.RemoteException. To indicate a system-level problem, such as the inability to connect to a database, a business method should throw javax.ejb.EJBException. When a business method throws an EJBException, the container wraps it in a RemoteException, which is caught by the client. Since EJBException is a subclass of RuntimeException, you do not need to explicitly include it in the throws clause of the business method. The HelloBean class is shown in Listing 20-3. It should be noted that the method getWelcomeMsg(int) is coded defensively to prevent the index from going out of range. Listing 20-3: HelloBean class package java_database.ch20.HelloSLBean; import javax.ejb.*; import java.util.*; public class HelloBean implements SessionBean { // instance variables private SessionContext ctx; private String[] msgList = new String[3]; // default constructor – different from ejbCreate() public HelloEJBBean() { } // Life cycle methods called by EJB container public void setSessionContext(SessionContext c) { System.out.println("setSessionContext called."); ctx = c; } public void ejbCreate() { System.out.println ("ejbCreate() called."); Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... @version: 1.0 */ package java_ database. YachtSessionSFBean; import javax.ejb.*; import java. rmi.*; import java. util.*; import javax.naming.*; import java_ database. common.*; -516- Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 20:Enterprise JavaBeans import java_ database. YachtEBean.*; import java_ database. MemberEBean.*; public class YachtSessionBean implements SessionBean,... /** YachtSessionEJB YachtSessionEJB * @author: Andrew Yang * @version: 1.0 */ package java_ database. YachtSessionSFBean; -515- Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark Chapter 20:Enterprise JavaBeans import javax.ejb.*; import java. rmi.*; import java_ database. common.*; import java_ database. MemberEBean.*; public interface YachtSession extends EJBObject { public void... package java_ database. YachtSessionSFBean; import javax.ejb.*; import java. rmi.*; import java_ database. YachtEBean.*; public interface YachtSessionHome extends EJBHome { public YachtSession create(Yacht yacht) throws CreateException, RemoteException; } Listing 20-7: YachtSessionEJB implementation class /** YachtSessionEJB Implementation Class * @author: Andrew Yang * @version: 1.0 */ package java_ database. YachtSessionSFBean;... msgList.length; } } Where is the database- access code? After all, this is a book on Java database programming Since EJB itself is complex enough, I have deliberately kept the first EJB example as simple as possible (the spirit of the HelloWorld example) As soon as you have this piece of code running, you can easily extend it to fulfill your needs, such as accessing databases using the JDBC programming skills you... Split-Merge on www.verypdf.com to remove this watermark Chapter 20:Enterprise JavaBeans from going out of range, so there is always a welcome message returned for any integers passed into the method Figure 20-1: Test output after the JSP client shown in Listing 20-5 Listing 20-5: JSP client . */ package java_ database. YachtSessionSFBean; import javax.ejb.*; import java. rmi.*; import java. util.*; import javax.naming.*; import java_ database. common.*;. Andrew Yang * @version: 1.0 */ package java_ database. YachtSessionSFBean; import javax.ejb.*; import java. rmi.*; import java_ database. YachtEBean.*; public interface