EJB call without stubs

[Ravi Bansal]

Hi ,
i have two different JVM's(one of them belongs to app server weblogic) in my machine....i am calling the EJB deployed on the weblogic using my client program with just home and remote interface classes in my class path.........call is working perfectly......

i m not able to understand , how is it working without having any stub classes in the classpath.....can any one help me understanding this...?

[Jimmy Clark]

...with just home and remote interface classes in my class path

When you get the home object and then get the remote interface object, do you think that these are the "stub" objects for the EJB?
[ December 28, 2008: Message edited by: James Clark ]

[Ravi Bansal]

When i said


"with just home and remote interface classes in my class path"

it means that just class files for these two interfaces(i did nt mean class implementing these two interfaces)


I need to understand , how can the call work without having stub classes in the patha.... as these are helper classes required by the client for creating socket connections and I/O Streams....?

[Jimmy Clark]

The call is not working without the stub "objects." The application server is sending the implementations of the EJB interfaces to the client JRE.

Keep in mind that classes are simply detailed descriptions, objects are the elements that execute code.

[Ravi Bansal]

Can i see the classes on client side that applicaton server is sending to client JRE??

[Jimmy Clark]

The application server is not sending "classes", it is sending "objects."
These objects implement the interfaces that you have in the client JRE classpath.

If you post the code that connects to the EJB from the client program, I will show them too you. As you mentioned, the call is working perfectly.
[ December 31, 2008: Message edited by: James Clark ]

[Ravi Bansal]

Yes you are right in a sense that application server is sending the Objects (implementations of the interfaces ) , but to deserialize those objects , we need to have stub classes in our classpath ?

BTW this is the client code i m using

Context ctx = null;
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL, "t3://localhost:7001");
try {
ctx = new InitialContext(ht);
} catch (Exception e) {
}
Object o = ctx.lookup("First");
AdviceHome home = (AdviceHome) PortableRemoteObject.narrow(o,
AdviceHome.class);
Advice advisor = home.create();
String st=advisor.getAdvice("nishan")

[Jimmy Clark]

Yes, the remote and home interface classes need to be in the classpath of the client JRE. The stub objects that are sent from the application server are the implementations of these interfaces.

Object o = ctx.lookup("First");
AdviceHome home = (AdviceHome) PortableRemoteObject.narrow(o,AdviceHome.class);

This is the first "stub" object that is sent from application server.

Advice advisor = home.create();

This is the second "stub" object that is sent from application server.
[ January 01, 2009: Message edited by: James Clark ]

[Ravi Bansal]

I am sure by just having the classes of interfaces(home and remote) in the classpath....stub objects sent from server cant be deserialized , we need to have stub classes to deserialize the stub objects

[Jimmy Clark]

I am sure by just having the classes of interfaces(home and remote) in the classpath....

The home and remote interface classes ARE the "stub" classes.

The "stub" objects sent from application server are the implementations of these classes which are used in the client's JRE.
[ January 02, 2009: Message edited by: James Clark ]

[Vidyasagar Guduru]

I think internally it uses JRMP protocol which sends the required stubs on the wire.