ITPub博客

首页 > 应用开发 > IT综合 > 专访Restlet框架首席开发者Jrome Louvel

专访Restlet框架首席开发者Jrome Louvel

原创 IT综合 作者:heying1229 时间:2007-09-25 10:02:02 0 删除 编辑
专访Restlet框架首席开发者Jrome Louvel[@more@]来自:infoq

最近Restlet框架发布了它的1.0版。Jérome Louve是Java框架Restlet的领导开发者,近来记者有机会和Jérome Louvel进行了一次对话,本次谈话的主题讨论了Restlet存在的原因、在Java Web服务框架中的REST支持、Ruby on Rails、对JSR 311的期望以及Restlet的路线图。

记者:你能给我们简单地介绍下Restlet的目标吗?

Jérome Louvel(以下简称JL):Restlet是一个Java下的轻量级REST框架。通过拥抱REST(REST是一种Web架构风格)它模糊了Web 站点和Web服务之间的界限,从而帮助开发人员构建Web应用。每一个主要的REST概念(REST concept)都有一个对应的Java类。你的REST化的Web设计和你的代码之间的映射是非常简单直接的。

Restlet是一个以CDDL或GPL发布的开源项目。该项目包含一个Restlet API,一个引用实现(Noelios Restlet引擎)以及一套扩展。

记者:你为什么会觉得有必要创建另一种框架?难道Servlet API还不够好用吗?

JL:Servlet AIP在1998年发布,从那个时候起它的核心设计一直没有很大的变化。它是Java EE的众多API中最成功的一个,但是它的几个设计缺陷和一些限制损害了它。举个例子,URI模式和它的处理者(handler)之间的映射是受限制的,而且其配置都集中在一个配置文件中。还有,他把socket流的控制直接交给了应用系统开发人员,Servlet容器阻碍了我们充分使用NIO特性对IO 操作进行优化。最后,他对一些HTTP特性,例如缓存、内容协商以及内容压缩支持的不好。这对开发人员来说是件痛苦的事,因为这阻碍了他们将精力集中在应用系统相关的代码上。

另一个主要问题是,Java EE Stack中新的HTTP客户端API的缺少。JDK的HttpURLConnection类很难用,而且许多HTTP特性都不支持,比如为内容协商而表达的客户端选择等。人们经常需要依赖第三方HTTP客户端API突破这些限制。但是,HttpURLConnection不支持NIO。

2005年,我看到了超越这些限制的机会:在REST原则下设计一个新的API。第一次,我们有了统一Web应用客户端和服务器端的机会,这个 API完全支持NIO并能让开发人员编程控制Web容器、连接器(connector)等,而且不需要经常性的依赖XML描述符就能部署应用系统。

记者:你怎么看在别的框架中对REST的支持(例如Axis2,或者CXF/XFire)?

JL:我想这些支持非常有效,但是作用非常有限。我的主要观点是设计这些项目是为了符合WS-*/SOAP Stack,它们与REST世界并不非常契合。在REST世界里,定义了一个全新的范例:面向资源的设计,而非通过远程方法调用这样的范例。

例如Axis2仅仅支持GET和POST两种HTTP方法,它需要远程方法的传递需要一个URI参数。这在REST中式不允许的,这种做法也不能被称之为REST化。

XFire1.2不支持REST,但是它发布了一个项目用于将POJO映射到REST化的Web服务。这有点类似最近发布的JSR-311,此JSR试图基于一套annotation和助手类标准化这种映射。

记者:你是JSR 311专家组的成员,能否对JSR 311做一下展望?

JL:我期望它能在REST资源和POJO领域对象之间实现一个完好的映射。就像JPA在关系数据库和POJO之间实现了很好的映射那样,我们也希 望这个JSR能做到像JPA那样。我希望以annotation为中心的API能够相当符合(complimentary)Restlet API,后者已经是一个将REST资源映射到POJO的以类为中心的API了。

这些annotation也能被像Axis2和XFire这样的项目实现,我认为这个JSR给了REST和WS-*阵营一个达成和解的机会。

记者:你能告诉我们一些基于Restlet的项目吗?

JL:有几个不同规模的组织已经部署并应用了这样的应用系统,包括Overstock.com,这是一个在线购物方面的Internet领导者。 Restlet项目也被作为支持技术用在覆盖REST构架风格的不同软件构架类别中。例如在加州Irvine大学,以及在INSA Rouen工程学院的使用。

我们自己的网站也是用Restlet引擎构建的。考虑到我们受到拒绝服务(denial of service)的攻击量,我们对我们系统的可伸缩性很自信。最近我们还发布了一个公用基准以证明了其性能品质。我们与流行的Servlet容器处在同一水平线上,而且有望在下一个加入完全的NIO优化的连接器(基于Glassfish的Grizzly NIO框架)的版本中比后者表现更为优异。

记者:在构建REST化的应用系统中,能否比较一下Java和其他语言有何不同?

JL:流行的REST化技术,例如Rails或者Django这些技术的经验告诉我们,Java/Restlet这样的技术在支持REST化的应用中会有更好更高的性能表现。Rails和Django开始的设计并没有考虑到REST,REST的这些概念只是在后来被加进去的。相比Restlet,这导致了很多做作的(contrived)代码。以Django为例,它并不天然支持在URI和资源之间映射的URI模板。而Rails强迫在关系数据库和对数据的CRUD操作间使用一种不自然的映射,REST/HTTP方法导致一种令人不满意的结果:开发人员不得不在各种限制下工作,或者采用自己的面向资源的设计去迎合Rails。而Restlet不强迫你使用任何持久化技术,它让你自由的定义你的资源及其特定的表现形式(representation),以及它们怎么被映射到你的领域对象或你的数据库。

记者:你能更详细的解释下你刚才对Rails的批评吗? 你认为它的CRUD映射什么地方不够自然?

JL:除了GET和DETLET这样的HTTP方法可以很好的映射到SQL的SELECT和DELETE外,我还发现Rails将HTTP的 POST方法用来进行创建行为,这很不幸。在REST中,对于创建行为最好的方法是使用PUT,它也可以用于更新。PUT比POST优越的地方是如果操作行为失败了,它可以很安全的重复操作,而POST不行。

还有,资源列表是基于表名和行记录的数字型id映射的,在实践中这并不总是可行的。你不想失去对你的URI的控制,而URI既是应用系统用户界面的一部分,又是REST最基本的概念之一。在Restlet中,我们并不对你的URI强加任何限制,你可以自由的使用任一持久化技术(例如JPA的 annotation化POJO,纯JDBC调用,对象数据库等等)在你的资源和表现形式(representation)之间进行映射。

我对Rails的另一个小小的批评是,Rails鼓励使用笨拙的“;edit”后缀访问一个资源的编辑Web页面。这有点误导,REST并不鼓励使用URI参数的非一致方法,应该使用分隔的Web表单资源,这样浏览器可以使用GET、POST或者PUT方法。

记者:你好像在Restlet上花了不少时间。这个业余项目占用了你多少时间,你的公司期望能从这个项目中得到多大的商业成就?

JL:从开始这个项目就不是作为一个业余产品启动的。当我构建另一个很重要的私人项目是我就感觉到了对它的需要。我相信专业的开源项目,也希望Noelios Consulting能提供的专业服务(如支持计划,顾问服务)能让我们继续投入更多的精力。

记者:第一版发布之后的路线图是什么?

JL:除了维护1.0版修改bug外,我们还将很快启动1.1版。一些我们曾想过的对WAR包(不再需要XML描述符)的增强将被加进来。用户可以选择通过一个XML描述符配置Restlet组件(可移植的应用系统和虚拟主机容器)从而简化管理员的工作。我们还有几个连接器原型要实现,一个是基于 Grizzly NIO框架的HTTP服务器连接器,它将带来更多的可伸缩性和响应(responsiveness)。另外两个HTTP连接器是基于JXTA的虚拟 socket(一个客户机和一个服务器)。

我们还想更深入的支持HTTP特性,例如内容范围(content range),Digest和WSSE授权。我们还计划在2008年将Restlet API提交给JCP。这有利于逐渐替代Servlet API。
Jérome Louvel简介:Jérome Louvel是一位软件架构师,它是Noelios Consulting公司的创始人。在软件版本(Software edition)和咨询方面有超过8年的工作经验,它常年工作在欧洲和北美洲。他对Java、REST、语义网以及商业过程集成有浓厚的兴趣。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10172717/viewspace-972044/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    1690
  • 访问量
    9284282