• 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 Client Vs. Remote Client

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear Ranchers,

My understanding is that eventhough the client that invokes the Bean is running in the same JVM it is good to expose the bean as remote as in future it would be helpful scaling it horizontally.

In the case of AdviceBean example, the AdviceClient is being invoked in the same JVM as the server in which the bean is deployed. So my question is when we do a PortableRemoteObject.narrow(o, AdvisorHome.class) which would generally return a reference to the stub of a component Interface, does the Container know when it did a JNDI lookup that it found the AdvisorBean locally and that it does not have to make remote calls and thereby instead of returning a reference to the stub of a Component Interface, returns a direct reference to the EJBObject??

Best Regards,
Agasthya
 
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can access the ejb thru its remote interface, even if you are in the same container.
 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It wont be like a box of chocolates, you will always know what you are gonna get.
 
Agasthya Iyer
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes I know that we can access the ejb thru the remote interface even if it is in the same container.

The question is How?? Does the container have to determine that it does not need to use serialization as all the processing is going to happen in the local heap and it can pass object references to method calls??

Best Regards,
Vish
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Agasthya Iyer:
My understanding is that eventhough the client that invokes the Bean is running in the same JVM it is good to expose the bean as remote as in future it would be helpful scaling it horizontally.


While that is possible technically, architecturally speaking that is a Really Bad Idea. To quote Rod Johnson from Expert One-on-One J2EE Design and Development (p.224; find a great sample chapter here):


The following issues should be considered before giving an EJB both a remote and local interface:

  • It is potentially confusing to have the same object supporting both call-by-value and call-by-reference, even if it doesn't happen through the same methods.
  • Remote and local interfaces are likely to vary in level of abstraction and granularity, confilicting with it being good OO practice for all object's methods to be at a consistent level of abstraction. Remote interfaces should be coarse-grained; the local interfaces may be finer grained.
  • If the bean is really a remote object, yet it provides a local interface to support local callers, it might be better to refactor the functionality used by local callers into a helper class. Having one EJB call another indicates questionable design.

  • The greatest benefit of local interfaces is that they make the implementation of the session facade possible - because many entity beans are just too finely grained to be accessed remotely.

    Originally posted by Agasthya Iyer:
    In the case of AdviceBean example, the AdviceClient is being invoked in the same JVM as the server in which the bean is deployed.


    No it's not. If you are running the setup as described in HFEJB then your client and application server are running in different processes - that means the client has an instance of the JVM and the server has a separate instance of the JVM - even if its on the same physical machine.

    Originally posted by Agasthya Iyer:
    Does the container have to determine that it does not need to use serialization as all the processing is going to happen in the local heap and it can pass object references to method calls??


    The EJB specification makes no such requirement - so in general all the usual overhead is still done even if the "remote" call is local. Some vendors feature value-added optimizations that you can turn on - however you have to be very careful that you handle the call-by-value/call-by-reference issues very carefully - otherwise the optimization could break your code.
    [ November 11, 2005: Message edited by: Peer Reynders ]
     
    Agasthya Iyer
    Greenhorn
    Posts: 17
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Superb explanation. Thank you Peer.

    Regards,
    Agasthya
     
    It's a beautiful day in this neighborhood - Fred Rogers. Tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic