Remote-EJB-Calls to a not known amount of EJB-Server

[def321]

Hi,

I have two JBoss EAP 6.2 server installed. On server1 is a web-application installed, which calls EJBs on server2. I successfully made the remote-ejb-call following the steps explained in this tutorial: http://www.mastertheboss.com/jboss-server/jboss-as-7/how-to-call-ejbs-from-another-jboss-as-7-instance

The problem I am running into is, that i don't know at compile time, how many ejb-server are available. As an example there can be multiple ejbs (ejb1, ejb2, ejb3) deployed on multiple server / cluster (server2, server3, server4). Yes, I can call ejbs on multiple server by adjustifying jboss-ejb-client.xml, but that's not an valid option, because we have to redeploy the client-application everytime a new ejb-server will be added.

Right now I'm reading into the standalone-style of invoking remote-ejb-calls by using jboss-ejb-client.properties. But I'm not happy with this solution either, because the password has to be set in the properties file.

What is the best practice for this kind of problem?

Thanks in advance.

[lylewang]

If I am understanding correctly you don't have to specify all the possible EJB "server" nodes in that config, once the cluster is formed and you connect to any node in the cluster, the node list (client side) should be updated automatically to include all the nodes (and should maintain itself on any node leaving / joining the cluster). The node list configured there is only for the initial connection to make you hit the cluster, configuring only one or two nodes from the cluster there would be fine.

I'm a bit confused as you said it was EAP server-to-server EJB invocation but then you talked about "reading into the standalone-style of invoking remote-ejb-calls " ?

If you're doing server-to-server calls (one web app on EAP 6 server to call a remote EJB on another EAP 6), the article you're looking at is the correct way (via "remote-outbound-connection" definition in server configuration)

For the multiple node cluster invocation, there is a quickstart please read through and setup a lab to try:

jboss-eap-quickstarts/ejb-multi-server at 6.4.x · jboss-developer/jboss-eap-quickstarts · GitHub

Btw, latest EAP 6.4 is recommended.

[def321]

Thanks for your response, Lyle.

First I want to connect to multiple clusters. Maybe I was a bit confusing by talking about servers and clusters. So there is a cluster1 containing server1 and server2 and we have a cluster2 containing server3 and server4. The client has to connect to either cluster1 or cluster2. At compiletime it is not known how many clusters are existing.

The solution working 1:1 was with the jboss-ejb-client.xml file lying inside the EAR/META-INF folder. The problem about that is, the receivers has to be announced at compiletime. To work around I looked into the "standalone"-style with the properties file. Because using them doesn't require a static xml file. The properties-file can be loaded dynamically at runtime.

I found the scoped ejb client contexts (Scoped EJB client contexts - JBoss AS 7.2 - Project Documentation Editor). I guess this can be the right way doing this. Also here is the "standalone"-style with properties.

You also said, that EAP 6.4 is recommended. Are there any crucial bugfixes or changes to remote ejbs or do you recommend to use the latest version? I by myself am just the developer. I won't go in production / "online" with the server.

[lylewang]

I'm still not sure how your environment would look like exactly, so you have server1/2 as cluster1, server3/4 as cluster2, same EJB server side app. deployed on both cluster1 and cluster2 ?

Where is your EJB client ? outside cluster1 and cluster2 ?

Is the EJB client calling from another EAP server instance, or as a standalone EJB client (not running in EAP container) ?

You can use the "EJBClientConfiguration" approach to configure the EJB nodes programmatically .

In this way you don't need to include any properties file, you can load this node list and setup it on the fly, all done in java code.

http://www.mastertheboss.com/jboss-server/jboss-as-7/jboss-as-7-ejb-remote-clients-without-configuration-file

If you need multiple nodes you can try to put multiple connections like there:

pr.put("remote.connections", "node1,node2");

pr.put("remote.connection.node1.port", "4447");

pr.put("remote.connection.node1.host", "localhost");

pr.put("remote.connection.node1.username", "user");

pr.put("remote.connection.node1.password", "Password12345");

pr.put("remote.connection.node2.port", "....");

pr.put("remote.connection.node2.host", "....");

pr.put("remote.connection.node2.username", "....");

pr.put("remote.connection.node2.password", "....");

Scoped context is not really recommended when you're handling performance critical environments, it has performance limitations.

But as you said you don't plan to put this onto production / live server so I assume that's fine just playing it around in your local dev. environment.

There are some bug fixes in EJB / clustering area in 6.3 / 6.4, actually there are improvements / bug fixes in every version , for the details you can check the release notes for each version.

It is always recommended to use latest version.

[def321]

Okay my setup more detailled:

The client is running on a jboss-eap-instance (own cluster) and is somethink like a dispatcher. The client reads a database which has information in it, where the ejbs are deployed and how to call them (jndi names).

The ejbs implementing all the same interface. So lets say we have an interface "RemoteEjbInterface" and we have 2 ejbs implementing this interface called "MyRemoteEjbA" and "MyRemoteEjbB". MyRemoteEjbA is deployed on cluster1 and MyRemoteEjbB is deployed on cluster2. Again: There could be more or less Ejbs deployed on 1 to n clusters. The access-information (jndi name and cluster, if needed) is stored in the database.

I'll look into your approach, it could be also a good alternative.

Can you tell me more about the performance drawbacks? I'm developing on my local machine, but the app will be running in production. I know, that the app has to manage the lifecycle of the scoped ejb client context. So when I cache this context and open it once for the runtime of the application it should be fine?

[wdfink]

The problem here is that you have the information dynamically.

At the moment there is no perfect way to handle this.

The scoped-context consume resources and there are some drawbacks as well (i.e. CMT behaviour) as you need to close the context after use which might break the transaction if it span across the servers.

The better solution will come with EAP7 and Wildfly 10, it's called profiles (not sure whether this is final) and you only need to reference the profile(s) in the application.

the servers and properties are handled inside of the serves configuration, so you are able to have more or less servers.

In the app code you only need to have the JNDI name and the context selects the target for you.

Regarding the approach from Lyle, the EJBClientConfiguration will not work inside of a server as you can't override the context here, you will see a message that the selector can not be overriden.

[def321]

Thanks for your answer. Yeah I also saw something about the profiles. I'll use the scoped ejb client context approach until EAP7 will be released.