热点讨论：SOA重在技术还是业务？

下载本文示例代码
　　本文转自InfoQ，文中内容不代表本站观点，仅提供参考。　　Nick Gall发帖说脱离技术去讨论SOA是有问题的。他是看了Andrew McAfee的一篇批评“无关技术论”(It's not about the technology，INATT)的贴子之后有感而发。 　　Andrew认为有两种类型的INATT。一种是表达得不够充分，另一种则是完全错误而且误导人的。Andrew说第一种说的其实是“不仅仅跟技术有关”，第二种则是“讨论问题的时候可以忽略技术细节”。 　　Nick把Andew的定义用到SOA身上，他说： 　　跟Andrew一样，每当我听到这种说法都要颤一颤——尤其是在SOA的讨论中，更尤其是在Yahoo新闻组Service-Orientated-Architecture上面的SOA讨论中。在这些讨论里头，实现SOA的各种技术上的选择是被当作不相干的事情而不加考虑的，讨论的人只是在夸夸其谈中自得其乐。 　　Burton的Anne Thomas Manes承认她也说INATT，不过她相信自己用的是这句话的另一层意思，目的是强调在设计中技术是次要的： 　　更具体地说，技术是实现上的决策。当项目启动的时候，项目团队应该首先确定和分析项目需求，然后才选择适当的技术来满足项目需求。 　　Anne说，技术只是工具，你要为工作选择正确的工具——但首要的事情应该是确定要做的是什么工作。 　　但毕竟SOA是一种架构风格，跟任何架构性工作一样，你必须首先想清楚你的架构性目标。不过在作出技术上的选择之后，还是应该回头去重新检查你在架构上的决策。(见下图)。因为技术、平台之类总有它们自身的一套架构、功能和局限。 　　　　 　　(引用自“An Architectural look at SOA”) 　　在最近一篇名为《以ESB为导向的架构：错误的SOA采纳路径》中，IBM的Bobby Woolf(著名的《Enterprise Integration Patterns》的作者)提醒我们： 　　“客户常常希望单纯构建ESB，因为这样可以避开难搞的业务需求，专心解决技术上的挑战。单纯构建ESB是IT人员的梦想，这样他们可以先建立ESB，然后指望以后会有SOA跟上来利用它。这种以ESB为导向的架构丢掉了SOA的优势。它没有产生业务价值。实际上，花费了成本却没有收获直接的利益。而且它不能让IT与业务保持齐头并进。比ESB为导向的架构更好的是以SOA为导向的架构。不要单纯构建ESB;把它作为SOA的一部分来构建，最好是能适合IBM所推荐的SOA Foundation架构。” 　　总而言之，技术是重要的，因而我们在设计SOA或者任何项目的时候，都不可能忽视技术。然而技术应该放在第二位，业务才是第一位的——是这样吗?你怎么想?　　参看原文链接　　查阅关于SOA的全部文档 　　本文转自InfoQ，文中内容不代表本站观点，仅提供参考。　　Nick Gall发帖说脱离技术去讨论SOA是有问题的。他是看了Andrew McAfee的一篇批评“无关技术论”(It's not about the technology，INATT)的贴子之后有感而发。 　　Andrew认为有两种类型的INATT。一种是表达得不够充分，另一种则是完全错误而且误导人的。Andrew说第一种说的其实是“不仅仅跟技术有关”，第二种则是“讨论问题的时候可以忽略技术细节”。 　　Nick把Andew的定义用到SOA身上，他说： 　　跟Andrew一样，每当我听到这种说法都要颤一颤——尤其是在SOA的讨论中，更尤其是在Yahoo新闻组Service-Orientated-Architecture上面的SOA讨论中。在这些讨论里头，实现SOA的各种技术上的选择是被当作不相干的事情而不加考虑的，讨论的人只是在夸夸其谈中自得其乐。 　　Burton的Anne Thomas Manes承认她也说INATT，不过她相信自己用的是这句话的另一层意思，目的是强调在设计中技术是次要的： 　　更具体地说，技术是实现上的决策。当项目启动的时候，项目团队应该首先确定和分析项目需求，然后才选择适当的技术来满足项目需求。 　　Anne说，技术只是工具，你要为工作选择正确的工具——但首要的事情应该是确定要做的是什么工作。 　　但毕竟SOA是一种架构风格，跟任何架构性工作一样，你必须首先想清楚你的架构性目标。不过在作出技术上的选择之后，还是应该回头去重新检查你在架构上的决策。(见下图)。因为技术、平台之类总有它们自身的一套架构、功能和局限。 　　　　 　　(引用自“An Architectural look at SOA”) 　　在最近一篇名为《以ESB为导向的架构：错误的SOA采纳路径》中，IBM的Bobby Woolf(著名的《Enterprise Integration Patterns》的作者)提醒我们： 　　“客户常常希望单纯构建ESB，因为这样可以避开难搞的业务需求，专心解决技术上的挑战。单纯构建ESB是IT人员的梦想，这样他们可以先建立ESB，然后指望以后会有SOA跟上来利用它。这种以ESB为导向的架构丢掉了SOA的优势。它没有产生业务价值。实际上，花费了成本却没有收获直接的利益。而且它不能让IT与业务保持齐头并进。比ESB为导向的架构更好的是以SOA为导向的架构。不要单纯构建ESB;把它作为SOA的一部分来构建，最好是能适合IBM所推荐的SOA Foundation架构。” 　　总而言之，技术是重要的，因而我们在设计SOA或者任何项目的时候，都不可能忽视技术。然而技术应该放在第二位，业务才是第一位的——是这样吗?你怎么想?　　参看原文链接　　查阅关于SOA的全部文档 下载本文示例代码


热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？热点讨论：SOA重在技术还是业务？