EJB design: COM and EJB
I don't know about anyone else but my organization uses both COM and EJBs but only recently have we begun EJB development. We have been struggling with how to bridge EJB and COM. We have looked into the VJ++ solution. We fear it will go away with C#. We have looked into JIntegra. It doesn't perform. We have tried XML. Nice but it's not as nice as a bridge with method/property invocations. We use BEA/Weblogic for our EJB development/deployment. We don't like their solution because it means deploying WLS everywhere.
Does anyone have another product suggestion to bride COM and EJB which works with BEA/Weblogic?
Thanks for any info,
A few questions..
1) What did not perform about JIntegra? Did you try their tech support and ask why it was having performance problems? What about performance tuning the system with a tool such as OptimizeIt?
2) XML bridge - I like this solution best (via SOAP). What about generating stubs/skeletons to make things appear to be method/property invocations? I heard something at some point about RMI/SOAP.. any idea what that's about?
3) BEA weblogic - what are the issues behind why you can't deploy weblogic everywhere? Is it because your COM client is an ActiveX control?
1) What did not perform about JIntegra? Did you try their >>tech support and ask why it was having performance >>problems? What about performance tuning the system with a >>tool such as OptimizeIt?
JIntegra not only is slow but we find the inprocess native unstable. It causes the VM to crash ( we have tried Sun's and the one which comes with Cafe here ). We have contacted their support but so far not much help. What does not perform are simple method/property invocations.
>>2) XML bridge - I like this solution best (via SOAP). >>What about generating stubs/skeletons to make things >>appear to be method/property invocations? I heard >>something at some point about RMI/SOAP.. any idea what >>that's about?
The end user of this are COM developers. We prefer to give them an interface they understand best, at least for now. I also have not heard anything about generating stubs and skeletons for RMI/SOAP but this sounds like a lot to get into. We have a short deadline for this.
>>3) BEA weblogic - what are the issues behind why you >>can't deploy weblogic everywhere? Is it because your COM >>client is an ActiveX control?
The reason is simple: cost. BEA's solution requires you put WLS on the client machines. We don't want to pay for all those CPUs.
So, do you or anyone else have any COM/EJB bridge product suggestions which work with WebLogic?
Check out theJ2EE Client Access Services (J2EE CAS) COM Bridge 1.0 Early Access, on java.sun.com.
The JavaTM 2 Platform, Enterprise Edition Client Access Services (J2EETM CAS) COM Bridge lets Windows developers create native client applications that access Enterprise JavaBeansTM (EJBTM) components deployed on a Java 2 Platform, Enterprise Edition application server.
The J2EE CAS COM Bridge provides a set of COM objects that let any COM-enabled client application establish a connection to an application server and obtain references to EJB components. The bridge will then transparently map remote objects (accessed by means of the RMI-IIOP protocol) to COM objects that the client can readily access using the COM IDispatch interface.