Application server@ejb

An application server is an application program that accepts connections in order to service requests, by sending back responses. An application server can run remotely(connected to client through a computer network) or can exist on the same computer where the client application is running.


      File server
      Database server
      Backup server
      Web server
      FTP server
      Application server
      VPN server
      DHCP server
      DNS server
      WINS server
      Logon server
      Security server
      Domain controller
      Backup domain controller
      Proxy server

Application server are developed to support the quick development of the enterprise model. They provide security and state maintenance with the database persistence.

An application server may be a part of a three tier architecture model. A three tier architecture includes the client tier, Middle tier and the EIS(Enterprise information system) tier.

The view tier: is nothing but the web based graphical user interface to interact with the clients.
Middle tier: is the combination of web containers and the ejb containers.
EIS tier: EIS contains persistence and the database management system to support the applications.

J2EE platform requires database to store the business data. This database is accessible by means of JDBC, JDO or SQLJ APIs. We can also access the database through enterprise beans, we components and the application client components.



A session bean represents a single client inside the J2EE server. To access an application that is deployed on the server, the client invokes the session bean’s methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server.

a session bean is similar to an interactive session. A session bean is not shared–it may have just one client, in the same way that an interactive session may have just one user. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a database.) When the client terminates, its session bean appears to terminate and is no longer associated with the client.

Stateful Session Beans:
The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts (“talks”) with its bean, this state is often called the conversational state.The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears. This transient nature of the state is not a problem, however, because when the conversation between the client and the bean ends there is no need to retain the state.

Stateless Session Beans:
A stateless session bean does not maintain a conversational state for a particular client. When a client invokes the method of a stateless bean, the bean’s instance variables may contain a state, but only for the duration of the invocation. When the method is finished, the state is no longer retained. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client.

Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.

At times, the EJB container may write a stateful session bean to secondary storage. However, stateless session beans are never written to secondary storage. Therefore, stateless beans may offer better performance than stateful beans

Things are important:

>> General Session bean
>>> At any given time, only one client has access to the bean instance.
>>> The state of the bean is not persistent, existing only for a short period of time (perhaps a few hours).

>>Stateful session bean
>>> The bean’s state represents the interaction between the bean and a specific client.
>>> The bean needs to hold information about the client across method invocations.
>>> The bean mediates between the client and the other components of the application, presenting a simplified view to the client.
>>> Behind the scenes, the bean manages the work flow of several enterprise beans.

>> To improve performance, you might choose a stateless session bean
>>> The bean’s state has no data for a specific client.
>>> In a single method invocation, the bean performs a generic task for all clients. For example, you might use a stateless session bean to send an e-mail that confirms an online order.
>>> The bean fetches from a database a set of read-only data that is often used by clients. Such a bean, for example, could retrieve the table rows that represent the products that are on sale this month.


Enterprise JavaBeans are server-side, moduler, and reusable components that comprise specific units of functionality. They are similar to the classes we create every day, but are subject to special restrictions and must provide specific interfaces for container and client use and access. In addition, they can only run properly in an EJB container, which manages and invokes specific life cycle behavior. You should consider using EJB components when the application design requires scalability, transactional processing, or availability to multiple client types.

EJB components come in three varieties, each with its own defined role and life cycle:
1. Session beans: These may be either stateful or stateless, and are primarily used to encapsulate business logic, carry out tasks on behalf of a client, and act as controllers or managers for other beans.
2. Entity beans: Entity beans represents persistent objects or business concepts that exist beyond a specific application’s lifetime; they are typically stored in a relational database. Entity beans can be developed using bean-managed persistence, which is implemented by the developer, or container-managed persistence, implemented by the container.
3. Message- driven beans: Message-driven beans listen asynchronously for Java Message Service(JMS) messages from any client or component and are used for loosely coupled, typically batch-type, processing.

EJB Programming Restrictions
1. An enterprise Bean must not use read/write static fields. Using read-only static fields is allowed. Therefore, it is recommended that all static fields in the enterprise bean class be declared as final.

2. An enterprise Bean must not use thread sychronization primitives to synchronize execution of multiple instances.

3. An enterprise Bean must not use the AWT functionality to attempt to output information to a display, or to input information from a keyboard.

4. An enterprise Bean must not use the package to attempt to access files and directories in the file system.

5. An enterprise bean must not use attempt to listen on a socket, accept connections on a socket, or use a socket for multicast.

6. The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the java language. The enterprise bean must nto attempt to use the Reflection API to access information that the security rules of the java programming language make unavailable.

7. The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output and error steams.

8. The enterprise bean must not attempt to set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL.

9. The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread; or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.

10. The enterprise bean must not attempt to directly read or write a file descriptor.

11. The enterprise bean must not attempt to obtain the security policy information for a particular code source.

12. The enterprise bean must not attempt to load a native library.

13. The enterprise bean must not attempt to gain access to packages and classes that the usual rules of the Java programming language maje unavailable to the enterprise bean.

14. The enterprise bean must not attempt to define a class in a package.

15. The enterprise bean must not attempt to access or modify the security configuration objects(Policy, Security, Provider, Signer, and Identity).

16. The enterprise bean must not attempt to use the subclass and object substition features of the Java serialization protocol.

17. The enterprise bean must not attempt to pass this as an argument or method result. The enterprise bean must pass the result of SessionContext.getEJBObject(), SessionContext.getEJBLocalObject(), EntityContext.getEJBObject(), or EntityContext.getEJBLocalObject() instead,