Paper II: Unit 4: Chap 1 & 2: EJB

3. Java Enterprise Beans - EJB

3. Although transparent to the application developer, the EJB container provides system-level services such as transactions and security to its enterprise beans. 4. These services enable you to quickly build and deploy enterprise beans, which form the core of transactional Java EE applications. 5. An enterprise bean is written in the Java programming language, and it is a server-side component that contains the business logic of an application. The business logic is the code that fulfills the purpose of the application. In an inventory control application, for example, the enterprise beans might implement the business logic in methods called checkInventoryLevel and orderProduct. 6. By invoking these methods, remote clients can access the inventory services provided by the application.

1.

What are the benefits of EJB? 1. Enterprise beans simplify the development of large, distributed applications. 2. The EJB container provides system-level services to enterprise beans, the bean developer can concentrate on solving business problems. 3. The EJB containerand not the bean developeris responsible for system-level services such as transaction management and security authorization. 4. Because the beansand not the clientscontain the applications business logic, the client developer can focus on the presentation of the client. The client developer does not have to code the routines that implement business rules or access databases. As a result, the clients are thinner, a benefit that is particularly important for clients that run on small devices. 5. Because enterprise beans are portable components, new applications can be built from existing beans. These applications can run on any compliant Java EE server provided that they use the standard APIs.

mukeshtekwani@outlook.com

Prof. Mukesh N. Tekwani

EJB

2.

When to use Enterprise Beans? Enterprise beans should be used if your application has any of the following requirements: 1. The application must be scalable. To accommodate a growing number of users, you may need to distribute an applications components across multiple machines. Not only can the enterprise beans of an application run on different machines, but also their location will remain transparent to the clients. 2. Transactions must ensure data integrity. Enterprise beans support transactions, which are the mechanisms that manage the concurrent access of shared objects. 3. The application will have a variety of clients. With only a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous. What are the types of Enterprise Beans?

3.

4.

What is a session bean? What are the two types of session beans (or state management modes) ? 1. A session bean represents a single client inside the Application Server. 2. To access an application that is deployed on the server, the client invokes the session beans methods. 3. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server. 4. As its name suggests, a session bean is similar to an interactive session. 5. A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. 6. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a database.) 7. When the client terminates, its session bean appears to terminate and is no longer associated with the client. There are two types of session beans: stateful session bean and stateless session bean. STATEFUL SESSION BEAN: 1. The state of an object consists of the values of its instance variables. 2. In a stateful session bean, the instance variables represent the state of a unique client-bean session. 3. Because the client interacts (talks) with its bean, this state is often called the conversational state. 4. The state is retained for the duration of the client-bean session. 5. If the client removes the bean or terminates, the session ends and the state disappears. 6. 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. 7. When to use stateful session beans? Stateful session beans are appropriate if any of the following conditions are true: a. The beans state represents the interaction between the bean and a specific client. b. The bean needs to hold information about the client across method invocations. c. The bean mediates between the client and the other components of the application,

Prof. Mukesh N Tekwani

mukeshtekwani@outlook.com

EJB

presenting a simplified view to the client. d. Behind the scenes, the bean manages the work flow of several enterprise beans.

STATELESS SESSION BEAN: 1. A stateless session bean does not maintain a conversational state with the client. 2. When a client invokes the method of a stateless bean, the beans instance variables may contain a state, but only for the duration of the invocation. 3. When the method is finished, the state is no longer retained. 4. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. 5. Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. 6. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients. 7. Under certain circumstances, the EJB container may write a stateful session bean to secondary storage. 8. But, stateless session beans are never written to secondary storage. 9. Therefore, stateless beans may offer better performance than stateful beans, as the act of retrieving a stateful session bean from secondary storage adds latency to bean activation. 10. When to use stateless session bean? It is used when a. The beans state has no data for a specific client. b. 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 email that confirms an online order.

5.

What is a message driven bean? 1. A message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. 2. It normally acts as a JMS (Java Message Service) message listener, which is similar to an event listener except that it receives JMS messages instead of events. 3. The messages can be sent by any Java EE componentan application client, another enterprise bean, or a web componentor by a JMS application or system that does not use Java EE technology. Message-driven beans can process JMS messages or other kinds of messages. What are the differences between message-driven beans and session-driven beans? 1. The main difference between message-driven beans and session and entity beans is that clients do not access message-driven beans through interfaces. 2. Unlike a session or entity bean, a message-driven bean has only a bean class. 3. In several respects, a message-driven bean resembles a stateless session bean. 4. A message-driven beans instances retain no data or conversational state for a specific client. 5. All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. 6. The container can pool these instances to allow streams of messages to be processed concurrently. 7. A single message-driven bean can process messages from multiple clients. The instance variables of the message-driven bean instance can contain some state across the handling of client messagesfor example, a JMS API connection, an open database connection, or an object reference to an enterprise bean object. Characteristics of message-driven beans: Message-driven beans have the following characteristics: They execute upon receipt of a single client message.

6.

mukeshtekwani@outlook.com

Prof. Mukesh N. Tekwani

EJB
They are invoked asynchronously. They are relatively short-lived. They do not represent directly shared data in the database, but they can access and update data. They can be transaction-aware. They are stateless.

this

7.

What are the characteristics of a message-driven bean? 1. Refer Q 7 above What are the characteristics of a remote client of an enterprise bean? What are the different ways to create an enterprise bean that allows remote access? A remote client of an enterprise bean has the following traits or characteristics : 1. It can run on a different machine and a different Java virtual machine (JVM) than the enterprise bean it accesses. (It is not required to run on a different JVM.) 2. It can be a web component, an application client, or another enterprise bean. 3. To a remote client, the location of the enterprise bean is transparent. 1. To create an enterprise bean that has remote access, you must annotate the business interface of the enterprise bean as a @Remote interface. 2. The remote interface defines the business and lifecycle methods that are specific to the bean. 3. For example, the remote interface of a bean named BankAccountBean might have business methods named deposit and credit. Figure below shows how the interface controls the clients view of an enterprise bean.

8.

9.

What are the characteristics of a local client of an enterprise bean? A local client has these characteristics: It must run in the same JVM as the enterprise bean it accesses. It can be a web component or another enterprise bean. To the local client, the location of the enterprise bean it accesses is not transparent. You must annotate the business interface of the enterprise bean as a @Localinterface. The local interface defines the beans business and lifecycle methods.

10.

What are the factors which decide whether to allow local or remote access? Following factors are important to decide whether to allow local or remote access: Tight or loose coupling of related beans: Tightly coupled beans depend on one another. For example, a completed sales order must email the customer a confirmation message upon completion of the order. If the SalesOrder stateful session bean, which contains the business logic of an ordering application, calls the CustomerContact stateless session bean to email the

Prof. Mukesh N Tekwani

mukeshtekwani@outlook.com

EJB

order confirmation to the customer, these session beans would be described as tightly coupled. Tightly coupled beans are have local access. Because they fit together as a logical unit, they typically call each other often and would benefit from the increased performance that is possible with local access. Type of client: If an enterprise bean is accessed by application clients, then it should allow remote access. In a production environment, these clients almost always run on different machines than the Application Server. If an enterprise beans clients are web components or other enterprise beans, then the type of access depends on how you want to distribute your components. Component distribution: Java EE applications are scalable because their server-side components can be distributed across multiple machines. In a distributed application the web components may run on a different server than do the enterprise beans they access. In this distributed scenario, the enterprise beans should allow remote access. Performance: Due to factors such as network latency, remote calls may be slower than local calls. On the other hand, if you distribute components among different servers, you may improve the applications overall performance. Both of these statements are generalizations; actual performance can vary in different operational environments. 11. What is the life cycle of a Stateful Session Bean?

The client initiates the life cycle by obtaining a reference to a stateful session bean. The container performs any dependency injection and then invokes the method annotated with @PostConstruct, if any. The bean is now ready to have its business methods invoked by the client. While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by moving it from memory to secondary storage. (Typically, the EJB container uses a least-recently-used algorithm to select a bean for passivation.) The EJB container invokes the method annotated @PrePassivate, if any, immediately before passivating it. If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean, calls the method annotated @PostActivate, if any, and then moves it to the ready stage.

mukeshtekwani@outlook.com

Prof. Mukesh N. Tekwani

EJB

At the end of the life cycle, the client invokes a method annotated @Remove, and the EJB container calls the method annotated @PreDestroy. The beans instance is then ready for garbage collection.

12.

What is the life cycle of a Stateless Session Bean?

A stateless session bean is never passivated, so its life cycle has only two stages: nonexistent and ready for the invocation of business methods. The client initiates the life cycle by obtaining a reference to a stateless session bean. The container performs any dependency injection and then invokes the method annotated @PostConstruct, if any. The bean is now ready to have its business methods invoked by the client. At the end of the life cycle, the EJB container calls the method annotated @PreDestroy. The beans instance is then ready for garbage collection.

13.

What is the life cycle of a Message-Driven Bean?

The EJB container usually creates a pool of message-driven bean instances. The EJB container performs these tasks: 1. If the message-driven bean uses dependency injection, the container injects these references before instantiating the instance

Prof. Mukesh N Tekwani

mukeshtekwani@outlook.com

EJB

2. The container calls the method annotated @PostConstruct, if any. A message-driven bean is never passivated, and it has only two states: nonexistent and ready to receive messages. At the end of the life cycle, the container calls the method annotated @PreDestroy, if any. The beans instance is then ready for garbage collection. 14. Write a note on JAX-WS 1. JAX-WS stands for Java API for XML Web Services. 2. JAX-WS is a technology for building web services and clients that communicate using XML. 3. JAX-WS allows developers to write message-oriented web services. 4. In JAX-WS, a web service operation invocation is represented by an XML-based protocol such as SOAP (Simple Object Access Protocol). 5. The SOAP specification defines the envelope structure, encoding rules, and conventions for representing web service invocations and responses. These calls and responses are transmitted as SOAP messages (XML files) over HTTP. 6. Although SOAP messages are complex, the JAX-WS API hides this complexity from the application developer. 7. On the server side, the developer specifies the web service operations by defining methods in an interface written in the Java programming language. 8. The developer also codes one or more classes that implement those methods. Client programs are also easy to code. A client creates a proxy (a local object representing the service) and then simply invokes methods on the proxy. 9. With JAX-WS, the developer does not generate or parse SOAP messages. It is the JAX-WS runtime system that converts the API calls and responses to and from SOAP messages. 10. With JAX-WS, clients and web services have a big advantage: the platform independence of the Java programming language. In addition, JAX-WS is not restrictive: a JAX-WS client can access a web service that is not running on the Java platform, and vice versa. This flexibility is possible because JAX-WS uses technologies such as HTTP, SOAP, and the Web Service Description Language (WSDL).

mukeshtekwani@outlook.com

Prof. Mukesh N. Tekwani