Santiago Blanco (ver su blog que es muy bueno) me paso el siguiente link de worklow patterns... MUY BUENO!!! Indican los patrones tipicos de control de flujo, manejo de datos, de recursos y de excepciones.
Encima, marcan que productos soportan cada patron!!!!
Link a la pagina
Patrones de SOA y buenas practicas... de quien otro si no es Thomas Erl: http://www.soapatterns.org/
Que lo disfruten!!
Saludos
domingo, 3 de agosto de 2008
POEM, una alternativa al BPMN
POEM es una metodologia abierta para el modelado de procesos en la empresa. Se puede ver en el siguiente link
y.....Un poster de POEM es todo arquitecto de empresa deberia tener en una pared, aunque no lo use!!!! :D
Porque? porque queda bien :P
NAH! realmente es util y resume la metodologia POEM para modelar los procesos de la empresa. link al poster
Saludos.
y.....Un poster de POEM es todo arquitecto de empresa deberia tener en una pared, aunque no lo use!!!! :D
Porque? porque queda bien :P
NAH! realmente es util y resume la metodologia POEM para modelar los procesos de la empresa. link al poster
Saludos.
SOA: Arquitectura de referencia
Existen varias metodologias para llegar a una arquitectura SOA.
Este link, que se lo debo a Pablo Albornoz (gracias Pablo!!!) nos sirve de checklist, y nos indica tooooodo lo que nos puede faltar para tener una arquitectura SOA completita y bien definida. Link
Cuando querramos ver que pasos seguir y que nos falta hacer, podemos seguir esta referencia.
Saludos!
Este link, que se lo debo a Pablo Albornoz (gracias Pablo!!!) nos sirve de checklist, y nos indica tooooodo lo que nos puede faltar para tener una arquitectura SOA completita y bien definida. Link
Cuando querramos ver que pasos seguir y que nos falta hacer, podemos seguir esta referencia.
Saludos!
¿Estandares? WS-*
Si hay algo que se respeta menos que un semaforo en rojo, en la provincia de buenos aires de noche, son los estandares de Servicios WS-*
Thomas Erl (un Groso) los explica un poquito en su pagina soa specifications
y Tambien en http://www.ws-standards.com/
El hecho es que cada proveedor hace con sus productos lo que quiere.
No todos los frameworks
no todos los productos
no todos los proveedores
orientados al desarrollo y soporte de WS soportan los estandares de WS.
Microsoft desarrollo sus estandares de Transacciones, seguridad y adressing como mas le parecio. Extendio el estandard y hace pleno uso de el, haciendo casi imposible confiar en una integracion completa con otros productos (incluso de BEA y de IBM con los que comparte mas estandares definidos en OASIS).
WS-Addressing.... esta ampliamente difundido, pero no por todos los frameworks, asi que antes que esperar que un framework o un producto resuelva el pooling de espera de una respuesta de servicio por el id del mensaje, hay que hacerle un par de pruebas de integracion con otros productos similares y puede ser preferible generar un servicio con callback a la vieja usanza o asumir el costo de poolear a la espera de respuesta.
WS-Security.... la forma "estandar" de microsoft es "estandar" consigo misma. Aun asi, es uno ampliamente soportado.
WS-ReliableMessaging... nada en contra, nada a favor. Todavia no tuve la oportunidad de usarlo , ni que me resulte util.
WS-Transaction... JAJAJAJAJAJAJAJAJAJA el sueño del pibe. Todavia sigo sacando canas verdes con la compensacion de servicios, con transacciones distribuidas y demas. Esto aun esta verde. Igual, la idea es buena, pero.... en las AT, aun tienen faces de 2PC que en algunos casos pueden resultar en lockings de recursos. Estos son unos buenos links para ver. WS-T Parte 1, Parte 2 y Parte 3
Bueno, esto es un poco con lo que me fui encontrando. Los WS-* no son la solucion a nuestros problemas de arquitectura y diseño aun, porque no se pueden (aun) realizar una integracion confiable.
En una arquitectura empresarial, se debe ir a lo ultimo seguro y estable, sin dejar de lado las nuevas tendencias que quedaran para analizar.
Saludos.
Thomas Erl (un Groso) los explica un poquito en su pagina soa specifications
y Tambien en http://www.ws-standards.com/
El hecho es que cada proveedor hace con sus productos lo que quiere.
No todos los frameworks
no todos los productos
no todos los proveedores
orientados al desarrollo y soporte de WS soportan los estandares de WS.
Microsoft desarrollo sus estandares de Transacciones, seguridad y adressing como mas le parecio. Extendio el estandard y hace pleno uso de el, haciendo casi imposible confiar en una integracion completa con otros productos (incluso de BEA y de IBM con los que comparte mas estandares definidos en OASIS).
WS-Addressing.... esta ampliamente difundido, pero no por todos los frameworks, asi que antes que esperar que un framework o un producto resuelva el pooling de espera de una respuesta de servicio por el id del mensaje, hay que hacerle un par de pruebas de integracion con otros productos similares y puede ser preferible generar un servicio con callback a la vieja usanza o asumir el costo de poolear a la espera de respuesta.
WS-Security.... la forma "estandar" de microsoft es "estandar" consigo misma. Aun asi, es uno ampliamente soportado.
WS-ReliableMessaging... nada en contra, nada a favor. Todavia no tuve la oportunidad de usarlo , ni que me resulte util.
WS-Transaction... JAJAJAJAJAJAJAJAJAJA el sueño del pibe. Todavia sigo sacando canas verdes con la compensacion de servicios, con transacciones distribuidas y demas. Esto aun esta verde. Igual, la idea es buena, pero.... en las AT, aun tienen faces de 2PC que en algunos casos pueden resultar en lockings de recursos. Estos son unos buenos links para ver. WS-T Parte 1, Parte 2 y Parte 3
Bueno, esto es un poco con lo que me fui encontrando. Los WS-* no son la solucion a nuestros problemas de arquitectura y diseño aun, porque no se pueden (aun) realizar una integracion confiable.
En una arquitectura empresarial, se debe ir a lo ultimo seguro y estable, sin dejar de lado las nuevas tendencias que quedaran para analizar.
Saludos.
Suscribirse a:
Entradas (Atom)
