面向服务的体系结构SOA.docx
《面向服务的体系结构SOA.docx》由会员分享，可在线阅读，更多相关《面向服务的体系结构SOA.docx（16页珍藏版）》请在冰豆网上搜索。
面向服务的体系结构SOA
面向服务的体系结构
面向服务的体系结构（Service-OrientedArchitecture，SOA，也叫面向服务架构）是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。
SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
从计算模型上讲，软件服务是SOC/SOA的基本实体，较对象、构件又有了新的发展，具有较高的抽象级别、更大的粒度与更强的独立性与可用性，更加便于使用者直接使用。
在此基础上，基于软件服务的SOC/SOA借助了开放的社会系统中较为成熟的基于服务的松耦合运营模式的理念，以服务为基本单元封装各类网络资源，以服务集成为基本手段提供开放环境下的资源共享与集成的高层次抽象模型，以服务交互和协同为基本支撑，提供松耦合的计算模型。
传统的Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。
WEB服务（XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。
SOA则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。
WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。
对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。
一个应用程序的业务逻辑（BusinessLogic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。
这些服务的关键是他们的松耦合特性。
例如，服务的接口和实现相独立。
应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。
举例来说，一个服务可以用.NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。
目录
[隐藏]
∙1SOA的生命周期
∙2SOA具有的特性
∙3SOA三大基本特征
o3.1独立的功能实体
o3.2大数据量低频率访问
o3.3基于文本的消息传递
∙4面向服务架构（SOA）的原则
o4.1SOA的原则
▪4.1.1业务驱动服务，服务驱动技术
▪4.1.2业务敏捷是基本的业务需求
▪4.1.3一个成功的SOA总在变化之中
▪4.1.4SOA基础
▪4.1.5SOA的五视图实现方法
▪4.1.6剩下的部分
∙5为什么选择面向服务架构（SOA）
∙6面向服务架构（SOA）基础结构
o6.1SOAP，WSDL，UDDI
o6.2WS-IBasicProfile
o6.3J2EE和.Net
o6.4服务品质
▪6.4.1安全
▪6.4.2可靠
▪6.4.3策略
▪6.4.4控制
▪6.4.5管理
∙7SOA不是Web服务
∙8面向服务架构（SOA）的优势
∙9采用服务驱动型方法的企业体验着以下业务和IT好处
o9.1面向服务架构的业务好处
o9.2面向服务架构的IT好处
∙10反响
∙11SOA企业考虑事项
∙12辅助工具
[编辑]
SOA的生命周期
SOA的生命周期
由于SOA涉及到业务的诸多方面，因此需要从一开始就对SOA项目进行细心的规划和设计。
需要考虑项目的整个生命周期，从最初的阶段到第一个实现，再一直到可能的修订和重用。
现在让我们看看SOA生命周期，如图中所示。
此部分概略说明了在生命周期的各个阶段发生的事项，并详细介绍了实现生命周期的各个步骤。
∙建模
∙组装
∙部署
∙管理
∙控制
[编辑]
SOA具有的特性
SOA服务具有平台独立的自我描述XML文档。
Web服务描述语言（WSDL，WebServicesDescriptionLanguage）是用于描述服务的标准语言。
SOA服务用消息进行通信，该消息通常使用XMLSchema来定义（也叫做XSD，XMLSchemaDefinition）。
消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。
服务间的通讯也可以看作企业内部处理的关键商业文档。
在一个企业内部，SOA服务通过一个扮演目录列表（Directorylisting）角色的登记处（Registry）来进行维护。
应用程序在登记处（Registry）寻找并调用某项服务。
统一描述，定义和集成（UDDI，UniverSAlDescription，Definition，andIntegration）是服务登记的标准。
每项SOA服务都有一个与之相关的服务品质（QoS，QualityofService）。
QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：
可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。
），以及谁能调用服务的策略。
[编辑]
SOA三大基本特征
[编辑]
独立的功能实体
在Internet这样松散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。
SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。
传统的组件技术，如.NETRemoting，EJB，COM或者CORBA，都需要有一个宿主（Host或者Server）来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。
这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。
SOA架构中非常强调实体自我管理和恢复能力。
常见的用来进行自我恢复的技术，比如事务处理（Transaction），消息队列（MessageQueue），冗余部署（RedundantDeployment）和集群系统（Cluster）在SOA中都起到至关重要的作用。
[编辑]
大数据量低频率访问
对于.NETRemoting，EJB或者XML-RPC这些传统的分布式计算模型而言，他们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。
在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。
因此SOA系统推荐采用大数据量的方式一次性进行信息交换。
[编辑]
基于文本的消息传递
由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式。
在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。
由于基于文本的消息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。
此外，对于一个服务来说，Internet与局域网最大的一个区别就是在Internet上的版本管理极其困难，传统软件采用的升级方式在这种松散的分布式环境中几乎无法进行。
采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。
[编辑]
面向服务架构（SOA）的原则
SOA的强大和灵活性将给企业带来巨大的好处。
如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，而不必考虑其后台实现的具体技术。
更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。
但是，要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。
企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解SOA，还要理解SOA的实践。
在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。
本文将讨论SOA的实践，即：
面向架构的设计师在构建SOA时必须要做的事情。
[编辑]
SOA的原则
SOA是一种企业架构，因此，它是从企业的需求开始的。
但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。
业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。
对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知的业务需求。
要满足这种业务敏捷性，SOA的实践必须遵循以下原则：
[编辑]
业务驱动服务，服务驱动技术
从本质上说，在抽象层次上，服务位于业务和技术中间。
面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。
[编辑]
业务敏捷是基本的业务需求
SOA考虑的是下一个抽象层次：
提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。
从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。
[编辑]
一个成功的SOA总在变化之中
SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。
IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。
对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。
如下文所写的，SOA的基础还是一些类似的架构准则。
[编辑]
SOA基础
在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。
第一个就是模型驱动架构（MDA），由提出CORBA的OMG模型提出。
MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。
MDA首先给出一个平台无关的模型来表示系统的功能需求和UseCases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。
MDA的核心就在于在设计阶段系统就已经完全描述，这样，在创建系统的时候，几乎就没有错误解释的可能，模型也就可以直接生成代码。
但MDA有一些局限性：
首先，MDA假设在创建模型之前，业务需求已经全部描述，而这一点，在当前典型的动态业务环境中几乎是不可能的。
第二，MDA没有一个反馈机制。
如果开发人员对模型有需要改动的地方，并没有提供给他们这么一个途径。
SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。
象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程。
XP要求在开发团队中要有一个用户代表，他帮助书写测试来指导开发人员的日常工作。
开发团队中的所有成员都参与到设计之中，并且设计要尽量小并且非形式化。
AM的目标是仅仅创建用户想要的，而不是在一些形式化模型上耗费工作量。
AM的核心思想就在于其敏捷性－处理需求变更的敏捷性。
AM的主要弱点是其规模上的限制，例如，XP在一个小团队和中型项目中效果不错，但是当项目规模增大时，如果没有一个一致的清晰的计划，项目成员很难把握项目中的方方面面。
从表面看来，MDA和AM似乎是相对立的－MDA假定需求是固定的，而AM恰恰相反。
MDA的中心是形式化的模型，而AM恰恰要避开它们。
但是，我们还是决定冒险把这些不同方法中的一些元素提取出来，放入到一个一致的架构实践中。
在SOA中有三个抽象层次，按照SOA的第一条准则：
业务驱动服务、服务驱动技术。
AM将业务模型直接和实践连接起来，表现在平台相关的模型之中。
MDA并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。
SOA必须连接这些模型，或者说抽象层次，得到单一的架构方法。
我们将从五个视图的架构实现方法来实现这个连接。
[编辑]
SOA的五视图实现方法
企业架构设计师发现他们的职业非常有竞争力并且值得骄傲，因为他们要从很多方面来通盘考虑IT系统。
Kruchten（RUP的开发负责人）将这些方面提取出来，在应用到SOA时，我们称为五视图实现方法（five-viewapproach）。
四个方框表示对一个架构的不同审视方法，分别代表不同的涉众（stakeholder）。
第五个视图，use-cASe视图涵盖了其它视图，在架构中扮演的是一个特殊的角色。
部署视图将软件映射到底层平台和相关硬件上，是系统部署人员对架构的视图；实现视图描述了软件代码的组织，是从开发人员角度出发的视图；业务分析人员则利用过程视图进行工作，它描述的是软件系统的运行时特性。
最后，逻辑视图表示的是用户的功能需求。
在SOA中，面向服务的架构必须能够以use-case视图中的用例将用户连接到服务，将服务连接到底层的技术。
为了表示面向对象的架构是如何工作在这些视图之上，让我们将他们置于SOA元模型的上下文之中。
SOA中两个领域存在重叠：
由业务模型和服务模型表示的业务领域和由服务模型及平台相关模型表示的技术领域（两个领域共享服务模型）。
业务用户通过逻辑视图和过程视图处理粗粒度的业务服务，根据变化的业务需求，按照需要将它们安排在过程之中。
另一方面，技术专家的工作是创建并维护服务和底层技术之间的抽象层。
表示这些服务的中间模型，起到的是轴心的作用，业务以它为中心进行。
SOA元模型从MDA中继承平台无关模型和平台相关模型，但是添加了AM和用户交互以及敏捷的反馈这两部分，后者通过椭圆之间的双向箭头来表现。
类似地，元模型通过引入由中心的服务模型提供的中间层抽象解决了AM在伸缩性方面的问题。
这样，服务模型中的任何需求的变化，都会反映到用户每天的业务处理中。
同样，由于底层技术是模型驱动的，技术专家也可以根据这些变化的需求迅速而有效地作出应变。
SOA实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。
如前所说，SOA的第三条原则就在于它总在变化之中。
这种恒在的变化性环境是SOA实践的基石。
如图所示，涉众（stakeholders，译者注：
RUP中也有这个词，表示软件开发中涉及到的各种角色如：
用户、设计人员、开发人员乃至测试人员等等。
）在一个必需的基础上影响到整个架构的变化。
在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地分离这两个阶段。
[编辑]
剩下的部分
我们已经为面向服务的架构提供了一个高层次的框架，其中MDA和AM的元素帮助工具的使用者来创建和维护SOA。
但是，SOA中还缺少一些内容－那就是软件开发商和专业的服务组织必需提供的。
理想情况下，开发商必需提供面向服务的业务流程、工作流以及服务的协调工具和服务；另外，能够以一种敏捷的、平台无关的方式充分反映业务服务的建模工具也是必须的；技术专家必须配备可以从模型中自动生成代码，并在代码变化时更新模型的工具，最后，开发商必须提供支持SOA的软件，帮助面向服务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的抽象层次。
幸运的是，这方面的产品即将上市。
另外，最重要的就是贯穿本文的自顶而下的SOA实现方法了。
今天关于Webservices的大部分思考都是自底而上的：
“这是如何创建Webservices的方法，现在，我们来使用它们集成吧”，对Webservices技术的这种方法是伟大的第一步，因为它可以惊人地降低集成的开销，这是现在的技术管理人员最乐意见到的了。
但当经济进一步发展，IT走出低谷，企业会寻求IT的帮助来提高组织战略意义上的核心价值。
使用面向服务的架构，IT可以提供给企业实现业务敏捷性的这样一个框架。
[编辑]
为什么选择面向服务架构（SOA）
不同种类的操作系统，应用软件，系统软件和应用基础结构（applicationinfrastructure）相互交织，这便是IT企业的现状。
一些现存的应用程序被用来处理当前的业务流程（businessprocesses），因此从头建立一个新的基础环境是不可能的。
企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（applicationinfrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（orGAnicbusiness）的构架。
SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务，从而保护了现有的IT基础建设投资。
如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supplychaincompositeapplication），这些现有的应用通过标准接口来提供功能。
Figure1.Supplychainapplication.Clickonthumbnailtoviewfull-sizedimage.
服务架构
为了实现SOA，企业需要一个服务架构，图2显示了一个例子：
Figure2.Asampleservicearchitecture.Clickonthumbnailtoviewfull-sizedimage.
在图2中，服务消费者（serviceconsumer）可以通过发送消息来调用服务。
这些消息由一个服务总线（servicebus）转换后发送给适当的服务实现。
这种服务架构可以提供一个业务规则引擎（businessrulesengine），该引擎容许业务规则被合并在一个服务里或多个服务里。
这种架构也提供了一个服务管理基础（servicemanagementinfrastructure），用来管理服务，类似审核，列表（BIlling），日志等功能。
此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatoryrequirement），例如SarbanesOxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
[编辑]
面向服务架构（SOA）基础结构
要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。
SOA基础必须支持所有的相关标准，和需要的运行时容器。
接下来的章节将逐一讨论该结构的每个部分。
[编辑]
SOAP，WSDL，UDDI
WSDL，UDDI和SOAP是SOA基础的基础部件。
WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。
SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。
一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。
[编辑]
WS-IBasicProfile
WS-IBasicProfile，由Web服务互用性组织（WebServicesInteroperabilityOrganization）提供，是SOA服务测试与互用性所需要的核心构件。
服务提供者可以使用BasicProfile测试程序来测试服务在不同平台和技术上的互用性。
[编辑]
J2EE和.Net
尽管J2EE和.NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。
像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。
新的规范，例如JAXB（JavaAPIforXMLBinding），用于将XML文档定位到Java类；JAXR（JavaAPIforXMLRegistry）用来规范对UDDI注册表（registry）的操作；XML-RPC（JavaAPIforXML-basedRemoteProcedureCall）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如.NET）的服务互用。
[编辑]
服务品质
在企业中，关键任务系统（MISsion-criticalsystem，译注：
关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。
比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。
）用来解决高级需求，例如安全性，可靠性，事物。
当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。
正如前面所提到的，这些需求也称作服务品质（QoS，qualityofservices）。
与QoS相关的众多规范已经由一些标准化组织（standaRDSBOdies）提出，像W3C（WorldWIDEWebConsortium）和OASIS（theOrganizationfortheAdvancementofStructuredInfORMationStandards）。
下面的部分将会讨论一些QoS服务和相关标准。
[编辑]
安全
Web服务安全规范用来保证消息的安全性。
该规范主要包括认证交换，消息完整性和消息保密。
该规范吸引人的地方在于它借助现有的安全标准，例如，SAML（asSecurityAssertionMarkupLanguage）来实现web服务消息的安全。
OASIS正致力于Web服务安全规范的制定。
[编辑]
可靠
在典型的SOA环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。
具有诸如“仅且仅仅传送一次”（once-and-only-oncedelivery），“最多传送一次”（at-most-oncedelivery），“重复消息过滤”（duplicatemessageelimination），“保证消息传送”（guaranteedmessagedelivery）等特性消息的发送和确认，在关键任务系统（mission-criticalsystems）中变得十分重要。
WS-Reliability和WS-ReliableMessaging是两个用来解决此类问题的标准。
这些标准现在都由OASIS负责。
[编辑]
策略
服务提供者有时候会要求服务消费者与某种策略通信。
比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。
这些要求被定义为策略断言（policyassertions）。
一项策略可能会包含多个断言。
WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。
[编辑]
控制
当企业着手于服务架构时，服务可以用来整合数据仓库（silosofdata），应用程序，以及组件。
整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请
升级会员 