ejb over jndi from remote client
robert.geisler Sep 24, 2012 11:33 AMhello everybody...
i try to find out how to use JNDI for EJB (and JMS!) from a remote (Java) client in JBoss AS 7.1.1.
well, today i am stuck... i already read this and this; i think i know the differences between the JBoss EJB Client API und the Remoting JNDI Client API.
now i would like to summarize and to discuss the possibilities, their advantages and disadvantages -in respect to our project.
0) we are going to migrate : )
at first i like to say that we are going to migrate an existing Java EE application that is running on JBoss AS 4.2.2 today.
we tried JBoss 5 and JBoss 6 in the meantime, but never used it in production. now we hope in JBoss 7 and try again : )
because we want to migrate an existing application we always will prefer a solution that needs as few changes as necessary!
and it is important that such solutions work for JBoss 4.2.2 and JBoss 7.1.1 at the same time.
1) why not to use the JBoss EJB Client API?
because of our existing application i thought i should avoid JBoss EJB Client API: because it is a new and JBoss specific API not even JBoss 4.2.2 knows about.
if we use it, we have to bundle a JBoss 7+ specific library into JBoss 4.2.2. that sounds like an anti pattern to me, doesnt it?
JBoss EJB Client API uses jboss-ejb-client.properties file to establish connections to the server at runtime.
but our application is running on JBoss installed in our customers local networks. we dont know these networks and its difficult to guess the servers ip address ; )
certainly it could be possible to edit the .properties file while server installation. but our client application is launched through Java Web Start.
if we edit jars referenced by the JNLP file we have to resign these jars. but resigning at the customers physical server ist not an option of course!
last but not least: our server application uses JMS messages to send requests to clients, so we need remote access to JMS destinations.
the JBoss EJB Client API doesnt support this yet, right?
2) why use the Remote Naming API?
later i read about the possibility to use the Remote Naming API.
this 'bridge' allows a developer to use the well-known InitialContext with properties at runtime to access remote EJBs.
the Remote Naming API also supports JMS ConnectionFactories and destinations. that was what i (thought i) searched for ; )
i tried that as it is described here and got a simple example working.
in the next step i tried to integrate this solution into our client application. client startup was successfull and simple functions could be used without any errors.
but when it comes to multithreading i hit the first problem...
EJBClientContext does not seem to be designed for multithreading as i get "No EJB receiver available for handling" in every thread except the main thread.
i guess the reason for this exception is, that we create an InitialContext once, put it into a static (global) field and use it widely in the client application.
within the client modules we lookup remote EJBs through this InitialContext to use the servers functionality.
it seems to me that EJBClientContext via the Remote Naming 'bridge' isnt initialized for a newly created thread!?
RemoteNamingEjbClientContextSelector.currentContext is a ThreadLocal and that is why an invokation of a proxies method from within a subthread says that it isnt able to find an EJBReceiver!?
is that correct? is it to be expected? by design? or am i doing something wrong??
if it is correct, how am i supposed to initialize this for new threads or more generell: may i use one Context instance in all my client code?
in the past we experienced a JNDI initial lookup as a heavy operation, so we tried to avoid it as the server connection properties changes rarely...
3) back to JBoss EJB Client API?
is there a solution for the current problem with the Remote Naming API at all? or do you just advise me to use the JBoss EJB Client API instead?
if i have to use JBoss EJB Client API: what are the answers to my questions and doubts in 1)?
- may we bundle the jboss-ejb-client-1.0.5.Final.jar into JBoss 4.2.2 without any problems?
- is it possible to not use jboss-ejb-client.properties but configure the properties at runtime??
- how do we get remote access to JMS resources with this API?
well... in the end... an open question:
5) is there any other approach to access ejb and jms from a remote client?? : )
thanks in advance!
regards
robert geisler