cuiyi's blog(崔毅 crazycy)

记录点滴 鉴往事之得失 以资于发展
数据加载中……

构件 构件 怎么就成sca了呢?soa虚阿虚阿(乱弹)

      构件,本是一个很古老的主题,SUN最初推出javabean即是一种可视组件的萌芽,可惜如同java的动态代理的潜伏期一样,一直没有足够的人发现并重视起来。

     与此同时,另外的阵营,Boland的delphi,Microsoft的V*家族以及现在.Net家族,却不断制造着高产易用的神话。

     Java本来就是重视扩展和让涉足的人享受背后机理的语言,如同做饭而非速餐,这早已成为一个很好的说辞。

     今天,为了互操作而退出的webservice,实际就是接口的更泛化拓展;构件也从了组件的泛化延伸,成为一个极大成者。我们拥有了构件,我们也将走向了高速和易用,我们是否可以反思,当初阐释不进Microsoft阵营的冠冕堂皇理由,是否经得起构件的洗礼?

     想到了构件,不由延伸到了sca,更不由的触及soa,从一个听不懂的概念炒作历经几年之久走过多个版本的演化,成为今天的方法论和架构方法标准工具。曾经一味的热情投入着,呼吁呐喊着,从为集成而生的理解到当今稍微成熟的soa本质既业务敏捷,也就是变化的需求;依然没有逃出任何技术产生的直接机理:适应需求的变化。换句话说,一切技术思想方法论无不是为更好的适应需求的变化而生。

     那中间的esb等是否真的是过度的羔羊?如果诸如IBM,BEA同样拥有雄厚的ESB产品线的话,今天的soa定当别论;历史不可假设,演化不可逆转,soa的路也得益于此俩巨头的“盲区”,否则tibco必然不会让出esb头把交椅。

    那soa是否真的可以实现业务敏捷?摸着头皮思考,良久良久,受个人阅历(刚有不足3个月工作经验)之限,虽阅读各家之言,然不由闷笑。构件显然不是,因为架子在具体细节依然离开不具体实现技术,一旦涉足技术就无法避免软件工程的延迟等诸多风险因素,业务敏捷谈何而来?如果说加强了业务人员和开发人员的沟通,亦为必然。不认为有了一个可以看得外貌就可以确定一些理解上的盲区,能画出来的大多自然是彼此不存在疑惑的地方,但是很多地方亦是模棱区,产品或者说项目不是儿戏,不存在不可确定的东西,是就是非就非,最后落实的沟通是最有效的方式,也可能是迭代感知,这些都不是soa之大手笔。

    那soa为何会走过如此多的路,最后走向了一个“无就是有有就是无,更多的成为道家的境界呢?”我觉得就是因为解决不了定位的目标,那归结为一个无限大的话题---本来就是要正面的主题,肯定不会错,改进多少年,反正都是在解决这个目标,这就是soa。

   个人一时乱弹,友善交流,请勿攻击漫骂之。

posted on 2007-07-11 23:31 crazycy 阅读(1283) 评论(0)  编辑  收藏 所属分类: SOA、WebService、BPEL


只有注册用户登录后才能发表评论。


网站导航: