多年以来，动态路径选择已被证明是一种可靠的CICS配置。它可以增加CICS的灵活性，从而提供更高的可用性，更好的性能和效率。即使IBM已添加了新的功能，系统程序员们还是在采用这种策略。

　　为什么一定要动态选择Web服务路径？

　　起初，Web负载似乎不需要动态管理。Web流量可以通过负载分发器，以TCP/IP HTTP协议的形式来选择路径，负载分发器可以依据处理器可用性来“智能”地选择目标LPAR（逻辑分区）。在独立的LPAR中，系统程序员会提供多个Region来共享同一个TCP/IP端口，其中任何一个都可以支持服务。这种冗余配置和半智能路径分配方式确保应用的永久可用性和性能。

　　多数时候，是这样的情况。但是，尽管说可以指定路径分配决策，但上文提到的配置并不能确保Region的“健康”状况。例如，对于一个没有连接到数据库管理系统的CICS而言，上述配置就不能指定一个DB2应用到CICS的需求路径。在遇到存储资源短缺或遭到破坏的情况时，也会遇到同样的问题。如果你想指定更好的路径选择决策，至少要提供一级能识别并监控CICS的“健康”状况的“迂回”路径。

　　LR可以提供所需的“迂回”路径。传统的LR拥有TCP/IP服务和端口，数据可以从此输入。虽然基本原理大致一样，但Web服务要求稍高。

　　Web服务提供者泛滥

　　在CICS收到一条Web服务网关上的输入信息时，它会启动CWXN事务。CWXN会利用这条信息对内置URI和URIMAP定义进行比对，找回目标Web服务属性。得到这一属性之后，CWXN会使用Web服务捆绑文件（WSBIND）和管道配置文件来推断出下一步该做什么。如果捆绑文件能够说出管道事务的名称，CWXN会对其进行标记。否则，CWXN会启动默认的CPIH。

　　管道事务会将剩余的输入信息去除。在对XML进行分析的同时，它随时可能呼叫任何管道配置文件专用的消息头处理器。此外，CICS将会对消息头中包含的任何安全文本进行认证。

　　消息头处理器可以在其它文件中为Web需求指定一个新的事务或用户ID。同样，内部消息中通过认证的安全身份会强迫安全文本发生变更，已适应其余管道处理进程的需要。其中，不管发生什么特殊情况，CICS都会开启第三个事务，对文本或事务进行转换。

　　最终，无论安全文本或事务ID如何变化，CICS都会与准备提供Web服务的应用程序取得联系。在CICS重新回到网络之前，应用程序都会返回答复，传输事务链的备份文件。

　　动态路径分配的机遇

　　对于工作负载分配而言有很多机遇，因为CICS支持DTR和DPL两种方式。通过对管道事务或应用进程的动态分配，我们可以很轻松地实现对事务路径分配的管理。对于DPL而言，通过对管道事务的本地化、并对目标程度进行可绕性处理，我们可以确保应用需求停留在LR层面，知道Web服务链接到其目标应用程序，也就是求助于DPL。

　　DTR有可能更适合LR的最初意图——Region只是负责与网络进行沟通，最终决定将工作分配给谁，除此之外别无它用。对于Web服务而言，有更多的东西可以运行在LR上，比如说消息头处理器。但是，应用负载可以在任何地点完成。

　　然而，同其它领域一样，难免会有其他因素被牵扯进来。根据路径分配地点的不同，Web服务和管道定义并须被安装在AOR之内，LR也会将需求发到这里。这也就意味着SOAP消息和附带的容器必须通过MRO在LR和AOR间传递。SOAP消息往往更大一些，可能更适合本地交叉存储链接。但是，如果数据必须通过XCF传到另一个LPAR那里，就会遇到问题。

　　DPL方式相对要更为“清洁”。原因如下：首先，只有早已从输入需求和文本容器中得到数据分析的应用才需要通过MRO链接发送。其次，所有的进程（特别是Web服务进程）在LR中都会被隔离，AOR不需要知道其任何信息。事实上，AOR更像是一台真实的服务器，来处理本地的DPL需求。无论来源是哪里，它都会提供数据输入服务给某数据容器，最后再传回LR那里。然而，所有损坏输入信息的进程都会破坏传统的LR模式。对于一些非正常的SOAP信息而言，LR也会陷入圈套。