Hi ksak, hi jmarine,
thanks a lot. Both answers are very helpful. Now we know that there is a way to connect via plain CORBA to the EJBs. I don't know why this use case is not so well documented. This is a very important thing for EJB interoperability, also between different vendors container implementations. I think Web Services are not a real solution for interoperability (bad performance/bandwith/cpu usage and unclear specification) - CORBA is the perfect way for such a situation.
I hope that this way is not deprecated and I wonder why this is not specified in the EJB 3 world and only in the EJB 2.x Home/Remote view. Hopefully this will be clarified in future.
Now we have successfully running the first two client samples:
1) A pure Java SE 6.x client without a need for having GlassFish JAR files on it. The only libraries we needed are javaee.jar (which is standard JEE and not implementation specific) and the stub code. The stub was generated with the GlassFish "asadmin deploy --generatermistubs" mechanism. But after looking very deep into the generated stub, it is not GlassFish specific. This client using InitialContext(props) with the following props:
java.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactory
java.naming.provider.url=iiop://<host>:<port>
This solution uses internally the usual Java SE 6.x ORB implementation.
2)Now we try to generate a pure Java SE 6.x client only build with IDLs (to get rid of javaee.jar) and to make it in principle possible to use a C++ client. I will post my experience in this thread.
Just to inform you about our use case and why we need this:
Until now our software is running on pure standard Java SE and we want to migrate to Java EE. Our current application server implementation is completely self made and is besed on Java SE ORB with own implementation of failover and load balancing. A lot of our Java clients are build into manufactoring machines. Usually we are not able to access this production equippment - not even for software updates. Our customers often runs these production machines for years, nearly non stop. We have the need to update the servers without touching the clients for years. That's the reason why we need a portion of software in the client which is able to connect to servers - even if the servers get updated from time to time. Maybe somtimes from GlassFish v2 to v3 to v4 or from GlassFish to BEA WebLogic or whatever - it depends on our custers IT strategy.
[Message sent by forum member 'fmeili' (fmeili)]
http://forums.java.net/jive/thread.jspa?messageID=250763