Hi again,
as stated in my last post, i just want to inform you about our current status about this interpoerability issue.
After a lot of evalutation of different potential solution we found the following way to connect clients without using EJB-container-specific jar files and still have our CORBA like interface available to clients written in different languages.
1. EJB:
We build a EJB with 2.x style (Home/Remote Interfaces). This makes it possible to connect via plain CORBA to the EJB. This is covered by the JEE 5 spec. The business interface for this EJB will be defined in IDL. Our IDL interface will be extend from version to version of our application. We will write a code generator which generates the EJB (2.x style) out of this IDL. There are two main reasons why we define the interface in IDL and not in java/RMI:
a) Because plain CORBA clients are using this EJB, it's a protection against using serializable java objects by mistake. e.g. a C/C++ client can't us serialized java objects. All objects (structs) have to be defined in IDL itself.
b) Our current API (which we want to migrate to JEE) is based on the IDL-CORBA direction directive in,out,inout and we are using a lot of out's in our current API. In RMI there is no out possible.
To achive this EJB code generation, we tranlate automatically all IDL out and inout parameters into a java result object wich conains all this parameters. All in and inout parameters are also used in the RMI method declaration. For all IDL-structs we generate java classes. As a result, we have an RMI representation of our IDL interface. We found out, that it's not good to let the idlj generate this java classes for IDL structs (it's too CORBA dependent). e.g. if GlassFishs Classloader find a class which implements IDLEntity, it tries to load also the CORBA-Helper classes - which we don't need in this scenario.
2. Java CORBA clients:
After we have this EJB, we run the "rmic -iiop" compiler against the EJB-Home interface. This step generates the needed RMI/IIOP stubs for our clients (we think it's better to use "rmic -iiop" instead of "asadmin deploy --generatermistubs" to generate the stubs). So we are able to build the stubs without deploying the EJB to GlassFish. If we would use the asadmin command to generate the stubs, the EJB has to be deployed and the GlassFish has to be up and running. When using the rmic, the build process is much easier. Now a second code generator generates client side wrapper code which makes the reverse translation from RMI calling style to IDL calling style (with in,out,inout mechanisms and holder concept). With this code, our java clients only need the javaee.jar file and no other JEE server implementation specific libraries.
We found out, that it's NOT possible to write a pure java client only using plain CORBA with idl compiler instead of using RMI/IIOP. From principle, it's possible to generate IDL out of an EJB (command "rmic -idl". But in real life, these IDLs are unusable in java because a lot of existing java core classes are also generated (some in java.lang and in java.io). This produces name clashes which we were not able to solve. We found the following hint. Excerpt: "CORBA client that uses a CORBA 2.3 ORB. Note: Due to name-space conflicts, Java CORBA IDL clients are not supported by the RMI over IIOP specification." in the document
http://edocs.bea.com/wls/docs70/rmi_iiop/rmiiiop2.html#1067029. This seems to be a general problem an not a bea specific one. But it doesn't matter, the RMI/IIOP way without IDL is more convenient - but we need the javaee.jar!
3. C/C++ and C# clients
Compared to java clients, which are happy to use RMI/IIOP, other languages may use the IDL which is produced automatically out of the EJB (with the "rmic -idl" command). In this languages the names java.lang and java.io are not known and so, no name clashes are there. For this type of clients we just use this generated IDL out of the EJB and feed it to the language specific IDL compiler. Here, we also do a reverse tranlation with generated code, to make the interface more IDL like with holder objects for out and inout parameters.
4. ORB bootstrapping / failover / load balancing
Because these features are vendor specific in the JEE world, we wrote a small middleware stack by ourself to achive this. This is not portable and only usable in our product, where we build our API EJB and the client code. But this is our only chance to achieve JEE vendor neutrallity for our clients AND high availibility - remember we're not able to update our clients for years. The clients must work, even if we update the server in the future from GF v2 to v3 or from GF to JBoss or BEA...
With this steps, all our requirements are possible to implement with JEE 5. Now we try the adventure to migrate...
We wonder, if we are the only users who are interested in using JEE technology in the manufactoring production environment infrastructure. In manufactoring production lines (high integrated electronic equipment production) , it's usual that youre not able to touch a production client after installig it and the line has started to produce things. This a typical 24x7 high availibility requirment in this area.
greetings,
Frank
[Message sent by forum member 'fmeili' (fmeili)]
http://forums.java.net/jive/thread.jspa?messageID=255178