Servicios de datos con WSO2 para resolver el acceso a datos.

En la entrada Introducción a Spring JDBC como solución a los problemas de uso e JDBC en proyectos productivos veíamos cómo podíamos implementar el acceso a datos usando Spring JDBC y luego en la entrada Sustituyendo la capa de persistencia de Spring JDBC por Spring + Hibernate hacíamos lo mismo pero usando Spring + Hibernate + Anotaciones.

En esta entrada entonces quiero ilustrarles un posible problema y la solución que se le puede dar.

Asumamos que somos los desarrolladores de una aplicación donde una de las entidades es “capítulo” y que hemos creado un DAO para dicha entidad. Esto permite que se pueda acceder desde cualquier lugar de la aplicación a los datos de “capítulo” a través del DAO correspondiente, pero que pasa si otra aplicación por algún motivo justificado necesita acceder a esos mismos datos. ¿Cómo se hace?

Soluciones pueden existir 2 o 3, pero en mi caso quiero exponerles una que he usado bastante y que consiste en crear un servicio de acceso a datos que exponga a través de SOAP o REST un conjunto de operaciones CRUD sobre dicha entidad. Pueden ver esta solución en la siguiente imagen.

Como se puede ver en la imagen el “Sistema propio” bien puede optar por acceder a la entidad directamente en la BD o puede hacerlo vía el servicio web. El resto de las aplicaciones tiene ahora acceso a los datos de la entidad “Capitulo” de una forma controlada gracias al uso del AS o el DSS.

Las ventajas de este enfoque son:

• Se desarrolla más rápido el acceso a la entidad, con tan solo 3 minutos tienes creado un servicio web que cumple con todos los estándares del Stack WS-*.
• Se puede brindar acceso a los datos de la entidad a otras aplicaciones sin requerir nuevas implementaciones.
• La aplicación dueña de la entidad puede seguir accediendo de la manera tradicional o empezar a hacerlo desde el servicio web. Aquí si el servicio web cumple con la misma interface con que cumplía la implementación usando JDBC o Hibernate no debe haber problema para hacer el cambio.
• Al usar la plataforma de WSO2 al servicio se le pueden incorporar facilidades para la autenticación, autorización y auditorias que aseguren un correcto acceso a los recursos.
• El servicio expuesto es interoperable e independiente de la tecnología, o sea que se puede consumir desde cualquier lenguaje de programación.

Desventajas:

• Por lo general se dice que el acceso a los servicios es más lento que si se accede directamente a los recursos, y es algo cierto. Lo que se debe determinar es si la latencia introducida afecta la experiencia del usuario final o del sistema. Aquí temas como el cacheo de la información juegan un papel fundamental.
• A los desarrolladores no les gusta tener fuera de su control funcionalidades del sistema y en este caso el servicio está fuera del sistema en un servidor externo, lo que requiere un acceso diferente a la BD.
• Si solo se requiere un servicio web para 1 entidad, la solución dada puede ser como el ejemplo de usar un cañón para matar un mosquito. Algunas otras variantes como RMI o incluso Spring Web Services puede ser más interesante de implementar. Aunque si la empresa se encuentra dentro de una iniciativa SOA o en alguna implementación de una solución de integración si tiene mucho sentido implementar un servicio de acceso a datos. Esto último lo pueden ver en la siguiente entrada Introducción a SOA y BPM.

Para aquellos que quieran ver cómo implementar un servicio de acceso a datos usando la suite de WSO2 en solo 3 minutos los invito a que vean este enlace.

El servicio que se crea por esa vía contiene las operaciones CRUD básicas y lo bueno es que luego se puede modificar para ajustarlo a nuestras necesidades. Si alguien quiere hacerlo desde cero y no usar la funcionalidad de “Generate” pues lo puede hacer sin ningún problema.

En otras entradas estaremos viendo más de estos temas.

Palabras claves: servicio web, servicio de acceso a datos, WSO2, AS, DSS, SOAP.