ServiceInvoker over RMI to remote registry

[imaeses]

I am using the JBossESB standalone version 4.8.

When using the ServiceInvoker to query a remote UDDI registry via the RMI transport, I get some strange behavior. If I execute the client on the same machine as the server but from a different JVM (ie, the command line), everything is fine. If, however, I edit uddi.xml to use a machine that is on the network, I get the familiar TransportException as given here:

Exception in thread "main" org.jboss.soa.esb.listeners.message.MessageDeliverException: org.apache.ws.scout.transport.TransportException: java.lang.Exception: Failure during JNDI lookup of service: /juddiv3/UDDIInquiryService

at org.jboss.soa.esb.client.ServiceInvoker.loadServiceClusterInfo(ServiceInvoker.java:545)

at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:174)

at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:155)

at org.jboss.soa.esb.client.ServiceInvoker.<init>(ServiceInvoker.java:197)

at nl.anva.diginota.esbAwareClient.SendEsbMessage.main(SendEsbMessage.java:81)

Caused by: org.jboss.soa.esb.services.registry.RegistryException: org.apache.ws.scout.transport.TransportException: java.lang.Exception: Failure during JNDI lookup of service: /juddiv3/UDDIInquiryService

at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:348)

at org.jboss.internal.soa.esb.services.registry.InVMRegistryInterceptor.findEPRs(InVMRegistryInterceptor.java:85)

at org.jboss.soa.esb.services.registry.RegistryFactory$HeadRegistryInterceptor.findEPRs(RegistryFactory.java:229)

at org.jboss.soa.esb.listeners.RegistryUtil.getEprs(RegistryUtil.java:226)

at org.jboss.soa.esb.client.ServiceInvoker.loadServiceClusterInfo(ServiceInvoker.java:532)

... 4 more

Caused by: javax.xml.registry.JAXRException: org.apache.ws.scout.transport.TransportException: java.lang.Exception: Failure during JNDI lookup of service: /juddiv3/UDDIInquiryService

at org.apache.ws.scout.registry.BusinessQueryManagerV3Impl.findConcepts(BusinessQueryManagerV3Impl.java:516)

at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.getJBossESBTModel(JAXRRegistryImpl.java:653)

at org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl.findEPRs(JAXRRegistryImpl.java:307)

... 8 more

I have read numerous posts about this problem. However, I think the classpath looks alright based on what I've read:

<classpathentry kind="lib" path="lib/java-getopt-1.0.13.jar"/>
<classpathentry kind="lib" path="lib/jaxb-api.jar"/>
<classpathentry kind="lib" path="lib/jaxb-impl.jar"/>
<classpathentry kind="lib" path="lib/log4j.jar"/>
<classpathentry kind="lib" path="lib/commons-codec-1.3.jar"/>
<classpathentry kind="lib" path="lib/commons-collections.jar"/>
<classpathentry kind="lib" path="lib/commons-configuration-1.5.jar"/>
<classpathentry kind="lib" path="lib/commons-lang-2.3.jar"/>
<classpathentry kind="lib" path="lib/commons-logging.jar"/>
<classpathentry kind="lib" path="lib/jboss-aop-jdk50.jar"/>
<classpathentry kind="lib" path="lib/jboss-aspect-library-jdk50.jar"/>
<classpathentry kind="lib" path="lib/jboss-messaging-client.jar"/>
<classpathentry kind="lib" path="lib/jboss-remoting.jar"/>
<classpathentry kind="lib" path="lib/jbossall-client.jar"/>
<classpathentry kind="lib" path="lib/jbossesb-config-model-1.0.1.jar"/>
<classpathentry kind="lib" path="lib/jbossesb-registry.jar"/>
<classpathentry kind="lib" path="lib/jbossesb-rosetta.jar"/>
<classpathentry kind="lib" path="lib/jbossts-common.jar"/>
<classpathentry kind="lib" path="lib/juddi-client-3.0.1.jar"/>
<classpathentry kind="lib" path="lib/juddi-core-3.0.1.jar"/>
<classpathentry kind="lib" path="lib/scout-1.2.1.jar"/>
<classpathentry kind="lib" path="lib/stax-api-1.0.1.jar"/>
<classpathentry kind="lib" path="lib/stax-ex.jar"/>
<classpathentry kind="lib" path="lib/trove.jar"/>
<classpathentry kind="lib" path="lib/uddi-ws-3.0.1.jar"/>
<classpathentry kind="lib" path="lib/wstx-asl-3.2.8.jar"/>
<classpathentry kind="lib" path="lib/xbean-2.2.0.jar"/>
<classpathentry kind="lib" path="lib/xercesImpl.jar"/>
<classpathentry kind="lib" path="lib/commons-io-1.3.1.jar"/>
<classpathentry kind="lib" path="lib/commons-httpclient.jar"/>

These classpath entries come from Eclipse, but I have also tried using ant based on the Quickstart helloworld project and the classpath it uses, and I still get this problem.

The client is using the jbossesb-properties.xml that comes with the quickstart helloworld example. (LocalTransport and the UDDI wrapper classes). The only settings I changed were in uddi.xml (javaNamingProviderUrl in the registry section and serverName under node.name(@Default).properties).

My understanding is that the server is already exposing a jUDDI RMI service.

Our only other option is to write a JMS client that is aware of which Queue to submit to. This presents its own problems beyond awareness of the transport, as the JBoss SOA Message is better suited to encapsulate the data we wish to submit.

Any advice?

Separately, I thought that communication between two separate JVM's must always occur over RMI, so I don't see how the two runtime situations can practically differ.

Thanks in advance,

Adam

Hi all,

[imaeses]

Turns out we were able to solve this problem with a bit of luck! I say luck because (according to my understanding at least) the required change should not have been necessary.

In order for one (in this case Scout) client on one interface to make a call to the NamingService on another interface (in this case to make queries against the UDDI registry), the server's bind address must match the exact IP address that the client will use. That is, if in our uddi.xml we declare that the naming provider url is at jnp://192.168.2.67:1099, then the server must be started up with the option "-Djboss.bind.address=192.168.2.67" for it to be reachable (and not 0.0.0.0).

So as expected the problem had nothing to do with RMI at all but rather the interface on which the server's naming service was reachable.

Hope this helps someone other than me ;-)

Adam