SOA para principiantes
La capacidad de poder responder rápidamente ante los constantes cambios en las reglas y optimización dentro de los procesos de negocio, forma parte de un factor fundamental dentro de la competitividad y crecimiento de las empresas.
Las arquitecturas SOA (Service Oriented Architecture), buscan separar las actividades de los procesos, en servicios independientes y con gobernabilidad, lo que permite una integración de distintas tecnologías en diferentes plataformas, fácilmente.
¿Que ganamos?
Al implementar una arquitectura SOA, ganamos gobernabilidad de las actividades de los procesos, es decir cada tarea del proceso (Si el análisis nos indica que esta es la solución) se expone como un servicio, lo cual indica que al cambiar la tecnología de alguno de ellos, no afecta a los demás ya que para el intercambio de información se hacen el uso de estándares, aun incluso si el proceso global cambia, las tareas se siguen comportando de la misma forma y solo se adaptan si el proceso lo requiere.
Imaginemos que en nuestro proceso tenemos una funcionalidad de alarmas la cual envió correos y mensajes de texto, esta funcionalidad esta a tres distintos sistemas de la empresa, ¿que pasaria si nuestro proveedor de correos cambia?, pues tendríamos que recompilar las tres aplicaciones añadiendo en cada una los cambios y las adecuaciones.
Si nuestros sistemas estuvieran en una arquitectura SOA, veríamos a la funcionalidad de alarmas, como un servicio, y todas nuestras aplicaciones se conectarían al mismo servicio, y un cambio en el proveedor de correos o de mensajes solo implicaría un cambio en el servicio.
Bueno espero que les allá sembrado la duda de las arquitecturas SOA, seguir publicando referente a SOA y su integración con BPM.
Saludos.
- abrahamstalin's blog
- Inicie sesión o regístrese para enviar comentarios
transacciones distribuidas
La promesa de SOA se va al traste cuando intervienen las transacciones distribuidas, ya que la complejidad se incrementa bastante.
Ejemplo:
Una transacción que requiere invocar 3 servicios independientes todos bonitos hechos bajo SOA. La transacción solamente se puede considerar exitosa si las 3 llamadas son exitosas, y cada una depende de la anterior.
Entonces:
1. Llamas el primer servicio
2. Si esa primera invocación fue exitosa, llamas el segundo servicio (seguramente pasando valores obtenidos del primero). Si hubo error en la primera, pues contestas error y terminas.
3. Si la segunda invocación fue exitosa, llamas el tercer servicio, pasando valores obtenidos del segundo (y tal vez del primero). Si hubo error en la segunda, qué? Tal vez hay que llamar un método de cancelación del primer servicio... y si no lo ofrece? y si no contesta?
4. Si la tercera invocación es exitosa, haces tus operaciones de cierre y contestas OK. Si no fue exitosa... qué? hay que cancelar primero y segundo... si después de la tercera invocación tienes problemas internos procesando y guardando resultados antes de poder contestar... hay que cancelar en los 3 servicios.
Comparado con una transacción en base de datos donde simplemente das rollback en cualquier punto, está bastante complicado y hay demasiados puntos de falla. Pero eso no te lo platican cuando te venden SOA.
Re: SOA
Fuente: IMM031 u1153936: Service-Oriented Architecture.
ezamudio, el problema que
ezamudio, el problema que comentas de las transacciones distribuidas no son ocasionadas por SOA, si no por la naturaleza en sí de ellas. Quita SOA y ponte un cluster de bases de datos, donde un update tiene reflejarse en todas ellas, tienes el mismo problema, ¿que pasa si el quinto server no recibió la información, todos los demas la eliminan? por supuesto hay diferentes soluciones dependiendo la situación, pero eso es harina de otro costal.
En lo que si vamos a estar de acuerdo es que implementar SOA tal y como se espera, es mas complejo de lo que supone.
Transacciones distribuidas no tienen problemas.
Los problemas son de los "programadores" por creerse arquitectos.
Nopalin
Cuando manejas puras bases de datos diferentes, puedes apoyarte en JTA. Y bueno, supongo que JTA también lo puedes usar para transacciones distribuidas usando web services en vez de bases de datos, *pero* cada servicio debe tener un método para poder aplicar el reverso.