2.4 SCA/SDO规范与实现

　　就在我搁置对于SOA的研究有半年之久的时候，忽然打开互联网，发现SOA已经有标准了，那就是刚露头角的SCA（ Service Component Architecture ）和SDO（ Service Data Object ）。因此，在SOA有何不同的论述中，我尤其强调了SOA注重标准和规范这一事实。

　　SCA

　　SCA是一个SOA的编程模型，就好比JSP是Web开发的一个编程模型一样，Web是一种架构模式，而SOA亦然。SCA有很多部分组成，核心理念是 1）将业务功能作为一系列的服务而提供）将这一系列的服务组装起来。SCA致力于创建服务组件，以及解决各服务组件间的多技术互访问题。 SCA 的核心工件是组件Component）。

　　如果想要问 SCA 与其他诸如JMS、CORBA这样的编程模型有何不同，我觉得IBM的Barcia和Brent给了我们最好的答案：SCA向您提供一个以与技术无关的方式定义接口、实现和引用的模型，从而使您能够将这些元素绑定到所选择的某一技术的特定实现。

　　OK ，当我们谈及组件或对象时，无非要涉及这么几个抽象关注点（如果你认同每个实组件或对象都要将接口与实现分离的话）：其接口是什么，实现是什么，以及其依赖了什么（依赖的组件或对象当然又包含接口和实现）。SCA则把关注点分离发挥到了极致，接口，实现，以及引用都是可选的。如图2.4-1 所示。

　　图 2.4-1 SCA组件模型

　　于是在SCA规范中5 ， SCA当前支持接口类型系统包括：Java interfaces和WSDL（WSDL 1.1 portTypes和WSDL 2.0 interfaces ）

　　而对于实现，则可以包括Java、C++、BPEL流程、Web Service以及SCA Composite 。在IBM WID中可以选择实现（ generating implements ）为Java、Web Service、Process、State Machine、Rule、Human Task等。 Process、State Machine（特定的Process）由BPEL 技术支持。

　　当SCA模块（在SCA规范中即Composite ，在IBM的产品中被称为Module）被导出（作为服务），或者需要导入其他服务时， SCA 中还可以指定要访问服务使用的机制是什么。这是通过Binding实现的。由于导入、导出都是抽象概念，因此需要绑定通讯机制。

　　通过Binding，来指出想要调用服务和服务被调用时的访问机制，包括SCA、JCA、Web Service、JMS、无状态会话 bean 等。

　　OK、接口、实现、Binding、引用、全是独立变化、自由组合的、全面的灵活、与技术无关。前所未有，这就是SCA 。

　　在IBM的实现版本中，可以借助WID ，很方便的开发SCA程序，并且提供了很多便利的扩展。比如谈及实现问题时，IBM提供的诸如 Process、State Machine之类的实现类型。

　　SDO

　　SDO是一个数据应用系统开发框架，它包括架构和API 。它在SOA系统中充当抽象数据。

　　SCA规定了怎样编写SOA程序，组件、服务、引用等都是如何定义的，以及它们之间如何通讯，而且还规定了如何传递数据，数据的类型可以有很多种，但是首选SDO 。

　　那么SDO又是如何超越以往任何技术或规范实现技术中立、平台无关的呢？没什么令人惊奇的，做到这些无非就是增加中介和中间层次，将不同的关注点隔离。SDO客户端通过SDO框架工作在SDO数据图（Data Graph）之上。数据图中包含多个数据对象和改变摘要（Change Summary）。 DMS（数据中介服务）访问数据源，即DMS负责从数据源创建数据图，并且基于对数据图的改变更新数据源。

　　如果想要更新 SDO 数据，将如何做呢？首先SDO客户端（即SDO应用）遍历数据图，修改其中的数据对象，然后将修改的数据图传回 DMS ，然后 DMS 根据修改的数据图更新数据源。

　　可以看出，正是由于有了数据图和数据中介服务这两个隔离，才将具体的数据源与SDO应用分离开，而由SDO框架来做出相应的转换。

　　IBM对SDO进行了扩展，就是所谓的BO（Business Object）。

　　阅读和理解规范，并且与具体的实现产品联系起来，可以更好的理解 SOA思想。

　　BPEL

　　BPEL是用来编排流程服务的规范，这里的服务技术是WS*-堆栈的Web Service 。 BPEL 规范中详细的定义了如何引入Web Service ，其中包含的各种活动（诸如Invoke、IF、Scope等）以及如何建立引用。在规范中，对于引用的其他服务称为Partner，可以看出，这样的说法更贴近于业务层次。

　　正是由于SCA、SDO这样的将抽象发挥到极致的规范，使得我们可以按照CBM 、SOMA方法来设计SOA系统。我想使用一下WID来进行SOA系统的开发，将使你更容易体会我想说的内容。可见SCA和SDO中规定的组件、服务、接口、数据对象以及 BPEL 中提到的活动，与之前CBM 、SOMA 方法中提到的组件，业务服务、接口、数据对象和活动，是非常吻合的，而且这是一个前后照应，完整的方法体系。

　　小结

　　写到这，似乎可以将理论和实践、规范和实现联系起来了，再强调一次，SOA的思维是从企业业务出发，甚至是企业战略出发，来考虑服务和组件，而不是从远程方法调用（RPC），消息服务，或者是分布式对象（EJB等）的角度去考虑服务。

　　SOA不只是EAI ，这句话的另一个意思是，SOA包含EAI的部分。前文我提到了，通过BPEL和SCA Composite这样的技术，我们可以实现系统的集成，企业是流程驱动的，流程是由业务组件组成的，那么我们就可以通过 BPEL 将服务组合起来，或者通过SCA将服务组装起来（SCA的基本理念之一）。那么，还要ESB干嘛？ESB在哪？

　　2.5 ESB在哪？

　　ESB（Enterprise Service Bus，企业服务总线）继承了EAI的思想。我不必重复讲解Hub/Spoke和Bus这两种拓扑结构。因此，ESB的出现是为了解决集成问题。

　　ESB是SOA的一种实现模式，任何接入ESB的应用都将封装为服务的形式，其核心是个中介流（在IBM Websphere ESB（WESB）中是通过策略 SCA/SDO实现的中介流组件），可以在其中设计消息路由，然后由其来完成消息的路由，格式、协议的转换 / 翻译，以及消息的分发。消息路由当然是要按照业务逻辑来设计。两个系统（包括但不限于异构系统）需要进行通讯难道不是因为业务逻辑的需要？这其中的业务逻辑就包括了业务规则和业务流程，不过也有可能就是某个业务需求，需要对两个系统进行消息转换。

　　可以简单的说，SCA+BPEL就可以代替ESB的存在BPEL可以充当中介流，只不过它更为强大（尤其是IBM将SCA作为WESB的编程模型之后，这进一步模糊了直接使用SCA和使用ESB的界限，如果说状态机是Process的一个特定实现，那么WESB就是SCA的一个特定实现了）。但是如果仅仅是想做EAI，或者尝试用SOA的方式做EAI，而不是如我前文所讲，采用一套完整的、从业务到IT的水到渠成式的SOA解决方案，则采用SCA+BPEL会面临更加复杂的学习曲线，虽然我认为它是更好的实现。

　　3 BPM与SOA互动

　　BPM是从BPR（业务流程重组）发展而来，在大型的企业中，想要实施ERP（企业资源计划）往往都要经历一个BPR的过程，然而想要一蹴而就的BPR很难在大型企业中实现。预先看不到一点好处的改革将会受到巨大的阻挠，因此，一个更好的方式，先将企业的流程监管起来，发现流程运转中的问题，或者那些大幅度创造价值的热区，然后在对业务活动扬长避短，以提高企业的效率。那么，如果才能有效的监管流程呢？答案当然是数字化业务流程，还记得CBM方法论吗？我们需要一套从执行到控制再到战略的、互相沟通的组件。然后在组件之上设定KPI和特别事件（执行时间和成本，资源等待时间和成本，角色/人员等）的属性。当企业正常运转时，我们就可以从现场直接搜集到第一手资料，进行企业的监控了。然后根据监控结果进行流程优化。优化后再监控，再根据新的结果优化，如此反复。

　　这里就存在两个问题，一个问题是KPI如何得来；第二个问题，当发现了问题，并且找到了优化方案后，IT如何能够快速的随需而变。以下两节将解决这两个问题。

　　3.1 企业价值树模型

　　企业价值树可以帮助我们从企业战略到业务流程KPI的推导，当然，这不是数学，严谨的推导是不可能的。我们可以先从企业战略主题出发，然后由主题发现企业关键绩效指标，然后在寻找影响这些企业关键绩效指标的核心驱动流程，最终推导出流程的关键绩效指标（KPI）。

　　不得不说，详细完整的CBM方法论应该包括这个部分，但是这一方面大概是IBM内部的机密，因此我们只能通过引入其他的模型来解决问题。

　　3.2 SOA帮助企业数字化BPM

　　从CBM方法论我们可以看到（你可以回顾本文的相应章节），其核心的业务组件模型包括了活动、资源等，我们也提到过，业务组件是从业务流程中归纳出来的，它们是一个互动的关系。

　　从概览部分你可以了解到JPort团队做了哪些工作，这些工作连起来就是为了利用SOA帮助企业数字化BPM 。

　　SOA的方法论支持BPM中需要监控业务组件的需求，因为SOA的服务是由业务组件来实现的。另外，SOA也可以满足随需应变的业务要求，就像领域驱动建模一样，基于业务建立的模型，神奇的可以随业务更好的变化。SOA的方法论可以完整的更好的以这种方式建模，就像本文始终所演示的那样。

　　4 结论

　　采用SOA方法论一定要站在企业的角度去思考问题，具体的、可操作的方法就是CBM，更重要的是其中蕴含的思想。首先要了解企业的战略是什么，根据战略再来了解企业的业务，可以通过业务流程建模软件模拟企业流程，分析企业问题。然后俯视整个企业，设计出业务组件模型，并暴露服务。接下来在通过SOMA方法识别出所有的服务，之后再考虑服务规约，数据对象模型的设计。最后，才是决策实现的方式，复用遗留系统的功能，引入第三方服务，还是自行开发。当然并非所有的企业应用都有必要采用这样的步骤，比如只是一个新的功能，可以不妨以SOA的思想来开发这个新功能，关键是要为企业提供合理的ROI。

　　新的SOA编程模型SCA，与过去的众多用于SOA实现技术相结合，使得SOA的思想可以更好的实现，比如复用遗留系统，Web Service不再是不二法门，诸如无状态会话Bean 、JMS之类的应用，亦可无缝的连接到SOA系统之中。SDO也增加了更多的抽象层次，其目标也更为宏大，这与JDO等目标不同。

　　SOA和BPM结合起来，使得SOA找到了新的务实方向，对于企业信息系统而言是大有裨益的。

　　当然，本文主要是从IBM、BEA、Oracle、SAP、JBoss、Sun等这些Java世界的领导者的视角来看待SOA ，以它们的产品和理论为基础，然而不得不说Microsoft有其自己的一套产品和理念，但是，其根本的SOA理论是一致的：以企业为圆点，高度抽象，关注点分离，技术中立，平台无关；另外，就是其亦看中与业务流程管理的整合。毕竟，微软是BPEL的缔造者之一。

　　一种务实的精神是，开发那些真正为企业创造价值的系统，如果某个业务单元本身就是低效和没有价值的，我们是不是可以考虑一下改变它的运作模式？