Mike Dee

Thanks Craig, your code was exactly what I was looking for.

I believe port 900 is the default port for older versions of Websphere. We have explicitly set the ports to be as named above. Since the standalaone(non web) client is working, we are presuming that these ports have been correctly configured to the above ports and are working correctly.
The issue seems to be a difference between how InitialContext's are created for standalone clients versus clients accessing the remote EJB's via a servlet running in a web server. It appears that when creating the InitialContext while running in a server(i.e. servlet), the InitialContext will always default to the intial context for that web server, unless(we presume) that you setup the IntialContext with the proper initialialzation parameters. It appears that the proper parameters are different for standalone clients than for clients running in a servlet.

We are having difficulties looking up remote EJB's in JNDI. We are using Websphere 5.0. We created the following test scenario to demonstrate our problem:
We are using Websphere Studio Application Develor(WSAD). In WSAD, we setup up two different EARs and deployed them to two different servers. We changed the ports on both servers so that they don't conflict. Each EAR has a different EJB deployed to it.
We wrote the following standalone app to access the JNDI InitialContext on both servers and dump the initial context: (note: DumpNameSpace is a class in naming.jar)
///////////////////////////////////////////////////////
/// Lookup JNDI context for Server A
DumpNameSpace dumpNizzle = new DumpNameSpace();
Hashtable proj1 = new Hashtable();
proj1.put( Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
proj1.put(Context.PROVIDER_URL, "iiop://localhost:9809");
InitialContext proje1Context = new InitialContext(proj1);

dumpNizzle.generateDump(proje1Context);
/// Lookup JNDI context for Server B
Hashtable sheet = new Hashtable();
sheet.put( Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
sheet.put(Context.PROVIDER_URL, "iiop://localhost:5809");
InitialContext sheetContext = new InitialContext(sheet);
dumpNizzle.generateDump(sheetContext);
///////////////////////////////////////////////////////

When we run this code in a standalone client, it works as expected. We get two different JNDI contexts and they hold the EJB's from their respective servers.
However, when we run the same exact code from a servlet running in a separate Websphere web application, we do not get the same results. Instead of getting the JNDI context from the specified server and port, we get the JNDI context for the Web application that the servlet is running in. We get this same context for both of the above lookups. We are therefore unable to access these EJBs from our web app, because we can't look them up.

1) What is going on here?
2) How can we access remote EJBs from a web application running in a different server?
Thanks for any help.
-Mike

My company is considering the use of a standalone J2EE application client for a system within the company. We are trying to assess how difficult it is going to be to intially deploy the application client and to also deploy periodic updates to the application client. I have several questions and would appeciate anyone's assistance and wisdom:
1. What is required to be installed on a client to run an application client that is accessing EJBs on a Websphere 4.0 server? I am currently able to to run my client by running the "launchClient.bat" file located in the \WEbsphere\AppServer\bin directory, but I can't seem to figure out how to launch the application client from an end-user machine that doesn't have the app server installed on it. Numerous searches on Google allude to the existence of a Websphere Appplication Client install CD, but I can't seem to locate any documentation of this on IBM's site.
2. Given whatever the answer to nubmer #1 above is, is it then further possible to create one JAR file that contains all the needed runtime and support software from #1 above as well as the application client (my code)? My motivation for this is that I want to use WebStart to deploy the application client and it appears that WebStart requires everything to be packaged into one JAR file. The end goal is for a new user to be able to use WebStart to click a link on a web browser and have everything needed to run the application client downloaded and installed.
Thanks for any help you can give.

-Mike