WAS J2EE Functions ”Servlets, JSPs, and EJBs The IBM WebSphere Application Server product at its core implements the Java 2 Enterprise Edition (J2EE) technologies of servlets, Java Server Pages (JSPs), and Enterprise Java Beans (EJBs). These three principal J2EE technologies are the foundation upon which large-scale distributed and high-performance Web-enabled applications can be built. With the addition of Web services technology, WAS stands as a premier platform for providing Web-based applications. NOTE In WebSphere Application Server, EJBs are executed by the EJB (Enterprise Java Beans) container, and servlets and JavaServer Pages files are executed by the Web container.
Servlets J2EE servlets can be viewed as small Java programs running on the Web server side of a Web browser to server interaction. Servlets handle a browser request, formulate the response, and convey the response back to the browser. More technically, servlets consist of Java objects invoked by the Web application server. (Servlets execute as threads under the Java Virtual Machine established for the application server, referred to as the "servlet container.") The servlet object accepts and validates an HTTP request and formulates an HTTP response message, which it writes back to the application server that, in turn , returns it to the browser. The Java classes and interfaces used in this HTTP request and response processing are defined by the J2EE servlet specification (and thus provided in the same way by any J2EE-compliant application server). It is important to keep in mind that although servlets are Java programs and have the full range of J2EE function available to them, they are meant to run in the context of a server response to a browser request. Servlets are appropriate for functions such as generating Web pages with dynamic content, handling HTML form submissions (HTTP POST requests ), triggering more complex server-side processing, and so on. Servlets are not the best choice for implementing persistent data transactions, complex application logic, or computation intensive processing. For readers already familiar with Domino server processing, the J2EE servlets are similar to Domino server-side database agents. The fact that Domino agents can be coded in Java makes it tempting to think of servlets and agents as equivalent; however, there are significant differences. Chapter 7 gives more details on this in the section, "Servlets vs. Web Agents ." Java Server Pages JSPs can be viewed as a specific implementation of the servlet model geared toward providing dynamic HTML content. A JSP consists of HTML tags, some of which contain JavaScript code that is executed by the application server when the JSP is requested . A JSP is executed by the application server in the same way as a servlet is and produces a response containing HTML. JSPs are the J2EE way to implement powerful dynamic HTML functions. You will see in later chapters that IBM/Lotus provides extensive support for JSPs and JavaScript tags to access documents in Domino databases. The Domino-provided JavaScript tag libraries open up the full scope of Domino document databases to the J2EE application developer and are a key point of integration between Domino and WebSphere. Enterprise JavaBeans Enterprise JavaBeans (EJBs) are the Java component that can be combined with other resources to create J2EE applications. They combine Java server-side components with distributed object technologies: CORBA + RMI. EJBs are always distributed, which make them fundamentally different from standard JavaBeans. EJBs are not concerned with presentation issues and therefore must be used in conjunction with display functions, such as servlets or JSPs for HTML clients or Java applications that use technologies such as AWT or Swing. WebSphere Application Server provides an implementation of the EJB defined component models. This implementation is referred to as the "EJB container." EJBs can be used in a broad scope of applications beyond Web applications, but they are often used to provide the transaction processing of persistent data (often called the "business logic") of a Web application. It is often EJBs that are invoked to update bank account or reservation records. WAS provides the full range of functions required to make EJB use robust, secure, and scalable. There are three types of enterprise beans: entity beans, session beans, and message-driven beans. All types of EJBs reside in EJB containers, which provide an interface between the beans and the application server on which they reside. Entity EJBs store permanent data. Entity beans with container-managed persistence (CMP) require connections to a form of persistent storage. Bean-managed persistence implies that the task of managing the lifecycle of the entity within the datastore is performed by the bean itself. The bean developer has to develop both the business logic as well as the logic to persist the bean to the datastore. The disadvantage is that the persistence code has to be hardcoded within the bean itself. As a result, the bean is targeted for a single datastore and becomes difficult to reuse. Entity beans differ from session beans in several ways. Entity beans are persistent, allow shared access, have primary keys, and may participate in relationships with other entity beans. Session beans do not require database access, although they can obtain it indirectly as needed through entity beans. Session beans also can obtain direct access to databases (and other resources) through the use of resource references. Session beans can be either stateful or stateless. Use a stateless session bean to act as the entry point for business logic. Message-driven beans (MDB) are new in the EJB specification version 2.0., which enable asynchronous message servicing . The EJB container and a Java Message Service (JMS) provider work together to process messages. When a message arrives from another application component through JMS, the EJB container forwards it through an onMessage() call to a message-driven bean instance, which then processes the message. In other respects, message-driven beans are similar to stateless session beans. A typical e-business application with JSP, servlet, and EJBs is depicted in Figure 2-1. Figure 2-1. Diagram of the EJB model. 
Use the following best practices when designing and developing the enterprise beans: In an Enterprise JavaBeans (EJB) Version 2.0 environment, use local interfaces to improve communication between enterprise beans in the same JVM. Local calls avoid the overhead of RMI/IIOP and use pass-by-reference semantics instead of pass- by-value . For each call, the caller and callee beans share the state of arguments. EJB 2.0 beans can have both a local and remote interface but more typically have one or the other. For communicating with remote clients, provide remote and remote home interfaces. For communicating with local clients such as servlets, entity beans, and message-driven beans, provide local and local home interfaces. Method-Level Object Security with EJB Until the advent of enterprise beans, there was no way to restrict access to an object or method by a particular user. Enterprise beans now, however, allow method-level security on any enterprise bean or method. Users and user groups can be created, which can be granted or denied execution rights to any EJB or method. In WebSphere, these same user groups can be granted or denied access to Web resources (servlets, JSPs, and HTML pages), and the user IDs can be seamlessly passed from the Web resources to the EJBs by the underlying security framework. As Domino is not oriented toward transaction processing, there is no analogous function to EJBs in Domino. EJBs are most often invoked from Domino components, such as from form documents or from agents. It is also possible to invoke Domino functions from within EJBs and there are some technical issues in doing so. In this book, we'll focus on the issues with invoking EJBs managed by WAS from Domino and vice versa, rather than those involved with using EJBs themselves . | 