CN101888376B - 信息协作基础装置 - Google Patents

Abstract

在信息协作基础装置(70)中，根据包含相互对应的请求侧属性名、应用程序侧属性名以及属性信息取得目的地的属性信息取得方法，从请求中取得属性信息，并且将该属性信息内的请求侧属性名及属性值中的请求侧属性名变更为应用程序侧属性名，将该应用程序侧属性名以及属性值写入到临时存储部(53)中，生成包含临时存储部(53)内的应用程序侧属性名以及属性值的应用程序会话，并将其保存在应用程序会话存储部(61)中，然后将应用程序会话存储部(61)内的应用程序会话发送给服务逻辑部(80)。由此，在不变更服务逻辑的安装的情况下，从属性信息的提供方法或属性名不同的访问管理服务器取得用户的属性信息。

Description

信息协作基础装置

相关技术的交叉引用

本申请基于先前在2009年5月15日递交的日本专利申请No.2009-118153，并享受其优先权的好处；其全部内容被收容于本申请中，以资参考。

技术领域

本发明涉及一种信息协作基础装置，其在对请求提供服务的用户进行认证后，使访问管理服务器提供的用户的属性信息与服务逻辑(service logic)协作。

背景技术

在用户利用Web应用程序系统(application system)时的认证技术中，存在称为单点登录(single sign on)的技术。关于该技术，通过一次认证能够利用多个Web站点，对于用户而言，能够省略对每个Web站点接受认证的手续，从而能够减轻用户登录时的负担。

近年，很多供应商提供具有该单点登录的功能的访问管理服务器产品。作为单点登录的方式，访问管理服务器主要分为代理(agent)式和反向代理(reverse proxy)式。

代理式是如下方式，在Web服务器或应用程序服务器上设置称为代理的模块，在未认证的用户从客户终端向Web服务器/应用程序服务器发送了请求时，代理使该请求重定向(redirect)至访问管理服务器，从而在客户终端与访问管理服务器之间进行认证处理。在代理式中，在认证处理成功时，来自客户终端的请求再次返回Web服务器/应用程序服务器。

另一方面，反向代理式是如下的方式，在客户终端与Web服务器/应用程序服务器之间设置作为代理服务器进行动作的访问管理服务器，访问管理服务器接受来自未认证的用户的请求，进行认证处理。在反向代理式中，在认证处理成功时，访问管理服务器把来自客户终端的请求交给Web服务器/应用程序服务器。来自Web服务器/应用程序服务器的响应经由访问管理服务器返回客户终端。

访问管理服务器对储存有用户的属性信息的数据库进行管理。而且，访问管理服务器在代理式和反向代理式的认证都成功的情况下，把该数据库内的用户的属性信息交给Web服务器/应用程序服务器。对于转交哪个属性信息，预先在设定文件中进行设定。

Web服务器/应用程序服务器上的应用程序将从访问管理服务器取得的属性信息存储在会话(session)中，用于画面显示和访问控制。

在日本特开2007-48241号公报中记载的技术中，在访问管理服务器侧，确定向Web服务器/应用程序服务器发送的用户的属性信息，仅将需要的属性信息交给Web服务器/应用程序服务器，由此，减轻Web服务器/应用程序服务器侧的处理负荷，使属性信息的转交高效化。

但是，在对Web服务器/应用程序服务器交接属性信息时，对于访问管理服务器的每个产品，属性信息的提供方法或属性名不同。例如，在某个产品中使用如下的属性信息提供方法，即，将邮箱地址以称为“mail”的属性名的方式储存在属性信息中，利用小型文件(cookie)信息将该属性信息交给Web服务器/应用程序服务器。另外，在另外的产品中使用如下的属性信息提供方法，即，将相同的邮箱地址以称为“mailAddress”的属性名的方式储存在属性信息中，利用HTTP(超文本传输协议)头域(header)，将该属性信息交给Web服务器/应用程序服务器。即，对于访问管理服务器的每个产品，使用不同的属性信息的提供方法或属性名。

由于这样的访问管理服务器的产品的不同，所以在每次转移访问管理服务器时，需要在作为Web服务器/应用程序服务器侧的服务提供单元的服务逻辑中安装对应转移后的访问管理服务器的产品，取得用户的属性信息的功能。

总之，在Web服务器/应用程序服务器一侧，从取得用户的属性信息的观点出发，存在如下的缺陷，即，需要对属性信息的提供方法或属性名不同的访问管理服务器的每个产品，变更服务逻辑的安装。

发明内容

本发明的目的在于提供一种信息协作基础装置，其能够不变更服务逻辑的安装地，从属性信息的提供方法或属性名不同的访问管理服务器取得用户的属性信息。

本发明的一个方面是一种信息协作基础装置，设置在访问管理服务器装置与应用程序服务器装置中的所述应用程序服务器装置中，对从所述访问管理服务器装置发送的请求执行信息协作处理，通过该信息协作处理将所述应用程序会话发送给服务提供单元，所述访问管理服务器装置在从终端接收到请求时，对发送所述请求的用户进行认证处理，在所述认证处理成功后，发送储存了对每个请求侧属性名包含所述用户的属性值的属性信息的所述请求，所述应用程序服务器装置具有所述服务提供单元，所述服务提供单元根据包含相互对应的应用程序侧属性名以及所述属性值的应用程序会话，向所述终端提供服务信息，所述信息协作基础装置具有：属性信息取得方法定义单元，其定义了包含相互对应的请求侧属性名、应用程序侧属性名以及属性信息取得目的地的属性信息取得方法；属性信息取得单元，其根据所述属性信息取得方法，从所述发送的请求取得属性信息，并且将该属性信息内的请求侧属性名及属性值中的请求侧属性名更改为应用程序侧属性名，然后将该应用程序侧属性名以及该属性值写入所述应用程序服务器装置的存储单元中；应用程序会话验证单元，其验证在所述存储单元内是否存在包含该应用程序侧属性名以及属性值的应用程序会话；应用程序会话生成单元，其在所述验证的结果为否的情况下，生成包含该应用程序侧属性名以及属性值的应用程序会话；以及应用程序会话发送单元，在将所述生成的应用程序会话写入到所述存储单元后，其将所述存储单元内的应用程序会话发送给所述服务提供单元。

此外，本发明的一个方面表现为“装置”，但不限于此，可以使用其他的表现方式，即，“方法”、“程序”或“计算机能够读取的存储有程序的存储介质”。

在本发明的一个方面中，根据包含相互对应的请求侧属性名、应用程序侧属性名以及属性信息取得目的地的属性信息取得方法，从请求取得属性信息，并且将该属性信息内的请求侧属性名以及属性值中的请求侧属性名更改为应用程序侧属性名，将该应用程序侧属性名以及属性值写入应用程序服务器装置的存储单元，然后生成包含存储单元内的应用程序侧属性名以及属性值的应用程序会话，将该应用程序会话发送给服务提供单元。

由此，可以不变更服务逻辑的安装地，从属性信息的提供方法或属性名不同的访问管理服务器取得用户的属性信息。

附图说明

图1是表示包含本发明第一实施方式的信息协作基础装置的服务提供系统的结构例子的示意图。

图2是表示同一实施方式的属性信息存储部的结构的示意图。

图3是表示同一实施方式的属性信息取得方法定义部的结构的示意图。

图4是表示同一实施方式的临时存储部的结构的示意图。

图5是表示同一实施方式的应用程序会话存储部的结构的示意图。

图6是用于说明同一实施方式的动作的流程图。

国7是表示包含本发明的第二实施方式的信息协作基础装置的服务提供系统的结构例子的示意图。

图8是表示同一实施方式的属性信息验证规则定义部的结构的示意图。

图9是用于说明同一实施方式的动作的流程图。

图10是表示包含本发明第三实施方式的信息协作基础装置的服务提供系统的结构例子的示意图。

图11是表示同一实施方式的属性信息变换规则定义部的结构的示意图。

图12是用于说明同一实施方式的动作的流程图。

图13是用于说明同一实施方式的应用程序会话的存储动作的示意图。

图14是表示包含本发明的第四实施方式的信息协作基础装置的服务提供系统的结构例子的示意图。

图15是用于说明同一实施方式的动作的流程图。

具体实施方式

下面，使用附图说明本发明的各实施方式。对于以下的各装置中的每个装置，可以通过硬件结构，或者通过硬件资源与软件的组合结构来构成。作为组合结构的软件，使用预先从网络或计算机可读取的存储介质安装到对应的装置的计算机中，用于实现对应的装置的功能的程序。

(第一实施方式)

图1是表示包含本发明第一实施方式的信息协作基础装置的服务提供系统的结构例子的示意图，图2至图5是表示同一服务提供系统内的各存储部或定义部的结构例子的示意图。该服务提供系统具有客户终端10、Web服务器装置20、访问管理服务器装置30以及应用程序服务器装置40。

在此，客户终端10设置有任意的Web浏览部(未图示)。Web浏览部由执行存储器内的任意的Web浏览器的CPU的一个功能构成，例如，具有如下两种功能，即，第一种功能是通过用户的操作，对Web服务器装置20发送存储了对每个请求侧属性名包含用户的属性值的属性信息的请求；第二种功能是显示经由Web服务器装置20从应用程序服务器装置40提供的服务信息。

Web服务器装置20接受从客户终端10发送的服务请求，将其交给应用程序服务器装置40，并且把来自应用程序服务器装置40的响应交给客户终端10。在Web服务器装置20中设置有代理部21，所述代理部21用于与访问管理服务器装置30进行信息的收发。代理部21由执行存储器内的代理程序(agent program)的CPU的一个功能构成，例如，进行把从未认证的用户操作的客户终端10发送的请求重定向至访问管理服务器装置30的处理；对访问管理服务器装置30发送属性信息取得要求的处理；从访问管理服务器装置30取得认证完的用户的属性信息，然后将其交给应用程序服务器装置40的处理。

访问管理服务器装置30具有属性信息存储部31以及访问管理部32。在本实施方式中，举例表示了使用代理式的访问管理服务器装置30的情况，但还可以使用反向代理式的访问管理服务器装置。

属性信息存储部31是访问管理部32能够进行读取/写入的数据库，如图2所示，存储用户的属性信息表31a。属性信息表31a对每个用户存储有由各字段构成的记录，所述各字段包含与作为请求侧的属性名的“uid”(用户识别名)、“cn”(姓名)、“telephoneNumber”(电话号码)、“facsimileTelephoneNumber”(传真号码)、“mail”(邮箱地址)对应的属性值。

访问管理部32具有如下的功能，即，在从客户终端10接收到请求时，对发送请求的用户进行认证处理，在认证处理成功后，对Web服务器装置20发送存储有对每个请求侧属性名包含该用户的属性值的属性信息的请求。认证处理例如能够适当地使用如下的处理：将请求内的属性信息与属性信息存储部31内的属性信息进行核对来确认两者的一致的处理；或将请求内的用户ID以及密码与属性信息存储部31内的用户ID以及密码(未图示)进行核对来确认两者的一致的处理。访问管理部32具有如下的功能，即，在来自客户终端10的请求包含用户ID以及密码，但不包含提供服务所需的属性信息时，在认证处理成功后，通过来自Web服务器装置20的属性信息取得要求，将属性信息存储部31内的属性信息发送给Web服务器装置20。

另一方面，应用程序服务器装置40具有通过属性信息处理部50以及会话处理部60执行信息协作处理的信息协作基础装置70和作为服务提供单元的服务逻辑部80。信息协作基础装置70设置在应用程序服务器装置40中，例如由执行存储器内的程序的CPU一个功能构成，对经由Web服务器装置20从访问管理服务器装置30发送来的请求进行信息协作处理，通过该信息协作处理将应用程序会话(application session)发送至服务逻辑部80。

属性信息处理部50具有属性信息取得方法定义部51、属性信息取得部52以及临时存储部53。

属性信息取得方法定义部51预先通过操作者的设定操作，如图3表示一个例子那样，定义了表示从访问管理服务器装置30如何取得用户的属性信息的属性信息取得方法51a。此外，“定义”这一用语可以更改为“设定”，这在本说明书中的其他的说明部部分也相同。属性信息取得方法51a包含相互对应的请求侧属性名(以下，还称为属性名(请求侧))、应用程序侧属性名(以下，还称为属性名(应用侧))，以及属性信息取得目的地，在图3的例子中还包含会话储存标识。其中，在定义了将所有的属性信息储存在应用程序会话中时，可以省略会话储存标识。

属性信息取得方法51a的“属性名(应用侧)”表示应用程序侧的属性名，“属性名(请求侧)”表示在访问管理服务器装置30中的属性名。根据该2种属性名的定义，能够从访问管理服务器装置30取得“属性名(请求侧)”的属性值，并在应用程序服务器装置40侧设定为“属性名(应用侧)”的属性值。“属性信息取得目的地”定义了从哪里取得从访问管理服务器装置30提供的属性信息。在本实施方式中，“cookie”表示从小型文件(cookie)信息取得，“header”表示从HTTP头域取得。“会话储存标识”定义是否在应用程序会话中存储从访问管理服务器装置30取得的属性信息。在此，在值为“TRUE”时，表示储存在应用程序会话中，在值为“FALSE”时，表示不储存在应用程序会话中。

属性信息取得部52基于在属性信息取得方法定义部51中定义的属性信息取得方法51a，从访问管理服务器装置30发送的请求中取得用户的属性信息。具体地说，属性信息取得部52具有如下的功能，即，基于在属性信息取得方法定义部51中定义的属性信息取得方法，从该发送的请求中取得属性信息，并且将该属性信息内的请求侧属性名以及属性值中的请求侧属性名更改为应用程序侧属性名，然后将该应用程序侧属性名以及该属性值写入临时存储部53中。

临时存储部53是能够从属性信息取得部52以及应用程序会话生成部63进行读取/写入的存储区域，如图4所示，临时存储由应用程序侧属性名以及属性值构成的属性信息53a。临时存储部53以及应用程序会话存储部61构成应用程序服务器装置30的存储单元。

会话处理部60具有应用程序会话存储部61、应用程序会话验证部62以及应用程序会话生成部63。

应用程序会话存储部61是能够从应用程序会话验证部62以及应用程序会话生成部63读取/写入的存储区域，如图5所示，存储使用由应用程序服务器装置40提供的服务信息的用户的应用程序会话61a的信息。在此，应用程序会话61a对每个会话ID具有应用程序侧属性名以及属性值。

应用程序会话验证部62验证在应用程序会话存储部61中是否存在包含想使用服务信息的用户的应用程序侧属性名以及属性值的应用程序会话61a。如果验证的结果为存在应用程序会话61a，则原样地结束处理。在不存在应用程序会话61a时(为否时)，委托应用程序会话生成部63生成应用程序会话61a。

应用程序会话生成部63在接收到来自应用程序会话验证部62的应用程序会话生成委托时，将临时存储部53内的由属性信息取得部52取得的属性信息53a写入应用程序会话61a中，在将该应用程序会话61a储存在应用程序会话存储部61中后，将应用程序会话存储部61内的应用程序会话61a发送给服务逻辑部80。

服务逻辑部80安装有提供给用户的服务，具体地说，由执行存储器内的服务提供用程序的CPU的一个功能构成，例如，具有服务提供功能，所述服务提供功能在从应用程序会话生成部63接收到包含相互对应的应用程序侧属性名以及属性值的应用程序会话61a时，基于该应用程序会话61a，向客户终端10提供服务信息。“服务逻辑部”这一名称也可以适当地更改为“服务安装部”、“服务提供部”或“服务信息提供部”等名称。

另外，“服务信息”，在“向用户提供的服务”是像电子商务交易中的内容销售等那样提供电子数据(例如，加密内容)的服务时，是该电子数据；在“向用户提供的服务”是像电子商务交易中的物品销售等那样提供物品(例如，通过快递服务等配送的有形物体)的服务时，能够使用该物品销售的受理完成通知(例如，包含顾客侧存根信息的通知)等。即，服务信息能够对应于服务内容使用任意的信息。

然后，使用图6的流程图说明包含以上结构的信息协作基础装置的服务提供系统的动作。

首先，客户终端10通过未认证的用户的操作，将请求发送给Web服务器装置20。

Web服务器装置20通过代理部21使该请求重定向至访问管理服务器装置30。

在访问管理服务器装置30从客户终端10接收到通过重定向再次发送的请求时，基于请求，通过访问管理部32对用户进行认证处理，在认证处理成功后，使请求重定向至Web服务器装置20。

在Web服务器装置20中，通过代理部21向访问管理服务器装置30发送属性信息取得要求，取得对该用户的每个请求侧属性名包含该用户的属性值的属性信息。在取得属性信息后，将该属性信息储存在该请求中，然后发送至应用程序服务器装置40。

(步骤S1)

应用程序服务器装置40当接收到该请求时，属性信息取得部52读取由属性信息取得方法定义部51定义的属性信息取得方法51a。

(步骤S2)

属性信息取得部52根据在步骤S1中取得的属性信息取得方法51a，逐一取得包含在请求中的属性信息。例如，从小型文件(cookie)信息取得请求侧属性名“sessionid”的属性值，从HTTP头域取得请求侧属性名“uid”的属性值。

(步骤S3)

属性信息取得部52针对在步骤S2中取得的属性信息，确认属性信息取得方法51a的“会话储存标识”是“TRUE”还是“FALSE”，如果是表示“储存”的“TRUE”则进入步骤S4。如果是表示“不储存”的“FALSE”则进入步骤S5。

(步骤S4)

属性信息取得部52将取得的用户的属性信息内的“属性名(请求侧)”的属性值作为“属性名(应用侧)”的属性值存储在临时存储部53中。在本实施方式中，如图4所示，设定属性值。临时存储部53可以是存储器也可以是HDD(硬盘驱动器)。

(步骤S5)

属性信息取得部52判定在请求内是否存在未取得的属性信息。在存在未取得的属性信息时，进入步骤S2。在不存在时，进入步骤S6。

(步骤S6)

应用程序会话验证部62判定是否已经存在要求了服务的用户的应用程序会话61a。在不存在应用程序会话61a时，进入步骤S7。在存在时，进入步骤S8。

(步骤S7)

应用程序会话生成部63生成新的应用程序会话61a，并将其储存在应用程序会话存储部61中。此时，把在步骤S4中存储在临时存储部53中的属性信息53a设定在应用程序会话61a中。在本实施方式中，如图5所示，设定属性值。

(步骤S8)

然后，应用程序会话生成部63将应用程序会话61a发送至服务逻辑部80，来交接处理。

服务逻辑部80基于该应用程序会话61a将服务信息发送至客户终端10。

客户终端10显示发送来的服务信息。由此，用户接受提供的服务。

如上所述，根据本实施方式，根据包含相互对应的请求侧属性名、应用程序侧属性名以及属性信息取得目的地的属性信息取得方法，从请求取得属性信息，并且将该属性信息内的请求侧属性名以及属性值中的请求侧属性名更改为应用程序侧属性名，然后将该应用程序侧属性名以及属性值写入到临时存储部53中，并且包含临时存储部53内的应用侧属性名以及属性值的应用程序会话，然后将其保存在应用程序会话存储部61中，然后将应用程序会话存储部61内的应用程序会话发送给服务逻辑部80。

因此，可以在不变更服务逻辑部80的安装的情况下，从属性信息的提供方法或属性信息的名称不同的访问管理服务器装置30取得用户的属性信息。因此，能够简单地转移访问管理服务器装置30。

在本实施方式中，记载了通过属性信息取得部52取得经由代理部21从访问管理服务器装置30转交的请求中包含的属性信息，但包含属性信息的请求例如还可以是从反向代理式的访问管理服务器装置30转交的请求，另外，也可以是利用发出请求的工具从客户终端10直接发送的请求。

(第二实施方式)

图7是表示包含本发明第二实施方式的信息协作基础装置的服务提供系统的结构例子的示意图，对与图1相同的部分标注相同的附图标记，在包含附加的功能部附加符号’，并省略其详细的说明，在此主要描述附加的功能部。此外，在以下的各实施方式中同样省略重复的说明。

本实施方式是第一实施方式的变形例，是对从请求取得的属性信息进行验证的方式，具体地说，对于图1所示的结构，附加了属性信息验证规则定义部54以及属性信息验证部55。

在此，如在图8表示的一个例子那样，属性信息验证规则定义部54预先通过操作者的设定操作，定义用于对从访问管理服务器装置30取得的用户的属性信息53a的属性值进行验证的属性信息验证规则54a。

属性信息验证规则54a对每个“属性名(请求侧)”，定义了“属性验证标识”以及“验证规则”。

“属性验证标识”定义进行验证的定时(timing)。在本实施方式中，定义了“TRUE”、“FIRST”、“FALSE”这3种定时。“TRUE”表示在每次用户进行服务要求时进行验证。“FIRST”表示仅在不存在用户的应用程序会话61a的情况下进行验证。“FALSE”表示不进行验证。验证的定时并不限于此，还可以定义为其他的定时。

在“验证规则”中定义用于验证的规则。在本实施方式中，定义了“Exists”、“isNumber”这两种规则。“Exists”是用于验证有无属性值的(是否存在属性值)的规则，“isNumber”是用于验证属性值是否是数值数据(数字)的规则。验证规则不限于此，可以定义任意的规则。

属性信息验证部55基于由属性信息验证规则定义部54定义的验证规则以及定时，对从请求取得的属性信息内的属性值进行验证，并且具有在验证的结果为验证失败时，向客户终端发送例外消息的功能。

然后，使用图9的流程图说明包含如上构成的信息协作基础装置的服务提供系统的动作。在第二实施方式中，在第一实施方式的处理的步骤S2与步骤S3之间追加新的步骤S2-1、S2-2的处理。除此以外的处理与第一实施方式相同。因此，仅说明第一实施方式的步骤S2至步骤S3之间的处理。

(步骤S2-1)

如上所述，执行直到步骤S2的处理。

属性信息验证部55参照由属性信息验证规则定义部54定义的“属性验证标识”，对在步骤S2中取得的用户的属性信息判定验证的定时。在判定的结果为“不验证”、“第二次以后的服务要求(“FALSE”或“FIRST”)”时，进入步骤S3。在判定的结果为“验证”或“第一次服务要求(“TRUE”或“FIRST”)”时，进入步骤S2-2。在本实施方式中，仅在请求侧的属性名为“mail”的情况下，进入步骤S3。

(步骤S2-2)

属性信息验证部55参照属性信息验证规则定义部54定义的“验证规则”，根据该“验证规则”对在步骤S2中取得的用户的属性信息进行验证。在本实施方式中，定义了与请求侧的属性名即“sessionid”、“uid”、“cn”对应的属性值，按照“Exists”(是否存在)的规则进行检验。因为这些属性信息都是已经通过属性信息取得部52取得，所以验证结果成功。另外，定义了与请求侧的属性名即“tel”、“fax”对应的属性值，按照“isNumber”(属性值是否是数字)的规则，在“FIRST”(仅第一次验证)的定时，进行验证。因为这些属性信息都是数值，所以验证结果为成功。在所有的验证成功的情况下，进入步骤S3。在对某个属性信息的验证结果失败的情况下，例如，进行显示例外消息等的处理，并结束验证处理。

以下，如上所述执行步骤S3以后的处理。

如上所述，根据本实施方式，根据在信息协作处理中验证属性信息的结构，除了第一实施方式的效果之外，因为不会向服务逻辑部80发送基于存在不足或不完备的属性信息的应用程序会话61a，所以能够提高信息协作处理的可靠性。

(第三实施方式)

图10是表示包含本发明第三实施方式的信息协作基础装置的服务提供系统的结构例子。

本实施方式是第一实施方式的变形例，是对从请求取得的属性信息进行变换的形式，对于图1所示的结构，附加了属性信息变换规则定义部56以及属性信息变换部57。

在此，属性信息变换规则定义部56预先通过操作者的设定操作，如在图11表示的一个例子那样，定义属性信息变换规则56a，所述属性信息变换规则56a用于对从访问管理服务器装置30取得的用户的属性信息的属性值53a，变换属性值的形式。

属性信息变换规则56a对每个“属性名(请求侧)”，定义了“属性变换标识”以及“变换规则”。

“属性变换标识”定义是否变换属性信息的形式。在本实施方式中，定义了“TRUE”、“FALSE”。在“属性变换标识”为“TRUE”时，进行变换处理。在“属性变换标识”为“FALSE”时，不进行变换处理。

在“变换规则”中定义用于变换的规则。在本实施方式中，定义了“H_DEL”，所述“H_DEL”表示删除属性值中包含的“连字符(hyphen)”的规则。“变换规则”不限于此，只要能够变换属性值的形式，可以定义任意的内容。作为“变换规则”其他例子，列举将英文的小写文字变换为大写文字，或者将大写文字变换为小写文字等。或者，列举有删除邮箱地址中的以后的文字等。或者，列举将属性值中包含的不等号“＜”、“＞”变换为不对计算机的动作造成影响的“&lt”、“&gt”等。

属性信息变换部57基于由属性信息变换规则定义部56定义的属性信息变换规则56a，变换由属性信息取得部52取得的属性信息的属性值的形式。

然后，使用图12的流程图说明包含如上构成的信息协作基础装置的服务提供系统的动作。在第三实施方式中，在第一实施方式的处理的步骤S2与步骤S3之间追加新的步骤S2-3、S2-4的处理。除此之外的处理与第一实施方式相同。因此，说明第一实施方式的步骤S2至步骤S3之间的处理。

(步骤S2-3)

如上所述，执行直到步骤S2的处理。

属性信息变换部57，参照由属性信息变换规则定义部56定义的“属性变换标识”，判定是否对在步骤S2中取得的用户的属性信息进行变换。在判定的结果为不进行变换(“FALSE”)时，进入步骤S3。在判定的结果为进行变换(“TRUE”)时，进入步骤S2-4。在本实施方式中，仅在属性名为“telephoneNumber”、“facsimileTelephoneNurnber”时，进入步骤S2-4。

(步骤S2-4)

属性信息变换部57参照由属性信息变换规则定义部56定义的“变换规则”，基于该“变换规则”，对在步骤S2中取得的用户的属性信息，变换属性值的形式。在本实施方式中，使用对于属性名(请求侧)“telephoneNumber”、“facsimileTelephoneNumber”的属性值(包含连字符的数值串数据)，删除“连字符”的规则(“H_DEL”)。结果，如图13所示，在应用程序会话存储部61中，作为属性名(应用侧)“tel”、“fax”的属性值，储存包含删除了连字符的数值串数据的应用程序会话61a。

以下，如上所示，执行步骤S3以后的处理。

如上所示，根据本实施方式，通过在信息协作处理中对属性信息进行变换，除了第一实施方式的效果之外，因为能够向服务逻辑部80输送基于适合服务逻辑郡80的处理的属性信息的应用程序会话61a，因此，能够提高信息协作处理中的信息的匹配性。

(第四实施方式)

图14是表示包含本发明第四实施方式的信息协作基础装置的服务提供系统的结构例子的示意图。

本实施方式是将第一～第三实施方式组合的形式，对于图1所示的结构，附加了图7所示的属性信息变换规则定义部54以及属性信息验证部55，和图10所示的属性信息变换规则定义部56以及属性信息变换部57。

在此，属性信息验证部55以及属性信息变换规则定义部56分别如第二实施方式中所述那样。

属性信息变换规则定义部56以及属性信息变换部57分别如第三实施方式中所述那样。

接着，使用图15的流程图说明包含如上结构的信息协作基础装置的服务提供系统的动作。在第四实施方式中，在第一实施方式的处理的步骤S2与步骤S3之间，追加上述的步骤S2-1、S2-2、S2-3、S2-4的处理。此外的处理与第一实施方式相同。在步骤S2与步骤S3之间，可以在步骤S2-1、S2-2之前执行步骤S2-3、S2-4。

不论为何种顺序，在步骤S2和步骤S3中，执行上述的属性信息的验证处理(S2-1、S2-2)和属性信息的变换处理(S2-3、S2-4)。以下，如上所述，执行步骤S3以后的处理。

如上所述，根据本实施方式，通过对图1所示的结构附加第二实施方式的属性信息变换规则定义部54以及属性信息验证部55，和第三实施方式的属性信息变换规则定义部56以及属性信息变换部57，能够同时得到第一～第三实施方式的效果。

此外，可以将上述实施方式记载的方法作为可由计算机执行的程序，储存在磁盘(软盘(注册商标)，硬盘等)、光盘(CD-ROM、DVD等)、光磁盘(MO)、半导体存储器等存储介质中来进行发布。

另外，作为该存储介质，只要是能够存储程序，并且是计算机能够读取的存储介质，该存储形式可以是任何的方式。

另外，根据从存储介质安装在计算机上的程序的指示在计算机上运行的OS(操作系统)、数据库管理软件、网络软件等MW(middleware：中间软件)等可以执行用于实现上述实施方式的各处理的一部分。

而且，本发明的存储介质不限于与计算机独立的介质，还包含下载通过LAN或因特网(Internet)等传送的程序，然后存储或者临时存储该程序的存储介质。

另外，存储介质并不限于一个，从多个介质执行上述实施方式的处理的情况也包含在本发明的存储介质中，介质结构可以是任何结构。

此外，本发明的计算机根据存储在存储介质中的程序，执行上述实施方式中的各处理，可以是个人电脑等1个计算机构成的装置，也可以是通过网络连接了多个装置的系统等任何结构。

另外，本发明的计算机不限于个人电脑，还包含信息处理设备中的运算处理装置、微型计算机等，是通过程序能够实现本发明的功能的设备、装置的总称。

此外，本发明不限于上述实施方式，在实施阶段，在不脱离其宗旨的范围内可以使结构要素变形来具体化。另外，可以通过在上述实施方式中公开的多个结构要素的适当的组合，形成各种发明。例如，可以从实施方式所示的全部结构要素中删除几个结构要素。而且，可以适当地组合不同的实施方式中的结构要素。

Claims (3)

1.一种信息协作基础装置，设置在访问管理服务器装置与应用程序服务器装置中的所述应用程序服务器装置中，对从所述访问管理服务器装置发送的请求执行信息协作处理，通过该信息协作处理将应用程序会话发送给服务提供单元，

所述访问管理服务器装置在从终端接收到请求时，对发送所述请求的用户进行认证处理，在所述认证处理成功后，发送储存有对每个请求侧属性名包含所述用户的属性值的属性信息的所述请求，

所述应用程序服务器装置具有所述服务提供单元，所述服务提供单元根据包含相互对应的应用程序侧属性名以及所述属性值的应用程序会话，向所述终端提供服务信息，

所述信息协作基础装置的特征在于，具有：

属性信息取得方法定义单元，其定义了包含相互对应的请求侧属性名、应用程序侧属性名以及属性信息取得目的地的属性信息取得方法；

属性信息取得单元，其根据所述属性信息取得方法，从所述发送的请求中取得属性信息，并且将该属性信息内的请求侧属性名以及属性值中的请求侧属性名更改为应用程序侧属性名，然后将该应用程序侧属性名以及该属性值写入到所述应用程序服务器装置的存储单元中；

应用程序会话验证单元，其验证在所述存储单元内是否存在包含该应用程序侧属性名以及属性值的应用程序会话；

应用程序会话生成单元，其在所述验证的结果为否的情况下，生成包含该应用程序侧属性名以及属性值的应用程序会话；以及

应用程序会话发送单元，在将所述生成的应用程序会话写入到所述存储单元后，其将所述存储单元内的应用程序会话发送给所述服务提供单元。

2.根据权利要求1所述的信息协作基础装置，其特征在于，还具有：

属性信息验证规则定义单元，其对每个请求侧属性名定义验证规则以及进行基于所述验证规则的验证的定时；

属性信息验证单元，其基于所述验证规则以及所述定时，验证从所述请求取得的属性信息内的属性值；

例外消息发送单元，其在所述属性信息验证单元的验证结果为验证失败时，将例外消息发送给客户终端。

3.根据权利要求1或2所述的信息协作基础装置，其特征在于，还具有：

属性信息变换规则定义单元，其对每个请求侧属性名定义了对属性值的形式进行变换的属性信息变换规则；

属性信息变换单元，其根据所述属性信息变换规则，变换从所述请求取得的属性信息内的属性值的形式。

Images