Gente,
En esta ocacion les dejo un dato de una expo que pinta interesante.
Es la Ekoparty. La entrada es paga, pero si les interesa y pueden hacer que alguna empresa se los banque, no hay problema.
Tienen trainings muy buenos, asi que chusmeenlos un poco.
Saludos.
jueves, 4 de septiembre de 2008
domingo, 3 de agosto de 2008
Patrones SOA y de Workflow
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
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
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.
jueves, 31 de julio de 2008
Analisis en SOA
Hace tiempo que vengo estudiando como es el mejor camino para implementar un analisis SOA.
Aca escribo un poco de lo que estuve viendo.
En fin, parece que para el analisis y la entrega de servicios en una metodologia SOA existen dos caminos posibles. TOP-DOWN y BOTTOM-UP. Pueden verlos aqui
Cuando lo lei, asocie la forma de delivery BOTTOM-UP a la forma de analisis orientada a la necesidad actual cuando los requerimientos provienen de sistemas legacy y los procesos de negocio no estan definidos; y la TOP-DOWN, cuando se parte del analisis basado en entidades de negocio, procesos de negocio y demas descomposiciones, que se pueden ver aqui
Igual, se debe tener en claro que todo el proceso tendera tarde o temprano a ser un TOP-DOWN, de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT este alineado al negocio.
Otra cosa que dice MSOAM es que el analista funcional debe trabajar en conjunto con el tecnico (aqui).
Con los analistas tecnicos deben trabajar si o si, ya que estos son los que conocen las restricciones tecnologicas, los patrones de diseño y podran modelar los servicios de manera acorde a los estandares empresariales. Un analista funcional no podra modelar las entradas, salidas y capacidades de un servicio por si mismo; especialmente hoy en dia, que la vision orientada a servicios es escaza.
Cuando se habla de analistas funcionales son analistas cross al negocio. Eso quiere decir que el analista no debe conocer UNA aplicacion o UN proceso de negocio, sino meterse en todos los procesos y conocer un poco de tooooodo IT en la empresa.
Es por eso que el analista SOA debe trabajar (o consultar antes de definir, al menos) con la gente que modela y documenta los procesos de negocio.
El ciclo de vida de servicios debe estar bien definido y se deben formalizar los pasos para la creacion, eliminacion o modificacion de un servicio, como tambien los pedidos para su consumicion. Sin esto, no se podran generar politicas adecuadas para el repositorio...
Para un correcto analisis, se debe poseer un repositorio de entidades de negocio y de servicios Y con un proceso de GOVERNANCE bien definido es fundamental.
La existencia del repositorio y la definicion de la metadata de cada servicio sera lo que permita modelarlos y centralizar la informacion de servicios en toda la empresa.
No se habla unicamente de UDDI, ya que este estandar es limitado. Se habla de un repositorio a nivel de analisis y diseño, que permita automatizar el proceso de modelado y descubrimiento de servicios, como tambien asi su aprobacion por parte de la SOA BOARD (que sera el sector/comision/grupo de sectore que tendran el governance de los servicios en la empresa y definiran los estandares).
El proceso de Governance debe estar bien definido, y los estandares y modelado de negocio tambien. Aqui hay un articulo sobre la importancia del governance
La metodologia de analisis debe ser iterativa!!!! no se debe querer relevar tooooooda la informacion de tooooooodos los procesos para comenzar a definir servicios que sean reutilizables.
Los servicios son altamente modificables y apuntan a la reutilizacion, por lo que se debe analizar por partes a los procesos de negocio/procesos de la empresa para poder entregar los primeros servicios. Luego, estos se iran modificando con la aparicion de nuevos requerimientos, para eso se definio un repositorio y un ciclo de vida de servicios.
Con los links y la metodologia en si, hay bastante para profundizar. SOA Es una metodologia que sigue cambiando y que cada consultor hace, hoy en dia, como mas le parece.
Es importante tener una metodologia de analisis que se ajuste a las necesidades de la empresa, dependiendo su grado de madurez (me gusta la piramide de ese link, es muy clara). El grado 3 de madurez, es el mas dificil de lograr, el resto sale con fritas.
Saludos.
Aca escribo un poco de lo que estuve viendo.
- La metodologia de IBM SOMA
- La de Thomas Erl (la mejorcita) MSOAM y otro link de lo mismo
- Las de ciclo de vida de los servicios de BEA (que no me dejo mucho) y
- Las recomendadas por las SOA practitioners guide
En fin, parece que para el analisis y la entrega de servicios en una metodologia SOA existen dos caminos posibles. TOP-DOWN y BOTTOM-UP. Pueden verlos aqui
Cuando lo lei, asocie la forma de delivery BOTTOM-UP a la forma de analisis orientada a la necesidad actual cuando los requerimientos provienen de sistemas legacy y los procesos de negocio no estan definidos; y la TOP-DOWN, cuando se parte del analisis basado en entidades de negocio, procesos de negocio y demas descomposiciones, que se pueden ver aqui
Igual, se debe tener en claro que todo el proceso tendera tarde o temprano a ser un TOP-DOWN, de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT este alineado al negocio.
Otra cosa que dice MSOAM es que el analista funcional debe trabajar en conjunto con el tecnico (aqui).
Con los analistas tecnicos deben trabajar si o si, ya que estos son los que conocen las restricciones tecnologicas, los patrones de diseño y podran modelar los servicios de manera acorde a los estandares empresariales. Un analista funcional no podra modelar las entradas, salidas y capacidades de un servicio por si mismo; especialmente hoy en dia, que la vision orientada a servicios es escaza.
Cuando se habla de analistas funcionales son analistas cross al negocio. Eso quiere decir que el analista no debe conocer UNA aplicacion o UN proceso de negocio, sino meterse en todos los procesos y conocer un poco de tooooodo IT en la empresa.
Es por eso que el analista SOA debe trabajar (o consultar antes de definir, al menos) con la gente que modela y documenta los procesos de negocio.
El ciclo de vida de servicios debe estar bien definido y se deben formalizar los pasos para la creacion, eliminacion o modificacion de un servicio, como tambien los pedidos para su consumicion. Sin esto, no se podran generar politicas adecuadas para el repositorio...
Para un correcto analisis, se debe poseer un repositorio de entidades de negocio y de servicios Y con un proceso de GOVERNANCE bien definido es fundamental.
La existencia del repositorio y la definicion de la metadata de cada servicio sera lo que permita modelarlos y centralizar la informacion de servicios en toda la empresa.
No se habla unicamente de UDDI, ya que este estandar es limitado. Se habla de un repositorio a nivel de analisis y diseño, que permita automatizar el proceso de modelado y descubrimiento de servicios, como tambien asi su aprobacion por parte de la SOA BOARD (que sera el sector/comision/grupo de sectore que tendran el governance de los servicios en la empresa y definiran los estandares).
El proceso de Governance debe estar bien definido, y los estandares y modelado de negocio tambien. Aqui hay un articulo sobre la importancia del governance
La metodologia de analisis debe ser iterativa!!!! no se debe querer relevar tooooooda la informacion de tooooooodos los procesos para comenzar a definir servicios que sean reutilizables.
Los servicios son altamente modificables y apuntan a la reutilizacion, por lo que se debe analizar por partes a los procesos de negocio/procesos de la empresa para poder entregar los primeros servicios. Luego, estos se iran modificando con la aparicion de nuevos requerimientos, para eso se definio un repositorio y un ciclo de vida de servicios.
Con los links y la metodologia en si, hay bastante para profundizar. SOA Es una metodologia que sigue cambiando y que cada consultor hace, hoy en dia, como mas le parece.
Es importante tener una metodologia de analisis que se ajuste a las necesidades de la empresa, dependiendo su grado de madurez (me gusta la piramide de ese link, es muy clara). El grado 3 de madurez, es el mas dificil de lograr, el resto sale con fritas.
Saludos.
Oracle BEA, como sera la fusion
En este link que pongo a continuacion esta el roadmap que va a tomar la gente de Oracle.
http://www.espaciosoa.net/2008/07/02/conversion-de-productos-de-bea-y-oracle/
Por suerte, van a quedarse con JRockit como VM de los aplicattion server fusionados, lejos, lo mejor de BEA
Van a seguir teniendo la BAM de oracle, por lo que solo se podra implementar sobre un server con windows instalado. Uno de sus tantos requisitos es ese.
Saludos.
http://www.espaciosoa.net/2008/07/02/conversion-de-productos-de-bea-y-oracle/
Por suerte, van a quedarse con JRockit como VM de los aplicattion server fusionados, lejos, lo mejor de BEA
Van a seguir teniendo la BAM de oracle, por lo que solo se podra implementar sobre un server con windows instalado. Uno de sus tantos requisitos es ese.
Saludos.
Suscribirse a:
Entradas (Atom)
