Last year you wrote some middleware using EJBs. This year your boss tells you that a C++ client needs to talk to those beans. You consider SOAP, but are dicouraged by reading about its performace. Papers showing SOAP is 100 to 1000 times slower than RMI are all over the place. Even with the newest pull parsers it still can't meet your performance needs of sub 200ms response times for up to 1000 transactions per second.
You start to look at other technologies, some more traditional, others a little newer.
- CORBA
- If your EJB container supports it, you can start using CORBA right away. But CORBA adds a lot more moving parts to the system. Your client code is more complicated. And its slower than some of the other solutions.
- JNI Bridge
-
As strange as it might sound, there is actually a commercial product built around this. C++ wrappers are generated, which invoke RMI stubs via JNI. The client interface is simplier and faster, but you level of 'moving parts' is still fairly high. You need a JVM installed on each of your C++ clients. - Native C++ JNI
-
I couldn't find much information on this, but if your generating C++ wrappers, why not just generate an entire C++ RMI client. I found a small sample application / proof of concept.
So what do you do? Choose one of these? Maybe something more complicated with MQ to MDBs? Maybe a non-standard remoting method like Hessian?
<< Home