Capítulo 2. Arquitectura
Este capítulo cubre los aspectos técnicos del diseño de la plataforma de JBoss Enterprise BRMS. No es una lectura obligatoria para los usuarios de la aplicación BRMS. Esta dirigido a los desarrolladores que integran la plataforma JBoss Enterprise BRMS con otros sistemas.
Figura 2.1, “Diagrama arquitectónico” muestra los componentes más importantes del sistema, la manera en que se integran y se implementan.
Figura 2.1. Diagrama arquitectónico
BRMS se implementa como un WAR, el cual proporciona interfaces de usuario a través de la web y paquetes binarios por medio de URLs. Utiliza el estándar JSR-170 para almacenamiento de datos (JCR). JBoss Seam se utiliza como el marco de trabajo del componente y GWT se utiliza como el kit de herramientas para construir la interfaz de usuario web basada en ajax.
2.1. Componentes re-utilizables Copiar enlaceEnlace copiado en el portapapeles!
Copiar enlaceEnlace copiado en el portapapeles!
BRMS usa una interfaz de servicio para separar la interfaz gráfica del usuario de la funcionalidad de segundo plano. En este caso el segundo plano incluye el repositorio de activos así como las especificaciones del compilador para tratar con las reglas.
La interfaz principal es
RepositoryService
, la cual se implementa en ServiceImplementation
. El plano principal ajax GWT le habla a esta interfaz usando el mecanismo de callback asincrónica de GWT. El archivo de configuración Seam es components.xml
.
Esta interfaz de servicio la pueden re-utilizar componentes opcionales o de primer plano.
La interfaz de usuario GWT se puede volver a utilizar ya que GWT es solo una página html:
Guvnor.html
. Para aquellos familiarizados con GWT, cada una de las funcionalidades se puede utilizar por separado. La clase JBRMSFeature
y las clases que la implementan (en teoría pueden ser autónomas) contienen información adicional.
2.2. Versionamiento y almacenamiento Copiar enlaceEnlace copiado en el portapapeles!
Copiar enlaceEnlace copiado en el portapapeles!
En la base de datos se almacenan versiones de activos junto con los datos.
Cuando se crean tomas de pantalla se realizan copias de todo el paquete en un lugar separado en la base de datos JCR.
Para aquellos familiarizados con JCR y jackrabbit, los archivos
.cnd
se encuentran en la fuente para las definiciones de tipo de nodos ya que algunos desean verlas. Un paquete es un folder y cada activo es un archivo: un archivo puede ser textual o puede tener un anexo binario.