Rumblings from a Technologist and Book author
Tuesday, May 29, 2007
Monday, May 21, 2007
EJB 3 In Action is in Amazon's Top 20 Selling Java Books
Thursday, May 10, 2007
EJB 3 Action @JavaOne bookstore!
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!
Thursday, May 03, 2007
EJB 3 In Action: Book Signing
See you at San Francisco and have a great JavaOne!