• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Local vs. Remote Interface

 
Ranch Hand
Posts: 78
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
from EJB 2.0, i heard that itz easy to instantiate a EJBean without much overhead in going thru' whole process of accessing local stub, then marshall parameters......etc. with the use of LOCAL OBJECT & LOCAL interface.
Could anybody detail a bit on this and how itz different from Remote object(EJBObject)/remote interface ?.
Any input is appreciated.
~ Shalini
 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi we use Local Interface in the same way as Remote Interface
but in local interface there is no remote call it is local call
no network traffic it is like local method call
but in Remote Interface
network traffic is there
the difference is that local interface are more efficient
 
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In local interfaces, you still need EJBLocalObjects...
but no stubs, so no RMI and of course, better performance
 
Ranch Hand
Posts: 282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If I have Tomcat and Weblogic on the same machine, when servlet/JSP call the EJB, we should use Local or Remote interface?
What if Tomcat and Weblogic sitting on different machine but with network connection?
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by sarah Marsh:
If I have Tomcat and Weblogic on the same machine, when servlet/JSP call the EJB, we should use Local or Remote interface?
What if Tomcat and Weblogic sitting on different machine but with network connection?


This is a great case for using the Business Delegate pattern. Instead of clients looking up a local or remote interface and using it directly, they get a delegate from a Service Locator. For this case, you basically take the local interface and use it as the base delegate interface. The local delegate implementation simply proxies the call to the local object. The remote implementation should do the same but catch RemoteException and throw a different exception that is already listed in the throws (or is added to the base interface).
This way the clients don't have to know whether they have a local or remote object. The Service Locator decides either via configuration or at runtime which one to give to the client, but both implementations have the same interface.
Here's an simple example:

Of course you'll need to provide the code to look up the EJBs in each implementation, but you already need that.
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by sarah Marsh:
If I have Tomcat and Weblogic on the same machine, when servlet/JSP call the EJB, we should use Local or Remote interface?
What if Tomcat and Weblogic sitting on different machine but with network connection?


My understanding is that, for local interfaces to work, both Servlet/JSP and EJBContainer need to run on the same JVM. Some application servers do allow local interfaces access from Servlet/JSP layer if it is the same application server that hosts both Servlet engine and EJB Container, but I am not entirely sure about 2 different products from 2 different vendors like Tomcat and Weblogic.
I am curious as to, why use Tomcat when you have access to one of the best application servers in the market, Weblogic ...Is it something to do with licensing, does Weblogic license its EJBContainer seperately?
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Harkness:
This is a great case for using the Business Delegate pattern. Instead of clients looking up a local or remote interface and using it directly, they get a delegate from a Service Locator. For this case, you basically take the local interface and use it as the base delegate interface. The local delegate implementation simply proxies the call to the local object. The remote implementation should do the same but catch RemoteException and throw a different exception that is already listed in the throws (or is added to the base interface).
This way the clients don't have to know whether they have a local or remote object. The Service Locator decides either via configuration or at runtime which one to give to the client, but both implementations have the same interface.[/QB]


This is a good design pattern. But it is also essential to know that the Remote client view assumes that copies of objects are passed, while the local client view assumes that references of objects are passed.
 
Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Shalini,
Remote EJB are nothing but distributed objects.
Distributed objects are called by in-process clients, out-of-process clients or a client located elsewhere on the network.
For Distributed objects :-
1. Client calls stub : client side proxy object. Stub is responsible for masking network communications from client.
2. Stub calls over the network to a skeleton : server side proxy object.
Skeleton masks network communication from distributed object.
3. Skeleton delegates call to distibuted object, which does its work and returns control back to the Skeleton, which returns to the Stub, which then returns back to the client.
In short Stub clones the Distibuted Objects method signatures.
Local objects do not need all this Networking concepts.
HTH,
Seetesh
 
reply
    Bookmark Topic Watch Topic
  • New Topic