介绍在前面的文章中我写了篇关于Web Services的，其实本人对这分布式领域是十分感兴趣的，今天，我将概要地写个关于SOA（面向服务的架构）的文章，文章可能不是很细，但是比较适合作为入门的学习资料，希望大家能喜欢。下面我将逐节进行SOA的介绍。 什么是SOA？SOA的全称是Service Oriented Architecture，即面向服务的架构。在定义SOA之前我们先看看服务（service）的定义。在现实生活中，服务指的是我们支付后而获得的服务内容。例如：去酒店吃饭时点菜的服务内容，首先客人走到柜台点菜，然后厨房将为客人准备食物，最后服务生上菜给客人。在这个过程中，柜台点菜、厨房做菜以及服务生上菜这三个部分分别就是服务，如下图所示：
图1 酒店的服务 所以，当你在酒店点菜时，你需要上述的三个服务一起协同工作。 和上面的例子相似，软件世界中，服务的内容将变为业务服务（business service）。它们的逻辑是自包含（self contained）的，所以下面我们将定义业务服务。 业务服务的定义：业务服务是指将自包含的业务功能在逻辑上进行的封装，封装的结果就是业务服务。 例如：下面的图中显示了简单的订货系统“order system”，它是通过将支付网关（payment gateway）、存货系统（stock system）和发货系统（delivery system）三个服务组合后实现的。所有这些服务都是自包含的。它们就像一个黑盒，我们不用理解这些业务服务的内部实现细节，对于外部世界来说它只是个黑盒，只用关心消息的接收和进行服务。例如：支付网关（payment gateway）中，业务服务将接收消息检查信用（check credit），然后输出客户是否有信用凭证。对于“order system”来说，业务服务支付网关（payment gateway）就是一个黑盒。
图2 简单订货系统 在理解了上边的内容后，让我们先理解一些SOA的基本内容，最后我们将给出SOA的定义。 （1）SOA组件是松耦合的：当我们说松耦合，指的是每个服务是自包含的，只出现在单个的逻辑中，例如：上例中所示的支付网关（payment gateway）服务，它可以用在别的系统中。 （2）SOA服务是黑盒的：SOA服务隐藏内部的复杂性。它们只通过消息和基于这些消息发送的服务进行交互。这样的设计使得松耦合成为了可能。 （3）SOA服务应该是自包含的：SOA服务应该是明确的，能够自我进行定义的。 （4）SOA服务应该在列表中进行维护：SOA服务应该在一个中心的服务库中进行维护。应用程序可以查找到这些服务然后进行使用。 （5）SOA组件可以按照一定顺序进行组合和连接以实现特定的功能：SOA可以实现一种即插即用的服务方式。例如：下面的图中显示了两个服务“Security service”和“Order processing service”。你可以按照以下的顺序实现自定义的功能，即可以先对用户进行检查然后在进行订单处理，也可以翻过来。通过SOA我们可以以一种松耦合的方式安排服务的工作流程（work flow）。
图3 服务的组合 下面我们来定义SOA吧。SOA是一种架构，它通过将服务进行组合和连接来建立具有特定功能的商务应用程序。其中服务之间是松耦合的，对外界就像一个黑盒，隐藏了内部的工作方式。 SOA的系统建立方式如果你需要集成已存在的系统，将它作为一个业务服务的话，那么你只需要对你的系统建立一个松耦合的包装，它将封装你的系统，然后以一种通用的方式向外界展示自己的系统的服务。 SOA的业务层（business layers）和管道层（plumbing layers）在SOA中采用了两层架构，首先一层直接与业务相关，因为它实现了业务功能。第二层则是技术层次，该层将管理计算机资源，例如：数据库、web服务器等等。这样的划分需要识别服务，考虑下下面的图“Simple order system”。它包含了很多组件，组件之间通过进行通信来完成订货系统的功能。 这个简单的订货系统可以被划分为两层，如下图“business and plumbing layer”所示，其中一层是与业务相关的，另一层则是与技术相关的。你可以看到管道层（plumbing layer）包含了数据访问层，Ajax以及众多的技术点。
图5 business and plumbing layer SOA中服务（service）和组件（component）有什么不同？服务是组件的逻辑分组，通过将组件进行逻辑上的分组从而实现了特定的业务功能。组件是实现服务的方法。组件可以使用JAVA、C#、C 实现，但是服务将以一种普遍的方式提供，例如：web services。 SOA的总体架构下图“SOA架构”显示了SOA的完整视图。请注意的是，这幅图并不与特定的实现绑定，它不是单独指Microsoft的实现或者IBM的实现。它只是一个通用的架构。任何要实现SOA架构的公司都要实现下面的SOA组件。
图6 SOA架构 SOA的首要目标是实现与其它独立的系统的连接。为了使各个系统可以协作，它们之间将互相发送消息（Message），ESB（Enterprise Service bus）企业服务总线就像一个稳定的邮局，它保证了系统之间的消息以一种松耦合的方式进行传递。ESB是一个特殊的层次，它只负责系统之间的消息发送。在上面的图中我们，我们显示了一个管道，它并不是什么硬件或者管线，它只是一组软件组件，这些组件将帮助发送和接收不同系统上应用程序的消息。不要自己去编ESB，你可以去微软、IBM、Oracle去买一个。下面我们将针对上图进行一定解释。 SOA registry：它就像一个服务的数据库的引用，描述了每个服务能做什么，它们在哪里可以获取到以及它们之间怎么进行通信。它是一个服务元数据的中心引用集合。 SOA workflow：它允许我们使用SOA registry中的服务定义工作流程。 Service broker：它读取工作流程的定义，然后将服务和流程进行绑定。Service broker其实通常是一个中间件，像EAI（Enterprise Application Integration）产品，你可以从微软、IBM或者SUN公司查到相关产品信息。 Process manager：它是SOA registry, SOA workflow and service broker的集合。 SOA supervisor：它保证了服务的质量，主要关心的是服务的性能的指标，如果某个服务的性能出现了问题它将会发送适当的消息。 注意：上面的解释只是一个基础的SOA架构，任何的公司，例如MS、IBM或者Sun的产品都应该包含上面的组件或者以其它方式实现。所以如果大家感兴趣，不妨可以动手实践一下某个产品来加深理解。 SOA的实际例子下面的图中显示了显示中SOA的例子，有大家熟知的Web Service、Biz talk和XML。
图7 SOA现实例子 终端（ends）,约定（contract）,地址（address）和绑定（bindings）的概念上面的这些术语是SOA支持的，每个服务必须提供一个或多个终端，通过这些终端服务可以由客户进行访问。终端包含了三个重要的部分：where，what和how： Contract（what）：约定是两方或这多方之间的约定。它定义了客户如何与服务进行通信的协议。从技术角度而言，它描述方法的参数和返回值。 Address（where）：一个地址说明了在哪你可以获取服务。地址是一个URL，它指向了服务的位置。 Binding（how）：绑定决定了终端以什么方式可以访问。它决定了通信是以什么方式完成的。例如，你提偶那个了服务，服务可以通过在HTTP上使用SOAP协议或者TCP传输BINARY（二进制）的方式访问。所以，对于每个通信方式，绑定都是必须的。 下面的图中显示了终端的三个主要组件。你可以看到stock tiker是服务的类，它放在www.这个地址上，可以通过HTTP或者TCP的绑定使用StockTicker接口类型。
Web Services和SOA的区别SOA是一个概念上的想法，它只是一个架构性的概念，而Web Service则是SOA的一个技术上的实现方法。而现今web service也是一个很受欢迎的实现SOA的方式。关于web service，如果大家感兴趣可以阅读我写的相关文章。 总结今天我从概念性的讲解了SOA的架构，讲解的不算是很完善和有条例，希望大家能理解，如果出现了什么错误，因为本人也是初学者，希望大家能给出意见，多多指点，谢谢！ [转载] 资源 |
|
|
