JSR 168与WSRP

 作者：Rachel Greenblatt

 

　　您为什么需要标准呢？您曾经经历过尝试整合业务合作伙伴的门户——可能是有防火墙并正在运行.Net的机器——的痛苦吗？您曾经花费数周的时间为某一业务部门部署一个个性化的portlet，不料竟发现您需要辛勤地重新编程以便为其他五个使用不同门户的部门部署该portlet吗？您曾经想在您的企业外的门户中部署一个portlet吗？
　　标准可以减轻进行移植和实现互操作性的痛苦。随着门户标准JSR168和用于远程Web服务Porlet（WSRP）的广泛采用，来自这些任务的痛苦将会消失。
　　总的来讲，这些新标准正在给门户部署的本质带来根本性的变化，伴随而来的是门户开发商市场的剧变。越来越多的客户在根据门户的总体体系结构是否符合该企业来选择门户技术，而不是根据门户的一组专用的特性，例如portlet的数目来选择。

JSR 168
　　JSR168是Java 规范要求（Java Specification Request ，JSR）的缩写，它为创建portlet建立标准的API。BEA参与了Java标准化组织（Java Community Process）创建JSR168标准的过程，并且WebLogic Portal 8.1支持JSR 168。
JSR 168的主要价值在于它被独立软件开发商（ISV）所广泛采用。在采用JSR 168之前，企业应用程序开发商不得不支持所有开发商门户的不同portlet集。支持多个门户开发商不同的portlet集在类似业务信息、内容管理、检索和分析这样的领域中非常令人头疼。
　　JSR 168是解决ISV这样问题的灵丹妙药，现在开发商只需要支持一种portlet集。结果，更多的ISV提供他们自己的通用的、开箱即用（out-of-the-box）的门户集成组件。这是值得客户高兴的时刻，因为开箱即用的应用程序集成现在无需考虑选择那个门户开发商就可以使用。
　　JSR 168是为实现porltet、基于Java的门户服务器和其他Web应用程序之间的互操作性而设计的。BEA采用此标准，通过减少开发商的占用来保护客户当前的portlet投资。大多数商用门户产品现在都支持JSR 168，因此开发符合JSR 168规范的portlet的客户可以将portlet从某一开发商的门户移到另一个开发商的门户中。此外，客户现在还可以使用迅速增长的开箱即用、符合标准的、支持ISV的portlet集。
　　按照Java标准化组织（Java Community Process）所述，JSR 168 portlet拥有一个适用于所有门户客户端的简单的、标准的API，支持多种类型的客户端（多设备、多浏览器），支持本地化和国际化，允许门户应用程序的热部署和重新部署，并且包含声明性安全（与servlet和企业JavaBean规范中使用的机制相同）。
　　由JSR 168获得的主要好处是通过标准化得到的互操作性。一个门户开发商开发的portlet可以很轻松地部署在不同开发商的门户中，并且这样的标准化简化了现有系统的升级、以及开发新系统的过程。
　　最主要的门户开发商已经宣布计划支持JSR 168标准，下面这些ISV正在致力于使他们的应用程序可作为符合JSR 168规范的porlet而提供：Bowstreet、CoreMedia、Citrix、Digital Harbor、Documentum、EDS、Fatwire、Filenet、Fuego、Macromedia、Interwoven、HP、MobileAware、Pegasystems、Orbeon SAS Institute、Stellant、Saba、Sybase、Tarantella、 Sun和Vignette。由于很多ISV一直在支持JSR 168，所以查看JSR 168站点（参见资源）可以得到目前为止JSR 168支持者的完整列表。
　　JSR 168意味着在门户市场上，争夺主导地位的优势不再是哪个开发商拥有最多数目ISV的开箱即用集成。相反，标准化通过使ISV支持他们自己的porlet统一了这一领域。客户的风险和成本降低，并且不再根据重建portlet的的业务量来选择门户开发商。在选择门户开发商的时候，主要的决定性因素将是门户产品与客户企业体系结构的适应程度。

WSRP
　　由portlet标准化获取的益处被WSRP进一步得到了增强。WSRP由OASIS（一个由开发电子商务标准的行业专家所组成的非赢利性社团）创建，它规定porlet的远程城县（rendering）。BEA是WSRP委员会中的一员，WebLogic Portal 8.1支持WSRP既作为远程portlet的“生产者”，又作为远程portlet的“使用者”。
　　WSRP使获得原来极难实现的功能成为可能，例如，部署portlet一次，但把它们传递到任何地方，将第三方的portlet整合在一起，增强来自不同开发商的门户之间的互操作性。
　　第一次，WSRP也为客户提供了一种构建联合门户的可行方法。联合门户由互操作的门户网络组成，由此，某一门户托管的资源可以被许多门户使用（参见图1）。采用联合门户有无数的好处，包括门户合理化和更少的IT管理的Web资产。

图 1

　　联合门户由互操作的门户网络组成，由此，某一门户托管的资源可以被许多门户使用。
　　过去，一个portlet只能被托管它的同一门户本地使用。而有了WSRP，则可以将一个portlet从门户表面（“使用”）的portlet交给物理上、逻辑上独立的基础设施托管（“生产”）。由于这种革新，WSRP具有从根本上增强门户部署灵活性的潜能。
　　因为门户能够从任何地方的portlet中提取内容，所以业务部门现在可以编写和维护他们自己的portlet。这可以在各个业务部门的本地基础设施上完成，所以某一单个门户内的所有portlet不必部署在单个门户实例上。由于防火墙或者不同部署方案而一度难以更新和修改的内容，现在可以由各业务部门方便而快捷地进行。业务部门获得了前所未有的独立性和灵活性。
　　此外，通过减少实现和传递与代码的相互影响，可以很容易地组合企业的内容。开发者团队可以独立于业务部门来进行开发，业务部门可以不受互操作性问题的困扰，而很快地适应多变的业务需求。
　　WSRP将降低门户维护的成本。Portlet可以部署在比运行任务关键门户所需的机器价格便宜的机器上，结果是降低了门户基础设施的总体成本，提高了系统的可靠性。由于不再要求portlet和门户协同定位，所以各个组织可以扩展他们的门户而保持他们的远程porlet不变。信息阻塞比较严重的portlet可以用计算能力单独处理。版本控制问题也减少了或者消失了。合作伙伴可以管理他们自己的portlet，而不必共享安全的或者私有的信息或者基础设施。
　　WSRP拓宽了门户可以利用的资源范围。Porlet可以被所有J2EE门户或者所有运行.Net的机器生产或者使用。Weblogic Portal 8.1能够使用.Net应用程序。整个企业都可以利用现有的portlet，而不用管企业目前的门户开发商。不再受开发商制约，并且较少了IT方面的费用，节约了托管和部署重复portlet的时间。成本的节约是不同的开发商和不同的业务部门有权使用相同的应用程序和数据的结果。
虽然大多数门户行业的公司支持WSRP，但BEA是参与测试WSRP版本1.0实现的互操作性为数不多的公司之一。

联合门户
　　BEA正在与他的一些最喜创新的客户一起利用WSRP开发联合门户解决方案。通常，联合门户体系结构涉及大量单独管理的门户。各门户既起着portlet生产者（对于其他门户来说）又起着portlet使用者（从远程门户来看）的作用。
例如，市场部的门户可能使用来自设计门户的portlet，同时为销售门户提供portlet。联合门户网络允许业务部门维护和托管他们自己的portlet，因此，减轻了IT中心的负担，增加了整个门户网络的灵活性。联合门户有从根本上改变业务伙伴如何使用彼此IT服务的潜能。
　　联合门户体系结构还提供使企业门户合理化的机制。通过对现有资源启用WSRP，客户可以移植用户到某一使用这些资源的“überportal”。WSRP也有助于克服门户合理化的主要障碍，那就是对于大型、复杂的业务，单个门户不是可行的选择。
　　利用WSRP，客户可以标准化整个组织的单个门户架构（überportal），在该门户架构内，许多较小的门户使用彼此的内容。因此，不再需要单一的门户部署，各个IT服务只部署一次，就可达到始终如一地使用各个IT服务。
　　因为BEA在帮助世界各地客户部署最复杂的预定软件系统方面有着丰富的经验，所以被惟一放置在实现最好WSRP标准的位置——一个可以支持不同规模的企业联合门户体系结构。

结束语
　　JSR 168和WSRP是门户未来和门户合理化的关键。内容和信息可以在本地源上进行管理，但可以从任何源访问。业务部门可以在其他部分使用内容的的同时而保持对内容的管理权，而开发者团队可以独立进行开发。企业在朝着统一的、联合门户架构发展，在联合门户架构中，共享门户组件为共享业务服务铺平了道路。联合门户增加了不同业务部门和业务伙伴之间共享内容的灵活性。
　　例如，某家零售公司可能有面向客户的门户需要与批发商集成。用WSRP通过portlet的远程呈现，不仅零售商的门户直接与供应商的portlet集成在一起，而且供应商仍然可以作为主机，独立于零售商维护和更新内容。JSR 168通过减少开发商的独占提供价值。通过使portlet与任何一个开发商的门户集成，将节约代码和程序员大量的时间。

原文出处：
JSR 168 and WSRP: Setting High Standards
New standards fundamentally change the portal landscape
http://www.fawcette.com/weblogicpro/2004_11/magazine/features/rgreenblatt/