We have a distributed system written mainly in C/C++ on HP/UX 10.20 (uses HP DCE 1.5). We now wish to migrate to J2EE. Since we have an enormous amount of source code written in C++, we would like to use the same. The implementation will consist, mainly of stateless session beans. The actual method implementation will continue to remain in C++ (we will access the code using JNI).
What are the major issues in choosing the above architecture?
Inputs will be extremely helpful.
helo, SOAP maybe another alternatives...
I'm assuming that you have already know that JNI is technically disallowed by J2EE (along with several other useful and widely used constructs). You are likely to encounter problems with deployment to a running app server, as JVMs (tried Sun's and IBM's 1.3.x) are not capable of linking the same JNI code to multiple same-named Java classes living in different class loaders. The effect for our project was that the first instance of the app worked fine but a complete server restart was required when a redeployment should have sufficed.
We are no longer using this configuration so my experience was with a previous generation of app server, but I expect that the newer ones use the same child class loader mechanism.
Yes, we are aware that EJB "discourages" the use of JNI. Also, the limitation that of not being able to deploy to a running server is acceptable to us.
The main issue is what happens when a problem happens when executing the JNI code. For example, let's assume a memory access violation happens when executing the JNI code. Can these errors be "trapped". Or will the JVM crash (since the JNI code is executing in the process space of the JVM)? What happens to the EJB server itself?
Some AppServers like Sybase EAS (Jaguar) allows to use C/C++
as components. It creates Home/Remote interfaces for C/C++ object so this object acts as EJB. Or you can use C/C++ objects using CORBA and they will communicate with EJB in this AppServer. This way you dont need to throw away all the enormous amount of source code written in C/C++
Using JNI inside the J2EE architecture is not advisable as per the SPEC. Hence the options are using Sockets to call the C/C++ program, sending a JMS message from one app server to another, invoking the C/C++ application from another app server which doesn't have any of your J2EE components, or using other message oriented middleware techniques.
I didnt understand why EJB discourages JNI.
Can you pls explain me the reason.