UNIT -IV Define the following: Entity Bean, Entity Context, Object Relational Mapping, JMS Entity Bean-

An "Entity Bean" is a type of Enterprise JavaBean, a serverside J2EE component, that represents persistent data maintained in a database. An entity bean can manage its own persistence (Bean managed persistence) or can delegate this function to its EJB Container (Container managed persistence). An entity bean is identified by a primary key. If the container in which an entity bean is hosted crashes, the entity bean, its primary key, and any remote references survive the cras OR An entity bean is a type of enterprise bean; a type of EJB server-side component. Entity bean components implement the javax.ejb.EntityBean interface and can be container-managed (CMP) or bean-managed (BMP). Entity beans are designed to represent data in the database; they wrapper data with business object semantics and read and update data automatically Entity Context- The EntityContext interface provides an instance with access to the containerprovided runtime context of an entity enterprise Bean instance. The container passes the EntityContext interface to an entity enterprise Bean instance after the instance has been created. The EntityContext interface remains associated with the instance for the lifetime of the instance. Note that the information that the instance obtains using the EntityContext interface (such as the result of the getPrimaryKey() method) may change, as the container assigns the instance to different EJB objects during the instance's life cycle Object Relational Mapping-Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-orientedprogramming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools. JMS- The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API[1] for sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914.[2] It is a messaging standard that allows application components based on the Java Enterprise Edition (JEE) to create, send, receive, and read messages. It allows the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous Define Session Bean? Discuss the lifetime of a session bean? A session bean is an EJB 3.0 or EJB 2.1 enterprise bean component created by a client for the duration of a single client/server session. A session bean performs operations for the client. Although a session bean can be transactional, it is not recoverable should a system failure occur. Session bean objects are either stateless (see "What is a Stateless Session Bean?") or stateful: maintaining conversational state across method calls and transactions (see "What is a Stateful Session Bean?"). If a session bean maintains state, then OC4J manages this state if the object must be removed from memory ("When Does Stateful Session Bean Passivation Occur?"). However, the session bean object itself must manage its own persistent data Stateless-

A stateless session bean is a session bean with no conversational state. All instances of a particular stateless session bean class are identical. A stateless session bean and its client do not share state or identity between method invocations. A stateless session bean is strictly a single invocation bean. It is employed for reusable business services that are not connected to any specific client, such as generic currency calculations, mortgage rate calculations, and so on. Stateless session beans may contain client-independent, read-only state across a call. Subsequent calls are handled by other stateless session beans in the pool. The information is used only for the single invocation

Figure 1-3 Stateless Session Bean Life Cycle

EJB Method ejbCreate

Description The container invokes this method right before it creates the bean. Use this method to initialize nonclient-specific information such as retrieving a data source. This method is never called for a stateless session bean. Provide an empty implementation only. This method is never called for a stateless session bean. Provide an empty implementation only. The container invokes this method before it ends the life of the stateless session bean. Use this method to perform any required clean-up (for example, closing external resources such as a data source).

ejbActivate ejbPassivate ejbRemove

setSessionContext The container invokes this method after it first instantiates the bean. Use this method to obtain a reference to the context of the bean. For more information, see "Implementing the setSessionContext Method".

What is a Stateful Session Bean? A stateful session bean is a session bean that maintains conversational state.

Stateful session beans are useful for conversational sessions, in which it is necessary to maintain state, such as instance variable values or transactional state, between method invocations. These session beans are mapped to a single client for the life of that client. A stateful session bean maintains its state between method calls. Thus, there is one instance of a stateful session bean created for each client. Each stateful session bean contains an identity and a one-to-one mapping with an individual client. When the container determines that it must remove a stateful session bean from memory (in order to release resources), the container maintains the bean's state by passivation (serializing the bean to disk). This is why the state that you passivate must be serializable. However, this information does not survive system failures. When the bean instance is requested again by its client, the container activates the previously passivated bean instance.

Figure 1-4 Stateful Session Bean Life Cycle

EJB Method ejbCreate

Description The container invokes this method right before it creates the bean. Stateless session beans must do nothing in this method. Stateful session beans can initiate state in this method. The container invokes this method right after it reactivates the bean. The container invokes this method right before it passivates the bean. For more information, see the following:

ejbActivate ejbPassivate

EJB Method

Description

"When Does Stateful Session Bean Passivation Occur?" "What Object Types can be Passivated?" "Where is a Passivated Stateful Session Bean Stored?"

ejbRemove

A container invokes this method before it ends the life of the session object. This method performs any required clean-up (for example, closing external resources such as file handles).

setSessionContext The container invokes this method after it first instantiates the bean. Use this method to obtain a reference to the context of the bean. For more information, see "Implementing the setSessionContext Method".

20. What is the difference between Message Driven Beans and Stateless Session beans? In several ways, the dynamic creation and allocation of message-driven bean instances mimics the behavior of stateless session EJB instances, which exist only for the duration of a particular method call. However, message-driven beans are different from stateless session EJBs (and other types of EJBs) in several significant ways: Message-driven beans process multiple JMS messages asynchronously, rather than processing a serialized sequence of method calls. Message-driven beans have no home or remote interface, and therefore cannot be directly accessed by internal or external clients. Clients interact with messagedriven beans only indirectly, by sending a message to a JMS Queue or Topic. Only the container directly interacts with a message-driven bean by creating bean instances and passing JMS messages to those instances as necessary. The Container maintains the entire lifecycle of a message-driven bean; instances cannot be created or removed as a result of client requests or other API calls How do message-driven beans overcome the limitations of RMI? Message Driven Beans (MDBs) are a new type of bean added in the EJB 2.0 specification. The reason why these beans were added is that there was no way in EJB 1.1 to handle asynchronous invocation. The primary reason for this is that an EJB bean could never be invoked from other objects through anything other than its remote interface. Therefore a bean could never set itself up as a listener for asynchronous invocation. This limitation is overcome by Message Drive Beans. An MDB is a bean without a remote interface; the container sets itself up as a listener for asynchronous invocation of the MDB and handles the invocation of the concrete bean. Otherwise, MDBs follow all the usual roles for EJB beans. Message Driven Beans are primarily focused on JMS. An MDB is either a topic or a queue subscriber. One nice feature with MDBs is that one gets multithreaded subscribers (even for topics) without having to deal with the subtle difficulties of writing multithreaded code for JMS message consumers. For what purpose should you use an MDB? Basically, you would use an MDB any time you are about to create a JMS subscriber. Typical conditions for doing this are:

Decouple an invoker from the invoked code. Make it possible for multiple parties to get your messages. Get asynchronous behavior, i.e. start long-running code without the need to wait for the called code to finish. UNIT-I

J2EE- Short for Java 2 Platform Enterprise Edition. J2EE is a platform-independent, Javacentric environment from Sun for developing, building and deploying Web-based enterprise applications online. The J2EE platform consists of a set of services, APIs, and protocols that provide the functionality for developing multi tiered, Web-based applications.

Some of the key features and services of J2EE: At the client tier, J2EE supports pure HTML, as well as Java applets or applications. It relies on Java Server Pages and servlet code to create HTML or other formatted data for the client. Enterprise JavaBeans (EJBs) provide another layer where the platform's logic is stored. An EJB server provides functions such as threading, concurrency, security and memory management. These services are transparent to the author. Java Database Connectivity (JDBC), which is the Java equivalent to ODBC, is the standard interface for Java databases. The Java servlet API enhances consistency for developers without requiring a graphical user interface. What is a Servlet? Servlet is an interface defined in javax.servlet package. It declares three essential methods for the life cycle of a servlet init(), service(), and destroy(). They are implemented by every servlet(defined in SDK or self-defined) and are invoked at specific times by the server. 1. The init() method is invoked during initialization stage of the servlet life cycle. It is passed an object implementing the javax.servlet.ServletConfig interface, which allows the servlet to access initialization parameters from the web application. 2. The service() method is invoked upon each request after its initialization. Each request is serviced in its own separate thread. The web container calls the service() method of the servlet for every request. The service() method determines the kind of request being made and dispatches it to an appropriate method to handle the request. 3. The destroy() method is invoked when the servlet object should be destroyed. It releases the resources being held. From the life cycle of a servlet object, we can see that servlet classes are loaded to container by class loader dynamically. Each request is in its own thread, and a servlet object can serve multiple threads at the same time(thread not safe). When it is no longer being used, it should be garbage collected by JVM.

Servlets are most often used to

Process or store data that was submitted from an HTML form Provide dynamic content such as the results of a database query Manage state information that does not exist in the stateless HTTP protocol, such as filling the articles into the shopping cart of the appropriate customer

Servlet ContainerAs we see here, the user/client can only request static webpage from the server. This is not good enough, if the user wants to read the web page based on his input. The basic idea of Servlet container is using Java to dynamically generate the web page on the server side. So servlet container is essentially a part of a web server that interacts with the servlets.

1. What is a Web Server? To know what is a Servlet container, we need to know what is a Web Server first.

A web server uses HTTP protocol to transfer data. In a simple situation, a user type in a URL (e.g.www.programcreek.com/static.html) in browser (a client), and get a web page to read. So what the server does is sending a web page to the client. The transformation is in HTTP protocol which specifies the format of request and response message.

The role of JVM Using servlets allows the JVM to handle each request within a separate Java thread, and this is one of the key advantage of Servlet container. Each servlet is a Java class with special elements responding to HTTP requests. The main function of Servlet contain is to forward requests to correct servlet for processing, and return the dynamically generated results to the correct location after the JVM has processed them. In most cases servlet container runs in a single JVM, but there are solutions when container need multiple JVMs cookie

A message given to a Web browser by a Web server. The browser stores the message in a text file. The message is then sent back to the server each time the browser requests a page from the server. Also see session cookie and persistent cookie. The main purpose of cookies is to identify users and possibly prepare customized Web pages for them. When you enter a Web siteusing cookies, you may be asked to fill out a form providing such information as your name and interests. This information is packaged into a cookie and sent to your Web browser which stores it for later use. The next time you go to the same Web site, your browser will send the cookie to the Web server. The server can use this information to present you with custom Web pages. So, for example, instead of seeing just a generic welcome page you might see a welcome page with your name on it.

Differentiate between the following Generic and Http Servlet Generic Servlet: GenericServlet class is direct subclass of Servlet interface. Generic Servlet is protocol independent.It handles all types of protocol like http, smtp, ftp etc. Generic Servlet only supports service() method.It handles only simple request public void service(ServletRequest req,ServletResponse res ). Generic Servlet only supports service() method. HttpServlet: HttpServlet class is the direct subclass of Generic Servlet. HttpServlet is protocol dependent. It handles only http protocol. HttpServlet supports public void service(ServletRequest req,ServletResponse res ) and protected void service(HttpServletRequest req,HttpServletResponse res). HttpServlet supports also doGet(),doPost(),doPut(),doDelete(),doHead(),doTrace(),doOptions()etc.

doGet() and doPost() DoGet 1)In doGet Method the parameters are appended to the URL and sent along with header information 2)Maximum size of data that can be sent using doget is 240 bytes 3)Parameters are not encrypted 4)DoGet is faster if we set the response content length since the same connection is used. 5)Thus increasing the performance 6)DoGet should be idempotent. i.e. doget should be able to be repeated safely many times 7)DoGet should be safe without any side effects for which user is held responsible DoPost 1)In doPost, parame ters are sent in separate line in the body 2)There is no maximum size for data 3)Parameters are encrypted 4)Dopost is generally used to update or post some information to the server 5)DoPost is slower compared to doGet since doPost does not write the content length 6)This method does not need to be idempotent. Operations requested through POST can

have side effects for which the user can be held accountable, for example, updating stored data or buying items online 7)This method does not need to be either safe getInitParameter public java.lang.String getInitParameter(java.lang.String name) Returns a String containing the value of the named initialization parameter, or null if the parameter does not exist. Parameters: name - a String specifying the name of the initialization parameter Returns: a String containing the value of the initialization parameter getInitParameterNames public java.util.Enumeration getInitParameterNames() Returns the names of the servlet's initialization parameters as an Enumeration of String objects, or an empty Enumeration if the servlet has no initialization parameters. Returns: an Enumeration of String objects containing the names of the servlet's initialization parameters

Servlet and Applet A Java Applet is a Java class which is run on the client's JVM (via a Browser Plugin). A Java Servlet is run on the server-side in a Servlet container, like Apache Tomcat and the client recieves the results in the form of plain old HTML. The key difference is that where as one runs on the client side, the other on the Server side. applet is the Desktop application and the Servlet is the web Application Applet is run on the Clients machine and the Servlet is run the Server Machine And produce the html page on the client browser with the help of the Request And Response Parameter in the Java.servlet.*; Package Which are the servlet life cycle methods and they are defined by which interface What are the protocols supported by HttpServlet? It extends the GenericServlet base class and provides an framework for handling the HTTP protocol. So, HttpServlet only supports HTTP and HTTPS protocol. Servlet API Servlet API Documentation Packages The javax.servlet package contains a number of classes and interfaces that describe and define the contracts between a servlet class and the runtime environment provided for an instance of such a class by a conforming servlet container.

javax.servlet

javax.servlet.http

The javax.servlet.http package contains a number of classes and interfaces that describe and define the contracts between a servlet class running under the HTTP protocol and the runtime environment provided for an instance of such a class by a conforming servlet container.

techniques for servlet configuration? The ServletConfig interface contains the following methods : 1. ServletContext getServletContext() : Retrieve a Servlet Context for the Application. 2. String getServletName() : Retrieve the name of the Servlet. 3. Enumeration getInitParameterNames() : Retrieve the names of the initialization parameters of the Servlet, if any. The names are returned in a java.util.Enumeration instance ofString objects. 4. String getInitParameter (String name) : This returns a String object containing the value of the specified initialization parameter, or null if there is no parameter by that name.

understand by Servlet Mapping? servlet mapping specifies the web container of which java servlet should be invoked for a url given by client. It maps url patterns to servlets. When there is a request from a client, servlet container decides to which application it should forward to. Then context path of url is matched for mapping servlets. How is servlet mapping defined? Servlets should be registered with servlet container. For that, you should add entries in web deployment descriptor web.xml. It is located in WEB-INF directory of the web application. Entries to be done in web.xml for servlet-mapping: <servlet-mapping> <servlet-name>milk</servlet-name> <url-pattern>/drink/*</url-pattern> </servlet-mapping> servlet-mapping has two child tags, url-pattern and servlet-name. url-pattern specifies the type of urls for which, the servlet given in servlet-name should be called. Be aware that, the container will use case-sensitive for string comparisons for servlet matching. Syntax for servlet mapping as per servlet specification SRV.11.2: A string beginning with a / character and ending with a /* suffix is used for path mapping. A string beginning with a *. prefix is used as an extension mapping. A string containing only the / character indicates the default servlet of the application. In

this case the servlet path is the request URI minus the context path and the path info is null. All other strings are used for exact matches only. Rule for URL path mapping: It is used in the following order. First successful match is used with no further attempts. 1. The container will try to find an exact match of the path of the request to the path of the servlet. A successful match selects the servlet. 2. The container will recursively try to match the longest path-prefix. This is done by stepping down the path tree a directory at a time, using the / character as a path separator. The longest match determines the servlet selected. 3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last . character. 4. If neither of the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource

techniques of inter-servlet communication?

Servlets running together in the same server have several ways to communicate with each other. There are three major reasons to use interservlet communication: Direct servlet manipulation A servlet can gain access to the other currently loaded servlets and perform some task on each. The servlet could, for example, periodically ask every servlet to write its state to disk to protect against server crashes. Servlet reuse One servlet can use another's abilities to perform a task. Think back to the ChatServlet from the previous chapter. It was written as a server for chat applets, but it could be reused (unchanged) by another servlet that needed to support an HTML-based chat interface. Servlet collaboration The most common, situation involves two or more servlets sharing state information. For example, a set of servlets managing an online store could share the store's product inventory count. Session tracking (see Chapter 7, "Session Tracking" ) is a special case of servlet collaboration.

Servlet collaboration

One simple way for servlets to share information is by using Java's system-wide Properties list, found in the java.lang.System class. This Properties list holds the standard system

properties, such as java.version and path.separator, but it can also hold applicationspecific properties. Servlets can use the properties list to hold the information they need to share. A servlet can add (or change) a property by calling: System.getProperties().put("key", "value"); That servlet, or another servlet running in the same JVM, can later get the value of the property by calling: String value = System.getProperty("key"); The property can be removed by calling: System.getProperties().remove("key"); It's best if the key for a property includes a prefix that contains the name of the servlet's package and the name of the collaboration group. For example,"com.oreilly.servlet.ShoppingCart". The Properties class is intended to be String based, meaning that each key and value is supposed to be a String. This limitation, though, isn't commonly enforced and can (although it's quite a hack) be ignored by servlets that want to store and retrieve non-String objects. Such servlets can take advantage of the fact that the Properties class extends the Hashtable class, so the Properties list can (quite rudely) be treated as a Hashtable when storing keys and values. For example, a servlet can add or change aproperty object by calling: System.getProperties().put(keyObject, valueObject); It can retrieve the property object by calling: SomeObject valueObject = (SomeObject)System.getProperties().get(keyObject); It can remove the property object by calling: System.getProperties().remove(keyObject); This misuse of the Properties list causes the getProperty(), list() and save() methods of the Properties class to throw ClassCastException objects when they naturally--but erroneously--assume each key and value to be a String. For this reason, if there's any chance these methods might be called, you should instead use one of the techniques for servlet collaboration we describe later in the chapter. Also, remember the class files for keyObject and valueObject should be found in the server's classpath, not in the default servlet directory where they would be loaded, and perhaps reloaded, by the special servlet class loaders. There are three more caveats to using the system Properties list for servlet collaboration: the information isn't naturally persistent between server restarts, the information can be viewed (and modified or deleted) by other classes executing in the servlet's JVM, and some servlet security managers may not grant servlets access to the system property list. UNIT-I 1))).. // hack

2))).

3)).. Scriptlets: Scriptlets are the code blocks of a JSP page. Scriptlets start with an opening <% tag and end with a closing %> tag. Ex: <%@ page session="false" %> <%@ page import="java.sql.*" %> <% try { Class.forName("sun.jdbc.odbc.JdbcOdbcDriver"); System.out.println("JDBC driver loaded"); } catch (ClassNotFoundException e) { System.out.println(e.toString()); } %> <HTML> <HEAD> <TITLE>Display All Users</TITLE> </HEAD> <BODY> <CENTER> <BR><H2>Displaying All Users</H2> <BR> <BR> <TABLE> <TR> <TH>First Name</TH> <TH>Last Name</TH> <TH>User Name</TH> <TH>Password</TH> </TR> JSP Directives: JSP directives provide directions and instructions to the container, telling it how to handle certain aspects of JSP processing. A JSP directive affects the overall structure of the servlet class. It usually has the following form:

<%@ directive attribute="value" %> Directives can have a number of attributes which you can list down as key-value pairs and separated by commas. The blanks between the @ symbol and the directive name, and between the last attribute and the closing %>, are optional. There are three types of directive tag:

The page Directive: The page directive is used to provide instructions to the container that pertain to the current JSP page. You may code page directives anywhere in your JSP page. By convention, page directives are coded at the top of the JSP page. Following is the basic syntax of page directive: <%@ page attribute="value" %> Following list of attributes associated with the page directive:

The include Directive: The include directive is used to include a file during the translation phase. This directive tells the container to merge the content of other external files with the current JSP during the translation phase. You may code include directives anywhere in your JSP page. The general usage form of this directive is as follows: <%@ include file="relative url %> The taglib Directive: The JavaServer Pages API allows you to define custom JSP tags that look like HTML or XML tags and a tag library is a set of user-defined tags that implement custom behavior. The taglib directive declares that your JSP page uses a set of custom tags, identifies the location of the library, and provides a means for identifying the custom tags in your JSP page. The taglib directive follows the following syntax:

<%@ taglib uri="uri" prefix="prefixOfTag" > 4)).. JSP Expressions A JSP expression is used to insert the value of a scripting language expression, converted into a string, into the data stream returned to the client. When the scripting language is the Java programming language, an expression is transformed into a statement that converts the value of the expression into a Stringobject and inserts it into the implicit out object. The syntax for an expression is as follows: <%= scripting-language-expression %> Note that a semicolon is not allowed within a JSP expression, even if the same expression has a semicolon when you use it within a scriptlet. In the web service version of the hello1 application, response.jsp contains the following scriptlet, which gets the proxy that implements the service endpointinterface. It then invokes the sayHello method on the proxy, passing the user name retrieved from a request parameter: <% String resp = null; try { Hello hello = new HelloService().getHelloPort(); resp = hello.sayHello(request.getParameter("username")); } catch (Exception ex) { resp = ex.toString(); } %> A scripting expression is then used to insert the value of resp into the output stream: <h2><font color="black"><%= resp %>!</font></h2> 5))) Both the <jsp:include> and <jsp:forward> transfer control to new jsp page. The <jsp:include> action transfers control to a new page, whose results are inserted into the current page at this point, then execution of the current page continues. Means control returns back to main page frm where ur including that page. Opposite to this <jsp:forward> works, giving up the control to the forwarded page. Control doen't return to main page once u forward it. This is the only difference I found. Hope this would help... The jsp:forward request is similar to a jsp:include, but you don't get control back afterwards. The attribute flush="true" is required on some JSP engines (including the release of Tomcat at the time this book went to press) to remind you that once you do this include, you have committed your output (prior to the include, the output might be all in a buffer). Therefore, as I just stated, you can no longer do anything that might generate headers, including setContentType(), sendRedirect( ), and so on. An alternate include mechanism is <%@include file="filename"%>. This mechanism is a bit more efficient (the inclusion is done at the time the JSP is being compiled), but is limited to including text files (the file is read, rather than being processed as an HTTP URL; so if you include, say, a CGI script, the contents of your CGI script are revealed in the JSP output: not useful!). The<jsp:include> can include a URL of any type (HTML, servlet, JSP, CGI, even PHP or ASP). here is the main difference ... jsp:include , includes the page inside the current page... so the included page will appear

exactly where u have added the jsp command inside the current page... but jsp:forward will forward the current page to the forwarded page... meaning when the current page is called the forwarded page is called immediately after...like i say... if(....) {forwared to pageOne.jsp} else if (...){forward to pageTwo.jsp} Online resources would help a lot also 5))).. Core Tags: The core group of tags are the most frequently used JSTL tags. Following is the syntax to include JSTL Core library in your JSP: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> There are following Core JSTL Tags: Tag Description <c:out > <c:set > Like <%= ... >, but for expressions. Sets the result of an expression evaluation in a 'scope' Removes a scoped variable (from a particular scope, if specified). Catches any Throwable that occurs in its body and optionally exposes it. Simple conditional tag which evalutes its body if the supplied condition is true. Simple conditional tag that establishes a context for mutually exclusive conditional operations, marked by <when> and <otherwise> Subtag of <choose> that includes its body if its condition evalutes to 'true'. Subtag of <choose> that follows <when> tags and runs only if all of the prior conditions evaluated to 'false'. Retrieves an absolute or relative URL and exposes its contents to either the page, a String in 'var', or a Reader in 'varReader'. The basic iteration tag,

<c:remove >

<c:catch>

<c:if>

<c:choose>

<c:when>

<c:otherwise >

<c:import>

<c:forEach >

accepting many different collection types and supporting subsetting and other functionality . Iterates over tokens, <c:forTokens> separated by the supplied delimeters. <c:param> <c:redirect > <c:url> Adds a parameter to a containing 'import' tag's URL. Redirects to a new URL.

Creates a URL with optional query parameters Formatting tags: The JSTL formatting tags are used to format and display text, the date, the time, and numbers for internationalized Web sites. Following is the syntax to include Formatting library in your JSP: <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %> Following is the list of Formatting JSTL Tags: Tag Description <fmt:formatNumber> To render numerical value with specific precision or format. Parses the string representation of a number, currency, or percentage. Formats a date and/or time using the supplied styles and pattern Parses the string representation of a date and/or time Loads a resource bundle to be used by its tag body. Stores the given locale in the locale configuration variable. Loads a resource bundle and stores it in the named scoped variable or the bundle configuration variable. Specifies the time zone for any time formatting or parsing

<fmt:parseNumber>

<fmt:formatDate>

<fmt:parseDate>

<fmt:bundle>

<fmt:setLocale>

<fmt:setBundle>

<fmt:timeZone>

actions nested in its body. <fmt:setTimeZone> Stores the given time zone in the time zone configuration variable To display an internationalized message. Sets the request character encoding

<fmt:message> <fmt:requestEncoding>

6)).. Model 1 and Model 2 (MVC) Architecture Model 1 Architecture Servlet and JSP are the main technologies to develop the web applications. Servlet was considered superior to CGI. Servlet technology doesn't create process, rather it creates thread to handle request. The advantage of creating thread over process is that it doesn't allocate separate memory area. Thus many subsequent requests can be easily handled by servlet. Problem in Servlet technology Servlet needs to recompile if any designing code is modified. It doen't provide separation of concern. Presentation and Business logic are mixed up. JSP overcomes almost all the problems of Servlet. It provides better separation of concern, now presentation and business logic can be easily separated. You don't need to redeploy the application if JSP page is modified. JSP provides support to develop web application using JavaBean, custom tags and JSTL so that we can put the business logic separate from our JSP that will be easier to test and debug.

As you can see in the above figure, there is picturized the flow of the model1 architecture. Browser sends request for the JSP page JSP accesses Java Bean and invokes business logic Java Bean connects to the database and get/save data Response is sent to the browser which is generated by JSP Advantage of Model 1 Architecture Easy and Quick to develop web application Disadvantage of Model 1 Architecture Navigation control is decentralized since every page contains the logic to determine the next page. If JSP page name is changed that is referred by other pages, we need to change it in all the pages that leads to the maintenance problem.

Time consuming You need to spend more time to develop custom tags in JSP. So that we don't need to use scriptlet tag. Hard to extend It is better for small applications but not for large applications. Model 2 (MVC) Architecture Model 2 is based on the MVC (Model View Controller) design pattern. The MVC design pattern consists of three modules model, view and controller. Model The model represents the state (data) and business logic of the application. View The view module is responsible to display data i.e. it represents the presentation. Controller The controller module acts as an interface between view and model. It intercepts all the requests i.e. receives input and commands to Model / View to change accordingly.

Advantage of Model 2 (MVC) Architecture Navigation control is centralized Now only controller contains the logic to determine the next page. Easy to maintain Easy to extend Easy to test Better separation of concerns Disadvantage of Model 2 (MVC) Architecture We need to write the controller code self. If we change the controller code, we need to recompile the class and redeploy the application. Visit here to get the Example of MVC using S 7)).. There are two types of comments in a JSP page: server side comments and client sidecomments. The server side comments, or hidden comments, is visible only on the server side because it is removed during JSP page translation. A server side comments is of the form <%-- comments --%> This type of comments can be used for documentation, such as the author(s), the date, and the copyright notice of the revision, an identifier and a description

about the JSP page for web developers. All these information will be ignored by the JSP engine at compile time and will not be propagated to the client side. This type of comments can also be used to "comment out" some portions of the Java codeof a JSP page. An alternative way to place a "comment" in JSP is to use the comment mechanism of thescripting language. For example: <% /** this is a comment ... **/ %> However, pure JSP comments are preferred over JSP comments with scripting language comments, as the former is less dependent on the underlying scripting language, and will be easier to evolve into JSP 2.0-style pages. The following table is quoted from Code Conventions for the JavaServer Pages Technology Version 1.x Language: JSP scriptlet with scripting language Pure JSP Line comment comment <% /** ... */ %> <% /* ... */ %> <%-- ... --%> single <% // ... %> <% /* * ... * <%-*/ ... multiple %> <% -- %> // // ... // %> The client-side style, or output comments, that are intended to appear in the generated document sent to the client. They should not contain information about the behavior and internal structure of the server application or the code to generate the responses. In order to generate comments that appear in the response output stream to the requesting client, the HTML and XML comment syntax is used, as follows: <!-- comments ... --> These comments are treated as uninterpreted template text by the JSP container. If the generated comment is to have dynamic data, this can be obtained through an expression syntax, as in: <!-- comments <%= expression %> more comments ... --> The use of client-side comments is generally discouraged, as a client / user does not need or read these kinds of comments directly in order to interpret the received responses. The client-side comments for HTML authors to use a small amount of HTML comments to embody the guidelines of the HTML document structures, to break down the HTML code into sections for easy reading when viewing the page source. Sometimes it can be also used for highlighting copyright information. As for the preferred style of the client-side comments, the following is also quoted from Code Conventions for the JavaServer Pages Technology Version 1.x Language: Multiline Comment Block

A multiline comment block, be it JSP or client-side, is decorated with the dash character "-". In the XML specification, the double-dash string "--" is not allowed within an XML comment block. Thus, for compatibility and consistency with this specification, no double-dash string is used to decorate comment lines within a multiline comment block. The following table illustrates this preference using a client-side comment block: Preferred Non-XML compliant <!-<!-- line 1 -- line 1 - line 2 -- line 2 ... ... --> --> 9)). JSP Implicit Objects are the Java objects that the JSP Container makes available to developers in each page and developer can call them directly without being explicitly declared. JSP Implicit Objects are also called pre-defined variables. JSP supports nine Implicit Objects which are listed below: Object Description request This is the HttpServletRequest object associated with the request. This is the HttpServletResponse object associated with the response to the client. This is the PrintWriter object used to send output to the client. This is the HttpSession object associated with the request. This is the ServletContext object associated with application context. This is the ServletConfig object associated with the page.

response

out session

application

config

This encapsulates use of serverpageContext specific features like higher performance JspWriters. page This is simply a synonym for this, and is used to call the methods defined by the translated servlet class.

The Exception object allows the exception data to be accessed by designated JSP. JSP Implicit objects are created by the web container. These implicit objects are Java objects that implement interfaces in the Servlet and JSP API. Scripting elements in a JSP page can make use of these JSP implicit objects. There are nine (9) JSP implicit objects available. Exception

JSP Implicit Objects are as follows: request implicit object The JSP implicit request object is an instance of a java class that implements the javax.servlet.http.HttpServletRequest interface. It represents the request made by the client. The request implicit object is generally used to get request parameters, request attributes, header information and query string values. response implicit object The JSP implicit response object is an instance of a java class that implements the javax.servlet.http.HttpServletResponse interface. It represents the response to be given to the client. The response implicit object is generally used to set the response content type, add cookie and redirect the response. out implicit object The JSP implicit out object is an instance of the javax.servlet.jsp.JspWriter class. It represents the output content to be sent to the client. The out implicit object is used to write the output content. session implicit object The JSP implicit session object is an instance of a java class that implements the javax.servlet.http.HttpSession interface. It represents a client specific conversation. The session implicit object is used to store session state for a single user. application implicit object The JSP implicit application object is an instance of a java class that implements the javax.servlet.ServletContext interface. It gives facility for a JSP page to obtain and set information about the web application in which it is running. Ads by Google exception implicit object The JSP implicit exception object is an instance of the java.lang.Throwable class. It is available in JSP error pages only. It represents the occured exception that caused the control to pass to the JSP error page. config implicit object The JSP implicit config object is an instance of the java class that implements javax.servlet.ServletConfig interface. It gives facility for a JSP page to obtain the initialization parameters available. page implicit object The JSP implicit page object is an instance of the java.lang.Object class. It represents the current JSP page. That is, it serves as a reference to the java servlet object that implements the JSP page on which it is accessed. It is not advisable to use this page implict object often as it consumes large memory. pageContext implicit object The JSP implicit pageContext object is an instance of the javax.servlet.jsp.PageContext abstract class. It provides useful context information. That is it provides methods to get and set attributes in different scopes and for transfering requests to other resources. Also it contains the reference to to implicit objects. 10)).. What is the Struts Framework? The Struts Framework is a standard for developing well-architected Web applications. It has the following features: Open source Based on the Model-View-Controller (MVC) design paradigm, distinctly separating all three levels: Model: application state View: presentation of data (JSP, HTML) Controller: routing of the application flow Struts Architecture:

All incoming requests are intercepted by the Struts servlet controller. The Struts Configuration file struts-config.xml is used by the controller to determine the routing of the flow. This flows consists of an alternation between two transitions: 11))).. 12)) import import import import

java.io.*; java.util.*; javax.servlet.*; javax.servlet.http.*;

/** Simple Hello World Servlet */ public class HelloServlet extends HttpServlet{ public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException { PrintWriter out = response.getWriter( ); response.setContentType("text/html"); out.println("<H1>Hello from a Servlet</h2>"); out.println("<P>This servlet ran at "); out.println(new Date().toString( )); out.println("<P>Courtesy of HelloServlet.java 1.2 "); } } The program will give output 13)). jsp(java server pages) and its advantages over servlet Posted on November 24, 2011 JavaServer Pages (JSP) is a java technology that helps software devlpoers serve dynamically generated webpages based on HTML, XML or other document types. Released in 1999 as Suns answer to ASP and PHP,JSP was designed to address the perception that the Java programming environment didnt provide developers with enough support for the Web. To deploy and run, a compatible web server with servlet container is required. The Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems and the JCP(Java Community Process) must both be supported by the container. Architecturally, JSP may be viewed as a high-level abstraction of Java Servlets. JSPs are loaded in the server and are operated from a structured special installed Java server packet called a Java EE Web Application, often packaged as a file archive.

JSP allows Java code and certain pre-defined actions to be interleaved with static web markup content, with the resulting page being compiled and executed on the server to deliver an HTML or XML document. The compiled pages and any dependent Java libraries use Java bytecode rather than a native software format, and must therefore be executed within a Java virtual machine(JVM) that integrates with the host Operating systemto provide an abstract platform-neutral environment. JSP syntax is a fluid mix of two basic content forms: scriptlet elements and markup. Markup is typically standard HTML or XML, while Scriptlet elements are delimited blocks of Java code which may be intermixed with the markup. When the page is requested the Java code is executed and its output is added, in situ, with the surrounding markup to create the final page. JSPs must be compiled to Java bytecode classes before they can be executed, but such compilation is needed only when a change to the source JSP file has occurred. Java code is not required to be complete (self contained) within its scriptlet element block, but can straddle markup content providing the page as a whole is syntactically correct (for example, any Java if/for/while blocks opened in one scriptlet element must be correctly closed in a later element for the page to successfully compile). This system of split inline coding sections is called step over scripting because it can wrap around the static markup by stepping over it. Markup which falls inside a split block of code is subject to that code, so markup inside an if block will only appear in the output when the if condition evaluates to true; likewise markup inside a loop construct may appear multiple times in the output depending upon how many times the loop body runs. The JSP syntax adds additional XML-like tags, called JSP actions, to invoke built-in functionality. Additionally, the technology allows for the creation of JSP tag libraries that act as extensions to the standard HTML or XML tags. JVM operated tag libraries provide aplatform independent way of extending the capabilities of a web server. Note that not all commercial Java servers are Java EE specification compliant. jsp has a lot of advantages over servlets and it is using tag libraries and both servlets and jsp together are using as number one combination for devloping projects and most web based projects . About these ads

14))).. JSP - Standard Tag Library (JSTL) Tutorial Advertisements

The JavaServer Pages Standard Tag Library (JSTL) is a collection of useful JSP tags which encapsulates core functionality common to many JSP applications. JSTL has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and SQL tags. It also provides a framework for integrating existing custom tags with JSTL tags. The JSTL tags can be classified, according to their functions, into following JSTL tag library groups that can be used when creating a JSP page: Install JSTL Library: If you are using Apache Tomcat container then follow the following two simple steps: Download the binary distribution from Apache Standard Taglib and unpack the compressed file. To use the Standard Taglib from its Jakarta Taglibs distribution, simply copy the JAR files in the distribution's 'lib' directory to your application's webapps\ROOT\WEB-INF\lib directory. To use any of the libraries, you must include a <taglib> directive at the top of each JSP that uses the library. Core Tags: The core group of tags are the most frequently used JSTL tags. Following is the syntax to include JSTL Core library in your JSP:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> There are following Core JSTL Tags: Tag <c:out > <c:set > <c:remove > <c:catch> <c:if> Description Like <%= ... >, but for expressions. Sets the result of an expression evaluation in a 'scope' Removes a scoped variable (from a particular scope, if specified). Catches any Throwable that occurs in its body and optionally exposes it. Simple conditional tag which evalutes its body if the supplied condition is true. Simple conditional tag that establishes a context for mutually exclusive conditional operations, marked by <when> and <otherwise> Subtag of <choose> that includes its body if its condition evalutes to 'true'. Subtag of <choose> that follows <when> tags and runs only if all of the prior conditions evaluated to 'false'. Retrieves an absolute or relative URL and exposes its contents to either the page, a String in 'var', or a Reader in 'varReader'. The basic iteration tag, accepting many different collection types and supporting subsetting and other functionality . Iterates over tokens, separated by the supplied delimeters. Adds a parameter to a containing 'import' tag's URL. Redirects to a new URL. Creates a URL with optional query parameters

<c:choose>

<c:when> <c:otherwise >

<c:import>

<c:forEach > <c:forTokens> <c:param> <c:redirect > <c:url>

Formatting tags: The JSTL formatting tags are used to format and display text, the date, the time, and numbers for internationalized Web sites. Following is the syntax to include Formatting library in your JSP: <%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %> Following is the list of Formatting JSTL Tags: Tag <fmt:formatNumber> <fmt:parseNumber> <fmt:formatDate> Description To render numerical value with specific precision or format. Parses the string representation of a number, currency, or percentage. Formats a date and/or time using the supplied styles and pattern

<fmt:parseDate> <fmt:bundle> <fmt:setLocale> <fmt:setBundle> <fmt:timeZone> <fmt:setTimeZone> <fmt:message>

Parses the string representation of a date and/or time Loads a resource bundle to be used by its tag body. Stores the given locale in the locale configuration variable. Loads a resource bundle and stores it in the named scoped variable or the bundle configuration variable. Specifies the time zone for any time formatting or parsing actions nested in its body. Stores the given time zone in the time zone configuration variable To display an internationalized message.

<fmt:requestEncoding> Sets the request character encoding SQL tags: The JSTL SQL tag library provides tags for interacting with relational databases (RDBMSs) such as Oracle, mySQL, or Microsoft SQL Server. Following is the syntax to include JSTL SQL library in your JSP: <%@ taglib prefix="sql" uri="http://java.sun.com/jsp/jstl/sql" %> Following is the list of SQL JSTL Tags: Ads not by this site Tag <sql:setDataSource> <sql:query> <sql:update> <sql:param> <sql:dateParam> Description Creates a simple DataSource suitable only for prototyping Executes the SQL query defined in its body or through the sql attribute. Executes the SQL update defined in its body or through the sql attribute. Sets a parameter in an SQL statement to the specified value. Sets a parameter in an SQL statement to the specified java.util.Date value. Provides nested database action elements with a shared Connection, set up to execute all statements as one transaction.

<sql:transaction >

XML tags: The JSTL XML tags provide a JSP-centric way of creating and manipulating XML documents. Following is the syntax to include JSTL XML library in your JSP. The JSTL XML tag library has custom tags for interacting with XML data. This includes parsing XML, transforming XML data, and flow control based on XPath expressions. <%@ taglib prefix="x" uri="http://java.sun.com/jsp/jstl/xml" %> Before you proceed with the examples, you would need to copy following two XML and XPath related libraries into your <Tomcat Installation Directory>\lib: XercesImpl.jar: Download it from http://www.apache.org/dist/xerces/j/ xalan.jar: Download it from http://xml.apache.org/xalan-j/index.html Following is the list of XML JSTL Tags:

Tag <x:out> <x:parse> <x:set > <x:if > <x:forEach> <x:choose>

Description Like <%= ... >, but for XPath expressions. Use to parse XML data specified either via an attribute or in the tag body. Sets a variable to the value of an XPath expression. Evaluates a test XPath expression and if it is true, it processes its body. If the test condition is false, the body is ignored. To loop over nodes in an XML document. Simple conditional tag that establishes a context for mutually exclusive conditional operations, marked by <when> and <otherwise> Subtag of <choose> that includes its body if its expression evalutes to 'true' Subtag of <choose> that follows <when> tags and runs only if all of the prior conditions evaluated to 'false' Applies an XSL transformation on a XML document Use along with the transform tag to set a parameter in the XSLT stylesheet

<x:when > <x:otherwise > <x:transform > <x:param >

JSTL Functions: JSTL includes a number of standard functions, most of which are common string manipulation functions. Following is the syntax to include JSTL Functions library in your JSP: <%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %> Following is the list of JSTL Functions: Function fn:contains() fn:containsIgnoreCase() fn:endsWith() fn:escapeXml() fn:indexOf() fn:join() fn:length() fn:replace() fn:split() Description Tests if an input string contains the specified substring. Tests if an input string contains the specified substring in a case insensitive way. Tests if an input string ends with the specified suffix. Escapes characters that could be interpreted as XML markup. Returns the index withing a string of the first occurrence of a specified substring. Joins all elements of an array into a string. Returns the number of items in a collection, or the number of characters in a string. Returns a string resulting from replacing in an input string all occurrences with a given string. Splits a string into an array of substrings.

fn:startsWith() fn:substring() fn:substringAfter() fn:substringBefore() fn:toLowerCase() fn:toUpperCase() fn:trim()

Tests if an input string starts with the specified prefix. Returns a subset of a string. Returns a subset of a string following a specific substring. Returns a subset of a string before a specific substring. Converts all of the characters of a string to lower case. Converts all of the characters of a string to upper case. Removes white spaces from both ends of a string.

Session beans and entity beans compared Session bean Entity bean

Represents a single conversation with a client. Typically, encapsulates persistent business Typically, encapsulates an action or actions to be datafor example, a row in a database. taken on business data. Is relatively short-lived. Is created and used by a single client. Has no primary key. Typically, persists only for the life of the conversation with the client. (However, may choose to save information.) Is not recoverableif the EJB server fails, it may be destroyed. May be stateful (that is, have a client-specific state) or stateless (have no non-transient state). May or may not be transactional. If transactional, can manage its own OTS transactions, or use container-managed transactions. A stateful session bean that manages its own transactions can begin an OTS transaction in one method and commit or roll it back in a subsequent method. A stateless session bean that manages its own transactions and begins an OTS transaction must commit (or roll back) the transaction in the same method in which it was started. The state of a transactional, stateful session bean Is relatively long-lived. May be shared by multiple clients. Has a primary key, which enables an instance to be found and shared by more than one client. Persists beyond the life of a client instance. Persistence can be container-managed or beanmanaged. Is recoverableit survives failures of the EJB server. Is typically stateful. May or may not be transactional. Must use the container-managed transaction model. If transactional, its state is automatically rolled back on transaction rollback.

Session bean is not automatically rolled back on transaction rollback. In some cases, the bean can use session synchronization to react to syncpoint. Is not re-entrant.

Entity bean

May be re-entrant.

Figure 1 illustrates a simple view of the component model for Enterprise JavaBeans.

Architecture :- The component view of an EJB application. The figure shows the following three key players in an EJB application:

The client is a software application that makes use of EJB components. The client can reside on the same computer as the EJB component, or it can reside on a remote computer. The client can also be virtually any type of application. You may have a JavaServer Pages (JSP) application as a client, or a desktop application residing on a user's computer. The client may also be another Enterprise JavaBean. The container is the host for EJB components. It provides a variety of system services to the EJB component so you don't have to develop them yourself. When a client application such as a JSP application invokes a method on an EJB component, the call is passed through the EJB container first. The container performs these extra services and then passes the client's call to the EJB component. Ultimately, the EJB component performs the operations requested by the client. This entire process is completely transparent to the client application; as far as the client is concerned, it thinks it's talking directly to an EJB component. The EJB component is a provider of business services or business data. Business services and business data are processes andinformation that you define and which are specific to the

needs of your business. As an EJB component developer, your development responsibilities are twofold: Your EJB components must implement the methods required by the EJB component architecture. These methods are collectively referred to as the application programming interface (API). The methods defined in the API allow the EJB container to provide system services to your EJB components. They also allow you to make requests to the container to perform certain actions, such as getting the identity of a user. You must implement the business methods required for the application you're developing. That allows the client to receive business services and business data from your EJB component. For example, if you're developing a shopping cart application for your business, you'll need to define methods to add items to the cart and remove items from the cart.

1)))). EJB Advantages

To access EJB free security is provided. Declarative transactions are provided. EJBs are cached & pooled. Containers manage the EJB life cycles. Remote access capabilities are present & are clustered for sake of scalability. OO concepts are supported for example inheritance. Usage of attributes or annotation based programming is possible. Free usage & access of complex resources

EJB Disadvantages

Complicated and large specification Increased time of development Complexities are added in comparison with straight Java classes Potential to create a more essential, costly & complex solution Continual revisions of the specifications Lots of resources are used & have also lots of artifacts. Requires understanding of certain intricacies. For example, granularity and rolling back a transaction, infrastructures like business delegates, value objects, session facades & strategies like dirty marker and lazy loading etc. 2))) Types of EJB: There are three types of Enterprise Java Beans namely: Session Beans Entity Beans Message driven beans

1) Session Beans

Session beans are intended to allow the application author to easily implement portions of application code in middleware and to simplify access to this code. Session beans are divided into two types: a) Stateless Session Bean b) State full Session Bean a) Stateless Session Bean Stateless Session Bean is intended to be simple and light weight components. The client, thereby making the server highly scalable, if required, maintains any state. Since no state is maintained in this bean type, stateless session beans are not tied to any specific client, hence any available instance of a stateless session bean can be used to service a client. b) State full Session Bean State full Session Bean provides easy and transparent state management on the server side. Because state is maintained in this bean type, the application server manages client/bean pairs. State full session beans can access persistent resources on behalf of the client, but unlike entity beans, they do not actually represent the data.

Answer 2 Session EJBs Implement Business Logic Session beans implement business logic. A session bean instance serves one client at a time. There are two types of session beans: stateful and stateless. Stateless Session Beans A stateless session bean does not store session or client state information between invocationsthe only state it might contain is not specific to a client, for instance, a cached database connection or a reference to another EJB. At most, a stateless session bean may store state for the duration of a method invocation. When a method completes, state information is not retained. Any instance of a stateless session bean can serve any clientany instance is equivalent. Stateless session beans can provide better performance than stateful session beans, because each stateless session bean instance can support multiple clients, albeit one at a time. Example: An Internet application that allows visitors to click a Contact Us link and send an email could use a stateless session bean to generate the email, based on the to and from information gathered from the user by a JSP. Stateful Session Beans Stateful session beans maintain state information that reflects the interaction between the bean and a particular client across methods and transactions. A stateful session bean can manage interactions between a client and other enterprise beans, or manage a workflow. Example: A company Web site that allows employees to view and update personal profile information could use a stateful session bean to call a variety of other beans to provide the services required by a user, after the user clicks View my Data on a page:

Accept the login data from a JSP, and call another EJB whose job it is to validate the login data. Send confirmation of authorization to the JSP. Call a bean that accesses profile information for the authorized user.

Entity EJBs Maintain Persistent Data An entity bean represents a set of persistent data, usually rows in a database, and provides methods for maintaining or reading that data. An entity bean is uniquely identified by a primary key, and can provide services to multiple clients simultaneously. Entity beans can participate in relationships with other entity beans. The relationships between entity beans are a function of the real-world entities that the entity beans model. An entity beans fields and its relationships to other entity beans are defined in an object schema, which is specified in the beans ejb-jar.xmldeployment descriptor. An entity bean can have other bean types, such as message-driven or session beans, as clients, or be directly accessed by Web components. The client uses the entity bean to access data in a persistent store. An entity bean encapsulates the mechanics of database access, isolating that complexity from its clients and de-coupling physical database details from business logic. Example: The stateful session bean in the previous example, which orchestrates services for an employee accessing personal profile information on a company intranet, could use an entity bean for getting and updating the employees profile. Message-Driven Beans Implement Loosely Coupled Business Logic A message-driven bean implements loosely coupled or asynchronous business logic in which the response to a request need not be immediate. A message-driven bean receives messages from a JMS Queue or Topic, and performs business logic based on the message contents. It is an asynchronous interface between EJBs and JMS. Throughout its lifecycle, an MDB instance can process messages from multiple clients, although not simultaneously. It does not retain state for a specific client. All instances of a message-driven bean are equivalentthe EJB container can assign a message to any MDB instance. The container can pool these instances to allow streams of messages to be processed concurrently. The EJB container interacts directly with a message-driven beancreating bean instances and passing JMS messages to those instances as necessary. The container creates bean instances at deployment time, adding and removing instances during operation based on message traffic. Example: In an on-line shopping application, where the process of taking an order from a customer results in a process that issues a purchase order to a supplier, the supplier ordering process could be implemented by a messagedriven bean. While taking the customer order always results in placing a

supplier order, the steps are loosely coupled because it is not necessary to generate the supplier order before confirming the customer order. It is acceptable or beneficial for customer orders to stack up before the associated supplier orders are issued.

Question next;;; <?xml version="1.0" encoding="UTF-8"?> <application-client version="5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application-client_5.xsd"> <description>Accessing Database Application</description> <display-name>Secure-app-client</display-name><enterprise-beans> <session> <ejb-name>secure</ejb-name> <home>org.glassfish.docs.secure.secureHome</home> <remote>org.glassfish.docs.secure.secure</remote> <ejb-class>org.glassfish.docs.secure.secureBean</ejb-class> <session-type>Stateless</session-type> </session> </enterprise-beans> </application-client> web-app icon 1 ? Is the root of the deployment descriptor for a web application. Contains small-icon and large-icon elements that specify the file names for small and a large GIF or JPEG icon images used to represent the parent element in a GUI tool. Contains a short name that is intended to be displaye d by tools. The display name need not be unique. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description.

display-name

description

distributable

This empty element indicates that this web application is programmed appropriately to be deployed into a distributed servlet container. Contains the declaration of a web application's servlet context initialization parameters. You set each context-param within a single contextparam element, using <param-name> and <paramvalue> elements. You can access these parameters in your code using the javax.servlet.ServletContext.getInitParameter() and javax.servlet.ServletContext.getInitParameterNames() methods. Contains the name of a parameter. Each parameter name must be unique in the web application. Contains the value of a parameter. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The filter is mapped to either a servlet or a URL pattern in the filter-mapping element, using the filtername value to reference. Filters can access the initialization parameters declared in the deployment descriptor at runtime via the FilterConfig interface. Contains small-icon and large-icon elements that specify the file names for small and a large GIF or JPEG icon images used to represent the parent element in a GUI tool. Specify the file name for a small (16 x 16) GIF or JPEG icon image used to represent the parent element in a GUI tool. The file name is a relative path within the web application's war file. Example: <small-icon>employee-service-icon16x16.jpg</smallicon> Specify the file name for a large (32 x 32) GIF or JPEG icon image used to represent the parent element in a GUI tool.

context-param

param-name param-value

1 1

description

filter

icon

small-icon ?

large-icon ?

The file name is a relative path within the web application's war file. Example:

<large-icon>employee-service-icon32x32.jpg</largeicon> The logical name of the filter. This name is used to map the filter and corresponds to the name assigned in the <filter-mapping> element with the <filter-name> element. Each filter name is unique within the web application. Contains a short name that is intended to be displayed by tools. The display name need not be unique. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The fully qualified classname of the filter. Contains a name/value pair as an initialization param of the filter. Contains the name of a parameter. Each parameter name must be unique in the web application. Contains the value of a parameter. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The container uses the filter-mapping declarations to decide which filters to apply to a request, and in what order. The container matches the request URI to a Servlet in the normal way. To determine which filters to apply it matches filter-mapping declarations either on servlet-name, or on url-pattern for each filtermapping element, depending on which style is used. The order in which filters are invoked is the order in which filter-mapping declarations that match a request URI for a servlet appear in the list of filter-mapping elements. The filter-name value must be the value of the <filter-name> sub-elements of one of the <filter> declarations in the deployment descriptor. The logical name of the filter. This name corresponds to the name assigned in the <filter> element with the <filter-name> element. Each filter name is unique within the web application. If servlet-name element is used it contains the canonical name of the servlet. Each servlet name is unique within the web application. 1 If url-pattern element is used it contains the url pattern of the mapping. Describes a pattern used to resolve URLs. The portion of the URL after the http://host:port

filter-name

display-name

description

filter-class init-param paramname paramvalue

1 * 1 1

descriptio ? n

filter-mapping

filter-name

url-pattern | servlet-name

+ ContextPath is compared to the <url-pattern> by the Application Server. If the patterns match, the filter mapped in this element is called. Example patterns: /process/request/* /foo/* /contents *.do Must follow the rules specified in Section 11.2 of the Servlet API Specification. listener * Define an application listener using the listener element. Declares a class in the application must be registered as a web application listener bean. The value is the fully qualified classname of the listener class. For example: <listener> <listener-class> com.xyz.demo.ContextListener </listener-class> </listener> <listener> <listener-class> com.xyz.demo.SessionListener </listener-class> </listener> Contains the declarative data of a servlet. If a jsp-file is specified and the load-on-startup element is present, then the JSP should be precompiled and loaded when the Application Server starts. Contains small-icon and large-icon elements that specify the file names for small and a large GIF or JPEG icon images used to represent the parent element in a GUI tool. Specify the file name for a small (16 x 16) GIF or JPEG icon image used to represent the parent element in a GUI tool. The file name is a relative path within the web application's war file. Example: <small-icon>employee-service-icon16x16.jpg</smallicon>

listener-class

servlet

icon

small-icon ?

Specify the file name for a large (32 x 32) GIF or JPEG icon image used to represent the parent element in a GUI tool. The file name is a relative path within the web application's war file. Example: <large-icon>employee-service-icon32x32.jpg</largeicon> servlet-name display-name 1 ? The servlet-name element contains the canonical name of the servlet. Each servlet name is unique within the web application. Contains a short name that is intended to be displayed by tools. The display name need not be unique. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. Use only one of either the <servlet-class> tags or <jsp-file> tags in your servlet body: servlet-class|jspfile If the jsp-file element is used it contains the full path to a JSP file within the web application beginning with a "/". If the servlet-class element is used it contains the fully qualified class name of the servlet. Contains a name/value pair as an initialization param of the servlet. init-param * You can access these parameters with the javax.servlet.ServletConfig.getInitParameter() method. paramname paramvalue 1 1 Contains the name of a parameter. Each parameter name must be unique in the web application. Contains the String value of a parameter. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. Indicates that this servlet should be loaded (instantiated and have its init() called) on the startup of the web application. load-on-startup ? The optional content of this element must be an integer indicating the order in which the servlet should be loaded.

large-icon ?

description

descriptio ? n

If the value is a negative integer, or the element is not present, the container is free to load the servlet whenever it chooses. If the value is a positive integer or 0, the container must load and initialize the servlet as the application is deployed. The container must guarantee that servlets marked with lower integers are loaded before servlets marked with higher integers. The container may choose the order of loading of servlets with the same load-onstart-up value. run-as ? The run-as element specifies the run-as identity to be used for the execution of the web application. It contains an optional description, and the name of a security role. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The role-name element contains the name of a security role. This can be a role name that is mapped to a principal name in deployment plan. The name must conform to the lexical rules for an NMTOKEN. Contains the declaration of a security role reference in the web application's code. The <security-role-ref> element links a security role name defined by <security-role> to an alternative role name that is hard-coded in the servlet logic. This extra layer of abstraction allows the servlet to be configured at deployment without changing servlet code If the security role is not specified, the Deployer must choose an appropriate security role. descriptio ? n Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The security role name used in the code. The value must be the String used as the parameter to the EJBContext.isCallerInRole(String roleName) method or the HttpServletRequest.isUserInRole(String role) method. The <role-link> element is a reference to a defined <security-role>. The servlet-mapping element defines a mapping between a servlet and a url pattern. The <servlet-name> element contains the canonical

descriptio ? n

role-name 1

security-role-ref

role-name 1

role-link servlet-mapping servlet-name

? * 1

name of the servlet. This name corresponds to the name you assigned in the <servlet-name> element in the <servlet> element. Each servlet name is unique within the web application. Contains the url pattern of the mapping. Describes a pattern used to resolve URLs. The portion of the URL after the http://host:port + WebAppName is compared to the <url-pattern> by the Application Server. If the patterns match, the servlet mapped in this element will be called. url-pattern 1 Example patterns: /process/request/* /foo/* /contents *.do Must follow the rules specified in Section 11.2 of the Servlet API Specification. session-config ? Defines the session parameters for this web application. The session-timeout element defines the default session timeout interval for all sessions created in this web application. The specified timeout must be expressed in a whole number of minutes. If the timeout is 0 or less, the container ensures the default behaviour of sessions is never to time out. The mime-mapping element defines a mapping between an extension and a mime type. Contains a string describing an extension. example: "txt" The mime-type element contains a defined mime type. example: "text/plain" Contains an ordered list of welcome files elements. When the URL request is a directory name, the Application Server serves the first file specified in the <welcome-file> element. If that file is not found, the server then tries the next file in the list. Contains file name to use as a default welcome file, for example: welcome-file + <welcome-file>index.html</welcome-file> <welcome-file>index.jsp</welcome-file> <welcome-file>start.do</welcome-file> Contains a mapping between an error code or exception type to the path of a resource in the web application.

session-timeout

mime-mapping extension mime-type

* 1 1

welcome-file-list

error-page

When an error occurs, while the Application Server is responding to an HTTP request, or as a result of a Java exception, the Application Server returns an HTML page that displays either the HTTP error code or a page containing the Java error message. You can define your own HTML page to be displayed in place of these default error pages or in response to a Java exception. Define either an <error-code> or an <exception-type> but not both. error-code | exception-type 1 The error-code contains an HTTP error code, for example: 404. The exception type contains a fully qualified class name of a Java exception type. Contains the location of the resource in the web application relative to the root of the web application. The value of the location must have a leading "/", for example: /myErrorPage.html taglib * Is used to describe a JSP tag library. This element associates the location of a JSP Tag Library Descriptor (TLD) with a URI pattern. Describes a URI, relative to the location of the web.xml document, identifying a Tag Library used in the Web Application. If the URI matches the URI string used in the taglib directive on the JSP page, this taglib is used. Contains the location (as a resource relative to the root of the web application) where to find the Tag Libary Description file for the tag library. It is a good idea to store the tag library descriptor file under the WEB-INF directory so it is not publicly available over an HTTP request. Contains a declaration of a web application's reference to an administered object associated with a resource in the web application's environment. It consists of an optional description, the resource environment reference name, and an indication of the resource environment reference type expected by the web application code. resource-env-ref * Example: <resource-env-ref> <resource-env-ref-name>jms/StockQueue</resourceenv-ref-name> <resource-env-ref-type>javax.jms.Queue</resourceenv-ref-type>

location

taglib-uri

taglib-location

</resource-env-ref> Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. Specifies the name of a resource environment reference; its value is the environment entry name used in the web application code. The name is a JNDI name relative to the java:comp/env context and must be unique within a web application. Specifies the type of a resource environment reference. It is the fully qualified name of a Java language class or interface. The resource-ref element defines a reference lookup name to an external resource. This allows the servlet code to look up a resource by a "virtual" name that is mapped to the actual location at deployment time. Use a separate <resource-ref> element to define each external resource name. The external resource name is mapped to the actual location name of the resource at deployment time in the Application Server deployment plan. The resource-ref element consists of an optional description, the resource manager connection factory reference name, the indication of the resource manager connection factory type expected by the web application code, the type of authentication (Application or Container), and an optional specification of the shareability of connections obtained from the resource (Shareable or Unshareable). <resource-ref> <res-ref-name>jdbc/EmployeeAppDB</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> <res-sharing-scope>Shareable</res-sharing-scope> </resource-ref> Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The name of the resource used in the JNDI tree. Servlets in the Web Application use this name to look up a reference to the resource. The name is a JNDI name relative to the java:comp/env context. The name must be unique

description

resource-env-refname

resource-env-reftype

resource-ref

description

res-ref-name

within a web application. res-type 1 Specifies the type of the data source. The type is specified by the fully qualified Java language class or interface expected to be implemented by the data source. Specifies whether the web application code signs on programmatically to the resource manager, or whether the Container will sign on to the resource manager on behalf of the web application. In the latter case, the Container uses information that is supplied by the Deployer. The value of this element must be one of the two following: <res-auth>Application</res-auth> <res-auth>Container</res-auth> The res-sharing-scope element specifies whether connections obtained through the given resource manager connection factory reference can be shared. The value of this element, if specified, must be one of the two following: res-sharing-scope ? <res-sharing-scope>Shareable</res-sharing-scope> <res-sharing-scope>Unshareable</res-sharingscope> The default value is Shareable. security-constraint display-name * ? The <security-constraint> element defines the access privileges to a collection of resources defined by the <web-resource-collection> element. Contains a short name that is intended to be displayed by tools. The display name need not be unique. Is used to identify a subset of the resources and HTTP methods on those resources within a web application to which a security constraint applies. If no HTTP methods are specified, then the security constraint applies to all HTTP methods. Contains the name of this web resource collection. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. Use one or more of the <url-pattern elements to declare to which URL patterns this security constraint applies. Must follow the rules specified in Section 11.2 of the

res-auth

web-resourcecollection

webresource- 1 name descriptio ? n

url-pattern *

Servlet API Specification. httpmethod Use one or more of the <http-method> elements to declare which HTTP methods (usually, GET or POST) are subject to the authorization constraint. If you omit the <http-method> element, the default behavior is to apply the security constraint to all HTTP methods. Indicates the user roles that should be permitted access to this resource collection. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The role-name must either correspond to the rolename of one of the security-role elements defined for this web application, or be the specially reserved rolename "*" that is a compact syntax for indicating all roles in the web application. If both "*" and rolenames appear, the container interprets this as all roles. If no roles are defined, no user is allowed access to the portion of the web application described by the containing security-constraint. The container matches role names case sensitively when determining access. The user-data-constraint element defines how the client should communicate with the server. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. Specifies that the communication between client and server should be NONE, INTEGRAL, or CONFIDENTIAL. NONE means that the application does not require any transport guarantees. A value of INTEGRAL means that the application requires that the data sent between the client and server be sent in such a way that it can't be changed in transit. CONFIDENTIAL means that the application requires that the data be transmitted in a fashion that prevents other entities from observing the contents of the transmission. In most cases, the presence of the INTEGRAL or CONFIDENTIAL flag will indicate that the use of SSL is required. login-config ? The login-config element is used to configure the

auth-constraint

descriptio ? n

role-name *

user-dataconstraint

descriptio ? n

transport1 guarantee

authentication method that should be used, the realm name that should be used for this application, and the attributes that are needed by the form login mechanism. Used to configure the authentication mechanism for the web application. As a prerequisite to gaining access to any web resources which are protected by an authorization constraint, a user must have authenticated using the configured mechanism. Legal values for this element are "BASIC", "DIGEST", "FORM", or "CLIENT-CERT". Specifies the realm name to use in HTTP Basic authorization. Specifies the login and error pages that should be used in form based login. If form based authentication is not used, these elements are ignored. Defines the location in the web app where the page that can be used for login can be found. The path begins with a leading / and is interpreted relative to the root of the WAR. Defines the location in the web app where the error page that is displayed when login is not successful can be found. The path begins with a leading / and is interpreted relative to the root of the WAR. Contains the definition of a security role. The definition consists of an optional description of the security role, and the security role name. <security-role> <description> This role includes all employees who are authorized to access the employee service application. </description> <role-name>employee</role-name> </security-role> Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description. The role-name element contains the name of a security role. The name must conform to the lexical rules for an NMTOKEN. Contains the declaration of a web application's environment entry. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description.

auth-method

realm-name form-login-config

? ?

form1 login-page

form1 error-page

security-role

description

role-name env-entry

1 *

description

env-entry-name

Contains the name of a web applications's environment entry. The name is a JNDI name relative to the java:comp/env context. The name must be unique within a web application. Example: <env-entry-name>minAmount</env-entry-name> Contains the value of a web application's environment entry. The value must be a String that is valid for the constructor of the specified type that takes a single String parameter, or for java.lang.Character, a single character. If a value is not specified, one must be supplied during deployment. Example: <env-entry-value>100.00</env-entry-value> Contains the fully-qualified Java type of the environment entry value that is expected by the web application's code. The following are the legal values of env-entry-type: java.lang.Boolean java.lang.Byte java.lang.Character java.lang.String java.lang.Short java.lang.Integer java.lang.Long java.lang.Float java.lang.Double Is used for the declaration of a reference to an enterprise bean's home. The declaration consists of:

env-entry-value

env-entry-type

ejb-ref

an optional description the EJB reference name used in the code of the web application that's referencing the enterprise bean the expected type of the referenced enterprise bean the expected home and remote interfaces of the referenced enterprise bean optional ejb-link information, used to specify the referenced enterprise bean

description

Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description.

The ejb-ref-name element contains the name of an EJB reference. The EJB reference is an entry in the web application's environment and is relative to the java:comp/env context. The name must be unique within the web application. ejb-ref-name 1 It is recommended that name is prefixed with "ejb/". Example: <ejb-ref-name>ejb/Payroll</ejb-ref-name> The expected type of the referenced enterprise bean. The ejb-ref-type element must be one of the following: ejb-ref-type 1 <ejb-ref-type>Entity</ejb-ref-type> <ejb-reftype>Session</ejb-ref-type> The home element contains the fully-qualified name of the enterprise bean's home interface. home 1 Example: <home>com.aardvark.payroll.PayrollHome</home> Contains the fully-qualified name of the enterprise bean's remote interface. remote 1 Example: <remote>com.wombat.empl.EmployeeService</remot e> To specify that an EJB reference is linked to an enterprise bean. The name in the ejb-link element is composed of a path name specifying the ejb-jar containing the referenced enterprise bean with the ejb-name of the target bean appended and separated from the path name by "#". The path name is relative to the war file containing the web application that is referencing the enterprise bean. This allows multiple enterprise beans with the same ejb-name to be uniquely identified. Examples: <ejb-link>EmployeeRecord</ejb-link> <ejb-link>../products/product.jar#ProductEJB</ejblink> ejb-local-ref * The ejb-local-ref element is used for the declaration of a reference to an enterprise bean's local home. Should include any information that the web application war file producer wants to provide to the deployer. Tools used by the deployer will display the description when processing the parent element that contains the description.

ejb-link

description

ejb-ref-name

The EJB reference name used in the code of the web application that's referencing the enterprise bean The expected type of the referenced enterprise bean. The ejb-ref-type element must be one of the following:

ejb-ref-type

1 <ejb-ref-type>Entity</ejb-ref-type> <ejb-reftype>Session</ejb-ref-type>

local-home local

1 1

The local-home element contains the fully-qualified name of the enterprise bean's local home interface. Contains the fully-qualified name of the enterprise bean's local interface. To specify the referenced enterprise bean. The name in the ejb-link element is composed of a path name specifying the ejb-jar containing the referenced enterprise bean with the ejb-name of the target bean appended and separated from the path name by "#". The path name is relative to the war file containing the web application that is referencing the enterprise bean. This allows multiple enterprise beans with the same ejb-name to be uniquely identified. Examples: <ejb-link>EmployeeRecord</ejb-link> <ejb-link>../products/product.jar#ProductEJB</ejblink>

ejb-link