Remote EJB in Domain mode WildFly - ejb

We are trying to lookup a remote EJB across wildfly running in domain mode with two nodes.
The setup is like this:
Wildfly Node 1:
Module A: EJB Client
Module B: Remote EJB
Wildfly Node 2:
Module A: EJB Client
Module B: Remote EJB
The wildfly nodes are part of a single domain.
Now, if we lookup the remote EJB across the nodes, it should return the EJB from the same node first, if it is available. Only if, it is not available, should the lookup return EJB from other node.
We have configured the EJB as clustered.
The problem is that even if we use "java:global" binding, the lookup is always returning the EJB from other node.
What configuration are we missing?

Have you tried configuring the JNDI properties for your InitialContext before doing the lookup? You can create a properties file and load at the moment to instantiate your InitialContext, in this file you can define the primary and secondary host that will be used to get the proxy, you can define this by a properties file or programmatically.
https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI

Related

Using InitialContext for lookups on Liberty

I am working on migrating ear application from WebSphere 8.5 to WebSphere Liberty.
There are 2 EJB Applications A and B deployed on different systems.
In the code , whenever B has to talk with A, the steps were
a) Create InitialContext and pass the EJB URL of A
Hashtable<String, String> env = new Hashtable<String, String>();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.ibm.websphere.naming.WsnInitialContextFactory");
env.put(Context.PROVIDER_URL, url);
InitialContext ic = new InitialContext(env)
b) Use this InitialContext to then do JNDI lookup
To migrate this code to Liberty , I need to replace all JNDI lookups for EJB Interfaces with java namespace.
The migration tool also suggests using default InitialContext and not passing the INITIAL_CONTEXT_FACTORY and PROVIDER_URL on Liberty
InitialContext context = new InitialContext();
My question is how will this work in case of liberty for the above scenario where A and B are on remote systems ?
Don't we require the EJB Url to be provided?
Another related question is whether this change is backward compatible with Websphere 8.5
On Liberty, the java: namespace lookups are only available when looking up beans within the same server process. To lookup beans between server processes, you must use a corbaname lookup, where the corbaname would include the host and IP address of the target server. Details about this may be found here:
https://www.ibm.com/support/knowledgecenter/SSD28V_liberty/com.ibm.websphere.wlp.core.doc/ae/twlp_ejb_remote.html
Also, an example of this may be found in the open-liberty source test project that explicitly tests different ways of looking up remote EJBs between processes:
https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.ejbcontainer.remote_fat/fat/src/com/ibm/ws/ejbcontainer/remote/fat/tests/Server2ServerTests.java
And the actual servlet for that test (running on one of the two servers) is found here:
https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
The test is using localhost since both servers are on the same system, so that would need to be replaced if they are on separate systems.
As for being portable with WebSphere traditional 8.5, the answer is no. WebSphere traditional and Liberty would both support looking up remote interfaces in the java: name spaces for beans that are co-located in the same server process, however the behavior for looking up EJBs between processes is not compatible.

Wildfly 12 - EJB invocations from remote servers under domain controller (Elytron)

I am following the instructions from this link: https://developer.jboss.org/people/fjuma/blog/2017/09/08/getting-started-with-ejbs-and-elytron-part-2
Trying to replicate those configurations under domain controller but without success.
I have two server groups, one is client of other. But the servers of server group "B" still unable to lookup the remote EJB from servers of server group "A"
I tried to configure the servers with jboss-cli.sh from domain controller. Applying the configurations at the corresponding profiles.
Ex:
From Domain Controller's jboss-cli.sh:
/profile=my-custom-profile-full-ha/subsystem=elytron/authentication-configuration=ejb-auth-config:add(authentication-name=ejb, credential-reference={clear-text="ejbejb"})
and so on...
The socket-binding-group is defined at domain.xml as well.
But my client server still getting errors when lookup the remote EJB.
Is there other configuration for servers running under domain controller to get remote invocations work?
The error:
javax.ejb.NoSuchEJBException: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "/portal/SampleEJB", view is interface my.company.ejb.interfaces.SampleEJBRemote, affinity is None
Thanks!

How to configure a Message Driven Bean to subscribe to a remote JMS Topic

I am trying to get a MessageDriven (EJB 3) bean to subscribe to a JMS Topic on another glassfish instance on another host. Is this possible?
In the Glassfish console you can modify the JMS server and point it to another Glassfish instance or a standalone OpenMQ broker. Although you can configure several JMS hosts to my knowledge Glassfish will always use the one called default_JMS_host so that's the one you want to edit.
Just one thing: in such a setup the two server instances will share queues and topics, which may not be what you want if the two servers are for example running the same application but don't want to share e.g a particular queue. This can easily be solved via the Destination Resources configuration, by specifying different physical names for that queue.

GlassFish clustering + EJB lookup

We have Glassfish cluster which has two instances.
On this cluster one my EJB application is deployed and running.
Now I have another EJB-Timer-application which I want to deploy on Glassfish server(domain) not on cluster then I want to access the cluster's EJB. AS per my understanding EJB timer could not deployed on a cluster because it could be run on both the instances of cluster.
What are the possible ways to access it ?
Thanks
You can actually deploy EJB timers on a cluster. They will only execute on one instance. At startup, each #Scheduled bean is assigned in a round-robin manner to an instance. If an instance fails, the timers will fail-over to the next healthy instance.
Remember to follow the setup procedure for EJB timers as described here: http://docs.oracle.com/cd/E18930_01/html/821-2418/beahw.html. In short, you need to specify an XA datasource for the timers database instead of using the default embedded one.
We are running several #Scheduled beans in a Glassfish clustered production environment.

Call to EJB method from a remote jboss server(servlet)

case 1:
I'm having war in one jboss server and ejb jar in another jboss server.
I want to call my ejb from my servlet which is present in another server.
How to call it. can any one help me with a working sample and required configurations.
case 2:
Message Driven Bean(MDB) in my transaction jboss server and business method in another jboss server. How to call my business method from my transaction server.
kindly help me to solve this case
Thanks in advance
I can't (won't) help with a working example, but this is what you have to do:
Your EJBs (session beans) must be configured in a way to support remote access, RMI.
You have to export your EJB client classes into a separate JAR file; those are the interfaces and base classes required to perform an RMI call (stubs). This is required as clients (your WAR) must understand how to deserialize/serialize the RMI communication between your servlets and the remote EJBs.
Make the exported EJB client JAR available to your WAR file
Define an initial context pointing to your remote EJB server as described here.
Deploy and run it...
BTW: A personal opinion, RMI communication is painful and you should try to avoid it as it tightly couples the client (your WAR) to the remote EJBs.
EDIT: Which EJB version and which IDE do you use?

Resources