wcf soa

Anti-patrón de SOA o WCF



(5)

Aunque puedo encontrar muchos artículos que abogan por SOA o WCF, mi pregunta es que lo que no debe exponerse como servicio, ¿hay alguna disminución que aprendamos del fracaso de SOA? WCF es una forma de implementar SOA, si usamos WCF, significa que estamos implementando SOA. Seguro que hay mucha gente que usa C # escribiendo un código no permanente.

Creo que tienes razón En mi asignación actual (desarrollo web), cada acceso a la base de datos se implementa como un servicio. Somos "PURE SOA", como dijo el arquitecto principal ... ¡Guau!

En realidad, esto agrega mucha complejidad a todo. Cuando quiero leer el contenido de una tabla simple, debo generar algo así como 8 proyectos, 42 archivos, 8 ensamblajes y probablemente 9 archivos de configuración.

Mucha complejidad como dije. Es probable que alguien olvide en algún lugar un archivo ... Exponer un proceso simple como un servicio es estúpido.

En mis libros, debe exponer sus procesos como un servicio cuando:

  • Muchas aplicaciones que usan diferentes lenguajes y marcos tienen que llamar tus cosas.
  • Hay más de una plataforma involucrada (Windows, Unix ...).
  • Los datos que se manejan son el núcleo de la empresa.

Además, observe que un servicio debe estar DISEÑADO para ser un servicio, y que diseñar un servicio es al menos tan complejo como diseñar una biblioteca: la captura de errores debe elaborarse cuidadosamente, el registro debe ser lo suficientemente flexible, la documentación debe estar completa, etc.

Bueno, como puedo ver, la mayoría de los servicios que uso a diario no serán utilizados por otras personas: sin documentación, manejo deficiente de errores, código sujeto a cambios frecuentes, datos de segunda zona ...

Bueno, una pregunta muy interesante. 1 punto: o)

Hay dos antipatrones principales que conozco:

  • Exponer directamente objetos de su capa empresarial a través de su capa de servicio
  • Exponer métodos específicos de grano fino, como los de su capa empresarial

La recomendación es que su capa de servicio contenga métodos genéricos de grano grueso, y que acepten y devuelvan solicitudes y respuestas bastante grandes basadas en mensajes. El objetivo es proporcionar una interfaz bastante genérica, sin hacer demasiadas suposiciones sobre cómo se utilizará el servicio, y sin requerir numerosas llamadas para lograr la funcionalidad básica. Intente minimizar la cantidad de llamadas al servicio web.

Aquí hay algunos consejos excelentes a un alto nivel: http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines

Aquí hay un ejemplo específico del tipo de clases de "mensaje" de las que habla la guía, y cómo implementar una en WCF: http://dotnet.org.za/hiltong/pages/windows-communication-foundation-tutorial-part-3-messaging-messagecontracts.aspx

SOA como concepto es una gran idea.

SOA como se implementó usando HTTP-WS / BPEL et al es una broma que merece morir en mi punto de vista no tan humilde. Dejé de tomar el sistema en serio poco después de aprender que su único concepto de transacciones distribuidas son las transacciones de compensación ... bzzt ¡PRÓXIMO!

SOA es uno de los conceptos peor presentados. SOA es un estilo arquitectónico y no tiene nada que ver con los servicios web ni con ninguna tecnología. Estoy de acuerdo en que explicar SOA a través de servicios web y BPEL es engañoso, BPEL generalmente no tiene nada que ver con SOA, sino que es una forma de implementar WS orchestration. Los vendedores hicieron un terrible lío.

Sugiero un libro descargable muy bueno, que explica realmente qué es SOA:

http://www.infoq.com/minibooks/enterprise-soa

Entonces podrías leer esta interesante entrada de blog

Saludos