I. Comparison between EJB 2.0 and 3.0
Oracle’s Weblogic Server’s (OWLS) support for EJB 3.0 specification started from WLS 9.0 onwards. Here is some comparison between EJB 2.0 and 3.0 as well as requirements for EJB 3.0. For detailed discussions please refer to http://edocs.bea.com.
Please note that starting Aug 31, 2009 edocs.bea.com will no longer be maintained and will be moved to OTN- Oracle Technology Network (http//www.oracle.com/technology/index.html)
One of the central goals of Version 3.0 of the EJB specification is to make it much easier to program an EJB, in particular by reducing the number of required programming artifacts and introducing a set of EJB-specific metadata annotations that make programming the bean file easier and more intuitive.
Another goal of the EJB 3.0 specification was to standardize the persistence framework and reduce the complexity of the entity bean programming model and object-relational (O/R) mapping model.
a) EJB Programming Model Requirements Between Versions 2.X and 3.0
The changes between EJB 2.X and 3.0 are:
· You are no longer required to create the EJB deployment descriptor files (such as
ejb-jar.xml). 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 bean file can be a plain Java object (or POJO); it is no longer required to implement
§ As a result of not having to implement
javax.ejb.MessageDrivenBean, the bean file no longer has to implement the lifecycle callback methods, such as
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
§ The bean file is required to use a business interface. The bean file can either explicitly implement the business interface or it can specify it using the
§ The business interface is a plain Java interface (or POJI); it should not extend
§ The business interface methods may not throw j
ava.rmi.RemoteException unless the business interface extends
b) New EJB 3.0 Features
§ Bean files can now use metadata annotations to configure metadata, thus eliminating the need for deployment descriptors.
§ The only required metadata annotation in your bean file is the one that specifies the type of EJB you are writing (
@javax.persistence.Entity). 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 are do not support the requirements.
§ 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.
§ You can configure multiple interceptor methods that execute in a chain in a particular order.
§ You can configure default interceptor methods that execute for all EJBs contained in a JAR file.
II. Tips for EJB Admin Best Practices in Weblogic Clusters
· Set pool and cache sizes based on anticipated load. Remember, cache sizes affect all servers in cluster
· Have developers mark methods as idempotent if they really are that way
· Configure clusterable home stubs
· Configure in-memory replication of Stateful Session Beans
· If ALL clients of a particular EJB will access it from the the same server on which it is deployed, then
o set clients-on-same-server to true in weblogic-ejb-jar.xml
o server will not send JNDI announcements about EJB to other
Servers in the cluster, reducing server startup time
III. Availability of Guardian Software
As all Weblogic Administrators aware Guardian software has pre-emptive support features which has been designed to eliminate potential software issues and system outages towards better maintainance of weblogic server environments. For those who are wondering its availability , the good news is, still its available at :
Article by Shree Srinivasan