OSGi、SOA、SCA
OSGi、SOA以及SCA领域的相关Blog。
摘要: 摘自我那本6月份要上市的，但目前名字还没完全确定的书，由于书中涵盖的更多的为构建高性能分布式Java应用所需要的基础知识，也许改成了《通往高性能分布式Java应用之路》，主要是阐述下为什么大型应用需要SOA，以及eBay的例子，blog全文请见：http://bluedavy.com/?p=30
阅读全文
摘要: 在QCon SF 2009的SOA分会场上，eBay的架构师讲了一个SOA @ eBay的PPT，正好和我的工作有很多的交叉点，于是比较认真的看了下这个PPT，感兴趣的同学可以从这里下载：http://qconsf.com/sf2009/file?path=/qcon-sanfran-2009/slides/SastryMalladi_SOAEBayHowIsItAHit.pdf，在这个PPT中可以看到eBay对于SOA的看法以及他们目前的做法，自己也是做这方面工作的，就在这篇blog中介绍下这个PPT以及自己对于SOA的一些看法。
阅读全文
摘要: 和清华学子做了一次关于OSGi的交流，在此公开下这个PPT，:)，这个PPT是我写的最长的一个OSGi PPT,涵盖的内容主要是OSGi标准方面的知识以及Equinox使用的一些知识，感兴趣的同学可以下载下: http://www.bluedavy.com/opentopic/OSGi20094qh.pptx
阅读全文
摘要: 这本书的名号有：国内第一本OSGi中文书，全球第二本OSGi技术书，少数的能够领先于英文技术原创书出版的中文书籍，这些都乃虚名，最重要的是希望这本书能真正的为希望了解、学习或深入掌握OSGi；希望了解、学习如何编写模块化、动态化的Java应用的Java技术人员提供一些帮助，那么也就不枉这本书的出版了，很荣幸能参与这本书的编写，圆了自己两年前出一本OSGi书的梦，下面放上一些本书的封面的图片show下。
阅读全文
摘要: Equinox的设计非常经典，其在扩展方面提供了很多的支持，同样包括类加载方面的控制，除了通过标准的org.osgi.framework.bootdelegation以及equinox提供的osgi.parentClassLoader这两个属性来简单的控制类加载之外，还可通过实现ClassLoaderDelegateHook来更为灵活的控制类加载。
阅读全文
摘要: 很不容易，经过两个多月两个人的努力，终于完成了《OSGi原理与最佳实践》一书的草稿，目前正在review过程，预计将在7月底上市，而由于国外的那本《OSGi in action》将出版时间推迟到11月了，《OSGi原理与最佳实践》这本书也将成为全球第二本OSGi的书籍（很遗憾，德国之前出版了第一本），:)，现将本书的目录公布如下，上市的书也许会稍有改动，但应该会大体一致。
阅读全文
摘要: 这是Lifecycle Layer中的最大改进，在之前的规范中只是简单的描述了下框架的启动和关闭，在制定了这个规范后，以后无论是启动equinox还是felix，都可采用同样的方式启动，详细的来看看，本文摘自《OSGi原理与最佳实践》。
阅读全文
摘要: 本文内容同样摘自《OSGi原理与最佳实践》，在之前的blog中也摘选了部分内容分析了Equinox的动态化，在这里再试验下Felix的动态化，关注点为：“即插即用”、“热部署”、“即删即无”，看下Felix在这几方面的表现和Equinox有什么不同。
阅读全文
摘要: 对于采用OSGi来做系统的人而言，ClassLoader的问题必然是头号需要解决的问题，如果又是个需要远程通讯的OSGi应用的话，那么反序列化的classloader问题几乎可以肯定是会碰到的，来看看在如今流行的两种序列化、反序列化协议：java/hessian中如何使用自定义的classloader。
java/hessian并不提供直接的传入ClassLoader类来改变反序列化时采用的ClassLoader，hessian采用的为使用当前线程的上下文ClassLoader来加载反序列化的类，java则采用堆栈上最近的一个ClassLoader类来加载，可以认为就是调用类所在的ClassLoader来加载，但在OSGi应用中，通常采用以上默认的行为来反序列化加载类是会出问题的，因此需要采用自定义的。
阅读全文
摘要: 对于想使用Equinox来构建OSGi应用的同学们而言，掌握Equinox是如何加载Bundle中的Class无疑是相当重要的，这样在碰到各类ClassNotFoundException的时候也就有底了，否则可能出现的ClassNotFoundException会多的让你非常的头疼，本文提取自《OSGi原理与最佳实践》，介绍下equinox是如何来加载Bundle中的class的。
阅读全文
摘要: OSGi最吸引人的特性除了模块化之外，就是动态化了，在我之前写的OSGi实战以及进阶两篇Opendoc中，都有相关的示例，但不知道大家有没有注意，在两篇Opendoc中都未提及到bundle本身的更新，而基本都是以新增服务实现的bundle以及停止服务时限的bundle为例，并且相对而言是个比较简单的例子，动态化在java界更明确的词也许是hot deployment，而hot deployment的实现并不容易，同样，即使你采用OSGi，但也不代表你的应用就具备了hot deployment的能力，在hot deployment上，完美的结果就是当更新完成后，新的执行请求就在新的代码逻辑上正确的执行，就像没发生过更新这回事样，但实际要做到这样的效果，远没这么容易，即使是基于OSGi也同样如此，No magic & no silver bullet，在本篇blog中我们就来具体的看看。
阅读全文
摘要: 把自己写的两篇opendoc和Book统一放入此blog中提供下载，避免占据我blog的两个置顶位，:)
阅读全文
摘要: 在使用OSGi时，有些时候会需要在OSGi容器外获取OSGi服务，加载OSGi容器加载的class，或者说需要内嵌OSGi容器，本篇blog以一个简单的例子来说明如何基于equinox实现OSGi容器的内嵌，或者说通过程序来启动equinox，同时也通过此例子展示下如何在容器外来获取OSGi服务以及加载OSGi容器里面其他插件的class，同时还会附送一个如何让OSGi容器里的插件能加载到OSGi容器外的类的方法。
阅读全文
摘要: 之前的Opendoc中没有涉及过此部分的内容，maven又是现在非常流行的java的工具，再加上到目前为止搭建OSGi Maven开发和部署的环境还是比较的麻烦，觉得有必要写篇这样的blog，:)，在这篇blog中来看下如何搭建一个比较好用的OSGi Maven开发和部署环境，看看我在搭建一个这样的环境中的痛苦历程。
阅读全文
摘要: 随着OSGi近两年的迅猛发展，尤其是Java企业应用领域厂商对OSGi的认同，大家对于OSGi的新版规范的关注远远超过了之前的几个版本，近来OSGi终于是放出了传闻已久的R 4.2的Early Draft，其实从Early Draft来看，我觉得完全可以认为不仅仅是一个小版本的升级了，甚至可以认为是R5了，因为R 4.2增强的东西还是非常多的，其中就包括了大家期待已久的RFC119，不过没看到传说中的RFC66，有一丁点的失望，不过相信后面的Draft中应该会加上，:)，这样看来，R5更是值得期待了，让我们先来一起品尝一下4.2 Early Draft这道大餐。
阅读全文
摘要: 由于Topic的时间有限，因此此篇PPT只是简单的对OSGi进行了介绍和演示，而没有做详细的OSGi使用的讲解，可能让参与这次Topic的同学们失望了，不过还是在此把PPT公开出来了，如感兴趣的话，可以从以下地址下载：
http://www.riawork.org/opentopic/Simple.Introduction.For.OSGi.ppt
阅读全文
摘要: JavaOne的第二天Sun正式官方宣布在Java 7中将支持OSGi：This will allow developers who create applications that use OSGi bundles will be able to run them unmodified in JDK 7.这消息对于知悉OSGi Vs JSR 277的一系列历史战争的人而言绝对是非常的振奋人心，尽管不是说Java 7直接纳用OSGi来实现模块化这一块（这个呢，其实如果JDK做的话，确实可以做的更好，至少可以更高效什么的），但就支持这一点也可看出Sun已经看到了OSGi是事实性的模块化标准，这对于OSGi来说也是里程碑的一天。
阅读全文
摘要: Java领域中的分布式框架比较的多，分析一个已有的远程调用框架无论是对于打算采用已有成果还是自己做分布式框架，都是很必要的事情，JBoss Remoting是其中很好很强大的一个框架，在此来对JBoss Remoting进行深入的分析，看看JBoss Remoting是如何基于java.net提供的包去解决这些问题的，本文所分析的JBoss Remoting源码的版本为2.2.2_SP2，本来以为会是篇不怎么长的文档，没想到还没写的详细和深入的时候就已经有三十多页了，也不好在这里直接贴出来，就把文档目录和最后的总结部分贴在这了，感兴趣的同学们可以从这个地址下载PDF版本的文档：http://www.riawork.org/opendoc/JBoss.Remoting.Opendoc.pdf
阅读全文
摘要: 非常感谢Kane的工作，其实在差不多两个月前就完成了和OSGi官方联盟的协议的签订，使得OSGi China User Forum成为了继法国、日本、韩国、西班牙以及瑞典后的第六个官方授权和认可的组织，并且拿到了OSGi联盟官方提供的空间，其实就是个简单的wiki了，只是一直没抽出时间去建设网站，Kane在百忙之中抽出时间把站点的基本页面进行了搭建，使得这个官方站至少看上去有点内容了，官方站的地址为：http://china.osgiusers.org。
阅读全文
摘要: OSGi DevCon2008已经闭幕，迫不及待、非常迫不及待的希望能了解更多此次大会的盛况，不过目前相关的新闻报道等还是比较少的，除了osgi.org/blog上有三四篇报道，根据日程找到目前公开的OSGi DevCon 2008中Topic的PPT，共11个，在此根据自己看这些PPT的情况做个简单的介绍和评价。
阅读全文
摘要: 期待已久的OSGi DevCon 2008将会在下周（3月17日---3月20日）和EclipseCon 2008共同召开，今年OSGi的Topic比去年更多，也占据了更重要的位置，来看看本次大会即将开讲的Topic，畅想畅想，看看哪些Topic将会成为热题。
本届Topic仍然和往年一年，分为Long Talks、Tutorials、Short Talks、Panel和Additional OSGi Talks，本届OSGi DevCon可谓是众星云集，世界级的OSGi大师们共聚一堂，毫无疑问将给我们这些OSGi Fans们贡献一场盛宴。
阅读全文
摘要: 在分布式服务框架中，一个最基础的问题就是远程服务是怎么通讯的，在Java领域中有很多可实现远程通讯的技术，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，这些名词之间到底是些什么关系呢，它们背后到底是基于什么原理实现的呢，了解这些是实现分布式服务框架的基础知识，而如果在性能上有高的要求的话，那深入了解这些技术背后的机制就是必须的了，在这篇blog中我们将来一探究竟，抛砖引玉，欢迎大家提供更多的实现远程通讯的技术和原理的介绍。
阅读全文
摘要: 在使用Spring的时候，我们习惯于用bean的名称作为注册、查找的条件，这也就意味着bean的引用是唯一的了，而不能来查找、注入一系列具备相同功能但不同实现的bean，这种应用的场景其实还是很多的，尤其在扩展的场景中，在这篇blog中以一个应用场景来说明下这种需求，顺便也宣传下OSGi的服务接口+版本+属性的注册和查找机制。
阅读全文
摘要: 在上篇分析完了在V 0.7需要干的活后，开始细化其中的实现细节，由于技术细节和之前想的有点不同，在细化的同时也稍做了调整，系统的架构仍然保持不变，在这篇blog中来看看实现每项任务的技术细节，之后就可以进入编码实现阶段了。
阅读全文
摘要: 经过上篇分析分布式服务框架的blog后，正式对之前的基于OSGi实现分布式服务框架的系列改名(顺便把分布式服务框架改为使用DSF缩写)，因为已经决定基于Spring-DM来实现，为什么呢，而且为什么一定要是Spring-DM，而不直接说Spring呢？
在讲完这个原因后，在这篇blog中你还会看到基于Spring-DM后的DSF V0.7是什么样子，以及要干些什么活来完成V 0.7。
阅读全文
摘要: 昨天刚分析完分布式服务框架，今天便看到Spring Integration 1.0 M1发布的消息，这也为Spring进军SOA领域拉开了序幕。
阅读全文
摘要: 技术是为需求而服务的，分布式服务框架也同样如此，它不是凭空诞生的，也是因为有这样的需求才会有分布式服务框架这样的东西诞生，在这篇blog中来详细的分析分布式服务框架诞生的原因(其实也是需要用分布式服务框架的应用场景，这里隐含的意思就是并不是什么应用都需要分布式服务框架的)、分布式服务框架需要提供的feature以及实现这些feature可选的技术方案。
阅读全文
摘要: 在这个篇幅中将来分析下这个分布式服务框架的服务的生命周期的管理的问题，在分布式服务框架中，支持服务的动态部署、卸载、升级是很关键的，至于服务的生命周期是否需要做到像OSGi那样的动态通知，在这个篇幅中会进行分析，并最终形成这个分布式服务框架的生命周期模型以及到目前为止的服务架构模型。
阅读全文
摘要: 上篇说到，经过分析后决定选用JNDI来实现服务的远程注册、查找和路由，在这篇blog中就来详细分析下基于JNDI怎么和OSGi结合来实现服务的远程注册、查找和路由。
阅读全文
摘要: 在这篇历程中来完成对于JINI的Spike，目标仍然是判断基于JINI实现服务的路由、查找需求的满足度。
JINI是由Sun研究院制定的，其目标就是为了实现分布式的服务，所以在很多地方可以看到它和分布式服务框架是有不少重叠之处的，来先看看它对于需求的满足度，最后再来分析做个总结。
阅读全文
摘要: 写完之前的那篇基于OSGi实现服务框架的分析后，决定动手来实现一个基于OSGi的分布式服务框架，而其feature呢，就会遵照之前写的服务框架的要素来实现，根据之前的分析，将这个实现过程分为了三个大的步骤来完成：Spike阶段、实现阶段和测试阶段，Spike阶段用于完成几个关键问题的技术的研究和选型；实现阶段用于完成基于OSGi的分布式服务框架；测试阶段用于判断实现的分布式框架对于应用场景的符合程度、性能的情况。
首先进入Spike阶段，在Spike阶段需要完成服务注册、创建以及服务的proxy管理的技术研究和选型，这主要是因为我对这两部分的技术并不怎么熟悉，对于服务的注册和查找，可选的技术有两种：JNDI和JINI；对于服务的proxy的管理，可选的技术应该就是cglib这一种了，不过需要研究具体怎么用，在这篇blog中将介绍对于JNDI的Spike。
阅读全文
摘要: 根据上一篇服务框架的要素的blog，来分析下基于OSGi实现一个这样的适合分布式场景的服务框架时需要对目前的OSGi框架做出哪些方面的修改，以及预估一下实现的难度。
根据分析可以看出要基于OSGi实现一个这种适合分布式场景的服务框架还是比较麻烦的，需要重写的部分是非常的多，以此来看的话，目前OSGi最适合的场景应该还是如下几种：
1、不需要分布式部署的应用场景；
2、需要分布式部署，但仅仅是分层的分布式部署，例如业务层在一台机器上，数据层在另外的机器上。
不过基于OSGi实现一个这样的服务框架也是一件很不错的事，估计这也是EEG目前正在做的事，希望以后能在自己有空的时候动手做做这个基于OSGi的服务框架。
阅读全文
摘要: 服务框架，这个名词已经出现了很多年了，很早以前系统的架构就希望是以基于服务框架的方式来搭建的，turbine、phoenix、avalon等都是朝着实现服务框架的目标而去，如今的SCA，也可以说就是为了提供一个可用的服务框架，服务框架在系统中到底承担什么角色呢，为什么它会显得那么重要呢，如果要实现一个服务框架，不太可能从最底层做起，那么我们又需要怎么样去选择呢？
服务本身是个挺形象的名词，在系统设计中我们非常强调输入和输出，服务呢，可以说是更形象的去强调了这一点，每个模块都会对外提供一定的功能，而这些对外提供的功能我们就可以作为服务了，细到模块内，我们也会发现模块内各个类其实也是以服务的方式来交互的，在这样的情况下，服务框架自然就成了整个系统的核心基础框架，那么服务框架能帮我们来提供哪些功能呢，如果我们要实现一个服务框架，有哪些要素是需要考虑的呢，欢迎大家拍砖，多多交流！
阅读全文
摘要: 之前发布了一篇Introduction OSGi的PPT，Introduce OSGi PPT主要是用于介绍OSGi，更多的是在讲解OSGi的一些基础概念，OSGi in action PPT则主要是针对有一定OSGi使用经验的用户而编写的，此篇PPT更加专题性质和细致的讲解了OSGi如何在实际的项目中进行使用，如何和流行的java框架进行集成，以及在实际的OSGi应用设计和开发时的一些最佳实践的介绍和讲解，对此PPT感兴趣的同学可从以下地址下载：
http://www.riawork.org/opentopic/OSGi.in.action.ppt
阅读全文
摘要: 上次发布OSGi in action的PPT后，得到了flyisland的反馈意见，:)，在此也谢谢他，正是从他的意见中看到了之前PPT的一些问题，之前PPT的问题应该是目标听众不明确，讲的内容多但却都不详细，很有可能最后讲完了无论是对于OSGi Newer还是OSGi熟悉的人都没有什么任何的帮助，为了解决这个PPT，决定把PPT分为两篇来完成，一篇为OSGi Newer编写的关于OSGi介绍方面的PPT，将名字定为了Introduce OSGi，重点的介绍OSGi的基础概念和基本的使用方法；而另外一篇则是为较为OSGi的同学们编写的，名字仍然保持为OSGi in action，会重点和较为详细的讲解OSGi在实际项目的使用，目前先发布Introduce OSGi的PPT，希望能继续得到大家的反馈意见，感兴趣的同学们可以从这下载这篇PPT：
http://www.riawork.org/opentopic/Introduce.OSGi.ppt
阅读全文
摘要: 这个PPT将会用于最近的一些OSGi活动作为Topic来讲讲，不过是英文版的，:)，一方面是锻炼自己的英文，另一方面也准备把这PPT再雕磨雕磨，提交到OSGiDevCon 2008的Topic中试试。
感兴趣的朋友请从以下地址下载此PPT：
http://www.osgi.org.cn/opentopic/OSGi.in.action.ppt
不过俗话说，PPT嘛，靠的主要是讲，但同时也希望得到大家对此PPT的反馈意见，以便我进行进一步的修改，希望在之后的公开的活动中不会把这Topic讲砸了，此PPT会不断的进行修改，我会在此篇blog中公布目前ppt的版本号，大家就可以确认手头的PPT是否是最新的了，:)。
version info:
1.0 2007-10-21
阅读全文
摘要: 在历时两个多月后，OSGi进阶的编写已完毕，感谢N多朋友一直以来的关注和支持，现将正式版对外发布，下载地址为：
http://www.riawork.org/opendoc/osgiopendoc2.pdf
随文的代码的下载地址为：
http://www.riawork.org/opendoc/osgiopendoc2-source.zip
随文的例子的可运行版本的下载地址为：
http://www.riawork.org/opendoc/osgiopendoc2-dist.zip
随后将会相继在Redsaga上发布Redsaga Opendoc版本，以及在InfoQ中国站上发布InfoQ miniBook版本，这两个版本在精美程度上都会超过我现在发布的版本，到时再給予大家通知，:)
阅读全文
摘要: OSGi在应用时具备了典型的微核系统的特点，但对于实际项目/产品型的应用而言，这个微核有些过于底层了，为什么这么说呢？
对于实际项目/产品型的应用而言，何谓其微核呢，应该说其脚手架或开发平台才是它的微核，而并非仅仅是OSGi框架，当然，也可以将自己的脚手架或开发平台以Fragment-Host的方式绑定到OSGi的System Bundle上去，但这样的做法无疑有些evil了，TPF诞生的最主要的目的就是形成一个应用级的微核的概念，使得我们在管理实际的项目和产品时，能够将脚手架和实际的业务应用模块分离管理，让脚手架也变成微核，这样在管理时就可以做到对应用系统的统一管理，而同时保持一个含应用意义的微核（也可以认为是开发平台）的稳定运行，在具备了TPF的情况下，就可以将应用系统从部署上分为脚手架和应用系统，而在管理上也可以单独对应用系统进行管理，如启动应用系统、停止应用系统，同时避免应用开发人员对脚手架无意的修改。
在本篇文档中将介绍TPF提供的功能、TPF实现的方法以及TPF的下载地址。
阅读全文
摘要: 本来目前这篇Opendoc还没有达到发布的条件，不过正逢国庆佳节，希望各位感兴趣的同学能够在国庆期间抽出时间看看这篇Opendoc，而国庆期间我也会对Opendoc进行润色和内容的充实、完善，国庆后希望能获取到各位看过预览版的同学的意见，我会根据各位的意见对Opendoc进行适度的修改，争取在10月中旬发布正式版。
至于随Opendoc的代码等到正式版的时候我再发布，如有需要的同学可以直接mail给我，我可先mail给需要的同学。
另外由于预览版还有不少需要润色、完善的地方，请各位收到预览版的同学不要传播这个版本，:)，多谢！
阅读全文
摘要: 《OSGi实战》Opendoc推出已一年有余，该篇Opendoc主要是为了介绍OSGi而编写的，相对而言知识点较浅，很多朋友在看过那篇Opendoc后也许会对OSGi产生兴趣，但未必会在商业的项目/产品中去使用它，为了能够让更多的朋友能够在商业的项目/产品中使用OSGi，根据自己的经验以及这一年多来OSGi界的发展情况，从8月初开始了《OSGi进阶—模式与最佳实践》Opendoc的编写，争取在国庆前推出一个预览的版本，希望《OSGi实战》能吸引大家关注OSGi，而《OSGi进阶》能推动大家在商业项目/产品中使用OSGi，如对预览版有兴趣，请发邮件联系我，在完成后的第一时间我将mail给你，谢谢关注！
阅读全文
摘要: OSGi.org.cn将做为OSGi.org的官方中文网站推出，整个项目预计分为两期完成。
一期的目标为翻译OSGi.org的所有内容，至于blog部分则能尽量翻译，暂定为先翻译近三个月的blog，一期的计划为一个月内完成，也就是说在国庆前正式的推出OSGi.org.cn，到时会在国内的几个大网站上(InfoQ-CN、JavaEye、EclipseWorld、CSDN等)做一定的宣传和推广；
二期的目标为翻译OSGi.org中的所有blog，同时翻译www2.osgi.org中的所有内容。
在一二期工作完成后，进入OSGi.org.cn的维护期，到时就是跟随着OSGi.org做更新的翻译，同时OSGi.org.cn会考虑做一些本地化的blog、新闻、论坛、开源项目等工作，目标是让OSGi.org.cn做到中国顶尖的OSGi网站，并为推广OSGi和发展OSGi做出贡献。
阅读全文
摘要: 向Peter Kriens问了一些自己比较关心的OSGi进展情况的问题，总结而言：
从Peter Kriens的答复来看，R5和EEG的工作成果生效还得等待较长的时间，好消息是SCA采用OSGi作为基础架构看来是非常的有希望了，这对于OSGi的推广是件非常好的事。
阅读全文
摘要: 在Play OSGi中提及到了Bnd是个非常有用的东西，既然是个好东西，就介绍给大家用，在得到了Peter的授权下，我把这篇使用手册翻译成了中文，大家感兴趣的话可以到这里看看：http://www.aqute.biz/Code/BndCn，同时也会提供一个PDF的版本供大家下载，PDF版本下载地址为：http://www.blogjava.net/Files/BlueDavy/Bnd.zip。
有了Bnd后，传统的java工程非常容易打包成标准的OSGi R4的bundle，同时Bnd也为校验Bundle是否符合OSGi R4规范提供了支持，而且Bnd有命令行、Eclipse插件、Ant Task和Maven插件，拿过来非常的好用，强烈推荐大家用用看。
见文中的例子...
基于Bnd我们非常容易就把一个传统的java工程打包成了两个有效的OSGi R4的Bundle，从这可以看出这对于要把传统的java系统重构为基于OSGi的系统会有很大的帮助，除了打包生成Bundle外，Bnd本身还具备了校验bundle是否符合OSGi R4规范、把新的文件或jar文件添加到
阅读全文
摘要: Peter(OSGi主席)在7月3日的一篇blog上展示了一个很有趣的演示，相信可以给公众很好的展示下使用OSGi是一件很好玩的事，很简单的快速的基于OSGi搭建出各种各样不同的系统，我知道也许你会说你们的系统也可以，但你觉得真的能做到和基于OSGi所做出的系统的效果一样吗，really？如果可以的话，非常恭喜你，你对模块化、动态化都有很强很深的认识，如果不可以但又想做到这种效果的话，我觉得不妨和Peter所做的一样试着Play OSGi。
阅读全文
摘要: 由于当时匆忙的发布，没有进行仔细的校对，发布的EventAdmin部分的代码中缺少了使用DS实现的示例，但同时在其中又提供了OSGI-INF/component.xml，导致了如果大家直接使用该Component.xml切换为使用DS来实现EventHandler的时候会出现运行时事件未通知到EventHandler的现象。
阅读全文
摘要: 在本届EclipseCon 2007大会上，OSGi占据了不少的Topic，下面就对本次EclipseCon 2007大会上OSGi相关的主要的一些Topic简单的介绍下，最后总结下通过本次大会形成的反馈(信息来源于OSGi官方网站blog和EclipseCon 2007官方网站)，关于EclipseCon其他方面的精品Topic在后续的blog中也将相继介绍。
阅读全文
摘要: Peter在2月23的时候在OSGi的官方网站上贴了这么一篇blog，挺经典，至少让我学到了一些东西，建议关注OSGi或者关心系统设计中资源管理的人都看看，在这篇blog中我简单的将peter写的blog的意思大概写一下，也不全部翻译了，另外说一下自己的看法。
如果感兴趣的话，请同学们去查看Peter的这两个帖子：
http://www.osgi.org/blog/2007/02/osgi-extender-model.html
http://www.aqute.biz/Snippets/Extender
这个OSGi Extender Model给了我们什么启示呢：
1、Declarative方式的使用
Declarative无非是现在一种非常非常流行的软件设计理念，在这样的理念中，可以尽量的保证当前组件的简单，而通过Declarative的方式去增强的描述该组件，其实在spring中最重要的也是这个思想，而在OSGi的DS中也是这么一个思想，声明式的编程自然让整个系统的体系变得非常的简单和灵活，并且大大提升系统组件的可
阅读全文
摘要: 搭建动态化的系统是作为java开发人员一直就非常追求的目标，一个系统能够动态化就意味着：
★ 添加新功能时不需要重启系统；
★ 修改已存在的功能时不需要重启系统；
★ 删除一些不需要的功能时不需要重启系统；
★ 修改系统中的配置时可以不需要重启系统即刻生效；
★ 系统的业务行为可动态的改变。
也许习惯了传统java开发方式的人而言，没有这些动态化也没什么，但不可否认，这些动态化的特征还是非常吸引人的，尤其是如果能很容易就获得这些好处，那么自然就不会错过这些好处了，基于OSGi可以很容易的让我们获取到这些好处。
阅读全文
摘要: 作为一个桌面应用的开发者，向RCP致敬的理由会是RCP提供了丰富的界面控件，使得基于Java开发桌面应用也变得容易了很多，尽管仍然不能和基于VB、Delphi去相比；对于我而言，尽管使用RCP也是为了开发桌面应用，但RCP给我带来的更多的感觉是在它充分发挥插件化系统的优势方面，RCP可以视为基于OSGi构建插件化系统的最佳实践的指导，从RCP的设计中，可以学习到如何让应用做到模块化、让应用做到动态化，甚至还可以学习到象如何自动生成界面这样的细节设计思想，尽管我自己基于OSGi做应用型的产品也做了一段时间了，但自己仍然一直感觉到在发挥插件化系统的优势方面还有不小差距，RCP可以看做是基于OSGi做插件化应用系统的最佳实践，其中的不少设计方法甚至都可以整理成为基于OSGi做插件化应用系统的设计模式，让我们进入RCP之旅，揭开面纱，一探其本质吧，相信大家在了解了RCP的设计思想，看过其代码后，不得不对RCP表示崇高的敬意，大师之作，不同凡响。
阅读全文
摘要: 上午在普元的网上培训的地方和业界的朋友们进行了OSGi的交流，PPT在我之前的blog中已经提供，大家可以通过以下网址来下载今天演讲时的全程录像(带声音)，PPT：
http://www.osgi.org.cn/opentopic/OSGiInAction.rar
其中的会议全程录像就是带声音和演示的东西，感兴趣的同学们可以下去听听、看看，欢迎大家多交流。
这次的演讲主要就是一个介绍，讲的都比较粗，没有细致的去讲其中的东西。
阅读全文
摘要: 新年即将来临，Peter在OSGi的官方blog上对OSGi 06年的发展进行了回顾，同时也就07年OSGi进行了展望，在这篇blog中我也对一年以来OSGi的发展、自己在OSGi方面的工作以及对于明年OSGi的期望也做些阐述。
阅读全文
摘要: 12月30日下午13:00--15:00我将在普元goCom社区举行一次OSGi Topic，欢迎感兴趣的O粉(OSGi Fans)到时前往交流和讨论，由于这是在网上首次进行的公开Topic，鉴于对听众群不了解的情况，本次Topic主要仍然是宣传和推广OSGi，所以基本上只是OSGi的一些简介，以下列出了大纲和PPT的下载地址。
阅读全文
摘要: 之前也写过关于Service-Oriented Component Model的blog了，Service-Oriented Component Model(以下简称SOCM)是OSGi R4中最为重要的改进，SOCM也是切实体现OSGi的动态性的模型，大家在使用SOCM的时候可能会因为受到原有思想的影响而一时无法理解，在这篇blog中将再次的对SOCM进行讲解，以便大家能够更好的理解和进行运用。
阅读全文
摘要: EclipseCon2007中OSGi主题部分的Long Talks均已提交，虽然尚未确定最终哪些Topic将会入选，我们可以先一睹为快，此次总共提交了16个Topic，让我们来看看这些Topic：
阅读全文
摘要: 在之前的一篇blog中我曾经写到过CM对于application level的configuration的不适用，提到的主要是两点：
1、无法在外部统一的对Bundle中service所需要的属性进行管理；
当时基于这个约束，只好在各自的bundle下编写一个管理当前bundle属性的服务，当外部需要管理此bundle的属性时，必须通过这个服务来管理，否则的话改变是不会起到效果的。
2、无法共享属性的配置。
每个bundle都保存自己独立的一份属性配置，这就导致了当出现共享属性时，在管理端也不得不同时去重复的更新多个bundle。
经过对于Equinox的CM实现代码的查看，发现我冤枉CM了，现在给它平反，:)
阅读全文
摘要: EclipseCon 2007中将会有关于OSGi的专题Topic，经过一段时间的Topic征求后，目前公布出来了一些Topic供大家投票，以确定到底哪几个Topic会在明年的EclipseCon上登场，稍微看了一下，基本上都属于初级的介绍，没有什么深入性质的探讨，毕竟OSGi在国外目前也只是处于开始流行阶段，顺便提一下最近OSGi EEG倒是有不少的动作，相信近期会有一些他们活动的结果公告出来。
在这篇blog中将介绍下这些参加海选的Topic....
总体而言，无论这里面哪些Topic会成为EclipseCon 2007的正式Topic，它们的讲述必将为OSGi的推广做出贡献，支持谁，就赶紧为它投上一票吧，移动、联通、小灵通用户均发送至OSGi，哈哈
回到正题，给Topic投票必须是EclipseCon网站的注册会员，或者你可以直接发邮件给peter，:)，具体投票的地址请见：
http://bundles.osgi.org/Conference/Tutorials
阅读全文
摘要: Peter对于JSR 277是极度的关注，毕竟JSR 277和OSGi在实现的目标上具备了那么多的共同性，从98年JSR 277开始，Peter就希望能加入JSR 277 JCP Group，但是被拒了，JSR 277基本完全是SUN在主导的，经过这么多年了，JSR 277的草稿终于是发布出来了，Peter在对JSR 277做了Review后特意写了篇Blog做了评价，总结而言，Peter认为JSR 277 just like a toy,JSR 277并没有吸取OSGi在这8年模块化方面的教训和经验，在模块的一致性校验、可选性、分离包机制等等方面都缺少足够的考虑，原文见：
http://www.osgi.org/blog/2006/10/jsr-277-review.html
阅读全文
摘要: 关于OSGi、SCA的最新的一些消息。
阅读全文
摘要: 发了封关于SCA和OSGi的mail给OSGi-dev的邮件列表，收到了Peter的回应，Peter的回信如下：
"What the EEG will do depends on its members ...
I think there is a lot of excitement about SCA and OSGi. I also just
read it and agree that it seems very complementary. But we need people
that can drive the work."
目前还没收到EEG成员的回应，估计他们可能不在这个maillist里吧......
阅读全文
摘要: OSGi和SCA到底能有什么关系呢，确实，至少从现有的OSGi规范以及SCA规范分别来看，两者没有直接的关联，由于OSGi规范是对于嵌入式领域的软件而制定的，其特别注重软件的动态性的支持，而SCA规范是对于企业应用领域的软件而制定的，并且是基于SOA的，其特别注重对于企业应用而言的基础设施的实现，同时又尽量的去屏蔽对于SCA容器使用者而言SOA带来的技术实现细节的难度；但根据OSGi规范以及SCA规范，同时又能发现两者有个共同希望解决的问题，那就是规范的模块化，这是OSGi规范和SCA规范中的一个共同目标。
阅读全文
摘要: SCA无疑是目前业界最为火热的词语之一，粗略的翻阅了一下SCA V0.9的规范，先不论SCA的商业因素，不得不感叹于SCA确实可以称为企业应用开发的利器，而SCA的野心也是从目前的规范中可见一斑。
阅读全文
摘要: OSGi的CM就是Configuration Admin Service，是用于管理Bundle属性、并在属性发生变更时通知相应的Service，但在实际的使用中发现OSGi的CM规范缺少对于共享属性配置管理的支撑。
关于模块的耦合上只有个小小的想法讨论下，就是做为设计师你能否很快的告诉别人搭建你其中的一个模块的工程需要哪几个模块的支撑，或者最好就是运行检验你其中的一个模块的功能需要哪几个模块来支撑，当然，这个在基于OSGi的系统更容易来做到，不过这个确实是设计时很关键的一个地方，这既反映了系统中模块的耦合性，更体现了系统的扩展性以及系统的组装耦合上是否合理。
阅读全文
摘要: OSGi联盟的主席Peter做了这么个小东西，原理非常的简单，在现在传统的使用ajax的方式多为通过js直接调用Spring中的bean，那么peter做的这个小东西就变成了js直接调用OSGi中的service，基本上没有什么难度，只是玩了一把ajax的东西，估计是peter以前对这块接触的少，peter把他做的这个东西放到他的Nokia E70上跑.....
阅读全文
摘要: 模块的可扩展性是模块设计时需要重点考虑的非功能特性，对于框架而言，扩展性的设计则更加的重要，框架需要通过不断的扩展来充实其基础设施，构成真正的应用系统。
模块的扩展主要有两种，一种为扩充功能的扩展，另一种为覆盖性质的扩展，当然，本质上而言是可以把这两者进行合并的。
在模块的扩展上Eclipse的扩展点的设计方式无疑是支撑模块可扩展的经典设计方法，到现在为止仍然是如此，基于Eclipse的扩展点的设计无论是对于扩充功能的扩展还是覆盖性质的扩展都支持的非常好，这个经典的设计也是RCP得到那么多client side app的原因之一，尽管OSGi中并没有定义这方面的规范，但做为OSGi R4的RI的Equinox考虑到更好的支撑Bundle的扩展就引入了Eclipse的扩展点的设计，在现在的Equinox中我们仍然可以基于Eclipse的扩展点的方式来支撑模块的可扩展性。
但是否有别的方法呢？一定需要Eclipse的扩展点的方式吗？其实个人觉得基于OSGi的Service就已经天然的构成了一种可扩展的设计，为什么这么说呢？
阅读全文
摘要: 在企业应用中，持久化无疑是其中非常重要的一环，尽管OSGi的规范中也有负责持久数据、属性的服务规范，但对于企业应用而言那些显然是不够的，这里就以目前Java界流行的Hibernate为例来看看如何集成Hibernate到OSGi中，使得我们能够很简单在OSGi中使用Hibernate进行持久化。
阅读全文
摘要: OSGi越来越风行了，得到的关注越来越多，这本来是好事，但听到的越来越多的声音都是认为OSGi对于B/S、企业应用支持的太不够，怎么说呢，这些声音挺好，至少说明发出这些声音的人肯定是想过将OSGi应用到自己的项目/产品中去，虽然这是好的，但我觉得更多的原因还是很多的人都习惯的以一种框架的观点去看OSGi，这对于OSGi而言或多或少有些不公平，为什么这么说呢？
阅读全文
摘要: 最近一段时间，OSGi这个词在业界出现的频率已经越来越高，其受关注的程度也已经在大幅度的增长，当然，这其中不可否认OSGi联盟、Eclipse、IBM等的推广，但这主要当然还是得益于OSGi在规范的模块化以及动态化的管理的领先优势，但也会发现，很多厂商以及很多人对于OSGi仍然处于观望阶段，这主要还是因为OSGi在企业应用上目前尚无太多案例的原因，但OSGi就真的不适合企业应用了吗，还是别的原因让这么多的厂商、这么多的人对OSGi只是处于观望的阶段呢，应该说，主要原因应该是OSGi目前对于企业应用缺少足够的基础设施，OSGi联盟显然认识到了OSGi在企业应用上的不足，9月11日OSGi联盟对外正式宣布了EEG(EEG的成员包含了IBM、BEA等各大厂商)的成立；而Spring与OSGi的结合更是很好的推动OSGi进入企业应用。那么，就现在的OSGi规范来看，它离企业应用到底还有多远呢：
阅读全文
摘要: 规范的模块化开发是需要OSGi的重要理由之一，模块化的开发方式一直就是现在的主流开发方式，但业界却一直缺乏这样的标准，当然，如果java本身具备这样的标准自然就更好了，那么大家就会很自然的以同样的方式去设计、开发和部署模块，但目前java暂时还没有这样的标准，虽然之前的JSR 277(Java Module System)的目标是制定这样的标准，但由于该标准制定完后并没有得到业界和各大厂商的认可，所以基本上没起到什么作用，而现在JSR 291的认可则更是触动了它，目前的情况看下去，OSGi成为下一个版本的Java Module System JSR只是时间的问题而已，整个业界能够采取统一的方式进行模块的设计、开发是非常重要和有意义的事，这也是OSGi得到IBM等大公司支持的重要原因之一，说了这么多背景性质的话后开始来看看OSGi是如何规范化模块的开发的：
阅读全文
摘要: 在OSGi的官方网站的blog上Peter Kriens(OSGi主席)贴了一篇关于Spring and OSGi的blog，呵呵，peter在blog里写的还真不客气，直接说以前只是听说过spring而已，但基本上没任何了解，不过peter毕竟是高人，稍微看了后便准确的点出了spring的两个核心：解决依赖和组装的配置方式以及POJO的动态增强，Peter在blog里提及到在OSGi R5中将考虑如何让现有系统无需改动移植至OSGi平台中，这点非常令人兴奋，不过R5估计还早，最近OSGi R4.1倒是准备release了，目前还没得到关于4.1对比4的改进的信息，在blog中，peter也提及他认为目前Spring and OSGi的很多实现过于繁琐，于是之前他和spring-osgi的几个人员碰面重新考虑了这块的设计，这可是非常好的事，OSGi的开发人员的视角和企业应用的开发人员的视角确实会有很大的不同，两者的碰撞还是能产生不少火花的，通过那次讨论，Peter认为OSGi的服务注册/寻找机制可以很好的和spring的applicationContext机制做结合，他觉得现在这样的改
阅读全文
摘要: JSR 291：Dynamic Component Support for JSR291，这个消息虽然有点旧了，不过还是同样非常的令人振奋，OSGi成功的进入了JAVA SE领域，在Java新版本中必然会越来越多的看到OSGi的影子，JSR 291的final版本将在9月1日发布，其实它的内容基本就是OSGi Core的内容。
OSGi对于Spring产生了重大的影响，这个从Rod Johnson本人的一段话以及之前Equinox中的"Declarative Services Vs Spring"邮件中可以看出很多：
阅读全文
摘要: 最近有好几个人都问了我这个问题，问的挺好的，在软件业界新技术层出不穷，做技术的人每天都要不断的学习新技术，在学习每样技术之前，自然是要知道为什么要学习它，说白点，就是得给自己一个理由，对于一个对OSGi完全陌生的人而言，学习OSGi能带给什么呢，给大家几个可选的理由：
阅读全文
摘要: 这个东西其实在以前的OSCAR项目中是有的，而现在处于Apache沙箱中OSGi R4的实现Felix也准备构建这个了，构建OBR其实和构建Maven 2、Ivy这些的Repository没什么区别，解决的都是方便其他的使用者通过仓库直接下到所需要的东西(OBR中提供的是Bundle、Maven2、Ivy中是jar)，最大的好处在于下载的Bundle或jar会根据其元数据信息去下载其所依赖的其他的Bundle或jar，这就大大方便了使用者了。
阅读全文
摘要: 正式版的下载地址为：
http://www.bluedavy.com/opendoc/OSGI_Opendoc.rar
压缩包中包含了OSGi Opendoc的PDF、随文发布的代码以及可运行包。
阅读全文
摘要: 每个系统中都会有需要配置的属性，而通常这些属性的配置都会是分散式的管理，而且很多时候都是不支持动态，在实现这些属性的管理(新增、编辑、删除、保存等)时总是要不断的做重复的工作，如果框架中能提供一个这样的基础设施那么对于系统的配置属性管理来说就会比较好了，这样的话系统中所有的属性配置就可以采用统一的方式进行配置、获取、管理和动态的更新了，如果能动态的管理系统配置属性的话，简单的动态改变系统行为也就自然的可以实现了。
阅读全文
摘要: 听说过OSGI的人基本都知道OSGI最早是为了移动设备、制造业生产线等嵌入式系统而制定的规范，而现在随着OSGI在桌面式软件、服务器端应用逐渐的被接受，OSGI组织也决定开始进军服务器端应用和企业应用领域，OSGI成立的EEG(Enterprise Expert Group)的关注领域主要是企业级应用的配置管理、类级别生命周期管理、分布式部署、国际化以及异构软件集成，在技术领域的目标是为企业级应用平台提供包括技术需求、功能规范、数据和元数据以及通讯协议在内的服务平台。
阅读全文
摘要: 是否能够真正做面向接口的开发，和系统所采用的容器或框架具有很大的关系，面向接口的开发最重要的就是解决系统的依赖问题，在这点上目前最成熟的解决方案莫过于IoC，IoC容器而言最成功的莫过于Spring，那么基于OSGI的话是不是会带来不同的视角呢，来看看这几个方面的例子：
阅读全文
摘要: C/S结构的软件的可维护性一直就认为是较大的问题，当然，在引入了自动升级这样的小功能就好很多了，这里谈谈C/S结构软件的可管理性，意思就是指Server对Client端的管理，在大多数C/S结构的软件中，并没有很强的管理性的概念，更多的面都是关注Server的业务处理、数据存储这些功能，当然，不一定所有的C/S结构软件都强调Server对Client的管理功能，来说说自己看法中的Server对Client的管理功能吧。
阅读全文
摘要: 这篇新闻令人振奋，OSGI被越来越多的商业产品认同和采用，在这篇新闻中提到了之前OSGI是被象Eclipse这样的重量级的开源产品而采用，而现在Apache的Tuscany工程也开始采用，还有之前提及的IBM的重量级的商业产品--WAS V6.1，现在Adobe大名鼎鼎的CS2产品中也开始使用Equinox，同时这篇新闻也提及到了部分这些商用产品之所以要采用OSGI的原因，最后提及到OSGI对JSR 294、JSR 277可能会产生的影响。
阅读全文
摘要: 代码参见code.rar，其中的classic目录放置了基于Equinox的实战部分的代码，其中的ds目录放置了基于ds重构后的代码，请从这下载：
http://www.riawork.org/opendoc/code.rar
同时还发布了一个可直接运行的环境dist.rar，解压后直接运行其中的run.bat，就可通过http://localhost:8080/demo/page/login.htm来访问用户登录验证模块，请从这下载：
http://www.riawork.org/opendoc/dist.rar
同时在收集到大家的一些意见以及自己对Opendoc的重新浏览后，做了少量的改动，都发布到了新的pdf中了，新的PDF仍然是通过以前的这个地址下载：
http://www.riawork.org/opendoc/OSGI_Opendoc_Preview.pdf
阅读全文
摘要: 这里的Equinox不是Appfuse的那个Equinox，而是Eclipse的Project(www.eclipse.org/equinox)，是OSGI R4的RI，具体大家可参考我之前发布的OSGI Opendoc预览版中对于Equinox的描述和讲解，而现在又有一个重量级的产品基于Equinox而构建，那就是WAS V6.1，这也就足以说明在IBM这样的大厂商心目中对于OSGI的认同。
WAS V6.1之所以要改为基于Equinox而搭建，它认为主要是为了提升WAS的组件化、灵活性、松耦合和简洁性，具体大家可参见此篇PPT：
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/advanced/help.jsp?topic=/com.ibm.iea.was_v6/was/6.1/Architecture/WASv61_Componentization/player.html
阅读全文
摘要: 本篇Opendoc按照学习开源框架的基本流程进行编写，从体验OSGI到基于OSGI框架的实战，到深入OSGI，完成对于OSGI从入门到深入学习的过程，最后对于OSGI的现状和发展发表些自己的看法和思考，限于笔者的水平以及时间，文内难免有些错误，还请大家不吝指正，也希望本文能作为国内OSGI的抛砖之作，引出更多的关于OSGI的Opendoc。
由于个人时间的关系，这篇Opendoc历经一个半月左右的时间才基本完成，在此先发布预览版，希望能够得到感兴趣的朋友们的指点，先谢了....
请从这下载：http://www.riawork.org/opendoc/OSGI_Opendoc_Preview.pdf
随本文的代码将在随后发布，请大家关注......
阅读全文