论文部分内容阅读
对于那些身处SOA大潮流中的CIO而言，构想和建设一个敏捷、灵活、模块化和可扩展的IT系统是他们的最终梦想。但在很大程度上，很多人一开始就陷入了误区。
一重门:主动VS.被动
被动面对SOA使得CIO面对越来越多的挑战。在SOA大潮下，CIO们应该主动出击，而不是被越来越多的业务和扑面而来的SOA概念弄得手忙脚乱。
Gartner的调查表明，2007年，有50%以上的新的关键业务应用和业务流程设计将使用SOA；到2010年，这个比例将提高到80%以上；到2011年，80%以上的现有应用将通过升级融入到以SOA为特征的业务驱动型组合应用中；有65%以上的套装软件使用者将会在他们的核心业务环境中使用面向服务化的套装软件；到2010年，在SOA项目中使用服务注册机制将由2006年的低于5%，上升到高于40%；到2010年，有60%以上的企业部署的SOA服务会用单独的SOA注册机进行管理；到2011年，80%以上的大型企业会实施多个基于SOA架构的后台基础架构；到2010年，在所有的软件基础架构产品中，会有80%上使用企业服务总线技术或以企业服务总线为基础……
相关机构这一系列的预测数据表明，CIO再也不能被动面对SOA了。
SOA用户不需要冗繁、昂贵的软件架构，他们所需要的是专门针对满足SOA发展趋势而设计好的软件，也就是如何使得已有(或新的)IT资产可以得到更好的重用，如何令IT系统更加灵活并能快速构建新应用。SOA的设计也需要更好的方法来实施和部署可重用的服务，并且做到能够随时随地且简易直接地使用这些服务。
对于用户来说，其实并不需要一开始就把SOA的全局设计好。因为SOA也是一个理念，要贯穿企业IT部署的整个生命周期，不能一蹴而就。在规划之后，首先要把高价值的东西设计成SOA，之后循序渐进。在选择实现方案的时候，要选择那些允许后期进行灵活扩展的产品和方案。有的厂商一下子推荐很大的方案和软件给用户，这对用户并不一定是好事。为此，CIO需要主动选择，而不是被动接受厂商的推销。
尽管用户拥有极为复杂的IT 系统和同样复杂的IT需求，但在某些SOA实现情况下，企业并不需要所有组件。或者说，用户以不同的先后顺序部署更为合理。借助灵活、循序渐进的实施方法，用户可以对SOA产品和方案进行任意组合。
二重门:松耦合VS.紧耦合
随着公司的发展，业务模式不断变化，SOA也要随需应变。对比松耦合与紧耦合这两种模式的特点，分布式SOA会给企业和CIO带来更多的便利。
现在宣传SOA的厂家非常之多，但是真正提出分布式SOA架构的并不多。因为很多大型软件厂商习惯了以紧耦合的方式提供SOA架构的主要功能，SOA紧紧地和他们的数据库、操作系统、服务器和存储绑定，这种紧耦合方式缺乏与其他系统的互操作性，初期需要大量的资金投入，往往会导致用户对某个厂商的依赖。紧耦合式SOA架构导致用户对采用SOA处于犹豫状态，因为在还未看到成功的希望时就需要大量的投资。
面向服务的体系结构最重要的一个思想就是实现软件间的松耦合。松耦合的软件结构可以降低软件的复杂性，提高软件的重用性，使软件能够更好地适应需求的变化。
其实，用户更需要低成本的SOA解决方案，令他们可以从小规模SOA做起，并随着业务的增长逐步扩大规模，同时根据自身的需求增加服务质量和其他功能等。与此同时，用户可以使用点到点的通信方式，避免新增加昂贵的服务器。简而言之，SOA用户需要的SOA架构必须真正具备SOA架构的固有特性，也就是分布式的特性。
SOA的本质是通过松耦合的方式实现服务的重用。分布式SOA则把松耦合的优势发挥得淋漓尽致。它可以帮助用户摆脱紧耦合的束缚，以较少的投资开始SOA建设，用户只配置需要的功能，并根据需要以渐进的方式扩大整合的规模。分布式SOA可以在运行环境中动态配置，也就是说用户的业务无需中断。分布式SOA基础架构，具备今天SOA所涉及的全部元素。
然而不幸的是，集中式的SOA架构方式还在被不断地开发和鼓吹。这些厂商们会不遗余力地说服潜在用户，他们所提供的技术和产品自始至终都支持SOA架构，且从设计伊始便是为了方便用户建立SOA架构，而不管这些技术和产品原本是为J2EE应用服务器而设计，还是为某个系统而设计的。IONA科技公司的Artix是一个可扩展的企业服务总线产品，能够让这些IT资产协同工作，缔造一个分布式的SOA。
三重门:SOA治理同等重要
随着服务数量的增加，管理服务成为SOA过程中的一项重要工作，与IT治理同等重要。
需要指出的是，IT系统在建立之日起就需要考虑IT治理的理念和方法一样，SOA也存在着类似的问题。随着大量服务的构建，系统也日益复杂，尤其是随着服务的可重用性日益提高，调用同一个服务的请求的个人和部门也越来越多。而Web服务的数量越来越多且被不同的部门调用和管理的时候，SOA治理问题就被提上了日程，对IT系统有灵活、可扩展和快速响应需求的企业尤其如此。所以说，SOA的构建和与治理几乎是同步的，这关系着一个企业能否从SOA上获得高收益，甚至也决定着SOA成功与否。
当然，建立一个模块化的环境并提供足够的灵活性是IT设计的终极目的，但总体的设计和策略并不能将未来所有的变化和根据这一变化做出的决策全部考虑进去，这就是SOA治理的意义所在，甚至可以说这是SOA永久成功的基石。
Gartner相关专家指出，SOA治理须确保那些非常重要的需要决策的情况能够让合适的人知晓，并保证那些人有适当的权利来做出那些决策。这就是SOA治理问题的一半了。第二部分就是不管是在何时做出的决策，SOA治理需要保证那些决策能被很好的执行。这不仅仅是设置一个时间限制，而是要强制其执行，并最后给予相关人以奖励或是惩罚，这就是SOA治理的真正含义。
在失败的大型SOA项目中，绝大多数的项目输就输在SOA治理上。没有规矩，不成方圆。对于SOA 的成功，SOA治理不是可选的，而是必须要考虑的关键因素，并且需要将SOA治理作为最早进行的工作之一。
SOA治理并不设计服务，而是指导将如何设计服务。这可帮助回答和解决很多关于SOA的问题：我们提供了哪些服务?谁可以使用这些服务?它们的可靠性如何?安全性如何？……因此治理更多的是策略问题，而不是技术或业务问题。
一重门:主动VS.被动
被动面对SOA使得CIO面对越来越多的挑战。在SOA大潮下，CIO们应该主动出击，而不是被越来越多的业务和扑面而来的SOA概念弄得手忙脚乱。
Gartner的调查表明，2007年，有50%以上的新的关键业务应用和业务流程设计将使用SOA；到2010年，这个比例将提高到80%以上；到2011年，80%以上的现有应用将通过升级融入到以SOA为特征的业务驱动型组合应用中；有65%以上的套装软件使用者将会在他们的核心业务环境中使用面向服务化的套装软件；到2010年，在SOA项目中使用服务注册机制将由2006年的低于5%，上升到高于40%；到2010年，有60%以上的企业部署的SOA服务会用单独的SOA注册机进行管理；到2011年，80%以上的大型企业会实施多个基于SOA架构的后台基础架构；到2010年，在所有的软件基础架构产品中，会有80%上使用企业服务总线技术或以企业服务总线为基础……
相关机构这一系列的预测数据表明，CIO再也不能被动面对SOA了。
SOA用户不需要冗繁、昂贵的软件架构，他们所需要的是专门针对满足SOA发展趋势而设计好的软件，也就是如何使得已有(或新的)IT资产可以得到更好的重用，如何令IT系统更加灵活并能快速构建新应用。SOA的设计也需要更好的方法来实施和部署可重用的服务，并且做到能够随时随地且简易直接地使用这些服务。
对于用户来说，其实并不需要一开始就把SOA的全局设计好。因为SOA也是一个理念，要贯穿企业IT部署的整个生命周期，不能一蹴而就。在规划之后，首先要把高价值的东西设计成SOA，之后循序渐进。在选择实现方案的时候，要选择那些允许后期进行灵活扩展的产品和方案。有的厂商一下子推荐很大的方案和软件给用户，这对用户并不一定是好事。为此，CIO需要主动选择，而不是被动接受厂商的推销。
尽管用户拥有极为复杂的IT 系统和同样复杂的IT需求，但在某些SOA实现情况下，企业并不需要所有组件。或者说，用户以不同的先后顺序部署更为合理。借助灵活、循序渐进的实施方法，用户可以对SOA产品和方案进行任意组合。
二重门:松耦合VS.紧耦合
随着公司的发展，业务模式不断变化，SOA也要随需应变。对比松耦合与紧耦合这两种模式的特点，分布式SOA会给企业和CIO带来更多的便利。
现在宣传SOA的厂家非常之多，但是真正提出分布式SOA架构的并不多。因为很多大型软件厂商习惯了以紧耦合的方式提供SOA架构的主要功能，SOA紧紧地和他们的数据库、操作系统、服务器和存储绑定，这种紧耦合方式缺乏与其他系统的互操作性，初期需要大量的资金投入，往往会导致用户对某个厂商的依赖。紧耦合式SOA架构导致用户对采用SOA处于犹豫状态，因为在还未看到成功的希望时就需要大量的投资。
面向服务的体系结构最重要的一个思想就是实现软件间的松耦合。松耦合的软件结构可以降低软件的复杂性，提高软件的重用性，使软件能够更好地适应需求的变化。
其实，用户更需要低成本的SOA解决方案，令他们可以从小规模SOA做起，并随着业务的增长逐步扩大规模，同时根据自身的需求增加服务质量和其他功能等。与此同时，用户可以使用点到点的通信方式，避免新增加昂贵的服务器。简而言之，SOA用户需要的SOA架构必须真正具备SOA架构的固有特性，也就是分布式的特性。
SOA的本质是通过松耦合的方式实现服务的重用。分布式SOA则把松耦合的优势发挥得淋漓尽致。它可以帮助用户摆脱紧耦合的束缚，以较少的投资开始SOA建设，用户只配置需要的功能，并根据需要以渐进的方式扩大整合的规模。分布式SOA可以在运行环境中动态配置，也就是说用户的业务无需中断。分布式SOA基础架构，具备今天SOA所涉及的全部元素。
然而不幸的是，集中式的SOA架构方式还在被不断地开发和鼓吹。这些厂商们会不遗余力地说服潜在用户，他们所提供的技术和产品自始至终都支持SOA架构，且从设计伊始便是为了方便用户建立SOA架构，而不管这些技术和产品原本是为J2EE应用服务器而设计，还是为某个系统而设计的。IONA科技公司的Artix是一个可扩展的企业服务总线产品，能够让这些IT资产协同工作，缔造一个分布式的SOA。
三重门:SOA治理同等重要
随着服务数量的增加，管理服务成为SOA过程中的一项重要工作，与IT治理同等重要。
需要指出的是，IT系统在建立之日起就需要考虑IT治理的理念和方法一样，SOA也存在着类似的问题。随着大量服务的构建，系统也日益复杂，尤其是随着服务的可重用性日益提高，调用同一个服务的请求的个人和部门也越来越多。而Web服务的数量越来越多且被不同的部门调用和管理的时候，SOA治理问题就被提上了日程，对IT系统有灵活、可扩展和快速响应需求的企业尤其如此。所以说，SOA的构建和与治理几乎是同步的，这关系着一个企业能否从SOA上获得高收益，甚至也决定着SOA成功与否。
当然，建立一个模块化的环境并提供足够的灵活性是IT设计的终极目的，但总体的设计和策略并不能将未来所有的变化和根据这一变化做出的决策全部考虑进去，这就是SOA治理的意义所在，甚至可以说这是SOA永久成功的基石。
Gartner相关专家指出，SOA治理须确保那些非常重要的需要决策的情况能够让合适的人知晓，并保证那些人有适当的权利来做出那些决策。这就是SOA治理问题的一半了。第二部分就是不管是在何时做出的决策，SOA治理需要保证那些决策能被很好的执行。这不仅仅是设置一个时间限制，而是要强制其执行，并最后给予相关人以奖励或是惩罚，这就是SOA治理的真正含义。
在失败的大型SOA项目中，绝大多数的项目输就输在SOA治理上。没有规矩，不成方圆。对于SOA 的成功，SOA治理不是可选的，而是必须要考虑的关键因素，并且需要将SOA治理作为最早进行的工作之一。
SOA治理并不设计服务，而是指导将如何设计服务。这可帮助回答和解决很多关于SOA的问题：我们提供了哪些服务?谁可以使用这些服务?它们的可靠性如何?安全性如何？……因此治理更多的是策略问题，而不是技术或业务问题。