Планирование перехода на платформу Windows Communication Foundation: упрощение будущей миграции

Статья
03/05/2024

Чтобы упростить дальнейшую миграцию новых приложений ASP.NET в WCF, следуйте приведенным выше рекомендациям, а также приведенным ниже рекомендациям.

Протоколы

Отключите поддержку ASP.NET 2.0 для SOAP 1.2:

<configuration>  
     <system.web>  
      <webServices >  
          <protocols>  
           <remove name="HttpSoap12"/>  
          </protocols>
      </webServices>  
     </system.web>
</configuration>

Это рекомендуется, так как WCF требует, чтобы сообщения соответствовали разным протоколам, таким как SOAP 1.1 и SOAP 1.2, для перехода с помощью разных конечных точек. Если веб-служба ASP.NET 2.0 настроена для поддержки SOAP 1.1 и SOAP 1.2, которая является конфигурацией по умолчанию, она не может быть перенесена на одну конечную точку WCF на исходном адресе, который, безусловно, будет совместим со всеми существующими клиентами веб-службы ASP.NET. Кроме того, выбор версии SOAP 1.2 вместо версии 1.1 будет более строго ограничивать клиентуру службы.

Разработка служб

WCF позволяет определять контракты служб, применяя ServiceContractAttribute их к интерфейсам или классам. Рекомендуется применять этот атрибут для интерфейса, а не для класса, поскольку при этом создается определение контракта, который может быть по-разному реализован любым количеством классов. ASP.NET 2.0 поддерживает возможность применения атрибута WebService для интерфейсов и классов. Однако, как уже было сказано, в ASP.NET 2.0 существует недостаток, из-за которого параметр Namespace атрибута WebService не имеет силы, если этот атрибут применяется для интерфейса, а не класса. Так как обычно рекомендуется изменить пространство имен службы из значения по умолчанию, http://tempuri.orgиспользуя параметр WebService пространства имен атрибута, следует продолжать определять ASP.NET веб-службы, применяя ServiceContractAttribute атрибут к интерфейсам или классам.

Обеспечьте минимально возможный код в методах, с помощью которых определяются эти интерфейсы. Заставьте их делегировать свою работу в другие классы. Затем новые типы служб WCF могут делегировать основную работу этим классам.
Обеспечьте явные имена для операций службы, используя параметр MessageName атрибута WebMethodAttribute.
```
[WebMethod(MessageName="ExplicitName")]  
string Echo(string input);  
```
Это важно, так как имена по умолчанию для операций в ASP.NET отличаются от имен по умолчанию, предоставленных WCF. Обеспечение явных имен исключает необходимость полагаться на имена по умолчанию.
Не реализуйте ASP.NET операции веб-службы с полиморфными методами, так как WCF не поддерживает реализацию операций с полиморфными методами.
Используйте атрибут SoapDocumentMethodAttribute, чтобы обеспечить явные значения для заголовков SOAPAction HTTP, по которым запросы HTTP будут направляться в методы.
```
[WebMethod]  
[SoapDocumentMethod(RequestElementName="ExplicitAction")]  
string Echo(string input);  
```
Использование этого подхода будет обойти необходимость полагаться на значения SOAPAction по умолчанию, используемые ASP.NET и WCF одинаковыми.
Избегайте использования расширений SOAP. Если необходимы расширения SOAP, определите, является ли назначение, для которого они рассматриваются, — это функция, которая уже предоставляется WCF. Если это действительно так, то пересмотреть выбор, чтобы не принять WCF сразу.

Управление данными о состоянии

Избегайте поддержания состояния в службах. Не только сохранение состояния, как правило, компрометирует масштабируемость приложения, но механизмы управления состоянием ASP.NET и WCF очень отличаются, хотя WCF поддерживает механизмы ASP.NET в режиме совместимости ASP.NET.

Обработка исключений.

При разработке структур типов данных, которые должны передаваться и приниматься службой, разработайте также структуры для представления различных типов исключений, которые могут происходить в службе и подлежать передаче клиенту.

[Serializable]  
[XmlRoot(Namespace="ExplicitNamespace", IsNullable=true)]  
public partial class AnticipatedException
{
    private string anticipatedExceptionInformationField;  

    public string AnticipatedExceptionInformation
    {  
        get {
            return this.anticipatedExceptionInformationField;  
        }  
        set {  
            this.anticipatedExceptionInformationField = value;  
        }  
    }  
}

Предоставьте таким классам возможность сериализовать себя в XML:

public XmlNode ToXML()  
{  
     XmlSerializer serializer = new XmlSerializer(  
      typeof(AnticipatedException));  
     MemoryStream memoryStream = new MemoryStream();  
     XmlTextWriter writer = new XmlTextWriter(  
     memoryStream, UnicodeEncoding.UTF8);  
     serializer.Serialize(writer, this);  
     XmlDocument document = new XmlDocument();  
     document.LoadXml(new string(  
     UnicodeEncoding.UTF8.GetChars(  
     memoryStream.GetBuffer())).Trim());  
    return document.DocumentElement;  
}

Затем классы могут использоваться для предоставления сведений в отношении явно вызванных экземпляров SoapException:

AnticipatedException exception = new AnticipatedException();  
exception.AnticipatedExceptionInformation = "…";  
throw new SoapException(  
     "Fault occurred",  
     SoapException.ClientFaultCode,  
     Context.Request.Url.AbsoluteUri,  
     exception.ToXML());

Эти классы исключений будут легко использовать повторно с классом WCF FaultException<TDetail> для создания нового FaultException<AnticipatedException>(anticipatedException);

Безопасность

Ниже приведены некоторые рекомендации по безопасности.

Избегайте использования профилей ASP.NET версии 2.0, так как они ограничивают использование режима интеграции ASP.NET, если служба была перенесена в WCF.
Избегайте использования списков управления доступом к службам, так как веб-службы ASP.NET поддерживают списки управления доступом с помощью службы IIS (IIS), WCF не делает этого, так как ASP.NET веб-службы зависят от служб IIS для размещения, и WCF не обязательно должны размещаться в СЛУЖБАх IIS.
Не принимайте во внимание использование поставщиков ролей ASP.NET 2.0 для авторизации доступа к ресурсам службы.

См. также

Планирование перехода на платформу Windows Communication Foundation: упрощение будущей интеграции

Поделиться через