• 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
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

For clustering, should I use Remote/Local Interface for EJB ?

 
Ranch Hand
Posts: 159
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear all,

We I used clustering. I mean I deploy a ejb module into multiple servers (clustering).
Should I code this ejb against remote/local?

What I concerned is that if i code this ejb against local.
the ejb modules could not keep sync on different servers on cluster.

Thanks and Rgds

Rgds
Wang Yan
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I may not understand your description correctly but it sounds like you are under the impression that adding remote interfaces to your EJBs will inherently give them the capability of automatically synchronizing their data over multiple JVMs and servers - it does not. In regards to your situation you may want to ponder the following points:
  • First Law of Distributed Object Design: Don't distribute your objects! (Martin Fowler, PEAA p.89). So your application itself should be designed so that it is stateless. If there is any state necessary, identify the smallest possible subset and attach this "data-context" to every message between the client and the server. Of course, there are cases where this "context" can become too large.
  • Avoid giving entity java beans a remote interface - use a Session Facade instead. Once you design the session facade you may find that you really don't need the entity beans anymore.
  • Avoid using stateful session beans if you can. If it is necessary to maintain state between the client and the server, maintain that state in an HttpSession in the web tier. HttpSessions are easier to migrate from one server to another when necessary.
  • While on an API level local and remote interfaces may look very similar - they do exist for totally different reasons. The local interfaces are used for finer-grained interfaces between domain objects that reside on the same server but may want to take advantage of some of the EJB container's services (otherwise they should simply be POJOs). The remote interfaces are used for coarse-grained interfaces; much less like an object interface but more like a service interface (that uses an entire domain model to process a request). So, if you are looking at an enterprise bean that exposes the same interface locally and remotely then you are most likely looking at an inappropriate design.

  • For more advice along these lines consult Expert One-on-One J2EE Design and Development (Even chapter 1 contains useful information).
    [ September 13, 2005: Message edited by: Peer Reynders ]
     
    Ranch Hand
    Posts: 1683
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Bear in mind that the certification exam does not test you on clustering.
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic