Capa de servicios de datos

La capa de servicios de datos (DSL) proporciona una capa de abstracción para el acceso a datos que es independiente del esquema físico.

La finalidad de la capa de servicios de datos es proporcionar una interfaz coherente (llamada fachada de servicios de datos) para acceder a datos, independiente de la infraestructura de correlación de objetos relacionales (como EJB, DAS o JPA). A su vez, la infraestructura de correlación extraída se utiliza para transformar los datos recuperados de la base de datos en un colección de objetos Java. Esos objetos se implementan como objetos de datos de servicio físico (SDO).

La capa de servicios de datos realiza transformaciones bidireccionales entre SDO físicos y SDO lógicos. Le permite realizar operaciones de creación, recuperación, actualización y supresión en los SDO lógicos. De forma alternativa, la capa de servicio de datos también le permite realizar operaciones de creación, recuperación, actualización y supresión directamente en los datos físicos, ignorando completamente el esquema lógico.

XPath se utiliza como lenguaje de consulta en el esquema lógico. La capa de servicios de datos correlaciona consultas XPath con plantillas de sentencias SQL. Estas plantillas se utilizan para generar sentencias SQL reales que acceden a la base de datos.

La capa de servicios de datos también permite a la plantillas contener variables de contexto de negocio que se sustituyen cuando se generan las sentencias SQL. Por lo tanto, las consultas XPath enviadas por el cliente pueden convertirse en consultas SQL reales distintas, dependiendo de los valores de las propiedades del contexto de negocio. Las sentencias se almacenan en un archivo de plantillas de consultas separado, que aísla la lógica de ejecución del código de la consulta SQL.

El archivo de plantilla de consulta proporciona un mecanismo para correlacionar fácilmente la consulta XPath, a partir de la consulta del modela lógico, con una o más sentencias SQL. Estas sentencia recuperan los datos físicos de la base de datos.

El archivo también aísla las sentencias SQL del código Java y, de esa forma, el mantenimiento del código es más fácil. También resulta útil para los administradores de bases de datos que deseen localizar y analizar consultas. Los cambios en las consultas SQL no necesitan la recompilación de Java.

El siguiente diagrama muestra las distintas capas del modelo de programación de HCL Commerce e indica cómo se ajusta la capa de datos en el modelo:

DSL consta de tres partes: el servicio de mediación de objeto de negocio, el servicio de persistencia física y la fachada de servicios de datos.

El servicio de mediación de objetos de negocio inicializa mediadores. 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 sus propios mediadores, y hay de dos clases: Mediadores de lectura y de cambio. Están listados en el archivo de configuración de BOM. Los mediadores de lectura se utilizan para procesar las peticiones de obtención (Get) de OAGIS. Los mediadores de Cambio gestionan solicitudes de sincronización, proceso y cambio de OAGIS.

Los mediadores acceden a los datos físicos a través del servicio de persistencia física. Este servicio transforma las consultas XPath en consultas SQL.

La fachada de servicios de datos es una capa delgada que proporciona un solo punto de entrada en el DSL. Proporciona interfaces para trabajar con datos físicos y lógicos y delega en el servicio de mediación de objetos de negocio o en el servicio de persistencia física. También permite a cada módulo de servicio registrarse con la capa de servicios de datos y carga los archivos de configuración específicos del módulo de servicios.

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. Finalmente, los SDO físicos se devuelven al BOM. La configuración de BOM describe cómo crear una instancia con los mediadores necesarios. Estos se devuelven a la capa de lógica de negocio. Es el mediador que se devuelve, no solo 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 creación crea objetos físicos y los rellena con valores de nombre. 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.