Why and when to use local interfaces ?

[James Adams]

When is it appropriate to use local interfaces ? Is it only when you know that your client and server will always be on the same machine ? Is there an online article which outlines the reasons for and the benefits of local interfaces ? It's not altogether clear to me as an EJB newbie.
Thanks in advance for your feedback.

-James

[Kyle Brown]

Well, my recommendation is pretty simple. Always use only Local Interfaces for Entity beans. In never made sense to make an Entity bean a remote object -- transaction management alone made that a nightmare to deal with.
For Session beans, my recommendation is to build both, but to program your clients in most cases to the Remote Interface. That way you can easily separate or rejoin your Web Tier and your EJB tier as necessary without having to change the code. If performance becomes an issue, even after co-hosting your Web Tier and EJB tier on the same machine so as to avoid network overhead, then use the Local Interface to the session bean to gain the little bit of performance boost that avoiding serialization/deserialization will give you.
Kyle

[Ade Barkah]

My $0.02,
One should not create extra interfaces on the premise that they "might" be used later. Trying to optimize an application too early by providing both remote and local interfaces is questionable at best.
As a general rule, prefer (coarse-grained) remote interfaces for session facades so you can independently scale different tiers of the application, and to prevent clients from depending on pass-by-reference semantics. Apply best practices such as using 'value objects' to minimize the cost of having remote calls. Only convert those interfaces into local ones as a last resort.
If you do run into performance problems, solve it by doing things like optimizing your database queries, selecting better data structures, caching results, using more efficient algorithms, pooling heavy objects, etc., instead of by wholesale conversion to local interfaces.
Hope that helps,
-Ade Barkah

[Jeanne Boyarsky]

I read in an article that local interfaces can't be used if you are clustering the app server. Is this only if you have the web and ejb layer on different machines?

[Chris Mathews]

Originally posted by Jeanne Boyarsky:
I read in an article that local interfaces can't be used if you are clustering the app server. Is this only if you have the web and ejb layer on different machines?

If you always co-locate your web and ejb tiers on nodes within the cluster then you can certainly use Local Interfaces. In fact, this is the architecture that I most often recommend.

[Chris Mathews]

Originally posted by Ade Barkah:
My $0.02,
One should not create extra interfaces on the premise that they "might" be used later. Trying to optimize an application too early by providing both remote and local interfaces is questionable at best.
As a general rule, prefer (coarse-grained) remote interfaces for session facades so you can independently scale different tiers of the application, and to prevent clients from depending on pass-by-reference semantics. Apply best practices such as using 'value objects' to minimize the cost of having remote calls. Only convert those interfaces into local ones as a last resort.
If you do run into performance problems, solve it by doing things like optimizing your database queries, selecting better data structures, caching results, using more efficient algorithms, pooling heavy objects, etc., instead of by wholesale conversion to local interfaces.
Hope that helps,
-Ade Barkah

Actually, I think it is best to always err on the side of local interfaces. Make everything a local interface and then make deliberate decisions on what services to provide remotely. This keeps a nice coarse-grain interface to your remote api and can be easily implemented by layering a
Remote Facade on top of your local ejbs.

[Chris Mathews]

Originally posted by Ade Barkah:
As a general rule, prefer (coarse-grained) remote interfaces for session facades so you can independently scale different tiers of the application, and to prevent clients from depending on pass-by-reference semantics.

I should also add, as I have in the past, local interfaces are not required in order to cluster or scale an application. In fact, applications that make use of ejbs are no more scalable than applications that just use Servlets/JSP.

[Kyle Brown]

Originally posted by Jeanne Boyarsky:
I read in an article that local interfaces can't be used if you are clustering the app server. Is this only if you have the web and ejb layer on different machines?

That is hogwash. Local interfaces and clustering are perfectly compatible -- see what Chris says later. Post a link to the article here if you can find it. Sounds like the authors are blowing smoke...
Kyle

[Ade Barkah]

Originally posted by Chris Mathews:

Actually, I think it is best to always err on the side of local interfaces. Make everything a local interface and then make deliberate decisions on what services to provide remotely. This keeps a nice coarse-grain interface to your remote api and can be easily implemented by layering a Remote Facade on top of your local ejbs.

Instead of having session beans with only local interfaces -- to be invoked from the facades -- then consider just implementing them as plain-old Java classes instead. Why bother, in most cases? Their transactional context, security, object lifecycle, etc., are dependant on the facade layer anyway. Encapsulation is good, but only to a point.
Having layers of session beans on top of other session beans not only slows things down (even if they are local) but may introduce subtle problems (e.g., state-chaining issues if any of the beans are stateful.)
-Ade Barkah

[Kyle Brown]

Originally posted by Ade Barkah:

Instead of having session beans with only local interfaces -- to be invoked from the facades -- then consider just implementing them as plain-old Java classes instead. Why bother, in most cases? Their transactional context, security, object lifecycle, etc., are dependant on the facade layer anyway. Encapsulation is good, but only to a point.
Having layers of session beans on top of other session beans not only slows things down (even if they are local) but may introduce subtle problems (e.g., state-chaining issues if any of the beans are stateful.)
-Ade Barkah

What do you mean by this? Local Interfaces would still provide security, transactional context and object lifecycle. The only thing you don't get with local interfaces is distribution. That's why I'm saying have two interfaces that are EXACTLY THE SAME with only one implementation class. It's the same facade! Why did you think this was an extra layer?
The only difference in your code is then which home you obtain -- the local or remote -- and whether you just cast your stub to the local interface, or use PortableRemoteObject.narrow().
In fact. this is the kind of thing you can safely hide in a business delegate, and if you use a factory to create the business delegate, no one will ever be the wiser.
Kyle

[Ade Barkah]

Good discussion.
Kyle my post was specifically addressing Chris' suggestion of having local-only session beans, along with Remote Facades. This is a different idea from yours of always declaring both local & remote interfaces.
Let's examine the local-only session beans. They can't be called by "clients" directly since non-layer clients would use the Facades. Thus their only clients must be other session beans within the same layer. So we have a layer chain, e.g. (servlet)->(remote facade bean)->(local-only session bean)->(possibly other beans).
Although these local-only beans are capable of initiating their own transactions, managing their own security, having their own state, etc., 99 times of out 100 they will never do so. Typically these beans will simply use the transactional and security context propagated from the calling session bean (ie., likely from the Facade.) It would also be risky for them to be stateful unless all of their clients are stateless.
Which goes back to my previous post... if realistically these local-only beans will never have context independent from its caller, then why not simply use POJOs? Session beans (even with local interfaces) are expensive to have and manage.
In one large project I encountered, it seems that the architect made every single helper class into (local) session beans in the name of "encapsulation" and "reuse". I'd say a good 75% of the beans were totally dependant on other beans, and should have been POJOs. The performance of the system was horrible, and the architect couldn't figure out why.
-Ade Barkah

[Kyle Brown]

Whoo. Now that you put it that way I agree with you 100%. A top priority is to limit the number of Session beans in your app. The fewer the better. I've seen the same kind of thing (making every class an EJB) and it is a nightmare, I'll agree.

Kyle