EJB3 Local and Remote interfaces

Asked 15/12, 2011 at 20:31 Answered 15/12, 2011 at 22:47

I understood that Local interface is designed for clients in the same container's JVM instance and remote interface is designed for clients residing outside the EJB container's JVM. How about the web application client which is not reside (or packaged) in the same .ear but reside on the same Java EE server?

Stanford answered 15/12, 2011 at 20:31 Comment(4)

Why wouldn't you put the webapp in the same EAR? The point of an EAR is precisely to contain both the web and EJB parts of an application. – Stramonium 15/12, 2011 at 20:34

What do you mean by the same J2EE server? Is it deployed on the same instance, in the same domain? – Ellette 15/12, 2011 at 20:35

EAR is maintained and deployed separately and other WAR wants to use some business methods from the ejb reside in the EAR. J2EE server means they will be deployed on the same instance. – Stanford 15/12, 2011 at 21:0

In my case, on Glassfish 3.1, deploying web and ejb module separately, on their own (no ear involved), on the same instance and using @EJB annotation to inject ejbs into JSF managed-beans works. – Hyperopia 15/12, 2011 at 22:15

Officially @Local annotated beans can only be accessed if they're in the same application. A .war deployed separately from an .ear (or other .war or other .jar EJB) is a different application, even when deployed to the same application server instance.

There's thus no guarantee that the code in your .war can call @Local EJB beans that are defined in the .ear.

However, in practice in nearly all application servers this just works.

There's a request for the EJB 3.2 spec to officially support local cross-application calls: https://download.oracle.com/otndocs/jcp/ejb-3_2-fr-spec

Fidget answered 15/12, 2011 at 22:47 Comment(3)

I feel somewhat sad to be the only one who voted on this feature... Everyone - feel free to join and just click 'vote' on this JIRA request ;-) – Shipman 15/12, 2011 at 23:15

It might be quite hard to have 100% working cross-application (cross ClassLoader!) calls. Let ClassLoader 1 has class A and ClassLoader 2 has class A (another copy). Passing object A via local interface will cause ClassCastException because there are two copies of the same class. An EAR has its own sometimes isolated ClassLoader. – Pilsudski 4/9, 2012 at 20:39

Yes, the class loading isolation might be the problem here. It would still work for classes from the JDK and possibly for (interface) classes from the AS (depending on how the AS does modularization of those). Many users will probably not understand this limitation and it might become one of the new puzzlers in Java EE. – Fidget 4/9, 2012 at 21:37

Local interfaces are to be used in communication within the same application. It doesn't necessarily mean JVM.

The point is: even within the same JVM instance, on the same server, two different applications cannot communicate using local interfaces (which means local and no-interface views).

If you have a web component (WAR) as well as a business component (EJB-JAR) which is in the same application, the most intuitive and straightforward solution is to package them in one EAR or in one WAR (since Java EE 6).

Shipman answered 15/12, 2011 at 22:40 Comment(3)

Yes but this is all just theory. In practice you have a big application with multiple WARs (i.e. partner, customer and administration portal application), calling the same EJBs. For deployment/less downtime reasons you would want to package these WARs separately, as many people do. – Trim 7/5, 2012 at 9:41

Agreed - I also don't like this idea and the cumbersome EAR approach as well, but it's the officially suggested solution. – Shipman 7/5, 2012 at 10:21

Don't get me started on JEE people. The whole thing is a job security project. We've been using it in complex projects for years, and I must say that we were 10 times more productive in PHP. But nowadays the PHP is "uncool" with various certifications people, and you have to have a certificate to sell toilet paper today, so we all have to suffer bloated bullsh*t that doesn't do anything properly. It reminds me of F-35. ;) – Trim 9/5, 2012 at 13:45

You use the remote interfaces, but you make a lookup using JNDI (that's how i'd do it), this way you find the instance of the EJB in the server and can use it in your web application.

Although you still need a jar with the EJB interfaces in the web application project.

EDIT and I agree with JB Nizet, why would you want the WAR outside the EAR?

Hebbe answered 15/12, 2011 at 20:34 Comment(1)

You may want to deploy it separately because of class loading shenanigans. – Compo 15/12, 2011 at 23:14

Remote interfaces can be called across applications, from everywhere within the application server as well as from outside, even from other hosts.

So assume that you need remote (@Remote) interface. In EJB 3.1 you can use dependency injection.

Boil answered 15/12, 2011 at 20:35 Comment(0)

Recommended topics

Hot tags