Alan Greenspan wrote:
> > > If so, it will be necessary for clients to have copies of the server Handle
> > > implementation classes on their local classpath. This is because the base
> > > java.io implementation of ObjectInputStream resolves classes using the
> > > application class loader hierarchy.
> > >
> > > This restriction seems neither practical nor desirable. I see no other
> > > requirements placed on EJB clients to have local copies of server
> > > implementation classes. If this is required, it will involve some server
> > > specific client deployment mechanism. Clients using a variety of servers
> > > will need to keep a repository of all the Handle implementations provided by
> > > the various vendors. Seems bad and works against world wide EJB deployment
> > > and ease of use.
> > What about the proxies for the bean homes and for the beans themselves? I have
> > worked with several EJB servers, and they all require a fairly large set of
> > server-specific classes deployed on the client. I don't think that
> > server-neutral deployment of the client code is actually a goal of EJB.
> Proxies and all other server-specific implementation files should flow to
> the client via RMI. At least that's how it works in our system. I have
> found no need to deploy clients with any EJB server-specific classes. This
> includes the Handle implementation - with the only issue for Handle being
> the one I described, that is the inability to deserialize it unless the
> client has the class locally.
>
> I can't imagine widespread adoption of EJB if vendors require clients to
> pre-load server-specific classes. We should be able to use EJB to build
> highly distributed systems where clients no nothing about server
> implementations and choose their services based only upon agreeable
> interfaces between client and server bean. You think that's not a goal of
> EJB?
I agree with you that client portability and vendor neutrality should be an
EJB goal, but we have to be patient about it. There are quite a few
obstacles to reaching that goal. Handles are just one. Client stubs are
another. Others include security APIs and credentials, configuration
values, and JNDI context implementations.
All of the vendors we've worked with are interested in making continued
progress toward interoperability, portability, and neutrality, as a means
of expanding the acceptance of EJB (and J2EE) as the premier enterprise
application platform.
Marc San Soucie
GemStone Systems, Inc.
Beaverton, Oregon
[EMAIL PROTECTED]
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
