现在进行应用程序开发时，差不多所有人都朝着浏览器靠拢，去搞那所谓的瘦客户应用。大家如此选择，并非真的是由于浏览器界面有多么好用，其核心缘由是桌面软件发布实在太费周折了。你仔细想想，每一台电脑都得进行安装配置，仅仅这一项就能让 IT 部门忙碌上好几天。更为麻烦的是，老一套的 DCOM 通信在局域网里运行起来状况连连，众多工程师宁愿忍受浏览器功能的局限，也不愿再去触碰那些令人头疼的远程调用问题。

从实际呈现的效果来观察，这种做出的选择所带来的结果常常会表现为，发布环节确定是省事了不少，然而开发过程却变得极为困难重重，用户界面同样也遭受了极大限度的限制。你投入了更多的资金以及耗费了更多的时间，最终制作完成的应用程序，在用户的视角看来反倒比原来的桌面软件更难以使用。随意去询问一下你公司的会计人员便能够知晓，他们对那些新推出的网页版财务软件存在着多少的抱怨，操作时并不顺手，响应速度又十分缓慢，与原来桌面的使用体验相比差之甚远。

跨平台通信的硬需求

当下企业的 IT 环境极为复杂，大型主机之中存有大量非关系型文件，通过 COBOL 程序进行访问，与此同时，新的业务系统运用 C++、Java、C#等各类语言编写，这些系统必须相互交换数据，以完成业务流程，以往要打通它们，仅能用诸如定时传文件、使用消息队列，或者调用 IBM 的 APPC 这类专用接口，此类笨办法，每种都被绑定在特定平台之上。

这个局面真正改变是一直等到Web服务出现之时，它给出了一套标准，这套标准独立于任何平台，独立于任何编程语言？独立于任何组件模型，不管是Windows服务器，还是Linux系统，或者是IBM大型机，只要是支持HTTP协议的；那么就能够互相通信，程序员之后再也不需要去关心对方系统是运用什么语言编写而成的啦，同样也不用再去纠结底层硬件到底是什么情况了，跨平台协作的门槛由此被大幅度拉低了。

从API到可互操作的平台

仅从程序员视角出发，Web服务在本质层面而言，乃是一个应用程序，然而其面向外部所展露的并非寻常网页，却是能够借助网络编程予以调用的且满足某种特定条件的API接口。此一特性使得程序彼此之间能够如同调用本地函数那般，去施行远程服务器之上的功能。举例来讲，你能够于自身所编写的代码范围之内，直接调用由另外一个公司所提供的具备特定条件的物流查询服务，恰似调用自己亲手撰写的函数一般简易。

说得更为准确些，Web服务是用于构建可具有互操作性的分布式应用的全新平台，它并非仅仅是单一的技术，而是属于一组标准，这组标准清晰地明确了应用程序在Web上彼此之间如何进行相互操作，不管你所使用的是何种编程语言，处于什么样的操作系统之上，只要你所开发的服务遵循了这组标准，那么其他人便能够借助标准方式找到你并调用你。

解决数据表示的关键：XML与XSD

想要达成不一样系统之间的相互操作，最为巨大的阻碍便是数据格式并非统一。Java程序运用一种方式去体现字符串，C++程序却采用另外一种方式，径直进行交换必定会发生问题。Web服务平台将XML用作数据表示的基础格式，此为纯文本的标记语言，任何平台均可解析，并且不依存于任何特定厂商，解决了最根本的数据互通问题。

但XML仅仅解决了数据如何书写的问题，并未解决数据类型怎样统一的问题，比如说某个参数在Java当中当作整数使用，在COBOL里面有可能是别的类型值，两边必须要相互对应才行，故而Web服务平台又引入了XSD作为标准类型系统，当你运用C#或者Java开发Web服务时，所有所用到的数据类型都会被自动映射成相对应的XSD类型，以此确保调用方能够准确理解每个参数的含义。

远程调用的标准方式：SOAP协议

得出数据格式以及类型定义之后，紧接着就要求一种标准的调用方式。SOAP 协议正是鉴于此而产生出来的。它界定了一套标准的远程过程调用机制，将函数名、参数以及返回值统统封装成为结构化的消息。虽说名字当中含有“对象”这两个字，然而实际上你能够运用 C 语言编写一系列普通函数，依旧能够借助 SOAP 作为 Web 服务予以暴露从而供他人调用。

SOAP规范对消息的样子作出了极为具体的规定，还规定了如何借助HTTP协议去发送以及接收这些消息。这表明调用过程能够穿透企业防火墙，原因在于HTTP协议本身是默认开放的。并且由于HTTP在全世界是通用的，不管调用方处于哪个国家，使用何种编程语言，都能够依据同一套规则发送请求、接收响应。

服务描述的利器：WSDL文档

光存在调用方式是不足够的，要是你开发了一个网络服务，其他人怎样晓得它给出了何种函数呢？每一个函数需要传递啥参数呢？以往仅仅能凭借撰写文档或者凭借口语告知对方，效率可谓极低，并且开发工具也没办法依据这样的描述自动生成调用代码。程序员准备运用服务时，还得依靠手动设法构造请求消息，极容易出现差错。

能解决这个问题的就是WSDL，它是一种基于XML的描述语言，它能像一本说明书那样，详细地列出服务所支持的全部操作，还有每个操作之中的输入输出参数方面的信息，以及消息的传输方式，关键之处在于这种所形成的文档是机器能够读取的那种，开发工具能够直接对它作出解析，进而自动生成客户端调用代码，程序员只需要如同调用本地函数那样去写代码便可以了。

服务发现的支撑：UDDI注册中心

当Web服务数量日益增多，怎样去寻得你所需要的那个服务，这便成了新出现的问题。比如说，倘若你想要集成一项来自第三方的支付服务，然而却不清楚究竟是谁予以了这般服务，同时也不晓得此项服务的地址处于哪里。UDDI规范乃是用以解决这个发现方面问题的，它的作用类似于一个面向全球或者企业内部的黄页，所有那些提供Web服务的公司均能够在上面进行注册。

UDDI的核心是个商业注册中心，其里用XML文档详尽记述了企业的基本资讯，以及它对外给出了哪些Web服务，服务的调用地址，技术规范之类 ，虽说在实际使用中，UDDI并未像起初预想的那般成为公共的、唯一的服务发现中心，不过在企业内部或者特定行业，这种基于标准的服务注册和查找机制，对于管理成百上千个微服务以及API接口，依旧极具价值。

你认为于企业内部系统集成里，Web服务这般传统形式，跟当下流行的微服务架构相比较，它们各自所具备的优势以及适用的场景分别是些什么呢？欢迎在评论区域分享你的见解。