RMH J2EE WS page 339

Using Dynamic Proxy
Folks!
Do we really need to do a JNDI lookup for a service in Stand Alone web services Client ? Can we do it (I mean is it legal to do it)?

I see an example for Dynamice Proxy on pg 339 of RMH's J2EE Web Services that does a JNDI look up in a stand alone application and it confuses me.

Thanks for the help

For Dynamic Proxy, we know the services we can have, but we dont know where the services are provided, thus, we need to lookup for the services, and JNDI is one of the ways.

Nick

Nicholas,

I don't have RMH book, but I think the original question was: is it possible to use JNDI lookup on J2SE client ? I guess, JNDI is available on J2EE platform only (may be I am wrong).

Cheers,
MZ

I look at it like this. You have a client which has the J2EE jar files on its classpath. So, a JNDI lookup is done to obtain a javax.xml.rpc.Service object whose getPort() method is invoked. This returns the endpoint interface, thus enabling the client to call one of the interface's business methods.

Hello

Having J2EE jars on CLASSPATH is not enough IMHO to allow client use names lookups.
JNDI is implemented as some server - it needs to listen some port on some host, as well it must have some config files.

cheers,
MZ

Of course, you must have somewhere to hold (or bind) the JNDI reference.

I am currently studying IBM 288, and thus, if you have configure the some JNDI to the web services endpoints, even you use J2SE clients, you can lookup the web services endpoints.

It is always possible to have any Java clients that access to the JNDI context, as the Service Locator pattern does not apply to J2EE platform solely.

Nick

Taking points from your discussion I will go home and look at the example again and see if makes sense to me. Please continue the discussion, may be I can get more of this.

I agree with Nicholas Cheung. In EJB, a standalone client (not in a container) can still do JNDI lookup on the bean instances via the jar file which packages the bean information (home interface, remote interface, bean instance, etc).

Hello.

Well, client not in EJB container anyway need network access to JNDI implementation. It can use JNDI network connection to EJB container it working with.

As for Web Services - one of the declared advantages is ability to work behind firewall, using HTTP protocol only. This means either JNDI directory has to be running and be accessed locally (not the case when use J2SE), or J2SE Web Services client has to connect to remote JNDI directory (may not the case because all ports except HTTP (80/8080/9080) can be blocked).

So, let's assume that J2SE Web Services client connects to its endpoint's JNDI directory and firewalls do no block these connections.