Archivos Mensuales: octubre 2007

Resultado del Magister

Comparto con ustedes mis resultados en el Magister en tecnologías de la información.

Desde ahora en adelante, soy un Maestro según ellos …. ja ja ja

Anuncios

ESB con WCF, ¿cómo puedo implementar Adaptadores?

Problema

Para un proyecto de plataforma móvil estamos haciendo un ESB pequeño que utiliza WCF. La idea es que este ESB permita agregarle nuevos servicios de manera administrativa sin volver a compilar. Estos servicios son expuestos por otros sistemas y no se puede normar los contratos que estos exponen.

WCF permite llamar servicios a los cuales se le conoce su interfaz mediante el uso de ChannelFactory. Esto serviría pero hay una complicación adicional, no tenemos las interfaces en tiempo de diseño sólo en tiempo de ejecución. En resumen se necesitan en este caso dos cosas:

  1. Llamar servicios en tiempo de ejecución sin volver a compilar el cliente.
  2. Soportar DataContract en las llamadas a los servicios.

 Este es el concepto de adaptador…….

Solución propuesta, Uso de Reflexión

Para el primer problema podemos usar reflexión [2]. La reflexión nos permitirá en tiempo de ejecución hacer una instancia del Proxy para el servicio y de los tipos DataContract [3] que este utilice. Esto quiere decir que en tiempo de ejecución cargamos el Assembly [4] que contenga en Proxy y lo invocamos.

Veamos un ejemplo de un servicio simple en WCF. El código uno muestra el contrato del servicio, esto es lo que describe que es lo que el servicio hace. Luego, el código dos muestra los tipos de datos específicos del contrato del servicio. Por último, el código 3 muestra la implementación del servicio.

 

[ServiceContract()]

public interface IService1

{

    [OperationContract]

    string MyOperation1(string myValue);

    [OperationContract]

    string MyOperation2(DataContract1 dataContractValue);

}

 

Código 1: Contrato de servicio.

 

 [DataContract]

public class DataContract1

{

    string firstName;

    string lastName;

 

    [DataMember]

    public string FirstName

    {

        get { return firstName; }

        set { firstName = value; }

    }

    [DataMember]

    public string LastName

    {

        get { return lastName; }

        set { lastName = value; }

    }

}

Código 2: Datos del Contrato de servicio.

 

 public class service1 : IService1

{

    public string MyOperation1(string myValue)

    {

        return "Hello: " + myValue;

    }

    public string MyOperation2(DataContract1 dataContractValue)

    {

      return "Hello: " + dataContractValue.FirstName + " " + dataContractValue.LastName;

    }

}

Código 3: Implementación del servicio.

Para que el cliente (ESB) invoque al servicio va a requerir de un Proxy que le permita llamar a los métodos del servicio. Generamos entonces un proxy en un Assembly separado que pueda ser entregado al administrador del ESB para que lo "instale". La instalación no requerirá de compilación del lado del cliente (ESB).

Una vez que tenemos el Assembly podemos hacer una instancia del Proxy y ejecutar sus métodos. Como ejemplo, primero llamaremos al método MyOperation1 del servicio de ejemplo. Para esto construimos un método de llamado en el cliente como se muestra en el código 4.

 

/// <summary>

/// Este método ejecuta el proxy usando reflexion

/// </summary>

/// <param name="pathAssembly">Ruta del Assembly del Proxy</param>

/// <param name="NombreTypoProxy">Tipo del proxy</param>

/// <param name="NombreOperacion">Nombre del método a Ejecutar</param>

/// <param name="mParametros">paramtros del método</param>

public static void EjecutarProxy(string pathAssembly, string NombreTypoProxy,string NombreOperacion, object[] mParametros)

{

    Console.WriteLine("LLamada a través de un Proxy Externo");

    //1.- Levantar el Assembly que contiene el Proxy.

    Assembly SampleAssembly = Assembly.LoadFile(pathAssembly);

    //2.- Hacen una inctancia de la clase Proxy       

    object myClassObj = SampleAssembly.CreateInstance(NombreTypoProxy);// ("ProxyIntermedio.localhost.Service1Client");

    // 3.- Obtener la información del tipo del Proxy

    Type myTypeObj = myClassObj.GetType();

    // 4.- Obtener información del método a llamar

    MethodInfo myMethodInfo = myTypeObj.GetMethod(NombreOperacion);//("MyOperation1");

    //5.- llamar al servicio, usando el Proxy

    Console.Write("\nLLamando a – " + myTypeObj.FullName + "\n Respuesta: " +

                         myMethodInfo.Invoke(myClassObj, mParametros) + "\n");

    Console.ReadLine();

}

Código 4: llamada a través del proxy externo.

Este ejemplo utiliza un tipo de datos "primitivo" lo cual puede ser muy común pero no necesariamente así es siempre. Para servicios más complejos se usan tipos de datos complejos los cuales se modelan utilizando DataContract. El próximo ejemplo llama al método MyOperation2 que usa un argumento del tipo DataContract1.

El código 5 muestra cómo podemos llamar a un servicio que tiene como argumento de entrada un tipo de dato complejo haciendo uso de un Proxy externo. El principio es el mismos que en el caos anterior, con la diferencia que ahora debemos instanciar un DataContract y asignarle los valores que correspondan. Para esto usamos las capacidades de Reflexión para instanciar tipos y asignarle valores a sus propiedades como se muestra en el punto 6 del código 5. El código que llama a este método se muestra en el código 6, ahí se puede ver que el parámetro de entrada al método EjecutarProxyTypoComplejo es un diccionario [5] con los valores, el cual será recorrido y asignado dentro del método.

 

/// <summary>

/// LLamada utilizando un proxy externo con un método de datos complejo

/// </summary>

/// <param name="pathAssembly">Ruta del Assembly del Proxy</param>

/// <param name="NombreTypoProxy">Tipo del proxy</param>

/// <param name="NombreTypoData">Nombre tipo del DataContract</param>

/// <param name="NombreOperacion">Nombre del método a Ejecutar</param>

/// <param name="mParametros">Diccionario con los valores a asignar al Datacontract</param>

public static void EjecutarProxyTypoComplejo(string pathAssembly, string NombreTypoProxy,string NombreTypoData,string NombreOperacion, Dictionary<string,string>  mParametros)

{

    Console.WriteLine("\nLLamada a través de un proxy externo con tipo de dato complejo");

    //1.- Levanatr Assembly

    Assembly SampleAssembly = Assembly.LoadFile(pathAssembly);

    //2.- Crear instancia del Proxy       

    object myClassProxy = SampleAssembly.CreateInstance(NombreTypoProxy);

    //3.- Crear Instancia del DataContract

    object myDataContract = SampleAssembly.CreateInstance(NombreTypoData);

    //4.- Obtener los tipos de datos

    Type myTypeProxy = myClassProxy.GetType();

    Type myTypeData = myDataContract.GetType();

    //5.- Obtener la información del método.

    MethodInfo myMethodInfo = myTypeProxy.GetMethod(NombreOperacion);

    //6.- Asignar los valores al Datacontract1

    PropertyInfo prop;

    foreach (KeyValuePair<string, string> kvp in mParametros)

    {

        prop = myTypeData.GetProperty(kvp.Key);

        prop.SetValue(myDataContract, kvp.Value, null);

    }

    //7.- Objeto para usar como argumento tipado.      

    object[] mParam = new object[] { myDataContract };

    //8.- llamar al servicio

    Console.Write("\nllamando a  – " + myTypeProxy.FullName + " \nRespuesta:  " +

                         myMethodInfo.Invoke(myClassProxy, mParam) + "\n");

    Console.ReadLine();

}

Código 5: llamada a través del proxy externo con un tipo de dato complejo.

 

//….. algun códiogo aqui

Dictionary<string,string> lala = new Dictionary<string,string>();

lala.Add("FirstName","Juan Pablo");

lala.Add("LastName","García González");

EjecutarProxyTypoComplejo(

    @"..\ProxyIntermedio.dll",

    "ProxyIntermedio.localhost.Service1Client",

    "ProxyIntermedio.localhost.DataContract1",

    "MyOperation2", lala);

//…. algun código aquií

Código 6: llamada a través del proxy externo con un tipo de dato complejo.

Con esta técnica todos los futuros servicios pueden ser enlazados utilizando el Proxy autogenerado para cada servicio.  

 

Referencias

[1] Adapter pattern, http://en.wikipedia.org/wiki/Adapter_pattern

[2] Información general sobre la reflexión, http://msdn2.microsoft.com/es-es/library/f7ykdhsy(VS.80).aspx

[3]Contratos de Datos, http://www.microsoft.com/spanish/msdn/articulos/archivo/041206/voices/LearnTheABCsOfP.mspx#E3H

[4] What is a .Net Assembly? , http://www.programmersheaven.com/2/FAQ-DOTNET-DOTNET-Assembly-Explained

[5] Dictionary Generic Class, http://msdn2.microsoft.com/en-us/library/xfhwa508.aspx

¿Qué tópicos se deben incluir en un proyecto de SOA?

Cuando se comienza a desarrollar un proyecto de SOA es necesario detenerse a pensar en todos los aspectos a cubrir para que la adopción de este estilo de arquitectura no se convierta en un problema. Comúnmente se piensa que construir servicios es comenzar con una arquitectura orientada a servicios, pero en rigor afirmar esto es como decir que la arquitectura de una casa de hace construyendo ladrillos.

Los temas a incluir en el desarrollo de un proyecto de adopción de SOA que considero fundamentales son los siguientes:

  1. Cumplir con los principios de la orientación a Servicios.
  2. Diseño de las capas de Servicios.
  3. Definición del ciclo de vida de los Servicios
  4. Definición de los aspectos operacionales
    1. Soporte de múltiples protocolos estándares.
    2. Despacho garantizado.
    3. Servicios Síncronos y Asíncronos.
    4. Manejo de excepciones.
    5. Seguridad de los Servicios.
    6. Instrumentación.
    7. Contenedor de Servicios
  5. Caso de prueba.

Cumplir con los principios de la orientación a Servicios

Los principios de la orientación a servicios son la fundamentación de todo el esfuerzo que se realiza en este tipo de proyectos. Por esta razón se deben cumplir en todo momento con estos principios.

  • Los servicios son reusables.
  • Los servicios comparten contratos no código.
  • Los Servicios tienen bajo acoplamiento.
  • Los servicios tienen Fronteras explicitas.
  • Los Servicios son modulares y permiten la composición.
  • Los Servicios son autónomos.
  • Los servicios deben permitir métodos de descubrimiento.

Diseño de las capas de Servicios

En una arquitectura empresarial, es necesario ubicar la capa de servicios entre la capa de negocios y la capa de servicios de aplicación. Lo que se busca lograr con la definición clara de las capas de servicios es poder contestar preguntas fundamentales como:

  • ¿Qué lógica será representada por los servicios?
  • ¿Cómo se relacionaran estos servicios con la lógica de aplicaciones existentes?
  • ¿Cómo los servicios pueden representa de mejor forma los procesos de negocio?
  • ¿Cómo pueden los servicios ser construidos e instalados para promover la agilidad?

La siguiente figura muestra una idea de las capas y como se busca definirlas.

Definición del ciclo de vida de los Servicios

Para poder asegurar un resultado predecible en los futuros proyectos de software es necesario definir un proceso de análisis de los servicios que se desean construir.

El ciclo de vida del proyecto es un conjunto de pasos necesarios que deben ser cumplidos para construir los servicios necesarios de una arquitectura SOA. Los proyectos de implementación de una arquitectura orientada a servicios (SOA), siguen al igual que todos los proyectos de software un ciclo de vida definido.

Las etapas de este ciclo de vida son:

  • Análisis Orientado a Servicios
  • Diseño Orientado a Servicios
  • Desarrollo de Servicios
  • Prueba de Servicios
  • Instalación de Servicios
  • Operación de Servicios

Definición de los aspectos de implementación

Este es el primer punto que se ocupa de los aspectos de implementación. Estos temas son importantes para llevar las definiciones conceptuales de alto nivel a definiciones pragmáticas que los equipos de proyectos puedan utilizar. Por supuesto cada definición de estos aspectos debe cumplir con las orientaciones generales definidas con anterioridad.

La lista de aspectos a cubrir son:

  • Soporte de múltiples protocolos estándares.
  • Despacho garantizado.
  • Servicios Síncronos y Asíncronos.
  • Manejo de excepciones.
  • Seguridad de los Servicios.
  • Instrumentación.
  • Contenedor de Servicios

Caso de prueba

Como estrategia de validación, necesaria en cualquier proyecto, es necesario realizar un caso de prueba. La idea del caso de prueba es validar que las definiciones hechas son posibles de implementar y útiles para la organización.

Transferencia de Conocimiento

Por último, uno de los mayores problemas que se enfrentan las organizaciones que enfrentan proyectos de orientación a servicios es que cuando los consultores se retiran debe hacerse cargo de la arquitectura, operarla y seguir extendiéndola.

Para facilitar estas tareas se debe incluir un plan de transferencia de conocimiento que es más que escribir manuales o hacer una capacitación.

Estas son las recomendaciones para enfrentar un proyecto de inicio de arquitectura SOA.

Architect Forum

Estimados

El próximo miércoles 17 de octubre se hará el famoso evento Architec Forum, esta oportunidad, abordaremos SOA GOVERNACE como tema principal del fórum.

Las Arquitecturas Orientadas a Servicios (SOA de su sigla en inglés) proponen organizar las capacidades presentes en aplicaciones empresariales, en servicios interoperables basados en estándares que pueden ser recombinados y reutilizados para responder con mayor agilidad a las necesidades del negocio.

Las tecnologías habilitadoras han evolucionado muchísimo y con estas las experiencias que existen en la implementación de estas arquitecturas, sin embargo las estadísticas no son de fiar:  1 de cada 7 proyectos fracasan, las causas son varias pero la principal, según los estudios de Gartner,  es la falta de gobernabilidad de estas plataformas o Governance como ha sido acuñado este término en inglés.

Governance, desde la perspectiva SOA, significa estar en control de nuestra infraestructura de servicios, respondiendo a preguntas tales como: ¿Cuáles son los servicios disponibles? ¿Quienes usan estos servicios? Y ¿cumplen los mismos con las expectativas de los clientes o con los contratos de servicios previamente establecidos?

Estamos convencidos que a todos quienes en este momento se encuentran en un proceso de adopción de SOA les resultará sumamente interesante el tema a desarrollar.

Para poder inscribirse a este evento tienen que hacer click aquí. Recuerden que los cupos son limitados. 

 

Agenda

 

Miércoles 17-oct

09:00 a 09:30 – Welcome Coffee

09:30 a 10:00 – El Proceso de Adopción de SOA

10:00 a 10:40 – Transformando los Desafíos de SOA en Beneficios para el Negocio

10:40 a 11:00 – Cofee Break

11:00 a 12:00 – SOA Governance en la práctica, demostración basada en AmberPoint

12:00 a 12:10 – Sorteamos libros entre todos los asistentes

 

El Proceso de Adopción de SOA

En esta primera sesión analizaremos el proceso de adopción de SOA que Microsoft recomienda a las empresas y las potenciales dificultades que pueden surgir en el camino.

Oradores

Juan Pablo García, DATCO Chile, Alejandro Pacheco y Martín Cabrera, Microsoft Cono Sur.

 

Transformando los desafíos de SOA en Beneficios para el Negocio

Junto con los beneficios que SOA nos brinda, reducción del tiempo de desarrollo, más agilidad a nivel de negocio, facilidad a la hora de hacer integraciones entre sistemas, etc., también nos presenta nuevos desafíos:

 

  • ¿Cómo monitoreo en Tiempo Real el estado técnico del Servicio? (Rendimiento / Tiempo de Respuesta / Carga / Errores)
  • ¿Cómo monitoreo el negocio e informo en Tiempo Real de lo que ocurre? (Cliente / Proveedor / Importes / Tarjetas / Productos /…)
  • ¿Cómo controlo y gestiono los errores SOAP?. Cuanto me cuesta sin plataforma de control?
  • ¿Cómo defino los Service Level Agreements (SLAs) de los servicios?
  • ¿Cómo reacciono AUTOMATICAMENTE a las situaciones que exigen reacción?
  • ¿Cómo Implemento seguridad a nivel de servicio?
  • ¿Cómo pruebo los sistemas compuestos de servicios?
  • ¿Cómo monitoreo los servicios de proveedores externos?
  • ¿Cómo implemento servicios nuevos o versiones nuevas en el sistema, de forma controlada?

Oradores

Miri Hakmon es la responsable del área de soluciones y productos SOA y BPM en Slinges, cuenta con 10 años de experiencia en el mundo de integración de sistemas, gran parte de ella desarrollada en Israel trabajando con las soluciones lideres en el mercado, anteriormente ya ha colaborado con Microsoft Israel en conferencias sobre Business Process Management y Web Services Management.

 

SOA Governance en la  práctica, demostración basada en Amberpoint

En esta última sesión, Miri Hakmon realizará una demostración práctica de los productos de SOA Governance ofrecidos por AmberPoint Inc., uno de los partners globales de Microsoft con mayor experiencia en este tema.

Oradores

Miri Hakmon, Slinges

Lugar

 Microsoft Chile, Mariano Sanchez Fontecilla 310, Piso 6

 Nos Vemos.

Chiste, Derroche de conocimiento

Iba un chileno y un alemán en el metro de buenos aires y el alemán le
pregunta al chileno…

de dónde tu eres…. el chileno responde… bueno yo soy de Chile…

de Chile, ufff yo conozco Chile es muy bonito, sus poetas, Gabriela
Mistral y Pablo Neruda tan conocidos en todo el mundo, el 18 de
Septiembre donde celebran la primera junta de gobierno que la presidió Don
Mateo y Toro Zambrano, iniciando la República.

Como no olvidar el centro de Santiago con sus humoristas ambulantes que se
divierten riendo de los peruanos, como olvidar.

Recordar su gran vino hecho de las uvas bañadas por las
cristalinas aguas que provienen de la Cordillera de los Andes.

Ufff y su presidenta, la primera presidenta de Chile que tienen, la
Señora Michelle Bachelet Jeria hija de un militar asesinado por el
Régimen Militar que tomó el gobierno por la fuerza tomando el mando el
general Augusto Pinochet Ugarte quedándose en el mando 17 años, ufff

Y sus deportistas como Marcelo Ríos que salio numero uno en 1998 ganándole a
Andre Agassi 6-4 6-4 , o Iván Zamorano que salió
pichichi en España jugando por el Real Madrid, como olvidar.

Y el chileno le pregunta….. y usted de donde es???
bueno yo soy de Alemania, soy de Berlín.

y el chileno dice…… que son ricos los berlines

Vamos a decir que NO

 

Hace un año escribí este Post por el aniversario del triunfo del NO en el plebiscito del año 88. Ayer, casi el día de la conmemoración fueron detenidos todos los familiares de Pinochet vinculados al vergonzoso caso de robo de dineros públicos durante el gobierno militar, en rigor la dictadura.

Ahora comparto el hermoso himno de esa campaña, yo sólo era un niño en esa época.

 
Himno campaña del NO

MVP Open Day en Chile

Me llegó la invitación para el evento MVP Open Day en Chile. En este evento los manager del programa MVP vienen a Santiago de Chile a conocer las comunidades locales, recibir feedback y compartir experiencias.

Esta es la invitación, será una excelente oportunidad de intercambiar ideas. Todo lo interesante que no sea NDA lo compartiré en este BLOG.