??xml version="1.0" encoding="utf-8" standalone="yes"?> 看到 Shale ?Spring Integration 文档的介l原理,其中序如下Q?/font> When asked to resolve a variable name, the following algorithm is performed: 1.Does a bean with the specified name already exist in some scope (request, session, application)? If so, return it. 2.Is there a standard JavaServer Faces managed bean definition for this variable name? If so, invoke it in the usual way, and return the bean that was created. 3.Is there configuration information for this variable name in the Spring WebApplicationContext for this application? If so, use it to create and configure an instance, and return that instance to the caller. 4.If there is no managed bean or Spring definition for this variable name, return null instead. q样的话Q只?Spring 可以控制 Bean ?Scope 的话Q就可以?Managed-Bean 的配|放?Spring Bean 里来配置Q一斚wQ我们可以省M JSF ?Managed Bean 的配|,另外的话Q我们可以对 JSF ?Backing Bean 使用 AOP 以及 Spring 提供的很多功能。过d JSF-Spring 中尝试着L?Spring Bean ?ScopeQ但是做的ƈ不好Q现?Spring 2.0 l我们提供了q样的能力,l过实验Q证明了q样是可行的?/font> 不过如果使用 Spring Bean 以后Q会造成使用 Managed Bean ?JSTL 无法使用Q其?JSTL 本n用v来就时好时坏的,所以媄响ƈ不太大了?/font> 整合h步骤非常的简单: 1. ?Spring 2.0 ?jar 文g攑ֈ lib 下面Q当前用的?Spring 2.0 RC3 2. 因ؓ使用的是 Servlet 2.4Q所以要?web.xml 中加?br />
<listener> 3. 修改 applicationContext.xml 注释或删掉以下内容: <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" 修改 <beans> 为: <beans xmlns=" http://www.springframework.org/schema/beans " 4. 然后可以按照配|?Spring Bean 的方式来配置 Managed Bean: q个?Request Scope 中的 Bean: q个?Session Scope 中的 Bean: 虽然短期来看Q配|上会少写了一些,因ؓ autowire="byName"Q但是从长远来看Q我们可以利?Spring 的更多功能,比如 AOP 来增?Backing Bean 的能力,我的W一个设惛_是用 AOP 来处?Backing Bean 中的异常.good
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
" http://www.springframework.org/dtd/spring-beans.dtd ">
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
xmlns:aop=" http://www.springframework.org/schema/aop "
xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd ">
<bean id="loginBean" class="org.agilejava.icustomer.backingbean.LoginBean"
scope="request" autowire="byName">
<aop:scoped-proxy/>
</bean>
<bean id="menuBean" class="org.agilejava.framework.commons.menu.MenuBackingBean"
scope="session" autowire="byName">
<aop:scoped-proxy/>
</bean>
]]>
q是《SOAQ原理方法实c的W?4 章。在W?3 章我们已l详l阐qC作ؓ一U新的方法,SOA使用哪些原理和方法去构徏ITpȝQƈ使得构徏的ITpȝ更加灉|Q更加和业务寚w。那么如何在实践的层面上Q在IT的生命周期中贯彻SOA的原理和思想Q一步步构徏出符合SOA设计原则的ITpȝ呢?q个问题的答案属于SOAҎ学的范畴?/p>
q义上讲QSOAҎ学诏I于IT生命周期的各个阶D和各个斚wQITpȝ目的规划,pȝ分析和设计,pȝ的实施,pȝ的部|和l护Q以及整个过E中的监控和理{。从实践的角度说Q已l出现如下SOAҎ学?/p>
Q?Q面向服务的分析和设计(SOADQ。以服务Z心,Ҏ业务需求发现服务、描q服务,q设计服务的实现?/p>
Q?Q面向服务的开发过E。结合现有开发过E,规划以服务ؓ中心的开发过E中的角艌Ӏ职责、活动和工g?/p>
Q?QSOA的成熟度分析和迁U\U图。以服务Z心,分析现有或目标系l的成熟度,q设计从现有成熟度迁Ud目标成熟度的路线图?/p>
Q?QSOA监管。设计组l和程Q确保SOA的设计原则在IT生命周期中得以诏彻,理服务生命周期中的各种q移的合理性等?/p>
本章对SOAҎ学的阐述主要集中在面向服务的分析和设计。首先介lSOAҎ学和主要的几U方法学的区别和联系Q其ơ以IBM的SOMAQService Oriented Modeling and ArchitectureQ面向服务的建模与架构)ZQ介lSOA分析和设计中的主要内容和Ҏ?/p>
![]() ![]() |
![]()
|
与SOA的设计原则类|SOAҎ学ƈ不是全新的方法学Q它是现有方法学的承和发展。一斚wQ原有的Ҏ学ƈ不能解决׃服务概念的引入带来的问题Q如怎样发现服务Q怎样定义服务Q另一斚wQ服务是一个水q的概念Q而不是一个垂直的概念Q在服务分析和设计的q程中,需要处理服务和现有Ҏ学物的关系Q如业务程和服务,企业架构和SOAQ服务和对象{。因此服务的分析和设计最主要的职责在于发现服务、定义服务和实现服务Qƈ指导如何和其他方法学l合完成q些职责?/p>
如图4-1所C揭CZ现有几种Ҏ学的定位。图的横坐标项目周期分为分析、设计和开发三个阶D,U坐标将域分为应用、架构和业务。流E徏模(BPMQ用于业务领域的分析和设计,如业务流E的定义、业务数据的定义{;企业架构QEAQ和Ҏ架构QSAQ侧重在架构领域的分析和设计Q如Ҏ业务需求确定目前目标业务系l和ITpȝQ根据目标系l需求设计主要架构元素和它们之间的关p;面向对象的分析和设计QOOADQ则贯穿分析、设计和开发三个阶D,它主要分析细_度的业务需求,如用例,分析和设计实现这些需求的cd对象Q以及它们之间的关系?/p>
?-1 传统的方法学
如图4-2所C,面向服务的分析和设计贯穿目周期的三个阶D和ITpȝ的三个域。这暗示着Q在操作层面上,面向服务的分析和设计会和其他Ҏ学紧密相联?/p>
?-2 SOA和传l的Ҏ?/strong>
1QBPM和SOA
业务程建模是一个相当零散的领域Q存在各U各LҎ和技术,有效的方法可以帮助企业对业务q行合理的划分,从而求得业务层面的灉|性。有些方法则侧重于流E徏模本w,例如如何定和定义业务流E中的业务活动、业务数据、业务规则、业务指标和业务事g{,但是BPMq不会帮助我们去发现和定义服务。从SOA的方法学来看Q各UBPM的结果是面向服务的分析和设计的重要输入,如业务组件、业务流E和业务目标是服务发现的重要依据Q而业务指标、业务数据、业务规则等是服务暴露的分析的重要依据?/p>
2QEA和SOA
管和BPM一PEA是一个零散的领域Q但是当前的EA主要侧重于定义跨业务单元边界的pȝ框架Q企业范围内pȝ的主要构成元素,q些元素间的关系Q以及将q些元素有机l合在一L参考架构。但是,各种EA技术都~Z业务领域的蓝图指g业架构的设计。从SOAҎ学来看,一斚wQ面向服务的分析和设计通过和BPMl合业务分解ؓ各种cd的服务,可以作ؓ企业业务的蓝图指g业架构的设计Q另一斚wQ企业架构设计的l果Q如参考架构,又是服务实现的重要依据?/p>
3QOOAD和SOA
面向对象的分析和设计告诉我们使用Use Case捕获需求,q设计类、对象及对象间交互来满Use Case定义的需求。但是面向对象的分析和设计往往只是局限在单个应用内部Q它不会~Z业务蓝图和企业架构蓝囄指导。从SOAҎ学看Q在原理层面上,OOAD中的很多设计原则Q如抽象、隔d注等被SOAl承和发扬,q应用于服务的定义和实现中。而在操作层面上,服务模型为OOADq行cd对象设计提供了业务蓝囑֒企业架构蓝图Q与此同ӞUse Case作ؓ对业务流E的补充说明被用于服务的发现和定义中?/p>
![]() ![]() |
![]()
|
本章以下节以IBM的SOMAZQ说明面向服务的分析和设计的主要d和方法?IBM的SOMA面向服务的分析和设计分为服务发现、服务规U和服务实现。服务的实现包括服务、组件和服务l装的实现?/p>
Z开始面向服务的分析和设计,如下的输入需要被用在分析和设计的q程中?/p>
Q?Q业务领域(Business DomainQ和业务功能域(Business Function AreaQ。业务领域和业务功能域的划分勑了目标企业的业务l构Q它一斚w帮助我们从全局的角度来理解目标企业的业务,另一斚w也是我们q行l织服务层次l构的重要依据?/p>
Q?Q业务流E(Business ProcessQ。业务流E,其是第一U的业务程Q对企业l营全局臛_重要。通常Q通过W一U的业务程可以q溯C业中最为重要的业务zdQ因此第一U业务流E是我们q行服务分析和设计的主要入口炏V?/p>
Q?Q业务目标(Business GoalQ。组l和业务程都是Z务目标服务的Qؓ了完成业务目标,l织和业务流E都有可能进行适当的调整。分析业务目标在有些时候可以帮助我们发C些通过业务程分析遗漏的服务;与此同时Q业务目标也是服务描qC一部分重要的内宏V?/p>
Q?Q现有系l(Existing SystemQ。现有系l是目前业务zd和业务流E的写照Q通过分析现有pȝ模块和功能,能够帮助发现服务。与此同Ӟ对于现有pȝ的分析和理解是进行服务实现设计的重要前提?/p>
在掌握了业务领域划分、业务流E、业务目标和现有pȝ后,SOMA按照三个阶段来进行服务分析和设计--发现服务、描q服务和服务实现Q如?-3所C。在SOMA三个阶段的分析和设计q程中,分析和设计h员还需要借助于传l方法中的一些素材,如业务环境和业务用例、IT环境、当前应用或lg的模型和设计{,从而完成与现有业务和IT紧密l合的服务规范和服务设计。在q用SOMA的过E中Q这三个阶段q不是一ơ性完成的Q一般需要一个P代的q程。另外,从企业范围而言Q分析和定的服务模型也有一个演化的q程Qƈ逐渐地精化,来脓q业务?/p>
?-3 面向服务的徏模和架构QSOMAQ概貌图
服务发现是SOMAq行服务分析和设计的W一步。服务发现的主要dQ是定在一定范围内Q通常是企业范_或若q关键业务流E范围内Q可能成为服务的候选者列表?/p>
目前有三U方式发现服务的候选者,它们分别是自上而下的领域分解、自下而上的现有系l分析和中间寚w的业务目标徏模?/p>
1Q自上而下Q领域分解)方式
自上而下的领域分解方式从业务着手进行分析,选择端到端的业务程q行逐层分解至业务活动,q对光涉及的业务活动和业务对象q行变化分析?/p>
业务lg模型是业务领域分解的输入之一。业务组件模型是一U业务咨询和转型的工P它根据业务职责、职责间的关pȝ因素Q将业务l分Z务领域、业务执行层ơ和业务lg。由于企业内部和外部环境的不同,每个业务lg在成本、投资、竞争力{方面不相同,因此Q每个业务组件在企业发展的过E中战略职责和演化的路径也是不同的,于是׃角度的不同,Ş成了所谓的业务lg?热点视图"。SOA是一U特别强调业务和IT互动的技术。对于面向服务的分析和设计,业务lg模型提供了进行服务划分的依据Q而且q种划分的方法可以^滑地从业务视囄化到服务视图?/p>
端到端的业务程是业务领域分解的另一个输入。将业务程分解成子程或者业务活动,逐q行Q直到每个业务活动都是具备业务含义的最单元。流E分解得到的业务zd树上的每一个节点,都是服务的候选者,构成了服务候选者组合。业务领域分解可以帮助发C要的服务候选者,加上自下而上和中间对齐方式发现的新服务候选者,最l会构成一个服务候选者列表。在SOA的方法中Q服务是业务lg间的契约Q因此将服务候选者划分到业务lgQ是服务分析中不可或~的一步。服务候选者列表经q业务组件的划分Q会最lŞ成层ơ化的服务目录?/p>
变化分析的目的是业务领域中易变的部分和E_的部分区分开来,通过易变的业务逻辑及相关的业务规则剥离出来Q来保证未来的变化不会破坏现有设计,从而提升架构应对变化的能力。变化分析可能会从在未来需求的分析中发C些新的服务候选者,q些服务候选者需要加入到服务候选者目录中?/p>
2Q自下而上Q已有资产分析)方式
自下而上的已有资产分析方式的目的是利用已有资产来实现服务Q已有资产包括:已有pȝ、套装或定制应用、行业规范或业务模型{?/p>
通过对已有资产的业务功能、技术^台、架构及实现方式的分析,除了能够验证服务候选者或者发现新的服务候选者,q能够通过分析已有pȝ、套装或定制应用的技术局限性,早验证服务实现决策的可行性,为服务实现决{提供重要的依据?/p>
3Q中间对齐(业务目标建模Q方?/strong>
中间寚w的业务目标徏模方式的目的是帮助发C业务寚w的服务,q确保关键的服务在流E分解和已有资分析的过E中没有被遗漏?/p>
业务目标建模业务目标分解成子目标,然后分析哪些服务是用来实现这些子目标的。在q个q程中,Z可以度量q些服务的执行情况ƈq而评C务目标,我们会发现关键业务指标、度量值和相关的业务事件?/p>
l合q三U方式的分析Q我们发现服务候选者组合,q按照业务范围划分ؓ服务目录。同时ؓ服务规约做好其他准备Q如通过对已有资产分析进行的技术可行性评伎ͼ通过业务目标建模发现的业务事件等?/p>
关于服务发现CZQ请参见本书W?3?SOA体系l构的实例讲??/p>
l过服务发现阶段Q服务目录基本Ş成,但是对于每个服务本n的属性信息依焉散。ؓ了能够将服务作ؓ业务和IT层面互动的契U,服务规约阶段是必不可的。服务规U阶D늚主要d是规范性地描述服务各个斚w的属性,其中既包括输?输出消息{功能性属性,服务安全U束和响应时间等服务质量U束Q以及服务在业务层面的诸多属性,如涉及的业务规则、业务事件、时?人员消耗等。与此同Ӟ规范描述服务相关斚w的关pM很重要,如服务间依赖关系Q服务和业务lg间关p,服务和ITlg间关pd服务消息间关pȝ?/p>
q行服务暴露决策是服务规U的W一步。理Z所有的服务候选者都可以暴露为服务,但是一旦暴露ؓ服务Q该服务候选者就必须满附加的安全性、性能{方面的要求。企业还必须为服务的规划、设计、开发、维护、监支付额外的开支,因此Q我们会Ҏ一定的规则来决定将哪些服务候选者暴露ؓ服务?/p>
q些规则包含以下几个斚wQ?/p>
Z企业应用开发的l验Q我们还可以有其他一些方面的考虑?/p>
l过服务暴露决策后,层次化的服务目录基本形成。下一步是l合传统的方法学Ҏ务各斚w属性进行描q。这里说的传l的Ҏ学是指企业架构,面向对象的分析和设计{。在企业架构Ҏ学的产物中,企业数据模型有助于服务消息的定义QITlg模型有助于服务和ITlg间关pȝ描述Q企业安全架构有助于服务安全U束规约Q企业基设施架构有助于服务质量的描述。在面向对象分析和设计的产物中,业务用例和系l用例有助于服务消息、服务相关业务规则和业务事g{描qͼlg静态模型和动态模型有助于描述服务间关pR?/p>
l过服务规约Q服务组Ӟ企业lgQ和服务的各个方面的属性被规范下来Q它会成Z务和IT层面互动的基。以后,业务对IT的新需求会体现为服务层面的变更QIT层面的变化会量遵@服务规约。在SOA监管的配合下QQ何对服务规约的变更都是可理和可控制的?/p>
关于服务规约CZQ请参见本书W?3?SOA体系l构的实例讲??/p>
l过服务规约阶段Q作Z务和IT互动的服务契U已lŞ成。但是服务契U和IT的现状还是有很大差距的,如和某个服务对应的业务逻辑分散于不同的应用中,分散在不同的地域Q某些服务目前主要依靠h工完成,q没有IT层面的实现?/p>
Z服务契U落在实圎ͼ服务实现阶段通过差距分析Qƈl合传统Ҏ学完成每个服务实现决{。这其中包括的内容甚多,其主要内容如下?/p>
Q?Q现有系l分析:调研现有pȝ架构Q了解架构风根{主要架构元素和能力和架构元素的基本特征Q调研现有应用,了解应用主要功能和对外接口,技术实现特征等Q如果应用构建已l遵循基于组件开发规范,~制应用已有lg目录Q如果应用ƈ没有lg化,应用覆盖的业务功能和服务规U确定的企业lgq行映射Q确定应用现?lg"目录?/p>
Q?Q确定服务分配:通过服务lg和现有系l分析确定的ITlg间差距分析,定服务lg和ITlg间映关pR例如,一个服务组件对应一个或多个ITlgQ没有ITlg和服务组件对应,没有服务lg和ITlg对应Q服务组件和ITlg对应时有能力~失或不匚w{。经q差距分析,一些服务中介被定下来d现服务\由,或消息格式等不匹配现象,一些新的ITlg被确定下来,如实现某业务程的组件或实现人工服务的组件等。最l,服务lg都被映射到ITlg上,从而完成服务分配?/p>
Q?Q服务实现决{:服务分配仅仅定了需要哪些组件来实现服务Q但是ƈ没有实现的策略和技术层面的决策。服务实现决{首先帮助确定服务实现策略,是在现有基础上进行服务包装,q是重新构徏Q如果重新构建,是采用已l包装好的应用,q是外包Q或者自己构建;如果是服务包装的话,有哪些候选方案等。通常服务实现决策和传l的架构决策是关联在一L?/p>
Q?Q服务基设施设计Q服务的功能实现Q非功能需求的满都需要服务基设施的支持。在q行服务实现决策后,需要根据具体的需求确定服务基设施的能力,如用于支撑h工服务的人工服务容器Q用于支撑服务编排的程引擎{?/p>
服务实现阶D늚各种产物和传l设计方法结合v来,可以开始指导实际服务实现的实施?/p>
SOA是英文词?Service Oriented Architecture"的羃写,中文有多U翻译,?面向服务的体pȝ??以服务ؓ中心的体pȝ??面向服务的架?Q其?面向服务的架?比较常见。SOA有很多定义,但基本上可以分ؓ两类Q一c认为SOA主要是一U架构风|另一c认为SOA是包含运行环境、编E模型、架构风格和相关Ҏ论等在内的一整套新的分布式Y件系l构造方法和环境Q涵盖服务的整个生命周期Q徏?开?整合-部v-q行-理。后者概括的范围更大Q着g未来的发展,我们更們于后者,认ؓSOA是分布式软gpȝ构造方法和环境的新发展阶段?/p>
在SOA架构风格中,服务是最核心的抽象手D,业务被划分(lg化)Zpd_粒度的业务服务和业务流E。业务服务相对独立、自包含、可重用Q由一个或者多个分布的pȝ所实现Q而业务流E由服务l装而来。一?服务"定义了一个与业务功能或业务数据相关的接口Q以及约束这个接口的契约Q如服务质量要求、业务规则、安全性要求、法律法规的遵@、关键业l指标(Key Performance IndicatorQKPIQ等。接口和契约采用中立、基于标准的方式q行定义Q它独立于实现服务的gq_、操作系l和~程语言。这使得构徏在不同系l中的服务可以以一U统一的和通用的方式进行交互、相互理解。除了这U不依赖于特定技术的中立Ҏ,通过服务注册库(Service RegistryQ加上企业服务ȝQEnterprise Service BusQ来支持动态查询、定位、\由和中介QMediationQ的能力Q得服务之间的交互是动态的Q位|是透明的。技术和位置的透明性,使得服务的请求者和提供者之间高度解耦。这U松耦合pȝ的好处有两点Q一Ҏ它适应变化的灵zL;另一Ҏ当某个服务的内部l构和实现逐渐发生改变Ӟ不媄响其他服务。而紧耦合则是指应用程序的不同lg之间的接口与其功能和l构是紧密相q的Q因而当发生变化Ӟ某一部分的调整会随着各种紧耦合的关pd起其他部分甚x个应用程序的更改Q这Lpȝ架构很脆弱了?/p>
SOA架构带来的另一个重要观Ҏ业务驱动ITQ即IT和业务更加紧密地寚w。以_粒度的业务服务为基来对业务建模Q会产生更加z的业务和系l视图;以服务ؓ基础来实现的ITpȝ更灵zR更易于重用、更好(也更快)地应对变化;以服务ؓ基础Q通过昑ּ地定义、描q、实现和理业务层次的粗_度服务Q包括业务流E)Q提供了业务模型和相关IT实现之间更好?可追溯?Q减了它们之间的差距,使得业务的变化更Ҏ传递到IT?/p>
因此Q可以将SOA的主要优Ҏ括ؓQIT能够更好更快地提供业务h|Business CentricQ、快速应变能力(FlexibilityQ、重用(ReusabilityQ?/p>
从演变的历程来看QSOA在很多年前就被提出来了,现在SOA的再现和行是若q因素的l合。一斚w是多q的软g工程发展和实跉|U篏的经验、方法和各种设计/架构模式Q包括OO/CBD/MDD/MDA、EAI和中间gQ另一斚w是互联网的多q发展带来前所未有的分布式pȝ的交互能力和标准化基。与此同Ӟ企业来重视业务模型本w的lg化,以支持高度灵zȝ业务战略。但是现有的企业软g架构不够灉|Q难以适应日益复杂的企业整合,难以满随需应变商务的需要,因此与业务对齐、以业务的敏捷应变能力ؓ首要目标、松散耦合、支持重用的SOA架构Ҏ得到青睐。更多的l节请参?
Z我们同客h交道的经验,有必要在q里澄清大家l常h的几个基本问题?/p>
W一QSOA是架构风|是方法;而不是具体架构具体实现技术(如Web ServiceQ、具体架构元素(如企业服务ȝQEnterprise Service BusQESBQ?/p>
l常有h认ؓ只要用了Web ServiceQ就是SOA了。这是不对的QWeb Service只是实现服务的一U具体技术表现Ş式。同P认ؓ搞SOAQ就是买点YӞZESBQ这也是不对的,ESB只是SOA架构风格中的一部分。首先,ESB是一U从实践中ȝ出来的架构风格元素,即BUSQȝ模式Q;其次QESB的主要功能是负责q通性和服务中介QService MediationQ,解耦服务的h者和服务的提供者?/p>
W二QSOA的首要目标是IT与业务对齐,支持业务的快速变化;其次是IT架构的灵zL和IT资的重用?/p>
业务Ҏh的需要,是SOA最大的驱动力。一斚w是业务在q方面的要求来高Q另一斚w是今天的IT很不灉|Q很N应业务快速变化的需求,不仅仅是因ؓIT架构不灵z,更重要的是业务模型中的元素和ITpȝ的元素之间存在很大的差距。这U不寚wQ导致业务h员和IT人员之间的沟通不够有效,业务的变化需要花费很大的代h传递到ITpȝ。很难想像,业务人员对一个Java对象Q一个EJB或者一个JSP面感兴,q离业务世界太远了。这U业务和IT的对齐,需要在ITpȝ中实现更高阶的抽象元素,是业务模型中的元素Q服务、流E、业l管理)Qƈ且满业务需要的水^整合Q将人、信息、应用和程端到端地动态整合v来)。这样一个以服务Z心的、端到端整合的环境,首先使得业务变化可以在业务元素这个层面上沟通,更容易、更准确C业务传递到IT。其ơ,q种变化被隔d需要变化的局部,而不扩散到系l的其他部分。这需要整个IT架构本n是松散耦合的,一个服务的变化Q功能、数据、过E、技术环境等Q不影响其他服务。最后,我们希望q些反映业务元素的服务,是相对稳定、可以重用的Q这对快速适应变化、减成本是非常重要的?/p>
W三Q在工程上,SOA的重Ҏ服务建模和基于SOA的设计原则进行架构决{和设计?/p>
l常到客户提出q样的问题:SOA挺好Qؓ什么好Q怎么做才是SOA的方法?跟过ȝҎQ比如OO/CBD有什么不同?有时候一个J2EE服务器就好了Qؓ什么那么复杂? 从徏模和设计的角度来_SOA更多C重在业务层次上,也就是通过服务建模业务组件化为服务模型,它是业务架构的底层,是技术架构的层Q承上启下,是灵zȝ业务模型和IT之间的桥梁,保证二者之间的"可追溯?。从q里往下,是基于已有的ҎQ比如OO/CBD来进行的。从架构的层ơ上QSOA更多C重于如何企业范围内多个分布的系l(包括已有pȝ/遗留pȝQ连接v来(ESBQAdapter/ConnectorQ,如何它们的功能、数据{化ؓ服务Q如何通过服务中介机制QESBQService RegistryQ保证服务之间以松散耦合的方式交互,如何l装Q集成)服务为流E,如何理服务和流E等。从q往下,对于实现服务的一个具体应用,它的架构、设计和实现是可以基于已有的实践和方法的Q比如J2EE?NET?/p>
有些时候,׃业务需求比较简单,所有这些东襉K在一个J2EE的应用服务器上,有些要素不是那么H出Q不q随着pȝ规模的扩大,要解决的业务问题更复杂、范围更大的时候,SOA的各U架构要素就会变得越来越重要?/p>
在下面的节里就概括地讨Z下SOA的若q个重要斚wQ包括:面向服务的计环境,~程模型Q架构风|工程ҎQ以及相关的技术?/p>
![]() ![]() |
![]()
|
计算环境׃l计机、Y件^台和怺联通的|络l成Q这个环境能够处理和交换数字信息Q允许外界访问其内信息资源(1Q?。不同的计算环境有不同的计算风格和编E模型,׃些特定于该计环境的技术来支撑。如何在一个计环境中分割和部|计能力、数据资源,如何让各个部分相互通信和协作,如何在概念上寚w题域q行建模Q然后映到该计环境,都会受到计算环境的媄响和制约。因此,了解一下计环境的历史Q会帮助我们理解面向服务的计环境是如何演变而来的?/p>
计算环境的演变经历了若干个阶D,在早期的L时代Q绝大多数的计算功能和系l的l成部分Q都包括在一台机器里。在20世纪80q代Q随着PC的繁荣,计算环境发生很大的变化。通过局域网怺q接的计设备构成客?服务器计环境,计算资源和数据资源被适当地分Ԍ客户和服务器通过|络协议、远E调用或消息{方式来怺协作Q完成计?/p>
Z满更高的可伸羃性需求,多层架构出现Q计资源和数据资源的分布多样化Q与企业中原来已l存在的计算环境Q尤其是L及其遗留pȝ之间的集成也变得来重要。中间gq速发展,开始出现分布式对象、组件和接口{概念,用于在计环境中更好地分割运逻辑和数据资源。计环境中不同部分之间的交互,也从原有相对低层的网l协议、远E调用和消息机制的基上,发展到支持分布式对象、组件和接口之间的交互,q种交互在名字服务(Naming ServiceQ等的支持下Q通常是位|透明的。但׃~Z普遍的标准化支持Q很隑ց到技术透明Q系l是紧耦合的?/p>
随着互联|(InternetQ的发展Q开攑֒标准的网l协议被普遍支持Q所有底层计^台都开始支持这些标准和协议Q这D一个计环境内部和各个计算环境之间交互的藩p打破。数据和功能的表CZ交互在XML、WEB服务QWeb ServiceQ技术与标准的基上,保证了通用性和最大的交互能力Q这使得计算环境发展C个全新的阶段--Z标准、开攄互联|技术的计算环境。在q样的计环境中Q各个部分可以采用异构的底层技术,它们使用XML来描q和表示自己的数据和功能Q采用开攄|络协议Q如HTTPQ来握手Q在此之上,ZWeb服务来互操作和交换数据。在q里Q一个很重要的新概念?服务"Q?a >2Q,它是一个自包含的功能,使用者通过明确定义的接口(契约Q来与一个服务交互,q个接口的描q基于WSDLQWeb Service Description LanguageQ这L开放标准。对象和lg重在表示一个事物本w的l成部分和相互关联(也就是WHAT"THINGS"ARE的问题)Q而服务则表示一个事物做什么(也就是WHAT"THINGS"DO的问题)。Web服务是实现服务的技术手D,如同各U编E语a中的对象是实现对象的技术手D,J2EE中的EJB是实现组件的技术手D一栗这U基于标准、开攄互联|技术,以服务ؓ中心的计环境,我们UC?面向服务的计环??/p>
在面向服务的计算环境中,pȝ可以是高度分布、异构的。它一般包括服务运行时环境QService RuntimeQ、服务ȝQService Integration InfrastructureQ、服务网养IService GatewayQ、服务注册库QService RegistryQ和服务l装引擎QService Choreography EngineQ等Q如?-1所C?/p>
服务q行时环境提供服务(和服务组Ӟ的部|Ӏ运行和理能力Q支持服务编E模型,保证pȝ的安全和性能{质量要素;服务ȝ提供服务中介的能力,使得服务使用者能够以技术透明和位|透明的方式来讉K服务Q服务注册库支持存储和访问服务的描述信息Q是实现服务中介、管理服务的重要基础Q而服务组装引擎,则将服务l装为服务流E,完成一个业务过E;服务|关用于在不同服务计环境的边界q行服务译Q比如安全?/p>
面向服务的计环境是开攄、标准的Q由如图1-2所C的技术标准协议栈所定义和支持。例如,Transport层的HTTP协议QService Description层的WSDLQBusiness Process层的WS-CDL{,与Policy相关的WS-Policy。本书后面的章节讨论所有统UCؓWS-*的标准和协议?/p>
?-1 SOA计算环境的组成要?/strong>
?-2 SOA计算环境的标准协议栈
面向服务的计环境,为IBM所定义的随需应变计算环境奠定了现实基。随需应变计算环境应具备以下特点,如图1-3所C?/p>
?-3 随需应变的计环境应该具备的特点
Q?Q整合:h、过E、应用和数据全面整合h?/p>
Q?Q虚拟化Q将分布、异构的物理资源Q服务器、存储设备等Q整合v来,呈现为统一的逻辑对象Q以安全和可理的方式供使用?/p>
Q?Q自主计:如同生物体一Ppȝ具备一些高U生物系l的能力Q包括自我诊断和修复问题Q自动配|和调整以适应环境的变化,自动优化资源的用效率、增强工作负L处理的能力,自我保护数据和信息的安全?/p>
Q?Q开放标准:整个环境建立在开攄标准之上Q保证系l的交互性?/p>
不同的服务计环境,采用不同的技术和产品Q这里主要结合IBM的品和技术来介绍在J2EEq_上实现的服务计算环境?/p>
L通过增加对互联网技术和标准的支持,来创ZZ的面向服务计环境。比如IBM的CICS 3.1Q提供了SOAP和Web服务的支持,可以主Z的应用以Web服务的方式提供出来,供消费者用?/p>
多年来,IT界的主要技术提供者,一直携手努力定义和推动Web服务的相x准,q且在主要的几个计算q_上实C高度兼容Q包?NETQJ2EE和开源^収ͼ如LAMPLinuxQApacheQmySQLQPHP/Perl/PythonQ?/p>
IBM以J2EE为基Q提供了全面的、强大的服务计算环境Q如?-4所C?/p>
?-4 IBM提供的服务计环?/strong>
在这个计环境中Q它是服务的世界。其中,Access Services提供讉K已有应用或遗留系l的能力Q将已有pȝ中的功能和信息{化ؓ服务QIBM提供了访问不同系l的适配器和相应的框架来帮助转化。Business App Services指那些通过新的计算q_J2EEQ如IBM的WebSphere Application ServerQ来实现的新应用Q它们所实现的功能和信息也都转化为服务提供出来。Partner Service指那些来自合作伙伴的服务QWebSphere Partner Gateway提供企业边界处不同安全等差异的{换。Information Service是那些跟信息Q而不是活动)有关pȝ服务Q比如将多个pȝ中异构的数据Q聚合、{换ؓ业务需要的l一整齐的业务数据对象来讉K。Process Service是指把多个服务聚合成Z个服务流E对应业务过E的服务Q这U复合服务通常是长旉q行的过E。Interaction Service是把人的zdQ通过人机交互以服务的方式出现在整个业务过E中Q作为Process Service中的一部分?/p>
在面向服务计环境中Q企业服务ȝ处于非常重要的位|,它提供服务的中介Q解耦服务请求者和服务提供者,是服务计环境中的核心?ESB是过L息中间g的发展,采用?ȝ"q样一U模式来理和简化应用之间的集成拓扑l构Q以qؓ接受的开放标准ؓ基础来支持应用之间在消息、事件和服务U别上的动态互联互通?/p>
ESB的基本特征和能力包括Q描q服务的元数据和服务注册理Q在服务h者和提供者之间传递数据及对这些数据进行{换的能力Qƈ支持由实践中ȝ出来的一些模式如同步模式Q异步模式等Q发现、\由、匹配和选择的能力,以支持服务之间的动态交互,解耦服务请求者和服务提供者。高U一些的能力Q包括对安全的支持、服务质量保证、可理性和负蝲q{?/p>
ESB所提供的基于标准的q接服务Q将应用中实现的功能或者数据资源,转化为服务请求者能以标准的方式来访问的服务Q当h者来h一个服务时QESB中这U中介{化过E可能简单到什么也没有Q也可能要很复杂的中介服务支持,包括动态地查找、选择一个服务,消息的传递、\由和转换、协议的转换。这U中介过E,是ESB借助于服务注册管理及问题域相关的知识Q如业务斚w的一些规则等Q自动进行的Q不需要服务请求者和提供者介入,从而实C解耦服务请求者和提供者的技术基。这使得服务h者不需要关心服务提供者的位置和具体实现技术,双方在保持接口不变的情况下,各自可以独立地演变?/p>
所以,ESB采用ȝl构模式化了应用之间的集成拓扑,通过源自实践的模式,提供了基于标准的通用q接服务Q得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互Q从而在不同层次上得SOA解决Ҏ是一个松散耦合、灵zȝ架构?/p>
需要注意的是,ESB是一U架构模式,不能单地{同于特定的技术或产品Q但实现ESB实需要各U品在q行时和工具斚w的支持。IBM有很好的产品支持Q运行时支持包括WebSphere ESB和WebSphere Message BrokerQ工h持有WebSphere Integration DeveloperQ支持用户以囑Ş界面的方式来完成相关的开发Q务,如发布服务、用各U模式、{换消息和定义路由{?/p>
1.2.5 面向服务的编E模型:服务lg架构QSCAQ和服务数据对象QSDOQ?/span>
Z促进面向服务应用的开发,IT公司联合hQ在2005q?1月发布了服务lg架构QService Component ArchitectureQ和服务数据对象QService Data ObjectQ规范,q些公司包括IBMQBEAQOracleQSAP{?/p>
SCA的目标是大大地简化服务开发,直接采用Web服务和XML开发服务,使得E序员工作在底层技术上Q需要应付各U异构环境下的具体实现细节。其中,SCA定义和规范了技术中立和实现透明的服务组件、服务及服务调用和组装;而SDO定义和规范了服务世界里的数据Q这些数据对象拥有清晰定义的信息模型Q独立于数据源和具体数据讉K技术,使得服务讉K数据和在服务之间交换数据更方ѝ有效?/p>
很多公司已经在J2EEq_上支持了SCA/SDOQ还提供了C++的版本。IBM WebSphere Process Server 6实现了SCA/SDO规范Q提供了最新的SOA~程模型的支持,已经在很多实践中被广泛用?/p>
![]() ![]() |
![]()
|
软g开发一直是一件很隄事情Q因为我们要处理的问题越来越复杂Qh们处理这U复杂性最主要的手D就是抽象。回֎Ԍ我们的抽象层ơ越来越高,反映在各个方面,从编E语a、^台、开发过E、工具到模式。尤其是模式Q大量出现在那些l构上设计得很好的Y件系l中Q无论是微观层次上(对象、组ӞE_出现的结构范式,q是在宏观层面上出现的架构模式。用哪些抽象手D|为问题域建模Q如何定义组成部分之间的协作和结构关p?如何定义从外界所看到的系l结构和行ؓQ是什么设计原则在指导我们的架构决{?有什么最佛_践和模式可供借鉴Q所有这些,形成了不同设计风格和体系l构范式QArchitecture ParadigmQ?/p>
通常Q一U体pȝ构范式,包括设计原则Q来自实늚l构式样、组成要素和关系Q以及在整个开发生命周期中它们是如何被识别、描q和控制的。体pȝ构从q去单个应用包罗一切的客户/服务器的模式Q逐渐演变C层和多层l构的各U分布式计算模式。今天,Z开始谈论和实践面向服务、更加分布化的架构范式?/p>
从抽象手D而言QSOA在原有方法的基础上,增加了服务、流E等元素。这些抽象手D之间的关系如图1-5所C?/p>
如何利用q些抽象手段Q将一个业务需求{化ؓ程、服务,q一步徏模ؓ服务lgQ然后结合具体实现环境,在重用已有系l的功能和数据资源的基础上来实现Q如?-6所C是IBMȝ的SOA架构概念模式?/p>
SOA架构中,l承了来自对象和lg设计的各U原则,如封装、自我包含等。那些保证服务的灉|性、松散耦合和重用能力的设计原则Q对SOA架构来说同样是非帔R要的?/p>
l构上,服务ȝ是SOA的架构模式之一?/p>
关于服务Q一些常见和讨论的设计原则如下:
Q?Q无状态。以避免服务h者依赖于服务提供者的状态?/p>
Q?Q单一实例。避免功能冗余?/p>
?-5 SOA中的重要抽象手段
?-6 SOA的概忉|构模?/strong>
Q?Q明定义的接口。服务的接口由WSDL定义Q用于指明服务的公共接口与其内部专用实现之间的界UѝWS-Policy用于描述服务规约QXML模式QSchemaQ用于定义所交换的消息格式(x务的公共数据Q。用者依赖服务规U来调用服务Q所以服务定义必长旉E_Q一旦公布,不随意更改;服务的定义应可能明,减少使用者的不适当使用Q不要让使用者看到服务内部的U有数据?/p>
Q?Q自包含和模块化。服务封装了那些在业务上E_、重复出现的zd和组Ӟ实现服务的功能实体是完全独立自主的,独立q行部v、版本控制、自我管理和恢复?/p>
Q?Q粗_度。服务数量不应该太大Q依靠消息交互而不是远E过E调用(RPCQ,通常消息量比较大Q但是服务之间的交互频度较低?/p>
Q?Q服务之间的松耦合性。服务用者看到的是服务的接口Q其位置、实现技术、当前状态等对用者是不可见的Q服务私有数据对服务使用者是不可见的?/p>
Q?Q重用能力。服务应该是可以重用的?/p>
Q?Q互操作性、兼容和{略声明。ؓ了确保服务规U的全面和明,{略成ؓ一个越来越重要的方面。这可以是技术相关的内容Q比如一个服务对安全性方面的要求Q也可以是跟业务有关的语义方面的内容Q比如需要满的费用或者服务别方面的要求Q这些策略对于服务在交互时是非常重要的。WS- Policy用于定义可配|的互操作语义,来描q特定服务的期望、控制其行ؓ。在设计Ӟ应该利用{略声明保服务期望和语义兼Ҏ方面的完整和明?/p>
软g工程Ҏ和过E伴随着软g实践不断发展。Y件危机发生之后,从瀑布模型、原型方法等讲究q程、文档密集、控制较多的ҎQ逐渐发展到轻量、敏捷和q代的方法。这些方法更加h性化Q避免因重的q程而扼杀人的d性和创造性。这些方法更快速地交付对客h价值的软g、直接的沟通、持l集成和持箋质量保证?/p>
SOA和当前Y件工E过E的一个共同交叉点是业务价值驱动(Business CentricQ,速度。SOA从Y件的灉|性和重用能力入手Q而敏捯E则从Y件交付效率出发?/p>
SOA的架构特性,使得敏捷q程非常适合SOA目的实施。在SOA架构中,服务的独立性,使得每个服务可以被单独地开发、测试和集成。一个企业中的ITpȝQ如果是ZSOA的计环境,那么q个环境是一个服务的生态系l,每开发一个服务,马上可以独立部|Ԍ成ؓq个生态系l中的一部分。这h很好地支持了持箋集成、持l质量保证,又很好地使得q个服务马上产生业务价|而不是苦{其他服务的C。服务的Ҏ,使得敏捷q程和SOA架构可以有一个很好的l合Q让二者相得益彰。以我们与不同客户合作的实践Q我们已l充分体会到q二者在实现q程中的风险控制、业务需求改变的适应能力斚w怺配合的好处。比如我们在中远集运Q从瀑布q程转向了P代的开发过E,采用了敏h法的原则?/p>
在韩国的目里,我们的团队来自IBM中国QIBM韩国及韩国客戯q工程师,分处汉城和北京两个地方,q些工程师怎样协作才能很快C付高质量的系l而不怺牉|Q对于北京的工程师,北京的团队无法复制客户在汉城的已有系l,如何试自己开发的服务Q通过服务建模Q系l被分解q相互独立的服务Q我们将那些要重用已有系l来实现的服务交l汉城的队员Q其他的交给北京的队员,q且要求每个服务开发h员提供一个简单的"?实现QMock ServiceQ。一开始,q些单实现被部v在北京和汉城的测试环境中Q然后各个服务开发小l开始各自独立地开发自己所负责的服务,而流E开发h员也在同一旉开始开发他的流E,不过所Z的服务是在那些简单实C上,但是q些单实现以支持有意义的单元和集成试。随后,一旦某个服务被实现Q它p部v到实际的环境中,通过调整ESB的服务中介配|,Ҏ服务的请求被路由到真实实现。一旦真实实现有问题Q还可以换回单实玎ͼ以避免媄响其他服务、流E的单元和集成测试。这U灵zL带来的随时开发、随旉|Ӏ随旉成和试对于采用敏捷q程是非常有利的?/p>
![]() ![]() |
![]()
|
本节讨论目前SOA体系架构中用到的主要技术和标准?/p>
在前面关于计环境的讨论里,我们已经提到SOA计算环境的主要组件包括:服务q行时环境、服务ȝ、服务注册库、服务网兛_程引擎。通常Q还会包括服务管理、业务活动监控(Business Activity MonitoringQ和业务l效理QBusiness Performance ManagementQBPMQ。另外,在服务徏模、开发和~排服务{方面,我们需要相应的工具来支持。在分析、设计方面,我们需要基于服务的分析、设计方法,是我们通常说的服务建模Q包括服务的识别、定义和实现{略Q其输出是一个服务模型(Service ModelQ?/p>
Web服务作ؓ实现SOA中服务的最主要手段。我们首先来了解跟Web Service相关的标准,它们大多?WS-"作ؓ名字的前~Q所以统UWS-*?Web服务最基本的协议包括UDDIQWSDL和SOAPQ通过它们Q我们可以提供直接而又单的Web Service支持Q如?-7所C?/p>
但是基本协议无法保证企业计算需要的安全性和可靠性,所以我们需要增加这斚w的协议,比如WS-SecurityQWS-Reliability和WS-ReliableMessagingQ对于复杂的业务场景Q我们需要WS-BPEL和WS-CDLq样的语a来将多个服务~排成ؓ业务程Q管理服务的协议如WS-ManageabilityQWSDM{。跟Web服务相关的标准,q在快速发展当中。目前在SOA产品和实践中Q除了基本协议外Q比较重要的q包括BPELQWS-SecurityQWS-Policy和SCA/SDO。如?-1所C给Z一个基本的ȝQ后面的章节会介l重要的技术和标准?/p>
?-7 基本Web服务协议
?-1 当前Web服务协议?/strong>
目前QWeb的标准和技术在演变当中Q不同的技术环境的支持力度也不同,但是前面提到的基本核心协议,都有很好的支持。关于Web服务协议的接受和支持E度Q如?-8所C?/p>
?-8 当前Web服务的接受情?/strong>
SOA服务hq_独立的自我描qXML文档。Web服务描述语言QWSDLQ?nbsp;Web Services Description LanguageQ是用于描述服务的标准语a?/p>
SOA 服务用消息进行通信Q该消息通常使用XML Schema来定义(也叫做XSDQ?nbsp;XML Schema DefinitionQ。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档?/p>
在一个企业内部,SOA服务通过一个扮演目录列表(directory listingQ角色的登记处(RegistryQ来q行l护。应用程序在登记处(RegistryQ寻扑ƈ调用某项服务。统一描述Q定义和集成QUDDIQ?nbsp;Universal DescriptionQ?nbsp;DefinitionQ?nbsp;and IntegrationQ是服务登记的标准?/p>
每项SOA服务都有一个与之相关的服务品质QQoSQ?nbsp;quality of serviceQ。QoS的一些关键元素有安全需求(例如认证和授权)Q可靠通信Q译注:可靠消息是指Q确保消?#8220;仅且仅仅”发送一ơ,从而过滤重复信息。)Q以及谁能调用服务的{略?/p>
Z么选择SOAQ?/strong>
不同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基础投资?/p>
如图1的例子所C,一个用SOA的企业,可以使用一l现有的应用来创Z个供应链复合应用Qsupply chain composite applicationQ,q些现有的应用通过标准接口来提供功能?/p>
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类似审核,列表QbillingQ,日志{功能。此外,该架构给企业提供了灵zȝ业务程Q更好地处理控制hQregulatory requirementQ,例如Sarbanes OxleyQSOXQ,q且可以在不影响其他服务的情况下更改某项服务?/p>
SOA基础l构
要运行,理SOA应用E序Q企业需要SOA基础Q这是SOAq_的一个部分。SOA基础必须支持所有的相关标准Q和需要的q行时容器。图3所C的是一个典型的SOA基础l构。接下来的章节将逐一讨论该结构的每个部分?/p>
Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.
SOAPQ?nbsp;WSDLQ?nbsp;UDDI
WSDLQUDDI和SOAP是SOA基础的基部g。WSDL用来描述服务QUDDI用来注册和查找服务;而SOAPQ作Z输层Q用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机Ӟ其他的技术ؓ可以服务实现其他cd的绑定。一个消费者可以在UDDI注册表(registryQ查找服务,取得服务的WSDL描述Q然后通过SOAP来调用服务?/p>
WS-I Basic Profile
WS-I Basic ProfileQ由Web服务互用性组l(Web Services Interoperability OrganizationQ提供,是SOA服务试与互用性所需要的核心构g。服务提供者可以用Basic Profile试E序来测试服务在不同q_和技术上的互用性?/p>
J2EE ?nbsp;.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的服务互用?/p>
服务品质
在企业中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织Qstandards bodiesQ提出,像W3CQWorld Wide Web ConsortiumQ和OASISQthe Organization for the Advancement of Structured Information StandardsQ。下面的部分会讨论一些QoS服务和相x准?/p>
安全
Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换Q?nbsp;消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准,例如QSAMLQas Security Assertion Markup LanguageQ来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定?/p>
可靠
在典型的SOA 环境中,服务消费者和服务提供者之间会有几U不同的文档在进行交换。具有诸?#8220;仅且仅仅传送一?#8221;Q?nbsp;once-and-only-once deliveryQ,“最多传送一?#8221;Q?nbsp;at-most-once deliveryQ,“重复消息qo”Qduplicate message eliminationQ,“保证消息传?#8221;Qguaranteed message deliveryQ等Ҏ消息的发送和认Q在关键dpȝQmission-critical systemsQ中变得十分重要。WS-Reliability ?nbsp;WS-ReliableMessaging是两个用来解xc问题的标准。这些标准现在都由OASIS负责?/p>
{略
服务提供者有时候会要求服务消费者与某种{略通信。比如,服务提供商可能会要求消费者提供Kerberos安全标示Q才能取得某Ҏ务。这些要求被定义为策略断aQpolicy assertionsQ。一策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的{略通信?/p>
控制
当企业着手于服务架构Ӟ服务可以用来整合数据仓库Qsilos of dataQ,应用E序Q以及组件。整合应用意味着例如异步通信Qƈ行处理,数据转换Q以及校正等q程h必须被标准化。在SOA中,q程是用一l离散的服务创徏的。BPEL4WS 或?nbsp;WSBPELQWeb Service Business Process Execution LanguageQ是用来控制q些服务的语a。WSBPEL目前也由OASIS负责?/p>
理
随着企业服务的增长,所使用的服务和业务q程的数量也随之增加Q一个用来让pȝ理员管理所有运行在多相环境下的服务的管理系l就昑־ؓ重要。WSDMQWeb Services for Distributed ManagementQ规定了MҎWSDM实现的服务都可以׃个WSDM适应QWSDM-compliantQ的理Ҏ来管理?/p>
其它的qosҎ,比如合作方之間的溝通和通訊Q多個服務之間的事務處理Q都在WS-Coordination ?nbsp;WS-Transaction 標準中描qͼ 這些都是OASIS 的工作?/p>
SOA 不是Web服务
在理解SOA和Web服务的关pMQ经常发生淆。根?003q?月的Gartner报道QYefim V. Natisp个问题是q样解释的:“Web服务是技术规范,而SOA是设计原则。特别是Web服务中的WSDLQ是一个SOA配套的接口定义标准:q是Web服务和SOA的根本联pR?#8221;从本质上来说QSOA是一U架构模式,而Web服务是利用一l标准实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实C个中立^収ͼ来获得服务,而且随着来多的Y件商支持来多的Web服务规范Q你会取得更好的通用性?/p>
SOA的优?/strong>
SOA的概念ƈ非什么新东西QSOA不同于现有的分布式技术之处在于大多数软g商接受它q有可以实现SOA的^台或应用E序。SOA伴随着无处不在的标准,Z业的现有资或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创徏应用QSOA能够使客h服务消费者免予服务实现的改变所带来的媄响;SOA能够升单个服务或服务消费者而无需重写整个应用Q也无需保留已经不再适用于新需求的现有pȝ。总而言之,SOA以借助现有的应用来l合产生新服务的敏捷方式Q提供给企业更好的灵zL来构徏应用E序和业务流E?/p>
相关的一些资源:
本土QJBoss SeamQ?a target="blank">http://www.jboss.com/products/seam
DocsQSeam DocumentQ?a target="blank">http://labs.jboss.com/portal/jbossseam/docs
入门Q?
一个用JBoss Seam化Web开发的Flash演示Q可以当做JBoss Seam的入门教?
Example showing you how to generate a CRUD web application from a database using JBoss Eclipse IDE
q阶Q?
IBM developerWorks里的专题?a target="blank">Seam - 无缝集成 JSF?
q个pd讲述?Seam 是真正适合 JSF 的第一个应用程序框Ӟ能够修正其他扩展框架无法修正的主要弱炏V阅读该pd的文章,您可以自己判?Seam 是不是对 JSF 的适当补充?/p>
目前有三文章在里面?
1?a target="blank">?JSF 量n定做的应用程序框?/a>
JSF 是用?Java Web 应用E序的第一个标准化的用L面框Ӟ?Seam 是一个扩?JSF 的强大的应用E序框架。本文将发现q两U框架之间的互补性?
2?a target="blank">借助 Seam q行对话
借助 Seam 开发有状态的 CRUD 应用E序是g轻而易丄事情。本文向您展C如何?Java™Server Faces (JSF) ?Seam 为基?Web 的高夫评目录开发创建、读取、更新和删除用例?
3?a target="blank">用于 JSF ?Ajax
JSF Zlg的方法论促进了抽象,但大多数 Ajax 实现׃公开了底层的 HTTP 交换而之大受干扰。本文展CZ如何使用 Seam Remoting API ?Ajax4jsf lg与服务器上的受管 bean 通信Q就好像q些 bean 与浏览器同在本地一栗?/p>