SOA概述.docx
《SOA概述.docx》由会员分享，可在线阅读，更多相关《SOA概述.docx（12页珍藏版）》请在冰豆网上搜索。
SOA概述
关于SOA的技术报告
1SOA（面向服务的体系结构）
1.1定义
面向服务的体系结构（service-orientedarchitecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
1.2松耦合
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。
松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需（Ondemand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
1.3横向对照
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。
虽然基于SOA的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。
由于它考虑到了系统内的对象，所以虽然SOA是基于对象的，但是作为一个整体，它却不是面向对象的。
不同之处在于接口本身。
SOA系统原型的一个典型例子是通用对象请求代理体系结构（CommonObjectRequestBrokerArchitecture，CORBA），它已经出现很长时间了，其定义的概念与SOA相似。
然而，现在的SOA已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensibleMarkupLanguage，XML）为基础的。
通过使用基于XML的语言（称为Web服务描述语言（WebServicesDefinitionLanguage，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前CORBA中的接口描述语言（InterfaceDefinitionLanguage，IDL）可比了。
Web服务并不是实现SOA的惟一方式。
前面刚讲的CORBA是另一种方式，这样就有了面向消息的中间件（Message-OrientedMiddleware）系统，比如IBM的MQseries。
但是为了建立体系结构模型，您所需要的并不只是服务描述。
您需要定义整个应用程序如何在服务之间执行其工作流。
您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。
因此，SOA应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。
例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。
因而，工作流还可以在SOA的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。
因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。
最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。
因此，安全、信任和可靠的消息传递应该在任何SOA中都起着重要的作用。
1.4功能
我可以用面向服务的体系结构做什么？
对SOA的需要来源于需要使业务IT系统变得更加灵活，以适应业务中的改变。
通过允许强定义的关系和依然灵活的特定实现，IT系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。
下面举一个具体的例子。
一个服装零售组织拥有500家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。
这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。
如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。
通过利用WSDL接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配WSDL接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。
这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。
这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。
另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。
这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。
尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。
在这种情况下，SOA模型保持原封不动，而内部实现却发生了变化。
虽然可以将新的方面添加到SOA模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念，IT经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。
这里，新的业务提议是通过在新的设计中重用灵活的SOA模型得出的。
这是来自SOA模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。
垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。
如果垂直改变完全从最底层开始的话，就会带来SOA模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。
在这种情况下，SOA模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。
然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。
正如您可以看到的，在这里，改变和SOA系统适应改变的能力是最重要的部分。
对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。
与开发人员不同的是，架构师的作用就是引起对SOA模型大的改变。
这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（UniversalModelingLanguage，UML），并且描述成模型驱动的体系结构（Model-DrivenArchitecture，MDA）。
2服务
2.1WebService
2.1.1WebService简介
WebService主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。
WebService所使用的是Internet上统一、开放的标准，如HTTP、XML、SOAP（简单对象访问协议）、WSDL等，所以WebService可以在任何支持这些标准的环境（Windows,Linux）中使用。
注：
SOAP协议（SimpleObjectAccessProtocal,简单对象访问协议）,它是一个用于分散和分布式环境下网络信息交换的基于XML的通讯协议。
在此协议下，软件组件或应用程序能够通过标准的HTTP协议进行通讯。
它的设计目标就是简单性和扩展性，这有助于大量异构程序和平台之间的互操作性，从而使存在的应用程序能够被广泛的用户访问。
2.1.2WebService之长
2.1.2.1跨防火墙的通信
举个例子，在应用程序里加入一个新页面，必须先建立好用户界面（Web页面），并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。
要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。
如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。
要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。
不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。
同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。
从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可以节省花在用户界面编程上20%的开发时间。
另外，这样一个由WebService组成的中间层，完全可以在应用程序集成或其它场合下重用。
最后，通过WebService把应用程序的逻辑和数据“暴露”出来，还可以让其它平台上的客户重用这些应用程序。
2.1.2.2应用程序集成
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。
应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。
即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。
通过WebService，应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用。
例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。
这两个程序来自不同软件厂商。
一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。
通过在订单执行程序上面增加一层WebService，订单执行程序可以把“AddOrder”函数“暴露”出来。
这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。
2.1.2.3B2B的集成
用WebService集成应用程序，可以使公司内部的商务处理更加自动化。
但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？
跨公司的商务交易集成通常叫做B2B集成。
WebService是B2B集成成功的关键。
通过WebService，公司可以把关键的商务应用“暴露”给指定的供应商和客户。
例如，把电子下单系统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。
当然，这并不是一个新的概念，EDI（电子文档交换）早就是这样了。
但是，WebService的实现要比EDI简单得多，而且WebService运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。
不过，WebService并不像EDI那样，是文档交换或B2B集成的完整解决方案。
WebService只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。
用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。
只要把商务逻辑“暴露”出来，成为WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。
这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。
2.1.2.4软件和数据重用
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。
最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。
当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。
但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。
原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。
WebService在允许重用代码的同时，可以重用代码背后的数据。
使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。
举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。
WebService的提供商可以按时间或使用次数来对这项服务进行收费。
这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是，把好几个应用程序的功能集成起来。
例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。
现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。
一旦他们把这些功能都通过WebService“暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件/WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。
两种情况下，都可以重用代码和代码背后的数据。
2.1.3WebService之短
2.1.3.1单机应用程序
目前，企业和个人还使用着很多桌面应用程序。
其中一些只需要与本机上的其它程序通信。
在这种情况下，最好就不要用WebService，只要用本地的API就可以了。
COM非常适合于在这种情况下工作，因为它既小又快。
运行在同一台服务器上的服务器软件也是这样。
最好直接用COM或其它本地的API来进行应用程序间的调用。
当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。
2.1.3.2局域网的同构应用程序
在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。
例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。
在这些程序里，使用DCOM会比SOAP/HTTP有效得多。
与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。
有趣的是，在.NETremoting中，也可以指定使用SOAP/HTTP来进行WebService调用。
不过最好还是直接通过TCP进行RPC调用，那样会有效得多。
总之，只要从应用程序结构的角度看，有别的方法比WebService更有效、更可行，那就不要用WebService。
2.2SOAP（SimpleObjectAccessProtocol服务通信协议）
简单对象访问协议（SOAP）是一种轻量的、简单的、基于XML的协议，它被设计成在WEB上交换结构化的和固化的信息。
SOAP可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。
它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。
SOAP包括三个部分：
a）SOAP封装：
它定义了一个框架,该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。
b）SOAP编码规则：
它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。
c）SOAPRPC（rpc:
远过程调用协议）表示：
它定义了用于表示远程过程调用和应答的协定。
SOAP消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。
所有的SOAP消息都使用XML编码。
一条SOAP消息就是一个包含有一个必需的SOAP的封装包，一个可选的SOAP标头和一个必需的SOAP体块的XML文档。
把SOAP绑定到HTTP提供了同时利用SOAP的样式和分散的灵活性的特点以及HTTP的丰富的特征库的优点。
在HTTP上传送SOAP并不是说SOAP会覆盖现有的HTTP语义，而是HTTP上的SOAP语义会自然的映射到HTTP语义。
在使用HTTP作为协议绑定的场合中，RPC请求映射到HTTP请求上，而RPC应答映射到HTTP应答。
然而，在RPC上使用SOAP并不仅限于HTTP协议绑定。
2.3WSDL（服务的说明语言）
WSDL（WebServicesDescriptionLanguage）表示Web服务说明语言。
我们可以认为WSDL文件是一个XML文档，用于说明一组SOAP消息以及如何交换这些消息。
换句话说，WSDL对于SOAP的作用就象IDL对于CORBA或COM的作用。
由于WSDL是XML文档，因此很容易进行阅读和编辑；但大多数情况下，它由软件生成和使用。
要查看WSDL的值，可以假设您要调用由您的一位业务伙伴提供的SOAP方法。
您可以要求对方提供一些SOAP消息示例，然后编写您的应用程序以生成并使用与示例类似的消息，但这样很容易出错。
例如，您可能看到一个2837的客户ID，并假设它为整数，而实际上它是一个字符串。
WSDL通过明确的表示法指定请求消息必须包含的内容以及响应消息的样式。
WSDL文件用于说明消息格式的表示法以XML架构标准为基础，这意味着它与编程语言无关，而且以标准为基础，因此适用于说明可从不同平台、以不同编程语言访问的XMLWebService接口。
除说明消息内容外，WSDL还定义了服务的位置，以及使用什么通信协议与服务进行通信。
也就是说，WSDL文件定义了编写使用XMLWebService的程序所需的全部内容。
2.4SOAP实施
2.4.1自下而上
先写代码建立webservice，然后用wsdl语言描述。
2.4.2自上而下
先用wsdl描述业务，然后写代码实现webservice。
2.4.3实用工具
Axis2功能强大，操作简易。
2.5BPEL
BPEL就是为了整合现有的Web Services,将现有的Web Services按照要求的业务流程整理成为一个新的Web Services,再这个基础上,形成一个从外界看来和单个Service一样的Service.
作为可执行流程的实现语言，BPEL4WS 的作用是将一组现有的服务整合起来，从而定义一个新的 Web 服务。
因此，BPEL4WS 基本上是一种实现这样的整合的语言。
与其它任何 Web 服务一样，整合服务的接口也被描述为 WSDL portType 的集合。
整合（称为 流程）指明了服务接口与整合的总体执行的配合情况。
2.6UDDI（服务的黄页）
通用发现、说明和集成（UDDI）是Web服务的黄页。
与传统黄页一样，您可以搜索提供所需服务的公司，阅读以了解所提供的服务，然后与某人联系以获得更多信息。
当然，您也可以提供Web服务而不在UDDI中注册，就象在地下室开展业务，依靠的是口头吆喝；但是如果您希望拓展市场，则需要UDDI以便能被客户发现。
UDDI目录条目是介绍所提供的业务和服务的XML文件。
UDDI目录条目包括三个部分。
“白页”介绍提供服务的公司：
名称、地址、联系方式等等；“黄页”包括基于标准分类法（例如NorthAmericanIndustryClassificationSystem和StandardIndustrialClassification）的行业类别；“绿页”详细介绍了访问服务的接口，以便用户能够编写应用程序以使用Web服务。
服务的定义是通过一个称为类型模型（或tModel）的UDDI文档来完成的。
多数情况下，tModel包含一个WSDL文件，用于说明访问XMLWebService的SOAP接口，但是tModel非常灵活，可以说明几乎所有类型的服务。
UDDI目录还包含若干种方法，可用于搜索构建您的应用程序所需的服务。
例如，您可以搜索特定地理位置的服务提供商或者搜索特定的业务类型。
之后，UDDI目录将提供信息、联系方式、链接和技术数据，以便您确定能满足需要的服务。
UDDI允许您查找提供所需的Web服务的公司。
如果您已经知道要与谁进行业务合作，但尚不了解它还能提供哪些服务，这时该如何处理呢？
WS-Inspection规范（英文）允许您浏览特定服务器上提供的XMLWebService的集合，从中查找所需的服务。
3建立体系结构
3.1通信模块（ESB）
3.1.1ESB企业服务总线（web服务代理）
ESB负责处理消息，把流程转发到最合适的应用程序或者服务。
ESB（EnterpriseServiceBus，即企业服务总线）是传统中间件技术与XML、Web服务等技术结合的产物。
ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。
企业服务总线ESB就是一种可以提供可靠的、有保证的消息技术的最新方法。
ESB中间件产品利用的是Web服务标准和与公认的可靠消息MOM协议接口（例如IBM的WebSphereMQ、Tibco的Rendezvous和SonicSoftware的SoniCMQ）。
ESB产品的共有特性包括:
连接异构的MOM、利用Web服务描述语言接口封装MOM协议，以及在MOM传输层上传送简单对象应用协议（SOAP）传输流的能力。
大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。
ESB的主要功能有:
通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模、管理和自治、基础架构智能等。
3.1.2ESB特性
●它是面向服务架构的实现。
●它通常是操作系统和编程语言无关的；它应能在Java和.Net应用程序之间工作。
●它使用XML（可扩展标识语言）作为标准通信语言。
●它支持Web服务标准。
●它支持消息传递（同步、异步、点对点、发布-订阅）。
●它包含基于标准的适配器（如J2C/JCA），用于集成传统系统。
●它包含对服务编制（orchestration）和编排（choreography）的支持。
●它包含智能、基于内容的路由服务（itenerary路由）。
●它包含标准安全模型，用于ESB的认证、授权和审计。
●它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
●它包含基于模式（schema）的验证，用于发送和接收消息。
●它可以统
升级会员 