IDL to WSDL code generation

This component is based on this simple pseudo equation: idl2java + java2wsdl = idl2wsdl.

The algorithm used is the following:

1. idlj

The first step is the "IDL to Java" code generation. To implement this operation the component uses a Sun's tool distributed with the standard JDK: idlj.

This tool has several options and if you want a more detailed discussion about it, please visit the java.sun.com.

The command line used is

idlj -fall -td targetdir -i includedir file.idl

where targetdir is the directory to place the source files and includedir is the directory where the IDL file is located.

com.sun.tools.corba.se.idl.toJavaPortable.Compile.main(
            new String[] { "-fall",
                           "-td",
                           targetdir,
                           "-i",
                           includedir,
                           idlFilename });

At the end, if the IDL is correct, in the there are the java source files just generated.

2. value type implementation

If the IDL file contains one or more value types the source files produced don't compile, in fact the developers must supply an implementation class for each value type.

For example:

If you have an IDL file that contains a value type like the following

valuetype FooValueType {
          public  short fooField;
        };

We generate 2 classes: the class of the value type and the factory.

public abstract class FooValueType
            implements org.omg.CORBA.portable.StreamableValue {

            // ... some code
        }

public class FooValueTypeDefaultFactory
            implements org.omg.CORBA.portable.ValueFactory {

            public java.io.Serializable read_value (
                org.omg.CORBA_2_3.portable.InputStream is) {

                return is.read_value(new FooValueTypeImpl ());
            }
        }

But the class FooValueTypeImpl does not exist so we generate an empty class that extends FooValueType and called FooValueTypeImpl in the source's directory.

public class FooValueTypeImpl extends FooValueType {
        }

Now the code generated compiles!

3. javac

Compiling the java source code generated.

4. bytecode manipulation

The compiled code generated is not ready to be used by CXF, so we inspect all the Operations class (generated from the CORBA interface) and extract from this class all the data types used in the methods.

For each data types found we modify their bytecode to comply the CXF behaviour:

1. for each public or protected member we add the getter and setter method
2. if the class is abstract we remove this keyword
3. we append to the default constructor the code to istantiate the array (if the class contains one or more array) to avoid NullPointerException

5. CXF

Now, the classes are ready to be analyzed by CXF to generate the related WSDL.

This page (revision-25) was last changed on 02-Apr-08 06:11 AM, -0700 by 213.174.165.189.
This page was created on 27-Apr-07 08:01 AM, -0700 by 213.174.165.189.

More info...