reason behind this architecture

[rak shar]

Hi
This is an interview question
As we know in EJB we have the Remote interface in which we declare
all the business logic methods which the EJ Bean needs to implement.
Though the EJB directly doesnt impleement this interface , all methods
in teh EJB have to match the method signatures of the Remote Interface.
WHat is the advantage of this decoupling .
Or why Java has forced developers to use this type of architecture
CAn someone explain.

Rgrds

[Lasse Koskela]

As we know in EJB we have the Remote interface in which we declare
all the business logic methods which the EJ Bean needs to implement.
Though the EJB directly doesnt impleement this interface , all methods
in teh EJB have to match the method signatures of the Remote Interface.
WHat is the advantage of this decoupling .
Or why Java has forced developers to use this type of architecture
CAn someone explain.

Well, first of all Java doesn't force the developer to use Enterprise JavaBeans...
Anyway, the methods must match the ones in remote interface so that the EJB Container knows which method of the implementation class instance to call when an EJBObject receives a method invocation request.

[Anthony Egizi]

You have missed a very key reason for this design concerning the remote interface which is coupled to the bean instance. The J2EE container as it is often called is an advanced component transaction monitor (CTM) and as such must intercept business method invocations to offer and ensure the consistency of transactional, security and system-level services to the container components. In one sense the J2EE container is facilitating cross-cutting concerns for distributed components which is the motivation behind aspect-oriented programming (AOP)

[Lasse Koskela]

True. Reading the EJB 2.0 specification is recommended (even though it's VERY repetitive and unorganized, in my opinion) for all EJB developers.