CN101193089B

CN101193089B - 有状态会话系统及其实现方法

Info

Publication number: CN101193089B
Application number: CN2006101403128A
Authority: CN
Inventors: 姚建东
Original assignee: Alibaba Group Holding Ltd
Current assignee: Advanced New Technologies Co Ltd
Priority date: 2006-11-20
Filing date: 2006-11-20
Publication date: 2010-11-03
Anticipated expiration: 2026-11-20
Also published as: CN101193089A; HK1117309A1

Abstract

本发明公开了一种有状态会话系统，包括服务器端与客户端，服务器端设置有SOA服务器，客户端设置有session管理工具包；SOA服务器，用于在接收到客户端发送的用户登录请求时返回用户安全信息、并对session管理工具包提供的用户安全信息进行验证；session管理工具包，用于接收SOA服务器提供的用户安全信息，还用于在请求服务时将用户安全信息递交给SOA服务器验证；还包括存储单元，用于存储用户安全信息。由于session保存在客户端，使服务器端得到解放，从而提高了服务器的资源利用率，降低了硬件投入；且可方便实现跨越服务器服务，降低了对应用服务器的要求，实施难度低。本发明还公开了一种实现有状态会话的方法。

Description

有状态会话系统及其实现方法

技术领域

本发明涉及网络通信技术领域，尤其涉及一种有状态会话系统及其实现方法。

背景技术

会话(session)可以分为有状态和无状态，有状态会话可以在客户访问之间保存数据。在如今WEB(网络)蓬勃发展的时代，session在WEB开发语境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的解决方案。

网络协议HTTP(Hyper Text Transfer Protocol，超文件传输协议)采取无状态访问，所以为了实现有状态的服务，在客户端发出有状态服务请求时，WEB服务器通过“session+cookie”来提供有状态的服务。如图1所示，是目前常用的有状态会话解决方案示意图，WEB服务器为发送请求的客户端创建一个session，并在客户端暂时存放一个能够识别客户端的文本文件cookie，通过调用应用程序，实现和WEB浏览器进行有状态信息交互。

在如图1所示的有状态会话解决方案中，当服务器服务能力不足时，常用的方法有以下几种：

①增加新的WEB服务器：这种方式的前提是所有服务器部署相同的服务；并且需要高的可靠性，也就是在一台服务器不能提供服务时，所有服务应该能够转移到新的服务器上，这种方式往往通过session复制或者内存复制来实现；

②应用分置：按照用例把服务部署在不同的服务器上，这种方式可由路由器提供的session管理、或者也可由session复制来提升容量；

③提升服务器处理能力：例如将服务器更换为处理能力强大的大型机等。

但是，上述三种方法存在以下缺点或困难：

(1)硬件成本投入高，或者硬件资源浪费严重：例如方法①、②都需要增加新的服务器，而方法③采用的大型机价格不菲，而且对于大型机不能完全利用，造成资源浪费；

(2)部署模型复杂，带来高的管理成本、维护成本和运营成本：特别是方法①、②，规模庞大，不利于管理和节约成本；

(3)技术复杂，需要高的技术投入成本；

(4)随着网站数量的增多，难度成指数增加，维护成本也非常高。

可见，对于高PV(page view，页面浏览量)、高并发的网站来说，现有的有状态会话方案束缚了系统的扩展能力。

而且，在实现跨网站的业务流程时，实现难度非常大。例如用户在A网站买了书，在B网站买了手机，又在C网站提供的支付服务上付款，这就需要用户在实际付款前要能够在任何一个网站上方便看到自己的订单。但是，由于A、B和C网站的session不可能同步，要实现这样的业务，存在很大难度，投入的技术和人力代价也非常高。

发明内容

本发明的目的是提供一种有状态会话系统及其实现方法，以解决目前有状态会话方案中服务能力有限的问题。

为此，本发明采用如下技术方案：

一种有状态会话系统，包括服务器端与客户端，所述服务器端设置有面向服务的体系结构服务器，所述客户端设置有会话管理工具包；所述面向服务的体系结构服务器，用于在接收到客户端发送的用户登录请求时返回用户安全信息，并对会话管理工具包提供的用户安全信息进行验证；所述会话管理工具包，包括服务器接口单元，用于接收所述面向服务的体系结构服务器提供的用户安全信息，还用于在请求服务时将所述用户安全信息递交给面向服务的体系结构服务器验证；还包括存储单元，用于存储所述用户安全信息。

所述存储单元还包括为不同服务器端建立的不同会话记录文件，通过不同会话记录文件对不同服务器端的信息进行交换。

所述会话管理工具包还包括过期管理单元，用于设置会话记录文件生存时间，并在会话记录文件超过生存时间时，删除会话记录文件。

所述会话管理工具包还包括安全管理单元，用于对会话记录进行加密管理。

所述会话管理工具包由客户端中的插件实现会话功能，或者由javascript与cookie方式实现会话功能。

一种实现有状态会话的方法，包括步骤：在服务器端构建面向服务的体系结构服务器，在客户端构建会话管理工具包；面向服务的体系结构服务器端接收容户端发送的用户登录请求后返回用户安全信息，客户端通过调用所述会话管理工具包，将所述用户安全信息存储在客户端会话管理工具包中；会话管理工具包向面向服务的体系结构服务器提供用户安全信息，面向服务的体系结构服务器验证通过后，为客户端提供服务。

所述方法还包括：会话管理工具包为不同服务器端建立不同的会话记录文件，当用户请求不同服务器端提供服务时，会话管理工具包通过不同会话记录文件对不同服务器端交换信息。

所述客户端调用会话管理工具包存储用户安全信息的过程包括：客户端设置应用编程接口；利用应用编程接口将服务器端返回的信息存放到会话记录文件中。

所述方法还包括：对服务器端与客户端间交互的信息采用DES加密算法加密。

所述方法还包括：当会话记录文件超过预设的生存周期时，所述会话管理工具包删除所述会话记录文件。

本发明采用上述技术方案，带来很多有益技术效果，比如：

(1)现有解决方案中，服务器保留session数据占用服务器资源，限制服务器的服务能力，而且session采用文件存储的方式，也导致服务器性能下降；而本发明中服务器端不需要保留session，可以得到高的资源利用率，降低了硬件投入；

(2)session保存在客户端，可以方便的实现跨越服务器，甚至不同服务商提供的服务，不需要象现有技术那样采用群集、session复制等复杂技术，同时，也降低了对应用服务器的要求，实施难度低；

(3)本发明采用成熟的SOA(Service-Oriented Architecture，面向服务的体系结构)服务器，很容易利用现有免费的HTTP服务器实现，降低了实现难度，从而使普通的服务商都能够提供大容量的服务。

附图说明

图1为现有技术有状态会话方案示意图；

图2为本发明有状态会话方案示意图；

图3为本发明有状态会话系统示意图；

图4为本发明有状态会话方案流程图；

图5为本发明通讯协议消息头扩展示意图

图6为本发明实施例流程图；

图7为本发明实施例服务器部署示意图。

具体实施方式

本发明有状态会话的实现方案，采用客户端异步技术和SOA架构思想，采用反传统的思路，在服务器端不保留session记录(以下简称session)，由客户端来负责session的处理，服务器端只负责计算和提供服务。

如图2所示，为本发明有状态会话方案示意图，采用客户端异步技术，将session保存在客户端，并在服务器端部署SOA服务器，用户WEB浏览器上仍保存cookie，通过本地调用session，实现有状态会话。WEB服务器提供传统的IITML(Hypertext Marked Language，超文本标记语言)、图片等服务功能，SOA服务器提供计算服务，也可以通过增加UI服务来扩展SOA服务器，使其提供HTML和图片等传统的数据处理功能。

SOA是一个组建模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。本发明中更多的是指SOA架构思想，而不是具体的一项技术。本发明中，SOA服务器提供两种标准服务：一种是安区服务：当用户第一次登录时，提供客户端到服务器端的安区验证，验证的方式可以是简单的用户名/密码方式，也可以是基于证书的验证；验证通过后、返回安全身份证，提供客户端在session中保存。当用户访问本服务器或其它服务器时，通过安全检查服务确定用户身份是否有效。另一种是服务查询/定位服务：SOA服务器提供服务查询服务，供客户端查询服务的有效性。如果该服务无效，SOA服务器在自身可能的范围内提供定位服务，辅助客户端找到正确的服务提供商。

客户端session实现策略有两种：一种是，通过Javascript+cookie方式存储数据，同时利用cookie过期概念实现session过期机制；另一种是，通过客户端插件技术实现，由插件实现所有客户端session功能，供Javascript调用。比较之下，前者在现有技术基础上就能实现，不需要额外的技术，但是对于复杂的对象模型，必须要提供一套序列化机制，对象无法缓存(cache)，而且实现数据安全共享策略时难度较大；而后者能够提供强大的session管理功能，是优选方式。

如图3所示，本发明提供的有状态会话系统包括服务器端301和客户端302，可以部署多个服务器端301。服务器端301设置有SOA服务器311，客户端302设置有session管理工具包312；

SOA服务器311，用于在接收到客户端302发送的用户登录请求时返回用户安全信息，并对session管理工具包312提供的用户安全信息进行验证；

session管理工具包312包括服务器接口单元321，用于接收SOA服务器311提供的用户安全信息，还用于在请求服务时将用户安全信息递交给面SOA服务器311验证；；还包括存储单元322，用于存储用户安全信息；优选地，存储单元322还包括多个会话记录文件331，用于为不同服务器端301建立不同的session，并通过不同session对不同服务器端301的信息进行交换。session管理工具包312还包括过期管理单元323，用于设置会话记录文件331生存时间，并在会话记录文件331超过生存时间时，负责删除会话记录文件331；还包括安全管理单元324，用于对session进行加密管理，例如采用DES(DataEncryption Standard)加密算法加密。

实现本发明有状态会话，首先要搭建整个方案的实施环境。如图4所示，搭建有状态会话环境包括：

步骤401：构建SOA服务器311；

而构建SOA服务器311又包括如下子步骤：

步骤411：开发HTTP/TCP传输服务；

步骤412：开发SOA服务管理/配置服务；

步骤413：开发SOA服务查询/定位服务；

步骤414：开发标准协议打包/解包服务；

步骤415：开发客户端session转换服务；

步骤416：开发安全管理服务；

步骤417：开发可选的辅助服务，例如HTTP协议支持服务、提供静态资源服务等。

步骤402：构建客户端session管理工具包312。

构建客户端session管理工具312又包括如下子步骤：

步骤421：开发标准协议打包/解包工具包；

步骤422：开发session管理工具包；

步骤423：开发SOA服务传输工具包；

步骤424：开发客户端安全工具包；

步骤425：开发可选工具包，例如，数据与样式格式化工具包、提供包数据通过样式转换为HTML标准显示等。

在实施上述步骤时，需要遵循以下A和B两个标准：

A.标准的协议打包格式

其中，又有两种选择：

1)采用业界标准的SOAP(Simple Access Protocol，简单对象访问协议)1.2版本，作为基础打包规范，扩展SOAP消息头增加session、以及上下文方面的标准格式。

2)采用简化版本的打包规范，该规范支持消息头宽展，因此增加session、上下文方面的标准格式即可。

如图5所示，每个消息头Message包含一个Body对象，它可以包含1至N(N为大于1的整数)个Header对象，Body可以包含0到N个Attachment(附件)对象。消息头部分允许为空，所有扩展消息头都包含在父元素Hcader中；消息正文部分运行是任何结构的XML(Extensible Markup Language，可扩展的标记语言)数据。

B.标准的协议绑定格式

标准的协议绑定格式，尤其是指协议与TCP(Transfer Control Protocol，传输控制协议)/TCPS/HTTPS的绑定。绑定时，需要遵循一个原则：服务器端301能够判断客户端302使用哪种传输协议。例如，可采用的协议类型包括soa/soap+xml(The Extensible Markup Language，可扩展标识语言)、soa/xml或soa/html。

而且，可以依据需求对安全、session和错误处理这三部分进行扩展：

安全扩展：提供客户端302与服务器端301，以及跨服务器端301、跨网站的安全策略。

Session扩展：客户端302与服务器端301交互时，提供上下文信息，供服务器端301使用。

错误扩展：客户端302与服务器端301交互时，服务器端301返回的错误信息采用HTTP协议规定的错误代码。

除了要遵循以上A和B两个标准之外，在实施过程中，还需要注意以下几个方面：

①服务器端301把数据存入客户端302

为了在客户端302创建session管理工具，需要客户端302提供方便的API(Application Programming Interface，应用编程接口)函数，以便于把服务器端301返回的数据放人session中。服务器端301在请求返回时，会将需要存储在session中的数据一并提交，返回客户端302，客户端302在接到该数据后，按照session语义把数据存入客户端302。

②服务器端301与客户端302交互的基础

客户端302与服务器端301对通信协议的支持必须一致，否则无法进行数据交互。

③服务器端301与客户端302安全交互的基础

采用通用的安全标准保证服务器和客户端的交互安全，例如，采用DES加密算法。

④客户端302把session数据传递到服务器端301

客户端302把session传递到服务器端301有两种方式：

第一种是把session中的所有数据打包提供给服务器端301；

第二种是按照需要发送，客户端302在提交之前，把服务器端301需要的数据从session中取出，打包发送。

相比而言，第二种方式效率高、传输数据量少。

⑤客户端302中session的功能与实现

实现有状态会话期间，客户端302保存的session需要具有以下功能：

a.提供set/get/remove功能；

b.提供session过期管理机制：在session超过预设的生存周期时将其删除；

c.提供session域管理功能：当用户访问不同网站时，不同的服务器能够建立自己的session域，从而防止session的混乱；

d.提供session中数据安全共享策略：当从一个域跨越另一个域时，能够方便地通过session交还数据，构建跨不同网站的业务流，此处网站至不同服务商提供的不同、带有UI(User Interface，用户与界面)的服务功能集合。

下面以两个具体例子介绍客户端302中Session的实现：

I、基于不同客户端302(浏览器、非浏览器)开发插件，插件以C++编程语言为开发环境，提供数据存储功能，定时器功能；在这两个功能基础上，提供Session管理功能。

II、在HTML页面中使用

定义一个Session对象

<OBJECTID＝″sessionManager″

CLASSID＝″CLSID:8AD9C840-044E-11d1-B3E9-00805F499D93″/>

通过Javascript调用

function calculate(){

documcnt..sessionManager.getSession()

}

</SCRIPT>

在构建会话环境之后，可以在客户端302与服务器端301实现有状态会话。概括而言，本发明的实现有状态会话的过程包括以下步骤：

(1)服务器端301构建SOA服务器311，在客户端302构建会话session管理工具包312，从而完成构建整个会话环境；

(2)SOA服务器311端接收客户端302发送的用户登录请求后返回用户安全信息，客户端302通过调用所述session管理工具包312，将用户安全信息存储在客户端302session中；

(3)客户端302请求SOA服务器311提供服务，SOA服务器311对session提供的安全信息验证通过后，为客户端302提供服务。

下面以一个具体应用实例来阐述本发明提供的有状态会话方案。此实例的应用背景是：用户在A网站订阅书籍，在B网站预付费，A、B两个网站分别由不同运营商提供，并都设置SOA服务器；且由于用户量比较大，A网站需要3台服务器提供服务。

此应用实例涉及A、B两个网站，以此来说明跨session域实现信息交互的过程。如图6所示，此应用实施例包括：

步骤601：客户端调用SOA服务器登录A网站服务；

步骤602：客户端调用本地session管理工具包，将用户安全信息存储在客户端session中；

步骤603：客户端调用A网站SOA服务器预订书籍服务；

步骤604：客户端调用SOA服务器预付费服务；

步骤605：通过客户端session管理工具包，把服务转发到B网站预付费服务，同时对客户端提供的安全信息进行验证；

步骤605：预付费成功，B网站SOA服务器在客户端session标记；

步骤607：通过客户端session管理工具包，将服务转发到A网站书籍订阅服务；

步骤608：A网站验证客户端session传来的数据，确认后通知客户端。

A网站服务器与B网站服务器在交换数据时，是通过客户端session来进行的，这样在用户与A、B来回交互的过程中，就比较方便，而且避免了服务器之间的大量数据交互。

如图7所示，为A网站服务器部署示意图，通过负载平衡设备将服务器a、b、c连接，这样就不需要在服务器之间作群集，每台服务器上设置SOA服务器，设置的服务也是相同的。当用户正常访问时，由负载均衡设备把访问信息分发到不同的服务器上，当一台服务器死机或停止服务时，用户的交互并不会中断，因为此时与该用户的session都在客户端上，只需负载均衡设备将交互信息发给另外一台服务器进行交互即可。

可见，由于服务器不需要群集，session不需要复制，对应用服务器(SOA服务器)要求低，实施难度低；由于服务器不保留大量客户session数据，避免了由此导致的性能下降的问题，减轻了服务器的计算负担；而且，采用负载均衡设备能够实现服务器之间的切换无缝进行，用户的信息交互不会受到影响。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims

1.一种有状态会话系统，包括服务器端与客户端，其特征在于，所述服务器端设置有面向服务的体系结构服务器，所述客户端设置有会话管理工具包；

所述面向服务的体系结构服务器，用于在接收到客户端发送的用户登录请求时返回用户安全信息，并对会话管理工具包提供的用户安全信息进行验证；

所述会话管理工具包，包括服务器接口单元，用于接收所述面向服务的体系结构服务器提供的用户安全信息，还用于在请求服务时将所述用户安全信息递交给面向服务的体系结构服务器验证；还包括存储单元，用于存储所述用户安全信息，还用于为不同服务器端建立的不同会话记录文件，通过不同会话记录文件对不同服务器端的信息进行交换。

2.根据权利要求1所述的有状态会话系统，其特征在于，所述会话管理工具包还包括过期管理单元，

用于设置会话记录文件生存时间，并在会话记录文件超过生存时间时，删除会话记录文件。

3.根据权利要求1所述的有状态会话系统，其特征在于，所述会话管理工具包还包括安全管理单元，

用于对会话记录进行加密管理。

4.根据权利要求1至3任一项所述的有状态会话系统，其特征在于，所述会话管理工具包由客户端中的插件实现会话功能，或者由javascript与cookie方式实现会话功能。

5.一种实现有状态会话的方法，其特征在于包括：

在服务器端构建面向服务的体系结构服务器，在客户端构建会话管理工具包；

面向服务的体系结构服务器端接收客户端发送的用户登录请求后返回用户安全信息，客户端通过调用所述会话管理工具包，将所述用户安全信息存储在客户端会话管理工具包中；

会话管理工具包向面向服务的体系结构服务器提供用户安全信息，面向服务的体系结构服务器验证通过后，为客户端提供服务；

会话管理工具包为不同服务器端建立不同的会话记录文件，当用户请求不同服务器端提供服务时，会话管理工具包通过不同会话记录文件对不同服务器端交换信息。

6.根据权利要求5所述的实现有状态会话的方法，其特征在于，所述客户端调用会话管理工具包存储用户安全信息的过程包括：

客户端设置应用编程接口；

利用应用编程接口将服务器端返回的信息存放到会话记录文件中。

7.根据权利要求6所述的实现有状态会话的方法，其特征在于，所述方法还包括：

对服务器端与客户端间交互的信息采用DES加密算法加密。

8.根据权利要求7所述的实现有状态会话的方法，其特征在于，所述方法还包括：

当会话记录文件超过预设的生存周期时，所述会话管理工具包删除所述会话记录文件。