是ESB应用有害于SOA还是架构问题
2008-08-23 15:35
429 查看
在网站上读到了一篇Rich Seeley写的文章,大意如下: “ITKO公司是一家专门进行面向服务架构(SOA)测试的厂商,其首席架构师John Michelsen认为在实施过程中除了相关WS-*规范存在隐患之外,企业服务总线(ESB)的应用媒介仍然是个问题。” “他们发现公司内部的两三个部门正在使用来自不同厂商的不同企业服务总线(ESB)应用。”
这里已经出现了许多问题,首先如果真的存在“企业架构”和“企业架构师”,那么不同部门就不应该出现使用不同ESB应用的情况,在这种应用不明确的条件
下甚至连ESB都不应该使用。也许这种想法有些疯狂,但是你们难道不认为,基于业务要求制定一个关于SOA的集中计划相较于出于一次性战术考虑撒下大笔的
资金或仅仅做出对于潮流的反应来说更有意义吗?
第二,如果我之前的看法是正确的,那么为什么要尝试将这些应该全部替换的集成引擎整合到一起呢?事实上是集成引擎在众多使用不同方案的系统之间调节差
异。因此,在企业中拥有两个或更多的ESB意味着你正处理两个或者更多完全不同信息集成方案以及服务调节。没有ESB是完全相同的,所以你将发现将它们全
部去除并重新开始比起使不同的ESB相互交流更为节省成本。还要再一次强调的是你需要决定自己的需求,而后得出解决方案的形式,然后才是技术。而根据
TechTarget的文章,企业似乎是倒着来的。 如果你专注于层叠更多的技术而不是正常化现有的技术,矫正业务变革以及着眼于简化程序增加敏捷度,那么你SOA就将失败。在没有更加整体的概念之前,着眼于简单,不要再将技术带到您的企业中去。
这里已经出现了许多问题,首先如果真的存在“企业架构”和“企业架构师”,那么不同部门就不应该出现使用不同ESB应用的情况,在这种应用不明确的条件
下甚至连ESB都不应该使用。也许这种想法有些疯狂,但是你们难道不认为,基于业务要求制定一个关于SOA的集中计划相较于出于一次性战术考虑撒下大笔的
资金或仅仅做出对于潮流的反应来说更有意义吗?
第二,如果我之前的看法是正确的,那么为什么要尝试将这些应该全部替换的集成引擎整合到一起呢?事实上是集成引擎在众多使用不同方案的系统之间调节差
异。因此,在企业中拥有两个或更多的ESB意味着你正处理两个或者更多完全不同信息集成方案以及服务调节。没有ESB是完全相同的,所以你将发现将它们全
部去除并重新开始比起使不同的ESB相互交流更为节省成本。还要再一次强调的是你需要决定自己的需求,而后得出解决方案的形式,然后才是技术。而根据
TechTarget的文章,企业似乎是倒着来的。 如果你专注于层叠更多的技术而不是正常化现有的技术,矫正业务变革以及着眼于简化程序增加敏捷度,那么你SOA就将失败。在没有更加整体的概念之前,着眼于简单,不要再将技术带到您的企业中去。
相关文章推荐
- SOA 架构中的ESB是更好的应用于异构系统集成整合还是用于统一服务调用/基础服务实施
- 驱动还是应用? 这是一个多人提起的问题 韦东山
- IFS应用系统-面向服务的架构(SOA)
- 伴随开发人员成长的问题:工程重要,还是算法重要?细节重要,还是架构重要?
- 架构设计师与SOA之架构企业级SOA应用
- 架构设计:进程还是线程?是一个问题!
- ESB实现SOA 企业复杂应用集成的解决措施(1)
- SOA架构重点:信息化管理与应用整合
- SOA架构实施重点:信息化管理与应用整合
- 参加Tibco的SOA应用及2009 IT架构趋势研讨会记
- 大数据架构和模式(五)——对大数据问题应用解决方案模式并选择实现它的产品
- 当cio遇见soa架构 是该希望还是该恐惧 (1)
- [面试][架构] 微服务、SOA、ESB
- 大数据架构和模式(五)对大数据问题应用解决方案模式并选择实现它的产品
- .NET的WEB企业应用架构所要解决的若干问题[转]
- 免费ESXI 3.5服务器应用虚拟架构的备份问题探讨
- .NET的WEB企业应用架构所要解决的若干问题
- 动态加载程序集[仿Petshop架构应用开发遇到的问题]
- 架构设计:进程还是线程?是一个问题!(转载)
- 架构设计:进程还是线程?是一个问题!