Hi
1. The application I have in mind is a module that is part of a large
enterprise application hosted on Weblogic.
2. The predictive modelling library is a third party one devloped for data
mining(It is going to be higly customised for our use).
3. On further analysis I have found that the native code need not maintain
state or take part in transactions, i.e the native method calls are
idempotent.
4. Since making a native call from the same VM as Weblogic might bring the
whole app server down if the native library crashes, we have decided to put
the native library on another machine and access it remotely using RMI/JNI
or CORBA. We have to select either one of these. Any tips? Or are there any
other techniques?
5. Portability is an issue that is hyped around too much. You don't really
change appservers/OS every other day after you have made a heavy
investment. So it is not much of an issue with us.
6. The EJBs probably could be stateless session beans. I want EJB because
I don't want RMI/CORBA calls to be made from my web-tier(Servlets/JSPs)
Any more tips are welcome
Regards
Anup
Prabhakar Goel
<prabhakar.goel@J To: [EMAIL PROTECTED]
IL.CO.IN> cc:
Sent by: A Subject: Re: Jni and EJB
mailing list for
Enterprise
JavaBeans
development
<EJB-INTEREST@JAV
A.SUN.COM>
03/28/2001 11:12
PM
Please respond to
A mailing list
for Enterprise
JavaBeans
development
hi anup,
It would be better if you can make it clear what do you mean by predictive
modelling and is it really necessary to use that library or if yes than
what is the reason that forces you to use " EJB " with this library.
* you don't want to rely on Transaction of an Application Server and
instead want your library to look after It.
* when you speak of a library it is a compiled bunch of code and is system
specific so you loose the portability of your EJB .
So it doesn't sound comfortable to why one should use EJB if this is going
to be the case, though you might have some reasons to think up of using EJB
but then plz make it a little clear.
Ofcourse you can do what you had asked but being your question a design
issue it sounds strange to have such kinda design coz It will bring
overheads of Corba Abstraction on your library and EJB's in that sense
already come with lots of Overhead. So boy u will be suffereing a lot with
the performance.
Well anything to say further requires some more detail on the real issue.
***********************
enJoy Life with Technology
***********************
pirbhu
I have a design issue regarding JNI and EJB. I have a native library with
me for predictive modelling. I want to use the library along with EJB. I
have searched the archives and a few other sites like theserverside.com and
have got a few tips
1. Even though J2EE prohibits JNI from EJB a lot of app servers allow you
to do it. So one option is use JNI directly from EJB.
2. Use a helper class having a static block to load the library. This
helper class can have methods(static?) to call the native methods. From EJB
call the methods of the helper class
3. Use RMI from EJB to talk to the native library
4. Use CORBA
5. Use messaging service
My questions are
1. Are there any security issues in using option 1 or option 2?
2. What should be the approach if the native library has to maintain state
and might be part of an ejb transaction?
3. Are there any problems with concurrent access to the library?
4. What about exceptions thrown from native code? How will it affect
clustering, transactions etc.
5. What are the pros and cons of the various approaches listed above.
Any tips would be appreciated
Regards
Anup
===========================================================================
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".
