The process starts by translating COBOL Structures to XML Schema. This is option LegStar->New structures mapping…

On the Structures Mapping plug-in first page, type an XML Schema file name making sure the extension is xsd. The source type will be COBOL for this use case:

Figure 4.2. Adapter structures mapping screen 1

On the next page, you can either paste COBOL code copied from somewhere else or select a file containing COBOL source code from the file system. Make sure this is valid COBOL as the mapping generator is not a full featured COBOL syntax checker:

Figure 4.3. Adapter structures mapping screen 2

After you click finish, an ant script with a name similar to build-schemagen-CustomerService.xsd.xml is generated and launched. This script generates a new XML Schema and then the Eclipse standard XML Schema editor is opened and you can check the mapping (COBOL annotations) that was automatically generated:

Figure 4.4. Adapter structures mapping screen 3

Observe the extensions used to annotate the XML Schema elements with COBOL meta-data.

The next step is to generate binding classes from the Mapping XML Schema. These Java classes will be responsible for marshaling/un-marshaling XML into a mainframe data.

The wizard is started from the package explorer, by right clicking on a previously generated XML Schema:

Figure 4.5. Adapter COBOL binding generation menu

The next page allows you to specify which elements from the source XML Schema will need to be bound. All elements are displayed here but if you select a parent element, this will automatically select all children for you, so all you need to do is to select root elements:

Figure 4.6. Adapter COBOL binding generation screen 1

In our case, the mainframe program expects a Dfhcommarea and also produces a Dfhcommarea so that’s the only element we need to select.

When you click the finish button, an ant script with a name similar to build-coxb-CustomerService.xsd.xml is generated and launched. There are two different java packages that are generated by the ant script:

Figure 4.7. Adapter COBOL binding generation screen 2

The final step in the process is to generate a Mainframe Adapter, which is a JAX-WS Endpoint.

The first stage is to perform a mapping between the target mainframe program and a Java side operation. This is option LegStar->New operations mapping… On the first page you select a name and location for the mapping file. Operations mapping files are XML files with the cixs extension.

Figure 4.8. Adapter service generation screen 1

Clicking on Finish creates the operations mapping file and then opens up a special editor associated with files with cixs extension:

Figure 4.9. Adapter service generation screen 2

Click on the add button to start the operations mapping dialog:

Figure 4.10. Adapter service generation screen 3

Type in an operation name and then enter the target mainframe program name. This must correspond to an actual mainframe program.

The next step is to specify input and output structures. You will have to use the add button again. You are then presented with the JAXB classes that you generated previously:

Figure 4.11. Adapter service generation screen 4

The target LSFILEAE CICS program is commarea-driven, there is a single input and a single output which both happen to be described by the same COBOL structure. So all we have to do is to select Dfhcommarea both for input and output.

Figure 4.12. Adapter service generation screen 5

This dialog allows you to specify a different input and output structures if needed. It also allows you to specify more than one input and more than one output as it would be the case for a target container-driven program (using CICS channel/containers) for instance.

You can now click on the generate button and should see the following dialog:

Figure 4.13. Adapter service generation screen 6

The operations mapping editor can be used with different kinds of generators, which are registered dynamically on your machine. Depending on your configuration, you might have more than one possible generation target. In our case, we want to generate a Mainframe Adapter. When you select that target and click the OK button you get this final dialog:

Figure 4.14. Adapter service generation screen 7

The generation process needs to create various artifacts, including Java classes that implement a JAX-WS endpoint bundled in a J2EE war file. This dialog allows you to select the target locations and other options. Most of these options have default values derived from your preferences. You can change the proposed parameters as you see fit.

Again, the Finish button creates an ant script, which actually generates the artifacts. The ant script has a name similar to build-jaxws-j2c-CustomerService.xml.

Besides the JAX-WS java classes, you will also find ant scripts that were generated to help you with deploying your endpoint. build-jar.xml bundles the classes in a jar archive that you could deploy to AXIS2 for instance. build-war.xml bundles a war file suitable for Sun's JAX-WS RI (Metro).

Once deployed, you can use the Web Service with any SOAP client such as soapUI.