关于B/S和C/S的想法，兼谈web service
程序员文章站
2022-06-14 16:17:42
...
最近做的这个项目，是一个外线管理系统。
外线人员使用android应用与服务端进行交互，内线人员使用浏览器访问系统。服务端既提供了给浏览器访问的页面，也暴露了一些接口给智能手机调用。
我原本觉得，这理所当然是一个C/S架构的应用，Server是服务端，Client是我们开发的android应用。不过今天看了一些关于B/S和C/S比较的帖子，回头又想了想，发现我原来的理解貌似不对。因此把一些想法记录在这里，以后再回顾一下。如果有朋友知道答案，也希望能指教一下，谢谢。
首先，我突然有点疑惑什么是所谓的web service。像我们服务端提供了一个地址，比如说http://localhost:8080/service/accept.action。然后我们的终端应用访问这个地址，并且传递一些参数进来，系统后台就做了一些逻辑处理，数据库操作什么的，然后返回一个响应回到android终端。
这种形式和我以前做过的web service就不太一样。以前系统A发布了一个web service，然后系统B是根据系统A的WSDL，直接调用系统A发布的一些方法。我理解这样才像一个web service。
但是现在这种形式，我感觉效果和上面的例子也是一样的，服务端就是发布web service的系统A，终端应用就是系统B，虽然它没有看到什么WSDL，但是它只要知道http://localhost:8080/service/accept.action这个地址，和这个地址需要的参数，照样可以访问到，并且也能让系统A作逻辑处理，也能得到系统A返回的结果。虽然这种形式上不是web service，但是实际的效果和web service又有什么区别呢？如果是这样的话，那么什么又才是真正的web service呢？
关于这个问题，我感到很疑惑，希望知道的朋友能给我讲解一下。
扯完题外话，再说回B/S和C/S。我原本认为我们这个系统肯定是C/S结构的，现在想想也不对劲。
终端应用和服务端的交互有2种方式，一种是走http协议，也是发起请求、获得响应、断开连接；另一种是通过走短信网关的方式，发送短信、解析短信。这2种方式，终端应用和服务端都没有保持长连接。如果服务端想推送什么消息到终端的话，是要通过向目标手机号发送特殊格式短信的方式来实现的。但是真正的C/S架构，却是可以通过Socket之类的长连接来即时推送消息的。
不过除了这点以外，我们又确实需要：
1、同时维护服务端系统和终端应用
2、负责终端应用的分发和升级
3、保证终端数据和服务端数据的同步
4、可以在终端应用上进行比较多的业务逻辑
上面这些特征又类似于传统的C/S架构，所以我现在也有点迷糊，究竟如何区分所谓的B/S和C/S呢？至少我认为我们这个系统不是纯粹的C/S，但是又不能说是B/S。。。
其实想想，也不用这么拘泥这个划分。除非一个系统和外部系统一点关系没有（比如安装一个单机的连连看），就一定涉及到如下问题：
1、系统职责划分（业务逻辑分配的比重）
2、系统间通信（HTTP、Socket……）
3、系统间数据同步
4、系统一致性（服务端升级，客户端需要相应升级）
5、部署和维护的成本
6、……
或许所谓的B/S、C/S，之间不存在也没必要某种绝对的划分，只要能处理好上述这些问题就行了。比如我们这次的系统，就可以算是一个B/S和C/S混搭的系统
外线人员使用android应用与服务端进行交互，内线人员使用浏览器访问系统。服务端既提供了给浏览器访问的页面，也暴露了一些接口给智能手机调用。
我原本觉得，这理所当然是一个C/S架构的应用，Server是服务端，Client是我们开发的android应用。不过今天看了一些关于B/S和C/S比较的帖子，回头又想了想，发现我原来的理解貌似不对。因此把一些想法记录在这里，以后再回顾一下。如果有朋友知道答案，也希望能指教一下，谢谢。
首先，我突然有点疑惑什么是所谓的web service。像我们服务端提供了一个地址，比如说http://localhost:8080/service/accept.action。然后我们的终端应用访问这个地址，并且传递一些参数进来，系统后台就做了一些逻辑处理，数据库操作什么的，然后返回一个响应回到android终端。
这种形式和我以前做过的web service就不太一样。以前系统A发布了一个web service，然后系统B是根据系统A的WSDL，直接调用系统A发布的一些方法。我理解这样才像一个web service。
但是现在这种形式，我感觉效果和上面的例子也是一样的，服务端就是发布web service的系统A，终端应用就是系统B，虽然它没有看到什么WSDL，但是它只要知道http://localhost:8080/service/accept.action这个地址，和这个地址需要的参数，照样可以访问到，并且也能让系统A作逻辑处理，也能得到系统A返回的结果。虽然这种形式上不是web service，但是实际的效果和web service又有什么区别呢？如果是这样的话，那么什么又才是真正的web service呢？
关于这个问题，我感到很疑惑，希望知道的朋友能给我讲解一下。
扯完题外话，再说回B/S和C/S。我原本认为我们这个系统肯定是C/S结构的，现在想想也不对劲。
终端应用和服务端的交互有2种方式，一种是走http协议，也是发起请求、获得响应、断开连接；另一种是通过走短信网关的方式，发送短信、解析短信。这2种方式，终端应用和服务端都没有保持长连接。如果服务端想推送什么消息到终端的话，是要通过向目标手机号发送特殊格式短信的方式来实现的。但是真正的C/S架构，却是可以通过Socket之类的长连接来即时推送消息的。
不过除了这点以外，我们又确实需要：
1、同时维护服务端系统和终端应用
2、负责终端应用的分发和升级
3、保证终端数据和服务端数据的同步
4、可以在终端应用上进行比较多的业务逻辑
上面这些特征又类似于传统的C/S架构，所以我现在也有点迷糊，究竟如何区分所谓的B/S和C/S呢？至少我认为我们这个系统不是纯粹的C/S，但是又不能说是B/S。。。
其实想想，也不用这么拘泥这个划分。除非一个系统和外部系统一点关系没有（比如安装一个单机的连连看），就一定涉及到如下问题：
1、系统职责划分（业务逻辑分配的比重）
2、系统间通信（HTTP、Socket……）
3、系统间数据同步
4、系统一致性（服务端升级，客户端需要相应升级）
5、部署和维护的成本
6、……
或许所谓的B/S、C/S，之间不存在也没必要某种绝对的划分，只要能处理好上述这些问题就行了。比如我们这次的系统，就可以算是一个B/S和C/S混搭的系统