<p>I'm trying to setup a remote EJB call between 2 WebSphere Liberty servers deployed in k8s.
Yes, I'm aware that EJB is not something one would want to use when deploying in k8s, but I have to deal with it for now.</p>
<p>The problem I have is how to expose remote ORB IP:port in k8s. From what I understand, it's only possible to get it to work if both client and remote &quot;listen&quot; on the same IP. I'm not a network expert, and I'm quite fresh in k8s, so maybe I'm missing something here, that's why I need help.</p>
<p>The only way I got it to work is when I explicitly set host on remote server to it's own IP address and then accessed it from client on that same IP. This test was done on Docker host with macvlan0 network (each container had it's own IP address).</p>
<p>This is ORB setup for remote server.xml configuration:</p>
<pre><code>&lt;iiopEndpoint id=&quot;defaultIiopEndpoint&quot; host=&quot;172.30.106.227&quot; iiopPort=&quot;2809&quot; /&gt;

&lt;orb id=&quot;defaultOrb&quot; iiopEndpointRef=&quot;defaultIiopEndpoint&quot;&gt;
    &lt;serverPolicy.csiv2&gt;
        &lt;layers&gt;
            &lt;!-- don't care about security at this point --&gt;
            &lt;authenticationLayer establishTrustInClient=&quot;Never&quot;/&gt;
            &lt;transportLayer sslEnabled=&quot;false&quot;/&gt;
        &lt;/layers&gt;
    &lt;/serverPolicy.csiv2&gt;
&lt;/orb&gt;
</code></pre>
<p>And client server.xml configuration:</p>
<pre><code>    &lt;orb id=&quot;defaultOrb&quot;&gt;
    &lt;clientPolicy.csiv2&gt;
        &lt;layers&gt;
            &lt;!-- really, I don't care about security --&gt;
            &lt;authenticationLayer establishTrustInClient=&quot;Never&quot;/&gt;
            &lt;transportLayer sslEnabled=&quot;false&quot;/&gt;
        &lt;/layers&gt;
    &lt;/clientPolicy.csiv2&gt;
&lt;/orb&gt;
</code></pre>
<p>From client, this is JNDI name I try to access it:</p>
<pre><code>corbaname::172.30.106.227:2809#ejb/global/some-app/ejb/BeanName!org\.example\.com\.BeanRemote
</code></pre>
<p>And this works.</p>
<p>Since one doesn't want to set fixed IP when exposing ORB port, I have to find a way to expose it dynamically, based on host IP.
Exposing on 0.0.0.0 does not work. Same goes for localhost. In both cases, client refuses to connect with this kind of error:</p>
<pre><code>Error connecting to host=0.0.0.0, port=2809: Connection refused (Connection refused)
</code></pre>
<p>In k8s, I've exposed port 2809 through LoadBalancer service for remote pods, and try to access remote server from client pod, where I've set remote's service IP address in corbaname definition.
This, of course, does not work. I can access remote ip:port by telnet, so it's not a network issue.</p>
<p>I've tried all combinations of setup on remote server. Exporting on host=&quot;0.0.0.0&quot; results with same exception as above (Connection refused).</p>
<p>I'm not sure exporting on internal IP address would work either, but even if it would, I don't know the internal IP before pod is deployed in k8s. Or is there a way to know? There is no env. variable with it, I've checked.</p>
<p>Exposing on service IP address (with host=&quot;${REMOTE_APP_SERVICE_HOST}&quot;) fails with this error:</p>
<pre><code>The server socket could not be opened on 2,809. The exception message is Cannot assign requested address (Bind failed).
</code></pre>
<p>Again, I know replacing EJB with Rest is the way to go, but it's not an option for now (don't ask why).</p>
<p>Help, please!</p>
<hr />
<p>EDIT:</p>
<p>I've managed to get some progress. Actually, I believe I've successfully called remote EJB.
What I did was add <code>hostAliases</code> in pod definition, which added alias for my host, something like this:</p>
<pre><code>hostAliases:
- ip: 0.0.0.0
  hostnames:
  - my.host.name
</code></pre>
<p>Then I added this host name to remote server.xml:</p>
<pre><code>&lt;iiopEndpoint id=&quot;defaultIiopEndpoint&quot; host=&quot;my.host.name&quot; iiopPort=&quot;2809&quot; /&gt;
</code></pre>
<p>I've also added host alias to my client pod:</p>
<pre><code>hostAliases:
- ip: {remote.server.service.ip.here}
  hostnames:
  - my.host.name
</code></pre>
<p>Finally, I've changed JNDI name to:</p>
<pre><code>corbaname::my.host.name:2809#ejb/global/some-app/ejb/BeanName!org\.example\.com\.BeanRemote
</code></pre>
<p>With this setup, remote server was successfully called!</p>
<p>However, now I have another problem which I didn't have while testing on Docker host. Lookup is done, but what I get is not what I expect.</p>
<p>Lookup code is pretty much what you'd expect:</p>
<pre><code>Object obj = new InitialContext().lookup(jndi);
BeanRemote remote = (BeanRemote) PortableRemoteObject.narrow(obj, BeanRemote.class);
</code></pre>
<p>Unfortunatelly, this narrow call fails with <code>ClassCastException</code>:</p>
<pre><code>Caused by: java.lang.ClassCastException: org.example.com.BeanRemote
    at com.ibm.ws.transport.iiop.internal.WSPortableRemoteObjectImpl.narrow(WSPortableRemoteObjectImpl.java:50)
    at [internal classes]
    at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:62)
</code></pre>
<p>Object I do receive is <code>org.omg.stub.java.rmi._Remote_Stub</code>. Any ideas?</p>

<p>Solved it!</p>
<p>So, the first problem was resolving host mapping, which was resolved as mentioned in edit above, by adding host aliases id pod definitions:</p>
<p>Remote pod:</p>
<pre><code>hostAliases:
- ip: 0.0.0.0
  hostnames:
  - my.host.name
</code></pre>
<p>Client pod:</p>
<pre><code>hostAliases:
- ip: {remote.server.service.ip.here}
  hostnames:
  - my.host.name
</code></pre>
<p>Remote server then has to use that host name in iiop host definition:</p>
<pre><code>&lt;iiopEndpoint id=&quot;defaultIiopEndpoint&quot; host=&quot;my.host.name&quot; iiopPort=&quot;2809&quot; /&gt;
</code></pre>
<p>Also, client has to reference that host name through JNDI lookup:</p>
<pre><code>corbaname::my.host.name:2809#ejb/global/some-app/ejb/BeanName!org\.example\.com\.BeanRemote
</code></pre>
<p>This setup resolves remote EJB call.</p>
<p>The other problem with <code>ClassCastException</code> was really unusual. I managed to reproduce the error on Docker host and then changed one thing at a time until the problem was resolved. It turns out that the problem was with <code>ldapRegistry-3.0</code> feature (!?). Adding this feature to client's feature list resolved my problem:</p>
<pre><code>&lt;feature&gt;ldapRegistry-3.0&lt;/feature&gt;
</code></pre>
<p>With this feature added, remote EJB was successfully called.</p>
