Question

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.

Was it helpful?

Solution

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.

OTHER TIPS

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".

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top