Modelo de aplicación (Avalanche: marco de aplicación para Java)

"Avalanche - framework de aplicaciones para Java" - implementación de la tecnología de diferencias borrosas
entre llamadas a código local y remoto. Tolerancia a fallos, escalabilidad,
modificabilidad, disponibilidad continua vienen con bonificaciones bonitas.

El modelo de aplicación considerado en este artículo nació sobre la base de nuestra propia experiencia en la implementación y operación de diversas interacciones de integración de sistemas de información (SI) y tenía como objetivo principal reducir el uso de diversos recursos (financieros, laborales, de tiempo, etc.) en la implementación de estas soluciones de integración.

La mayoría de las empresas operan muchos sistemas diferentes que automatizan procesos individuales o el trabajo de unidades o departamentos estructurales individuales. Como resultado, existe la necesidad de organizar el intercambio de información entre estos sistemas o con los sistemas de información de organizaciones relacionadas con el fin de reducir los costos operativos, eliminar la introducción de datos duplicados y la inconsistencia de datos en varios sistemas (por ejemplo, NSI), reducir la influencia del factor humano y reducir el tiempo dedicado al intercambio de información.

La necesidad de integración surge no solo en software especial de desarrollo propio o personalizado, sino también en soluciones "en caja". El costo de ventas puede exceder la reducción esperada en los costos operativos.

Formas existentes para abordar la integración de los sistemas de TI:

• Compartir archivos
• Mensajería (un tipo de intercambio de archivos)
• Integración a nivel de modelo de datos, por ejemplo, creando objetos especiales de base de datos o procedimientos almacenados
• Utilizando tecnologías RCP (procedimiento de llamada remota), por ejemplo, CORBA, RMI, SOAP, DCOM, etc.

Todos estos métodos de implementación de soluciones de integración tienen los mismos inconvenientes: la complejidad de la implementación y la modificación, la baja repetibilidad, la necesidad de resolver problemas de tolerancia a fallas, la incapacidad de trabajar en un modo de múltiples versiones durante la instalación de cambios, la complejidad de la operación y el mantenimiento de la documentación operativa actualizada.

Como resultado de la búsqueda de una alternativa a las soluciones existentes, la idea se formuló para convertir el modelo MVC (MODELO - VER - CONTROLADOR) al modelo MVFA (MODELO - VER - FUNCIÓN - APLICACIÓN), dividiendo el CONTROLADOR en dos capas de programa FUNCIÓN y APLICACIÓN entre las cuales se puede colocar una red de transmisión de datos (SPD )



La división en funciones dentro del controlador está presente en un grado u otro en todos los sistemas de TI modernos, especialmente si el desarrollo se realiza utilizando lenguajes de programación orientados a objetos. Y la separación de estas funciones en una capa de software separada resuelve el problema de su reutilización por otros sistemas de TI.

La separación de objetos de "aplicación" en una capa de programa separada estandariza la llamada no solo a sus propias funciones, sino también a las funciones de otros sistemas, lo que borra todas las diferencias en las llamadas de las funciones "propias" y "ajenas".

Para implementar el modelo MVFA, se propone el siguiente modelo de software:

1. Función (Función), cualquier objeto que tenga métodos para implementar cualquier funcionalidad;
2. Un adaptador, un objeto declarado que no tiene una implementación. Este objeto proporciona la conexión de los objetos de "aplicación" con funciones locales o remotas. Para acceder a las funciones remotas, se utiliza el objeto "interfaz";
3. Connector (Connector), proporciona acceso a las funciones locales de objetos remotos utilizando objetos de "publicación";
4. Publicación (Publicar), publica una función local en el conector;
5. Interfaz (Interface), proporciona acceso a adaptadores para funciones remotas;
6. Aplicación (Aplicación), realiza la conversión de datos entre la presentación y la función / funciones, también puede actuar como una "función" para otros objetos de la "aplicación".

Un par de "interfaz" - "conector" forman un canal de datos a través de un protocolo entre diferentes sistemas o diferentes nodos del mismo sistema. Un canal implementado debe tener la capacidad de pasar las cantidades requeridas de datos.

Existen implementaciones especializadas de "interfaces" que no tienen elementos "conectores" emparejados, por ejemplo, una interfaz de alta disponibilidad que le permite crear sistemas de información tolerantes a fallas. El objetivo principal de la interfaz de alta disponibilidad es redirigir la carga a nodos duplicados cuando se planifica o se realiza el apagado planificado de uno de los nodos del sistema.

El modelo MVFA considerado se implementa en Avalanche: marco de aplicación para el producto de software Java, que pertenece a la categoría de software intermedio y está diseñado para crear grupos de software o sistemas de información de alta disponibilidad con tolerancia a fallas.

Por supuesto, como cualquier tecnología, Avalanche - framework de aplicaciones para Java tiene algunas limitaciones:

1. Todos los objetos (tipos) declarados en los adaptadores (parámetros de entrada y retorno) se pueden transmitir a través de la red y, por lo tanto, estos objetos deben implementar la interfaz java.lang.Serializable . Los objetos locales se llaman directamente, sin usar operaciones de lectura y escritura en la secuencia.
2. No todos los objetos se pueden transferir a través de la red. Por ejemplo, los objetos cuyo estado o rendimiento dependen de la configuración del nodo del sistema donde se crearon. Dichos objetos incluyen objetos que implementan la especificación javax.sql.DataSource.
3. Los nodos de sistema duplicados deben ubicarse en hardware diferente.
4. Los nodos del sistema duplicados no deben apagarse (repararse) al mismo tiempo.

En el artículo se describe un ejemplo de una aplicación simple: Primera aplicación (Avalanche: marco de aplicación para Java)