SOA正在成为开发新的商业解决方案的首选方法。每一个在充满活力领域的环境中进行开发的人都应该使用SOA，但是很少的人能有享受这种奢侈的条件。

　　导致大规模的SOA实现的推迟的最大的绊脚石是过多的现有系统没有提供一个SOA接口。他们应该被再工程以创建一个web services接口吗?或者一个接口可以通过包装或者间接的方式被创建吗?

　　无处不在的这个问题是比在大型机上面更为有压力的，因为：

　　﹡　许多现有的大型机处理应该提供一个丰富的关于有用服务的缝合。
　　﹡　一般的CICS COBOL程序都不能理解web services中的alphabet soup。
　　﹡　这些处理的所有者只是对他们的稳定性、性能和安全性感到自豪，并且提防分布式应用程学和程序员直接访问他们。
　　﹡　Merrill Lynch在遇到这个问题之后开发了一个内部解决方案，称之为X4ML。已经证明了该方案的有效性，他们把该方案出售给SOA Software，而SOA Software现在将会对该系统进行维护、扩展，并把它同SOA Software的其它产品线整合起来。SOA Software把该工具的名字标识为SOLA。

　　现在的需求就是要能创建一个工具，该工具可以用来为服务的拥有者（the CICS developer）迅速地和容易地把他们的主机程序和数据发布为Web Services，并且这个过程不需要修改任何的代码。CICS开发者应该不需要任何的特别的环境，除了需要能够使用一个浏览器之外，也不需要懂得任何的XML，Java或者web services.

　　Merrill Lynch通过创建一个工具来解决这些需求的问题。该工具对一个CICS事务处理的COBOL程序的来源进行分析，分析对象不仅仅是书的拷贝，而且还有作为结果的Web Service（s）的签名，其中分析书的拷贝是由此可以标识它的输入和输出。作为该过程的一部分，开发者有机会以多种不同的方式来组装Web Service，例如可以通过使用直觉的变量名而不是原来的COBOL程序员选中的名字来发布这些服务。当完成之后，工具自动的创建WSDL并且把它发布到一个UDDI目录中去。

　　一旦发布之后，该服务就可以在运行环境中获取到了，并且它将会执行未标识的CICS事务处理。该工具有一套测试工具，从而使得新的服务可以被所有者测试，但是并不要求所有者理解web services或者将要使用这些服务的分布式环境。

　　这种方式的关键的好处是CICS事务处理可以和web service一起持续的以最初的状态运作。这就意味着在添加新的服务的时候，不会打断现有的系统，并且对同事保持一个事务处理的两个版本也不需要解决。这就是从旧的技术过渡到新技术所得到的无代价方式。

　　我现在可以听到CICS狂热者说“这一切都太简单了，但是会话的3270应用程序怎么样啊?”；明显地Merrill Lynch已经考虑过这个问题，并且创建了一个解决方案，使得接口可以以一种智能的方式被训练，让其知道一个多步事务处理看起来是怎么样的和输入和输出是什么。这种会话的多步的事务处理可以作为一个单独的Web Service发布。就像以前，WSDL可以自动的生成并且服务可以在UDDI注册。

　　SOLA最初的目的是使得企业机构能够把大型程序集成到SOA环境作为逐步淘汰它的第一步，并且不需要分割系统合替代策略的代价。尽管如此，在已经知道集成现有程序是一件多么简单的事之后，这些所有者意识到这个过程应该和在一个主机上使用现有的CICS COBOL开发者才能来开发新的web services一样的容易。SOLA实际上是给大型机程序的开发和应用继续延续的生命。

　　SOA Software计划在这个季度的随后发布SOLA. SOLA将会同SOA Software的其它的系统集成在一起，其中包括Registry，XML VPN和Service Manager。SOA Software也正在考虑为IMS TP提供SOLA。

　　任何具有在大型机上的CICS COBOL产品系统的企业机构应该把SOLA看成一种延长这些系统的生命周期的方式，并且SOLA很可能成为使得大型机程序称为SOA世界的核心的方式。