Monday, May 21, 2007

Thursday, May 10, 2007

EJB 3 Action @JavaOne bookstore!

Few guys told me that their local B & N or Borders do not carry EJB 3 In Action as yet. The Bookstore at JavaOne is selling the EJB 3 In Action. It is offering 20% discount so it's a steal! Also the publisher is offering 35% discount on the book for the JavaOne attendees if ordered from it's website. So get a flyer with a coupon code. Some of these are in the bookstore or around the Oracle's EJB 3/ OC4J booth in the Exhibition Hall!

Wednesday, May 09, 2007

Using Dependency Injection to invoke EJB deployed in a remote container

Many applications require invocation of EJBs deployed in a remote container. EJB 3 and Java EE 5 support injection of remote EJB references only in the application client container. Let us say you want to invoke an EJB based on a remote container from your web client (JSF backing bean) or an EJB then you have to resort to the JNDI lookup. Unfortunately injection of remote references have been left as an extension to application server vendors.

In this blog I will demonstrate how OC4J 11g preview supports injection of EJB references that is deployed in a remote container.

Let us assume that we have two Session EJBs HelloWorld and Namaste deployed in two different OC4J instances. The HelloWorld EJB uses dependency injection to get a reference to Namaste EJB located in a remote container.

Stateless Session Bean example using EJB 3.0


We will deploy Namaste EJB into second OC4J instance that will be remotely invoked by the HelloWorld EJB. The following is the coded for the Namaste EJB.

@StatelessDeployment(location="Namaste")
@Stateless
public class NamasteBean implements Namaste 
{
public void sayHello(String name)
{
System.out.println("Namaste "+name +" from Remote EJB");
}

Note that the location parameter of @oracle.j2ee.annotation.ejb.StatelessDeployment is used to configure global JNDI name for the Namaste EJB.

Injection Code to Invoke the Remote EJB

OC4J allows injecting remote EJB references (deployed on remotre server) by using a proprietary annotation @oracle.j2ee.annotation.ejb.EJBRefMapping, as shown in the following code. Note that HelloWorld EJB is deployed in OC4J instance 1.

@Stateless

public class HelloWorldBean implements HelloWorld {

@EJBRefMapping(remoteServerRef="true",location="Namaste",

jndiPropertiesFile="META-INF/jndi.properties")

@EJB

private Namaste namaste;

public void sayHello(String name) {

System.out.println("Hello " + name+ " from your first EJB 3.0 component ... ");

System.out.println("Using Injection to invoke method of Namaste Bean! See console of remote container ");

namaste.sayNamaste(name);

}

}

The location element specifies the global JNDI for the remote interface of the EJB and jndiProperties file specifies the JNDI properties such as provider URL, principal, credential, etc to look up the remote EJB as follows:



java.naming.factory.initial=oracle.j2ee.rmi.RMIInitialContextFactory
java.naming.provider.url=ormi://localhost:23792/remoteDI
java.naming.security.principal=oc4jadmin
java.naming.security.credentials=welcome


You can use @EJBRefMapping annotation in any manage classes in the container such as Servlet, listeners or managed POJOs. If you are not comfortable using Oracle's extension, you can use the equivalent in oracle-ejb-jar.xml.

Client Code

The client code runs in Oracle’s application client container and uses dependency injection to invoke methods on HelloWorld EJB as follows:.

public class HelloWorldClient {

@EJB

private static HelloWorld helloWorld;

helloWorld.sayHello(name);

}

Conclusion

Dependency Injection of remote EJB references in not standardized. You can use Oracle's proprietary extension to injection remote EJB references.

Should EJB 3 contain support for EJB 2? Yes, ALWAYS !!

I read the interesting blog by Andreas where he makes argument that EJB 2 should have been optional in EJB 3!


In my opinion, “No, never”. There have been countless EJB 2 applications in production and I still see many developers actively developing/deploying EJB 2 applications because many application servers such as IBM Websphere still do not have support for EJB 3 in their production servers. Many of EJB 2 applications will migrate to use EJB 3 but many will probably hang around for years. Support for EJB 2 and EJB 3 together allows applications to interoperate between applications using two different versions of applications deployed in the same container. This also enables customers to do a phased migration of applications. Having said that EJB 3 de-supported EJB 1.1 and I still want to see support for EJB 2.1 in EJB 3.1. I think it makes sense for a standard to support at least two earlier releases. I’m okay if EJB 4 (probably it will at least 2-3 years from now) de-supports EJB 2.1. If Sun decides to EJB 2.1 in EJB 3.1 then most customers will probably be mad and decide to dump EJB :) Anyway vendors like Oracle will keep supporting EJB 2.1 with EJB 3.1 to keep their customers up and running!

Tuesday, May 08, 2007

Oracle releases Java EE 5 compatible container!

Oracle released Java EE 5 compliant Oracle Application Server 11 technology preview. This preview has several extensions to the Java EE 5 that includes the POJO injection, injection remote EJB references, embeddable Spring container and many more. I'm at JavaOne currently and I will blog about these features in coming days!

Thursday, May 03, 2007

EJB 3 In Action: Book Signing

I will do a book-signing at JavaOne next week. You can drop by at the DigitalGuru Bookstores at Moscone between 4:00-4:30pm on Tuesday(8th May) with your copy of the EJB 3 In Action or buy one at the bookstore and get it autographed!

See you at San Francisco and have a great JavaOne!