基于portal技术的个性化门户网站—毕业设计论文

基于portal技术的个性化门户网站—毕业设计论文内容摘要：

户市场的现状而言，我想用 困惑和硝烟并存 来形容。 对于门户实施的主体的 CIO们来说，他们更多的是困惑：他们害怕 为了使用这个门而重建一所房子 ，他们不仅要考虑不同的产品套件的产品成熟度、技术风险和应用风险，还要考虑到企业现有的应用、系统以及员工的工作习惯、部门的经济利益等等，要进行较多的权衡与折衷实在是困惑。 而对于提供企业门户套件或解决方案的国内外厂商，他们背后则在进 行一场没有硝烟的战争。 据估计，国内外主流的门户软件供应商早已超过 100家。 有关资料显示， 2020 年， Plumtree、 SAP和 IBM 的市场占有率并列第一位，但这三家公司各自的市场占有率都只不过 7%。 2020年 BEA系统有限公司 (NASDAQ： BEAS)以 2 亿美元现金收购 Plumtree 则是最好的说明。 在这样的一个大背景下，国内企业门户应用的现状怎么样。 他们在建设企业门户的摸索道路上是否有成功的经验和教训。 企业门户建设的关键成功因素是什么。 等等这些问题都是需要我们去回答的。 为此我们特进行了 2020 年中国 企业门户应用现状与趋势的调查，希望通过这样一项工作探索国内企业门户应用的脉动或规律，同时也籍此为国内正在进行或将要进行企业门户建设的企业提供宝贵的参考意见。 中国企业的门户建设才刚刚起步，但企业门户应用的趋势不可阻挡 2020年 6月， Gartner Group 估计门户市场将从 2020年的 709万美元上升到 2020 年的 2亿美元；就在当月 IDC研究也表明门户市场将从 2020年的 550万美元上升到 2020年的（见表 1）。 即使 Delphi保守估计，门户市场也有 20％的增长率。 在这种大环境下， 国内那些企业信息化完善的公司或那些敢于吃 螃蟹 的 CIO们已经在摸索中开始了门户建设，通过调查企业门户建设的状态和水平，我们发现有 %企业门户建设处于萌芽和启动阶段， % 的企业正在进行门户建设的规划制定工作，更有 %的企业部署了企业门户软件。 当然我们必须还注意到有接近 30%的企业没有门户建设的计划和 50％的企业只是简单的进行了企业内外网的建设。 即使这样，还差不多有接近 6成的企业对企业门户的关注和投入在增加。 相比于我们所调查的企业信息化大部分还处于业务操作电子化阶段和业务流程信息化阶段，这样一个数据让我们感到非常意外，也让我们充满了信心，它暗示着企业门户将会得到广泛的应用。 虽然我们现在还无法估计国内的门户市场究竟有多大，但是根据我们调查的结果，我们对于门户应用的趋势不可阻挡性还是十分乐观的。 Portal 未来的发展方向分析 Portal 的出现已经多年，在国内外大大小小的项目和产品中也有一些应用。 随着网络和应用技术的迅速发展， Portal 本身也会随之快速发展。 本文就 Portal的特点分析未来的Portal发展方向： 一、运行在浏览器中的“应用操作系统”：目前为止， Portal 已经有了国际规 范 JSR168，各大软件公司的 Portal都遵从此规范（包括： Microsoft、 IBM、 Bea等），通过此规范，大大增强了 Portlet 可移植性。 随着网络的快速发展，以后的 Portal 就是一个“应用操作系统”内核，软件开发人员只要按规范开发好应用，就可以“安装”到 Portal平台里，就好象 Windows 平台开发的软件一样，只要符合规范要求，就能 setup到系统中，系统菜单会自动添加相关的功能项，点击菜单就可以运行相应的功能。 这样的”操作系统平台“不是面向机器各种硬件的（ Windows、 Linux、 UNIX等都是驱动硬件的），而是面向具体应用功能的，比如开发一套进销存的 Portlet，注册安装到平台后，有权限的用户就可以选择这些 Portlet 进行工作 —— 完全是远程的，通过浏览器访问远程服务器的，而此远程服务器就安装有 Portal 平台 —— 一个“面向应用的操作系统” 二、前台界面平台决定多家 Portal并存：根据界面的技术特点、风格特征、处理效力，决定多家 Portal核心平台提供商并存，而不是根据后台技术（ JAVA、 .NET等）决定。 这就像 Windows 与 Apples 一样，对于用户来说不关心后台的实现技术，而是 根据界面、某些方 面的处理能力上做选择。 所以，如果能在 Portal 前台显示界面上有新的模式创新或突破，会有大的发展的空间，也更容易被用户青睐。 三、跨平台的优势仍然很重要：在操作系统平台上， Oracle 依靠其跨平台特点赢得大量的 Linux、 UNIX客户，使得 SQL SERVER 无法企及。 在 Portal平台发展的未来，跨平台性也是 Portal平台的竞争所在，只不过这种“跨平台性”是指跨多种“客户端浏览器”平台，对于客户来说，可以按喜好任意选择自己喜欢的浏览器，如果能兼容各种客户端浏览器（无论是 Linux、 Unix上的浏览器，还是 Windows上的浏览器） —— 即跨客户端浏览器平台，将是客户选择的一个重要标准。 相关技术 J2EE 平台 J2EE 是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。 J2EE 核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循 J2EE 架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的 窘境。 在 J2EE 架构下，开发人员可依循规范基础，进而开发企业级应用；而不同 J2EE 供货商，同会支持不同 J2EE 版本内所拟定的标准，以确保不同 J2EE 平台与产品之间的兼容性。 换言之，植基 J2EE 架构的应用系统，基本上可部署在不同的应用服务器之上，无需或者只须要进行少量的代码修改，即能大幅提高应用系统的可移植性 (Portability)。 J2EE 主由升阳 (SUN)与 IBM 等厂商协同业界共同拟定而成的技术规范，以企业与企业之间的运算为导向的 JAVA 开发环境。 J2EE 架构定义各类不同组件，如 Web Component、EJB Component„等，而各类组件可以再用 (reuse)，让已开发完成的组件，或者是经由市面采购而得的组件，均能进一步组装成不同的系统。 对于开发人员而言，只需要专注于各种应用系统的商业逻辑与架构设计，至于底层繁琐的程序撰写工作，可搭配不同的开发平台，以让应用系统的开发与部署效率大幅提升。 J2EE 的核心规范是 Enterprise Java Beans（ EJBs）。 EJB 依照特性的不同，目前共分为三种，分别是 Session Bean、 Entity Bean，以及 Message Driven Bean。 其中 Session Bean 与Entity Bean 算是 EJB 的始祖，这两种 EJB规格在 EJB ，而 Message Driven Bean 则是出现在 EJB 的规格之中。 目前业界许多程序设计师，或者是网页设计人员，多利用 JSP/Servlet 的便利性，进而在 J2EE 服务器之上开发相关的应用，或是整合公司内部的各种资源。 Java 2 平台依照应用领域的不同，共分为三大版本，分别是 J2EE、标准版本 J2SE（ Java 2 Platform, Standard Edition）、微型版本 J2ME（ Java 2 Platform, Micro Edition），以及 Java Card等。 从整体上讲， J2EE 是使用 Java 技术开发企业级应用的一种事实上的工业标准 (Sun 公司出于其自身利益的考虑，至今没有将 Java 及其相关技术纳入标准化组织的体系 )，它是 Java技术不断适应和促进企业级应用过程中的产物。 Sun 推出 J2EE 的目的是为了克服传统Client/Server 模式的弊病，迎合 Browser/Server 架构的潮流，为应用 Java 技术开发服务器端应 用提供一个平台独立的、可移植的、多用户的、安全的和基于标准的企业级平台，从而简化企业应用的开发、管理和部署。 J2EE 是一个标准，而不是一个现成的产品。 各个平台开 发商按照 J2EE 规范分别开发了不同的 J2EE 应用服务器， J2EE 应用服务器是 J2EE 企业级应用的部署平台。 由于它们都遵循了 J2EE 规范，因此，使用 J2EE 技术开发的企业级应用可以部署在各种 J2EE 应用服务器上。 为了推广并规范化使用 J2EE 架构企业级应用的体系架构， Sun 同时给出了一个建议性的 J2EE 应用设计模型： J2EE Blueprints。 J2EE Blueprints 提供了实施 J2EE 企业级应用的体系架构、设计模式和相关的代码，通过应用 J2EE Blueprints 所描述的体系模型，能够部分简化架构企业级应用这项复杂的工作。 J2EE Blueprints 是开发人员设计和优化 J2EE 组件的基本原则，同时为围绕开发工作进行职能分工给出了指导性策略，以帮助应用开发设计人员合理地分配技术资源。 J2EE 组成了一个完整企业级应用的不同部分纳入不同的容器 (Container)，每个容器中都包含若干组件 (这些组件是需要部署在相应容器中的 )，同时各种组件 都能使用各种 J2EE Service/API。 J2EE 容器包括： ◆ Web 容器 服务器端容器，包括两种组件 JSP 和 Servlet， JSP 和 Servlet 都是 Web 服务器的功能扩展，接受 Web 请求，返回动态的 Web 页面。 Web 容器中的组件可使用 EJB 容器中的组件完成复杂的商务逻辑。 ◆ EJB 容器 服务器端容器，包含的组件为 EJB(Enterprise JavaBeans)，它是 J2EE 的核心之一，主要用于服务器端的商业逻辑的实现。 EJB 规范定义了一个开发和部署分布式商业逻辑的框架，以简化企业级应用的开 发，使其较容易地具备可伸缩性、可移植性、分布式事务处理、多用户和安全性等。 ◆ Applet 容器 客户端容器，包含的组件为 Applet。 Applet 是嵌在浏览器中的一种轻量级客户端，一般而言，仅当使用 Web 页面无法充分地表现数据或应用界面的时候，才使用它。 Applet 是一种替代 Web 页面的手段，我们仅能够使用 J2SE 开发 Applet， Applet 无法使用 J2EE 的各种 Service 和 API，这是为了安全性的考虑。 ◆ Application Client 容器 客户端容器，包含的组件为 Application Client。 Application Client 相对 Applet 而言是一种较重量级的客户端，它能够使用 J2EE 的大多数 Service 和 API。 通过这四个容器， J2EE 能够灵活地实现前面描述的企业级应用的架构。 在 View 部分， J2EE提供了三种手段： Web 容器中的 JSP(或 Servlet)、 Applet 和 Application Client，分别能够实现面向浏览器的数据表现和面向桌面应用的数据表现。 Web 容器中的Servlet 是实现 Controller 部分业务流程控制的主要手段；而 EJB 则主要针 对 Model 部分的业务逻辑实现。 至于与各种企业资源和企业级应用相连接，则是依靠 J2EE 的各种服务和 API。 在 J2EE 的各种服务和 API 中， JDBC 和 JCA 用于企业资源 (各种企业信息系统和数据库等 )的连接， JAXRPC、 JAXR 和 SAAJ 则是实现 Web Services 和 Web Services 连接的基本支持。 J2EE 容器也称为 J2EE 服务器，大部分时它们概念是一致的。 衡量 J2EE 应用系统设计开发水平高低的标准就是：解耦性；你的应用系统各个功能是否能够彻底脱离。 是否不相互依赖，也只有这样，才能体现 可维护性、可拓展性的软件设计目标。 为了达到这个目的，诞生各种框架概念， J2EE 框架标准将一个系统划分为 WEB 和 EJB主要部分，当然我们有时不是以这个具体技术区分，而是从设计上抽象为表现层、服务层和持久层，这三个层次从一个高度将 J2EE 分离开来，实现解耦目的。 因此，我们实际编程中，也要将自己的功能向这三个层次上靠，做到大方向清楚，泾渭分明，但是没有技术上约束限制要做到这点是很不容易的，因此我们还是必须借助 J2EE具体技术来实现，这时，你可以使用 EJB 规范实现服务层和持久层， Web 技术实现表现层。 Liferay Portal 工作原理 Portal系统根据需要由一个或者多个 Portal页面组成，每个 Portal 页面包含零个或者多个的 Portlet。 每个 Portlet呈现自己的信息内容，以此实现内容聚合。 通过定义每个Portlet的可用权限，实现个性化的桌面信息定制。 Portlet 样式以及窗口状态 JCP 组织提出的 JSR168 规范定义了 Portlet 的实现标准。 每个 Portlet 对外表现为一个小窗口，有自己的默认样式和窗口状态。 如上图， Portlet 有自己的标题，浏览状态 下支持编辑、关闭、上移、下移、最。