3

Is it possible to create a client that accesses an EJB3 bean, with the client having no dependence on a vendor JAR or configuration? We currently need to support scenarios where our service is deployed on a WebSphere or JBoss server, and the client is deployed as an application either on a WAS or JBoss, or is running as a standalone app.

I used to be able to do to this with EJB2.x beans, I just needed to create stubs using RMIC.

But with EJB3, If I'm connecting to WebSphere I have to include thinclient JARs, plus I have to pre-generate the stubs using WAS tools. For JBoss I have to use jboss-client.jar.

Renan
  • 827
  • 8
  • 16
  • I'd consider using ws over ejb for remote invocation – Sami Korhonen Feb 20 '14 at 10:17
  • yeah I thought about that too, but we're neck deep in EJBs already. plus we can't lose the performance boost we got from using RMI. – Renan Feb 20 '14 at 10:22
  • From my expirements performance difference is negligible. I guess you could also use jax-rs and java serialization, if you are worried about jax-ws's performance – Sami Korhonen Feb 20 '14 at 10:42
  • we're sending really big objects across. our tests show an almost 50% speed pickup from plain servlet calls using XML. – Renan Feb 20 '14 at 22:40
  • Try the jax-rs and java object serialization then, it should be as fast as rmi. Btw, why did you use servlets + xml over jax-ws services (servlet + xml combination is much harder to get right performance wise, esp if you are using jaxb for marshalling/unmarshalling) – Sami Korhonen Feb 20 '14 at 22:55
  • Oh, this software is *old*. The servlets were written when the servlet spec became official. ~1999 – Renan Feb 20 '14 at 22:59

2 Answers2

3

No, this is not possible. This has been made explicit in section 10 of the EJB 3.2 specification:

This chapter describes the interoperability support for accessing an enterprise bean through the EJB 2.1 remote client view from clients distributed over a network, and the distributed interoperability requirements for invocations on enterprise beans from remote clients that are Java Platform, Enterprise Edition (Java EE) components. Distributed Interoperability is not defined for the EJB 3.x remote client view.

Also note section 10.5.5:

System value classes are serializable value classes implementing the javax.ejb.Handle, javax.ejb.HomeHandle, javax.ejb.EJBMetaData, java.util.Enumeration,java.util.Collection, and java.util.Iterator interfaces. These value classes are provided by the EJB container vendor. They must be provided in the form of a JAR file by the container hosting the referenced bean. For interoperability scenarios, if a referencing component would use such system value classes at runtime, the Deployer must ensure that these system value classes provided by the container hosting the referenced bean are available to the referencing component. This may be done, for example, by including these system value classes in the classpath of the referencing container, or by deploying the system value classes with the referencing component’s application by providing them to the deployment tool.

For WebSphere Application Server, the EJB thinclient contains these system value classes as well as the IBM JNDI implementation that uses CosNaming. In theory, this thinclient is not needed if you don't need the system value classes and your client JVM has its own ORB with an implementation of CosNaming.

Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • I am using the SUN CosNaming class. I've been trying to make it work, but I'm running into 'non-matching serialization' issues. Which probably means the WAS system value classes do not match the SUN system value classes. – Renan Feb 20 '14 at 22:37
  • If you can provide the specific exception message/stack (perhaps update the question description or create another question), I can try to take a closer look. Perhaps the value classes for argument/return/exception are different between client and server? If not, perhaps there's an interop bug in either the Sun/Oracle or WAS code. – Brett Kail Feb 20 '14 at 23:22
2

Short answer: No, it's not possible, as a client needs three things:

  • The interface classes.
  • The client libraries of the server AS (yes, sadly)
  • A configuration telling the client the server address/jndi lookup path (qa, prod etc.)

If your client is running on the same product (let's say JBoss to JBoss communication), you will not be in need of client libraries and just be able to do a remote lookup. If you have a mix of client/server application servers this will make things complicated, as you will have to run client libraries of one product in another server product.

Speaking of standalone applications running as clients, I'd just build and provide 1 heavy client jar/lib containing not only the interface classes, but also the client libs of both servers. Then providing a small helper class that returns the correct InitialContext created and based either on JBoss or Websphere depending on a flag in the client configuration.

I know this last idea ain't a clean solution, though might even work in a different AS product running as "client".

Big Bad Baerni
  • 996
  • 7
  • 21
  • 1
    we actually already have that 1 heavy client JAR that has class that acts as a gateway. Our concern now is that the WAS thinclient JARs are relatively huge (17MB total). And due to licensing issues, we are not allowed to bundle jboss-client.jar with our product. – Renan Feb 20 '14 at 22:34
  • You Sir, are in a horrible situation :( Besides having licensing issues, imagine having a JBoss client jar as a requirement in a running WebSphere application, that of course also does lookup local EJBs. It's surely possible with coded lookups and encapsulate the remote calls, though you are then so far away from the sexy HelloWorld examples that just use EJB / Inject annotations and shine so nice in JEE tutorials :( – Big Bad Baerni Feb 21 '14 at 08:57