Ron,
With all due respect, EJB is not intended to be a be all and end all
framework. It is intended to meet the needs of most transaction oriented
business systems. J2EE adds surrounding technologies that provide
alternatives and extensions for other usage models.
We find in our customer base that it is usually a mix of technologies (e.g.
JSPs, Servlets, Messaging, EJB and CORBA) that are need for many large scale
applications.
-Chriis.
> -----Original Message-----
> From: Ron Yust [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 27, 1999 12:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: EJB Restrictions-- threads, io
>
> Rickard,
>
> You misunderstood my question. I know why an EJB server is better than a
> RMI server. My question was highlighting the silliness of designing an
> application that has to use both to get a job done. I want to just use
> EJB
> only, but if I have to have a RMI server next to it, well, why don't just
> do
> it all in RMI then. Don't want to, but I'm beginning to complicate things
> by going outside EJB anyway.
>
> -Ron
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> > Sent: Wednesday, October 27, 1999 9:34 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: EJB Restrictions-- threads, io
> >
> >
> > 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".
> >
> >
>
> ==========================================================================
> =
> 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".
