CHAPTER 8 NOTE TO READER:

Transcription

1 Chap8 Page 602 Thursday, December 9, :50 PM CHAPTER 8 Servlets 604 The Enterprise JavaBeans Framework 613 Java 2 Enterprise Edition 650 Electronic Commerce Server Applications 651 Scaling Multitier Java Applications 654 NOTE TO READER: This chapter is a modified version of the chapter that appears in the book. It has been shortened for placement on the Web site. In instances where text has been removed, brackets and ellipses appear [...]. Also note that figures and page numbers may not be the same as those in the actual book chapter.

2 Chap8 Page 603 Thursday, December 9, :50 PM Server Frameworks and Architectures When Java debuted in 1995, its primary deployment platform was web browsers. Netscape s agreement to embed a Java VM in its version 2.0 browser was a public relations coup for Sun, and provided it with a means to make Java ubiquitous very quickly. A consequence, however, was a perception among programmers and the user community that Java was a client language, and that its main use was for developing user interfaces. If you are reading this book you probably know how inaccurate that picture is. One of Java s great benefits is the ability to develop platform-independent business logic and infrastructure. Yet, for the first two years of Java s existence, there was no universally accepted or robust way of deploying Java applications on servers. This was not due to a lack of support for server protocols. Sun has provided support in the standard Java packages for many Internet communication protocols from early on, and added RMI with Java 1.1. The problem was that there was no accepted standard framework for running Java applications on a server. CORBA provided such a framework, but not all organizations were willing to embrace CORBA just because they were considering Java. Further, Java CORBA implementations had many non-standard features, and suffered from a lack of compatibility. The Enterprise JavaBeans (EJB) specification finally provided the needed framework for deploying Java server applications. An application server supporting EJB can run Java application components and link them together to allow the creation of distributed server applications. Perhaps the most important result of this for Java acceptance was the fact that EJB-compliant application servers removed 603

3 Chap8 Page 604 Thursday, December 9, :50 PM 604 Advanced Java 2 Development for Enterprise Applications the issue of how to install Java on a server. Organizations no longer had to evaluate and choose a Java platform and figure out how to set it up if they wanted to build a server application. Instead, they could evaluate EJB products, which are backed by commercial support and documentation. The issue of Java on the server became moot, and selecting a Java server platform became no more controversial than selecting any other infrastructure product. When this book first appeared, it was the first book to discuss the EJB APIs. At that time, there were only a handful of fledgling products supporting EJB. Since then there has been a remarkable proliferation of Java application servers, nearly all supporting EJB. There are currently around forty such products. This range of choices has given the Java user community a rich set of options, and has greatly accelerated the adoption of Java for enterprise applications. In early 1998, Java server applications were rare, and were executed mainly by more adventurous developers. Today, Java is clearly the way to go for developing open protocol distributed applications on TCP networks. EJB is not the only deployment framework for server side Java. CORBA remains a viable Java server platform, and overlaps EJB in many areas. I will not go further into the CORBA APIs than I already have since there are many good books on that subject. The Java servlet API is another extremely important standard and is supported by many web servers, especially those which come bundled with application servers. The servlet API provides a very convenient and secure framework for creating web server extension programs which can serve dynamically generated HTML, and also can access other network servers such as databases and application servers. Servlets also provide a convenient and comparatively safe gateway for firewalls. Servlets are often used as a web-accessible front end to an EJB back end. The servlet framework includes a facility called JavaServer Pages (JSP), which allows developers to closely couple the specification of generated web content with the business rules for generating that content. This chapter explains the leading server side frameworks for Java application deployment, including servlets, JavaServer Pages, and EJB. At the end, I will try to pull all this together and discuss value-added features of current commercial frameworks and also show how these products can be used to create entire enterprise information systems. Servlets A servlet is a Java-based web server extension program. It is the Java equivalent of native web server extension technologies, such as Microsoft s ISAPI and ASP and Netscape s NSAPI. The main differences are that [...]

4 Chap8 Page 605 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 605 Security Security is no small consideration with any kind of server extension or dynamically invoked program through a web server. CGI is an enormous security hole for administrators, especially ISPs, so much so that many ISPs prohibit CGI programs. [...] Servlets as Gateways to Application Servers Servlets have become an important adjunct to application servers by providing a web-traversible gateway. Many products extend application server features including security, transaction management, and load balancing to the servlet engine, thereby allowing servlets to become the universal gateway to these services. For example, a servlet can authenticate a user and begin a transaction, and have both the user identity and transaction context propagate to the application server when remote Enterprise JavaBeans calls are made. Load balancing of EJB objects can also be provided by servlet modules used to obtain initial references to EJB objects. Load balancing of the servlets themselves can be provided using standard web load balancing techniques, including DNS-based load balancing. Later in this chapter I will discuss these integration issues more fully. For now, let s look at the servlet APIs up close. Invoking a Servlet There are three ways to invoke a servlet.[...] The Servlet Programming Interface You can either extend the abstract class HttpServlet, or implement the Servlet interface directly. You might choose to do the latter if your servlet needs to extend some other class for some reason. The Servlet interface methods are: [...] destroy() In this method you should release all servlet object resources (close database connections, etc.). This is also your last chance to write or commit persistent data, or make final log entries. Example: The Customer Manager Servlet I will demonstrate writing a servlet with a complete example, a small application which has two personalities: a servlet personality, and an RMI server personality. The servlet serves the function of letting web-based users query for information on a customer, and the RMI service allows an administrator to obtain more complete information and update the database. The administrator s user interface is shown in Figure 8-2.[...]

5 Chap8 Page 606 Thursday, December 9, :50 PM 606 Advanced Java 2 Development for Enterprise Applications Testing and Deployment [...] Retrieving GET and POST Data It is a little bit unfortunate but not unbearably inconvenient that the API you use to retrieve query parameters supplied with a GET request is different from the API you use to retrieve POST form parameters. Therefore, an HttpServlet must first determine if the data originates from a GET query or a POST. You can determine this using the HttpServletRequest.getMethod() call, which returns a string indicating the HTTP request method (i.e., GET or POST ). Once you know this, you can call the getquerystring() method for a GET request or the getinput- Stream() method for a POST request, and then call an appropriate parsing method which is again specific to the request method. For example, this code snippet produces a hashtable containing the request data: public void service(httpservletrequest req, HttpServletResponse res) throws ServletException, IOException { // Get the input data int len = req.getcontentlength(); ServletInputStream sis = null; Hashtable data = null; String method = req.getmethod(); if (method.equals("get")) { String q = req.getquerystring(); data = HttpUtils.parseQueryString(q); } else if (method.equals("post")) { sis = req.getinputstream(); data = HttpUtils.parsePostData(len, sis); } if (data == null) System.out.println("data is null"); Multipart POST Content. It is very unfortunate that at the present time, multipart content is not directly supported by the servlet API. If your application needs to supply multipart content to the servlet, you cannot use the parsepostdata() method and you must implement your own routines for parsing the raw posted multipart stream. Multipart content is quite common in many applications. For example, when an HTML form contains an input tag with type="file", the form tag usually specifies enctype="multipart/form-data" causing the form data and the

6 Chap8 Page 607 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 607 attached file to be sent as a multipart stream. This feature permits the use of web pages which allow the user to select a file for upload. The uploaded file is posted as one part of the multipart stream, and the form data itself is posted as the first part. Writing the code to handle multipart content is not hard, but it would be nice if the standard API handled it. Redirection. A servlet can respond to a web client with a location reply, which will cause a browser to redirect itself to the specified location. This is accomplished with the HttpServletResponse.sendRedirect(String url) method. The argument to this method must be an absolute URL. Class Loader Issues Like any Java component environment, a servlet server should generally separate one servlet from another by running it with its own class loader. However, the specification does not require it and many servers (including the Java Web Server 2.0) do not. Therefore it is a good idea not to set properties or use non-final static objects or data in a servlet. The Servlet 2.2 specification, which is still in draft form at this writing, states that servlets should be well-behaved with regard to separation from other servlets, although it does not address class loaders specifically and leaves the implementation up to the server provider. Apparently some server vendors felt that defining the behavior in terms of class loaders was too implementation specific, since some vendors may cache classes across VMs and use other means of keeping session data separate. The exact semantics of session separation is therefore a little bit unclear at this time, but it is likely that servers compliant with Servlet 2.2 will provide the separation between servlets that is needed. State Management HTTP is a stateless protocol, but defines a mechanism called cookies for maintaining state on a client in a way which can be retrieved by a server. There are other techniques which are commonly used, including encoding session state as query parameters in relocation URLs and in URLs that are embedded in content sent back to the client. The HttpSession type is an abstraction of client session persistence. HttpSession abstracts client state so that the servlet does not have to worry which client session persistence technique is used. A cookie is just a set of data, defined by a server, which is stored in the user s browser (if the user so permits). Any data can be stored in a cookie, but usually it is minimal and compact, and only enough to correlate the user with previous transactions the user has performed, and possibly containing user preferences as well. For example, a server might store in your browser a cookie containing a

7 Chap8 Page 608 Thursday, December 9, :50 PM 608 Advanced Java 2 Development for Enterprise Applications unique session ID (which the server creates for you), so that it can keep track of what requests you perform over time. Cookies usually expire, so this state does not persist forever. A cookie may also be set to terminate when the user exists the browser. The user can set whether they want any server to read a cookie, or only the server that set it otherwise, any web site could examine your cookies to tell what other web sites you had visited recently. Cookies do not impact the HTML content or URLs sent back to the browser, and therefore are preferred for maintaining client state. To get the current session, use the Servlet getsession(boolean create) method with an argument of true. This will create a session between your servlet and the user s browser, if one does not already exist, and return the new or preexisting session to you. Most implementations will attempt to use cookies for maintaining session state, and if that fails, use URL encoding. Some servers allow you to specify which technique to use by setting a property or other means. You can associate data with a session by using the HttpServletRequest.getSession(true) to get the session, and then HttpSession.putValue(String name, Object value) to set a value and the HttpSession.getValue(String name) method to retrieve a session value. Also, to ensure that session state is maintained regardless of the session mechanism used, you should call the getsession() method each time the servlet is invoked; otherwise, session state may be lost if URL encoding is being used. The actual session data that the session management system stores in a cookie or encodes in URLs is small, and is typically a session ID of some kind. In general, your servlet should be written to assume that URL encoding is the mechanism used for maintaining session state. In fact, when a browser first invokes a servlet, URL encoding may be used to get the session going and then switch to using cookies. To allow URL encoding to work, you should never manually write URL strings to the output stream for receipt by the browser or for embedding in a web page. Instead, you should pass all written URLs through the encodeurl(string) method to allow the session management system to add any state information it needs. When performing redirects, you should also pass a redirect URL through the encoderedirecturl(string) method. Session objects are stored on the server. Therefore, the session state may be local to the VM maintaining the session. If clustering is provided by the web server, the server must either guarantee that a client session will remain with a particular server during the session s lifetime, or the session object must be made available to the other servers in the cluster. Clustering is usually supported by some kind of

8 Chap8 Page 609 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 609 Note The encodeurl(string) and encoderedirecturl(string) methods replace the similarly named methods encodeurl(string) and encoderedirecturl(string) from earlier releases of the Servlet API. distributed session state management facility, which may even be persistent, allowing for long-term sessions. In designing an application s session state, you need to decide if that information needs to be persistent and durable across system restarts, and if it needs to be transactional. It is a good idea to distinguish clearly between session data and persistent application data, since the latter represents true business data and usually needs to be transactional and durable. Any data which needs to be reliably available across server restarts should probably be incorporated into the application data model explicitly rather than treated as session data. Session data is inherently transient. In fact, a session can go away unpredictably simply by a cookie expiring. Servlet session objects will be reclaimed when the session expires. When Session State Is Large [...] User-Specific Profiles and Authentication If you want to provide user-specific profiles for your application, then you need to have users first log in, and then associate their session with their login profile. To do this, you should first check if the user s session is new, and if it is, redirect them to a login page where they log in, and then store in a database an association between their login ID and their current session. For example, this code checks if the session is new, and if so redirects them to a login page: HttpSession session = request.getsession(true); if (session.isnew()) { response.sendredirect( } else { // Session is preexisting; get its ID and apply profile // based on that. }

9 Chap8 Page 610 Thursday, December 9, :50 PM 610 Advanced Java 2 Development for Enterprise Applications At the login URL, make them provide a user ID and password in a form, which you can retrieve with the parsepostdata() method discussed above. Then call getid() on the session, and store the session ID for later use, and redirect the user back to where they just came from. Note that if your application requires that users log in again after a period of inactivity, you will have to include this in your logic, since isnew() will only return true if there is no session state; if session state is retrieved via a cookie, it will return false. The isnew() method also continues to return false if a session cannot be established for any reason. Alternatively, you can make use of standard HTTP authentication provided by the web server. If the user is authenticated, you can obtain the user ID by calling HttpServletRequest.getRemoteUser(). You should make the call at the entry point to the web site. If you need to make it at more than one point, you can still use the isnew() method to determine if the user has just connected and therefore if you should obtain the user ID. Here is an example of using web authentication to obtain the user ID: HttpSession session = request.getsession(true); if (session.isnew()) { String user = request.getremoteuser(); if (user == null) throw new Exception( Should not happen ); // Set session state to include the user.... } The Servlet 2.2 specification (available as a pre-release draft only at this writing, and so this is subject to change) adds the methods getremoteuserprincipal() and isremoteuserinrole(), analogous to methods of the same name defined in the EJB 1.1 specification. While the getremoteuser() method returns the user ID provided by the user, the getremoteuserprincipal() returns the authenticated Principal which the server identified to correspond to the remote user. Servlet 2.2 compliant servlet engines should unify authentication mechanisms and the getremoteuserprincipal() should always return the user authenticated identity (principal) regardless of how the user is authenticated to the servlet server. For example, if basic authentication (password provided to the browser) is used, the getremoteuserprincipal() method should return the user s Principal, and if certificate-based authentication is used via a user certificate and private key, the getremoteuser() method should also return the user s Principal. Pre-2.2 servers may not be able to return the user ID if certificate-based authentication is

10 Chap8 Page 611 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 611 used; instead a different method must be used to obtain the user identity, as shown below. You should give some thought to how secure you want the session to be. For example, instead of using a password, you could install the servlet on a secure web server and use SSL, and require users to install a personal digital certificate in their browser. In pre-servlet 2.2 (and pre-java 2) servers, a technique supported by some servers for obtaining the user s SSL identity was by getting the attribute javax.net.ssl.peer_certificates with the ServletRequest getattribute() method, which would return an array of javax.security.cert.x509certificate (with the user s certificate first), and could then get the distinguished name of the certificate owner by calling getsubjectdn(). Here is an example: [...] Basic web authentication works by having the web client (browser) send an authorization header to the server. If an authorization header is required but was not sent, the server returns an authorization error, and the browser then sends the header (this is called lazy authentication). Before doing so, the browser may display a dialog box for the user to enter a user ID and password. The web server is not involved in the creation of this dialog box. The Servlet 2.2 specification defines a method of authentication called formbased authentication which uses an HTML form instead of relying on the authentication dialog and protocol built-in to the web client or on the authentication header. Instead, it uses the HTTP POST method and a special server-based program (servlet) for obtaining the posted authentication parameters and submitting them to the web server s authentication service. An HTML form of the following basic kind must be used to utilize this technique. The form can be customized to depict a look and feel appropriate for the application, but its input parameter names and the action field cannot be changed. <form method="post" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> </form> Note that the POST action target is the special j_security_check servlet program. This program is required to be provided by all servlet engines and it provides the form-based authentication service. Reentrancy It is generally a good idea to avoid using multithreading in server business applications, and allow the middleware to manage threading and concurrency. While some middleware component systems such as EJB (discussed later in this chapter)

11 Chap8 Page 612 Thursday, December 9, :50 PM 612 Advanced Java 2 Development for Enterprise Applications disallow multithreading in server applications, some do not, and it is then necessary for the developer to anticipate the effects of concurrent invocations on objects and code. Multiple web clients are allowed to access a servlet object concurrently unless the servlet class implements the SingleThreadModel interface. In that case, the servlet is assumed to not be reentrant and the servlet can be assured that accesses to it will be serialized (guarded) by the server. To prevent other clients that are trying to access the servlet from blocking, it is then necessary for the server to spawn multiple instances of the servlet, possibly maintaining them in a pool. In any system which maintains a resource pool, the system must have a policy for determining to what extent the pooled resources are interchangeable. In the case of a servlet pool, the servlet specification requires that servlets be interchangeable. Therefore, you should not leave client-specific state in a servlet object in any way other than via the HttpSession mechanism. Otherwise, instances of the same servlet will not be interchangeable. Multiple UI Frames and Concurrency It is common for a servlet to be accessed from a multiframe thin-client page, just as it is common for a heavy-client application to have multiple panels or windows. If each page corresponds to a servlet URL, the servlets will be invoked simultaneously when the UI page is shown. Servlet Design One of the most challenging aspects of servlets is deciding how to coordinate the functions of obtaining information and presenting it. Servlets operate in a request/response model, and the state which they can maintain between invocations is limited. Therefore it is best to view each invocation as a separate transaction, which is mostly if not completely self-contained, and which is fully responsible for obtaining and displaying its own data. The application therefore cannot be designed to first build a user interface, and then process user interactions with that user interface: the user interface must be rebuilt each time. This makes it difficult to maintain user interface context, such as the current selected item on a screen, and so on. [...] Mixing and Matching Servlet Servers and EJB Servers Most web application servers come bundled with a web server, which includes a servlet engine. Nevertheless it is often possible to mix and match web server, servlet engine, and EJB server from different sources. For example, you should be able to deploy servlets in a Netscape web server which access Enterprise Java- Beans in a WebLogic EJB server. To go a step further, there are many third-party servlet engines for the Netscape web servers. A popular one is JRunner. Thus, it is

12 Chap8 Page 613 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 613 possible to deploy servlets in a Netscape web server, using a third-party servlet engine, accessing an EJB server of a different brand.[...] Deploying Servlets Prior to Servlet 2.2 there was no standard way to deploy servlets. There was no specification of what could reside in a servlet JAR file, or even if servlets could be deployed as JAR files. There was also no specification stating how servlet codebases were defined, as already mentioned. Nevertheless there have been some de facto standards for deployment and these other aspects of behavior.[...] XML-based Deployment. Sun is making an effort to better define and standardize the way in which Java applications of all kinds are deployed. The Servlet 2.2 draft specification includes an XML definition of a servlet deployment descriptor. The deployment descriptor will be packaged inside of a servlet deployment file, which will be a JAR file, possibly with a.web or.war (WebARchive) extension. [...] Where to Run a Servlet Server An issue that often comes up in application architecture design is where to deploy servlets. In particular, should they be inside the firewall or outside the firewall, and should they be colocated with the application server? [...] JavaServer Pages JavaServer Pages (JSP) is an HTML/Java hybrid language for embedding program commands in a web page. These commands are interpreted by the web server prior to returning content to the client. JSP is the modern Java incarnation of what historically were known as server side includes, which did much the same thing in a more primitive way. While JSP operation can be understood to be interpreted, most implementations will in fact compile portions of a JSP page into one or more runtime objects which can be cached for efficiency. [...] Serving XML. An extremely important aspect of JSP is that it is defined as an XML application. Thus a JSP page can be viewed as an XML document with embedded Java code snippets (escaped using XML syntax) which are evaluated at runtime. JSP can therefore be used to create dynamic templates for generating XML messages.[...] The Enterprise JavaBeans Framework In the previous chapters we saw some of the tremendous practical difficulties in designing and implementing correct multiuser multitier applications. Intuitively, you should feel that these difficulties should not be necessary; somehow, the tools are not right, or are too complicated. After all, all you want to do in most cases is

13 Chap8 Page 614 Thursday, December 9, :50 PM 614 Advanced Java 2 Development for Enterprise Applications get data in and out, in such a way that you don t conflict with what someone else is doing. It should be very simple. Enterprise JavaBeans (EJB) attempts to address these problems by defining a standard architecture for creating multiuser applications based on a three-tier approach. The architecture drastically simplifies the choices the application programmer needs to make, and delegates most of those concerns to an infrastructure layer that is the responsibility of the middleware vendor. The market for middleware is now in a tremendous growth phase, and having a standard architecture that requires interoperability, as the Enterprise JavaBeans framework does, will greatly enhance the value of these products. Client, Server, and Data Resource The EJB model is a three-tier model based on remote method invocation on server objects using RMI. EJB defines an object framework for a set of server object roles and implementations. The model is symmetric, however, in that server objects invoke each other in the same way clients invoke them (i.e., there is no distinction between a local and a remote client). This provides a high degree of object relocatability. (Of course, under the covers, an implementation is free to implement local calls differently, as long as this is transparent to the application.) Client sessions with server objects are either stateless or stateful. A stateful object retains value between transactions (but not necessarily between client connections). If a connection is stateful, the server object can be either persistent (retains value between client connections) or not persistent. A nonpersistent server object is called a session object, and a persistent server object is called an entity object. Entity objects are available to all clients, and a server which provides entity objects in effect provides an object database. Session objects, however, are available only to the client for which they were created, and they do not persist after the client connection is terminated. Even though EJB connections are based on RMI, EJB servers are free to use either RMI s native stream protocol (JRMP), IIOP, or any protocol that can bridge to either of these. This means that EJB objects can interoperate with non-java clients. Many vendors have also developed EJB-based gateways to their server products, including many mainframe-based applications. Transaction Management Transaction management is a central feature of EJB servers, and all EJB servers either provide transaction management or allow the integrated use of an external transaction manager. From an API point of view, transactions are manifested as remote calls. You can either take charge of transaction management in your client or server beans, or

14 Chap8 Page 615 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 615 leave it up to the middleware. The latter is recommended, since that is one of its main advantages. I will assume that unless otherwise specified. [...] Propagation of Transaction Context. An interesting situation arises if an organization has more than one application server, and a bean in one application server needs to access a bean in another application server. If the first bean executes in a transaction context, its call to the second bean in the other server needs to execute in the same context. Therefore, the two servers need to be linked, and the first server must be able to transfer the transaction context to the second server. The ability to transfer or import transaction context is an important feature as an application grows and starts to be used by other departments, and integrated into the infrastructure. Most EJB servers provide this capability, but in different degrees and in different ways. The EJB specification does not require that an EJB server be able to share transaction context with other servers, although it is clear that is a desired and intended feature. The wonderful thing is that if your application does not need transaction context propagation today, you can always change servers later if you do need it without affecting your application design. At most, you may need to import a different RMI package and change some JNDI properties, but the overall application should not need to change. Taking this a step further, you can design applications without worrying about where components are deployed, because the components can operate within the same transaction even if they are redeployed on different servers. Application components are therefore portable, even if they are transactional. This is depicted in Figure 8-1. EJB Server A EJB Server A EJB Server B DB1 DB2 DB1 DB2 Figure 8-1 Applications need not change if components are redeployed for improved efficiency.

15 Chap8 Page 616 Thursday, December 9, :50 PM 616 Advanced Java 2 Development for Enterprise Applications How It Works Let s look at the sequence of events that normally occurs, as depicted in Figure 8-5. When a client wants to use a server service, it first establishes a connection by looking up the container object in some directory service via a JNDI interface, and performing a create(). This creates (or allocates from a pool, if the object is stateless) an instance of the requested enterprise bean. It does not return a reference to this object, however: it creates a server-side proxy, called an EJB Object (an unfortunate name, since everything is an object), and returns a reference to that. The proxy object fields calls from the client, and in turn makes identical calls to the Enterprise JavaBean, which in turn makes identical calls to the actual user-written class that implements the business logic. In addition, the proxy object acts as a checkpoint, and performs checks with the container environment regarding security policies. As you can see, it is the EJB container which actually invokes the Enterprise Java- Beans that you write. The container therefore has the opportunity to perform various actions before it actually makes this invocation, such as identifying your user Principal, what roles your Principal belongs to, and what transaction your call may already be associated with. The container has the job of allocating a thread for the purpose of servicing your request, and then turning the request over to that thread. From that point on, it keeps track of which transaction that thread belongs to. The container also may provide load management services and may provide persistent data resource connection pools. In short, the container provides a protected and managed environment for EJB invocations and performs many of the infrastructure-related housekeeping tasks that you would have to otherwise build into a distributed application.

16 Chap8 Page 617 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 617 RMI/JRMP JNDI provider RMI/IJRMP Stub: EJBHome RMI/JRMP Stub: EJBObject Client* RMI Registry JRMP JRMP JRMP EJB Server Container Create implementation for EJBObject Implementation for EJBHome the container s exposed interface Java EJB Business Object *May be another enterprise bean XAResource TM Figure 8-2 Client and EJB interaction. Data sources JDBC2 or other JTA- Compatible Connection (i.e., exposes an XAResource interface) Session Bean vs. Entity Bean EJB defines two primary kinds of enterprise beans: session beans and entity beans (see Figure 8-2). The difference between a session bean and an entity bean is that an entity bean represents a persistent data item, such as a record in a database. An entity bean instance therefore does not represent a class of items, but represents a particular instance, just as a record is an instance of a row in a relational table. An entity bean instance also has a unique identity, and can be obtained by looking it up using one of its finder methods, just as an indexed row in a relational table can be obtained by performing a query on the value of the index. The lifetime of an entity bean instance is also permanent, and it exists until it is explicitly removed, just as a table row exists until it is deleted. Entity beans provide an object-oriented view of arbitrary data resources, which may be non-object-oriented in actuality. For example, an entity bean facade may be created to represent a relational data resource so that the application can be coded as if the data resource were object oriented. The EJB server may even provide a tool to generate the entity bean layer for relational or other kinds of data resources that it directly supports.

17 Chap8 Page 618 Thursday, December 9, :50 PM 618 Advanced Java 2 Development for Enterprise Applications Exists until Access by multiple clients Obtained by Can be passivated when in a transaction Session Bean Server crashes, container is destroyed, or session is terminated No Creating No Entity Bean Explicitly removed Yes Creating, using Handle, or finding Yes Figure 8-3 Comparison of session and entity JavaBeans. Both kinds of beans can be provided to client applications from instance pools in an EJB server. However, the use of instance pooling is a performance feature, and it is largely transparent to clients. In addition, a session bean can be declared to be stateless, allowing the server greater freedom to reuse the bean instance, but whether the server actually makes use of this freedom depends on the server and is transparent to the application. Beans Are Components Entity beans may be small-grain representations of actual persistent data items. Still, an entity bean is a component not a data item. An entity bean instance represents a runtime proxy for an actual data item, typically a complex data item. If your database table has a million rows in it, there are not a million entity beans there is one entity bean instance for each instance you look up via a findxxx() method, or obtain a reference to by any means. These instances may be reclaimed at any time to conserve resources, which may cause your application to block briefly the next time it tries to access the instance. The conceptual difference between components and persistent data objects is an important one. Data objects represent the actual data, and components provide reusable and portable methods of getting to those objects in convenient ways, as well as operations to perform on them. Even if your database is an object database and the objects themselves provide methods, database objects are not inherently portable and self-contained. It is analogous to the difference between a non-enterprise JavaBean and a simple Java program object. An ordinary JavaBean has additional requirements to allow it to be reusable and redeployable, and its getter and setter methods provide a gateway to any real or virtual attributes managed by the bean. Similarly, Enterprise JavaBeans are reusable and redeployable components for accessing data. Runtime Synchronization An extremely important aspect of Enterprise JavaBeans is that runtime access to methods is automatically synchronized by the EJB container so that a program-

18 Chap8 Page 619 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 619 mer does not have to deal with reentrancy issues. This is a departure from the CORBA models which provide shared object access, but require you to write reentrant code and manually keep track of client-specific state. Bean access synchronization is accomplished without limiting scalability by defining models which support either unshared session-specific state, or shared state which is transactionally managed. These are the session bean and entity bean models respectively. In addition, to support the use of pre-initialized object pools, the model explicitly provides for a special kind of session bean which is declared to not retain state between invocations, thereby allowing it to be pooled after every method call. These bean models will be discussed in greater detail later in this chapter. Deployment EJB 1.0 defined a set of six provider and user roles for enterprise beans. However, the 1.0 specification did not make use of many of these roles, particularly those related to deployment and assembly. The six roles are: 1. Server provider Integrates and provides the core EJB services required by an EJB container. There is no standard interface between an EJB server and an EJB container (the two are effectively synonymous in current products), and so the server provider is currently the same as the container provider. In the future, there may exist a standard interface between an EJB server and an EJB container, making it possible to obtain containers from third parties (e.g., containers which provide entity bean access to specialized data resources); then the server provider and container provider may no longer necessarily be the same party. 2. Container provider Provides an EJB container, which is able to deploy and run enterprise beans with the facilities and APIs required by the EJB specification. The EJB container implements the API seen by an enterprise bean. 3. Bean provider (module developer) Develops an enterprise bean, in accordance with the EJB specification. The bean is packaged in an EJB JAR file, typically with a tool provided by the EJB server provider. The bean provider specifies deployment information in the EJB deployment descriptor, which is also included in the JAR file. EJB 1.0 used a serialized Java object as a deployment descriptor; EJB 1.1 replaces that with an XML format. The Java 2 Enterprise Edition specification refers to this role with the more generic terms module developer and component developer. 4. Application assembler Selects a set of enterprise beans to compose a larger application.

19 Chap8 Page 620 Thursday, December 9, :50 PM 620 Advanced Java 2 Development for Enterprise Applications 5. Application deployer Installs enterprise beans and enterprise beans applications in an EJB server. 6. System administrator Configures the runtime resources and security settings needed by the EJB server to support the EJB services, data resources, and containers. These roles are summarized in Figure 8-4. The EJB 1.0 specification does not define precise boundaries between roles 1 and 2, or between roles 4, 5, and 6. The 1.1 specification clarifies the roles somewhat and addresses some important issues important to server and container builders. An enterprise bean is packaged in a JAR file with a deployment descriptor. An EJB 1.0 deployment descriptor is itself a serialized bean, which is an instance of javax.ejb.deployment.deploymentdescriptor. EJB 1.0 beans had to have a manifest listing each bean s deployment descriptor s serialized file along with the special attribute Enterprise-Bean: True. For example, this manifest section lists the bean MyBean : Name: mypackage/mybeandeploymentdescriptor.ser Enterprise-Bean: True

20 Chap8 Page 621 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 621 Server Provider Builds the application server Container Provider Builds the container which runs in the application server and exposes EJB services and APIs to the application components Component Developer May assemble components into an application as well The result is a highly reusable component, set of components, or applications Application Assembler Selects and configures components to create an end-use application The result is an application unit suitable for deployment in a specific kind of environment or a specific environment Application Deployer Selects and configures applications and components to deploy ( stand up ) an end-use application The result is a fully deployed application users can use Figure 8-4 EJB application lifecycle roles. Application Administrator Monitors and administers the application Makes configuration changes as necessary over time The EJB 1.0 deployment descriptor serialized object contains the deployment attributes, which may apply to the entire enterprise bean, or be specific to particular remote methods. The deployment descriptor contains a security descriptor, method descriptors, a transaction attribute, and an object JNDI name. The security descriptor specifies access rights on a per-user basis. The deployment descriptor may have a set of method descriptors, which specify a security descriptor and transaction attribute on a method-specific basis. EJB 1.1 deprecates this representation and replaces it with an XML representation, which is discussed below. In addition, EJB 1.1 no longer uses the manifest to identify beans, but instead identifies them from the XML deployment descriptor syntax, which must be stored in the META-INF directory in the JAR file and have the name ejb-jar.xml.

21 Chap8 Page 622 Thursday, December 9, :50 PM 622 Advanced Java 2 Development for Enterprise Applications An EJB server registers an enterprise bean via JNDI, using the object name obtained from the deployment descriptor. This provides object location independence, because other beans can find the object simply by using the JNDI API. EJB 1.0 Deployment Descriptors. EJB 1.0 defines these attributes for bean deployment descriptors: Name beanhomename The JNDI Name to use for this bean. (The environment may prefix the name with other path information.) String enterprisebeanclassname The full name of the enterprise bean class i.e., the business class. String homeinterfaceclassname The full name of the bean s Home interface. String remoteinterfaceclassname The full name of the bean s remote interface. boolean reentrant If true, multiple concurrent calls to the same bean instance are permitted. This is necessary for beans that require recursion or which are called back by the beans they call. Use with care, because this capability disables many safeguards, particularly the container s concurrency control mechanisms. This can be set to true only for entity beans. Properties environmentproperties The customizable properties, with default values, that the administrator may set when the bean is deployed. AccessControlEntry[] Method method The bean method this access control entry applies to, or null if it applies to the entire bean. Identity[] allowedidentities The identities that are permitted to invoke the method (or the bean if method is null). ControlDescriptor[] Each enterprise bean method may have a control descriptor. It includes the following: Method method The method the descriptor applies to, or null if the descriptor applies to the entire bean. int runasmode One of: CLIENT_IDENTITY Use the identity of the client invoking the method. SYSTEM_IDENTITY Use a privileged account. The actual account used is determined in a product-specific way. SPECIFIED_IDENTITY Use the identity specified in the runasidentity property (see below). Identity runasidentity Use this identity, if the runasmode is set to SPECIFIED_IDENTITY.

22 Chap8 Page 623 Thursday, December 9, :50 PM Chapter 8 Server Frameworks and Architectures 623 int transactionattribute One of: TX_BEAN_MANAGED The bean uses JTA to manage transactions itself. It can obtain the current JTA transaction by using EJB- Context.getCurrentTransaction(). TX_MANDATORY If the client is not in a transaction when the bean is called, an exception will be thrown. TX_NOT_SUPPORTED The bean must not be invoked within a transaction. TX_REQUIRED The EJB server starts a transaction for each method invocation (and commits on return), unless one is already in progress for that client. TX_REQUIRES_NEW The EJB server always creates a new transaction for the call. If the client was already in a transaction, that transaction is temporarily disassociated from the caller s thread until the new call (and new transaction) completes. TX_SUPPORTS The call executes in the context of the client's transaction, if there is one; otherwise it executes without a transaction. int isolationlevel One of the following. These have the meanings defined in JDBC. TRANSACTION_READ_COMMITTED TRANSACTION_READ_UNCOMMITTED TRANSACTION_REPEATABLE_READ TRANSACTION_SERIALIZABLE Session bean descriptors have these additional attributes: int sessiontimeout A container may destroy a session bean after an inactive period set by this timeout (value is in seconds). A value of zero means a default value should be used. int statemanagementtype One of: STATEFUL_SESSION The bean is assumed to retain a modified state after an invocation returns, preventing the bean from being shared with other clients that request a bean of the same kind. STATELESS_SESSION The container can assume that the bean does not retain state across invocations, and that the bean may therefore be pooled. It also assumes the bean as a zero-argument create() method.

23 Chap8 Page 624 Thursday, December 9, :50 PM 624 Advanced Java 2 Development for Enterprise Applications Entity bean descriptors have these additional attributes: String primarykeyclassname The full name of the class that is used to represent the entity bean s primary key value. Field[] containermanagedfields The specified fields are to be made persistent by the container. The bean makes sure to set the values of these fields during bean initialization, in its ejbcreate() method. It should be noted that when referring to a session bean deployed as STATEFUL_SESSION, the term stateless refers more to the bean s reusability than to whether or not it actually contains state. Session beans are identified as stateless only so that the server can economize on its creation of new session bean instances. If a bean can be returned to a pool of session bean instances, and used for calls by additional clients without those clients being able to detect that the bean has already been used, then the bean is considered to be stateless, even if the bean maintains a resource connection. EJB 1.1 Deployment Descriptors. The EJB 1.1 deployment descriptor uses XML syntax, and its overall structure is shown Figure 8-5. It has three main parts: a header consisting of descriptive information, an enterprise-beans section which lists bean definitions, and an assembly-descriptor section which adds information related to access control and transaction control. <ejb-jar> <description>...text...</description> optional <display-name> name to be displayed by tools... </display-name> <small-icon> relative pathname of a 16x16.jpg or.gif... </small-icon> <large-icon> relative pathname of a 32X32.jpg or.gif... </large-icon> <enterprise-beans> <session> one or more <session> and/or <entity> definitions see below... </session> optional optional optional <entity> </entity> </enterprise-beans> <assembly-descriptor> see below... </assembly-descriptor> </ejb-jar> see below... optional Figure 8-5 EJB 1.1 deployment descriptor structure.