J2EE is not just one technology, but rather a collection of technologies. Sun
defines standards embodied as J2EE, which other vendors implement. For
example, WebLogic implements the following J2EE components:
- JavaServer Pages (JSP)
- Enterprise JavaBeans (EJB)
- Java Transaction Service (JTS)
- Java Message Service (JMS)
- Java Naming and Directory Interface (JNDI)
JavaServer Pages (JSP) allow you to embed Java code directly into HTML-like documents. JSP has access to nearly all the core features of the Java programming language, except you’re returning only streams back to the user’s browser. This allows you to construct complex applications using only JSP. However, just because you can construct complex JSP-based applications does not mean that you should. JSP is best restricted to presentation logic, with more complex business logic delegated to EJBs.
Enterprise JavaBeans (EJB) technology allows code to be executed on a remote system. This remote system is the application server. EJB is commonly used to isolate business logic from presentation logic. EJB coordinates access with the database and shields higher levels, such as JSP, from the need to directly access the database. In this way, if you were to change database servers or the format of your database, all code related to data access would be in one location.
Java Transaction Service
Java Transaction Service (JTS) is a transaction manager that allows requests to be segmented into transactions. These transactions succeed or fail as a whole. This prevents partial transactions from persisting if only a part of the transaction is successful.
Java Message Service
The Java Message Service (JMS) API was developed to allow Java applications to be message driven. A message-compatible EJB can receive and generate messages. These messages can contain any data needed by the program. Messaging is asynchronous, so considerable time can elapse before a response message is received, if at all. JMS also allows messages to be saved to a message store, such as a file or a database.
Java Naming and Directory Interface
Java Naming and Directory Interface (JNDI) is a standard extension to the Java platform that provides naming and directory information to Java programs. This allows EJB and other resources to have names that can be looked up by their client programs. JNDI is a high-level standard and can use any number of underlying name and directory services.
Enterprise applications tie many of the previously mentioned components together into one application. An enterprise application is most commonly made up of a web application and any EJB that may be used by that web application. The entire enterprise application is packaged as a single archive file, which can be easily deployed to a server such as WebLogic. This allows for easy packaging, distribution, and deployment of your enterprise applications.
What are servlet, servlet engine, jsp, static html pages?
Servlet: A Servlet is an object that receives a request (ServletRequest) and generates a response (ServletResponse) based on the request. Servlets are the Java Technologies’ answer to CGI programming. They are programs which run on the server side and generate dynamic content.
Servlet Engine: The servlet engine is a customized extension to a Web server for processing servlets, built in conformance with the Java Servlet API by the Web server vendor. The servlet Engine provides network services, understands MIME requests, and runs servlet Containers.
Java Server Pages (JSP) is a Java technology that allows software developers to dynamically generate HTML, XML or other types of documents in response to a Web client request. The technology allows Java code and certain pre-defined actions to be embedded into static content. JSP is an extension of Servlets technology. Anything that is done in JSP can be done with Servlets, however, JSP allows you to easily mix static HTML with your code. Typically, it is also easier to read the code and visualize the page that will ultimately be generated.
Static HTML Pages: A static Web page is a Web page that always comprises the same information in response to all download requests from all users. When a URI representing a static page is received by a Web server, the server always responds to that request with the same set of HTML (or XHTML) and associated Web content, regardless of the user’s identity or the retrieval context
What is a container in an application server?
A Web application runs within a Web container of a Web server. The Web container provides the runtime environment through components that provide naming context and life cycle management. Web applications are composed of web components and other data such as HTML pages. Web components can be servlets, JSP pages created with the Java Server Pages technology, web filters, and web event listeners. These components typically execute in a web server and may respond to HTTP requests from web clients. Servlets, JSP pages, and filters may be used to generate HTML pages that are an application’s user interface. They may also be used to generate XML or other format data that is consumed by other application components.
An EJB container manages the enterprise beans contained within it. For each enterprise bean, the container is responsible for registering the object, providing a remote interface for the object, creating and destroying object instances, checking security for the object, managing the active state for the object, and coordinating distributed transactions. Optionally, the container can also manage all persistent data within the object.
Enterprise JavaBeans technology supports both transient and persistent objects. A transient object is called a session bean, and a persistent object is called an entity bean.
A session bean exists only for the duration of a single client/server session. A session bean performs operations such as accessing a database or performing calculations. Session beans can be transactional, but normally are not recoverable following a system crash. Session beans can be stateless, or they can maintain conversational state across methods and transactions. A session bean must manage its own persistent data.
An EJB container can hold three major categories of beans:
Stateful Session Beans : An EJB that holds information from one invocation to the next. Holding this information requires overhead, so stateful session beans should be used sparingly.
Stateless Session Beans : An EJB that doesn’t hold any information from one invocation to the next. This is the most commonly used EJB.
Entity Beans : A bean that represents some form of persistent data. An entity bean usually corresponds to one record of data.
Message Beans : An EJB that receives JMS messages.
Stateless Session Beans are distributed objects that do not have state associated with them thus allowing concurrent access to the bean. The contents of instance variables are not guaranteed to be preserved across method calls. The lack of overhead to maintain a conversation with the calling program makes them less resource-intensive than stateful beans.
Stateful Session Beans are distributed objects having state, that is, they keep track of which calling program they are dealing with throughout a session. For example, checking out in a web store might be handled by a stateful session bean, which would use its state to keep track of where the customer is in the checkout process. On the other hand, sending an e-mail to customer support might be handled by a stateless bean, since this is a one-off operation and not part of a multi-step process. Stateful session bean’s state may be persisted, but access to the bean instance is limited to only one client.
Entity Beans are distributed objects having persistent state. An entity bean represents a business object in a persistent storage mechanism.The persistent state may or may not be managed by the bean itself. Beans in which their container manages the persistent state are said to be using Container-Managed Persistence (CMP), whereas beans that manage their own state are said to be using Bean-Managed Persistence (BMP).
Message Driven Beans are distributed objects that behave asynchronously. That is, they handle operations that do not require an immediate response. For example, a user of a website clicking on a “keep me informed of future updates” box may trigger a call to a Message Driven Bean to add the user to a list in the company’s database. (This call is asynchronous because the user does not need to wait to be informed of its success or failure.) These beans subscribe to JMS ( Java Message Service ) message queues or message topics. They were added in the EJB 2.0 specification to allow event-driven processing inside EJB Container. Unlike other types of beans, MDB does not have a client view (Remote/Home interfaces), i.e. clients can not look-up an MDB instance. It just listens for any incoming message on a JMS queue (or topic) and processes them automatically