Webservice讲解

Webservice讲解


软件越来越复杂、业务需求越来越复杂，出现跨系统、跨平台、跨公司、跨网络的要求。


一、什么是webservice







我们先看一个网页，这个网页有天气预报、股市行情、公司业务等信息。天气预报、股市行情信息是需要从公司外部系统获取的。



上面的WEB页面中，天气预报信息和股市行情信息是从互联网上其他系统服务器获取的，类似在互联网上提供天气预报信息和股市行情信息服务，供第三方用户使用的系统（程序）我们就称其为Web service。

从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。
对Web service 更精确的解释： Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。
通常，你用你自己喜欢的语言来构建你的Web service，然后任何语言，任何平台上的客户都可以阅读你的Web service提供的WSDL文档，以调用这个Web service。客户根据WSDL描述文档，会生成一个SOAP请求消息。Web service都是放在Web服务器 (如IIS或其他web服务器) 后面的，客户生成的SOAP请求会被嵌入在一个HTTP POST请求中，发送到Web服务器来。Web服务器再把这些请求转发给Web service请求处理器。



上面的Web service工作流程涉及到了一些基本概念，下面我们讲一下这些概念。
二、基本概念
SOAP (简单对象访问协议)
Web service建好以后，其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的远程过程调用( RPC)方法来调用Web service。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。客户端和服务端之间的方法调用请求和结果返回值都放在这些消息里。
XML和XSD
可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的。XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有使用的数据类型都必须被转换为XSD类型。
WSDL(Web Services Description Language)
用于描述服务端所提供服务的XML格式。WSDL文件里，描述了服务端提供的服务，提供的调用方法，以及调用时所要遵循的格式，比如调用参数和返回值的格式等等。WSDL 很像COM编程里的IDL(Interface Description Language)，是服务器与客户端之间的契约，双方必须按契约严格行事才能实现功能。
UDDI(统一描述、发现和集成（Universal Description,Discovery, and Integration）)
一个提供注册和定位商业Web service 的开放框架，既是一个规范，又是若干企业的伙伴。UDDI注册中心包含了通过程序手段可以访问到的Web服务。如果我们是非商业的Web service（我们自己使用，并不需要给第三方暴露）或者是你已经知道所要调用的Web service的地址和wsdl，就不需要到UDDI去注册或者查询服务了。
上面讲了几个概念，那这些概念之间的关系是怎么样的？
大体上来说,UDDI提供发布场所,WSDL用来描述这个场所的服务功能，SOAP则是规定WSDL文档的格式，XML是WSDL文档的书写语言，HTTP是数据的传输协议。读懂了WSDL文档，我们才知道怎么调用其提供的功能。





下面是一份Web service的wsdl文档。我们看到其是用XML书写的，其格式是符合SOAP规范的。
(在我的浏览器地址栏输入http://localhost:8080/xfireDemo/services/LoginService?wsdl，就会显示这个WSDL文档)

<?xml version="1.0" encoding="UTF-8" ?>
- <wsdl:definitions targetNamespace="http://service" xmlns:tns="http://service" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/" xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding" xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
- <wsdl:types>
- <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" attributeFormDefault="qualified" elementFormDefault="qualified" targetNamespace="http://service">
- <xsd:element name="checkLogin">
- <xsd:complexType>
- <xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="in0" nillable="true" type="xsd:string" />
<xsd:element maxOccurs="1" minOccurs="1" name="in1" nillable="true" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
- <xsd:element name="checkLoginResponse">
- <xsd:complexType>
+ <xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
- <wsdl:message name="checkLoginResponse">
<wsdl:part name="parameters" element="tns:checkLoginResponse" />
</wsdl:message>
- <wsdl:message name="checkLoginRequest">
<wsdl:part name="parameters" element="tns:checkLogin" />
</wsdl:message>
- <wsdl:portType name="LoginServicePortType">
- <wsdl:operation name="checkLogin">
<wsdl:input name="checkLoginRequest" message="tns:checkLoginRequest" />
<wsdl:output name="checkLoginResponse" message="tns:checkLoginResponse" />
</wsdl:operation>
</wsdl:portType>
- <wsdl:binding name="LoginServiceHttpBinding" type="tns:LoginServicePortType">
<wsdlsoap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
- <wsdl:operation name="checkLogin">
<wsdlsoap:operation soapAction="" />
- <wsdl:input name="checkLoginRequest">
<wsdlsoap:body use="literal" />
</wsdl:input>
- <wsdl:output name="checkLoginResponse">
<wsdlsoap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
- <wsdl:service name="LoginService">
- <wsdl:port name="LoginServiceHttpPort" binding="tns:LoginServiceHttpBinding">
<wsdlsoap:address location="http://localhost:8080/xfireDemo/services/LoginService" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

三、Webservice的技术特点

1： 跨防火墙的通信
如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。
举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。如果中间层组件换成Web Service的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web Service，可以直接使用Microsoft SOAP Toolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。
从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web Service这种结构，可以节省花在用户界面编程上20%的开发时间。另外，这样一个由Web Service组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过Web Service把应用程序的逻辑和数据“暴露”出来，还可以让其它平台上的客户重用这些应用程序。
2： 应用程序集成
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过Web Service，应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用。
例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web Service，订单执行程序可以把“Add Order”函数“暴露”出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。
3： B2B的集成
用Web Service集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。
Web Service是B2B集成成功的关键。通过Web Service，公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如，把电子下单系统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。用Web Service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来，成为Web Service，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。


4： 软件和数据重用
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。
当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。
Web Service在允许重用代码的同时，可以重用代码背后的数据。使用Web Service，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的Web Service就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的Web Service，这个Web Service 就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。Web Service 的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过Web Service“暴露”出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
将来，许多应用程序都会利用Web Service，把当前基于组件的应用程序结构扩展为组件、Web Service 的混合结构，可以在应用程序中使用第三方的Web Service 提供的功能，也可以把自己的应用程序功能通过Web Service 提供给别人。两种情况下，都可以重用代码和代码背后的数据。
四、如何调用webservice
客户端：取得服务端的服务描述文件WSDL，解析该文件的内容，了解服务端的服务信息，以及调用方式。根据需要，生成恰当的SOAP请求消息（指定调用的方法，已经调用的参数），发往服务端。等待服务端返回的SOAP回应消息，解析得到返回值。
服务端：生成服务描述文件，以供客户端获取。接收客户端发来的SOAP请求消息，解析其中的方法调用和参数格式。根据WSDL和WSML的描述，调用相应的功能，并把返回值放入SOAP回应消息返回给用户。
如下图所示：


上面我们讲了Web Service的概念和原理，开发Web Service除了要遵守一定的技术规范外，我们还遵循一些设计原则、设计思想或者说是设计架构，这就要谈到SOA概念了。注意设计架构和技术规范是两个概念。（比如我们公司标识图形logo的设计架构是要体现有限资源无限化、以人为本等理念，技术规范则用是什么颜色、什么形状等来体现这种理念）
五、SOA
SOA是面向服务的体系结构（Service-Oriented Architecture，SOA），是一种设计架构。
传统的架构，软件包是被编写为独立的软件，即在一个完整的软件包中将许多应用程序功能整合在一起。实现整合应用程序功能的代码通常与功能本身的代码混合在一起。我们将这种方式称作软件设计“单一应用程序”。与此密切相关的是，更改一部分代码将对使用该代码的代码具有重大影响，这会造成系统的复杂性，并增加维护系统的成本。而且还使重新使用应用程序功能变得较困难，因为这些功能不是为了重新使用而打的包。
传统的架构的缺点：代码冗余、不能重用、紧耦合、成本高 。
什么是面向服务的体系结构？
这种体系结构就是在设计应用程序时，把程序的各种功能考虑为对外提供服务的接口，把程序设计为别人可以使用的组件，而不是独立的别人不可访问的系统。比如气象局设计一个天气预报系统，不仅仅是自己使用这个系统，还允许外部的其他系统调用这个系统功能，那么这个天气预报系统就应该设计成面向服务的体系结构，别的公司调用气象局的系统，气象局可以收取一定的费用。再如电子地图服务公司，采用面向服务的体系结构，把自己公司的地图功能提高给其他公司使用。
如果说SOA是设计原则，那么Web service是技术规范，Web service是实现SOA思想体系的一种具体实现。用web service实现SOA的好处是：可以实现一个中立平台，来获取服务，获取更好的通用性。
Web Services的目标是即时装配、松散耦合以及自动集成。
SOA优点：代码重用、松耦合、平台独立、语言无关。

SOA架构中有三种角色：
• 服务提供者：发布自己的服务，并且对服务请求进行响应。
• 服务注册中心：注册已经发布的web service，对其进行分类，并提供搜索服务。
• 服务请求者：利用服务中心查找所需要的服务，然后使用该服务。
•
SOA的三种操作：
• 发布操作：为了使服务可访问，需要发布服务描述以使服务使用者可以发现它。
• 查找操作：服务请求者定位服务，方法是查询服务注册中心来找到满足其标准的服务。
• 绑定操作：在检索到服务描述之后，服务使用者继续根据服务描述中的信息来调用服务。

我们开发了若干Web Service，并且互联网上还提供很多Web Service，我们如何把这些Web Service组装集成起来，这就需要讲一下ESB概念。
六、ESB
ESB是企业服务总线（Enterprise Service Bus）的缩写，是中间件技术与Web Service等技术结合的产物，也是SOA系统中的核心基础设施。ESB就是一个服务的中介，形成服务使用者->ESB服务代理->服务提供者的生物链。
通俗的讲，ESB就是各种webservice的组装平台。ESB的基本功能是数据传输，消息协议转化，路由三大核心功能。ESB 需要某种形式的服务路由目录（service routing directory）来路由服务请求。




SOA、Web Service、ESB概念都清楚了，那么SOA、Web Service、ESB的关系是怎么样的？
SOA是一种设计架构，Web Service是符合SOA设计架构的程序（产物），ESB是Web Service的组装（集成）车间。

标准的 ESB 功能
通信 服务交互
• 路由
• 寻址
• 通信技术、协议和标准（例如 IBM® WebSphere® MQ、HTTP 和 HTTPS）
• 发布/订阅
• 响应/请求
• Fire-and-Forget，事件
• 同步和异步消息传递 • 服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL））
• 支持替代服务实现
• 通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型）
• 服务目录和发现
集成 服务质量
• 数据库
• 服务聚合
• 遗留系统和应用程序适配器
• EAI 中间件的连接性
• 服务映射
• 协议转换
• 应用程序服务器环境（例如 J2EE 和 .NET）
• 服务调用的语言接口（例如 Java 和 C/C++/C#） • 事务（原子事务、补偿、Web 服务事务（WS-Transaction））
• 各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持）
安全性 服务级别
• 身份验证
• 授权
• 不可抵赖性
• 机密性
• 安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security）） • 性能
• 吞吐量
• 可用性
• 其他可以构成契约或协定的持久评估方法
消息处理 管理和自治
• 编码的逻辑
• 基于内容的逻辑
• 消息和数据转换
• 有效性
• 中介
• 对象标识映射
• 数据压缩 • 服务预置和注册
• 记录、测量和监控
• 发现
• 系统管理和管理工具的集成
• 自监控和自管理
建模 基础架构智能
• 对象建模
• 通用业务对象建模
• 数据格式库
• B2B 集成的公共与私有模型
• 开发和部署工具 • 业务规则
• 策略驱动的行为，特别是对于服务级别、服务功能的安全和质量（例如 Web 服务策略（WS-Policy））
• 模式识别
上面的许多功能既可以使用专有技术实现，也可以通过利用开放标准实现。然而，使用不同的技术来实现 ESB 可能会使它们的性能、可伸缩性和可靠性这些特性显著不同，同时 ESB 功能和所支持的开放标准也会有所不同。由于这些原因，再加上最近制订和正在兴起的一些相关标准，当今实现 ESB 的许多关键决策都涉及到成熟的专有技术和不成熟的开放标准之间的权衡。


七、作业：
1、UDDI和ESB有何区别？
2、在实现了Web Servicede的系统中，esb是必须的吗？
3、SOAP是用什么来表达的？XML有自己的规范吗？SOAP的规范和XML的规范有何不同？HTTP有和他们有什么关系？


（举例，如“邀请函”的格式(SOAP)、语言(XML)、语法(XML语言规范)，“邀请函”必须有某种格式，用中文还是英文，中文或者英文有自己的语法。“邀请函”装在信封里邮寄（消息封装），信封的格式要符合某种规范（HHTP）。会场发出邀请函，接收者接到邀请函出席会场提供演讲服务）