2005年5月25日
摘要: 这本书就是之前blog上写的《构建高性能的大型分布式Java应用》一书，书稿完成后，觉得本书更多的仍然是偏向讲解分布式Java应用的基础知识，以及我个人工作经验的一些分享，于是改名成了《分布式Java应用：基础与实践》，本书目前已送往印刷厂印刷，下面是目前的一些关于本书的信息：
1、封面和目录
http://bluedavy.com/?p=55
2、序
http://bluedavy.com/?p=60
3、豆瓣上书的信息
http://book.douban.com/subject/4848587/
阅读全文
摘要: 本PPT只介绍了在Sun Hotspot V 1.6.0中：
1、内存结构；
2、内存分代，如何控制代大小；
3、可用的GC，每种GC对于参数的不同使用，例如SurvivorRatio、MaxTenuringThreshold等；每种GC不同的内存分配策略和回收策略，但不涉及具体算法是如何实现的；
4、GC是怎么触发的，日志是什么含义；
5、怎么使用上面的GC；
6、GC Tuning，简单介绍了一些常见的GC调优的目标时的瓶颈、可采用的方法等。
阅读全文
摘要: 网络访问时，通常要做超时控制，要实现的好其实还是有些挑战的，欢迎大家围观code show，并提供你的改进代码，:)：http://bluedavy.com/?p=39
阅读全文
摘要: 本次交流在4月24日圆满完成，主题为关于JVM的那些事，撒迦@rednaxelafx给大家做了一个长达四小时的精彩分享，涵盖了javac、解释执行、c1、c2编译执行方面的知识点。
由于视频太大，感兴趣的同学请从以下地址下载，自行观看，:)，也欢迎看完后在twitter上，或在这里来进行讨论，blog迁移到了bluedavy.com，地址在此：http://bluedavy.com/?p=36
阅读全文
摘要: 摘自我那本6月份要上市的，但目前名字还没完全确定的书，由于书中涵盖的更多的为构建高性能分布式Java应用所需要的基础知识，也许改成了《通往高性能分布式Java应用之路》，主要是阐述下为什么大型应用需要SOA，以及eBay的例子，blog全文请见：http://bluedavy.com/?p=30
阅读全文
摘要: blog已转移至bluedavy.com，感兴趣的同学可以移步至此：http://bluedavy.com/?p=27
阅读全文
摘要: 3月30日Twitter在其engineering blog上写了一篇Unicorn Power的blog：http://engineering.twitter.com/2010/03/unicorn-power.html，写的挺经典的，按我的理解来讲下这篇blog吧，如有错误，请帮忙纠正，:)，blog已迁移至bluedavy.com，感兴趣的同学可以访问这个地址来查看全文：http://bluedavy.com/?p=25
阅读全文
摘要: 由于blog开始转移到bluedavy.com，感兴趣的同学可到此围观：http://bluedavy.com/?p=23，本篇blog从看一个超市发展的过程中，收银碰到的问题以及解决方案来阐述互联网的技术。
阅读全文
摘要: blog开始转移到www.bluedavy.com，因此感兴趣的同学请访问http://bluedavy.com/?p=18
阅读全文
摘要: 由阿里云龙浩同学牵头的杭州程序员圆桌交流，第一期主题为并发编程，把自己的经验也分享下，在活动结束后会公开此次交流的资料，具体PPT请见文中。
阅读全文
摘要: 在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的一些看法。
阅读全文
摘要: 本篇blog将讲述coroutine的一些背景知识，以及在Java中如何使用Coroutine，包括一个简单的benchmark对比，希望能借助这篇blog让大家了解到更多在java中使用coroutine的方法，本篇blog的PDF版本可从此下载：http://www.bluedavy.com/open/UseCoroutineInJava.pdf
阅读全文
摘要: 公历的2009已经过去，2010来临，不免俗的也对自己个人2009做一次回顾，同时对自己的2010做一次展望，希望自己的2010能过的更加精彩。
阅读全文
摘要: In product env,we always need to monitor gc trend or tunning gc based on gc trend,before sun jdk 1.6+,we can use GCViewer to visualize gc log to see gc trend,but it not support jdk 1.6+,so I write a free open source tool to visualize gc log produced by sun jdk 1.6+,now V 0.2 release,If you need,pls download from http://code.google.com/p/gclogviewer/.
阅读全文
摘要: In this blog,I'll test the coroutine supported on jvm,now famous is scala actor & kilim,this blog show the program reliazed with scala actor/kilim/java,let's compare these three program performance.
阅读全文
摘要: 在HPTS大会上，Randy Shoup放出的eBay的PPT有所改变，在原有的5个Architectural Lessons上又增加了5个lesson，从这也可以一定程度的看出当访问量、数据量、功能不断上涨后，碰到的技术问题也将继续发展，想必这也是eBay增加5个lessons的原因，eBay在技术方面的发展对很多互联网公司都有一些参考意义，毕竟它已经经历过了国内很多网站目前的阶段甚至是几年后的阶段，在本篇blog中就完整的来看看eBay的这10个lessons、eBay的应对策略以及我个人的一些推测。
阅读全文
摘要: 本书预计共八章，目前完成五章，由于本书需要涵盖Java分布式应用、高性能java应用、可伸缩的java应用以及高可用java应用四方面的知识点，编写的难度不小，因此在此先行放出目录和样章，希望能够得到大家的一些反馈，以保证本书的质量，目录&样章下载地址为：http://www.bluedavy.com/opendoc/bookpreview.pdf
阅读全文
摘要: 非常强烈的推荐下BTrace这个工具，用了后不得不说太强大了，BTrace简单来说，就是能在不改动当前程序的情况下，运行时的去监控Java程序的执行状况，例如可以做到内存状况的监控、方法调用的监控等等，官方网站上有非常多详细的例子，我不说太多，只在下面举一个简单的例子来说明它的作用，BTrace的User Guide请见：http://kenai.com/projects/btrace/pages/UserGuide。
阅读全文
摘要: 摘自《构建高性能的大型分布式Java应用》第六章，感兴趣的同学们可以看看。
GC策略在G1还没成熟的情况下，目前主要有串行、并行和并发三种，对于大内存的应用而言，串行的性能太低，因此使用到的主要是并行和并发两种，具体这两种GC的策略在深入JVM章节中已讲解， 并行和并发GC的策略通过-XX:+UseParallelGC和-XX:+UseConcMarkSweepGC来指定，还有一些细节的配置参数用来配置策略的执行方式，例如：-XX:ParallelGCThreads、-XX:CMSInitiatingOccupancyFraction等，新生代对象回收只可选择并行，在此就举例来看看两种GC策略在Full GC时的具体表现状况。
阅读全文
摘要: 和清华学子做了一次关于OSGi的交流，在此公开下这个PPT，:)，这个PPT是我写的最长的一个OSGi PPT,涵盖的内容主要是OSGi标准方面的知识以及Equinox使用的一些知识，感兴趣的同学可以下载下: http://www.bluedavy.com/opentopic/OSGi20094qh.pptx
阅读全文
摘要: 架构师接龙是《程序员》杂志最近推出的一个活动，活动方式为：每期一个提问嘉宾，一个回答嘉宾，并由回答嘉宾提出新的问题给下期的架构师，形成接龙，之前第一期是支付宝的冯大辉提问，腾讯的研发总监王速瑜回答，我参与的是第二期，这期会登在《程序员》0909期上，内容转帖如下，原帖为程序员官方上的：http://www.programmer.com.cn/727/，呵呵，都只是个人的片面理解做出的回答，也欢迎大家在此帖中继续讨论，:)
阅读全文
摘要: 这篇文章中总结了一些构建可伸缩性系统的最佳实践，总结的不错，于是翻译了下，原文在此：http://akfpartners.com/techblog/2009/08/11/scalability-best-practices/，翻译内容如下。
阅读全文
摘要: 在将Hessian从3.0.13升级到3.2.0时碰到两个bug和一个ClassLoader处理策略的改变的问题，在此记录下，希望能为使用Hessian 3.2.0的同学们提供点帮助，避免再走同样的弯路。
阅读全文
摘要: 几年以来，eBay在几个不同的大会上先后分享过几次关于eBay技术的PPT，在这篇blog中，就以这些PPT来以旁观者的角度分析下eBay的技术发展历程，不论eBay现在的业绩如何，不可否认，他们的技术还是挺强的，因此还是值得学习，eBay的整个技术发展历程从一定程度上来说可以认为是互联网公司的典型技术发展历程，基本上各家互联网公司都在走着类似的路线，只是各家选择的语言不同、具体的实现方案不同、细节不同，当然，思路是一方面，实现又是另外一方面，只有两者结合才能实现一个高可用、高性能和高并发的有海量数据的系统。
阅读全文
摘要: 这本书的名号有：国内第一本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中我们就来具体的看看。
阅读全文
摘要: 在这篇blog中放置了我收集的一些网站架构相关的PPT和文章，提供给大家下载，如果大家有相关的好的PPT、文章的话，也欢迎推荐给我，非常感谢，:)，这篇blog的内容也会随着我收集的东西增加而变化，同时也会增加我对于这些PPT、文章的看法和评价。
阅读全文
摘要: 把自己写的两篇opendoc和Book统一放入此blog中提供下载，避免占据我blog的两个置顶位，:)
阅读全文
摘要: 在使用OSGi时，有些时候会需要在OSGi容器外获取OSGi服务，加载OSGi容器加载的class，或者说需要内嵌OSGi容器，本篇blog以一个简单的例子来说明如何基于equinox实现OSGi容器的内嵌，或者说通过程序来启动equinox，同时也通过此例子展示下如何在容器外来获取OSGi服务以及加载OSGi容器里面其他插件的class，同时还会附送一个如何让OSGi容器里的插件能加载到OSGi容器外的类的方法。
阅读全文
摘要: 此次QCon北京大会为期三天，总体而言，精彩纷呈，尤其是第二天，完全将大会的精彩推至了高潮，让大家觉得值回票价，总结而言，这次大会是相当成功的，一次成功的大会不能缺少的有两个要素：知名的嘉宾和精彩的Topic，无疑QCon北京大会很好的把握了这两个要素。
知名的嘉宾，此次大会出现的嘉宾绝对足够重量级，看看Title就吓人了：Spring老大、ThoughtWorks首席科学家、Dojo creator、eBay搜索核心架构师、Amazon云计算战略师、淘宝首席架构师、支付宝首席架构师、豆瓣技术总监、优酷首席架构师、网易有道技术总监等等。
精彩的Topic，不是说嘉宾知名Topic就一定精彩的，不能不说，这次大会还是有些爆冷门的，嘉宾不是很知名，但演讲的Topic确实还不错，而且也不是说知名的嘉宾就一定能给出精彩的Topic，就像Martin Fowler这次的Topic，实在称不上精彩，总体而言，这次大会并不缺少精彩的Topic，来分享下我的收获。
阅读全文
摘要: JVM是Java程序的运行环境，因此对于JVM的掌握有助于理解Java程序的执行以及编写，尤其是运行时碰到的一些诡异问题，那么怎么样能考察自己对于JVM关键知识点的掌握情况，帮助学习JVM机制呢，在这篇blog中来探讨下。
阅读全文
摘要: 在产品中有碰到过使用LinkedBlockingQueue.poll时超时很不准的现象，关键是这不是一般的不准，如果只是一点点不准的话也就勉强接受了，例如指定poll的超时时间为100ms，但最终执行.poll这段代码就花费了8000ms的现象，这篇blog就是展示下通过一段小小的代码来重现这样的现象，毕竟没有重现是无法证明为什么会出现这样的现象的。
阅读全文
摘要: 本文摘自《构建高性能的大型分布式Java应用》一书，Garbage First简称G1，它的目标是要做到尽量减少GC所导致的应用暂停的时间，让应用达到准实时的效果，同时保持JVM堆空间的利用率，将作为CMS的替代者在JDK 7中闪亮登场，其最大的特色在于允许指定在某个时间段内GC所导致的应用暂停的时间最大为多少，例如在100秒内最多允许GC导致的应用暂停时间为1秒，这个特性对于准实时响应的系统而言非常的吸引人，这样就再也不用担心系统突然会暂停个两三秒了。
阅读全文
摘要: 记得自己在没有进入互联网行业之前，对于互联网行业并不怎么感冒，总觉得互联网行业的技术含量不高，没什么意思，值得进入互联网行业了，才明白，原来互联网行业的技术是这么的复杂，这么的困难，而构建一个拥有巨大用户量的系统无疑也会给自己带来更多的成就感，记得自己刚进入互联网行业的时候，才发现构建一个高并发、高性能、承受高压力、高度可伸缩以及高可用性的系统要掌握的知识体系是在太多了，而且这些知识体系根本就不是在学校或是google、网络中能够学习到的，于是当时就想，如果能有一本书全面的介绍构建这”五高“特性的系统需要掌握的知识体系，那将是多么的美好呀，毕竟很多的知识体系都是靠经验积累出来的，甚至可是说，是痛苦的教训等得出来的，但当然，要在一本书中完全讲清楚所有的知识体系，自然是不靠谱的，但我想我会尽量在书中表达出自己的一些观点、看法以及少少的经验吧，希望能够让更多的同学即使没有大型系统的实际经验，也能掌握到一些大型系统所需的知识体系，那么我心甚慰了，由于本书需要写的东西非常的多，预计在9月底完成写作，估计要到明年春节后上市，:)，以下先揭秘下本书的大概内容，也请大家多多提出意见。
阅读全文
摘要: 之前的Opendoc中没有涉及过此部分的内容，maven又是现在非常流行的java的工具，再加上到目前为止搭建OSGi Maven开发和部署的环境还是比较的麻烦，觉得有必要写篇这样的blog，:)，在这篇blog中来看下如何搭建一个比较好用的OSGi Maven开发和部署环境，看看我在搭建一个这样的环境中的痛苦历程。
阅读全文
摘要: 记得Martin大叔在《企业应用架构模式》中特别强调：“能够不分布式的应用就不要分布式”，这句话没什么问题，尤其对于做过分布式应用的人而言，就更会有深刻的体会了，但这个世界偏偏就没有那么简单，大多数人都会碰到分布式应用的场景，尤其是对于大型应用而言，从集中式步入分布式是不可避免的，只是也许是小型分布式的，也许是大型分布式的；也许是有高性能要求的，也许是没有的，在这篇blog中我们来看看java应用从集中式步入分布式后到底会带来些什么挑战。
阅读全文
摘要: XSS漏洞是网站漏洞中最容易出现的一种，至少现在的各大网站中基本都存在，传闻只有gmail是唯一一个完全不存在的，或者说攻击者没找出漏洞的，也许是因为XSS漏洞看起来危害并不是那么的大吧，所以基本上没有得到过太大的重视，从而也就造成了这么多的网站存在着一些很简单就能发现的XSS漏洞，在这篇blog中以我这个网站安全的外行人的角度来侃侃XSS漏洞攻击以及防范的措施。
阅读全文
摘要: 近来连续调试了好几天的代码，乐趣无穷，:)，在纯净的人和机器对话的时间中，充分的和机器不断的交流，最终共同实现功能，和同事说：“我喜爱调试代码胜过了写代码”，怎么说呢，我觉得调试代码能够充分让你将所掌握的知识发挥出来，考察自己解决问题的能力以及学习知识的能力，在这篇blog中来闲聊下调试代码。
阅读全文
摘要: 近期参与了几个大学的校园招聘，总体下来感觉还行，由于校园招聘需要面的人很多，差不多面试流程都形成模式了，在面试的过程中，有不少学生问过我，到底面试的标准是什么，不过每个面试官的标准都是不同的，所以也就注定了面试是会有些不公平的，是否对面试官的胃口会起到很大的决定性因素，当然，最重要的还是实力，很多学生会认为面试不公平，但我觉得这也算是从学校进入社会的第一课吧，工作后学生们会发现更多不公平的事，对于学生而言，无论是应届毕业的本科、硕士，我的面试标准都差不多，考察的为Java基础、Java框架、设计模式、互联网架构的了解，当然，在最后会问一些其他的问题，例如大学学习情况呀、一两年后对自己的期望呀、优势和不足、最近看过的技术新闻等等，在这些所有的问题的背后，考察的最重要的是基础掌握的是否扎实、学习能力、反应速度、抗压能力以及技术兴趣。
阅读全文
摘要: 在面试中，经常要评估面试者的java基础知识和其他知识的掌握情况，包括public/private/protected/默认修饰符、static/final修饰符、集合、字符串操作、对象比较、异常、设计模式和面试者经常使用的框架等，整理一下自己经常使用的评估方法，:)，抛砖中，希望能看到一些好的建议，让大家更好的学习java知识，同时也更好的判断人才，挖出真正的“金子”。
阅读全文
摘要: 随着OSGi近两年的迅猛发展，尤其是Java企业应用领域厂商对OSGi的认同，大家对于OSGi的新版规范的关注远远超过了之前的几个版本，近来OSGi终于是放出了传闻已久的R 4.2的Early Draft，其实从Early Draft来看，我觉得完全可以认为不仅仅是一个小版本的升级了，甚至可以认为是R5了，因为R 4.2增强的东西还是非常多的，其中就包括了大家期待已久的RFC119，不过没看到传说中的RFC66，有一丁点的失望，不过相信后面的Draft中应该会加上，:)，这样看来，R5更是值得期待了，让我们先来一起品尝一下4.2 Early Draft这道大餐。
阅读全文
摘要: 之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，:)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
阅读全文
摘要: 应该是差不多两个月前收到了这本书，一直到最近才抽出时间来看了下，这本书的开篇的第一题现在基本已经成了经典中的经典了，相信很多人都因为这个控制 CPU使用率的题从而买了这本书的，在我自己看过这本书后我同时相信买了这本书的人应该会觉得非常的值得，要写出合理实现需求、高性能以及大数据量的程序，数据结构和算法就成为关键要素了，这本书用简短的题目给大家回顾了一些经典的算法。
阅读全文
摘要: 不是专职做压力测试这行当的，只能是以自己的经验来以外行人的眼光来说说压力测试，压力测试并不仅仅是个压力测试的过程，而是一个相当系统的工程，我认为压力测试是为了让系统达到所期望的运行效果以及承受所期望的压力，这也就要求压力测试应该帮助性能调优团队，为其提供一定程度的指导，在这里我不将压力测试和性能调优分的那么清楚了，在我看来，压力测试过程包括了：明确压力测试的目标、构建压力测试案例、进行压力测试、分析压力测试结果、寻找瓶颈并进行调优以达到目标，在这篇blog中来细看下这几个过程以及常用的方法。
阅读全文
摘要: 这篇文章的第二部分在昨天也发布出来了，于是抓紧时间把它给翻译了。在这篇文章的第一部分中，作者结合自己的经验对如何构建具备良好的垂直扩展能力的Java EE应用做了讲解，在这第二部分的文章中，作者则对如何构建具备良好水平扩展能力的Java EE应用来进行了详细的讲述，常见的session复制问题，水平扩展中经常需要涉及的分布式文件系统、分布式缓存、分布式并行计算，全文读下来，作者基本指出了构建可扩展的Java EE应用需要了解的知识体系（如需深入的话还有必要进一步的学习，例如集群技术、通讯协议、线程、并发等）和平时实践中的一些注意事项，应该说是篇十分难得的好文章，值得推荐。
阅读全文
摘要: 这是一篇从TheServerSide上翻译过来的文章，很自豪这篇这么好的文章是一个中国人（从作者名字上猜想应该是中国人吧，:)）写的，原文地址为：http://www.theserverside.com/tt/articles/article.tss?l=ScalingYourJavaEEApplications，可以说，这篇文章写的是非常的不错的，这是文章的第一部分，探讨了如何构建可垂直扩展的Java EE应用，文中谈论到的让所编写的Java EE应用具备垂直扩展能力的几个关键要素，例如热锁问题、尽可能的缩短同步块、不要在static方法上加锁、多使用Atomic包、jvm内存不能设置的太大等，文中除了列了这几个关键要素外，还详细的解释了为什么不能做以及如何避免出现这样的现象，可以很明显的看出作者在这些方面是具备了非常丰富的经验的，因此这篇文章不仅仅讲述了可扩展性理论方面的知识，同时也很好的从实战角度进行了分析，之后我也会结合这篇文章来说说自己曾经碰到的垂直扩展场景的反例，同时也很期待这篇文章的第二部分，第二部分将探讨如何构建可水平扩展的Java EE应用，翻译的不好的地方还请大家多
阅读全文
摘要: 之前写了个简单的jsp做压力测试，没想到出现的一个问题是当压力比较大的情况，运行比较久的话会出现一个现象，就是jvm的内存几乎被耗尽，用 jprofiler查看会发现是有一个ConcurrentHashMap对象的内存一直在增长，而且没有释放的迹象，随后进入Debug模式，跟踪查找都有谁new了ConcurrentHashMap，因为测试场景中是个非常简单的jsp页面，发现只有jsp的Request session会创建这个ConcurrentHashMap，很久没写jsp了，猜测是request session的默认超时时间太长，所以导致高压力下(200并发，总共连续访问50万次，jvm内存1G)会出现内存一直没有回收的问题，后来打印了一下request session的默认超时(AS是jboss 4.2.2)，是半小时，如果这样的话确实是会有造成上面内存一直被占用的现象。
阅读全文
摘要: 在JBoss Remoting 2.2.2中存在这么一个bug，如果刚好客户端的timeout比服务器端处理时间短的话，就会出现客户端连接池中的连接被无故用掉一个的状况，而且是没法回收的，最终就会导致很快客户端的连接池被占满的现象，在分析JBoss Remoting 2.2.2的代码后发现了问题的所在，同时查看了下JBoss Remoting 2.4的代码，发现在2.4中此bug已被修复。
阅读全文
摘要: 性能调优无疑是个庞大的话题，也是很多项目中非常重要的一环，性能调优的难做是众所周知的，毕竟性能调优涵盖的面实在是太多了，在这篇blog中我们蜻蜓点水般的来看看性能调优这项庞大的工程都有些什么过程，同时也看看这些过程中常见的一些做法。
阅读全文
摘要: Java 5并发包的加入，给Java的并发程序的开发带来了很多的好处，在此列举一些并发编程中应该掌握的一些基础知识片断，这些片断基本都是由一些问题组成，在片段中没有直接写出答案，由于可用来解决这些片段的方法还是很多的，因此只是提到了解决问题可选方案的关键字，如果有需要进一步了解的话，基本上 google一下应该就能查出来了，不过就像之前有朋友说的，如果不是经常用的话，其实就算现在知道了也是会忘记的，这很正常，:)，不过我更认为那是因为知其然而不知其所以然造成的，很多东西如果知道原理的话，基本上还是可以记得很长一段时间的。
阅读全文
摘要: 精通这个词估计是在简历中最常见到的词了，简历上通常都充斥着精通struts2、精通java、精通hibernate等等词语，近来经常看些比较底层的书，越来越体会到精通这个词应该具备的份量了，也越来越理解以前朋友和我说的在国外工程和研究是分的很清楚的原因了，在这篇blog里来扯扯自己对精通这个词的看法。
先来看几个面试的片段，从中也许能看出些端倪，:)
阅读全文
摘要: 由于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，也可以说就是为了提供一个可用的服务框架，服务框架在系统中到底承担什么角色呢，为什么它会显得那么重要呢，如果要实现一个服务框架，不太可能从最底层做起，那么我们又需要怎么样去选择呢？
服务本身是个挺形象的名词，在系统设计中我们非常强调输入和输出，服务呢，可以说是更形象的去强调了这一点，每个模块都会对外提供一定的功能，而这些对外提供的功能我们就可以作为服务了，细到模块内，我们也会发现模块内各个类其实也是以服务的方式来交互的，在这样的情况下，服务框架自然就成了整个系统的核心基础框架，那么服务框架能帮我们来提供哪些功能呢，如果我们要实现一个服务框架，有哪些要素是需要考虑的呢，欢迎大家拍砖，多多交流！
阅读全文
摘要: 07年的最后一天了，回顾当年、展望来年已经是每年最后一天的惯例了，就像往年一样，07年对于业界而言仍然是高速发展的一年，新技术、新框架、新名词不断的在冒，不过对于自己而言，07年在新东西方面接触的不多，也许是现在更加的专注了吧，没有以前那么博了，:)，回顾的关键字自然也就锁定在自己感兴趣的领域：OSGi、SCA、Erlang、互联网应用、认识架构。
对于08年，有很多的期待：OSGi、互联网应用和深入架构。
阅读全文
摘要: 之前发布了一篇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
阅读全文
摘要: 这篇文档是erlang创始者之一的Joe Armstrong所编写的博士论文，由段先德翻译、邓辉审校，感兴趣的同学可以从以下地址下载：
http://erlang-china.org/study/joe-armstrong_thesis_cn.html
Erlang在业界已经引起了不小的轰动，通读了下这篇博士论文，翻译的质量很高，:)，所以读起来非常的顺畅，论文的内容对于erlang初学者而言绝对是堪称经典，写的非常的不错，点出了erlang的强项并详细的进行了解释，感谢翻译论文的段先德和邓辉的工作。
Erlang以天生的支持并发、分布式和容错而闻名，由于erlang的诞生是为交换机而服务的，因此在并发、分布式、容错、动态代码升级等方面是实现的非常好的，其目前主要是应用在erission的交换机上，这对于erlang的那些天生的特性也是个很好的证明。
通过阅读这篇博士论文，让我对了erlang有了部分的认识，由于目前尚未实践过，只能根据论文本身对自己理解的erlang做个阐述。
Erlang采用的是虚拟机的方式，这个虚拟机和java的虚拟机类似
阅读全文
摘要: SQLUnit是一个用于对存储过程进行单元测试的工具，其实也可以用于做针对数据库数据、性能的测试等，延续了xUnit家族的一贯特性和风格，只不过它的测试是以xml的方式来编写，但原则仍然和xUnit家族其他产品一样，强调的是输出和预期的比较，SQLUnit的文档比较的少，由于官方站上并没有提供类似其他开源工具的quick start guide，就写了这篇quick start guide以便大家快速的使用sqlunit，至于SQLUnit的高级用法还是得去多看看sqlunit.sf.net官方站上的文档。
为了让大家能快速的开始入门使用SQLUnit，将介绍SQLUnit环境的搭建、如何编写一个单元测试、如何运行。
阅读全文
摘要: 上次发布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
阅读全文
摘要: 在我现在的项目中出现了这么两个问题，大家可以来探讨下这样的两个问题的解决方法，:)
1、从开发环境到正式环境的部署/校验非常麻烦；
2、数据库的频繁移植/校验非常麻烦。
我的解决方法：
对于上面两个问题，我自己想到的解决方法是：
1、建立持续集成机制，编写环境部署脚本和文档，采用这两种方法可保证从开发环境到正式环境的部署是非常简单的；
编写自动验收测试脚本，可以基于Selenium进行编写，这样每次在升级版本的时候就不需要再人工的进行回归测试了，这里面的问题是如何在测试完毕完毕后清除这些测试数据，因为这些测试数据是不能和正式数据共存的。
2、建立数据库升级移植机制，每次升级时做增量的升级，不过这需要建立在对原库建立版本记录，这个方法对于我们的项目而言不太可行；
第二种方案就只能每次进行全面的重新移植了，但这个带来的一个巨大问题就是存储过程的重复修改，目前我还没想到什么解决方法，而且；
至于如何校验数据库移植是否成功，我觉得可以建立数据库移植校验的Checkpoint，除了保证数据库结构、数据量等的
阅读全文
摘要: 这个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版本，这两个版本在精美程度上都会超过我现在发布的版本，到时再給予大家通知，:)
阅读全文
摘要: 软件架构的选择和设计并不是很容易做出的，一个成功的软件架构取决于N多的因素，软件架构这个词向来就是最为模糊的一个词，个人认为软件架构实在是个很大的话题，业界一直采用的形象比喻就是建设房子时的房屋结构图，以软件的角度来说，软件架构应至少包括软件开发时使用什么语言、形成软件开发时可运行的核心基础框架、软件应用模块的设计（包括模块内聚的功能、对外提供的服务等）、软件测试的方法、软件部署的方法以及团队开发的方法，那么怎么来选择和设计软件架构呢，其衡量的因素是什么呢，个人认为其中质量和快速是衡量软件架构的选择和设计是否成功的两个最重要的因素。
阅读全文
摘要: 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做出贡献。
阅读全文
摘要: 此次需要完成的目标是将库从SQLServer 2005完整的移植到Oracle10g中，包括表结构、数据、视图、函数以及存储过程的移植，移植主要基于Oracle的OMWB（Oracle Migration Workbench）来完成，尽管OMWB能帮助完成大部分具备难度的工作，但还是有很多工作量的事情需要在OMWB完成后来手工进行，所以整个移植过程工作量看起来会非常大，但是不是仅仅只有工作量的问题呢？我觉得不是，写下这篇blog以便需要进行此项操作的同学以及给自己做个备忘。
阅读全文
摘要: 《Oracle9i&10g编程艺术》即为《Expert one to one oracle》的升级版本，不过升级后可能会变为三本书，这本书强调的是深入数据库体系结构的讲解，本书的作者Thomas Kyte(即Tom)无疑是Oracle界最为知名的人物，而这本书可以说基本是专为开发人员而写的，因为我个人觉得书中讲的东西大部分DBA都是懂的，但对于开发人员来讲估计大部分都不懂，Thomas Kyte抓住了怎么给开发人员讲才能讲清的方法，对于书中的每项内容Thomas会讲解什么时候这么做、为什么要这么做、什么时候不能这么做以及为什么不这么做，要说服开发人员，很多时候除了告诉怎么做以外，还必须得告诉为什么要这么做，否则很难说服，而Tom在书中则很好的做到了这点，Tom会告诉你Oracle是怎么去实现的，所以你要这么做或者不能这么做，这本书除了让我学习到了更多的Oracle知识外，还让我更加明白了数据库在系统中的重要性以及充分发挥数据库的功能是多么重要的一件事，还有一个附加的好处就是让我们可以窥探到部分Oracle的设计，对于自己实现应用系统也是会找到一些可参考的地方，这本书写的实在是太好了，强
阅读全文
摘要: 向Peter Kriens问了一些自己比较关心的OSGi进展情况的问题，总结而言：
从Peter Kriens的答复来看，R5和EEG的工作成果生效还得等待较长的时间，好消息是SCA采用OSGi作为基础架构看来是非常的有希望了，这对于OSGi的推广是件非常好的事。
阅读全文
摘要: 说书评实在是没什么资格，:)，已经有将近半年的时间都没使用Ajax做产品或项目了，不过一直都在关注Ajax的发展和动态，应该说Ajax的发展在这两年以来非常的可喜，Ajax带来的web友好性的改变在各大网站已经开始显现出来了，这一切都是很值得高兴的，说回正题，记得是当时在做一个Ajax方面的框架，做的过程中开始看《Ajax patterns and best practice》，英文版本，碰巧从dlee那了解到他们正在翻译这本非常不错的书，后来从dlee那拿到了翻译后的草稿版，先睹为快了，记得当时看了翻译稿后就在我的blog上写了一些关于书中介绍的模式，主要是看书后的激动之情，顺便也为了大家先了解下这本书的内容，在《Ajax模式与最佳实践》上市后拿到博文的赠书，不过由于工作原因，一直没时间好好的翻看，最近才拿出书来仔细的看了看。
很久都没看技术方面的书了，大部分技术相关的东西都是要用的时候才从网上临时的翻阅，基本就是看些小文章，再加上自己是个典型的实战主义者，所以对书应该也是较为挑剔的，《Ajax模式与最佳实践》是本典型的实战书籍，而且无疑是ajax实战类书籍中的佼佼者，为什么
阅读全文
摘要: 在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。
阅读全文
摘要: 很久以前写过一篇关于产品规划的blog，结合最近在做产品规划时的一些感想再来写一些想法，产品规划涵盖的面非常的大，宏观上来讲涉及到技术部门、销售部门、售前部门等，细节上来讲涉及到产品每个版本的功能特性、销售、推广策略、销售对象、售后支持、产品定价甚至是产品包装的细节，所以在做产品规划时要考虑的较为全面，需要做到宏观以及细节层面的共同把握，本篇blog主要是对产品规划中的蓝图规划和版本规划做一些概述。
阅读全文
摘要: 在之前的一篇blog中提及到实现系统整合的方式有两种，其中一种就是通过建设综合系统来实现系统整合，近期经历了好几个这样的项目，来说说这种方式的项目的几个难点的地方，我是以整合厂商的身份进入此类项目，所以blog中更多的可能代表了整合厂商的心声。
在这类项目中，集成商的能力非常的关键，集成商的能力主要包括了技术能力、业务能力以及协调能力，这三种能力缺一不可，分别来看看这三种能力在此类项目中的重要性。
阅读全文
摘要: 整合项目难做，做过的人都是很容易知道的，这也是为什么整合项目通常要规划很久、实施很久，而且还要花费很大的财力的原因，在之前的blog中曾经写过整合项目难做的一些地方，像数据分析、客户的不够理解等。
随着对于整合项目实施的逐步深入，碰到的难点在逐步的增多，目前手头的一个整合项目接近完成了，对于这种类型而言的整合项目中的难点估计该出现的都已经出现了，总结下来除了数据分析这个大难点之外，还有的难点就是业务理解的不一致、系统设计的不一致和协调这三个，其实业务理解的不一致和系统设计的不一致可以列入数据分析这个范围，但由于这两点对于整合项目的影响较大，会很大程度影响整合项目实现的难度，所以还是单独列出来讲讲。
阅读全文
摘要: 在信息化建设上企业以及政府都投入了很多年了，多年的信息化建设使得企业以及政府拥有了很多套独立的专业的信息/业务系统，随着系统建设的完毕以及应用的深入，企业以及政府对于系统的依赖性在逐步的加大，企业以及政府慢慢的意识到多套系统造成了各套系统中的信息无法分享，也就是形成了常说的“信息孤岛”，企业以及政府对于信息的整合的需求已经越来越迫切也越来越突出了，尽管整合“信息孤岛”这样的概念各大公司(IBM、BEA等)在几年前就已经提出了，但应该说在几年前仍然是洗脑甚于实际，不过现在整合已经步入了实际阶段，也可以说是整合时代已经来临。
阅读全文
摘要: 这是一篇对于从事数据集成的实施、销售和售前人员的培训的PPT,较为简单，主要是讲解了数据集成类项目的概念、实现方法和通常采用的实施步骤。
感兴趣的朋友们可以到这里下载：
http://www.blogjava.net/Files/BlueDavy/数据集成项目培训.rar
阅读全文
摘要: 在数据集成类的项目中，最难的过程就是数据分析了，数据分析过程位于数据集成类项目整个过程(前期准备调研-----数据分析-----接口实现)的第二步，它为第三步接口实现提供了充分的准备，因此数据分析的正确与否很大程度上决定了数据集成能否成功的实现和完成。
怎么样有效的进行数据分析呢，怎么样提前在数据分析中尽量避免问题等到实现时才出现呢？这是一个行之有效的数据分析方法论的评判的关键。
经过几个项目的经历，反思了一下在做这些项目时比较有效的方法和失妥的方法，总结了一套目前个人觉得可行的数据分析方法，此套数据分析方法只适用于数据库---文件---数据库或数据库---数据库的分析，对于接口式的集成(例如调用对方的webservice、EJB接口等)并不适用，在这样的一套数据分析的方法中，为数据分析的步骤以及需要注意的问题事项提出了指导，编写此blog以希望有同行的同学们多多交流。
阅读全文
摘要: 话说上篇blog谈到了数据集成类项目的难点，在这篇blog中再根据数据集成项目/产品的特点来侃侃所需的人才，对于做数据集成产品的公司而言，通常都是走专业性质的产品公司的发展路线，在这样的公司中技术方向的组织架构多数为产品实施人员、产品技术支持人员和产品研发人员，那么根据数据集成类项目的情况来说，这些人才都需要具备些什么样的能力呢，产品公司又应该给这些人才提供些什么方面的培训呢，借此篇blog做个总结，同行的同学们多多交流。
阅读全文
摘要: 经过之前几年各大厂商对于应用整合的概念的大肆推广、吹嘘，近两年来随着各企业/单位的基础系统的建设完善，应用整合类项目开始步入实质阶段，而数据集成就是目前应用集成类项目中一个重要的部分，那么数据集成类的项目它的难点通常会有哪一些呢，根据自己的经验稍微的进行了些总结，希望从事相关工作的同学们多多交流。
阅读全文
摘要: 不知道很多正在创业、已经起步或者想做中间件厂商的同学们会怎么看待这个问题，中间件厂商到底有多难呢，它的难处到底又在哪里呢，为什么中国一直以来就很难诞生一家比较好的中间件产品的厂商呢，在这篇blog中想谈谈自己的一些感受。
阅读全文
摘要: 由于当时匆忙的发布，没有进行仔细的校对，发布的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中也是这么一个思想，声明式的编程自然让整个系统的体系变得非常的简单和灵活，并且大大提升系统组件的可
阅读全文
摘要: 去年带了几个新人，越来越觉得软件开发这行还是需要一定的"天份"的，其实每行都需要一定的"天份"，每个人都有自己最为适合的行业，特别是技术行当而言，如果真的希望在软件的技术领域有所发展的话，勤奋、吃苦的精神固然是必须的，但以下的几点素质却是基本的，而有些我觉得完全是靠天生的，或者后天小时候的努力才能培养出来的，如果不具备的话，我觉得这样的人就不是很适合从事软件技术行业：
1、逻辑思维能力
2、举一反三能力
3、自学、独立解决问题的能力
4、对软件开发的兴趣
阅读全文
摘要: 搭建动态化的系统是作为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：
阅读全文
摘要: 置换模式，引用即将出版的《ajax模式和最佳实践》(也就是《ajax patterns and best practice》)中对于它的意图的描述：
“置换模式(Permutations pattern) 被服务器用来分离资源(URL)与表现(例如HTML或XML)。分离资源与表现使得终端用户只需要关心资源，不需要担心URL所关联的内容。例如，假如一个客户的银行帐号是URL http://mydomain.com/accounts/user，那么相同的 URL 能够被各种各样的设备 (电话，PC等等)来使用。”
阅读全文
摘要: 一眼看过去相信大家都知道用Runtime.getRuntime().exec来调用，我的需求就是：
调用Oracle EXP命令完成备份，并返回生成的备份文件名，这个备份文件会很快在其他的地方被使用。
采用Runtime.getRuntime().exec我们都知道，需要处理它的InputStream，以避免出现执行的命令输出的信息过多使得进程被堵死，OK，按照这样的方法写出来的代码执行后却碰到了问题.....
阅读全文
摘要: 在之前的一篇blog中我曾经写到过CM对于application level的configuration的不适用，提到的主要是两点：
1、无法在外部统一的对Bundle中service所需要的属性进行管理；
当时基于这个约束，只好在各自的bundle下编写一个管理当前bundle属性的服务，当外部需要管理此bundle的属性时，必须通过这个服务来管理，否则的话改变是不会起到效果的。
2、无法共享属性的配置。
每个bundle都保存自己独立的一份属性配置，这就导致了当出现共享属性时，在管理端也不得不同时去重复的更新多个bundle。
经过对于Equinox的CM实现代码的查看，发现我冤枉CM了，现在给它平反，:)
阅读全文
摘要: 此模式出自《Ajax patterns and best practice》，这个模式非常具备实际意义，为客户端的缓存实现做出了指导，和以往在使用传统B/S结构进行开发时所做缓存的思路有一个改进点，:)。
阅读全文
摘要: 界面设计，一个在软件行业非常尴尬地位的东西，但是绝对离不开的东西，不过在软件行业的技术发展一直是为程序员们提供更佳的方式，而在界面设计方面则是在近些年来才逐渐的重视，但这并不意味着在界面设计上一直就做的很好，反倒在界面设计方面一直就是软件设计中最薄弱的环节，如果从软件设计的层面去看界面设计，N多的设计师都会看到其中犯的N多设计错误的基本常识，可以去想想为什么每次系统改界面总会是件那么痛苦的事，很多时候都是因为在项目/产品中缺乏专业的界面设计师而造成的。
在你的项目/产品中，是否有专业的界面设计师呢？
阅读全文
摘要: 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
阅读全文
摘要: 每个面试官随着面试经验的积累，都会逐渐的积累自己的一套面试标准，当然，这套面试标准也会随着公司的需求、业界的发展而不断的变化和发展，面试标准反应了面试官对于各种级别技术人员的技术要求，在以前的一篇blog中曾经提及过面试官应营造好的面试氛围，而这篇blog则会谈及自己面试时采用的标准来衡量面试者的技术能力，抛砖引玉，大家多交流.....
个人觉得面试标准主要由纯技术方面的标准和符合公司产品/项目技术要求的标准两部分组成，当然，还有一些是性格方面的要求，这篇blog主要谈及下技术方面的面试标准，由于面试多和公司要求、面试官的判断标准有关，所以通常来说不能因为没通过面试就认为自己没有这方面的能力，需要多尝试。
面试时对于面试者我会根据程序员和设计师两种大的标准来问问题。
阅读全文
摘要: 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的最新的一些消息。
阅读全文
摘要: POJO这个词无疑是这几年来Java界最为热门的词，各类框架都是以支持POJO形式作为其关键的特性之一，确实，POJO方式降低了开发的难度和门槛，让开发人员能够得以更加的关注和实现业务，而Spring也同样是依靠着"POJO Enhanced"获得了大家的认可。
阅读全文
摘要: 发了封关于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规范中的一个共同目标。
阅读全文
摘要: IBM认为一个完整的EAI的解决方案应当包括五个方面：用户交互、应用连接、业务流程整合、构建整合和信息集成。
在这篇blog中来探讨下EAI的应用连接，IBM对于应用连接的定义：通过 HUB 或总线架构，实现应用与应用之间的连接，完成相关的数据路由与数据格式转换，对于IBM的这个定义，非常的认可，在实际的EAI类的项目中，这也确实是个很实际的需要解决的问题，可能很多人仍然会认为EAI是一种炒作，好象也是没有什么做的成功的EAI项目，但EAI项目现在确实是存在的，而且在这块的技术、实施经验也是不断的成熟，EAI项目带来的意义更是不可否认，在这篇blog中将从应用连接所应对的应用场景、技术实现两个方面来探讨下：
阅读全文
摘要: 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机制做结合，他觉得现在这样的改
阅读全文
摘要: 尽管这只是一个小项目，耗时也很短，但个人觉得这个项目的整个过程还是值得回顾的，项目虽小，五脏俱全，项目经历了两个小的迭代，迭代过程中经历了典型的需求调研、设计、开发&重构、集成测试过程，采用了现场客户、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那本书也是挺难看懂的，不过自己还是想在这里写写自己对于交互方面的一些想法，由于目前做项目/产品时还没有专业的交互设计师，现在自己在做项目/产品的时候根据自己的想法开始对系统的以下几个方面有所要求：
阅读全文
摘要: 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的话是不是会带来不同的视角呢，来看看这几个方面的例子：
阅读全文
摘要: 这篇blog是继之前的一篇提升C/S结构软件的管理性的延续，在这篇blog中会更加的实际的去介绍基于Eclipse Equinox实现的一个插件框架，而不再是象上篇中那样的提及的想法而已了，通过这篇blog来展现目前一个这样的插件框架的实际应用的情况，为了更加形象的表达，在文中会贴出一些目前这个系统的截图。
阅读全文
摘要: C/S结构的软件的可维护性一直就认为是较大的问题，当然，在引入了自动升级这样的小功能就好很多了，这里谈谈C/S结构软件的可管理性，意思就是指Server对Client端的管理，在大多数C/S结构的软件中，并没有很强的管理性的概念，更多的面都是关注Server的业务处理、数据存储这些功能，当然，不一定所有的C/S结构软件都强调Server对Client的管理功能，来说说自己看法中的Server对Client的管理功能吧。
阅读全文
摘要: 大家都知道，xmlhttp在通信时采用的是utf编码，而国内很多网页的信息都是采用gbk编码，所以当直接通过ajax去连接网页，并将获取到的信息直接显示的话就会出现乱码的现象，有些时候无法改变服务器端网页的编码(例如获取别的网站的天气预报信息)，在这种时候就只能在客户端通过js做编码的工作了，下面这段js就是用于将服务器端返回的gbk编码字符串转换为utf编码字符串：
阅读全文
摘要: 对于搜索技术基本是完全不懂，在这里也只是谈谈自己的一些想法，欢迎大家讨论.........
阅读全文
摘要: 这篇新闻令人振奋，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
随本文的代码将在随后发布，请大家关注......
阅读全文
摘要: 在进行系统设计时，采取的通常都是逐级分解的策略，无论是分层、分模块都是典型的分而治之的策略，而系统在通过逐步分解形成架构、详细设计时，输入、输出以及扩展都是考虑的重点。
阅读全文
摘要: 发送动作是流程中的关键动作，程序或用户通过触发发送动作来进行流程的流转，对于人工干预的发送动作来说，通常会显得很复杂，做过类似办公系统的人都会体会到这点，发送为什么会变得复杂呢，首先发送是由多个步骤构成的，其次就是各个步骤都有一些用户可通过配置来改变发送步骤的行为的点，在人工干预要求很强的发送动作中，就变得更为复杂了。
请见正文......
在实际的流程发送动作中，还有更为复杂的情况，象抄送、传阅办理、跳转、会签等这些特殊类型的发送动作，实现起来就比上述的发送动作更为复杂，但其实现原理仍然类似上面所述。
阅读全文
摘要: 昨天重装系统，突然想到一个问题，如果以后机器本身只要装个微核，然后所有的东西都可以通过网络直接安装就好了，那样重装系统就不是件什么痛苦的事了，只要连接到网络上选自己需要的windows、office等等，平时在用这些软件的时候随时可以把个人的偏好上传到服务器，那是多么爽的一件事呀，^_^，也许可以做个这样的网站，提供这样的服务，和一站式的框架类似.....
阅读全文
摘要: 所思、所悟：
建立客户、领导的信心；
模块的扩展设计；
界面设计的重要性。
阅读全文
摘要: 本来是不想写这种blog了的，反正自己现在也不准备做项目经理了，但在近来项目中碰到的一些事情让自己产生了些想法，还是要写写。
阅读全文
摘要: 已经看完，觉得这本书是越看到后面越精彩，Joel的很多观点引发我的思考，觉得这本书对于技术人员而言绝对是本好书，会很大程度的调整看软件、做软件的观点，不废话了，继续写最后看的这部分的读书笔记。
阅读全文
摘要: 尽管抽象机制就象Joel说的一样，都是带有漏洞性质的，但是对于软件行业总体而言，应该说仍然是有利的，尽管它使得高手越来越强，而新手则越来越弱，抽象机制给业界带来的好处是很明显的，象Webwork、Struts、Hibernate等等，但这些东西同时也会带来一个问题，就是维护问题，特别是当整个业界的思想还没有同步的时候，就会变得比较麻烦了，不知道大家怎么看呢？
Internet时代的软件来临了？
觉得我们这代java软件从业人员是很幸运的，高度的抽象机制还在建立的过程中，有望参与到其中；软件的建设思想在改革中，web 2.0、OSGI；软件的商业运作模式在改变中，从传统的销售软件的模式改为internet软件商业模式。既然拥有这样的运气，我们是不是应该做点什么呢？.........
阅读全文
摘要: 继续读Joel on software，^_^，除了继续忍受中文版翻译的不佳外，还是享受着Joel的一些想法，痛并快乐着吧，好了，不废话了，这几天主要读了冰川下的密码到动机激励机制的几章，这几章引起的共鸣更强。
阅读全文
摘要: 缓存是在提升系统响应时常用的一种技术，在我之前的blog中也提及过好几次这部分的技术，今天还是想从缓存涉及的一些方面再次的去谈谈，在系统缓存上通常采用的是有页面缓存、处理缓存和数据缓存这三种具体的类别，应该说这三种缓存在实现上还是稍有不同，尽管底层的缓存实现是一样的。
阅读全文
摘要: 本来想等读完之后再来写读后感的，不过由于引起的共鸣或者说带来的感想确实不少，还是决定先写写，免得以后有所忘记，^_^
Joel on software不愧是jolt的得奖书籍之一，写的非常的不错，不过建议大家直接看E文版，不要看中文版，中文版翻译的实在不怎么样，给人的感觉根本就是直译的方法，象其中体现出不够专业的翻译的词到处都是，象连编、内用软件等等词，里面翻译的很多话都翻译的很晦涩，估计如果对joel讲的那个方面不懂的话，看中文版反而会完全看不懂...
Joel on software是本很薄的书，讲的主要是joel在软件方面的一些经验、想法、实践，joel是以前Microsoft Excel团队的领导之一。
目前看了大概一半，流水帐式的记录下读书的笔记.....
阅读全文
摘要: 插件开发框架其实和目前开源界流行的MVC框架之类的相同，都决定了基于这个框架的开发方式，如基于MVC框架，就会按照MVC思想来进行开发，而插件开发框架呢，也是同样如此，就要求基于插件的方式来进行开发，不过插件开发框架和MVC框架又有不同，插件开发框架是一个可以成为系统基础架构的框架，而MVC框架通常来讲不足以成为，如在目前的MVC框架Webwork、Struts上我们通常都需要加上Spring、Hibernate来构成系统完整的基础架构，这个时候由于MVC框架的实现是没有标准可参照的，就造成了在各种系统中形成了不同的但很类似的基础架构，但却造成了无法复用的现象；插件开发框架则是作为统一系统基础架构的一种开发方式，它使得系统的复用成为了可能，而同时由于插件开发框架对于动态性的支持，使得系统更加的灵活和可扩展。
来看看一个插件开发框架，应该提供些什么东西，作为改变系统架构思想的框架，插件框架需要考虑很多方面，如开发、测试、部署等，总结下来一个插件框架应提供插件的开发规范；插件开发、调试的IDE；插件的测试方法；插件的部署策略以及插件的管理端。
阅读全文
摘要: Ajax在带给我们提供良好的用户体验的情况下，还给我们带来了什么呢？
阅读全文
摘要: 最近用了下在php业界中非常出名的wordpress和mambo，使用下来的感觉就是这两个东西易用性真的太好了，功能方面同样非常的强大，实在想不出java界的CMS哪个能和它们进行对比的，引发自己的一些思考，java界的技术人员特别容易以技术观点去评价一个东西的好坏，觉得这就是为什么java界的论坛、CMS这种东西总是无法和其他语言体系的相比的原因，并不是说java界就真的做不出象mambo这样易用的CMS。
阅读全文
摘要: Foundations Of Ajax，Ajax领域中的经典书籍，还是决定看看，今天趁有些时间便翻阅了一下，总体而言，这本书写的还是不错的，在douban上我写了这么一段评价：“对于ajax新手而言，这绝对是本好书，可以快速的让你了解ajax涉及的技术，如何去使用ajax以及ajax的一些缺点；对于ajax老手来说，这本书固然有些简单，但我相信会带给你更加系统化的ajax知识。”
阅读全文
摘要: 之前公司招高程，估计面试了不下30个人，觉得面试别人其实也是一种乐趣，和各种不同的人聊天会让自己也学到很多，而且由于还是面试阶段，会更容易进行没有隔阂的技术交流，每次面试其实我都觉得是一次很好的技术交流机会，所以我很乐意面试，同时我也希望被我面试的人能够享受着这种感觉.....
阅读全文
摘要: 先简单的做了一个，结合TrimPath提供的JavascriptTemplate实现，目前的解决方案比较丑陋，通过xmlHttpRequest从服务器端获取模板文件，然后交由JavascriptTemplate结合数据解析形成最后的html。
阅读全文
摘要: 以前的自己一直认为做技术化性质的框架、产品是自己的职业发展之路，逐渐的慢慢而改变，发现以前的自己很陷入技术，不断的追求技术，而忽略了软件的本质，软件的本质是为了提高在某种工作上的效率，其实就是让业务能够更高效的完成，而要做到这一点，依赖的重点并不是技术，而是对业务的理解以及将业务转化为电脑化操作的能力，而这点是非技术能解决的，在业界可以看到很多公司，象浪潮，它在烟草行业的成功让人叹服，从技术人员的角度去看它的系统可能会觉得不过尔尔，技术人员往往会认为自己要做出一套这样的系统来不过是小菜而已，但事实是如果让你现在进入烟草行业，也许你做出来的系统从技术上是超越了浪潮，但从业务的理解上以及转化为电脑化操作的能力上能超越浪潮吗？这个不是一两年的业务积累就够的，^_^，从现在国内的软件业界的情况来看，我觉得大部分技术人员的最佳发展方式还是深入理解业务，这才是自己的优势，同时掌握将业务转化为技术的能力，这样的技术人员必将是强势的，这样做出来的东西才是有足够的竞争力的，软件是面向服务的，^_^，不要忘记了这一本质。
技术只是一种辅助而已，切勿反客为主.......
阅读全文
摘要: 为什么界面集成这么的麻烦呢，要做界面集成就是为了将动态性质的实现增加到静态的html上去，而这个步骤在现在还没有什么好的框架或者说好的IDE来支撑，导致了现在的这个步骤很麻烦，这也是为什么在做系统的时候很多时候最怕的不是用户所要的功能的变化，而往往是界面的变化，界面集成的这个步骤是这么的索然无味而且工作量奇大，怎么来提高这块的效率呢？
阅读全文
摘要: 在上篇RIAWork的简要介绍篇中，已经提及RIAWork的重要目标之一就是为界面和交互的灵活变化提供支撑，在这里来看看界面和交互在实际项目中的变化情况以及RIAWork是如何提供对于其变化的支撑。
阅读全文
摘要: 早上上班，就听闻用户评价系统代码写的很烂，作为programmer，听到这句话估计都有很不服的心理，但从用户评价系统的观点去看，就可以表示理解，在这个项目中尤其突出，用户最为看重的是系统漂不漂亮，操作起来是否方便，最后才是系统功能实现是否和需求一样，而事实证明，很多时候其实系统功能是已经实现了的，为什么他们还觉得和他们的需求不一样呢，问题出现在交互上，操作上他们按照他们的想法去进行，发现没法用，在这种情况下，他们就认为系统是不可用的，在系统设计的可用性上要引起足够的重视，这种看起来的小事往往容易造成客户对于系统的不信任和抵触。
阅读全文
摘要: 在现在的软件业界，我认为很大的问题是开发人员甚至是公司从来都没有真正的把用户当成上帝，当然，这和目前业界的项目有很大的关系，例如项目通常都是时间非常的紧张，N多开发人员投入只能尽量去保证功能、需求的实现，在界面以及交互上往往不是那么的重视，但其实业界很多成功的产品都证明，功能往往不是决定性的因素，界面和交互才是用户最为重视的，而且通常也是打败对手的重要地方，为什么项目中不在重视功能的同时去重视界面和交互呢，大都是因为现在的框架在界面和交互变化的支撑上都不是很好，导致了每次界面的改动都要花费很大的成本，而交互上则一方面是现在交互设计师急为的缺少，另一方面是还没引起企业足够的重视，所以其实我觉得在web应用开发框架上最大的目标就是为“把用户当上帝”提供足够的支持。
阅读全文
摘要: 动态产生的持久模型和数据存储，这个词语感觉挺晦涩的，不过估计在实际的项目中或者研发的产品中大家都碰到过这样的场景：
例如在一个简单的考试系统中，出题人在系统中出题，答题人进行相应的答题。
希望能发起讨论，总结出一个这样的设计模式，^_^，顺便还发起对于另外一个场景的设计模式的讨论，需要动态的扩展目前已有的PO或表，不知道在这个场景中大家会采用什么样的解决方案，预留字段？动态修改表？关联属性扩展表？抑或别的..........
阅读全文
摘要: 再次做项目，感觉颇多，项目和产品其实都有应对变化的部分，项目更在乎功能的实现以及对于需求的应变能力，产品更在乎的是通用性的高度抽象、开放性以及基础设施的建设上，产品比项目更依赖规划人员对于通用性需求的挖掘上，而项目则更依赖需求人员对于客户的需求的挖掘上。
阅读全文
摘要: 记录一下Maven 1升级到Maven 2、Hibernate 2.1升级到Hibernate 3的一些注意事项，^_^，以备后用，毕竟以前的系统很多都是基于Maven 1和Hibernate 2.1的。
阅读全文
摘要: 继续以OSGI R4的Declarative Services(DS)来讲讲Service-Oriented Component Model(SOCM)，SOCM对于现有的Component-Oriented Model或者是Service-Oriented Model来说到底有什么不同的地方，到底DS能给我们带来什么样的好处呢？
阅读全文
摘要: 目前做的一个Web开发框架，基于元数据和RIA，把现在所做的效果贴出来给大家看看，同时也简单的再说说基于元数据和RIA的开发，^_^
阅读全文
摘要: 做过Ajax应用的人都知道，在js端将后台的数据进行展示其实是一件挺麻烦的事，尽管操作dom不算太麻烦，但要和写一段html相比来说就显得太麻烦，而且难以维护了，所以我目前在做实现的时候不得已的采用在后台通过java+velocity模板的方式来生成html，再返回前端js，由其负责将html放入相应的container进行显示，在目前来看这种做法还算过得去，不过其实一种比较期盼的都是能有一个velocity for javascript版，这样我就可以直接把数据模型返回给js，在js端结合velocity模板直接渲染生成最后的显示效果了，那就比较爽了，^_^
阅读全文
摘要: Jeff在EclipseCon 2006那篇介绍Equinox的PPT中提到的Declarative Services(文中全部采用DS简称)的用法让人极度被吸引，但同时又产生怀疑，想起以前自己看过DS好像不是这样的，没这么强，便再次翻阅了OSGI R4中的DS的章节，以验证Jeff的说法，^_^，仔细看过DS章节后，确实为Declarative Services的强大而感到高兴，DS是一个面向服务的组件模型，从组件模型层次上去看，它超越了传统的组件模型，在组件模型描述的完备性上有了很大的进步，例如在组件服务的依赖上、组件服务的延迟加载上、组件服务的多样性控制上、组件服务的配置上以及组件服务的生命周期管理上，不过DS只能在OSGI容器中使用，这尽管看上去可能是个弱点，但作为OSGI规范中的一部分，这无可厚非，其思想值得很多目前Component Model的开源框架值得思考和学习，如感兴趣，请阅读OSGI R4中DS章节。
阅读全文
摘要: Hibernate获取数据的方式有不同的几种，其与缓存结合使用的效果也不尽相同，而Hibernate中具体怎么使用缓存其实是我们很关心的一个问题，直接涉及到性能方面。
阅读全文
摘要: 再次犯了没有仔细看Hibernate Reference的错误，在Hibernate 3以上版本都支持对于property设置lazy="true"，但一直我都以为只要设置了就可以实现的，今天和jindw讨论的时候才知道原来不是这样，^_^，赶快做了下试验，确实，即使对于property设置了lazy="true"，但在调用获取了po中的任意非主键属性时其他所有的property也就被加载了，也就是说lazy没有生效，到底怎么回事呢，翻阅Hibernate Reference才明白了这个问题。
阅读全文
摘要: EclipseCon2006已经结束一段时间了，最近才抽出时间去down下相关感兴趣的PPT来看看，受益不少，N多大师的演讲另人拍案叫绝，不过也有几个PPT让我看的有所疑问，摘录几个PPT的读后感，^_^
阅读全文
摘要: 在上一版的基础上进行了如下改进：
1、增加了事件参数传递的支持；
2、增加了事件、拦截器的有效范围定义的支持；
3、增加了事件、拦截器的清除的支持。
阅读全文
摘要: 在实际项目中使用Hibernate有两年多了，在两年多的实践过程中既体验到了Hibernate带来的N多好处，同时也碰到不少的问题，特写此篇文章做个总结，记录自己在Hibernate实践中的一些经验，希望对于新使用Hibernate的朋友能有个帮助，避免走过多的弯路。
阅读本文前建议至少拥有Hibernate的一些基本知识，因为本文不会去详细介绍相关的基本知识，最好就是先用Hibernate开发了一个HelloWorld，^_^。
根据自己所经历的项目中使用Hibernate所涉及的范围，本文从开发环境、开发、设计、性能、测试以及推荐的相关书籍方面进行讲述，本篇文档不会讲的非常细致，只是根据自己在实践时的经验提出一些建议，关于细致以及具体的部分请参阅《Hibernate Reference》或推荐的相关书籍章节。
此文档的PDF版本请到此下载：
http://www.blogjava.net/Files/BlueDavy/Hibernate实践.rar
本文允许转载，但转载时请注明作者以及来源。
阅读全文
摘要: 在上篇中简单的描述了下在我现在开发的东西中关于元数据的设计，在这篇中将结合目前实际的系统的截图来说明关于元数据的具体定义、UI方面的控制以及基于RIA和元数据的系统实现。
阅读全文
摘要: 分层与分模块开发，是开发时经常选用的两种方式，应该说分模块开发是较多被采用的方式，但一直以来都觉得其实分层方式自己是比较欣赏的方式。
阅读全文
摘要: 看了caoxg在广州Bea User Group上讲的《利用元数据和RIA简化企业应用程序的开发》的PPT，很有感触，说说自己对于其中几点的看法，同时也谈谈自己在现在的项目中的实际的关于metadata的做法。
阅读全文
摘要: 在采用Ajax进行系统实现时，通常会采用onepage的方式进行实现，自己目前也在一个实际的项目中使用着，总体感觉有几点是在使用onepage时特别要注意的。
阅读全文
摘要: 系统的不断抽象形成的接口实现与配置实现，系统的简易性、复杂性、可维护性到底是增强了还是降低了呢？...
阅读全文
摘要: Equinox，我不想多做介绍，相信很多人都有所了解了，不了解的可具体去www.eclipse.org/equinox看看。
最近基于equinox做了一个系统，还是碰到了一些问题，当然也得到了在插件体系架构下的不少优点，在这里也做个总结。
总体而言，基于equinox做开发对于大多数java开发人员来说应该不会有太多改变的感觉，最多改变的感觉应该是带给设计师，设计师需要有发挥插件体系架构优点以及减少其带来的缺点的能力，^_^
阅读全文
摘要: 每个团队都有它更为适合的软件工程，因此不可一概而论，谈谈自己对于XP以及重型软件工程象CMM这种更为适合的团队。
阅读全文
摘要: 写的一个比较简单的事件管理器，主要从这些方面进行的考虑：
1、实现事件的注册/反注册。
2、实现事件的调用。
3、注册事件的拦截器(方法执行前或执行后)。
目前写的这个版本还比较简单，后一步需要增加事件的有效范围以及事件的拦截器的有效范围的支持，就是scope的概念，还有一个需要改进的地方是将目前事件调用的部分改为COR模式。
阅读全文
摘要: 关注测试的几个方面：
1、测试数据/运行数据的互不影响；
2、单元测试；
3、集成测试。
阅读全文
摘要: 修改自blueidea上的windy2000提供的powertable.js，具体见：
http://www.blueidea.com/bbs/archivecontent.asp?id=697036...
修改的几个地方：
1、基于prototype.js进行了改写。
2、由外部传入需要增加丰富交互的表格的ID。
3、修正了列排序造成的表格行颜色的混乱。(如经常能见到的隔行颜色不同的表格，在排序后会有两行颜色在一起的现象出现)
4、修正了拖拉表头的功能。(之前的版本在页面中有通过js动态增加的元素的时候会出现拖拉不正确的现象，要么要拖到表头的上面，要么要拖到表头的下面)
5、修正了当css是通过js动态添加到head元素中的情况下的bug。(之前的版本会出现这个时候在点击行或拖拉行时颜色错乱的现象)
阅读全文
摘要: 介绍这方面的文章也有一些，我这里打算以一个demo来说明一下，也是基于prototype进行编写，javascript中的this看起来会和java中的this有些不同。
阅读全文
摘要: 学习使用prototype.js，关注于类的创建、继承以及事件机制的实现上，在事件机制上碰到了一些问题，监听和观察方面和预计的效果都不一样，这是为什么呢？
阅读全文
摘要: 总结，就是在同一个session内如果save了一个对象，再通过session.load的方式去取这个对象取出的将仍然是当前session中的对象，也就是说不会去数据库中重新获取...
怎么感觉这样是不太对的，明明数据库有改变，却没有去重新的加载...
阅读全文
摘要: 在设计时会碰到两种类型的设计，一种是框架级产品的设计，一种是项目产品的设计，在面向这两种进行设计时觉得还是非常不同的，框架级产品的设计强调一种通用性的抽象上，在这点上通常依赖开发或设计经验来进行抽象，难度不仅在此，通常框架级产品的设计都会面对技术性的问题，也就是说在设计阶段根本就是无法进行细化的一些部分，这种现象在框架级产品中通常出现，这时在进行设计时就要慎重考虑，通常按照敏捷工程的方法的话是先进行spike，spike后再进行相应的设计；对于项目产品的设计强调的是对项目需求的实现，这个时候通常需要的是业务角度的抽象，当然，这点也是具有难度的，通常来说项目产品上不会出现太多的技术难度，也不希望出现。
阅读全文
摘要: rife作为一个full stack rapid web development framework，对它还是比较感兴趣的，今天上rife的官方网站看了下rife的features，它提供了一个关于continuations介绍的quicktime movie，不错，把continuations介绍的还是比较清晰的，虽然影片很短，^_^，但点在了点子上。
阅读全文
摘要: Java界的开源产品多如牛毛，不掌握一定的方法论的话觉得一方面是学不来这么多的开源产品，另一方面则是根本就发挥不了开源产品的作用，一直以来我就推崇技术人员按照工具型人才--->思想型人才--->创新型人才的发展路线，所以我觉得学习和熟悉几种开源产品是必须的基本技能，但并不是说一定熟悉最新流行的开源产品，其实这个就象基于MS做开发的人员，最起码要熟悉的就是.net这些东西，只有先在熟悉这些东西的基础上才能形成更好的发展，一切都自己从底层摸起尽管会让自己学习到很多也会理解很深，但会走很多的弯路，基于开源产品能基于别人经验的基础上进行学习，这样自然会少一些弯路，而且其实这样是很容易形成自己的一些想法的。
阅读全文
摘要: 一直以来对于Acegi实现Domain Object Instance的权限控制就比较感兴趣，今天抽空大致的看了一下，感觉和我以前提出的数据权限那部分的实现是大致相同的。
阅读全文
摘要: 一直以来，各种行业都宣传要本着用户是上帝来服务，确实，真正做的成功的企业其实都取胜于这个原则上，软件行业其实同样如此，要把用户真正的当成上帝才行，就像MS，MS从很多方面都是在为用户考虑，不论是面向最终用户还是面向开发人员的产品。
阅读全文
摘要: 女娲造人，耳熟能详的神话，作为一个技术人员，不得不佩服女娲的系统设计和实现能力，^_^，人是一个极度复杂的系统，需要实现N多的功能，其系统的分解和设计需要有极强的抽象能力，女娲就像是一个伟大的架构师，同时又不仅仅如此，还是一个伟大的程序员，将系统实现的如此完美。
阅读全文
摘要: 数据驱动开发框架需要提供的功能以及简要描述的实现思路。
阅读全文
摘要: 界面对象化是指以对象的思想去描述页面元素以完成UI的集成和开发，以使UI原型能够映射或转化为可运行的系统原型，提升系统开发的效率，避免大量的花费时间在UI的集成、维护上。
阅读全文
摘要: 想改良一个烂设计为好设计吗？想增加或维护代码功能时更加简单吗？重构无疑是其中最好的方法之一，既然它是好的，我们就要把它发挥到极限，把重构发挥到极限的方法就像kent beck说的，采用两顶帽子的原则，工作中不断的交换帽子，^_^
阅读全文
摘要: 既然测试是好的，那就把它发挥到极限。
测试是好的，这一点无可厚非，几乎做软件的人都是认可的，本篇只是谈谈测试中的单元测试部分，单元测试的目的是为了保证类中的方法是符合设计时的需求的，需求驱动似的类实现，^_^
阅读全文
摘要: 既然认为它是好的，就要发挥到极限，这是XP的思想。
持续集成无疑是一种非常好的方法，那么在实际的软件开发过程中就应该把它的好发挥到极限，但就我自己经历过的项目以来，只在一个项目中真正的较好的实现了持续集成，不知道大家的情况是怎么样？持续集成的最出名的代表还是MS的Daily Build和冒烟测试了。
阅读全文
摘要: 回顾自己所经历的两个项目，来对设计阶段进行了总结，自己也算是个XPer，经历过的这两个项目也基本都是采用XP的方式进展，大家都知道，XP在设计阶段推崇的是群体设计，通过CRC来完成，在这里就对两个项目执行的情况做做总结。
阅读全文
摘要: 在很多的web框架中，经常会看到提供html元素的标签，例如在采用velocity作为显示层的很多web框架中就会提供诸如table、input等这些元素标签，提供这些标签的用意是很清楚的，就是为了能够统一整个web应用的显示形式和操作模式，但这些标签的提供却在很大程度上给UI集成带来了麻烦，想想本来只要UI设计师切割图片然后直接导为html的部分，变成了还需要开发人员去把页面所有的元素改为使用标签的方式，平白无故的增加了痛苦。
阅读全文
摘要: 为了提高系统的响应性能，一般都会采用缓存技术来实现，如果用象ehcache、oscache这样的开源的cache工具来实现，一般都需要由开发人员来设置maxElementsInMemory这个值，但这个值在设置的时候大家都是怎么去设置的呢？凭想像还是随便写一个值呢？这个值设的过大嘛有可能会造成outofmemory，设的过小嘛又浪费服务器巨大的内存，为了能够更好的设置这个值，我写了个测试程序来估算1M内存能够缓存多少个对象。
阅读全文
摘要: R4中增加了Declarative Service，简称DS，本来一直还没很关注，近来equinox maillist讨论的比较多，今天就又翻开r4来看了看，Declarative Service的提出就是为了解决之前在R3时对于service的调用比较麻烦的问题，^_^，不过觉得这也只是部分解决而已，现在支持了service的lazy load的概念，呵呵，但其实现在的问题同样很典型，新在采用的是通过ComponentContext.lookup的方式，多么象context.lookup，更是多么的象IoC 1，前段时间equinox maillist也一直讨论过引入IoC的问题，也不知道现在进展如何了，希望能快点看到引入了IoC 2 or IoC 3的方式，那样的话现在的service的引用就不会那么麻烦了......
阅读全文
摘要: 对于基于AJAX的开发与基于MVCFramework的开发的比较，同时提出基于ajax开发吸取基于MVCFramework开发的优点的方式。
阅读全文
摘要: 就设计文档的编写、意义来探讨设计文档。
阅读全文
摘要: 目前做的框架中对于数据驱动开发方式支持的Demo，如感兴趣的话可以下载过去看看，是flash版的，因为太大了，所以只能提供分个压缩包的方式。
阅读全文
摘要: Ruby on rails的流行让自己也忍不住去尝试了一把，毕竟能够号称比java开发快10倍，仅这点就够吸引人的了，初次使用下来，总体感觉就是和基于纯java的开发来比自然是强很多，毕竟ruby on rails是个web开发框架，但如果以基于java的web开发框架去对比的话我倒是不觉得java的web开发框架效率就比ruby on rails低多少，也许是因为自己对ruby on rails了解不够深入的原因。
阅读全文
摘要: 如何保证软件的质量一直就是令人头疼的事，这里列了一个自己实际运作的一套用于保证软件质量的方法，还望大家多加指点。
阅读全文
摘要: 昨晚看切尔西的比赛的时候突然联想到了软件开发，呵呵，来看足球赛：
1、根据比赛双方的实力、主客场、天气等等各方面因素来比赛双方都会制定自己的目标，战平、胜或别的目标。
2、需要在有限的时间内(90分钟)达成目标。
3、多种角色构成。(守门员、后卫、中场、前锋)
4、一定的阵型(4-3-3、4-4-2)和战术(防守反击、短传渗透、长传冲吊)。
5、多变的形式以及多种不定因素(裁判、球员状态等)。
阅读全文
摘要: 表现层组件的概念没什么多讲的，这里我主要讲表现层组件中的两个焦点问题：
1、表现层组件显示形式的控制。
包括对于表现层组件的显示形式(表格、列表)、显示样式(表格背景、悬浮等)、布局方式(组件中元素的摆放)等的控制。
2、表现层组件的事件响应机制。
阅读全文
摘要: 本文就Persistent层实现可采用的两种模式Dao Pattern & Command Pattern进行了简单的描述和对比。
阅读全文
摘要: 数据集表现层组件暴露对外的接口，组件可通过参数设置等方式来达到对组件的如下控制：
阅读全文
摘要: 近来带team的时候发现team中的人缺乏一种有效解决问题的思维，写代码出bug是很正常的事，关键是怎么去解决它，在解决问题时个人觉得比较好的顺序是这样：
阅读全文
摘要: 数据集(Dataset)这个概念相信对大多数人来说都不陌生，在.net中提供了很多数据集的表现层控件，最典型、复杂、实用的莫过于DataGrid，这里要讲的是数据集表格组件，相对DataGrid来说更为简单，在此系列中将阐述数据集表格组件的需求、设计、实现并将最后的效果进行截图演示，本文是系列的第一篇，主要讲述数据集表格组件(DataTable)的需求。
阅读全文
摘要: 担任系统设计师的职位一年了，尽管自己到现在为止仍然是个不合格的设计师，虽然这一年以来也不是完全从事设计的工作，但毕竟站在这个岗位上，主要从事的还是系统设计方面的工作，加上自己也有志于在这个方向发展，所以做一个年度总结是有必要的，也希望能对希望进入设计岗位的朋友们有些帮助，同时也希望得到在设计岗位上有经验的同行们的指点。
这也是自己真正担任系统设计师这个岗位的第一年，尽管在以前的工作中也曾经负责过设计部分，但现在回顾起来，觉得如果不在这个职位上，很多时候是无法了解到这个职位应该做的事的，自然也就无法去做了，在整个一年的工作中学到了很多的东西，同时也暴露了自己很多的不足，但总体而言自己是觉得已经踏入了系统设计的大门，但还需要不断的提高。
阅读全文
摘要: 项目的第一迭代结束，在此对整个过程中Team的表现做的一个总结和分析。
阅读全文
摘要: UIComponent，UI层组件，作为组件其最重要的就是接口的提供以及扩充性，同时作为UI层的组件，从UI层的职责来考虑就是UI的展示和交互两个方面，在这两个方面上UIComponent最需要考虑的就是显示和逻辑的分离，避免逻辑造成对显示的污染，显示和逻辑的分离的好处就在于修改UI以及修改逻辑时都会更加的方便，不用去繁重的html代码中寻找UI和逻辑。
阅读全文
摘要: TDD的大致概念、实施方法、操作过程，并举例说明，最后对于TDD实施过程中的注意事项稍做总结。
阅读全文
摘要: 对于Java Web UI Component的优点、目前实现的技术、缺点以及自己的一些观点，^_^
// TODO：以后需要在这个上面写一篇更全面和完整的文章
阅读全文
摘要: 在项目中正式的执行XP中的过程，除了PP由于暂时没实施，其他的都在实施中，虽然这点会被很多xper说，^_^，其实我也知道PP非常好，毕竟以前经历过，但由于某些原因，在现在的team中我还不好去执行，以后找到机会，呵呵.....
自己接触XP说起来也有两年多了，而且在以前的团队中也是采用这样的过程，但现在自己带team真的执行的时候却发现碰到一些问题，一方面可能是因为自己太久没温习XP，^_^，有些过程都不是那么记得了，另一方面是在执行的时候有些步骤确实不好走，在这样的情况下，回顾了手头的几篇XP的文档，从XP中对于整个软件过程的推行来看自己实施过程中的问题。
阅读全文
摘要: 前天那篇blog更多的是讲了下数据驱动、模型驱动的大致概念，今天更多的是讲数据驱动以及模型驱动在进行系统实现时的方法、过程以及自己的一些思考。
阅读全文
摘要: 数据驱动、模型驱动作为如今软件设计中两种不同的模型驱动方法，应该说各有各的优缺点以及适用的场合，不能就一概的去认为哪种必然就是更好的。
阅读全文
摘要: 软件建设需要考虑的重要的两点我觉得是：
1、客户的功能需求以及非功能需求。
2、软件的维护性。
软件的技术架构就是为了满足以上重要的两点而诞生的，同时由于软件的技术架构决定了使用它的开发人员所需的水平以及开发的难易，此时又要尽量做到降低对使用者素质的要求以及开发的门槛，以保证开发的高效性，但这个相对上两点来说更没那么重要。
阅读全文
摘要: 写这篇和以前的意思不一样，这篇主要是对现在的动辄采用aop思想、采用插件架构、采用SOA、大集成技术这些东西的一个个人的看法，象这种思想级别或者架构级别的东西来说，是很多人采用，但真的发挥了它的作用吗？不敢认同，呵呵，其实象一旦采用aop、插件体系架构这样的思想或架构级的东西，带来的是设计时，甚至是分析时的思想转变，^_^，否则采用了甚至比不采用还惨，不仅带不来效果反而会受很大的"伤害"，呵呵，所以在要采用思想级别和架构体系级别的技术转变的时候真的要慎重思考，需要的是对采用的思想以及架构体系的深入了解，毕竟做软件不是为了技术而技术的，当然，自己小玩玩当然是可以了。
阅读全文
摘要: Equinox是Eclipse的OSGI RI的Project，它的目标是建立成一个独立应用的Plugin Framework，因为现在Eclipse的那个是不好做剥离的，翻译了一篇它的编码实践，希望能有些指导。
阅读全文
摘要: 插件架构体系是我一直就非常关注的内容，其实插件架构体系的发展已经有很久的背景了，插件架构体系的优点我们也是能看的非常明显，象硬件一样的即插即用、无论对于公司还是业界而言的良好的积累方式、为公司或业界提供统一而规范的开发方式以及稳定的内核架构等等，这些优点无论对于公司还是业界来说都是非常重要的。
插件架构体系基本的一个概念就是基于松散的模块积累方式，通过新增插件以及扩展原有插件的方法来完成系统的实现，凡事有利必有弊，在看到插件架构体系的这些优点的同时，在实现和使用插件架构体系的时候仍然会碰到不少的问题，在本文中大概的整理了一些也相应的提出了一些自己的看法。
阅读全文
摘要: 在和一个朋友交流权限系统方面的实现时，朋友提及到JAAS，我自己对JAAS不是那么了解，不好去评价，后来去网上查阅了不少JAAS的文档，应该说现在大致的对JAAS有些的理解了吧，个人觉得JAAS只能算是实现权限系统的另一种方式，相当于提供了一个框架，至于这个框架基于什么模型我无从评价，对比下来我仍然认为基于RBAC自行实现是更佳的方案，不过JAAS中也有可取之处，那就是它的PAM思想。
阅读全文
摘要: 本来作为客户而言，它需要关心的是自己想基于系统做什么，实现什么样的功能，而不会关心到技术层面，但如果碰到了关心技术的客户怎么办呢，客户关心到你用的是什么平台、什么框架、为什么要用以及它如果要基于平台做自主开发要怎么做，感觉在这种情况下挺棘手的，客户往往就变成了对于你实现需求的技术进行干预，而很多时候又没法向用户解释清楚，而且在这种情况下往往是客户根据你的介绍和讲解来做出基于这样的平台是否能实现他们需求的评估，这就挺难搞了，也许是自己的技术不过关，不过觉得最缺乏的是沟通的方法，大家觉得在这种情况下会有什么比较好的方法呢？求教.......
阅读全文
摘要: 几乎在所有的系统中对于权限控制都有直接的需求，而这类需求往往有其相似性，综合常见的对于权限系统的需求构成了本文档，文档主要从功能复用以及模型复用的角度来对权限系统进行总结，以便在各种系统中可对照此篇文档来进行权限系统的实现，考虑到文档的关注点在复用度，在文档中不会过多的去描述功能点到模型产生的过程，而是采用直接通过产生的模型来说明基于此模型如何实现功能点的需求。
阅读全文
摘要: 从公司级来讲，自己的资格是远远的不够，在这里主要也是根据自己的项目经验阐述下自己对中小型企业技术团队的一种观点，个人觉得对于中小型企业来讲三级团队的构成是比较理想的，就是支撑平台团队+应用系统开发团队+实施团队，从三级团队的构成来讲切忌企业的面铺的太广，那这三级团队就很难形成了，但在国内大部分中小型企业仍然处于盈利为上的策略，这也是没办法的，毕竟求生才是最重要的，在这种情况下，我觉得在这样的公司不如干脆由应用系统开发团队+实施团队来组成，而支撑平台则选用开源的或进行采购，当然，选用开源的概念是某个可直接用的或者不需要进行太多集成工作的，这样在公司发展到一定程度的情况下，在适当的时机下再进行升级到三级团队的建设。
阅读全文
摘要: 大家都知道Eclipse是一个典型的插件系统，而从3.0起其插件体系架构就重构为基于OSGI规范来实现的，从这也可以看出osgi必然与Plugin Architecture是有很多的关联性的，在这里就来说说自己对Osgi R3与Plugin Architecture的关联。
阅读全文
摘要: 本文主要对于软件过程的整体规范进行较为完整的描述，来源于个人的项目经验、所在team使用的软件过程以及个人的一些想法总结而成。
文章按照对项目中采用的软件过程进行描述，之后对保证整个软件过程有效执行的工具、制度等进行描述。
本文意并不在标明这个软件过程是多么的优秀，关键是要找到适合自己团队的软件过程，没有最优秀的，只有最合适的。
阅读全文
摘要: 根据自己的经验整理一篇软件过程规范的文章，主要是根据自己的经历以及目前的情况来完整的描述一个软件项目过程中规范性的东西。
遵循的一个原则是："规范不是万能的，要不断调整，每个Team有每个Team适合的规范。"
这篇是序，明天整理一份完整的文档，对整个软件过程中涉及的规范的东西进行较为完整的描述。
阅读全文
摘要: 这篇Blog接着上篇Blog提出的场景进行解决方案的描述：
在和江南白衣聊的时候他提出了oscache提供的cache:cache标签的解决方案，开始想了一下觉得不怎么可行，这也是因为自己对cache标签不熟的原因，后来去网上查了一下cache:cache标签的使用，看了后觉得对于解决上面的需求应该是可行的。
阅读全文
摘要: CMS中缓存显的至关重要，CMS中的缓存主要有静态缓存和动态缓存两种技术，但看下来现在觉得这两种也只是对于最终信息页面的缓存，现在的需求是：
1、站点、栏目、信息列表的缓存。
2、信息页面的缓存。
阅读全文
摘要: Domain Model对于大多数的人来说都不怎么的陌生，Domain Model作为实现业务层的两种重要方法之一，在PoEAA(企业应用架构模式)中得到Martin Fowler的大力推广，但个人觉得在Domain Model上的应用并不是那么的理想，这个还得从业务层实现的两种模式谈起，分别为Domain Model和Transaction Script，Domain Model的原则为采用Domain Object的方式来实现业务逻辑，使得业务逻辑得以聚合到对象本身，从本质上提升业务对象的可复用性，其优点就在于提升了业务对象的复用性和代码的整洁性，缺点则在于实现的难度较高，有一定的学习曲线；Transaction Script则为采用Script的方式编排业务逻辑，其优点在于实现起来简单，缺点在于代码中出现较多重复的业务逻辑块，在业务逻辑一旦变动时需要修改很多地方，降低了业务逻辑的复用性。
阅读全文
摘要: 本篇为漫谈权限系列之结尾篇，涉及到权限系统的开源产品、个人观点以及其知识体系的描述。
阅读全文
摘要: 本文描述了基于ACL模型实现权限系统需求的方案以及优缺点！
阅读全文
摘要: 按照目录完成实现方案中的技术策略和基于RBAC的实现两部分。
阅读全文
摘要: 按目录结构完成的漫谈权限系统系列的概述、目的和需求部分。
阅读全文
摘要: 昨天没什么条理的写了昨天那篇文档后，今天想想觉得权限系统还是挺值得写写的，今天先大概的整理了下思路，准备按照以下的目录结构系统的对权限系统的实现进行描述和分析。
阅读全文
摘要: 本文作为漫谈权限系统的开篇，主要描述了权限系统的一般需求、实现方法以及实现时的难点。
阅读全文
摘要: 架构设计，一直就是软件业界中显得高深的名词之一，会造成很多的人对于它都充满了神秘感，但接触过几年软件业的人很多时候又会觉得软件架构原来不过如此，特别是看到一些架构设计文档后更是得出如此的感想，但真的是如此吗？也许是因为那些架构设计文档并没有起到它们真正的作用，只是拿来糊糊人的吧，架构设计文档最重要的是要能对系统的软件设计做出指导，做出规范性的约束，不谈这些，重点还是谈架构设计。
阅读全文
摘要: 这是在这次写架构设计文档后的一些感想，总体来说我觉得最重要的仍然是需要明确的知道架构设计文档的目的，何谓架构，架构设计的过程，架构对于需求的满足，在这之后可进行模块的概要设计，模块的概要设计其实同样是一个由繁化简的过程，产生出关键类以及类的接口设计，详细设计则是具体的对象设计以及接口实现。
阅读全文
摘要: 将来也准备就里面的各个知识点相应的写blog来介绍和阐述自己的观点。
阅读全文
摘要: B/S作为如今最为流行的体系结构模式，也是受到了广大开发人员以及客户的认同，其开发模式也在不断的发展着，在这里主要就Java B/S的开发模式做一番回顾和探讨，也算是自己对于Java B/S开发模式的一种总结。
阅读全文
摘要: 今天装Foxmail Server 2.0的公测版，没错，网上文档确实是非常的多，但几乎都是同一篇，而且按照那个步骤装完后竟然S活就是不行，郁闷S我了，如果你在装完Foxmail Server后启动webmail的首先中@后面的域名出不来，首页中没有登录按钮以及新用户注册按钮，那么这篇blog对你会有帮助。
阅读全文
摘要: 在项目中，通常由于项目的繁忙使得项目任务的跟踪很大程度上失去意义，导致在最后进行项目成员工作评价以及项目奖金分配时均带有很强的项目经理的主观性，为更加准确、客观的对项目成员的工作做出评价以及合理的分配项目奖金，特制定项目成员积分制度。
阅读全文
摘要: 在一个Web文档管理系统中，用户通过管理界面可增加新的目录分类，并且目录下既可包含子目录又可直接包含文档，同时用户可对目录以及文档分别授予访问、编辑、删除的权限，并且权限均为继承的，意思也就是比如有A目录，A目录下有B子目录和C文档，如用户未对B子目录进行权限设置，那么B子目录的权限控制是和A目录相同的，如用户对C文档已单独授权，那么则取其和A目录权限的交集；同时对于目录以及文档的权限都可分别授予给角色、组织机构、用户或三者的合集。
阅读全文
摘要: 经过团队其他成员上上周对OpenCms以及上周对Magnolia的摸索，加上我自己也稍微进行了了解，在今天做初步集成后我做出了一个决定，那就是抛弃这些开源的CMS，选择自主开发，现在想想，其实当初决定采用开源CMS真的是个错误，也许是因为自己对开源CMS的易用性、可扩展性给予了太大的信心，其实经过这段时间用下来发现并非如此，或者说其实这边客户的需求根本就算不上一个CMS，而要的是个其他的东西，这次确实是自己在做决策时出现了严重的错误，一定要吸取这次的教训，想想如果在两个星期前决定自己做的话早就做出来了，唉......
阅读全文
摘要: 最近一直在挑选CMS，Opencms和Magnolia是考察的重点，应该说用下来两者各有千秋，Opencms在功能上非常强大，灵活性上则相对没那么强，可能因为设计上的原因吧，例如它的权限系统的修改，不过在功能上确实是比较强大，基本上而言一个CMS的功能都已经拥有了，呵呵，关于CMS的需求详见我另外一篇blog，但Opencms的学习曲线较大，不是那么容易上手，体现在模板的编写、资源类型的配置上，Magnolia在功能上也是同样的强大，不过相对Opencms来说还不是那么的周全，但Magnolia提供了较好的扩展性，并且容易上手，模板的编写也是比较的容易。
阅读全文
摘要: 对于B/S结构的权限控制，有N多种实现方式的权限模型，但很多都是非常的复杂，以前在做这块时一直就做的不是很好，考虑的过于复杂，其实应该遵循Simple原则先做出自己能想到的最简单的方案，再逐渐的重构，一种基于URL方式的权限模型就非常简单，很容易理解，也是非常的有效。
阅读全文
摘要: 大概的整理一下，要成为实战型人才其实不难，呵呵，目前软件市场N多公司无非看你有没有spring、hibernate、webwork/struts这些东西的经验，但作为希望从事技术方面的人来说应该更加深入的去了解，而不是停留在表面...
阅读全文
摘要: 国内的软件公司来说仍然以行业化公司居主，而这其中大部分是做中小型的应用系统的，在这些公司中或多或少的存在着自己的一些多年项目积累形成的技术体系，但由于行业化公司来说，毕竟其优势在于行业化软件上，有想法的公司嘛就会自己去搞一套框架，使得自己的行业化软件均可在此之上进行快速、有积累的搭建，尽管这样，但毕竟其是行业化公司，在这方面自然不如专业做此类中间件的软件厂商来得强，虽然很多行业化软件也许根本就不需要一个强大的中间件，但毕竟专业做此类中间件的软件厂商可以从技术上、稳定性上、延续性发展上保证中间件的有利，而行业化软件公司应该发挥本身在行业业务的特长，基于此快速的搭建出适合行业的业务软件，这个我觉得就是双方互相发挥彼此的优势，何必以己之短对他人之长呢。
阅读全文
摘要: 由于此次基于的一个平台并未提供CMS，本来是非常不想去触碰这块，现在看来是没办法了，必须使用CMS，否则工作量太大，加上也没法满足合同中的要求，合同里明文写了需要有内容管理后台，用户可通过内容管理直接添加新的分类什么的，^_^，没有CMS的话还真不好应付。
阅读全文
摘要: 何谓责任心呢，责任心体现在既然自己选择了去做这个，就可以不去过多的考虑其他的事情而只是付出努力完成主要的目标，要尽自己的努力去完成目标和推进整个过程的进展，这就是责任心。
阅读全文
摘要: 项目正式启动，要做的第一件事往往是需求调研，经历了忙碌的不断的和客户的交互后完成了调研，那么接下来该做什么呢，接下来要做的就是需求分析了。需求分析作为软件过程的重要环节，其主要目的在于用某种客户和软件人员都能明白的语言来描述出客户调研的实际情况，并将作为后期软件系统设计以及工作计划制定的主要参考依据。
阅读全文
摘要: 系统设计师做为软件开发过程中的一个重要的角色，承担着系统的架构设计、概要设计的重要职责，对整个系统的技术负责，为整个系统开发过程中出现的技术问题负责。
阅读全文
摘要: Eclipse JSR-220 ORM Project And Java WorkFlow Toolbox Project 的简单介绍。
阅读全文
摘要: 今天浪潮的人过来公司做了他们workflow的演示，感觉不错，我也接触过国内诸如西安协同等等几家公司的流程产品，应该说，浪潮是我看到最实用的一家，在这里不去谈论它的技术到底怎么样，因为我也不知道，只知道是参照WFMC和OMG来实现的
阅读全文
摘要: 本文主要描述工作流管理系统通常的结构、参考模型以及通常使用的调度算法。
阅读全文
摘要: 在这里对JMX做了一个基本的介绍，可以看出JMX在设计上多方面的考虑到了对于资源的管理的简易性(MBean的编写)、易管理性(多种访问的形式)、实效性(Notification)，但同时我们也看出JMX有作为一个Plugin Architecture的潜质，因为MBean是作为即插即用的形式注册到MBeanServer中的，而且JMX还提供了对于MBean的多种便捷的管理方式，MBean呢就像plugin一样，暴露的是可供管理的属性和可供外部调用的操作，^_^，在这里为下一篇基于JMX实现Plugin Architecture埋下伏笔先。
阅读全文
摘要: 昨天在fog讨论到这个问题，fog认为Extension Point是按照IoC的思路实现出来的，我来谈谈我的观点，我却认为Extension Point并不是按照IoC思路来实现的，甚至可以说两者没有关系。
阅读全文
摘要: 昨天在一篇Blog上看到提及Visitor Pattern，一下想不起来了，赶快翻阅GOF Design Pattern，看了后似懂非懂，郁闷呀，平时Visitor模式用的比较少，对于pattern最重要的是理解，理解为什么要这么设计我觉得那么在自己应用的时候就容易考虑到一些，去S记pattern是没什么意义，为了理解visitor模式，按一个场景进行，给部门人员加工资的场景。
阅读全文
摘要: 半路出家的人大部分都是有这个问题的，在工作到了一定时间后会逐渐的明白理论知识的重要性，当然，这个时候去充电会比毫无实践直接进行学习来的效果好，毕竟很多时候可以直接结合到自己的实践中进行验证，对自己应该会是一个质的提升。
阅读全文
摘要: 通过对Eclipse启动过程的分析，可清晰的看到Eclipse Kernel+Core Plugins+Application Plugins的方式，在代码中分别对应为loadBasicBundles和registerApplicationServices，loadBasicBundles通过加载config.ini中的osgi.bundles完成基本的bundles的加载，去看看这个配置会发现是org.eclipse.core.runtime还有一个update，core.runtime又会通过IDEApplication来完成整个Eclipse的启动，同时会注册所有与workbench相关的plugin。Eclipse由于以前版本的Plugin Framework是没有采用OSGI的，所以通过EclipseAdaptor的方式来实现与以往的兼容，目前新的Plugin采用的方式基本就是manifest.mf描述Plugin OSGI部分的信息，Plugin.xml描述扩展点的信息。Eclipse中有非常多优秀的设计，这个在看它的代码时会有很深的感触，比如Contributing to
阅读全文
摘要: 通过对上面两种实现Plugin Architecture的简介，分别都实现了需求中的内容，但都有提升的余地，个
人认为Osgi的方式需提升对于Plugin管理的关注(不仅是生命周期管理)、而JMX+IoC方式则需提高对于
Plugin内部结构的关注(就象Osgi将Plugin分解为了Bundle和Service)，至于Plugin的扩展方面觉得
Eclipse的Extension Point是非常不错的一个设计，不过同时也看出在Plugin Architecture的实现上基
本都采用了管理和静态结构分离的方法，其实这个好处是非常明显的，可以快速的将系统原有的模块通过
编写一个管理类的方法就可作为plugin放入系统中，这提升了简便性，当然最大的作用还是分清了职责，
说一句题外话，职责单一一直是软件设计的重中之重，此文纯属抛砖引玉，希望能听到更多关于Plugin
Architecture的声音，也希望大家都关注Plugin Architecture，最近也出了一个JPF，不知道大家是否有
所了解。
阅读全文
摘要: 谈起职业规划，也许自己并没有什么资格，毕竟只工作了三年而已，在这里主要也是谈谈自己对于职业规划的一些想法，谈谈一个普通的IT从业人士、一个普通的软件开发人员三年工作以来的一些感想，也算是对自己三年工作以来的一个回顾。
阅读全文
摘要: 粒度这个词对于设计人员来说也不是什么陌生的词，粒度上通常称为粗粒度和细粒度，而这里讲的粒度控制主要指的是在系统设计的过程中如何根据需求去控制设计的范围。
阅读全文
摘要: 架构设计这个词听的非常的多，但真正何谓架构设计呢？？可能要你真的来讲还真的讲不太清楚，很多人都知道架构设计是对系统进行分层、分模块进行设计，但又有多少人知道这步应该怎么去做呢，往往很多的programmer在刚进入架构设计这个领域的时候，受到以前做模块的那种影响，把自己的眼光限定到了具体的模块实现上去了，并没有站在系统的高度上来把握系统的架构，这都是些理论性的话，来讲点实际的，^_^，具体架构设计指的是什么呢？目的是什么呢？如何去做呢？下面来讲讲我的体会。
阅读全文
摘要: 虽然这些文档一般来说公司都是有模板的，但我写这些文档以来基本上是每写一次就把目录结构给改一次，应该说这是因为自己对这些文档的理解开始加深，慢慢的越来越明白这些文档的作用和其中需要阐述的东西，觉得这三份文档主要阐述了一个系统的设计和实现过程，从系统分解为层次、层次内的模块以及相互的接口、模块分解为对象以及对象的接口、实现这些对象接口的方法。这次又整了一份，^_^，欢迎大家指正。
阅读全文
摘要: 本文的目的不在于对Lucene的概念和设计这些进行介绍，仅在于介绍怎么样去使用Lucene来达到自己想要的几种常见的全文检索的需求，如果想深入了解Lucene的话本文不会带给你什么收获的。看完本文后想更深入的了解Lucene请访问：http://lucene.apache.org
阅读全文
摘要: 为希望成为工作流系统开发人员关于工作流学习的一些建议。
阅读全文
摘要: 在构思怎么样培训别人学会持续集成做法时画的一个知识体系图。
阅读全文
摘要: 任何事情在开展之前往往都有一个规划，规划又分为长期规划、中期规划和短期规划，在规划中制定了在当前阶段需要达到的一个目标、基本的工作思路以及工作计划，对于事情的顺利开展具有方向性的指导意义。
产品规划作为产品过程的第一个正式的过程，此过程对于产品的发展方向、发展过程等具有指导性的意义，产品规划所做的是一个长期的规划，所以在制定的时候需要考虑多方面的因素。
阅读全文
摘要: Plugin System现在的流行程度已经勿庸置疑了，在N多的白皮书、解决方案中都可以看到即插即用这样的词语，而市场上面向构件、插件的软件也是越来越多，其实插件式的组装系统或者说”搭积木”式的组装系统一直就是软件界的追求，但对于Plugin System还是有些迷惑的地方，还望大家一起讨论讨论，^_^，目前的Plugin Framework基本都是一种Kernel+Core Plugins组成的结构体系，说出来就是all are plugins，^_^，典型的就如Eclipse，其实Maven也算的上的
阅读全文