# （一）Web Services基本概念




<br>
整理这一章资料的过程是比较痛苦的，Web Services 是一项不太容易讲清楚技术，我花不少时间来阅读相关的资料，由于涉及的概念比较多，不同的厂商和专家对这些概念的解释也不完全相同。在概念的选择上我比较倾向于已出版的书籍中的解释。不过，我仍然希望你带怀疑的态度来学习这一章。

#### SOA
----
全称: Service-Oriented Architecture，简称 SOA，面向服务架构又称“面向服务的体系结构”。

SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了 SOA 架构下的系统。
既然称它为一种架构，那么一般认为 SOA 是包含了运行环境，编程模型，架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期。

service-architecture.com 网站对 SOA的定义：

SOA 本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。

所谓 __服务__ 就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。

虽然不同厂商或个人对 SOA 有着不同的理解，但是我们仍然可以从上述的定义中看到 SOA 的几个关键特性：

__一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通信模型。__

对于SOA来说，我们不需要太过较真 SOA 到是一个怎样的架构。只要符合它的定义和规范的软件系统都可以认为是SOA架构。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
#### SOA 与 Web Services
----
早在1996年Gartner就前瞻性地提出了面向服务架构的思想（SOA），SOA 阐述了“对于复杂的企业IT系统，应按照不同的、可重用的粒度划分，将功能相关的一组功能提供者组织在一起为消费者提供服务”，其目的是为了解决企业内部不同IT资源之间无法互联而导致的信息孤岛问题。

直到2000年左右，ESB（Enterprise Service Bus）、Web Services、SOAP 等这类技术的出现，才使得 SOA 渐渐落地。同时，更多的厂商像 IBM、Oracle 等也分别提出基于 SOA 的解决方案或者产品。

因为现在几乎所有的 SOA 应用场合都是和 Web Services 绑定的，所以不免有时候这两个概念混用。不可否认 Web Services 是现在最适合实现 SOA 的技术，SOA 的走红在很大程度上归功于Web Services标准的成熟和应用普及。因为现在大家基本上认同 Web Services 技术在几方面体现了 SOA 的需要：

首先，是基于标准访问的独立功能实体满足了松耦合要求：在 Web Services 中所有的访问都通过 SOAP 访问进行，用WSDL定义的接口封装，通过 UDDI 进行目录查找，可以动态改变一个服务的提供方而无需影响客户端的配置，外界客户端根本不必关心访问服务器端的实现。

其次，适合大数据量低频率访问符合服务大颗粒度功能：基于性能和效率平衡的要求，SOA的服务提供的是大颗粒度的应用功能，而且跨系统边界的访问频率也不会像程序间函数调用那么频繁。通过使用 WSDL 和基于文本（Literal）的 SOAP 请求，可以实现一次性接收处理大量数据。

最后，基于标准的文本消息传递为异构系统提供通信机制：Web Services 所有的通信是通过 SOAP 进行的，而 SOAP 是基于 XML 的，XML 是结构化的文本消息。从最早的 EDI
（Electronic Data Interchange）开始，文本消息也许是异构系统间通信最好的消息格式，适用于 SOA 强调的服务对异构后宿主系统的透明性。

综合上述观点， Web Services 不愧为当前SOA的最好选择。然而，就SOA思想本身而言，并不一定要局限于 Web Services 方式的实现。更应该看到的是 SOA 本身强调的是实现业务逻辑的敏捷性要求，是从业务应用角度对信息系统实现和应用的抽象。随着人们认识的提高，还会有新技术不断的发明出来，更好的来满足这个要求。

用一句话总结它们之间的关系。 <font color=#DC143C>“ SOA 不是 Web Services ， Web Services 是目前最适合实现SOA的技术。”</font>


#### Web Services
----
在解释 Web Services 之前，先抛出一个问题。有没有一种技术可以实现跨平台、跨应用程序进行通信呢？

__跨平台__，是指用 Java 开发的系统和用 .NET 开发的系统是否可以通信。

__跨应用程序__，是指开发的 A 系统和开发的 B 系统之间是否可以通信。

![](http://img.testclass.net/sopaui_qq_weather.png)

QQ天气预报

这样的需求有非常普遍，如图12.1，腾讯QQ上自带的天气功能。

腾讯要想获得实时的天气信息怎么办呢？有一种办法，就是腾讯公司放个卫星上天，并且在公司中成立一个气象部门，实时的收集天气信息，然后实时为腾讯QQ提供天气预报服务；这显然不是一种明智的做法，获取天气信息的成本过高。

更简单的做法是由中国气象局提供实时天气信息的接口，由腾讯公司调用并展示在QQ上面。那么这就遇到我上面所说的问题，如何跨应用与跨平台调用接口。

这个时候有聪明的你会跳出来说，前面不是已经通过HTTP协议实现了接口的调用么？用 HTTP 协议就可以了。嗯！这是完全可以的。不过，我们并不能拿HTTP与Web Services来进行比较。

HTTP 是互联网上应用最为广泛的一种网络传输协议。而 Web Services 是一种部署在Web上的对象或者是应用程序组件，Web Services 数据的传输同样需要借助HTTP协议。

Web Services 详细的描述：

<font color=#DC143C> Web Services 是一个平台独立的、低耦合的、自包含的、基于可编程的 web 的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。</font>




原始封面

![课程图片](https://images.unsplash.com/photo-1495347858443-047a7ad0aa15?w=300)


