SOA实践应从企业级IT架构设计着手

  各大软件供应商与媒体的联合吵作,使SOA(Service Oriented Architecture)成为">IT人士经常挂在嘴边的“时尚”词汇。2006年,在日本举行的年会上,Gartner公司乐观预测,到2007年,会有超过50%的企业采用SOA体系, 到2010年该比例将会达到80%。

  但事实上,到目前为止,国内的IT界也是很少有人清楚SOA的实践应从那里着手。国际软件供应商的大玩SOA概念,实际是它们的一种产品的市场推广策略。但从实际取得的效果看,这种宣传策略只是国际软件厂商的自娱自乐。

  IT界的普遍浮躁,使得很少有人真正探讨SOA究竟是什么?以及如何实施SOA?这也使得国际软件大佬的宣传,引来的只是随声附和,而没有具体的行动,即使它们极力的宣传自己的产品已经SOA了,也不会引起太多企业真正的兴趣,这样就客观减少了软件采购企业被忽悠的机会。

  那么SOA究竟是什么?

  首先,SOA并不是具体的软件产品,它与技术无关。如果那家软件供应商说自己的产品真的实现了SOA,那我们就要注意它的用心了。

  SOA是IT体系架构的设计思想。这种思想可以从软件工程体系结构设计,与企业级IT体系架构这两个层面来体现。

  在软件工程体系结构设计层面,SOA是一种软件体系结构的设计方式,它指导着业务服务(软件应用功能单元)在其生命周期(从构思开始,直到停止使用)中创建和体现SOA思想的方方面面。

  在企业级IT体系架构层面,SOA也是一种定义和提供IT基础设施(IT Infrastructure)的方式,体现SOA思想的企业级IT体系结构设计,应允许不同应用功能或应用系统之间交互数据、参与业务流程(Business Processes),无论它们各自背后使用的是何种操系统或采用了何种编程语言。

  在软件工程体系结构设计层面,基于SOA思想的软件工程技术实践还没有走向成熟,因为基于SOA思想的软件体系结构设计三大标准:服务组件架构标准(CSA)、服务数据接接口标准(SDO)、服务安全标准(WS-Policy),才仅仅刚刚发布了前两个标准,而且还是1.0版本,成熟还需时日。

  SOA思想指导的软件工程技术实践和不成熟,并不影响,企业级IT体系架构设计实践中,体现SOA的思想,设计出在某种程度符合SOA思想的企业级IT体系架构。企业业务与信息化的发展要求企业级的IT体系架构设计要有很强的灵活性与业务流程变化的适应性,需求的紧迫性不能等待SOA的软件工程技术实践成熟后再进行。

  企业级IT体系架构设计中,如何体现SOA思想?

  SOA的思想的企业级IT体系架构设计实践,要从BPM/BPI与SOAP、XML、WEB Service等IT技术相结合,企业级的IT体系架构设计,要以企业流程重整/优化为基础,划分适当粒度的应用系统或应用功能边界,同时应用系统或应用功能边界间的集成尽可能采用松散耦和集成的方式,从而增强企业级IT体系架构对企业业务战略与业务流程变化的适应性。(CIO时代网)

时间: 2024-10-27 04:04:13

SOA实践应从企业级IT架构设计着手的相关文章

《Microsoft.NET企业级应用架构设计(第2版)》——1.2 谁是架构师

1.2 谁是架构师 如你所见,架构通常是关于难以更改的决定.需要有人做出这些决定. 架构设计基于需求分析.分析确定系统要做什么:架构决定如何去做.需要有人了解这个"什么"来确定这个"如何". 架构师正是把需求和规范关联起来的专家.但架构师的职责是什么?需要哪些技能? 1.2.1 架构师的职责 根据ISO/IEC 42010标准,架构师是负责系统架构的个人.团队或组织.架构师与分析师和项目经理互动,评估和提议系统方案,以及协调开发团队. 架构师参与开发流程的所有阶段,

《Microsoft.NET企业级应用架构设计(第2版)》——第2章 为成功而设计 2.1“大泥球”

第2章 为成功而设计 我们认为成功的软件项目是在充分了解业务需求的情况下采用靠谱解决方案的项目.我们认为成功设计的软件是在项目成功的前提下能够(在任何可能的地方)重用现有代码和基础设施,并根据可用的技术和广为人知的最佳实践不断改善的软件. 今天,成功设计的软件对于任何类型.任何规模的商业来说都是至关重要的,但更为关键的是避免质量低下的软件.烂的软件会使组织在很多地方遭受损失,比如说,响应很慢的页面会导致访问者离开你的网站,笨拙的用户界面会带来入口瓶颈,导致你提供的服务不得不面对处理队列,甚至未处

使用WCF实现SOA面向服务编程“.NET研究”—— 架构设计

SOA本身就是一种面向企业级服务的系统架构,简单来说,SOA就是一种进行系统开发的新的体系架构,在基于SOA架构的系统上海企业网站制作中,具体应用程序的功能是由 一些松耦合并且具有统一接口定义方式的组件(也就是service)组合构建起来的.因此,基于SOA的架构也一定是从企业的具体需求开始构建的.但是,SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性.业务灵活性是指企业能对业务变更快速和有效地进行响应.并且利用业务变更来得到竞争优势的能力.对企业级架构设计师来说,创建一个业务灵活的架

《Microsoft.NET企业级应用架构设计(第2版)》——导读

前言 我们写这本书的主要目的是为你带来一个关于软件架构的坚实.可重用以及易于访问的知识库.在过去,我们使用Microsoft Windows DNA.分布式COM.多层CRUD.SOA.DDD.CQRS和事件溯源等技术完成了很多项目.我们用过Microsoft Visual Basic 6.C#.C++.Java和JavaScript.我们目睹了技术解决方案不断改变,对于这些方案的看法也进化了. 最终,我们和Fred Brooks得出的结论相同.我们不穿白袍,我们不是医生,我们不写处方.我们在这

《Microsoft.NET企业级应用架构设计(第2版)》——2.2 软件项目的机制

2.2 软件项目的机制 如果你问:"什么导致项目失败?",你得到的最常见的回答可能会把失败归咎到与业务有关的问题,比如说,缺少需求,项目管理不到位,成本估算不正确,缺少沟通,甚至各个团队的人员相互不配合.你很难看到坏代码可能导致问题这种情况. 有鉴于此,我们认为未被发现的BBM可以严重损害软件项目,但未能处理的BBM却可以真的毁了它. 最终,个体以及个体之间的实际互动才能真的决定软件项目的成功或失败.但是,组织结构及其整体文化也会影响最终结果. 2.2.1 组织文化 Apple公司的组

《Microsoft.NET企业级应用架构设计(第2版)》——1.3 总结

1.3 总结 架构对于现代软件来说是必需品而不是奢侈品.即使架构曾经只是附属品,现在也肯定不再是,其中的区别在于现代软件的复杂性. 我们通常会拿软件和土木工程比较,但是,当土木工程师要建一座桥时,这座桥将会建成.除此之外,这座桥总能正常使用,而且建筑成本和原先的预算相差无几.这对于很多软件项目来说并非如此.放到软件上,有时候很难确定利益相关者的承诺最终有哪些能够兑现.但可以确定的是,可能会超出原先的预算,交付的东西可能在某种程度上与预期的不同. 为什么软件会这样? 总的来说,软件开发很难像土木工

《Microsoft.NET企业级应用架构设计(第2版)》——第1章 今天的架构师和架构 1.1软件架构到底是什么

第1章 今天的架构师和架构 在计算机的最初年代,硬件成本远远大于软件成本.数十年之后,我们发现情况有了根本的变化.整个工业有了显著的进步,而硬件成本也急剧下降.另一方面,软件成本却大幅上升,这主要是因为开发自定义企业软件的复杂性提升了. 这种情况催生了一系列的准则,并以此指导工程师设计这类系统.架构这个术语源自建筑行业,现已普遍用于描述规划.设计和实现软件密集型系统的艺术.当我们两个还是青少年时,<爱是-->这部漫画(http://www.loveiscartoon.com)正值流行.每期漫画

简述.NET企业级系统架构设计

.NET设计层面上的体系架构,如1.1图是从设计层面上划分的.NET体系架构. 图 1.1 软件设计的原则是为了提高软件系统的可复用性和可扩展性,我们采用的手段是为应用系统划分层次,这是一种逻辑上的划分不是物理上的划分,也就是这些层可以是在一台电脑上也当然可以分布到在多台电脑上.这些层之间是松耦合的,层的内部是高内聚的.因此,降低耦合是软件设计的目标,能够设计出低耦合的系统,就意味着我们的系统具有可复用性和可扩展性了. 1.1.1 表示层 表示层(Presentation Layer)是用户与系

《Microsoft.NET企业级应用架构设计(第2版)》——2.3 走出混乱

2.3 走出混乱 即使做了最好准备,也不管团队的努力如何,系统的设计都可能在某个时刻陷入困境.BBM的形成通常是一个缓慢的过程,会在一段相对较长的时间里使设计恶化.在这个过程里,你的类到处都有修补和变通方案,最终大片代码开始变得难以维护和进化. 这个时候问题就很严重了. 管理者面临与魔鬼交易的抉择,要么采用更多修补和变通方案,要么根据审核的需求和新的架构选择做一次彻底的重新设计. 重新设计一个完整系统与完全从头开始开发之间的区别是什么?就采取的措施而言,区别是极小的,如果存在任何区别的话.但心理