关于系统集成的一些想法
最近在罗马尼亚做需求调研，发现用户在日常工作中，需要频繁从10个系统查看数据，辅助决策。于是就想是否有可能做一个信息聚合的系统，让用户不需要频繁地“切换”和“根据关键字检索”。今天晚饭时和同事讨论了一下，有一些零碎的想法，在此记录
我认为这里有2个层面的问题，第一个层面是集成，第二个层面是信息搜索。分别对应用户的2个动作：“切换”、“检索”
集成
问题的本质在于，这个新系统（下文简称A），需要和现有的10个系统集成起来（老系统是处于“被集成”的位置）。归纳起来，我认为一个系统是否容易“被集成”，可以分为3个层次：
通过URL集成
第一种情况是，系统对外提供的是完整的界面，即“展现层的接口”。比如输入一个www.somesystem.com/sla/aug，某系统返回一个完整的页面。那么如果A要集成这个系统，就直接将这个页面嵌入到自己的界面中；或者发送一个指令如“kpi=sla/aug”，某系统返回一个完整的flash。那么A也可以直接把这个flash嵌入自己的界面
这种情况在老的B/S应用中是比较常见的，在C/S应用中非常少见。难点在于一般都有鉴权机制，所以需要解决SSO的问题。
业务层接口调用
第二种情况是，系统对外提供只是数据片段，即“业务层的查询接口”。基本上所有的C/S架构应用都是这样的，比如在dota中潇洒地补刀，补刀了一个投石车，得到了70金币。server传给war3 client的只是类似“hit=yes;gold=+70;unit=destroy”的数据片段，而不是把整个补刀的动画传过来，动画是根据这些数据，在客户端上计算得到的
问题在于，对于大部分的C/S应用，这个接口并不开放。也就是说我想要得到上面的“hit=yes;gold=+70;unit=destroy”数据，唯一的办法就是打开客户端，然后认认真真地补中一辆投石车（好吧，这也不是很难），很难通过写代码的方式来模拟这个事情。
我们以前做过的一个系统，就是这种形式，通过www.company.com/workorder/username这个链接，返回某用户的工单数据。浏览器拿到数据以后，刷新DOM元素；而android终端拿到数据以后，刷新手机界面。这个接口，就是典型的业务层接口，无分B/S还是C/S
数据层接口
第三种情况是，系统将数据直接通过接口暴露出来，要什么就自己取。这个比较难举出例子，毕竟很少见。欧洲有些厂商的IT整体架构就是这样，底层是一个数据仓库，然后暴露了一堆查询接口。上层的应用系统是按需定制开发的，可能一个系统取了123数据来展示；另一个系统取了456数据来展示
这里的数据仓库，可以有多种形式，可能就是一个标准的RDBMS，开放了一个SQL接口；也有可能是加了一层很薄的接口，看起来类似第二种情况，但是可以更有效地做日志、权限控制、防SQL注入等。主要的问题是能否取得访问数据源的权限
对比
第一种方式最为省事，因为封装得最彻底最粗粒度。A要集成这种系统很简单，但是要做定制则非常难。比如对方系统提供了一个页面，如果我们只想直接复用，那就最好。但是如果我们只想要页面里3个字段的2个，那么就需要修改这个页面，比如加参数
第二种方式只提供数据，封装程度比较弱，细粒度，就给A的定制提供了更多的可能。但是相对的，A在界面开发上就需要更多的工作量
第三种方式则更彻底，没有任何封装，相对的就连业务规则也没有了。A想要什么就取什么，相对地工作量也就最大，某种程度上算是新开发一个系统，也谈不上什么集成了
从我来看，第一种方式封装过度，客户端的自由度太小；而第三种方式的粒度又太细，定制工作量太大，也缺乏约束。这两种方式都太极端，所以折中的第二种相对是比较好的，对一个开放系统来说，现在主要也是采取这种方式，比如各种开放平台的SDK，其实就是这种方式
搜索
相对于前面讨论的集成层面来说，搜索层面没有太多可说的，本质上取决于对方系统接口的粒度和开放程度
比如说，假设我现在想做一个书籍信息的垂直聚合应用，那么我当然要去当当、亚马逊、京东、china-pub上拿信息
某网站开放了接口（无论是上述哪一层的接口都无所谓），就比如说是web api吧，有queryByIsbn()、queryByAuthor()、queryByPrice()这3个方法，那么我就可以根据条件，去调用这些接口，来精确搜索到我想要的信息
而另一个网站则非常封闭，就希望读者到我网站来贡献流量，不要第三方应用乱戴帽子，那么就只有一个URL，www.bookshop.com/book?id=123456，那么我要在这个网站上做精确搜索“10块钱的JAVA书”就非常难，只能先向www.bookshop/book?name=java发请求，从拿到的结果中再解析（需要用到文本解析、正则表达式、去重等），得到我想要的数据之后，再嵌入我的系统里
从上面的例子可以看到，能不能很容易地得到搜索结果，最关键的因素是，目标系统是否是开放的，在设计的时候是否把“被集成”纳入考虑。遗憾的是，出于商业角度和历史原因，大部分都没有
总结
简单总结一下B/S和C/S，其实我觉得界限是非常模糊的。B/S中的B，其实也是一种客户端
B/S的优势主要是统一，应用层协议都走http，展现全都是html + css + javascript，就非常通用。而且所有终端上都有浏览器，解决了分发的问题。但是B/S曾经也有很多缺陷，比如页面渲染能力，javascript执行效率，兼容性，server push缺乏标准等。所以才会有C/S的一席之地
而最近几年，这些问题都在逐一解决，HTML5、CSS3、V8 Engine、ajax、W3标准、web socket等，都在解决这些曾经的问题，所以B/S也就越来越流行了。或许不能说C/S正在消亡，而是B/S越来越像C/S了