文章 - 212 评论 - 33 收藏 - 0 粉丝 - 12 访问量 - 237449

摘自《面向服务的企业应用架构》

-------架构特色与全息视角


1.1    面向服务架构必然性

面向服务这一概念源于SOASOIService-oriented Integration 顾名思义, SOA是面向服务架构,而SOI是面向服务的整合。 一般而言,在现有企业级应用中, SOASOI同时共存。 面向服务的关键是建立一套标准的架构体系, 而这一体系不受制于某一特定的技术或业务模式。 当信息技术的交互变得日益普及化, 标准化及产品化时, 面向服务的架构风格显得尤为重要。 简言之, SOA是一种架构风格或架构模式。 那么, 企业应用为何要如此强调SOA架构呢?

1.1.1    阿凡提的兔子汤

在阿凡提的故事里,他和朋友一起打了只兔子,美餐一顿还有所剩;第二天有人来说他是朋友的朋友,阿凡提于是同他分享了剩下的兔肉汤;第三天又有人跑来,说是他朋友的朋友的朋友,于是阿凡提就请那人喝了凉水,说这是“兔子的汤的汤的汤“。这个故事说明,凡事是有层级化的, 不可能充分扁平化。 就如部队里连长也许能关注全体战士, 同他们交流感情, 而营长就很难与全营成员沟通了。 同样道理, 当一个企业的系统发展到一定层面后,更新管理终将遭遇力不能及的地步, 从而思考如何进行架构转型。

从信息技术的发展历史来看, 我们从四十多年前CICSCustomer Information Control System系统包罗展现(Map操作),逻辑(Program操作)及数据(VSAM/文件/缓存)的一体机, 到如今以业务为导向的企业应用。我们从单层系统,到二层, 多层系统,到分布式系统,再到系统整合。我们从小到大,从基本到高层,从简单到复杂,从单一到聚合。我们从面向程序过程, 到面向对象,到基于组件,基于业务应用(ERP),再到面向服务化及框架化(1‑1)。这是一个必然的发展趋势。 其原因在于:

1)应用技术上,编程模式,语言,技术及工具不断变化更新及趋于多样化。

2)业务上,各个行业,部门,组织间,直接或间接地,日益关联协作。

3)用户体验上,简便的操作,随需而生的应用以及可以定制化的界面不再局限于单一的应用。

4)信息获取方式上,全球化,网络化的格局成为主流,如此等等。

SOA的应运而生正是满足了这种趋势: 换位思考扁平化的孤岛系统, 将日趋复杂的IT应用, 经由组件化,服务化/框架化的整合,变得相对简单易用。

 

11  信息技术应用架构的抽象进程

 

目前,SOA还处于发展阶段,企业对SOA必须具有前瞻性。在企业IT的初级阶段, 是否SOA或不SOA往往感觉不出太大效益。只有在企业IT规模发展到相当程度时,竖井式应用的弊端造成应用拓展维护困难, SOA的价值才会凸显出来。反过来说,SOA能够帮助企业未雨绸缪未来的业务整合,同时顺应IT应用网络化,商业化的趋势。许多大型企业或网站的IT架构发展进程充分说明了这一点。 所以说,层级化的SOA现在是,而且将来也将是应对这一变化趋势的一贴良方。

 

1.1.2    秦始皇的度量“衡”

提到SOA的通用性及标准性,我们常会引用秦始皇统一度量“衡”的故事。在企业IT应用层面,我们自然会想到应用组件的通用性。在相对独立的应用里,一般不需设计使用SOA服务。当某一应用或组件需要对外使用或重复使用时,或需要屏蔽特定的实现技术时,SOA服务才具有意义。 通用性是采用SOA的必要原因之一。而SOA的重用性区别于组件的通用性在于其广泛接受的统一接口标准。这也是秦始皇统一度量“衡”的意义所在。

SOA的通用性还体现在其架构设计。SOA的架构重在网络化,客户化及整合化。其考量的重点不在于某一个应用,而是应用的对外使用或是应用间的关联。对于相当规模的某种行业或某种交互形式,往往可以设计出具有相当通用性的SOA架构。虽然基于组件的架构同样可以具有通用性,但它局限于某一特定的技术,而且范围也较小。相对而言,SOA架构层次较高,其通用性包含服务化与标准化。通过业务组件分解,较易与业务对齐。

另外,SOA的通用性体现在不局限于某一厂商产品框架技术。SOA以独立于技术的架构为主导,在此基础上,可以利用具体厂商的产品技术或应用框架。例如,微软(Microsoft)的BizTalkWCFDynamics 甲骨文(Oracle)的Fusion中间件或SOA套件,IBM的中间件系列,普元的EOS等。当然,每个厂商的SOA侧重点不同,例如,微软主要侧重于Web服务集成或开发端的SOA,并在特定的平台上运行这些服务,IBM侧重于中间件的应用整合, SAP则重用于应用管理集成套件等。

本书主要从架构的角度考虑SOA,这与设计或产品技术是不同的思维方式。 SOA的真正意义不在于技术,而是架构优先的SOA构建部署方法。通用性的架构设计才是企业级应用整合的关键所在。同时,企业应用产品化的通用设计也便于SOA的推广与价值实现。

 

1.1.3    达尔文的“适变”理论

达尔文曾说过:“能够生存下来的不是最强的,也不是最聪明的,而是最能适应变化的”。 同样, 对于企业应用系统, 其生命力在于其适应变化的能力, 也就是说, 不依赖于代码改变而由整体架构形成的系统适变性Adaptability)或灵活性Flexibility)。适变性是SOA的首要目标 其很大程度上取决于其架构设计,关键表现在业务服务模块的设计,服务的依赖关系,服务粒度及服务接口的定义,业务及流程服务的定制化等在本书所强调的架构设计要素。相对于面向组件的灵活性要求, SOA的灵活性更强调企业级业务的灵活性,譬如说,跨域系统间接口调用的灵活性,或是易于最终用户配置的灵活性。而这种灵活性是通过应用的服务层来实现的,而非下层的应用组件。但是,服务层也取决于组件层。一个完善的SOA架构是服务层与组件层灵活性的有机结合。

同时, SOA以业务为导向,其成功与否,很大程度上取决于最终用户对应用或系统的使用便捷程度, 也就是易用性。易用性表现在容易上手,个性化配置,触摸或拖拉式操作,信息接口无缝转换等。当然,易用性与灵活性具有相当程度的关联。SOA的易用性不仅取决于可视化服务的界面设计,而且取决于服务视图及接口的关系配置。SOA易用性的受益者包括应用架构设计人员。

 

1.1.4    高尔的成功系统定律

高尔定律(Gall’s Law)表明:任何一个成功的复杂系统永远是源于一个成功的简单系统(A complex system that works is invariably found to have evolved from a simple system that worked)。

同样, 对于企业应用系统的集成, 永远是由简单的系统衍生而来。 没有基本的应用系统模块, 也就无所谓系统集成。由于SOA并非是一种技术或技术框架, 并非适用于所有的信息系统应用。 对于某一层面的IT架构或场景,例如, 如果系统不是以整合为目的,而强调性能,安全,业务逻辑应用化等,SOA可能会是一个错误的选择。 值得注意的是, SOA是基于传统应用之上的应用整合架构, 其成功意义在于服务化, 虚拟化的架构设计, 而非SOA技术本身。 所以,只有在一个企业的IT发展到一定层面, SOA才有意义。例如,

-     当企业已经进入ERP阶段,并使用服务化的方式来整合梳理系统及业务, 粗粒度的服务能带来规范和效益

-     当企业将其应用或系统作为服务对外暴露,实现网络化或产品化的战略

-     当企业具有一定规模的复杂系统,并且处于异构环境,或者是在与异构环境交互时,必须使用SOA标准时

-     SOA的服务层给系统性能带来负面影响时,企业的财力或技术资源能够补偿这种一定程度的性能耗损

-     当企业IT负责人员具有一定的SOA的思维方式及掌握基本的SOA技能时

-     当企业领导足够重视应用整合,优先规范IT系统应用的灵活性及重用性,并付诸于长期规划

 

参见 "When Not to Use an SOA"  Jason Bloomberg

 

总之,企业在具有一定的应用系统规模前,或在考虑或采用ERP系统前,虽然可以使用服务模块的方式, 或暴露使用服务,但须依循高尔定律, 逐渐过渡到SOA,不能一蹴而就。在设计或整合复杂系统时, 必然要大量地使用现有的, 逐渐积累起来的系统组件及资产,并且, 所构建的系统越复杂, 限制条件越多, 就越有SOA的必要。 而只有当SOA的标准,分布环境进入成熟阶段, SOA价值才能充分体现。 无论如何, SOA企业应用整合的架构方法是一个企业最终走向成熟的不二之选。

 

发表于: 2012-10-10 22:55 阅读(1613) 评论(1) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

# re: 面向服务架构的必然性
2012-10-11 08:54 | 蔻色指尖 | 1楼
看到了秦始皇和达尔文的名字,写的有点意思

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册