欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜:Formal mathematics/Isabelle/ML, Formal verification/Coq/ACL2, C++/F#/Lisp
Apache Pluto
第1行: | 第1行: | ||
− | + | Pluto项目是Java Portlet规范的参考实现(Reference Implementation)。该规范目前 的版本是 [[JSR 168: Portlet Specification|JSR 168]]。 | |
− | http://portals.apache.org/pluto/ | + | Portlets是一种运行在portal环境下的对象,它们通过与Servlet API相似的Portlet API 编写。与servlets不同的是,portlets有很多不能做的事情,比如直接向浏览器发送重定向应答 或错误,比如转发请求,比如往应答的输出流中写入任意的markup标签,等等。这是因为 portlets是被portal web application所使用的对象,它们的行为不能干扰到portlet web application的工作。与servlets的另外一个区别是,portlets依赖一些portal所特有 的底层功能,诸如对user profile信息的访问,诸如存取持久层设定的标准接口,诸如获取客户 信息,等等。一般而言,与servlets相比较,portlets以一种更加动态的方式被管理。 |
+ | |||
+ | Portlet容器为满足Portlet API规范的portlets提供了运行环境。Portlets可以在该环境中 被初始化,被触发和调用,以及最终被销毁。和Servlet容器不同的是,Portlet容器不是作为一 个独立可运行的容器来实现的,而是架设在Servlet容器之上的一个层,它重用了Servlet容器提 供的许多功能。 | ||
+ | |||
+ | Pluto是一个满足Portlet API规范的Portlet容器的实现,它为开发者提供了一个运行 portlets的工作平台。然而,如果没有一个驱动器(driver),也就是Portal,的支持的话, 运行和测试Portlet容器将非常之麻烦。Pluto本身也提供了一个简单的Portal模块,该模块仅 仅是为了满足Portlet容器和JSR 168的需要而写的。如果你需要一个成熟的Portal,请参考 Jetspeed项目。Jetspeed项目关注的是Portal本身,而不是Portlet容器。 | ||
+ | |||
+ | ==目标== | ||
+ | Pluto Portlet Container是Java Portlet规范的参考实现。因此,对于开发社团而言, Pluto提供了一个关于如何去解释规范的参考;对于portlet开发者而言,Pluto可以用来测试他 们的兼容portlets;对于portal开发者而言,Pluto则是一个可集成的兼容容器。 | ||
+ | |||
+ | 以下文档试图澄清在Apache Pluto项目中的开发优先级。 | ||
+ | |||
+ | 对于Pluto开发社团而言,最重要的一点是要保证Pluto与最新版的Java Portlet规范的兼容性。 功能的加强和bug的修复必须在这个前提下来完成。 | ||
+ | |||
+ | 确保不要在该参考实现中引入歧义,这是Pluto开发团队的责任。如果加强一个功能会引起一些与 规范有关的问题,那将不会被采纳。 | ||
+ | |||
+ | Pluto项目的目标是构建一个强壮稳定且易于使用的portlet容器,这将使开发者们更容易的去接 受它和使用它。为了达到这一目的,我们认为,如果一个功能是属于规范所定义的范畴以外,那么 它可以被集成到Pluto中去。但它必须被放到一个单独的包(package)中,并且在文档里声明这 一点(即“属于规范所定义的范畴以外”这一点)。必须保证,即使把这些功能移除,Pluto依然可 以运行,并保持与规范的完全兼容。在大多数情况下,应该只需修改配置参数就可以移除这些额外 的功能。 | ||
+ | |||
+ | 最后,虽然Pluto项目包含了很多子项目,但必须认识到,只有Pluto Portlet Container 项目(也即Java Portlet规范的参考实现)才是最重要的。Portal驱动器、testsuite和部 署器(deployer)等子项目的存在只是为了简化Pluto Portlet Container项目的使用和 测试。因此,任何对那些组件(尤其是portal驱动器)的显著的强化在付诸实现之前都必须通过 审查,因为那很可能已经超出了Pluto项目的范围。 | ||
+ | |||
+ | ==Roadmap== | ||
+ | 许多人建议对Pluto的实现进行重构,这主要是因为Pluto目前的实现太复杂了,他们认为应该 把Pluto写的“更象一个容器”。在未来,Pluto二代也许将简化一下实现的方式,并使用更多的 标准设计模式。对于设计一个容器而言,IoC模式是个不错的选择。 | ||
+ | |||
+ | ==Pluto和WSRP== | ||
+ | JSR 168规范和Web Service for Remote Portlets(WSRP)标准有高度的一致性。这两 个同时出现的标准都发布了开放源码的实现,它们的实现都完成了在相应的规范中定义的所有必要 功能。这两个标准都把能很好的互相协作作为它们共同的目标。因此,WSRP portlets在 portlet容器中既可以作为消费者运行,也可以作为生产者运行。 | ||
+ | |||
+ | Pluto项目必须支持在一个Portal中运行多个portlet容器。因此,Pluto Portlet容器可以 被多次初始化。更重要的是,它可以以不同的方式运行,每个portlet容器都使用一个不同的SPI 实现。 | ||
+ | |||
+ | *http://portals.apache.org/pluto/ | ||
+ | *http://people.apache.org/~zheng/pluto/chinese/ | ||
[[Image:jw-0801-portal_arch.jpg|thumb|left|The simple portal included with Pluto.]] [[Image:jw-0801-pluto_arch.jpg|left|thumb|container's architecture]] [[Image:jw-0801-RI_deploy.jpg|left|thumb|deployment in the RI]] | [[Image:jw-0801-portal_arch.jpg|thumb|left|The simple portal included with Pluto.]] [[Image:jw-0801-pluto_arch.jpg|left|thumb|container's architecture]] [[Image:jw-0801-RI_deploy.jpg|left|thumb|deployment in the RI]] |
2007年1月16日 (二) 15:58的版本
Pluto项目是Java Portlet规范的参考实现(Reference Implementation)。该规范目前 的版本是 JSR 168。
Portlets是一种运行在portal环境下的对象,它们通过与Servlet API相似的Portlet API 编写。与servlets不同的是,portlets有很多不能做的事情,比如直接向浏览器发送重定向应答 或错误,比如转发请求,比如往应答的输出流中写入任意的markup标签,等等。这是因为 portlets是被portal web application所使用的对象,它们的行为不能干扰到portlet web application的工作。与servlets的另外一个区别是,portlets依赖一些portal所特有 的底层功能,诸如对user profile信息的访问,诸如存取持久层设定的标准接口,诸如获取客户 信息,等等。一般而言,与servlets相比较,portlets以一种更加动态的方式被管理。
Portlet容器为满足Portlet API规范的portlets提供了运行环境。Portlets可以在该环境中 被初始化,被触发和调用,以及最终被销毁。和Servlet容器不同的是,Portlet容器不是作为一 个独立可运行的容器来实现的,而是架设在Servlet容器之上的一个层,它重用了Servlet容器提 供的许多功能。
Pluto是一个满足Portlet API规范的Portlet容器的实现,它为开发者提供了一个运行 portlets的工作平台。然而,如果没有一个驱动器(driver),也就是Portal,的支持的话, 运行和测试Portlet容器将非常之麻烦。Pluto本身也提供了一个简单的Portal模块,该模块仅 仅是为了满足Portlet容器和JSR 168的需要而写的。如果你需要一个成熟的Portal,请参考 Jetspeed项目。Jetspeed项目关注的是Portal本身,而不是Portlet容器。
目标
Pluto Portlet Container是Java Portlet规范的参考实现。因此,对于开发社团而言, Pluto提供了一个关于如何去解释规范的参考;对于portlet开发者而言,Pluto可以用来测试他 们的兼容portlets;对于portal开发者而言,Pluto则是一个可集成的兼容容器。
以下文档试图澄清在Apache Pluto项目中的开发优先级。
对于Pluto开发社团而言,最重要的一点是要保证Pluto与最新版的Java Portlet规范的兼容性。 功能的加强和bug的修复必须在这个前提下来完成。
确保不要在该参考实现中引入歧义,这是Pluto开发团队的责任。如果加强一个功能会引起一些与 规范有关的问题,那将不会被采纳。
Pluto项目的目标是构建一个强壮稳定且易于使用的portlet容器,这将使开发者们更容易的去接 受它和使用它。为了达到这一目的,我们认为,如果一个功能是属于规范所定义的范畴以外,那么 它可以被集成到Pluto中去。但它必须被放到一个单独的包(package)中,并且在文档里声明这 一点(即“属于规范所定义的范畴以外”这一点)。必须保证,即使把这些功能移除,Pluto依然可 以运行,并保持与规范的完全兼容。在大多数情况下,应该只需修改配置参数就可以移除这些额外 的功能。
最后,虽然Pluto项目包含了很多子项目,但必须认识到,只有Pluto Portlet Container 项目(也即Java Portlet规范的参考实现)才是最重要的。Portal驱动器、testsuite和部 署器(deployer)等子项目的存在只是为了简化Pluto Portlet Container项目的使用和 测试。因此,任何对那些组件(尤其是portal驱动器)的显著的强化在付诸实现之前都必须通过 审查,因为那很可能已经超出了Pluto项目的范围。
Roadmap
许多人建议对Pluto的实现进行重构,这主要是因为Pluto目前的实现太复杂了,他们认为应该 把Pluto写的“更象一个容器”。在未来,Pluto二代也许将简化一下实现的方式,并使用更多的 标准设计模式。对于设计一个容器而言,IoC模式是个不错的选择。
Pluto和WSRP
JSR 168规范和Web Service for Remote Portlets(WSRP)标准有高度的一致性。这两 个同时出现的标准都发布了开放源码的实现,它们的实现都完成了在相应的规范中定义的所有必要 功能。这两个标准都把能很好的互相协作作为它们共同的目标。因此,WSRP portlets在 portlet容器中既可以作为消费者运行,也可以作为生产者运行。
Pluto项目必须支持在一个Portal中运行多个portlet容器。因此,Pluto Portlet容器可以 被多次初始化。更重要的是,它可以以不同的方式运行,每个portlet容器都使用一个不同的SPI 实现。