I would think that the EJBContainer interface would have a
"deploy" method, and then an external "Deployer" service would manage
chunking up an EAR and sending part of it to the EJBContainer, part of it
to the WebContainer, part of it to the RARContainer, creating the
ClassLoader hierarchy, etc.
As for the method calls, it seems like it would be best to have an
"invoke" sort of method on the EJB container, and then you could start an
RMI service to listen for requests, an IIOP service to listen for
requests, a Web Services service, etc. In other words, don't build the
invocation method into the EJBContainer, but allow any number of
invocation handlers to be started, each one of which communicates with the
EJB container through it's EJBContainer interface, or whatever.
Transactions are a little trickier, because they may be started
outside the EJBContainer (user transactions in the web layer, etc.), but
they may also be started inside the EJBContainer (container-managed
transactions). Presumably there would be a Transaction service as well
which all the other services could deal with.
It seems to me a starting point would be to identify all of these
services and their interfaces, but that may be rendered moot by the code
that's checked in.
Aaron
On Thu, 7 Aug 2003, Christian Trutz wrote:
> the first question that i have is:
>
> what should be the contract / interface
> between Geronimo and its EJBContainer?
>
> ould the beans be deployed thru Geronimo to the
> EJB container or directly to the container or both
>
> should a method call be fired thru:
>
> Geronimo -> EJB container -> bean -> method
>
> EJB container -> bean -> method
>
> how about transactions .... :-)
>
>
> oh i think transaction + ejb container is the central
> piece of code :-)
>
> chris
>
