Desarrollo basado en componentes
Oportunidades y problemas a resolver
El desarrollo basado en componentes o CBD (Component Based Development) está revolucionando el sector del software. A diferencia de otras tendencias, como el desarrollo orientado a objetos, en este caso no se trata sólo de una nueva variante del proceso distribuido, sino de una arquitectura extensible para soportar una representación o “metáfora” de proceso de ciclo completo, incluyendo el diseño, el desarrollo y el despliegue.
A causa de sus altos niveles de reutilización e interoperabilidad, el desarrollo CBD ejercerá influencia sobre todas las dimensiones y aspectos de la composición de aplicaciones, incluyendo todos los tipos de clientes, servidores de aplicación y servidores de base de datos, y ejercerá también un impacto profundo sobre todos los aspectos del desarrollo de aplicaciones.
El predecesor del desarrollo CBD fue el desarrollo orientado a objetos (OO). Los objetos fueron el primer elemento en ofrecer altos niveles de reutilización en el sector. Sin embargo, la falta de sofisticación de los entornos de desarrollo OO y la ausencia de una infraestructura común para permitir la interoperabilidad de los objetos impidió su adopción generalizada. El desarrollo OO iba demasiado por delante de su tiempo y carecía de apoyo estructural por parte del sector del software.
En el desarrollo CBD se redefinen objetos dentro del contexto de una infraestructura estandarizada para interoperabilidad, marcos o “frameworks” para la construcción y ensamblaje de aplicaciones, y componentes pre-construidos que se adscriben a infraestructuras y frameworks de componentes. La dimensión infraestructural de la arquitectura de componentes es el catalizador que permite la reutilización e interoperabilidad, cuya ausencia fue un obstáculo para el desarrollo de la orientación a objetos. Esta infraestructura, junto con la disponibilidad de frameworks CBD que permiten el diseño, construcción y ensamblaje de componentes (en lugar de ser simplemente un entorno para programación visual), cambiará para siempre la forma en que se desarrollan aplicaciones.
Tres etapas del desarrollo CBD
La primera etapa del desarrollo CBD es la era de los componentes monolíticos, una aparente contradicción que describe el estado adolescente en que se encuentran los componentes. Ninguno de los estándares de componentes y frameworks actuales han resuelto los problemas de portabilidad e interoperabilidad que permitirían que los componentes fueran distribuidos o persistieran en múltiples frameworks de vendedores. Aunque se están estableciendo estándares para CBD, no existen componentes estructurales estandarizados y, en consecuencia, se están introduciendo frameworks con un alto contenido de componentes estructurales propietarios.
En la etapa siguiente, los componentes monolíticos ceden el paso a componentes distribuidos, al permitir los estándares de componentes de mayor madurez y los nuevos componentes estructurales la interoperabilidad y portabilidad de componentes. Los frameworks, liberados ahora de tareas estructurales específicas, se concentran más en el modelo o paradigma de desarrollo y soportan más aspectos del ciclo de vida de los componentes. La mayor variedad y riqueza de los estándares y frameworks de componentes permite componentes más granulares, y son cada vez más los vendedores que ofrecen bibliotecas de componentes. En esta etapa, el ámbito del desarrollo CBD se amplía para incluir también el diseño de componentes. El diseño basado en componentes hace que el modelo CBD cambie de construcción física a diseño lógico. Por otra parte, la mayor granularidad de los componentes, el hecho de que estén disponibles en una amplia variedad, y la inclusión de meta-datos de diseño en los componentes propiamente dichos, mejora el desarrollo CBD y lo convalida como paradigma de desarrollo de aplicaciones.
La etapa de persistencia de componentes tiene lugar cuando prácticamente toda la infraestructura asociada al proceso CBD se convierte en un producto de uso corriente o “commodity”. Esta “commoditización” hace que aumente el número de proveedores de servicios, que ofrecen muchos tipos de componentes que pueden ser adaptados fácilmente de acuerdo con reglas comerciales. En esta etapa, la mayoría de los componentes son objeto de reutilización, alquiler o compra por los consumidores. El diseño de componentes es el punto crucial de las actividades CBD para quienes fabrican componentes. Las cuestiones relativas a herramientas (cobertura del ciclo de vida, paradigma de desarrollo, metáfora de utilización y disponibilidad de componentes pre-construidos) se convierten en factores clave de diferenciación competitiva.
Ahora, la calidad de la aplicación -medible por primera vez- se convierte en un factor competitivo. Los frameworks continúan siendo el punto crucial para hacer posible el desarrollo de aplicaciones, dado el control que ejercen sobre el paradigma de desarrollo. La antigua funcionalidad “desciende”, y puede incluso llegar a formar parte del sistema operativo, mientras que la nueva funcionalidad es dividida en funcionalidad de procesos, que reside en los frameworks, y funcionalidad específica de dominio (junto con el contenido de dominio, que está integrada en bibliotecas de componentes). La fase de componentes persistentes se caracteriza por una interoperabilidad entre vendedores, sin requerir relaciones tecnológicas bilaterales específicas.
Este modelo de proceso distribuido, que descansa en una relación de sinergia entre estándares de componentes, infraestructura y frameworks, actúa con la máxima eficiencia cuando los vendedores colaboran en las dimensiones estructurales básicas del desarrollo CBD. Cuanta mayor sea la rapidez con que tiene lugar esta colaboración, con mayor rapidez adquirirá CBD la madurez necesaria. Esta colaboración implica un acuerdo sobre interfaces API, lenguajes básicos, y las diversas clases de fundamentos y definiciones de meta-datos específicas de dominio. Una vez que se llega a un acuerdo sobre la infraestructura, la competencia puede girar en torno a factores como las funciones y características, la calidad y el costo de utilización. Esta evolución a una infraestructura basada en estándares se está acelerando, al adquirir madurez las actitudes de los vendedores sobre la base a utilizar para la competencia en el mercado.
Las reglas para elegir un framework CBD
---------------------------------------------------------
La infraestructura para CBD está evolucionando, y los compradores deberán buscar frameworks con arquitecturas flexibles, que ofrezcan la máxima funcionalidad y un soporte amplio y generalizado para la infraestructura CBD. Deberán elegirse frameworks que:
1.- Estén construidos para ofrecer capacidad de arquitecturas abiertas. Las herramientas basadas en arquitecturas propietarias tienen una capacidad limitada de utilizar frameworks de componentes y la variedad de componentes y servicios estandarizados que se mantienen en evolución. No hay que confundir el paradigma de desarrollo de una herramienta - que por definición es propietario - con su arquitectura. Hay que encontrar herramientas que generen componentes estandarizados y los ensamblen formando aplicaciones que utilicen servicios estandarizados asociados a CBD.
2.- Soportar múltiples estándares de componentes. Cada estándar de componente tiene sus propios atributos. Deberán conseguirse herramientas que sop
A causa de sus altos niveles de reutilización e interoperabilidad, el desarrollo CBD ejercerá influencia sobre todas las dimensiones y aspectos de la composición de aplicaciones, incluyendo todos los tipos de clientes, servidores de aplicación y servidores de base de datos, y ejercerá también un impacto profundo sobre todos los aspectos del desarrollo de aplicaciones.
El predecesor del desarrollo CBD fue el desarrollo orientado a objetos (OO). Los objetos fueron el primer elemento en ofrecer altos niveles de reutilización en el sector. Sin embargo, la falta de sofisticación de los entornos de desarrollo OO y la ausencia de una infraestructura común para permitir la interoperabilidad de los objetos impidió su adopción generalizada. El desarrollo OO iba demasiado por delante de su tiempo y carecía de apoyo estructural por parte del sector del software.
En el desarrollo CBD se redefinen objetos dentro del contexto de una infraestructura estandarizada para interoperabilidad, marcos o “frameworks” para la construcción y ensamblaje de aplicaciones, y componentes pre-construidos que se adscriben a infraestructuras y frameworks de componentes. La dimensión infraestructural de la arquitectura de componentes es el catalizador que permite la reutilización e interoperabilidad, cuya ausencia fue un obstáculo para el desarrollo de la orientación a objetos. Esta infraestructura, junto con la disponibilidad de frameworks CBD que permiten el diseño, construcción y ensamblaje de componentes (en lugar de ser simplemente un entorno para programación visual), cambiará para siempre la forma en que se desarrollan aplicaciones.
Tres etapas del desarrollo CBD
La primera etapa del desarrollo CBD es la era de los componentes monolíticos, una aparente contradicción que describe el estado adolescente en que se encuentran los componentes. Ninguno de los estándares de componentes y frameworks actuales han resuelto los problemas de portabilidad e interoperabilidad que permitirían que los componentes fueran distribuidos o persistieran en múltiples frameworks de vendedores. Aunque se están estableciendo estándares para CBD, no existen componentes estructurales estandarizados y, en consecuencia, se están introduciendo frameworks con un alto contenido de componentes estructurales propietarios.
En la etapa siguiente, los componentes monolíticos ceden el paso a componentes distribuidos, al permitir los estándares de componentes de mayor madurez y los nuevos componentes estructurales la interoperabilidad y portabilidad de componentes. Los frameworks, liberados ahora de tareas estructurales específicas, se concentran más en el modelo o paradigma de desarrollo y soportan más aspectos del ciclo de vida de los componentes. La mayor variedad y riqueza de los estándares y frameworks de componentes permite componentes más granulares, y son cada vez más los vendedores que ofrecen bibliotecas de componentes. En esta etapa, el ámbito del desarrollo CBD se amplía para incluir también el diseño de componentes. El diseño basado en componentes hace que el modelo CBD cambie de construcción física a diseño lógico. Por otra parte, la mayor granularidad de los componentes, el hecho de que estén disponibles en una amplia variedad, y la inclusión de meta-datos de diseño en los componentes propiamente dichos, mejora el desarrollo CBD y lo convalida como paradigma de desarrollo de aplicaciones.
La etapa de persistencia de componentes tiene lugar cuando prácticamente toda la infraestructura asociada al proceso CBD se convierte en un producto de uso corriente o “commodity”. Esta “commoditización” hace que aumente el número de proveedores de servicios, que ofrecen muchos tipos de componentes que pueden ser adaptados fácilmente de acuerdo con reglas comerciales. En esta etapa, la mayoría de los componentes son objeto de reutilización, alquiler o compra por los consumidores. El diseño de componentes es el punto crucial de las actividades CBD para quienes fabrican componentes. Las cuestiones relativas a herramientas (cobertura del ciclo de vida, paradigma de desarrollo, metáfora de utilización y disponibilidad de componentes pre-construidos) se convierten en factores clave de diferenciación competitiva.
Ahora, la calidad de la aplicación -medible por primera vez- se convierte en un factor competitivo. Los frameworks continúan siendo el punto crucial para hacer posible el desarrollo de aplicaciones, dado el control que ejercen sobre el paradigma de desarrollo. La antigua funcionalidad “desciende”, y puede incluso llegar a formar parte del sistema operativo, mientras que la nueva funcionalidad es dividida en funcionalidad de procesos, que reside en los frameworks, y funcionalidad específica de dominio (junto con el contenido de dominio, que está integrada en bibliotecas de componentes). La fase de componentes persistentes se caracteriza por una interoperabilidad entre vendedores, sin requerir relaciones tecnológicas bilaterales específicas.
Este modelo de proceso distribuido, que descansa en una relación de sinergia entre estándares de componentes, infraestructura y frameworks, actúa con la máxima eficiencia cuando los vendedores colaboran en las dimensiones estructurales básicas del desarrollo CBD. Cuanta mayor sea la rapidez con que tiene lugar esta colaboración, con mayor rapidez adquirirá CBD la madurez necesaria. Esta colaboración implica un acuerdo sobre interfaces API, lenguajes básicos, y las diversas clases de fundamentos y definiciones de meta-datos específicas de dominio. Una vez que se llega a un acuerdo sobre la infraestructura, la competencia puede girar en torno a factores como las funciones y características, la calidad y el costo de utilización. Esta evolución a una infraestructura basada en estándares se está acelerando, al adquirir madurez las actitudes de los vendedores sobre la base a utilizar para la competencia en el mercado.
Las reglas para elegir un framework CBD
---------------------------------------------------------
La infraestructura para CBD está evolucionando, y los compradores deberán buscar frameworks con arquitecturas flexibles, que ofrezcan la máxima funcionalidad y un soporte amplio y generalizado para la infraestructura CBD. Deberán elegirse frameworks que:
1.- Estén construidos para ofrecer capacidad de arquitecturas abiertas. Las herramientas basadas en arquitecturas propietarias tienen una capacidad limitada de utilizar frameworks de componentes y la variedad de componentes y servicios estandarizados que se mantienen en evolución. No hay que confundir el paradigma de desarrollo de una herramienta - que por definición es propietario - con su arquitectura. Hay que encontrar herramientas que generen componentes estandarizados y los ensamblen formando aplicaciones que utilicen servicios estandarizados asociados a CBD.
2.- Soportar múltiples estándares de componentes. Cada estándar de componente tiene sus propios atributos. Deberán conseguirse herramientas que sop
