IBM has done significant work to allow mainframe based applications to expose and consume web services. They’ve particularly targeted CICS and languages COBOL, PL/I and C++.
While many vendors (including IBM) offer a variety of tools to provide easy web service bridging, IBM’s CICS efforts offer a direct path without loading and managing additional utilities. There was concern in the past of the CPU load this added to CICS, but IBM handled those problems over the years with the current edition having good performance with reasonable overhead.
While IBM recommends using modern development tools such as their Rational Application Developer for Z/Os (RD for Z) to automatically generate and build the binding and WSDL’s necessary for a service, their CICS command line based utility is probably used by most that do so (this being DFHLS2WS). With a short series of configuration sessions (and limited options), it will take program information and data areas and generate appropriate WSDL and binding files.
Which is where it gets interesting.
IBM’s mainframe folks have worked hard to generate a very exacting and 100% compliant WSDL while dealing with the difficult aspects of fixed length fields, fixed array quantities, EBCIDIC to UTF-8 translations, and unique language storage models (such as COBOL’s COMP-3 packed decimal field). For the most part they’ve done a good job of mapping 2nd generation languages’ internal storage models to XML and the latest schema/XSD capabilities. But in a few areas they’ve seriously fallen down.
1. Arrays. Empty arrays are sent through in XML as…repetitive empty copies of the field/tag. So if in COBOL you have a 05 PHONE-NUMBERS PIC X(9) OCCURS 50 (that’s an array of fields called phone-numbers of 9 characters), in XML you get <PHONE-NUMBERS> repeated 50 times, with no values if empty but still there.
2. There’s sophisticated namespace usage by IBM in the resulting WSDL, with the WSDL having one namespace, the request tags having another and the response tags having a third. At the start of each section the DFHLS2WS utility names an XSD complex type “ProgramInterface”. Before doing that they change the namespace, but to NOT tag the names in the section with the namespace. The strict rules of XSD’s say this is acceptable. BUT when .Net programmers import the CICS generated WSDL into Visual Studio or Java programmers import it into Eclipse (including IBM’s Rational Application Developer for Websphere), these tools reject the WSDL due to a duplicate name (the repeating of ProgramInterface without the namespace pre-pended but after the namespace change).
Technically, that’s a bug in Visual Studio, Eclipse and Rational Application Developer, as those tools aren’t handling the namespace change and implicitly placing the names in that section in the namespace.
Practically it means IBM’s CICS team outsmarted themselves with the XSD sophistication of the output of DFHLS2WS, using a feature that’s not well supported by the developers of the development tools that will be importing the resulting WSDL.
Interoperability standards are critical. But vendor interoperability isn’t perfect. While we shouldn’t have to go to the lowest common denominator, going to the highest isn’t wise.
[ There is no solution for this particular DFHLS2WS problem beyond writing a utility to automatically modify the output WSDL, or manually modifying it. Maddeningly the IBM documentation even says it is likely to need to be modified rather than offering options or flexibility! ]