asp.net - services - ¿Cuándo no se debe usar un servicio web?
web services (7)
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.
El uso de un servicio web a menudo es 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í.
Uno podría probar esto creando dos versiones de la aplicación web, con y sin el servicio web, y haciendo pruebas de estrés, 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?
El hecho de que la herramienta genere varios talones no significa que sea un buen uso. WS- * sobresale en escenarios donde 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 en 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 en 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. Vea este documento 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, revise los Búferes de Protocolo de Google o si necesita RPC, consulte 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 hacen bien son casi inútiles).
Para resumir: "¿Cuándo no se debe usar un servicio web?" - cada vez que puedes salir sin él
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 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 te refieres a SOAP), pero eso es principalmente para la interoperabilidad.
La granularidad de los servicios también está en duda 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
Los servicios web por el bien de los servicios web son una programación irresponsable.
Nick Harrison, un brillante desarrollador en Charlotte, sugirió estos escenarios donde el uso de un servicio web tiene sentido:
- En una granja de servidores web, donde hay varios servidores web que alojan sitios web, todos apuntan a servicios 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.
- Plataforma cruzada
- Pasando por un firewall
Para una aplicación web a pequeña escala, creo que el uso de servicios web suele ser una buena idea, puede usarlo para desacoplar fácilmente el servidor web del nivel de datos. Con los requisitos de desarrollo directo y las excelentes herramientas, no veo el problema.
Sin embargo , no use servicios web en los siguientes escenarios:
- Cuando debe utilizar Http como el transporte y la serialización Xml de sus datos y necesita muchos bits de datos diferentes, de forma sincrónica y con frecuencia. 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 utilizar TcpIp directo (por ejemplo, Wcf netTcpBinding), estaría mejor.
- Cuando necesite consultar y unir datos de su servicio web con otras fuentes de datos, en lugar de motivar para un depósito de datos que puede ser llenado con datos racionalizados y consolidados adecuadamente de toda la empresa.
Esta es mi experiencia, espero que ayude.
Si solo está codificando una aplicación web pequeña (menos de 50 usuarios) 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.
Sin embargo, para una aplicación web a pequeña escala (sin embargo, debe formularse la pregunta "¿Seguirá siendo siempre de pequeña escala?) El uso de servicios web, capas comerciales separadas, capas de datos, etc., puede ser exagerado.
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 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á siempre en pequeña escala?" :-)