Q：结合中国的具体环境，您认为在中国实施SOA与欧美实施SOA存在哪些方面的区别？哪些欧美模式是我们不能照搬使用的？哪些经验是我们可以借鉴的？
A：企业因为实施SOA而遇到一些难题是很正常的，因为SOA的实施暴露出过去IT系统一直存在的诸多问题：比如建设模式、原有系统、组织架构、治理模式等等。对大多数企业来说，SOA的远景目标架构是比较相似的，因此，SOA的设计哲学、治理原则、基于服务的软件工程学、SOA卓越中心等通用的策略与方法是可以借鉴的。不同之处主要有两个方面，其一是IT现状和业务发展策略的不同导致了每个企业演进路径的路线图不同，其二是管理模式和文化习惯的不同，又导致了实施策略的不同。从这几个角度分析，中国企业实施SOA时，要特别注意中国特有的经济特性，管理模式和IT现状带来的一些特殊要求。
Q：在实际的IT环境中，并不是所有的项目都适合SOA，这涉及到原有系统的切割或者重建，您认为如何能寻求到这两者的平衡？
A：如果把企业的IT系统比喻为一棵大树，那么我们可以把银行核心交易、电信计费、交通调度等应用等视为大树的根茎，它是很多企业的基础业务。SOA架构则很像是这棵大树的树冠，它的架构多适用于面向各种外部与内部信息服务有关的业务。SOA的推进过程往往是这样，先不去大幅度翻新已有的树根类核心应用，而是侧重于为内外部客户提供灵活的信息服务类应用，采用共享服务式的架构来建立一个中间层，逐步地把原有树根系统应用中一些与这些信息服务相关的应用组件暴露成服务，部署在基于服务总线的共享服务式架构上，还可以采用BPM等工具重新编排这种服务。因此这是一个“边破边立”的过程，不要求把原有系统一次全部服务化，而是逐步根据新项目的业务目标来改造原有系统。
Q：今年陆续出台了SOA的标准SCA和SDO，这些标准的出台对SOA有哪些促进作用？对中国的企业实施SOA有什么样的影响？
A：目前实施SOA的企业，多是原有系统比较健全的大型客户，他们将SOA作为一种企业级架构的演进，认为这是一个长达3～5年的旅程。在这里，整体架构的规划、SOA能力中心的建立以及基于SOA的软件工程学，是三个重要的长期任务。SCA和SDO的价值在于，为新应用的开发提供了一个面向SOA架构的标准，可降低新应用在未来融入企业SOA的远期成本，所以它属于基于SOA的服务工程学里面一个开发方法。至于SCA和SOA之间的关系，如果用城市作比喻的话，SOA是在考虑如何将一座城市逐步演进得更为灵活，更为高效;而SCA是一种在SOA整体规划的标准下，建设一栋新楼(应用)的一种施工方法。对于中国企业里面考虑新应用的开发方式，选择SCA/SDO是个有前瞻性的选择。
Q.您认为目前中国的企业在搭建IT环境时最关心的是什么？是否采用SOA架构进行部署？还是更低的成本？在实施SOA过程中怎么降低成本，达到二者的平衡？
A：从中国经济特性分析可以得出一些结论，中国企业搭建IT环境时最关心的问题有几个方面：如何快速部署？架构是否可以灵活改变？能否降低维护的成本？SOA的实施过程有一个特点，它在开始实施的初始阶段往往需要比普通的项目花费更多的精力，因为需要考虑今后的治理原则、服务的未来复用等问题，因此SOA的实施是一个N+1的项目，在N个业务应用之外，有一个持续存在的SOA(1项目)一直需要考虑，只有这样，SOA的企业级有时才会发挥越来越大作用。因此SOA永远不是一个速战速决的事情，它需要通过眼前更多的耐心和努力换取以后IT系统的长治久安。
Q：SOA与EAI的关系？
A：SOA与EAI既有区别又有联系。区别在于SOA是以业务为中心的系统设计思想，其设计目标之一就是敏捷地响应业务变更，所以SOA注重服务的标准化与重用。一个SOA系统的建设内容包括架构规划、服务的开发、服务的管理、服务基础设施的建立以及相关技术和管理规范的建立。SOA希望在业务层面、技术层面和管理层面等全方位地考虑问题，系统性地解决企业的IT问题。而EAI更多地关注系统间如何实现互联，并解决相应技术问题。EAI包含的内容比较狭窄，对于业务功能共享、复杂的应用集成等问题，EAI 希望通过接口技术、流程配置来解决。
二者之间的联系体现在它们都是面向企业级应用的，都可以用来解决应用集成问题。通常，EAI技术被用来实现SOA分层参考架构中的信息与访问服务层，解决SOA系统与遗留系统的互联问题。
Q：重用、继承等是OO的概念，与SOA是什么区别？
A：SOA关于服务的重用抽象的程度比较高，是企业级的业务重用，因此要求其具有自包含的特性，即可以不依赖于其他组件，向外部提供相对完整的业务功能，这个功能是对于业务语意而言的，有明确的业务定义。OO的重用和继承是对应于编程技术语意的，通常，一个重用的对象需要通过与其它对象的交互，才能实现完整的“业务功能”
Q：遗留系统以及原有技术架构对SOA实施有多大的影响？
A：有一定的影响，通常体现在几个方面：其一是共享功能的服务化。遗留系统以及原有技术架构对提取需要服务化的共享业务功能有影响，例如C/S结构，提取业务功能较为困难;其二是遗留系统作为服务的消费者，访问共享服务，实现业务流程优化和再造时，它的原有技术架构对共享服务的接口设计有影响;其三是遗留系统的安全认证、授权方式，当前的负荷及设计容量，响应能力等非功能性特性，也会对服务的设计造成影响。
当然，上述影响可以通过分层参考架构模型的设计，加以通盘考虑，予以解决。
Q：ESB技术和EAI技术甚至BPM技术似乎有些重叠，它们的关系如何？
A：服务总线(ESB)技术支持各种通讯协议转换、消息格式转换，以及服务编排调用。从这个意义上讲，它的确与EAI技术甚至BPM技术都存在重叠。设计服务总线主要目的是实现功能服务化、服务的协同调用以及支持服务的管理。所以服务总线技术的功能不止于此，例如还包括服务目录管理的支持、对服务代理的支持、对SLA的支持等。
而EAI技术虽然具有通讯协议转换、消息格式转换的能力，但是在功能服务化和服务管理等方面有欠缺。EAI技术是关注应用的，BPM技术关注的是跨应用的流程，SOA关注的是可重用的服务。BPM可以实现复杂的业务流程建模和充当流程引擎，这是服务总线技术不能胜任的。
Q：COTS软件或集成商的软件自成一套服务体系，如何考虑SOA的切入呢？
A：SOA的一个重要的价值在于解耦。很多客户使用的COTS软件或集成商的软件自成一套服务体系，因此在修改和与其他系统集成是会遇到困难，比如客户的信息集成，数据集成，利用这类集成项目的机会，来对原有软件进行解耦，是一个很好的切入点。
Q：SOA是崇尚革命式的演变还是渐进式的变革？
A：SOA 转型通常是渐进式的变革，因为SOA往往面对整个企业，影响的应用系统很多。所以采用渐进式的变革可以有效降低实施风险。此外渐进式的变革有助于分散SOA初始阶段高昂的投资成本，也有助于尽快取得投资回报。
Q：如果是渐进式的演进，从工程的角度看边界不易敲定，SOW如何定？
A：渐进式的演进含义是指一个项目接一个项目的增量式开发，周期性的架构规划与调整。而对于其中的特定项目，其项目工作范围、实施边界应该是非常明确的，其SOW也是非常明确的。不能把SOA项目看作独立的IT 项目，甚至是边设计、边实施、边验收的“三边工程”，而要在一个整体规划的基础上，进行边界明确的项目实施。
Q：SOA设计很多基础设施的搭建，责权利如何定义？
A：SOA项目通常以架构规划开始，在架构规划中，明确定义基础设施的功能、实施的路线图。对于基础设施的搭建，应当以架构规划为依据，由专门的项目小组完成。
Q：以企业为边界考虑SOA和与项目为边界考虑SOA对未来有无影响？
A：有很大的影响。SOA的主要目标之一就是实现企业范围内服务的标准化和重用。以项目为边界考虑SOA，势必造成SOA服务规划短视，影响服务的标准化和重用。
Q: Services Governance(服务管控或IT资产管控)是企业以前的薄弱环节，但如果系统都面向服务了，服务的管控何时开始考虑？
A: 最好的方式，当然是在SOA项目开始的时候，就考虑服务管控或IT资产管控，包括制定管控模型。考虑到项目实际情况，起始的项目范围较小，服务数量也很少，所以项目虽然缺乏明确的服务管控或IT资产管控制度，SOA系统仍然可以良好运转。但是随着项目实施范围的扩大、服务数量的增加，管控的必要性就增加了。应适时引入服务的管控规划。
文章来源：CSDN
责编：李华星
微信扫一扫实时了解行业动态
微信扫一扫分享本文给好友
微信扫一扫实时了解行业动态
POEM Experiments 2.0 Brochure ...
