购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

4.1 SOA的4个特性

面向服务的技术架构必须具有某些属性,这些属性需满足包含已应用了面向服务设计原则服务的自动化解决方案的基本需求。这4个特性有助于进一步区分SOA和其他架构模型。

注意

当我们逐一探讨这些特性时,谨记,在实现中,这些特性可以达到的程度可能会有所不同。

4.1.1 业务驱动

技术架构通常设计为支持提供解决方案以满足战术(短期)业务需求。因为在定义架构时,不考虑组织过渡性、战略性(长期)业务目标,所以随着时间的推移,这种方法可能导致技术环境与组织的业务方向和要求无法保持一致。

业务和技术的逐渐分离产生了一种技术架构,它削弱了满足业务需求的潜力,并且越来越难以适应不断变化的业务需求(见图4-1)。

图4-1 技术架构(A)的交付通常与业务的当前状态一致,但是可能不能根据业务演进而进行改变。随着业务和技术架构越来越不同步,对业务需求的满足逐步减少,通常需要一个全新的技术架构(B),这实际上产生了一个周期性循环

当技术架构是业务驱动时,总体的业务愿景、目标和需求被定位为架构模型的基础和主要影响。这使得技术和业务的潜在一致性最大化,并允许技术架构可以与整个组织一起发展(见图4-2)。其结果是架构的价值和寿命不断提高。

图4-2 通过定义一个战略性的、以业务为中心的技术架构,可以与业务演化随着时间的推移不断同步

4.1.2 供应商中立

围绕一个特定供应商平台设计面向服务的技术架构可能会无意中继承这个供应商专有的特性。为响应其他供应商可靠有用的技术创新,可能会阻碍存量架构的未来发展。

抑制性技术架构无法根据变化的自动化需求而演变和扩展,这可能导致架构的寿命有限,随后需要被替换以保持有效(见图4-3)。

一个组织的最佳利益是采用与主要SOA供应商平台一致的基于面向服务架构的设计模型,但对所有这些平台都是中立的。供应商中立的架构模型可以从供应商无关的设计范式导出,这种设计范式用于构建该架构所支持的解决方案逻辑(见图4-4)。面向服务范式提供了这样一种方法:它源于并适用于现实世界的技术平台,同时对它们保持中立。

注意

只是因为架构被归类为供应商中立,并不意味着它也与当前供应商技术相一致。通过独立工作产生的一些模型,与当今主流SOA技术存在的方式不同步,并且预期在未来将演变,因此可能与供应商绑定模式一样抑制了未来的发展。

图4-3 以供应商为中心的技术架构通常绑定了相应供应商平台的路线图。这可能减少利用其他供应商平台提供技术创新的机会,并且可能最终需要用新的供应商实现(其再次开始循环)来完全替代该架构

4.1.3 企业中心化

面向服务的解决方案基于分布式架构的事实并不意味着在企业内不断创建新的竖井的危险就不存在,这种危险在构建设计不良的服务时仍然是存在的,如图4-5所示。

当应用面向服务时,服务被定位为企业资源,这意味着服务逻辑设计为具有以下主要特征:

·该逻辑在特定实现边界之外可用。

·该逻辑是根据既定的设计原则和企业标准设计的。

本质上,逻辑的主体被归类为企业的资源。这不一定使其成为企业级资源或必须在整个技术环境中使用的资源。企业资源只是作为IT资产的逻辑定位;企业资源是企业的扩展,它不属于任何一个应用程序或解决方案。

图4-4 如果架构模型被设计为对供应商平台保持中立,通过利用多个供应商技术创新,它就保持了实现多样化的自由。这增加了架构的寿命,因为这样可以基于需求的变化而不断增加和发展

图4-5 提供用于特定自动化业务流程的单一目的服务,可能最终在企业内部建立竖井

SOA模式

如在服务封装模式中所建立的,企业资源基本上体现了服务逻辑的基本特性。

为了将服务作为企业资源来使用,底层技术架构必须建立一个模型,该模型本身基于以下假设:作为服务提供的软件程序将由企业的其他部分共享,或者是包括共享服务更大解决方案的一部分。这个基准要求强调对架构各部分进行标准化,以便可以不断地促进服务的重用和互操作性(见图4-6)。

图4-6 当服务被定位为企业资源时,它们不再创建或驻留在竖井中。相反的,它们作为服务目录的一部分可用于更广泛的应用范围

4.1.4 组合中心化

尤其是与以前的分布式计算模式相比,面向服务更注重将软件程序设计为不仅仅是可重用的资源,而是作为更加灵活的资源,可以插入到用于各种面向服务解决方案的不同聚合结构中。

要实现这一点,服务必须是可组合的。如服务可组合性原则所倡导的,这意味着服务必须能够被拉入各种组合设计,而不管它们最初是否在首次发布时被要求参与组合(见图4-7)。

图4-7 同一服务目录中的服务组合为不同的配置。重点服务被多个组合重用,以自动完成不同的业务流程

为了支持本地可组合性,底层技术架构必须具有实现一系列简单和复杂的组合设计。与可扩展性、可靠性、运行时数据交换处理和完整性有关的架构扩展(以及相关基础设施扩展),对支持这一关键特性至关重要。

4.1.5 设计优先级

“SOA声明”(SOA Manifesto)的出版提供了一个有价值的观点,即面向服务如何与SOA相关,以及这种关系的形式化如何导致一系列设计优先级。看看下面的摘录:

面向服务是一个范式,用于框定你做什么。面向服务的架构(SOA)是一种通过应用面向服务而产生的架构类型。

我们一直应用面向服务来帮助企业根据不断变化的业务需求,持续提供可持续的业务价值、提高敏捷性和成本效益。

通过我们的工作,按轻重缓急考虑:

·商业价值高于技术战略

·战略目标高于项目特定的效益

·本征互操作性高于定制集成

·共享的服务高于特定目的的实现

·灵活性高于效率

·渐进的演化高于追求一开始就尽善尽美

也就是说,虽然我们重视右侧的项,但我们更重视左侧的项。

很明显,这些设计优先级是由面向服务的设计范式和面向服务的架构模型直接支持的。这一点在 www.soa-manifesto.com 上发布的“注释版SOA声明(Annotated SOA Manifesto)”中有进一步地探讨,详见附录D。 AuHK8SpuU/kW7uJd/lPcupTwtjAd6TOQ5XOgDp6r5s1DBj08VYqWbycO3E9yzndh

点击中间区域
呼出菜单
上一章
目录
下一章
×

打开