** 从现存的应用来构建 ** ** Web Services **
** ** 当一个新的想法成为真的一件好事的时候将会发生什么了？人们争相宣称是他们提出了这个想法。而且另外一群人则想占有这想法，并为它增加或修改点什么，这样他们可以说是他们让它更美好。
可能这就是 Web services 的处境。 IBM, Microsoft, Sun, HP, Oracle 和 BEA 就是其中的参与者，他们或声称是他们创造了 Web services 或说他们可以提供最佳的 Web services 服务。
为什么所有的这些卖主都欲竟相领导这个领域了？答案是： ** 钱 ** ** ** 。 Web services 是个伟大的观念，它允许应用软件能被构建集成到一起，并基于应用来部署，这些应用构建于块，块的接口或 API 遵循自我证明标准。这个观念将可能革新人们对软件应用是如何开发和交付的观念。
根据 Gartner 所说， Web services 市场在下个三年将预期增长到 280 亿美圆，但 Web services 并不只是成为潮流的下一个好想法，也不只是关于软件将如何开发的。它也将有关于软件是如何被售卖,并且更重要的是我们将如何购买和为之付费。实际上，很合理的想到微软正将它整个软件技术移向基于 .net 的 Web services 模型的一个主要原因正是它给予了公司为应用软件而完全改变它的商业模型的机会。
** 定义 ** ** Web services ** 在 Web services 背后的想法是软件解决方案能被交付于远程 web 上的离散的 services ，用通用的方式理解每个 service 作什么和用它集成什么。为了使这点实现，该行业已经建立了一些标准如：统一描述、发现和集成（ UDDI ）， Web services 定义语言（ WSDL ），和简单对象访问协议（ SOAP ）。这些标准让一个应用开发者找到一个提供所需的功能 Web service 和理解这个 Web service 是如何运转的，且集成这个 Web service ，该 Web service 有效地使用基于标准接口语言的远程调用。
然而，用宿主在远程 Web 上的功能性模块（可能是匿名的）来集合成新应用软件观念仍旧离现实还很远。在这些幻想成为现实之前有许多问题要克服。下面是三个主要障碍：
** • ** ** 至今无任何 ** ** services ** ** — ** ** ** 这可能有点夸大其词，但它准确的道出了我们距拥有丰富的可用的预构造的功能应用 services 将有多年之远。行业正创建许多我们能用来开发新的 Web services 的工具，并且 IBM 的 Web services 工具就是帮助我们开发新 Web services 的积极例子。
** • ** ** 仍无一个商业模型 ** ** ** ** — ** ** ** 没有谁真地作出它的商业模型。就像三年前 ASP 观念一样， Web services 是一个好想法，但你该如何用它来赚钱了？
** • ** ** 共享的动机可能不充分 ** ** ** ** — ** ** ** Web services 之后的驱动力量就是为了团体共享他们的知识产权。不幸的是，软件的内部功能被看作是私有服务。故在认识到他们在市场上卖的是内部的部分功能而不是完整的解决方案时，软件开发公司将要很大地转变他们的观念。
** 慌乱为什么存在？ ** ** ** 那么如果 Web services尚且 处在幼年阶段，我们为什么能听到如此多有关它的说法了？因为它是有利的！现在 Web services 的观念已经在使用中了，但不是作为应用功能之源的方式，而是把应用集成到一起并且可在企业或贸易合作伙伴组织间建立新的应用的高产的可升级的方式。
两个因素驱动开发企业应用集成（ EAI ）：
• 可扩展性 / 性能
• 业务流粒度控制在集成系统内
EAI 的开发已经从批更新过程转向在事物级别的应用集成，然后到使用高级别消息的应用到应用的集成。下一需求将是要获得更大的可扩展性和在业务功能级别的集成应用的粒度控制，而 Web services 架构就为之提供了方法。
今天大部分使用 Web services 架构的项目是在企业内或贸易合作伙伴之间构建应用服务集成的 EAI 项目。公司正意识到为了将来应用软件的发展，如果他们想转移到 Web services 架构上，他们需要一个方法将存在企业内以行的软件功能转为新的 Web services 。这种选择（将以有的黄金功能模块重写为新的 Web services ）是低耗而费时的。
想象下这样一个场景：一个企业提供它的核心商业应用软件的所有可行逻辑以作为可重用的 Web services 。那样，作为新应用软件开发进行的需要，开发者可立即调用丰富的可立即用的 Web services 而组合成为新的应用。他们可注重于努力开发创建新的商业过程服务，该服务然后能被将来开发可利用。
许多公司认识到组件化的遗留应用商业准则是个很有价值的投资。 Web services 提供了架构和一组成为这些项目结构的标准。
** 功能点分析 ** ** ** 为了度量程序员的生产力和软件开发的投资，许多组织使用了功能点分析。使用功能点为单位的好处是注重于度量各自应用功能点而不是他们的编程语言和独立的技术。平均每个程序员一年全职工作可开发 270 个新应用功能点。
大部分的核心应用由上万个功能点组成。开发一个新的应用功能点要耗费 $550 到 $2,000 ，甚至更多，而存在的核心系统可能将要有数百万美圆的投资，所以一个被迫的选择是重用方法学，让你在的开发投资上继续收获回报并且减少花费和新项目开发的风险。
将你的核心应用逻辑公布为可重用的 Web services 而获得投资收益，为了将来把你的公司转型为灵活的、高综合的科技领域。另外，这个重用过程将有助于在你的 IT 公司中拆卸知识岛屿并且帮助您优化新项目资源。你的遗留应用开发资源将被 JAVA 或 .NET 程序员吸收利用。
** 通向成功的三步 ** ** ** 公布以存的应用为 Web services 的过程包括三个步骤：
• ** 知道你拥有什么 ** ** ** — 许多战略应用软件已开发了数十年之久，被修改了再修改，所以文档是过时的或根本不存在。经常，这最重要的应用成为了未知领域，如果你贸然使用，将会有很多麻烦。可能会显示消息： “ 如果它不停下来，就不要修理它。 ” 只有“远古的高贵的” COBOL 程序员才能涉险这个领域。不幸的是，当那些 COBOL 程序员离去或退休许多公司只能看着 COBOL 编程技巧消失，而又很难替代这些个别的能力和知识。
所以，如果我们想将遗留应用转为动态的、易使用的和易理解的 Web services ，我们必须学会遗留的应用软件是什么？它们作些什么？它们其中的商业准则在哪里？你可以使用应用理解工具做到这点。不要将适合的应用理解工具误解为用来 Y2K 修正项目的代码限制工具。这个你所需要的工具必须提供你应用软件的整体上的和语义上的理解。当提供内部应用流、事物处理和业务逻辑时，它必须能理解整个应用软件的上下文，包括程序代码、数据库和工作控制环境。
• ** 挖出真金 ** ** ** ** — ** ** ** 一旦你理解了你的核心系统知道了商业准则在哪里，那么下一步就是孤立它们以用来重用为 Web services 。这个过程可被划分成非干预的和可干预的方式。有时，分离与一个特殊业务功能相关的代码元素可能很难。较少干预方式可能更有意义，这种方法将可公布为 Web services 的业务过程限制于功能性，该功能性能通过 屏幕擦写 或从数据库创建服务来访问。
简单屏幕擦写可能并不能提供基于 service 的架构，该架构需要公布实际的业务功能为 Web services 。任何基于通过屏幕 I/O 接口来公布业务逻辑的非干预方式必须提供这一级别粒度用来公布每个屏幕接口为一个应用 services 集合，或任何屏幕的团体是单应用 service 。基于接口的屏幕提供优化可扩展性也是基本的。如果对每个过程基于屏幕服务的练习，架构是基于对等网络的关系的话，那么它不可能是充分的解决方案。
建立数据库 services 可能也将是个挑战，因为许多商业系统是基于 COBOL 文件系统的或其它非关系数据的。在基于架构的 services- 上的纯数据的访问意味着这些数据通过一些形式访问语言（如 SQL ）而暴露。大部分的 COBOL 数据库不支持本地 SQL 访问。然而，市场上有中间件产品能提供非 SQL 适应数据的开放存取，那么这些中间件工具就需要集成到 Web services 结构和标准中。
更完全的和最具战略性的解决方案是公布程序逻辑为可重用的 services ，这需要采取干预方式——进入到代码中去。如果你对应用理解投入足够的投资，那么这就不是那么难了。而且，可获得的工具能帮助你从以存在程序中隔离和抽取数据，然后将这些数据打包而作为离散的 service 使用。
• ** 创建 ** ** Web services ** ** — ** ** ** 已经理解了你的应用软件后，然后发现和收获你想重用为 Web services 的商业准则，你现在需要调节你的产品以使你能公布 COBOL ， C 或其它的遗留程序为 SOAP 上的 Web services 。
一种可选的适配方法是自动将分离的数据翻译成 Java 或 C# ，意识到这点，虽然它听起来具有吸引力，但自动转化遗留语言代码为适应的 Web services 代码，它是具有很多缺陷的。你几乎不能将清楚的转化用新的语言来完成。通常，在新的目标语言中效法原始代码结果是种错误的架构。你获得其半成结果，不管如何，你的程序员要理解或继续工作。
如果适配方法将商业逻辑留在现有语言中，一个好的适配环境将可允许你采用新语言写的 services 与遗留的 services 混合。这个演变方式让你逐渐转换根本的技术，而避免重开发的灾难性危险。
为了正确的实现这三步，你将需要软件工具和中间件（见图 1 ）来帮助你完成工作。
图 1 为转化以存在的应用商业准则为 Web services 的中间件栈 ** **
** 结论 ** ** ** 上述过程描述了从现有的核心商业应用来创建 Web services 的有效方法。为了它的益处，只有勇敢的公司才能着手大的项目将他们以存在的应用软件转化为 Web services 仓库。商业需求和驱动才能领导这些项目。
** 应用理解 ** ** ** ** — ** ** ** 第一步必须完全地理解和文档化你现有的系统，你的 IT 公司就要完成第二和第三步——识别出应用集成和新应用组合的需要，然后完成从以存在的应用去创建可重用的 Web services 而需履行的步骤。经常，重要的新的应用能使用相对少的数量的遗留商业准则而被构建或集成为 Web services 而公布。通过这种项目接项目的方式，交付你公司切实利益同时，你可以完全地转换为 Web services 的架构。尽量应用这一伟大想法吧， Web services 明天是有保障的。