>Now another question I have, is that I've seen people
>mentioning J2EE
>RI, what does RI stands for?
RI stands for Reference Implementation.
--- Yiwen Jiang <[EMAIL PROTECTED]> wrote:
> Hi Assaf,
>
> Thanks for the response.
>
> > If you compare EJB to the current state of
> application servers, where
> > your code is 100% non portable and you need to
> relearn the API when you
> > change products (or try to integrate them), then
> you'll see the benefit
> > of EJB.
> Agreed. However, all these conviences assumes that
> one will be using an
> application server. Another approach is to build an
> application runs as
> a server, and have reusable and portable components.
> This type of
> application could easily be a lot less bulky
> comparing to the size of
> the application server+container+EJBs, and
> conceivably, the performance
> would be a lot better. This would be especially
> useful since different
> applications may have different requirements for its
> threading model.
>
> From all the articles that I've read so far, my
> impression is that EJB
> is probably not suitable for writing hard-core
> servers, but for writing
> high level business applications. Is this correct?
>
> > > The fact that EJB restricts loading native
> libraries (I interpret it as
> > > prohibit JNI calls) makes reuse of existing
> components impossible if the
> > > implementation of the component is not
> implemented in Java (which IMHO,
> > > is the majority of the case). The spec did not
> mention of any other way
> > > to allow such software reuse. Now we could wrap
> these components with a
> > > normal Java class (not an EJB), and have EJB
> import these classes, but
> > > inherently, this is really no different from
> issuing JNI calls within
> > > EJB itself. Or am I interpreting this all wrong?
> >
> > It does not prohibit you, e.g. from using a
> library that might access
> > JNI or spawn it's own thread. JDBC, JMS and even
> JNDI are prime examples
> > of that. But they they have been properly designed
> to provide their own
> > level of reliability, security, monitoring, etc so
> you can trust them to
> > work well in a demanding environment.
> I read somewhere that an exception will be raised if
> an EJB spawns off a
> thread, so I am assuming that an exception will be
> raised if an EJB
> invokes a JNI call?
>
> > > Also, if EJB prohibit synchronizing threads, how
> would it adress the
> > > typical producer/consumer problem which is quite
> a common scenario in
> > > server requirements/designs?
> >
> > There is no producer/consumer in the EJB world,
> this sort of
> > functionality either leaves on the client or
> inside the resources that
> It would be mighty difficult to have this problem
> dealt with on the
> client side, assuming that the client can be a
> producer or a consumer..
> Who would manage the synchronization and
> notification concering the
> queue?
>
> > the EJB bean accesses. Typically if your business
> logic is about being
> > produced/consumed you will be looking at JMS.
> Please execuse my ignorance, but what is JMS?
>
> > I think what we need are good real world scenarios
> so people can see how
> > different design patterns are being used and
> reflect that on their
> > projects.
> This would be very helpful for me for sure!!
>
> Now another question I have, is that I've seen
> people mentioning J2EE
> RI, what does RI stands for? Is it referring to the
> run time environment
> or the developing environment?
>
> Thanks very much!
> --
> Yiwen Jiang
> CRYPTOCard
> [EMAIL PROTECTED]
> Tel: (613) 599-2441 x245
> Fax: (613) 599-2442
>
>
===========================================================================
> 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".
>
>
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.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".
