Service-Oriented Architecture)Q即面向服务的架构，q是最q一两年出现在各U技术期刊上最多的词汇了。现在有很多架构设计师和设计开发h员简单的把SOA和W(xu)eb Services技术等同v来，认ؓSOA是Web Service的一U实现。本质上来说QSOA体现的是一U新的系l架构，SOA的出玎ͼؓ整个企业UY件架构设计带来巨大的影响?
1. 什么是架构?什么是ZSOA的架?
1.1 什么是架构
从架构设计师的角度来看，架构是一套构建系l的准则。通过q套准则Q我们可以把一个复杂的pȝ划分Z套更单的子系l的集合Q这些子pȝ之间应该保持怺独立Qƈ与整个系l保持一致。而且每一个子pȝq可以l细分下去，从而构成一个复杂的企业U架构?/p>
当一名架构设计师在构建某个企业的Y件系l时Q除了要考虑q个pȝ的架构以及其应具有的功能行ؓ以外Q还要关注整个架构的可用性，性能问题Q容错能力，可重用性，安全性，扩展性，可管理维护性，可靠性等各个相关斚w。有的时候一名好的架构设计师甚至q需要考虑所构徏的系l架构是否合乎美学要求。由此我们可以看刎ͼ我们衡量一个好的架构设计ƈ不能只从功能角度出发Q还要考虑很多其他的因素，对Q何一个方面的Ơ缺考虑都有可能为整个系l的构徏埋下隐?zhn)?/p>
1.2 什么是ZSOA的架?/strong>
SOA本n是一U面向企业服务的系l架构，单来_SOA是一U进行系l开发的新的体系架构Q在ZSOA架构的系l中Q具体应用程序的功能是由一些松耦合q且hl一接口定义方式的组?也就是service)l合构徏h的。因此，ZSOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处在于SOA提供的业务灵zL。业务灵zL是指企业能对业务变更快速和有效地进行响应、ƈ且利用业务变更来得到竞争优势的能力。对企业U架构设计师来说Q创Z个业务灵zȝ架构意味着创徏一个可以满_前还未知的业务需求的IT架构?/p>
利用ZSOA的系l构建方法，如图1中所C的一P一个基于SOA架构的系l中的所有的E序功能都被装在一些功能模块中Q我们就是利用这些已l封装好的功能模块组装构建我们所需要的E序或者系l，而这些功能模块就是SOA架构中的不同的服?services)?br />
_51CTO_COM--中国最大的|络技术网?files/1621360.jpg)
?
因此QSOA架构本质上来说体C一U复合的概念:它不仅ؓ一个企业中商业程的组l和实现提供了一U指导模式，同时也ؓ具体的底层service开发提供了指导?/p>
2. SOA架构设计师的角色
2.1 SOA架构设计师应该具备什?
谈到SOA架构设计师的角色Q我们首先要了解架构设计师应h的能力。M上来_一个好的架构设计师不仅应该是一个成熟的Q具有实际经验的q具有快速学?fn)能力的人，而且他还应该h良好的管理能力和沟通能力。只有具备了必需的能力，架构设计师才能在关键的时M出困隄军_Q这是一名架构设计师应该承担的责仅R从角色上来看，SOA 架构师不仅会负责端到端的服务h者和提供者的设计Qƈ且会负责对系l中非功能服务请求的调研和表q?/p>
对于M一名经验丰富的架构设计师来_不论他是采用Z传统的架构设计方?ZJ2EE架构或?NET架构)q是采用ZSOA的架构设计方法来构徏一个企业的系l架构，h相关商业领域的知识对于架构设计师来说都是必不可少的，架构设计师往往可以通过实际的工作经验积累以及接受相关的专项培训来获得这些商业领域的知识。除了具有相兛_业领域的知识以外Q一名合格的架构设计师必d有较q泛的技术背景，q可能包括YgQ通信Q安全等各个斚w的知识。但qƈ不是意味着要成Z名架构设计师必ȝ(zhn)每一门具体技术的l节Q架构设计师必须臛_能对各种技术有一个整体上的了解，能够熟知每种技术的特点以及优缺点，只有q样架构设计师才能在特定的应用场景下正确地选择各种技术来设计企业整体架构?/p>
2.2 什么是SOA架构设计师的职责?
那什么是企业USOA架构设计师的具体角色?什么是SOA架构设计师与设计和开发h员之间的差别?怿q些都是使大家最Ҏ(gu)产生qh的问题。D个实际的例子来说Q当构徏一个基于SOA架构的系l的时候，针对一个具体的 serviceQ系l设计h员主要应该关注的是这个service能够为外部用h供什么样的服务，也就是说pȝ设计人员x的是q个service所提供的功能。而对于SOA架构设计师来_他们更关心的可能是当有一千个用户同时调用q个 service的时候，什么会发生?也就是说架构设计师关注的应该是一些商业需求和服务U别(service-level)需求。所有的架构设计师的角色都包含了在构Z个系l的一开始就应该量减少可能存在的技术风险。而技术风险一般指的是一切未知的、未l证明的或未l测试所带来的风险。这些风险通常与服务?service-level)需求相养I偶尔也会与企业具体的业务需求相兟뀂无论是哪种cd的风险，在项目初期设计整体系l架构的q程中更易于发掘q些风险Q如果等到架构实施时再发觉这些风险，那么很可能会致大量的开发h员等在那里，直到q些风险被妥善解冟뀂如果进一步的l化Q我们可以看到SOA架构设计师的主要d包括Ҏ(gu)个系l解x案轮廓的构徏Q需求分析，对体pȝ构的整体决策Q相关组件徏模，相关操作建模Q系l组件的逻辑和物理布局设计?/p>
作ؓSOA架构设计师必要能够领导整个开发团队，q样才能保证设计和开发h员是按照构徏好的pȝ架构来开发整个系l的Q这一点十分的重要。这p求一名架构设计师不仅要有很好的技术洞察力Q同时还要具有一定的目理和项目实施的能力。在pȝ开发的q程中，架构设计师必要有良好的沟通和表达能力Q这׃现在由架构设计师构徏的系l模型是否具有很好的可读性和易理解性。如果由架构设计师构造出的系l模型不是很清晰的话Q就可能会媄响设计和开发h员对于整个系l架构的理解。ؓ了避免这U情늚出现Q定期由架构设计师主持的开发团队内部讨论是十分重要的?/p>
3. 构徏SOA架构时应该注意的问题
3.1 原有pȝ架构中的集成需?/strong>
当架构师ZSOA来构Z个企业的系l架构的时候，一定要注意对原有系l架构中的集成需求进行细致的分析和整理。我们都知道Q面向服务的体系l构是当前及未来应用E序pȝ开发的重点Q面向服务的体系l构本质上来说是一U具有特D性质的体pȝ构，它由h互操作性和位置透明的组仉成构建ƈ互连而成。基于SOA的企业系l架构通常都是在现有系l架构投资的基础上发展v来的Q我们ƈ不需要彻底重新开发全部的子系l?SOA可以通过利用当前pȝ已有的资?开发h员、Y件语a、硬件^台、数据库和应用程?来重复利用系l中现有的系l和资源。SOA是一U可适应的、灵zȝ体系l构cdQ基于SOA构徏的系l架构可以在pȝ的开发和l护中羃短品上市时_因而可以降低企业系l开发的成本和风险。因此，当SOA架构师遇C个十分复杂的企业pȝӞ首先考虑的应该是如何重用已有的投资而不是替换遗留系l，因ؓ如果考虑到有限的预算Q整体系l替换的成本是十分高昂的?/p>
当SOA架构师分析原有系l中的集成需求的时候，不应该只限定为基于组件构建的已有应用E序的集成，真正的集成比q要宽泛得多。在分析和评C个已有系l体pȝ构的集成需求时Q我们必考虑一些更加具体的集成的类型，q主要包括以下几个方?应用E序集成的需求，l端用户界面集成的需求，程集成的需求以及已有系l信息集成的需求。当SOA架构师分析和评估现有pȝ中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在MU类的企业中都有一定程度的体现。针对不同的企业cdQ这些集成方式可能是化的Q或者没有明地q行定义的。因而，SOA架构师在着手设计新的体pȝ构框架时Q必要全面的考虑所有可能的集成需求。例如，在一些类型的企业pȝ环境中可能只有很的数据源类型，因此Q系l中Ҏ(gu)息集成的需求就可能会很单，但在一些特定的pȝ中，例如航运pȝ中的EDI(Electronic Data Interchange ?sh)子数据交?pȝQ会有大量的?sh)子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这U情况下整个pȝ对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构徏的系l架构能够随着企业的成长和变化成功地l得以保持，则整个系l构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成?/p>
3.2 服务_度的控制以及无状态服务的设计
当SOA架构师构Z个企业的SOApȝ架构的时候，关于pȝ中最重要的元素，也就是SOApȝ中的服务的构建有两点需要特别注意的地方:首先是对于服务粒度的控制Q另外就是对于无状态服务的设计?/p>
服务_度的控?/strong>
SOApȝ中的服务_度的控制是一十分重要的设计d。通常来说Q对于将暴露在整个系l外部的服务推荐使用_粒度的接口Q而相对较l粒度的服务接口通常用于企业pȝ架构的内部。从技术上Ԍ_粒度的服务接口可能是一个特定服务的完整执行Q而细_度的服务接口可能是实现q个_粒度服务接口的具体的内部操作?举个例子来说Q对于一个基于SOA架构的网上商店来__粒度的服务可能是暴露l外部用户用的提交购买表单的操作，而系l内部的l粒度的服务可能是实现q个提交购买表单服务的一pd的内部服务，比如说创买记录，讄客户地址Q更新数据库{一pd的操作。虽然细_度的接口能为服务请求者提供了更加l化和更多的灉|性，但同时也意味着引入较难控制的交互模式易变?也就是说服务的交互模式可能随着不同的服务请求者而不同。如果我们暴露这些易于变化的服务接口l系l的外部用户Q就可能造成外部服务h者难于支持不断变化的服务提供者所暴露的细_度服务接口。而粗_度服务接口保证了服务请求者将以一致的方式使用pȝ中所暴露出的服务。虽焉向服务的体系l构(SOA)q不强制要求一定要使用_粒度的服务接口Q但是徏议用它们作为外部集成的接口。通常架构设计师可以用BPEL来创建由l粒度操作组成的业务程的粗_度的服务接口?/p>
无状态服务的设计
SOApȝ架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时Q我们最好把它定义成具体的业务流E?BPEL)。在服务的具体实现机制上Q我们可以通过使用 EJB lg来实现粗_度的服务。我们通常会利用无状态的Session Bean来实现具体的服务Q如果基于Web Service技术，我们可以将无状态的Session Bean暴露为外部用户可以调用的到的Web服务Q也是把传l的Session Facade模型转化Z EJB 的Web服务端点Q这P我们可以向 Web 服务客户提供_粒度的服务?/p>
如果我们要在 J2EE的环境下(ZWebSphere)构徏Web服务QW(xu)eb 服务客户可以通过两种方式讉K J2EE 应用E序。客户可以访问用 JAX-RPC API 创徏?Web 服务(使用 Servlet 来实?;Web 服务客户也可以通过 EJB的服务端Ҏ(gu)口访问无状态的Session BeanQ但Web 服务客户不能讉K其他cd的企业BeanQ如有状态的Session BeanQ实体Bean和消息驱动Bean。后一U选择(公开无状?EJB lg作ؓ Web 服务)有很多优势，Z已有的EJBlgQ我们可以利用现有的业务逻辑和流E。在许多企业中，现有的业务逻辑可能已经使用 EJB lg~写Q通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。EJB 端点是一U很好的选择Q因为它使业务逻辑和端点位于同一层上。另外EJB容器会自动提供对q发的支持，作ؓ无状态Session Bean实现?EJB 服务端点不必担心多线E访问，因ؓ EJB 容器必须串行化对无状态会?bean M特定实例的请求?׃EJB容器都会提供对于Security和Transaction的支持，因此Bean的开发h员可以不需要编写安全代码以及事务处理代码?性能问题对于Web服务来说一直都是一个问题，׃几乎所?EJB 容器都提供了Ҏ(gu)状态会?Bean 集的支持以及对无状态Session Bean 池与资源理的支持，因此当负载增加时Q可以向集中增加机器，W(xu)eb 服务h可以定向到这些不同的服务器，同时׃无状态Session Bean 池改q了资源利用和内存管理，?Web 服务能够有效地响应多个客戯求。由此我们可以看刎ͼ通过?Web 服务模型化ؓ EJB 端点Q可以服务h更强的可伸羃性，q增Zpȝ整体的可靠性?/p> SOA Z业架构设计带来的媄响，以及在构建基?SOA 架构的企业系l时应该怎样保证所构徏的系l架构能够满系l中不同的服务别需求?
1. SOA Z业架构设计带来的媄?/strong>
1.1 SOA 的特点及其用范?/strong>
SOA 既不是一U语aQ也不是一U具体的技术，它是一U新的Y件系l架构模型?SOA 最主要的应用场合在于解军_Internet环境下的不同商业应用之间的业务集成问题。Internet环境区别于Intranet环境的几个特点主要是:
(a)大量异构pȝq存Q不同计机g工作方式不同Q操作系l不同、编E语a也不?
(b)大量、频J的数据传输的速度仍然相对较缓慢ƈ且不E_;
(c)无法完成服务(service)的版本升U，甚至Ҏ(gu)无法知道互联网上有哪些机器直接或者间接的使用某个服务?/p>
SOA 架构h一些典型特性，主要包括松耦合性，位置透明性以及协议无x。松耦合性要?SOA 架构中的不同服务之间应该保持一U松耦合的关p，也就是应该保持一U相对独立无依赖的关p?位置透明性要?SOA pȝ中的所有服务对于他们的调用者来说都是位|透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但ƈ不需要知道所调用服务的物理位|在哪里;而协议无x要求每一个服务都可以通过不同的协议来调用。通过q些 SOA 架构所h的特性我们可以看刎ͼSOA 架构的出Cؓ企业pȝ架构提供了更加灵zȝ构徏方式Q如果企业架构设计师Z SOA 来构建系l架构，可以从底层架构的别来保证整个pȝ的松耦合性以及灵zL，q都为未来企业业务逻辑的扩展打好了基础?/p>
1.2 SOA 架构的分层模?/strong>
接下来简要介l一?SOA pȝ中的分层模型Q整?SOA 架构的分层模型如?所C?/p>
560)this.style.width=560;" border=0>
?SOA pȝ中不同的功能模块可以被分??W一层就是系l已l存在的E序资源Q例如ERP或者CRMpȝ{。第2层就是组件层Q在q一层中我们用不同的lg把底层系l的功能装h。第3层就?SOA pȝ中最重要的服务层Q在q层中我们要用底层功能组件来构徏我们所需要的不同功能的服务。ȝ来说QSOA 中的服务可以被映成具体pȝ中的M功能模块Q但是从功能性方面可以大致划分ؓ以下三种cd:(1)商业服务(business service) 或者是商业q程(business process)。这一cȝ服务是一个企业可以暴露给外部用户或者合作伙伴用的服务。比如说提交h甌Q用户信用检查，h信用查询?2)商业功能服务(business function service)Q?q类服务会完成一些具体的商业操作Q也会被更上层的商业服务调用Q不q大多数情况下这cL务不会暴露给外部用户直接调用Q比如说索用户帐户信息，存储用户信息{?3)技术功能服?technical function service)Q这cL务主要完成一些底层的技术功能，比如说日志服务以及安全服务等。在服务层之上的W?层就是商业流E层Q在q一层中我们利用已经装好的各种服务来构建商业系l中的商业流E。在商业程层之上的是W?层表C层了，我们利用表示层来向用h供用h口服务，q一层可以用Zportal的系l来构徏。以上这5层都需要有一个集成的环境来支持它们的q行Q第6层中的企业服务ȝ(ESB)提供了这个功能。第7层主要ؓ整个 SOA pȝ提供一些辅助的功能Q例如服务质量管理，安全理q一cȝ辅助功能?/p>
2. SOA 架构中的非功能性服务?service-level)需?/strong>
除了pȝ的业务需求，架构设计师还必须要保证构建出来的pȝ架构能够满pȝ中的非功能性服务?service-level)需求以及服务质?QoS)斚w的需求。在目初始及细化阶D，架构设计师应该与pȝ所有涉及方(Stakeholders)一P为每一个服务别需求定义其相关的衡量标准。构建出的系l架构必要能满以下几斚w的服务水准要?性能、可升性、可靠性、可用性、可扩展性、可l护性、易理性以及安全性。架构设计师在设计架构过E中需要^衡所有的q些服务U别需求。例如，如果服务U别需求中最重要的是pȝ性能Q架构设计师很有可能不得不在一定程度上牺牲pȝ的可l护性及可扩展性，以确保满系l性能上的要求。随着互联|的发展Q新构徏的系l对于服务别需求也变得日益重要Q现在基于互联网的企业系l的用户已经不仅仅局限于是本企业的雇员，企业的外部客户也会成Z业系l的主要用户?/p>
架构设计师的职责之一是要尽可能Cؓ提高pȝ设计人员和系l开发h员的工作效率考虑。在构徏整个企业pȝ架构的过E中Q需要充分重视各U服务别需求，从而避免在pȝ开发和q行的时候出现重大问题。一个企业pȝ中的服务U别需求往往是十分错l复杂的Q?SOA 架构设计师需要凭借丰富的专业l验和扎实的理论知识来分d抽象pȝ中不同的服务U别需求，?展示了这U分析的q程?/p>
560)this.style.width=560;" border=0>
?
l过 SOA 架构设计师分析和抽象的服务别需求主要分Z下几c?
性能是指pȝ提供的服务要满一定的性能衡量标准Q这些标准可能包括系l反应时间以及处理交易量的能力等;
可升U性是指当pȝ负荷加大Ӟ能够保所需的服务质量，而不需要更Ҏ(gu)个系l的架构;
可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力;
可用性是指一个系l应保一Ҏ(gu)务或者资源永q都可以被访问到;
可扩展性是指在不媄响现有系l功能的基础上，为系l填加新的功能或修改现有功能的能?
可维护性是指在不媄响系l其他部分的情况下修正现有功能中问题或缺Pq对整个pȝq行l护的能?
可管理性是指管理系l以保pȝ的可升性、可靠性、可用性、性能和安全性的能力;
安全性是指确保系l安全不会被危及的能力?/p>
1) 性能
我们通常可以Ҏ(gu)每个用户讉K的系l响应时间来衡量pȝ的整体性能;另外Q我们也可以通过pȝ能够处理的交易量(每秒)来衡量系l的性能。对于架构设计师来说Q无论采取哪U衡量系l性能的方法来构徏pȝ架构Q这些对于性能的考虑对系l设计开发h员来说都应该是透明的，也就是说对于pȝ整体架构性能的考虑应该是架构设计师的工作，而不是系l设计开发h员应该关注的事情。在较传l的ZEJB或者XML-RPC的分布式计算模型中，它们的服务提供都是通过函数调用的方式进行的Q一个功能的完成往往需要通过客户端和服务器来回很多次的远E函数调用才能完成。在Intranet的环境下Q这些调用给pȝ的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在Z SOA 的架构中使用了很多Web Service来作为服务提供点的话Q我们就需要考虑性能的媄响，其是在Internet环境下，q些往往是决定整个系l是否能正常工作的一个关键决定因素。因此在Z SOA 的系l中Q推荐采用大数据量低频率讉K模式Q也是以大数据量的方式一ơ性进行信息交换。这样做可以在一定程度上提高pȝ的整体性能?/p>
2) 可升U?/strong>
可升U性是指当pȝ负荷加大Ӟ仍能够确保所需的服务质量，而不需要更Ҏ(gu)个系l的架构。当Z SOA 的系l中负荷增大Ӟ如果pȝ的响应时间仍能够在可接受的限度内Q那么我们就可以认ؓq个pȝ是具有可升性的。要想理解可升性，我们必须首先了解pȝ定w或系l的承受能力Q也是一个系l在保证正常q行质量的同Ӟ所能够处理的最大进E数量或所能支持的最大用h量。如果系l运转时已经不能在可接受旉范围内反应，那么q个pȝ已经到达了它的最大可升状态。要惛_U已辑ֈ最大负载能力的pȝQ你必须增加新的g。新d的硬件可以以垂直或水q的方式加入。垂直升U包括ؓ现在的机器增加处理器、内存或盘。水q_U包括在环境中添|新的机器，从而增加系l的整体处理能力。作Z个系l架构设计师所设计出来的架构必能够处理对g的垂直或者水q_U。基?SOA 的系l架构可以很好地保证整体pȝ的可升性，q主要是因ؓpȝ中的功能模块已经被抽象成不同的服务，所有的g以及底层q_的信息都被屏蔽在服务之下Q因此不是对已有系l的水^升q是垂直升Q都不会影响到系l整体的架构?/p>
3) 可靠?/strong>
可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当pȝ负荷增加Ӟ你的pȝ必须能够持箋处理需求访问，q确保系l能够象负荷未增加以前一h地处理各个q程。可靠性可能会在一定程度上限制pȝ的可升性。如果系l负荷增加时Q不能维持它的可靠性，那么实际上这个系l也q不具备可升U性。因此，一个真正可升的系l必L可靠的系l。在Z SOA 来构建系l架构的时候，可靠性也是必要着重考虑的问题。要在基?SOA 架构的系l中保证一定的pȝ可靠性，必要首先保证分布在系l中的不同服务的可靠性。而不同服务的可靠性一般可以由光|的应用服务器或Web服务器来保证。只有确保每一?SOA pȝ中的服务都具有较高的可靠性，我们才能保证pȝ整体的可靠性能够得以保障?/p>
4) 可用?/strong>
可用性是指一个系l应保一Ҏ(gu)务或者资源应该L可被讉K到的。可靠性可以增加系l的整体可用性，但即使系l部件出错，有时却ƈ不一定会影响pȝ的可用性。通过在环境中讄冗余lg和错误恢复机Ӟ虽然一个单独的lg的错误会对系l的可靠性生不良的影响Q但׃pȝ冗余的存在，使得整个pȝ服务仍然可用。在Z SOA 来构建系l架构的时候，对于关键性的服务需要更多地考虑其可用性需求，q可以由两个层次的技术实现来支持Q第一U是利用不同服务的具体内部实现内部所Z的框架的定w或者冗余机制来实现Ҏ(gu)务可用性的支持;W二U是通过UDDI{动态查扑配方式来支持pȝ整体的高可用性。在 SOA 架构设计师构Z业系l架构的时候，应该l合考虑q两个方面的内容Q尽量保证所构徏?SOA pȝ架构中的关键性业务能h较高的可用性?/p>
5) 可扩展?/strong>
可扩展性是指在不媄响现有系l功能的基础上，为系l添加新的功能或修改现有功能的能力。当pȝ刚配|好的时候，你很难衡量它的可扩展性，直到W一ơ你必须L展系l已有功能的时候，你才能真正去衡量和检整个系l的可扩展性。Q何一个架构设计师在构建系l架构时Qؓ了确保架构设计的可扩展性，都应该考虑下面几个要素:低耦合Q界?interfaces)以及装。当架构设计师基?SOA 来构Z业系l架构时Q就已经隐含地解决了q几个可扩展性方面的要素。这是因?SOA 架构中的不同服务之间本n׃持了一U无依赖的低耦合关系;服务本n是通过l一的接口定?可以是WSDL)语言来描q具体的服务内容Qƈ且很好地装了底层的具体实现。在q里我们也可以从一个方面看到基?SOA 来构架企业系l能为我们带来的好处?/p>
6) 可维护?/strong>
可维护性是指在不媄响系l其他部分的情况下修改现有系l功能中问题或缺L(fng)能力。同pȝ的可扩展性相同，当系l刚被部|时Q你很难判断一个系l是否已l具备了很好的可l护性。当创徏和设计系l架构时Q要x高系l的可维护性，你必考虑下面几个要素:低耦合、模块性以及系l文档记录。在企业pȝ可扩展性中我们已经提到?SOA 架构能ؓpȝ中暴露出来的各个子功能模块也是服务带来低耦合性和很好的模块性。关于系l文档纪录，除了底层子系l的相关文档外，Z SOA 的系l还会引用到许多pȝ外部的由W三Ҏ(gu)供的服务Q因此如果h力资源准许的话，应该增加专职的文档管理员来专门负责有x个企业系l所涉及的所有外部服务相x档的攉、归cd整理Q这些相关的文档可能涉及到第三方服务的接?可以是WSDL)、服务的质量和别、具体性能试l果{各U相x档。基于这些文档，可以ؓ SOA 架构设计师构Z?SOA 架构提供很好的文档参考和支持?/p>
7) 可管理?/strong>
可管理性是指管理系l以保整个pȝ的可升性、可靠性、可用性、性能和安全性的能力。具有可理性的pȝQ应具备Ҏ(gu)务质量需?QoS)的系l监控能力，通过改变pȝ的配|从而可以动态地改善服务质量Q而不用改变整体系l架构。一个好的系l架构必能够监控整个系l的q行情况q具备动态系l配|管理的功能。在对复杂系l进行系l架构徏模时Q?SOA 架构设计师应该尽量考虑利用系l整体架构构建在已有的成熟的底层pȝ框架(Framework)上。对?SOA 架构设计师来_可以选择的底层系l框架有很多Q可以选用ZMQ, MessageBorkerQW(xu)ebSphere Application Server{品来构徏企业服务ȝ(Enterprise Service Bus)以支持企业的 SOA pȝ架构Q也可以选用较新的基于WebSphere Application Server 6中内嵌的Sibus来构Z业的ESB以支?SOA pȝ架构。具体选择哪种底层框架来实?SOA pȝ架构要根据每个系l各自的特点来决定，但这些底层的框架都已l提供了较高的系l可理性。因此，分析q择不同的品或底层框架来实C业系l架构也是架构设计师的主要职责之一。有关于如何利用已有底层架构来构?SOA pȝQ中?SOA 设计中心已经发表了一pd相关的文章，大家可以在DeveloperWorks中的 SOA 专栏看到它们?/p>
8) 安全?/strong>
安全性是指确保系l安全不会被危及的能力。目前，安全性应该说是最困难的系l质量控制点。这是因为安全性不仅要求确保系l的保密和完整性，而且q要防止影响可用性的服务拒绝(Denial-of-Service)d。这p求当 SOA 架构设计师在构徏一个架构时Q应该把整体pȝ架构可能地分割成各个子功能模块Q在一些子功能模块暴露为外部用户可见的服务的时候，要围l各个子模块构徏各自的安全区Q这h便于保证整体pȝ架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企?SOA 架构中的一些服务是由Web Service实现的，在考虑q些服务安全性的时候也要同时考虑效率的问题，因ؓWS-Security会ؓWeb Service带来一定的执行效率损耗?/p>
3.l束?/strong>
本系列两部分介绍了有x构设计师以及 SOA 架构的知识，分析?SOA 架构师在设计 SOA pȝ架构时有哪些应该特别注意的地方ƈ在最后简要介l了在构建基?SOA 架构的企业系l时应该怎样保证所构徏的系l架构能够满系l中不同的服务别需求。从架构设计师的角度Q?SOA 是一U新的设计模式，Ҏ(gu)学。因此， SOA 本n늛了很多的内容Q也触及Cpȝ整体架构设计、实现、维护等各个斚w。本文的内容只是涉及C有关于架构方面的一部分内容Q希望能对广大的 SOA pȝ开发设计h员vC定的帮助作用?/p>
]]>