Hi!,
Comment on following.
1. As of today, EJB specs doesn't solve problem of integrating legacy code.
The connector archi. solves to limited extent. But thats only for enterprise
connections. What about the code like somebody mentioned in the list in
cobol,c++ the restriction of not been able to access from EJB is fair, but
restrictive. As i understand it is for the container security that JNI is
not allowed as it is unsecure and unsafe code may cause fatal harm.
But it is always possible if there is a separate container provided for such
things, with least services and sandbox like restrictions that can integrate
legacy code.
2. As we know EJB is targetted towards enterpirse solutions, it will be
surprising to know if servers hosting these apps. are not multiprocessor. As
of today, the specs gives container providers the privilege to make use of
these multiprocessing, but to a bean provider there is a restriction of not
spawning threads. It maks sense that container would take care of thread
management etc.
What if bean provider wants to make use of this multiprocessing by doing a
background job. For e.g.
I have a bean that takes customer orders and send it to inventory and sales
office. This may not be a good example, but my point is there is too much of
serialization if requests in ejb specs.
What if like XaResource container has a thread pool that i can submit
background jobs. This way container willl be able to do thread management
and bean provider will be able to use multiprocessing.
Punit
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.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".
