Los módulos de TIBCO BW son uno de los contenidos más relevantes en tus desarrollos de TIBCO BW. Aprende todos los detalles sobre los diferentes módulos de TIBCO BW disponibles y cuándo usar cada uno de ellos.
TIBCO BW ha evolucionado de varias maneras y se ha adaptado a los últimos cambios de arquitectura. Debido a eso, desde la concepción de la última versión principal, ha introducido varios conceptos que es importante dominar para poder desatar todo el poder que esta notable herramienta te proporciona. Hoy vamos a hablar sobre los módulos.
Cada aplicación de TIBCO BW está compuesta por diferentes módulos que son los componentes que alojan toda la lógica que puedes crear, y eso es lo primero que hay que anotar: Todo tu código y todo lo que haces en tu aplicación pertenecerá a un módulo de TIBCO BW.
Si pensamos en la jerarquía normal de los componentes de TIBCO BW, será algo como la imagen a continuación:
En el nivel superior, tendremos la aplicación; en el segundo nivel, tendremos los módulos, y después de eso, tendremos los paquetes y finalmente, los componentes técnicos como Procesos, Recursos, Clases, Esquemas, Interfaces, etc. Aprende más sobre esto aquí.
Clasificación de Módulos de TIBCO BW
Hay varios tipos de módulos y cada uno de ellos proporciona un caso de uso específico y tiene algunas características asociadas con él.
- Módulo de Aplicación: Es el tipo de módulo más importante porque sin él no puedes tener una aplicación. Es el módulo maestro y solo puede haber uno por aplicación. Es donde residirá toda tu lógica principal para esa aplicación.
- Módulo Compartido: Es el otro único módulo nativo de BW y su propósito principal, como muestra el nombre, es alojar todo el código y componentes que pueden ser compartidos entre varias aplicaciones. Si tienes experiencia con versiones anteriores de TIBCO BW, puedes pensar en este módulo de TIBCO BW como un reemplazo de una Biblioteca de Tiempo de Diseño (también conocida como DTL) o si tienes experiencia con un lenguaje de programación, una biblioteca que se importa al código. Debido a eso, no tiene una restricción en el número de aplicaciones que pueden usar un módulo compartido y no hay limitación en el número de módulos compartidos que una aplicación de TIBCO BW puede tener.
- Módulo OSGI: Este módulo es el que no es nativo de BW y no va a incluir objetos de BW como Procesos, Recursos, etc., y están principalmente concebidos para tener clases Java. Y nuevamente, es más como un módulo auxiliar que también puede ser compartido según sea necesario. Los escenarios habituales para usar este tipo de módulo son definir funciones XPath personalizadas, por ejemplo, o tener código Java compartido entre varias aplicaciones.
Tanto los módulos compartidos como los módulos OSGI pueden definirse como dependencias de Maven y usar el proceso de Maven para publicarlos en un repositorio de Maven y también para ser recuperados de él según la declaración.
Eso proporciona una forma muy eficiente para la distribución y control de versiones de estos componentes compartidos y, al mismo tiempo, ofrece un proceso similar para otros lenguajes de programación como Java, de modo que disminuirá la curva de aprendizaje para ese proceso.
Limitaciones de los Módulos de TIBCO BW
Como ya comentamos, hay algunas limitaciones o características especiales que cada módulo tiene. Debemos ser muy conscientes de ello para ayudarnos a distribuir adecuadamente nuestro código utilizando el tipo correcto de módulos.
Como se comentó, una aplicación solo puede tener un módulo de aplicación de TIBCO BW. Aunque técnicamente es posible tener el mismo módulo de aplicación de BW en más de una aplicación, eso no tiene sentido porque ambas aplicaciones serán las mismas ya que su código principal será el mismo.
Los módulos compartidos de TIBCO BW, por otro lado, no pueden tener componentes de inicio o procesos de activación como parte de su declaración y todos ellos deben residir en el módulo de aplicación de TIBCO BW.
Tanto el módulo de aplicación de TIBCO BW como el módulo compartido de TIBCO BW pueden tener código Java, pero por otro lado, el módulo OSGI puede solo tener código Java y ningún otro recurso de TIBCO BW.
Los módulos compartidos de TIBCO BW pueden exportarse de dos maneras diferentes, como módulos regulares (archivo ZIP con el código fuente) y en formato binario, para ser compartidos entre otros desarrolladores pero no permitiéndoles cambiar o cambiar su vista de los detalles de implementación. Esto todavía se admite por razones de legado, pero la forma recomendada hoy en día para distribuir el software es usando Maven, como se discutió anteriormente.
Casos de Uso de los Módulos de TIBCO BW
Como se comentó, hay diferentes casos de uso para cada uno de los módulos que debido a eso te ayudará a decidir qué componente funciona mejor para cada escenario:
- Los módulos compartidos de TIBCO BW cubren todos los componentes estándar necesarios para todas las aplicaciones. Aquí, el caso de uso principal son los componentes del marco o patrones principales que simplifican el desarrollo y homogeneizan. Esto ayuda a controlar capacidades estándar como manejo de errores, auditoría, registro, o incluso comunicación interna, por lo que los desarrolladores solo necesitan centrarse en la lógica de negocio para su caso de uso.
- Otro caso de uso para el módulo compartido de TIBCO BW encapsula cualquier cosa compartida entre aplicaciones, como recursos, para conectarse a un backend, por lo que todas las aplicaciones que necesitan conectarse a ese backend pueden importar y evitar la necesidad de rehacer esa parte.
- El módulo OSGi es para tener código Java que tiene una relación débil con el código BW, como un componente para realizar una actividad como firmar un documento PDF o integrar con un elemento usando una API nativa de Java para que podamos mantenerlo y evolucionarlo separado del código de TIBCO BW.
- Otro caso para el módulo OSGI es definir las funciones XPath personalizadas que necesitarás como parte de tu módulo compartido o tu módulo de aplicación.
- El módulo de aplicación de TIBCO BW, por otro lado, solo debe tener código que sea específico para el problema de negocio que estamos resolviendo aquí, moviendo todo el código que pueda ser utilizado para más de una aplicación a un módulo compartido.