Hey
Ron Yust wrote:
> But I'm assuming this EJB/RMI scenario requires a RMI server in addition to
> the EJB server. Why have the EJB server then?
Read ch. 2 ("Goals") in the EJB spec., and you'll see why. Plain-vanilla
RMI doesn't do all that.
As an application developer, EJB gives you lots of features for free,
which you would have to code yourself if you went with plain RMI. Of
course, this is a strange discussion since EJB *is* RMI. You can develop
an application server in RMI, but then you have this neat specification
for how everything should work, called EJB, so why not code it like
that.
Which is what I did 2 years ago. Instead of doing everything proprietary
we split our development team in two: one half (me) did an EJB server
and one did the EJB application as a set of beans. Since we had
well-defined (comparatively) interfaces between us we could develop
concurrently and simply plug it together in the end, and everything
worked magically. Presto :-) Had we done everything ourselves we would
have to solve the problems of how to get transactions, security,
resource pooling etc. blah blah. together in a neat little package. Not
easy. The course we took (as outlined above) took 6 weeks from initial
design to final documentation.
Just my 2 cents..
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
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".
