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".
