It is stated that the new EJB 3. This is attributed to the major modifications to the EJB 2. Replacement of the DTD that identified the ejb-jar. While the introduction of session beans altered the added reinforcement for internet service, EJB 3. Furthermore, they can work outside an EJB container. When EJB 2. Introduction of improved methods like use of metadata annotations and other mechanisms used to create the Java codes and XML descriptors, unlike the EJB 2.
The EJB 2. EJB 3. This is because the annotations possess as a suitable replacement for the allocation descriptors. You are able to use default values more often when using the EJB 3. It is easy to work with the EJB 3. Java codes are easily generated by the improved applications in the EJB 3.
Difference Between EJB 2. In addition, critical elements of the bean, including its transaction and security definition, and whether it was stateful or stateless, were defined in the associated deployment descriptors.
Listing 1 illustrates an example of a stateful session bean defined using the EJB 2. In the EJB 3. The home interface has been removed. The business interface does not need to extend the EJBObject or the EJBLocalObject interface; instead, if required, it could be defined within the interface hierarchy that represents the business domain model.
It does not implement an EnterpriseBean type. The declaration and the configuration in the deployment descriptor can be defined within the Java code, using the annotations metadata facility.
In addition, default values are provided for most configurations, thus minimizing the bean-specific configuration requirements. Under the new specification, one could deploy session beans without any ejb-jar. In the case of EJB 3. Session beans that serve as Web service endpoints are annotated as a WebService.
Listing 2 illustrates the earlier example from Listing 1 of the stateful session bean using the EJB 3. The callback methods were implemented in the bean class and the container, on a particular event called the corresponding method. Message-driven beans never involved the concept of a home and a remote, or local, interface. In EJB 3. The deployment descriptor can also be used to specify a bean as message-driven. Thus, it is not required for the bean class to implement the MessageDrivenBean interface.
The business interface of a message-driven bean is the message listener interface that corresponds to the message type that the bean is a listener for. In the case of Java Message Service, javax.
MessageListener is the message listener interface or the business interface. The bean class needs to implement the message listener interface or annotate the message listener interface using the MessageDriven annotation.
The scheduling functionality takes the form of CRON-styled schedule definitions that can be placed on EJB methods, in order to have the methods be automatically invoked according to the defined schedule.
EJB 3. Automatically created timers are created by the container as a result of application deployment. Unlike traditional Java EE server-based execution, embeddable usage allows client code and its corresponding enterprise beans to run within the same virtual machine and class loader.
This provides better support for testing, offline processing e. JPA 2. Although JPA 2. You are no longer required to create the EJB deployment descriptor files such as ejb-jar. You can now use metadata annotations in the bean file itself to configure metadata. You are still allowed, however, to use XML deployment descriptors if you want; in the case of conflicts, the deployment descriptor value overrides the annotation value. The only required metadata annotation in your bean file is the one that specifies the type of EJB you are writing javax.
Stateless , javax. Stateful , javax. MessageDriven , or javax. The default value for all other annotations reflect typical and standard use of EJBs.
This reduces the amount of code in your bean file in the case where you are programming a typical EJB; you only need to use additional annotations if the default values do not suit your needs. SessionBean or javax. As a result of not having to implement javax. MessageDrivenBean , the bean file no longer has to implement the lifecycle callback methods, such as ejbCreate , ejbPassivate , and so on. If, however, you want to implement these callback methods, you can name them anything you want and then annotate them with the appropriate annotation, such as javax.
Session beans may expose client views via business interfaces. Session beans may either explicitly implement the business interface or they can specify it using the javax.
Remote or javax. Local annotations. EJBObject or javax. The business interface methods may not throw java. RemoteException unless the business interface extends java. Bean files supports dependency injection. Dependency injection is when the EJB container automatically supplies or injects a variable or setter method in the bean file with a reference to another EJB or resource or another environment entry in the bean's context.
Bean files support interceptors, which is a standard way of using aspect-oriented programming with EJB. You can configure two types of interceptor methods: those that intercept business methods and those that intercept lifecycle callbacks. Because the EJB 3. Rather, you can use this tool only on 2. Session beans implement business logic. There are three types of session beans: stateful, stateless, and singleton. Stateful and stateless session beans serve one client at a time; whereas, singleton session beans can be invoked concurrently.
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:.
A stateless session bean does not store session or client state information between invocations—the 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 client—any 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.
0コメント