EJB programming & troubleshooting: local interfaces and limitations?
- Posted by: Marc Logemann
- Posted on: June 04 2002 07:03 EDT
i am quite new to EJB, so dont burn me when this should sound somehow weird.
By reading floyds book on EJB patterns, i wondered where are the drawbacks of using local interfaces. If my facade session bean uses local interfaces to access entity beans, what happens if by some accident (workload) my application must scale across different app servers?
I mean, this way the interface cant be still local, cause perhaps the entity beans on the second server must be called or?
I think about a scenario where its not predictable if Entity_A (on server A) or Entity_B (on server B) will be called cause of runtime performance considerations.
can somebody clearify this?
thx for input.
- local interfaces and limitations? by Marc Logemann on June 04 2002 07:04 EDT
- local interfaces and limitations? by David Jones on June 04 2002 15:31 EDT
- local interfaces and limitations? by Gal Binyamini on June 04 2002 16:58 EDT
correction: Entity_B must read Entity_A!
I mean the same Entity Beans on different servers.
I'm new to EJB too, but I'm nearly sure that an Entity Bean can have both remote and local interfaces. So if, for example you try to access Entity Bean A on server A through local interfaces but you have runtime performance problems, you will call Entity Bean A on server B through its remote interfaces.
i know that there are remoteInterfaces, they are with us for a long time i think, but the point is, when the appServer decides to delegate to a different server, what happens if i only used localInterfaces. I mean, there must be a mechanism by which there is a detection what Interface to use and when. Performance is allways a runtime issue, so a developer cant foresee this ...
then try clustering
The most common pattern at the moment is to create your stateless EJBs with Remote Interface and then have them access your Entity Beans through their local interfaces.
If really want your EJBs to have local and remote interfaces publish a Remote Interface as well as a Local Interface into the JNDI tree and access as appropriate.
The limitation you describe is exactly the reason there are two types of interfaces: local interfaces are great, unless you need to access the component remotely.
I suppose the most common practice it to create remote components as session beans, and access "data components" (entities) purely using local interfaces. This is kind of like a "service based" architecture, where remote servers expose "services", not "objects". From my expirience, this type of architecture does not impose real scalability problems, except maybe in your notebook :)
Let's be clear: applications built using this architecture can still scale across many App servers: the only limitation is, each server will have it's own "entity bean cache". This can cause some theoretical limitations, but with the current level of distributed cache support, it doesn't go beyond the theoretical problem.
If you use remote interfaces, and call an entity that's actually local, the overhead will not be too big. But there is still the overhead of replicating parameters, etc. That's what local interfaces are for. If you're asking:
"Why couldn't we have an interface that behaves either as local or remote, depending on where the component is" the answer is that remoteness is a part of an interface, and "transparent" remoteness has never worked, and is fundenmentally flawed. There is a classic Sun Labs report about this issue, that made a big influence on the design of RMI and EJB. It used to be in:
But now I can't seem to access it. Does someone have a new address?
just to ensure that i get this point right, even with usage of local interfaces, the appserver is capable of scaling across several servers?
So, in practice when using sesion facade, there is no real need to use remote interfaces on entity beans, cause the appserver can reach an entity bean on ServerB even with a local interface?
If yes, that would be perfect or?
"Let's be clear: applications built using this architecture can still scale across many App servers: the only limitation is, each server will have it's own "entity bean cache". This can cause some theoretical limitations, but with the current level of distributed cache support, it doesn't go beyond the theoretical problem."
Your application can still scale in the sense that you can deploy the session bean (I'm not too fond of calling this a "facade". I think it's a misuse, in the terminological sense, of this pattern. But I digress...), along with the locally accessed entity beans, on multiple servers. The session bean deployed on ServerA will only be able to call entities on ServerA: but client requests from outside the system can be directed to any of the servers.
As I've said, this does impose some limitations. But I doubt you will ever feel them in practice. Over-distributing a system causes more harm than under-distributing it in some cases. In literally 99% of the cases, modelling a distributed seperation between the model and the controller is an overkill, IMO.