瞎想：我该把逻辑层放到哪里

[这里我们讨论的是Mobile设备上的信息系统逻辑层的问题]
最近在看一些关于 WebSphere Everyplace Access的资料，这是一个非常优秀的软件，针对移动设备提供了中间件的功能。它作到了一些别人没有作到的东西，其中一个很有意思的功能是脱机的protlet。说简单一点，就是在移动设备脱机时，可以将protlet保存在浏览器的高速缓存中，保证在没有网络连接的情况下用户可以继续使用。而且在最新的V5版本中，还增加了脱机提交表单的功能，用户可以在脱机状态下提交表单，等网络再次连接时，请求才会被发送到Server中。
说实话，尽管我不是做Java开发或者WebSphere开发的，但是看完这个软件的介绍，它却引发了我对心里长久存在的一个疑问的思考：“我该把逻辑层放到哪里？”

逻辑层是什么

UI层、逻辑层和数据层，已经成为我们对软件逻辑划分的标准模式。我的理解，逻辑层是将UI层的请求转换为对业务逻辑的操作，最后反应到数据层中去，只所以要增加这一层，目的有二：
1）在面向对象的情景下，封装逻辑层可以更直观地将业务逻辑体现到软件结构中；
2）业务逻辑是随时变化的，封装该层有助于将来程序的维护。
好了，逻辑层是必须的，但放在哪里呢？引发这个思考的原因其实是：网络。有了网络，才可以让我们部署大规模的分布式系统，才有了SOA的概念。其实有了SOA的概念后，逻辑层放哪里的问题应该迎刃而解了，放到Web Service中啊！没错，对于普通的LOB系统，放在Web Service里是最佳的解决方案。
可是Mobile设备上的系统很特殊，特殊的原因也是网络。Mobile设备大多运行在间断的网络连接下，不能像普通的PC那样随时可以访问网络上的资源。让Mobile设备的用户在有网络的情况下才能够使用软件，这显然是不可接受的。

我们的传统

目前最“传统”的做法是，将UI层、逻辑层、数据层一起放在设备上，因为有SQL Mobile数据库的支持，我们可以将数据存放其中，然后在有网络的情况下，再让SQL Mobile数据库与远程SQL Server数据库进行数据同步。这就是所谓的胖客户端方案，将一切都放在设备上，远程服务器只起到一个数据存储的作用。最近微软推出的一个“ Mobile Line of Business Solution Accelerator”中采取的就是这种形式。
不过在IT这个行业，“传统”往往不是个什么好词。现在，中间件越来越多，Web Service已经开始占据主导地位，SOA的趋势将不可逆转，我们不可能让Mobile应用徘徊在这个趋势之外。而且胖客户端的缺点也显而易见：
1）    不适应大规模企业级部署，软件更新的成本将十分巨大；
2）    无法适应随时变化的业务逻辑；
3）    所有的数据验证工作都在客户端进行，数据冲突的问题只能依赖数据库进行解决，可能造成复杂业务数据的混乱。
好了，胖客户端的批判就到这里，那么传统的瘦客户端（B/S）解决不了网络间断的问题。WebSphere Everyplace Access为我们提供了一个基于瘦客户端的解决方案，将业务逻辑通过缓存的方式保存到设备端。我前边说过了，这是款优秀的软件，但是这个方案也不是没有它的问题：（下面的话是基于我对WebSphere Everyplace Access的浅薄理解，恳请高手的指正）这个问题来源于数据，脱机portlet解决了UI层（Web）和逻辑层（portlet）的问题，但是没有解决数据层的问题。我不知道portlet是否可以访问DB2 Everyplace，但是从目前的资料来看，即使可以，恐怕也是件很难的事情（这个问题我不确定，欢迎大家指教）。那么我们可以容忍表单的延迟提交，但是对于一些针对数据库的查询，我们也需要等到网络连接之后才能获得结果吗？这个问题也许将来会解决的，但至少目前看起来WebSphere Everyplace Access基于瘦客户端的解决方案也是存在一定问题的。

我们的问题

现在想起来真是有点乱了，我们回到最根本的问题：“我该把逻辑层放到哪里？”，但是这个问题加了很多条件限制：
1）    可以方便地操作Web Service中的业务逻辑
2）    能够方便地更新客户端的业务逻辑
3）    在离线状态下，仍然可以完成数据查询的任务
好了，这就已经够复杂了。目前看起来，我们要依靠Web Service中的业务逻辑层（因为Web Service中的业务逻辑也要支持其他的Client），但是又需要在离线状态下，使Web Service中的业务逻辑仍然可用。哦，我们也不能忽略数据的问题，Web Service中的业务逻辑访问的是后台数据库，而设备端的业务逻辑要访问的是本地的数据缓存。
事情越来越复杂了，既然瘦客户端存在问题，那么我们试试胖客户端是不是可以通过减肥的方式来完成一些工作呢？比如：
1）    在设备端增加一个Proxy类，当网络可用时，直接通过Web Service来进行操作；网络不可用时，分两种情况：对于操作，我们进行缓存当网络再次连接时，我们将操作提交到Web Service中去；对于查询，直接查询本地的数据缓存。这样做缺点很明显，客户端数据与Server数据不同步。
2）    再有的办法就是像Protlet那样，将包括逻辑层的程序集从Web Service下载到客户端，这样就能够保证业务逻辑的一致性。本地所有的操作都是使用本地的业务逻辑，将结果保存到本地数据缓存中，再与远程数据库进行数据同步。这样做的问题是：Web Service的业务逻辑程序集会有安全性的风险，而且同步也是说起来容易做起来难，如果程序集改变了，而设备端使用了原来的程序集进行处理，数据不会有问题吗？
如此说起来，这个问题真的没什么好的解决方法。逻辑层是为了不暴露数据，但是偏偏移动设备需要对数据进行缓存，于是逻辑层就变成了一个很尴尬的角色，恨不得学会分身术。可是逻辑层如果真得分身了，那么危害是不是比存在于设备端更大？
看来我们需要等待一个天才想法的出现了……