On 23 Aug 00, at 7:25, Rickard �berg wrote:

> Hi!
>
> Dan OConnor wrote:
> > The example of multiple distribution protocols is interesting and not
> > immediately obvious to me.  I think I could make a case that a
> > single deployment of an EJB should be able to have multiple
> > distribution protocols.  The basic argument is that the distribution
> > strategy is independent of the business logic (in much the same
> > way that a view is independent of a model in MVC).
> <snip>
>
> I agree completely. There's just one tiny little catch: if an EJB does
> getEJBObject() what should he get? A JRMP EJBObject, or an IIOP
> EJBObject, or..? Because of this it is impossible to support multiple
> protocols/deployment, hence multiple deployments (one per protocol) is
> necessary. :-(

Oops.  Good point Rickard.

Would a possible solution be to just return an EJBObject of the
same type as the original client used?  (A possible optimization
would be to use a JRMP EJBObject, but to substitute one of the
type the original client used if the object passes through the
boundary of the jBoss server [i.e. is returned to the client].)

What do you think?

-Dan

>
> > Let me make the case by example.  Say that you have two
> > distribution protocols for an entity bean.  If our application has
> > exclusive access to the database, wouldn't it be reasonable to use
> > the same cached entity instance for an access via either protocol?
> > This would only be possible if the component had a one-to-many
> > relationship with distribution protocols.  (Note that this is different
> > from the situation where a resource or environment entry is
> > different; the EJB container could not reuse a cached instance,
> > because it would behave differently based on its corresponding
> > deployment parameters.)
>
> Since apps should be accessed by session beans, this isn't that a big a
> problem. Use JRMP for EntityBeans to let Sessions access them
> "internally", and use multiple sessions with various protocols to access
> the app from the outside.
>
> However, you're right in theory. If we only could figure out a way to
> implement it consistently I'm all for it.
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>



Reply via email to