客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
|
松散耦联：如果两个系统中，只有使用的命令能理解前面提到过的自我描述基于文本的消息，那么这两个系统就被认为是松散耦联的。而另一方面，紧密耦联的系统使用大量的定制的软件来增强系统间的通讯，并且需要对系统之间了解的更多。 无所不在的通信：现在个人不太可能能够构造一个操作系统，或者在近期内也不会整合接入因特网的能力，所以这就要求提供一个无所不在的通信渠道。同样，把几乎任何系统和设备连接到因特网的能力将确保这样的系统和设备能够被连接到因特网的其他的系统或设备使用。 通用的数据格式：通过采用现有的开放标准而不是专用的闭环式通信方法，任何系统都能支持能够理解XML Web服务的相同的开放标准。使用自我描述的基于文本的消息，XML Web服务和它们的客户可以共享这些消息，而不必知道每个底层系统的组成，这将能够在独立的完全不同的系统之间通信。XML Web服务使用XML来实现这个功能。 XML Web服务使用一个提供下列功能的基础结构：一个发现机制,用于定位XML Web服务；一个服务描述，用于定义如何使用这些服务；以及用来通信的标准连接格式。下列插图显示了这个基础结构的一个实例。
XML Web服务目录 和使用因特网上任何其他的资源一样，XML Web服务目录如果没有某些查找方法的话，它是不可能够找到一个特定的XML Web服务的。XML Web服务目录提供了中央地址，可以让XML Web服务供应者在其上发布他们提供的XML Web服务的信息。这样的目录甚至可以是XML Web服务本身，可以编程访问并且提供搜索结果来响应XML Web服务客户端的查询。使用一个XML Web服务目录来定位一个提供XML Web服务作为特定目的的组织，或者判断一个特定组织提供了什么XML Web服务，这可能是非常必要的。 UDDI（统一描述发现和集成规范）规格定义了一个标准方法来发布和发现XML Web服务的信息。与UDDI关联的XML模式定义了四个信息类型，能让开发者使用一个发布的XML Web服务。这些是：商业信息、服务信息、绑定信息和其他用于服务的规范的信息。 作为UDDI工程的核心组件，UDDI Business Registry（业务登记）允许业务编程定位其他组织发布的XML Web服务的信息。开发者可以使用UDDI Business Registry来定位发现文件和服务描述。更多信息，请看UDDI Web站点（http://uddi.microsoft.com）。 XML Web服务发现 XML Web服务发现是使用Web服务描述语言WSDL定位或发现一个或多个描述特定的XML Web服务的文件的操作。它让XML Web服务客户端得知一个XML Web服务是否存在并且到哪里找到这个XML Web服务的描述文件。 一个发布的.disco文件，是包含连接到其他描述XML Web服务的资源的XML文件，能够编程发现一个XML Web服务。下面的代码给出了一个发现文件的结构的例子：
注意：发现文档是一个元素容器，一般包含到提供用于XML Web服务的发现信息的资源的链接。如果关联的是URL，它们假定关联到发现文档的位置。 然而，一个实现XML Web服务的Web站点不必支持发现。另一个站点可以负责描述这个服务，例如一个XML Web服务目录。没有一种公共的方法用来发现服务，例如当你创建一个私人使用的服务时。 XML Web服务描述 XML Web服务基础结构创建在使用遵循一个公布的服务描述的基于XML的消息的通信的基础上。服务描述是一个使用WSDL语言的XML语法编写的XML文档，定义了XML Web服务能理解的XML Web服务消息格式。服务描述起一个协定的作用，用来定义一个XML Web服务的行为并且指示潜在的客户如何与之交互。XML Web服务的行为取决于服务定义和支持的消息类型。这些模式在概念上指示了服务使用者在相应格式的消息被发送到XML Web服务时可以期待什么。 例如，与远程过程调用（RPC）风格的服务关联的请求/响应模式将定义哪个SOAP消息模式用来调用一个特定的方法。这个模式还将定义响应SOAP消息将遵循的格式。 消息模式的另一个例子表示单方面的交互操作。这个模式在单向通信发生的时候被使用。在这种情况下，发送方不会从XML Web服务中接收任何消息，包括故障消息。 定义SOAP消息格式的模式可以在内部定义来进行实际的服务描述，它们也可以在外部定义并被导入服务描述。 除了消息格式的定义和消息模式以外，服务描述还可选择性的包含每个XML Web服务入口点的地址。这个地址的格式对应于用于访问服务的协议，例如URL对应于HTTP或者电子邮件地址对应于SMTP（简单邮件传送协议）。 更多WSDL规格的信息，请看W3C Web站点（http://www.w3.org/TR/wsdl）。 XML Web服务连接格式 象DCOM那样的二进制协议由一个去掉专有的通信协议的顶部的方法请求层组成。这样的协议对创建普遍可用的XML Web服务没有帮助。这么说并不是说阻止你们在XML Web服务方案中使用这样的协议，但是使用它们的缺点在于这样的协议依靠它们的底层系统的特定结构，因此限制了潜在客户的增加。 取而代之，你可以构造XML Web服务来协同一个或多个开放协议一起工作，就象HTTP和SOAP的综合使用一样。象你所料想的那样，基础结构要求支持不同的协议。 XML Web服务不局限于提供远程过程调用访问。它们还可以被构造来交换结构化的信息，例如采购订单和发货单，并且还可用于自动化和连接内部与外部的业务处理。 HTTP-GET和HTTP-POST HTTP-GET和HTTP-POST是使用HTTP的标准协议动词，用于编码和传送变量名/变量值对参数，并且使用相关的请求语义。每个HTTP-GET和HTTP-POST都由一系列HTTP请求头组成，这些请求头定义了客户端从服务器请求了什么，而响应则是由一系列HTTP应答头和应答数据组成，如果请求成功则返回应答。 HTTP-GET以使用MIME类型application/x-www-form-urlencoded的urlencoded文本的格式传递参数。Urlencoding是一种字符编码，保证被传送的参数由遵循规范的文本组成，例如一个空格的编码是"%20"。附加参数还能被认为是一个查询字符串。 与HTTP-GET类似，HTTP-POST参数也是被URL编码的。然而，变量名/变量值不作为URL的一部分被传送，而是放在实际的HTTP请求消息内部被传送。 SOAP简介 SOAP是一个简单的、重量轻的基于XML的协议，用于交换Web上的结构化的和模式化的信息。SOAP的总体设计目标是使它保持尽可能的简单，并且提供最少的功能。这个协议定义了一个不包含应用程序或传输语义的消息框架。因此，这个协议是模块化的并且非常利于扩展。 通过越过标准传输协议，SOAP能利用因特网现有的开放体系结构，并且能够被任何支持最基本的因特网标准的系统所接受。通过越过标准传输协议，SOAP能利用因特网现有的开放体系结构，并且能够被任何支持最基本的因特网标准的系统所接受。你可以看到，基础结构要求支持一个虽然简单但是功能强大的遵从SOAP的XML Web服务，因为它基本不向现有的因特网基础结构中添加新的内容，然而却有助于访问SOAP构造的服务。 SOAP协议规范由四个主要的部分组成。第一部分定义了一个强制的可扩展信封（envelope）用于封装数据。SOAP信封定义了一条SOAP消息和在SOAP信息处理器之间交换的基本单元。这是这个规格唯一的强制性的部分。 SOAP协议规范的第二部分定义了可选数据编码规则用于表示应用程序定义的数据类型和直接图表，以及一个用于序列化非语法数据模型的统一模型。 第三部分定义了一个远程过程调用风格（请求/响应）信息交换的模式。每个SOAP消息都是单向传输。虽然SOAP的根源于RPC，但是它不局限于请求/响应机制。XML Web服务经常联合SOAP消息来实现这样的模式，但是SOAP并不必须使用信息交换模式，并且规格的这个部分是可选的。 这个规格的第四部分定义了SOAP和HTTP之间的绑定。然而，这个部分还是可选的。你可以让SOAP和任何转送协议或机制一起协同使用，这些传送协议能够传送SOAP信封，包括SMTP、FTP甚至一个软盘。 更多SOAP规格的信息，请看W3C Web站点（http://www.w3.org/TR/soap）。 原文：http://soft.yesky.com/SoftChannel/72342380468043776/20040823/1845364_1.shtml |
请发表评论