一般说，消息队列是改进系统伸缩性的选择。一则消息是异步的，二则这会降低系统的耦合度。东西是好东西，有人说jms或者mdb是j2ee规范中最好的标准，不过最近项目中用到的JMS感觉却很痛苦。配置很痛苦，调用很痛苦，调试也很痛苦。感觉这东西是上古的东西，在java中使用很麻烦。 最近看到twitter的架构居然也用MQ，很感兴趣。看了下，跟IBM MQ Server完全不一样，笑。这个原来是基于Memcached协议的一个list，放在内存中，主要强调性能，也可以cluster。调用么，rest style，get/set，标准的东西，对客户端没啥要求，不需要额外包，更不需要预先配置，一个URL搞定。看看这里，觉得也不复杂。 twitter很多东西都是开源了，活雷锋。MQ的这个东西在这里，称为kestrel。基于jdk6 + scala，actor的并发模式，有人已经走读过了。Cool! 相对企业MQ，这东西局限在：1）消息难做到严格的排序；2）事务。大多数情况下不是致命。 多数情况下，如果一个技术上手容易，虽然功能少点，但是也会尝试的在系统中使用。如果跟IBM MQ Server一样的巨无霸，碰的人不多，推广开也难了。
Posts under ‘methodology’
OSGi的白板模式(White board Pattern)
这个模式主要是来对付Listener Patter（或者Observer Pattern），具体来说，后者的缺点在： 产生了很多的类，比如很多情况下，一个event source只对应一个listener，这种浪费在手机这种受限设备上是一个不得不考虑的问题。 event source和listener的管理复杂，比如注册和注销，因为这两者可能都很动态，不能保证自己需要对方时对方是工作的，或者说难以达到消息的可靠性。这两者之间的依赖太明显，太直接。 White Board引入了event broker，作为两者间的桥梁，保存消息和分发消息，走向了subscribe/publish模式。 图摘抄至OSGi in Practice。这并无神奇的地方，只是把复杂的代码挪到了broker。OSGi则在这个地方加上了比如异步，有顺序的分发和可靠的分发这些功能。还有Topic的功能，比如有一个topic: a/b/c/*，这样event source和listener直接就靠这个纽带来进行交互，在Android中把这个抽象成URI，感觉几乎是一样的。 倒不清楚Android是一个OSGi的实现？还是只是把OSGi作为一个templete拿来模仿？
手机只是网络的延伸
最近在考虑做一个手机上的“可同步的“的记事本，因为感觉的android上的通讯录和邮件功能确实很cool，在PC上面修改Gmail的通讯录马上就可以同步到手机上，这样手机丢了或者刷机后，同步一下就可以了：信息只存在一个地方（这让我想起了TDD中的消除重复…）。 如果记事本里面的内容保存在网络上，在普通的pc上也可以编辑，那么势必还有一整套的相关事情：1）得有记事本的web界面，主要在PC上使用；2）如何说服用户使用这个网站，没有人愿意把私有数据放到一个不知名的网站或者不知道哪里的“云”上；3）还得有 firefox的插件，方便操作；4）如何避免滑入一个信息孤岛，如何和其他app分享数据。 结论是：手机只是网络的延伸，只是PC机不在时的一个补充（或者说当我们不在cloud中时）。PC机上好的应用，可以迁移到这个平台上来，反之则不大可能的。 当然这只是一个例子，只是技术上的可行性验证，不用考虑太多。
开源的源
如果没有源代码，分析问题就不能追本溯源，就会流于表面。 虽然自己不一定会从头到尾的看代码，但是有源代码在那里，让人总觉得有安全感。 代码的开源，还表示了一种“授之以鱼，不如授之以渔”的态度。源代码提供了更多的信息，提供了解决问题的方式。虽然功能不是最强大的，而自有的产品更多的只是关于配置相关的文档，其后的原理一般人不甚了了。Dan Farion谈及MySpace架构时说到：“我们尝试了某个东西之后就从中学到些东西，然后可能就会把其中有价值的地方给剥离出来，再为了达到我们的性能或伸缩性需求重新写一个。” Open Source则可以充当学习的例子。项目中总会有让人感到棘手的问题，这些问题超出了框架之外，是不能用常规方法解决的，如果而源代码这个时候就能作为特例中的一般例子，让我们有一个改进的基础。