¿Cuándo no se debe usar un servicio web?

Question

El uso de un servicio web suele ser un excelente enfoque arquitectónico. Y, con la llegada de WCF en .Net, se está haciendo aún mejor.

Pero, en mi experiencia, algunas personas parecen pensar que los servicios web siempre deben usarse en la capa de acceso a datos para las llamadas a la base de datos. No creo que los servicios web sean la solución universal.

Estoy pensando en aplicaciones de intranet más pequeñas con unas pocas docenas de usuarios. La aplicación web y su servicio web se implementan en un servidor web, no en una granja de servidores web. No va a haber otra aplicación web en el futuro que pueda usar este servicio web en particular. Me parece que el costo de llamar al servicio web aumenta innecesariamente la carga en el servidor web. Hay un rendimiento alcanzado para llamadas entre procesos. Mantener y depurar el código de la aplicación web y el servicio web es más complicado. También lo es el despliegue. Simplemente no veo las ventajas de usar un servicio web aquí.

Se puede probar esto creando dos versiones de la aplicación web, con y sin el servicio web, y realizando pruebas de resistencia, pero no lo he hecho.

¿Tiene una opinión sobre el uso de servicios web para aplicaciones web a pequeña escala? ¿En otras ocasiones cuando los servicios web no son una buena opción arquitectónica?

Answer 1

Los servicios web son una opción absolutamente horrible para el acceso a los datos. Es un montón de sobrecarga y complejidad para casi cero beneficio.

Si su aplicación se va a ejecutar en una máquina, ¿por qué no puede realizar llamadas de acceso a datos en proceso? No estoy hablando de acceder directamente a la base de datos desde su código de UI, estoy hablando de abstraer sus repositorios pero aún incluir sus ensamblajes en su sitio web en ejecución.

Hay casos en los que recomendaría servicios web (y supongo que usted quiere decir SOAP), pero eso es principalmente para la interoperabilidad.

La granularidad de los servicios también está en cuestión aquí. Un servicio en el sentido SOA encapsulará una operación o un proceso comercial. Los métodos de acceso a los datos son solo parte de ese proceso.

En otras palabras:

- someService.SaveOrder(order); // <-- bad 
    // some other code for shipping, charging, emailing, etc 

    - someService.FulfillOrder(order); //<-- better 
    //the service encapsulates the entire process 

servicios web para el bien de los servicios web es la programación irresponsable.

Answer 2

Si solo está codificando una pequeña (menos de 50 usuarios) aplicación web para su intranet, un servicio web parece excesivo. Especialmente si su función principal (que proporciona un único punto de acceso a muchos servicios) no será utilizada.

Answer 3

Para una aplicación web a pequeña escala (sin embargo, debe formularse la pregunta "¿Seguirá siempre en pequeña escala?) Utilizando servicios web, capas comerciales separadas, capas de datos, etc., pueden ser excesivas. .

Antes de que alguien me ataque, estoy de acuerdo en que la separación de la lógica entre las capas junto con las pruebas unitarias, la integración continua, etc. son absolutamente sangrientas. En mi rol actual, estaría completamente perdido y meciéndome en la esquina sin ellos. Sin embargo, para una aplicación web de muy pequeña escala utilizada, por ejemplo, para rastrear números de contacto y direcciones de una compañía de 36 empleados, el análisis costo/beneficio sugeriría que todas las "sutilezas" enumeradas anteriormente serían exageradas.

Sin embargo ... Recuerde hacer la pregunta "¿Seguirá siendo siempre de pequeña escala?" :-)

Answer 4

Acepto que el uso de un servicio web en una aplicación web a pequeña escala agrega una capa de complejidad que no parece justificada. La mayoría de mis soluciones, Internet e Intranet, entre 10 y 50 usuarios, no emplean servicios web. Me alegra que los demás sientan lo mismo ... Pensé que era el único.

Answer 5

El hecho de que la herramienta genere varios talones no significa que sea un buen uso. WS- * sobresale en escenarios en los que expone servicios a partes externas. Esto significa que cada operación debe estar en la granularidad del proceso de negocio en lugar del acceso a datos.

La multitud de estándares se puede utilizar para describir diferentes facetas de su contrato con gran detalle y una (hipotética) pila de WS totalmente compatible puede quitarle mucho dolor a los desarrolladores de terceros e incluso permitir el punto legendario y hacer clic integración a'la Yahoo Pipes. Con buenos controles de gobierno, puede desarrollar su interfaz pública y administrar la compatibilidad hacia atrás según sea necesario.

Todo esto es casi imposible de generar automáticamente. El generador de código auxiliar de C# solo conoce la interfaz física de su clase, pero no tiene ninguna idea sobre la semántica involucrada. Ver this paper para una discusión más detallada.

Si está construyendo un sitio web, entonces cree un sitio web. Si desea mensajería asíncrona dentro de su aplicación, use MSMQ. Si desea exponer datos a clientes internos, use POX. Si necesita un formato de mensaje binario eficiente, consulte el Protocol Buffers de Google o si necesita una verificación de RPC Hessian for C# o DCOM.

Los servicios web son una solución de integración de grano grueso. Son rígidos, son más lentos que las alternativas, toman demasiado esfuerzo para hacerlo bien (y cuando no se hacen bien son casi inútiles).

En resumen: "¿Cuándo se debería utilizar un servicio web no?" - en cualquier momento se puede salir sin él

Answer 6

Nick Harrison, un desarrollador brillante en Charlotte, sugirió estos escenarios en los que el uso de un servicio web tiene sentido:

• En una granja de servidores web, donde hay varios servidores de alojamiento web sitio (s) web, todos apuntando a servicio (s) web que se ejecutan en otro servidor web. Esto permite distribuir la carga en múltiples servidores.
• Cliente/servidor, donde las aplicaciones de formularios de Windows pueden llamar a un servicio web.
• Cruz plataforma
• Pasando a través de un cortafuegos

Answer 7

Para una pequeña aplicación web escala Creo que el uso de los servicios web es a menudo bastante una buena idea, que se puede utilizar para desacoplar fácilmente el servidor web de los datos nivel. Con los requisitos de desarrollo directo y las excelentes herramientas, no veo el problema.

Sin embargo hacer no servicios web de uso en los siguientes escenarios:

• Cuando debe utilizar HTTP como el transporte y la serialización XML de los datos y que necesita una gran cantidad de diferentes bits de datos, de forma sincrónica y a menudo. Ya sea REST o SOAP o WS- *, usted sufrirá problemas de rendimiento. Cuantas más llamadas haga, más lento será su sistema.Si desea trozos de datos de tamaño medio con menos frecuencia, de forma asincrónica y puede usar TcpIp directo (por ejemplo, Wcf netTcpBinding), estaría mejor.
• Cuando tenga que consultar y unirse a los datos de su servicio web con otras fuentes de datos, en vez motivar a un almacén de datos que puede ser rellena con datos debidamente consolidados y racionalizados de todo el enterprize

Esta es mi experiencia , Espero eso ayude.