Cairngorm VI: Services y ServiceLocator

al como comentábamos en el último artículo un Command es transversal a las capas de influencia. Aunque un command esté especializado en una tarea muy concreta, esta tarea puede afectar al modelo, a la capa visual o a la capa de negocio.

Es normal que muchos de los commands afecten al modelo de datos, el cual podríamos ver como una capa compartida entre cliente y servidor, introduciendo así el canal de comunicación. Si por ejemplo realizamos una petición al servidor para cargar datos en formato xml, estos datos (modelo) quedarán cargados en el cliente pero los ha facilitado el servidor (modelo compartido).

Por ejemplo, un comando podría ser el responsable de grabar los datos obtenidos a través de un formulario en una tabla de una BBDD (persistencia de datos) pasando a través de algún DAO. Al tratarse de una aplicación cliente, ésta desconoce 100% la lógica interna de la aplicación servidora que almacenará esta información (DAO). La aplicación cliente sólo sabe qué parámetros va a necesitar su homólogo en la parte servidora. Es por ello que desde el lado cliente se recogen los datos y se delega en la parte controladora del lado del servidor la serialización y la persistencia así como el resto de tareas asociadas a la BBDD de estos datos.

La parte cliente se ocupará de gestionar la transacción con el servidor (que la comunicación sea satisfactoria), que los datos tengan coherencia e integridad (filtros y validadores) y de pasarle en un formato conocido por ambas partes los datos necesarios (VO’s si usamos RemoteObject, XML si usamos HttpService o SOAP).

Introducimos el concepto de Servicio como el homólogo, en la parte cliente, de la business logic de servidor. Por ejemplo el servidor es el responsable y conocedor de cómo trabajar con la BBDD a través de DAO’s (Data Access Objects), de cómo crear nuevos registros, modificarlos y eliminarlos. En la parte cliente existe su homólogo pero en vez de saber cómo realizar estas acciones directamente, sabe cómo delegar la responsabilidad a la parte servidora. En algunos casos se utilizará HTTPService en otros RemoteObject o WebService, etc.

Por ejemplo, en el cliente tenemos un formulario de alta de usuario. Los campos de este formulario se tienen que terminar serializando en una BBDD. La forma en que podríamos hacerlo:

• Si la aplicación servidora está basada en URL’s (dependiendo de los parámetros se ejecuta una acción u otra sobre los datos) como por ejemplo Spring, Struts, etc. nuestra aplicación constaría de un servicio HTTPService que referenrenciaría a la url pertinente.
• Si la aplicación servidora funciona sobre FDS, openAMF, amfPHP, etc. nuestra aplicación constaría de un service por cada una de las clases mapeadas.
• Si la aplicación servidora consiste en un servicio SOAP, nuestra aplicación constaría de un servicio WebService.

Estos servicios simplemente ejecutan el código en el servidor pasándole los parámetros que requieran y recogen la respuesta que el servidor genere.

Estos servicios tienen que ser accesibles desde cualquier parte de la aplicación y tienen que ser únicos. Esto es, si queremos invocar dos veces a un servicio SOAP con paremetrización diferente y desde puntos distintos de nuestra aplicación no tendríamos que reinstanciar a los servicios.
Para evitar la duplicidad de los servicios introducimos el patrón ServideLocator que implementa una singleton garantizando así una existencia única.

A través del ServiceLocator podremos acceder así a los servicios disponibles (declarados) para la aplicación sin tener que declararlos una y otra vez. Garantizando así la escalabilidad de su mantenimiento y la facilidad para el cambio (p.e cambio en la url de los servicios o un cambio de mapping).

Fte: http://www.madeinflex.com/2007/01/21/cairngorm-viservices-y-servicelocator/