Mostrando las entradas con la etiqueta SOA. Mostrar todas las entradas
Mostrando las entradas con la etiqueta SOA. Mostrar todas las entradas
martes, marzo 15, 2011
Tip para el SoapUI
Hay casos en que desde el SoapUI no se puede importar wsdls que están hosteados en un sitio con autenticación integrada. Se desconoce el motivo del error. Pero de todas formas se puede importar el wsdl bajándolo como archivo y luego importar el archivo utilizando la opción Browse de Projects->"New SoapUI Project" o "Proyecto Ya creado"->Add WSDL
martes, noviembre 03, 2009
SOA anti-patterns
Como en diseño de aplicaciones multicapas, web, cliente-servidor u otras existen patrones que describen problemas comunes y sus soluciones estandarizadas, en el caso de SOA no es la excepción. En este post no vamos a describir los patrones más comunes, pues son muchos y son de referencia para arquitectos y desarrolladores que trabajen en el diseño de servicios SOA, en el sitio de “SOA patterns”, http://www.soapatterns.org/ hay publicado muchos patrones y constantemente se agregan nuevos.
La intención es describir algunos de los anti patrones SOA más comunes con el fin de indicar como no se debe diseñar una solución SOA.
Interfaces CRUD
CRUD en la sigla en inglés que representa las operaciones de creación, lectura, actualización y borrado. Es muy común utilizar estas operaciones en relación a las bases de datos, pero en el caso de un sistema orientado a servicios especificar las operaciones de los servicios como CRUD es una mala práctica.
Por ejemplo en un servicio de manejo de ordenes diseñar en servicio en base a CRUD implica tener operaciones del este tipo
FindOrderByIDResponse FindOrderByID(FindOrderByIDRequest request);
CreateOrderResponse CreateOrder(CreateOrderRequest request);
UpdateOrderResponse UpdateOrderByID(FindOrderByIDRequest request);
DeleteOrderResponse DeleteOrder(DeleteOrderRequest request);
Si en los casos de uso se necesita crear, actualizar y borrar ordenes esta especificación de servicios es válida, pero si la creación de una orden implica varias operaciones previas (por ej verificar la disponibilidad del producto, verificar el estado de crédito del cliente y crear la orden), la operación CreateOrder debe invocar internamente todas las operaciones necesarias para crearlo pues en caso de exponer solo la creación de la orden el consumidor debe hacer las operaciones previas. Este diseño violaría el TNet 3 pues no estaríamos compartiendo solo contratos.
En resumen lo incorrecto no es el uso de CRUD para la especificación de un servicio sino un mal diseño.
Interfaces Chatty
Este anti patrón se refiere a cuando se diseña un sistema orientado a servicios con operaciones que implican un alto nivel de granularidad. En este tipo de interfaces el consumidor es el encargado de llamar a las diferentes operaciones siguientes una lógica específica para que juntos hagan una determinada acción de negocio. Lo correcto es que todas las operaciones para hacer una determina acción de negocio se ejecuten internamente en el servicio.
Por ejemplos la siguientes operaciones se basan en un diseño que aplica este anti patrón
bool ChekGoodAvailability(Ordr order);
bool CheckCreditStatus(Order order);
bool PlaceOrder(Order order);
Estos dos anti patrones están asociados pues un mal diseño de una interfaz CRUD se convierte en una interfaz chatty.
En conclusión el formato de los servicios expuestos depende fundamentalmente de la especificación de casos de uso que estos deben implementar. Por lo tanto en ciertos casos se van a requerir operaciones tipo CRUD pero en muchas otras no. Un adecuando análisis de las especificaciones funcionales seguido de un buen diseño es importante para no terminar utilizando anti patrones.
La intención es describir algunos de los anti patrones SOA más comunes con el fin de indicar como no se debe diseñar una solución SOA.
Interfaces CRUD
CRUD en la sigla en inglés que representa las operaciones de creación, lectura, actualización y borrado. Es muy común utilizar estas operaciones en relación a las bases de datos, pero en el caso de un sistema orientado a servicios especificar las operaciones de los servicios como CRUD es una mala práctica.
Por ejemplo en un servicio de manejo de ordenes diseñar en servicio en base a CRUD implica tener operaciones del este tipo
FindOrderByIDResponse FindOrderByID(FindOrderByIDRequest request);
CreateOrderResponse CreateOrder(CreateOrderRequest request);
UpdateOrderResponse UpdateOrderByID(FindOrderByIDRequest request);
DeleteOrderResponse DeleteOrder(DeleteOrderRequest request);
Si en los casos de uso se necesita crear, actualizar y borrar ordenes esta especificación de servicios es válida, pero si la creación de una orden implica varias operaciones previas (por ej verificar la disponibilidad del producto, verificar el estado de crédito del cliente y crear la orden), la operación CreateOrder debe invocar internamente todas las operaciones necesarias para crearlo pues en caso de exponer solo la creación de la orden el consumidor debe hacer las operaciones previas. Este diseño violaría el TNet 3 pues no estaríamos compartiendo solo contratos.
En resumen lo incorrecto no es el uso de CRUD para la especificación de un servicio sino un mal diseño.
Interfaces Chatty
Este anti patrón se refiere a cuando se diseña un sistema orientado a servicios con operaciones que implican un alto nivel de granularidad. En este tipo de interfaces el consumidor es el encargado de llamar a las diferentes operaciones siguientes una lógica específica para que juntos hagan una determinada acción de negocio. Lo correcto es que todas las operaciones para hacer una determina acción de negocio se ejecuten internamente en el servicio.
Por ejemplos la siguientes operaciones se basan en un diseño que aplica este anti patrón
bool ChekGoodAvailability(Ordr order);
bool CheckCreditStatus(Order order);
bool PlaceOrder(Order order);
Estos dos anti patrones están asociados pues un mal diseño de una interfaz CRUD se convierte en una interfaz chatty.
En conclusión el formato de los servicios expuestos depende fundamentalmente de la especificación de casos de uso que estos deben implementar. Por lo tanto en ciertos casos se van a requerir operaciones tipo CRUD pero en muchas otras no. Un adecuando análisis de las especificaciones funcionales seguido de un buen diseño es importante para no terminar utilizando anti patrones.
domingo, octubre 25, 2009
What SOA is not?
Este post tiene como fin aclarar que no es SOA, con el fin de evitar confusiones y malos entendidos a la hora de emprender un proyecto de implementación SOA.
Dino Esposito [Esposito Dino et at, 2009] indica que hay que tener claro que SOA no es una revolución, un objetivo en sí, una tecnología , ni tampoco una implementación de webservices.
No es una revolución porque hace más de 15 años que existe la infraestructura para integrar aplicaciones (EDI, CORBA, COM, DCOM etc). Lo que generó SOA fue la necesidad de integrar sistemas existente con el fin de implementar procesos de negocios usando software. Por lo tanto invocar objetos remotos, enviar mensajes ya existía antes que SOA, por lo tanto no es una revolución sino una evolución.
Tampoco es una tecnología en sí, pues SOA es totalmente independiente de proveedores y productos. Unos de los mayores beneficios de SOA es que se aplican sus principios a una organización en particular. No se debe pensar una implementación SOA en base a productos del mercado, se debe pensar en SOA tomándose en tiempo necesario para entender sus principios y aprender cómo aplicarlos en toda su infraestructura.
Decir que SOA son webservices es un error común pues a la hora de implementar los webservices son los más utilizados como mecanismo de comunicación entre los sistemas que forman la infraestructura SOA. Por lo tanto no todas las soluciones SOA utilizando webservices y no todos sistema basado en webservices es una implementación de SOA.
Como venimos diciendo ante de pensar como implementar SOA se debe tener bien definidos los procesos de negocio que suponemos que se van a mejorar mediante la implementación de SOA. Por lo tanto el objetivo no es implementar SOA sino mejorar uno o varios procesos de negocio determinados. Luego de analizar los procesos involucrados, la infraestructura, aplicaciones, tiempo y presupuesto disponible recién en ese momento estaremos en condiciones de decir si SOA es aplicable o no.
Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.
Dino Esposito [Esposito Dino et at, 2009] indica que hay que tener claro que SOA no es una revolución, un objetivo en sí, una tecnología , ni tampoco una implementación de webservices.
No es una revolución porque hace más de 15 años que existe la infraestructura para integrar aplicaciones (EDI, CORBA, COM, DCOM etc). Lo que generó SOA fue la necesidad de integrar sistemas existente con el fin de implementar procesos de negocios usando software. Por lo tanto invocar objetos remotos, enviar mensajes ya existía antes que SOA, por lo tanto no es una revolución sino una evolución.
Tampoco es una tecnología en sí, pues SOA es totalmente independiente de proveedores y productos. Unos de los mayores beneficios de SOA es que se aplican sus principios a una organización en particular. No se debe pensar una implementación SOA en base a productos del mercado, se debe pensar en SOA tomándose en tiempo necesario para entender sus principios y aprender cómo aplicarlos en toda su infraestructura.
Decir que SOA son webservices es un error común pues a la hora de implementar los webservices son los más utilizados como mecanismo de comunicación entre los sistemas que forman la infraestructura SOA. Por lo tanto no todas las soluciones SOA utilizando webservices y no todos sistema basado en webservices es una implementación de SOA.
Como venimos diciendo ante de pensar como implementar SOA se debe tener bien definidos los procesos de negocio que suponemos que se van a mejorar mediante la implementación de SOA. Por lo tanto el objetivo no es implementar SOA sino mejorar uno o varios procesos de negocio determinados. Luego de analizar los procesos involucrados, la infraestructura, aplicaciones, tiempo y presupuesto disponible recién en ese momento estaremos en condiciones de decir si SOA es aplicable o no.
Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.
viernes, octubre 16, 2009
Reflections about SOA implementation in the enterprise.
El tema de SOA no es nada nuevo, pero a la hora de querer conocer sobre este interesante tema el problema no fue encontrar información, sino todo lo contrario, clasificar y sacar conceptos útiles de las gran cantidad de información al respecto.
A mi criterio el tema de SOA fue un gran boom hace 6 o 7 años y luego fue madurando para ser un paradigma aplicable con exito en empresas donde la madures de sus procesos justifique la gran inversión que requiere implementar SOA. No solo es cuestión de soft y hard, sino también de un cambio cultural muy importante en la compañía. Es común que cada área de negocio tenga su propia genencia que sub procesos independientes y prioridades diferentes. por los general es obvio que todas está alineadas a un objetivo de negocio común, pues sino estraríamos en otros problema que es más un análisis de administradores de empresas y consultores asociados.
Pero de todas formas esta diferentes prioridades hace que a larga cada área sea como silos aislados en donde emprenden la contrucción de aplicaciones para resolver determinadas área de negocio, sin pensar (o poco) en lo que implementa las otas áreas.
Como consecuencia tenemos casos de duplicación de funcionalidad, repostorios con datos con entidades redundantes (por ej varias tablas de clientes o de proveedores).
La estandarización de esto requiere de un área que tenga una visión transversal a todas las áreas para poder alinearlos, definir estándares de integración, desarrollo , deployment etc con el fin de integrar las diferentes áreas de negocio. Esta área deberia estar formado por especialistas en las diferenes ramas del desarrollo y arquitectos empresariales.
Volviendo al tema de SOA, una vez que tenemos los procesos, podemos pensar en la implementación en sistemas software (primero los procesos , despues el software).
Ahora, para los más ansiosos paso a describir un resumen (o recordatorio según en caso) de los que es SOA desde el punto de vista ténico.
Arquitectura orientada a servicios
Servicios
Los servicios son sistemas autónomos, que poseen una especificación definida que pueden ser accedidos en forma remota desde otras aplicaciones de la compañía.
Desde el punto de punto de vista del consumidor del servicio no interesa como está implementado sino cual es el mensaje de entrada a recibir y cuál es el formato de la salida, de esta forma se pueden crear sistemas altamente escalables, distribuidos y reutilizables.
Para que los servicios puedan forma parte de una arquitectura orientada a servicios deben tener al menos las siguientes características
• Reusables: Proveen servicios de negocio que pueden ser utilizados por varias aplicaciones.
• Proporcionar un contrato formal: Indica que establece una interface formal para los mensajes de entrada y de salida. En la práctica se debe los mensajes tienen formato XML, por lo tanto se deben exponer esquemas XML (XSD) y no clases.
• Deben tener bajo acoplamiento
Significa que un cambio en la implementación de alguno de ellos debe afectar lo mínimo posible a los demás.
• Deben permitir la composición entre ellos.
Esta funcionalidad permite componer el resultado de la ejecución de varios servicios para ofrecer un solo resultado. En la práctica esto se podría implementar con un Enterprise Service Bus.
• Deben ser autónomos.
Indica que su implementación y administración se debe poder hacer independientemente de los demás, eta característica está muy asociada con la de bajo acomplamiento.
• No deben tener estado.
Indica que el servicio recibe el mensaje de entrada, lo procesa y luego responde el resultado sin mantener estado alguna entre ejecuciones.
• Deben poder ser descubiertos.
El descubrimiento de lo servicio es un factor muy importante para poder administrarlos, de esta forma el sistema consumidor puede conocer su especificación en un forma simple. Este proceso se implementa con un registro de servicios y una herramienta de UDDI.
TNets de SOA
En la práctica se definen 4 reglas que debe cumplir un sistema basado en SOA , estas reglas se las denomina TNets de SOA [Esposito Dino et at, 2009]
TNet N° 1; Las fronteras deben ser explícitas
La interacción con los servicios se debe hacer mediante interfaces públicas. Los métodos en la interface representan los puntos de entrada en el servicio y los datos en la firma de los métodos representan los mensajes de entrada y salida del servicio.
Las interfaces deben ser lo más simples posibles y no deben exponer datos internos a los servicios, la implementación interna de los mismos debe ser transparente para el consumidor.
TNet N° 2 ; Los servicios deben ser autónomos
Para el caso de los servicio esta regla indica que cada servicio debe poder ser implementado, administrado y versionado en forma independiente del sistema en el cual es implementado y consumido. Esto no indica que los servicio deben estar totalmente aislados del resto del sistema, lo que indica que debe tener el menor acoplamiento posible. Por lo tanto si necesita comunicarse con otros servicios lo debe hacer mediante contratos y políticas.
TNet N° 3: Usar contratos , no clases
Unos de los objetivos de SOA es la interoperabilidad, o sea todo servicio debe tener una inteface pública basadas en estándares de la industria e independiente de la plataforma. En el caso de un sistema basado en componentes las interfaces entre ellos comparten clases, para el caso de SOA esto no es válido porque el sistema sería dependiente de la plataforma.
Estas interfaces públicas se basan en contratos de servicios basado en mensajes.
Los mensajes compartidos son documentos XML y su contrato está especificado mediante esquemas xml (XSD).
Las diferentes implementaciones de SOA convierten esos mensajes XML en clases específica de una determinada plataforma y convierten las clases de respuesta en sus correspondientes mensajes XML como respuesta al consumidor del servicio.
TNet N° 4: La compatibilidad es basada en políticas
Que un servicio sea accesible y que lo pueda llamar no es una buena razón para el consumidor lo invoque. Los servicios y contratos son necesarios pero no suficientes, estos indican que es lo que se envía al servicio y que se espera de él.
Este TNet se refiere a la semántica de compatibilidad entre servicios, que un servicios haga exactamente lo que el consumidor espera. Esta semática se expone vía un acceso público y una política estándar. El estándar WS-Policy [W3C WS-Policy, 2007] específica como se debe implementar este TNet
Gobierno SOA
De la definición de SOA se desprende que para poder hacer una correcta implementación y mejorar el ROI es necesario un gobierno SOA, esto implica el proceso para poder administrar los servicios, publicarlos, controlar las versiones etc. Este factor es imprescindible porque en caso contrario no se puede aprovechar las ventajas que provee este estilo de arquitectura.
Según Bobby Wolf , Consultor WebSphere J2EE de IBM [Woolf Bobby, 2007], un proceso de gobierno SOA debe manejar al menos los siguientes aspectos.
• Definición del servicio
Involucra la técncias y herramientas que permiten identificar, describir la funcionalidad y comportamiento de un determinado servicio
• Ciclo de vida del servicio
Como todo desarrollo software los servicios deben respetar un ciclo de vida de desarrollo, para el caso particular de los servicios estos pueden tener los siguiente estados.
1. Planeado.
Cuando un nuevo servicio está siendo diseñado, pero aún no implementado
2. En prueba.
El servicio está implementado en un ambiente de prueba para que pueda ser probado por el grupo correspondiente.
3. Activo
En este estado el servicio está disponible para ser consumido y por lo tanto se considera un servicio productivo. Esto implica que debe tener alta disponibilidad no se puede dar de baja o modificar sin un adecuado proceso que mitigue el impacto en los consumidores.
4.Obsoleto:
En este estado el servicio aún está activo, pero su funcionalidad es obsoleta y por lo tanto a partir de pasar a este estado no se deben aceptar nuevos consumidores y se debe comunicar que el servicio será reemplazado.
5.Eliminado:
En este estado el servicio ya no está más disponible, muchas veces es inevitable y no siempre se pasa a este estado en forma planificada. Cosa que se debe evitar para evitar el impacto en los consumidores.
• Versionado
Los servicios tienen cierta funcionalidad que satisfacen una especificación funcional específica, por lo tanto el servicio puede cambiar por cambios funcionales, por errores detectados u otro motivo. Esta situación inevitable en todo software requrie ser adminstrado en forma correcta para evitar perjudicar a los consumidores. Lo que se debe hacer es versionar los servicios manteniendo las versiones antiguas disponibles hasta que por algún motivo se se consideren obsoletas.
Para versionar existen varias técnias y cada una tiene sus pro y contras y algunas de ellas son mandatorias cuando se implementan los servicios en determinada tecnología que solo utiliza determianda técnica. Como técnicas podemos mencionar:
- Cambio de nombre del servicio con un sufijo que indique la versión.
- Agregado de parámetros opcionales en la espcificación de la interface.
- Agregado de información de la versión en la cabecera de los mensajes.
- Enrutamiento dinámico por contenido, en donde el sistema envía el mensaje a la versión correspondientes.
• Migración
En muchas situaciones en que el servicio evoluciona de versión el consumir puede seguir usando alguna versión antigua, pero esto no siempre es así y necesariamente el cosumidor debe migrar de versión porque la nueva provee funcionalidad que justifican el esfuerzo , porque la versión actual se queda obsoleta etc. El proveedor del servicio no puede depender de la migración de los consumidores, a los sumo proporciona la mayor información para que estos migren en sus propios tiempos.
• Registros de servicios
Para que los consumidores puedan acceder a los servicios primero debe saber donde están ubicados y como acceder a ellos. Además permite administrar las versiones de los servicios.
Una vez que el consumidor comienza a invocar el servicios depende de él, por lo tanto no alcanza con publicar el servicios sino que debe existir un mecanismo para regitrar las dependencias entre lo servicios y los consumidores incluyendo notificaciones a los consumidores cuando hay cambios en el servicios publicado o cuando va a ser pasado al estado obsoleto.
• Modelos de mensajes de los servicios.
En una invocación de servicios el consumidor y el proveedore debene estar de acuerdo con el formato de los mensajes a intercambiar. Para evitar el caos que searía ponerse de acuerdo entre grupos de trabajo que separados, decenas de servicios y de consumidores se adopta utilizar un modelo de datos canónico.Un modelo de datos canónico es un grupo de formatos de datos que es independientes de cualquier aplicación y compartida por todas ellas. Dentro de los procesos de gobierno SOA debe haber uno que en forma neutral encargado de definir estos formatos de datos comunes.
• Monitoreo
Es un sistema SOA se debe garantizar un determina Nivel de Servicio Acordado (SLA), pues la caída de cualquier de ellos puede afectar el funcionamiento de los consumidores y de servicios asociados si el que falló por parte de una composición de servicios.
El sistema de monitoreo es el encargado de detectar y prevenir problemas antes que ocurran midiendo los recuros de lso servidores donde están implementados los servicios, si los tiempos de respuesta están dentro de los valores predeterminados etc.
• Propiedad del servicios
Cuando una aplicación usa un servicios, ¿quién es el responsable por el servicios?. La definición es ambigüa y se debe determinar en forma clara para evitar malos entendidos. En grandes empresas puede ser un área provea servicios para acceder a información referente a ella,pro lo tanto en ese caso el área de IT de esa área de negocio es la responsable por la diponibilidad y mantenimiento del servicio. En el caso de sistemas empresariales formado por composición de servicios esta responsabilidad se solapa, por lo tanto debe haber una cooperación entre analisistas de negocios, arquitectos empresariales, arquitectos de software, reponsables de tecnología y de áreas de desarrollo para alinear todo lo referente a los servicios al negocio de la empresa.
• Pruebas de los servicios
Como todo sistema software los servicios pasan por un estado de pruebas antes de implementar en un sistema productivo. Estas pruebas deben ser tanto funcionales como técnicas y las debe hacer el área proveedora de los servicios. Los consumidores lo único que debe probar es su propia funcionalidad y la conexión con los servicios consumidos, pues pueden asumir que los servicios publicados funcionan correctamente.
• Seguridad en los servicios
¿Cualquier usuarios puede acceder al servicios? ¿Todos los datos expuestos son públicos?, ¿La información compartida debe transmitirse por canales seguros? ¿Cómo se maneja el sistema de auditaría para evitar invocaciones no autorizadas?. Estas y muchas preguntas relacionadas con la intergradidad de los datos manejados y la disponibilidad de los servicios la maneja el área de seguridad y por lo tanto estos aspectos se deben considerar en la etapa de diseño de los servicios.
Conclusión:
SOA es un importante paradigma que si es bien aplicado puede ayudar en mucho a la integración de las áreas de negocio de la empresa, mejorar la reusabilidad de los desarrollos, tener un leguaje común de modelado etc. Los proveedores suelen poner como latigijo el tema de la mejora del ROI, este es un tema en donde no pude profundizar y no se que tan fácil es calcularlo.
Lo más importante para implementar SOA no es la técnología aplicada, productos y habilidades ténicas, sino procesos bien conformados, integración de las áreas y lo más importantes cambios cultural para pensar en "SOA" de los gerentes de negocios, de IT, analisistas y lideres de proyecto.
Luego de salvado este paso (nada fácil por cierto) pasamos las habilidades de la gente ténica de IT, deben pensar en el árbol pero tambien en el bosque para no plantar un eucalipto en un bosque de pinos, usar patrones de la industria para independizar los servicios de la plataformas del consumidor , diseñar pensando en la reutilización (en la medida de los posible) entre otroas cosas.
Por último, como los procesos de negocio cambian constantemente (como dice el famoso refrán "lo único constante es el cambio"), los sistemas que forman la solución SOA deben ser lo más flexibles posible para poder seguir ese cambio, ese también es una gran desafío.
Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.
[W3C WS-Policy, 2007], Web Services Policy 1.5 – Framework,
http://www.w3.org/TR/ws-policy .
[Woolf Bobby, 2007], “Introduction to SOA governance, Governance: The official IBM definition, and why you need it”,
IBM SOA Governance
A mi criterio el tema de SOA fue un gran boom hace 6 o 7 años y luego fue madurando para ser un paradigma aplicable con exito en empresas donde la madures de sus procesos justifique la gran inversión que requiere implementar SOA. No solo es cuestión de soft y hard, sino también de un cambio cultural muy importante en la compañía. Es común que cada área de negocio tenga su propia genencia que sub procesos independientes y prioridades diferentes. por los general es obvio que todas está alineadas a un objetivo de negocio común, pues sino estraríamos en otros problema que es más un análisis de administradores de empresas y consultores asociados.
Pero de todas formas esta diferentes prioridades hace que a larga cada área sea como silos aislados en donde emprenden la contrucción de aplicaciones para resolver determinadas área de negocio, sin pensar (o poco) en lo que implementa las otas áreas.
Como consecuencia tenemos casos de duplicación de funcionalidad, repostorios con datos con entidades redundantes (por ej varias tablas de clientes o de proveedores).
La estandarización de esto requiere de un área que tenga una visión transversal a todas las áreas para poder alinearlos, definir estándares de integración, desarrollo , deployment etc con el fin de integrar las diferentes áreas de negocio. Esta área deberia estar formado por especialistas en las diferenes ramas del desarrollo y arquitectos empresariales.
Volviendo al tema de SOA, una vez que tenemos los procesos, podemos pensar en la implementación en sistemas software (primero los procesos , despues el software).
Ahora, para los más ansiosos paso a describir un resumen (o recordatorio según en caso) de los que es SOA desde el punto de vista ténico.
Arquitectura orientada a servicios
Servicios
Los servicios son sistemas autónomos, que poseen una especificación definida que pueden ser accedidos en forma remota desde otras aplicaciones de la compañía.
Desde el punto de punto de vista del consumidor del servicio no interesa como está implementado sino cual es el mensaje de entrada a recibir y cuál es el formato de la salida, de esta forma se pueden crear sistemas altamente escalables, distribuidos y reutilizables.
Para que los servicios puedan forma parte de una arquitectura orientada a servicios deben tener al menos las siguientes características
• Reusables: Proveen servicios de negocio que pueden ser utilizados por varias aplicaciones.
• Proporcionar un contrato formal: Indica que establece una interface formal para los mensajes de entrada y de salida. En la práctica se debe los mensajes tienen formato XML, por lo tanto se deben exponer esquemas XML (XSD) y no clases.
• Deben tener bajo acoplamiento
Significa que un cambio en la implementación de alguno de ellos debe afectar lo mínimo posible a los demás.
• Deben permitir la composición entre ellos.
Esta funcionalidad permite componer el resultado de la ejecución de varios servicios para ofrecer un solo resultado. En la práctica esto se podría implementar con un Enterprise Service Bus.
• Deben ser autónomos.
Indica que su implementación y administración se debe poder hacer independientemente de los demás, eta característica está muy asociada con la de bajo acomplamiento.
• No deben tener estado.
Indica que el servicio recibe el mensaje de entrada, lo procesa y luego responde el resultado sin mantener estado alguna entre ejecuciones.
• Deben poder ser descubiertos.
El descubrimiento de lo servicio es un factor muy importante para poder administrarlos, de esta forma el sistema consumidor puede conocer su especificación en un forma simple. Este proceso se implementa con un registro de servicios y una herramienta de UDDI.
TNets de SOA
En la práctica se definen 4 reglas que debe cumplir un sistema basado en SOA , estas reglas se las denomina TNets de SOA [Esposito Dino et at, 2009]
TNet N° 1; Las fronteras deben ser explícitas
La interacción con los servicios se debe hacer mediante interfaces públicas. Los métodos en la interface representan los puntos de entrada en el servicio y los datos en la firma de los métodos representan los mensajes de entrada y salida del servicio.
Las interfaces deben ser lo más simples posibles y no deben exponer datos internos a los servicios, la implementación interna de los mismos debe ser transparente para el consumidor.
TNet N° 2 ; Los servicios deben ser autónomos
Para el caso de los servicio esta regla indica que cada servicio debe poder ser implementado, administrado y versionado en forma independiente del sistema en el cual es implementado y consumido. Esto no indica que los servicio deben estar totalmente aislados del resto del sistema, lo que indica que debe tener el menor acoplamiento posible. Por lo tanto si necesita comunicarse con otros servicios lo debe hacer mediante contratos y políticas.
TNet N° 3: Usar contratos , no clases
Unos de los objetivos de SOA es la interoperabilidad, o sea todo servicio debe tener una inteface pública basadas en estándares de la industria e independiente de la plataforma. En el caso de un sistema basado en componentes las interfaces entre ellos comparten clases, para el caso de SOA esto no es válido porque el sistema sería dependiente de la plataforma.
Estas interfaces públicas se basan en contratos de servicios basado en mensajes.
Los mensajes compartidos son documentos XML y su contrato está especificado mediante esquemas xml (XSD).
Las diferentes implementaciones de SOA convierten esos mensajes XML en clases específica de una determinada plataforma y convierten las clases de respuesta en sus correspondientes mensajes XML como respuesta al consumidor del servicio.
TNet N° 4: La compatibilidad es basada en políticas
Que un servicio sea accesible y que lo pueda llamar no es una buena razón para el consumidor lo invoque. Los servicios y contratos son necesarios pero no suficientes, estos indican que es lo que se envía al servicio y que se espera de él.
Este TNet se refiere a la semántica de compatibilidad entre servicios, que un servicios haga exactamente lo que el consumidor espera. Esta semática se expone vía un acceso público y una política estándar. El estándar WS-Policy [W3C WS-Policy, 2007] específica como se debe implementar este TNet
Gobierno SOA
De la definición de SOA se desprende que para poder hacer una correcta implementación y mejorar el ROI es necesario un gobierno SOA, esto implica el proceso para poder administrar los servicios, publicarlos, controlar las versiones etc. Este factor es imprescindible porque en caso contrario no se puede aprovechar las ventajas que provee este estilo de arquitectura.
Según Bobby Wolf , Consultor WebSphere J2EE de IBM [Woolf Bobby, 2007], un proceso de gobierno SOA debe manejar al menos los siguientes aspectos.
• Definición del servicio
Involucra la técncias y herramientas que permiten identificar, describir la funcionalidad y comportamiento de un determinado servicio
• Ciclo de vida del servicio
Como todo desarrollo software los servicios deben respetar un ciclo de vida de desarrollo, para el caso particular de los servicios estos pueden tener los siguiente estados.
1. Planeado.
Cuando un nuevo servicio está siendo diseñado, pero aún no implementado
2. En prueba.
El servicio está implementado en un ambiente de prueba para que pueda ser probado por el grupo correspondiente.
3. Activo
En este estado el servicio está disponible para ser consumido y por lo tanto se considera un servicio productivo. Esto implica que debe tener alta disponibilidad no se puede dar de baja o modificar sin un adecuado proceso que mitigue el impacto en los consumidores.
4.Obsoleto:
En este estado el servicio aún está activo, pero su funcionalidad es obsoleta y por lo tanto a partir de pasar a este estado no se deben aceptar nuevos consumidores y se debe comunicar que el servicio será reemplazado.
5.Eliminado:
En este estado el servicio ya no está más disponible, muchas veces es inevitable y no siempre se pasa a este estado en forma planificada. Cosa que se debe evitar para evitar el impacto en los consumidores.
• Versionado
Los servicios tienen cierta funcionalidad que satisfacen una especificación funcional específica, por lo tanto el servicio puede cambiar por cambios funcionales, por errores detectados u otro motivo. Esta situación inevitable en todo software requrie ser adminstrado en forma correcta para evitar perjudicar a los consumidores. Lo que se debe hacer es versionar los servicios manteniendo las versiones antiguas disponibles hasta que por algún motivo se se consideren obsoletas.
Para versionar existen varias técnias y cada una tiene sus pro y contras y algunas de ellas son mandatorias cuando se implementan los servicios en determinada tecnología que solo utiliza determianda técnica. Como técnicas podemos mencionar:
- Cambio de nombre del servicio con un sufijo que indique la versión.
- Agregado de parámetros opcionales en la espcificación de la interface.
- Agregado de información de la versión en la cabecera de los mensajes.
- Enrutamiento dinámico por contenido, en donde el sistema envía el mensaje a la versión correspondientes.
• Migración
En muchas situaciones en que el servicio evoluciona de versión el consumir puede seguir usando alguna versión antigua, pero esto no siempre es así y necesariamente el cosumidor debe migrar de versión porque la nueva provee funcionalidad que justifican el esfuerzo , porque la versión actual se queda obsoleta etc. El proveedor del servicio no puede depender de la migración de los consumidores, a los sumo proporciona la mayor información para que estos migren en sus propios tiempos.
• Registros de servicios
Para que los consumidores puedan acceder a los servicios primero debe saber donde están ubicados y como acceder a ellos. Además permite administrar las versiones de los servicios.
Una vez que el consumidor comienza a invocar el servicios depende de él, por lo tanto no alcanza con publicar el servicios sino que debe existir un mecanismo para regitrar las dependencias entre lo servicios y los consumidores incluyendo notificaciones a los consumidores cuando hay cambios en el servicios publicado o cuando va a ser pasado al estado obsoleto.
• Modelos de mensajes de los servicios.
En una invocación de servicios el consumidor y el proveedore debene estar de acuerdo con el formato de los mensajes a intercambiar. Para evitar el caos que searía ponerse de acuerdo entre grupos de trabajo que separados, decenas de servicios y de consumidores se adopta utilizar un modelo de datos canónico.Un modelo de datos canónico es un grupo de formatos de datos que es independientes de cualquier aplicación y compartida por todas ellas. Dentro de los procesos de gobierno SOA debe haber uno que en forma neutral encargado de definir estos formatos de datos comunes.
• Monitoreo
Es un sistema SOA se debe garantizar un determina Nivel de Servicio Acordado (SLA), pues la caída de cualquier de ellos puede afectar el funcionamiento de los consumidores y de servicios asociados si el que falló por parte de una composición de servicios.
El sistema de monitoreo es el encargado de detectar y prevenir problemas antes que ocurran midiendo los recuros de lso servidores donde están implementados los servicios, si los tiempos de respuesta están dentro de los valores predeterminados etc.
• Propiedad del servicios
Cuando una aplicación usa un servicios, ¿quién es el responsable por el servicios?. La definición es ambigüa y se debe determinar en forma clara para evitar malos entendidos. En grandes empresas puede ser un área provea servicios para acceder a información referente a ella,pro lo tanto en ese caso el área de IT de esa área de negocio es la responsable por la diponibilidad y mantenimiento del servicio. En el caso de sistemas empresariales formado por composición de servicios esta responsabilidad se solapa, por lo tanto debe haber una cooperación entre analisistas de negocios, arquitectos empresariales, arquitectos de software, reponsables de tecnología y de áreas de desarrollo para alinear todo lo referente a los servicios al negocio de la empresa.
• Pruebas de los servicios
Como todo sistema software los servicios pasan por un estado de pruebas antes de implementar en un sistema productivo. Estas pruebas deben ser tanto funcionales como técnicas y las debe hacer el área proveedora de los servicios. Los consumidores lo único que debe probar es su propia funcionalidad y la conexión con los servicios consumidos, pues pueden asumir que los servicios publicados funcionan correctamente.
• Seguridad en los servicios
¿Cualquier usuarios puede acceder al servicios? ¿Todos los datos expuestos son públicos?, ¿La información compartida debe transmitirse por canales seguros? ¿Cómo se maneja el sistema de auditaría para evitar invocaciones no autorizadas?. Estas y muchas preguntas relacionadas con la intergradidad de los datos manejados y la disponibilidad de los servicios la maneja el área de seguridad y por lo tanto estos aspectos se deben considerar en la etapa de diseño de los servicios.
Conclusión:
SOA es un importante paradigma que si es bien aplicado puede ayudar en mucho a la integración de las áreas de negocio de la empresa, mejorar la reusabilidad de los desarrollos, tener un leguaje común de modelado etc. Los proveedores suelen poner como latigijo el tema de la mejora del ROI, este es un tema en donde no pude profundizar y no se que tan fácil es calcularlo.
Lo más importante para implementar SOA no es la técnología aplicada, productos y habilidades ténicas, sino procesos bien conformados, integración de las áreas y lo más importantes cambios cultural para pensar en "SOA" de los gerentes de negocios, de IT, analisistas y lideres de proyecto.
Luego de salvado este paso (nada fácil por cierto) pasamos las habilidades de la gente ténica de IT, deben pensar en el árbol pero tambien en el bosque para no plantar un eucalipto en un bosque de pinos, usar patrones de la industria para independizar los servicios de la plataformas del consumidor , diseñar pensando en la reutilización (en la medida de los posible) entre otroas cosas.
Por último, como los procesos de negocio cambian constantemente (como dice el famoso refrán "lo único constante es el cambio"), los sistemas que forman la solución SOA deben ser lo más flexibles posible para poder seguir ese cambio, ese también es una gran desafío.
Referencias
[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.
[W3C WS-Policy, 2007], Web Services Policy 1.5 – Framework,
http://www.w3.org/TR/ws-policy .
[Woolf Bobby, 2007], “Introduction to SOA governance, Governance: The official IBM definition, and why you need it”,
IBM SOA Governance
miércoles, septiembre 02, 2009
Interoperability I
Es cada vez más común que los sistemas empresariales actuales tengan que
interactuar entre ellos, con productos implementados dentro de la compañía o con
sistemas implementado en Internet o dentro de otra compañía u organismos
gubernamentales.
En ese contexto existieron muchos protocolos de comunicaciones, desde el manejo
de la comunicación directamente utilizando el protocolo TCP/IP hasta modernos
sistemas de integración modernos donde se maneja seguridad, estabilidad,
fiabilidad, direccionamiento, enrutamiento etc.
Los primero protocolos de comunicaciones estaban diseñados para interconectar
sistemas que corrieran bajo la misma plataforma o lenguaje, de ellos surgió el DCOM
para plataforma Microsoft, CORBA para Java etc. Para el caso de necesitar
interconectar sistemas heterogéneos se debía recurrir e protocolo de bajo nivel como
TCP/IP o RPC, hoy en día se siguen utilizando para comunicarse con versiones
antiguas de algunas plataformas como SAP o Host.
Debido a esta gran torre de Babel de protocolos varios importantes proveedores de
software y hardware como Microsoft, Sun, IBM, Intel, CA, Entrust, BEA, TIBCO entre
otros coordinaron la creación de un estándar de comunicación para interconectar sus
plataformas.
Con el advenimiento del XML como lenguajes para especificar datos y metadatos se
dio un gran avance en el tema, luego se crearon las especificaciones de los XML
WebServices, en sus versiones más básicas se pudo efectuar interconexiones básicas
entre varias plataformas, como por ej .Net de Microsoft con Java de Sun.
Para poder satisfacer requerimientos de interoperabilidad más exigentes se creó el
Organization for the Advancement of Structured Information Standards OASIS.
OASIS es un consorcio de organismos con el fin de crear estándares abiertos para la
intercomunicación de sistema de información globales.
Con respecto a los webservices se generaron la familia de estándares WS*, que
extienden la especificación original para los webservices otorgando especificaciones
para agregar seguridad, manejo de transacciones, de enrutamiento etc.
En lo que respecta a seguridad se crearon la familia de estándares WS-Security ,
que tiene como objetivos establecer mecanismos de intercambio de mensajes SOAP
en forma segura.
Utilizando protocolo independientes de la plataforma
Una forma de evitar todos los problemas asociados con el marshaling entre
plataformas es utilizar protocolos que sean independientes de ellas.
Luego de un gran esfuerzo de los mayores vendors de software y hardware (Intel,
HP, Sun, IBM, Microsoft, CA etc) se formalizaron una serie de estándares para
manejar un lenguaje común a la hora de interconectar sistemas heterogéneos.
De todos estos estándares lo que nos interesan son los referidos al uso de servicios
web como mecanismo de comunicación.
De este trabajo surgió el WS-Basic Profile 1.1 que consta de un conjunto de
especificaciones para servicios web no propietarias que agrega clarificaciones,
refinamientos, interpretaciones y ampliaciones de especificaciones que promueven la
interoperabilidad.
Este conjunto está formado por las especificaciones de WSDL v1.1, UDDI v2 y SOAP
v1.1 .
Conclusión
La correcta integración de plataformas heterogéneas necesita , valga la redundancia
, la correcta integración de los proveedores que las crean, pues son lo que deben
generar herramientas para poder interconectarse con otros sistemas utilizando un
lenguaje común.
Los estándares de OASIS, en especial los WS* son un importante paso en este
sentido
Referencias
Especificación WS-Securiy, http://docs.oasis-open.org/wss/2004/01/oasis--
200401-wss-soap-message-security-1.0.pdf
World Wide Web Consortium http://www.w3.org/
interactuar entre ellos, con productos implementados dentro de la compañía o con
sistemas implementado en Internet o dentro de otra compañía u organismos
gubernamentales.
En ese contexto existieron muchos protocolos de comunicaciones, desde el manejo
de la comunicación directamente utilizando el protocolo TCP/IP hasta modernos
sistemas de integración modernos donde se maneja seguridad, estabilidad,
fiabilidad, direccionamiento, enrutamiento etc.
Los primero protocolos de comunicaciones estaban diseñados para interconectar
sistemas que corrieran bajo la misma plataforma o lenguaje, de ellos surgió el DCOM
para plataforma Microsoft, CORBA para Java etc. Para el caso de necesitar
interconectar sistemas heterogéneos se debía recurrir e protocolo de bajo nivel como
TCP/IP o RPC, hoy en día se siguen utilizando para comunicarse con versiones
antiguas de algunas plataformas como SAP o Host.
Debido a esta gran torre de Babel de protocolos varios importantes proveedores de
software y hardware como Microsoft, Sun, IBM, Intel, CA, Entrust, BEA, TIBCO entre
otros coordinaron la creación de un estándar de comunicación para interconectar sus
plataformas.
Con el advenimiento del XML como lenguajes para especificar datos y metadatos se
dio un gran avance en el tema, luego se crearon las especificaciones de los XML
WebServices, en sus versiones más básicas se pudo efectuar interconexiones básicas
entre varias plataformas, como por ej .Net de Microsoft con Java de Sun.
Para poder satisfacer requerimientos de interoperabilidad más exigentes se creó el
Organization for the Advancement of Structured Information Standards OASIS.
OASIS es un consorcio de organismos con el fin de crear estándares abiertos para la
intercomunicación de sistema de información globales.
Con respecto a los webservices se generaron la familia de estándares WS*, que
extienden la especificación original para los webservices otorgando especificaciones
para agregar seguridad, manejo de transacciones, de enrutamiento etc.
En lo que respecta a seguridad se crearon la familia de estándares WS-Security ,
que tiene como objetivos establecer mecanismos de intercambio de mensajes SOAP
en forma segura.
Utilizando protocolo independientes de la plataforma
Una forma de evitar todos los problemas asociados con el marshaling entre
plataformas es utilizar protocolos que sean independientes de ellas.
Luego de un gran esfuerzo de los mayores vendors de software y hardware (Intel,
HP, Sun, IBM, Microsoft, CA etc) se formalizaron una serie de estándares para
manejar un lenguaje común a la hora de interconectar sistemas heterogéneos.
De todos estos estándares lo que nos interesan son los referidos al uso de servicios
web como mecanismo de comunicación.
De este trabajo surgió el WS-Basic Profile 1.1 que consta de un conjunto de
especificaciones para servicios web no propietarias que agrega clarificaciones,
refinamientos, interpretaciones y ampliaciones de especificaciones que promueven la
interoperabilidad.
Este conjunto está formado por las especificaciones de WSDL v1.1, UDDI v2 y SOAP
v1.1 .
Conclusión
La correcta integración de plataformas heterogéneas necesita , valga la redundancia
, la correcta integración de los proveedores que las crean, pues son lo que deben
generar herramientas para poder interconectarse con otros sistemas utilizando un
lenguaje común.
Los estándares de OASIS, en especial los WS* son un importante paso en este
sentido
Referencias
Especificación WS-Securiy, http://docs.oasis-open.org/wss/2004/01/oasis--
200401-wss-soap-message-security-1.0.pdf
World Wide Web Consortium http://www.w3.org/
viernes, mayo 29, 2009
¿(Des) Orientación a Servicios?
Un tema analizado en el Microsoft Architecture Day de Buenos Aires es un tema que a mi criterio resulta polémicos, la aplicación de SOA en la práctica.
SOA y su aplicación práctica en grandes empresas, según el disertante SOA no tuvo el exito esperado debido a multiples factores. La misma conclusión expresó Wilson Chelsa de Microsoft pero desde el punto de vista de retorno de inversión, modelos de beneficios etc.
- SOA resultó ser muy complejo de implemementar.
- La industria en general no se alineo a la filosofía de SOA en sus procesos de negocio.
- Requiere gran inversión en el cambio cultural de la organización.
- En sus etapas iniciales no existían servicios laterales de importancia cmo registry, governance etc.
- Las implemetaciones muchas veces no tuvieron los resultados esperados porque fue muy dificil adecuar la cultura del negocio a la folosofía SOA.
- Aún continua la discusión acerca de la granularidad de los servicios, pues si es muy granular se corre el riesgo de no exponer servicios de negocio, poco granular surge que es muy poco reutilizable. En mi experiencia los servicios expuestos muy pocas veces son reutilzables.
- El tema del versionado también está es discusión.
- El desempeño de las implementaciones SOA resultaron ser muy costosas por su grano grueso, muchas capas, gran overhead en sistemas laterales.
El disertante introdujo el concepto de (Des)SOA:
- Reducir la cantidad de capas lógicas y físicas.
- Framework como helpers externos en lugar de contenedores.
Actualmente la nueva arquitectura de Microsoft sobre sistemas distribuídos en clouds Azure, utilizan un modelo con menos capas en donde expone los servicios en forma independiente. Evidentemente es un tema para discutir en profundidad.
Este tema da para un interesante discusión.
SOA y su aplicación práctica en grandes empresas, según el disertante SOA no tuvo el exito esperado debido a multiples factores. La misma conclusión expresó Wilson Chelsa de Microsoft pero desde el punto de vista de retorno de inversión, modelos de beneficios etc.
- SOA resultó ser muy complejo de implemementar.
- La industria en general no se alineo a la filosofía de SOA en sus procesos de negocio.
- Requiere gran inversión en el cambio cultural de la organización.
- En sus etapas iniciales no existían servicios laterales de importancia cmo registry, governance etc.
- Las implemetaciones muchas veces no tuvieron los resultados esperados porque fue muy dificil adecuar la cultura del negocio a la folosofía SOA.
- Aún continua la discusión acerca de la granularidad de los servicios, pues si es muy granular se corre el riesgo de no exponer servicios de negocio, poco granular surge que es muy poco reutilizable. En mi experiencia los servicios expuestos muy pocas veces son reutilzables.
- El tema del versionado también está es discusión.
- El desempeño de las implementaciones SOA resultaron ser muy costosas por su grano grueso, muchas capas, gran overhead en sistemas laterales.
El disertante introdujo el concepto de (Des)SOA:
- Reducir la cantidad de capas lógicas y físicas.
- Framework como helpers externos en lugar de contenedores.
Actualmente la nueva arquitectura de Microsoft sobre sistemas distribuídos en clouds Azure, utilizan un modelo con menos capas en donde expone los servicios en forma independiente. Evidentemente es un tema para discutir en profundidad.
Este tema da para un interesante discusión.
miércoles, mayo 27, 2009
Microsoft Architecture Day
En el día de hoy se hizo la reunión de la Comunidad de Arquitectos de Microsoft. Fue una reunión muy interesante en la que gente de Microsoft y otra empreass presentaron sus experiencias en soluciones de sistemas utilizando las últimas tecnologías de Microsoft,también se presentaron nuevos feactures de tecnologias como Windows 7 , WPF , Siverligh etc. Los asistentes pudieron preserciar presentaciones como:
Andres Vetori y equipo de VMBC Caso de exito de un sistema con .Net 3.5 SP1, WCF, Retina.Net ,Geneva framework, AOP, IVR con Speech Server 2007 entre otra tecnologías. Fue un proyecto contruido utilizando la metodología Agile / Scrum.
Como herramientas de desarrollo utilizaron Team System con integración continua en base a Team Build y deploy con scripts de MSDeploy.
Conclusiones generadas del proyecto:
- Es deseable automatizar las implementaciones en producción
- Adaptar la metodología de desarrollo a las particularidades del proyecto.
- El merge continuo no es siempre justificable.
- Se debe tener un adecuado control de los builds y que objetos contiene cada iteración.
Recomendaciones para un exito de un proyecto de este tipo:
- Virtualización (Hiper-V).
- Equipo con buen señority.
- No reiventar la rueda (patrones, frameworks etc).
- No subestimar el test (automzatizarlo y controlar su correcta ejecución como entregable de la iteración).
- No olvidarse del monitoreo.
- Tener un adecuado procedimiento de control de cambios.
- Mantener una cultura de motivación para hacer las cosas bien hechas.
- Crear una cultura de calidad continua.
Diego Gonzales de lagash presentó una visió de las tendencias en arquitectura de software
- Arquitecturas elásticas
- Base de datos no relacionales.
- (des) orientación a servicios.
- Programación dinámica.
En el tema de arquitectura elástica se vió consideraciones sobre escalabilidad en ambientes Cloud, planificación de arquitectura y modelos de arquitectura.
Diego presentó el concepto de que las arquituras deben ser emergentes y no prescriptivas, es decir se deben diseñar en conjunto con el desarrollo del sistema.
Dentro del tema de escalabilidad horizontal existe el nuevo paradigma de Microsoft que es Azure y el sistema operativo Windows Azure, creado para aplicaciones distribuidas en infraestructura Cloud. La escalabilidad vertical ya está llegando a su límite.
Para scar provecho a este nuevo paradigma es necesario especialización en programación concurrente.
Respecto a la planificación de arquitectura Diego mencionó que en muchas ocaciones conviene que el diseño de la arquitectura sea emergente en vez de prescriptiva, haciendo participar al aquipo de desarrollo ensu definición, esto tiene la ventaja de motivarlos en la creación de la misma y el desarollo del sistema y permite un mejor refinamiento mientra se crea el sistema.
Planteó conceptos de modelado de arquitecturas que pueden ser centralizadas o satelitales.
Un tema que recordó es que por lo general es una desición por defecto que la base de datos a utilizar sea del tipo relacional, esto no siempre es una correcta elección, hay casos donde se requieren datos temporarios, no es tan exigible que sea transaccional en donde la RDBMS no resultan ser lo más apropiado. Ejemplos de uso de este tipo de base de datos son aplicaciones del tipo redes sociales como Facebook.
Las bases de datos no relacionales tienen entre otras las siguientes características:
- key-value db y document db.
- Buen soporte para lenguajes dinámicos.
- Facil cambio en la aplicación.
- Datos a-normalizados. etc.
Productos: SQL Services, Drizzle,Amazon WebServices etc.
Andres Vetori y equipo de VMBC Caso de exito de un sistema con .Net 3.5 SP1, WCF, Retina.Net ,Geneva framework, AOP, IVR con Speech Server 2007 entre otra tecnologías. Fue un proyecto contruido utilizando la metodología Agile / Scrum.
Como herramientas de desarrollo utilizaron Team System con integración continua en base a Team Build y deploy con scripts de MSDeploy.
Conclusiones generadas del proyecto:
- Es deseable automatizar las implementaciones en producción
- Adaptar la metodología de desarrollo a las particularidades del proyecto.
- El merge continuo no es siempre justificable.
- Se debe tener un adecuado control de los builds y que objetos contiene cada iteración.
Recomendaciones para un exito de un proyecto de este tipo:
- Virtualización (Hiper-V).
- Equipo con buen señority.
- No reiventar la rueda (patrones, frameworks etc).
- No subestimar el test (automzatizarlo y controlar su correcta ejecución como entregable de la iteración).
- No olvidarse del monitoreo.
- Tener un adecuado procedimiento de control de cambios.
- Mantener una cultura de motivación para hacer las cosas bien hechas.
- Crear una cultura de calidad continua.
Diego Gonzales de lagash presentó una visió de las tendencias en arquitectura de software
- Arquitecturas elásticas
- Base de datos no relacionales.
- (des) orientación a servicios.
- Programación dinámica.
En el tema de arquitectura elástica se vió consideraciones sobre escalabilidad en ambientes Cloud, planificación de arquitectura y modelos de arquitectura.
Diego presentó el concepto de que las arquituras deben ser emergentes y no prescriptivas, es decir se deben diseñar en conjunto con el desarrollo del sistema.
Dentro del tema de escalabilidad horizontal existe el nuevo paradigma de Microsoft que es Azure y el sistema operativo Windows Azure, creado para aplicaciones distribuidas en infraestructura Cloud. La escalabilidad vertical ya está llegando a su límite.
Para scar provecho a este nuevo paradigma es necesario especialización en programación concurrente.
Respecto a la planificación de arquitectura Diego mencionó que en muchas ocaciones conviene que el diseño de la arquitectura sea emergente en vez de prescriptiva, haciendo participar al aquipo de desarrollo ensu definición, esto tiene la ventaja de motivarlos en la creación de la misma y el desarollo del sistema y permite un mejor refinamiento mientra se crea el sistema.
Planteó conceptos de modelado de arquitecturas que pueden ser centralizadas o satelitales.
Un tema que recordó es que por lo general es una desición por defecto que la base de datos a utilizar sea del tipo relacional, esto no siempre es una correcta elección, hay casos donde se requieren datos temporarios, no es tan exigible que sea transaccional en donde la RDBMS no resultan ser lo más apropiado. Ejemplos de uso de este tipo de base de datos son aplicaciones del tipo redes sociales como Facebook.
Las bases de datos no relacionales tienen entre otras las siguientes características:
- key-value db y document db.
- Buen soporte para lenguajes dinámicos.
- Facil cambio en la aplicación.
- Datos a-normalizados. etc.
Productos: SQL Services, Drizzle,Amazon WebServices etc.
lunes, mayo 25, 2009
Windows Communication Fundation
El WCF fue dado a la luz junto con el framework .Net 3.0 en 2006. En ese momento existían addíns para el Visual Studio 2005 que permitían generar proyectos WCF en forma simple, muchas de esas herramientas eran beta, y se debían usar un poco por linea decomandos y un poco dentro del VS2005,algo muy poco práctico para implementar en una empresa o sector de desarrollo de software.
No voy a describir los problemas que tuve con el desarrollo de proyectos WCF en VS2005 pues el el Visual Studio 2008 incluye todas esas herramientas que se debian agregar a la anterior versión del IDE pudiendo generar proyectos WCF en forma mucho más simple.
Para aquellos que aún no han trabajado con el WCF o necesitan una capacitación de diferentes aspectos que provee esa tecnología les sugiero los siguientes recursos. Los WebCasts están basado enel Visual Studio 2008, por ese motivo es conveniente usar ese entorno.
En ingles
WCF Getting Started
http://msdn.microsoft.com/en-us/library/ms734712.aspx
Microsoft Windows Communication Foundation Step by Step, John Sharp
Disponible para su compra en Microsoft-Press
http://www.microsoft-press.co.uk/scripts/product.asp?ref=811252
O bien en librerias online como http://www.books24x7.com
Pro WCF: Practical Microsoft SOA Implementation
by Chris Peiris, Dennis Mulder et al.
Apress © 2007 (505 pages) Citation
ISBN:9781590597026
Providing coverage of the unified programming model, reliable messaging, security, peer-to-peer programming, and more, this is a complete guide to WCF from the SOA architecture perspective and shows why WCF is important to web service development.
(este aun no lo lei,pero me parece muy interesante)
En Portugues (Brasil)
MSDN Webcast: Melhores práticas no uso do WCF
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032409560&flag=3
Webcast Arquitetura: Arquitetura Orientada a Serviços: WCF Boas práticas (do levantamento, construção e hospedagem
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032415471&flag=3
No voy a describir los problemas que tuve con el desarrollo de proyectos WCF en VS2005 pues el el Visual Studio 2008 incluye todas esas herramientas que se debian agregar a la anterior versión del IDE pudiendo generar proyectos WCF en forma mucho más simple.
Para aquellos que aún no han trabajado con el WCF o necesitan una capacitación de diferentes aspectos que provee esa tecnología les sugiero los siguientes recursos. Los WebCasts están basado enel Visual Studio 2008, por ese motivo es conveniente usar ese entorno.
En ingles
WCF Getting Started
http://msdn.microsoft.com/en-us/library/ms734712.aspx
Microsoft Windows Communication Foundation Step by Step, John Sharp
Disponible para su compra en Microsoft-Press
http://www.microsoft-press.co.uk/scripts/product.asp?ref=811252
O bien en librerias online como http://www.books24x7.com
Pro WCF: Practical Microsoft SOA Implementation
by Chris Peiris, Dennis Mulder et al.
Apress © 2007 (505 pages) Citation
ISBN:9781590597026
Providing coverage of the unified programming model, reliable messaging, security, peer-to-peer programming, and more, this is a complete guide to WCF from the SOA architecture perspective and shows why WCF is important to web service development.
(este aun no lo lei,pero me parece muy interesante)
En Portugues (Brasil)
MSDN Webcast: Melhores práticas no uso do WCF
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032409560&flag=3
Webcast Arquitetura: Arquitetura Orientada a Serviços: WCF Boas práticas (do levantamento, construção e hospedagem
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032415471&flag=3
Suscribirse a:
Entradas (Atom)