服务组件架构（Service Component Architecture，SCA）是一个应用程序打包和描述方案，旨在提高在应用程序编程中的可移动性和复用，SCA是IBM的CICS事务服务器4.1（IBM’s CICS Transaction Server 4.1）中的一部分，在深入了解CICS如何实现之前，我们先对SCA做个简短的概述。

　　服务组件架构基础

　　和今天许多其它标准类似，SCA是一个通过扩展标记语言（XML）描述的非常抽象的概念。但是，很多细节方面则留给了一个单独平台的大纲中，当这些细节在宏观层面中开放并可移动的时候，近距离接触装配的细节，情况将会变得难以忍受。

　　SCA的基本单元是组件，一个组件执行一个业务功能，它可能作为一个或多个服务公布，每个服务可能包含多个操作，服务之间也可以引用，组件的实现就是真正实现业务功能的代码。

　　一个或多个组件构成复合组件，但需要注意的是，复合组件中的独立组件可以运行在相同进程或多个进程中，相同复合组件中的组件可以相互通信，暴露在复合组件外的任何服务都可以推广，如何使用一个推广服务的描述叫做绑定。

　　复合组件本身可以分成域，大体上和应用程序差不多，域可以在计算机之间分开。

　　所有这些项目都是在服务组件定义语言（Service Component Definition Language，SCDL）XML中描述的，SCDL可能包括它包含的独立组件的属性，属性操作很像一个为组件提供环境数据的配置文件。

　　CICS定义

　　正如前面提到的，SCA没有大谈平台如何实现一个应用程序，CICS的应用程序编程指南（Application Programming Guide，APG）确定了这一点，它提出，复合组件SCA应用程序必须和CICS的XML Schema一致，APG也指出，你可以编写你自己的SCDL代码，但我不推荐这么做，相反，手册建议使用使用某些工具，如Rational Developer for System z（RDz）。

　　如果你感到好奇，可以查看/usr/cicsts/cicsts41/samples目录中的示例，对CICS模式看起来像什么就有一个初步的了解。

　　在构建好应用程序后，RDz会产生一个CICS包，这个包应该被上传至CICS可用的Unix系统服务（Unix System Services，USS）目录，接下来，系统程序员构建和安装一个包资源，指定上传的目标目录。

　　默认情况下，包的域是空的，但BASESCOPE属性命名一个域，可以围绕组成一个SCA应用程序的所有。

　　服务组件架构服务

　　CICS支持两种类型的SCA应用程序：基于通道的和基于XML的，这两种应用程序可以通过EXEC CICS INVOKE SERVICE命令调用。

　　有趣的是，应用程序编程参考手册（Application Program Reference Manual，APRM）指出，程序员应该使用INVOKE SERVICE命令代替INVOKE WEBSERVICE，这似乎是基于XML的服务可能是Web服务的超集或泛化的信号，实际上，APG中谈到了使用Web服务绑定Web服务描述语言（Web Service Description Language，WSDL），这意味着在SCA中，当域跨平台时，Web服务沦落到成为常规服务的一个特例。

　　基于通道的服务非常简单，SCDL定义了容器或通信区域（COMMAREA）看起来的样子，组件的实现是目标程序名，调用者使用INVOKE SERVICE命令，指定包括输入数据，服务URL，以及服务操作的通道，在识别服务后，CICS只需要简单地链接到程序。

　　基于XML的服务更多的是扮演我们已经使用过的Web服务，当调用者调用服务时，CICS传递信息给请求程序和提供程序管道，如果没有为服务定义管道，CICS会临时分配一个，所有信息都顺着管道传递，普通消息处理程序像以前那样控制和处理消息，最后，CICS调用目标程序执行业务功能。

　　服务组件架构的未来

　　正如前面提到的，CICS和IT行业似乎都在朝更普通的服务转移，CICS将优化管道处理，包括为内部调用基于XML的服务优化。

　　我不确定SCA是否会取代RDO，或CICS是否会将每个应用程序作为一个服务来调用，而不使用事务代码。但我可以想象未来某个时间，服务和SCA将构成CICS的主要工作，就像Web服务和TCP/IP取代IBM 3270终端一样。