Accessing remote ejb from classic websphere application with websphere liberty application

1
votes

I need some help using remote ejb calls. There is the following setup:

Background:

A JavaEE web application (naming it app1) is hosted on an oldschool WAS8 application server. The application provides at least one (knowen) remote ejb for application to application communication.

An other JavaEE web application (naming it app2) is hosted on a websphere liberty server. (We are currently migrate this application from WAS8 to websphere liberty.) This application (app2) now has to access the remote ejb provided by app1.

Problems:

  1. The old implementation of the remote ejb call did not perfom with websphere liberty. I did a lot of research and was able to migrate the remote ejb call. That looks like this:

    try {

    // Holds the server address 
    String server = "server.address:port";

    // Building JNDI address:
    // E.g. corbaname:iiop:server:port/java:global/app1/ejb-module/BeanImpl!qualified.name.of.RemoteBean
    StringBuilder address = new StringBuilder("corbaname:iiop:") // Protocol
            .append(server) // Server address
            .append("/") // Separator
            .append("java:") // EJB context
            .append("global/") // Globales Repository
            .append("app1/") // Applikation
            .append("ejb-module/") // module
            .append("BeanImpl!") // Bean
            .append("qualified.name.of.RemoteBean"); // Remote Interface

    // Performing jndi lookup (shadowed remote ejb call by context (liberty server))
    Object o = InitialContext.doLookup(address.toString());

    // Casting requested object
    service = (qualified.name.of.RemoteBean) PortableRemoteObject.narrow(o,
            qualified.name.of.RemoteBean.class);
} catch (NamingException e) {

    // Catching naming errors
    log.warn("Cannot read app1 URL from JNDI: {}.", e.getMessage());
    log.error("Exeption: ", e);
} catch (SystemException e) {

    // Catching any other error
    log.warn("Cannot connect to app1: {}", e.getMessage());
    log.error("Exeption: ", e);
}

    This code compiles and is executable w/o any naming exception.

  2. I am still not able to successfully request any remote ejb object. On every request, a org.omg.CORBA.OBJ_ADAPTER exception occures with the following stacktrace (error message: org.omg.CORBA.OBJ_ADAPTER: : vmcid: 0x4942f000 minor code: 0xb81 completed: No):

     Exeption:  org.omg.CORBA.OBJ_ADAPTER: 
    at org.apache.yoko.orb.OB.Util.unmarshalSystemException(Util.java:165)
    at org.apache.yoko.orb.OB.GIOPConnection.processReply(GIOPConnection.java:543)
    at org.apache.yoko.orb.OB.GIOPConnection.processMessage(GIOPConnection.java:365)
    at org.apache.yoko.orb.OB.GIOPConnectionThreaded.execReceive(GIOPConnectionThreaded.java:429)
    at org.apache.yoko.orb.OB.GIOPConnectionThreaded.access$200(GIOPConnectionThreaded.java:42)
    at org.apache.yoko.orb.OB.GIOPConnectionThreaded$Receiver.run(GIOPConnectionThreaded.java:68)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

I have no idea what is happening there. I guess that the requesting VM (Oracle Java 8) is not able to read the object from the response (sent from IBM J9 VM with Java 6)

Infrastructure information:

The WAS8 is running with the IBM J9 VM with java version 1.6.0 on a linux server, hosted in my companies intranet. The WAS8 is version 8.0.0.15 ND.

The websphere liberty is running with the Java HotSpot(TM) 64-Bit Server VM with java version 1.8.0_172-b11 on a windows 10 machine, connected via VPN to the same network zone like the WAS8 application server. Liberty is version 18.0.0.2

Question:

  1. Is the JNDI address correct? The binding of the remote ejb is the following (from server startup log):

    [1/11/19 13:26:21:230 CET] 00000008 EJBContainerI I   CNTR0167I: The server is binding the qualified.name.of.RemoteBeaninterface of the BeanImplenterprise bean in the ejb-module.jar module of the app1 application.  The binding location is: BeanImpl
[1/11/19 13:26:21:246 CET] 00000008 AbstractEJBRu I   CNTR0167I: The server is binding the qualified.name.of.RemoteBeaninterface of the BeanImplenterprise bean in the ejb-module.jar module of the app1 application.  The binding location is: java:global/app1/ejb-module/BeanImpl!qualified.name.of.RemoteBeaninterface

  2. Is it possible to call a remote ejb from an other jvm with a different vendor an a different version in general?

  3. Is there any documentation about WAS8 concerning it's NameService?

1
javajakarta-eeejbwebsphere-libertywebsphere-8

1 Answers

0
votes

A similar thread in DeveloperWorks discusses the issue of a Liberty client invoking an EJB in tWAS. At the time, there was question on whether Liberty had this functionality. RFE 32815 has since been implemented. And Liberty doc shows examples of EJB lookups (see links given below.)

In any case, based on the stacktrace you posted, it appears the CORBA.OBJ_ADAPTER is being thrown on the tWAS server and the client is processing that exc from within a reply message from the server. Trace from the server may be necessary. I would also run dumpnamespace on your tWAS server in order to see the topology-based ejb object you're trying to look up and try using that rather than the java:global name.

As to your specific questions:

  • A1. While the "java:global" indirect name may be valid, most lookups I see into tWAS namespace employ topology-based qualified names (e.g. cell//node/...)
  • A2. In general, yes, interoperability between different CORBA/Naming versions and vendors should exist.
  • A3. See links listed below.

If none of the following doc helps, it would be best to open a ticket with IBM support so we can more easily exchange logs etc and tap the various Liberty, tWAS Naming/EJB experts.

Doc Links: