由mashup所想到的.....

   (语次有些混乱，见谅....)
   最近正在参与公司的一个改造项目，页面展示使用的是mashup，后台使用服务调用的方式。较之之前做的一个使用restlet开发的lbs项目，觉得还是有蛮多想说。

   公司由小做到大，都会经过系统的由小到大的膨胀。最初使用以jsp或者改进的mvc框架开发，感觉挺得心应手的。

   后来，业务变多，系统变得复杂，重复的或者类重复的内容或功能增加。比如修改用户基本信息和修改用户的时候，首先都要查询用户信息，以供展示，同样的业务功能需要被多次封装，很浪费是吧？
   对于公司内部的crm更是如此，所有的功能无非是信息的查询展示和信息的修改，只不过他们可能调用相同或不同的系统服务，操作相同或不同的数据库。比如，现在有两个页面：详细信息展示页面和用户基本信息修改页面，两个看似风马牛不相及的功能，却使用了会员系统相同的功能——查询用户的基本信息(详细信息展示页面，会同市查基本信息和一些其他相关信息；基本信息修改页面首先需要查询基本信息显示在页面)。在我们公司，用户有着举足轻重的地位，会员信息的管理更是非常复杂，这时候功能的重复使用和没有有效的包装的问题显得更为严重。到了需要重构的时候了。

   怎么重构，我们待会儿再说。首先说说restful这个东东吧。以前用过restlet框架，总感觉自己理解了，却又有写说不上来，今天在Google reader上看了一篇文章 http://www.udpwork.com/item/5785.html，将得挺好的 "长期以来，软件研究主要关注软件设计的分类、设计方法的演化，很少客观地评估不同的设计选择对系统行为的影响。而相反地，网络研究主要关注系统之间通信行为的细节、如何改进特定通信机制的表现，常常忽视了一个事实，那就是改变应用程序的互动风格比改变互动协议，对整体表现有更大的影响。"。restful本身是在改变浏览器和服务器之间的互动风格。每一个URI代表一种资源；客户端和服务器之间，传递这种资源的某种表现层；客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
   其实，对于对于客户端来说，他不需要知道资源是什么东东，html文件也好，二进制文件也行，他只需要如何获取想要的资源就行。
  
   mashup本身并不是什么计算机技术，是当今网络上新出现的一种网络现象,将两种以上使用公共或者私有数据库的web应用，加在一起，形成一个整合应用。由于业务的需要——在一个页面同时展示许多的功能点——公司自己实现了以一套框架(具体怎么实现的，保密)。对滴，这正是在解决前面如果重构的问题，一旦能够做到将资源的展示，和资源的来源分离，就可以形成一种类c/s的开发模式，展示层和业务层使用服务调用的方式，有点restful的感觉吧。唯一不同的是，获得的资源本身是资源的某种形式，如流，但mashup有自己的展示层，对数据重新展示到页面，而没有关注资源的展示形式。

   公司也确实采用类似这种方式，A系统的用户详情页面可能需要用到/users/{id}这个资源，B系统的修改用户信息页面也要用到/users/{id}这个资源，我们可以把A系统分成多个资源的请求，其中有一个就是/users/{id}这个资源，服务需要的只是提供资源就行。

   但是现在问题出来了：原有系统之间的调用关系大量的采用了链接的方式，这也是最方便的方式，但是本质上是在是展示层之间功能更加耦合，当需要功能变迁，或页面迁移的时候，需要找到所有链接到该页面的所有页面，然后逐一修改，这样还不能保证不出问题。该怎么办？

   有两种办法：1.继续使用链接的方式；2.采用复制展示层的方式，每个系统copy一份自己的展示层，调用同一个服务。第一种方式是目前采用的，改动和需要的系统资源最少；第二种方式其实能解决问题，但是牵扯的要改动的系统太多，难实现，同时代码太过臃肿。其实我个人比较赞同后者，因为这样能够真正的发挥mashup的优势，并且让系统之间的耦合降低。

  悲剧，自己像是没有说清楚。