Specifying JNDI Details for Controls (EJB/JMS) in Workshop

Question

Hello,
I was running into some basic issues in using workshop for building applications. Any help is appreciated !
How do I point Controls (EJB/JMS) to JNDI where the Objects have been bound
In J2EE I will do this :
Context ctx = new InitialContext(ht); // ht has Provider URL etc.
Specifically in Design view of Workshop for (WLI) JMS Control how do you define PROVIDER_URL, SECURITY_PRINCIPAL, etc. My JMS Server is targeted to separate Managed Server that where Workshop Applications are deployed and I do not want to create Foriegn Destinations etc. on Managed Server where Applications get deployed.
For EJB Controls: How do you lookup remote EJBs that get deployed as a part of (EARs) on managed server (different from where Workshop Application and EJB Controls reside)
Basic Question: How do we distribute this "EJB Control" JAR to clients to call these EJBs using controls and specify the JNDI Environment for the control that surfaces the EJB resource deployed remotely?
I cannot import these as modules in an Workshop Application (=> EAR) and generate controls from these as they will get "deployed" in that application and we want only one deployment.
Thanks
Harish

Answer 1

Hi there,
In your GUI client you should consdier building a model that represents the data that you want the GUI to display. This model would contain the references to the EJB's that you need to use. If you want to avoid using some kid of model then it really depends on the complexity of your GUI. If your GUI consists of one JFrame then everything can be done inside the main class for the GUI. If you have lots of sub windows then you need to consider where the references will be used. If theyare used in more than one window then you could end up with lots of complex cross references which is why the model would be better in this situation.
JNDI lookups can be expensive and this depends on several factors particularly network latency, if your client is self contained then once you have a reference to a home interface then you may as well keep and use it for any future calls. The key to this is keeping references to home interfaces as instance variables rather than scoping them locally.
There should really be no bottleneck caused by using as single session bean as a Facade to your EJB tier. The Session Facade is a very common pattern and the one that is most espoused by the various authors writing EJB tech books. As far as coupling is concerned this is an ideal situation as your client can then make coarse grained calls to the single facade session bean instead of making lots of smaller fine-grained calls to several session beans. I'd say that this is a good general design.
Hope this helps
Amanda
Developer Technical Support
Sun Microsystems
http://www.sun.com/developers