引:面向服务的体系结构(Service-Oriented Architec-ture，SOA)是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台
什么是面向服务的体系结构(SOA)?
面向服务的体系结构(Service-Oriented Architec-ture，SOA)是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性;另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而与此相对，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合系统的需求来源于业务应用程序需要根据业务的变动变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需(On Demand)业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA系统原型的一个典型例子是通用对象请求代理体系结构(Common Object Request Broker Architecture，CORBA)，它已经出现很长时间了，其定义的概念与SOA相似。
然而，现在的SOA已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言(eXtensible Markup Language，XML)为基础的。通过使用基于XML的语言(称为Web服务描述语言，Web Services Definition Language，WSDL)来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA中的接口描述语言(Interface Definition Language，IDL)可比了。
Web服务并不是实现SOA的惟一方式。前面刚讲的CORBA是另一种方式，这样就有了面向消息的中间件(Message-Oriented Middleware)系统，比如IBM 的MQSeries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间关系的策略，这种策略常常采用服务级协定和操作策略的形式。
最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何SOA中都起着重要的作用。
我可以用面向服务的体系结构做什么?
对SOA的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足系统之间交互的需要。
下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用WSDL接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。
另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店(Store-in-Store)的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到SOA模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的SOA模型得出的。这是来自SOA模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。
在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题，而不是从应用程序和编程的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。
正如您可以看到的，在这里，改变和SOA系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的，以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是决策对SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起。这种方式已经有十多年的历史了，通常用统一建模语言(Universal Modeling Language，UML)，并且描述成模型驱动的体系结构(Model-Driven Architecture，MDA)。
构成SOA的技术是什么?
SOA本身应该是“如何将软件组织在一起”的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。您还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。
SOA服务和Web服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web服务在需要交互的服务之间如何传递消息有具体的指导原则;从战术上实现SOA模型最常见的方式是通过HTTP传递的SOAP消息。因而，从本质上讲，Web 服务是实现SOA的具体方式之一。
尽管我们觉得 Web 服务是实现SOA最好的方式，但是SOA并不局限于Web服务。其他使用WSDL直接实现服务接口并且通过XML消息进行通信的协议也可以包括在SOA之中。正如在别处指出的，CORBA和 IBM的MQ系统通过使用能够处理WSDL的新特征也可以参与到SOA中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。
既为了建立所有这些信息的适当控制，又为了应用安全性、策略、可靠性以及会计方面的要求，在SOA体系结构的框架中加入了一个新的软件对象。这个对象就是企业服务总线(Enterprise Service Bus，ESB)，它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。虽然ESB并不是绝对必需的，但它却是在SOA中正确管理您的业务流程至关重要的组件。ESB本身可以是单个引擎，甚至还可以是由许多同级和下级ESB组成的分布式系统，这些 ESB一起工作，以保持SOA系统的运行。在概念上，它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。
从开发人员的角度来说，他们使用的工具必须知道 SOA的能力，并允许开发人员有效地使用SOA对象。这将把设计SOA模型、开发服务和服务对象以及测试 SOA应用程序这些过程包括进来并组成一个整体。因而，开发人员的工作必须为面向服务的应用程序设计/开发(Service-Oriented Application Design/Development，SOAD)做好准备。
SOA与其他技术的关系如何?
SOA可以与许多其他技术结合在一起使用，然而，组件的封装和聚合在其中扮演着重要的角色。如前所述，SOA可以是一个简单对象、复杂对象、对象集合、包含许多对象的流程、包含其他流程的流程，甚至还可以是输出单一结果的应用程序的整体集合。在服务之外，它可以看作是单个实体，但是在其自身中，它可以具有任何级别的复杂性(如果必要的话)。出于性能方面的考虑，大多数SOA服务并没有下降到单一对象的粒度，并且更适合于大中型组件。
除了可能离不开XML和WSDL之外，SOA并不是特定于语言的。可以用任何编程语言来实现服务，只要这种编程语言可以生成服务并且可以与WSDL结合在一起使用就可以了。SOAP本身并不是绝对需要的，但它是通用的消息传递系统。因此，可以使用几乎任何一种编程语言和支持WSDL的平台来实现SOA中的成员服务。
基于通用对象请求代理体系结构(Common Object Broker Request Architecture，CORBA)的应用程序有许多组件必须连接到 SOA 中。虽然 CORBA 中的接口描述语言(Interface Description Language，IDL)在概念上类似于WSDL，但它不是严格的，因而首先需要将其映射到WSDL。另外，需要使用更高级的 SOA协议(比如用于流程和策略管理的协议)，而不是CORBA中的类似的概念。请记住，这是CORBA组件(表示为服务)需要与SOA服务交互的情况;在 CORBA模型中，所有的独立子集仍然可以像以前一样工作。
由对象管理组织(Object Management Group，OMG)提出并在许多IBM Rational产品中得以实现的模型驱动体系结构在一个更抽象的层次上与SOA的概念具有很强的相关性。MDA基于这样的概念，任何软件流程都可以定义为模型甚至是元模型(即模型的模型)，然后可以将这些模型和元模型转换成应用程序的实际组件。因此，MDA创建了一个模型，这个模型先编译成软件应用程序，而软件应用程序接着又编译成可执行程序，这样就可以在平台上运行了。MDA并不区分服务和对象这两个概念，但是它确实允许模型由其他子集模型本身组成，这类似于BPEL(SOA的一个核心组件)中的流程聚合的概念。
SOA和Web服务是独立于编程语言的，但Java是主要的开发语言之一。可以使用定义良好的Java接口以及各种协议丰富的Java实现为正在构建这个模型的开发人员提供了优势。Java在此担当了开发每个服务的功能、管理数据对象和与其他在逻辑上封装在服务内的对象进行交互的角色。
SOA与Web的另一个重要的关系是自主计算和网格计算的概念。自主计算的概念应用于管理分布式服务体系结构的范围，具体来说，就是帮助维护策略和服务级协议以及SOA系统的总体稳定性。
另外，网格计算可以以两个级别与SOA系统一起使用。网格是分布式计算的一种形式，它利用分布式特性和服务之间的交互来为SOA应用程序提供计算支持。在这种情况下，网格起到了框架的作用，其中实现了一些或所有单独的服务。因此，SOA应用程序可以是网格服务的消费者。
在另一方面，网格本身也可以构建在SOA之上。在这种情况下，每个操作系统服务都是构成整个SOA应用程序的成员，而SOA应用程序就是网格本身。因此，单独的网格组件既可以使用Web服务进行通信，又可以以SOA的方式进行交互。总而言之，网格系统可以是SOA本身，也可以提供服务来在其上构建应用程序级SOA模型。
如何构建SOA系统?
利用SOA的好处不仅仅在于它是一个软件开发流程，而且还是一个业务开发流程。采用SOA有四个层次，您的实现可以跨越从创建特定的软件服务到将您的业务模型全面转换到按需系统的过程。
第一个层次是最简单的，因为它只需创建单独的服务。
在第二个层次中，您不仅可以创建服务，而且可以开始将业务功能集成到SOA中。这涉及多个层次的集成，其中包括应用程序集成、信息集成、流程集成和整个系统的集成。
第三个层次涉及将您的企业IT基础设施转换到 SOA模型，而采用SOA的第四个层次集中于转换您的业务模型，以使之成为随需应变的模型。
从IT专业人员的角度来看(与业务层相比)，要创建SOA应用程序，您通常将经历四个阶段：构建、部署、使用和管理。在构建阶段中，您可以定义业务模型或流程、软件模型和SOA模型。之后，您就可以创建一组服务，这组服务可以与已发布的通用接口一起重用。
在部署阶段，您提取创建的服务，并把它们放在一个可执行、可管理的环境之中。在使用阶段，您根据前面所讲的SOA和软件模型来装配应用程序，并且测试其软件质量以及非功能性需求，比如性能、可伸缩性等等。应用程序现在已经准备完毕并且可交付用户。最后的管理阶段是一个长期的过程，在这个阶段中，您可以监控并管理安全性和使用，以及在许多与您可能已经为 SOA制订好的服务级协定或策略相对应的方面比较其性能。
这些是SOA的生命周期的概念阶段。为了使对应于这些阶段的实际工作角色具体化，有许多角色需要加入到SOA应用程序的创建之中。这些角色可能从事相同的工作，也可能跨多个团队成员甚至多个团队。在 Rational Unified Process(RUP)中所划分的角色非常好地表达了角色概念。
如何提高我的SOA技能?
技能的获取取决于您是一个什么类型的专业人员：信息分析员、软件架构师、软件开发人员、软件质量分析员、系统管理员等等。如前所述，SOA的概念跨越所有这些工作角色。因此，理解每个工作角色所起的作用是非常有帮助的。
接下来，您应该熟悉每个角色中所包括的技术概念。信息分析员和软件架构师应该熟悉模型驱动的体系结构(Model-Driven Architectures，MDA)和UML 2.0。软件开发人员和程序员应该了解Web服务的程序化接口、MQ和其他协议、程序化地保护交互的方式以及工作流处理的概念。质量分析员和系统管理员应该理解 SOA流程模型与实际SOA功能性体系结构实现，以及分别开发单独的服务如何影响这样的分布式应用程序的整体性能。系统管理员还应该知道应用程序安全性和信任模型如何工作，以及应用程序使用策略如何影响操作系统平台和网络系统。 |
