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

El uso de un servicio web es a menudo un excelente enfoque arquitectónico. Y, con el advenimiento de WCF en. Net, es cada vez mejor.

Pero, en mi experiencia, algunas personas parecen pensar que los servicios web siempre deben usarse en la capa de acceso a datos para 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 es una granja web. No va a haber otra aplicación web en el futuro que pueda utilizar 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 impacto en el rendimiento de las llamadas entre procesos. Mantener y depurar el código para 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í.

Uno podría probar esto creando dos versiones de la aplicación web, con y sin el servicio web, y hacer pruebas de estrés, pero no lo he hecho.

¿Tiene una opinión sobre el uso de servicios web para aplicaciones web de pequeña escala? ¿Alguna otra ocasión en la que los servicios web no son una buena opción arquitectónica?

Author: DOK, 2008-10-15
Source

7 answers

Los servicios web son una opción absolutamente horrible para el acceso a los datos. Es una tonelada de gastos generales y complejidad para casi ningún beneficio.

Si su aplicación se va a ejecutar en una máquina, ¿por qué negarle la capacidad de hacer llamadas de acceso a datos en proceso? No estoy hablando de acceder directamente a la base de datos desde su código de interfaz de usuario, estoy hablando de abstraer sus repositorios de distancia, pero todavía incluyendo sus ensamblados en su sitio web en ejecución.

Hay casos en los que recomendaría web servicios (y asumo que te refieres a 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 de negocio. Los métodos de acceso a datos son solo una 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 por el bien de los servicios web es programación irresponsable.

 33
Author: Ben Scheirman,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-15 13:35:13

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

  • En una granja web, donde hay varios servidores web que alojan sitios web, todos apuntando a servicios web que se ejecutan en otro servidor web. Esto permite distribuir la carga en varios servidores.
  • Cliente/servidor, donde las aplicaciones de Windows Forms pueden llamar a un servicio web.
  • Multiplataforma
  • Pasando por un cortafuegos
 14
Author: DOK,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-15 13:55:42

Solo porque la herramienta genere un montón de talones no significa que sea un buen uso. WS - * sobresale en escenarios donde se exponen 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 pila de WS (hipotética) totalmente compatible puede quitar mucho dolor a los desarrolladores de terceros y incluso permitir el punto legendario y haga clic en integración a'la Yahoo Pipes. Con los controles de buen gobierno, puede evolucionar su interfaz pública y administrar la compatibilidad con versiones anteriores según sea necesario.

Todo esto es casi imposible de generar automáticamente. El generador de stub de C# solo conoce la interfaz física de su clase, pero no tiene idea de la semántica involucrada. Véase este documento para una discusión más detallada.

Si usted está construyendo un sitio web, a continuación, construir un website. Si desea mensajería asíncrona dentro de su aplicación, use MSMQ. Si desea exponer datos a clientes internos, utilice POX. Si necesita un formato de mensaje binario eficiente, verifique los búferes de protocolo de Google o si necesita RPC verifique Hessian para 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 hace bien están al lado de inútil).

Para resumir: "¿Cuándo debería usarse un servicio web no?"- en cualquier momento usted puede conseguir lejos sin él

 6
Author: ddimitrov,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-25 12:43:16

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

 5
Author: Jared,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-10-06 11:13:47

Estoy de acuerdo en que el uso de un servicio web en una aplicación web de pequeña escala agrega una capa de complejidad que no parece justificada. La mayoría de mis soluciones, internet e intranet, 10-50 usuarios, no emplean servicios web. Me alegra que otros sientan lo mismo...Pensé que era el único.

 3
Author: MBoy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-15 13:25:52

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

Sin embargo no use servicios web en los siguientes escenarios:

  • Cuando debe usar Http como el transporte y serialización Xml de sus datos y necesita muchos bits diferentes de datos, sincrónicamente y a menudo. Ya sea DESCANSO o JABÓN o WS- *vas a sufrir problemas de rendimiento. Cuantas más llamadas realice, más lento será su sistema. Si desea trozos de datos de tamaño mediano con menos frecuencia, de forma asíncrona y puede usar TcpIp directo (por ejemplo, Wcf NetTcpBinding), estaría mejor.
  • Cuando necesite consultar y unir datos de su servicio web con otras fuentes de datos, más bien motive un almacén de datos que se pueda llenar con datos debidamente consolidados y racionalizados de todo el enterprize

Esta es mi experiencia, espero que ayude.

 3
Author: Matthew,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2009-08-12 14:47:44

Para una aplicación web a pequeña escala (tienes que preguntar: "¿Siempre seguirá siendo a pequeña escala?"sin embargo) el uso de servicios web, capas de negocio separadas, capas de datos, etc., puede ser excesivo.

Antes de que alguien me dispare, 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 increíblemente brillantes. En mi papel actual estaría completamente perdido y balanceándome en la esquina sin ellos. Sin embargo, para una aplicación web de muy pequeña escala que se utiliza para, por ejemplo, rastrear los números de contacto y las direcciones de una empresa de 36 empleados, el análisis de costo/beneficio sugeriría que todas las "sutilezas" enumeradas anteriormente serían excesivas.

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

 2
Author: Rob,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2008-10-15 13:25:33