专题SOA面向服务的体系结构.docx
- 文档编号:14503211
- 上传时间:2023-06-24
- 格式:DOCX
- 页数:137
- 大小:816.96KB
专题SOA面向服务的体系结构.docx
《专题SOA面向服务的体系结构.docx》由会员分享,可在线阅读,更多相关《专题SOA面向服务的体系结构.docx(137页珍藏版)》请在冰点文库上搜索。
专题SOA面向服务的体系结构
专题:
SOA—面向服务的体系结构
SOAandWebservices新手入门
SOAandWebservices新手入门
developerWorks站点上的Webservices专区包含差不多数百篇文章、教程和技巧,可以帮助开发人员进行大多数与Web服务有关的应用程序的开发;但是对于那些尝试涉足这个新领域的用户来说,所有这些信息可能会使他们望而却步。
此页为那些想学习Web服务但是却又不知道从何入手的读者提供了一份概述。
它将Web服务技术所有的基础知识都放在适当的背景中,并且把它们与相关的developerWorks文章、教程和技巧、IBM学习服务教育、网络广播、专题研讨会以及IBM产品联系起来,供读者进一步地研究。
什么是面向服务的体系结构(SOA)?
面向服务的体系结构(service-orientedarchitecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。
松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,它能够继续存在。
而另一方面,紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的,因而当需要对部分或整个应用程序进行某种形式的更改时,它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活,以适应不断变化的环境,比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素,这些因素甚至会影响业务的性质。
我们称能够灵活地适应环境变化的业务为按需(Ondemand)业务,在按需业务中,一旦需要,就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物,但它却是更传统的面向对象的模型的替代模型,面向对象的模型是紧耦合的,已经存在二十多年了。
虽然基于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中都起着重要的作用。
要获得更多关于这一部分内容的信息:
●参阅SOA扩展Web服务的前景。
●阅读IBMvisionofServiceOrientedArchitectures以获得更详细的说明。
●Web服务新手入门指南回答了许多问题,这对那些还不熟悉Web服务技术的人应该会有很大的帮助。
●Web服务和WSDKV5.1介绍教程很好地介绍了Web服务的概念和技术结构。
如果您是一名想要了解Web服务的软件架构师或业务人员,AnExecutive'sGuidetoWebservices提出了许多有用的关于Web服务的商业价值的观念。
我可以用面向服务的体系结构做什么?
对SOA的需要来源于需要使业务IT系统变得更加灵活,以适应业务中的改变。
通过允许强定义的关系和依然灵活的特定实现,IT系统既可以利用现有系统的功能,又可以准备在以后做一些改变来满足它们之间交互的需要。
下面举一个具体的例子。
一个服装零售组织拥有500家国际连锁店,它们常常需要更改设计来赶上时尚的潮流。
这可能意味着不仅需要更改样式和颜色,甚至还可能需要更换布料、制造商和可交付的产品。
如果零售商和制造商之间的系统不兼容,那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。
通过利用WSDL接口在操作方面的灵活性,每个公司都可以将它们的现有系统保持现状,而仅仅匹配WSDL接口并制订新的服务级协定,这样就不必完全重构它们的软件系统了。
这是业务的水平改变,也就是说,它们改变的是合作伙伴,而所有的业务操作基本上都保持不变。
这里,业务接口可以作少许改变,而内部操作却不需要改变,之所以这样做,仅仅是为了能够与外部合作伙伴一起工作。
另一种形式是内部改变,在这种改变中,零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店,这可以看作是采用店中店(store-in-store)的业务模型。
这里,虽然公司的大多数业务操作都保持不变,但是它们现在需要新的内部软件来处理这样的出租安排。
尽管在内部软件系统可以承受全面的检修,但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。
在这种情况下,SOA模型保持原封不动,而内部实现却发生了变化。
虽然可以将新的方面添加到SOA模型中来加入新的出租安排的职责,但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念,IT经理可能会发现,软件的新配置还可以以另外的一种方式加以使用,比如出租粘贴海报的地方以供广告之用。
这里,新的业务提议是通过在新的设计中重用灵活的SOA模型得出的。
这是来自SOA模型的新成果,并且还是一个新的机会,而这样的新机会在以前可能是不会有的。
垂直改变也是可能的,在这种改变中,零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。
如果垂直改变完全从最底层开始的话,就会带来SOA模型结构的显着改变,与之一起改变的还可能有新的系统、软件、流程以及关系。
在这种情况下,SOA模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题,这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。
然后可以将软件系统构造为适合业务处理的方式,而不是在许多现有的软件平台上常常看到的其他方式。
正如您可以看到的,在这里,改变和SOA系统适应改变的能力是最重要的部分。
对于开发人员来说,这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生,这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。
与开发人员不同的是,架构师的作用就是引起对SOA模型大的改变。
这种分工,就是让开发人员集中精力于创建作为服务定义的功能单元,而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起,它已经有十多年的历史了,通常用统一建模语言(UniversalModelingLanguage,UML),并且描述成模型驱动的体系结构(Model-DrivenArchitecture,MDA)。
要获得更多关于这一部分内容的信息:
学习更多关于面向服务的体系结构的知识。
了解使用SOA的好处。
构成SOA的技术是什么?
SOA本身是应该如何将软件组织在一起的抽象概念。
它依赖于用XML和Web服务实现并以软件的形式存在的更加具体的观念和技术。
此外,它还需要安全性、策略管理、可靠消息传递以及会计系统的支持,从而有效地工作。
您还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。
SOA服务和Web服务之间的区别在于设计。
SOA概念并没有确切地定义服务具体如何交互,而仅仅定义了服务如何相互理解以及如何交互。
其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。
而另一方面,Web服务在需要交互的服务之间如何传递消息有具体的指导原则;从战术上实现SOA模型是通过HTTP传递的SOAP消息中最常见的SOA模型。
因而,从本质上讲,Web是实现SOA的具体方式之一。
尽管我们觉得Web服务是实现SOA的最好方式,但是SOA并不局限于Web服务。
其他使用WSDL直接实现服务接口并且通过XML消息进行通信的协议也可以包括在SOA之中。
正如在别处指出的,CORBA和IBM的MQ系统通过使用能够处理WSDL的新特征也可以参与到SOA中来。
如果两个服务需要交换数据,那么它们还会需要使用相同的消息传递协议,但是数据接口允许相同的信息交换。
既为了建立所有这些信息的适当控制,又为了应用安全性、策略、可靠性以及会计方面的要求,在SOA体系结构的框架中加入了一个新的软件对象。
这个对象就是企业服务总线(EnterpriseServiceBus,ESB),它使用许多可能的消息传递协议来负责适当的控制、流甚至还可能是服务之间所有消息的传输。
虽然ESB并不是绝对必需的,但它却是在SOA中正确管理您的业务流程至关重要的组件。
ESB本身可以是单个引擎,甚至还可以是由许多同级和下级ESB组成的分布式系统,这些ESB一起工作,以保持SOA系统的运行。
在概念上,它是从早期比如消息队列和分布式事务计算这些计算机科学概念所建立的存储转发机制发展而来的。
从开发人员的角度来说,他们使用的工具必须知道SOA的能力,并允许开发人员有效地使用SOA对象。
这将设计SOA模型、开发服务和服务对象以及测试SOA应用程序这些过程包括进来并组成一个整体。
因而,开发人员的工作必须为面向服务的应用程序设计/开发(Service-OrientedApplicationDesign/Development,SOAD)做好准备。
要获得更多关于这一部分内容的信息:
web服务新手入门页面描述了什么是Web服务的技术细节。
Web服务概念性体系结构(WebServicesConceptualArchitecture)解释了Web服务背后的技术思想以及Web服务如何运行。
在Web服务标准数据库中可以找到重要的Web服务规范和协议标准。
SOA与其他技术的关系如何?
SOA可以与许多其他技术结合在一起使用,然而,组件的封装和聚合在其中扮演着重要的角色。
如前所述,SOA可以是一个简单对象、复杂对象、对象的集合、包含许多对象的流程、包含其他流程的流程,甚至还可以是输出单一结果的应用程序的整体集合。
在服务之外,它可以看作是单个实体,但是在其自身中,它可以具有任何级别的复杂性(如果必要的话)。
出于性能方面的考虑,大多数SOA服务并没有下降到单一对象的粒度,并且更适合于大中型组件。
除了可能离不开XML和WSDL之外,SOA并不是特定于语言的。
可以用任何编程语言来实现服务,只要这种编程语言可以生成服务并且可以与WSDL结合在一起使用就可以了。
SOAP本身并不是绝对需要的,但它是通用的消息传递系统。
因此,可以使用几乎任何一种编程语言和支持WSDL的平台来实现SOA中的成员服务。
基于通用对象请求代理体系结构(CommonObjectBrokerRequestArchitecture,CORBA)的应用程序有许多组件必须连接到SOA中。
虽然CORBA中的接口描述语言(InterfaceDescriptionLanguage,IDL)在概念上类似于WSDL,但它不是严格的,因而首先需要将其映射到WSDL。
另外,需要使用更高级的SOA协议(比如用于流程和策略管理的协议),而不是CORBA中的类似的概念。
请记住,这是CORBA组件(表示为服务)需要与SOA服务交互的情况;在CORBA模型中,所有的独立子集仍然可以像以前一样工作。
由对象管理组(ObjectManagementGroup)提出并在许多IBMRational产品中得以实现的模型驱动体系结构在一个更抽象的层次上与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模型。
要获得更多关于这一部分内容的信息:
阅读更多关于面向服务的体系结构的关键组件的内容。
developerWorks站点上的Rational开发者园地包含关于模型驱动的体系结构(Model-DrivenArchitectures)的信息
developerWorks站点上的XML专区可以解释XML在现代编程语言中所扮演的角色。
Java是最流行的用于SOA开发的语言之一。
请从developerWorksJava技术专区获得更多关于Java的信息。
从developerWorks自主计算专区获得更多关于自主计算的信息。
开放网格服务架构之旅解释了现在如何以Web服务为基础设计网格计算。
请从developerWorks网格计算专区获得更多关于网格计算的信息。
?
我可以如何构建SOA系统?
利用SOA的好处不仅是一个软件开发流程,而且还是一个业务开发流程。
采用SOA有四个层次,您的实现可以跨越从创建特定的软件服务到将您的业务模型全面转换到按需系统的过程。
要获得进一步的信息,您应该阅读这一部分的末尾列出的文章“TheFourlevelsofSOAAdoption”。
第一个层次是最简单的,因为它只需创建单独的服务。
在这一部分列出的“SOA新手入门”中对此进行了详细解释,并且提供了更多的资源。
在第二个层次中,您不仅可以创建服务,而且可以开始将业务功能集成到SOA中。
这涉及多个层次的集成,其中包括应用程序集成、信息集成、流程集成和整个系统集成。
MigratingtoaService-OrientedArchitecture是一篇重要的文章,介绍了这个层次中的问题。
第三个层次涉及将您的企业IT基础设施转换到SOA模型,而采用SOA的第四个层次集中于转换您的业务模型,以使之成为按需就绪的模型。
从IT专业人员的角度来看(与业务层相比),要创建SOA应用程序,您通常将经历四个阶段:
构建、部署、使用和管理。
在构建阶段中,您可以定义业务模型或流程、软件模型和SOA模型。
之后,您就可以创建一组服务,这组服务可以与已发布的通用接口一起重用。
在部署阶段,您提取创建的服务,并把它们放在一个可执行、可管理的环境之中。
在使用阶段,您根据前面所讲的SOA和软件模型来装配应用程序,并且测试其软件质量以及非功能性需求,比如性能、可伸缩性等等。
应用程序现在已经准备完毕并且可用于用户。
最后的管理阶段是一个长期的过程,在这个阶段中,您可以监控并管理安全性和使用,以及在许多与您可能已经为SOA制订好的服务级协定或策略相对应的方面比较其性能。
这些是SOA的生命周期的概念阶段。
为了使对应于这些阶段的实际工作角色具体化,有许多角色需要加入到SOA应用程序的创建之中。
这些角色可能从事相同的工作,也可能跨多个团队成员甚至多个团队。
在RationalUnifiedProcess(RUP)中所划分的角色非常好地表达了角色概念。
RUP角色包括项目经理、分析员、架构师、建模人员、开发人员、测试人员以及部署和操作人员。
SOA几乎完全照搬了这种角色划分方法,惟一不同之处在于,SOA建模人员角色的工作是提取概念性软件模型,并且根据IT基础设施的SOA模型和资源来对其进行测试。
开发人员角色还可以包括二级角色像装配人员(在使用阶段),装配人员的角色是提取单独的服务,并且根据定义好的模型构建实际的SOA应用程序。
不管是显式的还是隐式的,这些角色都存在于支持SOA的企业之中。
要获得更多关于这一部分内容的信息:
阅读更多关于采用SOA的四个层次的内容。
阅读MigratingtoaService-OrientedArchitecture,Part1和Part2。
如果您想要了解更多关于RationalUnifiedProcess的信息,您就应该阅读它们的RationalUnifiedProcess:
BestPracticesforsoftwaredevelopmentteams。
BusinessprocessesandworkflowintheWebservicesworld描述了业务流程如何在面向服务的体系结构中工作。
要获得更多关于使用Web服务的工作流和业务流程的信息,您应该阅读BPEL4WS专栏中关于BPEL4WS规范的文章。
FromUMLtoBPEL:
ModelDrivenArchitectureinaWebservicesworld解释了如何适当地将Web服务加入到模型驱动的体系结构(Model-DrivenArchitectures)的世界中。
我可以如何提高我的SOA技能?
技能的获取取决于您是一个什么类型的专业人员:
信息分析员、软件架构师、软件开发人员、软件质量分析员、系统管理员等等。
如前所述,SOA的概念跨越所有这些工作角色。
然而,尽力地理解每个工作角色所起的作用是非常有帮助的。
接下来,您应该熟悉这每个角色中所包括的技术概念。
信息分析员和软件架构师应该熟悉模型驱动的体系结构(Model-DrivenArchitectures)和UMLV2.0。
软件开发人员和程序员应该了解Web服务的程序化接口、MQ和其他协议、程序化地保护交互的方式以及工作流处理的概念。
质量分析员和系统管理员应该理解SOA流程模型与实际SOA功能性体系结构实现,以及分别开发单独的服务如何影响这样的分布式应用程序的整体性能。
系统管理员还应该知道应用程序安全性和信任模型如何工作,以及应用程序使用策略如何影响操作系统平台和网络系统。
要获得更多关于这一部分内容的信息:
由OlafZimmerman划分的Web服务项目角色最初是为Web服务而描述的,但是实际上跨越了SOA的整个团队。
我们提供了许多关于Level1SOAAdoption:
ImplementingIndividualWebservices的入门和提高技能的信息。
其中还包括关于技术简报、课程和专题讨论会的信息。
我们还提供了更多关于Level2SOAAdoption:
ServiceOrientedIntegration的入门和技能提高信息。
AnintroductiontoModel-DrivenArchitecture将帮助您熟悉这个软件开发的体系。
SOAandWebservices专区通常会增加一些新教程,这些教程详细解释了如何执行SOA和Web服务的有用任务。
要了解更多关于UML的信息,请转到RationalUMLResource中心。
IBM的什么工具和产品可用于SOA?
IBM是第一个为构建、部署和关于基于SOA的IT系统提供一系列全面的工具、教育和服务路线的大型厂商。
它们涵盖了SOA生命周期的所有方面,其中包括用于前面所讲的采用SOA的各个层次构建、部署、使用和管理服务的工具。
每个层次都包括更低的采用层次及其工具。
由于流程可以扩展,所以并不是各个采用层次上所有的生命周期阶段都是必要的。
最后,按需业务转换(OnDemandBusinessTransformation)的第四个层次是面向业务的层次而不是技术流程,并且需要更低层次上的相同软件。
在第一个用于实现独立Web服务(ImplementingIndividualWebservices)的SOA采用层次中,图1所示的工具主要用于帮助开发人员创建和操作比较简单的Web服务。
图1.实现单独的Web服务――核心组件
在第二个层次,面向服务的集成(ServiceOrientedIntegration),工具转向提供发现多个服务并与其交互的方式,以及创建SOA模型的基础。
图2a展示了层次2采用的核心组件,而图2b展示了可以为层次2提供帮助的附加组件。
图2a.面向服务的集成――核心组件
图2b.面向服务的集成――附加组件
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 专题SOA 面向服务的体系结构 专题 SOA 面向 服务 体系结构