Porównywanie usług sieci Web na platformie ASP.NET z programem WCF na podstawie procesów programistycznych

Artykuł
03/02/2024

Program Windows Communication Foundation (WCF) ma opcję trybu zgodności ASP.NET, aby umożliwić programowaniu i skonfigurowaniu aplikacji WCF, takich jak usługi sieci Web ASP.NET i naśladować ich zachowanie. W poniższych sekcjach porównasz ASP.NET usług sieci Web i WCF na podstawie tego, co jest wymagane do tworzenia aplikacji przy użyciu obu technologii.

Reprezentacja danych

Opracowywanie usługi internetowej z ASP.NET zwykle rozpoczyna się od zdefiniowania dowolnego złożonego typu danych, którego usługa ma używać. ASP.NET polega na XmlSerializer przetłumaczeniu danych reprezentowanych przez typy .NET Framework na XML na potrzeby transmisji do usługi lub z usługi oraz tłumaczenia danych odebranych jako XML na obiekty programu .NET Framework. Definiowanie złożonych typów danych używanych przez usługę ASP.NET wymaga definicji klas programu .NET Framework, które XmlSerializer mogą serializować do i z formatu XML. Takie klasy można napisać ręcznie lub wygenerować na podstawie definicji typów w schemacie XML przy użyciu wiersza polecenia schematów XML/typów danych Support Utility, xsd.exe.

Poniżej znajduje się lista kluczowych problemów, które należy wiedzieć podczas definiowania klas programu .NET Framework, które XmlSerializer mogą serializować do i z kodu XML:

Tylko publiczne pola i właściwości obiektów programu .NET Framework są tłumaczone na format XML.
Wystąpienia klas kolekcji można serializować w formacie XML tylko wtedy, gdy klasy implementują IEnumerable interfejs lub ICollection .
Klasy implementujące IDictionary interfejs, takie jak Hashtable, nie mogą być serializowane w formacie XML.
Wiele typów atrybutów w System.Xml.Serialization przestrzeni nazw można dodać do klasy .NET Framework i jej składowych w celu kontrolowania sposobu reprezentowania wystąpień klasy w formacie XML.

Tworzenie aplikacji WCF zwykle rozpoczyna się również od definicji typów złożonych. WCF można używać tych samych typów programu .NET Framework co usługi sieci Web ASP.NET.

Program WCFDataContractAttribute i DataMemberAttribute można dodać do typów programu .NET Framework, aby wskazać, że wystąpienia typu mają być serializowane w formacie XML, a określone pola lub właściwości typu mają być serializowane, jak pokazano w poniższym przykładowym kodzie.

//Example One:
[DataContract]
public class LineItem
{
    [DataMember]
    public string ItemNumber;
    [DataMember]
    public decimal Quantity;
    [DataMember]
    public decimal UnitPrice;
}

//Example Two:
public class LineItem
{
    [DataMember]
    private string itemNumber;
    [DataMember]
    private decimal quantity;
    [DataMember]
    private decimal unitPrice;

    public string ItemNumber
    {
      get
      {
          return this.itemNumber;
      }

      set
      {
          this.itemNumber = value;
      }
    }

    public decimal Quantity
    {
        get
        {
            return this.quantity;
        }

        set
        {
            this.quantity = value;
        }
    }

    public decimal UnitPrice
    {
      get
      {
          return this.unitPrice;
      }

      set
      {
          this.unitPrice = value;
      }
    }
}

//Example Three:
public class LineItem
{
     private string itemNumber;
     private decimal quantity;
     private decimal unitPrice;

     [DataMember]
     public string ItemNumber
     {
       get
       {
          return this.itemNumber;
       }

       set
       {
           this.itemNumber = value;
       }
     }

     [DataMember]
     public decimal Quantity
     {
          get
          {
              return this.quantity;
          }

          set
          {
             this.quantity = value;
          }
     }

     [DataMember]
     public decimal UnitPrice
     {
          get
          {
              return this.unitPrice;
          }

          set
          {
              this.unitPrice = value;
          }
     }
}

Oznacza DataContractAttribute to, że należy serializować zero lub więcej pól lub właściwości typu, podczas gdy DataMemberAttribute wskazuje, że określone pole lub właściwość mają być serializowane. Element DataContractAttribute można zastosować do klasy lub struktury. Można DataMemberAttribute go zastosować do pola lub właściwości, a pola i właściwości, do których jest stosowany atrybut, może być publiczny lub prywatny. Wystąpienia typów, które mają DataContractAttribute zastosowane do nich, są określane jako kontrakty danych w programie WCF. Są one serializowane w formacie XML przy użyciu polecenia DataContractSerializer.

Poniżej znajduje się lista ważnych różnic między używaniem DataContractSerializer elementu i używaniem XmlSerializer elementu i oraz różnych atrybutów System.Xml.Serialization przestrzeni nazw.

Atrybuty XmlSerializer System.Xml.Serialization i przestrzeni nazw zostały zaprojektowane tak, aby umożliwić mapowanie typów programu .NET Framework na dowolny prawidłowy typ zdefiniowany w schemacie XML, dzięki czemu zapewniają bardzo precyzyjną kontrolę nad tym, jak typ jest reprezentowany w formacie XML. DataContractAttribute Element DataContractSerializeri DataMemberAttribute zapewnia bardzo małą kontrolę nad tym, jak typ jest reprezentowany w formacie XML. Można określić tylko przestrzenie nazw i nazwy używane do reprezentowania typu i jego pól lub właściwości w pliku XML oraz sekwencję, w której pola i właściwości są wyświetlane w kodzie XML:
```
[DataContract(
Namespace="urn:Contoso:2006:January:29",
Name="LineItem")]
public class LineItem
{
      [DataMember(Name="ItemNumber",IsRequired=true,Order=0)]
      public string itemNumber;
      [DataMember(Name="Quantity",IsRequired=false,Order = 1)]
      public decimal quantity;
      [DataMember(Name="Price",IsRequired=false,Order = 2)]
      public decimal unitPrice;
}
```
Wszystkie inne elementy dotyczące struktury XML używanej do reprezentowania typu .NET są określane przez element DataContractSerializer.
Nie zezwalając na dużą kontrolę nad tym, jak typ ma być reprezentowany w formacie XML, proces serializacji staje się wysoce przewidywalny dla DataContractSerializerelementu , a tym samym łatwiejszy do optymalizacji. Praktyczną zaletą projektu DataContractSerializer jest lepsza wydajność, około dziesięciu procent lepszej wydajności.
Atrybuty do użycia z parametrem XmlSerializer nie wskazują, które pola lub właściwości typu są serializowane w formacie XML, natomiast DataMemberAttribute atrybuty do użycia z pokazami DataContractSerializer jawnie, które pola lub właściwości są serializowane. W związku z tym kontrakty danych to jawne kontrakty dotyczące struktury danych, które aplikacja ma wysyłać i odbierać.
Obiekt XmlSerializer może tłumaczyć tylko publiczne elementy członkowskie obiektu platformy .NET na format XML. DataContractSerializer Element może tłumaczyć elementy członkowskie obiektów na kod XML niezależnie od modyfikatorów dostępu tych elementów członkowskich.
W związku z tym, że można serializować niepublizowanych elementów członkowskich typów w formacie XML, ma mniej ograniczeń dotyczących różnych typów platformy .NET, DataContractSerializer które może serializować w formacie XML. W szczególności może on tłumaczyć się na typy XML, takie jak Hashtable implementowanie interfejsu IDictionary . Jest DataContractSerializer o wiele bardziej prawdopodobne, aby móc serializować wystąpienia dowolnego wstępnie istniejącego typu platformy .NET w formacie XML bez konieczności modyfikowania definicji typu lub opracowywania otoki.
Kolejną konsekwencją DataContractSerializer możliwości uzyskania dostępu do niepubliowych członków typu jest to, że wymaga pełnego zaufania, podczas gdy XmlSerializer nie. Uprawnienie Dostępu do kodu pełnego zaufania zapewnia pełny dostęp do wszystkich zasobów na maszynie, do której można uzyskać dostęp przy użyciu poświadczeń, w ramach których jest wykonywany kod. Ta opcja powinna być używana z ostrożnością, ponieważ w pełni zaufany kod uzyskuje dostęp do wszystkich zasobów na maszynie.
Obejmuje DataContractSerializer to obsługę wersji:
- Właściwość DataMemberAttribute ma IsRequired właściwość, która może być przypisana wartość false dla elementów członkowskich dodanych do nowych wersji kontraktu danych, które nie były obecne we wcześniejszych wersjach, dzięki czemu aplikacje z nowszą wersją kontraktu mogą przetwarzać wcześniejsze wersje.
- Dzięki zaimplementowaniu interfejsu IExtensibleDataObject kontraktu danych można zezwolić na DataContractSerializer przekazywanie elementów członkowskich zdefiniowanych w nowszych wersjach kontraktu danych za pośrednictwem aplikacji z wcześniejszymi wersjami kontraktu.

Pomimo wszystkich różnic, xml, w którym XmlSerializer serializuje typ domyślnie jest semantycznie identyczny z XML, do którego DataContractSerializer serializuje typ, pod warunkiem że przestrzeń nazw xml jest jawnie zdefiniowana. Następująca klasa, która ma atrybuty do użycia z obydwoma serializatorami, jest tłumaczona na semantycznie identyczny kod XML przez element XmlSerializer i przez DataContractAttributeelement :

[Serializable]
[XmlRoot(Namespace="urn:Contoso:2006:January:29")]
[DataContract(Namespace="urn:Contoso:2006:January:29")]
public class LineItem
{
     [DataMember]
     public string ItemNumber;
     [DataMember]
     public decimal Quantity;
     [DataMember]
     public decimal UnitPrice;
}

Zestaw SDK (Software Development Kit) systemu Windows zawiera narzędzie wiersza polecenia o nazwie ServiceModel Metadata Utility Tool (Svcutil.exe). Podobnie jak narzędzie xsd.exe używane z usługami sieci Web ASP.NET, Svcutil.exe może generować definicje typów danych platformy .NET ze schematu XML. Typy to kontrakty danych, jeśli DataContractSerializer mogą emitować kod XML w formacie zdefiniowanym przez schemat XML. W przeciwnym razie są one przeznaczone do serializacji przy użyciu .XmlSerializer Svcutil.exe może również wygenerować schemat XML z kontraktów danych przy użyciu przełącznika dataContractOnly .

Uwaga

Mimo że ASP.NET usługi sieci Web korzystają z XmlSerializertrybu zgodności ASP.NET usługi WCF i ASP.NET sprawiają, że usługi WCF naśladują zachowanie usług ASP.NET sieci Web, opcja zgodności ASP.NET nie ogranicza ich do korzystania z programu XmlSerializer. Nadal można używać z DataContractSerializer usługami uruchomionymi w trybie zgodności ASP.NET.

Programowanie usług

Aby opracować usługę przy użyciu ASP.NET, jest ona niestandardowa do dodawania atrybutu WebService do klasy oraz WebMethodAttribute do dowolnej z metod tej klasy, które mają być operacjami usługi:

[WebService]
public class Service : T:System.Web.Services.WebService
{
    [WebMethod]
    public string Echo(string input)
    {
       return input;
    }
}

ASP.NET 2.0 wprowadzono opcję dodawania atrybutu WebService i WebMethodAttribute do interfejsu, a nie do klasy, i pisanie klasy w celu zaimplementowania interfejsu:

[WebService]
public interface IEcho
{
    [WebMethod]
    string Echo(string input);
}

public class Service : IEcho
{

   public string Echo(string input)
   {
        return input;
    }
}

Użycie tej opcji jest preferowane, ponieważ interfejs z atrybutem WebService stanowi kontrakt dla operacji wykonywanych przez usługę, które mogą być ponownie używane z różnymi klasami, które mogą implementować ten sam kontrakt na różne sposoby.

Usługa WCF jest dostarczana przez zdefiniowanie co najmniej jednego punktu końcowego programu WCF. Punkt końcowy jest definiowany przez adres, powiązanie i kontrakt usługi. Adres definiuje miejsce, w którym znajduje się usługa. Powiązanie określa, jak komunikować się z usługą. Kontrakt usługi definiuje operacje, które może wykonywać usługa.

Kontrakt usługi jest zwykle definiowany jako pierwszy, dodając ServiceContractAttribute element i OperationContractAttribute do interfejsu:

[ServiceContract]
public interface IEcho
{
     [OperationContract]
     string Echo(string input);
}

Określa ServiceContractAttribute , że interfejs definiuje kontrakt usługi WCF i OperationContractAttribute wskazuje, które, jeśli w ogóle, metody interfejsu definiują operacje kontraktu usługi.

Po zdefiniowaniu kontraktu usługi jest implementowany w klasie, dzięki czemu klasa implementuje interfejs, za pomocą którego zdefiniowano kontrakt usługi:

public class Service : IEcho
{
    public string Echo(string input)
    {
       return input;
    }
}

Klasa, która implementuje kontrakt usługi, jest określana jako typ usługi w programie WCF.

Następnym krokiem jest skojarzenie adresu i powiązania z typem usługi. Zazwyczaj odbywa się to w pliku konfiguracji, bezpośrednio edytując plik lub za pomocą edytora konfiguracji dostarczonego z usługą WCF. Oto przykład pliku konfiguracji.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <system.serviceModel>
      <services>
      <service name="Service ">
       <endpoint
        address="EchoService"
        binding="basicHttpBinding"
        contract="IEchoService "/>
      </service>
      </services>
     </system.serviceModel>
</configuration>

Powiązanie określa zestaw protokołów do komunikacji z aplikacją. W poniższej tabeli wymieniono powiązania dostarczone przez system, które reprezentują typowe opcje.

Nazwisko	Purpose
BasicHttpBinding	Współdziałanie z usługami sieci Web i klientami obsługującymi usługę WS-BasicProfile 1.1 i podstawowy profil zabezpieczeń 1.0.
WSHttpBinding	Współdziałanie z usługami sieci Web i klientami obsługującymi protokoły WS-* za pośrednictwem protokołu HTTP.
WSDualHttpBinding	Dwukierunkowa komunikacja HTTP, za pomocą której odbiorca początkowej wiadomości nie odpowiada bezpośrednio do początkowego nadawcy, ale może przesyłać dowolną liczbę odpowiedzi w danym okresie przy użyciu protokołu HTTP zgodnie z protokołami WS-*.
WSFederationBinding	Komunikacja HTTP, w której dostęp do zasobów usługi może być kontrolowany na podstawie poświadczeń wystawionych przez jawnie zidentyfikowanego dostawcę poświadczeń.
Nettcpbinding	Bezpieczna, niezawodna, wysoka wydajność komunikacji między jednostkami oprogramowania WCF w sieci.
NetNamedPipeBinding	Bezpieczna, niezawodna, wysoka wydajność komunikacji między jednostkami oprogramowania WCF na tym samym komputerze.
Netmsmqbinding	Komunikacja między jednostkami oprogramowania WCF przy użyciu msMQ.
Msmqintegrationbinding	Komunikacja między jednostką oprogramowania WCF a inną jednostką oprogramowania przy użyciu msMQ.
Netpeertcpbinding	Komunikacja między jednostkami oprogramowania WCF przy użyciu sieci równorzędnej systemu Windows.

Powiązanie dostarczone przez system zawiera BasicHttpBindingzestaw protokołów obsługiwanych przez usługi sieci Web ASP.NET.

Powiązania niestandardowe dla aplikacji WCF są łatwo definiowane jako kolekcje klas elementów powiązania używanych przez program WCF do implementowania poszczególnych protokołów. Nowe elementy powiązania można zapisywać w celu reprezentowania dodatkowych protokołów.

Wewnętrzne zachowanie typów usług można dostosować przy użyciu właściwości rodziny klas nazywanych zachowaniami. W tym miejscu klasa służy do określania, ServiceBehaviorAttribute że typ usługi ma być wielowątkowy.

[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple)]
public class DerivativesCalculatorServiceType: IDerivativesCalculator

Niektóre zachowania, takie jak ServiceBehaviorAttribute, to atrybuty. Inne, te z właściwościami, które administratorzy chcą ustawić, można zmodyfikować w konfiguracji aplikacji.

W typach usług programistycznych często używane są OperationContext klasy . Jego właściwość statyczna Current zapewnia dostęp do informacji o kontekście, w którym jest uruchomiona operacja. OperationContextjest podobny do HttpContext klas i .ContextUtil

Hosting

ASP.NET usługi sieci Web są kompilowane w zestawie biblioteki klas. Plik o nazwie plik usługi jest dostarczany, który ma rozszerzenie .asmx i zawiera dyrektywę @ WebService , która identyfikuje klasę zawierającą kod usługi i zestaw, w którym się znajduje.

<%@ WebService Language="C#" Class="Service,ServiceAssembly" %>

Plik usługi jest kopiowany do katalogu głównego aplikacji ASP.NET w usługach Internet Information Services (IIS), a zestaw jest kopiowany do podkatalogu \bin tego katalogu głównego aplikacji. Aplikacja jest następnie dostępna przy użyciu ujednoliconego lokalizatora zasobów (url) pliku usługi w katalogu głównym aplikacji.

Usługi WCF mogą być łatwo hostowane w usługach IIS 5.1 lub 6.0, usługa aktywacji procesów systemu Windows (WAS), która jest dostarczana w ramach usług IIS 7.0 i w dowolnej aplikacji .NET. Aby hostować usługę w usługach IIS 5.1 lub 6.0, usługa musi używać protokołu HTTP jako protokołu transportowego komunikacji.

Aby hostować usługę w usługach IIS 5.1, 6.0 lub w programie WAS, wykonaj następujące kroki:

Skompiluj typ usługi do zestawu biblioteki klas.
Utwórz plik usługi z rozszerzeniem svc z dyrektywą @ ServiceHost , aby zidentyfikować typ usługi:

<%@ServiceHost language="c#" Service="MyService" %>
Skopiuj plik usługi do katalogu wirtualnego, a zestaw do podkatalogu \bin tego katalogu wirtualnego.
Skopiuj plik konfiguracji do katalogu wirtualnego i nadaj mu nazwę Web.config.

Aplikacja jest następnie dostępna przy użyciu adresu URL pliku usługi w katalogu głównym aplikacji.

Aby hostować usługę WCF w aplikacji .NET, skompiluj typ usługi do zestawu biblioteki klas, do których odwołuje się aplikacja, i zaprogramuj aplikację do hostowania usługi przy użyciu ServiceHost klasy . Poniżej przedstawiono przykład wymaganego podstawowego programowania:

string httpBaseAddress = "http://www.contoso.com:8000/";
string tcpBaseAddress = "net.tcp://www.contoso.com:8080/";

Uri httpBaseAddressUri = new Uri(httpBaseAddress);
Uri tcpBaseAddressUri = new Uri(tcpBaseAddress);

Uri[] baseAddresses = new Uri[] {
 httpBaseAddressUri,
 tcpBaseAddressUri};

using(ServiceHost host = new ServiceHost(
typeof(Service), //"Service" is the name of the service type baseAddresses))
{
     host.Open();

     […] //Wait to receive messages
     host.Close();
}

W tym przykładzie pokazano, jak adresy dla co najmniej jednego protokołu transportowego są określone w budowie ServiceHostobiektu . Te adresy są określane jako adresy podstawowe.

Adres podany dla dowolnego punktu końcowego usługi WCF jest adresem względem podstawowego adresu hosta punktu końcowego. Host może mieć jeden adres podstawowy dla każdego protokołu transportu komunikacyjnego. W przykładowej konfiguracji w poprzednim pliku konfiguracji wybrany BasicHttpBinding dla punktu końcowego używa protokołu HTTP jako protokołu transportowego, więc adres punktu końcowego , EchoServicejest względem adresu podstawowego HTTP hosta. W przypadku hosta w poprzednim przykładzie podstawowy adres HTTP to http://www.contoso.com:8000/. W przypadku usługi hostowanej w usługach IIS lub WAS adres podstawowy jest adresem URL pliku usługi usługi.

Tylko usługi hostowane w usługach IIS lub WAS, które są skonfigurowane z protokołem HTTP wyłącznie, można używać WCF ASP.NET tryb zgodności. Włączenie tej opcji wymaga wykonania następujących kroków.

Programista musi dodać AspNetCompatibilityRequirementsAttribute atrybut do typu usługi i określić, że ASP.NET tryb zgodności jest dozwolony lub wymagany.

[System.ServiceModel.Activation.AspNetCompatibilityRequirements(
      RequirementsMode=AspNetCompatibilityRequirementsMode.Require)]
public class DerivativesCalculatorServiceType: IDerivativesCalculator

Administrator musi skonfigurować aplikację tak, aby korzystała z trybu zgodności ASP.NET.

<configuration>
     <system.serviceModel>
      <services>
      […]
      </services>
      <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
    </system.serviceModel>
</configuration>

Aplikacje WCF można również skonfigurować tak, aby używały pliku asmx jako rozszerzenia dla plików usługi, a nie .svc.

<system.web>
     <compilation>
      <compilation debug="true">
      <buildProviders>
       <remove extension=".asmx"/>
       <add extension=".asmx"
        type="System.ServiceModel.ServiceBuildProvider,
        System.ServiceModel,
        Version=3.0.0.0,
        Culture=neutral,
        PublicKeyToken=b77a5c561934e089" />
      </buildProviders>
      </compilation>
     </compilation>
</system.web>

Ta opcja umożliwia zapisanie konieczności modyfikowania klientów skonfigurowanych do używania adresów URL plików usługi asmx podczas modyfikowania usługi w celu korzystania z usługi WCF.

Tworzenie aplikacji klienckich

Klienci usług ASP.NET sieci Web są generowane przy użyciu narzędzia wiersza polecenia, WSDL.exe, który udostępnia adres URL pliku asmx jako dane wejściowe. Odpowiednie narzędzie udostępniane przez usługę WCF to narzędzie ServiceModel Metadata Tool (Svcutil.exe).The corresponding tool provided by WCF is ServiceModel Metadata Tool (Svcutil.exe). Generuje moduł kodu z definicją kontraktu usługi i definicją klasy klienta WCF. Generuje również plik konfiguracji z adresem i powiązaniem usługi.

W programowaniu klienta usługi zdalnej zaleca się programować zgodnie ze wzorcem asynchronicznym. Kod wygenerowany przez narzędzie WSDL.exe zawsze zapewnia zarówno synchroniczny, jak i asynchroniczny wzorzec domyślnie. Kod wygenerowany przez narzędzie ServiceModel Metadata Utility Tool (Svcutil.exe) może zapewnić dowolny wzorzec. Domyślnie zapewnia on wzorzec synchroniczny. Jeśli narzędzie jest wykonywane za pomocą przełącznika /async , wygenerowany kod zawiera wzorzec asynchroniczny.

Nie ma gwarancji, że nazwy w klasach klienta WCF generowanych przez narzędzie WSDL.exe platformy ASP.NET domyślnie są zgodne z nazwami w klasach klienta WCF generowanych przez narzędzie Svcutil.exe. W szczególności nazwy właściwości klas, które muszą być serializowane przy użyciu XmlSerializer klasy, są domyślnie, biorąc pod uwagę właściwość sufiksu w kodzie wygenerowany przez narzędzie Svcutil.exe, co nie jest przypadkiem narzędzia WSDL.exe.

Reprezentacja wiadomości

Nagłówki komunikatów PROTOKOŁU SOAP wysyłane i odbierane przez usługi sieci Web ASP.NET można dostosować. Klasa pochodzi z SoapHeader , aby zdefiniować strukturę nagłówka, a następnie SoapHeaderAttribute jest używana do wskazywania obecności nagłówka.

public class SomeProtocol : SoapHeader
{
     public long CurrentValue;
     public long Total;
}

[WebService]
public interface IEcho
{
     SomeProtocol ProtocolHeader
     {
      get;
     set;
     }

     [WebMethod]
     [SoapHeader("ProtocolHeader")]
     string PlaceOrders(PurchaseOrderType order);
}

public class Service: WebService, IEcho
{
     private SomeProtocol protocolHeader;

     public SomeProtocol ProtocolHeader
     {
         get
         {
              return this.protocolHeader;
         }

         set
         {
              this.protocolHeader = value;
         }
     }

     string PlaceOrders(PurchaseOrderType order)
     {
         long currentValue = this.protocolHeader.CurrentValue;
     }
}

Program WCF udostępnia atrybuty , MessageContractAttribute MessageHeaderAttribute, oraz MessageBodyMemberAttribute opis struktury komunikatów PROTOKOŁU SOAP wysyłanych i odbieranych przez usługę.

[DataContract]
public class SomeProtocol
{
     [DataMember]
     public long CurrentValue;
     [DataMember]
     public long Total;
}

[DataContract]
public class Item
{
     [DataMember]
     public string ItemNumber;
     [DataMember]
     public decimal Quantity;
     [DataMember]
     public decimal UnitPrice;
}

[MessageContract]
public class ItemMessage
{
     [MessageHeader]
     public SomeProtocol ProtocolHeader;
     [MessageBody]
     public Item Content;
}

[ServiceContract]
public interface IItemService
{
     [OperationContract]
     public void DeliverItem(ItemMessage itemMessage);
}

Ta składnia daje jawną reprezentację struktury komunikatów, natomiast struktura komunikatów jest implikowana przez kod usługi ASP.NET sieci Web. Ponadto w składni ASP.NET nagłówki komunikatów są reprezentowane jako właściwości usługi, takie jak ProtocolHeader właściwość w poprzednim przykładzie, podczas gdy w składni programu WCF są one dokładniej reprezentowane jako właściwości komunikatów. Ponadto program WCF umożliwia dodawanie nagłówków komunikatów do konfiguracji punktów końcowych.

<service name="Service ">
     <endpoint
      address="EchoService"
      binding="basicHttpBinding"
      contract="IEchoService ">
      <headers>
      <dsig:X509Certificate
       xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
       ...
      </dsig:X509Certificate>
      </headers>
     </endpoint>
</service>

Ta opcja umożliwia uniknięcie wszelkich odwołań do nagłówków protokołu infrastrukturalnego w kodzie klienta lub usługi: nagłówki są dodawane do komunikatów ze względu na sposób konfigurowania punktu końcowego.

Opis usługi

Wysłanie żądania HTTP GET dla pliku asmx usługi sieci Web ASP.NET z zapytaniem WSDL powoduje, że ASP.NET wygenerować plik WSDL w celu opisania usługi. Zwraca on plik WSDL jako odpowiedź na żądanie.

ASP.NET 2.0 umożliwił sprawdzenie, czy usługa jest zgodna z profilem podstawowym 1.1 organizacji współdziałania usług sieci Web (WS-I) i wstawić oświadczenie zgodne z usługą WSDL. Odbywa się to przy użyciu ConformsTo parametrów i EmitConformanceClaims atrybutu WebServiceBindingAttribute .

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(
     ConformsTo = WsiProfiles.BasicProfile1_1,
     EmitConformanceClaims=true)]
public interface IEcho

Plik WSDL, który ASP.NET generuje dla usługi, można dostosować. Dostosowania są tworzone przez utworzenie klasy pochodnej w celu dodania ServiceDescriptionFormatExtension elementów do języka WSDL.

Wysłanie żądania HTTP GET z zapytaniem WSDL dla pliku svc usługi WCF z punktem końcowym HTTP hostowanym w usługach IIS 51, 6.0 lub WAS powoduje, że usługa WCF odpowiada za pomocą języka WSDL w celu opisania usługi. Wysłanie żądania HTTP GET z zapytaniem WSDL do podstawowego adresu HTTP usługi hostowanej w aplikacji platformy .NET ma taki sam efekt, jeśli wartość httpGetEnabled ma wartość true.

Jednak usługa WCF odpowiada również na żądania WS-MetadataExchange za pomocą języka WSDL wygenerowanego w celu opisania usługi. ASP.NET usługi sieci Web nie mają wbudowanej obsługi żądań WS-MetadataExchange.

WSDL generowany przez usługę WCF może być szeroko dostosowywany. Klasa ServiceMetadataBehavior udostępnia kilka funkcji dostosowywania WSDL. Można również skonfigurować usługę WCF tak, aby nie generować WSDL, ale użyć statycznego pliku WSDL pod danym adresem URL.

<behaviors>
     <behavior name="DescriptionBehavior">
     <metadataPublishing
      enableMetadataExchange="true"
      enableGetWsdl="true"
      enableHelpPage="true"
      metadataLocation=
      "http://localhost/DerivativesCalculatorService/Service.WSDL"/>
     </behavior>
</behaviors>

Obsługa wyjątków

W usługach ASP.NET sieci Web nieobsługiwane wyjątki są zwracane do klientów jako błędy protokołu SOAP. Możesz również jawnie zgłaszać wystąpienia SoapException klasy i mieć większą kontrolę nad zawartością błędu protokołu SOAP, który jest przesyłany do klienta.

W usługach WCF nieobsługiwane wyjątki nie są zwracane do klientów jako błędy protokołu SOAP, aby zapobiec przypadkowo uwidocznieniu poufnych informacji za pośrednictwem wyjątków. Dostępne jest ustawienie konfiguracji, które ma nieobsługiwane wyjątki zwracane do klientów w celu debugowania.

Aby zwrócić błędy protokołu SOAP do klientów, możesz zgłosić wystąpienia typu ogólnego , FaultException<TDetail>używając typu kontraktu danych jako typu ogólnego. Możesz również dodać FaultContractAttribute atrybuty do operacji, aby określić błędy, które może przynieść operacja.

[DataContract]
public class MathFault
{
     [DataMember]
     public string operation;
     [DataMember]
     public string problemType;
}

[ServiceContract]
public interface ICalculator
{
     [OperationContract]
     [FaultContract(typeof(MathFault))]
     int Divide(int n1, int n2);
}

Dzięki temu możliwe błędy są anonsowane w języku WSDL dla usługi, co pozwala programistom klienckim przewidzieć, które błędy mogą wynikać z operacji, i napisać odpowiednie instrukcje catch.

try
{
     result = client.Divide(value1, value2);
}
catch (FaultException<MathFault> e)
{
 Console.WriteLine("FaultException<MathFault>: Math fault while doing "
  + e.Detail.operation
  + ". Problem: "
  + e.Detail.problemType);
}

Zarządzanie stanem

Klasa używana do implementowania usługi sieci Web ASP.NET może pochodzić z WebServiceklasy .

public class Service : WebService, IEcho
{

 public string Echo(string input)
 {
  return input;
 }
}

W takim przypadku klasę można zaprogramować, aby uzyskać dostęp do obiektu za pomocą WebService właściwości Context klasy bazowej HttpContext . Obiekt HttpContext może służyć do aktualizowania i pobierania informacji o stanie aplikacji przy użyciu właściwości Aplikacji i może służyć do aktualizowania i pobierania informacji o stanie sesji przy użyciu właściwości sesji.

ASP.NET zapewnia znaczną kontrolę nad tym, gdzie informacje o stanie sesji, do których uzyskiwany jest dostęp przy użyciu właściwości Session obiektu HttpContext , są rzeczywiście przechowywane. Może być przechowywany w plikach cookie, w bazie danych, w pamięci bieżącego serwera lub w pamięci wyznaczonego serwera. Wybór jest wybierany w pliku konfiguracji usługi.

Program WCF udostępnia rozszerzalne obiekty do zarządzania stanem. Rozszerzalne obiekty to obiekty, które implementują IExtensibleObject<T>element . Najważniejsze rozszerzalne obiekty to ServiceHostBase i InstanceContext. ServiceHostBase Umożliwia zachowanie stanu, do którego wszystkie wystąpienia wszystkich typów usług na tym samym hoście mogą uzyskiwać dostęp, a jednocześnie InstanceContext umożliwia zachowanie stanu, do którego można uzyskać dostęp za pomocą dowolnego kodu uruchomionego w ramach tego samego wystąpienia typu usługi.

W tym miejscu typ TradingSystemusługi , ma wartość określającą ServiceBehaviorAttribute , że wszystkie wywołania z tego samego wystąpienia klienta WCF są kierowane do tego samego wystąpienia typu usługi.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class TradingSystem: ITradingService

Klasa DealData, definiuje stan, do którego można uzyskać dostęp za pomocą dowolnego kodu uruchomionego w tym samym wystąpieniu typu usługi.

internal class DealData: IExtension<InstanceContext>
{
 public string DealIdentifier = null;
 public Trade[] Trades = null;
}

W kodzie typu usługi, który implementuje jedną z operacji kontraktu usługi, DealData obiekt stanu jest dodawany do stanu bieżącego wystąpienia typu usługi.

string ITradingService.BeginDeal()
{
 string dealIdentifier = Guid.NewGuid().ToString();
 DealData state = new DealData(dealIdentifier);
 OperationContext.Current.InstanceContext.Extensions.Add(state);
 return dealIdentifier;
}

Ten obiekt stanu można następnie pobrać i zmodyfikować przez kod, który implementuje inne operacje kontraktu usługi.

void ITradingService.AddTrade(Trade trade)
{
 DealData dealData =  OperationContext.Current.InstanceContext.Extensions.Find<DealData>();
 dealData.AddTrade(trade);
}

Podczas gdy ASP.NET zapewnia kontrolę nad tym, gdzie informacje o stanie w HttpContext klasie są rzeczywiście przechowywane, program WCF, przynajmniej w początkowej wersji, nie zapewnia kontroli nad miejscem przechowywania rozszerzalnych obiektów. Stanowi to najlepszą przyczynę wybrania trybu zgodności ASP.NET dla usługi WCF. Jeśli konfigurowalne zarządzanie stanem jest konieczne, należy wybrać tryb zgodności ASP.NET umożliwia korzystanie z obiektów HttpContext klasy dokładnie tak, jak są używane w ASP.NET, a także do konfigurowania miejsca przechowywania informacji o stanie zarządzanych przy użyciu HttpContext klasy.

Zabezpieczenia

Opcje zabezpieczania ASP.NET usług sieci Web to te, które służą do zabezpieczania dowolnej aplikacji usług IIS. Ponieważ aplikacje WCF mogą być hostowane nie tylko w usługach IIS, ale także w obrębie dowolnego pliku wykonywalnego platformy .NET, opcje zabezpieczania aplikacji WCF muszą być niezależne od obiektów usług IIS. Jednak dostępne są również usługi sieci Web ASP.NET dla usług WCF działających w trybie zgodności ASP.NET.

Zabezpieczenia: uwierzytelnianie

Usługi IIS udostępniają funkcje kontrolowania dostępu do aplikacji, za pomocą których można wybrać dostęp anonimowy lub różne tryby uwierzytelniania: uwierzytelnianie systemu Windows, uwierzytelnianie szyfrowane, uwierzytelnianie podstawowe i uwierzytelnianie usługi .NET Passport. Opcja Uwierzytelnianie systemu Windows może służyć do kontrolowania dostępu do ASP.NET usług sieci Web. Jednak gdy aplikacje WCF są hostowane w usługach IIS, usługi IIS muszą być skonfigurowane tak, aby zezwalały na anonimowy dostęp do aplikacji, aby można było zarządzać uwierzytelnianiem przez samą usługę WCF, która obsługuje uwierzytelnianie systemu Windows między różnymi innymi opcjami. Inne opcje, które są wbudowane, obejmują tokeny nazw użytkowników, certyfikaty X.509, tokeny SAML i kartę CardSpace, ale niestandardowe mechanizmy uwierzytelniania można również zdefiniować.

Zabezpieczenia: Personifikacja

ASP.NET udostępnia element tożsamości ASP.NET, za pomocą którego można personifikować określonego użytkownika lub niezależnie od tego, które poświadczenia użytkownika są dostarczane z bieżącym żądaniem. Za pomocą tego elementu można skonfigurować personifikację w aplikacjach WCF działających w trybie zgodności ASP.NET.

System konfiguracji programu WCF udostępnia własny element tożsamości na potrzeby personifikacji określonego użytkownika. Ponadto klienci i usługi WCF można skonfigurować niezależnie pod kątem personifikacji. Klienci mogą być skonfigurowani do personifikacji bieżącego użytkownika podczas przesyłania żądań.

<behaviors>
     <behavior name="DerivativesCalculatorClientBehavior">
      <clientCredentials>
      <windows allowedImpersonationLevel="Impersonation"/>
      </clientCredentials>
     </behavior>
</behaviors>

Operacje usługi można skonfigurować pod kątem personifikacji poświadczeń użytkownika z bieżącym żądaniem.

[OperationBehavior(Impersonation = ImpersonationOption.Required)]
public void Receive(Message input)

Zabezpieczenia: autoryzacja przy użyciu list kontroli dostępu

Listy kontroli dostępu (ACL) mogą służyć do ograniczania dostępu do plików asmx. Listy ACL w plikach svc programu WCF są jednak ignorowane z wyjątkiem trybu zgodności ASP.NET.

Zabezpieczenia: autoryzacja oparta na rolach

Opcja Uwierzytelnianie systemu Windows usług IIS może być używana w połączeniu z elementem autoryzacji dostarczonym przez język konfiguracji ASP.NET w celu ułatwienia autoryzacji opartej na rolach dla ASP.NET usług sieci Web opartych na grupach systemu Windows, do których przypisano użytkowników. ASP.NET 2.0 wprowadzono bardziej ogólny mechanizm autoryzacji oparty na rolach: dostawców ról.

Dostawcy ról to klasy, które implementują podstawowy interfejs do badania ról, do których przypisano użytkownika, ale każdy dostawca roli wie, jak pobrać te informacje z innego źródła. ASP.NET 2.0 udostępnia dostawcę ról, który może pobierać przypisania ról z bazy danych programu Microsoft SQL Server, a inny, który może pobierać przypisania ról z Menedżera autoryzacji systemu Windows Server 2003.

Mechanizm dostawcy ról może być używany niezależnie od ASP.NET w dowolnej aplikacji platformy .NET, w tym aplikacji WCF. Poniższa przykładowa konfiguracja aplikacji WCF pokazuje, jak użycie dostawcy ról ASP.NET jest opcją wybraną za pomocą .ServiceAuthorizationBehavior

<system.serviceModel>
     <services>
         <service name="Service.ResourceAccessServiceType"
             behaviorConfiguration="ServiceBehavior">
             <endpoint
              address="ResourceAccessService"
              binding="wsHttpBinding"
              contract="Service.IResourceAccessContract"/>
         </service>
     </services>
     <behaviors>
       <behavior name="ServiceBehavior">
       <serviceAuthorization principalPermissionMode="UseAspNetRoles"/>
      </behavior>
     </behaviors>
</system.serviceModel>

Zabezpieczenia: autoryzacja oparta na oświadczeniach

Jedną z najważniejszych innowacji WCF jest dokładna obsługa autoryzowania dostępu do chronionych zasobów na podstawie oświadczeń. Oświadczenia składają się z typu, prawa i wartości, na przykład prawa jazdy. Składa zestaw roszczeń na temat elementu nośnego, z których jeden jest datą urodzenia elementu nośnego. Typ tego roszczenia to data urodzenia, a wartość roszczenia jest datą urodzenia kierowcy. Prawo, które oświadczenie nadaje elementu nośnego, określa, co element nośny może zrobić z wartością oświadczenia. W przypadku roszczenia o datę urodzenia kierowcy prawo ma prawo: kierowca posiada ten dzień urodzenia, ale nie może na przykład go zmienić. Autoryzacja oparta na oświadczeniach obejmuje autoryzację opartą na rolach, ponieważ role są typem oświadczenia.

Autoryzacja oparta na oświadczeniach jest wykonywana przez porównanie zestawu oświadczeń z wymaganiami dostępu operacji i, w zależności od wyniku tego porównania, udzielenia lub odmowy dostępu do operacji. W programie WCF można określić klasę do użycia do uruchamiania autoryzacji opartej na oświadczeniach, przypisując wartość do ServiceAuthorizationManager właściwości ServiceAuthorizationBehavior.

<behaviors>
     <behavior name='ServiceBehavior'>
     <serviceAuthorization
     serviceAuthorizationManagerType=
                   'Service.AccessChecker, Service' />
     </behavior>
</behaviors>

Klasy używane do uruchamiania autoryzacji opartej na oświadczeniach muszą pochodzić z ServiceAuthorizationManagerklasy , która ma tylko jedną metodę zastąpienia, AccessCheck(). Program WCF wywołuje tę metodę za każdym razem, gdy jest wywoływana operacja usługi i udostępnia OperationContext obiekt, który zawiera oświadczenia dla użytkownika we właściwości ServiceSecurityContext.AuthorizationContext . Program WCF wykonuje pracę tworzenia oświadczeń dotyczących użytkownika z dowolnego tokenu zabezpieczającego, który użytkownik dostarczył do uwierzytelniania, co pozostawia zadanie oceny, czy te oświadczenia są wystarczające dla danej operacji.

Ta usługa WCF automatycznie tworzy oświadczenia z dowolnego rodzaju tokenu zabezpieczającego jest bardzo znaczącą innowacją, ponieważ sprawia, że kod autoryzacji oparty na oświadczeniach jest całkowicie niezależny od mechanizmu uwierzytelniania. Natomiast autoryzacja przy użyciu list ACL lub ról w ASP.NET jest ściśle powiązana z uwierzytelnianiem systemu Windows.

Bezpieczeństwo: poufność

Poufność wiadomości wymienianych z usługami sieci Web ASP.NET można zapewnić na poziomie transportu, konfigurując aplikację w usługach IIS w celu korzystania z protokołu HTTPS (Secure Hypertext Transfer Protocol). Można to zrobić w przypadku aplikacji WCF hostowanych w usługach IIS. Jednak aplikacje WCF hostowane poza usługami IIS można również skonfigurować tak, aby korzystały z bezpiecznego protokołu transportu. Co ważniejsze, aplikacje WCF można również skonfigurować pod kątem zabezpieczania komunikatów przed ich transportem przy użyciu protokołu WS-Security. Zabezpieczanie tylko treści wiadomości przy użyciu usługi WS-Security umożliwia jej poufne przesyłanie między pośrednikami przed dotarciem do jego ostatecznego miejsca docelowego.

Globalizacja

Język konfiguracji ASP.NET umożliwia określenie kultury poszczególnych usług. Program WCF nie obsługuje tego ustawienia konfiguracji z wyjątkiem trybu zgodności ASP.NET. Aby zlokalizować usługę WCF, która nie korzysta z trybu zgodności ASP.NET, skompiluj typ usługi do zestawów specyficznych dla kultury i mają oddzielne punkty końcowe specyficzne dla kultury dla każdego zestawu specyficznego dla kultury.

Zobacz też

Porównanie usług internetowych platformy ASP.NET i architektury WCF na podstawie przeznaczenia oraz stosowanych standardów

Udostępnij za pośrednictwem