Mediador de objetos de negocio

El Mediador de objetos de negocio (BOM) realiza transformaciones bidireccionales entre los objetos de datos de servicio físicos (SDO) y los SDO lógicos. Con este rol proporciona una interfaz de persistencia del objeto de negocio para la capa de servicios de datos. El BOM da soporte a operaciones de creación, lectura, actualización y supresión en los SDO lógicos para que la capa de lógica de negocio pueda trabajar con ellos en vez de con el esquema físico.

En HCL Commerce Versión 6, antes de Feature Pack 3, la lógica de negocio trata directamente con Enterprise Java™ Beans (EJB). Aunque es relativamente fácil manipular esos beans, el inconveniente es que dichos beans constituyen una correlación directa con el esquema físico y eso complica la ampliación y la personalización. La utilización directa de los EJB también vincula la lógica empresarial a la tecnología de persistencia. Como Commerce WebSphere® se orienta hacia la SOA y sigue ampliando su soporte de clientes de servicios web, se ha definido un modelo lógico de SDO para que la lógica de negocio lo utilice. Los objetos de este modelo lógico, los SDO lógicos, son el mecanismo de intercambio de datos para la interacción entre componentes y para las interacciones de servicios web.

Existe también un conjunto de objetos de datos de servicio utilizados por la capa de persistencia y llamados SDO físicos. Los SDO físicos son objetos Java™ que representan el esquema físico. El Mediador de objetos de negocio permite la correlación entre los SDO lógicos y sus equivalentes en la capa de persistencia, los SDO físicos.

Como parte del proceso de transformación, el BOM utiliza los servicios del Contenedor de datos físicos para recuperar y guardar los datos físicos. El Contenedor de datos físicos gestiona el trabajo real de interacción con el esquema físico. El Contenedor de datos físicos gestiona los SDO físicos – puede crearlos, almacenar matrices de los mismos y guardarlos en la base de datos.

Como puede verse en el diagrama de arriba, hay dos formas de crear datos persistentes a través de la capa de servicios de datos. El sistema más habitual es llamar al BOM para que transforme los SDO lógicos en SDO físicos. Sin embargo, a veces, los mandatos de lógica de negocio necesitan trabajar directamente con objetos físicos porque no están correlacionados con el modelo lógico. Por ejemplo, las tablas que se utilizan para conservar estadísticas o registros de auditoría. En tales casos, la capa de lógica de negocio puede utilizar el Contenedor de datos físicos para leer y grabar datos directamente en la base de datos.

Mediadores de lectura y de cambio

La Capa de servicios de datos inicializa el BOM. Son clases que realizan transformaciones entre representaciones lógicas y físicas del modelo de dominio. Esto permite a la capa de lógica de negocio tratar únicamente con la representación lógica de los datos. Cada módulo de servicio, proporciona su propia implementación a los mediadores.

Cada módulo de servicio proporciona sus propios mediadores que pueden ser de dos tipos: Mediadores de lectura y de cambio. Están listados en el archivo de configuración del Mediador de objetos de negocio. Los mediadores de lectura se utilizan para procesar las peticiones de obtención (Get) de OAGIS. Los mediadores de Cambio gestionan peticiones de sincronización, proceso y cambio de OAGIS.

Para operaciones de lectura, la fachada de la capa de servicios de datos recibe una consulta de la capa de lógica de negocio. La consulta está formada por una expresión XPath y un perfil de acceso que se extraen del verbo GET de OAGIS. La capa de servicios de datos envía la consulta al mediador de objetos de negocio (BOM) que, a su vez, la pasa al servicio de persistencia. Dicho servicio busca la plantilla de SQL correcta para la consulta y la utiliza para generar una o más sentencias SQL. Después, ejecuta esas sentencias y transforma sus conjuntos de resultados en SDO físicos. La correlación entre el esquema de base de datos (tablas y columnas) y las clases de SDO, se define mediante un XML llamado Metadatos relacionales de objeto. Por último, los SDO físicos se devuelven al BOM. La configuración del BOM describe cómo crear una instancia con los mediadores necesarios, que se devuelven a la capa de lógica de negocio.

Nota: el mediador también se devuelve, no únicamente el SDO. El mediador contiene los datos de los SDO físicos. Contiene también la lógica para convertir el SDO físico en el SDO lógico (que es la representación Java™ de un nombre OAGIS).

Para las operaciones de cambio (crear, actualizar, eliminar), la fachada de la capa de servicios de datos recibe los nombres de OAGIS como entrada y los pasa al servicio de mediación de objetos de negocio. Este servicio crea una instancia de los mediadores de cambio apropiados. A su vez, éstos recuperan la representación física de los nombres de un servicio llamado servicio de mediación de objetos físicos. El BOM devuelve después los mediadores a la capa de lógica de negocio. A continuación, se llama a los mediadores con acciones específicas para crear, actualizar o eliminar nombres y partes de nombres. La lógica de dentro de los mediadores convierte esas acciones en operaciones de los SDO físicos. Por ejemplo, una petición de crear creará nuevos objetos físicos y los rellenará con valores de nombres. Después de realizar todos los cambios, la capa de lógica de negocio indica al mediador de cambio de nombre que guarde los SDO físicos actualizados. El mediador llama a un servicio de persistencia de objetos físicos para actualizar la base de datos.

Nota:

• No se da soporte a la eliminación de objetos de la lista de objetos de datos físicos dentro de un mediador. Es decir, que es necesario llamar directamente al método delete() en el SDO físico para eliminarlo.
• Si intenta eliminar un DataObject padre después de recuperar el hijo de DataObject en el mismo gráfico de datos, el mediador JDBC de WebSphere Application Server generará una excepción. Debe eliminar primero los objetos de datos hijos antes de eliminar el padre. Sin embargo, si en el gráfico se recupera únicamente el objeto de datos (DataObject) principal cuando se ha suprimido el objeto de datos padre, las entradas de la tabla secundarias las eliminará la base de datos siempre y cuando la tabla de la base de datos contenga la restricción ON DELETE CASCADE.