I have deployed our application's entity (BMP) and stateful session beans in
three different servers, and ran into the following portability issues:
* The package of UserTransaction differs between servers (trivial).
* Some servers do not support PortableRemoteObject, so looking up the
home interface and casting the EJBObject proxy to the remote interface type
must be done in a non-standard way (minor).
* Some servers allow EJBObjects to be serialized, transmitted, and
reused on another machine. This is useful, but non-standard. We used it,
and had to switch to handles to get our beans to work in one server that did
not allow serialization of EJBObjects (major, but our own fault for not
adhering to the standard in the first place).
* Deployment descriptors are completely non-portable in our
experience, so be prepared to create jar files specific to each server
(medium).
* When using BMP, the server must have support for the persistent
store. Just because you are using BMP, your persistent store is not
independent from your server. (major, but identified in the spec, if you
read between the lines)
* Although the BeanContext classes define a method for beans to get
the identity of the caller, there is no standard mechanism for the client to
define this identity. Each server vendor is implementing their own
mechanism for client-to-server security/identity. So if your beans need the
caller's identity, the client code must be coupled to the server's security
framework. This is a major issue, and I hope it is addressed in Moscone.
Overall, I have been pleasantly surprised at the portability of the source
code. Portability of deployed beans (i.e. jar files) will have to wait for
Moscone.
> -----Original Message-----
> From: Tom Valesky [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 07, 1999 8:06 AM
> To: [EMAIL PROTECTED]
> Subject: EJB portability in real life
>
> One of my early concerns about the lack of a reference implementation for
> EJB was that it would result in divergent implementations, and that
> portability would be difficult or impossible to pull off. It's later now,
> and there are a few more implementations out there. I'm interested in
> hearing from folks that are developing shrink-wrapped EJBs (or any
> EJB solution that has to be runnable in more than one container) -- what
> have your experiences been with cross-container portability? Is it
> working out to be a non-issue? Is it hopeless? Or somewhere in between?
> ==========================================================================
> =
> Tom Valesky -- [EMAIL PROTECTED]
> http://www.patriot.net/users/tvalesky
>
> ==========================================================================
> =
> 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".
>
===========================================================================
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".
