SOA
最近以来，在企业级应用开发领域，谈论最多的一个词，恐怕非SOA(Service-Oriented Architecture，面向服务架构)莫属。那么SOA究竟拥有什么样的魔力，能够让众多的软件厂商对他趋之若骛，掀起新的一轮企业架构浪潮。让我们在本文中一探SOA的究竟。
什么是SOA？
对于什么是SOA，不同厂商或个人对SOA有着不同的理解。但是我们仍然能够从各种不同的定义中归结出SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。（至于什么是SOA，可参见本人写的另外一篇文章，SOA Notes）。
从软件技术角度来看，SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
从其它的角度看， SOA并不是一种现成的技术，而是一种架构和组织IT基础结构及业务功能的方法。SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。这一定义阐明了SOA的范围。
SOA 方法是在在有力地加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离，关注点分离）的基础上，演化而来的。绝对不是有那么一群软件开发设计者在某一天的凌晨醒来，并发现以前我们一直用着错误的方式构造软件系统，因此，他们找到了一种新的、可靠的方式，那就是SOA。绝对不是这样的！！！
SOA的动因
SOA 方法不是软件领域的革命，而是使开发者远离底层机器细节的持久进步中顺其自然的一步，从Code-Fix，到结构化设计、OOAD、AOP、MDA….，软件开发设计方法一直在进行演化。其实软件危机的来源并不是我们在用错误的方法开发软件，而是我们的方法已经不足以应付我们所需解决问题的日益增加的复杂性了。在处于只有8条指令和1KB内存（而且这1KB内存中的90%还被监控程序—操作系统占据了）的年代，用八进制或十六进制编码来写程序是天经地义的，我们使用这种变成方式毫无障碍。因为只要记住8条指令，要写的代码也不过30行。而当硬件边得更加强健，我们开始遇到64K内存问题，这样一来记忆操作码就变德复杂，超出了我们的掌控能力。于是，我们开始用汇编语言助记符。汇编语言助记符非常棒，直到有一天我们的问题再次超过它能容忍的复杂上限。于是我们改用高级语言来编程。药剂语言的每条指令都能替换很多条汇编语言助记符，这样我们就能在更高层次上思考。
除了减少语言复杂性，我们也在寻找思考问题的更好方式。我们不是把一串串的指令塞进小的函数再把这些函数拼成程序，而是用一种结构化的方法开把问题分割成小的子问题，每个子问题的复杂性都在可管理的范围之内，………...。
目前，软件系统的开发又到了临界点，对于今天的硬件所能处理和用户需求所要求处理的问题的复杂性，目前的结构和设计方法已经不足以应付了。我们需要性的方式、方法和原则！
不久前软件开发界开始出现支持模型驱动的开发（Model-Driven Development，MDD）的产品，而 SOA 无疑通过业务驱动的开发（Business-Driven Development，BDD）向前迈进了一步。MDD 从最初以软件建模为中心转向了以软件架构师角色为中心。BDD 则更进一步，上升到了以业务建模和业务分析人员（business Analyst，BA）角色为中心。
从应用的角度，我们主要经历了从传统应用程序、分布式应用到Web服务的演化过程：
（1）传统应用程序
首先从计算机发明开始，当时给人感觉非常不错。计算机能执行奇迹般的任务，可实现很多手动工作的自动化，包括复杂的计算、财务工作等等很多其他任务。
但传统应用程序是“竖井”(Silo) 型的。人力资源应用程序无法与财务应用程序真正通信，而后者又无法和分布应用程序进行真正的通信。所有这些应用程序都有独立的领域，在独立的计算机上运行，尽管很有用，但并不能很好地在彼此间共享数据。当时可以选择对批处理流程进行连接，以将数据从一个系统移动到另一个系统，但这并不适合进行实时集成。
（2）分布式计算
在我们的进化链中的第二步是分布式计算。分布式计算允许不同的应用程序彼此进行通信（即使位于不同的计算机上也是如此）。CORBA、MTS 和 Enterprise Java Bean (EJB) 等技术提供了包含各种类别的注册中心的系统，因此应用程序可以找到其希望与之进行交互的组件，然后像调用本地的组件一样调用这些组件。
这些系统由可同时满足这两个要求的中间件（或更具体一些，面向消息的中间件）提供支持。现在能以特定的方式构建应用程序，即使位于不同的地理位置，也能访问其他系统上的资源。
但仍然有一个问题。虽然系统可以自由地与系统内的任何对象进行通信，但仍然是一个封闭的系统。至少，客户机应用程序必须与服务器应用程序使用相同的技术。另外，通常并不会将系统设计为从创建其的个体组织外进行访问。
（3）Web 服务
此进化链中下一个几乎不可避免的链接点就是 Web 服务。“Web 服务”基于 XML 和 HTTP（大多数情况下），对很多人具有不同的含义，但在此处，我们要将 Web 服务作为系统间基于 SOAP 的消息交换进行讨论。
这些消息由 XML 组成（XML 是一个基于文本的开放标准），可由来自任何应用程序（任何设计为接收此类消息的应用程序）的任何人进行访问。这就扩展了应用程序的范围，从而包含任何可通过网络对其进行访问的任何人。
相关基础知识
（1）XML
进行传递的所有这些消息都基于可扩展标记语言（Extensible Markup Language，XML）。如果完全不熟悉 XML，在深入了解各个 Web 服务主题前，真的应该进行一些相关研究。不过，以下提供了继续学习本教程所需的基本知识。
XML 是一种“标记语言”，即给出了一种提供实际内容的附加信息的方式。此信息以“标记”的形式提供，这些标记用于指示“元素”。
Web 服务是能够进行重用的功能构建块。必须由提供者系统使用标准协议和语义对其进行发布、查找（发现）和调用。这是使用具有不同语法和相关结构的 XML 进行的, WSDL、UDDI、SOAP等。
（2）WSDL
Web 服务描述语言（Web Services Description Language，WSDL）是一个 XML 实例文档，符合用于服务请求方和服务提供者之间的通信的 W
创建服务时，通常的原因都是因为希望其他人使用此服务。为了使用服务，需要知道向服务发送什么信息、服务将发送回什么信息以及在何处能找到此服务。当然，可以将这些放入字处理文档中，但相比之下，如果此信息采用标准的、最好为人机均可读的格式，则要有用得多。
WSDL 就提供了这样的标准格式。除了不会造成混淆不清外，其主要优势是，由于 WSDL 是事实标准，且采用 XML 格式，因而可由计算机进行处理，便于自动创建客户机（甚至自动创建服务的框架）。Classifieds Department 将要创建接受和管理 classified 广告的服务，以允许其他人（如作业聚合网站）能更方便地使用此服务，他们同样也将使用 WSDL 文件对其进行描述。
（3）UDDI (统一描述、发现和集成)
UDDI 基本上就是一个 Web 服务，但与 SOAP 和 WSDL 存在很大差异，最好在开始之前了解一些背景知识。
当所有应用程序都位于本地时，要找到所需的功能会非常容易。不过，使用 Web 服务之类的分布式系统时，您不能获得中央注册中心的好处。分布式系统也容易发生更改。而这正是 UDDI 的用武之地。它旨在用于两个目的。最初形成时，它被认为是一种“通用业务注册中心”。其想法是，企业可以使用以下三种方法之一搜索合作伙伴：
l “白页”：白页与电话簿中用于查找公司信息的白页类似。例如，如果您知道公司的名称，可以在其中查找公司的地址、如何进行联系，甚至还能够确定与组织中的哪个人联系。
l “黄页”：同样，黄页与电话簿中的黄页一样，可以在其中根据分类查找公司。UDDI 指定了各种分类法，以供各个公司用于对自己进行分类。例如，如果您在查找体育用具，则可以查找其北美工业分类系统（North American Industry Classification System，NAICS）代码为 339920 的公司。
l “绿页”：电话簿中没有绿页，但这里的想法是，公司可以使用此搜索方法来查找实现了特定服务的贸易合作伙伴。例如，可以搜索实现了使用邮政编码的距离计算功能的公司。
UDDI 同时也被认为是一种保持分布式应用程序长期运行的方法。其想法是这样的，可以缓存有关访问特定服务的信息，如果客户机崩溃，应用程序将自动回到注册中心并进行检查，以确定信息是否已更改。如果已更改，则可以直接在应用程序内进行更改（在理想的情况下将自动进行更改）并重试您的请求。
（4）SOAP (简单对象访问协议)
SOAP 规范是所有基于 SOAP 的 Web 服务的基础，详细说明了实际消息的格式。其中还详细说明了应用程序应如何对待消息的特定方面（如“Header”中的元素），从而可以创建特定类型的应用程序，使其中的消息在达到最终的目的地前在多个中间层之间进行传递。
SOAP 是用于在网络上交换基于 XML 的消息的协议。通常，使用 HTTP 作为传输协议，但也可以使用其他协议，如 SMTP 等。
通用 SOA 指导方针
l WS-I：您使用的协议应与 Web 服务互操作性（Web Services Interoperability，WS-I）标准兼容。HTTP、SOAP 和 JMS 都是此类兼容消息传递基础协议。
l WS-BPEL：您的业务流程应该通过 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，WS-BPEL）定义。其名称很长，但此标准对于以跨产品的方式记录您的流程非常必要。
l WSDL：正如上面所说的，WSDL 定义 Web 服务如何工作。
l UDDI：使用 UDDI 时，它将对 Web 服务进行注册，以便使用者能够查找服务。
l SOAP： SOAP 是用于按照其 WSDL 文件的定义在网上进行基于 XML 的消息传递的协议。
l WS-Security：此规范处理加密和数字签名，允许创建特定类型的应用程序，以防止窃听消息，且能实现不可否认功能。
l WS-Policy：此规范对 WS-Security 进行了扩展，允许更具体地说明谁可以采用何种方式使用服务。
l WS-Coordination：定义了在Web服务之间发生的任何事务处理的底层基础 ，用来定义注册Web服务以及协作Web服务来参与事务的机制。用于建立上下文环境，用来执行和管理参与事务的不同Web服务单元。
l WS-Atomic Transaction: 用于处理事务的短期操作，实现事务的ACID特性。定义了分布式事务的两段提交协议，在两种资源之间达到同步以确保资源的一致性和完整性。
l WS-Business Activity:用于处理长期运行的事务，处理事务场景。
SOA 相对较新，但已经有了一些建议方法。这些方法经常是其他现有方法的组合和扩展。这样很好——重要的是有流程和技术可遵循。我们将向您介绍一些建议的 SOA 方法。
l 服务体系结构方法 (Methodology for Service Architectures)：（Jones，2005 年）重点在服务发现上，提供了此方法的概念。此方法的重点在最早期的 SOA 开发活动上。
l 面向服务的建模体系结构（Service-Oriented Modeling Architecture，SOMA）：根据 Ali Arsanjani的说法，“面向服务的建模方法提供了用于定义 SOA 基础的建模、分析、设计技术和活动。它可帮助在每个 SOA 层次定义元素和进行每个级别的关键体系结构决策。为了达到此目的，它结合使用了自顶向下、业务驱动的服务标识和通过利用现有资产和系统进行服务标识的工作流。”
l 面向服务的分析和设计（Service-oriented analysis and design，SOAD）：Zimmermann 这样描述 SOAD 方法：“该 SOA 方法强调了已确立的通用软件体系结构原则，如信息隐藏、模块化以及关注点分离，同时还添加了其他主题，如服务编排、服务存储库以及服务总线中间件模式，这些问题显然需要在建模期间加以注意”。此方法包含业务流程建模（Business Process Modeling，BPM）和面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD），对其进行了扩展，以标识服务和同步 BPM 与 OOAD 构件。此方法处理了 WS-BPEL 和 WSDL 之间的划分，还讨论了其他主题，如提供高服务质量（Quality of Service，QoS）等。作为一名老 OO 建模人员，我非常熟悉 OOAD 技术，包括 UML。SOAD 认为 OOAD 对 SOA 而言紧密耦合程度仍然太高，太过于细粒度，因此将其作为更为细粒度的层次使用。SOAD 主要关注业务级别的高级问题，如业务流程等。由于开发工作变得更为详细，因此使用了现有的面向对象的技术。SOAD 包括 SOA 特定的主题，如：
l 服务类别和聚合
l 策略与方面
l 中间相遇流程
l 语义代理
l 服务收集和知识代理
l 面向服务的建模 (Service-oriented modeling)：Mark Endrei 则从业务分解入手；业务分解的任务是标识用例和流程（当用例和流程进入设计阶段后，将使用系统用例和子系统来支持所标识的流程。随后将使用业务用例来标识服务。
l 敏捷性面向服务建模 (Agile service-oriented modeling)：Pal Krogdahl 的重点在于建模业务服务以及将业务流程连接到服务。他的方法是以 Zimmermann 和 Arsanjani 的成果为基础。他增加了将敏捷性方法应用到 SOA 的讨论。
面向服务的原则
有必要讨论一下 SOA 所基于的主要原则：
l 松散耦合：服务必须注意到彼此的存在，但位置、版本和实现的更改应该为透明的。Spring 之类的框架就是松散耦合的，基于声明性配置文件的连接和面向方面的交织，但 SOA 使得松散耦合达到了另一个境界。在 SOA 中，ESB之类的机制可以在不涉及客户机逻辑的情况下适应更改。ESB企业服务总线（Enterprise Service Bus，ESB）是集成组织的各个系统的企业级通信机制。它支持请求方与提供者之间跨网络进行事件驱动的消息传递，同时提供了身份验证和事务管理等服务。服务可以采用 .NET 框架或 J2EE 平台；协议可以为 HTTP 或 JMS；平台可以是 UNIX 或 Windows。
l 契约接口：WSDL 是定义 Web 服务的接口的标准方法，应该用于描述所有 Web 服务。
l 可重用服务：可重用性具有多个特征，包括抽象和耦合。服务应该定义为尽可能小，但同时仍然能为完整业务功能提供支持。如果您添加更多的功能，服务的可重用性就会减弱，因为能够与其协同工作的其他服务的数量就会减少。请考虑定义原子服务。
l 自描述服务：为了进行重用，必须能够找到组件。尽可能使用业务分析人员能够理解的术语。提供丰富的描述。使用全面描述 Web 服务的 WSDL 文件。
l 无状态性：服务不应在调用之间保持状态。应该设计为重入，从而避免在处理并发请求时出现问题。Artus 对服务为何需要无状态的相关问题进行了讨论。基本原因是什么呢？有状态服务的可重用性低。
但是在具体项目的实施过程中，应当根据项目的实际情况灵活运用这些原则，但是必须将采用已得到多数认可的“面向服务的原则”，将这些原则落实到详细设计之中，并遵照上述设计思路形成面向服务的设计文档。例如，某SOA项目将遵循的原则是：
l 服务应是“可复用”的。不论是否存在立即复用的机会，都要把服务设计成在将来是可以被复用的。
l 服务应共同承担一定形式的契约。服务应遵守共同的契约来实现彼此之间的交互，该契约对每个服务进行描述，并定义实现信息交换的条件和方法。
l 服务应是“松耦合”的。服务之间无需紧密的依赖就能进行交互。
l 服务应隐蔽其内在逻辑。外部所能见到的，只是服务的对外接口，即通过服务契约向外部暴露的那一部分信息。除了接口之外，内在逻辑等任何信息都是不可见的。
l 服务应是“可组合”的。几个服务可以被组合成一个新的服务，因而服务所代表的逻辑可以有不同的“粒度”。
l 服务应是“自主”的。一个服务所控制的逻辑有一个明确的边界。该服务具有在该边界之内的控制权，且实施这种控制并不依赖于别的服务。
l 服务应是“无态”的。不要让服务去管理状态信息，要把服务设计成是无态的，哪怕它要服从别处的状态管理。
l 服务应是“可被发现”的。应使服务的描述能被人和可能要用到它的其它软件发现和理解。
SOA平台
SOA平台是SOA基础设施的简称，是基于SOA的信息化系统的核心组成部分。SOA平台主要构成可分为五个部分：企业服务总线（ESB）、服务编排或业务流程执行语言的实现（BPEL）、服务注册中心（UDDI registry）、服务描述语言的实现（WSDL）以及消息传输处理（Messaging Transport）。其中每个部分大致都可分为核心层、辅助层、工具层。SOA平台的核心层主要指各部分的基础支持模块，如引擎等，SOA平台的辅助层主要是各部分核心层的扩展，SOA平台的工具层由为核心层和辅助层提供的各种可视化定义工具组成。
SOA的安全
l 可以从识别、认证、授权、机密性和完整性五方面来设计SOA平台安全的相关功能组件、服务。识别和认证由门户（单点登陆）服务来实现。机密性和完整性分别关注消息内容的机密保护、消息传输从头至尾未被改变。
l SOA安全的另一部分为数据安全，包括Web Service组件、Web Service、SOAP身份验证、HTTP身份验证、JAX-RPC客户端五种安全组件的开发，来保证SOAP消息、Web Service的安全。
l 在传输级别上，可以采用安全套接字（SSL），它是HTTP通道的安全方法，但是它保护的是两个服务端点之间保护信息，适合点对点的保护。在消息内容上的安全采用加密
