Adam Bien's Weblog

Friday Oct 28, 2011

EJB Remote, Local Interfaces and Clustering - Question Of The Week

An interesting question:

"…I can use a local interface to access EJB locally (from another EJB for example) and remote interface to access it remotely (using standalone client, appclient client). I have a question about those in a cluster. I'm using Glassfish 3.1.1. Let's say I have a application with two EJB's (EJB_A and EJB_B) and an appclient. I can use remote interface in my appclient to access EJB_A. Right? From EJB_A I use local interface to access EJB_B, right? What If I run the same application in a cluster? Will EJB_A and EJB_B will always be accessible locally? Can it happen that EJB_A and EJB_B will be on different machines?…"

And the answers:
  1. Only remote EJBs are clusterable. The proxy (synthetic implementation of bean's remote interface) cares about clustering. It is often called: "smart stub".
  2. It is a good idea to expose a single, coarse grained remote interface (e.g. ServiceFacade), and perform everything else locally behind this boundary (e.g. take a look on x-ray). Behind a boundary every call should be performed locally. One of my most important "patterns" is: "Don't Distribute!"
  3. @Local EJB interfaces have "call by reference" semantics. There are no smart-stubs or any clustering functionality between local calls. It would break the semantics...


Special Events: Java 8 with Java EE 7: "More Power with Less Code", 13th October, 2014 and Java EE 7: "Testing and Code Quality", 14th October, 2014

A book about rethinking Java EE Patterns

Comments:

Very good subject.

I have a question though.

What if we have a hybrid session bean (EJB 3.1) without interfaces?

@Local
@Remote
public class SomeFacade {
// business logic
}

Which of the above would apply to this one?

Posted by Gozzie on October 28, 2011 at 12:18 PM CEST #

@Gozzie,

a hybrid EJB has two interfaces. It is impossible to have a no-interface @Remote EJB. Your concern is not deployable :-)

thanks for the snippet!,

adam

Posted by Adam Bien on October 28, 2011 at 02:46 PM CEST #

Hi. I sent the quoted questions. :)
Thanks for the answer. So in short: if EJB_A and EJB_B both have remote interfaces then it can happen that in one transaction EJB_A on machine 1 communicates with EJB_B on machine 2.
I was also thinking about somekind of a facade EJB, that would have a remote interface and all other EJBs only having local interfaces, so communication is local.
How fast is local communication between EJBs? Like ordinary method calls?
Thanks for the pointers. :)

Posted by Kovica on October 28, 2011 at 04:37 PM CEST #

@Kovica: They don't only have to _have_ a Remote interface, you also have to access it with that. And even then, at least JBoss "optimizes" the remote call by redirecting it to the local machine!!! So even if your EJB_A does the lookup on server B, but EBJ_B happens to be deployed on server A as well, it will actually be a call within the same VM, only with call-by-value semantics.

What's even worse: It may happen that the transaction is distributed when you don't expect it to. Ugly stuff and IMHO underspecified in the spec.

Posted by on November 09, 2011 at 07:30 PM CET #

@Rü,

you are right. All (I don't know any exception) application servers do optimize the @Remote communication. Under certain circumstances like e.g. an exception, they can re-route the call to other cluster nodes what results in unpredictable behavior.

thanks!,

adam

Posted by Adam Bien on November 13, 2011 at 07:18 AM CET #

adam can i have your email for a gtalk in gmail. Sorry to disturb you in your busy schedule.Because am a newbie j2ee programmer,so that a chat in gtalk may solve my pogramming doubts.

Posted by kisley on February 08, 2012 at 09:05 PM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
Links
License