2010-02-03 29 views
16

Descubrí que puedo importar un servicio SOAP/WSDL que planeo usar en mi solución como una "Referencia de servicio web" (System.Web.Services) o como una "Referencia de servicio" (System.ServiceModel/WCF).Visual Studio/SOAP - 'Agregar referencia de servicio' frente a 'Agregar referencia de servicio web'

Me preguntaba si cuáles eran las diferencias. Entiendo que 'Agregar referencia de servicio'/WCF es más nuevo, ¿hay alguna desventaja al usarlo en System.Web.Services o es ahora la forma preferida de consumir servicios SOAP en .Net?

Respuesta

21

La forma preferida y más útil es usar Add Service Reference. Esto agregará su servicio como proxy del lado del cliente WCF.

Add Web Reference es la manera "antigua" de servicio web ASMX/ASP.NET de hacer las cosas.

WCF es la mejor opción que ASMX, porque:

  • es más nuevo y se apoyará en el futuro (ASMX está en el camino de salida); si lo aprende ahora, no tendrá que aprenderlo más tarde cuando ASMX se haya ido definitivamente
  • ofrece mucha más flexibilidad en todos los aspectos
  • que solo puede alojar un servicio ASMX es IIS, usando HTTP como su protocolo ; WCF se puede alojar en IIS; autohospedado en un servicio de Windows NT; WCF puede utilizar HTTP, NetTCP, MSMQ y muchos más protocolos
  • WCF ofrece mucha más seguridad y otros ajustes, por lo que es mucho más potente para usar

Sí, WCF tiene una mala reputación de ser muy difícil Aprender - Realmente no encuentro eso para ser verdad. Echa un vistazo a esos recursos para principiantes, ¡muy útiles!

+0

Gracias por los enlaces Marc! Siempre buscando más información. :) –

+0

Esos 3 enlaces de pluralsight parecen estar rotos ... – fretje

+0

@fretje: sí, lo siento, decidieron hacer que los screencasts en su propio sitio solo estuvieran disponibles para los suscriptores ... Trataré de encontrarlos nuevamente en el WCF Developer Center y actualizar los enlaces ... espere ..... –

3

Creo que una de las diferencias está en el código de proxy autogenerado para el servicio. Si va con la referencia de servicio, su aplicación requerirá que la capa WCF se comunique. Esto generalmente no es un problema, pero si está escribiendo código que se ejecutará en otras plataformas (como Mono), querrá utilizar la referencia del servicio web (ya que Mono aún no es compatible con WCF).

6

Tengo una aplicación que está llamando a un servicio SOAP existente que está escrito en J2EE y alojado en WebSphere.

He creado dos aplicaciones de consola, una que hace referencia al servicio como un servicio web de la vieja escuela y otra que lo hace referencia como una referencia de servicio.

En ambos casos, Visual Studio crea una clase de proxy y entradas de configuración apropiadas para el servicio.

En la aplicación de consola de referencia de servicio, obtengo muchas más opciones de configuración que no veo en la aplicación de servicio web. En particular, puedo establecer el tamaño máximo de mensaje, etc.

De hecho, para que la aplicación de consola de referencia de servicio funcione correctamente, tuve que aumentar el tamaño de mensaje predeterminado para recuperar todos los datos enviados en una de las llamadas al método.

Esto es lo que la configuración se ve como en la aplicación de servicio Referencia:

<configuration> 
    <system.serviceModel> 
     <bindings> 
      <basicHttpBinding> 
       <binding name="ClaimSoapBinding" closeTimeout="00:01:00" openTimeout="00:01:00" 
        receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" 
        bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" 
        maxBufferSize="65536000" maxBufferPoolSize="524288" maxReceivedMessageSize="65536000" 
        messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" 
        useDefaultWebProxy="true"> 
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
         maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
        <security mode="None"> 
         <transport clientCredentialType="None" proxyCredentialType="None" 
          realm="" /> 
         <message clientCredentialType="UserName" algorithmSuite="Default" /> 
        </security> 
       </binding> 
      </basicHttpBinding> 
     </bindings> 
     <client> 
      <endpoint address="http://urlgoeshere/ClaimService" 
       binding="basicHttpBinding" bindingConfiguration="ClaimSoapBinding" 
       contract="ClaimService.Claim" name="ClaimService" /> 
     </client> 
    </system.serviceModel> 
</configuration> 

En mi escuela vieja aplicación de consola Web Service, yo no tenía que alterar la configuración del todo para volver el conjunto gigante de datos enviados de vuelta. Esto es lo que se ve su configuración como:

<configuration> 
    <configSections> 
     <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > 
      <section name="ServiceTesterOldSchool.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> 
     </sectionGroup> 
    </configSections> 
    <applicationSettings> 
     <ServiceTesterOldSchool.Properties.Settings> 
      <setting name="ServiceTesterOldSchool_ClaimService_ClaimService" 
       serializeAs="String"> 
       <value>http://urlgoeshere/ClaimService</value> 
      </setting> 
     </ServiceTesterOldSchool.Properties.Settings> 
    </applicationSettings> 
</configuration> 

Es mucho más simple, pero carece de muchas de las opciones que se obtiene con las referencias de servicio.

El código real que llama al servicio es casi idéntico en ambos casos.

Para responder a su pregunta, creo que es importante seguir con la forma actual de hacer las cosas. Microsoft deja esto en claro al obligarlo a pasar por un par de niveles de diálogos antes de que pueda agregar una referencia web de la vieja escuela (al menos en VS2008).

Creo que la forma de WCF es más flexible, y la configuración es mucho más descriptiva sobre lo que está sucediendo.

Además, a medida que agrega nuevos componentes WCF a sus aplicaciones, será bueno mantener la configuración constante, en lugar de mezclar y combinar entre la vieja escuela y WCF.

Cuestiones relacionadas