在Web服务中使用SOA方案
毫无疑问，面向服务的架构（SOA）正快速成为企业计算领域中最热门的潮流。IT部门每周（如果不是每天的话）都受到厂商的宣传和市场消息夹击，厂商们宣称，他们可以提供大量技术和服务产品，用于魔术般地转变开展业务的方式。
与此同时，面向服务正得到越来越广泛的接受，而且SOA作为企业计算方法，正从根本上改变企业查看它们的IT基础架构的方式。使用基于公开服务而构建的灵活应用程序来代替复杂的单片式应用程序，可以提高开发人员的生产力，提供更大的灵活性，从而最终降低成本。采用Web服务和SOA还可以消除企业应用程序开发项目中的复杂性和集成问题。
但是，和任何具有极大潜在影响力的大型项目一样，IT部门必须制订出正确的计划，准备好正确的资源，以确保成功转换它们的计算基础架构。大多数IT企业面临的最大绊脚石不是是否要转而使用SOA，而是确定这样做的最佳方法和合适的投资水平。
定义面向服务的架构
面向服务的架构（service-oriented architecture，SOA）是一本蓝图，用于指导在业务服务的整个生命周期中创建和使用它们的方方面面（从构思到撤消），以及定义和提供这样的IT基础架构，该基础架构允许不同的应用程序交换数据和参与业务流程，而不论这些应用程序底层使用的操作系统或编程语言是什么。随着Web服务的出现，做到这一点已经变得更加容易，而且不会依赖于任何一种特定的方法（面向数据，面向消息，面向对象，面向过程，等等）。
任何SOA的首要目的都是帮助IT能力和业务目标达成一致。到SOA的迁移帮助企业精简了解决方案的设计和开发，使远程团队之间进行协作更加容易，并支持通过模块重新配置和重新确定目标进行重用。
首先，SOA是一种构建IT系统的方法；它并不是一种技术或一个银弹解决方案。SOA是一门方法学，在这门学问中，业务服务（即企业提供给客户、用户、公民、合作伙伴和其他企业的服务）是帮助IT系统与业务服务达成一致的主要组织原则。最重要的是，定义服务的方式是独立于底层技术的。相反，早期构建IT系统的方法依赖于具体方法，比如面向对象、面向过程和面向消息，这将导致系统与特定技术（比如CICS、IMS、CORBA、J2EE, COM/DCOM等等）的功能紧密耦合，因此对业务的通用性较低。按照这些方法和途径进行开发通常会导致出现单片式和筒仓式的应用程序，在当今的大多数IT系统中都可以找到这类应用程序。
通过使技术去自然地适应需要使用它的人，而不是专注于技术本身（就像前一代IT系统那样，这会迫使人们去适应技术），使用Web服务的面向服务降低了企业集成项目的成本，并提高了项目的成功率。面向服务的集成和其他方法之间最大的差别在于，面向服务可以让您更加专注于对业务问题的描述，而其他方法要求您把更多的精力投入到使用特定技术解决特定的集成问题这个过程中去。
由定义可知，面向技术的方法被限制在一种产品或技术上。使用Web服务的面向服务方法并没有基于一种技术、技术类型或产品之上，而是基于设计和部署能够在任何技术类型上执行的服务。因此，面向服务集成项目的开发人员可以更集中地考虑业务问题，而不是技术问题，因为Web服务可以广泛用作到几乎任何一致技术类型的接口。仍然可以为执行环境选择合适的技术，但是对于服务用户来说，执行环境技术与他们无关，因为他们要与之打交道的是Web服务描述，而不是执行环境。
如图1所示，设计、开发和实现SOA的最终目标是为应用程序之间的对话、与业务流程引擎和多种客户端类型集成提供更新更好的方式。条形上的菱形代表Web服务接口，可以使用某种编程语言（例如Java）从头开始开发它，也可以使用Web服务基础架构产品进行翻新。开发完毕之后，就可以使用常见的SOA服务传输访问这些Web服务。任何希望使用服务的新应用程序或新客户端从服务库中获得描述。业务流程引擎（通常称为编排引擎）还可以在把Web服务设计和开发为自动流之后再访问它们。
图1
使用Web服务成功实现面向服务的集成方法的业务通常比那些没有成功实现的业务具有一项竞争优势，因为与那些IT系统依赖于某项特定技术的业务相比，服务与战略IT业务目标一致的业务可以对不断变化的业务需求做出更快的反应。
SOA的概念并不新鲜，但是Web服务的新颖之处在于混合和匹配执行环境的能力，把服务接口和执行技术分离开来，允许IT部门为每个任务（新的或现有的应用程序）选择最佳的执行环境，并使用一种一致的架构方法试着把它们组合在一起。
实现SOA
一旦您决定了让IT系统转向面向服务和在Web服务中使用SOA的方向，您需要确定达到这个目的的最佳方式。即使您是WebLogic/J2EE方面的专家，Web服务仍然是实现SOA的最佳手段，因为它们基于一组技术标准，而这些标准独立于任何特定的软件域、开发流程或设计方法。因此，Web服务具有从根本上扩展WebLogic平台的应用范围的潜力。
BEA WebLogic可以很容易地用作设计中心和用于在需要时开发新代码。它还可以用于使用Web服务把各种不同的现有系统组合到一起。当通过Web服务接口公开现有系统时，可以很容易地把它们组合到功能强大的业务流程流和新的应用程序中。
可以以各种方式应用Web服务来解决许多问题。SOA带来了架构前景、开发指导方针和设计方法，它们都增大了以战略方式应用Web服务，通过灵活性和重用为企业增加长期价值的可能性。
图2说明了在多渠道访问同一个应用程序的Web服务中使用SOA的独特优势。在这个例子中，一个现有的客户服务应用程序就是一个Web服务，它是使用基础架构产品来启用的，帐户管理人员的手机、客户的移动设备、客户服务管理人员的笔记本电脑、呼叫中心操作人员的PC和转售者的服务应用程序，都把它当作一个可重用的服务进行访问。联合使用WebLogic和支持Web服务的程序（比如Atrix）可以把现有应用程序的应用范围扩展到新的应用程序和设备。Web服务有助于提高灵活性，因为可以跨多个业务流程设计和重用它们，这样的话，任何人可以在任何时间、任何地点使用任何设备访问它们。当根据持久性业务主题设计和实现Web服务，而不是与特定实现紧密耦合时，Web服务是可重用的。
图2
长远价值
当可以通过分解现有服务完整地或几乎完整地开发新的应用程序时，SOA的实际价值来自部署的后期阶段。当可以在可重用服务的现有集合之外组装新的应用程序时，可以实现工作的最佳价值（即花费最小的代价和时间获得结果）。但是要做到这一点，还需要一些时间，并在服务开发方面大量投资。
更加可能出现的情况是，在一些可重用业务服务（比如订单项、检查信用卡授权、流程清单，等等）和一些（数量可能比前者小）特别为应用程序开发的定制服务（比如帮助客户决定购买廉价书籍）之外构建新的应用程序。公司客户的在CORBA中使用SOA的现场经验表明，重用程度可以达到70%，而且行业在使用Web服务的时候达到的重用程度可能与前者持平，或者可能更高。
一般来说，理解重用常见业务服务，比如客户名称查找、ZIP代码验证或者信用检查，的优点十分容易。在称之为面向每个服务的开发环境中，可以由可重用代码库或被加载/链接到新应用程序中并进行重用的对象来执行这些功能（尽管有重复）。在基于SOA的应用程序中，像这些常见的功能，以及像安全性检查、事务协调和审计这样的典型系统功能却是使用外部服务来实现的。使用应用程序外部的服务不仅可以减少要部署的代码的数量，而且通过集中已部署的代码并管理对它的访问，还可以减轻管理、维护和支持的负担。
一种新的开发方法
正如许多读者所熟知的那样，软件行业已经广泛采用面向服务的开发范型作为在应用程序集成过程中利用Web服务的功能的最佳方式。然而，有一点需要清楚，对前面的面向对象、面向过程、面向消息和面向数据库的范型来说，面向服务的开发实际上是一种对它们形成补充的新方法。面向服务的架构已经不是新事物，但是它作为任何可执行软件系统的抽象Web服务层的用途是新事物。因此，当面向服务应用于被映射为以前这些技术中的任意一种或全部的统一服务抽象时，它是作为一种需要被理解和采纳的、重要的新开发模型而出现的。
开发服务和开发对象不同。服务是由它使用与其他服务交换的消息进行共享的数据来定义的，而不是由常见方法/参数签名的定义进行定义。定义服务的抽象层次必须比定义对象的高（有些人可能说是在最低的一般水平），因为服务定义被映射为面向过程的语言，比如COBOL或PL/I，或者是消息排队系统，比如JMS或MSMQ，面向对象的系统除外。因为Web服务需要能够跨所有这些技术域进行操作，它的开发要求进行一些研究，或者以新的思维方式进行思考。
在开发端，必须了解定义服务的粒度。Web服务通常需要一个粒度较大的、在一次调用中接受的数据比对象多的接口。然而，借助Web服务，可以创建一个Web服务的聚合，以便发布的Web服务封装多个其他的Web服务。这允许把一个粗粒度的接口分解为多个细粒度的服务。粗粒度的服务可能在发布时更有意义，而细粒度的服务在作为只能被粗粒度的Web服务调用的“私有”Web服务时更有意义。
图3说明了对SOA使用Web服务的另一个主要优点：创建复合应用程序的能力。WebLogic平台显示在图的左边，可用于访问图右边的Web服务，这些Web服务代表使用新的Java代码开发的服务和使用其他技术开发的服务的混合体。客户记录（customer record）服务公开了两个由其他服务组成的服务。
图3
在项目层次上，架构师必须纵观开发可重用服务的全局，并给出一种方法，用于在需要服务的时候和地方保存、管理和获得它们。可重用的服务层把业务操作，比如 “获得客户”或“下订单”，和各种底层软件平台实现隔离开来，就像Web服务器和浏览器把WWW和各种操作系统和编程语言隔离开来一样。可重用服务可以被分解为较大服务的能力为企业带来的是流程自动化的优点，以及及时对不断变化的情况做出响应的灵活性。
开发SOA
基于Web服务开发一个易于理解、管理和部署的SOA对象必须分为两个行为阶段。这两个阶段的中心任务是标识服务，这些服务必须是：
· 使用新的执行环境开发的：要求以Java类和EJB的形式开发新的应用逻辑，以在WebLogic应用服务器容器中运行。
· 支持现有的应用逻辑：要求使用适合于现有技术的、支持Web服务的工具集，要么使用Web服务调用直接集成，要么使用WebLogic集成服务器间接集成，或者同时使用这两者。
要在SOA中包含所有Web服务端点，可能需要使用工具组合。例如，IONA的Artix可以用于对TIBCO、MQSeries、CICS、IMS、CORBA和其他现有系统启用Web服务，并与使用WebLogic开发的新逻辑进行集成。另外，Web服务功能可以存在于这些产品的更新版本中，而且通过把现有软件安装或升级为支持Web服务的更新版本来公开或启用现有的应用程序，然后再使用它们，这十分有意义。然而，由于多个Web服务实现之间可能存在不兼容的情况，以及管理多个Web服务产品的复杂性，这种方法显得十分脆弱。
通过独立厂商和开源项目可以获得各种支持Web服务的工具集。因此，在您的SOA实现中，一个主要的决定是处理将要涉及到的技术组合。在企业范围内的SOA项目中，使用几种不同的、通常差别很大的技术是很经常的事情，这些技术提供的服务质量也各不相同。
在为SOA开发服务的过程中，首先您要决定您需要服务，然后把服务设计为与您正在开发的其他服务兼容。而且最后，如图4所示，您要决定，在针对可靠性、安全性和事务的额外服务质量要求中，您到底需要哪些。有一点是必要的，即检查您使用的Web服务产品，以确保不仅在基本的SOAP和WSDL层上是兼容的，而且在这些扩展功能的层次上也是兼容的。
图4
面向服务开发的起点是识别要共享的数据。这变成了要包含在消息中的数据类型和结构的XML Schema表示。Web服务提供两种基本的交互方式：
· 面向文档：消息被构造为“纯文本的”XML文档（换句话说，数据的格式只对XML有意义）。
· 面向RPC：消息被构造为一系列要传递给对象或过程方法的参数，通常与数据类型和结构匹配。
在第一种交互方式中，消息通常用于传输业务文档，比如购买订单、发票和提单。这种交互类型与同步消息排队系统的兼容性很好，比如MQ Series、MSMQ、JMS、TIBCO、IMS等等。它通常用于业务到业务的事务，因为这类事务依赖于交换大量要在一次可能需要花费数小时或数天的执行流中处理的数据，这将导致已执行的文档或新文档被传回给始发者。这种方式也是最为抽象的，因为它没有包含与用于在执行环境中映射消息的签名有关的任何描述。另一方面，面向RPC的方式假定消息中的数据由带有已定义接口的过程或对象来执行，而消息中XML的面向RPC格式用于使映射到或映射出这类现有结构变得更加容易。
然而，就像计算中的其他任何方面一样，可以通过多种方式完成同一个任务。大多数源自各种Web服务工具集和产品的互操作性问题，其产生的原因都是在映射复杂数据类型和结构（比如数组、记录和结构体）时的不兼容。换句话说，数据类型越简单，您实现互操作性的可能性就越大。
作为一条规则，Web服务产品的兼容性越高，它们的应用范围就越广泛。例如，WS-Interoperability Basic Profile建议使用文档和文字的编码风格（即纯文本的XML模式数据类型和结构），而不是SOAP编码风格（即从根本上定义与现有面向RPC技术不兼容的新数据类型和结构）。面向文档的交互方式比面向RPC的方式更加抽象，因为SOAP处理器和XML解析器提取出感兴趣的数据给应用程序，并将其传递给队列或对象。当消息的数据已针对RPC进行格式化时，关于参数中类型的知识对于解码和理解消息来说是必不可少的。
在设计和开发任何SOA的过程中，一个必需的步骤是找出对已扩展技术的需求。WS-Security, WS-ReliableMessaging和WS-Transactions已经在其他规范中给出定义，以解决此需求问题，但是它们在WebLogic和其他Web服务工具，以及到现有产品的Web服务接口中的可用性十分有限，而且跨扩展功能集的互操作性也是如此。您使用的扩展功能越多，实现互操作性的难度就越高。
面临的挑战
基于SOA的集成提供一种一致的方式来访问公司中以及可能位于公司外部的所有应用程序。由实现SOA所代表的挑战是，可能需要修改一些应用程序，以便使它们参与到SOA中。另外，第一次很难准确地给出可重用服务的定义。
采用SOA的最大障碍往往是确保进行充分的人员培训，以及实现SOA需要进行训练有素的长线投资这个事实。任何技术，无论它多么有前途，都可能被滥用和误用。必须着眼于长远利益来开发服务，而不能仅仅考虑眼前的利益。与对象或数据库不同，开发服务的目的是让客户使用它，但是当时可能不知道这一点。换言之，单独服务的存在并不具有很大的价值，除非它成为可以被多个应用程序消费的大型服务集合的一部分，而且可以在这个集合之外可以组装多个新的应用程序。任何服务集合都需要控制、设计和架构目的，因为它们往往不是同时被开发的。
转向SOA的主要挑战是管理短期成本。构建SOA并不便宜；重构现有的系统需要花费资金，而随着时间的推移，回报会变得越来越大。它需要业务分析员，以定义业务流程，需要系统架构师，以把流程变为规范，需要软件工程师，以开发新的代码，还需要项目经理来管理以上所有工作。
当然，当服务可以用于首先解决战略问题时，逐渐多地在SOA具有最大业务影响的地方采用和利用它可以抵消这些成本。因此，采用Web服务和SOA的一部分工作是，不仅要识别那些通过快速解决问题而快速返还价值的项目（比如集成J2EE和.NET Framework应用程序），而且要通过重用为实现未来的战略价值打好基础，比如更加快速地创建一个新的订单项应用程序，因为它可以重用用于信用检查和记帐的服务。
实现SOA前景的另一个挑战是，当前的应用程序是紧密耦合的，而底层的SOA技术却是松散耦合的。因此，在紧密耦合的业务关键型应用程序的现有环境中，不可能——至少不能以一种高性价比的方式——马上实现完美的松散耦合。可能有必要从细粒度的、紧密耦合的Web服务开始，以满足即时项目的需要，但这只应该在整个长期计划的环境中进行，以开发封装了细粒度服务的粗粒度服务。
结束语
所以，如果您想要在WebLogic环境中基于Web服务构建SOA，而且这是您和您的IT部门正面临的任务，那么恭喜您，您可以完成这个任务。有了正确的期望、战略、规划和执行，您现在就可以开始让您的企业转而利用这种计算技术，在现在和将来都可以取得喜人的效果。有一点很重要，即考虑需要新Java代码的和公开现有应用程序功能的这两种Web服务之间的差异。联合使用WebLogic和企业Web服务基础架构产品可以帮助扩展基于WebLogic的SOA项目的应用范围，具体方法是基于现有的应用程序代码更加轻松地处理Web服务，而不论是在大型主机、Unix还是已建立的中间件系统上。
