毕业设计-基于PORTAL技术的个性化门户网站论文.doc

基于基于 portal 技术的个性化门户网站技术的个性化门户网站 目目 录录 中文摘要中文摘要 3 英文摘要英文摘要 4 第一章第一章 引言引言.5 1.1 选题意义.5 1.2 论文研究内容.6 1.3 主要解决的技术问题.7 1.4 论文的内容安排.7 第二章第二章 国内外研究现状及相关技术国内外研究现状及相关技术 .8 2.1 portal 技术的提出及其发展历程.8 2.2 portal 技术原理9 2.3 研究现状及发展趋势11 2.4 相关技术14 2.4.1 j2ee 平台14 2.4.2 liferay portal 工作原理.17 2.4.3 mvc 模式介绍.20 第三章第三章 基于基于 portal 企业门户系统实现企业门户系统实现.23 3.1 总体设计23 3.2 数据库设计23 3.2.1 数据库的需求分析.23 3.2.2 数据库表的具体设计.24 第四章第四章 系统实现系统实现 .26 4.1 liferay portal配置 26 4.2 权限管理的设计29 4.3 编码实现37 第五章第五章 系统运行情况测试系统运行情况测试 40 5.1 测试的定义及目的40 5.2 测试的原则40 5.3 测试的方法40 5.3.1 界面测试.41 5.3.2 功能测试.41 5.3.3 需求测试.42 5.3.4 性能测试.42 5.4 测试中其他要注意的地方42 5.5 企业门户的测试43 第六章第六章 结论结论.44 参考文献参考文献.45 致致 谢谢 46 中文摘要中文摘要 portal 是近年 it 领域的一项重要新技术，是企业信息化的重要发展方向。当今，人 们对于信息的获取、集成要求越来越高。如何更好地解决信息获取的难题，使得适当的人 在适当的时间获取适当的信息。portal 就是在这样的背景下应运而生的，它帮助人们在获 取特定的数据时不用再进入众多的应用系统，而是由门户就可以方便快捷的获取信息，人 们能够快速地调用各种不同的后台应用，并完成对后台应用的各种操作。portal 本身已经 由静态网页、内容集成、企业运营平台、应用集成发展到今天完善的 portal。把 portal 作为企业信息集成平台，实现企业信息应用的整合、集成、增值，已经成为重要的企业信 息应用集成基础框架。 英文摘要英文摘要 portal was a recent years it domain important new technology, was the enterprise informationization important development direction.now, the people regarding the information gain, the integrated request more and more are high.how solves the information acquisition difficult problem well, causes the suitable person in the suitable time gain suitable information.portal is arises at the historic moment under such background, it helps the people when the gain specific data does not need to enter the multitudinous application system again, but is may facilitate the quick gain information by the gateway, the people can fast transfer each kind of different backstage application, and completes to backstage application each kind of operation.portal itself already by the static homepage, the content integration, the enterprise operation platform, developed portal using the integration which today consummates.integrates the platform portal as the enterprise information, the realization enterprise information application conformity, the integration, the increment, already became the important enterprise information application integration foundation frame. 第一章第一章 引言引言 1.1 选题意义选题意义 经济全球化和信息网络化已成为当今世界发展的趋势。因特网的广泛应用与日益普及， 使得知识的产生、更新、传播、利用等环节大大加速；技术创新、技术扩散的速度明显加 快，用户需求瞬息万变，市场产品日新月异，竞争异常激烈。企业求生存、图发展，必须 有很强的应变能力和快速的反映能力。 目前的企业采用了各种应用系统，数据正以几何级数增长，这些存储在企业数据库、 主机、文件服务器上的海量信息是企业最为头疼的问题，企业迫切需要一种提供组织、搜 索和获取真正有价值的信息的解决方案。 企业信息门户超出了传统的管理信息系统概念，也超越了普通意义上的门户网站，它 也不仅是企业管理信息系统与电子商务应用的简单结合，他的核心是提供一个集成企业内 部和外部信息的基础设施，整合企业的知识管理系统、财务系统、erp 系统、流程管理等 应用系统，扩展企业资源管理的范围，从而更有效地利用企业的数据资源和信息资产。 企业信息门户通过这些数据与应用的集成和个性化的控制，为管理者、雇员、供应商、 用户、分销商等提供一个唯一的接入点，而且保证企业内部和外部的每个合法用户都能访 问到这些信息，充分满足企业对信息交流实时互动的要求。同时企业信息门户为各种类型 的用户提供个性化的信息搜索、访问和分析功能，帮助他们通过有效利用企业的信息资产 做出最佳的业务分析和决策。 在我国，随着信息化带动工业化战略的不断发展和深入，企业为了解决各个部门的信 息孤岛，提高获得有效信息的速度，减少成本，也将目光转向企业信息门户系统。尤其是 一些企业，企业信息化建设起步比较早，经过近十年的努力，建立了硬件设备先进、安全 基础扎实，应用软件系统门类齐全、信息量大的管理信息系统。 目前在线运行的大小应用系统有几十项，这些系统是企业信息化建设快速发展的必然 结果和真实写照，为企业的生产经营管理发挥了日益重要的作用。但是由于应用系统是在 不同时期、根据不同的需求、由不同厂商来开发实施的，应用系统的用户界面不友好，也 没有形成统一规范，所以企业的员工无法完全了解每一个应用系统的具体功能，更难熟记 所有应用的口令以及操作方式，大大影响和制约了各项应用的实际效果；而且不同的应用 系统都有自身的应用数据库，各个数据库也是独立运行的，这样使得各应用数据库之间没 有统一的数据标准、编码标准，数据的统一性、共享性、唯一性、稳定性没有保证，信息 孤岛现象严重，这为所有系统的整合和集成造成了障碍；对企业基础数据进行纵向比较和 深层次挖掘以及业务流程的整合集成带来了困难。 随着企业信息化浪潮的高速发展，企业信息门户已经成为未来企业信息化与电子商务 发展的主要方向。电力企业作为我国的龙头企业也迫切需要建设自己的门户网站来适应信 息化发展的需要。 1.2 论文研究内容论文研究内容 论文研究了基于 portal 技术的个性化门户系统的信息化发展现状，分析了 j2ee 开发 平台和现有 portal 方案的主要技术，设计了基于 liferay 框架下的企业门户网站的基本 架构。本文的主要工作如下： (1) 分析了 j2ee 开发平台的框架及主要技术，讨论了 j2ee 框架下的三层体系结构的 特点，对 web service 的体系结构，相关标准与技术进行了研究，指出了基于 j2ee 平台 下构建企业门户网站的优势所在。 (2) 设计了系统企业门户网站的体系结构，采用基于 j2ee 平台的 mvc 设计模式。按 照三层模式将 web 结构划分为表示层（web） 、业务层（biz）和数据层（dao） 。表示层由 web 窗体组成，实现 view 和 controller 的功能；业务层包括业务实体组件和业务逻辑组 件；数据层包括数据对象、数据访问组件等，由业务层和数据层共同实现 model 的功能。 (3) 在此系统中提出了一套基于用户、用户组、业务和角色相结合的身份控制方案， 实现了灵活多变的权限控制组合。 (4) 设计出一个比较清晰的页面框架展现机制，把 view 层布局框架分为三层：页面 (page)、面板(pane)、内容(content)。既能够满足用户灵活多变的需求又易于实现。 1.3 主要解决的技术问题主要解决的技术问题 在门户网站的建设过程中，以下几个问题解决起来是比较复杂和困难的： (1) 权限管理及单点登录问题。 (2) 个性化页面的展现机制。 (3) 为生成动态信息内容各 web 组件间的通讯问题。 在对现有的门户技术进行了研究分析后发现虽然对上面的问题已经有了比较成熟的解 决方案，但是实现起来比较复杂，对开发人员的要求较高，运行起来对系统资源的消耗也 比较大。所以在本文中力求研究出比较简单容易实现的解决方案。 1.4 论文的内容安排论文的内容安排 第二章第二章 国内外研究现状及相关技术国内外研究现状及相关技术 2.12.1 portalportal 技术的提出及其发展历程技术的提出及其发展历程 portal 一词是“门户、入口”的意思，基于 portal 技术的门户网站的概念起源于 internet 的门户网站，如美国的 yahoo，国内的 sohu 和网易等。1998 年 11 月，美国美 林公司发表了一份关于企业信息门户（enterprise information portal，简称 eip）的报 告，这份报告成为引导电子商务想象空间的问路石，在美国企业界引起了巨大反响。据报 告估计，1998 年全球 eip 市场已达 44 亿美元，2002 年将达 148 亿美元。又据 gartnergroup 市场研究调查中心预测，2003 年，60%的财富 500 家大公司会导入企业信息 门户。自 2003 年以来，ibm，bea，sybase 等一些重要的企业级软件厂商已经开始正式进 入这一市场，伴随着众多小规模的独立软件厂商的加入，这一市场迅速拥挤起来。 企业门户与 yahoo、新浪等 public portal 网站是不同的。无论其面对的使用者还是 要解决的实际问题以及安全模式、与业务系统的集成等方面都有较大的不同。但是，从企 业门户的发展历程来看，这两者之间又存在着联系，企业门户是在 public portal 的基础 上逐步发展起来的。 从功能扩展的角度，企业门户的发展分为五个阶段： 在企业信息门户发展的最初阶段，portal 实际上就是一些静态网页，用户通过这些 网页可以获得企业提供的信息及服务。 在 eip（enterprise information portal）发展的第二个阶段，随着信息量的增加， eip 将企业中可以为大家共享的文档集成起来，并增加了搜索功能和内容发布功能，从而 在一定程度上实现了内容管理(content management)。 在 eip 发展的第三个阶段，为了更好的支持企业的业务运营，eip 增加了工作流、渠 道(包括电子邮件等)的功能。使得 eip 逐渐发展成为企业运营的平台。这时的 eip 已经具 备了初步的集成过程和交互能力。 在 eip 发展的第四个阶段，集成了更多的应用，如 erp、crm、scm 等。同时，增加 了 web service 引擎，eip 集成业务的能力进一步增强，逐渐成为与这些业务系统进行交 互的平台， 这时 eip 的理念与 eai （ enterprise applicationintegration）已经有些 类似。 在 eip 发展的第五个阶段，eip 软件进一步与应用服务器相结合，加强了高级的个性 化功能，发展成为应用服务器之上的管理客户、员工和合作伙伴应用的一个框架。以上阶 段的划分主要基于 eip 功能扩展的考虑。eip 演化的时间并不完全符合这种阶段划分方式。 一些机构也研究了 eip 的发展过程。 2.22.2 portalportal 技术原理技术原理 jsr168 将 portal 的组成分为三部份 (1) portal server (2) portlet container (3) portlet。 1、portal server 的定义 建立在 http server 上。负责接收 http 请求，调用 portlet，并将 portlet 产生的内容 聚集到 portal 页面返回给用户。 （portal server 有时简称 portal） 2、portlet container 的定义 portal container：管理 portlet 的生命周期并且提供其运行所需要的必要环境。同时也 提供 portlet 相关信息的存储。一个 portlet container 接收到来自 portal 的请求后，接着将 这个请求传递给存在 container 的 portlet 执行。portlet container 没有义务去组合 portlets 产生的信息內容，这个工作必须由 portal （即 portal server）来处理。portal 和 portlet container 可以放在一起视为同一个系统的组件，或者分开成为两个独立的组件。 3、portlet 的定义 一个 portlet 是以 java 技术为技术的 web 组件，由 portlet container 所管理，专门 处理客户的 request 以及产生各种动态的信息内容。portlets 为可插式 ( pluggable ) 的客 户界面组件，提供呈现层成为一个信息系统。 这些由 portlet 产生的内容也被称为片段 (fragment)，而片段是具有一些规则的 markup( html、xhtml、wml )，而且可以和其他的片段组合而成一个复杂的文件。而 portlet 中的内容正常来说是与其他 portlet 的内容聚合而成为一个 portal 网页。而 portlet 的生命周期是被 portlet container 所管理控制的。 客户端和 portlets 的互动是由 portal 通过典型的 request/response 方式实现，正常来 说，客户会和 portlets 所产生的内容互动，举例来说，根据下一步的连接或者是确认送出 的表单，结果 portal 将会接收到 portlet 的动作，将这个处理状况转向到目标 portlet。这 些 portlet 内容的产生可能会因为不同的使用者而有不同的变化，完全是根据客户对于这 个 portlet 的设置。 portlet 生命周期 portlet 接口的四个方法构成一个完整的生命周期： public void init(portletconfig config) throws portletexception; 由 portlet 容器调用，在将 portlet 放入服务区前调用。portlet 容器在初始 portlet 后， 直接调用这个方法。 public void processaction (actionrequest request, actionresponse response) throws portletexception, java.io.ioexception; 由 portlet 容器调用，用来处理 action request。 public void render (renderrequest request, renderresponse response) throwsportletexception, java.io.ioexception; 由 portlet 容器调用，用来生成输出。 public void destroy() ; 将 portlet 从服务区中删除。 一个 portal 处理流程 1. 一个客户端（例如：一个 web 浏览器）在被验证之后向 portal 发出 http 请求； 2. portal（或称为 portal server）接收到请求； 3. portal 判断请求是否包含与组成门户网站网页的 portlet 有关的动作； 4. 如果存在与某个 portlet 相关的动作，portal 请求 portlet 容器调用 portlet 处理动作； 5. portal 通过 portlet 容器调用 portlet，获得被包含在产生的门户网站网页中的内容 片段； 6. portal 将 portlet 产生的结果聚集于门户网站的网页，然后将网页返回至客户端。 在下图中需要注意的是 portal 服务器是建立在 http 服务器的基础上的。portal 服务器 不可独立的运行。 2.32.3 研究现状及发展趋势研究现状及发展趋势 1、研究现状 虽然企业门户的概念可以被预言家们肆意地描绘，然而真正要实现企业门户，所面临 的问题却不是轻易能够跨越的。就目前国内门户市场的现状而言，我想用“困惑和硝烟并存 “来形容。对于门户实施的主体的 cio 们来说，他们更多的是困惑：他们害怕“为了使用这 个门而重建一所房子“ ，他们不仅要考虑不同的产品套件的产品成熟度、技术风险和应用 风险，还要考虑到企业现有的应用、系统以及员工的工作习惯、部门的经济利益等等，要 进行较多的权衡与折衷实在是困惑。而对于提供企业门户套件或解决方案的国内外厂商， 他们背后则在进行一场没有硝烟的战争。据估计，国内外主流的门户软件供应商早已超过 100 家。有关资料显示，2001 年， plumtree、sap 和 ibm 的市场占有率并列第一位，但这 三家公司各自的市场占有率都只不过 7%。2005 年 bea 系统有限公司(nasdaq：beas)以 2 亿 美元现金收购 plumtree 则是最好的说明。 在这样的一个大背景下，国内企业门户应用的现状怎么样？他们在建设企业门户的摸 索道路上是否有成功的经验和教训？企业门户建设的关键成功因素是什么？等等这些问题 都是需要我们去回答的。为此我们特进行了 2007 年中国企业门户应用现状与趋势的调查， 希望通过这样一项工作探索国内企业门户应用的脉动或规律，同时也籍此为国内正在进行 或将要进行企业门户建设的企业提供宝贵的参考意见。 中国企业的门户建设才刚刚起步，但企业门户应用的趋势不可阻挡 2002 年 6 月，gartner group 估计门户市场将从 2001 年的 709 万美元上升到 2006 年 的 2 亿美元；就在当月 idc 研究也表明门户市场将从 2001 年的 550 万美元上升到 2006 年 的 3.1 亿美元（见表 1）。 即使 delphi 保守估计，门户市场也有 20的增长率。在这种大环境下，国内那些企 业信息化完善的公司或那些敢于吃“螃蟹“的 cio 们已经在摸索中开始了门户建设，通过调 查企业门户建设的状态和水平，我们发现有 35.8%企业门户建设处于萌芽和启动阶段， 24.1% 的企业正在进行门户建设的规划制定工作，更有 7.3 %的企业部署了企业门户软件。 当然我们必须还注意到有接近 30%的企业没有门户建设的计划和 50的企业只是简单的进 行了企业内外网的建设。即使这样，还差不多有接近 6 成的企业对企业门户的关注和投入 在增加。相比于我们所调查的企业信息化大部分还处于业务操作电子化阶段和业务流程信 息化阶段，这样一个数据让我们感到非常意外，也让我们充满了信心，它暗示着企业门户 将会得到广泛的应用。虽然我们现在还无法估计国内的门户市场究竟有多大，但是根据我 们调查的结果，我们对于门户应用的趋势不可阻挡性还是十分乐观的。 2、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 上的浏览器）即跨客户端浏览器 平台，将是客户选择的一个重要标准。 2.42.4 相关技术相关技术 .1 j2eej2ee 平台平台 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 1.x 版本推出时就已经存在，而 message driven bean 则是出现在 ejb 2.0 的规格之中。 目前业界许多程序设计师，或者是网页设计人员，多利用 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 用于企业资源(各种企业信息系统和数据 库等)的连接，jax-rpc、jaxr 和 saaj 则是实现 web services 和 web services 连接的基 本支持。 j2ee 容器也称为 j2ee 服务器，大部分时它们概念是一致的。 衡量 j2ee 应用系统设计开发水平高低的标准就是：解耦性；你的应用系统各个功能 是否能够彻底脱离？是否不相互依赖，也只有这样，才能体现可维护性、可拓展性的软件 设计目标。 为了达到这个目的，诞生各种框架概念，j2ee 框架标准将一个系统划分为 web 和 ejb 主要部分，当然我们有时不是以这个具体技术区分，而是从设计上抽象为表现层、服 务层和持久层，这三个层次从一个高度将 j2ee 分离开来，实现解耦目的。 因此，我们实际编程中，也要将自己的功能向这三个层次上靠，做到大方向清楚，泾 渭分明，但是没有技术上约束限制要做到这点是很不容易的，因此我们还是必须借助 j2ee 具体技术来实现，这时，你可以使用 ejb 规范实现服务层和持久层，web 技术实现表现层。 .2 liferay portal 工作原理工作原理 portal 系统根据需要由一个或者多个 portal 页面组成，每个 portal 页面包含零个或 者多个的 portlet。每个 portlet 呈现自己的信息内容，以此实现内容聚合。通过定义每 个 portlet 的可用权限，实现个性化的桌面信息定制。 1、portlet 样式以及窗口状态 jcp 组织提出的 jsr168 规范定义了 portlet 的实现标准。每个 portlet 对外表现为一个 小窗口，有自己的默认样式和窗口状态。如上图，portlet 有自己的标题，浏览状态下支持 编辑、关闭、上移、下移、最大化、最小化功能，编辑状态下支持返回和关闭功能。从各 种数据来源提取的信息以 portlet 内容的形式呈现在 portal 中。 portlet 样式指出 portlet 正处于什么模式，portlet 通常会根据所处的模式而执行不同的 工作并产生不同的内容。 portlet 模式让 portlet 决定它该显示什么内容和执行什么动作。调用一个 portlet 的时 候，portlet 容器会提供一个 portlet 模式给那个 portlet。当在处理一个请求动作时，portlet 的模式是可以用程序来改变的。 jsr168 规范定义了三个 portlet 模式： 浏览、编辑和帮助，liferay portal 支持其中的 全部三个模式。同时 portal 是可以根据使用者的角色，来决定是要提供(显示)哪几个 portlet 模式给使用者操作。 例如，匿名使用者可以操作浏览和帮助等 portlet 模式的内容， 而只有授权过的使用 者可以操作编辑这个 portlet 模式所提供的内容或动作。 在浏览这个 portlet 模式里，所被期望要提供的功能是产生标记语言来表现此时 portlet 的状态。 举例来说， portlet 的 浏览 模式可以包含一个或多个画面让使用者可以 浏览与互动， 或是一些不需要与使用者互动的静态内容。 在编辑这个 portlet 模式里， portlet 需要提供内容和逻辑来让使用者定制 portlet 的行为。典型的说，编辑模式的 portlet 会设定或更新 portlet 的参数设定值。 在帮助这个模式里，portlet 应该提供有关这个 portlet 的帮助信息。这个帮助信息可 以是有关这个 portlet 的简单且条理清楚的视窗说明或是详细的说明整个来龙去脉。所有的 portlet 并不需要都提供帮助这个模式。 一个 portlet 可以根据窗口状态来决定在一个页面里该占多少空间。当调用一个 portlet 时， portlet 容器 需要告诉该 portlet 目前的窗口状态。 此时 portlet 可以根据窗口 状态来决定它该对多少信息作处理。在处理请求的过程中， portlet 可以通过程序的方式来 改变窗口状态。 2、portal 页面 每个 portal 页面包含零个或者多个 portlet 小窗口，构成一个完整的信息呈现页面。 portal 在启动之后根据 portlet 配置文件等信息，给 portlet 的标题等属性赋值，赋予 portlet 编辑、关闭等各种控制按钮，使 portlet 成为一个标准的 portlet 窗口。portlet 合并这些 portlet 窗口，组成一个完整的文档，即 portal 页面。每个 portlet 都处于相应 的布局当中，呈现事先定义的内容，表现 portal 公共的品质。而且 portlet 可以在不同的 布局之间切换。portlet 响应客户端的请求，并将请求提交到相应的 url 进行逻辑处理。 portlet 开发完毕之后，部署到 portal 服务器，由 portal 服务器负责组织、权限控 制和呈现。portal 页面创建过程如下: portlet 在 portlet 容器内执行，portlet 容器接收 portlet 产生的内容。通常 portlet 容器将这些内容提交给 portlet 服务器，portlet 服务器依照这些内容建立 portal 页面，然后将它传给客户端呈现。具体流程如下图: portal 页面的请求过程如下: 使用者经由客户端设备（例如浏览器）存取 portal，portal 根据接收到的请求决定 哪些 portlet 需要被执行以满足需求。portal 通过 portlet 容器呼叫 portlet，然后由 portlet 产生的片段建立 portal 页面，再传回客户端呈现给使用者。具体流程如下图: .3 mvcmvc 模式介绍模式介绍 mvc 模式是“model-view-controller“的缩写，中文翻译为“模式-视图-控制器“。mvc 应用程序总是由这三个部分组成。event(事件)导致 controller 改变 model 或 view，或者 同时改变两者。只要 controller 改变了 models 的数据或者属性，所有依赖的 view 都会自 动更新。类似的，只要 controller 改变了 view，view 会从潜在的 model 中获取数据来刷 新自己。mvc 模式最早是 smalltalk 语言研究团提出的，应用于用户交互应用程序中。 smalltalk 语言和 java 语言有很多相似性,都是面向对象语言，很自然的 sun 在 petstore(宠物店)事例应用程序中就推荐 mvc 模式作为开发 web 应用的架构模式。mvc 模 式是一种架构模式，其实需要其他模式协作完成。在 j2ee 模式目录中，通常采用 service to worker 模式实现，而 service to worker 模式可由集中控制器模式，派遣器模式和 page helper 模式组成。而 struts 只实现了 mvc 的 view 和 controller 两个部分，model 部分需要开发者自己来实现，struts 提供了抽象类 action 使开发者能将 model 应用于 struts 框架中。 mvc 模式是一个复杂的架构模式，其实现也显得非常复杂。但是，我们已经总结出了 很多可靠的设计模式，多种设计模式结合在一起，使 mvc 模式的实现变得相对简单易行。 views 可以看作一棵树，显然可以用 composite pattern 来实现。views 和 models 之间的 关系可以用 observer pattern 体现。controller 控制 views 的显示，可以用 strategy pattern 实现。model 通常是一个调停者，可采用 mediator pattern 来实现。 mvc 与 j2ee 架构的对应关系是:view 处于 web tier 或者说是 client tier，通常是 jsp/servlet，即页面显示部分。controller 也处于 web tier，通常用 servlet 来实现， 即页面显示的逻辑部分实现。model 处于 middle tier，通常用服务端的 javabean 或者 ejb 实现，即业务逻辑部分的实现。 mvc 设计思想 mvc 英文即 model-view-controller，即把一个应用的输入、处理、输出流程按照 model、view、controller 的方式进行分离，这样一个应用被分成三个层模型层、视 图层、控制层。 视图(view)代表用户交互界面，对于 web 应用来说，可以概括为 html 界面，但有可 能为 xhtml、xml 和 applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。 一个应用可能有很多不同的视图，mvc 设计模式对于视图的处理仅限于视图上数据的采集 和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模 型(model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界 面的输入数据和请求传递给控制和模型。 模型(model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程 对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型 的设计可以说是 mvc 最主要的核心。目前流行的 ejb 模型就是一个典型的应用例子，它从 应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为 应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少 了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。mvc 设计模式告诉 我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是 否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。mvc 并没有提供模型的设计 方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用 对象编程来做比喻，mvc 定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你 能做这些。这点对编程的开发人员非常重要。 业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化） 。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型 单独列出，所有有关数据库的操作只限制在该模型中。 控制(controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成 用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什 么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据 处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的 信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可 能对应多个视图，一个视图可能对应多个模型。 模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某 个视图的控制器改变了模型的数据，所有其它依赖于这些数据的视图都应反映到这些变化。 因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更 新。这实际上是一种模型的变化-传播机制。 第三章第三章 基于基于 portal 企业门户系统涉及企业门户系统涉及 系统设计是在系统分析的基础上由抽象到具体的过程.主要目标是将系统分析阶段所提出 的反映了信息需求的系统逻辑方案转换成可以实施的基于计算机与通信系统的物理（技术） 方案,为下一阶段系统实施提供必要的技术资料,应符合系统性,灵活性,可靠性,经济性的要求。 3.13.1 总体设计总体设计 企业门户 关 于 企 业 企 业 新 闻 产 品 信 息 人 力 资 源 招 聘 信 息 联 系 方 式 图 3.1 企业门户需要展现的信息模块 3.2 数据库设计 3.2.1 数据库的需求分析 依据项目的处理需求,对应数据表的设计及功能如下: 招聘信息表: 存放发布企业的招聘信息 新闻表: 存放网站内的新闻 用户表: 存放注册用户的基本信息 产品表: 存放公司产品的基本信息 3.2.2 数据库表的具体设计 表 3.1 getjob : 招聘信息表 字段名称数据类型字段大小作用必填字段索引是否主键 positionvarchar20职位是有(无重复) numvarchar50招聘人数是无 placevarchar5工作地点是无 paidvarchar20待遇是无 showtimevarchar50发布日期是无 agevarchar30要求年龄是无 表 3.2 news : 新闻表 表 3.3 userinf o : 用户信息表 表 3.4 produc t : 产品信息表 describervarchar500职位描述是无 字段名称数据类型字段大小作用必填字段索引是否主键 idint4自动编号是有(无重复) 是 titlevarchar50新闻标题是无 contentvarchar50新闻内容是无 authorvarchar50作者是无 typevarchar50新闻类别是无 degreeint4浏览次数是无 intimev