ORACLE - Desarrollo sin Spring Framework

La facilidad para desarrollar la capa de datos en una aplicación Java EE, JPA y NetBeans IDE sin usar la Spring Framework se muestra en estas páginas:


Parte 1: http://www.oracle.com/technetwork/articles/java/springtojavaee-522240.html
Parte 2: http://www.oracle.com/technetwork/articles/java/springtojavaee2-1414289.html
Parte 3: http://www.oracle.com/technetwork/articles/java/springtojavaee3-1569377.html

Modelado de servicios

"Una aplicación SOA está formada por un conjunto de servicios interconectados cuyo objetivo es automatizar uno o varios procesos de negocio".

Por tanto, a la hora de construir una aplicación SOA, el elemento sobre el que debemos enfocar nuestros esfuerzos es el concepto de servicio. En este punto surgen una serie de preguntas:

·         ¿Cómo puedo saber cuántos servicios se deben crear?

·         ¿Qué tipos de servicios existen?

La primera pregunta es demasiado compleja para contestarla en un solo artículo. Por tanto, me centraré en la última.

¿Qué tipos de servicios existen?: Esta pregunta se la hace todo desarrollador a la hora de enfrentarse a una aplicación SOA. Existen varias clasificaciones dependiendo de su autor. A mí me gusta la más simple, porque a la vez me parece la más práctica para tener una visión general de una aplicación SOA.

Existen básicamente tres tipos de servicios, divididos en base a sus funcionalidades:

·       Servicios controladores: Son los encargados de recibir las peticiones de los clientes y realizar las llamadas necesarias a otros servicios (en la secuencia adecuada) para devolver una respuesta. Es decir, son los servicios encargados de coordinar al resto de servicios. Si analizamos bien este tipo de servicios, nos daremos cuenta de que representan a los procesos de negocio que queremos implementar, ya que un proceso de negocio no es más que un conjunto de tareas ejecutadas en una determinada secuencia para obtener un objetivo.

·       Servicios de negocio: Son los servicios que representan una tarea de negocio, y que forman parte de un proceso de negocio. Este tipo de servicios suelen ser poco reutilizables porque están orientados a resolver una tarea muy puntual.

·   Servicios de utilidad: Son aquellos servicios que se caracterizan por representar una tarea altamente reutilizable. Existen dos tipos, los servicios orientados al negocio que representan una tarea de negocio altamente reutilizable entre aplicaciones y los servicios tecnológicos encargados de encapsular una determinada tecnología y por tanto altamente reutilizables (ej: servicio de acceso a bases de datos relacionales).

Con lo cual, una aplicación SOA la podemos dividir en tres capas. La capa de recepción de peticiones (servicios controladores), la capa de tareas (servicios de negocio) la capa de lógica reutilizables (servicios de utilidad).

Principios de la orientación a servicios

Un problema con el que nos podemos encontrar a la hora de construir una aplicación SOA es si la aplicación construida realmente es una aplicación "SOA Compliant". Para comprobar si una aplicación lo es, la mejor forma de hacerlo es chequeando que la aplicación cumpla con los Principios de la Orientación a Servicios.

No existe una definición estándar de cuáles son los Principios de la Orientación a Servicios, por lo tanto, lo único que se puede proporcionar es un conjunto de Principios que estén muy asociados con la Orientación a Servicios. Estos Principios según Thomas Erl son:

·      Los Servicios deben ser reusables: Todo servicio debe ser diseñado y construido pensando en su reutilización dentro de la misma aplicación, dentro del dominio de aplicaciones de la empresa o incluso dentro del dominio público para su uso masivo.

·  Los Servicios deben proporcionar un contrato formal: Todo servicio desarrollado, debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida. De esta manera, todo consumidor del servicio, accederá a este mediante el contrato, logrando así la independencia entre el consumidor y la implementación del propio servicio. En el caso de los Servicios Web, esto se logrará mediante la definición de interfaces con WSDL.

·  Los Servicios deben tener bajo acoplamiento: Es decir, que los servicios tienen que ser independientes los unos de los otros. Para lograr ese bajo acoplamiento, lo que se hará es que cada vez que se vaya a ejecutar un servicio, se accederá a él a través del contrato, logrando así la independencia entre el servicio que se va a ejecutar y el que lo llama. Si conseguimos este bajo acoplamiento, entonces los servicios podrán ser totalmente reutilizables.

·     Los Servicios deben permitir la composición: Todo servicio debe ser construido de tal manera que pueda ser utilizado para construir servicios genéricos de más alto nivel, el cual estará compuesto de servicios de más bajo nivel. En el caso de los Servicios Web, esto se logrará mediante el uso de los protocolos para orquestación(WS-BPEL) y coreografía (WS-CDL).

·       Los Servicios deben de ser autónomos: Todo Servicio debe tener su propio entorno de ejecución. De esta manera el servicio es totalmente independiente y nos podemos asegurar que así podrá ser reutilizable desde el punto de vista de la plataforma de ejecución.

·    Los Servicios no deben tener estado: Un servicio no debe guardar ningún tipo de información. Esto es así porque una aplicación está formada por un conjunto de servicios, lo que implica que si un servicio almacena algún tipo de información, se pueden producir problemas de inconsistencia de datos. La solución, es que un servicio sólo contenga lógica, y que toda información esté almacenada en algún sistema de información sea del tipo que sea.

·       Los Servicios deben poder ser descubiertos: Todo servicio debe poder ser descubierto de alguna forma para que pueda ser utilizado, consiguiendo así evitar la creación accidental de servicios que proporcionen las mismas funcionalidades. En el caso de los Servicios Web, el descubrimiento se logrará publicando los interfaces de los servicios en registros UDDI.

Cuando se desarrollan aplicaciones SOA es muy útil y necesario tener en cuenta siempre estos principios, ya que nos van a dar las pautas necesarias para tomar ciertas decisiones de diseño complejas.

Como se habrá podido observar, una característica muy importante de los Principios de la Orientación a Servicios, es que todos ellos se inter-relacionan. El siguiente gráfico muestra la inter-relación de los diferentes principios:

 Como se puede observar en el gráfico, el objetivo de la Orientación a Servicios es obtener software totalmente reutilizable a través de un conjunto de técnicas y principios como los descritos anteriormente.

SOA y los Servicios Web (II)

El segundo tipo de Arquitecturas Orientadas a Servicios es el tipo utilizado actualmente, porque está basado en el SOA tradicional, añadiendo lo necesario para cubrir sus carencias, proporciona los elementos necesarios para cumplir con todos los principios de la orientación a objetos.

El esquema básico de una SOA de segunda generación en el siguiente gráfico:

Como se puede observar, una SOA de segunda generación está formada por un conjunto de Funciones y por la Calidad del Servicio.

La Funciones están formadas por:

·        Transporte: Mecanismo utilizado para trasladar las peticiones desde el cliente, hasta el proveedor del servicio, y viceversa.

·    Protocolo de comunicación: Es el sistema de comunicación entre el cliente y el proveedor de servicios.

·      Descripción del servicio: Es un esquema utilizado para describir qué servicio es, como se le puede invocar, y cuales son los datos necesarios para realizar su invocación.

·      Servicio: Es la implementación del servicio.

·      Proceso de negocio: Es una colección de servicios, invocados en una determinada secuencia, con un conjunto particular de reglas para satisfaces un requisito de negocio.

·   Registro de servicios: Es un repositorio de servicios y datos, usado por los proveedores de servicio y publicar los servicios, y para los clientes, donde buscarlos.

La calidad del servicio por:

·       Política: Son un conjunto de reglas bajo las cuales, un proveedor de servicio hace que el servicio esté disponible para los clientes (WS-Policy).

·       Seguridad: Son un conjunto de reglas que podrían ser aplicadas en la identificación, autorización y control de acceso a los servicios, por parte del cliente (WS-Security).

·     Transacción: Conjunto de atributos que podrían ser aplicados sobre un grupo de servicios para devolver un conjunto de datos consistentes (WS-Transaction, WS-Coordination).

·  Gestión: Conjunto de atributos que podrían ser aplicados para gestionar los servicios proporcionados (WS-Manageability).

Es decir, las SOA de segunda generación se basan en ampliar su funcionalidad mediante el uso de los estándares WS, que proporcionan funcionalidades como gestión de transacciones, seguridad, etc..