You are invited to take part in this exclusive opportunity to attend the Windows Server “Longhorn” Touchdown Trainer Airlift event in Amsterdam, The Netherlands the week of December 4, 2006. This event is being offered to a select group of Microsoft Regional Directors and trainers from the US, Canada, EMEA, and LATAM regions.

La agenda del evento sigue siendo la misma, pero comenzaremos un poco más temprano: 

8:30 a 9:00: llegada y desayuno

09:00 a 10:00: Programa MVP en Latinoamérica – Néstor Portillo, Gerente Regional de Américas

10:00 a 11:00: Programa MVP – Sean O’driscoll, GM Community Support and MVP Program

11:00 a 11:30: Break

11:30 a 12:30: Servers y D&PE

12:30 a 13:30: Almuerzo

13:30 a 14:30: Competencia

14:30 a 15:30: Break

15:30 a 16:00: Licenciamiento

16:00 a 17:00: MVP Mejores Practicas – Eugenio Serrano

🙂 nos vemos en el Capital 😉

Un enfoque de análisis especialmente pensado para proyectos de arquitectura orientada a servicios SOA.

El  objetivo es determinar el alcance de la iniciativa SOA. En la capa de servicios serán definidos e individualizados los servicios candidatos a ser implementados en el proyecto de integración.

El proceso de determinación de cómo se representan en Servicios los requerimientos de automatización de los procesos de  negocio, es dominio del análisis orientado a servicios. Las primeras preguntas a ser resueltas son:

Ø       ¿Qué servicios necesito construir?

Ø       ¿Qué lógica puede ser encapsulada en cada servicio?

Los objetivos superiores de desarrollar este proceso de análisis orientado a servicios son:

Ø       Definir las operaciones (funciones) candidatas.

Ø       Agrupar las operaciones en contextos lógicos. Estos contextos son los servicios candidatos.

Ø       Definir preliminarmente las fronteras de los Servicios para evitar solapamiento entre Servicios existentes o planeados.

Ø       Identificar lógica de negocio con potencial de re-uso

Ø       Asegurarse de que el contexto de la lógica encapsulada sea apropiado para el uso previsto.

Ø       Definir cualquier conocimiento de los modelos de composición preliminar de las aplicaciones.

El sub proceso de análisis tiene las siguientes etapas:

1.     Define business automation requeriments

Para lograr una buena definición de los servicios candidatos es necesario contar con requerimientos de negocio lo suficientemente maduros. Para asegurar esto, se realiza está etapa que apoya a la definición formal de los requerimientos de negocio.

2.     Identify existing automation systems

Se deben identificar la lógica de aplicaciones existente, a ser extendida o automatizada para satisfacer las necesidades de negocio identificadas en el punto 1.  En este punto del análisis orientado a servicios no se determinará cuales serán exactamente los Servicios a construir sino que se pretende identificar los sistemas que potencialmente serán afectados.

3.     Model Candidate Services

El análisis orientado a servicios introduce el concepto “Service Modeling Process” por el cual las operaciones candidatas son identificadas y agrupadas en contextos lógicos propuestos. Esta propuesta se convierte en los servicios candidatos que eventualmente se convierten en servicios en las etapas de implementación del proyecto.

En una arquitectura orientada a servicios los Servicios son una parte fundacional de dicha arquitectura. Un error común en las implementaciones de SOA es pensar que las aplicaciones exponen servicios de manera espontánea, típicamente implementaciones Web Services.

Este es una aproximación inocente, que lleva a tener problemas en el largo plazo porque genera un universo de conexiones punto a punto no administradas que sube los costos de integración y operación de los sistemas.

Por esta razón es necesario definir cómo los servicios serán expuestos en la plataforma de integración.

Definición de Servicio

Para poder enfrentar un proyecto SOA se necesita acordar que es un Servicio para evitar problemas de interpretación cuando los proveedores de las aplicaciones construyan servicios para la plataforma.

Existen las operaciones de servicios que son funcionalidades que las aplicaciones consumen. Estas operaciones se agrupan en contextos lógicos. Estos contextos lógicos son Servicios. Un ejemplo de esto sería:

Ø      Contexto Lógico: Servicio Información Indicadores Financieros

Ø      Operaciones se Servicios:

o       Valor UF

o       Valor UTM

Este ejemplo muestra la diferencia entre operaciones y servicios.

Diferencia entre Servicios de Negocio y Aplicación

Después de diferencia operaciones de servicios el siguiente paso es hacer la diferencia entre Servicios de Negocio y de Aplicación. Esta es una definición suave, porque no existe un criterio absoluto para la definición de que es un servicio de aplicación y cual es de Negocio.

Los Servicios de Aplicación son los servicios que exponen operaciones (funciones) de las aplicaciones para que la plataforma de integración use. Estos servicios son puestos a disposición de la plataforma de integración no de las aplicaciones clientes.

Los Servicios de Negocio son los servicios que exponen operaciones en la plataforma de integración para que las aplicaciones clientes consuman. Estas operaciones deben ser de una granularidad mayor, porque implementan funcionalidad de negocio muchas veces transversal a las aplicaciones.

En el desarrollo de software todo el mundo sabe que existe una disciplina de análisis que tiene como objetivo lograr un entendimiento profundo de los requerimientos que en software debe satisfacer y proponer la solución a nivel conceptual que después las tareas de diseño volverán en una solución concreta, lista para ser implementada.

 Lo primero que hay que tener claro sobre el análisis de Servicios en SOA, es que el objetivo de está disciplina es obtener los Servicios Candidatos. Son sólo candidatos, porque en el contexto de integración hay muchas cosas que pueden hacer imposible que ese candidato se convierta en un servicio en producción. Por ejemplo, la tecnología de la aplicación, quien administra esas aplicaciones, conocimiento de cómo funcionan, etc.

 Segundo, existe una confusión en la definición de un servicio. Por ejemplo, Obtener el valor de la UF en un día del año ¿es un servicio? En mi opinión no lo es, sólo es una operación de un servicio. Un Servicio es una agrupación de Operaciones de Servicios. Esta agrupación que llamamos servicio es un “contexto lógico” que agrupa.

 Tercero, existe una confusión en los analistas sobre la granularidad de los servicios. Antes de todo, no existe una regla que se pueda usar para determinar la granularidad adecuada de un servicio. Pero sí existe una diferencia entre un Servicio de Negocio y un Servicio de aplicación. Un Servicio de negocio nace para satisfacer necesidades de un proceso de negocio, típicamente están ubicados en el bus de servicios y son implementados usando lógica de una o más aplicaciones. Los Servicios de Aplicaciones nacen con un objetivo distinto, apoyar con lógica de esa aplicación a un servicio de negocios. Estos servicios son acotados al contexto de la aplicación.

 Después de revisar estos tres puntos fundamentales, se tiene una base para poder revisar el análisis de los servicios de negocio dentro de una iniciativa SOA.

 Análisis de servicios, pasos fundamentales.

 Cuando se están modelando los servicios de una arquitectura orienta a servicios es fundamental abstraerse de los sistemas y aplicaciones existentes. Primero es lo primero, ¿por qué está implementando SOA? No es por iniciativa de los Developer que aprendieron ha hacer servicios Web. La razón fundamental es agilizar la implementación de procesos de negocio.

 Por eso, hay que partir con la definición de los requerimientos de negocio. Esto quiere decir que se debe seleccionar el proceso de negocio a implementar. Además de seleccionar, se debe tener bien definido y documentado este proceso de negocio que sea información útil para la definición de servicios candidatos.

 Después de tener el requerimiento de negocio “identificado”, se deben descomponer el proceso para encontrar los “actores” de este proceso. Los actores del proceso son todos los sistemas, aplicaciones y personas que actúan en el proceso. En este punto no es el objetivo identificar servicios de aplicación cadidatos, solo identificar actores.

 Siguiendo estos dos pasos previos ya se cuenta con las necesidades del negocio y los actores que deben ser incluidos en el análisis de los servicios candidatos. Es ahora que se comienza con el modelamiento de los servicios candidatos.

 Este paso tiene como resultado dos entregables concretos:

Ø      Identificación de Operaciones de Servicios de Negocio Candidatos

Ø      Agrupación de las operaciones en Servicios de Negocio Candidatos.

 En resumen los pasos a seguir el análisis orientado a servicios son:

1. Definición de los requerimientos de negocio.
2. identificación de los actores.
3. Modelado de Servicios Candidatos.

 Modelado de Servicios Candidatos.

 Este punto es el núcleo del trabajo del análisis SOA, ya que pone foco en la generación de los Servicios Candidatos. Los pasos anteriores también son parte del análisis de cualquier sistema, mientras que este es especifica de un proyecto SOA.

 [Continuará en el próximo POST]

Un mensaje en si es simple, sólo es una estructura de datos. Ahora, en el contexto de SOA, donde consumidores y servidores intercambian información libremente en base a los contratos y políticas la cosa es diferente.

En este escenario la construcción del mensaje tiene varios aspectos de los cuales uno se debe hacer cargo. Estos datos “anexos” se incluyen en el sobre del mensaje (WRAPPER). A continuación se explican los aspectos básicos a tener en cuenta.

1. Identificador de correlación.

Problema: una aplicación que envía muchos mensajes a diferentes proveedores de servicios, recibe múltiples respuestas. Debe ser capaz de identificar que respuesta pertenece a que petición.

Solución: Cada mensaje debe tener un identificador de correlación único. Para esto se deben considerar los siguientes componentes de la cadena:

Ø      Aplicación que hace el Request.

Ø      Servicio que responde.

Ø      Mensaje Request.

Ø      Mensaje Response.

Ø      Identificador Request (identificador de correlación)

2. Secuenciador de Mensajes.

Problema: en un escenario SOA los mensajes viajan por redes por lo que se debe tratar de usar el ancho de banda de la mejor manera posible. Para ello hay que observar el tamaño del mensaje que se quiere enviar.

Solución: Usar un secuenciador de mensajes que divide los mensajes en partes para evitar el problema del ancho de banda. Los datos necesarios a agrega en el HEADER para cada mensaje secuenciado son:

Ø      Secuencia, identificador de la secuencia.

Ø      Posición, identificador de la posición de esa parte del mensaje en la secuencia.

Ø      Fin, indica si es el último mensaje de la secuencia.

3. Expiración de mensajes.

Problema: en todos los escenarios SOA de aplicaciones empresariales se persisten los mensajes como testimonios o para análisis posterior. Esto produce un problema de almacenamiento de datos.

Solución: Dar tiempo de vida a los mensaje. Un campo de tipo Fecha/Hora que indique si el mensaje a terminado su ciclo de vida. Si expira el mensaje debe ser eliminado o movido a un DEAD LETTER.  Siempre existirán mensajes que no tienen  expiración, ellos se marcan en este mismo campo.

Los aspectos anteriores podemos ubicarlos en el HEADER del WRAPPER del mensaje. A su vez en el BODY ponemos la información de negocio, propósito inicial del mensaje.

Existen muchas cosas que se  deben tomar en cuenta cuando se identifican escenarios en los cuales se utilizarán aplicaciones móviles. Por ejemplo el dispositivo que se utilizará para implementar la solución. La funcionalidad más compleja que se agrega a este tipo de soluciones tiene relación  con la administración de las comunicaciones y el intercambio de información entre la aplicación y los servidores de Back-End, ya que se tiene en estos momentos conexiones poco confiables o intermitentes.

Este tema obliga al desarrollar capacidades de trabajo Off-line en cada dispositivo. Para poder desarrollar aplicaciones que trabajen Off-line se debe tener en cuenta aspectos cómo Cache Local de datos, sincronización, transacciones basadas en compensaciones, etc. 

Este problema es conocido como Occasionally Connected Computing (OCC). Para hacer aplicaciones que se comporten bien ante los desafíos del OOC existe un modelo llamado OCC MODEL. 

Las aplicaciones OCC son la nueva generación de aplicaciones empresariales para la plataforma móvil. Las aplicaciones se ejecutan en los dispositivos, no como el Browser que obliga a estar conectado siempre;  donde se ingresan datos, se maneja la consistencia y se le da al usuario la sensación de trabajar sin importar el estado de la conectividad. Los criterios que establecen la diferencia entre una aplicación OCC y cliente servidor o basadas en Browser son:

Ø      Una aplicación OCC, sigue trabajando tenga o no conexión con los servidores centrales.

Ø      La aplicación OCC, trabaja con un Cache de datos local en ausencia de conectividad.

Ø      Las colas de la aplicación actúan al fallar la conectividad (Mensajería asíncrona)

Ø      La aplicación detecta cuando existe conectividad y procesa las colas de mensajes y refresca el Cache de datos local. (Publicación y Suscripción)

Las aplicaciones que cumplen con estos criterios son OCC. 

El martes tengo que dar una conferencia para clientes de mi empresa sobre integración. Es de un nivel técnico comercial. No es fácil plasmar un mensaje claro para estos dos segmentos de audiencia.

La audiencia técnica, suele descalificar de entrada a todos los comerciales y gente que hace presentaciones. En su pragmática mente, cualquier persona que no sepa hacer no es un interlocutor válido. Además muchas veces su visión es consumida por sus actividades del día a día, por lo que no pueden enfocarse en las necesidades futuras del negocio.

La audiencia comercial, no entiende nada del cómo hacer las cosas y no quieren que los agobien con complejidad. Esperan que sus problemas de negocio se resuelvan de manera “transparente” para ellos, y sólo participar el las felicitaciones del final del proyecto.

Ambos tipos de audiencia son válidos, lo difícil es hablarle a los dos en una misma conferencia y que todos se vayan a su casa contentos.