"Vamos a imaginar un lindo mundo de SOA-Feliz donde las necesidades informáticas de una empresa se dividen en muchas pequeñas aplicaciones que proporcionan servicios entre sí para permitir una cooperación eficaz. Una bella mañana un servicio consumidor precisa de información de un servicio proveedor. " Martin Fowler habla acerca de los problemas que cualquier unidad de negocio de una infraestructura SOA se enfrenta.
En un mundo ideal los desarrolladores del servicio consumidor sólo piden servicio al proveedor para desarrollar un servicio potencial y eso es todo. Pero la vida real no es ideal - el punto problemático aquí es que los desarrolladores del servicio proveedor tiene otras cosas que hacer, por lo general cosas que son más importantes para su cliente y para la gerencia antes que ayudar al equipo del servicio consumidor.
Martin apunta un ejemplo de una solución del mundo real para el problema, empleado por el colega Erik Dörnenburg.
Ellos tiraron una hoja del libro de normas de código abierto (open source) e hicieron todos sus servicios en sistemas código abierto (open source) internos. Esto permite a los desarrolladores del servicio del consumidor escribir el servicio por sí mismos.
Sugiere que alguien podría trabajar en mejorar el servicio y presentar "parches" que se analizan y se "aplican" por un tutor del servicio. Él compara el papel de un tutor del servicio a un mantenedor de código abierto (open source) y "aunque el enfoque no elimina el problema de desarrolladores consumidores que necesitan esperar a que los desarrolladores proveedores, hace muchas cosas para reducir en gran medida las dificultades". Sugiere que es más fácil para el tutor aplicar "parches" antes que desarrollar mejoras en el servicio y que el proceso escala muy bien ya que el desarrollador del servicio consumidor se gana la confianza del tutor a lo largo del tiempo.
La responsabilidad del tutor del servicio puede ser vital para el éxito de este enfoque. La solución que Martin sugiere, puede ser relacionada con SOA de Guerrilla de Jim Webber, un esfuerzo masivo de la arquitectura SOA.
Tony Baer, a partir de SOA Insights podcasts, advierte de los riesgos potenciales de este enfoque.
¿Qué sucede si el proyecto crece tanto que, para responder a un nuevo requisito, se crea un nuevo servicio a partir de cero, porque así se hará el trabajo mucho mas rápido? Eso es exactamente cómo el código espagueti (donde se tiene una maraña de programas) se crea - incluso si es más rápido de producir, no querrías acabar teniendo que mantener todo este descontrol.
La reutilización de los servicios debe ser institucionalizada y gobernada por los respectivos equipos funcionales o deberían ser un movimiento popular open-source dentro de la empresa y administrado por un tutor de servicio en cada uno de los equipos funcionales?
Asegúrese de consultar el post original de Martin Fowler y compartir sus experiencias.
Basado en Tutor de Serviço
