接下来我们讨论三种常见的、以数据为中心的服务：会话、登录与镜像。

会话这一服务，是将数据理解为公共数据与状态。通过会话来形成事务是一种常见的策略，但其可靠性是受置疑的。例如我们可以将用户在Web上的一次交易，看做是一个有着松散的事务关系的过程，从选择商品、下单、确认、支付以及转入到发货环节。这在整体上有着工作流的特点，在部分结点上有着事务性的要求。在这样的背景下，我们要求从选择商品开始建立一个会话，并在其后的行为中基于会话来实现处理逻辑。

将会话作为一个“状态”其实是非常危险的，因为Web交易中不可避免地会发生用户刷新页面导致的重复提交。因此，在同一个状态上出现两个等待逻辑的状况就会出现，若这种逻辑又正好是在事务型的结点上，例如支付，那么该怎么办呢?在稍小一些的系统中，由于相关的领域和应用结点不是非常多，因而我们还有能力应付交叉逻辑中的种种锁关系。但如果系统的规模相当大，应用逻辑相当复杂，那我们就必须回到最原初的设定上进行重新思考：会话，是否应当将数据作为状态?在此前我们讲到过，一个能保证确定性的“数据全集x”必须是{x',x",S}整个集合，其中的S,就是状态。将会话数据作为状态是典型的{x',S,}集合，因此它表现为数据确定而逻辑(x")可变。我们之所以会在逻辑中出现锁关系，便是因为逻辑对S①我们讨论过，这正是函数式语言的优势——将逻辑作为可迁移对象通常是基于运行机制来保障的、具有逻辑自身的不知觉性，而命令式语言则难于实现这一点。但看起来，我们在这里所面临的又似乎是典型的“数据不变”的系统环境。所以语言范式之于系统模型，是两种语境。

产生了依赖(而非对x'产生依赖)。因而将“状态(S)"这一性质从“会话数据”中抽离是我们必然面临的问题。

一个可选的策略是加入消息服务。这基本上借鉴自语言设计中对并发的处理，例如在Pascal/Delphi系列中采用的共享状态模型，以及在Erlang中采用的消息传送模型。图3-20说明相关语言特性的演化①:共享状态模型+状态命令式编程Pascal/C+线程状态共享的并发编程Pascal/C数据+逻辑一阶函数式编程事件循环编程E(in one vat)+端口(消息传递)+线程基于消息传送的并发编程Erlang消息传送模型图3-20 两种可选可替代的并发模型：共享状态模型与消息传递模型这说明共享状态模型与消息传送模型是可以相互替代的。具体来说，如果我们试图从会话中抽取掉状态，则应该考虑在多个任务(task)中“有效地传递或限制传递”这一状态(S,),而不是将S,放到另一个数据结点中去。后面这种策略，以及之前提到的会话服务事实上都是因为S,的存在而形成了数据单点。

当我们加入消息服务M之后(消息本身的“数据性质”中并不包括S,并且也不包括逻辑x"),任务Tj,…,T,之间便只因为“共享了会话数据”而变成相同的n个任务。当它们的“修改状态”请求被投送给M之后，M的端口(或其他消息限制策略)将请求的消息信息队列化，进而将状态S中的时序信息拿掉②,因而在具体的、在消息服务M中的、有关消息响应的逻辑中，就不必再处理时序信息了。yipindushu.com

在消息服务M中是否使用同一个会话数据作为上下文，是消息模型中的一个可选策略。这可以表达为对“(确定数据下的)PD模型”的两种不同理解，

①该图是对Peter Van Roy的“主要编程范式”一图中部分内容的重新表达。参见：www.info.ucl.ac.bel~pvr/paradigms.html②从概念上来说，数据全集x包括指示它自身的状态S;也就是说，S,是x之于时间的信息。

在解释1中，认为逻辑Pn通过确定数据之后，得到的是一个包括数据映像的新逻辑Pn'。在这种情况下，新逻辑是可以基于数据映像进一步求值的。这一思路可以理解为缓存，即在一个存储上加上IO逻辑。当通过IO逻辑得到数据时，我们并不关注数据是原始的确定数据，还是这一数据的一个映像，并且事实上我们也不关心映像与确定数据之间的同步问题，这是IO逻辑之下的服务层的责任。解释2则认为逻辑通过确定数据之后，得到的是可以用作后续计算的数据。因此，这一思路可以理解为函数连续调用，也是函数式语言的一个基本范式。

【这两种模型都可以解释“消息服务M中是否使用同一个会话数据作为上下文”①:】

对于解释1,要求会话数据是通过一个存取界面得到的；对于解释2,要求会话数据是在消息M的处理逻辑中自行持有的(例如可以队列化、加锁，或使用类似闭包的方式得到一个映像)。