Proyectos de desarrollo corporativo con Software Libre Sergio
Proyectos de desarrollo corporativo con Software Libre Sergio Machuca smachuca@telematica. com. uy Gabriela Sasco gsasco@telematica. com. uy JAIO – JSL 08/2012 – La Plata, Argentina
AGENDA § Introducción § Arquitectura utilizada § Integración § Gestión de los proyectos § Resumen estadístico § Conclusiones
Introducción (1) § Crecimiento significativo en la complejidad de la infraestructura tecnológica de TI. § Aplicaciones móviles y de Internet. § Ambiente competitivo. § Interacción con plataformas heterogéneas: – variedad de tecnologías – seguridad (encripción, puertos de comunicación) – administración de los sistemas – formas de interacción (sincrónica o asíncrona, unidireccional o bidireccional), restricciones sobre ella (atomicidad transaccional, niveles de robustez y performance, compatibilidad con lenguajes u otras plataformas). Utilización de mecanismos estándares u opciones ad-hoc. – disponibilidad (por ejemplo tolerancia fallas de componentes) – nivel de programación (facilidad de uso, nivel de abstracción); etc.
Introducción (2) §Plataformas de desarrollo empresarial - todos los componentes integrados en la herramienta de forma nativa. §Herramientas de software libre - los desarrolladores deberán dedicar tiempo en investigación e incluso debiendo construir componentes de bajo nivel.
Arquitectura utilizada (1) §Plataforma Base (basados en J 2 EE): –Servidor de aplicaciones: JBOSS –Framework de desarrollo: Eclipse –Técnicas y herramientas: • AJAX (Asynchronous Java. Script And XML) • MVC (Model View Controller) • STRUTS • HIBERNATE • JPA • JSF • Rich. Faces
Arquitectura utilizada (2) §Usabilidad - WEB = paradigma basado en request–response - Estándares y políticas que definen componentes y comportamientos de las interfaces de usuario y como ser implementados.
Arquitectura utilizada (3) §Servicios de Seguridad (1) –Repositorio de usuarios. • Garantizar la existencia de un usuario común para diferentes servicios –Autenticación de usuarios: • Open. Ldap –mediante la configuración de servidores de aplicaciones y, en Windows NT, desde la aplicación accediendo a través de una dll de acceso al Ldap. –Delegación: • clientes corporativos gestionan las cuentas de sus usuarios. • Definida mediante una estructura en el LDAP donde se definen usuarios supervisores que pueden delegar la administración de sus cuentas a otros usuarios
Arquitectura utilizada (4) § Servicios de Seguridad (2) – SSO (Single Sign On): • CAS (Central Authentication Service) – permite presentar las credenciales una única vez y que el ambiente las recuerde. – Certificación. • Open. SSL- herramienta de dominio público para generar certificados • Bibliotecas de interfaces con open. SSL (generación automática de certificados). – Cumplimiento de seguridad. • Documento de estándares de aplicaciones seguras basado en OWASP (Open Web Applicaction Security Project). • Tests de penetración y análisis de vulnerabilidades • Procedimiento que incluye la realización de escaneos, previo a la liberación de servicios y la realización de auditorias en forma periódica en producción. .
Integración (1) §Heterogeneidad y restricciones impuestas por las tecnologías y aplicaciones legadas: –IBM z. Series (390), i. Series (AS/400), aplicaciones legadas 3270 y 5250, CICS (Transaction Server for OS/390), con mecanismos de comunicación previsto como IBM MQSeries, UNIX propietarias, etc. .
Integración (2) § Tecnologías utilizadas (1): – Web Services: • basados en XML (SOAP, WSDL, UDDI) • Conexiones tanto sincrónicas request/reply como asíncronas (no necesariamente J 2 EE) • HTTP como protocolo de transporte – IBM MQSeries: • transporte genérico de mensajes con un API de alto nivel (mensajes y colas). • Se utilizaron para interactuar con aplicaciones en Windows y 390. – EHLL API, HATS, HACL • Son APIs para la comunicación con entornos OS/390. • Comunicación a través de la navegación entre pantallas (contenido de las pantallas es manejado en un array de 24 x 80) • HACL - implementación particular mediante clases Java y las • HATS – herramienta que facilita el desarrollo • Para las aplicaciones legadas orientadas a terminales IBM 3270, se crearon macros, que emulaban la navegación y la entrada de la información requerida. Luego, analizando sintácticamente los resultados, traduciendo códigos de retorno y mensajes en textos, se despliegan los resultados en páginas web. .
Integración (3) § Tecnologías utilizadas (2): – APPC (Advanced Program to Program Communications) y CPI-C (Common Programming Interface - Communications) • Protocolos y APIs para la comunicación de programas entre diferentes equipos en un entorno SNA (IBM Systems Network Architecture). • Interfaces de programación de un relativo bajo para comunicaciones bidireccionales – CICS: • monitor de transacciones difundido en entornos mainframes 390. – CTG (CICS Transaction Gateway) • implementación de un cliente CICS • puede realizar invocaciones a un servidor CICS remoto • Provee APIS para poder invocarlo desde entornos JAVA y. NET. – RSH (remote shell)/SSH (secure shell) • Aplicable para sistemas altamente especializados donde no es posible instalar software adicional y únicamente es posible interactuar con el sistema mediante comandos. • Permiten el loging y la ejecución remota de comandos. Son apropiados para la ejecución batch de scripts. • Se utilizaron en aplicaciones que requerían comunicarse con sistemas de tiempo real y de aprovisionamiento de servicios mediante un encapsulado java en entornos UNIX HP e IBM (AIX p. Series).
Gestión de los proyectos (1) § Basados en PMBOK®, seleccionamos caso a caso los procesos adecuados para lograr los diferentes objetivos. • Se agregan tareas y entregables para la creación del entorno de trabajo (de investigación y adquisición de componentes, de integración, de adaptación de código existente, etc. ). • Pasamos del proceso de adquisición de la herramienta de desarrollo a construir la misma.
Gestión de los proyectos (2) • La adquisición del equipo del proyecto debe contemplar capacidades y habilidades no requeridas en el desarrollo de software propietario: – arquitecto, con la habilidad de investigar y diseñar una arquitectura capaz de integrar ambientes heterogéneo e ínter operar con sistemas ya existentes en sistemas 390, as/400, AIX, Linux y Windows. – expertos en diferentes tecnologías (experto LDAP, experto MQ, experto en CICS, experto en EHLLAP, programadores JAVA con experiencia en componentización, programadores Java Web, etc. ) – Experto en seguridad – Diseñadores Web, que diseñen la comunicación con el usuario final y midan los resultados. – Expertos funcionales, conocimientos tanto de los objetivos del proyecto como del funcionamiento de los sistemas existentes que bebían se integrados para alcanzar dicho objetivo. - . .
Gestión de los proyectos (3) § Dedicación mayor a los procesos de gestión del alcance y gestión de la configuración, debido a las constante actualizaciones y cambios de tendencia provocadas por la comunidad. Es de esperar que los proyectos sufran mas cambios a lo largo del ciclo de vida § Cambios de alcance y/o de configuraciones, deben ser comunicados en forma ágil a los miembros del equipo (estado de arte, versionado, etc. de los componentes de la solución). § Gestión de riesgos: existen riesgos intrínsicos al utilizar tecnologías muchas veces inmaduras que obligan a reformular el objetivo de utilizar total o parcialmente herramientas de software libre. § Riesgo de tiempo de armado del ambiente de desarrollo. § El solo hecho de integrar sistemas muy heterogéneos, que son el corazón mismo de la organización, introduce un alto riesgo debido a la complejidad que esto tiene. .
Resumen estadístico §Más de 120. 000 usuarios en LDAP §Más de 70 aplicaciones Web §Más de 50 aplicaciones que acceden a equipos 390 y AS/400. §Aplicaciones distribuidas en más de 20 servidores heterogéneos.
Conclusiones § Necesidad de interconectar aplicaciones - sistemas 390, as/400 y Unix. - No siempre se puede utilizar Web Services (comúnmente utilizados en. NET y J 2 EE) § Heterogeneidad y restricciones impuestas por tecnologías y aplicaciones legadas. § Complejidades adicionales sobre todo en etapas iniciales: - armado de la solución, - preparación del equipo de trabajo y su ambiente, - complejidad de adaptar e integrar herramientas de desarrollo. - roles y capacidades adicionales (arquitecto investigador, expertos en LDAP, MQ, etc. ) § Impacto en las áreas y procesos de la gestión del proyecto: - gestión del alcance y de la configuración - planes de comunicación - Riesgos intrínsicos a utilizar tecnologías muchas veces inmaduras, en el armado del ambiente de desarrollo, etc.
Preguntas Sergio Machuca smachuca@telematica. com. uy Gabriela Sasco gsasco@telematica. com. uy JAIO – JSL 08/2012 – La Plata, Argentina
- Slides: 17