El modelo de Componentes está intimamente ligado al modelo OO, y podríamos decir que lo lleva implícito. Desde el punto de vista de la industria, o de la empresa usuaria de software, trabajar con componentes es un objetivo sumamente ventajoso: Es un movimiento hacia la "industrialización" del software, no sólo ya desde el punto de vista de los métodos y procesos, sino desde el punto de vista de la adquisición e integración. Se trata de extender al software ideas que son usuales en otras áreas: "Armar" un sistema conectando partes, elegir esas partes en un catálogo, optando por la más completa o la más económica, por caso, licitar la solución de una parte, postergar un área sin que el resto se vea afectado. Es también principalmente, un movimiento hacia la independencia de las plataformas, procurando que las aplicaciones, la comunicación entre procesos, se puedan lograr sin ser afectado por la heterogeneidad del soporte tecnológico. Con la universalización de la Internet, la necesidad de comunicar procesos, negocios y aplicaciones devino en algo imprescindible: hoy es impensable y no deseable un modelo cerrado. Ya sea por la conveniencia de la empresa, o por las obligaciones de controles estatales o requerimiento de proveedores o clientes, el modelo informático de cualquier empresa más o menos establecida, requiere intercambio directo de información con el "mundo exterior" Así, las aplicaciones internas en mayor o menor medida estan expuestas a terceros y deben importarse también servicios de fuera de la empresa.
Otro aspecto que se encuentra en la base de la idea de Componentes, es la conveniencia de la especialización. Este esquema permite dividir las responsabilidades, permitiendo que nos dediquemos al núcleo que debemos resolver, en el negocio que conocemos, y cediendo a un componente conectado, los servicios o funciones que requieren otro área de conocimientos. Nuestra preocupación se debe limitar a cómo conectarnos, y qué servicios debemos esperar.
Dentro de este marco de objetivos, la tecnología de componentes se desarrolló con tres sistemas: COM (o DCOM), CORBA, y, bajo Java, Enterprise Java Beans. Con el avance de Internet en todos los frentes, aparece hoy el esquema de Web Services, como una nueva forma de expresar estos objetivos generales. La especificación de servicios Web se orienta a publicar o utilizar servicios específicos tomados de la red pública, y a utilizar un formato de datos, el XML, capaz de intercambiarse sin inconvenientes en un entorno heterogéneo.
Los ActiveX en COM y las Java Beans en Java son la expresión más popular de este modelo. Ambas han sido usadas ampliamente en Plex, y aquí trataremos de presentar algunos ejemplos.
En ambos casos, el soporte de Plex está limitado a componentes GUI, asociados a paneles, interactuando por medio de VBScript o JavaScript.
La creación e importación de componentes basados en COM, fue largamente prometido, y está comenzando a implementarse cuando la propia tecnología está experimentando sus primeras observaciones críticas.
No obstante, sigue habiendo límites; para ser precisos, ahora es posible Importar un componente; pero sólo parcialmente es posible hablar de creación de componentes, si acudimos al uso de OLE Automation.
Y cuando hablamos de Importar componentes, es necesario advertir que se requiere una licencia separada para hacer uso de esa facilidad.
Decimos que el soporte de componentes tipo ActiveX se limita a los ligados a la interfase visual, requiriendo que la función tenga un panel. Sería posible recurrir a componentes servidor, pero eso requiere una de dos opciones difíciles: o la licencia separada para importar el componente al modelo, o ejecutar source code C++.
La creación de Servicios Web está disponible hoy con la extensión de Websydian, y está en curso de incorporación a través de la generación para .NET
Si usted necesita sistematizar su información, recurra al capítulo 13 de la Guía de usuario, donde encontrará el soporte básico disponible al nivel actual de explotación de Plex.
En primer lugar, una breve reseña de los ya empleados en los patterns de Plex, en la librería Active. Están diseñados, como el resto de los patterns en un nivel básico, y en algunos casos, luego estan combinados mas de uno para lograr otro pattern. Qué ventaja presentan éstos: 1, están preelaborados, y tienen una mínima guía de ayuda para su implementación. 2, en general (hay alguna excepción) no tienen costo adicional sobre el propio de Plex.
Hay otros, aunque estos son los que más frecuentemente uso. Revise rutinariamente el breve catálogo disponible en Plex, para recordarlos cada vez que sea necesario. A continuación, iremos incluyendo, como una sección abierta, otros que podrían incluírse, que usé, o testeé, o fueron usados por otros colegas en otras partes.