CIO在部署SOA过程中的五大隐患

 
   | |

导读:本文为了使你有一个好的开端,我们已经收集了五种最为常见的、SOA使用中的隐患。

关键词:SOA 隐患 部署SOA 服务设计 服务总线 服务治理

 
正在加载数据...

  现在是SOA领域动荡变化的时期,其发展变幻莫测,而这仅仅只是开始。由于服务设计、服务总线、服务治理甚至服务本身都处于不断变化中,而且各大公司仍在重审这一舞台,因此,人们的立场通常很复杂。对于IT产业中SOA的成熟度和整体状态,许多人还非常迷惑,但是,可以确定的是,SOA在结合商业和技术方面的潜力的确非凡。

  去年发布了许多SOA的新方案,每一个方案都有其特定的一套目标和期望。很可惜,其中一些方案与成功相距甚远,一些方案距成功仅仅是一步之遥。但是,对于大多数方案而言,它们都实现了最初的目标,其成功的决定因素是——借鉴那些经历过失败项目的人们的宝贵经验。这些前辈讲述他们的经验教训,告诉人们在通往SOA道路上所要警惕的重重障碍。

  在我们的日常工作中,我们被卷入进度不同、状态不同的多个项目中。而现在,我们已经看到,很好的SOA变得越来越差,甚至更糟。虽然,问题能够被解决,错误能够被避免,但是,总是有一种强大的力量把事情拖回到原来的轨道上。很明显,最佳做法就是:第一时间避免问题和错误。

  在SOA的使用中存在着隐患,很多人已经被这些错误的概念或者做法误导,那么,理解这些隐患,能够帮助你达到深谋远虑的程度,从而使你在SOA的道路上更加安全的前行。为了使你有一个好的开端,我们已经收集了五种最为常见的、SOA使用中的隐患。

  没有理解SOA的性能需求

  松散耦合是需要代价的。当使用Web服务实现松散耦合时,SOA引入了数据处理层,同时也带来了由这些层所影响到的上层的相关性能。当SOA项目刚开始时,规模较小,因此,构建符合功能和响应要求的、面向服务的解决方案并不复杂。但是,随着规模的增加,需要添加更多的功能,由此可以预见到,基于信息的通讯量将会大幅度增长。如果事先没有考虑这一情况,没有准备好构建环境的话,那么,就需要对前一阶段所做的小规模系统进行必要的遗留处理。

  要构建一个成功的面向服务的解决方案,其关键是:尽快理解你的解决方案的性能需求、以及基础架构的性能瓶颈。这意味着测试(如果需要的话,增强)你的构建环境的消息处理能力,并且密切关注服务设计,从而达到传输率、传输规模以及与其他服务特性之间的一个可接受的平衡点——这一平衡点会影响解决方案的性能。

  没有从XML基础架构开始

  在今天的SOA世界中,每件事情都开始于Web服务。这似乎已经成为公司内部的既成标准,但是它并不完全正确。事实上,在今天的SOA世界中,所有的事情都开始于XML。这才是真正的标准,依据这一标准,许多补充的标准都已经逐渐发展起来,并且形成了实际的数据表示架构。这一标准的核心,奠定了许多Web服务规则的形成基础,并且促进着SOA的发展。

  因此,人们更多地关注于数据在服务之间是如何传输的,而经常忽略在服务背后,数据构造和验证的方式。这一疏忽可能导致无法合理实现SOA的持久化XML数据表示层。对于SOA而言,这一层是基础,如果它存在着弱点,那么,所有基于这一层的解决方案都会受到不利影响。

  没有创建一个过渡计划

  如果没有使用一个详尽的过渡计划,那么,成功迁移的机会将会降低很多。因为,在一个企业内部,服务终端所处位置的范围将导致环境基础架构的重新确定,一次差强人意的迁移有可能带来重大影响。使用过渡计划,你就能够控制面向服务和SOA特性,并且进行相应的协调,如此一来,迁移就能够在技术、架构以及组织层面上,按照计划进行。

  对于一个SOA过渡计划而言,其典型的组件包括:一个具有重大影响的分析结果(预测SOA的改变程度将如何影响已有资源处理、用户标准和技术)、过渡架构(目标是SOA,勾画出一系列通向这一目标的中间过渡状态)以及推测分析(考虑Web服务和支持技术的未来发展)。

  没有标准化SOA

  与其他的架构相同,SOA也需要创建并且执行内部设计标准,以便能够使人们真正地认识到它的优势。举例说明,如果一个项目采用构建面向服务的解决方案,与其他项目不同,那么,该项目的解决方案的关键点将不再是与相关的应用程序保持一致,它可能是需要互操作或者分享某些不可预知的服务。

  这可能引发很多问题,包括不匹配的数据表示、含有不规则接口特性和语义的服务契约,以及使用非互补的Web服务扩展(或者是用不同方式实现的扩展)。

  SOA的出现,促进了分离后端处理这一开发环境的发展,因此,在每个应用程序内部,SOA都能够独立执行。然而,标准化仍然要求——服务需要封装这一后端逻辑,并且在设计和交互上确保一致性。

  将SOA构建成传统分布式架构

  在实现SOA的过程中,企业一直面对的诱惑是:自称SOA已经实现了,但是在构建面向服务的解决方案时,采用与构建传统分布式解决方案相同的构建方式。

  SOA既不是CORBA+XML,也不是ASP.NET+WSE。同样,面向服务既不是面向对象,也不是“足够接近”面向对象。虽然,通常情况下,构建面向对象组建逻辑总是“非常适合”于面向服务解决方案的环境。但是,SOA是基于面向服务的、与众不同的架构模型,以及截然不同的设计模式。对于构建自动化逻辑——纯粹的面向服务,与SOA产业向全球规模发展保持一致——理解上述这些不同之处,是非常关键的。


部署SOA
 用户分析企业成功部署SOA五大核心原则
 CIO该如何把握部署SOA的最佳时机
 怎样设计和部署SOA
 几大要素指引成功部署SOA
 企业部署SOA时面临的挑战
 CIO成功部署SOA项目需明白六个模糊认识
 企业部署SOA有五大原则
 CIO在部署SOA过程中的五大隐患
 数据中心要克服SOA环境误区
 SOA关键问题解答
 多企业SOA实施方案是最新的抗衰退趋势
 企业SOA实施的成熟度研究
 SOA迈向成功的八扇“门”
 电信企业SOA部署六步走
 用自动黑箱框架加快应用部署
 强化性能管理 克服SOA环境误区
 如何使SOA计划获得成功
 使用Reservation模式实现SOA事务
 SOA的好处、坏处以及尴尬之处
 再议SOA十大谜思 SOA双方都有错
 七步教你如何成功部署SOA
 SOA:从成长到壮大

原文出处:http://topoint.com.cn/
 
来源:支点网    
 
 
 
 
 

SOA性能

 
一些较长久的标准组织正在尝试衡量SOA性能。SPEC基准组织有兴趣听取大家关于这一主题的信息。目前SPEC成员包括IBM,Oracle和VMwar正致力……
 
如果改造的中间件不是解决问题的方案,那么什么是呢?答案当然就是架构。但这么说只是问题的一小部分。那我们还按照集成开发者的语言来说……
 
在典型的集成环境中,你首要关心的是数据的移动或者业务逻辑的合并以便完成特别的任务。在这种思想指导下,大多数集成开发者考虑的是输入……
 
Edward R. Murrow曾经说过:“人常说谈话是门失传的艺术;我经常希望真的是那样啊!”对于IT开发商和舆论导向者来说这很正确,这更适用于SOA……
 
数据存储:Android改变了开发者关于数据存储的观点,那就是没有一个普通的文件系统可以被所有应用系统所共享。

热门技术手册排行

 

随着开源技术越来越成熟,一个稍有开发经验的人通过学习就可以用开源的产品和技术构建一套可用的系统。对于从事软件开发的人员,尤其是对Java或动态语言相关领域的人来说,“开源”也许是他们最喜爱的单词。但是,很多时候我们需要的不仅仅是一个可用的系统,而是希望这个系统开发更简易、性能更高和扩展性更好等。这确实是一个令人头痛的问题。本指南很多地方都是点到为止,要深入了解相关信息的读者请借助参考资料、网站等自行挖掘。

 

本专题分六部分探讨SOA设计模式,当初设计面向服务架构的一大初衷就是降低服务间耦合度,由此提高服务的灵活性和自由度。

 

业务流程管理(business process management,bpm)不是一个新概念,甚至不是一个新名词。它是从相关的业务流程变革领域,如业务流程改进(bpi)、业务流程重组(bpr)、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、eai、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。

 

TOAGF是一个架构框架,简而言之,TOGAF是一种协助发展,验收,运行,使用,和维护架构的工具。它是基于一个迭代(Iterative)的过程模型,支持最佳实践和一套可重用的现有架构资产。

 

云计算的概念越来越流行,Amazon、Google和IBM是第一批将云计算引入公众视线的公司。云计算就是新的Web2.0,一种既有技术上的市场绽放。

 

Mashup是一个非常cool的新的应用程序种类。如果你想真正的了解它们,我们需要回过头来看看你现在的计算机,其实它就是一个非常好的帮助你理解mashup的模型。现在开源的操作系统无疑是非常好的apis的集合或应用程序编程接口,帮助开发者去构建其应用程序。计算机本身也是一个很好的为用户提供接口的例子,键盘和鼠标可以被理解为你通过计算机的接口而使用的不同的应用程序。本技术手册为读者提供了一些相关信息,如果需要深入了解mashup,读者可以借助其他参考资源。

查看更多
 
 

登录TechTarget中国

关闭
本服务仅向TechTarget中国的会员开放,请登录或立即免费注册
电子邮件地址:
请输入您的电子邮件地址
密码:
下次自动登录