Service Component Architecture (SCA) is an application packaging and description scheme designed to enhance portability and reuse in application programming, and it is included in IBM’s CICS Transaction Server 4.1. Before we dive into CICS’ implementation, here’s a short SCA overview.
Service Component Architecture basics
SCA, like so many other standards today, is full of abstract concepts described through extensible markup language (XML), however, many of the particulars are left to an individual platform’s schema. While this does leave things open and portable at the macro level, the going becomes brutal the closer one gets to the details of deployment.
The basic unit of SCA is a component. A component performs a business function, which may be advertised as one or more services. Each service may contain any number of operations. Any services a component needs from other components are references. A component’s implementation is the code that actually performs the business function.
One or more components are built into composites. Note that the individual components within a composite may run in the same process or multiple processes. Components within the same composite communicate via wires, which can be platform specific. Any services to be exposed outside of the composite are promoted. A description of how to use a promoted service is called a binding.
Composites themselves can be grouped into domains, which are roughly analogous to applications. Domains can be split between computers.
All these items are described in Service Component Definition Language (SCDL) XML. SCDL (pronounced “skiddle”) may include properties for individual components it contains. Properties operate a lot like a configuration file that provides environmental data for a component.
The CICS definitions
As mentioned above, SCA doesn’t have a lot to say about how a platform implements an application. CICS’ Application Programming Guide (APG) confirms this by mentioning that composite SCA applications must conform to CICS’ XML schema. The APG also says you can code your own SCDL but I wouldn’t recommend it. Instead, the manual suggests using some sort of tooling, such as the Rational Developer for System z (RDz).
A curious person can get an inkling of what the CICS schema looks like by viewing the samples in the /usr/cicsts/cicsts41/samples directory.
After building and “choreographing” the application, RDz produces a CICS bundle. This bundle should be uploaded to a Unix System Services (USS) directory available to CICS. The next step is for the systems programmer to build and install a BUNDLE resource, specifying the directory the definitions were uploaded to.
By default, a bundle’s domain is empty. However, the BASESCOPE attribute names a domain and can draw a line around all bundles that make up the definitions for an SCA application. CICS uses a combination of BASESCOPE and the SCA scope to define a service during runtime.
Servcie Component Architecture services
CICS supports two types of SCA applications: channel-based and XML-based. Both may be invoked through the EXEC CICS INVOKE SERVICE command.
Interestingly, the Application Program Reference Manual (APRM) notes that programmers should use the INVOKE SERVICE command instead of INVOKE WEBSERVICE. This seems to signal that XML-based services are either a superset or a generalization of Web services. In fact, parts of the APG talk about using Web service bindings with Web Service Description Language (WSDL). This means that in SCA, Web services are reduced to a special case of general services to be used when domains cross platforms.
Channel-based services are fairly simple. The SCDL defines how the containers or communication areas (COMMAREA’s) should look. The implementation of the component is the target program name. The caller uses the INVOKE SERVICE command, specifying the channel containing the input data, the URL of the service, along with service’s operation. After identifying the service, CICS simply links to the program.
XML-based services act more like the Web services we already use. When the caller invokes the service, CICS passes the information down a requestor and provider pipelines. If there isn’t a pipeline defined for the service, CICS assigns a temporary one. All along the pipeline, the usual message handlers get control and process the message as before. Finally, CICS invokes the target program to perform the business function.
The future of Service Component Architecture
As previously mentioned, CICS and the IT industry seem to be moving to a more general sense of a service. CICS is playing along by bracketing something as simple as LINK with elaborate descriptions and schemas. However, CICS will “optimize” pipeline processing even for XML-based services invoked internally.
I’m not sure if SCA is going to replace RDO, or if CICS will start invoking every application as a service instead of using transaction codes. However, I can picture a time in the future where services and SCA will make up the majority of CICS’ work, much as Web services and TCP/IP have replaced IBM 3270 terminals.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.