饭桶精英: WebService

Showing posts with label WebService. Show all posts

Sunday, June 27, 2010

SOAP vs REST

更多精彩请到 http://www.139ya.com

http://www.webforefront.com/archives/2005/05/rest_-_represen.html
SOAP vs. REST [ XML/HTTP ] :The Web Services debate.

There is no doubt that web services will continue to be a common practice when developing web applications, the capability of accessing business functions in a platform & device agnostic manner has made the technology a champion among J2EE, .NET, PHP and other web platforms. But even though the concept is clearcut, there seems to be two emerging camps defining how to implement a web service: SOAP and XML/HTTP (a.k.a REST-Representational State Transfer ).
[Entry continues to the left and below ad ]

Before you jump the gun on the lesser "advertised" XML/HTTP REST approach as not being a web service, the fact remains that it complies with a web service definition : The capability of accessing information in a platform transparent manner. And if you consider the thorough REST support offered by early web services adopters like Amazon and EBay, you can conclude that REST is not a fad.

The most obvious difference between both approaches is the actual payload that is transferred through the wire, which directly translates into distinct implementation details on both client & server. Lets explore the differences.

A REST design implies that a web application is equipped for returning a plain and simple XML fragment as a response to a URL request. Lets assume you make a call into the following address: http://www.yoursite.com/restapp/weather.php?city=sandiego. A REST type application would return a payload like the following snippet back to the caller:

http://www.webforefront.com/about/danielrubio/articles/techtarget/rest_design.html

REST: Simplicity in Web Services design

Linking Web service requesters and providers entails a fair amount of work for both parties, encompassing such things as agreeing on the business function to be fulfilled, the technical contract details and of course integrating the service into the grander scheme of an application. But far too often using the standardized SOAP/WSDL approach becomes overly complex in such scenarios.

There is an alternate approach to deploying a Web services compliant architecture named REST, Representational State Transfer. REST is a technique coined by Roy Fielding in the year 2000 during what was his doctoral dissertation, While it is questionable if he had the prescience to create an approach that would compete head-to-head with industry heavyweights and consortium specifications, since then the REST acronym has come to center stage in Web services design.

What is it about REST that makes it different from standard SOAP/WSDL? The simplicity in shedding some of the heavyweight requirements needed in the latter approach, which on many occasions prove unnecessary to achieving the basic functionality of a Web service.

SOA

Introduction

In my previous section we had concentrated on Design Patterns and UML which is one of the most important fundamentals for architecture interviews. One of the other areas other than both of them which needs to be stronger for architects is understanding of SOA.

Again I repeat do not think you get an architecture position by reading interview questions. But yes there should be some kind of reference which will help you quickly revise what are the definition. Just by reading these answers you get to a position where you are aware of the fundamentals. But if you have not really worked you will surely fail with scenario based questions. So use this as a quick revision rather than a shot cut.

Happy job hunting......

(B) What is SOA?

SOA stands for service oriented architecture. Before we define SOA lets first define a service. In real world service is what we pay for and we get the intended service. For instance you go to a hotel and order food. Your order first goes to the counter and then it goes to the kitchen where the food is prepared and finally the waiter serves the food.

...

Tuesday, November 10, 2009

XML Schema Standards Library

理解SOAP

理解 SOAP

发布日期 : 4/1/2004 | 更新日期 : 4/1/2004

Aaron Skonnard

DevelopMentor

2003 年 3 月

适用于：

全局 XML Web 服务结构 (GXA)
远程过程调用 (RPC)
SOAP 1.1 和 SOAP 1.2 规范
传输协议： TCP、HTTP、SMTP 和 MSMQ
Web Services Enhancements 1.0 SP1 for Microsoft .NET
XML 架构

摘要： SOAP 提供一种简单的、可扩展并且功能丰富的 XML 消息处理框架，用于定义高级别的应用程序协议，从而在分布式异构环境中提供更高的互操作性。（20 页打印页）

本页内容

简介
 SOAP 版本
 消息处理框架
 扩展性
 处理模型
 协议绑定
 HTTP 绑定
 RPC 和编码
 SOAP 类型
 小结

简介

就在不久以前，SOAP 还不过是指肥皂而已。而如今，大多数开发人员一听到这个词眼前就会浮现出一些尖括号来。 SOAP 最初代表“简单对象访问协议”。如果在几年前问任何一个人 SOAP 的含义，他们很可能这样回答：“SOAP 是用来使 DCOM 和 Corba（例如，RPC 调用）在互联网上工作”。原作者们也承认，在那时他们注重于“访问对象”，但随着时间的推移，人们希望 SOAP 能够处理更广泛的情况。因此，SOAP 规范的重心很快从对象转移到通用的 XML 消息处理框架上。

这种重心的变化给 SOAP 缩写词中的 "O" 带来了一点小问题。有意思的是，SOAP 1.2 工作组沿用了（到目前为止）SOAP 这个名称（为什么不呢？这个词太流行了），但决定不再把这个词拼出来以免误导开发人员。如今，在最新的 SOAP 1.2 规范中，其正式的定义并不提及对象：

SOAP 是一种轻量级协议，用于在分散型、分布式环境中交换结构化信息。 SOAP 利用 XML 技术定义一种可扩展的消息处理框架，它提供了一种可通过多种底层协议进行交换的消息结构。这种框架的设计思想是要独立于任何一种特定的编程模型和其他特定实现的语义。

这个定义确实体现了 SOAP 现在的主旨。 SOAP 定义了一种方法以便将 XML 消息从 A 点传送到 B 点（参见图 1）。为此，它提供了一种基于 XML 且具有以下特性的消息处理框架：1) 可扩展，2) 可通过多种底层网络协议使用，3) 独立于编程模型。以下将分别详细讨论这三种特性。

图 1. 简单的 SOAP 消息处理

首先，SOAP 可扩展性是关键所在。在这个缩写词还代表某些含义时，"S" 意味着“简单”。如果我们从 Web 中学到了一样东西，那就是，简单性总是比效率和纯技术更重要，因而互操作性成败的关键，就在于必须绝对要求简单性。简单性仍然是 SOAP 的主要设计目标之一，这一点的例证就是 SOAP 缺少分布式系统的很多特性（如安全性、路由和可靠性等）。 SOAP 定义了一种通信框架，允许以分层扩展的形式随着时间推移而加入这些特性。 Microsoft、IBM 和其他软件厂商正在积极开发一个 SOAP 扩展的通用套件，该套件将加入大多数开发人员期待的特性。这一计划被称为全局 XML Web 服务结构 (GXA)Microsoft 已经发布了针对若干 GXA 规范的一个参考实现，并将其命名为 Web Services Enhancements 1.0 SP1 for Microsoft .NET (WSE)。

其次，SOAP 可在任何传输协议（诸如 TCP、HTTP、SMTP，甚至是 MSMQ）上使用（参见图 1）。然而，为了保持互操作性，需要定义一些标准协议绑定以便草拟用于每种环境的规则。 SOAP 规范提供了一种用于定义任意协议绑定的灵活框架，并且由于 HTTP 的使用极为广泛，它现已为 HTTP 提供了一种显式绑定。

第三，SOAP 允许任何编程模型，并且不依赖于 RPC。大多数开发人员立刻将 SOAP 与对分布式对象进行的 RPC 调用等效起来（因为 SOAP 最初就是关于“访问对象”的），但实际上，基本的 SOAP 模型更接近于传统的消息处理系统，如 MSMQ。 SOAP 定义了一种模型以便处理个别的单向消息。你可以将多条消息组合成一条整体的消息交换。图 1 说明了一种简单的单向消息，其中发送方不会收到响应。但是，接收方可以向发送方发回一条响应（参见图 2）。 SOAP 允许使用任何数量的消息交换模式 (MEP)，请求/响应只是其中一种。其他示例包括要求/响应（与请求/响应相对）、通知和长期运行的点对点对话等。

图 2. 请求/响应消息交换模式

开发人员经常将请求/响应与 RPC 混为一谈，而实际上二者之间的差别很大。 RPC 使用请求/响应，但请求/响应不一定就是 RPC。 RPC 是一种允许开发人员进行方法调用的编程模型。 RPC 需要将方法签名转换成 SOAP 消息。鉴于 RPC 的广泛应用，SOAP 草拟了一项协议，以便将 RPC 用于 SOAP（参见本文稍后的RPC 和编码一节）。

具备这三种主要特性，SOAP 消息处理框架就促进了在异构环境中交换 XML 消息，而在这类环境中，互操作性长久以来都是极大的挑战。

返回页首

SOAP 版本

从第一个发布的 SOAP 规范到如今被广泛实施的 SOAP 1.1，很多方面都发生了改变，从琐碎的细节到思想的重大转变。 SOAP 1.1 被提交给 W3C，并于 2000 年 5 月被发布为 Note。由于 SOAP 1.1 未能通过 W3C 过程的严格审核，"W3C Note" 状态使其还停留在仅是一个好主意的层次，但当完成时，它将最终达到“推荐”状态。然而，由于如今 SOAP 1.1 得到了大小厂商如此广泛的支持，它仍然被认为是事实上的标准。

W3C 使用 SOAP 1.1 Note 作为新 XML 协议工作组的基础，负责产生下一版本的 SOAP，目前命名为SOAP 1.2。 SOAP 1.2 当前是一种“候选推荐方案”，意味着它正处在实施阶段且离最后完成为期不远。一旦 SOAP 1.2 成为“推荐方案”，它极有可能很快获得厂商的支持。

在 SOAP 1.2 发布之后，为了提供向后兼容性，厂商应该继续支持 SOAP 1.1。 SOAP 版本控制基于 XML 命名空间。 SOAP 1.1 由 http://schemas.xmlsoap.org/soap/envelope/ 命名空间标识，而 SOAP 1.2 由 http://www.w3.org/2002/12/soap-envelope 命名空间标识（尽管当其成为推荐方案时，这也将改变）。

有关每个版本的命名空间名称和规范所在位置，请参见表 1。在本文的剩余部分中，我们将讲述 SOAP 1.1 最重要的一些方面。要了解两个版本之间完整的更改列表，请查看当前的 SOAP 1.2 规范。

表 1. SOAP 版本信息

SOAP 1.1
命名空间名称
规范位置
SOAP 1.2
命名空间名称
规范位置

返回页首

消息处理框架

SOAP 规范的核心部分就是消息处理框架。 SOAP 消息处理框架定义了一整套 XML 元素，用以“封装”任意 XML 消息以便在系统之间传输。

该框架包括以下核心 XML 元素： Envelope、Header、Body 和 Fault，所有这些都来自 SOAP 1.1 中的 http://schemas.xmlsoap.org/soap/envelope/ 命名空间。以下代码中提供了 SOAP 1.1 的完整 XML 架构定义，以供在阅读下文时参考。我个人认为，每次让自己熟悉各种 XML 结构时，检查一下该架构是颇有帮助的。

SOAP 1.1 XML 架构定义

 xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"        
 targetNamespace="http://schemas.xmlsoap.org/soap/envelope/"
>
   
 
 
 
   
     
     
           maxOccurs="unbounded" processContents="lax" />
   
       processContents="lax" />
 

 
 
   
           maxOccurs="unbounded" processContents="lax" />
   
       processContents="lax" />
 

 
 
   
           maxOccurs="unbounded" processContents="lax" />
   
       processContents="lax" />
 

     
 
   
    
    
     
   
  
 
 

 
   
 

   type="tns:encodingStyle" />
 
   
 

 
 
   
     
     
           minOccurs="0" />
           minOccurs="0" />     
   
 

 
   
           maxOccurs="unbounded" processContents="lax" />
   
       processContents="lax" />

如果检查一下 Envelope 的 complexType 定义，你很快就能了解这些元素相互之间是如何关联的。以下消息模板说明了 SOAP Envelope 的结构：

  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

Envelope 元素始终是 SOAP 消息的根元素。这就便于应用程序识别“SOAP 消息” — 只要检查一下根元素的名称即可。通过检查 Envelope 元素的命名空间，应用程序也可确定所使用的 SOAP 版本。

Envelope 元素包含一个可选的 Header 元素（有关详细信息，参见可扩展性一节），后跟一个必要的 Body 元素。 Body 元素代表了该消息的有效内容。它是一种通用容器，因为它可包含来自任何命名空间的任意数量的元素。这就是试图发送数据的最终目的地。

例如，以下的 SOAP 消息代表了一个在银行帐户之间转帐的请求：

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

 
  22-342439
  98-283843
  100.00

如果接收方支持请求/响应，且能够成功地处理该消息，它应向最初的发送方返回另一条 SOAP 消息。在这种情况下，响应信息也应包含在 Body 元素中，如下例所示：

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

   xmlns:x="urn:examples-org:banking">
  
   
    22-342439
    33.45
   
   
    98-283843
    932.73

该消息处理框架还定义了一个名为Fault 的元素，用于在发生错误时在 Body 元素中表示错误。这是不可缺少的，因为如果没有一种标准的错误表示方法，每个应用程序将不得不自己创建，从而使得通用基础结构不可能区分成功和失败。以下示例 SOAP 消息中包含了一个 Fault 元素，指明在处理该请求时发生了“Insufficient Funds（资金不足）”错误：

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

 
  soap:Server
  Insufficient funds
  
   
    22-342439
    100.00
    89.23

Fault 元素必须包含一个 faultcode，后跟一个 faultstring 元素。 faultcode 元素使用一种符合命名空间的名称对错误进行分类，而 faultstring 元素提供一种对错误可读的解释（类似于 HTTP 的工作方式）。表 2 简要地说明了 SOAP 1.1 所定义的各种错误码（所有这些代码都包含在 http://schemas.xmlsoap.org/soap/envelope/ 命名空间中）。

Fault 元素也可能包含一个 detail 元素，以便提供该错误的细节，这样可以帮助客户端诊断问题，特别是在 Client 和 Server 错误码的情况下。

表 2. SOAP 1.1 错误码

名称

VersionMismatch
MustUnderstand
Client
Server

含义

处理方发现 SOAP Envelope 元素的命名空间是无效的。
处理方没有理解或服从 SOAP Header 元素的某个直接子元素，而该子元素包含一个值为 "1" 的 SOAP mustUnderstand 属性。
Client 类的错误表明消息的格式错误或者不包含适当的信息，因而不能成功。这通常表明，如果不对该消息做出更改，就不应该重发该消息。
Server 类的错误表明该消息未能得到处理的原因与消息的内容并没有直接关系，而是跟该消息的处理有关。例如，处理过程可能包括与某个上游处理器的通信，但该处理器没有响应。如果在稍后重发，该消息可能会成功。

现在，假设你想在初始的消息中增加一些验证信息，以便接收方能够确定发送方是否有足够的权限来执行传输。要达到这一目的，一种方法就是在主体中添加凭证信息，如下所示：

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

 
  22-342439
  98-283843
  100.00
  
  
   dave
   evad

如果使用这种方法，每项需要验证的操作都必须处理这些凭证。这也意味着其他需要安全性的应用程序必须开发自己的解决方案以解决这个问题；归根结底，这将损害互操作性。对于诸如安全性等公共需要，定义各方都同意的标准 SOAP 标头将更有意义。然后，各厂商可以在其通用的 SOAP 基础结构中建立对扩展功能的支持，这样各方皆赢。这种方法可提高开发人员的生产力，同时有助于确保更高级别的互操作性。而这正是 SOAP 扩展性模型设计要实现的目标。

返回页首

扩展性

大多数现有的协议都区分控制信息（例如，标头）和消息有效负载。在这方面，SOAP 也不例外。 SOAP Header 和 Body 元素在易于处理的 XML 世界中也进行同样的区分。除了易用性之外，可扩展 Envelope 的关键优势在于它可用于任何通讯协议。

在各种应用程序协议中（如 HTTP、SMTP 等）标头总是具有重要的意义，因为标头允许连网两端的应用程序就所支持命令的具体行为进行协商。尽管 SOAP 规范本身并不定义任何内置的标头，标头将逐渐在 SOAP 中扮演同等重要的角色。随着 GXA 日趋成熟及 SOAP 标头的标准化，开发人员能够更方便地定义丰富的应用程序协议，而不必每次都重新开始。

与 Body 元素类似，Header 元素是控制信息的通用容器。其中可包含来自任何命名空间（除 SOAP 命名空间之外）的任意数量的元素。放置在 Header 元素中的各个元素被称为标头块。 如同其他协议一样，标头块中包含的信息应该能够影响有效负载的处理。因此，这里正适于放置诸如凭证一类的元素，以帮助控制对操作的访问：

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

 
 
  dave
  evad
 


 
  22-342439
  98-283843
  100.00

我们也可以利用一个名为 mustUnderstand 的全局 SOAP 属性对标头块进行标注，以指明接收方在处理该消息之前是否需要理解标头。以下示例说明了如何要求对凭证标头进行处理：

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

 
   soap:mustUnderstand="1"
 >
  dave
  evad
 

...

如果某个标头块被标注为 mustUnderstand="1"，而接收方未设计为支持给定的标头，则不应处理该消息，而应该向发送方返回一条 Fault （带有 soap:MustUnderstand 状态码）。如果 mustUnderstand="0" 或者没有提供 mustUnderstand 属性，则接收方可以忽略相应的标头块并继续进行处理。在整个 SOAP 处理模块中，mustUnderstand 属性起着核心作用。

返回页首

处理模型

SOAP 定义了一种处理模型，它大致规定了从 SOAP 发送方传输到 SOAP 接收方的过程中对 SOAP 消息的处理规则。图 1说明了最简单的 SOAP 消息处理方案，其中一个应用程序（SOAP 发送方）向另一个应用程序（SOAP 接收方）发送一条 SOAP 消息。

但是，处理模型允许使用一些更有趣的结构（如图 3 中的结构），这类结构中包含多个中间节点。在下文中，将使用 SOAP 节点 这个术语指代任何要处理 SOAP 消息的应用程序，不管是最初的发送方、中间节点还是最终的接收方；否则，我将明确指出并使用相应的准确术语。

图 3. 高级 SOAP 消息处理

中间节点位于最初的发送方和最终的接收方之间，并截获 SOAP 消息。中间节点可同时作为 SOAP 发送方和 SOAP 接收方。中间节点使得有可能设计一些有趣且灵活的网络体系结构，而这些网络结构能受到的消息内容影响。 SOAP 路由就是一个很好的示例，它很大程度上利用了 SOAP 中间节点（有关 SOAP 路由的详细信息，请查看 Routing SOAP Messages with Web Services Enhancements 1.0）。

在处理消息时，SOAP 节点承担一个或者多个角色 (role)，这些角色会影响如何处理 SOAP 标头。各个角色被赋予独特的名称（以 URI 的形式），以便在处理过程中能够识别这些角色。当 SOAP 节点接收到一条要处理的消息时，它首先必须确定要假定哪些角色。它可以检查该 SOAP 消息以帮助确定。

一旦 SOAP 节点确定了要扮演的角色，它随后必须处理针对其角色之一的所有必要标头（标记为mustUnderstand="1" ）。 SOAP 节点也可选择处理针对其角色之一的任何可选标头（标记为 mustUnderstand="0"）。

SOAP 1.1 只定义了一个名为 http://schemas.xmlsoap.org/soap/actor/next 的角色（简写为 next）。每个 SOAP 节点都必须承担 next 角色。因此，当 SOAP 消息到达任一给定的 SOAP 节点时，该节点必须处理针对 next 角色的所有必要标头，它可以选择处理针对该 next 角色的可选标头。除 next 外，SOAP 1.2 定义了另外一些角色（参见表 3），且应用程序也可以定义自定义角色。

SOAP 标头通过全局 actor 属性（在 SOAP 1.2 中该属性名为 role ）来指定具体的角色。如果不存在 actor 属性，则标头默认地指向最终的接收方。以下 SOAP 消息说明了如何使用 actor：

 xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 
      soap:actor="http://schemas.xmlsoap.org/soap/actor/next"
   soap:mustUnderstand="1"
   >
   ...

由于 wsrp:path 标头被指定为 next 角色且被标记为必要的 (mustUnderstand="1")，因此接收到此消息的第一个 SOAP 节点必须根据该标头块的规范来处理此消息，在这种情况下为 WS-Routing。如果 SOAP 节点不理解针对其角色之一的某个必要的标头，则它必须产生一个带 soap:MustUnderstand 状态码的 SOAP 错误，并停止处理。 SOAP Fault 元素提供了faultactor 子元素，以指定在消息路径中哪个节点导致了该错误的发生。faultactor 属性的值是一个 URI，用以标识导致该错误的 SOAP 节点。

如果 SOAP 节点成功地处理了一个标头，则它必须从消息中删除该标头。 SOAP 节点可以再插入标头，但是这样做会改变合同方 — 它现在处于当前节点与该标头所指向的下一节点之间。如果 SOAP 节点恰好是最终的接收方，则它还必须处理 SOAP 主体。

表 3. SOAP 1.2 角色

SOAP 角色名称

说明

每个 SOAP 中间节点和最终的 SOAP 接收方必须 (MUST) 扮演此角色，并可以 (MAY) 另外承担零个或多个其他 SOAP 角色。
SOAP 节点绝不可以 (MUST NOT) 扮演此角色。
要将某个 SOAP 节点确立为最终的接收方，该 SOAP 节点必须 (MUST) 扮演此角色。 SOAP 中间节点绝不能 (MUST NOT) 扮演此角色。

返回页首

协议绑定

图 3中一个有趣之处是 SOAP 允许通过多种底层协议进行消息交换。由于 SOAP 消息处理框架独立于底层协议，每个中间节点可以选择使用不同的通信协议而不会影响 SOAP 消息。然而，为了确保各种 SOAP 应用程序和基础结构之间高级别的互操作性，标准的协议绑定是必要的。

一种具体的协议绑定准确地定义了应该如何利用给定的协议来传输 SOAP 消息。换言之，它详细定义了 SOAP 如何适用于另一协议的范围，该协议很可能具有自己的消息处理框架以及多种标头。协议绑定实际所定义的内容很大程度上取决于该协议的功能和选项。例如，针对 TCP 的协议绑定应很大程度不同于针对 MSMQ 或针对 SMTP 的协议绑定。

SOAP 1.1 规范仅规范化了一种用于 HTTP 的协议绑定（由于 HTTP 的广泛使用）。 SOAP 已经用于 HTTP 之外的很多协议，但是其实现并未遵循标准化的绑定。当你尝试与利用相同协议的其他 SOAP 实施进行集成时，只要准备好处理各种互操作性方面的问题，超前一点而不使用标准的协议绑定也未尝不可。

返回页首

HTTP 绑定

HTTP 协议绑定定义了在 HTTP 上使用 SOAP 的规则。 SOAP 请求/响应自然地映射到 HTTP 请求/协议模型。图 4 说明了 SOAP HTTP 绑定的很多细节。

图 4. SOAP HTTP 绑定

HTTP 请求和响应消息的 Content-Type 标头都必须设为 text/xml （在 SOAP 1.2 中是 application/soap+xml）。对于请求消息，它必须使用 POST 作为动词，而 URI 应该识别 SOAP 处理器。 SOAP 规范还定义了一个名为 SOAPAction 的新 HTTP 标头，所有 SOAP HTTP 请求（即使是空的）都必须包含该标头。 SOAPAction 标头旨在表明该消息的意图。对于 HTTP 响应，如果没有发生任何错误，它应该使用 200 状态码，如果包含 SOAP 错误，则应使用 500。

返回页首

RPC 和编码

尽管 SOAP 规范已日渐远离对象，它仍然定义了一种约定，以便利用上述的消息处理框架来封装并交换 RPC 调用。定义一种标准的方法将 RPC 调用映射到 SOAP 消息，这使得在运行时基础结构可以在方法调用和 SOAP 消息之间自动转换，而不用围绕 Web 服务平台重新设计代码。

要利用 SOAP 进行方法调用，基础结构需要以下信息：

1.终结点位置 (URI)
2.方法名称
3.参数名称/值
4.可选的方法签名
5.可选的标头数据

这些信息可以通过多种方法来传输，包括类型库、IDL 文件，或者，更好的是 WSDL 文件。 SOAP RPC 绑定定义了如何在 SOAP 主体中封装并表示这些信息。为此，RPC 绑定首先定义如何将方法签名映射到简单的请求/响应结构，然后将这些结构以 XML 进行编码。 RPC 绑定规定将以一个按照方法命名的 struct 来模拟该方法调用。该结构将包含对应于每个 [in] 或 [in/out] 参数的一个访问器，访问器的名称与参数名相同，其次序由消息签名确定。方法响应也将作为一个结构来建模。结构的名称无关紧要，尽管约定是使用方法名后跟 "Response"（例如，对于 add 操作，方法响应名应该相应为 addResponse）。响应结构包含一个用于返回值的访问器（其名称在 SOAP 1.1 中无关紧要，但在 SOAP 1.2 必须是 rpc:result），其后是针对每个 [out] 或 [in/out] 参数的访问器。

让我们来看一个示例。假设 add 操作具有以下的 C# 方法签名：

double add(ref double x, double y)

根据刚才所说明的 RPC 绑定规则，代表该方法调用的请求结构应如下建模：

struct add {
 double x;
 double y;
}

而响应结构如下：

struct addResponse {
 double result;
 double x;
}

现在的问题是：应该如何将这些结构映射到 XML(R) SOAP 规范定义了一组编码规则，专门用于此用途。 SOAP 编码规则大致阐述了如何将当今最常用的数据结构（如结构和数组）映射到普通的 XML 格式。根据 SOAP 编码规则，以上的请求结构应映射到以下 XML 消息（这将放在 SOAP 主体中）：


 33
 44

且上述请求的响应消息将映射到以下 XML 消息（这个消息将进入响应消息的主体）：


 77
 33

XML 架构的相关工作刚刚开始，SOAP 编码规则即已创立。既然 XML 架构已经完成，开发人员可以简单地提供文字的 XML 架构定义，从而准确指定应该如何以 XML 来格式化请求/响应消息。由于利用 XML 架构定义更易于获得互操作性，因此大多数开发人员已经决定完全摒弃 SOAP 编码规则。实际上，自 SOAP 1.2 起，SOAP 规范不再正式要求支持 SOAP 编码规则。从现在起，最好避免使用 SOAP 编码规则，有关此中原由的全面讨论，请查看关于 SOAP 编码的讨论一文。

尽管 SOAP RPC 绑定和编码规则为那些不愿意涉及诸如 XML 架构和 WSDL 等的应用程序提供了一个很好的 SOAP 集成层，因为 RPC 绑定和编码规则易于导致互操作性方面的问题，它们基本上已经失宠于 Web 服务社区。

返回页首

SOAP 类型

要重申的是，如今有两种基本类型的 SOAP 消息处理：文档和 RPC。文档类型指出主体只是包含一个 XML 文档，而发送方和接收方都必须遵循该文档的格式。另一方面，RPC 类型指出主体中包含某个方法调用的 XML 表示，正如刚才所述。

两种方法可用于确定如何将数据序列化到主体中：使用文字的 XML 架构定义和使用 SOAP 编码规则。利用前一种方法，架构定义逐字确定了主体的 XML 格式，不具有二义性。然而，利用后一种方法，SOAP 处理器必须在运行时遍历各种 SOAP 编码规则以确定主体正确的序列化。很显然，这种方法更易于导致错误和互操作性方面的问题。

最常见的情形是在使用文档类型时也使用文字架构定义（称为文档/文字），以及在使用 SOAP 编码规则时使用 RPC 类型（称为 rpc/编码）。文档/编码和 rpc/文字也是可能的，但并不常见，也没有太大意义。大多数 Web 服务平台都集中于文档/文字类型，将其作为发展的主要用例，且是现今 Microsoft ASP.NET WebMethod 框架的默认设置。

返回页首

小结

SOAP 定义了一种简单而可扩展的 XML 消息处理框架，它可以通过多种协议用于各种不同的编程模型，尽管此规范中规范化了如何将 SOAP 用于 HTTP 和 RPC 调用。 SOAP 还定义了一个完整的处理模型，大致规定了当消息沿路径传送时如何对其进行处理。总的来说，SOAP 提供了一个功能丰富而灵活的框架以便定义高级应用程序协议，这些协议可在分布式异构环境中提供更好的互操作性。

Thursday, June 11, 2009

web service links

更多精彩请到 http://www.139ya.com

http://www.webxml.com.cn/zh_cn/index.aspx

腾讯QQ在线状态 WEB 服务
Endpoint: http://www.webxml.com.cn/webservices/qqOnlineWebService.asmx
Disco: http://www.webxml.com.cn/webservices/qqOnlineWebService.asmx?disco
WSDL: http://www.webxml.com.cn/webservices/qqOnlineWebService.asmx?wsdl

通过输入QQ号码（String）检测QQ在线状态。返回数据（String）Y = 在线；N = 离线；E = QQ号码错误......
需要技术支持请：联系我们，欢迎技术交流。 QQ：8698053

Email 电子邮件地址验证 WEB 服务
Endpoint: http://www.webxml.com.cn/WebServices/ValidateEmailWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/ValidateEmailWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/ValidateEmailWebService.asmx?wsdl
Email 电子邮件地址验证 WEB 服务

Email 电子邮件地址验证 Web Service，通过查找给定的电子邮件域的邮件服务器和通过向邮件服务器发送数据来判断电子邮件地址正确与否。
此Email地址验证Web Service请不要用于任何商业目的，若有需要请联系我们

中国股票行情分时走势预览缩略图
Endpoint: http://www.webxml.com.cn/webservices/ChinaStockSmallImageWS.asmx
Disco: http://www.webxml.com.cn/webservices/ChinaStockSmallImageWS.asmx?disco
WSDL: http://www.webxml.com.cn/webservices/ChinaStockSmallImageWS.asmx?wsdl

中国股票行情分时走势预览缩略图 WEB 服务（支持深圳和上海股市的全部基金、债券和股票），数据即时更新。
返回数据：2种大小可选择的股票GIF分时走势预览缩略图字节数组和直接输出该预览缩略图。

外汇-人民币即时报价 WEB 服务
Endpoint: http://www.webxml.com.cn/WebServices/ForexRmbRateWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/ForexRmbRateWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/ForexRmbRateWebService.asmx?wsdl

外汇-人民币即时报价 WEB 服务，报价数据即时更新。外汇-人民币即时报价 WEB 服务仅作为用户获取信息之目的，并不构成投资建议。
支持人民币对：美元、欧元、英镑、日元、港币、加拿大元、新西兰元、新加坡元、瑞士法郎、瑞典克朗、泰国铢、挪威克朗、澳门元、澳大利亚元、丹麦克朗、菲律宾比索、清算瑞士法郎等的兑换即时报价。

即时外汇汇率数据 WEB 服务
Endpoint: http://www.webxml.com.cn/WebServices/ExchangeRateWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/ExchangeRateWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/ExchangeRateWebService.asmx?wsdl

即时外汇汇率数据 WEB 服务，数据即时更新。此外汇汇率数据 WEB 服务支持29种以上基本汇率和交叉汇率即时外汇汇率数据，
返回包括：代码、货币名称、最新价、涨跌%、涨跌金额、开盘价、最高价、最低价、震幅%、买入价、卖出价、涨跌颜色和数据时间。实例

中国股票行情数据 WEB 服务（支持深圳和上海股市的基金、债券和股票）
Endpoint: http://www.webxml.com.cn/WebServices/ChinaStockWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/ChinaStockWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/ChinaStockWebService.asmx?wsdl
中国股票行情数据 WEB 服务（支持深圳和上海股市的基金、债券和股票）

中国股票行情数据 WEB 服务，数据即时更新。
输出GIF分时走势图、日/周/月K线图、及时行情（股票名称、行情时间、最新价、昨收盘、今开盘、涨跌额、最低、最高、涨跌幅、成交量、成交额、竞买价、竞卖价、委比、买一 - 买五、卖一 - 卖五）。

国内飞机航班时刻表 WEB 服务公用事业
Endpoint: http://www.webxml.com.cn/webservices/DomesticAirline.asmx
Disco: http://www.webxml.com.cn/webservices/DomesticAirline.asmx?disco
WSDL: http://www.webxml.com.cn/webservices/DomesticAirline.asmx?wsdl

国内飞机航班时刻表 Web Service 提供：
通过出发城市和到达城市查询飞机航班、出发机场、到达机场、出发和到达时间、飞行周期、航空公司、机型等信息。

中国电视节目预告（电视节目表） WEB 服务公用事业
Endpoint: http://www.webxml.com.cn/webservices/ChinaTVprogramWebService.asmx
Disco: http://www.webxml.com.cn/webservices/ChinaTVprogramWebService.asmx?disco
WSDL: http://www.webxml.com.cn/webservices/ChinaTVprogramWebService.asmx?wsdl
中国电视节目预告（电视节目表） WEB 服务

中国电视节目预告 Web 服务，数据准确可靠，提供全国近800个电视拼道一个星期以上的节目预告数据。
一、获得支持的省市（地区）和分类电视列表；
二、通过省市ID或分类电视ID获得电视台列表；
三、通过电视台ID获得该电视台频道名称；四、通过频道ID获得该频道节目列表。实例

火车时刻表 WEB 服务（第六次提速最新列车时刻表）公用事业
Endpoint: http://www.webxml.com.cn/WebServices/TrainTimeWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/TrainTimeWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/TrainTimeWebService.asmx?wsdl
火车时刻表 WEB 服务（第六次提速最新列车时刻表）

火车时刻表 WEB 服务提供：站站查询；车次查询；车站所有车次查询。
数据来源时间：2007-5-14 第六次提速最新列车时刻表。
本火车时刻表 WEB 服务提供的列车时刻表数据仅供参考，如有异议以当地铁路部门颁布为准。实例

中文 <-> 英文双向翻译 WEB 服务获得标准数据
Endpoint: http://www.webxml.com.cn/WebServices/TranslatorWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/TranslatorWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/TranslatorWebService.asmx?wsdl
英文双向翻译 WEB 服务" src="http://www.webxml.com.cn/pro_images/b2c5f6c4-70b4-4f27-90a5-b13d7442a53b.gif" id="R1_ctl03_wsImage" alt="中文 <-> 英文双向翻译 WEB 服务" style="border-width: 0px;" align="left">中文 <-> 英文双向翻译 WEB 服务，本词典库中大部分单词是由程序根据词频和英<->中单词间相互关联程度自动生成，难免存在有解释错误和牵强的地方请大家谅解。

中文简体字<->繁体字转换 WEB 服务计算和单位换算
Endpoint: http://www.webxml.com.cn/WebServices/TraditionalSimplifiedWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/TraditionalSimplifiedWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/TraditionalSimplifiedWebService.asmx?wsdl
繁体字转换 WEB 服务" src="http://www.webxml.com.cn/pro_images/4112f275-7637-44b6-8afc-c4c7904cd343.gif" id="R1_ctl04_wsImage" alt="中文简体字<->繁体字转换 WEB 服务" style="border-width: 0px;" align="left">中文简体字<->繁体字转换 WEB 服务，此Web Services请不要用于任何商业目的，若有需要请联系我们，欢迎技术交流。
使用本站 WEB 服务请注明或链接本站：http://www.webxml.com.cn/ 感谢大家的支持！

验证码图片 WEB 服务支持中文、字母、数字图像和多媒体
Endpoint: http://www.webxml.com.cn/WebServices/ValidateCodeWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/ValidateCodeWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/ValidateCodeWebService.asmx?wsdl
验证码图片 WEB 服务支持中文、字母、数字

验证码图片 WEB 服务，输出PNG高品质格式的验证码图片和字节流，字符和字符之间的间距和高度随机产生，提高了验证码的安全性。
支持中文、字母、数字验证码图片。[演示1] [演示2]

中国邮政编码 <-> 地址信息双向查询/搜索 WEB 服务获得标准数据
Endpoint: http://www.webxml.com.cn/WebServices/ChinaZipSearchWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/ChinaZipSearchWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/ChinaZipSearchWebService.asmx?wsdl
地址信息双向查询/搜索 WEB 服务" src="http://www.webxml.com.cn/pro_images/0780ae9c-1692-4904-b023-978c74319de7.gif" id="R1_ctl02_wsImage" alt="中国邮政编码 <-> 地址信息双向查询/搜索 WEB 服务" style="border-width: 0px;" align="left">中国邮政编码搜索 WEB 服务包含中国全部邮政编码共计187285条记录，是目前最完整的邮政编码数据，精确到乡镇级、城市精确到街道，支持邮政编码<->城市、乡镇、街道的双向查询。
此邮政编码查询仅供参考，如邮政编码或地址有变动请以当地邮局为准，也请及时通知我们进行更正。

随机英文、数字和中文简体字 WEB 服务其他 Web Services
Endpoint: http://www.webxml.com.cn/WebServices/RandomFontsWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/RandomFontsWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/RandomFontsWebService.asmx?wsdl

随机英文、数字和中文简体字 WEB 服务，可用于验证码[演示1] [演示2]及其他方面，这里支持最多不超过8个随机中文简体字，10个随机英文、数字输出（一般也够了:P），如需要更多输出请联系我们。

IP地址来源搜索 WEB 服务（是目前最完整的IP地址数据）获得标准数据
Endpoint: http://www.webxml.com.cn/WebServices/IpAddressSearchWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/IpAddressSearchWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/IpAddressSearchWebService.asmx?wsdl
IP地址来源搜索 WEB 服务（是目前最完整的IP地址数据）

IP地址搜索 WEB 服务包含中国和国外已知的IP地址数据，是目前最完整的IP地址数据，记录数量现已超过30万条并还在不断更新和增加中，感谢纯真网络提供IP地址数据来源。因IP地址在不断变化，此IP地址数据查询仅供参考，如发现IP地址查询错误请向纯真网络报告。

天气预报Web服务，数据来源于中国气象局公用事业
Endpoint: http://www.webxml.com.cn/WebServices/WeatherWebService.asmx
Disco: http://www.webxml.com.cn/WebServices/WeatherWebService.asmx?disco
WSDL: http://www.webxml.com.cn/WebServices/WeatherWebService.asmx?wsdl
天气预报Web服务，数据来源于中国气象局

天气预报Web服务数据来源于中国气象局 http://www.cma.gov.cn/ ，数据每2.5小时左右自动更新一次，准确可靠。
包括 340 多个中国主要城市和 60 多个国外主要城市三日内的天气预报数据。实例

Monday, May 4, 2009

WebService 附件

Wednesday, April 29, 2009

WebService

WebService 的一些基本概念

更多精彩请到 http://www.139ya.com

转自： http://blog.csdn.net/dragondwy/archive/2009/01/06/3722397.aspx

Endpoint, Namespace,RPC/Document Type

http://www.ttdev.com/SimpleService 这个webservice全名就是所谓的"endpoint"

RPC 型的Web Service 方法定义

Document 类型Webservice

注释：

http://ttdev.com/ss 就是namespace, 并无特别意义，只需要global 唯一.
namespace 不用于endpoint, endpoint 是一个存在的location;而namespace就是一个表示unique ID.
可以任意移动webservice的位置，改变Server，也就是说变更endpoint；但是方法(operation)的namespace不可以改变。

不同点在哪？最大不同就是RPC不能通过Schema 来校验，而document 类型是可以的。因此document 类型webservice成为主流。
"WS-I (web services interoperability organization)" 组织规定只使用document类型 web services。

Port type

事实上，一个Web service 并不直接包含一组operation(方法)。方法是被组成一个或多个"Port Types"。
一个Port type 类似java 类，每个operation 类似java class中的静态方法。
比如，一个web service中，把所有string相关操作组成 stringUtil Port type, 把日期相关的操作组成dateUtil Port Type.
所有 port type的命名必须是QName. （QName 就是需要有 namespace和localname的全名称，见上篇的图示）

Binding

一个 port type 允许使用不同的信息格式访问，比如SOAP(Simple Object Access Protocal)或
普通文本格式(plain text fomat):

concat(s1='abc', s2='123')

除了信息格式，每个port type还允许使用信息通过HTTP Post 请求或者通过 email方式传送。

因此，每个被支持的信息格式和信息传送方式组合，就叫做 binding.
最常见的binding就是 SOAP+HTTP.

Port

假如很多人使用你的web service,你决定把你的web service部署到3台机器上(C1,C2,C3)。
部署策略为：采用binding1于C1,C2,C3 机器上；采用binding2于C3机器上.
此时，我们就说，你一共有四个port, 其中3个port使用用binding1, 1个port使用binding2.

看图理解的快

需要注意的是, 每个port的方法实现可以使用不同的软件，语言，比如port1用 java 写，port2用C#写，都无所谓，但都必须实现port type 中的operation,已经binding1定义的
message format 和传输方式。

因此，为了表达这个部署的结构信息，在Web service 接口定义中port的信息

Target Namespace

上面2篇中的例子看到，在web service中，无论是operation 名,还是port type的名字，都用了同一个namespace.
默认情况下，一个web service使用单一namespace来命名各种对象。这个namespace，称为web service 的Target Namespace

Namespace 的命名必须是URI (Uniform Resource Identifer), 而URI有分2种类型.
Web servie 中的target namespace, 使用两种URI都可以。

URL	http://blog.csdn.net/dragondwy
URN	urn:: sample: urn:isbn:1-23-456789-0

WSDL

上面图中的内容已经充分的描述出一个web service 设计。那么这中描述Web service的语言，就叫做WSDL(Web Services Description Language)

总结

Web service 是平台无关的，语言无关的，可以通过internet访问。
一个 Web service 具有一个或多个ports.每个port 是指部署在某个网络地址上的一个binding.
这个网络地址叫做endpoint. 一个binding是指某个port type使用的特有信息格式和特有的传输协议的结合。
一个port type可以包含一个或多个operations. 每个operation 可以有输入信息(方法调用和输入参数)和输出信息(返回值)。
每个信息包含一个或多个parts. 每个part都是一个在web service的schema中定义好的element。
所有内容通过WSDL描述。

如果要调用以讹RPC 类型的web service, 需要创建XML element, 其中包含operation 名字，所有输入信息(part)的element.等内容。
而调用document 类型的web service，只需要发送一个输入信息part 的内容即可。
因为RPC类型 web service中的XML element没定义在任何schema中，因此没有校验机制。
所以document 类型的web service是主流，为了更好地协作性考虑，应该使用这种类型。

web service，每个ports,bindings, port types, operations 都有一个QName作为唯一标识符。
一个QName包含 local part和 XML namespace两部分。
一个XML namespace是一个全局唯一URI.
默认情况下，web service中所有这些对象的命名都是用单一的Target namespace.

URI有两种类型：URL 和 URN.
URN 具有这样的格式 urn::.
XML namespace可以任意使用URL和URN格式，他们的区别是，URL 往往表示某个对象的位置，而URN就是一个纯粹的对象标志符号。
You can use either as an XML namespace. The only
difference is that a URL is suggesting that it is the location of an object, while a
URN is purely an id of the object.

Thursday, April 23, 2009

WebService 概念

更多精彩请到 http://www.139ya.com

转自： http://blog.csdn.net/zhangjian01361/archive/2006/08/24/1113779.aspx

1.定义
由两部分组成
·SOAP--Web Service之间的基本通信协议。
·WSDL--Web Service描述语言，它定义了Web Service做什么，怎么做和查询的信息。

2.简单的Web Service实现
包含四个基本步骤
·创建Web Service的商业逻辑（通常是一些Java类）
·将这些Java类部署到一个SOAP服务器上
·生成客户访问代码
·部署客户应用
注意：WSDL等文件的生成通常是利用厂商提供的工具来完成

3.SOAP

Soap 是 XML Web Service 的通信协议。当把 SOAP 描述为一种通信协议时，多数人都会想到 DCOM 或 CORBA，并且会问“SOAP 如何激活对象？”或“SOAP 使用什么样的命名服务？”等问题。虽然 SOAP 实现方案可能会包含上述内容，但 SOAP 标准并未对其进行规定。SOAP 一种规范，用来定义消息的 XML 格式 - 这是规范中所必需的部分。包含在一对 SOAP 元素中的、结构正确的 XML 段就是 SOAP 消息。这是不是很简单？

SOAP 规范的其他部分介绍如何将程序数据表示为 XML，以及如何使用 SOAP 进行远程过程调用 (RPC)。这些可选的规范部分用于实现 RPC 形式的应用程序，其中客户端将发出一条 SOAP 消息（包含可调用函数，以及要传送到该函数的参数），然后服务器将返回包含函数执行结果的消息。目前，多数 SOAP 实现方案都支持 RPC 应用程序，这是因为习惯于开发 COM 或 CORBA 应用程序的编程人员熟悉 RPC 形式。SOAP 还支持文档形式的应用程序，在这类应用程序中，SOAP 消息只是 XML 文档的一个包装。文档形式的 SOAP 应用程序非常灵活，许多新的 XML Web Service 都利用这一特点来构建使用 RPC 难以实现的服务。
SOAP 规范的最后一个可选部分定义了包含 SOAP 消息的 HTTP 消息的样式。此 HTTP 绑定非常重要，因为几乎所有当前的 OS（以及许多以前的 OS）都支持 HTTP。HTTP 绑定虽然是可选的，但几乎所有 SOAP 实现方案都支持 HTTP 绑定，因为它是 SOAP 的唯一标准协议。由于这一原因，人们通常误认为 SOAP 必须使用 HTTP。其实，有些实现方案也支持 MSMQ、MQ 系列、SMTP 或 TCP/IP 传输，但由于 HTTP 非常普遍，几乎所有当前的 XML Web Service 都使用它。由于 HTTP 是 Web 的核心协议，因此大多数组织的网络基础结构都支持 HTTP，并且员工已经了解了如何对其进行管理。如今，已经建立了用于 HTTP 的安全保护、监视和负载平衡的基础结构。

4.WSDL解析
WSDL描述语言一般包含三部分
·What部分--包括了type、message和portType元素
Type：定义了Web Service使用的数据结构（使用XML Schema定义）
Message：一个Message是SOAP的基本通信元素。每个Message可以有一个或多个Part，每个Part代表一个参数。
PortType：消息汇总为不同的操作并归入到一个被称为portType的实体中。一个portType代表一个接口（Web Service支持的操作集合），每个Web Service可以有多个接口，它们都使用portType表示。每个操作又包含了input和 output部分。
·How部分--包含binding元素
binding元素将portType绑定到特定的通信协议上（如HTTP上的SOAP协议）
·Where部分--由service元素组成
它将portType,binding以及Web Service实际的位置（URI）放在一起描述

5.客户端
通常Web Service可以有三种类型的客户
·商业伙伴（Business Partner）--包括分发商，零售商以及大型消费者）
此类客户通过SOAP、WSDL、ebXML、UDDI等XML技术与Web Service连接
·瘦客户--包括Web浏览器、PDA以及无线设备
该类客户通常经由轻量协议(如HTTP)与Web Service连接
·肥客户--包括Applet、各类应用以及现存系统
通常使用重量级协议（如IIOP）连接Web Service

饭桶精英

Sunday, June 27, 2010

SOAP vs REST

SOA

Tuesday, November 10, 2009

XML Schema Standards Library

理解SOAP

本页内容

简介

SOAP 版本

消息处理框架

扩展性

处理模型

协议绑定

HTTP 绑定

RPC 和编码

SOAP 类型

小结

Thursday, June 11, 2009

web service links

Monday, May 4, 2009

WebService 附件

Wednesday, April 29, 2009

WebService

WebService 的一些基本概念

Thursday, April 23, 2009

WebService 相关站点

WebService 概念

Soyez bienvenu

Libellés

Archive de blog

Ma liste de blogs

Qui êtes-vous ?

Sunday, June 27, 2010

Tuesday, November 10, 2009

本页内容

简介

SOAP 版本

消息处理框架

扩展性

处理模型

协议绑定

HTTP 绑定

RPC 和编码

SOAP 类型

小结

Thursday, June 11, 2009

Monday, May 4, 2009

Wednesday, April 29, 2009

Thursday, April 23, 2009

Soyez bienvenu

S’abonner à

Libellés

Archive de blog

Ma liste de blogs

Qui êtes-vous ?