构件，本是一个很古老的主题，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。
个人一时乱弹，友善交流，请勿攻击漫骂之。
与此同时，另外的阵营，Boland的delphi，Microsoft的V*家族以及现在.Net家族，却不断制造着高产易用的神话。
Java本来就是重视扩展和让涉足的人享受背后机理的语言，如同做饭而非速餐，这早已成为一个很好的说辞。
今天，为了互操作而退出的webservice，实际就是接口的更泛化拓展；构件也从了组件的泛化延伸，成为一个极大成者。我们拥有了构件，我们也将走向了高速和易用，我们是否可以反思，当初阐释不进Microsoft阵营的冠冕堂皇理由，是否经得起构件的洗礼？
想到了构件，不由延伸到了sca,更不由的触及soa,从一个听不懂的概念炒作历经几年之久走过多个版本的演化，成为今天的方法论和架构方法标准工具。曾经一味的热情投入着，呼吁呐喊着，从为集成而生的理解到当今稍微成熟的soa本质既业务敏捷，也就是变化的需求；依然没有逃出任何技术产生的直接机理：适应需求的变化。换句话说，一切技术思想方法论无不是为更好的适应需求的变化而生。
那中间的esb等是否真的是过度的羔羊？如果诸如IBM，BEA同样拥有雄厚的ESB产品线的话，今天的soa定当别论；历史不可假设，演化不可逆转，soa的路也得益于此俩巨头的“盲区”，否则tibco必然不会让出esb头把交椅。
那soa是否真的可以实现业务敏捷？摸着头皮思考，良久良久，受个人阅历（刚有不足3个月工作经验）之限，虽阅读各家之言，然不由闷笑。构件显然不是，因为架子在具体细节依然离开不具体实现技术，一旦涉足技术就无法避免软件工程的延迟等诸多风险因素，业务敏捷谈何而来？如果说加强了业务人员和开发人员的沟通，亦为必然。不认为有了一个可以看得外貌就可以确定一些理解上的盲区，能画出来的大多自然是彼此不存在疑惑的地方，但是很多地方亦是模棱区，产品或者说项目不是儿戏，不存在不可确定的东西，是就是非就非，最后落实的沟通是最有效的方式，也可能是迭代感知，这些都不是soa之大手笔。
那soa为何会走过如此多的路，最后走向了一个“无就是有有就是无，更多的成为道家的境界呢？”我觉得就是因为解决不了定位的目标，那归结为一个无限大的话题---本来就是要正面的主题，肯定不会错，改进多少年，反正都是在解决这个目标，这就是soa。
个人一时乱弹，友善交流，请勿攻击漫骂之。
932
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
