• Post Reply Bookmark Topic Watch Topic
  • New Topic

Concept of local in EJB.

 
Vishal Saxena
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,
I am unable to grasp the concept of 'local' in EJB(as in LocalHomeInterface).
If it implies the same JVM, to that particular client the bean is not remote.
The only case I can think of is, that apart from this local client there are remote clients as well. If all clients are local why go for distributed computing(EJB based over RMI) at all.
Thanks in Advance. Regards too.
 
Matthew Phillips
Ranch Hand
Posts: 2676
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One example of when to use Local interfaces is when you wrap your Entity Beans with Session Beans. You can have your clients call the Session Beans through remote interfaces to perform business logic on the Entity Beans. To speed up interaction between the Session Beans and Entity Beans you could have the Session Beans access the Entity Beans through the local interface instead of a remote interface.
 
Chris Mathews
Ranch Hand
Posts: 2712
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to add to Matthew's post... remote distribution is just one of the benefits of using EJBs. It is also one of the most abused features, most projects I see do not need to be distributed and doing so is just asking for trouble.
The reasons I would consider EJB are:
  • Remote Distribution (if it makes sense for the project)
  • Transaction Management
  • Declaritive Security
  • Container-Managed Persistance
  • Message Driven Beans (much better than writing plain old JMS listeners)
  • Timer Services of EJB 2.1 could be nice.
  • Web Services features of EJB 2.1
  • Add your own reasons...


  • If your project doesn't require any of those then EJB is probably overkill and more trouble than it is worth.
    [ May 21, 2003: Message edited by: Chris Mathews ]
     
    Stan James
    (instanceof Sidekick)
    Ranch Hand
    Posts: 8791
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I like your list of decision criteria for when to use EJB!
    Here's a made up scenario. I have a server, I checked that list, and it screams to be EJB. It has two public services that I publish to the world as stateless session beans. Clients call service 1, then service 2, they are happy.
    Now, some place in service 1 I discover I need to call service 2. Before local, I had to do a full blown JNDI name lookup and go across the network (not far: out one port, in another) to myself to call Service 2. Slow, ugly. With local, the container realizes it doesn't have to do all that stuff, but can hook me up for a more direct call. Faster, cheaper, smiles all around.
    I worked on one system before local was invented with a lot of calls like that. We finally decided we should have built exactly one EJB as a facade for a bunch of vanilla Java classes.
     
    Kalpesh Soni
    Ranch Hand
    Posts: 312
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Local is good , no doubt
    but it could have been made easier
    e.g. when u r accessing ejb2 from ejb1, just write something in ejb-jar.xml to say that ejb1 would be in same jvm
    actually weblogic does this by default, i.e. if client and ejb are in same jvm, data is not serialized and all !
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!