|
|
原 作 者：不详
原 出 处：不详
发 布 者：loose_went
发布类型：转载
术规范
协议及消息传递（Protocol and Messaging）
SOAP
即简单对象访问协议（Simple Object Access Protocol），它是用于交换XML编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架；将程序对象编码成为XML对象的规则；执行远程过程调用（RPC）的约定。
SOAP 可以运行在任何其它传输协议上。例如，您可以使用 SMTP，即因特网电子邮件协议来传递SOAP消息。在传输层之间的头是不同的，但XML有效负载保持相同。
性能：
SOAP 用 XML 将消息编码，因此在调用过程的任何一步都极易处理消息。另外，调试 SOAP 消息的方便性使各种 SOAP 执行能快速聚合在一起，这点很重要因为 SOAP 就是要达到大范围的协同工作。（CORBA、DCOM 和 RMI 对参数和返回值使用二进制编码。除此之外，他们假设发送端和接收端充分了解消息的前后关系，因此对诸如参数名称或类型的任何元信息都不编码。这种方法产生了良好的性能，但使中介很难处理消息。因为每个系统使用不同的二进制编码，所以建立互操作的系统很难）。
表面看来，基于 XML 的模式本应比基于二进制的慢，但它并不像表面那么简单。首先，当SOAP被用于通过因特网发送消息时，在每个端点给消息编码／解码的时间与在端点间传输字节的时间相比较是微不足道的，所以这种情况下使用 XML 没太大问题。
其次，当SOAP用于封闭环境下的点对点间的消息传送，如在同一公司部门间的传送时，各端点可能将运行相同的SOAP执行。这样，这个特定执行就拥有专门的优化机会。例如，一个SOAP客户端可添加一个 HTTP header 标记到 SOAP 请求上，这个请求说明它支持一个特定的优化。如果SOAP服务器也支持那个优化，它会在第一个SOAP响应中返回一个 HTTP header 标记，告诉客户端可以在下面的通信中使用这种优化。接下来，客户端和服务器可以开始使用这种优化了。
接口描述（Interface Description）
1. WSDL
WSDL是用来描述网络（network）服务或终端（endpoint）的一种XML语言，它用于定义Web Services以及如何调用它们（描述Web服务的属性，例如它做什么，它位于哪里和怎样调用它）。WSDL文档可用于动态发布Web Services、查找已发布的Web Services以及绑定Web Services。
在WSDL中包含了使用SOAP的服务描述的绑定，也包含了使用简单HTTP GET和POST请求的服务描述的绑定。
WSDL将Web服务定义成一系列的端口（port），每个端口用来表示从抽象端口类型（port type）到用于调用Web服务的具体通信协议的一个映射。端口类型由一组与Service provider交换信息的操作组成，它支持对包含消息的数据类型的定义。（可参考具体的WSDL文档定http://www-900.ibm.com/developerWorks/webservices/ws-peer4/listing1.html）
一个完整的 WSDL 服务描述是由一个服务接口和一个服务实现文档组成的。 由于服务接口表示服务的可重用定义，它在 UDDI 注册中心被作为 tModel 发布。服务实现描述服务的实例。每个实例都是使用一个 WSDL service 元素定义的。服务实现文档中的每个 service 元素都被用于发布 UDDI businessService。
因为 WSDL 包含了对服务接口的完整描述，所以我们可以使用它来创建能简化服务访问的存根，该存根为一段Java代码（假设使用Java），它自动生成了访问Web服务的类。如果我们需要访问Web服务，只需调用该类中对应的方法即可，而不用在客户端程序中再写入那些令人头疼的配置信息了。通过IBM提供的工具包可以轻松创建WSDL文档对应的存根。（由此看出，不用WSDL也可以访问Web服务）
WSDL取代了IBM的NASSL（Network-Accessible Service Specification Language）和Microsoft的SCL（SOAP Contract Language）。
2. UDDI
即Universal Description, Discovery and Integration。它提供了在Web上描述并发现商业服务的框架。UDDI通过服务注册，以及使用SOAP访问这些注册信息的约定来实现上述目标。
UDDI计划的核心组件是UDDI商业注册，它使用一个XML文档来描述企业及其提供的Web服务。从概念上来说，UDDI商业注册所提供的信息包含三个部分："白页(White Page)" 包括了地址，联系方法，和已知的企业标识；"黄页(Yellow page)"包括了基于标准分类法的行业类别；"绿页(Green Page)"则包括了关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是为服务发现机制服务的。所有的UDDI商业注册信息存储在UDDI商业注册中心中。
借助XML 和SOAP ，集成和交互的问题将从层次上被简化。XML 提供了跨平台的数据编码和组织方法，而SOAP 建立在XML 之上，定义了一种跨系统平台的信息交换的简单包装方法。绑定于HTTP之上的SOAP协议，可以跨语言、跨操作系统进行远程过程调用(RPC)，实现了编程语言和系统平台的无关性。而以前的调用方式则和复杂的分布式对象标准或是中间件有密切的关系，从长期的眼光来看，这些都不是高效的解决方案。XML 和SOAP 这样的跨语言、跨平台的解决方案大大简化了不同企业系统之间的交互问题。
但如果仅仅是XML和SOAP的话，对于公司间的交流仍存在着巨大的鸿沟。UDDI 规范在XML 和SOAP 的基础之上定义了新的一层，在这一层次，不同企业可以用相同的方法描述自己所能提供的，并能查询对方所能提供的服务。
互操作
协议栈 统一服务互操作协议
（这些协议尚未定义）
统一描述、发现和集成协议 (UDDI)
简单对象访问协议 (SOAP)
扩展标注语言 (XML)
通用Internet协议 (HTTP, TCP/IP)
以下图表描述了这些协议的层次关系：
UDDI 注册使用的核心信息模型由XML Schema 定义。使用XML 是因为它提供了平台无关的数据描述并很自然的描述了数据的层次关系。而选择XML Schema 是因为它支持丰富的数据类型，便捷的描述方式及其按信息模型对数据进行验证的能力。
UDDI XML Schema 定义了四种主要信息类型，它们是技术人员在需要使用合作伙伴所提供的Web 服务时必须了解的技术信息。它们是：商业实体信息、服务信息、绑定信息和服务调用规范的说明信息。
UDDI程序员API规范分为两个逻辑部分：查询API 和发布API 。查询API 又分为两个部分:一部分被用来构造搜索和浏览UDDI 注册信息的程序，另一部分在Web服务出现错误时使用。程序员可以利用发布API创建各种类型的工具，以直接与UDDI注册中心进行交互，便于企业技术人员管理businessEntity 或tModel 结构的发布信息。
UDDI调用模型
每一个独立发布的Web服务都是使用一个bindingTemplate结构来建模的。对这个Web服务的调用通常通过缓存bindingTemplate 数据来实现。注意到这一点后，在你准备编写调用某种Web 服务的程序时，该如何使用UDDI 就很清楚了。下面列出了基本步骤：
1．编写调用远程Web 服务的程序时，程序员使用UDDI 商业注册中心(通过使用Web界面或其它基于查询API 的工具)来定位businessEntity 信息，这些信息是由(或为)提供该Web 服务的企业注册的。
2．程序员可以进一步获得更详细的businessService信息，或是得到一个完整的businessEntity结构。因为businessEntity结构包含了有关已发布的Web服务的所有信息，因此程序员只需简单地选择一个bindingTemplate 并保存留待以后使用。
3．基于Web服务在bindingTemplate的tModel中提供的调用规范的相关信息，程序员可以按照该Web服务的调用规范编写程序。
4．在运行时，程序可以按需要使用已保存下来的 bindingTemplate的信息来调用Web服务。
一般说来，只要远程Web 服务和调用它的程序都准确的实现了必要的接口(按照在tModel 中所引用的调用规范)，对远程服务的调用就一定会成功。
服务发现（Service Discovery）
1． UDDI（同上）
2． ADS
即Advertisement and Discovery of Services。这是由IBM提出的建议，它使服务提供者（service provider）能够对他们的服务进行广告宣传。它允许将这些服务的信息集中到大家熟悉的地方，而且还提供了连接内容及服务的方式。
由于ADS提供了可选择的、分散的服务公告机制，因而补充了基于注册的访问方案。这遵循了Microsoft的DISCO（Discovery of Web Services）思想，但更为先进。
|
|
发表于 2006-4-14 18:25:00