Web服务和XML是否已发展为“封装”大型机遗留应用的一种有用手段？Web前端是否正开始压倒那些高贵的平台？在此专家对遗留应用的SOA化做出评价，包括迁移和更新改造的策略，架构方案以及做到什么程度才算足够。

　　Grace Lewis是位于匹兹堡的软件工程协会（SEI）的资深技术员工，按照她的说法，大型机仍有一席之地，但是，在理想的条件下，组织应该在它擅长的地方发挥其作用。

　　“许多公司留有许多数据在这些大型机里面，他们可以继续在大型机擅长的地方——数据处理方面利用它们。也就是说，不是把这些大型机用作交互的机器，而是在晚上结束数据的处理，然后交给白天那些更现代的应用。有些人视其为延长遗留应用寿命的一种方式；另外一些人则认为更新改造，尤其是支持方面，正变得越来越昂贵，要想寻找到了解大型机语言的人也变得越来越困难”。

　　Lewis负责讲授SEI的面向对象架构：遗留系统迁移教程，她说存在若干的更新改造/迁移策略：“一种是直接封装，不是进行代码修复，而是在遗留系统周边封装上一层以便能访问部分功能；按照原样封装功能的做法有利有弊”。

　　另一种策略是做一些增量式的更新改造，她说：“作为一种架构风格，面向对象的优点是接口和实现的分离。开始时你可以有接口访问到一些老的遗留代码，但随着时间的推移，一旦你准备好了，那不过就是切换一下底层实现而已”。

　　第三种，她说，则是“不必用Web服务接口精确地对接到大型机，而宁愿去创建一个中介。因此来自于大型机的数据被析取出来并放到更现代的带有Web服务接口的服务器上”。

　　“一方面你在使用着大型机上的数据，可同时大型机也并没有直接暴露出来”。

　　“封装”策略的任何部分都必须确定封装恰当的代码，Sunil Talreja建议。Talreja是全球性的咨询公司Sogeti负责应用开发与集成实践的高级副总裁。

　　“我们仍建议客户继续封装遗留代码及遗留功能”，他说：“这是从遗留环境中获取功能和能力的一种经过检验的方法和模式。这种架构性的关联仍然站得住脚”。

　　一个明显的风险，他说，是“在封装代码方面没有做出合理的决策。我观察客户已有多年，发现他们并未花时间去把恰当的代码封装起来，然后他们最终得到的是意大利面条式的封装代码”。

　　性能也是一个值得担忧的因素，Lewis说：“有许多产品都是抓取屏幕然后直接把它们传给一个工具，因此到最后你就是给屏幕增加另一个Web服务接口，这存在非常多的性能问题”。

　　尽管Lewis说这是避免让最终用户跟大型机打交道的一种临时应急的方式，如果性能有问题的话，这也许并非可行方案。

　　Talreja说封装需要着眼于全面，需要有效率，然而，他承认“你不能一直这么干下去”。如果大型机有缺陷，封装就会把这些缺陷暴露出来。

　　下一步，他说：“是要好好看看改进基本的事务需要做些什么了，评估一下”。组织需要明确拥有运行于大型机的特定能力是否还有意义，或者是不是把它移到分布式的环境中会更有意义。

　　Talreja补充说：“那种类型的投资仅着眼于需要关注的交易组合”。

　　Jim Johnson，位于波士顿的研究咨询机构斯坦迪什集团（Standish Group）的主席，他说，考虑到应用的状态在不断改变，封装并非长期策略，而组织则需要开始考虑将大型机应用分解，“以便变得更为轻快灵活。企业应用的寿命正在慢慢变短，而转向总是不断变化的轻量级应用观”。

　　其间，Johnson说许多组织“正在瘦身。相比于过去，当前正在进行着多得多的重构；各个组织，无论是使用SOA或其他方案的，都在大幅裁员，减小应用规模以便削减维护。”

　　按照William Ulrich的说法，这个问题的关键是IT与业务相适应这个老大难问题。Ulrich是位于加州索克尔（Soquel）的一家业务与IT咨询公司TSG的总裁。

　　“从核心上来说，老的遗留大型机系统是在干自己的事情，但它并不能按照业务需要的方式进行调整。我们需要找到解耦的办法，并对底层的架构进行重组”。

　　大型机远景

　　就长期而言，Ulrich说：组织将需要对所有的中间件进行解耦。“我们有遗留的Java、遗留的C++，也许还有一些PowerBuider挂在那里。这些中的许多都是建造在假设后端系统是黑箱的架构性基础之上的”。

　　Ulrich承认，解耦并不简单，“这正是为什么消息不能很好地引起共鸣的原因。这上面一层层地贴了那么多的创可贴；你不能够一直靠接口来做些临时的修修补补，因为在某些点上你可是在临时搭建的基础上再搭建临时设施”。

　　他说，组织需要利用更新改造分析工具去获得对自己系统的理解，然后“明智地将它们沿着由业务架构驱动的路线图进行解耦”。

　　他最后总结：“当进行更新改造的时候要把所有东西都摆到桌面上——当谈到系统的时候没什么东西是神圣不可侵犯的。也没有什么既定目标要让大型机消失——这是个副产品，根据业务需要，它可能会出现，也可能不会”。