Patrón de diseño para la implementación de servicios Get (SOI)
El patrón de diseño para servicios Get es el patrón de diseño básico que se debe utilizar para recuperar y visualizar información de los servicios web.
El diagrama de clases siguiente muestra las clases que se necesitan para crear un servicio Get. Se crea un mandato de controlador maestro para cada servicio Get para cada nombre. Este mandato, que utiliza la clase de programa de utilidad com.ibm.commerce.foundation.server.util.oagis.SelectionCriteriaMapper, extrae la información Get de la solicitud BOD. A continuación, divide el trabajo en dos tareas, delegando la infraestructura de mandatos para que ejecute un mandato Fetch y un mandato Compose. El mandato Fetch recupera los datos, mientras que el mandato Compose compone la respuesta.
Fetch
El mandato Fetch devuelve una lista de beans de datos que coinciden con la expresión. Las extensiones de este mandato Fetch están asociadas a una expresión XPath determinada. Deben implementar la expresión de búsqueda únicamente para devolver la lista adecuada de beans de datos que coinciden con la expresión.
La infraestructura de mandatos puede utilizar la expresión XPath y el mandato de tarea Fetch para resolver la solicitud Get en una implementación determinada utilizando los datos del registro de mandatos (CMDREG) de HCL Commerce existentes. En lugar de tener una implementación para una tarea de negocio Fetch, la infraestructura de mandatos utiliza la expresión XPath como el selector para resolver la implementación. Si no se define una implementación específica para la XPath especificada, se utiliza un mandato Fetch predeterminado.
El principio fundamental de este patrón de diseño es la personalización. Este patrón favorece la reutilización del mandato Fetch, de modo que el soporte de una nueva expresión de búsqueda es sólo cuestión de implementar un nuevo mandato Fetch para devolver una lista de bases de datos rellenadas con datos que representan esa nueva expresión. Mediante el uso de XPath y la configuración de mandatos, puede asociar una expresión XPath a una implementación de mandato, o varias expresiones XPath a la misma implementación de mandato. No necesita modificar las tareas Compose sólo para dar soporte a una nueva expresión de búsqueda.
Compose
El mandato Get toma entonces esa lista y, para cada bean de datos, llama a una tarea Compose para transformar el bean de datos en el modelo lógico (noun) apropiado.
Perfil de acceso
Se recomienda utilizar un perfil de acceso para delimitar los datos de respuesta. El uso de un perfil de acceso facilita la ampliación del servicio en un momento posterior, utilizando diferentes perfiles para permitir un acceso diferente o la devolución de los datos. Por ejemplo, para devolver una vista específica de los datos (como la vista de búsqueda de una entrada de un catálogo), o para devolver los datos en todos los idiomas para fines de autoría. Como extensión a la sintaxis XPath, se debe añadir como prefijo la pareja nombre-valor del perfil de acceso a la expresión XPath entre llaves ({}). Por ejemplo, para especificar el perfil de acceso:
{_wcf.ap=$accessProfile$}/CatalogGroup[Name='MyCatalogGroupName']
Cuando el mandato Get llama al mandato Compose, utiliza el perfil de acceso de la petición como la clave para seleccionar la implementación Compose adecuada. Puesto que el perfil de acceso es sólo un superconjunto de otro perfil de acceso, los mandatos Compose delegan en el perfil de acceso padre para que primero llene con datos el modelo lógico y añada cualquier información necesaria. Esto da como resultado una cadena de mandatos Compose que se llaman para el bean de datos, cada uno de los cuales completa un conjunto del modelo lógico.
Para personalizar la cantidad y el tipo de datos que se devuelven en la respuesta, puede utilizar distintas tareas Compose sin cambiar la tarea Fetch, utilizando un perfil de acceso diferente como la clave. El soporte de un nuevo perfil de acceso consiste en crear un nuevo mandato Compose para ese perfil de acceso y registrar la implementación. Además, este patrón de encadenamiento asegura que la personalización del mandato Compose en un perfil de acceso determinado se refleja en todos los perfiles de acceso dependientes. Si la personalización añade más datos en el perfil de acceso de resumen, todos los perfiles de acceso hijo también incluyen estos datos de resumen. Si altera temporalmente un mandato, todo el código dependiente obtiene este nuevo comportamiento.
Los nombres de perfil de acceso con el prefijo IBM_ están reservados para los perfiles de acceso predefinidos de HCL. Esto evita colisiones de nombres entre los perfiles de acceso que definen los componentes de HCL Commerce y los perfiles de acceso personalizados del usuario.
Los nombres de perfil de acceso con el prefijo IBM_Admin_ son para los servicios que van a ser utilizados por llamadas de servicios basadas en administración/CMC.
Los nombres de perfil de acceso con el prefijo IBM_Store_ son para los servicios que van a ser utilizados por el escaparate.
Para lograr la coherencia entre los distintos módulos de servicio, los nombres de perfil IBM_Admin_Summary e IBM_Admin_Details se utilizan al recuperar información de resumen y de nivel de detalle sobre el objeto de entidad.
El método recomendado para dar soporte a las operaciones Get es utilizar los beans de datos de HCL Commerce existentes, a fin de reutilizar la lógica de negocio y las políticas de control de acceso existentes.