基于Spring-DM实现分布式服务框架(DSF)(一)

最新推荐文章于 2021-06-15 18:09:20 发布

autoinspired

最新推荐文章于 2021-06-15 18:09:20 发布

阅读量3.1k

点赞数

分类专栏：架构文章标签：服务框架 osgi spring service webservice osgi框架

架构专栏收录该内容

1 篇文章 0 订阅

订阅专栏

基于Spring-DM实现分布式服务框架(DSF)(一)

发布时间:2008年01月29日作者:BlueDavy

阅读次数:448次类别:OSGi、SCA 永久链接 Trackback

经过上篇分析分布式服务框架的blog后，正式对之前的基于OSGi实现分布式服务框架的系列改名(顺便把分布式服务框架改为使用DSF缩写)，因为已经决定基于Spring-DM来实现，为什么呢，而且为什么一定要是Spring-DM，而不直接说Spring呢？
今天是Spring-DM 1.0 release的大好日子，

，不容易呀，做了这么久，具体怎么样还没来得及细看，不过之前有用过1.0 m2，已经觉得很不错了，相信1.0 release更不会失望。
在我眼里看来，Spring是个很大的东西，其实DSF需要的基础的东西并不多，但又希望保持微核性和扩展性，插件化、具备良好扩展支持的框架无疑是最佳的选择，OSGi无疑是个好的选择，但基于OSGi要自己去实现的东西实在是太多了，Spring-DM则是能满足我以上两点需求的最佳选择，既有了插件化的框架，又有了很多可用而且是很强大的东西，尤其是Spring在本地调用和远程调用的透明化提供了优秀的设计支持和指导，例如Spring提供的HessianServiceExporter、JNDIObjectFactoryBean等等，而且Spring和OSGi结合后，就可以根据需求来选择自己所需的Spring的那些增强功能了，不用每次都抱着整个巨大的Spring，当然，目前Spring还没完全剥离好，等Spring-DM 1.1后会好很多。
在之前的分析分布式服务框架的blog中，已经说到其实实现DSF简明扼要的说就是：高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力，其实这里面最重要的呢，又是强大的集成能力，为什么呢，因为呢，前两个关键点都是有挺多的可选方案的，需要根据系统运行的情况来做出不同的选择，这个时候就要求DSF具备很好的集成能力，使得可以很方便的进行不同实现方案的切换，这点Spring已经向世人证明了很多次了，鉴于这些原因Spring-DM荣幸的入选成为DSF的选择。

来看看基于之前的那篇分析分布式服务框架的blog以及选择了Spring-DM后，DSF变成什么样了：

是不是觉得和之前的DSF的图有很多的不同的地方，至于为什么会变成这样，可以去看看分析分布式服务框架的blog，不在此细说，在此会详细的介绍下目前DSF第一个版本V 0.7，也就是上图中的每个部分：
先全局的说下，仍然是分为服务应用端和服务中心，但是从图中可以看出，服务查找和调用的机制和以前的有所不同，在DSF中服务仅把其元信息直接在服务中心进行注册，此元信息会由服务中心写入分布式的缓存DB：MemcacheDB中，当服务应用端进行服务调用时，它将直接访问MemcacheDB来查找到目标服务的访问机制，然后直接和目标服务应用端进行通讯，而不经过服务中心路由，这里要稍微说下为什么采用MemcacheDB，其实就是解决DSF中所说的高效的存储、查找机制，当然，里面其实还有个细节，就是cluster的考虑，可以想想，如果目标服务的元信息是直接缓存在服务应用端的话，那么当目标服务元信息发生改变时，那通知起来是件非常麻烦的事，所以干脆找个支持cluster持久和高效缓存的东西，还好有了MemcacheDB，当然，其实你也可以根据你所面对的应用的实际需求来定，例如，你的目标服务压根就不可能存在元信息变化的现象，那完全可以直接把目标服务的元信息缓存到服务应用端(甚至这步可以在部署期直接完成)，这些等DSF做到后期版本后，可以考虑机制调整的支持，但在V 0.7中将会采用图示的方案。
经过机制的改变后，服务中心就变得非常简单了，而且压力是非常的小，它将来更多的需要承担服务的管理和监控的职责，逐步的会压力增大，这里就不去过多的讲它了，还是来看看服务应用端，其实也就是V 0.7需要干的活了：
1、服务查找
      这个服务查找就是负责和MemcacheDB通讯的了，根据服务模型进行服务的过滤查找，只是要考虑以后切换为其他查找方式(如基于分布式文件系统、服务查找后本地缓存等)的支持，由于是基于Spring-DM的，不会有什么问题。
2、发布服务
      参考Spring的ServiceExporter来实现，在V 0.7中，暂时只提供jndi的方式，jndi server采用jboss jnp，而以Hessian、Webservice的方式发布，都是Spring直接就支持的，:)，只是当服务应用端不是采用Spring实现时，需要做个集成策略的实现。
3、调用服务
      参考Spring的ObjectFactoryBean实现，由于V 0.7只有JNDI、Hessian方式，Spring已经分别提供了JNDIObjectFactoryBean和HessianProxyFactoryBean，所以这块暂时不用去考虑了。
      在后续版本中这块需要在缓存等方面多加考虑。
4、和服务应用端的集成
      在V 0.7中暂时假设服务应用端也是基于Spring的，所以就暂时不考虑集成的问题了。
OK，到此为止，剩下的两个工作就是：
1、服务元信息模型
      服务元信息模型完全参考OSGi Service。
      在V 0.7中将只支持xml方式描述服务元信息模型的注册，这里需要完成的就是将xml解析为元信息模型。
2、服务管理端
      V 0.7仅提供服务列表的查看、服务注册、元信息修改以及卸载。
V 0.7需要做的就是把DSF的架子搭好，保证好基于DSF的Scable的可行性，当然，其实service本身也是要考虑Scable的(如service操作的资源等)才行，在后续0.7-->1.0的过程中将会从细节加以改进，如支持更多的通讯协议、支持更多种服务应用端的集成、提高性能等。
Let"s move toward V 0.7！

Spring进军SOA领域

发布时间:2008年01月25日作者:BlueDavy

阅读次数:526次类别:OSGi、SCA 永久链接 Trackback

昨天刚分析完分布式服务框架，今天便看到Spring Integration 1.0 M1发布的消息，这也为Spring进军SOA领域拉开了序幕。
Spring的动作一直就颇多，其实它自己就是个非官方的标准，不过它显然更聪明，因为它基于一个强大的pojo container结合pojo enhanced机制使得它可以很容易的集成在其他领域极为专业的东西，而不是自己去竞争，更加好的是它提供的是选择，这也就使得Spring很容易的成为了最为流行的框架，而Spring和OSGi的结合更是进一步的提升了它的应用面，因为估计有很多人忌讳spring的巨大而不使用它了，至少我以前就这么选择过，选用OSGi这样的模块化框架固然是缺少了很多企业应用需求的东西的支持，但对于有些应用来讲完全可以自己去实现，但对于大而复杂的应用来说直接选用OSGi几乎是不可能的，因为要自己去实现太多的东西，还好Spring和OSGi结合在一起了。
说了这么多和标题无关的话，只是想表明Spring其实已经具备了分布式服务框架中很重要的一些因素：可插拔(这样的话完全可以根据应用的需求来搭建微小还是巨大的东西)、强大的集成能力，而且Spring本身之前就已经提供了一些分布式交互的支持，如JNDIObjectFactoryBean、HessianServiceExporter等等，回到正题，由于Spring本身就具备了这些特征，因此其实以它来实现分布式服务框架确实是个很好的选择，Spring自己果然也没浪费这样的机会，顺理成章的推出了Spring Integration。
Spring Integration是基于Message机制来达到Bean交互的，这个在上篇分析分布式服务框架的blog里已经有所提及，在服务的交互上是有多种协议可去选择的，Spring Integration选择了JMS机制，从它目前公布的例子也能看出，使用起来有点的晦涩，但是功能方面确实还不错，已经具备了分布式服务框架的整个的架子：
1、服务模型
      在Spring Integration里准确的说应该是一个供bean使用的Message Queue或Channel就是服务了。
2、服务的注册中心
      由于在Spring Integration里交互其实是通过message来完成的，因此服务的注册中心中其实只需要能提供message的地址和queue名或Topic名就可以了，这个在现在的IBMMQ Broker这样的东西是直接支持的。
      不过在目前的Spring Integration还没看到这块。
3、发布服务的方式
      源于上面服务的注册中心，其实就是发布mq server地址和queue名了。
4、查找服务和调用服务的方式
      目前由于无服务中心，没有查找这回事。
      调用服务目前是通过直接往目的地发消息来实现，当然Spring Integration已经屏蔽了调用JMS的细节。
5、服务的组装
      组装这块目前Spring Integration也没有清晰的提供。
6、稳定性和性能
      由于是基于message机制的，稳定性和性能主要就取决于MQ了。
根据这个可以看出，目前虽然是有架子了，但还是有一定的距离，不过毕竟是1.0 M1，希望等1.0 release的时候能让大家眼前一亮吧。
由于和自己想象中的分布式服务框架还是有很多的不同，因此还是继续去实现自己的分布式服务框架。

分析分布式服务框架

发布时间:2008年01月24日作者:BlueDavy

阅读次数:526次类别:OSGi、SCA 永久链接 Trackback

技术是为需求而服务的，分布式服务框架也同样如此，它不是凭空诞生的，也是因为有这样的需求才会有分布式服务框架这么样的东西诞生，在这篇blog中来详细的分析分布式服务框架诞生的原因(其实也是需要用分布式服务框架的应用场景，这里隐含的意思就是并不是什么应用都需要分布式服务框架的)、分布式服务框架需要提供的feature以及实现这些feature可选的技术方案。
其实这篇blog应该写在实现分布式服务框架系列blog之前，:)，不废话了，来看为什么会需要分布式服务框架，在一个不断发展的大型应用中，系统的业务和功能不断的增加，同时技术在不断的发展、团队在不断的变化，很容易造成的现象就是：各个子系统、模块实现的技术五花八门，部署时各子系统的方式和要求不同，各个子系统之间的交互方式和方法不统一。这种现象带来的问题就是整个系统感觉很混乱，不过技术毕竟是不断的发展，因此各子系统、模块的具体实现技术要完全限制应该是不太可能的，也没必要，但会希望系统对外提供的功能能采用统一的部署以及交互方法，这样的话每个子系统能保持其黑盒的实现方式，其他子系统不想也不需要关心它的实现方式，只需要能够统一的方式调用到它们提供的功能就可以了，这是出现的第一个需求。
起初整个应用部署在一台机器上，但随着系统的功能越来越多，不得不不断的增加机器以减轻服务器的压力，但很快就出现瓶颈，不得不把应用分层部署，这样可以撑一段时间，在撑过一段时间后发现再度出现瓶颈，于是希望能够再度的把系统进行划分，这个时候就变成了希望能够以非常细的粒度来部署了，而不是把一堆的功能都部署在同一台机器上，这样带来的好处是系统的重用性能够再度的增强，服务器的压力能够有效的降低，使得系统可以以较低的成本继续保持Scable（就像google），其实这也是ebay的演变过程，大家可以去看看那个著名的ebay架构演变的PPT，还有一篇中文的ebay是怎样炼成的。
从上面的需求场景描述中可以看出，需要分布式服务框架的场景并不是很多，这里还有一种场景没去提及，那就是对于一个大型企业而言，由于需要用到的软件多种多样，其实也是有分布式服务框架的需求的，但还是有些不同，因为要去满足那种场景的方法可以更为简单。
分析下分布式服务框架的应用场景，可以得知，分布式服务框架的诞生目的主要有两个：
1、约束需要对外提供的功能，保证其以一个统一的方式来对外提供和获取；
2、分布式的部署细粒度的功能。
在确定了这两个目的后，来详细的分析下为了达到这两个目的，需要提供些什么feature。
要约束对外提供的功能，保证以统一的方式来对外提供和获取，首先需要制定的标准是功能到底以什么方式来对外提供，这里首先诞生了服务这个很好很形象的名词，对外提供的功能其实也就是为别人提供的服务了，那么服务里到底有些什么呢，面向接口自然是首选，所以服务都以接口方式来提供，另外可能就是会有一些服务的元信息了，如服务的名称、描述、依赖、所在机器等等；接着要完成的就是如何把各子系统对外提供的功能定义成服务呢，这里要求分布式服务框架能提供强大的集成能力，例如子系统是采用spring来实现，那么就需要支持能把spring的bean直接定义成服务；定义服务完成了，这个时候要解决的问题就是其他的子系统怎么知道有这些服务的存在呢，因此需要提供一个统一的服务的注册中心，同时相应的带来的问题就是各个服务应用端怎么来查找这些服务，怎么调用这些服务，这也是分布式服务框架需要解决的，在提供了上面的这些feature后，第一个需求就可以基本实现了。
分布式的部署细粒度的功能，这个在第一个需求达成的情况下，直接就可以实现了，因为分布式服务框架对服务应用端的粒度并没有要求，可粗可细，只是分布式的部署细粒度的功能其实潜在的带来了另外的需求，那就是怎么样把这些细粒度的服务直接组装来满足业务的需求，这也是分布式服务框架应该提供的功能；同时，还要注意的一点是，当变成细粒度的分布式部署的场景时，系统的稳定性和性能是会受到影响的，对于大型应用来讲这两点偏偏又是非常重要的，分布式服务框架需要对此进行考虑。

.......................................................咖啡一杯，休息一下.......................................................

继续，上面分析完毕后产生了分布式服务框架的基本Feature，来总结看看，并同时对其进行可选的实现技术的分析：
1、服务模型
      在服务模型中需要详细定义服务模型包含了哪些信息，而这些信息也就决定了服务在发布时需要提供的信息，同时也是为服务查找和调用提供的信息。
2、服务的注册中心
      服务的注册中心在分布式服务框架中充当的就是服务信息的存储场所的作用，同时它还需要提供的一个重要的功能就是查找服务，这两个最重要功能最重要的就是稳定、高效以及支持Cluster。
      存储服务信息上可采用数据库存储、分布式文件系统存储等，查找服务需要的就是支持高效的查找，这个要根据服务的查找方法等来建立相应的缓存和索引，这里需要注意的是在cluster情况下的处理，选用数据库存储或分布式文件系统存储自然是不会有cluster的问题的。
      另外一个需要确定的就是服务应用端怎么调用服务注册中心提供的管理接口，可采用的技术有JNDI、JMS、WebService等等N多种实现方式，可以根据具体的性能要求、实现方法、需求等来进行选择。
      从扩展方面去看，服务的注册中心应该提供多种服务应用端和注册中心的交互协议的选择、扩展。
3、发布服务的方式，支持Spring、EJB3等等
      支持直接的把服务应用端的功能发布为服务，发布的方式更多的是xml、annotation等方式，就是一种很不错的设计，所以要根据服务应用端采用的技术而定，常见的如spring、EJB，这个完全根据分布式服务框架所面对的应用场景而定，如果你的服务应用端都是基于Spring的，那么就可以暂时只提供Spring的方式了。
      注册服务方面的技术基本也不用选择，因为它其实是根据服务应用端采用的技术而决定的，相当于提供一个集成的接口而已，由此接口去完成和服务中心的交互。
      但这里有个关键的实现技术需要选择，就是把服务以什么方式对外提供，例如有JNDI、Webservice、JMS等等，就像Spring中的HessianServiceExporter，这里需要的是服务框架本身支持好这些协议，至于到底要实现多少种也是根据需求来看了，而各种协议的实现可以选用协议对应的成熟产品，如jndi有jboss jnp，也可以自己根据需求实现。
      也许在spring中我们可以这么来发布service：
      <hsf:service>
              <ref bean="Spring Bean"/>
              <metainfo:jndi server="" interface="服务接口名" name="简要名称" desc="服务功能描述"/>
              
              <publish:jndi server="">
                        <property name=""></property>
              </publish:jndi>
              
              <publish:hessian server=""/>
              
              <publish:jms server="" queue=""/>
      </hsf:export>
4、查找服务和调用服务的方式，支持Spring、EJB3等等
      查找服务和调用服务方面，需要做到的就是能够让服务应用端透明的使用远程的服务，所以其实也是和服务应用端采用的技术相关的。
      当然，它本身需要提供以各种协议和服务中心通讯，以各种协议调用远端服务的支持，另外就是同步、异步的支持等，还需要从高效性去考虑。
      对于使用者来说则比较简单，也许在Spring中我们可以这么来调用远端的service：
      <bean id="loginService" class="HSFObjectFactoryBean">
              <hsf:service>
                      <import:jndi server="" interface="">
                              
                              <property name=""></property>
                      </import:jndi>
              </hsf:service>
      </bean>
5、服务的组装
      服务的组装需要提供的就是将服务中心的服务进行组装，以实现复杂的业务需求，这里面需要包括容错等等的支持，同样，高效性也是这里面的重点。
      可选用的技术有采用事件框架、jbpm等。
6、稳定性和性能
      通常来讲，需要用到分布式服务框架的应用在稳定性和性能方面都会有很高的要求，当然，稳定性更多的是通过避免Single Point的方式来提供，但同时软件层面也应该尽量避免无谓的错误，从技术角度上来讲可以采取fail-fast的思想来实现。
      性能方面，需要根据使用时的压力情况来决定，如查找服务时太慢，需要考虑提升服务中心查找服务的效率，增加索引，使用分布式存储等等都是可采用的方式，提升性能的方面其实可采用的方案是非常多的，但每种技术几乎都是需要非常专业的人才去实现的。

上面分析的feature只是分布式服务框架的基本feature了，一个强大的分布式服务框架的话实现的东西会比这个多很多(例如提供服务管理端、监控端、IDE等)，不过主要会是细节上，在具备了这些基础feature的情况下，细节就决定了高低了，:)。
分布式服务框架的引入也许会降低些性能，但应用的适当的话，则能充分发挥服务器性能，并且很大程度的降低系统Scable的成本，至于开发效率的话我不觉得是分布式服务框架需要解决的问题。
服务框架其实对于所有应用而言几乎都是需要的，而且非分布式的服务框架可选的是有很多的，但分布式服务框架可选的目前基本是没有，所以如果不是应用真的需要，没有必要去实现分布式服务框架（就像在企业应用模式里Martin Fowler讲的一样，尽量不要分布式，:)），因为分布式服务框架对于技术层面还是有挺高的要求的，说简单点呢，就是高效的存储、查找策略+高效的通讯策略+满足需求的服务模型+强大的集成能力构成了分布式服务框架的核心技术实现。

ps：在写完这篇blog后，发现自己在基于OSGi实现分布式服务框架（四）里面写OSGi不适合其实是个不准确的词，因为在服务的应用端其实是可以采用OSGi的，不过以分布式服务框架而言，OSGi是没有什么适用的场景，除了服务模型可参考外，但在服务应用端而言，OSGi仍然是个很好的选择。

基于OSGi实现分布式服务框架历程(四)

发布时间:2008年01月23日作者:BlueDavy

阅读次数:179次类别:OSGi、SCA 永久链接 Trackback

在这个篇幅中将来分析下这个分布式服务框架的服务的生命周期的管理的问题，在分布式服务框架中，支持服务的动态部署、卸载、升级是很关键的，至于服务的生命周期是否需要做到像OSGi那样的动态通知，在这个篇幅中会进行分析，并最终形成这个分布式服务框架的生命周期模型以及到目前为止的服务架构模型。
先来分析下服务的生命周期是否需要做到像OSGi DS的动态通知，这里以服务组件安装为例稍微的说下OSGi DS服务的生命周期模型，在OSGi DS中，当有新的Service Component安装时，首先会检查其是否lazy，如是lazy或此Service Component对外提供服务则完成安装，生成ServiceRegistration对象放入其服务中心；如不是lazy或此Service Component不对外提供服务，则首先检查其引用的服务是否可用，如不可用则尝试激活引用的服务，如所有引用的服务均可用，那么激活此Component，对外提供此Service，并发布Service Active的事件；服务生命周期事件管理器在接收到Service Active的事件后，将会查找所有引用此Service的Component，如Component未激活，则尝试激活，如已激活，则根据配置的bind-method注入此Active的Service Instance。
根据上面的分析，到分布式的服务应用的环境下，来看看，下图为一个典型的分布式服务应用的图示：

根据OSGi DS服务的生命周期模型，那么当我们在服务应用端部署了一个分布式服务时，此服务首先需要到服务中心进行注册，在注册时，需检查去所引用的服务是否可用，如可用，得激活此服务，同时需要将此消息发送给所有引用了此服务的服务应用端，这整个过程说起来是相当的顺畅的，但我们可以想想，如果这个服务是个基础服务，被N多服务应用端引用了，那这个时候会是个什么状况，那要通知到多少的服务器呢(可以想象100+的服务群)，尽管可以cluster+同步，:)，更复杂的情况，当此服务引用了其他N个服务，首先需要发消息尝试激活这些服务，然后那些服务激活后又带来了N个服务的激活，这个就把整个过程变得极度繁琐了，整个的实现难度和逻辑复杂度大大提升了，动态的处理生命周期的变化将会带来很大的技术难度以及不可控因素，例如在高并发的场景时某服务突然不可用了，但它的通知的消息还在传递，那结果会怎么样呢？既然这么难控制，那就干脆不去控制这种动态的变化了，简化整个生命周期模型，保证实现的简便性和系统的高稳定性，这也是实现所有系统必须遵循的原则：“简单(但不是简陋)到可控、满足需求为止”。
鉴于以上的分析，在这个分布式服务框架中将采取一种适合大型分布式应用使用的服务生命周期模型：
1、服务安装时
      当服务在应用端被安装时，首先注册其Service元信息到本地服务中心，接着判断如服务需要注册到远程服务中心，则进行注册，注册完毕后，根据服务引用的服务的信息生成相应的服务Proxy对象，注入到此服务中，同时激活服务。
2、服务卸载时
      当服务在应用端被卸载时，首先从本地服务中心中删除相应的Service元信息，如此服务注册到了远程服务中心，那么同时删除远程服务中心的Service元信息。
3、服务升级
      服务升级需要做的其实就是替换Service元信息，同时刷新classloader中的服务实例。
通过这个容易实现的服务生命周期模型可以看出，实现出来的这个分布式服务框架将会很好的支持服务的动态部署、卸载和升级，但并没有支持到服务的状态的通知等，其实也不是很必要，不过在目前的这种情况下需要解决的是调用的高效的问题，因为在不知道引用的服务的状态的情况下，最复杂的就是每次都得发起调用，这里需要有一个高效的缓存机制，以避免无谓的调用(如服务压根就不可用呀，或者服务没改变，参数也没改变的情况)，:)，这个具体怎么实现大家可以先想想，在后续的章节中会详细的介绍。
经历到目前这步后，大家会发现，OSGi在整个的分布式服务框架中开始逐步消失，确实，OSGi在分布式领域的不足(最强的DS在分布式领域非常不适合)已经让它不是很适合作为实现这种大型分布式场景应用的框架了，但这并不意味着OSGi就没什么用了，OSGi在很多应用领域仍然是王者型的框架，只有最适合的，没有最好的，:)，而且OSGi的很多思想(例如服务的模型，所以其中还是有很多DS的影子)其实也在指导着这个分布式服务框架的思想，所以即使最后这个实现的分布式服务框架和OSGi没有多大关系，也还是暂且叫着这个名字吧，来看下经历到目前这步后的分布式服务框架是个什么样子了：

从上图中可见，此框架中几乎所有的部分都是可换的，这和OSGi的microKernel思想是非常吻合的，当然，也是为了此框架能更加灵活的满足分布式应用领域的需求。

基于OSGi实现分布式服务框架历程(三)

发布时间:2008年01月22日作者:BlueDavy

阅读次数:146次类别:OSGi、SCA 永久链接 Trackback

上篇说到，经过分析后决定选用JNDI来实现服务的远程注册、查找和路由，在这篇blog中就来详细分析下基于JNDI怎么和OSGi结合来实现服务的远程注册、查找和路由。
1、远程注册
      目前OSGi DS注册时是直接在本地注册服务实例的，要支持远程注册的话首先需要修改DS注册服务部分的代码，在ds的描述中需要增加一个配置项，以支持将服务注册到远程服务中心，例如：
       <service>
             <provide interface="cn.org.osgi.opendoc.bulletin.service.WebCommand"/>
             <server>jnp://10.100.100.100:1099,jnp://10.100.100.101:3099</server>
       </service>
       在注册时直接采用InitialContext进行注册，不过这里要采取个不同的策略，就是通常jndi注册时绑定的都是实际对象的实例，但要注意，其实在分布式的服务框架体系中，服务是分布式部署的，服务中心仅仅是个注册、路由的地方而已，那么这种情况下只需要把服务的相关元信息注册到服务中心即可，所以这个时候我们会提供一个服务元信息对象，然后把这个元信息对象绑定到jndi上去，这里涉及到的一个问题是jndi的名称怎么取，这个名称要便于查找服务，同时还得保证唯一性。
       可以看出，在这个实现方案中，最重要的就是这个服务元信息对象了，这个元信息对象中应该包含和OSGi服务模型同样的所有的信息，同时还需要包括服务的状态信息，由于包含了状态信息，叫元信息对象的话有点不正确，要么干脆就叫Service或ServiceInfo得了。
2、远程调用
      远程调用准确来讲应该分为引用远程服务和调用远程服务两个环节，因为对于lazy init的服务而言首先是远程查找服务，但并不发生调用，所以在这里也分为两步来描述下。
      引用远程服务
      引用远程服务这块的话JNDI目前的实现肯定是很难满足需求的，按照OSGi的服务模型，在引用服务是只提供了服务的接口名，顶多就是增加了一些服务的特定属性来限定服务的范围，而JNDI在查找绑定的对象时是直接指定名称查找的，一对一的方式，但在OSGi的服务模型中获取到的服务有可能会是多个的，来看看怎么样修改实现这个需求。
       首先仍然是修改DS描述，以支持引用远程服务，例如：
       <reference name="CommonDaoService" interface="cn.org.osgi.module.hibernate.service.CommonDaoService" bind="setCommonDaoService" unbind="unsetCommonDaoService" policy="dynamic" server="jnp://10.100.100.100:1099"/>
       在查找远程服务中心的服务时，通过jndi将需要查找的服务的接口、属性等过滤条件传递给服务器端，这个应该可以通过扩展JNDI的lookup来实现，JNDI服务中心接到请求后根据过滤条件从注册的服务中查找到符合条件的服务元信息对象，并返回服务元信息对象集合至调用端，之后由生命周期管理对象决定后续的动作，关于生命周期管理对象在后一个篇章中来详细的分析。
        调用远程服务
        当远程服务被调用时，此时应该提供的一个配置是是否可跳过服务中心直接向另一端的服务发起调用(某些情况下可能会有这样的需求)，另外就是同步调用和异步调用的配置的支持。
        当调用时，可以走某种通讯机制对请求的服务的接口、方法以及参数传递至服务中心或相应的服务提供端，当服务提供端处理完毕后继续走这个通讯机制把处理的结果返回至调用端。经过上面的分析后，可以看出，基于JNDI实现服务的注册、查找不会是难点，在后面一个篇章中开始来分析生命周期的管理的问题，就会比较的复杂了，进入分布式环境后，生命周期的管理就比之前OSGi DS的生命周期管理复杂了很多。

基于OSGi实现分布式服务框架历程(二)

发布时间:2008年01月21日作者:BlueDavy

阅读次数:308次类别:OSGi、SCA 永久链接 Trackback

在这篇历程中来完成对于JINI的Spike，目标仍然是判断基于JINI实现服务的路由、查找需求的满足度。

JINI是由Sun研究院制定的，其目标就是为了实现分布式的服务，所以在很多地方可以看到它和分布式服务框架是有不少重叠之处的，来先看看它对于需求的满足度，最后再来分析做个总结。
1、怎么实现远程的将服务注册到服务中心？
      在jini中暂时没有找到远程注册服务到服务中心的方法。
      jini的服务需要和服务中心部署在同一台机器上，这个倒是可以通过服务管理中心直接将sar格式的服务部署上去，支持服务的动态管理，不过这是不符合分布式服务框架的需求的。
2、在服务应用端怎么查找服务中心的服务？
      在服务的查找上，Jini采用的方法估计是和JNDI差不多的，不过相对来讲要求就比JNDI高一些，因为它需要依赖它自己的serviceContext才能获取到服务，这点不是很好。
3、有否现成可用的实现？
      目前Jini的实现有好几个，最出名的当然是sun自己的Jini Starter Kit，但对于实现分布式服务框架的话，Newton是个更好的参考。
4、是否支持Cluster？
      由于服务和服务中心是在同一台机器，因此不存在是不是支持Cluster的问题，大不了部署的时候整个cluster中的所有机器都部署一次。
5、可参考的资源有哪些？
      jini可参考的资源主要就是：www.jini.org，通过这里可以找到挺多的jini的资料，比较好的有：
      http://blogs.sun.com/warren/entry/jini_made_easier_writing_a
      http://www.cheiron.org/seven/manual/html/developer/index.html
      http://jan.newmarch.name/java/jini/tutorial/Jini.xml
从服务的注册、查找和路由这三个需求去看，jini能直接满足的就只有查找了，因为我们需要的仅仅是一个注册、路由、查找的机制的框架，而不需要别的附加功能，jini就显得有点和这个需求不是很贴合了，尤其是jini本身就是个功能并不强的服务框架，如果采用它的话会导致还需要进行改造，剥离它的服务那块的机制或者做兼容，而且jini在使用时对于jini本身包的依赖性太强，这对于我们期待的pojo机制而言就挺麻烦了，当然，jini并不是毫无优点，如果大家去看看jini实现框架的那个可视化的服务的监控端，那实在是个很不错的东西，具体了完整的服务生命周期管理（安装、卸载、启动、停止以及目前的运行状态等）的功能。
jndi的简单性和对于需求的贴合性使得它成为了我们用于实现基于OSGi的分布式服务框架的选择。
在选择了jndi作为服务的注册、查找和路由机制后，我们需要逐步的演进基于OSGi的分布式服务框架的设计，在后续的篇章中我们将停留下spike过程，来分析下目前此分布式服务框架的状况。

基于OSGi实现分布式服务框架历程(一)

发布时间:2008年01月14日作者:BlueDavy

阅读次数:420次类别:OSGi、SCA 永久链接 Trackback 1条评论

写完之前的那篇基于OSGi实现服务框架的分析后，决定动手来实现一个基于OSGi的分布式服务框架，而其feature呢，就会遵照之前写的服务框架的要素来实现，根据之前的分析，将这个实现过程分为了三个大的步骤来完成：Spike阶段、实现阶段和测试阶段，Spike阶段用于完成几个关键问题的技术的研究和选型；实现阶段用于完成基于OSGi的分布式服务框架；测试阶段用于判断实现的分布式框架对于应用场景的符合程度、性能的情况。

首先进入Spike阶段，在Spike阶段需要完成服务注册、创建以及服务的proxy管理的技术研究和选型，这主要是因为我对这两部分的技术并不怎么熟悉，对于服务的注册和查找，可选的技术有两种：JNDI和JINI；对于服务的proxy的管理，可选的技术应该就是cglib这一种了，不过需要研究具体怎么用，在这篇blog中将介绍对于JNDI的Spike。
对于服务的注册和查找，首先想到的可用的技术莫过于JNDI了，JNDI作为java ee中重要的命名和查找的机制，和服务的注册、查找是非常吻合的，在做服务的注册和查找的技术的Spike时，主要从这么几方面去Spike：
1、怎么实现远程的将服务注册到服务中心？
      这个对于JNDI来讲，非常简单，在初始化jndi的context后，就可以通过context.bind或context.rebind来实现了。
      对于服务的远程注册来讲，在实现时是不注册服务的instance到服务中心的，只是注册服务的相关信息的对象。
2、在服务应用端怎么查找服务中心的服务？
      这个对于JNDI来讲，也很简单，通过context.lookup就可实现了。
      对于服务的远程引用和查找来讲，在实现时需要将context.lookup这种方式和DS方式融合。
3、有否现成可用的实现？
      有JBoss的JNP，从各类评价来说，还是不错的。
4、是否支持Cluster？
      JNP是支持Cluster。
5、可参考的资源有哪些？
      主要参考的资源有这两个网页：
      http://hankun.blogbus.com/logs/1774694.html
      http://blog.csdn.net/cjp472/archive/2003/10/28/17570.aspx
      关于JNDI cluster方面的资料：
      http://www.wangchao.net.cn/bbsdetail_30257.html

从上面几个方面来看，JNDI基本是满足服务的注册和查找的需求的，当然，在实现的时候还得做一定的改造，不过总体来说，还是不错的，等Spike完JINI后再来做出选择，为什么会想到JINI呢，就是因为著名的Newton项目了，Newton项目是基于OSGi+Jini实现的SCA框架，所以是值得参考的，欲知后事如何，请看下篇分解，:)。

基于OSGi实现服务框架的分析

发布时间:2008年01月13日作者:BlueDavy

阅读次数:364次类别:我的文章永久链接 Trackback

根据上一篇服务框架的要素的blog，来分析下基于OSGi实现一个这样的服务框架时需要对目前的OSGi框架做出哪些方面的修改，以及预估一下实现的难度。
1、如何注册服务
      OSGi服务采用的是xml+pojo的方式，应该说还是符合要求的，但如果要把这个服务注册到一个服务中心的话，目前是不支持的，但这个对于分布式部署服务的需求而言，是必须实现的了。
      要实现注册服务至远程的服务中心，这个可以通过编写一个监听服务生命周期变化的对象来实现，当监听到服务的生命周期发生变化时，发送消息至远端的服务中心，这里也就需要做出一个服务中心和各OSGi应用与服务中心远程通讯的机制（消息机制、RPC机制、Webservice机制等等）。
2、如何调用服务
      调用服务涉及的点比较的多，来看看基于OSGi如何来实现所有的需求：
      injection方式和显示调用方式
      OSGi支持injection方式的调用服务，在显示调用方式方面，OSGi不支持在OSGi框架范围外的显示调用，这个是有一定的不足的，因为这样会导致和第三方框架集成的复杂，不过由于目前有了Spring-OSGi，所以呢，可以选用Spring-OSGi，这样就两种方式都支持了，如果不想使用Spring-OSGi的话，那么可以选择查看OSGi框架的代码，找出显示调用的实现方法。
      另外一个就是可以通过服务中心来实现显示的服务调用和injection方式。
      本地调用和远程调用的区别
      OSGi并不支持远程服务的调用，在《OSGi进阶》Opendoc中我曾经写过基于webservice调用的方式，但这个对于高性能的分布式调用时其实是不可用的，要屏蔽本地调用和远程调用的区别，就得在现有的DS模型的基础上做改进了，需要支持引用服务时从当前的OSGi环境中或从服务中心中注册了，这个需要对现有的OSGi框架的DS实现做出改进，才能做到屏蔽本地调用和远程调用的区别，就可以仅仅通过在xml中做动作就可以了。
       同步调用和异步调用
       这个不用说，目前OSGi自然也是不支持的，只能是对DS的实现进行改进了，增加服务的同步调用和异步调用的支持，同步调用的话就没什么改动的了，异步调用的话就得对ds做比较大的改动了，注入引用的服务时注入的不能像目前的ds实现一样直接注入服务实例对象了，而是只能注册一个proxy对象了。
       lazy式的调用和固定的引用调用
       lazy式的调用目前OSGi并不支持，只能是自己对DS进行改动了，在引用远程服务和异步调用时，lazy调用是非常重要的。
      至于查找服务方面，这个OSGi目前的模型就可以了，只是要增加查找服务中心服务的功能，这个在修改DS实现调用远程OSGi服务时会去实现。
      在服务的安全性等方面这个也只能基于DS扩展实现了。
3、如何测试服务
      由于OSGi的服务是POJO的方式，在服务的测试方面是完全不会有问题的。
4、服务的生命周期
      在服务的生命周期方面，我想OSGi服务目前的机制就是不错的，即如果当前这个服务组件是对外暴露服务的，那么只有当其被引用且其本身所引用的服务可用时才被激活，如组件没有对外暴露服务，那么只需其引用的服务可用就可激活了，至于服务的卸载就是在上面条件不符合的情况下就应该卸载了。
      如果有必要的话，可以把服务的状态区分出installed、active、deactive。
      另外一个值得注意的问题就是，OSGi的DS是当服务的生命周期发生变化时，会通过bind-method和unbind-method去通知引用服务的组件的，这个特性我想即使是对于lazy式的调用也应该保持，这里也就需要DS关于服务通知的部分实现的代码了。
      来看看在这种服务框架的需求下的服务的生命周期的处理情况：
      安装服务：

服务被激活：

服务被钝化：

服务被卸载：

5、服务的管理和维护
      在服务的管理和维护上，应该说目前OSGi的DS模型提供的已经是很完整了，不过在服务中心点的服务的管理上则需自己实现了，基本可以参照OSGi的实现，需要考虑和增加的仍然是服务中心和各远程的OSGi应用的通讯。
6、服务的组装
      服务的组装方面，这个OSGi也是完全没有支持的，这个可以考虑基于服务中心去实现，抑或完全可以单独实现，只需可组装远程的服务中心中的服务即可了。
7、服务的出错处理
      服务的出错处理，这个对于OSGi来说还是有点的麻烦的，就像erlang强调的一点一样，不是进程隔离方式，自然很难保证当在同一VM中的一个OSGi服务出错时不影响到整个VM。
      只能尽量的去考虑另外一种方式了，当服务处理出错时的广播了，这样可以做到fail-fast。
8、服务事件的广播和订阅
      服务事件的广播和订阅，这方面OSGi目前支持的还是挺好的，不过在增加服务中心后，就需要增加事件广播至多个服务中心了。

在增加考量的两个因素方面，OSGi的DS是不支持aop方式的，不过要搭建一个服务库不是一件什么难事，其实服务中心本身就已经是服务库了。
上面的实现分析还是有点的虎头蛇尾吧，最后就按照上面的分析总结成一张图吧，来管窥下基于OSGi实现的分布式服务框架会是个什么样的结构：

从上图并结合服务的生命周期管理的部分可以看出要基于OSGi实现一个这种适合分布式场景的服务框架还是比较麻烦的，需要重写的部分是非常的多，以此来看的话，目前OSGi最适合的场景应该还是如下几种：
1、不需要分布式部署的应用场景；
2、需要分布式部署，但仅仅是分层的分布式部署，例如业务层在一台机器上，数据层在另外的机器上。
不过基于OSGi实现一个这样的服务框架也是一件很不错的事，估计这也是EEG目前正在做的事，希望以后能在自己有空的时候动手做做这个基于OSGi的服务框架。

服务框架的要素

发布时间:2008年01月02日作者:BlueDavy

阅读次数:505次类别:OSGi、SCA 永久链接 Trackback 1条评论

服务框架，这个名词已经出现了很多年了，很早以前系统的架构就希望是以基于服务框架的方式来搭建的，turbine、phoenix、avalon等都是朝着实现服务框架的目标而去，如今的SCA，也可以说就是为了提供一个可用的服务框架，服务框架在系统中到底承担什么角色呢，为什么它会显得那么重要呢，如果要实现一个服务框架，不太可能从最底层做起，那么我们又需要怎么样去选择呢？
服务本身是个挺形象的名词，在系统设计中我们非常强调输入和输出，服务呢，可以说是更形象的去强调了这一点，每个模块都会对外提供一定的功能，而这些对外提供的功能我们就可以作为服务了，细到模块内，我们也会发现模块内各个类其实也是以服务的方式来交互的，在这样的情况下，服务框架自然就成了整个系统的核心基础框架，那么服务框架能帮我们来提供哪些功能呢，如果我们要实现一个服务框架，有哪些要素是需要考虑的呢，欢迎大家拍砖，多多交流！
1、如何注册服务
      怎么样注册出服务这东西呢，:)，这是我们在做考评时的第一要素了，最理想的莫过于通过xml将一个pojo描述为服务了，或者是java annotation的方式了。
      另外个可以附加考评的点就是在注册服务时是否支持部署到指定的服务中心，类似websphere的远程部署。
2、如何调用服务
      如何调用服务，这个可以说是考评中很重要的一个因素，而且也是比较复杂的考评点。
      从调用的方式上来讲，服务的调用需要考评的有是否支持injection方式和显式调用方式、本地调用和远程调用的区别、同步调用和异步调用的区别、lazy式的调用还是固定的引用调用，从考评的期望上来讲，我们当然是希望injection和显式调用都支持，本地调用和远程调用、同步调用和异步调用能透明式的配置，lazy式的调用是指注入或调用的服务只有在切实调用到相应的方法时才会获取到真实的服务对象，而固定的引用调用时指当调用服务时即获取到真实的服务实例对象，lazy式的调用和固定引用调用的支持对于集群应用场景会产生很大的影响。
      调用服务同时涵盖了查找服务的概念，在查找服务方面考评的点就是是否支持按需查找服务、查找多个服务，由于同样的服务在系统中可能存在多个不同的实现，按需查找服务的意义就在于可以准确的指定所需的服务，这对于需要按规则准确查找服务的应用场景而言是很重要的；查找多个(0..n)服务呢，对于需要调用可用的所有服务的应用场景很重要，这个功能对于当调用的服务不是必须的时候也是非常重要的，例如引用了日志服务，但即使当日志服务不可用的时候也需要不影响当前类的功能的应用场景。
      在调用服务上还需要考虑调用服务的安全性，例如认证、权限控制等。
      在调用服务上还需考虑此框架中的服务是否可以很容易的被第三方进行调用，例如在spring中调用、在其他的语言中调用等，呵呵，是不是有点SCA的感觉。
3、如何测试服务
      服务的测试无疑也是考评的重要点之一，要知道当年webwork能在MVC框架领域争得一席地位和其action更好的支持了单元测试有很大的关系，所以服务框架在此方面支持的怎么样也是需要考评的要素之一。
4、服务的生命周期
      由于服务的生命周期是由服务框架来控制的，因此服务的生命周期是如何转换的这也是我们在考察服务框架时需要知道的。
      另外一个考评点就是如果服务的生命周期发生转变时，引用此服务的类是否能得到通知等，当然，如果是lazy式的调用的话，完全不存在这问题。
5、服务的管理和维护
      这个对于服务框架而言应该是比较基础的功能，包括的有提供服务列表，在服务列表中应该有服务的名称、所属的服务中心、服务的状态、服务的处理日志以及服务访问的压力记录等等。
      服务的管理就包括了服务的安装、升级、启动、停止和卸载。
6、服务的组装
      服务的组装的概念是指可以灵活的将多个服务组装为一条链，然后链式的调用，这个呢是附加的考评要素了。
7、服务的出错处理
      需考评当位于此服务框架下的服务处理出错时会造成什么现象，最理想的结果自然是服务的调用停止，并记录相关的日志，另外的服务对此情况做出纠错处理，有点像erlang的容错思想，:)，最基本的一点就是不能影响到服务框架和其他服务的正常运转。
8、服务事件的广播和订阅
      允许服务在处理时能对外广播事件，同时也可订阅事件，以触发某些动作，这里可以附加考评的就是是否支持多种灵活的服务触发方式，例如定时的触发等。
其他可考评的要素还有服务框架对于AOP的支持、是否可建立服务库，就像bundle repository一样，:)

当然，目前开源界应该说是没有此类框架的直接存在的，但我们可以基于Equinox、Newton等已存在的类似框架来实现一个这样的标准的服务框架，考评时就可以根据这些点去判断基于哪个已有的框架是较好的选择了。

回顾07，展望08

发布时间:2007年12月31日作者:BlueDavy

阅读次数:324次类别:业界随想永久链接 Trackback

07年的最后一天了，回顾当年、展望来年已经是每年最后一天的惯例了，就像往年一样，07年对于业界而言仍然是高速发展的一年，新技术、新框架、新名词不断的在冒，不过对于自己而言，07年在新东西方面接触的不多，也许是现在更加的专注了吧，没有以前那么博了，:)，回顾的关键字自然也就锁定在自己感兴趣的领域：
OSGi
07年对于OSGi业界而言，属于平稳发展的一年，表面上看起来没有去年里程碑式的发展，但其实这也是说明了OSGi已经切实的进入了企业领域，并成功得到应用的表现，并且另外一个更好的现象也在今年出现，就是OSGi越来越多的成为了话题，可以说OSGi在07年也成为了业界的关键词之一，在这一年，OSGi业界方面的大事有这么几件：
1、OSGi DevCon2007的召开；
      OSGi DevCon2007的召开对于OSGi业界而言是件非常重要的事，能够举办专门的OSGi DevCon本身就已经说明了OSGi在整个业界的地位，而通过这个DevCon OSGi的同仁们也有了一次很好的交流、共享知识的机会，本次OSGi DevCon的经典Topic也是很值得回味的，具体大家可以查看我就此次DevCon的blog： http://www.blogjava.net/BlueDavy/archive/2007/03/23/105967.html
2、BEA、IONA、 Eclipse、JAYWAY和Interface 21加入OSGi联盟；
      这几个大厂商和开源组织的加入对于OSGi而言也是件非常重要的事，毕竟一个规范要成功的实施必须有这些大厂商和开源组织的大力支持，在这几个加入之后，基本上业界知名的大公司和开源组织均已进入了OSGi联盟，从这也可看出OSGi将来发展的潜力是无限的。
3、Spring-OSGi的正式发布；
      Spring-OSGi在今年终于是发布了1.0，从试用的情况来看还是不错的，尽管还有很多发展的余地，但一定程度上还是帮助OSGi扫平了进军企业应用领域的障碍。
对于China OSGi User Group而言，今年应该算是很重要的一年，尽管还没达到里程碑式的发展，但基本做足了前期的准备工作：
1、《OSGi进阶》Opendoc的发布
       《OSGi进阶》Opendoc是继《OSGi实战》后的又一篇新的Opendoc，这篇Opendoc可以引导大家在实际的商业项目/产品中切实的使用OSGi。
2、两篇PPT的发布
      两篇PPT凝聚了我自己不少的心血，用于引导新人进入OSGi的大门以及和OSGi的使用者们探讨OSGi的深入使用。
3、China OSGi User Group的准备工作
      经过和OSGi官方联盟的一系列的交流，China OSGi User Group得以以官方的名义存在，并事先翻译好了OSGi.org中的大部分内容，目前试运行的网站暂时放在了 www.riawork.org这里，如想预先查看China OSGi User Group的信息，则可通过访问这个网站来查看。
另外一个就是OSGi在中国国内的发展也开始大幅度的前进了，至少据我个人的了解，目前国内就已经有几家顶尖的公司开始采用OSGi，例如中创、华为等，华为除了在硬件方面采用外，在纯软件方面也开始考虑采用了。
SCA
SCA无疑也是今年的热门关键字之一， SCA能否让 SOA得以落地实施是今年整个 SOA界争论的重点话题之一，无论如何，从 SCA 1.0的规范看过去， SCA的意义是比较大的，应该说对整个业界还是产生了极大的影响，IBM等厂商都积极的推出 SCA实现的产品，不过目前还没看到什么此方面的成功实践什么的，所以也不好过多的去评论。
不过 SCA所表达的愿景其实是很多厂商都追求的开发平台，有一个这样的平台对于任何应用而言都是很好的事。
Erlang
Erlang绝对是2007年业界最为热门的关键字之一，说起来Erlang并不是什么新东西，爱立信都已经用了二十多年了，而且在交换机上的成功的应用已经证明了Erlang在高并发、高性能要求和容错系统上的可用性，当然，Erlang之所以能成为热门的关键字是由于其在分布式、高并发、高性能和容错的独特支持，Erlang将这些特性都分离成为了语言级的特性，因此区分于其他的语言而独树一帜，无论是否采用Erlang，其所带来的实现分布式、高并发、高性能和容错系统的方法都是值得学习和研究的，从erlang中可以学习到的除了这些问题的优秀的解决方案外，另外一个更为重要的就是分离这些特性和应用的方法。
互联网应用
互联网应用对于我个人而言是07年很重要的关键词，可以说在07年前对于互联网应用没有什么切实的体会，07年呢，则可以说是自己进入这个领域的一年，逐渐的对互联网应用有了更多深入的理解，对于互联网应用的特性和企业应用的特性有了更多的理解，并且也改变了个人的观点，开始认同互联网应用是个挺有挑战的行业应用的观点，而互联网应用的经验也让自己更加清楚的看到了产品发展的方式，这对于企业应用其实也是相同的，给自己带来的另外一个体会就是敏捷中的众多实践对于互联网应用是多么的关键和重要。
而正因为自己之前对于互联网应用的了解不多，在08年需要补的课还是有不少。
认识架构
说起来有些的不好意思吧，毕竟自己任职系统设计师也有三年多的时间，但对于架构，我觉得自己也是随着经验的积累才逐渐的有了更多的认识，才逐渐的明白为什么架构对于一个产品/项目是如此的关键，也更加的明白为什么架构是如此的难，评论一个架构的成功与否也不是一件很容易的事，对于项目而言也许还没什么，但对于一个产品而言架构完全是一个可持续发展的产物，怎么样合理的去发展架构对于产品/互联网应用是个最难把握的问题。
07年的回顾虽然就这么草草的结束了，但这些回顾也让自己想到了很多很多，在后续的blog中我想我会对其中的一些话题深入的展开探讨。
对于08年，有很多的期待：
OSGi
对于整个业界而言，一方面希望看到OSGi DevCon 2008的精彩Topic，另一方面就是看看OSGi EEG的切实动作以及 SCA什么时候明言采纳OSGi了。
应该说目前OSGi成为企业应用的基础平台已经没有什么太大的问题了，剩下的就要看宣传和推广的力度了。
对于China OSGi User Group而言，最重要的莫过于网站的正式上线运营，另一方面就是开源文档和开源项目的推广和发展了，希望在08年China OSGi User Group能够在整个OSGi业界产生一定的影响，也希望中国能够更多的企业采用和推广OSGi。
互联网应用
对于自己而言，互联网应用是08年和OSGi可以相提并论的话题，在08年自己将更加全面的接触、认识、参与互联网应用，希望能从这里面学习到很多不同的东西并运用自己所长做出贡献。
深入架构
更加深刻的认识架构，把握架构设计的原则、尺度，培养架构属性重要级别的区分能力以及宏观把控能力。

希望在08年底回顾的时候能够有更多想说的吧，有更多可期待的吧，:)，加油！