Presentacion1_v2
Buenos días a todos, mi nombre es Oscar Eduardo Cala, Estudiante de la Maestría en Ingeniería de Sistemas y Computación, el tema seleccionado para el establecimiento del estado del arte corresponde a las arquitecturas de software utilizadas en los sistemas de laboratorios remotos utilizados para la enseñanza de ingeniería de control.
Para la mayoría de nosotros es conocido que una arquitectura de software define y comprende los componentes, estructuras, servicios y tecnologías que se utilizan para la creación de un sistema. Define las relaciones que existen entre las diferentes entidades y componentes del sistema y por lo tanto permite comprender su funcionamiento.
Sin embargo no siempre las arquitecturas se definen de una manera usable, en ocasiones resultan bastante abstractas, bastante generales, y resulta difícil tomar decisiones correctas acerca de la implementación concreta de la arquitectura.
Adicionalmente el proceso de instanciación e implementación de la arquitectura debe realizarse bajo un conjunto de restricciones que generalmente impiden que el resultado final de la implementación sea una fiel a las características planteadas por la arquitectura general.
Suelen existir restricciones en cuanto al personal que puede ejecutar el proyecto, generalmente por temas presupuestales.
Suelen existir requerimientos de tiempo que implican el uso de tecnologías no apropiadas
Deben cumplirse los requerimientos técnicos que la infraestructura imponga.
En un caso ideal, la implementación debería ser lo mas fiel posible a su definición por lo tanto deberían poderse encontrar implementaciones como las de la figura donde se explota la interoperabilidad de la arquitectura. El cliente se implementa utilizando HTML5, el primer servidor utiliza IIS para aceptar conexiones, y los servidores de experimentación pueden utilizar tecnologías y plataformas diferentes. Los experimentos son variados y pueden abarcar temáticas relacionadas con varios dominios de conocimiento.
Sin embargo la implementación de las arquitecturas generales no resultan siendo fieles a la definición lo que resulta en sistemas que pierden las propiedades ya definidas por la arquitectura. En la arquitectura mostrada en la figura, el servidor se utiliza como un túnel entre el cliente y el servidor de experimentación. El uso de VPN genera riesgos de seguridad al exponer la a red remota la red local. Requiere el uso de puertos que normalmente están cerrados por firewalls, requiere el uso de programas que podrían no estar permitidos para la sesión actual del usuario.
En este ejemplo se ha unido el servidor central con el servidor de experimentación. Requiere la conexión de tarjetas de adquisición de datos en el servidor lo que es peligroso, y poco recomendable. La solución depende de que muchos componentes estén funcionando en el mismo servidor. EL hardware queda expuesto a internet al estar conectado a un servidor expuesto.
En este ejemplo se muestra un proyecto que difícilmente puede escalar, utiliza software especifico que acopla de manera fuerte varias de las piezas de software. Corresponden a montajes experimentales que no deberían ser utilizados para producción.
Se encuentran en la literatura un gran número de implementaciones de Laboratorios remotos. El conjunto de todas estas soluciones se caracteriza por la falta de reusabilidad de los componentes, la falta de escalabilidad de las soluciones y la falta de modularidad. Son pocas las soluciones que son cercanas a ser completas pero dichas soluciones no son abiertas ni accesibles.
El problema no son las arquitecturas, pues existen propuestas muy buenas. Por ejemplo en esta arquitectura los usuarios dentro y fuera del campus pueden acceder a los servidores de experimentación los cuales controlan los dispositivos de hardware y los dispositivos de transmisión de audio y video. Pueden agregarse cuantos servidores sean necesarios. Adicionalmente existe la posibilidad de usar servicios web para complementar las capacidades del sistema.
En esta propuesta los servidores de experimentación se implementan utilizando maquinas virtuales, de manera que las maquinas virtuales pueden ser encendidas o apagadas, movidas entre sistemas de hosting. Todo controlado por el arbitrator quien es el capaz controlar el acceso a los usuarios.
Esta arquitectura es presentada de una manera muy conveniente porque permite identificar los usuarios locales y remotos respecto a la LAN, se identifican las diferentes redes de conexión de dispositivos, y se identifica la capa de midleware.
El problema entonces es causado entonces porque las implementaciones no obedecen formalmente a las arquitecturas. Aun cuando las arquitecturas definen una cantidad de componentes y funcionalidad que debe siempre mantenerse, lo que realmente se implementa resulta siendo un subconjunto de funcionalidades ya no relacionada con la arquitectura.
Un caso critico resulta siendo la arquitectura de sotfware de los sistemas que utilizan la tecnologia J2EE. J2EE define un buen número de componentes de software y plataformas que generalmente se definen de manera abstracta utilizando Interfaces Avanzadas de Programación. Estas interfaces luego son implementadas por los servidores de aplicación y luego son re-implementadas y usadas por los desarrolladores. Todo esto muestra un gran proceso de abstracción.
Aun cuando los niveles de abstracción de la definición son bastante altos, la existencia de un gran número de herramientas tecnológicas disponibles en cada capa de la arquitectura, hace posible la implementación de la arquitectura manteniendo su estructura intacta.
Buenos días a todos, mi nombre es Oscar Eduardo Cala, Estudiante de la Maestría en Ingeniería de Sistemas y Computación, el tema seleccionado para el establecimiento del estado del arte corresponde a las arquitecturas de software utilizadas en los sistemas de laboratorios remotos utilizados para la enseñanza de ingeniería de control.
Para la mayoría de nosotros es conocido que una arquitectura de software define y comprende los componentes, estructuras, servicios y tecnologías que se utilizan para la creación de un sistema. Define las relaciones que existen entre las diferentes entidades y componentes del sistema y por lo tanto permite comprender su funcionamiento.
Sin embargo no siempre las arquitecturas se definen de una manera usable, en ocasiones resultan bastante abstractas, bastante generales, y resulta difícil tomar decisiones correctas acerca de la implementación concreta de la arquitectura.
Adicionalmente el proceso de instanciación e implementación de la arquitectura debe realizarse bajo un conjunto de restricciones que generalmente impiden que el resultado final de la implementación sea una fiel a las características planteadas por la arquitectura general.
Suelen existir restricciones en cuanto al personal que puede ejecutar el proyecto, generalmente por temas presupuestales.Suelen existir requerimientos de tiempo que implican el uso de tecnologías no apropiadasDeben cumplirse los requerimientos técnicos que la infraestructura imponga.
En un caso ideal, la implementación debería ser lo mas fiel posible a su definición por lo tanto deberían poderse encontrar implementaciones como las de la figura donde se explota la interoperabilidad de la arquitectura. El cliente se implementa utilizando HTML5, el primer servidor utiliza IIS para aceptar conexiones, y los servidores de experimentación pueden utilizar tecnologías y plataformas diferentes. Los experimentos son variados y pueden abarcar temáticas relacionadas con varios dominios de conocimiento.
Sin embargo la implementación de las arquitecturas generales no resultan siendo fieles a la definición lo que resulta en sistemas que pierden las propiedades ya definidas por la arquitectura. En la arquitectura mostrada en la figura, el servidor se utiliza como un túnel entre el cliente y el servidor de experimentación. El uso de VPN genera riesgos de seguridad al exponer la a red remota la red local. Requiere el uso de puertos que normalmente están cerrados por firewalls, requiere el uso de programas que podrían no estar permitidos para la sesión actual del usuario.
En este ejemplo se ha unido el servidor central con el servidor de experimentación. Requiere la conexión de tarjetas de adquisición de datos en el servidor lo que es peligroso, y poco recomendable. La solución depende de que muchos componentes estén funcionando en el mismo servidor. EL hardware queda expuesto a internet al estar conectado a un servidor expuesto.
En este ejemplo se muestra un proyecto que difícilmente puede escalar, utiliza software especifico que acopla de manera fuerte varias de las piezas de software. Corresponden a montajes experimentales que no deberían ser utilizados para producción.
Se encuentran en la literatura un gran número de implementaciones de Laboratorios remotos. El conjunto de todas estas soluciones se caracteriza por la falta de reusabilidad de los componentes, la falta de escalabilidad de las soluciones y la falta de modularidad. Son pocas las soluciones que son cercanas a ser completas pero dichas soluciones no son abiertas ni accesibles.
El problema no son las arquitecturas, pues existen propuestas muy buenas. Por ejemplo en esta arquitectura los usuarios dentro y fuera del campus pueden acceder a los servidores de experimentación los cuales controlan los dispositivos de hardware y los dispositivos de transmisión de audio y video. Pueden agregarse cuantos servidores sean necesarios. Adicionalmente existe la posibilidad de usar servicios web para complementar las capacidades del sistema.
En esta propuesta los servidores de experimentación se implementan utilizando maquinas virtuales, de manera que las maquinas virtuales pueden ser encendidas o apagadas, movidas entre sistemas de hosting. Todo controlado por el arbitrator quien es el capaz controlar el acceso a los usuarios.
Esta arquitectura es presentada de una manera muy conveniente porque permite identificar los usuarios locales y remotos respecto a la LAN, se identifican las diferentes redes de conexión de dispositivos, y se identifica la capa de midleware.
El problema entonces es causado entonces porque las implementaciones no obedecen formalmente a las arquitecturas. Aun cuando las arquitecturas definen una cantidad de componentes y funcionalidad que debe siempre mantenerse, lo que realmente se implementa resulta siendo un subconjunto de funcionalidades ya no relacionada con la arquitectura.
Un caso critico resulta siendo la arquitectura de sotfware de los sistemas que utilizan la tecnologia J2EE. J2EE define un buen numero de componentes de software y plataformas que generalmente se definen de manera abstracta utilizando Interfaces Avanzadas de Programación. Estas interfaces luego son implementadas por los servidores de aplicación y luego son re-implementadas y usadas por los desarrolladores. Todo esto muestra un gran proceso de abstracción.
Aun cuando los niveles de abstracción de la definición son bastante altos, la existencia de un gran número de herramientas tecnológicas disponibles en cada capa de la arquitectura, hace posible la implementación de la arquitectura manteniendo su estructura intacta.