Service Data Objects and Service Component Architecture for C and COBOL

There are a number of important application execution environments, such as mainframe transaction processing systems like CICS or IMS and embedded systems, where the predominant programming languages are procedural languages - C and COBOL being common examples.  Given the widespread use of these environments and the significant number of applications that they run, extending Service Data Object (SDO) and Service Component Architecture (SCA) to support C and COBOL will broaden the applicability of SDO and SCA and increase their adoption.While there are other procedural programming languages, C and COBOL are the first that SDO and SCA will be mapped to.  This paper outlines the directions proposed for these mappings.

SDO for C and COBOL

Existing C or COBOL applications can often be used as service implementations with little if any change.  But over time, an increasing number of service providers will use SDOs in their input or output messages.  As existing applications are refactored to be more suitable for use in a SOA implementation, they may need to make use of these services and thus SDOs.  There will also be cases in this refactoring where it becomes desirable for the C and COBOL implementations to use SDOs in their own interfaces or start accessing data through Data Access Services.  In any of these cases it is necessary to have a C or COBOL version of the SDO API.

The basic SDO API can be mapped to C and COBOL in a straight forward manner.  Each interface in the Java or C++ SDO API becomes a collection of functions.  In general there is a function for every method in the interface.  Functions that create a new DataObject, Type, Property, etc. return an opaque handle and functions that operate on DataObjects, Types, Properties, etc. take the appropriate handle as the first parameter. Since there are no standard list processing functions in these languages, the SDO API defines a set of list processing functions that provide both indexed and sequential access.

As with Java and C++, it is possible, and recommended, to generate accessor functions for a given SDO. The rules for this generation are quite similar to the rules for the generation of an SDO specific interface in C++.

Exposing data that is used in existing programs is also possible.  A C or COBOL data structure definition (a struct or a group) can be used to define an SDO Type and its properties.  Types defined from data structures are closed, and the applications that provide this data will generally not expect a change summary, but that does not prevent the data from being shared as an SDO.  In this type of use, the existing code acts like a Data Access Service for the code using the SDO.

One other consideration about using SDOs with C or COBOL programs has to do with how arrays and strings are stored.  While it is possible to use dynamically allocated memory to store arbitrary length strings or arbitrarily sized arrays, the code is much more efficient if maximum bounds exist.  Use of XSD facets to define these bounds should be considered if possible.

Specification proposals for the SDO API for C and COBOL are now available for comment. SDO for C and SDO for COBOL Draft Specifications These should be updated to the current level in the second quarter of 2007.

SCA for C and COBOL

One of the basic principles of SCA is that composite applications can be assembled from components that have been implemented in a variety of languages and run on a diverse set of platforms.   As mentioned above, there has been a tremendous investment in applications that are implemented in C and COBOL.  Enabling these applications to be easily reused is essential to fully delivering the promise of SCA.  This means that it must be possible to define components - including interfaces - that are implemented in C and COBOL.

All aspects of the SCA programming model can be defined in C and COBOL, including callbacks and conversations.  This functionality is provided through a set of functions that synchronous invocation, asynchronous invocation - including callbacks, and conversations.  Local and remote interfaces are supported.

Procedural languages implement business logic in programs and subroutines instead of classes with methods.  Thus, a component implemented in C or COBOL can be either a set of subroutines in a library or a set of operations provided by a program.  Either type of implementation can be used and still provide the late binding capability of SCA - services are located and operations are invoked with a runtime binding.

To simplify authoring SCA implementations in C and COBOL, annotations are use.  Interface can be defined using annotated header or copybook files. Additional component and component type information can be specified with annotations in the implementation file. These annotations can be processed by tools to generate the corresponding SCDL files.  Tools to extract the SCDL for existing files are also being defined.

Like C++, C and COBOL programs are compiled and linked, and several services can be linked into a single DLL or load module and it not generally possible to introspect a DLL to load module to determine the interface(s) provided.  Accordingly, when defining a component that is implemented in C or COBOL, it will be necessary to specify both the interface and the executable file.

Once the SCA description of a component implemented in C or COBOL is created, the component can be used in a composite in the same manner as any other component.

Initial proposals for Client and Implementation specification proposals for C and COBOL are expected in the second quarter of 2007.