On Tue, 7 Nov 2000 21:33:07 +1000, Bartek Kiepuszewski
<[EMAIL PROTECTED]> wrote:
>> To me there are two main reasons where the restrictions are useful:
>> 1) If it's an EJB it is portable. Period. No "well, if it does
>> this or that
>> it needs.." crap. By refactoring everything that would be potentially
>> dangerous to external libraries we have the simple rule that EJB's
>> themselves are always portable.
>
>You lost me here, Rickard. If I refactor I/O to the system
>library and have an EJB that depends on this library, how
>does that make the EJB more portable ? To use it on a server X,
>I have to install this "unsecure" library as well as the EJB
>in question otherwise it won't work. In fact, if the library
>is referenced statically (i.e. EJB instantiates and uses
>library classes directly) the EJB won't even deploy unless
>the library is on a CLASSPATH of a server.
>
>So, where's the gain ?
The gain is subtle, agreed. The point is that EJB's themselves are
always portable. Always. Now, if they depend on a library that needs to
be ported then you have in practice isolated the non-portable parts to
the library. Since you must do this factorization there will be a
natural urge (IMHO) to make this library as generic as possible (i.e.
not tightly bound to your particular app) since there is some added
work/thoughts with doing file I/O this way because of the security
considerations (i.e. you don't want to do this very often; get it right
once and reuse for all apps).
So instead of having a bunch of non-portable EJB's doing file I/O you
will have a bunch of portable EJB's and a possibly portable library.
Now, this library might be trivially portable, in which case all is
fine. But it might be the case that the encapsulated functionality is
not portable, or that it stops scalability of the app (as Jonathan
outlined). In this case you will have to re-write it, either to make the
functionality work on the intended platform, or to change the
implementation entirely so that it does scale.
By having this "annoyance" in the EJB spec. you have been forced to
design your applications properly, which you will be happy for down the
road as outlined above. This is the gain IMHO, or at least one of them.
I do realize that this is a matter of opinion, but, well, here's mine
anyway :-)
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
===========================================================================
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".
