门户单点登录实现与应用集成技术

利用 WebSphere Portal 实现单点登录以应用集成技术规范,更好的满足客户的门户业务需求

随着企业门户平台的“平民化”,越来越多的工程师加入到门户项目实施的行列,但由于对门户技术的了解、使用的深度不同,许多门户项目离客户的理想需求还有一定的距离,主要在集成方面,没有从业务上真正为客户集成许多有价值的模块。网上已有的介绍这类知识的文章大多比较片面和简单。 所以,撰写了这篇文章,结合国内众多成功案例的经验积累,希望能给读者一个较为详细、全面的门户单点登录及应用集成技术的介绍。通过此文章,读者朋友也许可以发现,门户项目还可以做很多事情,还可以利用门户产品实现更多的价值。 希望此文章能够协助读者朋友们更好的实施当前的和未来的门户项目。

0 评论:

王 洪涛, 售前工程师, IBM

2012 年 2 月 09 日

  • +内容

在 IBM Bluemix 云平台上开发并部署您的下一个应用。

现在就开始免费试用

概述

企业信息门户作为企业内部门户基础平台,一大主要用途是实现现有的业务系统、数据资源、人力资源的整合,实现信息(数据)的合理聚集;通过实现统一的用户和统一的访问入口来访问门户平台中整合的相关信息资源,真正实现资源的有效利用,更大发挥企业现有资源的使用价值,提高生产效率。

门户应用集成技术作为关键性的技术手段,实现门户网站与业务系统之间单点登陆,以及内容聚集。本文档通过归纳总结,将企业应用集成中可以使用的技术做出相应阐述,为实现门户与业务系统集成提供技术参考。

本文将结合实际情况,分析企业应用中,常用的集成技术的核心环节,以及每项技术适用范围。本文档提供技术性的参考,实际工作中将需要结合具体情况选择最适合的集成技术来解决实际的问题,技术在日益更新,文档也将实时将最新的集成技术归纳总结。文章并不涉及具体编码、配置的实现细节,只针对相关的集成技术做阐述,具体实现应当专注于具体的技术环节,同时根据环境与实际需求来做相应的调整。

回页首

名词解释

门户

这里专指利用门户产品构建的各种门户系统,包括 B2E 门户、B2C 门户、B2B 门户。

单点登录

用户仅需要在门户系统登录一次,就可以访问被授权访问的栏目或者其他应用,用户只需要记住一个帐号即可。通过提供安全登录访问和集中管理应用软件和数据的信息框架,实现用户只需登录一次,即可获得授权范围内所有企业应用程序的访问权。

portlet

Portlet 是特殊类型的 Web 模块,它们被设计成在门户网站的环境中运行,是独立地开发、部署、管理和显示小门户网站的应用程序。Portlet 不仅仅是现有 Web 内容的简单视图。portlet 是完整的应用程序,遵循标准模型-视图-控制器设计。Portlet 有多个状态和查看方式以及事件和消息传递能力。同时 Portlet 是可再用的 Web 模块,它们在门户网站服务器上运行并提供对基于 Web 的内容、应用程序和其他资源访问。

WSRP

通过定义一组公共接口,WSRP 允许门户在它们的页面中显示远程运行的 portlet,而不需要门户开发人员进行任何编程 , 使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。

回页首

集成的基础统一用户目录

在门户集成项目实施中,首先要考虑的是用户目录的因素。用户目录是用于存储用户身份信息,可利用以下几种方式实现:基于 LDAP 协议,符合 X500 标准的用户目录服务产品;

定制用户注册表接口(如:基于关系型数据库系统实现、基于本地用户系统实现);统一用户目录可以分为物理的统一和逻辑的统一。

物理统一用户目录

物理统一用户目录是要求门户与待集成的业务系统使用统一的用户目录注册表,物理统一的用户目录不仅仅包含有用户基本信息,同时包含相关的业务系统资源信息,与业务系统相关的账户信息。

为了保证可用性,统一用户目录一般分为中央目录服务器及分支目录服务器,门户系统试用中央目录服务器作为用户存储,各业务系统,可以试用中央目录服务器也可以试用分支目录服务器。

中央目录服务器和分支目录服务器通过目录复制技术进行数据同步,如可实现全局复制,也可以实现选择性复制。如图 1。

图 1. 物理统一用户目录

图 1 物理统一用户目录

逻辑统一用户目录

一般情况下,由于历史遗留问题以及企业要求等各方面的原因,实现物理统一用户目录的情形不多,更多的是采用逻辑统一用户的方式。逻辑统一用户是指门户与待集成的业务系统不使用唯一的用户注册表,门户信息系统使用单独的用户信息,业务系统使用另外一套自己的用户注册表。建立逻辑统一的用户目录,必须建立门户用户目录与业务系统用户目录之间的联系,实现门户用户与业务系统用户之间映射技术主要包括:

Credential Vault (凭证保险库)

Credential Vault (凭证保险库)是由 WebSphere Portal 提供一项目服务,帮助 portlet 和门户网站用户来管理多个标识。凭证服务包含处理基本认证、LTPA 令牌认证和简单基于表单的用户标识/密码登录提问的对象。如图 2

图 2. 凭证保险库

图 2 凭证保险库

GSO-Lockbox

利用 GSO-Lockbox,可以建立起一个用户身份信息和后台应用系统之间的对应关系。这需要依赖于门户应用(portlet 应用或 J2EE 应用)来维护这样的关系映射表(包含门户用户与业务系统帐户之间的关系)。

门户用户与待集成业务系统之间映射关系完成之后,可根据业务系统认证方式来选择实现单点登录。

用户目录信息同步

用户关系映射表建立后,需要随时可以对这种映射关系进行维护,通过定期强制密码更新策略让每一个用户维护自己业务系统的用户、密码是一种选择。更常见的选择是通过管理员进行统一的账户管理和密码的同步推送,这项需求可通过开发完成,或者借助于成熟的企业级安全产品,例如 TIM/TDI。如图 3 所示,利用 TIM/TDI 实现门户目录与应用系统直接用户目录统一管理和用户信息的同步及清理。

图 3. 试用 TIM/TDI 实现目录统一管理和信息同步

图 3 试用 TIM/TDI 实现目录统一管理和信息同步

回页首

统一认证与单点登录

认证意味着用户标识自己以获取对系统的访问权。IBM WebSphere Portal 支持以下几种方式的认证:

WebSphere Application Server 的基于定制表单认证机制,这是 IBM WebSphere Portal 缺省认证方式;

第三方认证(通过外部安全性管理器,如 Tivoli Access Manager 或者 CA SiteMinder),第三方认证提供者确定提问机制和认证方法;

安全套接字层(SSL)客户机认证。

用户在未标识自己的身份而尝试访问受保护的资源时,Portal(门户信息系统将提示用户提供认证凭证。

WebSphere Portal 还支持与其它的应用系统实现认证的统一,即支持其它标准的、非标准的认证方式来实现单点登录和应用集成以下其它系统的认证方式均为 WebSphere Portal 能够支持的:

Form 方式,用户名和密码、CA 认证 (X.509v3)、Token 认证、WAP 身份认证、资源敏感的认证或者自行开发的认证等方式

门户与业务系统实现 SSO

门户与业务系统实现 SSO(单点登陆),通过在门户使用 portlet 技术实现,为业务应用提供访问连接,当用户点击门户站点页面中的连接,或者直接访问门户页面中的某第三方系统的业务模块 Portlet 时,自动将登陆到需要访问的业务系统,而无需再次进行用户认证。

单点登录的实现从技术上可以从不同的维度着手,一般分为“客户端 Web 应用 SSO(Client-Web App SSO)”方式和“Portal 后台应用 SSO(Portal-Back End SSO)”方式,每种方式均有相应的技术实现,如图 4 Portal 单点登录服务:

图 4. Portal 单点登录服务

图 4 Portal 单点登录服务

在实际的项目中,常用的 SSO 的实现方式按照应用系统与 Portal Server 的交互程度分为三种。需要指出这些 SSO 的实现方式并没有优劣之分,不同的实现方式适应不同的应用环境。解决现实中遇到的不同问题。

真实单点登陆:

门户认证中心

利用门户系统建立统一的 SSO 认证中心,通过 SSO 中心认证后,应用系统利用 SSO API 同 Portal Server 通信,验证用户是否经过认证。新开发的应用系统大多使用这种 SSO 的实现方式。这种方式需要对应用系统的认证模块进行修改。多数情况下,使用信任关联拦截器(TAI)也是建立 SSO 认证中心的常见方式。

门户服务器实现了 Java 认证和授权服务(Java Authentication and Authorization Service(JAAS))体系结构。JAAS 提供了一种用来认证 subject 和提供细粒度访问控制的办法。JAAS 是标准 Java 安全性模型的一部分;它使应用程序不依赖于所使用的底层认证和授权机制。

JAAS 使用模块化的服务提供者接口来执行登录和注销操作。通过门户网站的 JAAS 登录模块建立的凭证包括 CORBA 凭证、用户和组专有名称、用户标识和密码以及 LTPA 令牌。在分布式 J2EE 环境中,portlet 可以使用 JAAS API 来访问启用了 JAAS 的后端应用程序。

认证中心的建立,可以利用 JAAS 安全模型实现,例如,通过实现 WebSphere 自带的 LTPA 令牌技术来实现门户及各应用系统的认证统一,利用 Portal 建立公共的 SSOToken 实现认证统一。也可以通过一些开源的认证模块来实现,如 CAS、OpenSSO 等。

LTPA

另外,IBM 的产品体系中,大部分产品已经可以通过配置的方式实现真实单点登录。如:IBM WebSphere Base 产品(例如 IBM Connections、Quickr、ECM 等)、IBM WebSphere Portal、IBM Lotus Domino Server 之间的用户身份认证和单点登录。IBM WebSphere Portal 与 IBM Domino 提供基于 cookie 的轻量级第三方认证机制(LTPA)。当 LTPA 机制用于由多个服务器组成的环境中时,它是通过使用 Domain Cookie 而启用的。这种经过加密的会话 cookie 被放置在用户浏览器中,并包含了一些信息,WebSphere 或者 Domino Application 服务器可以加密这些信息,并使用这些信息来说明用户已经通过该 cookie 所覆盖的 DNS(Domain Naming Service,域名服务)域中的认证。

伪单点登陆

通过 WebSphere Portal 认证或者 SSO 中心认证后,应用系统还要自己进行用户的认证。这种方式适用于那些无法修改认证模块的应用系统。这种情况可以利用应用系统比较基础的接口来实现,如 URL+User+Password、Form 表单代填等。主要有以下几种技术选择:

利用 WebSphere Portal 凭证库认证模块

portlet 通过获得一个 CredentialVaultPortletService 对象并调用它的 getCredential 方法来获得凭证。对于所返回的凭证,有两种选择:

使用来自被动凭证(passive credential)的密码或密钥,用特定于应用程序的调用来传送这些密码或密钥。使用被动凭证的 portlet 需要从凭证中提取出加密信息并与后端应用程序进行所有认证通信。

调用主动凭证(active credential)的认证方法。主动凭证对象向 portlet 隐藏了凭证的加密信息,没有任何办法可以从凭证中提取出这些信息。主动凭证提供另外的方法来执行认证。

后一种情况允许 portlet 通过基本认证、SSL 客户机认证、摘要认证或者 LTPA 来触发远程服务器的认证,而不必知道凭证值。使用主动凭证意味着门户网站代表 portlet 进行认证,而且这个 portlet 可以只使用开放连接。尽管这可能并不适合于所有情况,但它却是您应该首选的技术。

基于 Form 方式

这种方式是通过模拟用户凭证提交,将业务系统相关的用户凭证通过 Form 提交的方式,传递给业务系统认证模块。

这种方式适合待集成的业务系统认证方式采用 From 表单,当通过 portlet 技术封装 Form 表单包含有业务系统相关的用户凭证,以及资源 URL。通过将业务系统所需的用户凭证通过 Form(表单)提交方式,模拟用户登陆,业务系统将用户所需的资源通过 web 方式反馈用户。

适用于基于 B/S 的 Web 业务应用系统,并且用户认证方式提供 Form 表单认证服务功能。

URL

将用户凭证直接通过 URL 的方式发送给业务系统,业务系统的认证程序将截获的用户请求 URL 中获取用户凭证,从而实现门户与业务系统的单点登陆。或者将用户凭证存储在 HTTP 请求报头,业务系统认证程序通过解析 HTTP 请求头信息,获取用户凭证。

模拟会话

利用 WebSphere Portal 以及应用系统的接口,模拟应用系统的认证状态。

模拟证书

实现单点登陆的业务系统用户认证方式并不是基于 Form,也不是采用 HTTP Header。需要客户端(此是门户信息系统将被作为客户端,业务系统将作为服务器)提供客户电子证书,这需要通过 portlet 应用程序,或 J2EE 应用程序来实现模拟将电子证书发送给业务系统认证模块。

整合第三方软件的单点登陆

使用信任关联拦截器(TAI)的第三方认证。如 Tivoli Access Manager,CA SiteMinder 等。门户通过使用第三方认证服务器作为外部安全管理器单点登陆。通过定义访问控制规则,由第三方认证服务器来实现用户登陆业务系统的认证功能,将大大简化集成带来的烦琐工作。

通常第三方认证服务器(如 Tivoli Access Manager、WebSeal 或者 CA SiteMinder)会提供默认的验证机制采用内置共享库的形式支持通过用户名和密码客户方证书 RSA SecurID 令牌或 HTTP header( 报头 )。选择性将会更多,便于用户根据实际软件需求配置所需的方式。

认证方式包括

  • Forms-based login
  • HTTP basic authentication
  • Digital Certificate (X.509v3)
  • RSA SecurID Token
  • WAP identity mechanism
  • Resource-sensitive authentication
  • Kerborse

还可以支持 Credentials Acquisition Service (CAS),从而实现外挂的用户认证方式,如:

  • 数据库的认证方式,如 Oracle,DB/2
  • 其它 security tokens (Vasco DigiPass)
  • 用户定义的认证方式,如使用用户访问代码 PIN 和 Code
  • RADIUS
  • Biometrics

回页首

利用门户实现企业应用集成

利用门户产品来实现企业应用集成,需要根据企业业务系统的现状,以及具体的业务需求,进行最合理的规划与设计。同时,还要兼顾企业的未来发展以及整体 IT 规划的考虑,企业应用集成包括的内容很复杂,涉及到结构、硬件、软件、数据、技术、接口以及流程等企业系统的各个层面。

页面前端集成展现(基于页面内容的集成)

iFrame Portlet

基于页面的集成整合可以通过 iFrame Portlet 的方式,这也是门户项目中常见的一种集成方式。IBM WebSphere Portal 提供 webPage Portlet 将待集成的业务系统页面实现与门户站点进行整合。

通过 iFrame Portlet 集成依赖于以下几种情况:

  1. 此方法只适合 B/S 的业务应用系统。
  2. 此种集成方式的前提是:门户系统和应用系统之间已经实现 SSO。由于应用系统的页面之间在门户页面中展现,故需要考虑 SSO 的自动实现。例如:

    方式一:可以在用户登陆门户站点时,将登陆门户的业务系统账号统一保存在用户会话中。并且实现应用系统的认证环节,当通过 iFrame 方式实现页面集成时,通过将业务系统的用户凭证从用户会话提取,然后直接通过配置的 URL 展现即可。

    方式二:对 Iframe Portlet 通过 Portlet 编程进行预处理,实现应用系统的认证。而不是在用户登陆 Portal 时加载。

  3. 业务系统界面需满足 VI 设计要求

    为保证门户站点的整体风格,业务系统的展示页面将必须满足门户站点的 VI 设计要求。

  4. 需要应用系统提供具体的,可配置的 URL。
  5. 可选,为了更好的适应集成的需要,可能需要更改业务系统 URL 级接口或者修改认证模块。例如:业务系统修改认证模块,来满足集成的要求 ; 业务系统修改功能模块加入 URL 认证能力。

通过 iFrame Portlet 的方式进行集成,除了上述限制条件外,效果不一样会好。这主要是由于:

  1. 使用 Iframe 框架,可能会改变原有应用的 HTML 结构,导致某些脚本无法运行。
  2. 在一个页面中过多的潜入 IFrame,由于不同 IE 版本对于 IFrame 的处理能力各异,可能会出现不可预料的异常效果。

Web 应用聚合器 (Web Application Integrator)

Web Application Integrator 提供了一种方法,可轻松将现有 Web 应用嵌入 WebSphere 门户,从而带来更高的价值。该技术在感官上与传统的门户集成方式不同,传统的门户集成方式一般是把业务系统的局部或整体界面嵌入到门户页面中,而 Web 应用聚合器是指在业务系统的页面中嵌入门户的主题导航、显示风格等元素,以让业务系统的操作界面保持与门户系统一致。本方式可以使业务系统更多的利用门户的价值,并保持企业内所有系统具有一致的操作体验。Web 应用聚合器可通过以下方式实现:

  1. 在门户中创建一个标准的 Portal URL 页面,并将页面链接指定到需要集成的 Web 应用的页面。
  2. 使用 WebAppIntegrator portlet 为该 Web 应用页面生成一段 HTML 标记代码。<Script>Tag。
  3. 将 script tag 加入到 Web 应用页面的 Header 部分。对于某些特殊的页面模式,script tag 可能也必须加入到 Footer 部分。

    效果如下图:

    图 5. Web 应用聚合器

    图 5 Web 应用聚合器

约束条件:

显而易见,开发人员必须具有在业务系统中修改页面的权限。

业务模块化集成展现(基于应用接口、业务功能模块的整合)

业务模块化集成,是比较深入的整合方式,可实现很好的集成效果,在此模式中,业务应用与门户之间,业务应用与业务应用之间,利用应用中的接口和函数提供接近实时的集成。例如在企业 B2E 门户集成中,把业务人员使用的核心业务系统与其它企业业务资源、协作功能构建在一起,实现综合业务处理平台;在一些 B2B 集成系统中使用 Web 门户来实现 CRM 系统与企业后端应用的集成,构建能够充分利用多个业务系统资源的电子商务门户网站。

在企业门户中,实现业务模块化集成,可以作为企业 ESB 建设的前期尝试和技术积累。一些已经实施了 ESB 项目的企业,利用门户产品可以更大的发挥 ESB 的价值。模块化集成可通过以下技术实现:

  1. 对于纯展现类的信息模块(信息整合),可以利用业务系统中默认提供的底层接口,如 HTML 接口(可以容易通过 HTML Parser 解析的)、XML 接口、Json 接口、Rest 接口等,使用 RAD、Portlet Factory 等开发工具开发实现。此类场景中,门户项目经理及开发工程师主要是需要理清业务系统究竟可以提供哪些现成的接口,利用哪些接口可以更快速的实现开发、部署。
  2. 对于一些标准化产品的模块化集成,比如需要集成 Domino 邮件、SAP 财务模块。一般这些产品会提供多个层面的标准接口,Domino 提供 JAVA/CORBA、JDBC、EJB、Web Service 等方式,SAP 可以提供 BAPI、Web Service 等接口。同时,选择合适的运行、开发平台来加速开发也很重要,例如可以使用 WebSphere Portlet Factory 中开箱即用的构建器(Builder)来来快速生成表单,加速整合进度。
  3. 对于一些交互性模块的集成或者一些非标准化的业务整合需求 ( 应用整合 ),例如需要在门户的内容发布模块直接选择 OA 系统中的公文进行发布,例如需要在门户中实现统一待办等,均需调用这些应用系统的接口,并进行二次开发实现。
  4. 增加协作功能,模块化集成方式中,均需基于某些接口进行二次开发,故为了更好的实现集成的价值,尽量在业务模块的实现协作能力,如实现在线感知、实现个人名片等功能,促进人员之间的协作。
  5. 保持松耦合,从企业 IT 运作的角度来说,先前的应用之间彼此独立,每当有新的业务需求产生时,企业的 IT 部门都要做大量的改进工作,耗费大量的人力、物力和财力。使用门户进行应用整合时,需要建立不同应用系统间的松耦合机制,从而为将来开发面向新的业务的应用奠定基础,以最终节省成本。

效果图如下:

图 6. 业务模块化集成展现示例

图 6 业务模块化集成展现示例

约束条件:

以上集成工作,均需或多或少的调用应用系统的接口,有些还需要业务系统做出若干调整。故,基于国情,门户实施过程中,协调应用系统进行接口的开放和配合工作是第一重要的事情,是门户项目能够顺利开发实施,并取得满意集成效果的非常重要的条件。

业务过程集成

企业中,往往有以下需求:在应用层面,处理一项业务,人们要在不同的业务系统间来回切换,由此降低了工作的效率,并影响了工作的效果。在业务层面,业务流程分散,不完善,致使企业不能根据业务需求自由组合业务流程。比如,企业的业务功能和业务流程被分割成许多小块,分散在不同的信息系统中,而这些系统之间的通信又是微弱的,存在很多的人为工作。故,需要通过门户进行业务过程的集成,以便改进操作、减少成本、提高响应速度。

当对业务过程进行集成的时候,企业必须在各种业务系统中定义、授权和管理各种业务信息的交换,业务过程集成包括业务管理、进程模拟以及综合任务、流程、组织和进出信息的工作流,还包括业务处理中每一步都需要的工具。对于非流程类的业务过程,可以通过业务模块化集成技术实现,对于流程类的业务过程参考以下环节。

企业门户常用来实现跨系统的业务流程整合,业务流程本质是一组按一定次序执行的活动(Activity),流程中的每一步或每一项活动都可以通过服务(Services)来实现,在标准的业务流程执行协议中,服务可以被编排用来实现流程,业务流程本身也是一种服务,服务编排通过业务流程执行语言 BPEL 来描述。在非标准的流程类业务系统中,系统通过其它方式来编排服务(Services)。因此,门户对流程的集成主要体现在对服务(Services)的集成,通过重新编排、组合跨业务系统的服务,门户能够提供:

  • 人与应用组合的流程 (Human-task workflow)
  • 审批过程中需要有第三方人的参与,团队的协作
  • 审批过程中需要查阅、对比相关的资料
  • 审批过程中需要利用以后的知识
  • 交易和补偿
  • 对流程数据的操作

同样,门户对于流程引擎本身的集成,也非常的方便,例如,可以使用 Portal 用户认领(Claim)和处理 WebSphere Process Choreographer 中的任务。门户中提供待办任务列表、提供待办任务提醒模块,对每一个被选中待处理的任务,门户都会启动相应的页面应用实例(Instance)。

  • 同一类型的任务可以启动多个页面;
  • 正在处理特定任务的上下文场景会被传递到页面应用中;
  • 任务完成后,页面自动关闭。

效果图如下:

图 7. 流程集成示例

图 7 流程集成示例

约束条件:

实现业务整合,必须贯穿于企业的多个业务环节,门户实施人员必须对企业环境具备很深厚的业务背景。对于业务方,也必须有一个重量级的 Leader,才能协调整个项目的顺利实施。

数据集成展现(基于业务数据集成整合)

数据集成的另外一层含义包括数据和数据库的集成,包括数据的标识化和编目,包括主数据管理,还包括元数据建模,包括数据在数据库系统中的分布和共享等。在这里,主要是指已经处理好的数据,如何通过门户进行展现的问题。

将业务系统相关的业务数据通过 portlet 技术实现与门户站点内容聚集,在实际集成中会经常遇到。通常业务系统并没有提供相关的业务数据整合功能,门户需要将不同业务功能的业务数据在一个 portlet 做集中展现,或者将某一个业务功能统计的数据部分展现。数据集成展现的主要技术实现如下:

  1. 通过 JDBC、Web Service 等方式,直接访问后台业务系统的数据源,并在 RAD 或 Portlet Factory 中进行 Portlet 开发。
  2. 通过 WebSphere Dashboard Framework 进行 Portlet 开发,利用内置的开箱即用的构建器(Builder)加速对 BI 系统的开发实施,利用内置的图形化引擎 (iLog Jview),实现丰富的展现效果。
  3. 直接利用 iLog Jview 图形化引擎进行 Portlet 开发。
  4. 某些特殊效果,比如动画效果,还可利用 Flex 开发 Flash 格式的 Portlet,然后嵌入到门户中。

效果图如下:

图 8. 数据集成示例

图 8 数据集成示例

约束条件:

对于 Dashboard、Flex、JView 开发技能有一定的要求。同时,美工的水平对最终的展现效果至关重要。

门户与 C/S 业务系统实现 SSO

对于 C/S 结构的应用,通常使用可以采用如下方式实现集成:

  1. 门户作为该应用的入口,通过定制开发的 Portlet,激活应用系统的客户端程序;通过客户端程序访问应用。而门户仅仅起到入口作用。门户上的 Portlet 激活应用系统的客户端程序后,所有的访问与门户无关。
  2. 通过定制开发新 Portlet 调用应用提供的各种接口,如 Web Service 接口、通过定制开发新 Portlet 调用应用提供的各种接口,如 Web Service 接口、API、XML 等,获取应用系统需要在门户上展现的数据,并根据门户的界面风格规范形成展现界面,在门户上实现展现集成
  3. 通过第三方软件实现 C/S 系统 B/S 访问方式。对业务系统的要求:提供符合当前 Portal(门户信息系统)VI 标准的用户界面;修改或添加业务功能接口,以便实现页面或业务数据在门户信息系统的内容聚集;
  4. 另外,Tarantella 和 Citrix 都是将 C/S 应用系统转化为 Web 应用的第三方软件系统。

MainFrame 应用的集成

对于某些大型机的应用,可能也需要集成到门户中。具体技术方案是,通过 HATS(Host Access Transformation Server)可将终端应用转成 Portlet 或者 Web 应用。HATS 提供开放、灵活的环境创建 Portlet,支持 Click-to-Action、协作 Portlet、Credential Vault、单点登录。

集成的标准

要实现完全的数据集成,必须首先选择数据的标准格式。要实现完全的应用集成,必须首先明确应用的标准接口,集成的标准化促成了信息和业务数据的共享和分布,构成了企业应用集成的核心,包括 COM+/DCOM、CORBA、EDI、JavaRMI 和 XML.

采用 portlet 技术实现业务系统数据与门户站点内容聚集,数据的存储、传递可选择如下标准:

层级 层次名称 标准 Portal 服务 安全 / 工具
Top 应用前端 
Application Front End
TCP/IP, Http/Https, XML,Json Iframe Portlet SSL, VPN
1 展现层 
Presentation
JSR168,JSR170
JCR,RSS
Widget,WSRP
HTMLParser Portlet
XML Parser Portlet
Web2.0 Portlet
凭证库(主动、被动凭证)
Dashboard( 仪表盘)
iWidget
TAM/TIM
LDAP
CA
2 流程层 
Process Management
BPEL
JSR286
流程类 Portlet
eForm Portlet
 
3 服务层 
Web services
JSR286
WSDL
UDDI
SOAP,XML
WebService Portlet
WebSerivce For Remote portlet
Dashboard
 
4 组件层 Components J2EE JAAS 认证标准接口 
LTPA 信任机制
WS-Security 规范 
SSO 单点登录

常用的数据传输标准规范明细:

  1. XML 文件

    XML 是可扩展置标语言,使用基于 XML 技术的数据封装,将异构数据源增加一个以 XML 为格式的封装体,在不改变数据源的前提下,用 XML 对数据源的定义描述字、数据源的创建等相关信息进行封装。

    XML 的核心是数据,通过采用基于 XML 技术的数据封装实现 portlet 与待集成业务系统之间的交互,portlet 应用程序不需要了解业务系统的数据格式。

    XML 技术已经成为了业界标准的异构系统间的数据传输技术。

  2. 文本文件

    文本文件相对而言没有固定标准,数据存储可由 portlet 应用实现与业务系统之间协商数据的存储格式。按照协商的数据存储格式,业务系统将业务数据进行封装,portlet 应用程序将数据文件采集、分解,实现业务数据内容与门户站点内容的聚集。

  3. 其他

    可采用例如 Excel 或 word 文件存储的方式。

    通过采用以上几种方式将数据封装,门户 portlet 应用通过多种通讯协议(如:HTTP、FTP 等), 通过应用程序开发实现数据文件的采集,分解数据文件,通过 portlet 编程实现业务数据与门户站点内容聚集。

  4. Web services 方式

    Web services 是基于网络的、分布式的模块化组件,它执行特定的任务,遵守具体的技术规范,这些规范使得 Web Services 能与其他兼容的组件进行互操作;Web services 是自包含的、模块化的应用程序,它可以在网络(通常为 Web)中被描述、发布、查找以及调用。

    通过改造待集成的业务系统,由业务系统通过提供 Web services 服务的方式,由 portlet 调用 Web services 服务来实现业务数据的采集,由 portlet 完成业务数据与门户站点内容的聚集。

  5. 直接访问业务系统数据源

    业务系统直接提供数据源的访问地址(如数据库服务器 IP),通过 JDBC 或 ODBC 技术,由 portlet 应用程序编程实现数据数据采集,而无需修改待集成的业务系统。

回页首

结束语

如上所述,利用标准的统一的技术规范作为工具,以 WebSphere Portal 提供的单点登录和应用整合功能作为加速器,快速满足企业的业务整合需求。一个统一的集成门户才能更好的为企业服务。

另外,别忘了,WebSphere Portal 的功能可不仅仅是整合能力。它还能提供框架服务、协作服务、内容服务等,从各个角度来满足企业的个性化门户需求,详情请了解门户产品的其它内容。

参考 :http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1202_wanght_sso/1202_wanght_sso.html

发布了26 篇原创文章 · 获赞 275 · 访问量 22万+

猜你喜欢

转载自blog.csdn.net/smxjant/article/details/91042923
今日推荐