（系统工程专业论文）信息服务平台VOISSP中资源协作及接口规范研究.pdf

摘要 摘要 p o r t a l 的应用日益广泛，p o r t l e t 是p o r t a l 的重要组件，是一个w e b 组件， 是基于w e b 内容和企业应用功能的封装体。开发人员希望多个p o r t l e t 能够协 同响应用户的请求，减少的用户的操作次数，这就要求p o r t l e t 之间能够共享 数据，相互协作。w e b 资源协作是一组p o r t l e t 协同响应用户的请求，是一种重 要的p o r t l e t 通信方式，它把通信和业务处理相结合。w e b 资源协作包括三个方 面：定义协作流程，p o r t l e t 之间进行消息传递，p o r t l e t 处理接收的消息。w e b 服务发现技术是w e b 服务系统架构中的一个重要部分，w e bs e r v i c e 目前的各项 标准均缺乏对语义层面的支持，传统的w e bs e r v i c e 发现技术也大多是基于关 键词匹配和框架结构实现的，无法提供有效的语义支持。 本文介绍了面向参观者的信息服务演示系统平台( v o i s s p ) 。一方面，以此为 基础设计了资源协作框架，并在这个框架的基础上研究了通信协作，通信协作、 通信机制、通信模式并提出了其支持接口规范。另一方面，以r s s ，i f r a m e ，w e b s e r v i c e 三类资源为主线研究了其内容聚合接口，w e b 服务与w s d l 的接口，w e b 服务与b p e l 的接口，并探索了基于语义的w e b 服务的接口规范，从而方便多重 继承，并行开发，而不再需要重新编写代码实现。 关键词：p o r t l e t ，协作，资源，接口，规范 a b s t r a c t a b s t r a c t t h ea p p l i c a t i o n so fp o r t a l i n c r e a s i n g l yw i d e s p r e a d p o r t l e ti s aw e b c o m p o n e n t ，w h i c he n c a p s u l a e s w e bc o n t e n t sa n da p p l i c a t i o nf u n c t i o n s ，p o r t a l d e v e l o p e r ss u t i l i z ep o r t l e tt op u b l i s he n t e r p r i s e i nf o r m a t i o na n di n t e g r a t ea p p l i c a t i o n s y s t e m s w e br e s o u r c e sc o l l a b o r a t i o ni sag r o u po fp o r t l e ts y n e r g i s t i c l yr e s p o n s ea t t h er e q u e s to fu s e r s ，i ti sa ni m p o r t a n tm e a n so fc o m m u n i c a t i o np o r t l e t ，a n di ti st h e c o m m u n i c a t i o n sa n di n t e g r a t i o n so fb u s i n e s sp r o c e s s e s c o l l a b o r a t i o n so fr e s o u r c e s i n c l u d et h ef o l l o w i n gt h r e ea s p e c t s ：d e f i n i t i o no fc o l l a b o r a t i o np r o c e s s e s ，p o r t l e t b e t w e e nm e s s a g i n ga n dn e w sp o r t l e tr e c e i v i n g w e bs e r v i c e st e c h n o l o g yi sr e g a r d e d a sa ni m p o r t a n tp a r to fo fw e bs e r v i c e s t h ec u r r e n tw e b s e r v i c es t a n d a r d sl a c kt h e s u p p o r to f t h es e m a n t i cl e v e l ，a n df r o mt h et r a d i t i o n a lw e bs e r v i c ew ea l s of o u n dt h a t m o s t t e c h n o l o g yi sb a s e do nm a t c h i n gk e y w o r d sa n df r a m es t r u c t u r et o a c h i e v e w i t h o u ts e m a n t i c v i s i t o r - o r i e n t e di n f o r m a t i o ns e r v i c es y s t e mp l a t f o r m ( v o i s s p ) i si n t r o d u c e d i nt h i sp a p e r o nt h eo n eh a n d ，w ed e s i g nt h ef r a m e w o r ko fr e s o u r c e sc o l l a b o r a t i o n ， a n db a s e do ni t ，w ea n a l y s i st h ec o m m u n i c a t i o nc o l l a b o r a t i o n ，c o m m u n i c a t i o n m e c h a n i s m s ，c o m m u n i c a t i o np a t t e r n s a n d p r e s e n t i t s s u p p o r t i n g i n t e r f a c e s p e c i f i c a t i o n o nt h eo t h e rh a n d ，t h r e et y p e so fr e s o u i c e ss u c ha sr s s ，i f r a m e ，w e b s e r v i c ea r er e g a r d e da st h ek e yl i n et oa n a l y s i st h ec o n t e n ta g g r e g a t i o ni n t e r f a c e ，w e b s e r v i c e s & w s d li n t e r f a c e ，w e bs e r v i c e s & b p e li n t e r f a c e t h es e m a n t i cw e b s e r v i c e si se x p l o r e db a s i n go nt h ei n t e r f a c es p e c i f i c a t i o n ，t h u sf a c i l i t a t i n gm u l t i p l e i n h e r i t a n c e ，p a r a l l e ld e v e l o p m e n t ，a n dt h ec o d ew i l ln ol o n g e rb en e e d e d t or e w r i t e k e yw o r d s ：p o r t l e t ，c o o p e r a t i o n ，r e s o u r c e s ，i n t e r f a c e ，s p e c i f i c a t i o n i i 学位论文版权使用授权书 本人完全了解同济大学关于收集、保存、使用学位论文的规定， 同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版 本；学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、 扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提供 本学位论文全文或者部分的阅览服务；学校有权按有关规定向国家有 关部门或者机构送交论文的复印件和电子版；在不以赢利为目的的前 提下，学校可以适当复制论文的部分或全部内容用于学术活动。 学位论文作者硌主。叶 沙r 年；月；日 经指导教师同意，本学位论文属于保密，在年解密后适用 本授权书。 指导教师签名：学位论文作者签名： 云1 虬圩 年月日沙辉；月3 日 同济大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进行 研究工作所取得的成果。除文中已经注明引用的内容外，本学位论文 的研究成果不包含任何他人创作的、已公开发表或者没有公开发表的 作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集 体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任 由本人承担。 学位论文作者签名： 弓、1 以牟 触g 年3 月；日 第1 章引言 1 1 课题背景 第1 章引言 p o r t a l 在j 2 e e 的应用中日益广泛，p o r t l e t 是p o r t a l 的重要组件，是一个w e b 组件，是基于w e b 内容和企业应用功能的封装体。p o r t a l 开发人员使用p o r t l e t 发布企业信息，并集成企业的应用系统。 资源协作这个概念源自于p o r t l e t 的开发和使用实践。基于客户端对p o r t l e t 的操作仅会引起所激活的p o r t l e t 、刷新信息，用户需要逐个操作p o r t a l 页面上的 p o r t l e t 来获取所需的信息或者进行一项业务。目前的p o r t l e t 规范仅支持使用 p o r t l e t s e s s i o n 进行通信，这是一种非常简单的通信方式，就是向p o r t l e t s e s s i o n 中 写入s c o p e 为a p p l i c a t i o ns c o p e 的属性，通过共享这个属性来实现通信。这种方 式有很多局限性，当应用于一组独立开发的p o r t l e t 时，容易出现属性被覆盖或 者改写的问题，而且不在同一个页面的p o r t l e t 不一定能够共享属性。p o r t l e t 容 器没有定义消息处理的方法，也没有对协作流程解析制定标准。因此，目前的 p o r t l e t 规范没有提供对p o r t l e t 协作的支持，给p o r t a l 进行企业应用集成和p o r t l e t 开发都造成很大的困难。于是，对p o r t l e t 体系结构进行扩展，并增加p o r t l e t 通 信和协作流程解析模块，就成为了p o r t a l 开发需要解决的一个问题。 用语义w e b 的知识标记手段来描述服务的语义，就可使w e b 服务成为计算 机可理解的实体，从而支持服务的自动发现、匹配、执行、组合等操作。对于 w e b 服务来说，动态、异构的w e b 环境要求基于w e b 提供的服务可以灵活的、 可靠的满足用户要求，实现“按需服务”，即根据用户的需求提供合适服务。 但是现有的基于语义的服务发现存在着服务语义描述模型与现有模型不兼 容，缺乏映射机制的问题。当前w e b 服务主要采用w s d l 描述、u d d i 存储。 而语义描述模型主要采用w e b 服务本体语言o w l s 描述问题。 1 2 课题研究目的 以现有的面向参观者的信息服务展示平台( v o i s s p ) 平台为基础，通过研 第l 章引言 究p o r t l e t 之间的通信机制，通信模式及其支持规范来实现w e b 资源协作。通过 资源协作框架使用户与p o r t l e t 的交互次数减少，提高信息服务的效率，大大增 强资源之间的互操作能力，充分复用每个p o r t l e t 的功能，从而高效地实现复杂 的业务流程。 1 3 课题研究意义 p o r t l e t 之间的协作实际上就是为了达到资源协作与多代理高效通信。协作的 实现可以大大提高多代理之间通信的效率和互操作能力。通过p o r t l e t 规范，在 显示层上统一p o r t l e t 的行为，一定程度上可以解决p o r t l e t 在异构的p o r t a l 之间 无法移植的问题。对其规范接口的研究不仅可以解决世博会筹建过程中的场馆 建设、招商以及运营期间等各时期对信息服务的需求，更能够在异构系统集成 方法和理论等领域取得重大突破，为今后解决企业、社会以及政府中大量存在 的异构系统中的信息进行交换与共享提供集成思路与应用接口，从而为信息化 时代的电子商务、电子政务，以及企业间的协同、社会中的协同提供更加有力 的信息决策支持。 1 4 研究内容及章节安排 论文共分为五章，论文的研究内容框架结构如图1 1 所示。本文内容作如下 安排： 第l 章：引言。介绍课题背景应用和研究现状以及论文的研究内容和相互关 系。 第2 章：本章介绍面向参观者的信息服务演示系统( v o i s s p ) 集成框架。 第3 章：基于v o i s s p 系统，本章主要介绍了资源协作框架，提出p o r t l e t 协作 模型；深入分析了通信协作，通信模式，通信机制； 第4 章：本章介绍了基于自主开发v o i s s p ，应用和实施的主要接口规范，包 括资源管理，动态协作，服务组合，快速配置接v l 。 第5 章：在前一章已成熟的接口规范基础上探索语义接1 5 1 机制，重点讨论了 w s d l 和o w l 的接口，以及相关的基于语义的w e b 服务中o w l 与w s d l 的衔接。 第六章：对现有工作进行了总结和展望，对进一步的开发方向作了简单分 2 第l 章引占 析。 者的信息服务演示系统( v o i s s p ) 集成框架 资源协作框架 基于协作框架的通信模式 基于协作框架的通信机制 图1 1 论文的研究内容和框架 垂嚣 一；|；：；一 “h 第2 章 面向参观者的信息服务演永系统( v o i s s p ) 集成框架 第2 章面向参观者的信息服务演示系统( v o is s p ) 集成框 架 面向参观者的信息服务演示系统( v o i s s p ) 集成框架包括基于w s r p 规范 的w e b 集成框架层和b p m 驱动的服务流集成框架，是以p o r t l e t 技术规范为依 托的。资源协作是实现实现信息服务平台框架的主要技术，而接口规范的研究 又为平台的整合提供了支持规范。 2 1p o r tle t 规范 随着越来越多企业门户的出现，不同的供应商都根据自己的标准开发了各 自的p o r t a l 组件接口，即p o r t l e t 接口。这些互不兼容的接口实现给应用提供商， p o r t a l 客户和p o r t a ls e r v e r 提供商带来了各种问题，为了解决这个问题，j c p 发 布了p o r t l e t 规范( p o r t l e ts p e c i f i c a t i o n ) ，从而提供了不同p o r t a l 和p o r t l e t s 之间的 互操作性。p o r t l e t 规范基于j 2 e e l 3 规范定义了整合不同信息数据来源和底层应 用的p o r t l e t a p i ，描述了p o r t l e t 与p o r t a l 之间的相互作用，p o r t l e t 的生命周期及 一些安全性，用户定制，p o r t l e t 显示管理等方面的信息，提供了统一的接口定义。 基于规范完成的p o r t a l 将成为一个通用性好，适用性强的系统，可兼容任何符合 p o r t l e t 规范的p o r t l e t ，提高了产品的复用性。 p o r t l e t 规范的主要目标如下： ( 1 ) 定义p o r t l e t 的运行环境，即p o n l e t 容器( p o r t l e tc o n t a i n e r ) ； ( 2 ) 定义p o r t l e t 容器与p o r t l e t 组件之间进行交互的a p i ； ( 3 ) 为p o r t l e t 组件的临时数据和持久数据提供一种存储机制； ( 4 ) 为p o r t l e t 组件提供访问并包含s e r v l e t s 和j s p 的机制； ( 5 ) 为p o r t l e t 组件提供打包机制，以方便进行部署； ( 6 ) 允许p o r t l e t 组件在所有满足j s r l 6 8 规范的p o n a l f i l e 的移植； ( 7 ) 利用w s r p ( w e bs e r v i c e sf o rr e m o t ep o r t l e t s ) 协议实现远程p o r t l e t 。 p o r t a l 是一个w e b 应用程序，它负责将不同资源进行整合并展现给用户， 通常其具有三个特点：个性化、单点登录和内容聚合，其中内容聚合指的是将 4 第2 章面向参观者的信息服务演示系统( v o i s s p ) 集成框架 不同来源的信息整合到一个页面的过程。p o r t a l 的主要任务是将不同的应用程序 集成到一个页面，这个页面的外观是p o r t a l 用户共有的；p o r t a l 也可以有复杂的 个性化特征，这些特征能够为用户提供自定义内容。同时，p o r t a l 页可以有不同 的p o r t l e t 集，以便为不同的用户创建不同的内容。p o r t l e t 是种基于j a v a 技术 的w e b 组件，它能够处理用户请求并产生相应的动态内容。这些动态内容称为 片段，实际上是满足特定规则的标记语言片段( 如h t m l ，x h t m l 或w m l ) ， 每个片段都能够和其它片段组合在一起形成一个完整的文档1 1 1 。这样，所有 p o r t l e t 的内容整合在一起，就构成了一个p o r t a l 页面。在p o r t a l 中，p o r t l e t 作为 可插拔的用户接口组件为p o r t a l 用户提供信息系统的表示层，其生存周期由 p o r t l e t 容器进行管理。p o r t l e t 容器用于运行p o r t l e t ，为其提供必需的运行环境， 管理p o r t l e t 的生存周期，并为其提供持久性存储机制。在运行过程中，p o r t l e t 容器从p o r t a l 接收请求，并调用其上的p o r t l e t 执行该请求，最后将执行的结果 返回给p o r t a l ，而不负责对其所有p o r t l e t 产生的内容进行组装，这实际上是由 p o r t a l 自身完成的。 p o r t a l 与p o r t l e t 容器既可以捆绑在一起实现为单个的应用组件，也可以作为 两个相互独立的应用组件来进行实现，p o r t l e t 规范对此并未进行限定。 基本的p o r t l e t 生命周期可以分成三个阶段： ( 1 ) 初始化：使用初始化类初始化p o r t l e t ，并将其放入服务中，以供后续访 问； ( 2 ) 处理请求：处理各种不同种类的a c t i o n 请求或r e n d e r 请求： ( 3 ) 销毁：销毁p o r t l e t ，回收p o r t l e t 所占有的资源。 p o r t l e t 容器在管理p o r t l e t 的生存周期的过程中，需要调用p o r t l e t 接口中的 相应方法来执行相应的操作。p o r t l e t 容器中运行的每个p o r t l e t 都必须实现规定 的p o r t l e t 接口，或继承某个实现了这些p o r t l e t 接口的类。p o r t l e t 接口主要包括 以下这些方法： ( 1 ) i n i t ( p o r t l e t c o n f i g c o n f i g ) ：初始化p o r t l e t 实例。该方法仅仅在p o r t l e t 实 例化后被c o n t a i n e r 调用一次，因此一般被用来创建p o r t l e t 所需的昂贵对象或资 源。 ( 2 ) p r o c e s s a c t i o n ( a c t i o n r e q u e s tr e q u e s t ，a c t i o n r e s p o n s er e s p o n s e ) ：当用 户触发了p o r t l e t 上的某个动作时，c o n t a i n e r 通过该方法来通知p o r t l e t 进行处。 每次客户请求中，只能有一个动作被触发，且p o r t l e t 将根据该动作的种类作相 第2 章面向参观者的信息取务演示系统( v o i s s p ) 集成框架 应操作，如重定向、改变p o r t l c t 模式或窗状态、设置r e n d e r 参数等等。 ( 3 ) r e n d e r ( r e n d e r r e q u e s u e q u e s t - r e n d e r r e s p o n s er e s p o n s e ) ：生成标记片 段。对于当前p o r t a l 页中的每个p o r t l e t ，该方法都会被调用一次，其生成的标记 片段将同时取决于p o f t l e t 模式、窗n 状态、r e n d e r 参数、请求属性、会话数据和 后台数据等几个因素。 ( 4 ) d e s t r o y ( ) ：指示e o r t l e t 的生命期己经结束。该方法允许p 0 n l n 释放所 占资源并修改该p o r t l 时的持久化数据。 2 2 面向参观者的信息服务演示系统集成框架( v 0 【s s p ) 本项目的重要成果之一是研究开发出一个“面向参观者的信息服务演示系 统”实例，其英文名称为：v i s i t o r - o r i e n t e c t i n f o r m a t i o ns e m i t es y s t e m p l a t f o r m ， 简称v o i s s p ，包括门户的w e b 集成平台v o i s p ( p o r t a l ) 和面向参观者的服务 组合平台v 0 1 s c p ( c o m p o s i t i o np l a t f o r m ) 。参照b p e l 、b p m i 等p o a 架构的参 考标准和s o a 标准，运用抽象技术，将集成框架分解为基于w s r p 规范的w e b 集成、b p m 驱动的服务流集成、组件集成和数据集成、系统安全与质量保证等 层次结构，如图2 i 所示。 ：谤曼 p o r a h # # 鏖 图2i 模型驱动下的、基于移动过程理论的异杓系统集成框架 l蔷 l 第2 章面向参观者的信息服务演示系统( v o i s s p ) 集成框架 在w e b 集成层，采用j s r l 6 8 ( j a v as p e c i f i c a t i o nr e q u e s t ) 规范和w s r p ( o a s i sw 曲s e r v i c ef o rr e m o t ep o r t l e t ) 标准，建立可以兼容p o r t l e ts e r v i c e s 和 w 曲p a r ts e r v i c e s 的w e b 集成框架，集成包括j s p 、j s p + s e r v l e t 、s t r u t s 、a s p 、 i f r a m e 和r s s ( r d fs i t es u m m a r t ) 等在内的所有w e b 资源，以及由w e bp a r t 、 j a v a 组件封装成的w 曲服务组件。 在服务流集成层，基于进程代数的数学理论、结合b p e l 规范，建模、仿真 和验证应用程序的业务执行流程。 在组件集成层，研究传统分布式组件集成和基于语义w e b 的服务组合机制。 在数据集成层，通过元数据模型，解决异构、分布、跨组织的高密度数据 的集成与交互。安全与质量保证层提供系统安全与质量保证。 2 2 1 基于w s r p 规范的w e b 集成框架层 如图2 2 所示，w e b 集成平台根据目标对象或w e b 资源( 应用系统、w e b 服务或r s s 资源) 的不同，提供多种类型的应用集成接口：i f r a m e 接口、内容 聚合接口、w e b 服务接口、其他接口，以整合现存的各类遗留系统，为使用各 种环境的用户提供一致的访问入口。 i f r a m e 接口 i f r a m e 接口可以通过在集成组件中指定u r l 等属性将外部资源集成到应用 集成平台，实现界面集成层次上对外部资源的整合。通过适当调整宽与高等属 性还能实现集成外部系统的页面剪裁功能，并可通过访问日志信息接口记录日 志访问数据信息。应用此接口需要协调好外部资源的认证方式( 如b a s i c ，f o r m 等) 与资源定位方式。 第2 章面向参观者的信息服务演示系统( v o i s s p ) 集成框架 图2 2 基于w s r p 的w e b 集成框架 内容聚合接口 内容聚合接口通过一定的数据信息交互标准( 如r s s 标准) ，以订阅的形 式实现内容交换 2 1 1 3 1 。只要在集成组件中指定目标内容发布的相关属性即可实现 自动的内容聚合。此接口亦需协调安全认证与资源定位方式。 w e b 服务接口 w e b 服务接口通过基于s o a p 的标准接口实现松耦合的集成模式，集成组 件即为调用w e b 服务的客户端，调用服务编排过的粗粒度w e b 服务或者是经过 服务总线的细粒度w e b 服务。开发方式主要可分为两个过程：应用程序主要功 第2 章 面向参观者的信息服务演示系统( v o i s s p ) 集成框架 能点的w e bs e r v i c e 化和作为w e bs e r v i c e 客户端的p o r t l e t 设计。前者借助自动 化开发工具可以很方便的实现，后者是将调用w e bs e r v i c e 客户端( 经服务总线 实现日志记录) 代码整合进集成组件方法调用中。 其他接口 w s r pw e b 服务是一种同步的、面向用户界面的服务，与面向逻辑或面向 数据的w e b 服务不同，面向用户界面的w e b 服务提供了一种更为粗粒度的应 用程序复用和集成。在实现时，采用基于p o r t l e t 的代理机制查找与绑定远程 w s r pw e b 服务。主要是将调用远程门户组件的相关工作抽象为一个通用的消 费者代理，支持门户管理者的灵活配置管理与多次实例化。该代理在标准w e b 服务请求和响应机制上运行，通过构建s o a p 请求转发到w s r pw e b 服务，并 将响应返回给门户。 2 2 2b p m 驱动的服务流集成框架层 b p m 驱动的服务流集成框架层采用业务过程建模工具( 如u m l 、a r i s 、 v i s i o 等工具) 、根据领域需求和业务规范确定需求的概念模型和需求模型；然 后，根据概念和需求模型进行业务过程建模( b p m ，b u s i n e s sp r o c e s sm o d e l i n g ) ， 通过企业建模工具对b p m 模型进行仿真、优化( b p r ，b u s i n e s sp r o c e s s r e e n g i n e e r i n g ) ，并在业务运作与经营过程中模型持续改进( c p i ，c o n t i n u o u s p r o c e s si m p r o v e m e n t ) ，形成比较合理的业务流程规范和模型( b u s i n e s sp r o c e s s m o d e l ) 。在此基础上，需求分析师将业务过程模型中可以被自动化的业务抽取 出来，进行需求建模( r m ，r e q u i r e m e n tm o d e l i n g ) 后，形成需求模型，和业务 过程模型一起通过管理工具管理起来。 领域服务编排( d s c ，d o m a i ns e r v i c e sc h o r e o g r a p h y ) 通过业务流( b p f ， b u s i n e s sp r o c e s sf l o w ) 、抽象服务流( a s f ，a b s t r a c ts e r v i c ef l o w ) 和可执行服 务流( e s f ，e x e c u t a b l es e r v i c ef l o w ) 完成业务流程到可执行服务环境的映射， 形成可执行服务流模型( e s f m ，e x e c u t a b l es e r v i c ef l o wm o d e l ) ，通过管理工 具管理起来。 服务执行环境提供服务实例( s e r v i c ei n s t a n c e ) 的运行环境，w e b 服务和网 格服务实例在可执行服务流引擎( e s f e ，e x e c u t a b l es e r v i c ef l o we n g i n e ) 的控 制下，通过集成l e g a c y 系统、数据库、以及计算、存储和其他硬件资源的抽象 9 第2 章面向参观者的信息服务演示系统( v o i s s p ) 集成框架 服务，有序执行领域服务。 2 3 信息服务平台框架，资源协作框架以及接口规范的关系 资源协作是实现v o i s s p 系统的关键技术，取决于p o r t l e t 之间的互操作能 力，充分复用每个p o r t l e t 的功能，需要p o r t l e t 之间可以通信，同时容器支持p o r t l e t 处理消息，从而可以在p o r t a l 上高效地实现复杂的业务流程。此外，p o r t a l 服务 器应该提供协作流程解析的功能。在p o r t l e t 规范中，用户请求的仅仅是被激活 的p o r t l e t ，其它p o r t l e t 不能获得客户端的数据，因此需要进行通信交换数据。 目前的p o r t l e t 规范仅支持使用p o r t l e t s e s s i o n 进行通信，这是一种非常简单的通 信方式，就是向p o r t l e t s e s s i o n 中写入s c o p e 为a p p l i c a t i o ns c o p e 的属性，通过共 享这个属性来实现通信。这种方式有很多局限性，当应用于一组独立开发的 p o r t l e t 时，容易出现属性被覆盖或者改写的问题，而且不在同一个页面的p o r t l e t 不一定能够共享属性。p o r t l e t 容器没有定义消息处理的方法，也没有对协作流程 解析制定标准。因此，目前的p o r t l e t 规范没有提供对p o r t l e t 协作的支持，给p o r t a l 进行企业应用集成和p o r t l e t 开发都造成很大的困难。于是，对p o r t l e t 体系结构 进行扩展，并增加p o r t l e t 通信和协作流程解析模块，就成为了p o r t a l 开发需要 解决的一个问题 信息服务平台的一般接口包括资源管理，动态协作，服务组合，快速配置 接口。从语义层面来看，利用语义w e b 的知识标记手段来描述服务的语义，就 可使w e b 服务成为计算机可理解的实体，从而支持服务的自动发现、匹配、执 行、组合等操作。对于w e b 服务来说，动态、异构的w e b 环境要求基于w e b 提供的服务可以灵活的、可靠的满足用户要求，实现“按需服务 ，即根据用 户的需求提供合适服务。但是现有的基于语义的服务发现存在着服务语义描述 模型与现有模型不兼容，缺乏映射机制的问题。当前w e b 服务主要采用w s d l 描述、u d d i 存储。而语义描述模型主要采用w e b 服务本体语言o w l s 描述问 题。 2 4 本章小结 本章以介绍以及p o r t a l 的定义，结构，功能。并以此为基础详细介绍了面向 l o 第2 章面向参观者的信息服务演示系统( v o i s s p ) 集成框架 参观者的信息服务演示系统( v o i s s p ) 集成框架，包括基于w s r p 规范的w e b 集成框架层和b p m 驱动的服务流集成框架层，以及资源协作及接口规范在与 v o i s s p 的关系。下一章将以v o i s s p 为基础，详细讨论资源协作框架。 第3 章资源协作框架研究 第3 章资源协作框架研究 资源协作狭义来讲就是p o r t l e t 通信，即p o r t l e t 之间交换处理数据的过程。 目前有多种p o r t l e t 通信方式，资源协作是一种较为完善的通信方式，与业务处 理相结合。资源协作可以看作是协作动作通过控制结构复合的结果，协作根据 业务类型可以分为紧密协作，松散协作和混合协作。p o r t l e t 协作框架包括了框架 理论研究，而通信协作、通信机制、通信模式是对框架机制功能的描述。 3 1 资源协作框架 3 1 1 框架结构 传统的p o r t l e t 协作实现方法的问题在于三个方面：其一，在p o r t l e t 之间传 递的数据没有统的格式，任何接收到数据的p o r t l e t 不得不针对具体的数据格 式进行解析；其二，进行通信的p o r t l e t 之间没有统一的协调逻辑，通信的发起 方不仅要知道自己的数据发给谁，还必须知道对方采取何种动作，而通信的接 收方也必须知道数据来自于何处和如何处理。这种实现方式可以理解为p o r t l e t 之间的点对点的通信，数据的解析逻辑和p o r t l e t 协调逻辑都分散在各个具体的 p o r t l e t 。在p o r t l e t l 0 规范中，客户端的请求仅由被激活的p o r t l e t 处理，其余的 p o r t l e t 不会响应请求，输出的仍然是未刷新的信息片段1 4 】。因此，直接在p o r t l e t l 0 规范进行协作开发是难以实现的，需要在这个规范的基础上，增加一种协作框 架来支持p o r t l e t 协作的开发。在以往的p o r t a l 应用中，用户提出了大量的协作 方面的需求。根据对这些需求的分析，我们认为协作框架应该具备以下的特性： ( 1 ) 框架应该支持p o r t l e t 之间进行通信，使得客户端提交的数据能够在 p o r t l e t 间传递。不同的p o r t a l 服务器对p o r t l e t 容器的实现方式可能不同，有的 p o r t l e t 容器本身就支持同步通信，有的仅支持异步通信。考虑到对松散协作的并 发执行的支持，p o r t l e t 协作框架应该提供对这两种通信方式的支持。 ( 2 1 协作框架能够简化p o r t l e t 的开发。在前面的协作模型里，协作动作在运 行时需要获取协作p o r t l e t 解析交换数据的类型，同时调用p o r t l e t 完成业务片段。 这里面一部分设计到与容器的操作，开发人员难以完成。框架应该提供数据类 第3 章资源协作框架研究 型解析，运行时p o r t l e t 的定位，业务处理过程的调用。这样开发人员只关心业 务处理过程，从而可以专注于协作业务本身的开发。 ( 3 ) 协作框架具有较好的扩展性和灵活性，支持开发人员定制协作流程。如 果把协作流程分散在程序中，对于程序的维护和升级都非常不利。框架应该将 协作流程持久化，提供流程解析和存储服务。使得用户可以不修改程序就直接 修改协作流程，便于系统的扩展和升级。 基于上述考虑设计了一种具备以上特性的理论框架，框架如图3 1 。 图3 1p o r t l e t 协作框架 第3 章资源协作框架研究 它包含以下的组成部分：p o r t a l 页面，p o r t l e t 容器，协作p o r t l e t ，协作分发 器，注册管理器，c a c h e ，协作事件监听器，协作控制器，协作流程管理器，协 作流程表，a c t i o n 协作流映射，a c t i o n 协作流映射缓存，a c t i o n 协作流映射表。 用户在客户端向服务器发送清求。在解析请求以后，p o r t a l 页面通过p o r t l e t 容器 把请求转发给被激活的p o r t l e t 。该p o r t l c t 首先处理一些自身的相关业务，如果 用户所激活的a c t i o n 操作不是一个需要其它p o r t l c t 协作的业务，则在执行完对 自身所封装的应用后结束，由服务器调用r e n d e r 输出p o r t a l 页面，否则生成p o r t l e t 消息，并调用s e n d m e s s a g e 向协作控制器发送消息，从而发起协作。协作控制器 首先与a c t i o n 协作流映射管理器取得联系，将p o r t l e t 消息中的a c t i o n k e y 传递 给a c t i o n 。协作流映射管理器，用以取得协作流程的关键字，随后访问协作流程 管理器根据先前查询得到的协作流程关键字读取相应的协作流程信息，再根据 协作流程中规定的流程进行处理，按照流程规定生成协作消息并将其发送给目 标p o r t l e t 。目标p o r t l e t 中的p r o c e s s m e s s a g e 接收协作消息后，提取协作消息中 指定的处理该消息的协作消息处理器的类名，借助j a v a 的反射机制将协作信息 转发给相关的协作消息处理器进行消息处理完成协作动作。数据结构用于数据 传递器发送表示协作的请求，协作注册表，p o r t l e t 消息，协作事件，协作项。协 作框架定义了3 种用户在客户端向服务在解析请求以后，p o r t a l 页面把请求通过 p o r t l e t 容器转发给源p o r t l e t 。源p o r t l e t 处理请求，然后向协作分发器发送p o r t l e t 消息发起协作。协作分发器通过注册管理器与c a c h e 、协作注册表进行通信，读 取协作项的信息，再根据协作的流程处理接收的p o r t l e t 消息，触发协作事件并 发送给目标p o r t l e t 的协作事件监听器，晟后由协作事件监听器激活相应的事件 处理过程完成协作动作。在这个框架中，p o r t a l 页面，p o r t l e t 容器是p o r t a l 服务 器的原有组件，其余的是新增加的组件，这些组件功能如下： ( 1 ) p o r t l e t 消息( p o r t l e t m e s s a g e ) ：是p o r t l e t 间进行通信的数据项，它包括消 息源，接收者，类型，有效期，内容。其中消息源，接收者，类型是必选的， 其余各字段可选。 ( 2 ) 协作事件：包含事件源，事件内容等属性。在协作进行的时候用于通知 事件的订阅者进行处理以完成协作动作。 ( 3 ) 协作事件监听器( c o e v e n t l i s t e n e r ) ：监听并处理协作事件的组件，在下文 中，简称监听器。 ( 4 ) 协作p o r t l e t ( c o p o r t l e o ：实现p o r t l e t l 0 规范中定义的p o r t l e t 接口，作为一 第3 章资源协作框架研究 个w e b 应用程序与用户交互。协作p o r t l e t 运行在p o r t l e t 容器中，不能直接访问。 协作p o r t l e t 和监听器实现了o b s e r v e r 设计模式，因此协作p o r t l e t 可以添加和卸 除监听器。 ( 5 ) 协作项( c o l t e m ) ：是一个记录形的数据结构，包括以下成员：源p o r t l e t ； 目标p o r t l e t ，目标p o r t l e t 可以有多个；协作中传递的数据类型等，协作项表示 了协作流程，当协作项用于表示紧密协作时，需要定义协作p o r t l e t 执行动作的 次序。 ( 6 ) 注册管理器( c o r e g i s t r y ) ：负责协作注册表的维护，包括协作注册表的创 建，更新，以及协作项的创建，修改，删除，查找等。在进行协作项的查询操 作时，注册管理器首先从c a c h e 中查找，如果没有查找到，则访问协作注册表， 读取相应的协作项，并在使用后置入c a c h e 备后面查询使用。 ( 7 ) c a c h e ：协作项缓存，用于存储已经使用过的协作项，c a c h e 的大小应该 根据服务器的内存数量和协作注册表的容量来定，正确设置c a c h e 值可以加快 对协作注册表的访问。 ( 8 ) 协作分发器( c o d i s p a t c h e r ) ：是协作的控制组件，从注册管理器读取协作 项信息，在接收