j2ee电子政务门户设计规划

j2ee电子政务门户设计规划（一）
散步的老虎 @ 2005-8-27 13:55:35
政府是全社会中最大的信息拥有者和最大的信息技术的用户，有效地利用信息技术，通过建立一个真正有效的、可伸缩的电子政务系统，可以帮助政府向更加勤政、精简、廉洁和高效的方向发展。电子政务将实现政务应用的四化方向：信息统一化、办公自动化、政务公开化、管理科学化，通过一站式的管理和服务，提升政府部门职能、办公效率，更好的为国家和人民服务。
整个电子政务系统从需求上可以分为两大部分：综合门户系统和政府政务系统。前者是面向公众的一个窗口，通过门户系统方便企业或市民办事；通过后者可以在政府内部建立一个信息共享、办事流程自动运转的高效协作协调体系。
电子政务系统是个非常复杂纷繁的系统，涉及很多功能和具体要求，越是这样庞大的工程，越需要一个总体架构设计，将那些几百甚至上千种具体功能纳入一个总体框架下，这样电子政务系统才能变成一个可伸缩、可动态扩展、可维护又是可控制性的良性系统。
需求分析
门户系统是整个电子政务系统的基础，体现了政府为民服务的基本思想，社会的需求驱动了政府机器的运转，从图 7-1 的结构图中可以发现门户系统在整个电子政务系统中的重要性：

图 7-1 电子政务系统结构图
图 7-2 中门户系统是整个电子政务的最前端，政府可以通过新闻内容管理系统进行单向的信息发布，这是面向整个社会大众的；社会大众将需要政府服务的信息通过网上办事互动功能进行提交，通过专门接口系统将这种服务请求递交到专门的部门系统，需要在多个平级或上下级之间协调的，将由专门的协调督办管理系统进行跟踪，整个系统设计目标之一是保证每个社会请求政府服务的信息都能被随时跟踪定位到，这类似物流公司的货物，货物在某个时间处于哪个环节，处于什么状态，这些信息都能立即被社会大众查询到，从而起到对政府工作效率的社会监督作用。
作为政府领导决策机构，可以从政务专网系统了解一些政策的执行情况和反馈意见，从而为政策修订以及辅助决策提供良好的数据支持。通过决策支持系统，可以将决策层领导从事务性工作中解放出来，将更多时间和精力用于思考和设计推动社会进步的决策上来，同时也能够及时发现和修正一些可能不切实际的方针政策。
政府政务系统属于一个不断动态扩展的系统，是整个系统的核心功能部分，而门户系统是政务专网系统“界面表现”部分，这样的组成结构非常符合现在 B/S 主流技术的应用需求。
所以，从表面上看，门户系统和政府政务属于两个不同的系统，实际上他们是可以纳入一个统一框架系统下统一设计的，主要思路是：门户系统主要以 Web 技术来设计，而政府政务系统则设计成一个功能组件系统。
政府政务作为一个功能组件系统，其系统需求是动态，可以依据政府具体需求单独组件，下面首先对门户系统进行需求分析。
门户系统是提供对定制化信息或各种资源应用系统进行有效地访问的网站系统，在传统的门户网站中，信息丰富而复杂，但是访问门户的用户要求不一，因此如何提供一种有效的技术手段，使得用户通过网站能够迅速方便地访问或使用到自己需要的信息或资源，这种新的需求就促使专有门户 Portal 系统的诞生。
总体归结电子政务综合门户系统的用例需求如下：

图 7-2 门户系统的用例需求
在这样的需求中，门户系统需要帮助企业或市民能够方便的定制自己相关的信息内容，同时提供一个网上办事的窗口，使得企业或市民能够通过这个窗口实现一些行政审批服务、政府采购、网上税务以及网上工商等。
门户系统提供了丰富而复杂的内容频道，例如新闻公告类有政府公告、机构介绍、新闻活动、法律制度公告和修改；互动性功能有全文检索、电子论坛、意见反馈以及网上办事等，这些内容和功能中，不是每个用户都需要，这样就要求门户网站提供的这些内容频道或互动性功能是由用户可定制的，实现用户自己的自主管理，可定制性是门户系统一个主要功能需求。
由于门户系统属于社会大众和政府的交流接口处，社会大众需要门户系统更好地为自己服务，而政府政务系统需要门户能将自己的服务功能推向社会，在这两种需求驱动下，门户系统的内容必将变得非常复杂和纷乱， 如何对这些内容进行有效的管理和监控也将是门护系统的一个主要功能需求。
除了上述两大功能需求外，还有需要考虑下列重要因素：
有多少用户？都是哪几种类型的用户，用户的角色定义； 用户的访问权限。
需要支持多少种语言？
需要支持哪几种客户端？ PC 浏览器、手机移动还是其它？
需要支持哪几种媒体类型？声音、图形、以及实时图像？
有多少种内容频道？
如果连接现有的资源？ Servelt 、 http 、 SOAP 、 CORBA 等等？
为什么要使用 J2EE 技术
J2EE 作为一个新型成熟的分布式计算技术，已经广泛应用在很多领域，其可伸缩性、可扩展性的框架体系为应用系统带来了灵活的选择和实现。
使用 J2EE 技术来实现电子政务系统主要有两个好处：高度的安全性以及多样化的选择。
首先是满足安全要求，电子政务系统由于涉及国家机密，作为互联网中的一个部分，其系统的安全性应当是首要考虑的。
实现安全的要求是多方面的，首先是操作系统和通信方面，通过修改操作系统内核实现国家自己的加密体系是一种比较好的方案，那么很显然，基于开放源代码的 Linux 操作系统将可能大量使用在电子政务系统中，而 Java 是一种跨平台的安全型语言，因此 J2EE 技术在安全性上可以满足要求。
电子政务系统中将涉及到大量终端和 PC 机以及服务器，包括老系统和新系统， Windows 和 Linux 或 Unix 都有，电子政府系统如何利用这些现有的资源，实现系统无缝运行，跨平台语言 Java 无疑又是首选，这样节省了投资，降低了成本。
电子政务系统是个复杂的综合性系统，又有大量老的系统资源需要整合，在这个庞大系统的实施过程中，可能碰到前所未有的各种问题，技术作为一种工具是专门来解决这些问题的，但是只有技术工具的多样化，提供各种解决问题的可能性，就如同五金工具箱提供有各种不同的螺丝刀、扳手等，有了这些丰富多样、各有特点的技术工具支持，才能帮助我们解决各种问题，而 Java 系统已经发展成为一个开放源代码的标准体系，在这个体系中，每天都诞生大量丰富、各有特点的软件工具，这些无疑为电子政务系统的建设提供了有力支持。
总而言之，高度的安全性以及多样化的选择是使用 J2EE 建设电子政务系统最大的优点，政府作为信息技术的消费者，必须将自己立于一种有多种选择的主动地位，这本身也是一种安全性的考虑。
j2ee电子政务门户设计规划（二）
现有 J2EE 门户技术的分析和比较
Apache Jetspeed
JetSpeed 是 Apache （ http:// jakarta.apache.org/jetspeed/ ）组织的一个开源项目， IBM 的 WebSphere Portal Server 正是基于 JetSpeed 进行二次开发。
在满足门户可定制性的需求上，引入了门户组件概念 Portlet ， Portlet 是一个可插拔的组件，关于 Portlet 有各种定义， JetSpeed 在提交的 JSR-168 portlet API specifications 对 Portlet 的定义如下：
Portlet 是一个 Web 组件，可以被容器管理，可以产生动态内容。 Portlet 可以很容易地被插入并且运行于一个 Web 应用中， Portlet 是被设计成聚合大量内容的组合页面，举例：同样一个 Portlet ，根据不同的用户，可以产生不同的实例，这些实例中是根据用户设置包含不同的内容，也就是满足用户的可定制性。
为了实现门户内容的有效管理和监控， JetSpeed 的重要内容组件 Slide 引入了 Domain 和 Namespace 方面的概念，对所有资源进行树形结构的控制，在 Slide 中， Domain 是一系列 Namespace 的聚合，它类似文件系统中的“ / ”根目录， domain 可以控制在其中登记的 Namespace 的访问权限以及执行 Namespace 的初始化和连接等管理工作。
Namespace 是个自我独立的有实体内容的容器，它不能包含指向或连接到其它 namespace ，每个应用系统可以是一个 NameSpace ， Namespace 包含独立的数据和这些数据的安全访问机制。
JetSpeed 虽然提供了丰富的 Portal 技术功能，但是其可定制性比较差，其重要的内容组件 Slide 也比较难以让人理解，它的安全控制框架与通用的 J2EE 使用 JAAS 不相融合，所有这些都造成了在其基础上进行二次开发的难度。
Liferay
Liferay （http://www.liferay.com ）代表了完整的 J2EE 应用，使用了 Web 、 EJB 以及 JMS 等技术，特别是其前台界面部分使用 Struts 框架技术，基于 XML 的 portlet 配置文件可以自由地动态扩展，使用了 Web Services 来支持一些远程信息的获取，使用 Apahce Lucene 实现全文检索功能。
Liferay 的缺点是它缺乏一个简单清晰可拓展的架构设计， portlet 设计显得比较凌乱，进行二次开发有一定的难度
OFBIZ
OFBiz （http://www.ofbiz.org/ ）是一个比较有影响力的开源软件， OFBiz 是一种试图与 　　J2EE 框架技术并驾齐驱的大型软件框架，其核心是三个引擎：实体引擎、服务 Service 引起以及工作流引擎， OFBiz 最大的优点是其方便的实体引擎，可以快速地开发数百张数据表。
OFBiz 的服务引擎提供了工作流、 SOAP 等具体的实现形式，这样用户可以直接通过服务引擎使用到自己需要使用的技术，类似一个动态方便的 API 库。
OFBiz 也有自己的安全权限控制框架，可以和每个 Service 绑定在一起。
OFBiz 的缺点在于由于它试图搭建一个无所不包的大型框架系统，必然导致其架构组织的复杂性，试图在其上进行整体的二次开发困难很大；而且 OFBiz 主要是一种 Web 结构的系统，在事务处理、安全性以及分布式计算上有所不足。当然 OFBiz 的一些优秀模块和组件是值得学习和直接使用的。
综合这几种门户软件，他们共同的一个缺陷是各自建立了一套用户安全权限控制框架，一旦使用了其中任何一个安全框架，整个系统的框架就被强行固定下来，不能进行弹性的拓展和变化，而且他们与目前通用的 JAAS 机制不相融合。
在实际应用中，用户安全权限控制应该是一个独立的、但是又和具体应用系统相关的动态可扩展系统，通过使用 J2EE 的 JAAS 机制可以实现一个分布式环境下单点登陆（ SSO ） 、访问权限灵活配置的动态系统。
架构设计
综合现有的几种门户设计理念，将本项目完全架构在 J2EE 标准框架内，充分利用 J2EE 整体的技术框架资源，将本项目建成一个分布式集群环境下、可动态伸缩的灵活的大型系统。
吸取 Apache Slide 中的 Domain 树形结构的思想，可以将门户网站认为是一个在树形结构控制下的集合系统，如图 7-3 所示：

图 7-3 门户系统的树形结构控制
图 7-3 中，无论是静态的新闻内容信息，还是网上办事等动态互动功能，他们都属于一种具体资源 Resource ，通过和树形结构某个 Node 实现连接，从而可以将资源插入整个门户系统，同时也可以通过树形结构方便地对这些资源实现管理。
吸取 Apache Slide 中 Domain 和 Namespace 的思想，可以认为当前整个应用系统就是一个 Domain ，如果这个应用系统是一个门户系统，对应 Web 应用层的 Web 目录结构如下。
Portal
|
|--- WEB-INF
|----admin
|----forum
|----taxation
|--- account
在上面示意图中，根目录“ / ”是一个 Domain 。在这个根目录下，有各种资源， forum 表示论坛功能； taxation 表示网上纳税相关办事资源； account 表示个人账户资源，这样在 Web 层中，资源是通过相对路径 path 来定位的，如 /forum 可以定位到本 Domain 下的论坛资源，其实相对路径也属于一种 URI （统一资源定位器）。
由于 Web 容器实现了角色的访问权限控制，可以在 web.xml 灵活设置某个路径 path 的访问权限，因此，这实际上解决了资源的安全权限控制问题。
整个系统的架构图如下：

门户系统中树形结构类似一个组织的组织图，属于系统的高度控制部分，树形结构的访问管理将在服务层中实现。
为应付随时可能出现巨大访问量，通过 J2EE 组成一个分布式的集群环境将具有强大的处理功能，以 JBoss 服务器为例：

统一的用户管理和安全权限机制
通过使用 J2EE 容器提供的 JAAS （ Java Authentication Authorization Service ： Java 验证和授权 API ）， JAAS 是 J2EE 服务器来帮助应用系统实现安全功能，当应用系统的开发者具体实现了 LoginModule API ，那么 J2EE 容器就执行 LoginModule 接口，通过接口和具体实现之间关系， J2EE 容器将结合具体应用系统实现特定的 JAAS 功能。
访问权限（ ACL ）将使用 J2EE 容器的安全机制，在 Web 层和 EJB 层都有相应的标准可实现基于角色的对资源的访问权限控制，通过简单的容器 ACL 配置，可以方便的进行权限分配和控制，同时可将安全配置工作和安全执行工作截然分开，防止舞弊。
建立统一的基于 LDAP 的集中式用户资料系统，这样可以实现整个系统用户的单点登陆（ SSO ），也就是说：整个系统只有一个可以登陆进入的点，它对所有的请求都是通用的。单点登陆可以保证用户能够访问到可以访问的资源，如果有一个未被授权的请求要求访问被保护的资源，这个请求将自动被导向到相应的验证点进行登陆验证。
系统整合和通信方案
考虑到整个电子政务系统的组成部分纷繁复杂，新旧技术标准不一致，因此提供这种数据整合方案也有很多种，根据具体情况进行不同的选择。
与原有系统的整合 EAI 是通过构建一个中间件基础架构和几个适配器来实现集成，这些适配器允许不同的后端应用程序插入到一个某种类型的公共协议，从而互相交换数据。
JMS 和 JCA
J2EE 环境下已经建立了几个规范来实现这种适配器作用，如 Java 消息传递服务（ JMS ）和 Java 2 连接器体系结构（ JCA ），这些规范主要用来把 J2EE 应用程序与非 J2EE 环境集成在一起。
JMS 是一种异步消息系统，它主要是实现消息生产者和消息使用者之间的传递服务，消息系统提供了许多其他分布式对象计算模型没有的优点。它鼓励在消息产生者和使用者之间的 " 松耦合 " ，在它们之间有很高程度的事务处理。对于使用者，它不在乎谁产生了消息，产生者是否仍在网络上以及消息是什么时候产生的。这就允许建立动态的，可靠的和灵活的系统。整个的子系统能被修改而不会影响系统的其他部分。
Java 2 连接器体系结构定义了一种用来使 J2EE 应用程序与非 J2EE 环境（通常情况下，是企业信息系统（ enterprise information system ），或称 EIS ）用一种安全的、事务性的方式进行通信的方法。利用 JCA API 的解决方案比基于 JMS 的解决方案与后端耦合得更紧；更确切地说是 JCA 规范可以在同一次消息交换或同一个事务中把消息的发送和处理结合起来。 EIS 进行的处理是同步的，因此可以成为 J2EE 应用程序服务器管理的事务的一部分。因此，被 J2EE 应用程序跨多个后端应用程序运行的业务流程可以是事务性的 — 这些应用程序所执行的步骤要么全部被提交，要么一步也不提交。
基于各种协议的数据交换
BIE （http://www.bruckwdi.com/index.pl/bie ）是用来帮助组织在不同应用不同操作系统间进行数据交换，实现 EAI 和 B2B 解决方案，它类似微软的 BizTalk ，但是与之相比有两大优势：
· 由于使用 Java 达到真正跨平台实现数据交换
· 开放源代码，适合二次开放
可以用 BIE 接受来自别的应用程序或其他企业的数据文档，并把他们转换成 XML 用于自己的应用程序。相反，也可以从自己的应用程序得到数据并通过 BIE 以不同的格式提供给别的应用程序或企业使用。不论是哪种情况，数据开始是一种格式，然后通过 BIE 转换成 XML ，然后你可以以完全不同的格式输出数据。不管是数据源还是数据接受者，它们的数据格式都不必是相同的，甚至不必是 XML 格式。
BIE 不仅仅是一个数据交换服务器，它也提供强大的图形业务流控制工具。业务分析员在一个类似流程图的工具中画出业务流，从而实现所需要的功能。
成为标准的 Web 服务提供商
电子政务系统一旦初具规模，整个系统所包含的信息量以及强大的功能服务将成为社会中最强大的资源，如何将这些资源更好的服务于社会，让社会各界以自己的方式充分挖掘其中的数据信息价值将成为首要议题。
通过 Web Services 技术让外界直接共享或调用自己的资源将是一种发展趋势，比如气象信息是属于政府气象部门发布的信息，但是几乎在所有新闻类网站或门户都需要本地的气象信息，那么就可以通过 Web Services 提供这种服务。
典型的 Web 服务（ Web Services ）结构包括三个实体：服务提供商、服务经纪人和服务需求者。他们分别提供了三项基本功能：运行发布、查找和绑定。服务提供商创建 Web 服务，并通过在服务经纪人处注册发布网络服务 ; 服务经纪人负责维护已发布服务的注册系统 ; 服务需求者通过搜索服务经纪人的注册登记查找所需要的服务，并将服务请求与服务提供商绑定以使用特定服务。
电子政务系统因为拥有丰富而强大的资源和信息，因此理所应当成为一个服务提供商，这些资源和信息又可能是本地社会中最多的，它有理由可能成为当地最大的 Web 服务提供商。
目前， Web 服务正在处于实践和完善当中，其中安全、管理或交易等问题还有待于进一步解决，但是在规划整个电子政务系统必须将 Web 服务包括进来。
_xyz