这段时间看了不少的文章都是关于 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 中的想法产生了共鸣才有了这么多费话，其他的感触将在后续的随笔中写到。写这篇文章也是为了提醒自己开发的时候一定要从实际出发，一切的灵感都是来源于实践的。

 

在现在的应用系统中几乎都能看到xml和database的身影,与这两个东西正交的是OO.

• XML <==> OO 影射的东西有很多,一般都是使用marshaller架构.

 

(这里不说用于xml解析的dom和sax模型,只是说xml与pojo的影射关系:)其实再怎么影射也是通过dom或者sax接口的实现进行解析的,还是通过新的javaSE规范Streaming API for XML (StAX), xml和OO的影射只不过进行了抽象封装,把xml到pojo之间的解析部分透明化了,我们这里实际说的其实是JavaEE5.0中一个新的规范Java Architecture for XML Binding (JAXB))

比较有名的框架有:

+ castor 比较有名的一个O/X影射框架,可以根据xsd生成解析框架.(个人比较喜欢使用她)

+ apache 的xmlbean和Commons-Digester(不知道为什么会存在两个同样领域的东西,可能是digester相对来说比较简单,因而它被许多的apache的开源项目使用);

+ JAXB 是JAVAEE中的对于xml和OO对象Binding定制的新的规范(标准阿!);

实际要研究xml和OO的影射框架,大家不妨看看现有的web service框架就会了解很多了,建议看Codehaus的 XFire 他是一个比较轻量级的WS框架,AXIS2也不错.

我了解的XML Binding框架就这么多,如果谁知道更好用的可以告诉我,相您请教.

• 对于O/R mapping 就不用太说了,大家了解的可能都比我多,个人只用过一下几个:

+ hibernate ,ibatis ,jdo ,castor jdo(期待EJB3.0种的Persistence规范JPA)对于这几种框架的介绍就不说明了,google一下会出来无数.

 

?这里不是想讨论两种技术,而是想听大家对XML到database的影射有什么更好的办法,因为O/X,O/R都有很好的框架了,是否有X/R的好的框架.

这里我只知道castor 中对从xml到database有一定的支持,但支持的还是不够,hibernate3.0种好象对xml到database进行了支持,但是也是一些简单的支持.

不断整理中。。。

   这几天在研究框架架高层次的抽象问题，还有框架的一些集成问题，可能要没时间维护Blog；框架的初期版本已经开发完毕了，在几次初期的使用中，反映还是不错的，真是高兴。但是还有很多不足的地方，下一阶段对框架的开发，主要就是在调试和测试方面。

       JBrain框架的设计的初期目的就是要提供一个基本的企业级运行环境，就好比JVM一样。而下一期开发的目标就是在JBrain框架的这一个运行环境的基础上，开发一套建模语言，而JBrain框架就是这种模型语言的运行环境。

       我们为了这个目标都在研究MDA，个人觉得MDA的思想是 “ Perfection”，但是实现他谈何容易，我们研究它只是研究它的思想，通过这种思想，能够给我们以启发。
   

   再一次的看设计模式的时候，感觉自己对设计模式，有了一个进一步的理解（自我感觉的J）.

       在数学计算中我们要求AàB点的最短路径，可能从A点到B点有很多种走法，但是追求完美的我们（尤其是程序员），总是希望找到一条最短的路径。设计模式也是相同，在设计中我们想要找到设计中的最短路径，也就是设计的永恒之道（就是设计模式中常说的无名的质），说白了，就是如何设计才能使系统更容易扩张，更灵活，更稳定。模式追求的是一种最佳的解决方案，在这个方案的指导下，我们能够跟好的去实现我们所想要实现的东西。

       数学计算的时候有一定的法则，软件设计的时候也是有一定的法则的，而这些法则，都是在追求软件设计的守恒定律时形成的——什么开/闭原则，面向接口原则，依赖倒置原则等等，但是软件设计中的原则也是可变的，而且是时刻发展的，要不然就不会出现，今天的spring非常火的场面，Ioc原则。

       数学计算是通过许多的公式推倒出结果的，但是我们求解的时候，会出现这种情况，C结果，是通过A和B两个公式推导出来的，模式也是一样，有一些较小的模式，而这些较小的模式是一些较大的模式的基础。

       在理解模式的时候我们可以从对象的生命周期来理解。

       对象产生的时候需要描述对象的属性，它的存在形式，创建模式就是用来描述这个的；而这个对象存在就会和其他对象发生联系，就会和其他对象发生作用，如何描述他们之间的联系和作用就是结构模式要做的事了；前面这些都是静态的，对象的存在，不可能永远静止不动的，它会根据自己的需要，完成一些动作，语言中还有动词，名词，形容词之分呢！模式就跟语言一样需要有动词来描述对象，行为模式就是用来描述对象的行动的；

       设计模式，实际就是一种设计中的语言，很多的最基本的模式，就是组成这种语言的基础，我们在理解模式的时候不能只是背模式，而应该灵活的运用他们，让他们有机的结合在一起，形成一个生动的句子。这个就好比我们学英语，不是光背一些单词，就能写出一篇好文章的，还需要我们有语感，理解了以后才能写出来。

       这个只是我对模式的一点点个人的理解，不代表所有人的观点！：）