关于AMF与BlazeDS

AMF是Action Message Format的简称,它是flash专有的数据传输格式,简单的可以理解为类似XML这样的数据格式,不过XML是纯文本,任何一种语言都通用,而AMF是二进制数据,为flash专用.

为什么又有新的数据格式?

有XML不够么?跨语言,世界范围的标准.而且一直以来,我们都是使用XML作为Flash与服务器端通讯的,这个AMF好在哪里,而且还是专用的!

AMF在作为一种数据结构,从通用性上来讲,肯定比不过XML,不过这种协议是专门服务于flash的客户端应用程序,它有两个大优点:
一,比XML等传输协议更优秀的传输性能.AMF能够缓解由基于文本导致的传输瓶颈问题.这可以有证据的哦.
二,更少的数据层抽象代码,甚至不需要反序列化的代码.使用XML类的协议编程时,避免不了有一个数据反序列化的过程,使无意义的数据片段变成有意义的Flash对象,数据模型多的时候可不是一件轻松的事情,想象一下,现在完全不用去管XML,只需要定义一个远程对象即可马上调用,这个过程节省多少成本?!

下图是XML与AMF传输过程的对照:

基于上面两个优点,AMF如今获得许多开发人员的认可,不少服务器端语言也提供了AMF的适配框架,如pythonAMF和下面要介绍的BlazeDS.

BlazeDS

BlazeDS是Adobe公司亲自开发并开源的AMF-Java适配框架.为flash提供java服务器端的简单远程调用能力和实现java对象与actionScript对象的转换.

使用BlazeDS很简单,其核心是一个服务器端的主配置文件:WEB-INF/flex下面的config.xml.示例片断如下:

这样在flash客户端可以通过声明一个远程对象"HelloWorld"来调用服务器端的方法获得返回值.

更详细的使用说明有兴趣的同学看文档吧.

另外不得不提的是BlazeDS在消息处理上面比较优秀,客户端可以发送消息到服务器端的同时,BlazeDS会在服务器端把消息主动push到客户端.具体实现暂时没有考究,不过用来做即时通讯的客户端支持还是挺有用的.

问题

被Spring和hibernate惯坏了的java程序员一定很关心:

BlazeDS的配置文件里面可以使用Spring Bean吗?这是我最关心的事情,因为现在的java web程序大部分都采用spring作为基础架构了,许多第三方的工具和框架都提供了spring的兼容方法.这是BlazeDS不能避免的.不过,现在的blazeDS还不是成熟的版本,不知道以后会不会提供?

使用BlazeDS肯定享受不了hibernate的lazyload了!目前看来是不行的.

 

Nuxeo WebEngine －－ java的plone?

今天看到一则新闻“Nuxeo WebEngine发布”，仔细看了一下，咦，这东西的概念怎么这么像python世界的plone？

说到plone，不得不提的就是它的开发框架Zope了。介绍Zope并不是本文的目的，有兴趣者可以Google之。

一、WebEngine依赖 Nuxeo内容管理框架提供基于组件的程序模型和web开发模型来创建以内容为中心的组件化应用，包括Wiki，博客，内容为主的web网站等。

注：Nuxeo内容管理框架(Nuxeo core?)应该是类似Zope 的CMF（Content Management Framework ）东东了。plone也一样是作为一个应用框架，用来开发以内容为中心的组件化应用。Plone内置的内容类型有页面、文件、图片、文件夹以智能文件夹，而Webengine则提供了更多内容相关的类型，如Blog，Wiki等。

二、WebEngine主要依赖REST方式：URLs映射到分层的内容存储，内容通过GETs获取，用户行为通过GETs和POSTs请求等。这种方式方便通过WebEngine使用和架构RESTful应用。

注：如果你了解RESTFul风格的URL并知道Zope以模型为中心，URL以节点漫游的方式进行映射，你就会发现两者的目的都差不多，REST是以资源为中心的。我后来看了一下WebEngine的实现，它使用了内容仓库Jackrabbit(什么是内容仓库)作为数据存储的一部分，真正实现多层次结构数据的存储。表现出来的效果和ZODB有点类似了。

三、WebEngine完全是可扩展的，组件化的，通过OSGI方式和Nuxeo运行来扩展。

注：WebEngine的扩展可看作是OSGI 的插件。由于OSGI，WebEngine在部署组件方式同样可以达到热部署，在Zope里面，这样的组件被称为产品（product）。

四、WebEngine有自己独立的服务器，并且兼容JBoss，允许嵌入式运行等。现在暂时不清楚其独立服务器的用意（不过从下载回来的Standalone版本来看，服务器是基于Jetty6的），但看起来有点模仿zope的意思，zope是提供独立的服务器。

我下载了一份Standalone的发行版下来试验了一下。发现WebEngine这一次的发布真是摆了个大乌龙，在它的网站的任何地方都找不到登录系统的初始密码，启动了服务器的我在门外徘徊了好久，终于在Google到一个可能的帐号Administrator/Administrator，试一下真的能进去。

界面还很简陋，用户管理的创建用户看起来有点Bug，我创建的每一种类型的内容最终都显得像一个目录，并且点击编辑的时候都出现这样的错误提示：
This is a placeholder page. Don't know how to edit generic documents.
Add an edit page for your document type please. (Your document type is: Blog)
不知道是我RP有问题还是系统根本就还不完善。

总而言之，这东西看起来不错，不过现成的Demo却有点令人失望。不知以后是否会有惊喜，继续关注。如果该产品发展至成熟，将会为Java平台上的内容管理领域带来一个更好的解决方案。到时除了plone，又多了一样选择，是好事！

We are on Grails

Grails？你的产品使用Grails！？是的，我想告诉你，我们正在使用Grails，并且产品现在也健健康康的。

轻量级也会做恶梦

我之前的项目大部分使用java做开发。spring + hibernate + Struts or Spring + hibernate + webwork 固然好用，可是到一千个人手里有一千种做法，你这样封装，我如此扩展，虽然这些东西在手中玩得烂熟，但，噢。。天，还有没完没了的配置文件，传统Java web Server那极不可靠的热部署能力，我只能无止境地重启再重启Web server。用我同事的话说，走出去抽完一支烟回来，还没启动完成。做Web开发，真用得着这样折腾吗？

老板，我也要on rails

如果到现在你还没听说过ruby on rails 或 django，那说明你还不是一般的脱节了。正在大家热衷于讨论“贫血模型还是充血模型”、“EJB3还是Hibernate”的时候，Ruby on rails的到来有如一缕清风拂面，让人有焕然一新的感觉。其简约清爽的风格赢得不少开发者尤其是Java开发者的欢心，不少Java界的大牛声称转移到Ruby社区，国内著名的Javaeye社区也开始使用Ruby on rails(以下简称ror)来开发新版的网站，真是很身体力行。后来，pythoner站出来说，在python社区也有一种框架比美ror，她叫django。

我分别用上了ROR，Django，喜欢上她们，并用Django写成了现在你看到的这个网站。满心欢喜的我按捺不住喜悦要跟朋友和同事们分享这一切，只是由于种种原因，我的“八卦N种流行的快速开发框架”的分享讲座至今还没有开。

ROR，Django固然好，无奈产品的生产环境是跑Java，Jruby，Jython之辈不成熟，更不用说Jruby on rails或Django for java。车到山前必有路，Java的王储Groovy日渐成熟，其对应的Web开发框架Grails更新也很勤快，Java社区是不是很快就有像ROR和Django一样的快速开发框架了？一时间，社区议论纷纷，有褒有贬，众说纷芸，JavaEye站长robbin更认为Grails不会有大作为。OK，1.0之前，我继续持观望状态。

Grails？嗯，很高效！

说真的我一直在等Grails1.0。1.0的释出，我跟团队说，今天开始，我们要用Grails了。

两个月下来，产品释出第一个版本，同事们认可了Grails的高效，并且表示往事不堪回首，再也不愿回到从前的开发模式当中去。

简单总结一下Groovy和Grails的好处，但本文重点并不在于此，更多的可以参考Grails官方网站或Google。
一、天然的充血模型，省略你曾经很头疼的DAO。
二、现在用Hibernate，一个配置文件也没有，讨厌的注解也不需要，实现ORM，实在是易过借火。
三、数据库Schema智能升级，管好你的模型，不用担心数据库。这个比Django好！
四、热部署，这是相当重要的。
五、灵活的数据库查询，跟ROR一样使用动态的find实现复杂的查询。
六、快乐的闭包。遇上一些策略性的业务情况，现在可以很萧洒地扔一个闭包进去作参数，Cool，和多余的Interface说再见。
七、智能的依赖注入功能，还是要感谢Spring的IOC，在Grails里面只需要声明成员变量即可自动获得注入，还是0配置哦。
八、强大的数据验证功能。这一点抄Django的。
九、生成完整的项目结构。正是这样，才能真正做到快速启动开发。
十、更多请Google

Grails其实很容易上手

团队里面有同事有ssh的开发经验，从接触Grails到开始编码使用1天时间，简单读过文档之后就可以开始了。

团队里还有个新人刚毕业，甚至Spring都不认识，可这些都没有妨碍他与Grails快速实现亲密接触。

如此容易开始，如此高效的工具，你真的还要考虑那么久吗？

我知道你在担心什么

有人问我，在现在这种形势下（Grails虽然出了1.0，但实际应用还不多，够不上成熟），你怎么有信心使用Grails？其实很简单，它发展速度很快。

他们担心Groovy太慢，Groovy解释速度慢只会在开发过程中有些影响，生产环境下将会部署生成的字节码，速度照样飞快，而且Groovy的效率也提高的很快，我完全有信心Grails以后越来越快和越方便。

再问，Grails刚出来，可能很多Bug，如果遇到一些无法控制的问题那不是死定？呃。有同事这样问过我同样的问题，我认为决定要在产品中使用一项新技术的时候，必须要对它有足够了解，还应该有信心面对一些不可预知的问题。只有如此坚定，你才敢去使用它，尤其是在它诞生不久的时间段内。

网上有Grails的负面评价。我的建议是，有些负面评价只是主观的判断，就像ror,django到今天同样有负面评价一样，借用那句话：谁用谁知道。

We are on Grails

不管你在想什么，我和我的团队的确感到了快乐。因为使用Grails。

搭车宣传一下上文的产品中的其中一个作品：手机仿真。这里是产品宣传站（基于Plone的哦），该产品前台演示及后台管理、制作均使用Grails开发，目前已在生产环境（指客户的）连续运行较长时间，工作正常。

Jmesa Grails plugin 完成

这个星期在公司就flex,回到家里就Java.脑子昏昏的就又到星期五凌晨.

Jmesa的Grails plugin开发工作基本完成,测试OK后源码和示例都提交到svn上面了.

新鲜热辣的指南文档在这里:

http://code.google.com/p/jmesa/wiki/JmesaGrailsTaglibTutorial

还是头一次写那么长的英文手册..

摘录一段我和Jeff的对话.

我: hi.check out the plugin document :)

jmesa grails plugin进行中

一年多以前我参与了开源表格API--Jmesa的开发，当时还在国内推广了一下，只是苦于时间的原因，宣传没有再继续，开发工作也一度中断。直到近日，mailList里有人提到jmesa想要和grails结合起来时，我才决定再加入jmesa，同样contribute一套标签库，不过这一次是为grails写一个plugin。

现在看看国内，使用jmesa作表格展现的同学越来越多，这一年多的时间也有不少同学找上门来问我些问题，不幸运的是一年之内我基本上与Jmesa脱节。接下来情况应该会好多了。重新review了jeff johnston同学的代码，这老外的代码风格就是赏心悦目！

本次grails的jmesa插件主要功能大概包括：

1. Jmesa tags for Grails

2. Jmesa 风格的代码生成模板

3. 外加一个sample

对Jmesa和grails有兴趣的同学可以联系我，给我提意见或一起出一份力。

Jmesa中文参考资料：

看这里，是我原来在javaeye的blog里留下的。

 

Google chart in house

前些时候Google推出了一款报表API“Google chart api”。该API让开发者可以通过URL来动态生成图表，图表的样式有流行的线状图、柱形图、饼图等。下面是一个使用实例：在你的浏览器输入下面的地址：http://chart.apis.google.com/chart?cht=p3&chd=s:hW&chs=250x100&chl=Hello|World 然后回车或确定，你将看到下面这一幅图片。

还有更多样式，更复杂的图表Google chart api也能胜任，本文不打算重复参考文档里的内容了。有兴趣的同学可以自己去研究一番。

也就是说，Google为你提供远程的图表生成服务，但是这个服务并非没有限制的，Google限定了，每个用户每日的访问图表数量不能大于50,000次，说实在的，普通的应用的用户要达到这个数本来就很难，所以这倒不是最大的限制。另外，如果你的项目是在企业内部部署，用户不能直接访问外网，那Google chart api就哑火了。你可能会说“真可惜了，Google chart api如此强大，我都已经掌握了它的全部用法了，如今却因为这种原因使用不了”。使用第三方的在线服务，还有一个潜在的问题就是，你不知道他们什么时候会把这个服务撤掉。

现在你不需要为这件事而发愁了，有一个好东西一定会让苦恼的你兴奋不已。著名的Java报表引擎Jfreechart的作者模仿Google chart api的URL风格开发出了一套Servlet－－Eastwood，这个项目是基于Jfreechart的，它可以让你使用Google chart api的方式生成与Google生成的几乎百分之百一样的图表，这味道着，如果你用Google chart api开发了一套图表，那么你需要Google chart inside的话，只需要把eastwood作为一个Servlet配置起来，然后替换一下URL的Host就搞定了。

来看看Google和EastWood生成的图表之间的差异：

更多的比较看这里。要进行最全面的比较，下载一份Eastwood的发行版，部署，打开Test.html就见到效果了。很赞。Jfreechart的作者怎么在之前没有想到以这样的方式来提供报表生成的功能呢？呵。看了下EastWood的代码量很少，只是将Jfreechart做一下封装就完了。

关于接口中使用Object参数的讨论

项目需求中终于出现了规则，由于时间问题，没打算使用规则引擎来处理这些规则。只是很简单地设计了一个很简单的接口，让事实的生产端直接调用。

我必须承认，这个接口很丑陋。像这种接口命名为Rule太造作了，除此之外，它还可以命名为EventHandler，Executor等等。只是我现在把这个丑陋的接口用在规则处理这一块，所以我很厚脸皮的为它命名为Rule。它的实现类的责任是：用Source对象按照一定的算法计算出相应的积分，并保存到数据库。

 

下面是一个很简单的实现，当一个用户登录后，按积分规则，他应该得到20点。那么我的一个登录积分规则的实现为：

为了让客户端调用起来更方便更统一，我加了一个类，起到入口和路由的作用，下面是简化版本的代码：

这样一来，登录完之后，只需要scoreGenerator.generateScore("login",user);就完了。（如果你惯性地认为用AOP可以处理这些分散又一致性的情况，那说明你的水平不错啊，不过目前的做法就是暂时让客户端来直接调用了）我的目的只是想让调用规则系统的代码尽量简单，各种积分规则独立实现，可增加减，互不影响。后来我的一个同事就这个接口的问题与我讨论了很久，他认为我的设计不符合OO的思维，不符合设计模式的种种范式。

 

引起我同事的反感的真正原因其实不在接口，而是我在做一个Rule实现的实例的时候，粗心地使用了另外一个项目的模型类，使用公用项目对具体项目产生严重的依赖。他没有先告诉我这个问题就整天上午在处理包的依赖问题，后来实在忍不住向我发牢骚我才发现，我做了错误的示范（当时我的示例代码是用注释的，仅想起到说明的作用，但实现类放错了地方，本该放在具体应用里的）。后来大家也就一个接口参数是否应该为Object做了很长时间的讨论。他认为这样的接口没有通用性，不能在别的项目里使用，不符合OO的思维，设计模式的书中没有见过这种做法，他在其他项目的代码里也没有见到过这种做法。

呵。相反，这种做法其时我经常在用，而且一些著名的开源项目的代码，印象最深的是ACEGI里面处处充斥着这样的接口。这种接口看起来简单，要清楚，他目的只有一个，把各种可能的实现屏弊起来，客户端只需要使用一致的接口来调用方法即可。致于那个Object的参数，实际上我更希望他是一个具体的接口或者是类，如大家都熟悉的大部分MVC框架里的Action，execute(HttpServletRequest reqeust,HttpServletResponse response);又如大家都知道的命令模式：onCommand(Command command);。我完全可以定义一个接口来实现类似的看起来很可爱接口。如把Object 换成 ScoreAware－－能计算积分的接口。这样一来，大家在设计业务对象的时候有需要的时候就实现上这个接口吧，但是对于一些已存在的业务类呢？我个人的立场是不愿意叫他一定要实现我这个接口，我更愿意告诉他：“你实现一个Rule吧，在Process里面根据你的业务对象进行些积分的操作”。也就是说，我用Object来做参数，我给予的实现的自由度也是最大的，不管是将来出现的业务对象还是已存在的业务对象都适用，这种接口只是提供一种执行规范，而它的参数是由实现来决定的，而接口是不关心的，它关注的是方式，不是参数。

我到底懂不懂设计模式？不要紧，但我知道什么情况下我应该设计怎样的接口，情况包括成本情况、时间情况、人员情况、业务需求情况等。《Java与模式》这本大部头更多时候我是用来垫底，我觉得自己知道什么时候要重构，知道一些反模式，也知道什么是滥用模式。讨论出真知，我很乐意有这样的讨论。我们的目的都是一样的，更灵活的代码，更高的重用度，更低的成本。