Why EJB endpoint is neccessary?

[Jack Zhou]

For me, You can always use a JSE and let JSE delegate to EJBs if services like transaction, security is required. So what is the benifit using EJB end point? I guess the EJB end point in the J2EE server will probably be ceated via a behind scen JSE. However, this "behind" scean JSE give very samll benifit for development. Is it possible, a vendor can realiaze a EBJ end point without createing a servlet? I'd rather not using EJB endpoint to keep my deployment simple.
Am I missing something?
Thanks,

[Dushy Inguva]

Jack,
I asked a pretty similar question a week ago. Here is Richard's nice response to it.
Dushy

[Jack Zhou]

Thanks Dushy,
I actually read that thread. My point is that you don't lose any thing by not using EJB end point. When you use JSE, it is like an adapter of the EJB, you still can have all these benifits from the service offered by ejb container. My guess is that EJB endpoint in J2EE1.4 is rather a convienance. I wish some one can give an example about features that can only obtained from EJB endpoint or I have to give a significant effort to achieve the same via JSE endpoint. My problem is that I believe vendor will actually create a sevlet to intercep the HTTP request which carry a soap message, then call the EJB. Does EJB accept HTTP request without using a servlet?

[Edy Yu]

If you want to build your servie based on EJBs, directly using EJB endpoint will save those "extra" stuff such as locating EJB home, using IIOP to communicate ... Internally, the app server may still need to locate the EJB Home ect. But Just as CMP entity beans, server does it better
My two cents.
Also, Monson's response in that post still holds perfect sense ....

[manoj pillai]

EJB end point implies the JSE internally doing the EJB lookups and invoking the intf method. But the lookups and the invocation could be made more efficient if managed by the application directly - like use of service locator with home interface caching etc. At least the Axis implementation of EJB end point doesnt seem to have any such optimization, it loads the intf classes and looks up home intf every time. So maybe it is a good idea to use JSE endpoint and then call your ejb method from it if you need to.

[k.p thottam]

My take on it is this :

with servlet endpoints that are mere adapters to the ejb (stateless and Message ) issues like transaction begin ,commit , rollback require to be understood by the adapter , then as the moderator pointed out , the adapter in turn can get the transaction context and propagate the transaction.

You could wrap the logic of detection of transaction related stuff into a template pattern , but that it will get used by any one else except your group I doubt.

The issue I see in this is : the fact that the developer is coding the plumbing , a business developer should not be doing this becuase that means changes in standards requires changes in the code .

on the other hand if you go with the ejb endpoint , the work is done by the app server , changes in standards , means upgrading your app server , and not your code thro out the enterprise .

[Richard Monson-Haefel]

Don't assume too much about how the J2EE app server works under the covers. While its likely that some vendors will use Servlets to wrapper SOAP calls to EJB endpoints this cannot be assumed as the only way to implement EJB endpoints. An EJB container may provide its own mechanisms for processing HTTP requests and delegating them to EJB endpoints.

In the end, the EJB endpoint is useful when you need to coordinate several operations within a transaction - operations that are managed by the endpoint - like accessing a JDBC database and a JMS messaging service in the same transaction.

EJB endpoints are also useful when you need to take existing stateless session beans and expose them as Web services - this may be more common than you think. A lot of business defined stateless session beans as business interfaces to their systems. Making the accessible as Web services just opens them to yet-another-type-of-client.

Richard