Thursday, February 5, 2009

EJB 3.0 Features, Best practices and Guardian Software

The Infogram is starting a series of original material from some of our Oracle technical experts. We start with this article by Shree Srinivasan:

EJB 3.0 Features, Best practices and Guardian software

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 javax.ejb.SessionBean or javax.ejb.MessageDrivenBean

§                As a result of not having to implement javax.ejb.SessionBean or javax.ejb.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.ejb.PostActivate.

§                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 @javax.ejb.Remote or @javax.ejb.Local annotations

§                The business interface is a plain Java interface (or POJI); it should not extend javax.ejb.EJBObject or javax.ejb.EJBLocalObject.

§                The business interface methods may not throw java.rmi.RemoteException unless the business interface extends java.rmi.Remote.

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.ejb.Stateless, @javax.ejb.Stateful, @javax.ejb.MessageDriven, or @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 :                                                                                

http://www.oracle.com/technology/software/products/guardian/index.html

Article by Shree Srinivasan

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Official, Youbetcha Legalese

This blog is provided for information purposes only and the contents hereof are subject to change without notice. This blog contains links to articles, sites, blogs, that are created by entities other than Oracle. These links may contain advice, information, and opinion that is incorrect or untested. This blog, links, and other materials contained or referenced in this blog are not warranted to be error-free, nor are they subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this blog, links and other materials contained or referenced in this blog, and no contractual obligations are formed either directly or indirectly by this blog, link or other materials. This blog may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. The opinions and recommendations contained in this blog(including links) do not represent the position of Oracle Corporation.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.