来自Min Luo, Mark Endrei, Philippe Comte,Pal Krogdahl, Jenny Ang, Tony Newling
, International Technical Support Organization, Raleigh Center
2004 q?6 ?01 ?/font>
在这一节中Q我们简要地描述了面向服务的体系l构的发展。然后,我们探究了面向组件的开发与面向服务的体pȝ构之间的关系Qƈ且说明了如何组件作为实现服务的基础设施?/font>
W一部分Q新Ҏ的商业驱动力
虽然 IT l理一直面临着削减成本和最大限度地利用现有技术的NQ但是与此同Ӟ他们q必M断地努力Q以期更好地服务客户Q更快地响应企业战略重点Q从而赢得更大的竞争力?/font>
在所有这些压力之下,有两个基本的主题Q异构和改变。现在,大多C业都有各U各Lpȝ、应用程序以及不同时期和技术的体系l构。集成来自多个厂商跨不同q_的品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品Q因为改变应用程序套件和支持基础设施是如此之难?/font>
在当?IT l理面的问题之中,改变是第二个主题。全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争Q品周期羃短了Q每个公叔R惌得超q竞争对手的优势。在竞争产品和可以从 Internet 上获得的大量产品信息的推动下Q客戯求更快速地q行改变。因而,在改q品和服务斚w展开的竞争进一步加剧了?/font>
Z满客户提出的越来越多的新要求,技术方面的改进也在不断地加快。企业必d速地适应q种改变Q否则就难以生存Q更别提在这个动荡不安竞争激烈的环境中取得成功了Q?IT 基础设施必须支持企业提高适应能力?/font>
因此Q企业组l正在从上世U八十年代或更早的时期的怺隔离的垂直业务部门,C世纪八十q代和九十年代关注业务流E的水^l构Q向新的生态系l业务范例发展。重Ҏ扩展供应链,支持客户和合作伙伴访问业务服务。第 19 늚?2-1 展示了企业的q种发展?/font>
?2-1 企业的发?/font>
我如何我的 IT 环境更灵zM更快地响应不断改变的业务需求呢Q?我们如何使这些异构系l和应用E序可能无~地q行通信呢?我们如何辑ֈ企业目标而不使企业走向破产的深渊呢?
IT 响应?支持者是随着企业的这U发展而ƈ行发展的Q如?2-2 所C。现在,许多 IT l理和专业h员都同样怿Q我们真的快扑ֈ了一U满意的{案——面向服务的体系l构?/font>
?2-2 体系l构的发?/font>
?2-2 体系l构的发?/font>
Z减少异构性、互操作性和不断改变的要求的问题Q这L体系l构应该提供q_来构建具有下列特征的应用E序服务Q?/font>
Zq样的面向服务的体系l构Q服务用者甚至不必关心与之通信的特定服务,因ؓ底层基础设施或服务“ȝ”将代表使用者做出适当的选择。基设施对请求者隐藏了可能多的技术。特别地Q来自不同实现技术(?J2EE ?.NETQ的技术规范不应该影响 SOA 用户。如果已l存在一个服务实玎ͼ我们p应该重新考虑用一个“更好”的服务实现来代替,新的服务实现必须h更好的服务质量?/font>
W二部分Q作x案的面向服务体系l构
自从“Y件危机”促qY件工E的开创以来,IT 界一直在努力L解决上述问题的方案。在q去几年里,下面要概q的核心技术进展我们走到了今天。我们将要讨些核心技术,而我们重点关注的是q些技术如何帮助解?IT 问题?/font>
面向对象的分析和设计
在“Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design”中QLarman 面向对象的分析和设计的本质描述为“从对象Q物体、概忉|实体Q的角度考虑问题域和逻辑解决Ҏ”。在“Object-Oriented SoftwareEngineering: A Use Case Driven Approach”中QJacobson {将q些对象定义为“特点在于具有许多操作和状态(记忆q些操作的媄响)的物体”?/font>
在面向对象的分析中,q样的对象是用问题域来标识和描述的,而在面向对象的设计中Q它们{变成逻辑软g对象Q这些对象最l将用面向对象的~程语言q行实现?/font>
通过面向对象的分析和设计Q可以封装对象(或对象组Q的某些斚wQ以化复杂业务场景的分析。ؓ了降低复杂性,也可以抽象对象的某些特征Q这样就可以只捕获重要或本质的方面?/font>
Zlg的设计ƈ不是一U新技术。它是从对象范例中自然发展而来的。在面向对象的分析和设计的早期,l粒度的对象被标榜ؓ提供“重用”的机制Q但是这L对象的粒度别太低了Q没有适当的标准可以用来重用q泛应用于实践之中。在应用E序开发和pȝ集成中,_粒度组件越来越成ؓ重用的目标。这些粗_度对象通过内聚一些更l粒度的对象来提供定义良好的功能。通过q种方式Q还可以打包的解决Ҏ套g装成这L“组件”?/font>
一旦组l在更高层次上实CZ完全独立的功能组件的完备体系l构Q就可以支持企业的应用E序划分成一l粒度越来越大的lg。可以将lg看作是打包、管理和公开服务的机制。它们可以共同用一l技术:实现企业U用늚大粒度企业组件可以通过更新的面向对象的软g开发与遗留pȝ相结合来实现
面向服务的设?/font>
在“Component-Based Development for Enterprise Systems”中QAllen 涉及了服务的概念Q“它是将lg描述成提供相x务的物理黑盒装的可执行代码单元。它的服务只能通过一致的已发布接口(它包括交互标准)q行讉K。组件必能够连接到其他lgQ通过通信接口Q以构成一个更大的l”。服务通常实现为粗_度的可发现软g实体Q它作ؓ单个实例存在Qƈ且通过松散耦合的基于消息通信模型来与应用E序和其他服务交互。第 22 늚?2-3 展示了重要的面向服务术语Q?/font>
-
服务Q逻辑实体Q由一个或多个已发布接口定义的契约?
-
服务提供者:实现服务规范软g实体?
-
服务使用者(或请求者)Q调用服务提供者的软g实体。传l上Q它UCؓ“客L”。服务用者可以是l端用户应用E序或另一个服务?
-
服务定位器:一U特D类型的服务提供者,它作Z个注册中心,允许查找服务提供者接口和服务位置?
-
服务代理Q一U特D类型的服务提供者,它可以将服务h传送到一个或多个其他的服务提供者?
?2-3 面向服务的术?/font>
Z接口的设?/font>
在组件和服务开发中Q都需要进行接口设计,q样软g实体可以实现和公开其定义的关键部分。因此,在基于组件和面向服务的系l中Q“接口”的概念对于成功的设计非常关键。下面是一些与接口有关的重要定义:
-
接口Q定义一l公共方法签名,它按照逻辑分组但是没有提供实现。接口定义服务的h者和提供者之间的契约。接口的M实现都必L供所有的Ҏ?
-
已发布接口:一U可唯一识别和可讉K的接口,客户端可以通过注册中心来发现它?
-
公共接口Q一U可讉K的接口,可供客户端用,但是它没有发布,因而需要关于客L部分的静态知识?
-
双接口:通常是成对开发的接口Q这P一个接口就依赖于另一个接口;例如Q客L必须实现一个接口来调用h者,因ؓ该客L接口提供了某些回调机制?
W?23 늚?2-4 定义了客户关pȝ?(CRM) 服务?UML 定义Q它表示Z?UML lgQ实现接?AccountManagement、ContactManagement ?SystemsManagement。在q些接口中只有头两个接口是已发布接口Q不q,后者是公共接口。注意,SystemsManagement 接口?ManagementService 接口构成了双接口。CRMservice 可以实现许多q样的接口,但是它以多种方式行ؓ的能力取决于客户端在行ؓ的实现方面是否允许有大的灉|性。甚x可能l特定类型的客户端提供不同或附加的服务。在一些运行时环境中,q样的功能也用于在单个组件或服务上支持相同接口的不同版本?/font>
?2-4 已实现的服务
分层应用E序体系l构
如前所qͼ面向对象的技术和语言是实现组件的极好方式。虽然组件是实现服务的最好方法,但是您必ȝ解的一ҎQ好的基于组件的应用E序未必构成好的面向服务的应用E序。一旦理解了服务在应用程序体pȝ构中所L作用Q组件开发h员就很有可能会利用现有的lg。进行这U{变的关键是认识到面向服务的方法意味着附加的应用程序体pȝ构层。第 24 中的图 2-5 演示了如何将技术层应用于程序体pȝ构以提供_度更粗的实玎ͼ它更靠近应用E序的用者)。ؓU呼pȝ的这一部分而创造的术语是“应用程序边界”,它反映了服务是公开pȝ的外部视囄极好Ҏ的事实(通过内部重用q结合用传l组件设计)?/font>
?2-5 应用E序实现层:服务、组件、对?/font>
W三部分Q近距离审视面向服务的体pȝ?/font>
面向服务的体pȝ构提供了一U方法,通过q种ҎQ可以构建分布式pȝ来将应用E序功能作ؓ服务提供l终端用户应用程序或其他服务。其l成元素可以分成功能元素和服务质量元素。第 25 늚?2-6 展示了体pȝ构堆栈以及在一个面向服务的体系l构可能观察到的元素?/font>
注意Q?/b>面向服务的体pȝ构堆栈可能是一个容易引起争议的问题Q因为各斚w的支持者已l提Z几种不同的堆栈。我们的堆栈不是作ؓ服务堆栈提出的。我们之所以在此提出它Q是因ؓ我们惌搭徏一个有用的框架Q在本书的剩余章节中Q我们将通过q个框架来组l对 SOA 的讨论?
?2-6 面向服务的体pȝ构的元素
体系l构堆栈分成两半Q左边的一半集中于体系l构的功能性方面,而右边的一半集中于体系l构的服务质量方面。这些元素详l描q如下:
功能性方面包括:
-
传输是一U机Ӟ用于来自服务用者的服务h传送给服务提供者,q且来自服务提供者的响应传送给服务使用者?
-
服务通信协议是一U经q协商的机制Q通过q种机制Q服务提供者和服务使用者可以就要h的内容和要q回的内容进行沟通?
-
服务描述是一U经q协商的模式Q用于描q服务是什么、应该如何调用服务以及成功地调用服务需要什么数据?
-
服务描述实际可供使用的服务?
-
业务程是一个服务的集合Q可以按照特定的序q用一l特定的规则q行调用Q以满业务要求。注意,可以业务流E本w看作是服务Q这样就产生了业务流E可以由不同_度的服务组成的观念?
-
服务注册中心是一个服务和数据描述的存储库Q服务提供者可以通过服务注册中心发布它们的服务,而服务用者可以通过服务注册中心发现或查扑֏用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能?
服务质量斚w包括Q?/font>
-
{略是一l条件和规则Q在q些条g和规则之下,服务提供者可以服务可用于用者。策略既有功能性方面,也有与服务质量有关的斚wQ因此,我们在功能和服务质量两个Z都有{略功能?
-
安全性是规则集,可以应用于调用服务的服务使用者的w䆾验证、授权和讉K控制?
-
传输是属性集Q可以应用于一l服务,以提供一致的l果。例如,如果要用一l服务来完成一业务功能,则所有的服务必须都完成,或者没有一个完成?
-
理是属性集Q可以应用于理提供的服务或使用的服务?
SOA 协作
?2-7 展示了面向服务的体系l构中的协作。这些协作遵循“查找、绑定和调用”范例,其中Q服务用者执行动态服务定位,Ҏ是查询服务注册中心来查找与其标准匚w的服务。如果服务存在,注册中心q使用者提供接口契U和服务的端点地址。下囑ֱCZ面向服务的体pȝ构中协作支持“查找、绑定和调用”范例的实体?/font>
?2-7 面向服务的体pȝ构中的协?/font>
面向服务的体pȝ构中的角色包括:
-
服务使用者:服务使用者是一个应用程序、一个Y件模块或需要一个服务的另一个服务。它发vҎ册中心中的服务的查询Q通过传输l定服务Qƈ且执行服务功能。服务用者根据接口契U来执行服务?
-
服务提供者:服务提供者是一个可通过|络d的实体,它接受和执行来自使用者的h。它自q服务和接口契U发布到服务注册中心Q以便服务用者可以发现和讉K该服务?
-
服务注册中心Q服务注册中心是服务发现的支持者。它包含一个可用服务的存储库,q允许感兴趣的服务用者查找服务提供者接口?
面向服务的体pȝ构中的每个实体都扮演着服务提供者、用者和注册中心q三U角色中的某一U(或多U)。面向服务的体系l构中的操作包括Q?/font>
-
发布Qؓ了服务可访问,需要发布服务描qC使服务用者可以发现和调用它?
-
发现Q服务请求者定位服务,Ҏ是查询服务注册中心来扑ֈ满其标准的服务?
-
l定和调用:在检索完服务描述之后Q服务用者l根据服务描qC的信息来调用服务?
面向服务的体pȝ构中的构件包括:
-
服务Q可以通过已发布接口用服务,q且允许服务使用者调用服务?
-
服务描述Q服务描q指定服务用者与服务提供者交互的方式。它指定来自服务的请求和响应的格式。服务描q可以指定一l前提条件、后|条件和/或服务质?(QoS) U别?
除了动态服务发现和服务接口契约的定义之外,面向服务的体pȝ构还h以下特征Q?/font>
-
服务是自包含和模块化的?
-
服务支持互操作性?
-
服务是松散耦合的?
-
服务是位|透明的?
-
服务是由lgl成的组合模块?
q些特征也是满电子商务按需操作环境的要求的主要特征Q如W?301 “e-business on demand and Service-oriented architecture”所定义的?/font>
最后,我们需要说明的是,面向服务的体pȝ构ƈ不是一个新的概c如?2-8 所C,面向服务的体pȝ构所涉及的技术至包?CORBA、DCOM ?J2EE。面向服务的体系l构的早期采用者还曾成功地Z消息传递系l(?IBM WebSphere MQQ创他们自己的面向服务企业体pȝ构。最q,SOA 的活动舞台已l扩展到包括 World Wide Web (WWW) ?Web 服务?/font>
?2-8 面向服务的体pȝ构的不同实现
SOA 范围中的服务
在面向服务的体系l构中,映射C务功能的服务是在业务程分析的过E中定的。服务可以是l粒度的Q也可以是粗_度的,q取决于业务程。每个服务都有定义良好的接口Q通过该接口就可以发现、发布和调用服务?企业可以选择自q服务向外发布C务合作伙_也可以选择在组l内部发布服务。服务还可以由其他服务组合而成?/font>
服务与组?/font>
服务是粗_度的处理单元,它用和产生由g送的对象集。它与编E语a术语中的对象不同。相反,它可能更接近于业务事务(?CICS ?IMS 事务Q的概念而不是远E?CORBA 对象的概c?/font>
服务是由一些组件组成的Q这些组件一起工作,共同提供服务所h的业务功能。因此,相比之下Q组件比服务的粒度更l。另外,虽然服务映射C务功能,但是lg通常映射C务实体和操作它们的业务规则。作Z个示例,让我们看一?WS-I 供应铄理(WS-I Supply Chain ManagementQ样本的定购单(PurchaseOrderQ组件模型,如图 2-9 所C?/font>
?2-9 定购单组件模?/font>
在基于组件的设计中,可以创徏lg来严格匹配业务实体(如顾客(CustomerQ、定购单QPurchase OrderQ、定购项QOrder ItemQ)Qƈ且封装匹配这些实体所期望的行为的行ؓ?/font>
例如Q定购单QPurchase OrderQ组件提供获取关于已定购的品列表和定购的总额的信息的功能Q定购项QOrder ItemQ组件提供获取关于已定购的品的数量和h格的信息的功能。每个组件的实现都封装在接口的后面。因此,定购单(Purchase OrderQ组件的用户不知道定购单QPurchase OrderQ表的模式、计税金的法、以及定单总额中的回扣?或折扣?/font>
在面向服务的设计中,不能Z业务实体设计服务。相反,每个服务都是理一l业务实体中的操作的完整单元。例如,֮服务响应来自Q何其他系l或需要访问顾客信息的服务的请求。顾客服务可以处理更新顾客信息的hQ添加、更新、删除投资组合;以及查询֮的定单历双Ӏ顾客服务拥有所有与它管理的֮有关的数据,q且能够代表调用方进行其他服务查询,以提供统一的顾客服务视图。这意味着服务是一个管理器对象Q它创徏和管理它的一l组件?/font>
W四部分Q面向服务的体系l构所带来的好?/font>
如前所qͼ企业正在处理两个问题Q迅速地改变的能力和降低成本的要求。ؓ了保持竞争力Q企业必d速地适应内部因素Q如兼ƈ和重l)或外部因素(如竞争能力和֮要求Q。需要经而灵zȝ IT 基础设施来支持企业?/font>
我们可以认识刎ͼ采用面向服务的体pȝ构将l我们带来几斚w的好处,有助于我们在今天q个动荡的商业环境中取得成功Q?/font>
利用现有的资产?/font>
SOA 提供了一个抽象层Q通过q个抽象层,企业可以l箋利用它在 IT 斚w的投资,Ҏ是将q些现有的资产包装成提供企业功能的服务。组l可以l从现有的资源中获取价|而不必重C头开始构建?/font>
更易于集成和理复杂性?/font>
在面向服务的体系l构中,集成Ҏ规范而不是实现。这提供了实现透明性,q将基础设施和实现发生的改变所带来的媄响降到最低限度。通过提供针对Z完全不同的系l构建的现有资源和资产的服务规范Q集成变得更加易于管理,因ؓ复杂性是隔离的。当更多的企业一起协作提供h值链Ӟq会变得更加重要?/font>
更快的响应和上市速度?/font>
从现有的服务中组合新的服务的能力为需要灵zd响应苛刻的商业要求的l织提供了独特的优势。通过利用现有的组件和服务Q可以减完成Y件开发生命周期(包括攉需求、进行设计、开发和试Q所需的时间。这使得可以快速地开发新的业务服务,q允许组l迅速地Ҏ变做出响应和减少上市准备旉?/font>
减少成本和增加重用?/font>
通过以松散耦合的方式公开的业务服务,企业可以Ҏ业务要求更轻村֜使用和组合服务。这意味资源副本的减、以及重用和降低成本的可能性的增加?/font>
说到做到
通过 SOAQ企业可以未雨绸~,为未来做好充分的准备。SOA 业务程是由一pd业务服务l成的,可以更轻村֜创徏、修改和理它来满不同时期的需要?/font>
SOA 提供了灵zL和响应能力Q这对于企业的生存和发展来说是至关重要的。但是面向服务的体系l构决不是灵丹妙药,而迁Ud SOA 也ƈ非一件可以轻而易丑ְ完成的事情。请别指望一个晚上就整个企业系l迁Ud面向服务的体pȝ构,我们推荐的方法是Q在业务要求出现或露头时q移企业功能的适当部分?/font>

]]>