欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜:Formal mathematics/Isabelle/ML, Formal verification/Coq/ACL2, C++/F#/Lisp
Apache Pluto
(→Pluto和WSRP) |
|||
(未显示1个用户的1个中间版本) | |||
第37行: | 第37行: | ||
Image:jw-0801-RI_deploy.jpg|deployment in the RI | Image:jw-0801-RI_deploy.jpg|deployment in the RI | ||
</gallery> | </gallery> | ||
+ | |||
+ | {{Comment}} | ||
[[Category:Portal]] | [[Category:Portal]] | ||
[[Category:Apache]] | [[Category:Apache]] |
2010年9月17日 (五) 04:52的最后版本
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 实现。
以上来源: http://people.apache.org/~zheng/pluto/chinese/
<discussion>characters_max=300</discussion>