martes, 16 de octubre de 2012

EAI

Uno de los temas que me interesó del curso DSD fue 'Enterprise application integration'.
En Internet encontré lo siguiente:

La integración de aplicaciones empresariales o EAI (siglas en inglés de enterprise application integration) se define como el uso de software y principios de arquitectura de sistemas para integrar un conjunto de aplicaciones, dentro de cualquier empresa.

Justificación del EAI

Es el proceso de conectar las aplicaciones unas con otras para intercambiar información operativa o financiera. Cuando dichos sistemas no pueden compartir su información efectivamente, se crean cuellos de botella que requieren de la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la información. Con una arquitectura EAI correctamente implementada, las organizaciones pueden enfocar la mayoría de sus esfuerzos en la creación de competencias que generen valor, en lugar de enfocarse en la coordinación de labores operativas.
Durante varias generaciones, los sistemas de las empresas han servido para un propósito especifico a un único usuario o grupo de usuarios, los cuales actúan como la interfaz de dicho sistema con el resto de la organización, limitando su conexión con otros sistemas modernos o más amplios en la empresa y más aún, por la creciente demanda de las empresas por compartir datos y usarlos en sus procesos sin tener que realizar cambios en sus aplicaciones o en sus estructuras de datos.
Uno de los retos que encaran las organizaciones modernas es darle a sus empleados información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de mover esta información entre las aplicaciones.
EAI, como una disciplina, busca solventar muchos de esos problemas, así como crear nuevos paradigmas para, ciertamente, mejorar a las organizaciones tratando de trascender en el objetivo de conectar las aplicaciones individuales, para ser un mecanismo que incremente el conocimiento dentro de la organización y crear ventajas competitivas futuras a la empresa.

Mejorando la conectividad
La integración de aplicaciones de empresa ha incrementado su importancia porque la computación en las empresas frecuentemente toma la forma de islas de información. Esto ocasiona que el valor de los sistemas individuales no sea aprovechado al máximo debido a su aislamiento.
Si la integración se aplica sin seguir un enfoque estructurado de EAI, las conexiones punto a punto crecen al interior de la organización resultando en una masa disforme que es difícil de mantener. Esto se denota normalmente como el espagueti, en alusión al equivalente en programación: el código espagueti.

Objetivo del EAI
EAI puede ser usado con diferentes fines:
Integración de datos (información): asegurando que la información en varios sistemas sea consistente. Esto también se conoce como EII (Enterprise Information Integration).
Integración de procesos: enlace de los procesos de negocios entre diferentes aplicaciones.
Independencia de proveedor: extrayendo las políticas o reglas del negocio de las aplicaciones e implementándolas en un sistema EAI, de forma que cualquiera de las aplicaciones usadas pueda ser cambiada sin que dichas reglas de negocio deban ser reimplementadas.
Facade común: Un sistema EAI puede actuar como el front-end de un cúmulo de aplicaciones, proporcionando una interfaz de acceso única y consistente a esas aplicaciones y aislando a los usuarios sobre la interacción con distintas aplicaciones.

Patrones de EAI
Patrones de integraciónHay dos patrones que implementan los sistemas de EAI:
Mediación: aquí, los sistemas de EAI actúan como el vínculo de los enrutadores entre varias aplicaciones. En el lugar en el cual ocurre un evento interesante en alguna aplicación (ejemplo: se crea una nueva información, se completa una nueva transacción, etc.) se notifica a un módulo de integración del sistema EAI. El módulo entonces propaga esos cambios a las otras aplicaciones relevantes.
Federación: en este caso, el sistema EAI actúa como un consolidador de información entre varias aplicaciones. Todos los accesos del exterior a cualquiera de las aplicaciones son recibidos por el sistema EAI y éste está configurado para exponer sólo la información relevante, conectándose a las aplicaciones del mundo exterior y efectuar todas las interacciones con las aplicaciones internas sin intervención del agente externo.
Ambos patrones son usados en conjunto frecuentemente. El mismo sistema EAI puede tener varias aplicaciones en sync (mediación), mientras sirve requerimientos de agentes externos contra esas aplicaciones (federación).

Patrones de acceso
EAI soporta patrones de acceso tanto síncronos como asíncronos, el primero es el habitual en el caso del patrón de mediación y el segundo en el caso de federación.
Vida de los patrones
Una operación de integración puede ser de "corta vida" (por ejemplo, puede mantenerse la sincronía de los datos entre dos aplicaciones en un segundo) o de "larga vida" (por ejemplo, en uno de los pasos puede ser necesario que el sistema EAI requiera de la aprobación por parte de un agente humano de un préstamo y que éste necesite horas o días para autorizarse).

Topologías de EAI
Hay dos topologías principales: hub-and-spoke, y bus. Cada una de ellas tiene sus propias ventajas y desventajas:
En el modelo hub-and-spoke, el sistema EAI actúa como el centro (el concentrador), el cual interactúa con las aplicaciones, vía las conversaciones (o spokes).
En el modelo de bus, el sistema EAI es el bus (o es implementado como un módulo residente en un bus de mensajes existente o un middleware orientado a mensajes).

Problemas de implementación de los EAI
En el año 2003 se reportó que el 70% de todos los proyectos EAI fallaron.
La mayoría de dichas fallas no se debían a fallas técnicas del software mismo o la implementación, sino a problemas de gobernabilidad.
El gerente general de EAIIC, Steve Craggs ha determinado los siete principales retos que afrontan las compañías que usan sistemas EAI y explica soluciones a dichos problemas.
Cambio constante
    La propia naturaleza de EAI es dinámica y requiere directores de proyecto dinámicos para su aplicación.
Falta de experiencia en EAI
    EAI requiere conocimiento de muchas problemáticas y aspectos técnicos.
Estándares en competencia
    Dentro del campo de EAI, la paradoja es que los estándares de EAI no son por sí mismos universales, ya que cada proveedor particular trata de imponer los propios.
EAI es un paradigma de herramientas
  EAI no es una herramienta, si no es un sistema y debe ser implementado como tal.
Construir interfaces es un arte
  Realizar el proceso de ingeniería de la solución puede no ser suficiente. Las soluciones requieren ser negociadas con departamentos de usuarios para lograr un consenso común sobre el producto final. La falta de consenso en los diseños de las interfaces tiende a acarrear un esfuerzo excesivo para mapear los requerimientos de datos de varios sistemas.
Falta de detalle
  La información que al principio parece poco importante, con el tiempo se puede volver crucial.
Contabilidad
  Puesto que varios departamentos pueden tener requerimientos contradictorios entre sí, ellos deben contar para la estructura del sistema final.
Otros problemas potenciales pueden abarcar las siguientes áreas:
Requerimientos nuevos
   Las implementaciones de EAI deben ser extensibles y modulares para permitir cambios futuros.
Proteccionismo
   Las aplicaciones cuyos datos son integrados, frecuentemente pertenecen a departamentos diferentes los cuales tienen razones técnicas, culturales y políticas para no querer compartir su información con otros departamentos.

http://es.wikipedia.org/wiki/Enterprise_application_integration

lunes, 15 de octubre de 2012

Seguridad DSD


Siempre me apasioné por la seguridad informática.

Checkeando las amenazas en Internet tenemos que nos pueden:

- interceptar
- interrumpir
- modificar
- fabricar

Con el transcurrir del tiempo se crearon algoritmos de cifrado simétrico. Entre los más conocidos tenemos DES, TRIPLE DES, IDEA (International Data Encryption Algorithm)

DES fue adoptado en 1977 por el NIST, sus datos a cifrar se procesan en bloques de 64 bits, la longiu de la clave es de 56 bits

TRIPLEDES, son tres ejecuciones del algoritmo DES, longitud de clave efectivade 168 bits.

IDEA fue desarrollado por Xuejia Lai y J.Massey, los datos a cifrar se procesan en bloques de 64 bits, la longitud de la clave es de 128.

FIRMA DIGITAL
Debe ser posible verificar al autor y los datos y el tiempo de la firma.

Todas estas tecnologías son usadas para proteger nuestra información y mucho más cuando exponemos nuestros servicios para que todo el mundo pueda consumirlas.

sábado, 13 de octubre de 2012

¿Maven?

En el curso de DSD escuchamos varias veces el término MAVEN, pienso que es importante presentarlo. Para variar, esta herramienta fue creado por la gentita de Apache Software Foundation. Su filosofía principal  es proporcionar un esquema para la ejecución de las distintas fases realizadas en la construcción del software, pasando por la creación hasta la distribución de los componente(s) producto del proyecto.

Características principales:
- Complemento evolutivo de Apache Ant.
Para aquellos desarrolladores antiguos de software usando la tecnología Java, que no es mi caso, saben que Apache Ant ha sido la herramienta de construcción de uso más extendido. Maven no es sustituto de Ant sino es un complemento, es más, Maven tiene el core de Ant
- Convenio sobre la configuración.
Maven establece una serie de convenciones para la estructura de proyectos, el nombrado de comandos, etc.; de manera que un proyecto creado en Maven es válido en cualquier equipo y los comandos para compilarlo, empaquetarlo, construirlo siempre serán los mismos.
- Estructura jerárquica de las fases del ciclo de vida de construcción del proyecto.

     * compila (compile)
     * testea (test)
     * empaqueta (package)
     * instalalo
     * despliegalo (deploy)
        Es decir que si ejecutamos la tarea package se realizará una verificación para comprobar si los comandos compile y test ya han sido ejecutados, de lo contrario se ejecutarán en orden jerárquico.

- Descripción centralizada de los proyectos a través del POM (Project Object Model)

POM es un archivo XML nombrado como pom.xml en dónde podemos definir los diferentes matices de nuestro producto, información descriptiva del proyecto como nombre, grupo y versión, definición de dependencias, plugins a utilizar para extender funcionalidad, módulos que conforman el proyecto, perfiles de construcción e incluso información referente al equipo de desarrollo.


- Gestión de dependencias.
Maven proporciona un repositorio central con las diferentes distribuciones de la gran mayoría de los proyectos open source actuales organizados por proveedor, grupo y versión. De esta manera desde nuestros proyectos basta con definir la dependencia que necesitamos y maven se encargará de resolverla. Con el paso del tiempo han surgido repositorios que nacieron como réplicas y/o complemento del repositorio central maven por ejemplo el repositorio de Red Hat – Jboss. A propósito de esto cabe destacar que maven permite la creación de repositorios basados en niveles jerárquicos. Por ejemplo, podemos crear el repositorio de nuestra empresa con los proyectos que al interior de los mismo se van generando. De hecho cuando comenzamos a utilizar maven en nuestro equipo se va generando un repositorio local que será el primer lugar en dónde maven busque resolver una dependencia.



En resumen MAVEN es una herramienta orientada a simplificar el proceso de construcción de nuestras aplicaciones a la vez que nos promueve a mantener consistencia en la estructura de nuestros proyectos de software, además proporciona gestión de dependencias una de sus características más destacables.

Efectivamente, comparado con mis tiempos, hoy por hoy las herramientas existentes en el mercado nos hacen cada vez  la vida más fácil.
Antes que me denuncien por piratería, como a Bryce, les mando el link


lunes, 8 de octubre de 2012

Primera experiencia

Este curso me permitió conocer mucho más los temas de Sistemas Distribuidos. Si bien es cierto fueron temas nuevos para mí, logré entender que los sistemas distribuidos son una realidad en el mundo TI.

Las herramientas usadas como GITHUB y otros; permitió al grupo 3JML culminar eficientemente el trabajo final. La metodología usada nos permitió trabajar en equipo y desarrollar cada tema, de acuerdo a la experiencia  de los integrantes, pero felizmente nos adaptamos sin sobresaltos.

Con respecto al foro, es un medio interesante de investigación; creo que la investigación de estos temas es muy amplia y se necesita bastante tiempo para además de investigar, aplicar los ejemplos. Creo que un tema (en el foro) bien investigado y aplicado es mucho más productivo que los cinco foros ofertados en este ciclo.