Is it possible that servlet uses local interface of EJB2.0?

[xiaolin yu]

From weblogic:
"Local interfaces allow enterprise javabeans to work together within the same EJB container using different semantics and execution contexts. The EJBs are usually co-located within the same EJB container and execute within the same Java Virtual Machine (JVM)."
Is it possible that web container and EJB container use the same JVM? If it could be, then servlet can call EJB methods from local interface without network headache. Is that right?
[ January 03, 2003: Message edited by: xiaolin yu ]

[Chris Mathews]

Yes that is the purpose of Local Interfaces, to avoid the network call.

[yi zhu]

It's very bad...
1.your code will not be portable as you can not assume that web an ejb will always run in the same JVM everywhere.
2.bad design pattern.

[Paul Done]

Use the business delegate J2EE design pattern to abstract the business logic location / implementation details from the web component's code. Then your initial business delegate implementation can use the local EJB interfaces for speed. At a later date if you choose to locate your business logic (EJBs) on a different app server instance, you just plug-in a different business delegate implementation which uses remote interfaces and your web component code does not have to change.

[Chris Mathews]

Originally posted by yi zhu:
you can not assume that web an ejb will always run in the same JVM everywhere.

Why not? Separating the EJB and Web Tier was seen as a good idea but in reality it proves to be a poor decision. It is one of the best ways to handicap your application's performance. Hardly anyone recommends this approach now.

Originally posted by yi zhu:
2.bad design pattern.

What is? Local Interfaces? Local Interfaces were one of the best things added to EJB 2.0. I don't get your point and I think you are way off on this.
Regardless, the client should be hidden from the complexity of EJB by a BusinessDelegate, as Paul said.
[ January 05, 2003: Message edited by: Chris Mathews ]

[Sanjay Raghavan]

A better solution is to make use of the Session Facade J2EE Design Pattern.
Since you cannot assume that your application will always reside in the same jvm (web and app tiers), you can use the Business Delegate to communicate to a Session Facade via a remote call.
The Session Facade (which is commonly used to hide the complexity of underlying Entity Beans, but can also be used when you are modeling complex work-flow) can then communicate with the other Beans using the EJB 2.0 Local Interfaces.
This addresses any concerns you may have about scalability (as the Business Delegate is still using Remote Interfaces). You get better performance because you have fewer remote calls, and lesser overhead.
HTH.

[yi zhu]

What is? Local Interfaces? Local Interfaces were one of the best things added to EJB 2.0. I don't get your point and I think you are way off on this.
Local interface is perhaps the best thing added to EJB2.0. What I'm against is to allow servlet communicating directly with local interfaces. (Sanjay Raghavan provided a far better approach...)

[Raees Uzhunnan]

Sanjay
Your answer forgot the question was about local interface
Raees

[Sanjay Raghavan]

Raees,
No I did not forget that the question was abt Local Interfaces.
Let's give it another shot. To quote "Core J2EE Patterns" Pg 300 (Consequences of Session Facade) - "Exposes fewer Remote Interfaces to clients." When clients interact directly with business data or business service objects, it increases network chattiness....Thus the scope for app performance degradation is reduced due to the limited interactions between the client and the facade when compared to direct interaction by the client to the individual business components.
This is a good area to use the EJB 2.0 Local Interfaces. In other words the client (Business Delegate, typically) comunicates with the Session Facade using your regular remote interfaces and the session facade can in turn use the EJB 2.0 Local Interfaces to communicate with the Entity Beans.
The discussion in this thread was basically whether to replace the Remote Interfaces with Local Interfaces entirely...the argument against it is one of scalability because when you move your web tier to another box, all your business delegates are affected. The example I cited allows you to use the power of local interfaces without compromising scalability.
HTH.

[Raees Uzhunnan]

That’s good explanation Sanjay

[Chris Mathews]

Originally posted by Sanjay Raghavan:
The example I cited allows you to use the power of local interfaces without compromising scalability.

I guess this is where I disagree. I don't think that local interfaces sacrifice scalablitity at all. Quite the contary, local interfaces promote scalability far more than remote interfaces. You can easily scale a co-located Web/EJB Application across multiple machines, in fact this is the architecture recommended by most.
Artificially separating the Web and EJB Tiers for the purposes of scalability is foolishly naive. It is a waste of hardware with very little benefits and definite disadvantages. I agree that logically separating the Web and EJB Tiers is necessary. Just don't buy onto the hype that physically separating tiers means scalibility.
My feeling is that local interfaces should be the de facto choice for EJB. Only if it is determined that an API needs to be remotely accessed should remote interfaces be used. Even then it should be in the form of a Remote Facade on top of the existing components. At no time would I make Entity Beans remoteable, they are too fine-grained. Either way, if we are talking about Web Applications, the Web and EJB Tiers should be co-located whenever possible.
My 2 cents.

[yi zhu]

Originally posted by Chris Mathews
At no time would I make Entity Beans remoteable

Christ and I shared at least this point! I even suggest that local interfaces will always be hidden behind a session facade.

Originally posted by Chris Mathews
You can easily scale a co-located Web/EJB Application across multiple machines, in fact this is the architecture recommended by most.

Well, though this may be correct in some cases, it can not be true everywhere.
1. Web is only one of possible clients for EJB.
And if I follow your logic, I would say the most scalable fashion will be put all on client's PC. Then we will be back to old dark days, no more distributed computing.
2. For mostly read only EJBs, we can provide only one separated server and a few more web server. With the caching capability of EJB, this will be more scalable than the architecture you provided.
My $0.02

[Chris Mathews]

Originally posted by yi zhu:
Christ and I shared at least this point!

Yes, Christ was very smart and likely would have also used local interfaces.

Originally posted by yi zhu:
1. Web is only one of possible clients for EJB.And if I follow your logic, I would say the most scalable fashion will be put all on client's PC. Then we will be back to old dark days, no more distributed computing.

Here is where you go off track. The question was specifically aimed towards a Web Application as the client of the EJB tier. Furthermore, in the majority of cases the Web App is the only client. At which point it makes no sense to separate the tiers.

Originally posted by yi zhu:
2. For mostly read only EJBs, we can provide only one separated server and a few more web server. With the caching capability of EJB, this will be more scalable than the architecture you provided.

A separate server for just read-only/mostly data? That would be a gross misappropriation of hardware, especially in economically hard times when funding is limited. This would also be bad for performance since this is the data that is usually accessed most frequently and each access would require a network call. Wouldn't it be better to keep this read mostly data cached as close to the client as possible? Many vendors provide excellent clustering capabilities for this type of situation and there are quite a few third party products aimed at this problem.
Furthermore your solution would create a single point of failure. Of course we could always add more machines to the EJB tier but that is just wasting more hardware and adding even more complexity to manage.
The benefit of separately scaling the Web and EJB tiers is overhyped. It is hardly ever a useful feature in real systems. I reiterate once more: hardware would be better utilized by colocating the Web and EJB tiers. Avoid remote calls when at all possible. If not then minimize the effect by using Design Patterns like Remote Facade. In the majority of J2EE Applications this is easily done. I am not alone in this, many others feel the same way.

[Rufus BugleWeed]

Would anybody call FBN's scaleability concerns large?

[Thomas Taeger]

Despite all responds to your topic up to the moment of writing:
It is _NOT_ possible to let a Servlet (in the Web-Container) access
any EJB (in the EJB-Container) via a local (instead of a remote)
interface.
It is not possible to let a component in one container access
any component in another container without JNDI, RMI and
serializing (see below) - to be J2EE compliant.

The J2EE specification allows
- One AppServer have multiple containers, including max.
one EJB container and/or max. one Web container.
- inter-container calls via JNDI, RMI and serializing parameters and
passing them "by value", not "by reference".
In our case a Servlet calls an EJB's methods.
- intra-container calls via remote interfaces: old fashion style 1.1;
the call itself is ca. 2000 times slower than via local interface.
Example: A SessionBean calls an EntityBean's methods via it's
remote interface, i.e. via JNDI lookup, narrowing, serializing...
- direct intra-container calls via local interfaces (EJB 2.0 like):
the call itself is ca. 2000 times faster than via remote interface.
Example: A SessionBean calls an EntityBean's methods via it's
local interface, i.e. _NO_ JNDI lookup, narrowing, serializing is
needed.
Good luck
Thomas.

[Thomas Taeger]

No, this is true only for EJBs calling EJBs within the same container, not for Servlets calling EJBs outside the WebContainer. See my longer post below.

[Thomas Taeger]

As said in my longer post below in a J2EE compliant app server the EJB container and the Web container can _never_ run in the same JVM.
Each container runs in its own JVM.
This enables scalability, stability etc. but requires the workload of JNDI and parameter serializing and deserializing.

[Thomas Taeger]

Topic was an INTER-container call, and that will never be possible via local interfaces, see below.

[Thomas Taeger]

Reading "Exposes fewer Remote Interfaces to clients" you probabely felt "clients" to be web clients as they really are often. But "clients" may also be other EJBs, entity beans for a session bean for instance.
What you write may be right for these inter-EJB calls, but does not belong to the topic "Can a servlet call an EJB via 2.0 local interface"

[Thomas Taeger]

How to "local interfaces promote scalability"?
You wrote: "I don't think that local interfaces sacrifice scalablitity at all." As far as I know this is against the "state of the art". That does not mean that you are wrong, but you will need good arguments. Let us see:
You wrote: "You can easily scale a co-located Web/EJB Application across multiple machines, in fact this is the architecture recommended by most." My questions are:
- What is a "co-located Web/EJB Application"? A Web/EJB Application running in one and only one container?: Impossible in J2EE.
You wrote: "Artificially separating the Web and EJB Tiers for the purposes of scalability is foolishly naive.". I agree as far as I allways try to avoid CROSSING container boundaries. To avoid "separating the Web and EJB Tiers" you would have to write a JavaWebStart application or an 2.0-applet that calls EJB methods DIRECTLY without using any mediating servlet. But you also wrote "At no time would I make Entity Beans remoteable, they are too fine-grained.".
You wrote: "Either way, if we are talking about Web Applications, the Web and EJB Tiers should be co-located whenever possible." In a J2EE compliant app server this will never be possible.
Best wishes
Thomas.

[Chris Mathews]

Originally posted by Thomas Taeger:
As said in my longer post below in a J2EE compliant app server the EJB container and the Web container can _never_ run in the same JVM.
Each container runs in its own JVM.
This enables scalability, stability etc. but requires the workload of JNDI and parameter serializing and deserializing.

Sorry you are dead wrong on this. Every major Application Server on the planet runs the Web and EJB Container in the same JVM. This is true for WebLogic, WebSphere, JBoss, Sun ONE, Pramati, JRun, etc...

Directly from the J2EE 1.3 Specification
Section J2EE.6.4:
The EJB Container is required to support access to local enterprise beans. We recommend that the web container also support access to local enterprise beans.

[Chris Mathews]

Originally posted by Thomas Taeger:

The J2EE specification allows
- One AppServer have multiple containers, including max.
one EJB container and/or max. one Web container.

Actually this is required by the spec and despite what you are saying it is possible and recommended that the EJB Container and the Web Container run in the same JVM process.

Originally posted by Thomas Taeger:
- inter-container calls via JNDI, RMI and serializing parameters and
passing them "by value", not "by reference".
In our case a Servlet calls an EJB's methods.
- intra-container calls via remote interfaces: old fashion style 1.1;
the call itself is ca. 2000 times slower than via local interface.
Example: A SessionBean calls an EntityBean's methods via it's
remote interface, i.e. via JNDI lookup, narrowing, serializing...

Again local calls are possible. BTW, where does your 2000 times more expensive statistic come from?

Originally posted by Thomas Taeger:
- direct intra-container calls via local interfaces (EJB 2.0 like):
the call itself is ca. 2000 times faster than via remote interface.
Example: A SessionBean calls an EntityBean's methods via it's
local interface, i.e. _NO_ JNDI lookup, narrowing, serializing is
needed.
Good luck
Thomas.

Yes local invocations are faster... lucky we can use them from the Web tier. Though in all honesty Application Servers have been optimizing the remote call away for years. In WebLogic a call to a Remote EJB in the same JVM will default to pass-by-reference unless you specify otherwise. This of course is a vendor extension but it is offered by most vendors.
[ January 08, 2003: Message edited by: Chris Mathews ]

[Raees Uzhunnan]

Hi All,
Chris is correct.
look at "Designing Enterprise Applications with the J2EETM Platform, Second Edition"
section 4.4.7.3.1 Maintain Session State with Stateful Session Beans
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html#1083750
The section says
You can maximize the runtime performance of this approach by choosing a J2EE server product that permits use of local EJB interfaces from co-located Web components.
I think Thomas Taeger is dead wrong on his arguments and the figures looks bogus
Raees

[Thomas Taeger]

Originally posted by RAEES UZHUNNAN:
Hi All,
Chris is correct.
look at "Designing Enterprise Applications with the J2EETM Platform, Second Edition"
section 4.4.7.3.1 Maintain Session State with Stateful Session Beans
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html#1083750
The section says
You can maximize the runtime performance of this approach by choosing a J2EE server product that permits use of local EJB interfaces from co-located Web components.
I think Thomas Taeger is dead wrong on his arguments and the figures looks bogus
Raees

... and I am really sorry for that. Thank you for providing us with the exact link.
Thomas.

[Chris Mathews]

Originally posted by Thomas Taeger:

... and I am really sorry for that. Thank you for providing us with the exact link.
Thomas.

No problem. Sorry for the flaming.

[Raees Uzhunnan]

.. Its all part of a healthy discussion ..Don't worry about it man...
Raees

[Thomas Taeger]

Originally posted by RAEES UZHUNNAN:
You can maximize the runtime performance of this approach by choosing a J2EE server product that permits use of local EJB interfaces from co-located Web components.

Hi Raees, hi Chris,
I accepted beeing "dead wrong" (I do not really know what "dead wrong" - slang?- means), but I just found

by Shai Almog:
"Re: Enterprise Applications CMP or JDO Posted: Jan 15, 2003 1:15 PM" in
http://www.javalobby.org/threadMode2.jsp?forum=61&thread=6407&start=0 :
"the web tier can't invoke the local interfaces (it can in some conditions but there is no spec guarantee that I know of)."

So I feel being brought back to what I originally ment with:

Originally posted by Thomas Taeger:
... - to be J2EE compliant.

However it was very interisting to hear about co-located containers (co-located in one JVM).
Do you agree that this is not guaranteed by the J2EE specification (regardless wether allowed or not) and therefore not guaranteed to be portable?
Thomas.

[Chris Mathews]

Originally posted by Thomas Taeger:
Do you agree that this is not guaranteed by the J2EE specification (regardless wether allowed or not) and therefore not guaranteed to be portable?

You are correct. It is not guaranteed. However, it is strongly recommended by the J2EE 1.3 Specification that the Web Container and EJB Container be run within the same JVM. I point you to my previous quote from the J2EE Specification:

Section J2EE.6.4 of the J2EE 1.3 Specification
The EJB Container is required to support access to local enterprise beans. We recommend that the web container also support access to local enterprise beans.

Furthermore, every Application Server that I know of runs the Web Container within the same JVM as the EJB Container. This is can basically be taken as a standard feature. It would be a huge difficiency in the Application Server to not allow this.
I personally know this is true for WebLogic, WebSphere, Sun ONE Application Server, Oracle 9iAS, Pramati, JBoss, and JRun.
[ January 21, 2003: Message edited by: Chris Mathews ]

[Lipman Li]

the very original question is in WebLogic, is it possible to call LocalInterface from Servlet,
the answer is yes.
even though every one agree that it is true for almost every known App Server, but it is not good habit so far, specially u want to use it to prepare your Architect assignment.
I also use Weblogic, my servelt & JSP use local interface to call EJB for EJB unit testing only.

[Chris Mathews]

Originally posted by Lipman Li:
even though every one agree that it is true for almost every known App Server, but it is not good habit so far, specially u want to use it to prepare your Architect assignment.

No way. It is very good practice to use Local Interfaces from the Web tier. Why use Remote Interfaces if you don't have to? Besides, the Web tier should be insulated from EJB by Business Delegates.
Sure for SCEA you shouldn't assume Local Interfaces but that is a completely different situation.
Number one rule: Avoid Remote calls when possible. If it doesn't make sense to separate the Web and EJB tier, and it doesn't in the majority of cases, then don't. If you are not going to separate the tiers then it makes no sense not to use Local Interfaces.
Way too many people just slap a Remote Interface on every EJB and call it a day. This is a shame, because the requirements of a distributed API are much different than that of a local API. EJBs systems should be developed completely using Local Interfaces and than Remote Facades should be layered on top where it is necessary. It shouldn't be the other way around. Remoteability should not be the driving force behind the Domain Design.
[ January 22, 2003: Message edited by: Chris Mathews ]

[Lipman Li]

Hi Chris,
from your writting, I could get the impression that you are refering EJB as Entity Bean only. Session Bean is not EJB.
I agree that Entity Bean shall be used through local interface as much as possible. most developer just do that exactly. for Session Bean, it is not always like that.
does the so-called Remote Facade provide Remote interface ? how you servlet talk to your Remote Facade?
does the servlet talk to Entity bean directly?

[Chris Mathews]

Originally posted by Lipman Li:
From your writting, I could get the impression that you are refering EJB as Entity Bean only.

No I am referring to EJB as a whole. This includes Entity and Session Beans. Message Driven Beans are a different story, since they are never directly executed by a client.

Originally posted by Lipman Li:
Does the so-called Remote Facade provide Remote interface ? how you servlet talk to your Remote Facade?

Remote Facade is a Pattern, not an implementation. Therefore, it is up to the Developer/Architect as to how it is implemented. One logical implementation in J2EE would be a Session Bean. Another implementation could be a Web Service. The important thing about a Remote Facade is that it does not contain business logic. Therefore, it is possible to have Session Beans that encapsulate business logic that are Local Interface only and Session Beans that serve as Remote Facades which by definition have Remote Interfaces.

Originally posted by Lipman Li:
Does the servlet talk to Entity bean directly?

I still believe in the use of Session Facades. They put a nice Service Layer on top of Entity Beans. Though I think with EJB 2.0 one could make a strong argument for having Local Entity Bean use on co-located clients. However, nobody should EVER make Entity Beans remotely accessable. They are far too fine-grained.

[Andrew Spruce]

Is this not a little detailed for the architect exam. After all a deployment diagram is not part of the deliverables
I would guess that the design should avoid making assumptions for vendor specific features if possible, where unavoidable they should be stated in the assumptions.
The requirements usually indicate a need for scalability.
This is often done horizontally through clustering and therefore requires remote interfaces. Clustering doesn't always achieve an improvement in performance but it is one of the scalability features of J2EE that I guess the Sun people are looking for
I guess you don't even need to mention which method because as already mentioned, the lookup logic should be hidden behind a BusinessDelegate.
Just my two-penneth