0 Replies Latest reply on Oct 18, 2016 2:52 PM by jfisherdev

    WildFly 9 Remote EJB Protocol For Server-To-Server EJB Invocation

    jfisherdev

      I am currently migrating from JBoss AS 4.2.2 to WildFly 9.0.2.

       

      One of the most challenging parts of this has been getting the right remote EJB client configuration.

       

      For standalone clients, I started with the http-remoting protocol/remote-naming approach and ultimately ended up using the recommended JBoss EJB client API approach/protocol with scoped contexts.

       

      I am currently working on the case of one WildFly server acting as an EJB client that invokes a remote EJB on another WildFly server.

       

      I have looked at this article EJB invocations from a remote server instance - WildFly 9 - Project Documentation Editor but have not invested enough time to get it working.

       

      With this approach I have these questions:

       

      - Are the configuration properties passed to a naming Context in this case different than those for a standalone EJB client using the JBoss EJB client API/protocol in any way.

      - Do scoped contexts work like they do for a standalone EJB client? That was not clear to me from this article Scoped EJB client contexts - WildFly 9 - Project Documentation Editor and I have not found anything else on this so far.

       

      I tried the remote-naming approach/http-remoting protocol to configure a standard remote-naming EJB JNDI client, which seems to work. Unless I am misunderstanding something, this would seem to contradict the statement "It is not possible to use remote-naming if the client is an application deployed on another JBoss instance" in this article Remote EJB invocations via JNDI - EJB client API or remote-naming project - WildFly 9 - Project Documentation Editor .

       

      My question is what is the optimal or recommended approach for this case?

       

      While I would like to use the EJB protocol as I do for standalone clients, this does seem like a lot of configuration effort when compared to a standalone client or using the remote-naming/http-remoting approach.

       

      Any information on this would be appreciated.