09 2006 档案
摘要: 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机制做结合，他觉得现在这样的改
阅读全文
摘要: 尽管这只是一个小项目，耗时也很短，但个人觉得这个项目的整个过程还是值得回顾的，项目虽小，五脏俱全，项目经历了两个小的迭代，迭代过程中经历了典型的需求调研、设计、开发&重构、集成测试过程，采用了现场客户、TDD等实践，这里就以第一迭代来对这个项目的过程做些总结：
1、迭代版本的频繁发布能很好的建立客户方对于系统的信心；
2、结合真实系统的调研能够更加准确的挖掘(引导)客户的需求；
3、简单而完整的设计过程和TDD能保证开发较好的完成；
4、把握设计的尺度，依靠重构来不断的提升设计。
5、提升系统的交互对于客户是直接而明显的帮助。
阅读全文
摘要: 表单是我们在实现应用时常用的，通常情况下多数的应用系统对于用户而言就是在于表单打交道，所以提升表单的交互能力是非常重要的一个环节，当然，交互其实很多时候和业务都是有关系的，就如很多业务表单需要的是快速录入的方式，这个时候如回车添加行、Tab快速切换到相应的域上都是非常重要的，在网上查了一下，没找到一个完整的交互性质的表单的Demo，非常的希望css高手们能动手搞一个这样的东西，这样以后大家就方便了，由于在现在的一个项目中用到了，就把自己做的一个具备了一定能力的交互表单放到网上，希望有高手能基于这个或者自己做一个能作为以后做表单时可参考的对象，在这个交互表单中，对于交互性主要提供了这么一些：
1、表单进入域时的即时提醒
2、回车增加行
3、星级评分
4、域值非法的提示
下载地址：http://www.blogjava.net/Files/BlueDavy/richform.rar
阅读全文
摘要: 简单的谈谈交互中重要菜单和工具栏按钮；
备忘javascript清空表格中行的问题；
备注动态创建的radio按钮无法选中的问题。
阅读全文
摘要: 在交互设计方面完全就是个外行，看About face那本书也是挺难看懂的，不过自己还是想在这里写写自己对于交互方面的一些想法，由于目前做项目/产品时还没有专业的交互设计师，现在自己在做项目/产品的时候根据自己的想法开始对系统的以下几个方面有所要求：
阅读全文