How to Make a Call to an EJB Service Deployed on Wildfly

Wildfly 8 is a completely new structure from JBoss 6. While migrating JBoss from version 6 to Wildfly 8, I remember that I struggled a lot for the migration of code especially in EJB call. As very little documentation was present online, I decided to write this blog. Remember that if you are migrating JBoss 6 to EAP 6.x (JBoss 7.x version), there is different way of EJB call if we are comparing it with Wildfly.

I will try to highlight the difference for the EJB call between EAP 6.3 and Wildfly 8. As in JBoss 6 we used to call the EJB with JNP url configuration but there is no concept of JNP url in Wildfly 8. In fact, there is no separate port for the EJB as it used to be in JBoss 6, so you can remove the JNP url while migration from JBoss 6 to Wildfly 8.

EJB call when EJB is deployed on Wildfly 8 and Client server is also Wildfly 8.
To understand the EJB call from outside world to an Application server (let’s call it MainServer) where EJB is deployed, WildFly 8 does not allow it without authentication. By default Wildfly 8 is a secure server. To call the EJB from Client server, we have to create an application user at MainServer which can be used from client server to call the EJB.

To create an application user, execute add-user.sh script (which can be found under Jboss_installed_dir/bin) to add a user in Application-realm. For example we are creating an application user with username: ejb and password: test@123. Please refer to the screenshot below for help.

Screenshot 2016-03-16 23.11.40

Please note, when client and server both are running on a different instance of the same Wildfly server, the node name must be different. Here we are assigning node name of main server as node1. To assign the different node name to server and client server, we need to pass an argument jboss.node.name.

Add the below additional arguments while main server startup.

-Djboss.node.name=node1

We are done with all configuration changes at Main server side which were required for the migration. Now if we talk about the code level, we need to update the way of constructing JNDI name as it is completely changed in Wildfly 8.

Structure of forming JNDI name is as follows:

Ejb:/app_name/module_name/service_name/fully_qualified_name_of_class!class_name.

Explicit declaration of ‘bean managed transaction demarcation’ annotation on all session EJB.

We also need to add @TransactionManagement (TransactionManagementType.BEAN) annotation explicitly for transaction management strategy in all bean implementation classes.

Now we need the following configuration update at the client side in standalone.xml file.

1. Add below security-realm configuration under <security-realms>

<security-realm name="ejb-security-realm">
         <server-identities>
             <secret value="dGVzdEAxMjM="/>
         </server-identities>
  </security-realm>

This is the same password which we created at main server for application user “ejb”. The security realm name can be anything.

2. Provide the below configuration in urn:jboss:domain:remoting:2.0 subsystem

<outbound-connections>
      <remote-outbound-connection name="remote-ejb-connection" outbound-socket-binding-ref="remote-ejb" username="ejb" security-realm="ejb-security-realm" protocol="http-remoting"/>
  </outbound-connections>

The protocol =”http-remoting” is the major change between EAP 6 and Wildfly 8.In Wildfly 8, the client can call the EJB on http protocol and there is no separate port for the ejb. Whereas in EAP 6, a different port is used for the EJB call.

3. We have to configure outbound-socket-binding as we are trying to call the EJB which is deployed on different server. The reference name for outbound-socket-binding must match with name which we have configured in step 2. The value for host can be host name or IP of main server. Please note that there is no separate port for EJB here and we are using same port i.e 8080.

wildfly2

We are done with all configuration changes at client side. Now we can call the EJB remotely at the client server at Wildfly 8.

In my next blog, I will cover the topic of calling EJB (deployed on Wildfly 8) from standalone application. Stay tuned!

Dharmveer Kedia

Dharmveer Kedia

Dharmveer Kedia is working as a Module Lead for 3Pillar Global. He is a sun-certified Java programmer and has over seven years of experience in the field of software development with various domain knowledge of Services and Investment Banking. Prior to joining 3Pillar, he worked with NIIT Technologies. He holds a B-Tech in Computer Science and Engineering. In his leisure time, he loves to travel, play cricket, and watch movies.

Leave a Reply

Related Posts

The Art of Building Rapid (and Valuable) Proofs of Concept Clients and stakeholders want results. They want assurances that their investment is well spent and they're building the right product. The software d...
Are You Doing Stuff or Creating Value? You can put a bunch of stickies on the wall, create tons of JIRA tickets, and commit lots of code, but are you creating value? Is the work your produc...
Costovation – Giving Your Customers Exactly What They ... On this episode of The Innovation Engine podcast, we delve into “cost-ovation,” or innovation that gives your customers exactly what they want – and n...
AI & Machine Learning Will See You Now, and Other Takea... A 3Pillar team and I spent a few days in Santa Clara recently for the 12th annual Health 2.0 Conference. As usual, we spent some time after the confer...
DevSecOps – The Latest Trends in Application Security ... I spent a very rewarding couple of days at DevSecCon in Boston recently. The conference focused on DevSecOps, which is a catch-all phrase for addressi...