portal产品分析报告

- 1 - PORTAL 分析报告分析报告 徐亚斌 Portal 是 web 应用发展的一个重要趋势，目前几乎所有大的软件厂商都有自己的 Portal 产品。并且 Portal 技术已经形成规范。本文对 Portal 技术和产品进行了分析，目的是为公 司产品的规划提供参考。本文包括 4 个部分：Portal 简介、Portal 厂商及 Portlet 规范、 Portal 技术分析、相关技术JSF。 Portal 简介介绍了 Potal 的概念，Portal 的发展等基本情况。 Portal 厂商及 Portlet 规范介绍了国内外主要的 Portal 厂商、Portal 开放源代码项目，以 及刚刚通过的 Portlet 规范JSR (Java Specification Request) 168。 Portal 技术分析介绍了 Portal 技术的核心概念以及实现思路。 由于组件化 web 页面开发对 Portal 技术及公司产品都有很大的影响，因此在本文的第 四个部分专门介绍了组件化 web 页面开发的技术 JSF。 1 Portal 简介简介 1.1Portal 的概念的概念 根据（JSR (Java Specification Request) 168）的定义，Portal 是基于 web 的应用，它主 要作为信息系统的展现层，提供个性化、统一登录和内容整合的功能。整合就是将不同来 源的信息集中展现在一张网页上。一个 Portal 可以具有很多个性化参数，用来调整为用户 定制的内容。对于不同用户，一个 Portal 网页可能由多组不同的页面构件portlet（定义参 看 3.1 节）组成，portlet 为不同用户生成不同的定制内容。Portal 网页的内容如图 1 所示。 Portal 网页中的 Portlet 窗口存在常规、最大化和最小化三种状态，窗口的状态可以由用户 调整。 从上面的定义可以看出，Portal 的核心思想是网页个性化，它有两个含义，一是为不 同的网页访问者匹配不同的内容(信息)，二是为不同的网页访问者提供不同的 portlet 应用 服务，并在所能提供服务的基础上根据访问者的不同相应改变处理流程。这个理念与 CRM 的理念非常相似。 下面从 Portal 的分类开始，介绍 Portal 的发展过程。 图 1 Portal 网页的内容（摘自 JSR168 文档） 1.2Portal 的分类的分类 最初的 Portal 指的是像 Yahoo、Lycos 这样的 Internet 门户网站。这些门户网站为用户 提供了检索、分类和类似“My Yahoo!“的个性化定制服务，目的是帮助用户更快地找到自己 所需要的信息。这样的 Portal 被称为 Public Portal，即面向公众的信息门户。 随着 web 应用的发展，又出现了 Vertical Portal 和 Enterprise Information Portal。Vertical Portal 即行业门户，目的是帮助某一行业的商业人员和技术人员找到自已需 要的特定行业的商业信息和技术信息。Enterprise Information Portal（EIP）即企业信息门户。 目的是帮助企业用户及员工通过统一入口找到分布于企业的各种信息。与 Public Porta 相似， lVertical Portal 和 EIP 也同样提供了检索、分类和个性化定制服务。 在以上三种 Portal 中，EIP 出现的包含内容最多。因此下文中的 Portal，如果不特别声 名，指的就是 EIP。 1.3EIP 的发展过程的发展过程 EIP 与 Yahoo、新浪等 Public Portal 网站是不同的。无论其面对的使用者还是要解决的 实际问题以及安全模式、与业务系统的集成等方面都有较大的不同。但是，从 EIP 的发展 历程来看，这两者之间又存在着联系，EIP 是在 Public Portal 的基础上逐步发展起来的。 本文从功能扩展的角度，将 EIP 的发展分为五个阶段： 在 EIP 发展的最初阶段，Portal 实际上就是一些静态网页，用户通过这些网页可以获 得企业提供的信息及服务，如图 2 所示。 图 2 EIP 发展的最初阶段 在 EIP 发展的第二个阶段，随着信息量的增加，EIP 将企业中可以为大家共享的文档 集成起来，并增加了搜索功能和内容发布功能，从而在一定程度上实现了内容管理 （Content Management） ，如图 3 所示。 图 3 EIP 发展的第二阶段 在 EIP 发展的第三个阶段，为了更好的支持企业的业务运营，EIP 增加了工作流、渠 道（包括电子邮件等）的功能。使得 EIP 逐渐发展成为企业运营的平台。这时的 EIP 已经 具备了初步的集成过程和交互能力，如图 4 所示。 图 4 EIP 发展的第三阶段 在 EIP 发展的第四个阶段，集成了更多的应用，如 ERP、CRM、SCM 等。同时，增 加了 web service 引擎，EIP 集成业务的能力进一步增强，逐渐成为与这些业务系统进行交 互的平台，这时 EIP 的理念与 EAI 已经有些类似，如图 5 所示。 图 5 EIP 发展的第四阶段 在 EIP 发展的第五个阶段，EIP 软件进一步与应用服务器相结合，加强了高级的个性 化功能，发展成为应用服务器之上的管理客户、员工和合作伙伴应用的一个框架，如图 6 所示。 图 6 EIP 发展的第五阶段 以上阶段的划分主要基于 EIP 功能扩展的考虑。EIP 演化的时间并不完全符合这种阶 段划分方式。一些机构也研究了 EIP 的发展过程。例如图 7 是 AMT（企业资源管理研究中 心）组织给出的 EIP 发展过程，AMT 将 EIP 的发展分为静态网页、内容集成、企业运营平 台和完善的 Portal 四个阶段。可以看出，ATM 对 EIP 发展过程的理解和本文的理解基本上 是相同的。 图 7 AMT 给出的 EIP 的发展过程 1.4EIP 的功能的功能 可以将 EIP 的功能概括为： 1）统一的访问渠道）统一的访问渠道 EIP 为用户提供了统一的访问渠道。无论信息存储在何处，信息的格式如何，都可以 按照预先的定义向用户个性化地组织和展现信息、应用和服务。向企业管理者、员工、供 货商、用户、经销商等提供统一的渠道访问其所需的信息。 2）内容管理）内容管理 EIP 与其他系统（比如 OA、Workflow 等）结合，提供了内容搜集、组织、筛选、分 发、展示、搜索和自定义等一系列功能，实现了对企业信息的高效和有序的管理。 3）个性化的设置）个性化的设置 EIP 根据不同的角色来确定 Portal 的个性化设置，以满足用户的需求。例如用户可以 自行选择显示语言、页面样式、及自己感兴趣的信息。 4）协同工作）协同工作 Portal 使内外用户可以通过统一的平台协同和高效地完成工作。 5）企业集成）企业集成(EAI)与商业智能与商业智能(BI) Portal 可以将客户关系管理、人力资源管理、项目管理、财务管理、工作流程管理、 知识文档管理、资产管理等企业现有的应用无缝地集成到一起，一方面可以从 EIP 中获取 这些系统中的数据，另一方面也可以从 EIP 中将数据写入到业务系统中去，从而完成企业 相应的业务流程和资源管理，例如客户交易、产品发布、邮件集成、请求处理、人事管理、 项目安排等。 1.5Portal 的价值的价值 从不同的角度出发，对不同的应用来说，Portal 所体现的价值是不同的。 首先作为一个网络用户，基于 Portal 的网站能够为我们更有效的提供信息和服务。虽 然目前的 Internet 为我们提供了大量的信息，但这些信息非常分散并且重复很多。因此有 必要建立以行业或专业领域为中心的网站，集中提供某个行业或领域的信息和服务。 在网上商店、书店和知识型网站和电子政务的层次，如果能够为用户提供内容定制和 服务定制的功能，通过网站的渠道实现 CRM，对用户来说将是非常有吸引力的。事实上， 国外的一些知识型网站就提供了检索和内容定制的增值服务，例如技术网站 expert exchange 提供的专家答疑是免费的，但内容检索和定制是付费的。 对于企业内网系统来说，如果通过 Portal 与外网集成，将减少网络系统开发和维护的 成本。通过企业内部文档和资料的内容管理，可以加强知识的积累和共享。通过建立公告 信息，记事本、聊天室等协同工作的工具，可以帮助员工提高工作效率。通过 EIP 与企业 旧有信息系统(如 ERP、SCM、POS)的运作结合，可以强化企业的运作效率。 1.6EIP 的应用情况的应用情况 1998 年 11 月，美林公司（Merrilllynch）发表了一份题为“超越 YAHOO！企业信息 门户已经上路”的关于 EIP（Enterprise Information Portal）的研究报告，当时在美国企业界 引起了巨大反响。在以后的 5 年中，很多欧美公司都导入了 EIP。 从信息系统建设的情况看，几乎所有的国外大公司（覆盖各个领域） ，例如 IBM、富 士通、欧莱雅等都部分实现了内容管理的功能，用户可以很容易地在其网站查到公司的产 品和公开的技术文档，其 EIP 发展的重点是统一入口和业务过程的集成。而国内的网站， 即使象方正这样知名的 IT 公司也没有实现内容管理的功能。在内网建设方面情况要好一些， 象联想、中国移动、网通公司、华泰保险公司、河北电信等都引入了企业内部管理的 EIP 系统（根据微软资料） 。在通过 EIP 进行应用系统整合方面，国内的案例很少，例如亚信帮 助网通启动首个 EIP，来整合其电信应用系统。 可以说，目前国内 EIP 的市场还没有完全启动。 2 Portal 厂商及厂商及 Portlet 规范规范 2.1国外厂商国外厂商 因为 Portal 是一个相对较新的技术趋势，各种背景的国外软件厂商都投入这个市场。 这些软件厂商几乎囊括了所有的知名软件厂商。下面，我们按照 1.3 节提到的 EIP 的发展 过程对这些厂商分类。 在 EIP 发展的最初阶段，只有一些纯粹的 Portal 供应商，如 Epicentric， Plumtree 和 Viador 等。 在 EIP 发展的第二个阶段，增加了一些提供搜索引擎和内容管理的厂商。搜索引擎的 厂商包括 autonomy，arisem 和 Verity 等，内容管理的厂商包括 Documentum， Interwoven， iManage， InStranet 和 OpenText 等。 在 EIP 发展的后面阶段，随着 EIP 与应用集成的发展，WEB 应用服务器和数据库服务 器的提供者、CRM 和 ERP 的提供者、EAI 厂商也加入到 EIP 厂商的行列。服务器厂商包 括 IBM，Oracle，BEA，Sybase 以及微软。CRM 和 ERP 厂商包括 BroadVision，Vignette，SAP 和 PeopleSoft 等。EAI 厂商象 Tibco 和 WebMethods 等。 随着数据仓库工具的普及，商业智能供应商，例如 Connos，Business Objects 以及 Brio 等也加入到 Portal 厂商的行列。它们都提供了集成分析报表与 Portal 的工具。 2.2台湾和国内厂商台湾和国内厂商 台湾的 Portal 厂商主要都是由搜索引擎的厂商发展而来的，目前主要发展知识管理、 内容检索和内外网的内容整合业务。主要的厂商包括意蓝（eLand） 、网擎（Openfind） 、龙 卷风（tornado）等。 上述公司中，意蓝的搜索引擎完全采用 java 技术。 龙卷风（tornado）在北京设有分公司，目前已经发展了方正、华为、上海交大等客户。 随着 Portal 的发展，国内的一些厂商也推出了自己的 Portal 产品，例如中关村科技软 件有限公司、东方资通（上海东环资通信息技术有限公司） 、上海安软计算机科技有限公司 等。 2.3开放源代码项目开放源代码项目 除了上面提到的国内外厂商外，一些开放源代码组织也提供了基于 JAVA 平台的 Portal 解决方案，这些开源产品有 JetSpeed、Jboss nukes、Liferay 等。 JetSpeed 是 Apache 组织的一个 Portal 开源项目， IBM 早期的 WebSphere Portal Server 就是基于 JetSpeed 进行二次开发的。jcorporate 的 Expresso（一个基于开放标准的 J2EE 体 系框架）也采用了 JetSpeed。 Jboss nukes 是基于 postnuke、phpnuke 等内容管理系统开发的 java 平台的内容管理系 统。由于使用了 java，其在响应速度和系统集成能力等方面都要比用和 php 开发的 postnuke、phpnuke 等系统出色。 Liferay 的 portlet 配置文件可以自由地动态扩展，并使用 Apahce Lucene 实现全文检索 功能。 另外，Portal 是 J2EE 平台上的企业应用架构的一部分。下面列出了一些主要的 J2EE 整体架构方面的开放源代码产品，可以作为下一步产品研究的参考，这些产品包括 Struts、 WebWork、Expresso、keelframework 和 Jahia，Portal 是这些产品或产品架构中的 一部分。 2.4Portlet 规范规范 随着 Portal 产品的不断扩大，不同厂家为各自的 Portal 构件（portlets）定义了不同的 API。这些 API 接口的不匹配对应用者和开发者都带来了很多问题。于是，形成了 Portlet 规范JSR (Java Specification Request) 168（可以从 下载） ，本文中的定义都源自 JSR168。 JSR168 起草的专家成员囊括了所有的 EIP 主要厂商，包括 Apache, ATG, BEA, Boeing, Borland, Broadvision, Citrix, EDS, Fujitsu, Hitachi, IBM, Novell, Oracle, SAP, SAS Institute, Sun Microsystems, Sybase, TIBCO, 和 Vignette 等。 JSR168 遵循 J2EE 规范 1.3 版，运行于基于 J2EE 架构的环境。由于 JSR168 刚刚通过， 在目前作者所知道的已经发布的产品中，只有 Liferay 的 Portal 2.0.0 支持 JSR 168。相信 各大公司很快都会推出符合 JSR168 规范的产品。 3 Portal 技术分析技术分析 3.1基本概念基本概念 3.1.1 Portlet JSR-168 Portlet Specifications 对 Portlet 的定义如下： portlet 是基于 web 的 Java 组件。它由 portlet 容器管理，能够处理请求，产生动态内容。 portlet 被 Portal 用作为可插拔的用户接口组件，为信息系统提供展现。 由 portlet 动态产生的内容也被叫做 fragment。fragment 是遵循某种规则的标记（例如： HTML，XHTML，WML） ，可与其他的 fragment 一起建立一个完整的文档。一般一个 portlet 产生的内容和其他的 portlet 产生的内容聚集在一起形成 Portal 网页。 3.1.2 Portlet 容器容器 portlet 在 portlet 容器中运行，portlet 容器为 portlet 提供必需的运行环境。portlet 容器 包含 portlet（组件）并且管理它们的生命周期，它也为 portlet 的参数设置提供持久化的存 储。 portlet 容器不是一个类似于 servlet 容器的独立容器。它是在 servlet 容器上通过扩展 方式实现的，并重用 servlet 容器提供的功能。 3.2工作原理工作原理 Portal 技术的原理如图 8 所示。 在图 8 中，portlet 的生命周期由 portlet 容器管理。web 端通过由 Portal 执行的请求/应 答机制与 portlet 进行交互。通常，用户与由 portlet 产生的内容进行交互，比如通过单击按 钮或链接，Portal 接收到 portlet 窗口的动作，随后将 portlet 产生的内容送至用户操作的 portlet 窗口。对不同的用户，一个 portlet 产生的内容可能会大不一样，这与用户对 portlet 的设置有关。 portlet 容器接收来自 Portal 的请求并运行它管理的 portlet 执行请求。portlet 容器并不 负责聚集 portlet 产生的内容，处理内容聚集是 Portal 的职责。Portal 和 Portlet 容器能够被 作为单一的应用组件组合在一起，也可以作为一个 Portal 应用的 2 个分离的组件。 Portal 服务器是建立在 Http 服务器的基础上的。 图 8 Portal 原理 下面是一个典型的事件序列。 一个客户端（例如：一个 web 浏览器）在被验证之后向 Portal 发出 HTTP 请求。 Portal 接收到请求。 Portal 判断请求是否包含与组成门户网站网页的 portlet 有关的动作。 如果存在与某个 portlet 相关的动作，Portal 请求 portlet 容器调用 portlet 处理动作。 Portal 通过 portlet 容器调用 portlet，获得被包含在产生的门户网站网页中的内容 片段。 Portal 将 portlet 产生的结果聚集于门户网站的网页，然后将网页返回至客户端。 4 相关技术和标准相关技术和标准JSF 4.1.1 web 开发页面组件化的技术发展趋势开发页面组件化的技术发展趋势 与 C/S 的应用开发相比，B/S 应用开发最大的缺点就是缺少象 DELPHY、VB 提供的 标准的客户端图形化界面开发工具。由于不能通过拖拉和属性设置建立菜单、按钮、表单 等页面控件，因此开发效率很低。 微软在.Net 中已经解决了这个问题，在 Visual Studio 中提供了 Microsofts .Net with WebForms 的工具，用于开发用户 Web 组件和支持 HTML 以外的标记语言。另外，国内象 bstek 这样的公司也提供了基于 DHtml 的页面组件化的技术方案。 JSF（JavaServer Faces）的出现正是为了在 java 平台上解决 web 页面组件化的问题。 4.1.2 JSF 是什么是什么 JSF 是生成基于 Web 的用户界面的应用程序框架。可以将 JSF 看作是 Struts（流行的 开放源码的 Web 应用程序框架）和 Swing（标准的用于桌面应用的 Java 用户界面框架）二 者的集成。类似于 Struts，JSF 通过一个控制器 Servlet 提供了 Web 应用的生命周期管理； 同时类似于 Swing，JSF 提供了包括事件处理和组件生成在内的丰富的组件模型。 JSF 的功能包括： 使你能够利用一些标准的可重用的服务器端构件来创建客户端界面。 提供了一组 JSP 标签来获取（访问）这些构件。 开发人员不用关心当页面刷新的时候页面状态数据的存储和重现。 提供了一个用于实现定制构件的框架。 封装了事件处理和构件显示，所以你可以使用标准的或者定制的 JSF 组件支持 HTML 以外的标记语言。 开发工具提供商可以开发针对标准 Web 应用框架的集成环境。 4.1.3 JSF 的现状的现状 JSF 的规范（JSR127）目前正在制订，根据 Java Community Process 的计划，JSF 规范 在今年底可以发布(目前最新的草案可以从 SUN 的网站 下载)。 JSR127 起草的专家成员包括 Sun、IBM、Borland、Macromedia、Apache、 Oracle 等， Sun、IBM、Borland 和 Oracle 都已声明在未来的开发工具中支持 JSF。 JSR127 遵循 J2EE 规范 1.3 版，要求提供 JSP 1.2 和 Servlet API 2.3 的支持，但不支持 老版本的 servlet 容器。 目前已经支持 JSR127 的产品包括 SUN 的JSF reference implementation、开放源代码 的 MyFaces和免费软件Faces console,，特别需要强调的是 Faces console 可以嵌入到 Borland JBuilder 、 Eclipse、IBM WebSphere Appl. Dev.、IntelliJ IDEA、 NetBeans 、Oracle JDeveloper、Sun One Sutdio (Forte)等 java 集成开发环境中。 另外 Crossbar 提供了一套基于 JSF 的应用集合。 4.1.4 Portal 和和 JSF 的关系的关系 由于一些知名公司既是 JSR127 的专家成员，也是 JSR168 的专家成员，因此，在 JSR127 的起草过程中，充分考虑了 Portal 和 JSF 的兼容问题。 从技术上看，Portal 技术主要在 J2EE 架构的前端，解决的是页面内容客户化和安全等 问题。而 JSF 技术是一个应用程序框架，设计到更广泛的机制。 从开发的角度看，Portal 管理的是大粒度的窗口内容的生成，而 JSF 支持的是小的控 件。因此，Portal 开发一定会用到 JSF 工具，来开发可视化的控件。 5 对对 EOS 产品的思考产品的思考 5.1EOS 向向 Portal 移植的考虑移植的考虑 Portal 方案集中在 J2EE 架构的前端，Portal 方案中的 Portal Server 是对 Web Server 的 扩展，Portlet 是对 Servlet 的扩展。而 EOS 对 Web Server 和 Servlet 容器没有扩展。因此， 从架构上分析 Portal 方案与 EOS 方案没有根本的冲突。 EOS 展现自动机的入口是一个执行统一控制功能的 Servlet，将 EOS 应用移植到 Portal Server 上，主要工作是将 EOS 中执行统一控制功能的 Servlet 重新部署成一个 Portlet。大部 分后端处理程序，包括业务自动机和 bl 方法应当不需要很大改动。尽管如此，仍然有许多 问题需要进一步明确。 1Portlet 容器与 Portlet 之间通过 PortletRequest 和 PortletResponse 对象来传递信息， 而 Servlet 容器与 Servlet 之间通过 HttpRequest 和 HttpResponse 对象来传递信息。虽然可以 将 PortletRequest 和 PortletResponse 看作是 HttpRequest 和 HttpResponse 的扩展，但信息传 递的细节需要进一步明确。 2EOS 从页面到后端的数据是通过一个统一的 bean 对象传递的，这种方式是否能应 用于 Portal 方案也需要明确。 3Portal 方案目录结构和配置文件与 EOS 方案肯定存在不一致。目录或配置文件改动 的细节需要进一步分析和试验，这些改动还将影响到系统安装程序。 4Portal 环境为了实现个性化，引入了 User 对象，提供对登录用户信息的统一管理。 而在 EOS 中，用户信息保存在 Session 中。当 EOS 应用转到 Portal 环境时，如果需要得到 用户信息，应当使用 Portal 环境建立的 User 对象而不是使用 Session 中的用户信息。这个 问题可能对 EOS 操作员管理和菜单功能管理的代码有一些影响。具体影响需要进一步分析。 5Portal 对组织权限和规则的管理也有自己的一套方法，可能与 EOS 原有的组织管理 和规则管理存在功能重叠或冲突。 5.2Bstek 方案、方案、JSF 与与 EOS 的比较的比较 Bstek 方案、JSF 与 EOS 的区别主要体现在以下几点： 5.2.1 Tags