??xml version="1.0" encoding="utf-8" standalone="yes"?> 面向服务的体pȝ构(service-oriented architectureQSOAQ是一个组件模型,它将应用E序的不同功能单元(UCؓ服务Q通过q些服务之间定义良好的接口和契约联系h。接口是采用中立的方式进行定义的Q它应该独立于实现服务的gq_、操作系l和~程语言。这使得构徏在各U这Lpȝ中的服务可以以一U统一和通用的方式进行交互?/p>
q种h中立的接口定义(没有强制l定到特定的实现上)的特征称为服务之间的松耦合?
松耦合pȝ的好处有两点Q一Ҏ它的灉|性,另一ҎQ当l成整个应用E序的每个服务的内部l构和实现逐渐地发生改变时Q它能够l箋存在。而另一斚wQ紧
耦合意味着应用E序的不同组件之间的接口与其功能和结构是紧密相连的,因而当需要对部分或整个应用程序进行某UŞ式的更改Ӟ它们显得非常脆弱?/p>
Ҏ耦合的系l的需要来源于业务应用E序需要根据业务的需要变得更加灵z,以适应不断变化的环境,比如l常改变的政{、业务别、业务重炏V合作伙伴关pR行业地位以及其他与业务有关的因素,q些因素甚至会媄响业务的性质。我们称能够灉|地适应环境变化的业务ؓ按需QOn demandQ?/i>业务Q在按需业务中,一旦需要,可以对完成或执行Q务的方式q行必要的更攏V?/p>
?
焉向服务的体系l构不是一个新鲜事物,但它却是更传l的面向对象的模型的替代模型Q面向对象的模型是紧耦合的,已经存在二十多年了。虽然基?SOA
的系lƈ不排除用面向对象的设计来构建单个服务,但是其整体设计却是面向服务的。由于它考虑Cpȝ内的对象Q所以虽?SOA ?i>Z对象的,但是作ؓ一个整体,它却不是面向对象的。不同之处在于接口本w。SOA pȝ原型的一个典型例子是通用对象h代理体系l构QCommon Object Request Broker ArchitectureQCORBAQ,它已l出现很长时间了Q其定义的概念与 SOA 怼?/p>
然而,现在?SOA 已经有所不同了,因ؓ它依赖于一些更新的q展Q这些进展是以可扩展标记语言QeXtensible Markup LanguageQXMLQؓ基础的。通过使用Z XML 的语aQ称?Web 服务描述语言QWeb Services Definition LanguageQWSDLQ)来描q接口,服务已经转到更动态且更灵zȝ接口pȝ中,非以?CORBA 中的接口描述语言QInterface Definition LanguageQIDLQ可比了?/p>
Web
服务q不是实?SOA 的惟一方式。前面刚讲的 CORBA 是另一U方式,q样有了面向消息的中间ӞMessage-Oriented
MiddlewareQ系l,比如 IBM ?
MQseries。但是ؓ了徏立体pȝ构模型,您所需要的q不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您其需要找C务的?
作和业务中所使用的Y件的操作之间的{换点。因此,SOA
应该能够业务的商业程与它们的技术流E联pv来,q且映射q两者之间的关系。例如,l供应商付款的操作是商业程Q而更新您的零件数据库Q以包括q新
供应的货物却是技术流E。因而,工作还可以?SOA 的设计中扮演重要的角艌Ӏ?/p>
此外Q动态业务的工作不仅可以包括部门之间的操作Q甚臌可以包括与不为您控制的外部合作伙伴进行的操作。因此,Z提高效率Q您需要定义应该如何得知服务之间的关系的策略,q种{略常常采用服务U协定和操作{略的Ş式? 最后,所有这些都必须处于一个信d可靠的环境之中,以同预期的一h据约定的条款来执行流E。因此,安全、信d可靠的消息传递应该在M SOA 中都L重要的作用?/p>
?SOA 的需要来源于需要业务 IT pȝ变得更加灉|Q以适应业务中的改变。通过允许强定义的关系和依然灵zȝ特定实现QIT pȝ既可以利用现有系l的功能Q又可以准备在以后做一些改变来满它们之间交互的需要?/p>
?
面D一个具体的例子。一个服装零售组l拥?500
家国际连锁店Q它们常帔R要更改设计来赶上时尚的潮。这可能意味着不仅需要更Ҏ式和颜色Q甚臌可能需要更换布料、制造商和可交付的品。如果零售商
和制造商之间的系l不兼容Q那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软g程。通过利用 WSDL
接口在操作方面的灉|性,每个公司都可以将它们的现有系l保持现Ӟ而仅仅匹?WSDL
接口q制订新的服务协定Q这样就不必完全重构它们的Y件系l了。这是业务的水^改变Q也是_它们改变的是合作伙伴Q而所有的业务操作基本上都保持不变。这里,业务接口可以作少许改变,而内部操作却不需要改变,之所以这样做Q仅仅是Z能够与外部合作伙伴一起工作?/p>
另一UŞ式是内部改变Q?
在这U改变中Q零售组l现在决定它q将把连锁零售商店内的一些地方出U给专卖行衣服的小商店Q这可以看作是采用店中店Qstore-in-storeQ?
的业务模型。这里,虽然公司的大多数业务操作都保持不变,但是它们现在需要新的内部Y件来处理q样的出U安排。尽在内部软gpȝ可以承受全面的检修,?
是它们需要在q样做的同时不会对与现有的供应商pȝ的交互生大的媄响。在q种情况下,SOA
模型保持原封不动Q而内部实现却发生了变化。虽然可以将新的斚wd?SOA
模型中来加入新的出租安排的职责,但是正常的零售管理系ll如往怸栗?/p>
Z延箋内部改变的观念,IT l理可能会发玎ͼ软g的新配置q可以以另外的一U方式加以用,比如出租_脓h的地方以供广告之用。这里,新的业务提议是通过在新的设计中重用灉|?SOA 模型得出的。这是来?SOA 模型?i>新成?/i>Qƈ且还是一个新的机会,而这L新机会在以前可能是不会有的?/p>
?
直改变也是可能的Q在q种改变中,零售商从销售他们自q服装完全转变C门通过店中店模型出U地斏V如果垂直改变完全从最底层开始的话,׃带来
SOA 模型l构的显著改变,与之一h变的q可能有新的pȝ、Y件、流E以及关pR在q种情况下,SOA
模型的好处是它从业务操作和流E的角度考虑问题而不是从应用E序和程序的角度考虑问题Q这使得业务理可以Ҏ业务的操作清楚地定什么需要添加、修Ҏ
删除。然后可以将软gpȝ构造ؓ适合业务处理的方式,而不是在许多现有的Y件^C常常看到的其他方式?/p>
正如您可以看到的Q在q里Q改变和
SOA
pȝ适应改变的能力是最重要的部分。对于开发h员来_q样的改变无论是在他们工作的范围之内q是在他们工作的范围之外都有可能发生Q这取决于是否有改变
需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发h员不同的是,架构师的作用是引v?SOA
模型大的改变。这U分工,是让开发h员集中精力于创徏作ؓ服务定义的功能单元,而让架构师和建模人员集中_֊于如何将q些单元适当地组l在一P它已l?
有十多年的历史了Q通常用统一建模语言QUniversal Modeling
LanguageQUMLQ,q且描述成模型驱动的体系l构QModel-Driven ArchitectureQMDAQ?/p>
SOA
本n是应该如何将软gl织在一L抽象概念。它依赖于用 XML ?Web
服务实现q以软g的Ş式存在的更加具体的观念和技术。此外,它还需要安全性、策略管理、可靠消息传递以及会计系l的支持Q从而有效地工作。您q可以通过?
布式事务处理和分布式软g状态管理来q一步地改善它?/p>
SOA 服务?Web 服务之间的区别在于设计。SOA
概念q没有确切地定义服务具体如何交互Q而仅仅定义了服务如何怺理解以及如何交互。其中的区别也就是定义如何执行流E的战略与如何执行流E的战术之间?
区别。而另一斚wQWeb 服务在需要交互的服务之间如何传递消息有具体的指导原则;从战术上实现 SOA 模型是通过 HTTP 传递的 SOAP 消息中最常见?SOA 模型。因而,从本质上ԌWeb 是实?SOA 的具体方式之一?/p>
?
我们觉?Web 服务是实?SOA 的最好方式,但是 SOA q不局限于 Web 服务。其他?WSDL 直接实现服务接口q且通过
XML 消息q行通信的协议也可以包括?SOA 之中。正如在别处指出的,CORBA ?IBM ?MQ pȝ通过使用能够处理 WSDL
的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据,那么它们q会需要用相同的消息传递协议,但是数据接口允许相同的信息交换?/p>
既ؓ了徏立所有这些信息的适当控制Q又Z应用安全性、策略、可靠性以及会计方面的要求Q在 SOA 体系l构的框架中加入了一个新的Y件对象。这个对象就?i>企业服务ȝQEnterprise Service BusQESBQ?/i>Q?
它用许多可能的消息传递协议来负责适当的控制、流甚至q可能是服务之间所有消息的传输。虽?ESB q不是绝对必需的,但它却是?SOA
中正管理您的业务流E至关重要的lg。ESB 本n可以是单个引擎,甚至q可以是p多同U和下 ESB l成的分布式pȝQ这?ESB
一起工作,以保?SOA pȝ的运行。在概念上,它是从早期比如消息队列和分布式事务计这些计机U学概念所建立的存储{发机制发展而来的?/p>
?
开发h员的角度来说Q他们用的工具必须知道 SOA 的能力,q允许开发h员有效地使用 SOA 对象。这设?SOA
模型、开发服务和服务对象以及试 SOA
应用E序q些q程包括q来q组成一个整体。因而,开发h员的工作必须为面向服务的应用E序设计/开发(Service-Oriented
Application Design/DevelopmentQSOADQ做好准备?/p>
SOA
可以与许多其他技术结合在一起用,然而,lg的封装和聚合在其中扮演着重要的角艌Ӏ如前所qͼSOA
可以是一个简单对象、复杂对象、对象的集合、包含许多对象的程、包含其他流E的程Q甚臌可以是输出单一l果的应用程序的整体集合。在服务之外Q它?
以看作是单个实体Q但是在其自w中Q它可以hMU别的复杂性(如果必要的话Q。出于性能斚w的考虑Q大多数 SOA
服务q没有下降到单一对象的粒度,q且更适合于大中型lg?/p>
除了可能M开 XML ?WSDL 之外QSOA
q不是特定于语言的。可以用M~程语言来实现服务,只要q种~程语言可以生成服务q且可以?WSDL l合在一起用就可以了。SOAP
本nq不是绝寚w要的Q但它是通用的消息传递系l。因此,可以使用几乎M一U编E语a和支?WSDL 的^台来实现 SOA 中的成员服务?/p>
?
于通用对象h代理体系l构QCommon Object Broker Request
ArchitectureQCORBAQ的应用E序有许多组件必连接到 SOA 中。虽?CORBA 中的接口描述语言QInterface
Description LanguageQIDLQ在概念上类g WSDLQ但它不是严格的Q因而首先需要将其映到
WSDL。另外,需要用更高?SOA 协议Q比如用于流E和{略理的协议)Q而不?CORBA 中的cM的概c请CQ这?CORBA
lgQ表CZؓ服务Q需要与 SOA 服务交互的情况;?CORBA 模型中,所有的独立子集仍然可以像以前一样工作?/p>
由对象管理组
QObject Management GroupQ提出ƈ在许?IBM Rational
产品中得以实现的模型驱动体系l构在一个更抽象的层ơ上?SOA 的概念具有很强的相关性。MDA
Zq样的概念,M软g程都可以定义ؓ模型甚至是元模型Q即模型的模型)Q然后可以将q些模型和元模型转换成应用程序的实际lg。因此,MDA
创徏了一个模型,q个模型先编译成软g应用E序Q而Y件应用程序接着又编译成可执行程序,q样可以在q_上运行了。MDA
q不区分服务和对象这两个概念Q但是它实允许模型由其他子集模型本w组成,q类g BPELQSOA 的一个核心组Ӟ中的程聚合的概c?/p>
SOA ?Web 服务是独立于~程语言的,?Java 是主要的开发语a之一。可以用定义良好的 Java 接口以及各种协议丰富?Java 实现为正在构个模型的开发h员提供了优势。Java 在此担当了开发每个服务的功能、管理数据对象和与其他在逻辑上封装在服务内的对象q行交互的角艌Ӏ?/p>
SOA ?Web 的另一个重要的关系是自主计和|格计算的概c自主计的概念应用于管理分布式服务体系l构的范_具体来说Q就是帮助维护策略和服务U协议以?SOA pȝ的ȝ定性?/p>
?
外,|格计算可以以两个别与 SOA pȝ一起用。网格是分布式计的一UŞ式,它利用分布式Ҏ和服务之间的交互来?SOA
应用E序提供计算支持。在q种情况下,|格起到了框架的作用Q其中实C一些或所有单独的服务。因此,SOA 应用E序可以是网格服务的消费者?/p>
?
另一斚wQ网格本w也可以构徏?SOA 之上。在q种情况下,每个操作pȝ服务都是构成整个 SOA 应用E序的成员,?SOA
应用E序是|格本n。因此,单独的网格组件既可以使用 Web 服务q行通信Q又可以?SOA 的方式进行交互。总而言之,|格pȝ可以?SOA
本nQ也可以提供服务来在其上构徏应用E序U?SOA 模型?/p>
利用 SOA 的好处不仅是一个Y件开发流E,而且q是一个业务开发流E。采?SOA 有四个层ơ,您的实现可以跨越从创建特定的软g服务到将您的业务模型全面转换到按需pȝ的过E。要获得q一步的信息Q您应该阅读q一部分的末ֈ出的文章 “The Four levels of SOA Adoption??br /> SOA 的松耦合Ҏ能够适应业务需求的灉|性,当服务内部结构及实现发生改变时它能够l箋存在从而降低了软g二次开发的成本?SOA 好比是一个服务中介将不同pȝ、不同^C的操作通过它联pv来,而实现各U服务和数据的交互,满市场快速变化的需?
定义SOA 员工培训 建立SOA委? Z保证独立应用和服务复用过E中企业的应用重点不发生偏移Q企业有必要建立一个SOA的管制委员会。许多SOA文献和实践者将q种l织UCؓ集成能力中心QIntegration Competency CenterQICCQ? 学着“眼高手低?br />最
后一点,也是重要的,卛_实施SOA的初期不要过于热情了。因是一w期工作。历史证明,在IT行业中用蘪炸式的工作方法很隑֥效。小规模的渐q式
发展成功的几率却高许多,因ؓq种变化更易于管理。幸q的是,事实证明Q渐q式的方法在实施SOA的过E中非常有效Q因U架构允怼业一ơ实施一Ҏ
务? 目前Q关于由 Service-oriented ArchitecturesQSOAQ和它的 Web 服务实现所表现的时机有许多传言 --
有一些是有事实根据的Q但是一些却没有什么事实依据。分析家已经预言Q博学者已l声Uͼ教授已经讲演Q公司已l匆忙的卖他们的产品Q作?SOA 产品
-- l常失去 SOA 不是一个品的要点。它是业务和 IT 之间的桥梁,通过一pd使用一些设计原则、模式和技术的依赖于业务的 IT
服务来实现?/p>
ZDNet 最q报道说Q“Gartner 预言C 2008 q_臛_ 60% 的企业将使用 SOA 作ؓ创徏d苛刻的应用程序和q程的“指导原则”?
开发和实现 SOA 有很大的需求。因此如?SOA 不仅仅和产品和帮助实现它的标准相养I比如通过 Web 服务Q,那么Z实现 SOA 你还需要什么附加的元素吗?
Z服务的徏?/i>需要其他的行ؓ和构Ӟq些在传l的Z对象的分析和设计QOOADQ中是不存在的。?
Z服务的分析和设计的元?/a>”这文章描qC一些最初的原因Q解释了Z么你需?OOAD 之外更多的内宏V它同样描述了业务流E管理或企业架构QEAQ和 OOAD Z么不是管理分析和设计的适当手段。同P?IBM Redbook 中名??
模式QService-Oriented Architecture ?Web Services”的文章中,我D例说明了Z服务的徏模方法的主要zd?
然而,你还需要重视一些额外的重要的需要考虑的事V首先,目前?OOAD Ҏ没有定位 SOA 三个重要的元素:
服务Q?
?/i>Q和实现服务?
lg。你同样需要可以明定位鉴别、制定和实现服务所需的技术和q程Q它们的程和组合,以及实现和确保所需服务质量的企业lg?
W?
二,需要进行范例的替换Q以便更好的区分 SOA
的两个关键角色之间的截然不同的需求:服务提供者和服务消费者。第三,假设Z个企业或者业务线构徏的应用程序,现在必须被提升到一个供应链中用,q且
公开l合作伙_q些合作伙伴可能l合、联合和装应用E序C个新的应用程序中。这是服务生态系l或者服务h值网的概c?/p>
q?
是仅从“分布式对象”的一个微的q步。它是关于通过|络作用创造的价|例如Q当合作伙伴利用?Amazon.com ?Google
搜烦的联合,q且?eBay
服务l合在一P来构Z们自q混合解决Ҏ。或者当旅行C深入到机票预订pȝQƈ且与汽RU赁公司以及N怺协调Q更C们的记录q且旅行计划发
送到你的电子档案中。无Z么样的应用程序,你如果想成功地创?SOAQ需要的都不仅仅是好的工具和标准。你需要一些规范的步骤来支持你?SOA
生命周期Q用来分析、设计、实现服务、流E和lg的技术。因此,对于M对企业应用程序开发感兴趣的h来讲Q理解基于服务的建模和架构中包含的细节步骤是
非常重要的?/p>
在我详细描述q些步骤以前Q我们首先应理解你打要做什么:
什么是 SOAQ以及它看v来像是什么??
定义?SOA 后面的概念和观点以后Q我描q?SOA 的层和你如何去记录每个层中的关键架构决策Q这些层帮助你ؓ SOA 构徏蓝图Q这?
SOA 正是那些你试囑一pd实现?SOA 服务、流E和lg集成以及出现的项目、业务线、企业成果和h值链所需要的?
Service-Oriented ArchitectureQ概忉|?/span>
q?
个概念基于一U架构样式,该样式在三个主要参与者之间定义了交互模型Q服务提供者,公布服务描述q且实现服务Q服务消费者,他既可以使用l一资源标记W?
QURIQ来直接使用服务描述Q也可以在服务注册中心来查找服务描述q且l定和调用服务。服务代理提供和l护服务注册中心Q然而现在ƈ没有通用公共注册?
心?/p>
?1 是一个显CZq些关系的元模型?
定义 SOA 的架构样式描qC一pd模式和指导方针来创徏
松耦合Q依赖业?/i>的服务,׃描述、实现和l定之间关系的分,为新业务q象和机会提供了I前的灵zL?
SOA
是企业?IT 架构Q用来按需q接资源。在 SOA
中,资源对于价值网、企业、业务线内的参与者时可用的(典型的是在一个企业内或多个企业之间跨多个应用程序)。它׃pd依赖业务?IT
服务l成Q这些服务共同满了l织的业务流E和目标。你可以这些服务设计成合成的应用程序ƈ且通过标准协议来调用它们,如下面的 ?2所C?
服务是一U有具体服务描述的Y件资源(可发玎ͼ。服务消费者可以搜索、绑定和调用服务描述。服务提供者实现服务描q的功能q且向服务消费者提供所需的服务质量。理Z服务应该l一由公布的斚w来管理,q且因此支持动态的
可配|架构样?/a>?
灉|的业务通过灉|?IT pȝ可以实现Q主要通过接口、实现和 SOA 提供的绑定(协议Q的分离Q基于新业务需求,允许在及时给定的点g?
选择服务提供?/i>Q(功能和非功能Q例如,性能、安全、可伸羃性等Q需求)?
你可以在内部业务单元之间或者在业务伙伴之间的h值链之间?
不规则的实现模式?
重用此服务。不规则的实现引用了架构样式的能力来在他的交互模型中通过合成的方式来应用与参与者关联的模式和角艌Ӏ你可以在架构中的一层上应用它,也可?
在诏I企业架构的多个层上来应用它。在目之间Q它可以通过l一的、概念上可升U的方式在h值链内部的业务单元和业务伙伴之间? 在本文中Q我介绍了鉴定、指定和实现的高U别的行为和一些基于服务徏模的构g。基于服务的建模是基于服务的分析和设计(SOADQ过E,来徏模、分析、设计和生依赖业务分析、过E和目标?SOA?/p>
首先我将看一下你惌构徏什么,也就?SOA 和它的层。接下来我将通过讨论创徏 SOA 所需主要的活动和技术来描述如何构徏 SOA?/p>
作ؓ一个示例,我们假设你正在开发一个项目,q且目标是将一部分h自服务帐目系l的银行业务U移植到 SOA上?/p>
ZUL?SOAQ你需要一些超出服务徏模的附加元素。它们包括:
?
面的关于UL?SOA
和实C后附加活动的讨论应该得到它们自己的文章,本系列中我将在随后的列中接触到这个。目前,让我们假设你为项目定义了范围Qƈ且决定了集中在什么地
方:已经定义了一个焦点,用来现有的pȝ或服务{化到一pd新的pȝ和服务。现在你可以开始基于服务徏模来构徏你的Z服务的架构?/p> SOA 的一个抽象观点将它描qCؓ与业务过E结合在一L合成服务的部分分层架构?
?3 呈现了这U类型的架构?
?
务和l徏之间的关pLQ企业的组Ӟ大粒度的企业或者业务线lgQ实现该服务q且负责提供它们的功能和l持它们的服务质量。通过l合q些公开的服务到?
成的应用E序Q就可以支持业务q程。综合的架构通过使用 Enterprise Service
BusQESBQ支持这些服务、组件和程的\由、中介和转化。ؓ了服务质量和非功能性的需求,必须监视和管理已l部|的服务?/p> 对于每一层,你都必须做设计和架构军_。因此,Z帮助用文件说明你?SOAQ你可能应该创徏文档Q由每个层相应的部分所l成?/p> q里是ؓ你的 SOA 架构文档设计的模板:
?1Q操作系l层?/b>本层包含现有的自定义构徏的应用程序,也叫?
遗留pȝQ包含现有的 CRM ?ERP 打包应用E序Q以?
较旧?/i>Z对象的系l实玎ͼq有业务应用E序。SOA 的复合层架构可以利用现有的系lƈ且用Z服务的集成技术来集成它们?
?2Q企业组件层?/b>本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特D的lg是企业和业务单元U支持的企业资的受理和控制的集合?
同企业范围资产一P他们通过架构最佛_践应用程序来负责保 SLAs 的一致。大多数情况下,本层使用Z容器的技术,比如实现lg、负载均衡、高可用性和工作量管理的应用服务器?
?3Q服务层?/b>业务选择来支持和公开的服务处在这一层。它们可以被
发现?
者直接静态绑定,接下来被调用Q或者可能的话,~排到合成服务中。这个服务公开层同h供了获取企业范围lgQ业务单元特定组Ӟ以及有些情况下,特定?
目组建的机制Qƈ且以服务描述的Ş式具体化了他们的接口子集。因此,企业lg使用它们接口提供的功能在q行时提供服务实现。在q一层的接口公开Z个服?
描述Q在q层中他们被公开以提供用。他们可以独立存在或者作为合成服务? ?4Q业务过E合成或~排层?/b>W三层中公开
的服务的合成和编排在q一层中被定义。通过配合、编排,服务被绑定成一个流E,q且从而作为单独的应用E序而共同作用。这些应用程序支持特D的用例和业?
q程。这里,可视的流E合成工P比如 IBM] WebSphere] Business Integration Modeler 或?
Websphere Application Developer Integration EditionQ都可以用来设计应用E序程? ?5Q访问或表现层?/b>管q一层经常超Z
围绕 SOA 讨论的范_但是它却变得来有意义。在q里我描q它因ؓ标准来集中,比如用于 Remote Portlets Version
2.0 ?Web 服务和其他技术,q些技术追求在应用E序接口或者表现层来利?Web
服务。你可以把它作ؓ来的层用来满来的解x案的需求。注意到以下q两Ҏ非常重要的:SOA
用h口从lg中分d来;最l你需要提供从讉K路线到服务或者合成服务的端到端解x案? ?6Q集成(ESBQ?/b>q一层服务可以集成Q通过引入一pd可靠的性能的集合,比如路由Q协议中介和其他转化机制Q经常被描述?ESBQ参?
参考资?/a>Q。Web Services Description LanguageQWSDLQ制定了l定Q其包含提供服务的地址。另一斚wQESB 为集成提供了位置独立机制?
?7QQoS?/b>q?
一层提供了监视Q管理和l持诸如安全Q性能和可用性等 QoS 的能力。这是一个通过 sense-and-respond 机制和监?SOA
应用E序健康的工hq行的后台处理过E,包括 WS-Management 和其他相兛_议的所有的重要的标准实C及ؓ SOA
实现服务质量的标准? 本节描述了如何利用遗留的投资Q来
联合自顶向下的,业务驱动的手D和自底向上的手Dc?
Z服务的徏模手D|供了建模、分析、设计技术和zd来定?SOA 的基。它通过?SOA 的每一层定义元素以及在每一层作严格的架构决{来起到帮助作用。它通过联合服务鉴别的自向下、业务驱动方式和通过利用遗留资和系l引导服务鉴别来实现q一炏V?/p> q样Q高U别的业务过E功能性ؓ大粒度的服务更加的具体化。小_度的服?-- q些可以帮助实现高别的服务 -- 通过查遗留功能性和军_如何创徏适配器、封装器Q或者组合遗留系l来具体化系l内l常调用的期望功能性可以来鉴别?/p> q个功能性业务需求和遗留pȝ中现有投资利用的l合Qؓ那些惌快速赢得和UL他们的企业到一个现代的 SOA 的组l提供了有效的解x案。通过Z服务的集成的软g应用E序的联合因此变得具备可能性?/p> Z服务的集成是 Enterprise Application IntegrationQEAIQ的一个进化,?EAI 中,所有的q接通过位置透明?ESB 概念被基于标准的链接替换Qƈ提供了一pd灉|的\由、中介和转化能力?/p> q今为止Q我已经通过描述 SOA 讑֮了阶Dc我同样展示了要x?SOAQ你需要在?SOA 的每个层中做关键架构决策Qƈ且你的设计必d映一pd依赖业务的服务和关于他们如何通过~排来合成到应用E序的决{?/p> 与对象不同,你在 SOA 中需要考虑两个观点Q他们是服务消费者和服务提供者。服务代理目前不是主,q且在后面的部分l将被涉及到?/p> SOA 的设计策略ƈ不从“自底向上”开始,q是 Web Z服务途径常有的事情。你必须CQSOA 更加有战略意义,q更加依赖于业务。Web 服务?SOA 的y妙实现。许多关键的zd和决{存在不仅仅影响集成架构Q而且q媄响企业和应用E序架构。他们包含两?
?4 中描q的消费者和提供者的zd.
?4?
CZ通过提供者和消费者的每个角色来管理的zd。注意,提供者的zd是消费者活动的爉Q例如,提供者同样参与服务鉴别、分cȝQ。在许多情况下,角色?
区别来自如下的事实,消费者指定他们想要的服务Q经常的搜烦它,q且一旦他们确信和他们L的服务规范相匚wQƈ且是由服务提供者提供,他们׃Ҏ需?
l定和调用服务。提供者需要依ơ发布他们想要支持的服务Q即在功能方面,更重要的是在消费者所需?QoS
斚w。这个在消费者和提供者之间的隐含的契U可能在 SLA 斚w成熟为明的契约Q自动的或者通过业务和合法区域来处理? 上面描述的活动可以被描述为在Z服务的徏模和架构Ҏ内流动,如下面的
?5 所C?
Z服务的徏模和架构q程包含三个主要的步骤:服务Q组件和程Q典型地Q服务的~排Q的鉴别Q指定和实现?/p> q个q程由域分解、现有资产分析和目标服务建模的自向下、自底向上、中间向外技术的联合l成。在
自顶向下视图?/i>Q业务用例的蓝图提供了业务服务的规范。这个自向下的q程作ؓ
域分?/i>来被引用Q域分解׃务领域到它的功能区域和子pȝ的分解组成,包含它的程或过E分解成q程、自q程和高U别业务用例。很多情况下Q这些用例是公开在企业边~的业务服务Q或者在贯穿业务U企业边界内所用的非常好的候选?
在过E的
从下C的部?/i>或?
现有pȝ分析中,现有的系l被分析和选择作ؓ可行的候选,来ؓ支持业务q程的底层服务功能性实现提供低消耗的解决Ҏ。在q个q程中,你分析和利用了来自遗留和打包应用E序?API、事务和模块。在有些情况下,Z支持服务的功能重新模块化现有的资产需要遗留系l的lg化?
中间向外视图?
目标服务建模l成Q来验证和发现自向下或自底向上的服务鉴别手D中没有捕捉到的其他服务。它服务连l到目标和子目标、关键性能指示和尺度?
q?
个活动在服务被指定时开始。将服务分为服务层ơ是非常重要的,反映了服务的复合或者不规则的本性:服务可以也应该由良好_度的组建和服务l成Q分U帮?
军_合成和分层,以及Z层次的相互依赖服务的协同构徏。同P它帮助减L务增值综合症Q这U症状中Q越来越多的粒度的服务被定义、设计和部vQ却~?
乏控ӞD了主要的性能、可伸羃性和理问题。更加重要的是,服务增值未能提供服务,q些服务对业务是非常有用的?/p> q?
个活动获取上面域分解q程中发现的子系l,q且指定子系l之间的怺依赖和流E。它同样域分解q程中鉴别的用例作ؓ子系l接口上公开的服务。子pȝ的分
析包含创建对象模型来表现内部工作方式Q以及所包含的公开服务q且实现它们的子pȝ设计。这Ӟ“子pȝ”的设计l构实Cؓ大粒度组件实现构造,在下?
的活动中实现服务?/p> 在下面的主要zd中,实现服务的组件的l节指定:
服务分配包括分派服务到目前鉴别的子系l。这些子pȝh实现了他们所公布的功能的企业lg。你l常会简单化假定Q子pȝ同企业组件有一对一的联pR?
l构化组?/i>在你使用模式来构?
企业lg时会通过以下几点的联合的形式出现Q?
q?
个步骤指出实现给定服务的软g必须被选择或者自定义构徏。其他可用的选项包括使用 Web
服务来集成、{化、订阅和外购不同功能。在q个步骤中,你决定哪个遗留系l模块用来实现给定的服务Q以及哪个服务将从基来构建。服务的其他实现决策不同
于业务功能包括:服务的安全、管理和监视?/p> 事实上,目向于利用Q意数量的相应的努力来满关闭的机会窗口。因此,我推荐ƈ行的理三个?/p> 自顶向下的域分解Q过E徏模和分解Q基于变更的分析Q方针和业务规则分析Q领域特定行为徏模(使用语法和图表)Q是同供lg化(模块化)和服务公开候选的现有遗留资的分析ƈ行控制。ؓ了获得项目背后的业务意图和服务同业务意囑֯切合作,目标服务建模可以来控制?/p> ?
文中Q我以基于服务架构、它的层和架构决{的相关cd的基知识来开始。接下来Q我通过一U方法,描写了基于服务徏模的zdQ以及从服务消费者和提供者角
度来看活动的重要性(服务代理在后面的文章中涉及刎ͼ。这U方式ؓ军_Z服务架构的三个基斚w提供了在分析和设计活动方面详l的指导Q服务,程?
实现服务的组件。我q描qC一个模板,你可以用它来?SOA 的每个层上ؓ你的架构q行决策?/p> 我提CQ对于服务鉴别,自顶向下、自底向上和跨部分、目标模型分析三U手D늚l合非常重要。接下来我关注了一下服务指定和实现的主要活动?/p> q一pd的下一文章中Q我应用该Ҏ到帐L理的I领域中Qƈ且用例子来描q每个步骤。除鉴别、指定和实现之外Q我q将讨论Z服务建模手段的其余活动,包含用来支持完整?SOA 生命周期的部|Ӏ监视、管理和控制?/p> ?
者希望象下面q些敬的同事和朋友致谢Q感谢他们宝늚和反馈(无特定顺序)QLuba CherbakovQKerrie
HolleyQGeorge GalambosQSugandh MehtaQDavid JansonQShankar KalyanaQEd
CalunzinskiQAbdul AllamQPeter HolmQKrishnan RamachandranQJenny
AngQJonathan AdamsQSunil DubeQRalph WiestQOlaf ZimmermanQEmily
PlachyQKathy Yglesias-ReeceQ以?David Mott?/p> 最初的面向服务的体pȝ构(Service-Oriented ArchitectureQSOAQ?
的实现项目的l验表明Q诸如面向对象的分析与设计(Object-Oriented Analysis and
DesignQOOADQ、企业体pȝ构(Enterprise ArchitectureQEAQ框架和业务程建模QBusiness
Process ModelingQBPMQ这L现有开发流E和表示法仅仅涵盖了支持目前出现?SOA 中的体系l构模式所需的部分要求?/p>
?Info World 最q的访谈Q请参见 参考资?/a>Q中QGrady Booch 宣称“像寚w题的良好抽象和良好的分离q样的工E基决不会过时”,不过Q他也指出“还是有现实的机会提升抽象的U别。过ȝl验表明Q必d抽象的别提升到公司处理?业务领域Q从而将整个企业 IT 前景都纳入考虑的范畴? 正如 Mark Colan 在文?“面向服务的体系l构扩展 Web 服务的前景,W?1 部分?/a>中介l的QSOA 是一U新兴的企业l构形式Q可以用于设计下一代企业应用程序。SOA Ҏ在有力地加强已经制定的良好通用软g体系l构原则Q如信息隐藏、模块化和问题分)的同Ӟq增M一些其他的主题Q例如服务编排、服务库和服务ȝ中间件模式? 需要结构化Ҏ?分析与设计方?/em>来设计高质量?SOA。因为现有的Ҏ中没有一U能够满程序设计h员对最新的 SOA 目的要求,所以他们徏议将已经形成的良好实践(?OOAD、EA ?BPMQ中的原理组合v来,q且使用Ҏ需要创新的原理来对其加以补充? 面向服务的体pȝ构(SOAQ和 Web 服务的基本观忉|成ؓ我们日常语言的一部分Qƈ可看作是适于设计C企业应用E序的体pȝ构Ş式。在q种背景下,
什么构成好的服?/i>q个基本问题成为确保成功实?SOA 的关键?
?
面向对象的分析与设计QObject-Oriented Analysis and DesignQOOADQ?/i>?
企业体系l构QEnterprise ArchitectureQEAQ框?/i>?
业务程建模QBusiness Process ModelingQBPMQ?/i>q样的现有徏模规则ؓ我们提供了高质量的实践,可以长期帮助标识和定义体pȝ构内的适当抽象。然而经验表明,q些实践各自单独应用时达不到要求?
在本文中Q我们将研究 OOAD、EA ?BPM 中的适当原理。我们还推动对混合Ҏ的需求,q种Ҏ把所有这些规则中的原理与许多独特的新原理l合h。这样得到的交叉学科 OOAD Ҏ使成功地q行 SOA 开发更ҎQ我们称之ؓ
面向服务的分析与设计QService-Oriented Analysis and DesignQSOADQ?/i>Q它q有待正式定义。我们还只是刚刚跨入 SOAD 的殿堂?
在发现新的商机或威胁的预期下QSOA 体系l构形式旨在提供企业业务解决ҎQ这些业务解x案可?
按需扩展或改变。SOA 解决Ҏ由可重用的服务组成,带有定义良好且符合标准的已发布接口。SOA 提供了一U机Ӟ通过q种机制Q可以集成现有的遗留应用E序Q而不它们的q_或语a?
从概念上ԌSOA 中有三个主要的抽象别: ?SOA 术语中,业务程包括依据一l业务规则按照有序序列执行的一pd操作。操作的排序、选择和执行称为服务或程
~排。典型的情况是调用已~排服务来响应业务事件?
早期?SOA 实现目l验表明Q诸?OOAD、EA ?BPM q样的现有开发流E和表示法仅仅涵盖支?SOA 范式所需的部分要求。SOA Ҏ在加强已l制定的良好通用软g体系l构原则Q如信息隐藏、模块化和问题分)的同Ӟq增M附加的主题,例如Q?
服务~排?
服务?/i>?
服务ȝ中间件模式,在徏模时需要对它们l予特别的关注?
?1展示了现有的 EA、BPM ?OOAD 建模Ҏ的主要应用领域,也是我们随后讨论 SOAD 的出发点。图中的水^轴表C?
目生命周期阶段Q垂直u表示不同抽象层或
领域之间的区别,而徏模活动通常是在其上进行的?
SOA
的远景是相当Ҏ理解的,因ؓ它的技术基众所周知。例如,在Q?SOA 工作中,应用通用的Y件体pȝ构原则和 OO
技术都是一个有效的开端。然而,正如我们已经提到的,早期采用者最常询问的问题是如何标识正的服务。如前所qͼOOAD、EA ?BPM
在各自独立地应用时不能提供满意的{案Q而这正是我们现在要说明的?/p> 在由
Booch ?Jacobson?
写的开创性的书(大约 10 q前出版的)中介l的 OOAD Ҏ在定?SOA
斚w提供了非常好的v炏V同样地Q虽然许多年来在体系l构层次中应?OOAD 技术和l一建模语言QUnified Modeling
LanguageQUMLQ表C法是一个常见的实践Q但?OOAD
q是与像cd单独的对象实例这L微观层次的抽象有兟뀂由于每个问题域常常都创建单独的用况模型Q因此,应用E序开发项目,q个企业的大方向在许多情况下
变得模糊。此外,׃U种原因Q用冉|型ƈ不L与其对等?BPM 保持同步? 诸如
Treasury 企业体系l构框架QTreasury Enterprise Architecture FrameworkQTEAFQ?/a>?
面向特征的领域分析(Feature-Oriented Domain AnalysisQFODAQ?/a>?
Zachmanq样?EA Ҏ都将城市规划U的观点加在解决Ҏ体系l构之上Q但是ƈ没有解决如何扑ֈ易于重用且具有持久性的高质量企业抽象的问题?
虽然 BPM ҎQ如
BPMIQ在功能工作单元之上提供了端到端视图Q但是它们通常都没有触及体pȝ构和实现领域。例如,在像
用于 Web 服务的业务流E执行语aQBusiness Process Execution Language for Web ServicesQBPELQ?/i>q样的语a出现之前QBPM 表示法缺操作语义。此外,我们q看C许多程建模与开发活动彼此分ȝ情况?
最后,现有的规则中没有一个可以解军_何ؓ SOA 启用
现有的应用程?/i>的问题;大部分时间都采用自顶向下程。现有的pȝ通常都存放有大量的重要数据和业务逻辑Qƈ且不能简单地加以替代。因此,Z研究包装和重构策略,必须对这些系l进行自底向上的分析。因此,对现有应用程序的考虑会将我们带到中间盔R的流E?
׃q些原因的存在,所以需要?SOAD 建模Ҏ。这U方法以最佳的方式l合?OOAD、BPM ?EA 中的原理Qƈ且融入了一些具有创新性的原理?
?2展示了这U新的方法的 SOAD 资源Q原理和技术)Q?
企业应用程序和 IT 基础设施发展?SOA 可能是一个大的负担,会媄响多个业务线和组l单元。因此,需要应?EA 框架和参考体pȝ构(?
开攄l体pȝ构框ӞThe Open Group Architecture FrameworkQTOGAFQ?/a>Q以?ZachmanQ以努力实现单独的解x案之间体pȝ构的一致性?
?
据过ȝl验Q大多数现有?EA
框架都在一个或多个斚w有限制。例如,如果主要的问题是表示技术设备的低构块如何在宏观层ơ互q,则无法获得业务层程或服务视图。然而,?SOA
的背景下Q这U考虑问题的方式必{换ؓ以表CZ务服务的逻辑构gZ心,q且集中于定义服务之间的接口?服务U协定(Service Level AgreementsQSLAQ?/i>?
此外Q许多企业参考体pȝ构和框架是相当普通的Qƈ没有触及设计领域。这L高体系l构无法为架构师和开发h员提供具体的战术意见Qƈ且常常导致企业体pȝ构和解决Ҏ体系l构之间出现Ҏ性的分歧?/p> SOAD 必须帮助 SOA 架构师定义服务前景的整体业务U视图。这是当今的 EA 框架所无法提供的,它们需要未来特定于 SOA 的增强;
按需操作pȝQOn Demand Operating EnvironmentQODOEQ?/a>?IBM 针对q种势制定的主要战略?
BPM 是一个不完整的规则,其中有许多不同的形式、表C法和资源。另一U常用的技术是定义表示概念性流E流?
事g驱动程?/i>Q正?
Barker ?Longman所定义的。这W二U技术用了不同?UML 的表C法?
?
外,q有许多专用ҎQ如 BPM 技术)可能被咨询公司和企业资源规划QEnterprise Resource
PlanningQERPQY件包厂商视ؓh竞争优势。ARIS Implementation Platform
是q样的品的一个例子。其他的Ҏ包括Q?Line of Visibility Enterprise Modeling(LOVEM) ?IBM 的组件业务徏模(Component Business ModelingQCBMQ战略?
最q的势是定义表C可执行模型(?
用于 Web 服务的业务流E执行语aQBusiness Process Execution Language for Web ServicesQBPELQ?/a>Q的标准Ҏ。BPEL 流E的范围从分析扩展到实现。这L可执行模型引发了一pd的新问题Q其中包括:
必须利用所有现有的 BPM Ҏ作ؓ SOAD 的v点;然而,必须使用程模型中用于驱?
候选服?/i>和它们的操作的附加技术来对其加以补充。此外,SOAD 中的程建模必须与设计层用况建模保持同步Qƈ且必ȝZ BPEL 有关的问题的{案?
OO 分析是一U非常强大且qؓ赞誉的方法,同样QSOAD 应该可能多地利?OO 分析技术。要?OO 分析成功地应用于 SOA 目Q您必Mơ分析多个系l。用冉|型必ȝl扮演重要的角色。然而,SOAD 必须主要?
程Q而不?
用户驱动?/i>。因此,SOAD 需?BPM 和用况徏模活动之间的强链接?
?
设计层,
OO 的目标是能够q行快速而有效的设计、开发以及执行灵zM可扩展的应用E序。对象是软g构造,其行为就像它们徏模的真实世界的实体。例如,֮
(Customer) 有名称和联pM息,q且q可能有一个或多个与之相关的帐户对象。从 OO 的角度看Q每件事情都是对象? OO的基本原则是Q?/p> OO 支持应用E序分析、设计和开发的完整生命周期Q?/p> 目前?SO 有关?OO 设计实践的主要问题在于,它的_度U别集中在类U,对于业务服务建模来说Q这L抽象U别太低了。诸如承这L强关联生了相关方之间一定程度的
紧耦合Q因而具有依赖性)。与此相反,SO 范式试图通过
松耦合来促q灵zL和敏捷性。目前,?SOA 中还没有服务
实例的跨q_l承支持和一的表示法来避免需要处理服务生命周期维护管理问题(如远E垃圾收集)?
q?
些考虑事项?OO 难以?SO 体系l构样式直接保持一致。然而,对于设计已定义的服务中的底层cdlgl构QOO
仍然是一U有价值的Ҏ。此外,许多 OOAD
技术(例如cR责仅R协作(CRCQ卡Q也可以用于服务建模Q如果它们提升到更高层次的抽象的话)。在本文后面Q我们将回过头来讨论q一炏V?/p> ?4展示了可见性层ơ和 OO?
面向lg?SO 设计提供的重点之间的对应关系。它q展CZ?SOA ?SOAD 背景中它们之间的怺关系?
至于表示法,l一建模语言QUnified Modeling LanguageQUMLQ——通过一些附加的定型QStereotypeQ和概要加以增强——自然成?SOAD 的重要基?/p> 在?
Rational Unified Process (RUP)—?
被认为是支持q代软g开发的分析与设计的L OOAD 程之一——的程斚wQ?UML 模型h首要价倹{然而,RUP ?OOAD
的原则ؓ基础Q因而其不Ҏ?SOA 设计保持一致。从 RUP
的角度来看,pȝ的体pȝ构是光过已定义接口交互的主要lg的体pȝ构。此外,q些lgq由逐渐减小到类U粒度的更小lgl成。相反,?SOA
中,pȝ的体pȝ构通常包括满普?业务服务需要的无状态、全装且自描述的服务组成,它更接近于映到 BPMQ如
?5所C?
q些服务可能包括许多协作或编排服务。这q没有排?RUP 采用?OO 观点Q而是在其上实C另一个抽象层。这个超层的作用是封装作为正式的跨层接口l构中的 RUP 构gQ?
软g服务Q设计的lg?
在这一部分中,我们更详细地描q?SOAD 的需求,q且开始确定它的主题和原理。目的是关于这个主题的讨论引到q一步的设计工作。进一步的工作无疑需要Ş式化 SOAD Ҏ?/p> 已经?SOAD 定了下列需求: 一些通用原则或品质因素已l确定,q且可以作ؓ SOAD 中的设计基准Q?/p> 自顶向下的业务建模技术(?CBMQ可以ؓ SOA 建模zd提供L。但是正如我们在前面提到的,SOA 实现很少是在全新的项目中开始的Q创?SOA 解决Ҏ几乎总需要涉及集成现有的遗留pȝQ方法是它们分解成服务、操作、业务流E和业务规则Q同时参?
?6Q:
所有的 OOAD 都同标识和定义服务有养I但是q需要具有更高层的观炏V此外,?SOA 致力于比l典开发项目层ơ更高的开发时Q就有了发挥其他创造性思维的空间?/p> 直接和间接业务分?/b> q去的经验表明,q条主要的途径应该通过补充
间接技
术来加以改进。在选择候选服务时Q品经理和其他业务领导应该q行协商。例如,什么是计划付款和开模型?应该商议假定使用正在构徏中的pȝ的企业的l织
l构图。徏议还考虑一下非 SOA
目中Q何现有的用况模型。用于对正在构造的pȝq行营销介绍的术语是另一个很好的关于服务操作候选者的来源Q特别是动词Q很关注营销动词Q)? 域分?/b> 服务_度 命名U定 除了l合 OOAD、BPM ?EA 技术之外,q有几个重要?SOAD 概念和方面有待充实: 服务分类和聚?/b> 服务l合可以通过可执行模型(?BPEL 建模的模型)来加以简化;q是传统的徏模工具和Ҏ不能处理的事情?/p> {略和方?/b> 除了已经制定的良?
体系l构可跟t?/i>原则之外Q?
业务可跟t?/i>也是一个理想的品质Q应该有可能所有的q行时构件直接与非技术领域专家可以理解的语言联系h。这对于直接在业务和服务层公开的抽象非帔R要。Sarbanes-Oxley (SOX) 法案Q请参阅来自
Astor的文章)是需要这U业务可跟踪性的业务驱动E序的一个例子?
程Q中间相?/b> ?
设计取决于现有的 IT
环境而不是现在和来的业务需要的情况下,自底向上的方法往往会导致不好的业务服务抽象。而自向下的Ҏ可能会生不的非功能性需求特征,q且损害?
他的体系l构品质因素Q例如因域模型中~Z标准化而导致的性能问题Q,另外Q也会在服务和组件中产生不匹配的不良问题?/p> 服务获取和知识代?/b> 应该重用看作是标识和定义服务最主要的推动标准之一。如果组Ӟ或服务)不可能重用,׃无法其作ؓ服务q行部v。它可以q接到另一个与企业体系l构相关的服务,但是不能单独作ؓ一个服务而存在?/p> 然而,即从开始就计划好了重用Q还必须形式化服务获取流E。由多个使用者用服务是明确?SOA 设计目标。构建时服务注册中心Q例如企?UDDI 目录Q可能能够解决部分问题?/p> 汽R工作订单QAutomotive Work OrderQ描qC一家汽车维修公司管理其֮q营的流E。我们将通过q个领域中的问题来阐q?SOAD 的观炏V?/p> 工作订单代表汽R服务公司和顾客之间的U定Q以q行一pd例行l修或应急维修,例如例行 50,000 英里服务Q更换刹车片或轮胎,或者换沏V?
业务场景Q如
?7所C)如下Q?
如果您将此作Z个独立的应用E序从头开始创建,您就可能创徏一l如
?8所C的cR?
如果您将工作订单构造ؓ一?OO 应用E序Q这些Y件对象将包含所有必需的业务规则,q且理解应该遵@的业务流E?/p> 然而,q种Ҏ在实跉|面存在着一些缺点: SOAD 些问题提供了极好的解x案。由于它Z相关的行为对服务q行分组Q而不是进行封装(行ؓ及数据)Q所以这l服务与业务对象略有不同?/p> ?
如,您可能将工作订单QWork OrderQ和工作订单(Work Order ItemQ一起分到工作订单服务(Work Order
ServicesQ,q且创徏日程安排QSchedulingQ、目录(CatalogQ和库存QInventoryQ服务。另外,因ؓ没有服务实例Q所
以没有与服务之间的关pȝL东西。工作订单的服务模型可能看v来如 ?9所C?
?OO 范式不同Q这个模型ƈ不表C功能系l。既没有考虑,也没有描qC务事件或规则。在 SOA 范式中,在服务外面维护的业务程~排军_了执行服务调用的序和时间?/p> 从概念上Ԍ从第一ơ顾客联pd完成工作和帐单支付的整个业务表示单个宏观层次的工作单元,q具有数天到数周不等的生命周期。毕竟,从企业的角度来看Q工作单元会产生收入?/p> 然而,实际出现的情冉|在一D늛寚w的时间内单独发生的一pd集中zdQ例如,定义zd、安排预U、选择零g和备件、进行维修活动等{。在 IT pȝ中,没有实际?
程会持l几分钟以上Q事件之间的业务程状态以数据的Ş式保存在数据库中?
q种cd的流E可以用状态{换模型(例如 UML 中可用的Q很好地q行表示?
?10昄了用有限状态机Qfinite-state machineQ方法如何对业务进行徏模的CZ。它是在业务程q行时工作订单的状态如何改变的高视图?
业务程~排集中于状态之间的q些转变。单独的操作怹地记录相关的状态改变?/p> ?11昄了部分编排的CZQ其中包?
?10所C的业务场景中的步骤 1 ?5Q例如,֮定义他们的交通工作所需的工作,q且安排预约以进行实施)?
?
本文中,我们已经讨论和激发了对创新的中间盔R的方法的需求,q种Ҏ搭徏了业务和 IT 之间的桥梁,q且支持 SOA
目的分析和设计阶段。我们还提议这U新的交叉学U的 SOAD Ҏ作ؓ一个整体的建模规则Q它以现在构好且qؓ赞誉?OOAD、EA、和
BPM 为基?/p> 在详l定?SOAD 表示法和程的同Ӟq确定了关键的原理,比如服务概念化(或标识)、服务分cL聚合、策略和斚w、中间相遇流E、语义代理和服务获取Q以供重用)?/p> SOAD 需要增强现有的软g开发方法,q一步提高企业应用程序开发项目的可用性和适用性。随着旉的推U,q将发展相关的最佛_c?/p> 我们q认识到QUML 在流E的表示法选择斚wl占支配CQ可能需要进行增Z满更广泛的 SOAD 的要求?/p> 完成 SOAD Ҏ的下一步就是定义所需的端到端程和表C法Q复审活动中的角色和它们的责任,q且l箋查所提议的方法在目中的有效性?/p> Olaf
Zimmermann ?IBM worldwide Applied Web Services l的N IT
构架师。他在分布式计算、面向服务体pȝ构、Web 服务/XML ?J2EE 斚w颇有专长。在q去的几q里QOlaf 指导了大量与 Web
服务有关的交项目,包括几本产品参考书。他?Springer 教科?Perspectives on Web ServicesQISBN 3-540-00914-0Q的作者。他q参与了几本 IBM ITSO U皮书(比如
Web Services Wizardry with WebSphere Studio Application DeveloperQSG24
-6292-00Q)的写作。Olaf ?1994 q开始就?IBM
合作Q涉及的领域非常q泛Q其中包括品开发、技术预售咨询、教学以及系l集成。Olaf 在位于d?Braunschweig ?
Technical University 获得计算机科学学位。您可以通过 ozimmer@de.ibm.com与他联系?
Pal
Krogdahl 是一名解x案架构师Q在 IGS ?IBM Business Consulting ServicesQ位于瑞典)工作。他?
1998 q开始就职于
IBMQ涉及了多个领域Q比如Y件开发、售前技术咨询和解决Ҏ体系l构。他擅长的领域包括分布式计算、中间g和应用程序服务体pȝ构,主要集中?
EAI ?SOA。Pal 最q撰写了一些范围广泛的文章Q探讨的主题有基?SOA ?EA、以及它们与 IBM
用于电子商务和按需操作pȝ环境的模式的关系。到目前为止Q他已经完成?IBM International Technical Support
Organization 的一些高U培训,在该l织中,他同人合著了一些与 WebSphere 有关的红皮书Q这些红皮书主要集中?Web
服务?SOA 斚wQ例?Patterns: Service-Oriented Architecture and Web Services(ISBN 073845317X)。在q去?18 个月里,他一直在?IBM 内外的技术h员介l?Web 服务和基?SOA 的按需操作环境的实现方面的知识。您可以通过
pal.krogdahl@se.ibm.com与他联系?
Clive
Gee 是一名高U解x案架构师Q工作在 IBM Enterprise Integration Services 部。他?1976 q加?
IBM Europe q于 1997 q调?IBM US?990 q_作ؓ创立 IBM European Object
Technology Practice 的一员,他是 IBM 中第一?OO 的支持者。从那以后,他获得了领导企业 OO
交流目的大量实늻验,涉及多个行业Q如公用事业、金融业、运输业、零售业和电信业Q的复杂pȝ集成和应用程序开发。目前,他正忙于Z个重要的国?
户配|部|?SOA 解决Ҏ。Clive 从苏格兰?University of Stirling 大学获得理论物理博士学位。您可以通过 clive@us.ibm.com与他联系?
ZSOAP侦听的SOA消息监控是构建高效SOA安全性解x案基的一U手DcSOAP侦听
? 一个用于监控SOAP消息的SOAP拦截器用作这个SOA中的安全性基。SOAP拦截器分析它监控的SOAP消息的标题头中包含的用户w䆾Qƈ其与保存在现有安全性基架构中的名称相比较。结果就是对SOAP消息发送方和接收方q行了n份验证和授权?/p>
是在web服务消费者和web服务之间来回传递的SOAP消息的\径中攑օ一个叫做“SOAP拦截器”的Ҏ软g块。因为其分类、监控、复制和转发?
含大量数据的SOAP消息的能力,SOAP拦截器可以在SOA安全性方面发挥重大作用。如?所C,一个SOA安全性解x案“监视”着到达web服务?
SOAP调用消息和对q些服务调用的响应。当它“看见”一条消息时QSOA安全性解x案就会进行检查,以确保发求的实体是经qn份验证和授权可以?
用web服务的。SOA安全性解x案通过查SOAP消息标题头中包含的数据实Cq一炏V?/p>
在大多数情况下,SOA安全性解x案是
对现有安全性解x案的扩展Q而现有安全性解x案是在迁UdSOA之前Z护整个企业而部|的。因此,SOA安全性解x案很可能不得不与现有安全性基
架构q行q接和通信。如?所C,SOA中的用户w䆾验证和授权发生在Z企业的授权用h据库查用戯书的时候。侦听SOAP消息Qƈ把消息标题头
中列出的用户与保存在现有安全性基架构中的用户q行比较Q便可实现n份验证和授权?/p>
当需?
对企业外部的SOA用户q行w䆾验证和授权时Q又会怎么样呢QSOA的开放性得上q情冉|以往M时候都更可能出现。您可能会面临这样一个难题:在一l?
在现有安全性基架构中没有记录的用户中,搞清楚每个用Lw䆾。ؓ了解决保护第三方q程中固有的安全性问题,SOA安全性解x案可以用联邦n份验
证。联邦n份验证是q样一个过E:通过q个q程Q多方可以达成一_使用一l给定的标准来对一l指定的用户q行w䆾验证。联邦n份验证方法的使用者可以创
Z个联邦n份管理系l?Federated Identity Management
System)Q这是一个已验证用户的库。SOA安全性解x案可以通过查联邦n份管理系l来Ҏ个用戯行n份验证。换句话_一些相互通信的系l的
“联邦”,可以一致同意某个用h合法的?/p>
在某些情况下Qn份验证过E会D在SOA安全性解x案中创徏安全断言标记语言
QSecurity Assertion Markup
LanguageQSAMLQ断aQ用于以一U可为用戯用的web服务所接受的方式表辄L真实性。SAML是一U基于XML的标准,它ؓ以标准方?
描述安全性信息提供了一个框架。WS-Security是迄今ؓ止得到认可的安全性标准集合的ȝ。许多SOA安全性解x案都利用了这些新兴的安全性标
准。如?所C,SOA安全性解x案可以侦听SOAP消息Q然后其经q一个对用户q行w䆾验证的过E。接下来QSOA安全性解x案把SOAP消息?
递给目的web服务Q但是会附加上一个SAML断言。注意:SAML断言不依赖于联邦w䆾验证q程?/p>
?
要在SOA安全性中使用联邦w䆾验证QSOAP拦截器必L传入的SOAP消息转发l安全性解x案,该安全性解x案再把SOAP消息标题头中包含的用
戯n份与联邦w䆾验证数据库中列出的用戯行匹配。如果匹配成功,SOA安全性解x案就会创Z个安全“断a”,内容是用户已l在安全断言标记语言文档
中通过了n份验证,该文档是在SOAP消息到达它要调用的web服务旉加给该SOAP消息的?/p>
一U非
常有效的保护核心pȝ的方法是避免让Q何h讉Kȝq_的服务。可以通过为SOA中的web服务部v一个代理做到这一炏V如?所C,一个受保护的代理可
以代表实际的web服务接收所有web服务hQƈ对其做出响应Q从而保护web服务免遭恶意的R実뀂代理方法的另一个好处在于,它能够减M业安全性基
架构的负担。代理可以降低网l流量,具体Ҏ是集中管理和~存对web服务h的n份验证和授权Q而不是每ơ用h调用web服务Ӟ在|络上用大
量消息对该用戯行n份验证和授权。代理还在消息中插入了n份验证和授权SAML断言Q从而消除了实际web服务直接查询安全性系l的需要?/p>
在下一章中Q我们将花大量时间来讲述q个主题Q但是作Z要的SOA理问题之一Q契U管理同样在SOA安全性中L举轻重的作用。契U就是用于管?
web服务使用情况的一l规则。例如,某个契约可能会规定,某个特定用户有权每天调用某个特定的web服务十次。而且在调用过E中Q服务水q_L特?
的参敎ͼ比如一U钟的响应时间?/p>
在安全性方面,契约有助于确定SOA是否q行正常Q或者由于违反安全性规则而误用。如?0所C,
SOA拦截器把web服务h和响应数据发送给SOA安全性解x案,然后该SOA安全性解x案再定是否满契约。如果某个安全性问题(比如DoS?
击)使web服务的速度降低到契U规定的服务水^以下QSOA安全性解x案就会警告管理方有问题存在。当Ӟ一ơ够严重的d可以D整个|络崩溃Q?
但是安全性解x案至可以发出有问题存在的通知?/p>
? 通过处理SOAP消息量Q降低企业安全性基架构的负担,q保护web服务免于误用Qweb服务代理有助于保护SOA?/p>
? SOA安全性解x案监控服务水qIq在安全性问题导致web服务降低到契U规定的服务水^以下时发告?/p>
q些q来QIT领域先后出现了很多消息的安全性技术,包括密码术。现在,也可以对SOA应用q些技术。这些过E,包括数字{、证书、密钥和加密Q都
可用来保护SOA。在q里我声明一点:对于q?U安全性技术中的每一U,都可以写Z本甚x好几本著作。请把本节看作是对与SOA相关的基于加密的安全
性的一个概q?/p>
如果希望让SOA拥有健壮的安全性,保证web服务的用户都可以得到适当的n份验证,而未ln份验证的人无法读取在
web服务及调用它们的应用E序之间往q的信息Q那么无疑需要对SOA安全性解x案应用功能强大的公钥/U钥加密工具。密钥是一个具有某U特D的数学?
性的大数Q数百个CQ。尽Ş式和大小各不相同Q但密钥都有一个基本属性,卻I可以与另一个密钥进行惟一兌。也是_当一个密钥遇到其惟一的匹配密
钥时Q双斚w会说Q“哦Q就是你了,我惟一的匹配…不会再有其他的什么h了。?/p>
惟一的密钥对h如下两个基本功能Q?
下面讲述当两个用h交换加密信息时的工作原理Q用户A创徏一个惟一的密钥对。然后,他在自己的系l中隐藏其中的一个密钥(“私钥”)Q却把另一个密?
Q“公钥”)发送到用户B可访问的|络上某处。然后,用户B使用公钥来加密他惌发送给用户A的信息。实际过E涉及到大量让我想一惛_头痛的数学知识,?
是基本上Q公钥和消息数据是通过一个加密算法来q作的,该加密算法生成一个没有私钥不可能打开的加密文件。接下来Q用户B把经q加密的消息发送给用户AQ?
而用户A则用最初隐藏的U钥来对加密数据q行解密。结果,用户A是世界上惟一一个能够解密这些加密数据的人,因ؓQ只有)他拥有与用户B的公钥匹配的?
一U钥?/p>
现在Q如果您像我一L刨根问底Q您可能会想Q但是用户A如何知道用户B真的是用户B呢?如果某位黑客侵入到用户B的系l中Q?
q找C他用的公钥Q那怎么办呢Qؓ了回{这个有效性问题,Z使用了大量实体来保特定用户的真实性,q授予他们证明其真实性的数字证书。这些实体叫
做certificate authority (认证机构QCA)。CA的一个著名例子是VeriSignQ它提供用于电子商务事务的证书?/p>
使用密钥、加密和证书来实C密性和w䆾验证的SOA安全性解x案如?1所C。在我们的制造商例子中,供应商系l想发送一条SOAP消息l制造商?
web服务。ؓ了做到这一点,刉商必须首先发送一个公钥给CA。然后,供应商系l从CAh一个证书。供应商收到的证书包含与刉商pȝ中存在的U钥?
匚w的公钥。然后,供应商用证书的公钥加密其消息,然后再把消息发送给刉商。然而,和前面的例子一PSOA安全性解x案侦听消息,q用CA?
证书的有效性。这可以验证供应商的w䆾。只有在通过w䆾验证之后Q加密后的SOAP消息才能被发送给刉商。SOAP消息到达之后Q制造商׃用它的私?
Ҏ息进行解密和处理?/p>
如果您觉得这听v来更多地像是在发送消息,那么您想得没错。就像在IT的其他领域中一PSOA中的安全性会?
来大量“开销”。在到达目的C前,每条消息都必ȝq好几个地方。证书文件可能会很大Q从而给|络造成很大的负担,而且整个q程往往会降低性能。但是遗
憄是,它仍然是必不可少的?/p>
?5 在安全性SOA中用公?U钥加密和证书的步进式过E?/p>
囑֭Q?/p>
Z保留SOA的开放性,同时制订严格的消息的安全性标准,您很可能惛_加密时用XML。当SOA安全性解x案用密钥对消息q行加密Ӟ它会?
消息转换ZD늻q加密的XML。消息是XML格式的,但是内容q不可见Q因Z用加密算法将光藏v来了。这样做的好处在于,接收消息的系l可以把它当
作XML来接收、解密和处理Q而不依赖于定制或专有的消息传递标准。这h们就获得了安全性,同时pȝ仍然Z开放标准?/p>
数字{是另一U消息的安全性Ş式,它是证书、密钥和加密{安全性方法的变体。数字签名就是附加给SOAP消息的证明真实性的数学语句。数字签名是一
个基于密钥的敎ͼ同样是一个非常大的数Q,它对您的w䆾和消息内容进行惟一的处理,具体Ҏ是对两组数据Q密钥和消息Q运行一个特D的法。D一个简单的
例子Q如果您的消息是“hello”而密钥是12345Q算法将处理q两U输入——单词“hello”的数值和密钥?2345——ƈ生成W三个数Q这W?
三个数就是数字签名。当接收pȝ获得消息和附加的数字{Ӟ它可以用密钥来验证以下内容Q?
如果消息被改变了Q那么惟一的数字签名将不再与密钥和用于创徏密钥的原始消息相匚w。数字签名和先前描述的完整加密过E之间的区别在于Q如果用数字签
名,不必Ҏ条消息进行加密。因此,pȝ的性能得到了提升。只要您不介意别人可以看到您的纯文本格式的消息,那么数字{可以ؓSOA提供高度的数据安
全性和完整性?/p>
{可以是一个不可否认性(nonrepudiationQ组成部分,该特性是一个需要在SOA环境中解决的安全性重?
斚w。不可否认性是指一个组l的一U能力:验证发生了特定的处理Qƈ从而不l发送方提供否定q行了处理的Z。例如,如果您针ҎU商品下了一份电子订
单,而该订单q没有以某种方式Q比如用数字签名)q行验证Q那么对方就有可能否认收到该订单。如果批发商的系l提供不可否认性,那么批发商就可以肯定?
订单已经送达?/p>
最后,SOA安全性解x案应该提供一U用于跟tSOAPh的工P从而降?
DoSd带来损害的可能性。通常Q跟t特性将监控SOAP消息的发送方及其创徏旉。在某些情况下,SOA安全性解x案将使用一个惟一的识别码l?
SOAP消息打上印记。如果解x案被讄为阻塞复制消息,那么同一条消息是不可能被发送两ơ的。消除这U可能性有助于降低黑客使用复制hҎSOA?
可能性,q是DoSd中常用的一U手法?/p>
审计是SOAP消息跟踪功能的进一步发展。如果SOA安全性解x案被配置t消息,那么
它应该能够生成特定时期中SOA消息量的用日志和审计报告。审计有很多用途,但是在安全性领域中Q它用于记录所发生的事情,以便研究安全性问题ƈ诊断
潜在的安全漏z。这cL志已l成为实现管理目标(比如对Sarbanes-Oxley法案的服从)所必不可少的?/p>
SOA安全性是一个很大的主题。我可以p个主题写一本书。(事实上,q是一个不错的L…)在本章中Q我的目的是提供一个概qͼ好让您可以评估自己对
q个主题所掌握的信息。如果您是一位企业主,我的是,要避免被安全性问题吓倒。h们很Ҏ被安全性吓倒,安全人员也不例外Q这L了他们做些实际工
作以消除对于安全性问题的恐惧。实际上Q我本来可以提出一个您正在考虑的IT解决ҎQƈ让您了解到围l该解决Ҏ的大量安全性噩梦,q些噩梦以使您q?
该解决Ҏ?/p>
相反Q我您寻求安全性方面的高质量徏议,q探讨企业中已经实施了哪些。如果您q样做,那么您的企业很可能会拥有一
个(或一些)相当健壮的安全性系l。实施SOA的难点在于如何把现有的安全措施扩展成为由SOA构成的web服务。许多SOA安全性解x案的设计目的?
是ؓ了与现有的安全功能有效互q。如果实现的话,安全性风险可能稍微易于管理一些,而您也可以l实施您的计划了?/p>
安全性是SOA中的一个焦炚w题,因ؓSOA机器与机器的交互Q而大多数IT安全性都是基于h与机器的交互。n份验证和授权在这个环境中变得更加?
于挑战性。在未受保护的SOA中,惌Lweb服务的未授权使用实际上是不可能的Q未授权用户可以非常L地访问web服务。Web服务不具备跟t谁?
使用它们或者谁被允怋用它们的固有功能。无法阻止不必要的监听和消息侦听。未受保护的SOA让黑客有Z监听SOAP消息q看到私密信息。此外,在未?
保护的SOA中,侦听SOAP消息qӞZ危害和欺骗的目的Q重新发送消息或转换消息内容要相对容易一些?/p>
׃SOA架构的开放性本
质,您无法保护SOA中未知的W三斏V第二和第三用户Q例如您的合作伙伴的合作伙伴Q是可以讉K未受保护的SOA的。因此,未受保护的SOA很容易超
负荷q{。如果没有访问控Ӟ未受保护的SOA很容易被来自黑客的大量SOAP消息所“没”。结果可能导致DoSd损害pȝ的正常功能。最后,您还?
有处理记录。未受保护的SOA无法跟踪其用h消息。因此,没有可用于研I安全性问题或诊断安全性漏z的可审计用记录?/p>
存在一些可?
解决所有这些问题的预打包和定制的SOA安全性解x案。在分析SOA安全性需求时Q可以考虑实现一个支持SOAP消息监控、联邦n份验证、应用程序代
理、契U管理、证书、密钥和加密以及审计记录的SOA安全性解x案。这个清单似乎很长,但是事实上,如果~少其中M一,SOA的所有优炚w可能遭到
破坏?/p>
SOAP消息监控利用了一个SOAP拦截器模型,以便在将SOAP消息从调用系l发送给web服务时对其进行侦听和监控?
SOAP消息监控是SOA安全性的基础Q因为它让安全性解x案能够停止和分析每条消息Q以q行用户w䆾验证和授权。ؓ了保护第三方Q安全性解x案可?
利用联邦w䆾验证。应该通过一个联邦n份验证过E提供对pȝ中的用户q行w䆾验证的能力。最l将获得一个ؓweb服务的用h供可信n份验证的SAML?
a?/p>
Web服务应用E序代理在实际的web服务中接收和处理SOAPhQ从而对安全性有所帮助。它可以使所有的用户都远d际的服务。代理不仅可以减ȝl的负蝲Q还可以为SOA提供一个额外的安全性层?/p>
契约理是另一对安全性有所帮助的SOA理Ҏ。契U确立了谁有权用web服务以及何时可以使用它。契U通过消除非契U方的用,提高了SOA的安全性?/p>
对于一个真正安全的SOA来说Q证书、密钥和加密同样是必不可的。最健壮的SOA安全性都源于实现了用来自认证机构的U钥/公钥q行w䆾验证的加?
消息传递。XML加密允许web服务用户发送保留XML格式的加密SOAP消息。因此,pȝ实现了安全性,但却仍然Z标准。数字签名是加密模型的一U变
体,它得web服务的用户可以创Z个惟一认的数字“签名”,其用途有二:验证用户w䆾和确保消息数据的完整性? 最后,Z跟踪SOA的用,有必要采用可以保存所有SOAP消息h和响应的动态审计日志的SOA安全性解x案。审计日志对于在SOA中研I安全性问题和诊断安全性漏z,以及实现理规章服从性,都是必需的?br />什么是面向服务的体pȝ构(SOAQ?
我可以用面向服务的体pȝ构做什么?
构成 SOA 的技术是什么?
SOA 与其他技术的关系如何Q?/h2>
我可以如何构建SOApȝQ?/b>
W一个层ơ是最单的Q因为它只需创徏单独的服务。在q一部分列出?“SOA 新手入门 ?中对此进行了详细解释Qƈ且提供了更多的资源?br />
在第二个层次中,您不仅可以创建服务,而且可以开始将业务功能集成?SOA 中。这涉及多个层次的集成,其中包括应用E序集成、信息集成、流E集成和整个pȝ集成?Migrating to a Service-Oriented Architecture 是一重要的文章Q介l了q个层次中的问题?br />
W三个层ơ涉及将您的企业 IT 基础设施转换?SOA 模型Q而采?SOA 的第四个层次集中于{换您的业务模型,以之成为按需qA的模型?br />
?IT 专业人员的角度来看(与业务层相比Q,要创?SOA 应用E序Q您通常经历四个阶D:构徏、部|Ӏ用和理。在构徏阶段中,您可以定义业务模型或程、Y件模型和 SOA 模型。之后,您就可以创徏一l服务,q组服务可以与已发布的通用接口一起重用?br />
在部|阶D,您提取创建的服务Qƈ把它们放在一个可执行、可理的环境之中。在使用阶段Q您Ҏ前面所讲的 SOA 和Y件模型来装配应用E序Qƈ且测试其软g质量以及非功能性需求,比如性能、可伸羃性等{。应用程序现在已l准备完毕ƈ且可用于用户。最后的理阶段是一个长期的q程Q在q个阶段中,您可以监控ƈ理安全性和使用Q以及在许多与您可能已经?SOA 制订好的服务U协定或{略相对应的斚w比较其性能?br />
q些?SOA 的生命周期的概念阶段。ؓ了对应于这些阶D늚实际工作角色具体化,有许多角色需要加入到 SOA 应用E序的创Z中。这些角色可能从事相同的工作Q也可能跨多个团队成员甚臛_个团队。在 Rational Unified Process Q?RUP Q中所划分的角色非常好地表达了角色概念?br />
RUP 角色包括目l理、分析员、架构师、徏模h员、开发h员、测试h员以及部|和操作人员?SOA 几乎完全照搬了这U角色划分方法,惟一不同之处在于Q?SOA 建模人员角色的工作是提取概念性Y件模型,q且Ҏ IT 基础设施?SOA 模型和资源来对其q行试。开发h员角色还可以包括二角色像装配h员(在用阶D)Q装配h员的角色是提取单独的服务Qƈ且根据定义好的模型构建实际的 SOA 应用E序。不是昑ּ的还是隐式的Q这些角色都存在于支?SOA 的企业之中?br />
个h体会Q?/b>
?
果您惛_施SOAQ首先要牢记的一点就是IT部门必须对SOA有明的理解和定义。您可以试着询问5位IT专家Q看看他们心目中的SOA到底是什么。您?
有可能会听到五种完全不同的答案。这主要是因为架构技术的发展速度太快Q没有h能精地说明最新的SOA定义I竟是什么?
但这q不是什么问题。即使IT行业无法在定义方面达成共识,也ƈ不媄响SOA的整体发展。但是,您的IT部门内部必须要达成共识,定SOAҎ所在企业的切意义?
您对有关SOA的一些权威文献进行研IӞq且ȝZ套适合自n需求的SOA理论。您也可以咨询一些该领域的专Ӟ让他们根据您公司的特D需求来定义一套专有的架构?br />最为关键的一ҎQ您的公司必L有一套能够自我发展的SOA定义。IT部门中的每一个h都必d分理解这套定义,q尽全力支持q种新的架构形式?
对许多企业而言QSOA与传l架构有着天壤之别。传l架构侧重的是各U应用间紧密q接的接口,因此员工要想理解SOA必ȝ历一D艰苦的学习q程。而通过合理的培训和教育Q您可以减轻员工的这U学习压力,更加自信CؓSOA的实施做好准备?
您采用自上至下的培训序。首先,寚wU管理h员进行培训,让他们了解SOA的基本要点,以及部vSOA后企业可能获得的利益与优ѝ?
在完成高U管理层的培训后Q接下来可以对下一U业务主开展SOA斚w的教育工作。他们不仅需要理解SOA的M目标Q还要深入理解具体实践中遇到的细节,q且需要明知道SOA是怎样实施的?br />最后,您还需要对构徏和部|SOA的h员进行具体培训。这U渐q式的培训应该解决一些特定的技术问题,Z业^E渡到SOA架构提供有效保障。当Ӟq一阶段培训的工作量和精力投入都是最大的?
需要提醒您的是Q早期培训ƈ不一定会带来d的成功。SOA的概念对于许多IT专家来说仍然非常陌生Q即便他们对其他架构研究得相当透彻Q面对SOA也会昑־有些不知所措?
惌理解新的规范L很困隄。未来主义学者Joel Barker这U症状称作“规范效应”。他解释_多数人所感知的世界都有一定的边界。当新的理论试图对这U边界发h战时Qh们很可能会表现出抗拒的态度Q因些新的理Z他们原有的信仰显得格g入?
惛_服规范效应,理层的支持和全面深入的培训必不可少。但是,千万不能灰心。员工完全可以通过再培训来接受q些新概念,在这斚w已经有很多成功的先例?/p>
SOA的最l目标是开发出一套灵zȝ架构Qƈ能够通过一个通用接口各U离散的异型应用集成在一赗要实现q一目标Q就必须设计和开发一些独立于应用的服务,q且使整个企业都能访问和׃nq些服务?
在徏立ICCӞ有一些关键组件是必须预先考虑到的。当您在定该中心的参与者时Q应保企业中的每个相关部门Q包括IT和业务部门)Q都zև了掌握实权的人员参加q来?br />要记住,此D的目的是减少可能出现的应用孤岛,q且提供充分的资产复用能力。因此,只有企业中所有部门都参与q来后,也就是徏立一个“检查与q”的体系之后Q这些目标才拥有实现的可能?br />理者可以委z最优秀、最机智的助理参加这个管委会Q确保他们经q良好的培训Q成为精通SOA的专家人物。请注意Q高U管理h员必ȝ解小l成员参与SOA委会的重要性,q且愿意重新分配工作dQɽ委会的工作能够被优先处理?
在开始时Q可以选择一些相Ҏ较简单的功能Q也是说风险较低、但仍然比较重要的功能。例如,从多个系l中提取和合q客户信息的功能可以当作早期尝试的不错范例。您可以围绕该功能开发一套服务,qؓ整个企业提供支持?
然后Q您可以开始“脱钩”不同系l中的功能,使之不再依赖点到点的接口Q而是其重新定向臛_新的׃n式服务?
从小处着手可以帮助您的企业在部v重大服务前进行一些初步的试Qƈ且对程加以l化。例如,您可以将财务应用重新定向Q让它们使用一个通用的接口。另外,q种初步的测试还能监出企业对SOA的准备情况,以及在新架构下的应变能力
回页?/b>
?1QSOA 架构样式的概忉|?/b>
回页?/b>
?2: SOA 的属?
回页?/b>
除了本文中描q的鉴别、制定和实现之外Q基于服务的建模Ҏq包含了支持完整 SOA 生命周期的部|Ӏ监视、管理和控制所需的技术?
回页?/b>
?3QSOA ?/b>
现在Q让我们更加仔细的描qC下每一层以及每一层之间的合成?
回页?/b> 回页?/b>
?4Q基于服务徏模的zd
?5Q基于服务的建模和架构方?/b>
消息和时间指定以及管理定义出现在q一步骤中?
服务分配同样由服务的指派和在 SOA 层中实现他们的组件组成。组件和服务?SOA 层中的分配是一个关键的dQ需要关键架构决{的文g和决议,q些决策不仅仅同应用E序架构有关p,也同在运行时设计和用来支?SOA 实现的技术操作架构有关的?
回页?/b> 回页?/b>
回页?/b>
从徏模的观点来看Q由此带来的挑战是如何描q设计良好的操作、服务和程抽象的特征以及如何系l地构造它们。这些相关问题都是当前行业内和学术界最常讨?
的问题。据我们所知,最q几乎所有的 SOA
目或专题研讨会都将q样的服务徏模方面作为重要的主题Qƈ引v了许多的争论。因此,让我们更q地作一番审视?回页?/b>
?1. BPM、EA ?OOAD 的位|?/b>
?2. SOAD 及其l成部分QOOAD、BPM ?EAl常帐户QCheckingAccountQ?/code> ?
储蓄帐户QSavingsAccountQ?/code> ?
h帐户QLoanAccountQ?/code> q样的对象。如果您看得更仔l一点(请参?
?3Q,您将发现q些cd享许多属性,比如都有收支q帐户、借方帐户和贷方帐L{?
?3. UML cȝ承示?/b>
与其重复定义和管理这些属性的代码Q不如创Z个通用?
帐户QAccountQ?/code> c,该类h现金收支qq且可以处理借贷事务。所有其他的c都是这?
帐户QAccountQ?/code> 对象的专门Ş式。例如,
h帐户QLoanAccountQ?/code> 在零和某个U定的最大g间具有负qQ?
储蓄帐户QSavingsAccountQ?/code> 具有负qQƈ且将展示增加利息的行为,{等?
l常帐户QCheckingAccountQ?/code> 实例Qƈ且将相应?
?/i>消息发送到
储蓄帐户QSavingsAccountQ?/code> 实例。当实例接收消息Ӟ它执行相应的功能Q称?
ҎQ它有与消息相同的名U?
自由l常帐户QFreeCheckingAccountQ?/code> 实例?
l常帐户QCheckingAccountQ?/code> 实例响?
?($100)
消息Q但?
自由l常帐户QFreeCheckingAccountQ?/code> 实例正?$1000 记入它的帐户q的借方Q?
l常帐户QCheckingAccountQ?/code> 实例?$1000 加上交易费记入它的帐户^衡的借方?
?4. 设计层次
?5. SOAD 服务定义层次回页?/b>
?6. 服务分解
通过目相关人员的会谈和 CBM 来进?BPM ?
直接需求分析是一个容易理解且非常合适的标识候选服务的Ҏ?
?
Endrei中定义的域分解、子pȝ分析、目标模型创建和相关技术是 SOA 程构造方法或
服务概念化框?/i>Q它是基?
Levi and Arsanjani先前完成的工作构建的Q最有希望的提议。来?
SEI?FODA 工作也ؓq方面的讨论做出了A献?
选择正确的抽象别是服务建模的一个关键问题。您常常会听?
q行_粒度徏?/i>的徏议。这有点q于单化了。您应该其改ؓ在不损失或损害相x、一致性和完整性的情况?
可能地q行_粒度徏?/i>。在M SOA 中,都有l粒度服务抽象的I间Q假定有业务要求的话Q。由?SOA q不{同?Web 服务?SOAPQ因此可以用不同的协议l定来访问抽象别不同的服务。另一U选择是一些相关的服务捆绑成粗_度的服务定义,q是门面模式的变U?
应该定义企业命名模式QXML 名称I间、Java 包名、Internet 域)。简单的例子是始终用名词来命名服务Q而用动词来命名操作。这U最佛_跉|源于 OOAD I间?
服务有不同的用法和用途;例如QY件服务可以不同于业务服务Q如前面?
?5所C)。此外,q可以将原子服务~排成别更高、功能齐全的服务?
服务h语法、语义和 QoS 特征Q所有这些都必须q行建模Q正式的接口契约必须늛的比 Web 服务描述语言QWeb Services Description LanguageQWSDLQ的多。因此,
Web 服务{略QWS-PolicyQ?框架是一个重要的相关规范?
在真实世界中Qƈ没有全新的项目,必须始终考虑遗留pȝQ?
遗留pȝ是现有系l的同义词)。因此,需?
中间盔R的方法,而不是单U的自顶向下或自底向上的程?
q是一个知识管理和生命周期问题Q如何成功地准备好服务ƈ且其在概念化之后可以重用?
回页?/b>
?7. 工作订单的宏示?/b>
?8. 工作订单的类囄?/b>
?9. 工作订单的服务模型示?/b>
?10. 工作订单的业务流E模?/b>
?11. 工作订单的业务交互模?/b>回页?/b> 回页?/b> 回页?/b>
SAML和联邦n份验?/h3>
应用E序代理
契约理
证书、密钥和加密
XML加密
数字{
重放d保护和审?/h3>
明智的管理h员所l出的忠告:不要让安全性吓倒了?/h3>
l束?/h3>
面向服务? 体系l构QSOAQ表C您可以如何使用 Web 服务的大图景。Web 服务规范定义了实现服务以及与它们的交互所需要的l节。然而,面向服务的体pȝ构(SOAQ是一U用于构建分布式pȝ的方法,采用 SOA q种Ҏ构徏的分布式应用E序可以功能作为服务交付给l端用户Q也可以构徏其他的服务。面向服务的体系l构QSOAQ可以基?Web 服务Q但是它可能改ؓ使用其他的技术来代替。在使用面向服务的体pȝ构(SOAQ设计分布式应用E序Ӟ您可以将 Web 服务的用从单的客户?服务器模型扩展成L复杂的系l?/p>
因而,单个的Y件资产成为开发其他应用程序的基本构g。您可以通过与新的代? 和遗留代码一起用的共同交互方式来减系l的复杂性(CBDi ?Lawrence Wilkes 开玩笑_面向服务的体pȝ构(SOAQ可以代表“节省我们的资QSave Our AssetsQ”)。有一U标准的Ҏ可以用于表示q些软g资和与它们交互Q现在h们关注的重点已经转移到基于这些构件的应用E序装配上来了?/p>
? 然在q里讨论的是用于业务应用E序的面向服务的体系l构QSOAQ,但是面向服务的体pȝ构(SOAQ同样也可以用于其他的分布式pȝQ比如网D和? U?Web 服务规范Q例如,Web 服务分布式管理(WS-DistributedManagementQ、Web 服务信QQWS-TrustQ以?UDDIQ?/p>
什么是服务Q?/strong>
? 面向服务的体pȝ构(SOAQ中Q服务(serviceQ是装成用于业务流E的可重用组件的应用E序函数。它提供信息或简化业务数据从一个有效的、一? 的状态向另一个状态的转变。用于实现特定服务的程q不重要Q只要它响应您的命oqؓ您的h提供高质量的服务可以了?/p>
通过定义的通信? 议,可以调用服务来强调互操作性和位置透明性。一个服务表Cؓ一个Y件组Ӟ因ؓ从服务请求者的角度来看Q它看v来就像是一个自包含的函数。然而,实际 上,服务的实现可能包括在一个企业内部的不同计算Z或者许多业务合作伙伴拥有的计算Z执行的很多步骤。就装的Y件而言Q服务可能是一个组Ӟ也可? 不是一个组件。如同类对象Q请求者应用程序能够将服务看作是一个整体?/p>
Web 服务是以使用 SOAP 消息Q它是用?HTTP q样的标准协议上?WSDL 来描q的Q的调用为基的。?Web 服务的最佛_践就是与外部的业务伙伴通信?/p>
松耦合
服务h者到服务提供者的l定与服务之间应该是松耦合的。这意味着Q服务请求者不知道提供者实现的技术细节,比如E序设计语言、部|^収ͼ{等。服务请求者往往通过消息调用操作——请求消息和响应——而不是通过使用 API 和文件格式?/p>
q? 个松耦合使会话一端的软g可以在不影响另一端的情况下发生改变,前提是消息模式保持不变。在一个极端的情况下,服务提供者可以将以前Z遗留代码Q例如, COBOLQ的实现完全用基?Java 语言的新代码取代Q同时又不对服务h者造成M影响。这U情冉|真实的,只要C码支持相同的消息模式?/p>
明确定义的接?/strong>
服务交互必须是明定义的。Web 服务描述语言QWeb services Description LanguageQWSDLQ是受到q泛支持的方法,用于描述服务h者所要求的绑定到服务提供者的l节。服务描q的重点在于与下面几部分交互所用的操作Q?/p>
服务
调用操作的消?br />构造这U消息的l节
关于向何处发送用于构造这U消息的处理l节的消息的信息
WSDL
不包括服务实现的M技术细节。服务请求者不知道也不兛_服务I竟是由 Java
代码、C#、COBOLQ还是由某种其他的程序设计语a~写的。它可以描述使用 HTTP ?SOAP
调用。由于它的扩展机Ӟ它也可以定义其他cd的交互,比如通过 JMS 提交?XML
内容、直接方法调用、由理遗留代码的适配器处理的调用QCICSQ,{等?/p>
WSDL 的通用定义允许开发工具创建各U各L型的交互的通过接口Q同旉藏它是如何由应用E序代码调用服务的细节。例如,如果服务是以多种交互cd公开的, Web 服务调用框架QWeb Services Invocation FrameworkQWSIFQ通过允许q行时决定调用高质量服务的最优方法来使用q种能力?/p>
无状态的服务设计
? 务应该是独立的、自包含的请求,在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时Q它们最? 定义成通用业务程、函数和数据模型Q而不是实现构Ӟ比如会话密钥Q。当Ӟh者应用程序需要服务调用之间的持久状态,但是q不应该与服务提供者分 开?/p>
q里有一个定义会话的错误Ҏ的示例:
Requester: “What is Bruce’s checking account balance?"
Provider: ?x"
Requester: “And what is his credit limit?"
Provider: ?y"
提供者被要求Ch之间 Bruce 的帐Pq就在服务实C引入了复杂性。无状态的服务设计重新定义会话,如下所C:
Requester: “What is Bruce’s checking account balance?"
Provider: ?x"
Requester: “What is Bruce’s credit limit?"
Provider: ?y"
服务_度
? 作的_度是一w要的设计要点。对于外部的消耗推荐用粗_度的接口,而细_度的接口可能用于企业内部。粗_度接口可能是特定服务的完整处理Q例? SubmitPurchaseOrderQ在q里消息包括定义订购单所需的所有业务信息。细_度接口可能h用于以下Ҏ的不同操作: CreateNewPurchaseOrder、SetShippingAddress、AddItemQ等{?
虽然l粒度的接口 求者应用程序提供了更多的灵zL,它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗_度接口保证服务 h者将以一致的方式使用服务。面向服务的体系l构QSOAQ不要求使用_粒度接口,但是推荐使用它们作ؓ外部集成的最佛_c服务编排可以用来创? q_度操作l成的业务流E的_粒度接口?
服务质量需要考虑的问?/font>
? 向服务的体系l构QSOAQ设计将跨越计算机系l,q且q可能跨企业边界。您不得不考虑在?Internet 时安全性功能和需求以及如何链接伙伴的安全域。Internet 协议q不是ؓ可靠性(有保证的提交和提交的序Q而设计,但是您不得不保消息被提交ƈ被处理一ơ。当q不可能Ӟh者必ȝ道请求ƈ没有被处理?
例如Q您可能需要考虑您所部v服务的度量、可靠性以及响应时_以便保它们在承诺的范围之内。当您设计用来自其他业务伙伴的服务的系l时Q您׃得不考虑面向服务的管理来以协作方式管理伙伴之间的服务?
面向服务? 架构是一UIT{略Q它企业应用程序中包含的分散功能组lؓ可互操作的基于标准的服务Q这些服务可按照业务需求快速组合和重用。只有^衡了企业的长期目 标与短期需求,SOA的益处才会显现出来。通过在开始采用SOA时就指定一l组l、资金、操作、设计和交付准则Q就可保持这一q。但“大爆炸”式的方? 是不可取的,应按照@序渐q的学习曲线Q选择一U往复渐q的方式来部|架构更改,q非帔R要。大体而言QSOA路线囑ְ提供了这样一U往复渐q的方式Q 您随着q展得出(重新得出)您的企业的独有规划?/p>
您的SOA路线囑ֺ包含3个关键特?
成熟:SOA路线囑ֺ该是? 断融入经验和教训的“活动文档”。SOA路线图成熟时Q您的SOA行动也就以一U可控的方式辑ֈ了一个更为精妙的U别。SOA路线囄创徏应该从评C? 当前在SOA斚w的能力和要求开始。此q程可?BEA的在U自我评估工?做ؓL?/p>
作用?完整的SOA路线囑ֺ包含6个域(? ?所C?。这6个域之间有明的界限Q但是仍怺兌、相互依赖。各个域的执行情冉|企业USOA行动成功的基矟뀂SOA路线囑ֺ清晰地定义SOA行动 的边界,q确定一个实现SOA目标的明晰、灵zȝ旉。这些目标应该被分散到多个易于管理的阶段中,随后便可以以一U往复渐q的方式实现?/p>
质量:通过在各里程处使用一个“学习与调整”的q程Q同旉用往复渐q的方式Q您的\U图在整个SOA行动中保持相x。ؓ保SOA路线囄质量Q应在所有涉众之间进行沟通及认Qƈ向各方征求反馈意见?/p>
?. BEA域模?/p>
构徏SOA路线囄步骤
SOA路线囄开发共?个阶D?SOA规划、SOA成熟度评估、SOA前景展望和SOA路线囑֮义?/p>
SOA规划
q一阶段l织q定义SOA行动。涉众通过通信和简报等方式参与此过E,q设|一致通过的优先和参数。由于此阶段牉|到整个企业的员工Q因此清晰、充分的沟通非帔R要。在此阶D中Q要完成的Q务包?
SOA成熟度评?/strong>
在SOA成熟度评估阶D,要ؓ当前所处状态徏立一个度量标准。此时将定义当前已经实现、可作ؓSOAL的服务和功能Qƈ定出可作ؓ基础目的项目? 团队应通过一pd讉K调查和问卯查查看各域——分析、制定基准ƈ验证各域的现状。用BEA的域模型l织查如下各斚w:
SOA前景展望
在这一阶段中,团队通过专题研讨会来定q定义要求的“预期”状态,q确保D办整个企业范围内的联合讨论?/p>
SOA路线囑֮?/strong>
从这一阶段P着手定义SOA路线图。应该根据前三个阶段所攉的信息,对企业的SOA目标和适当的时限进行彻底的差距分析(gap analysis)。近期事件要详细Q而较q的事g要灵zZ—以便在前进中融入所得到的经验教训?/p>
SOA路线囑ֺ该是不断融入l验和教训的“活动文档”。SOA路线图成熟时Q您的SOA行动也就以一U可控的方式辑ֈ了一个更为精妙的U别(如图2所C??/p>
?. SOA“学习与调整”\U图
l束?/strong>
我希望通过本文使您在脑中形成一个创qSOA路线囄框架Q文中还说明了“ؓ什么\U图对SOA行动如此重要?”。\U图是说明开发内宏V开发时间、部|所开发内容的一份指南。对于SOA的顺利部|而言Q\U图是最为强大的工具?/p>
传统的WebQHTML/HTTPQ技术有效的解决了h?a target="_new">信息pȝ的交互和沟通问题,极大的促q了B2C模式的发展。WEB服务(XML/SOAP/WSDLQ技术则是要有效的解决信息系l之间的交互和沟通问题,促进B2B/EAI/CB2C的发展。SOAQ面向服务的体系)则是采用面向服务的商业徏模技术和WEB服务技术,实现pȝ之间的松耦合Q实现系l之间的整合与协同。WEB服务和SOA的本质思\在于使得信息pȝ个体在能够沟通的基础上Ş成协同工作?/font>
对于面向同步和异步应用的Q基于请?响应模式的分布式计算来说QSOA是一场革命。一个应用程序的业务逻辑Qbusiness logicQ或某些单独的功能被模块化ƈ作ؓ服务呈现l消Ҏ者客L。这些服务的关键是他们的松耦合Ҏ。例如,服务的接口和实现相独立。应用开发h员或者系l集成者可以通过l合一个或多个服务来构建应用,而无ȝ解服务的底层实现。D例来_一个服务可以用。NET?a target="_new">J2EE来实玎ͼ而用该服务的应用程序可以在不同的^C上,使用的语a也可以不同?
一、SOAh的特?/strong>
SOA服务hq_独立的自我描qXML文档。Web服务描述语言QWSDLQ?Web Services DesCRiption LanguageQ是用于描述服务的标准语a?
SOA 服务?a target="_new">消息q行通信Q该消息通常使用XML Schema来定义(也叫做XSDQ?XML Schema DefinitionQ。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档?
在一个企业内部,SOA服务通过一个扮演目录列表(DIrECtory liSTingQ角色的登记处(RegistryQ来q行l护。应用程序在登记处(RegistryQ寻扑ƈ调用某项服务。统一描述Q定义和集成QUDDIQ?UniverSAl DescriptionQ?DefinitionQ?and IntegrationQ是服务登记的标准?
每项SOA服务都有一个与之相关的服务品质QQOSQ?quality of serviceQ。QoS的一些关键元素有安全需?/a>Q例如认证和授权Q,可靠通信Q译注:可靠消息是指Q确保消息“仅且仅仅”发送一ơ,从而过滤重复信息。)Q以及谁能调用服务的{略?
二、SOA三大基本特征
1 独立的功能实?
在Internetq样松散的用环境中QQ何访问请求都有可能出错,因此M企图通过Internetq行控制的结构都会面临严重的E_性问题。SOA非常架构中提供服务的功能实体的完全独立自ȝ能力。传l的lg技术,?NET RemotingQ?a target="_new">EJBQCOM或?a target="_new">CORBAQ都需要有一个宿?Host或者Server)来存攑֒理q些功能实体Q当q些宿主q行l束时这些组件的寿命也随之结束。这样当宿主本n或者其它功能部分出现问题的时候,在该宿主上运行的其它应用服务׃受到影响?
SOA架构中非常强调实体自我管理和恢复能力。常见的用来q行自我恢复的技术,比如事务处理(Transaction)Q消息队?Message Queue)Q冗余部|?Redundant Deployment)和集系l?Cluster)在SOA中都起到臛_重要的作用?
2 大数据量低频率访?
对于.NET RemotingQEJB或者XML-RPCq些传统的分布式计算模型而言Q他们的服务提供都是通过函数调用的方式进行的Q一个功能的完成往往需要通过? L和服务器来回很多ơ函数调用才能完成。在Intranet的环境下Q这些调用给pȝ的响应速度和稳定性带来的影响都可以忽略不计,但是? Internet环境下这些因素往往是决定整个系l是否能正常工作的一个关键决定因素。因此SOApȝ推荐采用大数据量的方式一ơ性进行信息交换?
3 Z文本的消息传?/font>
׃Internet中大量异构系l的存在军_了SOApȝ必须采用Z文本而非二进制的消息传递方式。在COM、CORBAq些传统的组件模型中Q从服务器端传往客户端的是一个二q制~码?a target="_new">对象Q在客户端通过调用q个对象的方法来完成某些功能Q但是在Internet环境下,不同语言Q不同^台对数据、甚x一些基本数据类型定义不同,l不同的服务之间传递对象带来的很大困难。由于基于文本的消息本n是不包含M处理逻辑和数据类型的Q因此服务间只传递文本,Ҏ据的处理依赖于接收端的方式可以帮忙绕q兼Ҏ这个的大惔坑?
此外Q对于一个服务来_Internet与局域网最大的一个区别就是在Internet上的版本理极其困难Q传l?a target="_new">软g采用的升U方式在q种松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式,数据处理端可以只选择性的处理自己理解的那部分数据Q而忽略其它的数据Q从而得到的非常理想的兼Ҏ?
三、面向服务架构(SOAQ的原则
SOA的强大和灉|性将l企业带来巨大的好处。如果某l织其IT架构抽象出来Q将其功能以_粒度的服务形式表示出来Q每U服务都清晰地表C其业务价| 那么Q这些服务的֮Q可能在公司内部Q也可能是公司的某个业务伙伴Q就可以得到q些服务Q而不必考虑其后台实现的具体技术。更q一步,如果֮能够发现 q绑定可用的服务Q那么在q些服务背后的ITpȝ能够提供更大的灵zL?br />但是Q要得到U强大和灉|性,需要有一U实现架构的新方法,q是一艰巨的d。企业架构设计师必须要变成?a target="_new">面向服务的架?/a>设计师”,不仅要理解SOAQ还要理解SOA的实c在架构实践和最后得到的架构l果之间的区别非常微妙,也非常关键。本文将讨论SOA的实践,卻I面向架构的设计师在构建SOA时必要做的事情?/font>
SOA的原?/u>
SOA是一U企业架构,因此Q它是从企业的需求开始的。但是,SOA和其它企业架构方法的不同之处在于SOA提供的业务敏h。业务敏h是指企业对变更 快速和有效地进行响应、ƈ且利用变更来得到竞争优势的能力。对架构设计师来_创徏一个业务敏L架构意味着创徏q样一个IT架构Q它可以满当前q未? 的业务需求?/font>
要满U业务敏h,SOA的实践必遵循以下原则:
* 业务驱动服务Q服务驱动技?/font>
从本质上_在抽象层ơ上Q服务位于业务和技术中间。面向服务的架构设计师一斚w必须理解在业务需求和可以提供的服务之间的动态关p,另一斚wQ同栯理解服务与提供这些服务的底层技术之间的关系?/font>
* 业务敏捷是基本的业务需?/font>
SOA考虑的是下一个抽象层ơ:提供响应变化需求的能力是新的“元需求”,而不是处理一些业务上的固定不变的需求。从gpȝ而上的整个架构都必须满业务敏捷的需求,因ؓQ在SOA中Q何的瓉都会影响到整个IT环境的灵zL?/font>
* 一个成功的SOAd变化之中
SOA工作的场景,更象是一个活的生物体Q而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化,因此面向服务架构设计师的工作永远不会l束? 对于习惯于盖房子的设计师来说Q要转向设计一个活的生物体要求崭新的思维方式。如下文所写的QSOA的基q是一些类似的架构准则?/font>
SOA基础
在IT行业有两个越来越普遍的发展方向,一个是架构斚w的,一个是Ҏ学方面的Q面向服务的架构设计师可以从中有所收获。第一个就?a target="_new">MDAQ?a target="_new">模型驱动架构Q,由提出CORBA的OMG模型提出。MDA认ؓ架构设计师首先要对待创徏的系l有一个Ş式化?a target="_new">UMLQ也是由OMG提出Q的模型。MDA首先l出一个^台无关的模型来表C系l的功能需求和Use CasesQ根据系l搭建的q_Q架构设计师可以p个^台无关的模型得到q_相关的模型,q些q_相关模型_详细Q以至于可以用来直接生成需要的代码?/font>
MDA的核心就在于在设计阶D늳l就已经完全描述Q这P在创建系l的时候,几乎没有错误解释的可能Q模型也可以直接生成代码。但MDA有一些局? 性:首先QMDA假设在创建模型之前,业务需求已l全部描qͼ而这一点,在当前典型的动态业务环境中几乎是不可能的。第二,MDA没有一个反馈机制。如? 开发h员对模型有需要改动的地方Qƈ没有提供l他们这么一个途径?/font>
SOA的另一个基是敏h法(AMQ,其中非常有名的方法是极限~程Q?a target="_new">XPQ。象XPq样的AM提供了在需求未知或者多变的环境中创?a target="_new">软gpȝ的过E。XP要求在开?a target="_new">团队? 要有一个用户代表,他帮助书写测试来指导开发h员的日常工作。开发团队中的所有成员都参与到设计之中,q且设计要尽量小q且非Ş式化。AM的目标是仅仅? 建用h要的Q而不是在一些Ş式化模型上耗费工作量。AM的核心思想在于其敏捷性-处理需求变更的敏捷性。AM的主要弱Ҏ其规模上的限Ӟ例如QXP 在一个小团队和中型项目中效果不错Q但是当目规模增大Ӟ如果没有一个一致的清晰的计划,目成员很难把握目中的Ҏ面面?/font>
从表面看来,MDA和AMg是相对立的-MDA假定需求是固定的,而AM恰恰相反。MDA的中心是形式化的模型Q而AM恰恰要避开它们。但是,我们q是军_冒险把这些不同方法中的一些元素提取出来,攑օC个一致的架构实践中?/font>
在SOA中有三个抽象层次Q按照SOA的第一条准则:业务驱动服务、服务驱动技术。AM业务模型直接和实践q接hQ表现在q_相关的模型之中。MDA q没有把业务模型和^台无x型分开来,而是把^台无x型做v炏VSOA必须q接q些模型Q或者说抽象层次Q得到单一的架构方法。我们将从五?a target="_new">视图的架构实现方法来实现q个q接?/font>
SOA的五视图实现Ҏ
企业架构设计师发C们的职业非常有竞争力q且值得骄傲Q因Z们要从很多方面来通盘考虑ITpȝ。KruchtenQ?a target="_new">RUP的开发负责hQ将q些斚w提取出来Q在应用到SOAӞ我们UCؓ五视囑֮现方法(five-view approachQ?/font>
四个Ҏ表示对一个架构的不同审视ҎQ分别代表不同的涉众QstakeholderQ。弟五个视图Quse-cASe视图늛了其它视图,在架构中扮演的是一个特D的角色?a target="_new">部v视图Y件映到底层q_和相关硬件上Q是pȝ部v人员Ҏ构的视图Q实现视图描qC软g代码的组l,是从开发h员角度出发的视图Q业务分析h员则利用q程视图q行工作Q它描述的是软gpȝ的运行时Ҏ。最后,逻辑视图表示的是用户的功能需求。在SOA中,面向服务的架构必能够以use-case视图中的用例用戯接到服务Q将服务q接到底层的技术?/font>
Z表示面向对象? 架构是如何工作在q些视图之上Q让我们他们置于SOA元模型的上下文之中。SOA中两个领域存在重叠:׃务模型和服务模型表示的业务领域和由服务模? 及^台相x型表C的技术领域(两个领域׃n服务模型Q。业务用户通过逻辑视图和过E视囑֤理粗_度的业务服务,Ҏ变化的业务需求,按照需要将它们安排 在过E之中。另一斚wQ技术专家的工作是创建ƈl护服务和地层技术之间的抽象层。表C些服务的中间模型Qv到的是u心的作用Q业务以它ؓ中心q行?/font>
SOA元模型从MDA中承^台无x型和q_相关模型Q但是添加了AM和用户交互以及敏L反馈q两部分Q后者通过椭圆之间的双向箭头来表现。类似地Q元模型通过引入׃心的服务模型提供?a target="_new">中间?/a>抽象解决了AM在~性方面的问题。这P服务模型中的M需求的变化Q都会反映到用户每天的业务处理中。同P׃底层技术是模型驱动的,技术专家也可以Ҏq些变化的需求迅速而有效地作出应变?/font>
SOA实践和过去解决企业架构传l方式的不同之处在于其Ҏh的支持。如前所_SOA的第三条原则在于它d变化之中。这U恒在的变化性环境是SOA实践的基矟뀂如图所C,涉众QstakeholdersQ译者注QRUP中也有这个词Q表C?a target="_new">软g开?/a>中涉及到的各U角色如Q用戗设计h员、开发h员乃x试h员等{。)在一个必需的基上媄响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的q种情况下,设计阶段和运行阶D之间的界限变得模糊hQ很难清晰地分离q两个阶Dc?/font>
剩下的部?/u>
我们已经为面向服务的架构提供了一个高层次?a target="_new">框架Q其中MDA和AM的元素帮助工L使用者来创徏和维护SOA。但是,SOA中还~少一些内容-那就是Y件开发商和专业的服务l织必需提供的。理x况下Q开发商必需提供面向服务的业务流E?a target="_new">工作?/a>? 及服务的协调工具和服务;另外Q能够以一U敏L、^台无关的方式充分反映业务服务的徏模工具也是必ȝQ技术专家必配备可以从模型中自动生成代码,q? 在代码变化时更新模型的工P最后,开发商必须提供支持SOA的YӞ帮助面向服务的架构设计师以一U可信ƈ且可伸羃的方式创Z于服务和底层技术之间的 抽象层次。幸q的是,q方面的产品卛_上市?/font>
另外Q最重要的就是诏I本文的自顶而下的SOA实现Ҏ了。今天关于Web services的大部分思考都是自底而上的:“这是如何创建Web services的方法,现在Q我们来使用它们集成吧”,对Web services技术的q种Ҏ是伟大的W一步,因ؓ它可以惊人地降低集成的开销Q这是现在的技术管理h员最乐意见到的了。但当经进一步发展,IT走出 低谷Q企业会LIT的帮助来提高l织战略意义上的核心价倹{用面向服务的架构QIT可以提供l企业实C务敏h的q样一个框架?/font>
四、ؓ什么选择面向服务架构QSOAQ?
不同U类的操作系l,应用软gQ系lY件和应用基础l构Qapplication infrastructureQ相互交l,q便是IT企业的现状。一些现存的应用E序被用来处理当前的业务程Qbusiness processesQ,因此从头建立一个新的基环境是不可能的。企业应该能对业务的变化做出快速的反应Q利用对现有的应用程序和应用基础l构 Qapplication infrastructureQ的投资来解x的业务需求,为客P商业伙伴以及供应商提供新的互动渠道,q呈C个可以支持有Z务(orGAnic businessQ的构架。SOA凭借其松耦合的特性,使得企业可以按照模块化的方式来添加新服务或更新现有服务,以解x的业务需要,提供选择从而可以通过不同的渠道提供服务,q可以把企业现有的或已有的应用作为服务, 从而保护了现有的IT基础投资?
如图1的例子所C,一个用SOA的企业,可以使用一l现有的应用来创Z个供应链复合应用Qsupply chain composite applicationQ,q些现有的应用通过标准接口来提供功能?
Figure 1. Supply chain application. Click on thumbnail to view full-sized image.
服务架构
Z实现SOAQ企业需要一个服务架构,?昄了一个例子:
Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.
在图2中, 服务消费者(service consumerQ可以通过发送消息来调用服务。这些消息由一个服务ȝQservice busQ{换后发送给适当的服务实现。这U服务架构可以提供一个业务规则引擎(business rules engineQ,该引擎容怸务规则被合ƈ在一个服务里或多个服务里。这U架构也提供了一个服务管理基Qservice management infrastructureQ,用来理服务Q类似审核,列表Q?a target="_new">BIllingQ,日志{功能。此外,该架构给企业提供了灵zȝ业务程Q更好地处理控制hQregulatory requirementQ,例如Sarbanes OxleyQSOXQ,q且可以在不影响其他服务的情况下更改某项服务?
五、面向服务架构(SOAQ基l构
要运行,理SOA应用E序Q企业需要SOA基础Q这是SOAq_的一个部分。SOA基础必须支持所有的相关标准Q和需要的q行时容器。图3所C的是一个典型的SOA基础l构。接下来的章节将逐一讨论该结构的每个部分?
Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.
SOAPQ?WSDLQ?UDDI
WSDLQUDDI和SOAP是SOA基础的基部g。WSDL用来描述服务QUDDI用来注册和查找服务;而SOAPQ作Z输层Q用来在消费者和? 务提供者之间传送消息。SOAP是Web服务的默认机Ӟ其他的技术ؓ可以服务实现其他cd的绑定。一个消费者可以在UDDI注册表(registryQ? 查找服务Q取得服务的WSDL描述Q然后通过SOAP来调用服务?
WS-I Basic Profile
WS-I Basic ProfileQ由Web服务互用性组l(Web Services Interoperability OrganizationQ提供,是SOA服务试与互用性所需要的核心构g。服务提供者可以用Basic Profile试E序来测试服务在不同q_和技术上的互用性?
J2EE ?.Net
管J2EE和。NETq_是开发SOA应用E序常用的^収ͼ但SOA不仅限于此。像J2EEq类q_Q不仅ؓ开发者自然而然地参与到SOA中来提供了一个^収ͼq通过他们内在的特性,可扩展性,可靠性,可用性以及性能引入了SOA世界。新的规范,例如 JAXBQJava API for XML BindingQ,用于XML文档定位到Javac;JAXRQJava API for XML RegistryQ用来规范对UDDI注册表(registryQ的操作QXML-RPCQJava API for XML-based Remote Procedure CallQ在J2EE1.4中用来调用远E服务,q得开发和部v可移植于标准J2EE容器的Web服务变得ҎQ与此同Ӟ实现了跨q_Q如。NETQ? 的服务互用?
服务品质
在企业中Q关键Q务系l(MISsion-critical systemQ译注:关键dpȝ是指如果一个系l的可靠性对于一个组l是臛_重要的,那么该系l就是该企业的关键Q务系l。比如,电话pȝ对于一个电? 促销企业来说是关键dpȝQ而文字处理系l就不那么关键了。)用来解决高需求,例如安全性,可靠性,事物。当一个企业开始采用服务架构作为工hq? 行开发和部v应用的时候,基本的Web服务规范Q像WSDLQSOAPQ以及UDDI׃能满些高U需求。正如前面所提到的,q些需求也UC服务品质 QQoSQquality of servicesQ。与QoS相关的众多规范已l由一些标准化l织QstandaRDSBOdiesQ提出,像W3CQWorld WIDE Web ConsortiumQ和OASISQthe Organization for the Advancement of Structured InfORMation StandardsQ。下面的部分会讨论一些QoS服务和相x准?
安全
Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换Q? 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准,例如QSAMLQas Security Assertion Markup LanguageQ来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定?
可靠
在典型的SOA 环境中,服务消费者和服务提供者之间会有几U不同的文档在进行交换。具有诸如“仅且仅仅传送一ơ”( once-and-only-once deliveryQ,“最多传送一ơ”( at-most-once deliveryQ,“重复消息过滤”(duplicate message eliminationQ,“保证消息传送”(guaranteed message deliveryQ等Ҏ消息的发送和认Q在关键dpȝQmission-critical systemsQ中变得十分重要。WS-Reliability ? WS-ReliableMessaging是两个用来解xc问题的标准。这些标准现在都由OASIS负责?
{略
服务提供者有时候会要求服务消费者与某种{略通信。比如,服务提供商可能会要求消费者提供Kerberos安全标示Q才能取得某Ҏ务。这些要求被定义 为策略断aQpolicy assertionsQ。一策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的{略通信?
控制
当企业着手于服务架构Ӟ服务可以用来整合数据仓库Qsilos of dataQ,应用E序Q以及组件。整合应用意味着例如异步通信Qƈ行处理,数据转换Q以及校正等q程h必须被标准化。在SOA中,q程是用一l离散的 服务创徏的。BPEL4WS 或?WSBPELQWeb Service Business Process Execution LanguageQ是用来控制q些服务的语a。WSBPEL目前也由OASIS负责?
理
随着企业服务的增长,所使用的服务和业务q程的数量也随之增加Q一个用来让pȝ理员管理所有运行在多相环境下的服务的管理系l就昑־ؓ重要。WSDMQWeb Services for Distributed ManagementQ规定了MҎWSDM实现的服务都可以׃个WSDM适应QWSDM-compliantQ的理Ҏ来管理?
其它的qosҎ,比如合作方之間的溝通和通訊Q多個服務之間的事務處理Q都在WS-COOrdination ?WS-Transaction 標準中描qͼ 這些都是OASIS 的工作?
六、SOA 不是Web服务
在理解SOA和Web服务的关pMQ经常发生淆。根?003q?月的Gartner报道QYefim V. Natisp个问题是q样解释的:“Web服务是技术规范,而SOA是设计原则。特别是Web服务中的WSDLQ是一个SOA配套的接口定义标准:q是 Web服务和SOA的根本联pR”从本质上来_SOA是一U架构模式,而Web服务是利用一l标准实现的服务。Web服务是实现SOA的方式之一。用 Web服务来实现SOA的好处是你可以实C个中立^収ͼ来获得服务,而且随着来多的Y件商支持来多的Web服务规范Q你会取得更好的通用性?
七、面向服务架构(SOAQ的优势
SOA的概念ƈ非什么新东西QSOA不同于现有的分布式技术之处在于大多数软g商接受它q有可以实现SOA的^台或应用E序。SOA伴随着无处不在的标 准,Z业的现有资或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创徏应用QSOA能够使客h服务消费者免予服务实现的改变所带来? 影响QSOA能够升单个服务或服务消费者而无需重写整个应用Q也无需保留已经不再适用于新需求的现有pȝ。总而言之,SOA以借助现有的应用来l合产生 新服务的敏捷方式Q提供给企业更好的灵zL来构徏应用E序和业务流E?
八、采用服务驱动型Ҏ的企业体验着以下业务?IT 好处
面向服务架构的业务好?
效率Q?业务流E从 " 烟囱 " 状的、重复的程向维护成本较低的高度利用、共享服务应用{变?
响应Q?q速适应和传送关键业务服务来满市场需求,为客戗雇员和合作伙伴更高水准的服务?
适应性: 更高效地转入转出让整个业务变得复杂性和隑ֺ更小Q达到节U时间和资金的目的?
面向服务架构?IT 好处
复杂性降低: Z标准的兼Ҏ,与点到点的集成相比降低了复杂性?
重用增加Q?通过重用以前开发和部v的共享服务,实现了更有效的应用程?/ 目开发和交付?
遗留集成Q?用作可重用服务的遗留应用E序降低了维护和集成的成本?
如今的服务驱动型企业都在体验着开发的高效率,服务的高可靠性和服务的高质量Q以最大限度获得业务机会所带来的这些好处?
九、SOA在国际市Z反响强烈
?004q初业界推出SOA后,Bea、IBM?a target="_new">ORACLE、微软等业界巨头UL发布自己的SOA战略Q徏议用户在q行企业IT时考虑SOA?/font>
ZapThink调研公司在最q发表的一份报告中预测Q到2006q_ZSOA架构(面向服务的架??a target="_new">中间?/a>产品成为网l化商业pȝ的主要设计思\Q其?0Q的商业企业公司用SOA架构?/font>
按照Gartner的预,?008q_SOA成为占有绝对优势的软g工程实践ҎQ它结束传l的整体软g体系架构长达40q的l治C。届Ӟ有60Q的商业公司在进行商业IT时会转向SOA?/font>
IDC预测?2007q_包括软g、服务和g在内的SOA市场达?10亿美元,其中商业企业斚w的市场将辑ֈ120亿美元?/font>
lg所qSOA已经成ؓ大势所,有着qK的市场空间和巨大的发展潜力;而在商业企业中的应用Q将成ؓSOA未来发展的一大亮炏V?/font>
SOA已经引v国内商业企业的重?/strong>
国内ZSOA架构Web服务目前q是集中在一些企业内部,而国内一些有影响的行业用h在搭建其核心业务pȝQ比如商业领域的通行业和销售行业的大集 中正在v步。因此当商业企业需要更好地服务客户Q需要更好地与上、下游合作伙伴协同工作,q且自己内部的核心业务之间也需要协同工作时Q基于SOA架构? 间g产品׃cL的业务应用提供理想的底Q这U新的应用被UC面向服务的业务应用?/font>
现在Q很多商业企业都准备?006q内开始规划用这些基于SOA架构的应用,可想而知Q这些SOA架构的中间g产品在两年内迅速发展,q在五年内在整个IT行业内获得广泛应用?/font>
商业企业信息化存在的问题
商业企业信息pȝ多数处于闭q行的状态,企业之间、企业与上游供应商、下游消费者之间信息不对称。商业企业之间无法Ş成协同效应。信息系l即无法满? 费者的l合需求也无法辑ֈ企业间的商务协同自动化和化的需求。信息化的经效益难以有效发挥。同时信息化标准不健全,如电子交换接口标准、业务流E协 同标准;通中的票证、单据格式标准;电子数据交换所必须的结构化数据标准{?/font>
采用传统的系l架构技术和传统的EAI和B2Bi技术则存在pȝ闭、厂商依赖性强、耦合度高、重用性差Q扩展性差、无法和上下怼业的pȝ建立l一的接 口等问题。而采用SOA 技术则可以有效解决上述问题Q由于SOAZHTTP/SOAP/WSDL{开攑ּ技术,对于特定厂商产品依赖性小Q系l开放、互操作性强Q可以徏立统一 的WEB服务用于和不同的上下怼业信息系l实C应链协同。由于SOA的松耦合Ҏ、比较符合集团和各下属机构的商业关系Q业务流E整合和目协调的阻 力会有效降低?/font>
SOA以服务ؓ基本单元Q更加脓q于企业的商业活动,业务梳理和徏模的复杂度会有效降低Q重用性也会有效提高。另外采用SOAQ企业ITpȝ所提供的服? 会更Ҏ扩展、组合和变更Q符合该集团目前业务发展变化较快的特点,可以有效的降低该集团ITpȝ的长期拥有M成本。我们将该集团公怽Z个试点,? qSOA技术的q用Q来有效解决上述问题?/font>
“协同商务”的新经时代即到?/strong>
采用SOA技术最l将使得各个商业企业之间、各个关联的l济实体之间实现高效实时的联接,使得整个产业铑֮现自动化的协同商务,会有力的提高商业企业的 应变能力Q{变现有的商业q作模式Q{变经增长的方式。SOA技术将促进信息pȝ在商业企业N易活动中的全面渗入和发展Q对于简单的贸易zdQ将会由? 息系l自动化实现Q对于复杂的贸易zdQ信息系l将会ؓ企业理人员提供_的决{信息ƈ可以高效的执行决{。SOA技术的应用会全面提高商务的自? 化、智能化和实时化水^?/font>
采用SOA技术实现协同商务可以提高城市范围内商流、物、资金流和信息流的运行效率,扩大北京市商业企业整体规模效益,加强商业企业的整体对外竞争力Q? 拉动l济增长Q降低企业运营成本,推动城市通信息技术创Cpȝ建立Q提高北京市通现代化水^Q促q城市管理现代化和城市社会经信息化的进E?/font>
采用SOA技术可以将物企业、物业企业、商业企业、消费者整体整合在一P对供应链兌企业、物企业以及网上支付体pR安全认证体pȝ环境h明显的带动作用,有利于促q支撑环境协同发展?/font>
促进商业企业信息化标准的制定Q完善政府职?/strong>
采用SOA技术ؓ信息pȝ的沟通提供了技术基Q而随着SOA在商业企业的应用Q必促q统一的商业领?a target="_new">电子商务行业标准的发展和制定Q对促进国家商业企业信息标准体系的徏立和完善h重要支撑作用?/font>
SOA技术ؓ政府对商业经的q行状况提供了实时监和指导的技术可能性,从Ҏ上改变政府对C会l济的管理方式?/font>
ZSOA的协同商务带来的最直接的好处就是由于N易范围的I前扩大而生的全球贸易zd的大q度增加Q因而提高了贸易环节中大多数角色的交易量Q因此, 全球范围的经Ş势将向一个良好的增长势发展。它q可以扩大地方商业企业整体规模效益,加强商业企业的业务整合和商业协同效应Q提高商业企业的整体对外 竞争力,通过协同商务有效降低企业q营成本Q推动城市流通信息技术创Cpȝ建立Q提高地方的通现代化水^Q促q城市管理现代化和城市社会经信息化? q程?/font>
SOA在商业企业的应用可以物企业、物业企业、商业企业、消费者整体整合在一P对供应链兌企业、物企业以及网上支付体pR安全认证体pȝ环境? 讑օ有明昄带动作用Q可推动信息化各环节的全面应用与发展Q有利于促进产业铑֒支撑环境协同发展Q从而也创造了更多的就业机会和C会财富?/font>
信息产业是知识经的核心和主要的推动力,而企业信息化又是目前信息产业中最具前途的发展势Q因此说企业信息化的发展Q必直接或间接地推动知识经的 潮。这U知识经有着大量的无形成本和高附加|在东南亚金融危机的同Ӟ高科技l美国带来的?高增镉K度、高׃率、低通货膨胀?。这也是我国? 宣传知识l济的热潮中应注意的一个真正有价值的切入炏V?/font>
SOA技术由于其前所未有的信息系l整合与自动协同能力Q成为互联|以来又一个革命性的技术,会把目前基于WEB/互联|的知识l济推进C个前所未有的新阶段?/font>
十、SOA 企业考虑事项
服务驱动型企业在对客戗合作伙伴和雇员的高效化服务斚w得到了优?--
q加速了业务服务响应旉。然而,成ؓ服务驱动型企业,需要的不仅仅是产品的部|Ӏ对实现服务驱动型架构感兴趣的企业将希望能与一个有l验?SOA
提供商合作,它提供的服务可以保护企业在业务和 IT 斚w的投入,他们考虑C以下几个斚wQ?br />
业务战略Q?l织需要明驱动关键业务流E的业务战略Q它用于成?SOA 的框架。一旦识别出业务问题Q就可以用一U一致的、可复用的方法对其进行定义,q实?font color="#0000ff">解决Ҏ