SOA? CORBA? 缩写首字母变了, 窘境依然

         
              SOA (面向服务的架构)好像已经成了很时髦的话!!! SOA可以解决所有的问题,每个人都希望用SOA--我听说的差不多就是这样. 然而,当CORBA诞生时,我记得也是这样相似的声明. 人们期望它能改变IT业的工作方式. 对我来说,SOA就是基于CORBA的拥有更完善标准的XML/SOAP. 我可能错了.

然 而时间到了现在,却没有什么变化. Well,也许不是没有改变,至少有一点可以确定 -- IT复杂度正在以一种恐怖的速度增加,我真的不知道 -- 在失控之前,我们最大能承受的复杂情况是什么样子? 网上购物网站最担心这种事情,他们花了大成本去处理这种复杂度. 我有一个问题 --- SOA的引入真的能帮助IT人员更好的管理复杂度和降低成本吗? 还是在CORBA后面重蹈覆辙? 目前为止我看到了它在这个领域起的积极作用,但也有不少的怀疑的声音.

我能确信的是那些组织机构正在寻找一些新的方式来利用这种技术,将它变成一种竞争优势. 掌控这种新的日益复杂的平台会只是一种挑战.

我的观点认为SOA的引入只会把IT复杂度推向一个新的高度,超过了那些目前能够有效的实施管理的管理架构. 为什么我要这样说? 有几个理由:


-- 以SOA为基础应用需要一些能够更快的适应需求改变情况的管理工具,而目前的管理工具却不要求这样.

--以SOA为基础的应用会把大量的各种非集成的业务组合到一起,创建一个集成的业务层,而这种集成的东西却不能被那些以事件触发为基础的健康监控程序监控到.

那些需要用来管理SOA环境的大量的工具和技术本身就需要去维护了,过于复杂了.

如果管理不好,或者不能系统的降低和简化,复杂性会呈指数级上升.

所以SOA架构有一个潜在的特征就是把事情复杂化,复杂化到不能控制,它比那些典型的3层结构, client/server或者是monolithic应用的管理复杂的多.

这样一来,我们如何去处理它一方面有优势而另一方面会增加复杂性的关系呢? 我觉得只有一个办法可以解决这个 -- 在SOA管理工具上和管理经验是多下投资. 不仅需要技术,而且需要技能,过程方法,和实践经验. 这里有几种方法看起来很有吸引力:

*虚拟化 -- 处理复杂性的一种方法是简化工作环境  -- do more with less -- 较少的硬件,较少的网络工作,较少的软件系统. Less is more very often(少经常会变成多).

*建立和维护能力储备 -- 而不是工具储备或你需要去掌握的工具清单. 很显然,你需要掌握至少一种技术或工具所能发挥的所有重要的能力. 也许不需要第二种. 着重是技术的功效,而不是工具和技术本身. 使用这些技术储备可以简化你的工作环境.

*使用KISS方法 -- 自从大学时代我喜欢这种方法. 保持傻瓜式和简单明了. 应用到每个可能的方面. 复杂的设备,构造很难去维护和管理.

如果不加斟酌, SOA的优势就会被不断增加的维护工作所吞噬,服务质量会下降,收入会降低,顾客的忠诚对也会下降. SOA环境实现的成功与否决定于均衡增长的策略 -- 不要仅考虑增加功能能力,也要考虑如何降低复杂度.

about author:
   Albert Amashev is a seasoned technology professional, and has worked in many large enterprise integration exercises. His professional interest lies in IT integration, performance tuning, and service-oriented architecture (SOA).

 

外刊IT评论  

@_@

原来不是我看错了  还是你们选的问题

你在对谁说话?自言自语?

复杂度上升是必然的。
如果大到机器能够自己写程序后
复杂度才会降下来
（如果用现在这种架构写程序大概永远写不出来。）

SOA 为什么而生？首先要搞清楚这个问题

往往初衷是好的,结果是坏的

用rss难 吗 ?   rss就是soa

对不起，我以小白的名义问：为啥说缩写的首字母“变”了？

猜测 :  CORBA 缩写 COA --> SOA

SOA和CORBA的思想是一脉相承的
很多事情往往叫得越响越是难以有预期的效果出来，时间是唯一的试金石