SOA governance系列之一
日期：作者：来源：
&&&&&&&&&&&&&&&&&&
　　最近，一段时间都忙于学习，已经很久没上blog写文章了，而查看SOAer里面的一个帖子，发现有同志对我写的SOA governance比较感兴趣，所以也就产生了写一系列对SOA governance理解的文章.这些文章会作为一个系列，是笔者本人的理解，希望对大家有所帮助.　　SOA governance最近在serverside网站上也是时常看到相关的内容，可见其Hot的程度了.把SOA摆在现实中看来，更觉得它是一个体系，包容万千，想一个绚丽的万花筒，从不同的角度看出不同的内容，而围绕着它也相应产生出了一系列相关的术语.研究SOA这么久，大家都有一个共识:服务的设计粒度难以把握.这块对于设计者来说可谓是"仁者见仁，智者见智".虽然SCA规范给出了基础设施技术上的规范，但仍然让"年轻"的SOAer们有足够的勇气迈入SOA的实验场.现实是现实，理想是理想，如果还是不跟上SOA的潮流，中国将在新的一轮"软件革命"中陨落，让我们踏上SOA governance的学习历程吧.　　既然研究和学习的对象是SOA governance，那么就从什么是governance开始吧.governance其实就是有目的地运用策略、计划、过程和组织机构来做决策并控制一个实体（这里的实体可以是企业、政府等，任何可以运营的实体）从而达到业务目标。SOA governance则关注于需要创建或已经存在的SOA实现中的服务。我们知道，采纳SOA的主要目的就是要实现业务和IT的敏捷性。SOA是一种利用企业架构实现公司业务战略的可重用服务方法。那么，要创建一个环境，以便里面的纵多的可复用服务以及好处可以得以实现，必须有经过慎重考量、明文给出、可实现且可以维护的管理规划。可能更多的人会提到SOA的好处，而在这里我想提出的是，SOA的好处是其指导意义，它的真正有效的现实价值在于它可以创建一个“面向服务的企业”。“面向服务的企业”则是围绕着以更水平的模式连接业务流程。　　一般做规划可能产生两种极端，一类是过于全局化，设置重重看似完美、其实繁冗的官僚机构的控制以及得出堆积如山的纸质文件，最近因为陷入管理的泥潭无法自拔，项目被迫取消；而另一类则为赶进度或其他原因，每个业务单元更多从自身的需求出发，无视对全局的影响，最终导致各个业务系统间的数据和业务冗余，而后期进入无休止的集成期。　　我们不禁反思，我们需要的是什么？答案很简单，我们需要的不过是一个“面向服务的企业”。它应该走中庸路线，某些控制是必须的，而另一些则无须繁冗的横加管涉，便于增值好的服务和敏捷性。管理模型趋向于通过普遍的自治策略、规划、程序和规则来实现多组织间的联邦制。其实，这不禁让我们想到英国的国情了，英国的历史其实就是一个入侵与被入侵、统治与被统治的历史。国力强盛的英国曾经被称做“日不落帝国”，它有中央集权时期，后来终于因为哪里有压迫，哪里就有反抗，废除了。现在的英国就称为“英联邦”，这种松散但又有组织的制度，维持着这个国家。这也是中庸的结果。看来中国的圣人们就是牛呀。把话题拉回来，刚才说到管理模型的联邦制。借助这种模式，可以分别通过两种方式催生出一个“面向服务的企业”，“自上而下”，“自下而上”。　　SOA可以看做是拥抱变化的催化剂，而不能看做是解决变化的银弹，如果使用适当，会融合业务和IT技术的优势。现在有很多公司申明有一系列基础设施技术，其实最多就是一个消息中间件而已。升级一个组织并引入SOA技术架构的能力是相对容易的，如使用ESB组织服务，XML实现异构系统消息交换等等并不难。虽然，这有价值，但只是SOA之旅万里长征的第一步，仅仅升级技术并不能带来什么现实的益处。　　未完待续。。。。。。
微信公众号
TechTarget
TechTarget中国
Gartner认为iBPM要比运营型智能平台更优秀，表现在以下几个方面：iBPM套件提供更好的工作流，适配性案例管理以及结构化流程协调能力。
云端业务流程管理已经不再是什么新鲜事，更不再是什么可怕的方法来管理重要的业务流程。现在，它已经普遍被认为是一种新常态。组织已经从这一技术中获益，使它来更有效地访问和管理企业信息。
随着云技术的不断采用，现代企业都面临着重大的集成问题。现在已经不再是把企业内部的数据和应用简单地缝合在一起，企业IT现在面临着整合着外部与内部信息的难题。
2014将会是API管理方法新旧PK的一年，据Delyn Simons说，她领导了Mashery开发者的外展团队。应用编程接口（API）的主流化和私有化在新的一年也将掀起波澜，她在波士顿“Future Insights Ultimate Developer Event 2013”大会上预测说。
企业级IT网站群
TechTarget中国 版权所有
All Rights Reserved, Copyright
TechTarget中国 版权所有
All Rights Reserved, Copyright比特客户端
您的位置：
详解大数据
详解大数据
详解大数据
详解大数据
此SOA 非彼SOA
　　本文作者为设计中心主管、IBM高级技术主管毛新生
　　《程序员》杂志邀请我写一篇短文探讨SOA的本质，也就是它究竟是什么。这个题目不好写，易起纷争，所以我预先说，这篇文章是用来分享我个人的理解，提供探讨用的材料，不是答案。
　　让我们开门见山。SOA的首要目的是让业务能够快速地响应或领导变化，即“业务敏捷性”(Business Agility)。而SOA自身，首先是设计原则和风格;其次它是来自实践、应用这些原则和风格的架构范式;再次，SOA是支持和实现这些原则和风格的技术、标准和产品;最后，它是保证各方有规可循、透过在“服务”的生命周期中相互协作来达成业务敏捷的管控策略(Governance)。
　　既然SOA是IT正在发生的一个大的变化和范式转移，这对我们意味着什么呢?本文也将简单讨论。
　　业务敏捷性
　　“敏捷性”(Agility)，包括几个重要因素：变化，变化的速度，和变化的质量。“业务敏捷性”让一个企(事)业能够适时、快速地响应变化，采取恰当、明智的应变措施。这是今天竞争激烈、变化越来越快的全球化商业环境所决定的，传统的企业观受到挑战，如何灵活快速适应变化甚至是创新求变，成为企(事)业生存和发展的。很多耳熟能详的名词和讨论都跟它有关，比如“随需应变”(On Demand)、“实时企业”(Realtime Enterprise)、“Adaptive Enterprise”、“Liquity Computing”等等。
　　业务敏捷性怎么跟SOA有这样的关系?我们需要讨论几个子问题来回答。首先，业务敏捷性要求什么?这里我们会谈到IT在其中充当什么角色。其次，为什么传统的IT不能解决问题，非要引入SOA?这里会谈到传统IT所缺，而SOA承诺提供的东西。最后，SOA如何实现它的承诺?我们会讨论SOA包括哪些主要的东西，还会谈到各种相关概念同SOA的关系，澄清一些常见的关于SOA的误解。
　　业务敏捷性要求些什么
　　业务敏捷性意味着快速决定和行动，这受很多因素的影响。比如掌握的信息不够、分析论证还不充分、组织条块分割和政治气候的改变等等，但其中最复杂难办的莫过于协调和优化依赖于一大群人和一大堆信息系统来完成的各种业务活动。如果这群人各自行动，而这些计算机系统相互隔离，不能协同工作，整体上就会处于一种混乱的状态，很难达成“业务敏捷性”。当业务面临挑战，如果能够通过调整人员的活动来应对，通常业务管理阶层能够果断决策，建立新计划，改变人员的职责，快速行动。但是，当这些变化需要信息系统来配合，业务管理阶层往往无能为力，无法快速行动，一方面信息系统是由IT部门负责的，另外一方面IT系统的相应改动所需要的时间、所花费的人力物力常常超出业务方的期望值，要么时机已逝，要么得不偿失。这往往造成我们经常观察到的业务与IT之间的冲突现象：业务方作为利润中心，总是抱怨IT每年都要花很多钱，投资回报不好，也不能帮助建立战略性的竞争优势。当企业面对变化，难以快速应变，更不要说帮助业务方创新来改变业务模式，主导竞争格局。而IT方作为成本中心，往往怨恨自己没有得到应有的重视，资金不够、加班加点，可是业务人员却不懂得如何珍惜和利用IT来的快速应变，甚至是创新求变，从而进一步主导市场。
　　这里牵涉到业务和IT之间的关系，这需要从几个层面上来看。首先，业务活动是由业务人员和信息系统共同完成的，业务人员执行人工活动，比如拜访客户、输入订单和客户资料、做出商务决策等等，而信息系统执行各种活动，包括商业逻辑、业务规则、管理业务数据，提供界面连接人员和信息系统。所以IT是业务的一个重要组成部分。其次，业务方决定人工活动和自动化活动的需求，管理人工活动，但是他们往往不具备必要的技术能力来建立、维护和运营那些支持自动化活动的信息系统，这些工作被委托给自己的IT部门，和(或)外包。所以我们说，IT要服务于企业战略，为业务建立竞争优势，帮助业务快速应变和创新求变。
　　通过这些讨论我们了解到，业务敏捷性首先需要的是一个灵活的业务模式(Business Model)，业务自身不灵活，想改变却心有余而力不足，IT 再能干也是干着急。其次，需要IT的敏捷性，也就是说一个当业务改变的时候，那些自动化活动说变就变，随业务的变化而变化，花的时间少，花的人力物力也少。这种IT的灵活性，对IT的所有方面都提出了挑战，从架构、方法论、技术、产品，到过程、成熟度和管控。最后，还需要这对“冤家”之间的有效沟通与亲密合作。这很不容易，业务与IT来自两个不同的世界，看世界的方式不同，所使用的“语言”也不同。大多数时候，业务不愿意花足够的时间在 IT 上，反过来，IT也不愿意花足够的时间去理解业务。他们把更多的心思放在技术上，有时候甚至为技术而技术，忘了IT是为业务和战略服务的。
　　所以业务敏捷性在挑战业务和IT两者，他们还需要更好的协作和对齐(Business C IT alignment)。
　　从传统的 IT 向支持业务敏捷性的 IT 演进
　　《程序员》杂志的编辑朋友，特别提醒我谈谈为什么传统的IT不能支持业务敏捷性。这个问题提得很好，要从几个方面来讨论。
　　首先，传统的做法缺乏一个方法让业务和IT真正地“亲密接触”，有效地沟通、协作，让IT很好地服务业务，而IT和业务又很好地跟企业战略对齐。这里牵涉到一个重要的概念和实践，那就是企业架构(Enterprise Architecture)。大百科(Wikipedia)的解释如下：
　　Enterprise Architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction.
　　这段话的意思大致可以理解成这样：
　　企业架构是这样一种实践，它采用周密的方法来描述一个企(事)业现在和/或未来的流程、信息系统、人员、组织，以使得它们跟这个企(事)业的核心目标和战略方向对齐。
　　这个定义没有明确提到架构管控(Architecture Governance)，它也应该是企业架构实践的一部分。企业架构跟信息系统紧密相关，但它同时也跟业务的各种实践，如业务绩效管理(Business Performance Management)紧密相关。企业架构包含的东西比较多，横跨业务和 IT，包括若干子架构：业务架构(Business Architecture)，IT架构(Application Architecture、Information Architecture、、Integration Architecture、Security Architecture、Infrastructure Architecture、Operation Architecture)和架构管控(Architecture Governance)。业务架构描述业务世界，从业务领域、业务组件、业务对象，到业务服务、业务流程、业务规则等等。IT架构描述，从应用、数据、集成、安全、基础设施(包括、、网络)，到IT运营，，即概念性地讨论各种架构设计原则和目标，也清晰地描述和追踪各种架构的现状，同时还定义技术、产品和提供商的选择依据，要遵循的标准等等。架构管控定义了从角色、活动、职责，到协作、审批和监管的框架，保证有一个游规则来让这些东西真正地服务于企业的战略和目标。这种实践很有用，但还不大普遍。在SOA实践中，通常会考虑企业架构实践，通过建立企业自己的“竞争力中心”(Center of Excellence，CoE)来将企业中的各方组织在一起，有来自IT和各业务战线的高管组成的团队，他们看方向，做高层决策和把关，也有由架构师和业务经理等构成的团队，他们负责更细节的层面，确保业务驱动的技术战略和设计决策。
　　其次，传统的做法需要加强业务建模。有些企业，在业务优化和创新的各种实践中，逐渐建立起了业务流程模型。但是大多数企业对自己的业务模型仍停留在自发状态，缺乏业务方面的严谨企业架构实践。这种缺乏，带来几个问题：一是业务优化、应变和创新缺乏形式化的基础，缺乏数字化的基础，很容易靠感觉办事。这种“”应变策略，往往带来很多问题，有些时候，这些问题的原因被强加到IT的头上。二是业务和IT之间缺乏“可追溯性”(Tracability)，在将业务的需求映射到IT的时候，使用模糊的自然语言，在操作的细粒度上交流(用例，use case)，这种模糊性带来了翻译后的失真和变形。同时，细粒度的操作层次所定义的需求，受到变化的冲击大而快，应该在业务流程相关的更粗粒度、更稳定的层次上进行。这些问题最终会导致业务和IT在进行需求映射，尤其是在需求发生变化时，很难或者无法保证好的可追溯性，从而导致业务的需求无法准确地映射到IT，业务需求的变化很难被快速地定位到IT受它影响的地方，反之亦然。所以我们说，在传统实践中，业务建模这一环需要加强。没有好的业务建模和业务架构实践，业务敏捷性难以保证。
　　最后，传统模式需要引入新的IT架构范式和抽象层次。企业的业务活动/流程需要多个系统相互协作来支持，这些系统包括企业自己的，也可能来自合作伙伴和客户，甚至是互联网。如何集成它们?如何在集成的基础上，重用已有系统的能力和数据，协调它们来增值，也就是响应业务的新需求?如何让这种集成和增值发生得多快好省，说变就变?
　　首先，增加了一个新的抽象层次，就是“业务层次上的契约”，用来描述不同的业务组件(或者业务对象)之间交互的接口。在SOA环境下，也就是通常所说的“服务”，包括功能接口、服务质量(Service Level Agreement)和业务策略等。它们是用于地对业务建模，通常其粒度比技术层次上的对象或者组件接口要粗，而业务流程就是通过将这些服务编排在一起得到的。当业务流程发生变化时，有些变化通过改变服务的配置(如业务策略)来完成，有些变化通过重新组装已有服务来完成，有些变化要用到现有服务之外的业务功能，则需要外购或者开发少量新服务，然后重新组装。
　　业务组件化建模所得到的服务模型，解耦了业务架构和IT架构，提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性，即在服务定义不变的情况下，业务和IT可以独立地演变，带来很好的灵活性。这种粗粒度的服务契约，将为人工活动和自动化活动，并进一步递次分解、影射到IT世界的组件和接口。所以SOA跟OO、CBD等过去的技术是包容和利用的关系，而不是取代的关系。
　　过去，服务和业务流程表现为一行行代码，隐于其中;新的抽象层次将服务和流程显式化，通过基于标准的声明式方式，来形式化地描述业务模型。这不仅仅为业务和IT的沟通奠定了一个好的基础，也为企业架构实践提供了一个好的基础;解耦业务和IT得到的灵活性，还为业务优化、应变和创新带来形式化、数量化、可模拟的基础。如“业务绩效管理”(Business Performance Management)以及“业务活动监控”(Business Activity Monitoring)。这里的重点是标准化，业务模型元素的显式化声明以及业务和IT的解耦与变化时的可追溯性。另外，一个很重要的事情是建立高质量的业务模型，它确保服务的稳定性、可组装能力、安全、服务质量、策略的保证、同企业目标和战略的对齐，而这些牵涉到管控问题，也就是“SOA Governance”。
　　这个抽象层次需要具体技术实现形式的支持，它需要最大程度的标准化和接受程度来跨越异构技术环境的边界，有赖于互联网的发展和普遍接受。Web服务成为理想选择，因为它能够真正地做到“平台无关”。过去，CORBA 等技术拥有类似的设计原则，但无法真正地做到异构兼容，从而失败。
　　这个新的抽象层次，同时带来了方法论上的改变。在SOA中，当我们启动一个项目，我们将首先从业务建模入手，通过对业务进行分析，来得到服务模型、流程定义等。通常，采用领域模型分析方法，对业务组件化，标识服务，定义服务的描述细节，检测服务是否符合业务人员的期望值，是否服务于企业的战略和目标。经过这个业务层次的建模过程之后，我们转向技术层次，也就是服务和流程的实现。如果我们没有什么遗留系统，一切是从头开始的一个应用，事情将很简单，我们会采用已有的方法论和技术来设计这些服务。比如一种可能的做法是，我们为每个服务建立它的用例，通过分析所有服务的用例，进入子系统和组件设计，然后是类和对象级别的分析与设计。但如果我们已经有了很多应用，这个时候，就可能需要多做一些事情。如果一个系统包含了业务建模中出现的某个(些)服务所需要的功能或者数据，我们怎么办?当然不能扔掉或者视而不见，我们需要重用它们，也就是要集成它们，所以我们开始面临一个企业整合的问题(应用、数据、安全等)。这就引出了集成架构的问题，请看下面关于集成架构的讨论。
　　一个新的集成架构负责将遗留系统和(或)新建的系统连通起来，让不同技术世界的服务组件可以相互以Web服务接口为中介来松散耦合地交互，这牵涉到各种协议、API、消息格式的转换、服务端点的发现和绑定、消息的路由、服务质量的保证、服务策略的实施等等。SOA继承了过去EAI (Enterprise Application Integration)和MOM(Message Oriented Middleware)的最佳实践，比如“企业服务总线”(Enterprise Service Bus，ESB)作为一种架构风格元素，用于在分布式环境下提供松散耦合的集成基础，但是SOA使用了Web服务，建立在标准和开放技术的基础上，而不是私有的技术、标准和方式。新的集成架构还引入Service Registry，ESB与之合作提供服务的动态发现和绑定。ESB的实现通常会利用已有的消息。
　　另外，在SOA的实践中，通常会创建一个数据服务层。而这通常会集成EII(Enterprise Information Integration)的技术和最佳实践，不过也会建立在Web服务等标准和开放技术的基础上。
　　这个集成架构，要确保所有服务和应用在开发之时，能够跟其他的应用和服务，不管它们今天是否存在，互联互通、相互集成，也就是“开发即集成”。
　　我们这里继续前面关于方法论的讨论。由于SOA架构范式提供了ESB这样一种架构元素来支持一个基于服务的分布式集成架构，我们需要以这个它为基础来设计一些集成用的IT组件，来将我们需要重用的数据和能力从已有的系统中“引”出来，你可以采用任何你所熟悉的技术和方式，不过大多数情况下存在标准的做法，也就是Connector和Adapter。值得提醒的是，这里有一个很重要的设计原则就是ESB是基于“服务”的分布式集成，我观察到很多基于“细粒度”的接口和消息集成，这是不符合SOA的设计原则的，也将导致可能的性能问题。实现时，通过购买支持ESB和Service Registry的产品，奠定基于服务集成的架构基础，然后，购买或者开发自己的Connector/Adapter来将各种应用连通起来，将功能和处理能力引出来。到此为止，我们有了：(1)业务建模而来的服务模型(2)对需要从头实现的服务，我们有了IT层次上的子系统、组件和对象模型(注意：这是一种可能的IT模型而已)(3)对于那些要重用已有系统功能或者数据的服务，我们有了Connector/Adapter来将需要的能力引出，如果它们并非恰好是我们所需要的，我们还需要进行IT组件的设计，这跟从头实现新服务是类似的(4)有了将分布的系统起来，基于服务来整合的集成架构。所以，我们需要开始转向实现。这就引出了应用平台的问题。
　　而在应用架构方面，新的SOA技术和标准，比如SCA/SDO允许你采用平台和语言相关的方式实现，但是组件实现的服务接口则是标准化的。复合应用(Composite Application)建立在其他应用的基础上，通过将来自Portal应用的人工活动、的合作伙伴应用、数据服务和本地业务服务来快速形成新应用。基于BPEL等标准的流程引擎，使用“声明式”的方式来将服务编排在一起，在复合应用中起着重要的作用。这些都是在已有的应用平台上增加而来，比如IBM的WebSphere Process Server支持SCA/SDO和BPEL，它是在IBM的J2EE服务器WebSphere Application Server的基础上实现的。
　　我们前面所设计的服务，实现它们的IT组件就表现为一些SCA组件，或者EJB、POJO组件，而业务流程则在IT层次上实现为BPEL或者一些SCA组件。这些服务和流程都有自己基于标准的形式化描述，保存在服务注册库(Service Registry)中。
　　最后，SOA Governance被用来在整个服务的生命中期中，将来自业务和IT的人协调起来，让他们各司其职，有规可循，相互协作来分析和定义服务，创建、组装和部署服务，运行和管理服务，监控和优化服务等。
　　在实现层面，这通常需要借助于Service Registry来管理服务的生命周期，同时，我们需要扩展现有的管理产品，从基础设施、应用和组件的管理，延伸到服务、流程和业务活动和业务绩效的管理。在这个基础上，建立数字化的服务和流程优化策略，从而使得IT可以主动地向业务提供业务优化和调整的支持。
　　SOA小结和概念澄清
　　谈到这里，相信读者对SOA的目的和它相关的一些概念更清楚了，简单总结一下。业务敏捷性需要一个灵活的业务模型，这需要一个灵活的IT来支持。同时，良好的业务建模，IT与业务之间的对齐和互动变得很重要，所以基于企业架构的实践，横贯业务和技术的SOA管控被用来保证SOA转型的成功。一个灵活的IT需要遵循必要的设计原则，比如关注点分离、松散耦合，而这些设计原则结合具体技术形式体现在IT架构中，将会形成自己的架构风格，这当然也由一些架构元素支撑，比如ESB，服务注册库等。这些架构元素多多少少都能够从过去的IT当中找到些影子，但是，它们使用新技术，建构在开放标准和技术的基础上，融合和继承了过去的实践成果。
　　下面简单地谈谈一些常见的误解。
　　SOA = ESB
　　ESB只是SOA架构中的一个元素，负责转换、路由和服务质量等。看待SOA，应该从业务、技术、管控等不同的角度来看待。
　　SOA = Web Service
　　Web Service通常指基于SOAP/HTTP的Web服务，这些服务是实现SOA中所定义服务的一种技术形式。Web Service提供了分布式环境下卓越的互操作能力。
　　我的系统都是新系统，SOA没有用武之地
　　答案应该是“有”，如果你希望得到业务敏捷性的话。SOA通过更好地让IT和业务融合在一起，借助于企业架构、业务建模、SOA监管和一些新的设计原则，架构风格，支持这些原则和风格的最新技术来达成IT的灵活性，以支持业务敏捷性。
　　SOA与BPM是一回事
　　BPM与SOA关系紧密，但并非一件事。BPM 的目的是业务优化，这种优化需要IT的支持，SOA提供很好的支持。另外，BPM在业务建模和业务规则方面为SOA提供很好的支持，为SOA达成业务敏捷性带来良好的基础。
　　SOA对您意味着什么
　　SOA作为IT的一个大的变化，业务驱动的价值诉求，非常清晰。通过总结和继承过去IT实践的成败得失，SOA将其首要目位为业务敏捷性，即通过建设一个灵活的IT来帮助业务快速应变，引领创新。
　　所以SOA对业务人员、管理阶层是一个值得注意并且很有吸引力的事，但如何获得?这需要业务和IT共舞，也需要认真建立业务模型，实践企业架构，这种转变是文化上的，对于企业来说，开始之时，并不容易。
　　对IT主管而言，SOA是一个好机会。建立IT的战略地位，通过IT帮助企业建立战略性竞争优势是IT人员马上就可以去做的，但是如何实践企业架构，如何建立SOA管控，如何通过SOA Center of Excellence来组织人员，培养种子力量将是IT主管要面临的挑战。
　　对于架构师，需要了解SOA的设计原则、架构风格、架构元素和相关技术和产品。他们需要配合IT主管，推动企业架构实践和SOA管控，跟业务人员共同合作，推动SOA项目。
　　对于开发人员，学习和使用SOA，是趋势使然，即需要学习新技术，也需要增加一点架构的意识，还需要培养自己的业务建模能力。
　　SOA对ISV可能意味着一个好机会，就是如何将自己对一个行业的理解转化为一个比较通用的业务模型和服务模型，通过可重用的软件资产，建立面向行业的解决模板与复合应用。当然，他们也可以进一步通过 (Software as a Service)来提供服务和复合应用，从而拓展业务流程外包的机会。
　　SOA是一个很大的题目，这里挂一漏万，如果需要系统性地了解SOA，我推荐IBM developerWorks的架构专区和SOA/Web Service专区，非常详尽和系统，而且很多人来自IBM之外。
　　参考文献
　　http://www-/software/solutions/soa/
　　http://www-/software/sw-bycategory/subcategory/SW920.html
　　/soa_specialoffer
　　http://www-/developerworks/webservices
　　http://www-/developerworks/architecture/library/ar-eaoverview/
　　http://www-/developerworks/architecture/library/ar-baoverview/index.html
　　http://www-/developerworks/architecture/library/ar-iaoverview/
　　http://www.proxyhub.co.uk/index.php?q=uggc%3A%2F%2Fra.jvxvcrqvn.bet%2Fjvxv%2FVG_Nepuvgrpgher_Pbasreraprf
　　http://www.proxyhub.co.uk/index.php?hl=&q=uggc%3A%2F%2Fra.jvxvcrqvn.bet%2Fjvxv%2FRagrecevfr_nepuvgrpgher
　　Enterprise Application Integration, William A. Ruh
　　Enterprise Interation, Beth Gold-Bernstein, William Ruh, ISBN 0-321-22390-X
　　Next Generation Application Integration, David S. Linthicum, ISBN 0-201-84456-7
　　Achieving Agility: BPM Delivers Business Agility Through New Management Practices 11 April 2006 Janelle B. Hill Michael James Melenovsky
　　Achieving Business Agility with SOA: Governance & SLA Management of Shared Service Ecosystems，Annie W. Shum & Jeffrey P. Buzen
　　Jean Faget, W4, F Mike Marin, FileNET, USA; Patrick Mégard, ILOG, F Vincent J. Owens, Cap Gemini Ernst & Young, United K Laurent Tarin, ILOG, France, Business Processes and Business Rules: Business Agility Becomes Real
[ 责任编辑：李健 ]
去年，手机江湖里的竞争格局还是…
甲骨文的云战略已经完成第一阶段…
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。
微信扫一扫
关注Chinabyte