这段时间看了不少的文章都是关于 SCA 与 OSGi 之间比较的。且不论他们之间到底有没有关系，我们来看看他们的定义

SCA

       服务构件架构 (Service Component Architecture) 是一套规范，它描述了采用面向服务的体系结构来搭建应用和系统时的模型。 SCA 扩展并完善了以前实现服务的方法，并且 SCA 构建在开放的标准之上，

例如： Web Service

服务构件架构 SCA （ Service Component Architecture ）为建设基于面向服务的体系结构的应用和系统提供了一种编程模型。这基于一种观点，即业务功能以一系列服务的形式被对外提供出来，然后它们被组合在一起去实现满足特定业务需求的解决方案。这些复合的应用，可以包含专门为此应用程序创建的新服务，也可以包含来自已有的系统和应用程序的业务功能，重复利用就像其中的一部分一样。 SCA 即为组合服务提供了模型，也为服务构件的创建，包括在 SCA 组装中重用已有应用系统的功能提供了模型。

 

OSGi

       OSGi 是什么， OSGi 是一种服务运行平台。通过实现能够提供服务的符合 OSGi 规范的组件，用户可以将其组件发布到 OSGi 运行平台，供用户和其他组件使用。 OSGi 组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为 Java 接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。

 

从概念看我们可以很快发现他们的相同点和不同点。

         他们都是一种组件模型，而且是面向服务的编成模型，都对服务组件模型作了相应的定义。在两种模型中都有“模块”，“组件”，“服务”这 3 种共同的概念。我们分别从这三种感念来看看他们之间的差别

模块：

         可能 OSGi 对于模块的概念定义的更完善一点，支持模块的动态更新和依赖，而 SCA 对于模块的概念中没有涉及动态更新的概念 ( 实际如果把 SCA 中的模块映射到 JEE 中的 EAR 块就可以做到了 ) ，对于模块间依赖关系的定义也没有 OSGi 中 Export/import 定义的完美，对于一个包的引用，要存在 2 个不同的副本，至少 WPS （ IBM 中 SCA 的实现）中是这样。所以说模块的定义 OSGi 要比 SCA 要完善，实际上这样是两种模型出发点是完全不同的， OSGi 设计之初主要是面向网络设备的，最后被 Eclipse 所采用才为大家所知的，而 SCA 从一开始就是面向企业级应用的，所以这方面没有 OSGi 定义的完善。模块的定义 OSGi 是在 MANIFEST.MF 文件中通过元数据定义的，而 SCA 是在 sca.module 文件中定义的 xml 格式。从这点上我们就可以看出来， OSGi 只能是在 java 平台上（他的规范中说明也是只适合 java 平台的，规范的 0layer 定义了它的最小 runtime ），而 SCA 是一种跨平台的规范，它不依赖于平台，你可以是 Java 环境也可以 C++ 环境。

 

         对于组件的概念，个人感觉 OSGi 是在 DS （ OSGI R4 的 Declarative Services ）出来以后才有了比较定性的定义，而 SCA 从一开始就非常强调组件的定义，对于 SCA 组件可以是一个 webservice ，一个 java 对象，一个有限状态机中的规则对象，也可以是一个 BPEL 流程对象，还可以一个人工干预的工作流对象，更可以是许多组件的组合对象，这一点 OSGi 组件是做不到，也不要想 OSGi 能够做到，因为他们的设计出发点根本是不同的，不要把企业级应用的东西强加到 OSGi 中来，在 OSGi 中的组件可以发布 / 查找服务， SCA 也可以这么做，对于服务的引用， OSGi 只能是在 single JVM 中，不要怪 OSGi 要知道他当初设计的目标就是网络设备，不用考虑企业级应用中的分布式，服务质量什么的。但是组件概念上 SCA 有一点还是弱于 OSGi ， OSGi 对服务的引用可以做到动态更新，一个服务改变了，它可以动态的或者是静态的更新应用它服务的组件对象，这一点在网络设备中是非常重要的，但是在 SCA 这种企业级应用中到底需不许多要我们还需要考虑，毕竟如果我们是面向接口编成，而不用关心细节是什么，你的服务再怎么更新，只要我们的接口不变就不会用什么问题。

         而服务，最大的差别可能就是 OSGi 是在 single JVM 内的所以对于服务的引用永远都是直接的内存引用吧，而 SCA 在服务的引用上附加了 Binding 的概念也就多了一个协议的选择层，很象 jmx 中 distributed layer ， SCA 对于服务的 Export/Import 都需要 Binding 一个具体的实现，你的服务可以通过 WebService 来发布，也可以通过 RMI ， JMS 等等来发布。这一点是 SCA 的设计出发点来决定的（面向企业级的应用开发）。对于服务的调用，不仅仅是必须在环境内的调用，也可以在环境外进行调用，比如你在一个 JSP 页面想要调用 SCAExport 出来的服务，你就可以通过 SCA 提供的 Tools 直接调用， OSGi 是不支持环境外调用的。

 

         从以上来看 OSGi 和 SCA 除了基于同样的设计方法，其他的不具什么可以比较性，因为他们设计的根本意图上是不同的，一个是用在单一个的 JVM 中的面向网络设备或者像 Eclipse 这种应用，不需要考虑服务质量，服务的可靠性，分布式，等等。而 SCA 从诞生之初就为了解决 SOA 应用中的规范性，而且与他同级别的还有 SDO 来定义服务的数据对象，这一点也是 OSGi 中没有定义的。

         有人会说 OSGi 最近正在定义在企业级应用的规范（ EEG ）， Eclipse 的 RSP 也在做相应的努力。但是如果是在 SCA 之外另开辟出一个新的模型空间，个人觉得不太可能，毕竟 SCA 是 IBM ， BEA ， Oracle ， Sap 这些厂商在认识到许多现有技术的不足之后总结出来的设计模型，是这些厂商经验的积累，就像 OSGi 是 OSGi 组织在网络设备应用中的积累的一样，这两种技术只能出现互补性，再说 SCA 模型的定义充分体现的软件界一贯的规则“重用”，不管是 IBM 的 WPS ，还是 Apache 的 Tuscany 都是以现有平台为出发点设计的，是把 SCA 这种模型与现实技术做一定的映射，例如，如何实现异步调用就可以以借助 JEE 环境中的消息或者 Corba 中消息机制。

         真希望看到 OSGi 的 EEG 组织和 SCA 规范定制组织合作的场景。这样不仅可以让组件服务思想得到升华，还能为企业级开发开辟一个新的天地。

         以上观点纯属个人感触，不代表任何特别的言论，其实最近正打算吧原有的平台迁移到 OSGi 平台上，在研究过程中发现了许多有趣的地方。

         欢迎大家一起讨论 OSGi 和 SCA 技术。

这几天总算有点时间，可以看看手头的书了。

手头一直有本书从买来就没有翻一下——《 expert one-on-one J2EE Development without EJB 》，这几天没事翻了一下。觉得大师就是大师一上来就把我们的苦衷说的清清楚楚，还是实践出真理阿。

最让我记忆犹新的是这几句话：

 

检验一个体系结构是否合理，判断一种实现选择是否合适，都要看他是否符合这一主旋律。        主旋律是： ²        简单 ²        高产 ²        面向对象为本 ²        业务需求至上 ²        重视检验过程 ²        重视可测试性

所谓的主旋律，个人理解就是一种审美观点，就像大家看到漂亮的 MM 一样，为什么 MM 这么漂亮，因为他符合人们对漂亮的机电看法
—— 国色天香 倾城倾国 沉鱼落雁 闭月羞花 如花似玉 花容月貌 美若天仙 艳如桃李。。。反正就是美。

从设计模式角度说明主旋律，就是设计中常常遵守的几点原则——可维护性，可扩展性，可复用性，要面向接口去设计，等等。

以上这些都是从理论角度出发考虑的，而 Rod Johnson 是从实践的角度来考虑问题，大学学了点哲学原理都运用在这里了。以前在设计第一个框架的时候没有太多的考虑到程序员的实用型，只是为了设计而设计，最后把框架设计的及其复杂，最后的结果只有进行重新设计，进行框架的重构。而在设计中遇到的问题很多是 Rod 在书中描述的场景，真是深有感触阿。

²        简单

设计中常常应该遵守 2/8 原则，系统中 80% 是最长用的，应该以这 80% 为重点去设计，如果只是为了设计中的完美而过多地考虑其他的 20% 就会陷入复杂的漩涡。就拿我们现在设计的 JBrain （我们的框架代号）框架中的元数据系统来说把，本来是为了对系统中的所有元素的一个建模过程，涉及到显示模型建模，业务模型建模，数据模型建模，工作流模型建模，（这个就好比在基础框架基础上又抽象出一层），我们在建模中就是考虑到那 80% 常见的情况，对模型系统进行设计，但是每一个业务都会涉及到报表系统，这就是那 20% 的情况，如果我们再花精力去研究报表系统的建模，就会把自己带入无比复杂的深渊中，所以我们决定用这 80% 的模型建模来描述这 20% 的报表建模，这样问题就简单多了，对于报表的设计来说，虽然有点麻烦，但是我们的设计可以适应大多数的情况。实际只要我们作一些辅助的工具就可以简化报表模型的建模，这是我们在框架开发的后期发现的，经过实践证明我们当初的想法是真确的。

这种情况还出现在我们当初在做一个业务系统的时的框架选择上，当时我们为了框架能够承受更大的负载度，而考虑使用 EJB 的多层开发（幸运的是没有用实体 Bean ），这使我们的开发量整整增加的一倍，还在不考虑测试的情况下。项目结束了上线使用，用户根本没有当初设想的并发量，我们当时真的还考虑了 Rod 所说的是否能够在客户端支持 Swing 程序，幸亏后来被否定了。有时候我们在设计中总是追寻完美，为了设计而设计，这种做法正如 Rod 所说的是不科学的。

简单才是美，因为简单出现了 POJO 对象，因为简单出现了 Hibernater ，因为简单出现了 Annotation ，因为简单出现了 EJB3.0 。因为简单才是 java 的开源社区如火如荼，人声鼎沸。

 

²        高产

有时候，设计者注重的是设计，这也是我们设计中常常存在的一种习惯，程序员总是追求完美，追求 perfect ，而一个企业在完成项目中要的是生成率，要的是质量，一个功能用那种完美的框架需要 2 周的时间才能开发完，而使用简单的框架只需要 3 天的时间就可以完成了，你说我们应该使用那种框架。

去年在开发一个项目的时候，因为我们是和其他部门一起合作开发，在项目开始的调研当中，我们极力推荐使用我们的 JBrain 元数据框架，而另为一个部门却强调使用 JSF 所建立的框架（ JSF 刚出来，而且那个部门的人员还没有太多的理解 JSF 的深刻含义，他们觉得 JSF 非常好，非常的完美），最后因为我们的框架是黑盒的，客户不想把他们的项目绑死在我们的框架上，所以最后决定使用 JSF 来设计框架（不说开发一个企业级框架所需要的时间），这里我不是说 JSF 不好，我研究过 JSF ，觉得他的设计哲学真的很好，尤其他的组件树和生命周期设计的非常完美，尤其他的 Render 机制，真的就是我们以前在使用 jsp Tag 的时候一直想要又没有的功能（我们框架中的显示模型有很多思想是从他的组件数概念而来的），但是如果用 jsf 开发企业级程序，而且是在国内这种客户要求非常苛刻的情况下是非常不足的。因为我们的 JSF 框架是在 Apache 的 MyFace 基础上开发的，实际上后来他的标签我们没有用多少，大部分都是我们自己在他的基础上重新开发的。后来框架设计出来了，生产率太低，完成一个工作需要做很多很多的事，我实在看不下去了，看着我周边的同事一边又一边的叹气（而且项目结束前几乎是天天加班到 9 点），根据我们原有框架的元数据原理，写了一个 JSF 框架的代码生成机，这才把生产率稍微提上了一点。

实际有时候我们设计框架的时候不必要考虑过多，一定要从开发和实用的角度去考虑，多考虑一下程序员的工作方式。

 

       今天就写到这里，可能是和 Rod 的 Without EJB 中的想法产生了共鸣才有了这么多费话，其他的感触将在后续的随笔中写到。写这篇文章也是为了提醒自己开发的时候一定要从实际出发，一切的灵感都是来源于实践的。