The process starts by mapping XML schema types, from the target Web Service WSDL, to COBOL data items. This is option LegStar->New structures mapping…

Figure 5.1. Proxy XSD structures mapping screen 1

The difference with the previous use case is that we select the XSD or WSDL source type. We also elect to have the JAXB class names suffixed with Type. As a result, the next page will allow you to select a file from your file system or to fetch it directly from the internet, which we do here by typing the URL and clicking on the go button:

Figure 5.2. Proxy XSD structures mapping screen 2

At this stage, we are ready to click on the finish button and then edit the generated mapping XML Schema:

Figure 5.3. Proxy XSD structures mapping screen 3

Since we started from a WSDL, a certain number of default COBOL data attributes were assigned. For instance, all character strings are 32 characters long. While this might be an acceptable default, it is not always the case. In our situation, the application ID must be 40 characters long. We need to enter 40 for the picture attribute.

Exactly like the previous case, the next step is to generate binding classes from the Mapping XML Schema. The wizard is started from the package explorer, by right clicking on a previously generated XML Schema and then selecting LegStar->Generate Binding classes:

Figure 5.4. Proxy COBOL binding generation menu

In this case, the root structures we are interested in are Search and SearchResponse, which are the wrapper elements expected and produced by the target Web Service. We select them both.

Figure 5.5. Proxy COBOL binding generation screen 1

After you click finish, two Java packages are created, one for JAXB classes with COBOL annotations and one for the optimized binding classes.

Figure 5.6. Proxy COBOL binding generation screen 2

The last step is also similar to the previous use case. We start by creating a mapping to the Web Service operation using the LegStar->New operations mapping… option:

Figure 5.7. Proxy service generation screen 1

We now add an operation with the following characteristics:

Figure 5.8. Proxy service generation screen 2

The mainframe program in this case is a sample COBOL CICS program that will be generated with the name that you specify here.

Once you are back on the operations mapping editor, you can click on generate. You can now select the mainframe proxy option:

Figure 5.9. Proxy service generation screen 3

The generator dialog will ask you for the target Web Service runtime characteristics. This is needed to allow the proxy to address the target Web Service at runtime. You can query these parameters from the WSDL again by entering the URL and clicking on go. If the target WSDL has more than one service or port, you will have to select one:

Figure 5.10. Proxy service generation screen 4

Clicking the finish button will create various artifacts. The Mainframe proxy is Servlet to be deployed in a J2EE container. The implementation uses Sun's JAX-WS RI (Metro) as a Web Service client. The build-war.xml ant file that is generated allows you to bundle the servlet ready for deployment.

The generator also creates a sample COBOL program that behaves as an HTTP client. The search structure shows up in the working storage section:

Figure 5.11. Proxy service generation screen 5

The sample COBOL source contains TODO comments to help you locate where you should set values for the search request and where you can display the results. The LIVE search service requires a developer ID that you can get for free and enter in the AppID field.

This is an example of code to set the search structures properly:

           MOVE ZERO TO Flags--C OF COM-REQUEST.
           MOVE ZERO TO SortBy--C OF COM-REQUEST.
           MOVE ZERO TO ResultFields--C OF COM-REQUEST.
           MOVE ZERO TO R-string--C OF COM-REQUEST.
           MOVE 1 TO SourceRequest--C OF COM-REQUEST.
      *  You should specify your own Microsoft LIVE application ID
           MOVE '5588C3ACE949317B3ECAADDQ908611BDF5D8D5ZA'
             TO AppID OF COM-REQUEST.
           MOVE 'Mainframe' TO Query OF COM-REQUEST.
           MOVE 'en-US' TO CultureInfo OF COM-REQUEST.
           MOVE 'Moderate' to SafeSearch OF COM-REQUEST.
           MOVE ZERO TO Latitude OF COM-REQUEST.
           MOVE ZERO TO Longitude OF COM-REQUEST.
           MOVE ZERO TO Radius OF COM-REQUEST.
           MOVE 'Web' TO R-Source OF COM-REQUEST(1).
           MOVE ZERO TO Offset OF COM-REQUEST(1).
           MOVE 1 TO R-Count OF COM-REQUEST(1).
           MOVE SPACES TO FileType OF COM-REQUEST(1).

And these are lines to display the result:

           STRING 'INVOKE-SERVICE success. First hit is '
                  DELIMITED BY SIZE
                  Description OF COM-REPLY(1, 1)
                  DELIMITED BY SIZE
                  INTO ERROR-MESSAGE.
           EXEC CICS SEND TEXT FROM(ERROR-MESSAGE) FREEKB END-EXEC.
           DISPLAY 'Response data length=' WBCLI-RESPONSE-BODY-LEN.

           DISPLAY 'SourceResponse--C ='
                    SourceResponse--C OF COM-REPLY.
           DISPLAY 'R-Source(1)=' R-Source OF COM-REPLY(1).
           DISPLAY 'Total(1)=' Total OF COM-REPLY(1).
           DISPLAY 'R-Title(1, 1)=' R-Title OF COM-REPLY(1, 1).
           DISPLAY 'Description(1, 1)='
                    Description OF COM-REPLY(1, 1).

After you add these lines of code, you should be able to upload the source onto your mainframe and get it compiled and defined to your CICS region. Please note that this program calls the CICS DFHWBCLI program defined in the CICS standard DFHWEB group. Alternatively, LegStar supports the new EXEC CICS WEB API or even supports older version of CICS with its own HTTP library.