About software development for the enterprise. Focus on Java EE and more general Java platforms.
You'll read a lot about Conferences, Java User Groups, Java EE, Integration, AS7, WildFly, EAP and other technologies that hit my road.

Thursday, December 17, 2009

Weblogic 11g calling GlassFish v3, Foreign JNDI Provider

10:14 Thursday, December 17, 2009 Posted by Markus Eisele
, , , , ,
And here is the second post about WLS/GF interoperability.
After answering the question How to call an EJB deployed on Weblogic 11g (WLS 10.3.2.0) from GlassFish v3? I now wanted to know, how do it the other way around.

Obvisously it would work the same way, I did on the GF side. Anyway, there is another feature build into Weblogic that makes this more easy for the developer. It is called Foreign JNDI. Foreign JNDI is an API that allows you to access objects on a remote JNDI tree without having to connect directly to the remote tree. It enables you to make links to a JNDI tree on another server or provider including, but not limited to, WebLogic Server, or a JNDI tree in a java program. Once you have configured Foreign JNDI, you can use an object that is somewhere else with the same ease that you would use an object bound in your WebLogic server instance. This is again using RMI-IIOP communication. Ok. Let's start.

You need an EJB to deploy to GF. Of course, this has to be a EJB 3.x. I wrote a quite simple one called GFTest. It has one business method public void sayHelloOnServer() which puts a text to stdout.
And again, you need EJB 2.x style remote interfaces for this.
That should look similar to this:

@Stateless(mappedName="GFTest")
@Remote(GFTestRemote.class)
@RemoteHome(GFTestRemoteHome.class)
public class GFTest implements GFTestRemote

GFTest is the EJB 3.x business interface. GFTestRemoteHome is the EJB 2.x EJBHome which creates the GFTestRemoteObject EJBObject. it is best to put all interfaces into a separate client project.
If everything is ready, deploy the ejb. In my previous post I recommended to run the appc compiler to generate stubs and skeletons. As proven today, this is not realy needed. You only need the interface classes on your client project. Thats totally suffient.

Now let's move over to the Weblogic administration console (http://localhost:7001/console) and configure the foreign JNDI Provider. The steps to take are described in the admin console online help.
First you have to create a foreign JNDI provider. (Summary of Services / Summary of Foreign JNDI Providers / New) and give it a name you like. Now click on the newly created provider and configure it. Settings are as follows:
Initial Context Factory: weblogic.jndi.WLInitialContextFactory
Provider URL: iiop://your_host:your_port (standard case is iiop://localhost:3700)

Next is to create a foreign JNDI object link. Switch from the general to the links tab and click new. Give it a name, you like, it is for administrational proposes only. Then configure the following settings:
Local JNDI Name: The local binding name for the object (in my case GFTest2)
Remote JNDI Name: corbaname:iiop:your_host:your_port#remote_binding_name (in my case corbaname:iiop:localhost:3700#GFTest).

After that, you have to restart the server instance.

Start your favorite IDE for your Weblogic projects and setup a client project. Again, I am one of those webguys and therefore I setup a simple Dynamic Webproject with OEPE. The remote interfaces should be available to the project (client.jar, or classess folder).

The only thing you have to do now, is to get an InitialContext and lookup your EJBHome.

InitialContext context = new InitialContext();
GFTestRemoteHome home =
(GFTestRemoteHome) context
.lookup("GFTest2");

The only thing left to do is to create your GFTestRemoteObject on which to call your business method.

GFTestRemoteObject object = home.create();
object.sayHelloOnServer();

Now you are done!Compared to the manual lookup this is extremely simple and does not force you to take care of the connection handling, urls and jndi names in the code at all.