ARTÍCULO DE REFLEXIÓN ARQUITECTURAS Y DESARROLLO DE APLICACIONES BASADAS EN EL MODELO DE COMPONENTES Ing. Celio Gil* El modelo de componentes denominado CCM – CORBA Component Model proporciona las bases para el desarrollo de aplicaciones centradas en la lógica de negocio de la empresa. PALABRAS CLAVE INTRODUCCIÓN El presente articulo tiene como objetivo la apropiación y el desarrollo del conocimiento relacionados con el tema de las arquitecturas basadas en componentes, las cuales se soportan en el Modelo CMM. La tecnología orientada a objetos tiene como objetivo lograr desarrollos mucho más rápidos y de fácil mantenimiento. En los últimos años esta finalidad se ha visto enormemente complicada por las arquitecturas distribuidas que pretenden integrar multitud de sistemas heterogéneos. De otra parte, los sistemas basados en componentes convierten la construcción de aplicaciones en un simple establecimiento de relaciones entre componentes, teniendo que implementar únicamente los que proporcionan una lógica de ne- Y DESARROLLO El objetivo de este articulo es ilustrar la importancia del desarrollo basado en componentes, el cual ha cobrando una gran importancia dentro de la industria del software. El desarrollo de software ha tenido grandes avances en materia de metodologías, pasando por el Ciclo básico de desarrollo de sistemas, metodología RUP hasta llegar a componentes. En la actualidad existen diferentes estándares, como J2EE y CORBA, que definen las características de un componente. CORBA es un estándar reconocido a nivel mundial como una solución en los desarrollos heterogéneos que busca la integración de aplicaciones. Arquitectura de Componentes, Arquitecturas distribuidas, Arquitectura multicapa, Ciclo básico de sistemas, Corba, J2EE, Modelo de componentes (CMM), Modelos de Objetos Distribuidos, RUP. ARQUITECTURA RESUMEN Fecha de recepción del artículo: Fecha de aceptación del artículo: * Ingeniero de Sistemas Universidad Distrital, Especialista en Administración de Empresas, Docente Investigador. Universidad Libre. AVANCES Investigación en Ingeniería - 2007 No. 6 161 gocio. Existen varios entornos de componentes tales como los que proporciona Microsoft, los que proporciona Sun Microsystems con su modelo de componentes basado en su plataforma Java y por último, el modelo de la OMG, basado en su plataforma CORBA llamado CCM (CORBA Component Model). OBJETIVOS General Apropiar y desarrollar conocimientos relacionados con el tema de las arquitecturas basadas en componentes, las cuales se soportan en el Modelo CMM, permitiendo de esta manera la consolidación de los fundamentos teóricos/ prácticos, la difusión del trabajo realizado e incentivar la creación de productos de software de calidad. ARQUITECTURA Y DESARROLLO Específicos • Conocer las diferentes arquitecturas basadas en componentes. • Investigar los factores de calidad aplicables a un producto elaborado bajo un esquema de arquitectura de componentes soportado sobre el modelo CMM. • Realizar un análisis comparativo entre las diversas plataformas existentes en el mercado. DESARROLLO TEMATICO Modelo de proceso Un modelo de proceso de software define como solucionar la problemática del desarrollo de sistemas de software. Para desarrollar software se requiere resolver ciertas fases de su proceso, las cuales se conocen en su conjunto como el ciclo de vida1 del desarrollo de software. Las metodologías orientadas a objetos se enfocan principalmente en el modelado de un sistema en términos de objetos. A diferencia de las metodologías estructuradas, se identifican inicialmente los objetos 1 2 162 del sistema para luego especificar su comportamiento, tales como: OOSE (Object Oriented Software Engineering2) Plataforma CORBA de la OMG La OMG (Object Management Group) es la organización que se ha encargado de definir el estándar CORBA. La OMG creo CORBA (Common Object Request Broker Architecture), la segunda versión del estándar, tiene como característica principal el IIOP (Internet Inter-Orb Protocol). El desarrollo de corba, ha generado las siguientes versiones: CORBA 2.2. que introdujo POA (Portable Object Adapter) que tiene como característica principal la especificación portable para los servidores CORBA y además añade flexibilidad en el paso de datos en tiempo de ejecución. La versión CORBA 2.3. incluye OBV (Object By Value) que permite enviar objetos complejos entre procesos CORBA. La última versión del estándar de la OMG es CORBA 3, que incorpora un gran número de funciones de versatibilidad, flexibilidad e interoperatividad, las cuales están catalogadas en tres grandes grupos: Soporte para componentes distribuidos, Soporte para Internet y Control de la calidad de servicio. Ventajas de la plataforma CORBA de la OMG El modelo de componentes CORBA especifica un área de trabajo para la creación de objetos plug – and – play, que ayudará a la integración con otras tecnologías basadas en objetos como Enterprise Java Beans (EJB). Este modelo encapsula la creación, el ciclo de vida y los eventos de los objetos permitiendo a los clientes explorar las características, los métodos y los eventos de cada uno de los objetos. Con ello se reduce la curva de aprendizaje para desarrollar y usar objetos CORBA en servidores y clientes al abstraer al desarrollador de la complejidad interna que conlleva el implementar los mecanismos para que los componentes ofrezcan servicios generales. De esta forma los desarrolladores se centran únicamente en la lógica de negocio consiguiendo un mayor rendimiento en el desarrollo y aumentando la eficiencia y productividad. Scacchi, W., 2006. Process Models in Software Engineering, 2nd Ed., Wiley. Jacobson, C., Rumbaugh, J., Object-Oriented Software Engineering, Addison Wesley. AVANCES Investigación en Ingeniería - 2007 No. 6 La mayor desventaja es que es mucho más compleja que la arquitectura J2EE y el tiempo de aprendizaje es más elevado que el de J2EE. preocupar por codificar servicios del sistema. De la misma forma, un programador cuya especialidad son los servicios del sistema se pueden centrar en el desarrollo de los mismos y no preocuparse por escribir lógica de negocio. Desventajas de J2EE Algunas de las ventajas de J2EE son: J2EE permite a los programadores diseñar y construir sistemas distribuidos de gran escala utilizando los servicios de interconexión en una arquitectura multicapa (Lógica de datos, Lógica de presentación y Persistencia). • Múltiples plataformas • Arquitectura y desarrollo simplificados • Escalabilidad para suplir variaciones de demanda del mercado • Integración con sistemas de información existentes • Tecnología estándar en el mercado • Brinda componentes portables a través de múltiples plataformas. • Alto rendimiento ante peticiones concurrentes. • Promueve el aprovechamiento de los servicios provistos por los servidores de aplicaciones. Por otro lado la confiabilidad supone que un recurso está siempre disponible y que proporciona un rendimiento óptimo cuando es invocado dentro de un sistema integrado en una organización. Esta situación empeora cuando algunos recursos se encuentran fuera del entorno de la red de la empresa y se convierten en servicios suministrados por un tercero. Esto significa que las aplicaciones Java tienen que incluir rutinas adecuadas de gestión de errores. El compilador obliga al desarrollador ya sea a capturar o a lanzar todas las excepciones del caso. Arquitectura multicapa Esta arquitectura presenta tres niveles a saber: • Capa de lógica de datos • Capa de presentación • Capa de persistencia de los datos Ventajas de la arquitectura J2EE multicapa Un beneficio fundamental de utilizar la tecnología de servidor y contenedor de EJB es que ésta tecnología hace un uso adecuado de la experiencia de los programadores. Es decir, que un programador especializado en codificar lógica de negocio no se tiene que CONCLUSIONES La industria del software ha tenido grandres avances en la ultima década y son las arquitecturas de software junto con las metodologías de desarrollo las que mas desarrollo han tenido. La ingeniería del software basada en componentes proporciona unos beneficios inherentes a la calidad del software, aumentando la productividad del desarrollador y reduciendo el costo general del sistema. Las técnicas de análisis y diseño de componentes se basan en los mismos principios y conceptos que forman parte de las buenas prácticas de Ingeniería de Software. Y DESARROLLO En transacciones cortas los recursos se bloquean cuando la transacción termina, lo cual es adecuado para transacciones de duración corta. Sin embargo, puede haber problemas si una transacción tarda horas en terminar y otros componentes del sistema necesitan tener acceso a los diferentes recursos que este utilizando, ocasionando un mayor consumo de recursos. ARQUITECTURA Desventajas de la plataforma CORBA de la OMG La ingeniería de software basada en componentes hace uso de un modelo de intercambio de datos, herramientas, almacenamiento estructurado y un modelo subyacente para construir aplicaciones. El modelo de objetos se ajusta a uno o más estándares de componentes (OMG/CORBA) que definen la forma en que una aplicación puede acceder a los objetos reutilizables. AVANCES Investigación en Ingeniería - 2007 No. 6 163 BIBLIOGRAFIA Alfredo Weitzenfeld, Ingeniería de Software Orientada a Objetos con UML, Java e Internet, Thomson, 2005. Booch, Gr. And Wesley, Adison. Análisis y Diseño Orientado a Objetos con aplicaciones, 2da edición, Massachussets, 1999. Brown, A.W., y K.C. Engineering of Component Based Systems. IEEE Computer Society Press, 1996. pp 7-15. MCConnell, Steve. Desarrollo y Gestión de proyectos informáticos, McGraw Hill Interamericana, España 1999. Pressman, Roger, “Ingeniería del Software un Enfoque Practico”. Tercera edición. Madrid. Mc GRaw Hill. 2005 ARQUITECTURA Y DESARROLLO Somerville, Ian. “Ingeniería de Software”. México. Pearson Educación, 2005. 164 AVANCES Investigación en Ingeniería - 2007 No. 6