SOA案例研究:不同应用程序的集成组织

【2006-10-11 07:51】【Mark Berman】【MSDN】　　这个案例的研究体现了利用一种SOA方法来迅速改进操作的好处.Host Integration Server 2004 体现了服务器的网络服务功能，使其更加容易适应不同的LOB应用系统。BizTalk Server 2004 使得创建复杂的商业逻辑变得容易，这种商业逻辑是集中的、简单易管理的、同时也容易和前端应用相结合。这种面向服务的解决方案技术，通过微软公司操作管理者，发现了以前没有报告的错误信息，从而使得整个构架变得更加容易管理。

　　应用于:

　　企业体系结构
　　解决方案技术架构
　　面向服务构架
　　应用程序集成
　　背景概述

　　在过去的几年里, 有很多关于面向服务构架SOA的讨论以及它能够为组织带来的利益，尤其是那些拥有LOB应用系统的组织。我们看到了由中间件研究机构推出的被广泛认可的SOA计划，这标志着针对企业级应用程序集成的SOA方法是成熟和可行的。这些独立软件开发商，咨询公司和消费者都这样认为:采用面向服务解决方案技术正在迅猛的增长。计算机世界最近报道说:“2005即将是SOA年... 对于美国的组织，75%的企业计划为这项技术进行投资并且为SOA安排人员。”

　　为了举例说明SOA的价值，本文描述了微软公司的一些步骤，这些步骤讲述了微软技术中心在应用程序集成方面所遇到的一些重要挑战，这些挑战和大多数公司所遇到的是类似的。伴随着我们探究这些挑战，揭示其深层次的原因，找到一种方法，这种方法能够使面向服务的解决方案技术迅速改进操作效率和提高同各种LOB应用系统相互交互的能力，那么SOA的前景将变得清晰。 本文同时讲述了微软技术是如何为面向服务解决方案技术中的一些重要的功能提供服务的。例如, Microsoft Host Integration Server 2004将基于IBM大型主机与中阶系统的应用系统当成基于Microsoft .NET的Web服务来处理，这种Web服务带有能够满足Windows应用的全部功能。这些功能使系统变得更加具有协同能力，同时为错误报告和错误处理提供了一种更好的解决方案。利用Microsoft BizTalk Server 2004去管理商业流程组织，微软技术中心能够控制商业流程，比如，在提交给应用程序之前进行错误数据检测。在下面详细的描写中，你将看到其他一些解决方案的原理, 包括一般的和基于微软的。

　　当微软公司坚定地相信选择去实施面向服的构架是一种商业决定而非一种技术决定时，你所采用的技术仍然很重要。本文将讲述在这个快速开发、快速集成和管理的时期，微软的技术能够更好的帮助你解决目前所面临的挑战。比如，通过采用微软的开发技术和中间层技术，整个面向服务的解决方案(如下所述)能够在2个人月里完成。

　　绪论

　　微软技术中心 (MTCs) 给用户提供了一个环境，供其去想象、构思，同时通过微软及其合作伙伴的技术得到一种解决方案，这种技术优先配置在用户自己的IT环境中。当微软公司技术中心这一商业组织去推广其服务时，它和它的13个遍及世界的技术中心像其他企业一样运行，关心所有的方面诸如可用性、安全性、稳定性和可管理性等等。

　　全球的微软技术中心组织机构设计成为了一个真实的企业环境。像其他公司一样，围绕着微软技术中心最主要的挑战是很多老式应用程序已经不再使用微软的技术来开发，并且前端的应用程序已经不在Windows平台环境下运行。确切地说，每个地域都有它们自己的构架，在总局主要访问一组LOB应用系统(比如,在Redmond中)。在总局和分局里，它们通过前端应用程序来为主要的商业流程实现资源共享。

　　伴随着各个地方交易数量的增长，如何给那些总局提供可靠的资源共享变得日益困难。比如，一些运行在中阶系统(Report Program Generator)和大型主机系统(COBOL)的应用程序在过去设计时并不能提供多路访问。结果，很多分局运行应用程序时会遭遇死锁和间歇性失败，并且没有任何出错原因提示和问题来源提示。当这些问题产生时，总局将要经历一个艰难的过程去管理这些应用程序和修复问题，尤其那些原始的开发者不在的时候。

　　为了不重新构建所有的微软技术中心的演示环境的LOB系统，管理小组决定检查已经存在的综合集成需求，同时优化介于LOB应用系统和前端应用程序的集成层，这样做有如下好处:

　　通过允许多前端应用程序同时访问LOB资源，并且有商业流程来彻底处理失败的业务来改进系统的稳定性。
　　通过提供可控的错误信息，减少了错误调试时间。
　　通过良好的监控器能够避免问题的发生
　　定义了一致的契约信息
　　定义了一致的绑定信息
　　挑战

　　总的来说，微软技术中心使用相同的系统来进行运作，作为一个典型的公司也拥有挑战。为了更好的了解微软技术中心所面临的一些特定问题，我们将利用其拓扑结构来讨论。

　　一个全球性的组织结构

　　微软技术中心的组织结构体现了一个虚拟中型的零售产品制造商的组织结构，在这个系统里完成接收订单和分发订单。每个分局都有一个需求组织结构(区域控制器，消息服务器，Web服务器，SharePoint 组织结构等等)，这个需求组织结构用来初始化一个订单和与订单进行交互。如图1 所示，总局有中阶系统(iSeries) AS/400 server(基于仓库应用程序为RPG服务)，大型主机zSeries 890 server(基于托运应用程序为客户信息控制系统服务[CICS])，RS/6000 UNIX server(基于执行应用程序为WebSphere服务)，还有一个土生土长的运行在Windows上的回复应用程序。

　　图 1. 全球组织结构

　　1.一个分局将订单发送到运行在中阶系统上的仓库应用程序。
　　2.仓库用户利用IBM 5250 Emulator 去查看订单，并且把订单的状态从新建改为已分配。
　　3.一个灵敏的挑选应用程序接收到了一个挑选请求。
　　4.仓库工作人员执行挑选活动，并且承认该项已经被挑选了。
　　5.订单状态信息在仓库应用程序上改为已经挑选了。
　　6.仓库工作人员更新订单的状态信息，从已经挑选了改为已经托运了。
　　7.大型主机托运应用程序收到了托运请求，该托运请求可以用IBM 5250 Emulator 来进行校验。
　　8.WebSphere执行应用程序 收到了执行请求。
　　9.回复服务器通报买方该项目将会在规定的时间内托运到。
　　严格的、难于管理的应用程序

　　在应用面向服务原则之前，许多老式的应用程序有同样的易管理问题。首先，LOB应用系统在前端应用程序尝试同时访问时可能会失败，还有在中间交易网络出现存储损耗时和数据格式化错误时都可能失败。当一个对应用的请求失败时，应用程序不会给出错误信息，并且系统不能够被彻底的关闭和重新重启(在适当处)。从一个运作观点来看，错误调试没有恰当的错误信息确实是一个挑战。而且，由于商业逻辑和商业流程的高度联系性，这种结构不能够利用新的技术。自从微软技术中心的商业突出为端到端的、更好的相连的模式时，这种模式在新技术和实际中是出类拔萃的。

　　最后，LOB应用程序是严格的、难于管理的，运作小组在一种连续的反应模式中，试图保持这些共享资源的工作，但是对于“系统不论什么时候，都不会出问题”却没有任何真正自信。

　　解决方案视角

　　微软技术中心开始的时候就有一个信念，认为面向服务的构架能够使各种LOB应用系统变得更加容易集成综合，提高稳定性，在错误调试时能够提供有意义的错误信息。基于这种理念，他们建立了一种约束和需求，使它们能够满足任何建设性构架。

　　最重要的目标是集成已经存在的大型主机和中介系统应用程序，应用程序有更加高效的交互性，同时也能够保持灵活性和协同工作能力，有一个基于标准的部件。形成面向服务解决方案的约束有如下一些:

　　•所有的公共接口都必须是Web服务，目的是:
　　•使所有的集成实现的时候都是同一种风格，不依赖于局部装配
　　•外部的开发者通过已经定义好的访问点(绑定)，能够独立集成解决方案。
　　•外部的开发者通过已经定义好的一致模式，能够独立集成解决方案。
　　•对于详细的外部应用程序和结构(像网络)，错误信息必须是有用的，而且是一致的、可预测的。
　　•为了促进交互和错误调试，必须要有一个端客户端到端的可靠的消息分发机制(在恰当处)。
　　•由于客户层频繁的改变，必须要支持松连结的客户端集成。

　　图 2 关于Redmond 设备资源共享的SOA解决方案

　　所有在暗绿色区域的部件都表示新的或者已经改变了的部件。可以注意到作为一种原始的解决方案的回复服务器已经被微软的语音服务器所替代，它是一种用来配置和管理分布式语音应用程序的工具。简而言之，在一系列的Web服务和BizTalk流程组织之后，面向服务的解决方案概括了所有的资源共享。

　　一个前端应用程序，比如一个订单表(上面已经描述了)，发起一个交易通过发送一个XML格式的订单发到BizTalk流程组织。该流程组织检查这个订单，这个新的订单详细信息被发送到另外一些Web服务上并且执行这个商业流程，这些Web服务是和各种不同的LOB应用系统交互的。关键是面向服务的解决方案，仅此面向服务的解决方案直接和LOB应用系统交互。因此，在订单到达LOB应用系统之前Web服务能够拒绝坏损的格式化订单，解决一个共性的问题(微软技术中心以前遇到这个问题)。而且，由于BizTalk Server 2004的这个商业流程组织是异步的，多路订单能够同时到达和处理，而不需要查找LOB应用系统。

　　最后，当那些很少出现的错误和异常发生时，不管是否在LOB应用系统层、在网络层、在主机集成层或者流程组织层，关于这个事件的丰富信息能够通过Web服务传播到操作小组，在这些地方利用微软的操作管理(MOM)来分析是可控的、可行的。

　　SOA是由一系列相互联系的层来组成的。从一个开发者的角度，讨论这些层也同时体现了构建面向服务的解决方案的方法步骤。因此，第一件事就是使它们能够通过Web服务来访问LOB应用系统。其次，以某一种方式来实现商业流程非常有必要。

　　通过Web服务使后端应用系统可用

　　由于仓库应用系统是由RPG编写的，客户信息控制系统服务[CICS]是由COBOL编写的，他们原本是不能够被访问通过Web服务。通过利用Host Integration Server 2004 (HIS)，下面的应用程序接口能够像可访问的.NET Web服务，在Visual Studio .NET中应用程序的功能可以直接使用 (Host Integration Server 在 图 2中可见) 。WebSphere应用程序能够用Web服务来体现，通过利用.NET框架来创建一个.NET代理对象。

　　对于语音服务器，小组决定用微软的语音服务器来代替现有的解决方案，这种服务器提供更加丰富的解决方案。一些有意义的开发技术被用来开发复杂的语音功能。语音服务器基于预定义的声音资源文件动态的生成一个恰当的信息，这些声音资源文件包括普通的东西表示方式，比如用整数作为顺序号和一些普通的问候信息。由于语音服务器原本就支持.NET，所以用Web服务来表示服务器的功能是一种很简单的事情。有了这些Web服务，应用程序基本的部件提取就完成了。所有的事件和错误代码都被捕获并且由微软的操作管理(MOM)来控制，MOM能够监控、分析、诊断和避免这些问题。

　　利用商业过程来控制组织构架

　　除了简单抽象的LOB应用系统之外，一个好的面向服务的解决方案同时也提供了一个控制商业逻辑的灵活方法。利用BizTalk Server 2004，流程组织作为一个已经定义好的商业流程被用来表示多路Web服务前端。这个流程组织好像一个乐队指挥员，也就是说，决定何时和如何让每一个交易都处理。在上面所述的商业流程例子里，当一个XML格式的订单表被提交了，流程组织检查这个订单，同时提交给另外一个流程组织，这个流程组织是为了管理和仓库应用程序交互而设计的。其它的流程组织管理与其它各个的LOB应用系统的交互。

　　注释:在图2里仅仅给出了BizTalk Server在LOB Web服务上。还有，像刚才描述的那样，多流程组织管理特定的商业流程。

　　这些流程组织坚持按序访问LOB应用系统，它们同时避免了许多种类的问题，这些问题在过去曾会导致失败。例如，流程组织不允许格式化错误的订单执行，而且会将失败和其失败原因写到事件日记里。

　　另外一个利用BizTalk Server 2004的好处是它允许在系统中实时看到订单的状态。比如，一个订单到了仓库应用程序，仓库操作人员假设将订单的状态改为“挑选”，说明产品在库房里，而且订单正准备托运。当一些失败出现时，操作人员能够看到现场运行场景，确信订单仍在仓库应用程序中等待状态改变，或者进一步诊断耽搁或失败的原因。

　　获取主动性

　　如上所述，管理组织意识到由于错误信息是用一致的方式表示的，他们就不仅能够利用这些信息来进行调试和报告错误，而且能够主动进行系统监控 。他们利用微软的操作管理(MOM)从Web服务上获取所有的错误和事件信息，利用这些信息能够进行诊断性的分析。

　　构建SOA

　　根据计算机世界的最近报道:

　　“SOA 在技术方面不需要大量的投资，这些投资是模糊的投资回报和延长的投资回收年限。SOA可以完成小的增量，巨大的软件和服务利益重新使用能够迅速交付基线结果。事实上，当一个组织构建一个有战略眼光的SOA，经常有一个在项目层次上的清晰投资回报。这种现象是奇怪的，这也是商业经理人经常怀疑的地方，然后事实却是如此。”--计算机世界 2004年11月15日。

　　微软技术中心的案例研究确实证实了以上所述。整个面向服务的解决方案，包括HIS对RPG的接口和COBOL 应用程序，所有的Web服务，BizTalk流程组织、新的语音服务器和其所有的逻辑，还有新的基于InfoPath的小客户端购买应用程序，所有的这些大概需要两个人月去构建。当然，主要是由于利用HIS、BizTalk, 和 .NET开发环境很容易，然而实事是前面的少量投资能够减少全部的开发时间，在控制老式系统的时候能够产生巨大的效果。同样，正如计算机世界所述，一旦这些投资已经投了，相同的项目非常容易做，SOA尽可能构建在项目和项目层次，而不是企业事业层次。

　　面向服务的解决方案的好处

　　面向服务的解决方案有如下好处:

　　商业逻辑层位于用户层和老式系统之间，这样能确保系统仅能够按照其原来的设计方式来访问。
　　老式应用程序作为.NET应用程序是可用的，所以使开发变得更快。
　　BizTalk的路由支持集中各种不同LOB应用系统的入口点。BizTalk简单的分析XML数据信息，它决定发往哪里。同时修改商业逻辑也不需要完全重写应用程序，开发人员仅仅需要更新流程组织和重新配置。
　　由于老式系统目前容易从.NET平台来访问，扩展也很容易。应用程序如Microsoft ASP.NET, [URL=http://soft.yesky.com/office/]Office[/URL] System, and Smart Phones都能够和在LOB应用系统中的数据进行交互。
　　开发人员没有必要专长每一个老式系统，因为每一个系统都是通过一些公共接口来访问的。
　　面向服务的解决方案跟踪了除原客户端之外的所有过程层次的错误，这也是它应该做到的，开发者和面向服务解决方案的交互也是应用程序应该具有的。从BizTalk到Web服务和它们自身的老式应用程序，如果有错误出现都会通报操作人员。常常，问题能够在外部客户端意识到之前就判断出来。
　　结论:

　　这个案例的研究体现了利用一种SOA方法来迅速改进操作的好处.Host Integration Server 2004 体现了服务器的网络服务功能，使其更加容易适应不同的LOB应用系统。BizTalk Server 2004 使得创建复杂的商业逻辑变得容易，这种商业逻辑是集中的、简单易管理的、同时也容易和前端应用相结合。这种面向服务的解决方案技术，通过微软公司操作管理者，发现了以前没有报告的错误信息，从而使得整个构架变得更加容易管理。

　　这一特殊面向服务解决方案的细节是微软技术中心的唯一特殊需求。然而，通过使用Web服务和流程组织，概括出的基本原理体现了如何利用比较少的费用完成一个灵活的、可重用的、能够支持已有投资的组织结构。

[URL=http://www.microsoft.com/china/MSDN/library/architecture/SOAStudy.mspx?mfr=true]查看原文[/URL]

特别是SUN DE JCAPS。。。