WebService-Funktionsprinzip

Ich schreibe WebService schon seit einiger Zeit und werde zusammenfassen, was ich über das Funktionsprinzip von WebService gesammelt und verstanden habe.

WebService verwendet hauptsächlich das HTTP-Protokoll, auf dem ein Protokoll der Anwendungsschicht basiert Tcp/Ip: (Hinweis: Die meisten aktuellen WebService-Entwicklungen können die Socket-Echtzeitkommunikation bereits sehr gut unterstützen. Aber http ist immer noch das Wesentliche.)

Http übernimmt die „Anfrage-----Antwort“ Modus;

HTTP-Kommunikation erfolgt über XML-Serialisierungskommunikation...

HTTP-Kommunikationsprozess: Aufruf des .asmx-Handles, XML-, XSD-, SOAP- und WSDL-Verarbeitung,

Es gibt Drei Hauptaspekte werden in XML bereitgestellt: (Der folgende Artikel ist zitiert aus: http://dev.csdn.net/article/19/19185.shtm)

Persönlich denke ich, dass das Wichtigste, was man beherrschen muss die SOAP-Anforderungsnachricht und das XML-Format der Antwortnachricht...

Nachrichtenversand

Wenn das .asmx-Handle von der HTTP-Pipeline aufgerufen wird, ermitteln Sie durch Suchen, welche .NET-Klasse überprüft wird in der WebService-Deklaration in der .asmx-Datei. Anschließend beobachtet es die Informationen in der eingehenden HTTP-Nachricht und bestimmt, welche Methode in der Referenzklasse aufgerufen werden soll. Um die Add-Methode im vorherigen Beispiel aufzurufen, sollte die HTTP-Anforderungsnachricht wie folgt aussehen:

Die obige HTTP-Anforderungsnachricht enthält zwei Informationen kann verwendet werden, um die aufrufende Klasse zu bestimmen: Der Name des Anforderungselements im SOAPAction-Header oder Soap-Body. In diesem Beispiel gibt jede Methode den Namen der Methode an, die der Absender aufrufen möchte. Das

.asmx-Handle verwendet den Wert des SOAPAction-Headers, um den Nachrichtenversand zu implementieren. Daher prüft das .asmx-Handle den SOAPAction-Header in der Nachricht und verwendet die .NET-Zuordnung, um nach der Methode in der referenzierten Klasse zu suchen. Es berücksichtigt nur Methoden, die mit dem Attribut [WebMethod] gekennzeichnet sind, bestimmt aber anhand des SOAPAction-Werts jeder Methode genau, welche Methode aufgerufen werden soll. Da wir den Wert von SOAPAction in der Klasse nicht explizit angegeben haben, geht das .asmx-Handle davon aus, dass der Wert von SOAPAction der Namespace des Webdiensts plus der Methodenname ist. Und wir haben keinen Namespace angegeben, daher ist der Handler standardmäßig http://tempuri.org. Auf diese Weise ist der Standard-SOAPAction-Wert der Add-Methode http://tempuri.org/Add.

Sie können den Namensraum des Webdienstes wie folgt anpassen. Markieren Sie die Klasse mit dem Attribut [WebService] und die WebMethods mit dem Attribut [SoapDocumentMethod], um den spezifischen SOAPAction-Wert anzugeben. Ein Beispiel lautet wie folgt:

using System.Web.Services;
using System.Web.Services.Protocols;
 
[WebService(Namespace="http://example.org/math")]
public class MathService
{
   [WebMethod]
   public double Add(double x, double y) {
      return x + y;
   }
   [WebMethod]
   [SoapDocumentMethod(Action="urn:math:subtract")]
   public double Subtract(double x, double y) {
      return x - y;
   }
   ...
}

Jetzt denkt das .asmx-Handle, dass der SOAPAction-Wert der Add-Methode http://example.org/math/Add und der SOAPAction-Wert der SubTract-Methode ist urn:math:subtract (weil wir in der Klasse klar definiert sind). Beispielsweise ruft die folgende HTTP-Anforderungsnachricht „Subtract“ auf:

Wenn das .asmx-Handle keine SOAPAction-Übereinstimmung für die HTTP-Anforderungsnachricht findet, wird eine Ausnahme ausgelöst. Wenn Sie sich zum Versenden von Nachrichten nicht auf den SOAPAction-Header verlassen möchten, können Sie das .asmx-Handle anweisen, den Namen des Anforderungselements zu verwenden. Um diesen Ansatz zu übernehmen, müssen Sie die Klasse mit dem RoutingStyle-Attribut des [SoapDocumentService]-Attributs markieren. Sie sollten auch darauf hinweisen, dass WebMethods keinen SOAPAction-Wert erfordern (setzen Sie seinen Wert in der Klasse auf leer). Wie unten gezeigt:

using System.Web.Services;
using System.Web.Services.Protocols;
 
[WebService(Namespace="http://example.org/math")]
[SoapDocumentService(
  RoutingStyle=SoapServiceRoutingStyle.RequestElement)]
public class MathService
{
   [WebMethod]
   [SoapDocumentMethod(Action="")]
   public double Add(double x, double y) {
      return x + y;
   }
   [WebMethod]
   [SoapDocumentMethod(Action="")]
   public double Subtract(double x, double y) {
      return x - y;
   }
    ...
}

In diesem Fall kümmert sich der Handler nicht einmal um den Wert von SOAPAction, sondern verwendet den Namen des Anforderungselements, um die aufrufende Methode zu bestimmen. In der folgenden HTTP-Anforderungsnachricht wird beispielsweise gehofft, dass der Name des Anforderungselements, das die Add-Methode aufruft, „Add“ lautet:

Wenn das .asmx-Handle also die HTTP-Nachricht empfängt, ist das erste, was es tut Entscheiden Sie, wie die Nachricht an die entsprechende WebMethod gesendet werden soll. Bevor die Methode tatsächlich aufgerufen werden kann, muss außerdem das eingehende XML einem .NET-Objekt zugeordnet werden.

XML Objekten zuordnen

Sobald das WebMethod-Handle entschieden hat, welche Methode aufgerufen werden soll, deserialisiert es die XML-Nachricht in ein .NET-Objekt. Beim Versenden der Nachricht überprüft der Handler die Klasse durch Reflektion und entscheidet dann, wie die XML-Nachricht verarbeitet werden soll. Die XmlSerializer-Klasse schließt automatisch die Zuordnung von XML zu Klassen im System.Xml.Serialization-Namespace ab.

XmlSerializer kann jeden öffentlichen .NET-Typ dem XML-Schematyp zuordnen. Mit dieser entsprechenden Zuordnung können .NET-Objekte automatisch XML-Instanzdokumenten zugeordnet werden (siehe Abbildung 4). XmlSerializer ist durch die von XML Schema unterstützten Funktionen eingeschränkt. Obwohl es nicht alle komplexen modernen Objektmodelle (z. B. Nicht-Baum-Objektdiagramme) verarbeiten kann, kann es komplexe Typen verarbeiten, die häufig von Entwicklern verwendet werden.

Mit Blick auf das vorherige Add-Beispiel ordnet XmlSerializer die x- und y-Elemente .NET-Double-Werten zu (muss beim Aufruf der Add-Methode angegeben werden). Die Add-Methode gibt einen Double-Typ-Wert an den Aufrufer zurück, der auch in ein XML-Element in der SOAP-Antwortnachricht serialisiert werden muss.

Abbildung 4. Zuordnen von XML zu Objekten

XmlSerializer也能自动处理一些复杂类型（除了上面说到的一些限制）。比如，下面的WebMethod计算两个点结构之间的距离。

using System;
using System.Web.Services;
public class Point {
  public double x;
  public double y;
}
[WebService(Namespace="urn:geometry")]
public class Geometry {
  [WebMethod]
  public double Distance(Point orig, Point dest) {
    return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) +
                     Math.Pow(orig.y-dest.y, 2));
  }
}

请求此操作的SOAP消息将包含一个Distance元素，它包含了两个子元素，一个称作orig，另一个是dest，每一个都包括了x和y元素，如下所示：

这种情况下SOAP应答消息将包含一个DistanceResponse元素，它包含一个double 类型的DistanceResult子元素。

缺省的XML映射使用方法名作为请求元素名，参数名作为子元素名。每个参数的结构依赖于类型的结构。公共字段和属性的名字简单映射为子元素，如Point类中的x和y。应答元素的名字缺省为请求元素的名字后面附加上“Response”,应答元素也包含一个子元素，是请求元素名字后面附加“Result”。也有可能使用一些固定的映射属性来打破标准的XML映射。比如，你可以使用[XmlType]属性来定制类型的名字和名称空间，使用[XmlElement]和[XmlAttribute]属性来控制如何将参数或类成员分别映射为元素或属性，也可以使用[SoapDocumentMethod]属性控制怎样把方法本身映射为请求/响应消息中的元素名。比如，检查下面重新定义的Distance。

using System;
using System.Web.Services;
using System.Web.Services.Protocols;
using System.Xml.Serialization;
 
public class Point {
  [XmlAttribute]
  public double x;
  [XmlAttribute]
  public double y;
}
[WebService(Namespace="urn:geometry")]
public class Geometry {
  [WebMethod]
  [SoapDocumentMethod(RequestElementName="CalcDistance",
     ResponseElementName="CalculatedDistance")]
  [return: XmlElement("result")]
  public double Distance(
    [XmlElement("o")]Point orig, [XmlElement("d")]Point dest) {
    return Math.Sqrt(Math.Pow(orig.x-dest.x, 2) +
                     Math.Pow(orig.y-dest.y, 2));
  }
}

它所期望的SOAP请求消息如下：

.asmx句柄使用SOAP document/literal风格来实现和描述上面显示的默认映射。意思上说WSDL定义将包含literal XML schema定义，它描述了SOAP消息中用到的请求和响应元素。

.asmx句柄也能使用SOAP rpc/encoded风格。这意味着SOAP体中包含一个RPC调用的XML代表（representation），参数用SOAP编码规则来串行化。实现这些仅需将[SoapDocumentService] and [SoapDocumentMethod]替换为[SoapRpcService] and [SoapRpcMethod]属性。

正如你所看到的，我们可能完全定制一个从给定方法到SOAP消息的映射。XmlSerializer提供了一个强大的串行化引擎。

除了处理参数的反串行化，.asmx句柄也能串行化/反串行化SOAP头。SOAP头的处理不同于参数，因为它们被认为是典型的无法控制的信息，和具体的方法没有直接的联系。由于这些，头处理主要是通过中间层（interception layers），完全为WebMethods屏蔽了头处理。

然而如果想涉足于WebMethod中的头信息，你必须提供一个.NET类，从SoapHeader派生而来，它代表了头的XML schema类型。然后定义一个此类型的成员变量作为每一个头实例的占位符。最后标记每个要访问头的WebMethod，指定你想要到达的域名。

比如，下面的SOAP请求包括一个用来进行身份验证的UsernameToken头。

更多WebService-Funktionsprinzip相关文章请关注PHP中文网！