- 学习 Web Services
- Web Services - 首页
- 什么是 Web Services?
- 为什么使用 Web Services?
- Web Services - 特性
- Web Services - 架构
- Web Services - 组件
- Web Services - 示例
- Web Services - 安全性
- Web Services - 标准
- Web Services - 总结
- Web Services 资源
- Web Services - 问题与解答
- Web Services 快速指南
- Web Services - 有用资源
Web Services 快速指南
什么是 Web Services?
不同的书籍和不同的组织对 Web Services 给出了不同的定义。这里列出了一些。
Web 服务是指任何可通过互联网访问并使用标准化 XML 消息系统的软件。XML 用于编码发送到 Web 服务的所有通信。例如,客户端通过发送 XML 消息来调用 Web 服务,然后等待相应的 XML 响应。由于所有通信都采用 XML 格式,因此 Web 服务不受任何特定操作系统或编程语言的限制——Java 可以与 Perl 通信;Windows 应用程序可以与 Unix 应用程序通信。
Web 服务是自包含的、模块化的、分布式的、动态的应用程序,可以通过网络对其进行描述、发布、定位或调用,以创建产品、流程和供应链。这些应用程序可以是本地、分布式或基于 Web 的。Web 服务构建在 TCP/IP、HTTP、Java、HTML 和 XML 等开放标准之上。
Web 服务是基于 XML 的信息交换系统,使用互联网进行直接的应用程序到应用程序交互。这些系统可以包括程序、对象、消息或文档。
Web 服务是一组用于在应用程序或系统之间交换数据的开放协议和标准的集合。用各种编程语言编写并在各种平台上运行的软件应用程序可以使用 Web 服务通过计算机网络(如互联网)交换数据,其方式类似于单个计算机上的进程间通信。这种互操作性(例如,Java 和 Python 之间,或 Windows 和 Linux 应用程序之间)是由于使用了开放标准。
总之,完整的 Web 服务因此是任何满足以下条件的服务:
可通过互联网或私有(内联网)网络访问
使用标准化的 XML 消息系统
不受任何特定操作系统或编程语言的限制
通过通用的 XML 语法进行自描述
可以通过简单的查找机制进行发现
Web Services 的组件
基本的 Web Services 平台是 XML + HTTP。所有标准的 Web Services 都使用以下组件:
SOAP(简单对象访问协议)
UDDI(通用描述、发现和集成)
WSDL(Web Services 描述语言)
所有这些组件都在Web Services 架构章节中进行了讨论。
Web 服务是如何工作的?
Web 服务通过使用 HTML、XML、WSDL 和 SOAP 等开放标准来实现各种应用程序之间的通信。Web 服务借助以下技术:
XML 对数据进行标记
SOAP 传输消息
WSDL 描述服务的可用性。
您可以在 Solaris 上构建一个基于 Java 的 Web 服务,该服务可从运行在 Windows 上的 Visual Basic 程序访问。
您还可以使用 C# 在 Windows 上构建新的 Web 服务,这些服务可以从基于 JavaServer Pages (JSP) 并运行在 Linux 上的 Web 应用程序调用。
示例
考虑一个简单的账户管理和订单处理系统。会计人员使用用 Visual Basic 或 JSP 构建的客户端应用程序来创建新账户并输入新的客户订单。
此系统的处理逻辑是用 Java 编写的,并驻留在 Solaris 机器上,该机器还与数据库交互以存储信息。
执行此操作的步骤如下:
客户端程序将账户注册信息捆绑到 SOAP 消息中。
此 SOAP 消息作为 HTTP POST 请求的主体发送到 Web 服务。
Web 服务解包 SOAP 请求并将其转换为应用程序可以理解的命令。
应用程序根据需要处理信息,并响应该客户的新唯一账户号码。
接下来,Web 服务将响应打包到另一个 SOAP 消息中,并将其发送回客户端程序以响应其 HTTP 请求。
客户端程序解包 SOAP 消息以获取账户注册过程的结果。
为什么使用 Web Services?
以下是使用 Web Services 的好处:
在网络上公开现有功能
Web 服务是可使用 HTTP 远程调用的托管代码单元。也就是说,它可以使用 HTTP 请求激活。Web 服务允许您在网络上公开现有代码的功能。一旦在网络上公开,其他应用程序就可以使用程序的功能。
互操作性
Web 服务允许各种应用程序相互通信并在彼此之间共享数据和服务。其他应用程序也可以使用 Web 服务。例如,VB 或 .NET 应用程序可以与 Java Web 服务通信,反之亦然。Web 服务用于使应用程序平台和技术独立。
标准化协议
Web 服务使用标准化的行业标准协议进行通信。所有四个层(服务传输、XML 消息传递、服务描述和服务发现层)在 Web 服务协议栈中使用定义良好的协议。协议栈的这种标准化给企业带来了许多优势,例如广泛的选择范围、由于竞争而降低的成本以及质量的提高。
低成本通信
Web 服务使用 HTTP 上的 SOAP 协议,因此您可以使用现有的低成本互联网来实现 Web 服务。与 EDI/B2B 等专有解决方案相比,此解决方案的成本要低得多。除了 HTTP 上的 SOAP 之外,Web 服务还可以实现到其他可靠的传输机制(如 FTP)上。
Web Services - 特性
Web Services 具有以下特殊行为特征:
基于 XML
Web Services 在数据表示和数据传输层使用 XML。使用 XML 消除了任何网络、操作系统或平台绑定。基于 Web Services 的应用程序在其核心级别具有高度的互操作性。
松耦合
Web 服务的使用者不会直接绑定到该 Web 服务。Web 服务接口可以随着时间的推移而更改,而不会影响客户端与服务交互的能力。紧耦合系统意味着客户端和服务器逻辑紧密地绑定在一起,这意味着如果一个接口发生更改,则必须更新另一个接口。采用松耦合架构往往使软件系统更易于管理,并允许不同系统之间进行更简单的集成。
粗粒度
Java 等面向对象的技术通过单独的方法公开其服务。单个方法对于在企业级提供任何有用的功能来说粒度太细了。从头开始构建 Java 程序需要创建几个细粒度方法,然后将这些方法组合成粗粒度服务,供客户端或其他服务使用。
企业及其公开的接口应该具有粗粒度。Web Services 技术提供了一种定义粗粒度服务的自然方法,这些服务可以访问适当数量的业务逻辑。
能够同步或异步
同步性是指客户端与服务执行的绑定。在同步调用中,客户端会阻塞并等待服务完成其操作后再继续。异步操作允许客户端调用服务,然后执行其他功能。
异步客户端在稍后的时间点检索其结果,而同步客户端在服务完成时接收其结果。异步能力是实现松耦合系统的关键因素。
支持远程过程调用 (RPC)
Web 服务允许客户端使用基于 XML 的协议调用远程对象上的过程、函数和方法。远程过程公开 Web 服务必须支持的输入和输出参数。
在过去的几年里,通过 Enterprise JavaBeans (EJB) 和 .NET 组件进行组件开发已日益成为架构和企业部署的一部分。这两种技术都是分布式的,并且可以通过各种 RPC 机制访问。
Web 服务通过提供自己的服务(等效于传统组件的服务)或将传入调用转换为对 EJB 或 .NET 组件的调用来支持 RPC。
支持文档交换
XML 的主要优势之一是它以通用方式表示数据和复杂文档。这些文档可以像表示当前地址一样简单,也可以像表示整本书或报价请求 (RFQ) 一样复杂。Web 服务支持文档的透明交换,以促进业务集成。
Web Services - 架构
有两种方法可以查看 Web 服务架构:
- 第一种方法是检查每个 Web 服务参与者的个体角色。
- 第二种方法是检查新兴的 Web 服务协议栈。
Web 服务角色
Web 服务架构中有三个主要角色:
服务提供者
这是 Web 服务的提供者。服务提供者实现服务并在互联网上提供服务。
服务请求者
这是任何 Web 服务的使用者。请求者通过打开网络连接并发送 XML 请求来利用现有的 Web 服务。
服务注册表
这是一个逻辑上的服务集中目录。注册表提供了一个中心位置,开发人员可以在其中发布新服务或查找现有服务。因此,它充当公司及其服务的集中信息交换中心。
Web 服务协议栈
查看 Web 服务架构的第二个选择是检查新兴的 Web 服务协议栈。该栈仍在发展,但目前有四个主要层。
服务传输
此层负责在应用程序之间传输消息。目前,此层包括超文本传输协议 (HTTP)、简单邮件传输协议 (SMTP)、文件传输协议 (FTP) 以及更新的协议,如块可扩展交换协议 (BEEP)。
XML 消息传递
此层负责以通用的 XML 格式编码消息,以便双方都能理解消息。目前,此层包括 XML-RPC 和 SOAP。
服务描述
此层负责描述特定 Web 服务的公共接口。目前,服务描述通过 Web 服务描述语言 (WSDL) 处理。
服务发现
此层负责将服务集中到一个公共注册表中,并提供简单的发布/查找功能。目前,服务发现通过通用描述、发现和集成 (UDDI) 处理。
随着 Web 服务的发展,可能会添加其他层,并且可能会向每个层添加其他技术。
下一章解释 Web Services 的组件。
关于服务传输的一些话
Web 服务协议栈的底部是服务传输。此层负责在两台计算机之间实际传输 XML 消息。
超文本传输协议 (HTTP)
目前,HTTP 是最流行的服务传输选项。HTTP 简单、稳定且部署广泛。此外,大多数防火墙都允许 HTTP 流量。这使得 XMLRPC 或 SOAP 消息能够伪装成 HTTP 消息。如果您想集成远程应用程序,这很好,但它确实引发了一些安全问题。
块可扩展交换协议 (BEEP)
这是 HTTP 的一个很有希望的替代方案。BEEP 是一个用于构建新协议的新型互联网工程任务组 (IETF) 框架。BEEP 直接构建在 TCP 之上,并包含许多内置功能,包括初始握手协议、身份验证、安全性和错误处理。使用 BEEP,可以为各种应用程序创建新的协议,包括即时消息、文件传输、内容联合和网络管理。
SOAP 不与任何特定的传输协议绑定。事实上,您可以通过 HTTP、SMTP 或 FTP 使用 SOAP。因此,一个有希望的想法是通过 BEEP 使用 SOAP。
Web Services - 组件
在过去的几年里,三种主要技术已成为全球标准,构成了当今 Web 服务技术的核心。下面将讨论这些技术。
XML-RPC
这是用于在计算机之间交换信息的、最简单的基于 XML 的协议。
XML-RPC 是一种简单的协议,它使用 XML 消息执行 RPC。
请求以 XML 编码并通过 HTTP POST 发送。
XML 响应嵌入在 HTTP 响应的主体中。
XML-RPC 是平台无关的。
XML-RPC 允许各种应用程序进行通信。
Java 客户端可以与 Perl 服务器进行 XML-RPC 通信。
XML-RPC 是开始使用 Web 服务的最简单方法。
要了解有关 XML-RPC 的更多信息,请访问我们的 XML-RPC 教程。
SOAP
SOAP 是一种用于在计算机之间交换信息的、基于 XML 的协议。
SOAP 是一种通信协议。
SOAP 用于应用程序之间的通信。
SOAP 是一种发送消息的格式。
SOAP 旨在通过互联网进行通信。
SOAP 是平台无关的。
SOAP 是语言无关的。
SOAP 简单且可扩展。
SOAP 允许您绕过防火墙。
SOAP 将作为 W3C 标准开发。
要了解有关 SOAP 的更多信息,请访问我们的 SOAP 教程。
WSDL
WSDL 是一种基于 XML 的语言,用于描述 Web 服务以及如何访问它们。
WSDL 代表 Web 服务描述语言。
WSDL 由微软和 IBM 联合开发。
WSDL 是一种基于 XML 的协议,用于在分散和分布式环境中交换信息。
WSDL 是描述 Web 服务的标准格式。
WSDL 定义描述了如何访问 Web 服务以及它将执行哪些操作。
WSDL 是一种用于描述如何与基于 XML 的服务交互的语言。
WSDL 是 UDDI(一种基于 XML 的全球业务注册表)的组成部分。
WSDL 是 UDDI 使用的语言。
WSDL 发音为“wiz-dull”,拼写为“W-S-D-L”。
要了解有关 WSDL 的更多信息,请访问我们的 WSDL 教程。
UDDI
UDDI 是一种基于 XML 的标准,用于描述、发布和查找 Web 服务。
UDDI 代表通用描述、发现和集成。
UDDI 是 Web 服务分布式注册表的规范。
UDDI 是平台无关的开放框架。
UDDI 可以通过 SOAP、CORBA 和 Java RMI 协议进行通信。
UDDI 使用 WSDL 来描述 Web 服务的接口。
UDDI 与 SOAP 和 WSDL 一起被视为 Web 服务的三大基础标准之一。
UDDI 是一项开放的行业计划,使企业能够彼此发现并定义如何在互联网上进行交互。
要了解有关 UDDI 的更多信息,请访问我们的 UDDI 教程。
Web Services - 示例
基于 Web 服务架构,我们创建以下两个组件作为 Web 服务实现的一部分:
服务提供者或发布者
这是 Web 服务的提供者。服务提供者实现服务并使其在 Internet 或 Intranet 上可用。
我们将使用 .NET SDK 编写和发布一个简单的 Web 服务。
服务请求者或消费者
这是任何 Web 服务的使用者。请求者通过打开网络连接并发送 XML 请求来利用现有的 Web 服务。
我们还将编写两个 Web 服务请求者:一个基于 Web 的消费者(ASP.NET 应用程序)和另一个基于 Windows 应用程序的消费者。
下面是我们的第一个 Web 服务示例,它充当服务提供者并公开两个方法(add 和 SayHello)作为 Web 服务供应用程序使用。这是 Web 服务的标准模板。.NET Web 服务使用 .asmx 扩展名。请注意,公开为 Web 服务的方法具有 WebMethod 属性。将此文件保存为 IIS 虚拟目录中的 FirstService.asmx(如配置 IIS 中所述;例如,c:\MyWebSerces)。
FirstService.asmx <%@ WebService language = "C#" class = "FirstService" %> using System; using System.Web.Services; using System.Xml.Serialization; [WebService(Namespace = "https://127.0.0.1/MyWebServices/")] public class FirstService : WebService{ [WebMethod] public int Add(int a, int b) { return a + b; } [WebMethod] public String SayHello() { return "Hello World"; } }
要测试 Web 服务,必须发布它。Web 服务可以发布在 Intranet 或 Internet 上。我们将在此本地计算机上运行的 IIS 上发布此 Web 服务。让我们从配置 IIS 开始。
打开“开始”→“设置”→“控制面板”→“管理工具”→“Internet 信息服务管理器”。
展开并右键单击默认网站;选择“新建”→“虚拟目录”。将打开“虚拟目录创建向导”。单击“下一步”。
将打开“虚拟目录别名”屏幕。键入虚拟目录名称。例如,MyWebServices。单击“下一步”。
将打开“网站内容目录”屏幕。
输入虚拟目录的目录路径名称。例如,c:\MyWebServices。单击“下一步”。
将打开“访问权限”屏幕。根据您的需要更改设置。对于此练习,让我们保留默认设置。
单击“下一步”按钮。它将完成 IIS 配置。
单击“完成”以完成配置。
要测试 IIS 是否已正确配置,请将 HTML 文件(例如,x.html)复制到上面创建的虚拟目录 (C:\MyWebServices) 中。现在,打开 Internet Explorer 并键入https://127.0.0.1/MyWebServices/x.html。它应该打开 x.html 文件。
注意 - 如果不起作用,请尝试将 localhost 替换为您机器的 IP 地址。如果仍然不起作用,请检查 IIS 是否正在运行;您可能需要重新配置 IIS 和虚拟目录。
要测试此 Web 服务,请将 FirstService.asmx 复制到上面创建的 IIS 虚拟目录 (C:\MyWebServices) 中。在 Internet Explorer 中打开 Web 服务 (https://127.0.0.1/MyWebServices/FirstService.asmx)。它应该打开您的 Web 服务页面。该页面应包含指向我们的应用程序公开为 Web 服务的两个方法的链接。恭喜!您已经编写了您的第一个 Web 服务!
测试 Web 服务
正如我们刚刚看到的,在 .NET Framework 中编写 Web 服务很容易。在 .NET 框架中编写 Web 服务使用者也很容易;但是,它涉及的内容更多一些。如前所述,我们将编写两种类型的服务使用者,一种是基于 Web 的,另一种是基于 Windows 应用程序的使用者。让我们编写我们的第一个 Web 服务使用者。
基于 Web 的服务使用者
如下所示编写基于 Web 的使用者。将其命名为 WebApp.aspx。请注意,它是一个 ASP.NET 应用程序。将其保存在 Web 服务的虚拟目录中 (c:\MyWebServices\WebApp.axpx)。
此应用程序有两个文本字段,用于获取用户要添加的数字。它有一个按钮“执行”,单击该按钮后将获取 Add 和 SayHello Web 服务。
WebApp.aspx <%@ Page Language = "C#" %> <script runat = "server"> void runSrvice_Click(Object sender, EventArgs e) { FirstService mySvc = new FirstService(); Label1.Text = mySvc.SayHello(); Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text), Int32.Parse(txtNum2.Text)).ToString(); } </script> <html> <head> </head> <body> <form runat = "server"> <p> <em>First Number to Add </em>: <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4< /asp:TextBox> </p> <p> <em>Second Number To Add </em>: <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox> </p> <p> <strong><u>Web Service Result -</u></strong> </p> <p> <em>Hello world Service</em> : <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label> </p> <p> <em>Add Service</em> : & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label> </p> <p align = "left"> <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button> </p> </form> </body> </html>
创建使用者后,我们需要为要使用的 Web 服务创建代理。当引用已添加的 Web 服务时,Visual Studio .NET 会自动为我们完成这项工作。以下是需要遵循的步骤:
为要使用的 Web 服务创建代理。使用 .NET SDK 提供的 WSDL 实用程序创建代理。此实用程序从 Web 服务中提取信息并创建代理。代理仅对特定 Web 服务有效。如果您需要使用其他 Web 服务,则也需要为此服务创建代理。当添加 Web 服务引用时,Visual Studio .NET 会自动为您创建代理。使用 .NET SDK 提供的 WSDL 实用程序为 Web 服务创建代理。它将在当前目录中创建 FirstSevice.cs 文件。我们需要编译它以创建 Web 服务的 FirstService.dll(代理)。
c:> WSDL https://127.0.0.1/MyWebServices/FirstService.asmx?WSDL c:> csc /t:library FirstService.cs
将已编译的代理放在 Web 服务虚拟目录的 bin 目录中 (c:\MyWebServices\bin)。Internet 信息服务 (IIS) 在此目录中查找代理。
创建服务使用者,就像我们已经做的那样。请注意,在使用者中实例化了 Web 服务代理的对象。此代理负责与服务交互。
在 IE 中键入使用者的 URL 以测试它(例如,https://127.0.0.1/MyWebServices/WebApp.aspx)。
基于 Windows 应用程序的 Web 服务使用者
编写基于 Windows 应用程序的 Web 服务使用者与编写任何其他 Windows 应用程序相同。您只需要创建代理(我们已经完成了)并在编译应用程序时引用此代理。以下是我们使用 Web 服务的 Windows 应用程序。此应用程序创建一个 Web 服务对象(当然,是代理)并在其上调用 SayHello 和 Add 方法。
WinApp.cs using System; using System.IO; namespace SvcConsumer { class SvcEater { public static void Main(String[] args) { FirstService mySvc = new FirstService(); Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello()); Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString()); } } }
使用c:\>csc /r:FirstService.dll WinApp.cs
进行编译。它将创建 WinApp.exe。运行它以测试应用程序和 Web 服务。
现在,问题出现了:您如何确定此应用程序实际上是在调用 Web 服务?
测试很简单。停止 Web 服务器,以便无法联系 Web 服务。现在,运行 WinApp 应用程序。它将引发运行时异常。现在,再次启动 Web 服务器。它应该可以工作。
Web Services - 安全性
安全对于 Web 服务至关重要。但是,XML-RPC 和 SOAP 规范都没有提出任何明确的安全或身份验证要求。
Web 服务存在三个特定的安全问题:
- 机密性
- 身份验证
- 网络安全
机密性
如果客户端向服务器发送 XML 请求,我们能否确保通信保持机密?
答案在这里:
- XML-RPC 和 SOAP 主要在 HTTP 之上运行。
- HTTP 支持安全套接字层 (SSL)。
- 可以通过 SSL 对通信进行加密。
- SSL 是一种经过验证的技术,并且已广泛部署。
单个 Web 服务可能包含一系列应用程序。例如,一项大型服务可能会将三个其他应用程序的服务捆绑在一起。在这种情况下,SSL 不够;需要在服务路径上的每个节点对消息进行加密,并且每个节点都代表链中一个潜在的薄弱环节。目前,还没有针对此问题的商定解决方案,但一种有希望的解决方案是 W3C XML 加密标准。此标准为加密和解密整个 XML 文档或 XML 文档的某些部分提供了一个框架。您可以在 www.w3.org/Encryption 中查看它。
身份验证
如果客户端连接到 Web 服务,我们如何识别用户?用户是否有权使用该服务?
可以考虑以下选项,但对于强大的身份验证方案尚无明确的共识。
HTTP 包含对基本身份验证和摘要身份验证的内置支持,因此可以像当前保护 HTML 文档一样保护服务。
SOAP 数字签名 (SOAP-DSIG) 利用公钥加密对 SOAP 消息进行数字签名。它使客户端或服务器能够验证另一方的身份。请在 www.w3.org/TR/SOAP-dsig 中查看它。
结构化信息标准促进组织 (OASIS) 正在开发安全断言标记语言 (SAML)。
网络安全
目前还没有简单易行的解决方法,这个问题一直备受争议。目前,如果您确实想要过滤掉 SOAP 或 XML-RPC 消息,一种方法是过滤掉所有将内容类型设置为 text/xml 的 HTTP POST 请求。
另一种方法是过滤 SOAPAction HTTP 头属性。防火墙供应商目前也在开发专门用于过滤 Web 服务流量的工具。
Web Services - 标准
本章将为您介绍所有与 Web 服务相关的最新标准。
传输
BEEP(Blocks Extensible Exchange Protocol,以前称为 BXXP)是一个用于构建应用协议的框架。它已由 IETF 标准化,它对互联网协议的作用如同 XML 对数据的作用。
消息传递
这些消息传递标准和规范旨在为在分散的分布式环境中交换信息提供一个框架。
描述和发现
只有潜在用户能够找到足够的信息以允许他们执行 Web 服务,Web 服务才有意义。这些规范和标准的重点是定义一组服务,这些服务支持对企业、组织和其他 Web 服务提供商的描述和发现;他们提供的 Web 服务;以及可用于访问这些服务的技术接口。
安全
使用这些安全规范,应用程序可以进行安全通信,旨在与通用的 Web 服务框架一起工作。
管理
Web 服务的可管理性定义为一组功能,用于在 Web 服务架构中发现 Web 服务的存在、可用性、健康状况、性能、使用情况以及控制和配置。随着 Web 服务变得越来越普遍并对业务运营至关重要,管理和实施 Web 服务的任务对于业务运营的成功至关重要。
Web Services - 总结
在本教程中,您学习了如何使用 Web 服务。但是,Web 服务还包括 WSDL、UDDI 和 SOAP 等组件,这些组件有助于使其活跃起来。下一步是学习 WSDL、UDDI 和 SOAP。
WSDL
WSDL 是一种基于 XML 的语言,用于描述 Web 服务以及如何访问它们。
WSDL 描述了 Web 服务,以及 Web 服务的消息格式和协议详细信息。
要了解有关 WSDL 的更多信息,请访问我们的 WSDL 教程。
UDDI
UDDI 是一种基于 XML 的标准,用于描述、发布和查找 Web 服务。
要了解有关 UDDI 的更多信息,请访问我们的 UDDI 教程。
SOAP
SOAP 是一种基于 XML 的简单协议,允许应用程序通过 HTTP 交换信息。
要了解有关 SOAP 的更多信息,请访问我们的 SOAP 教程。