还是夏天的味道

系列推荐：
【web第一篇】MVC框架模式，还是原来的味道

【web第二篇】JSP动作标识《Web第二篇》

【Web第三篇】重新认识cookie与session

思维导图：

C/S结构

client/server
缩写，这种结构，服务端一般用高性能的PC或工作站，并要用大型数据库（如Oracle或者SQL Server），客户端需要安装专门的客户端软件。下图表示这种可以充分利用两端硬件的优势，把任务分配给客户端及服务器，从而减少了通行的开销，是20世纪末网络程序开发的流行模式：

B/S结构

Brower/Server
的缩写，客户端不开发任何用户界面，统一采用Firefox或者谷歌浏览器,用Web浏览器向服务器发送请求，并接受处理。并把结果逐级传回客户端，这种的好处是利用成熟和普及的浏览器技术实现原有需要复杂软件才能实现的强大功能，节约了开发成本，也是当今应用软件的首选：

比较

• 1 开发维护成本

C/S
的开发和维护成本都比B/S
高，采用C/S结构时，对不同客户端要开发不同的程序，那么软件的安装，调试和升级需要在所有的客户机上面，真的：

举个栗子

❝

假如一个公司共有10个客户站点使用一套C/S的软件，那这10个客户站点都需要安装客户端程序，哪怕软件很微小的改动，维护员都必须把客户端原本的软件写了，再安新的进行配置，最可怕的是要不折不扣完成10次。那如果客户端忘记进行更新，客户端就因为软件版本不一致的问题而没法工作。

B/S
结构的软件，不必要在client安装及维护。如果将前面公司的C/S
结构的软件换成B/S
，那在软件升级后，系统维护员只需要把Server端的软件升级到最新版本，对其他client,只要重新登录系统即可使用最新版本的软件；

• 2 负载问题

C/S
结构的client不仅负责与用户的交互，而且还需要完成通过网络向服务器请求譬如对数据库，电子表格或者文档的处理工作。导致功能越来复杂，客户端的程序也跟着越来越庞大起来，那维护工作也不好做。B/S
的客户端就把事务处理逻辑交给Server由它来处理,我们客户端只显示就行。但是你说处理事务都交给Server也有一定的隐患。如果负荷较重，发生崩溃那不得提桶跑路啊，所以要备份的。

• 3 安全

C/S结构适合专人使用，通过严格的管理派发软件，比较安全。B/S的软件因为使用的人很多，也不会固定，安全性较差。总的说，就是为什么几十年来基于HTTP协议和HTML的web程序呈几何数量增长的重要原因。

工作原理

Web程序分为两种，即静态网页和动态网页。早期的是静态网页，HTML语言来写，放在Web服务器上，通过HTTP协议请求Server的Web页面，Web服务器接收到的用户请求处理后，在发送给客户端浏览器，显示给用户：慢慢的迭代，很多线下业务开始往往上面发展，Internet的web应用也变得越来复杂，用户访问的资源已不能只是保存的静态网页，更多的内容要更具用户的请求动态生成页面信息，就要用到动态脚本语言JSP，ASP及PHP
等，并把编写的程序部署到web服务器，它处理转化成解析的HTML
，再返回给客户端浏览器：

三层架构

为了更好地理解web应用技术是如何进行交互的，我用图来描述简单的三层架构:

• 表示层
  是应用的最高层，它显示与商品浏览、购买等相关的信息，并通过结果输出到浏览器/客户端和网络上的所有其它层来与应用架构的其它层进行通信;

• 逻辑层
  是从表示层剥离出来的，作为单独的一层，他用执行细节处理来控制应用的功能；

• 数据层
  (存储层)里面包括数据库服务器，用于对信息进行存储及检索。数据层保证数据独立于应用服务器或业务逻辑。将数据作为单独的一层还可以提高程序的可扩展性和较高性能。

❝

三层架构中一条最基本的原则：表示层不应直接与数据层进行通信。在三层架构中，所有通信都必须经过中间层。概念上来看，三层架构是一种线性关系。

web浏览器(表示层)向中间层(逻辑层)发送请求，中间层通过查询、更新数据库(存储层)响应该请求:

从图中可以看到，用户激活web浏览器并连接到http://www.github.com
,位于逻辑层的 web服务器 从文件系统中加载脚本 并把它加载给脚本引擎，脚本引擎负责解析和执行脚本。

脚本使用数据库连接程序打开存储层连接并对数据库执行SQL语句。数据库把数据返给数据库连接程序，后者把它传给逻辑层的脚本引擎，

紧接着逻辑层在将web页面用HTML
格式返回给表示层的用户的web浏览器之前，先执行完相关的应用或业务逻辑规则。用户的web浏览器呈现HTML并借助代码的图形化表示展现给用户。操作都在数秒完成，并且对用户也是透明的；

四层架构

三层架构并不具有扩展性，所以研究人员在三层架构的基础上创造了一种新概念：n层应用程序开发范式。其中包括一种4层解决方案。该方案在web服务器和数据库之间使用了一层中间件
(通常叫应用服务器)。

n层架构中的应用服务器负责将API(应用编程接口)提供给业务逻辑和业务流程供程序来使用。可以定制引入其他的web服务器

如图：

可以看到，用户激活web浏览器并连接到http://www.github.com
,逻辑层的web服务器从文件系统中加载脚本并将其加载给脚本引擎，脚本引擎负责解析并执行脚本。

脚本调用是位于应用层的应用服务器提供的API,应用层服务器使用数据库连接程序并打开存储层连接并对数据库执行SQL语句
。

数据库将数据返回给数据库连接程序，应用服务器在将数据返回给web服务器之前先执行相关的业务逻辑。web服务器再把数据用HTML格式返回给表示层的用户的web浏览器之前先执行最后的有关逻辑。web浏览器表示HTML并借助代码的图形化展现给用户，完成；

WebService

❝

大白说就是用 HTTP 协议为基础，通过 XML 进行客户端和服务器端通信的框架或者组件

两个关键点 :

• 服务端提供的功能 , 通过 xml 描述;

• 第一步中的描述的功能 , 要嵌入到 HTTP 协议中 , 使得能通过 HTTP 协议进行通信【SOAP】；

表示如图：

目的主要是 :

跨平台 , 支持 HTTP
协议的主机及服务器, 能够建立通信联系 , 并且大部分的主机和服务器(99.999%以上)将支持 HTTP协议。一般而言，不同目标主机之间的通信，需要通过防火墙，打开某个端口 ,HTTP 协议的优势在于，防火墙一般不会封掉80端口的, 这样可以方便，安全的通信。

跨语言,语言都支持 XML
文本解析, 这个目的是为了实现不同语言之间的通信, 通信的内容是要被xml限制的，因此这样进行通信，能跨越语言障碍，譬如Java开发的服务端，客户端可以用C去访问 , 反之也是这样。

二 原理和架构

当然， 架构比我们上面说到的图要更为复杂，上面只是说明了一来一回的通信 , 实际情况还需要考虑以下问题：

1.服务器端 (Provider)
提供统一的标准化服务。就像我们开办一个公司, 工商行政管理局，注册一下公司地址和性质。目的是 , 别人要用公司的服务，从工商管理局就知道你的地址。这样统一的做法，是方便所有的公司以及所有需要公司提供服务的客户。并且这些信息是最大限度的公开。

2.客户端 (Requester)
到注册中心(Registry)
拿到公司的基本信息之后 , 去找到这个公司, 然后使用该公司提供的服务;

注意图中的基本步骤的标号顺序：

• 1.Provider 节点提供好服务后, 首先注册到节点Registry；

• 2 和 3. Requester 节点到 Regitry 节点查信息 , 找到需要的Provider及其提供的Service；

• 
  
1. Requester 使用 Provider 提供的服务；

具体的介绍

上图这些东西 , 完完整整的表示 WebService
的整个流程 :

1. Client有需要，想调用一个服务，但不知道哪里去调用，但它知道 UDDI Registry 上面可以查得到。

2. 果然 UDDI 记录了某个一个叫做 Web Server A 的服务器能提供这样的服务。

3. 于是 Client 去 Web Server A, 询问确切的调用方法。

4. Web Server A 看到 Client 提出的“确切方法查询”之后， 立即返回给它一个 WSDL描述的xml文档 这里记录他能提供的各类方法及接口；

5. Client 了解到这些之后，将这些 xml 的接口方法，封装成为 HTTP 请求 , 发给 Web Server A. 这些封装方式采用的是标准的 SOAP 方式 , 实际是满足 HTTP 协议的一些 SOAP 的报文消息。

6. Web Server A 回应的也是 HTTP 协议的 SOAP 包 . 这样双方的请求响应就完全畅通。

上面看到的是应用原理图 , 深入 , 可以发现如下的协议架构图:

上面我们已经花了很大的精力, 介绍了发现 Service(UDDI), Service 提供的接口描述(WSDL), 调用 Service(SOAP),以及传输 (HTTP)
的的整个过程。因此不再做介绍。 这个技术的核心是 SOAP
：

实践 WebService

❝

看到上面的图那么复杂 , 实质上 SOAP+HTTP 协议已经足够成熟，犯不着让我们通过 xml 生成带有 SOAP 标签的 HTML 脚本, 有很多工具可以帮住我们实现。事实上，还是相当方便的：

情况A: 存在 Web Service
, 客户端的开发可通过如下步骤:

1 通过 UDDI，·查找
到 Client 程序需要的 Web Service 的位置；

2 通过 WebService 找到
WSDL 接口描述文件；

3 使用工具，将步骤 2 得到的 WSDL 文件，生成
一个 Client Stub, 这个实质上是代码, 也就是打了一个桩。把这个 stub 的代码归并
到 Client 程序中去；

4 每次 Client 需要调用 WebService 的时候，直接调用
步骤 4 生成的 Stub 接口，就实现了对 Server 端的调用。

情况B: Server
端的开发，同样无需做解析 SOAP 这样的小事，框架会帮我们做好。大致步骤:

1 实现 WebServer 需要提供的所有功能

2 利用 WSDL 文件 (或IDL)生成
Server Stub, 这些代码将负责接收
从外面获得的请求，并将其转发
给 Web Server 的 Service Implementation（实现代码）。当 Service Implementation 的代码处理
完，产生结果之后，又会把结果交给
Server Stub, 然后 Server Stub 可以产生
一个SOAP 的响应。Server Stub + Server Implementation组合在一起 , 称为 Web Service Container, 这玩意儿就是让发送到 WebService 的 HTTP 请求，直接送到
Server Stub 上面去：

实际应用中的调用

-- End --

备注：“进群”即可