Archivo de la categoría: Proyecto Mini ESB

Proyecto Mini ESB DotNet Código Abierto, Mensaje Universal

Dentro de los diferentes aspectos que hemos estado discutiendo en el contexto de este proyecto (Crear un ESB) estamos en este momento revisando el modelo de mensaje universal [1].

La idea es tener un único esquema de mensajería con el ESB simplificando de esa manera enormemente el problema.

 

Mensaje Universal

Las aplicaciones para comunicarse con la plataforma de integración utilizan mensajes XML. Un mensaje no contiene sólo información de los argumentos a utilizar en la llamada a la operación del servicio de negocio. Además de esta información propia del negocio contiene mucha información de utilidad para la plataforma.

La información propia de la plataforma son datos que se trasmiten fuera de banda. La idea es que no se mezclen con los datos de negocio.

Para simplificar la modelo y que la integración con la plataforma de integración se define usar un mensaje canónico de comunicación. Fowler llama a este mensaje universal como Canonical Data Model. La siguente figura muestra el patrón de Fowler.

Figura 1: Patrón Canonical Data Model.

La idea es que todas las aplicaciones y servicios usan un esquema de mensaje único. Está definición facilita el trabajo para los desarrolladores de servicios y aplicaciones porque siempre deben usar el mismo esquema.

Este mensaje para poder ser útil para todos los servicios debe ser capaz de contener los datos fuera de banda (para la plataforma) y los datos de negocio (para el servicio). Esto se logra implementando el patrón Envelope Wrapper, que se muestra en la siguiente figura.

Los datos de negocio, son insertados en el mensaje. Este mensaje viaja por la plataforma y al momento de consumir el Servicio de Negocio los datos de negocio son extraídos y pasados al servicio. La respuesta del servicio sigue el mismo proceso pero hacia la aplicación, que cuando recibe la respuesta la extrae del mensaje.

Figura 2: Patrón WRAPPER

 

Esquema de Mensaje propuesto

Para la plataforma de integración se propone el uso de un esquema de mensaje que tiene tres grandes secciones:

 

  • HEADER
  • BODY
  • ERROR

El esquema con estas tres secciones se muestra en la siguiente figura.

Figura 3: Esquema mensaje universal.

 
HEADER

La sección HEADER tiene como objetivo contener los datos de contexto necesarios para que la plataforma pueda actuar. Son los datos fuera de banda. En la siguiente figura se muestra la información que contiene e HEADER.

Figura 4: HEADER mensaje universal.

Los campos de está sección son lo siguientes:

Ø HASH

    • Request: Es la firma de los argumentos de llamada.
    • Repsonse: Es la firma de la respuesta.

Ø Gestión: es un diccionario de campos para destacar información del mensaje que debe ser almacenada en el LOG para gestión de manera destacada.

Ø Expiración: da el tiempo de vida del mensaje. Se usa para procesos de larga duración.

Ø Secuenciador: es el atributo que permite ensamblar una respuesta que viene dividida en partes.

  • Secuencia: Identificador del mensaje dividido.
  • Posición: indica que parte del mensaje es.
  • Fin: indica si es la última parte del mensaje.

Ø CorrelationID: Es el identificador de correlación. Tiene como objetivo ser un identificador único de los mensajes. Como no es posible tener un generador de números únicos para todas las aplicaciones que se conectan a la plataforma de integración, esto es un identificador compuesto.

 

  • appOrigen: Identifica la aplicación que llama a la plataforma.
    • § idUsuario: Identifica al usuario de la aplicación.
    • § idRequest: identificador de transacción de la aplicación.
    • § timeStamp: Fecha y hora de la llamada.
    • § CanalRespuesta: Para respuestas asíncronas indica la URI del canal de respuesta.
  • serDestino: identifica al servicio que se está llamado. Esta es una identificación lógica, porque es el motor de integración quien cursará la llamada para el servicio finalmente.
    • § isServicio: identificador del servicio.
    • § URI: URI del servicio expuesto por la plataforma.
  • tipoRequest: identifica el esquema de mensaje que se está enviando.
  • Version: versión del mensaje que se está llamando.
BODY

En el BODY se encuentran los parámetros de la llamada a la operación de negocio y en respuesta, viene la respuesta del servicio.

En la figura 5 se muestra el esquema.

Los parámetros son opcionales y son una tabla hash de parámetros serializados en XML.

La respuesta es un TAG de XML sin esquema porque puede contener cualquier información.

 

Error

Aquí se almacena la información de excepciones que ocurren en el circuito de la llamada al servicio. Este es un TAG opcional.

Los campos de esta sección son los siguientes:

 

  • Ø idError: Identificador del error.
  • Ø dateTime: Fecha y hora del error.
  • Ø Origen: es la glosa del lugar dónde se produjo el error.
  • Ø Tipo: Es el tipo de error.
  • Ø Decripcion: Es la descripción del error.

Figura 4: BODY y ERROR del esquema XML

El siguiente código muestra el esquema XSD

 

<?xml version="1.0" encoding="utf-8"?>
<!– edited with XMLSpy v2006 rel. 3 sp1 (http://www.altova.com) by Juan Pablo (Datco) –>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="xml1">
        <xs:annotation>
            <xs:documentation>Raiz</xs:documentation>
        </xs:annotation>
        <xs:complexType>
            <xs:sequence>
                <xs:element name="Header">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="correlationId">
                                <xs:complexType>
                                    <xs:sequence>
                                        <xs:element name="appOrigen">
                                            <xs:complexType>
                                                <xs:sequence>
                                                    <xs:element name="idAplicacion" type="xs:string" nillable="false" />
                                                    <xs:element name="idUsuario" />
                                                    <xs:element name="idRequest" />
                                                    <xs:element name="timestamp" />
                                                    <xs:element name="CanalRespuesta" />
                                                </xs:sequence>
                                            </xs:complexType>
                                        </xs:element>
                                        <xs:element name="serDestino">
                                            <xs:complexType>
                                                <xs:sequence>
                                                    <xs:element name="idServicio" type="xs:string" />
                                                    <xs:element name="uri" type="xs:anyURI" />
                                                    <xs:element name="Versión" />
                                                </xs:sequence>
                                            </xs:complexType>
                                        </xs:element>
                                        <xs:element name="tipoRequest" />
                                        <xs:element name="version" />
                                    </xs:sequence>
                                </xs:complexType>
                            </xs:element>
                            <xs:element name="secuenciador">
                                <xs:complexType>
                                    <xs:sequence>
                                        <xs:element name="secuencia" type="xs:int" default="1" />
                                        <xs:element name="posicion" type="xs:int" default="0" />
                                        <xs:element name="fin" type="xs:boolean" default="true" />
                                    </xs:sequence>
                                </xs:complexType>
                            </xs:element>
                            <xs:element name="expiracion" type="xs:dateTime" />
                            <xs:element name="gestion" minOccurs="0">
                                <xs:complexType>
                                    <xs:sequence>
                                        <xs:element name="campo" type="xs:string" maxOccurs="unbounded" />
                                    </xs:sequence>
                                </xs:complexType>
                            </xs:element>
                            <xs:element name="hash" minOccurs="0">
                                <xs:complexType>
                                    <xs:sequence>
                                        <xs:element name="request" />
                                        <xs:element name="response" />
                                    </xs:sequence>
                                </xs:complexType>
                            </xs:element>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>
                <xs:element name="body">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="parametros" minOccurs="0">
                                <xs:complexType>
                                    <xs:sequence>
                                        <xs:element name="parametro" maxOccurs="unbounded">
                                            <xs:complexType>
                                                <xs:sequence>
                                                    <xs:element name="nombre" type="xs:string" />
                                                    <xs:element name="valor" />
                                                </xs:sequence>
                                            </xs:complexType>
                                        </xs:element>
                                    </xs:sequence>
                                </xs:complexType>
                            </xs:element>
                            <xs:element name="respuesta">
                                <xs:complexType>
                                    <xs:attribute name="datetime" type="xs:string" use="required" />
                                </xs:complexType>
                            </xs:element>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>
                <xs:element name="error" minOccurs="0">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="idError" />
                            <xs:element name="datetime" />
                            <xs:element name="Orgien" />
                            <xs:element name="tipo" />
                            <xs:element name="Descripcion" />
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

Código Esquema XSD del mensaje universal.

Referencias

[1] http://www.enterpriseintegrationpatterns.com/CanonicalDataModel.html

Anuncios

Proyecto Mini ESB DotNet Código Abierto, Buscando definiciones Iniciales

Como primer paso para poder poner en marcha este proyecto, voy a tratar de ordenar los comentarios recibidos hasta ahora. Las respuestas puestas aquí son para la discusión del equipo.

Aquí van los comentarios

C1.- ¿El proceso no es demasiado waterfall? ¿No sería mejor pensar en iteraciones rápidas e ir publicando todo en CodePlex desde el inicio? Me parece que es más dinámico y todo avance irá en función al feedback que se obtenga -más allá de los objetivos iníciales que se establezcan.

Tienes toda la razón en el proceso “WaterFall”. Mi idea era hacer un proyecto pequeño, de alcance limitado por lo que no pensé en varias iteraciones. La razón de esto es que además de hacer el software la mayoría de los miembros del equipo no ha trabajado en un proyecto así. Me refiero a un proyecto de código abierto, con un equipo distribuido, etc.

Ahora, podemos fijar objetivos más amplios para el ESB y ponerlo en varias iteraciones. Me parece una buena idea. (Propuesta 1)

C2.- Me confunde un poco la idea de un Enterprise Service Bus para empresas pequeñas. ¿Cuál es la funcionalidad que tienes en mente? No conozco demasiadas empresas pequeñas que tengan problemas de integración que justifiquen esto. ¿Tienes una lista de requerimientos de alto nivel?

La idea de hacer un USB para pequeñas empresas es justamente darles una herramienta para que puedan construir “funcionalidad compartida” para diferentes aplicaciones. Es decir Servicios.

La funcionalidad que tengo en mente es (Propuesta 2):

1.- Catalogo de Servicios: Publicar servicios.

2.- Un despachador implementado en un Pipe And Filter.

3.- Filtros de autentificación, autorización y Traza.

C3 – Basarse en BizTalk creo que te dejaría fuera del alcance de cualquier empresa pequeña. El costo de licenciamiento es enorme. Lo que podría usarse eventualmente es BizTalk Services, aunque es algo en etapa de prueba aun.

Estoy de acuerdo usar BizTalk es mala idea, mejor usamos lo que viene con el Framework 3.0 (Propuesta 3)

C4 – Debiera haber una lista de cargos o tareas para que sean repartidas/asignadas/elegidas (?)

Para este proyecto usaremos una herramienta de colaboración como CodePlex [1]. Esta herramienta define los siguientes roles (Propuesta 4):

Rol1.- Anonymous

Rol2.- Logged-In

Rol3.- Developer

Rol4.- Coordinator

Las tareas las serán definidas por el equipo y la asignación será por acuerdo. Si no existe acuerdo en algún punto podemos votar como método de asignación. Aquí retomo algo que declaré en el segundo Post de este proyecto [2] "cumplir con los compromisos que asuman". Nadie será obligado a hacer algo, los compromisos son personales.

C5- Una de esas tareas inmediatas sería hacer un sitio/grupo propio del proyecto y por ende…

Sí, podemos usar CODEPLEX[1]. Yo ya creé el siguiente sitio para el proyecto:

http://www.codeplex.com/miniESB

Para poder darles acceso, necesito que se inscriban como usuarios codeplex. Este sitio permite hacer discusiones, compartir fuentes, etc.

C6- Hay que darle un nombre al proyecto

En este punto no tengo propuesta. Pueden darle el nombre que quieran 🙂

C7 – Felices vacaciones. …también eres de los que en sus vacas no puede estar sin desarrollar?

Muchas gracias, fueron unas buenas vacaciones pero muy cortas. 😉

Esos son los comentarios recibidos hasta ahora.

Durante “los comentarios sobre los comentarios” puse 4 propuestas, las cuales me gustaría validar con ustedes equipo. Las pueden ver fácilmente en el texto porque están marcadas con (Propuesta N).

Eso es todo por ahora, seguimos trabajando y quedo atento a sus comentarios.

Referencias

[1] Codeplex, http://www.codeplex.com

[2] Segndo Post, http://liarjo.spaces.live.com/blog/cns!4131EA552C5BB029!2266.entry

Proyecto Mini ESB DotNet Código Abierto

Hace un tiempo propuse en este espacio una idea que hace tiempo le doy vuelta. Hacer un proyecto de ESB en DotNet que sea Open Source. Ese post pueden verlo Aquí.

He conversado con unas 4 personas y me han dicho que Sí a la idea, lo cual me ha puesto muy contento. Además de las personas que he contactado directamente, hay otro par que leyendo el Blog me han mandado mensajes para participar.

Motivado por la recepción de la propuesta ahora propongo las siguientes etapas para el proyecto.

Etapa Inicial

  • Armar equipo
  • Definir Objetivos
  • Formalizar Alcances y visión.

Etapa Elaboración

  • Identificar referencias técnicas
  • Diseñar el ESB
  • Publicar Diseño.
  • Presentar el proyecto a la comunidad y recibir feedback.

Etapa de Construcción

  • Construcción del ESB
  • Construcción del caso de uso de Ejemplo.
  • Documentar el proyecto.

Etapa de publicación

  • Publicar el Proyecto en Codeplex
  • Presentación del resultado a la comunidad.
  • Celebrar el fin del proyecto. (Esta es la parte que más me gusta)

     

Hoy 27 de junio, dos días antes de irme de vacaciones partimos con esta iniciativa. Esto quiere decir que vamos a "Armar el equipo".

¿Quiénes puedes participar?

En rigor cualquier persona que tenga interés. Esto es un proyecto voluntario / Social, es decir no hay retribución económica por esto y el resultado del trabajo será un Software de uso libre y código abierto a la comunidad. La idea es hacer una contribución desde nuestra realidad a la problemática técnica de las empresas pequeñas y medianas.

¿Cuál es el beneficio de participar?

La respuesta para mí es muy simple, aquí todos aprendemos.

¿Qué requisitos necesito para participar?

Como vamos a desarrollar software es necesario que los miembros del equipo sepan programar, ojalá en DotNet. No hay que ser un genio de la NASA para participar, porque entre los diferentes miembros del equipo nos vamos apoyando para llegar al objetivo del proyecto.

¿A qué me comprometo si me inscribo en el proyecto?

El único compromiso que podemos pedirle a los voluntarios como proyecto es el de "cumplir con los compromisos que asuman". Es decir, si usted se compromete a asistir a una reunión o a escribir un paper, etc, simplemente hágalo. Nadie en el equipo impondrá tareas, los miembros del equipo nos repartiremos las tareas de común acuerdo, es decir cada uno tomará los compromisos que esté dispuesto a cumplir.

¿Cómo se organiza este proyecto?

Esto no es un proyecto de software comercial, por lo que no hay jefe. La idea es que los miembros del equipo se organicen entre pares y avancemos en dirección de cumplir con el objetivo del proyecto.

Ahora, la pregunta del millón de dólares…….

¿Cómo me inscribo?

La inscripción es muy simple. En este mismo POST ponga como comentario los siguientes datos:

  • Nombre ó Nick.

    Ejemplo: Juan Pablo – Liarjo.

  • De que parte de universo es.

    Ejemplo: Santiago de Chile, trabajo en una empresa de tecnología, en el departamento de Desarrollo de Software.

  • BackGround

    Ejemplo: He trabajado en desarrollo de sistemas 10 años. No soy informático sino que estudie Ingeniería Civil Electrónica, Tengo experiencia en DotNEt.

  • Enviar un mensaje privado con sus datos de Contacto

    Ejemplo: Hola Soy Juan Pablo, quiero participar, puse mis datos en el Blog y me correo es XXXX@lala.cl

    Los mensajes privados se pueden mandar usando la funcionalidad del Blog "Enviar Mensaje". Esto aparece al final del post, como Link/opción.

 

Bueno, la invitación hecha el 3 de junio ahora ya está formalizada.

Espero sinceramente que este proyecto sea exitoso, no sólo porque es una idea que se me ocurrió a mí, sino porque sería la primera iniciativa que conozco de la comunidad DotNEt en Chile que enfrenta un tema tan "sofisticado" como un ESB. Por otra parte con el producto que se generará aquí, muchas empresas pequeñas que no tienen acceso a este tipo de tecnologías podrán usarlo, lo que ayudará a acortar la Brecha Digital.

Por último pero no por eso menos importante es que aquí aprendemos todos.

Salu2

PD: Espero que alguien se anote por lo menos 😉

 

Proyecto MiniESB sobre Biztalk/WCF Código Abierto

Hace tiempo que estoy pensando en buscar algunos colaboradores para hacer un proyecto de código abierto para construir un mini ESB [1] con desarrolladores locales sobre BizTalk [2] / WCF [3].

Vamos por partes, código abierto para que sirva al resto de los miembros de la comunidad tanto como ejemplo de código y también como base para otros desarrollos.

Un mini ESB, porque es uno de los temas más confuso con los que me he topado en los proyectos relacionados con SOA [4] que he hecho. Además, la información disponible no es tan clara como se ve en otras plataformas.

Usando BizTalk porque es un excelente servidor para montar un ESB, el problema es que nadie te dice cómo. Por otra parte, WCF es una excelente Framework con el cual construir este tipo de aplicaciones.

No estoy seguro si hacerlo en BizTalk o con WCF, será resorte del equipo de trabajo ver cuál se usa.

Bueno, esto es una idea lanzada ahora queda reclutar el equipo y madurar el proyecto.

Un esquema de altísimo nivel de la solución sería

 

[Cliente] —–> [ESB(autentificación, autorización, catálogo)] —> [ServicioN]

 

Bueno, seguiré desarrollando esta idea, si alguien se quiere sumar es bienvenido.

Salu2

Referencias

[1]ESB, Enterprise Services Bus, http://en.wikipedia.org/wiki/Enterprise_service_bus

[2]BizTalk, Microsoft BizTalk Server, http://www.microsoft.com/biztalk/default.mspx

[3] WCF, Windows Communication Foundation, http://msdn2.microsoft.com/en-us/library/ms735119.aspx

[4]SOA, Service-oriented architecture, http://en.wikipedia.org/wiki/Service-oriented_architecture