Session 共享探讨

Session在不同架构中其实现机制也有所区别。详细内容可以到相应技术网站去查询，在此不再一一说明。那么在不同的架构中都有哪些方法去共享公共Session？对于这个问题可以有很多种方案，在此主要以最常用的几种方案来比较。

第一种：获取方式（B Get from A）

这种方式一般通过URL的Get方式（URL后边使用加密后的字符串参数传递）实现。该方式有很多优点，最主要的是它实现方便。一般实现方法如下：

在这种方式中Session Adapter文件通过解密读取URL传递的加密字符串参数后先生成该架构的Session后转到相应Request的页面中。

这种方式虽然实现简单但又很大的安全风险。最主要的是在系统连接中很容易暴露系统Session对象和传入的内容，这是很致命的缺陷。而且传递参数的容量有限，无法传递长字符串内容；语言的兼容性差，因很多情况不支持Unicode而无法传递中文或韩文等非字母语系语言内容或需要转换程序提供相应的语言支持。

第二种：缓存方式（A Write Cookies then B Read Cookies）

这种方式实现的前提是Cookie的数据结构完全相同。还好自从WWW开创以来到现在Cookie的数据结构一直保持其通用性，所以这种方式就具备了实现的条件。如图：

 

这种方式也是具备实现简单的优点且比起URL Get方式提高了其数据隐蔽性和数据容量限制。但因为它是用Cookies的缘故安全性很低（很多黑客光顾网站式系统的主要通道就是Cookies）。而且在系统间的无缝连接也会出现很大的问题，这是因为Cookies将数据储存于客户机的Internet缓存中，如果客户机不启用Cookies缓存机制则无法正常生成后者的Session。

第三种：赋予方式（A Post to B）

这种方式的实现理念是将Session转化为页面的隐藏控件后将其内容Post到第二个系统结构中后在生成相应的Session值。如下图所示：

这种方式就像每一个系统架构中设置一道关口，数据都是通过此关口通过。在实现上它虽然没有像URL Get方式简单但比起Cookies方式购具备程序的可读性。在安全性方面数据均存在于服务器，所以它是安全的。而在系统间无缝连接方面，他承接了流水线式的数据传输和页面转换。而且可传递的数据容量方面也得到了尽可能的扩展。

各种共享方式有各自的优点和缺点，根据系统的特性系统架构设计人员应判定如何去选择系统间共享Session。