En este punto asumimos que ya sabes como crear un proyecto SOA, configurar un Data Source y un Connection Pool desde la consola de WebLogic.

Una vez creado nuestro proyecto SOA lo que sigue es crear un Schema el cual contenga los tipos de datos que usaremos para el Request y Response de nuestro servicio el cual quedaría a sí.

fig.1: Muestra la estructura del schema necesario para crear el servicio de registro de usuarios.

Ya con el schema procedemos a crear un proceso BPEL con el schema anterior y configuramos para que quede de la siguiente manera:

Fig.2: Muestra la configuración del BPEL con el Reques y Response del Schema anterior.

El paso siguiente es crear la tabla de USUARIOS en nuestra base de datos la cual deberá estar accesible con el usuario que usaremos en el registro del DataSource.

En este punto tendremos la Composición SOA de la siguiente manera:

Fig.3: Estado de la Composición después de crear el proceso BPEL.

Lo que sigue a continuación es crear un DataBase Adapter para lo cual arrastramos el DataBase Adaper de la paleta a la sección de External References y nos saldrá el Wizzard y presionamos siguiente en la primera pantalla llevándonos a la siguiente pantalla:

En esta pantalla solo podremos el nombre que le daremos al Adaptador dentro de Composite por lo que ponemos un nombre que lo identifique rápidamente y presionamos Next para continuar.

 La siguiente tendremos que definir la forma en que nos vamos a conectar a la base de datos para lo cual vamos a requerir dos conexiones distintas, la primera(Arriba) es una conexión diracta con la base de datos que se utilizara exclusivamente en tiempo de desarrolla, ya que sera necesaria para introspectar la base de datos y crear los Schemas necesarios para hacer la comunicación. En caso de no tener ninguna disponible tendremos que crear una nueva con el botón verde de +.

Una vez configurada nuestra conexión tendremos que configurar la segunda(Abajo) esta es exclusiva para tiempo de ejecución y tendremos que poner el nombre del JNDI de un Connection Pool (Como crear un Connection Pool) registrado en WebLogic y presionamos Next para continuar.

En la siguiente pantalla tendremos que especificar el tipo de operaciones que realizaremos, En este caso como solo haremos Insert y Select seleccionamos las opciones siguientes y presionamos Next.

 La siguiente pantalla es para seleccionar las tablas con las que estaremos trabajando por lo que el botón de Import Tables y seleccionamos la tabla de usuarios para continuar.

La siguiente pantalla es para realizar las asociaciones pero como no tenemos solo presionamos Next.

El wizzard nos dirigirá a la pantalla para seleccionar los campo con lo cuales podremos interactuar por lo que seleccionamos todos y continuamos.

 En el siguiente paso configuramos el Query del Select de la siguiente manera pues buscaremos al Usuario por medio de su nombre de usuario o correo.

Finalmente presionamos Next en las dos siguientes pantalla para finalizar y tendremos el DBAdapter en nuestra composición.

El siguiente paso sera asociar el DBAdapter al BPEL como se muestra en la siguiente imagen:

En este punto la composición SOA ya esta lista pero faltara programar el BPEL para que realice las operaciones necesaria para registrar al usuario.

En este caso la lógica del BPEL sera la siguiente, Cuando llega una solicitud validara que el nombre de usuario no exista consultando la tabla por medio del nombre de usuario, si no existe registrara al usuario y regresara el código ‘000’ y la leyenda ‘Registro Exitoso’, en caso de que el usuario ya exista regresaremos el error ‘111’ y la leyenda ‘Usuario existente’ y finalizara.

DESARROLLO DEL BPEL

Primero que nada abrimos el BPEL dando doble click sobre el, esto nos llevara al editor y veremos lo siguiente en pantalla:

Si prestamos atención en la imagen veremos en rojo el DBAdapter que configuramos hace un momento como un PartnerLink lo cual indica que todo va bien hasta ahorita.

El siguiente paso sera crear una actividad Invoke de la siguiente manera:

En esta pantalla tendremos que definir primero que nada el nombre de la actividad en en el campo Name, después seleccionar el PartnerLink que deseamos invocar y tener cuidad de seleccionar la Operación de Select, Otro paso importante es crear la variables Input y Output de la parte de abajo y ponerles el nombre QueryUserInputVariable y QueryUserOutputVariable para finalizar.

Seguido creamos un actividad Assign para asignar los valores de entrada(InputVariable) a la variable de entrada del servicio (QueryUserInputVariable) para lo cual aremos la siguiente asignación:

El BPEL nos quedara de la siguiente manera:En este momento la variable QueryUserOutputVariable contendrá los resultados de la invocación del servicio por lo que tendremos que validar si encontró resultados mediante una actividad IF debajo del la actividad Invoke y la configuraremos de la siguiente manera:En este IF contamos los nodos del resultado, si es mayor que cero entonces quiere decir que el usuario ya existe y tendremos que regresar el error. Por lo cual agregamos una actividad Assign y un Reply quedando el IF de la siguiente manera:

La actividad ErrorAssign lo configuramos de la siguiente manera:

La actividad ErrorReply la configuramos de la siguiente manera:

Con esto lograremos que el BPEL regrese el error al detectar que ya existe el usuario.

El siguiente paso sera crear otra actividad Invoke para el mismo PartnerLink pero esta vez para la operación de Insert y definiremos las variables de entrada(InsertUsuarioInputVariable).

Creamos una actividad Assign para asignar los valores de la variable InsertUsuarioInputVariable para que quede de la siguiente manera:

Finalmente con un assign modificamos la variable OutputVariable para regresar el código 000 y la leyenda Registro Exitoso.

y el BPEL quedara de la siguiente manera:

Solo nos queda deployar y probar el servicio.

Para empezar virtualizar viene de la palabra virtual como cuando hablamos de maquinas virtuales, pues esto es algo parecido pues un servicio virtual no es mas que una mascara que lo único que hace es exponer un WebService que por dentro hace la llamada a otro u otros WebServices para dar una funcionalidad nuevo o extendida.

Imaginemos que estamos desarrollando una aplicación móvil para una empresa la cual dentro de sus sistemas ya tiene un conjunto de webservices desarrollados para las principales tareas que realiza, sin embargo hasta el momento no tiene ningún desarrollo para móviles y le preocupa la seguridad ya que al exponer sus webservices tema que alguna persona mal intencionada pueda entrar y hacer algún mal.

Por lo que desarrollo un WebService para que el usuario se Autentifique cuando entre a la aplicación, sin embargo eso no es todo, también requiere que cuando el usuario realice alguna acción se validen sus privilegios para denegar cualquier acción no permita para ese usuario.

Otro punto importante es que el cliente quiere que cuando una persona intente hacer una acción no autorizada o falle en el Login se registre tal acción para poder auditar y detectar situaciones sospechosas.

El cliente nos brinda los siguientes WebServices con los que debemos diseñar nuestra aplicación:

SecurityService  //WebServices que expone el sistema de seguridad centralizado.

• login(usuario, password) : boolean: Operación que autentifica al usuario y nos dice indica si el login fue exitoso o no.
• autorization(usuario,password, accion ):boolean: Operación que nos indica si un usuario tiene privilegios para realizar una acción determinada, El parámetro acción representa el ID de la operación a ejecutar.

AuditService //WebService que expone el sistema de Auditoria Informática

• intentoAccion(usuario, accion, DateTime, autorizationResult): void: Operación que registra cuando una acción es solicitada

ClienteService //WebService para consultar los datos del cliente

• consultaDatosPersonales(idCliente): Cliente: Operación que regresa los datos básicos del cliente como nombre,apellido, sexo, CURP, etc.
•  consultaSaldo(idCliente): double: Operación que regresa el saldo del cliente

Desarrollando la solución

Imaginemos que la aplicación lo único que hace es consultar los datos del cliente y su saldo sin embargo no todos los usuarios pueden saber el saldo de un cliente por lo que el servicio se separa y se consulta de forma independiente.

Lo primero que se nos ocurre es hacer una pantalla de login y autenticarnos con el servicio de login pasandole el nombre de usuario y password. Si el login se realiza correctamente entramos a la aplicación, sin embargo el cliente quiere que cuando un login falle o se de correctamente notifiquemos el evento al departamento de Auditoria mediante la operación de intentoAccion y pesarla el ID de la operación Login y la fecha y hora del intento.

Esto desde luego nos implicaría dos llamadas a Webservices, uno para Login y otro para Auditoria:

 Fig.1: Muestra la comunicación con los dos webservices de forma separada.

Para la pantalla de datos del cliente tendríamos que implementar nuevamente un sistema de llamadas donde primero verificaríamos si tenemos privilegios para leer los datos del cliente con el webservices de autorizacion, de darse los privilegios entonces se consulta el Webservices de consultaDatosPerosnales, seguido de consultar los privilegios para autorizar al usuario para leer el saldo del cliente y consultar el servicio de  consultaSaldo. Nuevamente si alguna autorización falla es requerido notificar al departamento de Auditoria mediante el Webservices intentoAccion. Este esquema quedaría algo a sí.

 Fig.2: Fugura que muestra el número de acción a realizar solo para completar la consulta de los datos del cliente y saldo.

Un esquema con Virtualización:

Una vez que examinamos como tendríamos que desarrollar una aplicación sin virtualización podemos empezar a examinar el esquema con virtualización.

La primera acción que deberíamos hacer es crear un proxy que cumpla casi exactamente con el contrato(WSDL) que sirve como punto de entrada a nuestra aplicación pero que ademas de esto le estaríamos pasando los datos de autenticación y autorización en el Header del mensaje SOAP de tal forma que el proxy tomara el header lo enviara al servicio de autorization en caso de autorización continuara con la llamada al servicio de consultaDatosPerosnales y regresara el resultado.Pero en caso de haber fallado la autorización llamaría al servicio de Auditoria y regresaría un Throw para indicar que el servicio ha fallado por seguridad.

La aplicación se viera de esta manera para el escenario de consulta de datos del suscriptor:

Fig.3: Escenario con virtualización

Si nos damos cuenta en este escenario ya solo tenemos una invocación a un único servicio el cual se encarga de realizar las operaciones previas a la consulta de los datos del cliente y también notificar al departamento de Auditoria en caso de haber fallado la autorización.

Este enfoque tiene las siguientes ventajas:

• Se reduce el numero de llamadas al servidor
• Aumentan los tiempos de respuesta
• Las operaciones se realizan desde la misma infraestructura del cliente por lo que la seguridad es mucho mejor.
• El implementar un Enterprice Service Bus nos da la cualidad de poder medir el performance (KPI o Key Performance Indicator).
• Definir los acuerdos de nivel de servicio o SLA.

Componentes de una Composición SOA:

Service Component

• HumanTask: Cuando automatizamos proceso por medio de BPEL o BPM llega el momento en que la computadora no es capaz de tomar una decisión por si mismo por lo que requiere de la intervención de un Humano para que toma la decisión mas apropiada y a si continuar con el resto del flujo. Estas decisiones se hacen mediante HumanTask las cuales son mini-aplicaciones ADF que son desplegadas en el portal WorkList de la SOA Suite.

• Business Rule: Este componente sirve para exponer reglas de negocio re-utilizables que pueden ser modificadas sin necesidad de desplegar nuevamente. En una Business Rule podemos definir funciones que ayuden a hacer cálculos o tomar sediciones de una forma mas inteligente, También nos da la posibilidad de crear Tablas de sección las cuales arrojan un resultado mediante la evaluación de reglas cruzadas.
• BPEL Process: Los BPEL estan diseñados para orquestar servios y realizar integraciones de forma automática con la menor interacción humana. Ya tengo una Entrada en la cual hablo mucho mas a detalle de lo que es un BPEL y también hablo de como crear un BPEL.
• Mediator: Los mediator están diseñados para mediar entre un component y otro, es decir nos ayuda a convertir el formato de salida de un servicio en la entrada de otro, pero también nos sirve para inyectar nuevos parámetros.
• Spring Context: Para los ya familiarizados con este potente framework se le hará muy simple comprender su funcionalidad pero para lo que no les podría comentar que este componte nos sirve para tener una interacción mas directa con Java ya que a través de este componente es posible ejecutar clases java para hacer funcionalidad muy especificas que con BPEL serie imposible o muy difícil de realizar.

Service Adapter

• B2B Adapter: Este es un adaptador especifico para comunicarnos con la plataforma de B2B de Oracle SOA Suite por medio de una cola de mensajes JMS
• BAM Adapter: Este adaptador nos permite comunicarnos con Business Activity Monitor(BAM) una plataforma de monitorio en tiempo real.
• Data Base Adapter: Adaptador que nos permite interactuar con una base de datos determinada, Esta comunicación se hacer siempre a través de un Pool de conexiones que se tiene que configurar desde la consola de WebLogc y que es accedida por medio del JNDI.
• Direct Binding Adapter: Este es un adaptador que nos permite comunicarnos con nuestros recursos a a través del protocolo propietario de Oracle llamado t3 el cual tiene la ventaja que es mucho mas directo y que ayuda al performance.
• EJB Services: Adaptador que nos ayuda a comunicarnos por medio de EJB los cuales son parte del JavaEE.
• File Adapter:  Este adaptador esta diseñado para interactuar con sistemas de archivos o servidores FTP/SFTP y nos permite hacer operaciones de lectura, escritura y borrado.
• HTTP Binding: Este componente nos permite leer o enviar cualquier tipo dato a través de una conexión HTTP.
• JMS Adapter: Adaptador que nos permite recuperar y encolar mensajes en una Cola(Queue) JMS. Les comparto una entrada que habla de las Colas JMS.
• Web Services: Uno de los mas usados y sirve para exponer un webservice o comunicarse con algún WebService externo.
• MQ Adapter: Bastante parecido al JMS Adapter pero este sirve para comunicarse con el proveedor MQ que le pertenece a IBM, Aun que al final sigue las especificaciones de JMS.

Por lo pronto lo dejo hasta aquí, mas adelante estaré publicando entradas para cada componente.

Paso 1: Crear una proyecto SOA.

Entraremos a JDeveloper y daremos click en File/New/SOA Project y nos saldrá la pantalla siguiente, Solo cambiamos el nombre del proyecto a “Calculadora” y damos Next en las dos pantallas.

En este punto ya habrás creado una SOA Project y te abrirá la pantalla del Composite, de no ser a podemos abrirlo desde el archivo composite.xml que se genera en la estructura del proyecto:

Paso 3: Crear los tipos de datos en un Schema

El siguiente paso es clave ya que es indispensable definir los tipos de datos que recibirá y responderá nuestro servicio para lo cual crearemos un Schema de la siguiente manera File/New/XML Schema asegurándonos que la pestaña All Technologies este seleccionada.

 En la siguiente pantalla solo cambiamos el nombre del archivo a “Calculadora.xsd” y continuamos.

Continuaremos con crear los tipos de tal forma que nuestro Schema quede de la siguiente manera:

NOTA: En la siguiente entrada explico mas a detalle como crear un Schema

Paso 3: Crear un BPEL

 Con el Schema creado ya podemos crear un BPEL que reciba SumaRequestType y que tenga como resultado un SumaResponseType

Abriremos el archivo composite.xml que se crea con el proyecto en el cual daremos click derecho en la sección del medio “Components” y seleccionamos Insert/BPEL Process como se muestra en la siguiente figura.

 Nos deberá aparecer una pantalla como la siguiente y pondremos los datos como aparecen:

Seleccionamos la opción de BPEL 2.0, Cambiamos el nombre a CalculadoraProcess, En NameSpace podemos poner lo que mas nos agrade no es necesario dejarlo igual, En Temple seleccionamos Synchronous BPEL Process para que sea un servicio con entrada y respuesta y finalmente en Input y Output seleccionamos los tipos que definimos en el Schema del paso 2. Seleccionar los correctamente los Input y Output es un paso clave ya que definen los tipos que se utilizaran como parámetro de entrada y salida de nuestro servicio. Finalmente presionamos OK y tendremos creado en BPEL que se mirara a sí:

En el centro tenemos el BPEL(Azul) el cual lo creamos en el paso anterior, Del lado izquierdo tenemos expuesto un WebService que para los parámetros
al BPEL y de igual forma regresara al consumidor el resultado del BPEL, Entre medio de los dos tenemos una linea que indica que el WebService y el BPEL están conectados por lo que la información fluirá entre los dos.

Ya con el BPEL creaso solo faltara programar el BPEL para que realice el calculo de la suma para lo cual daremos doble click sobre el BPEL para abrir el editor y nos dirigirá a la siguiente pantalla:

La imagen anterior nos muestra la forma mas simple del BPEL el cual solo tiene dos actividades receiveInput que solo recibe los parámetros de entrada en la variable llamada “InputVariable” y la actividad replyOutput las cual regresa el resultado del BPEL en la variable “OutputVariable”. Ambas variables son creadas de forma automática y corresponden con los tipos definidos en el Schema (SumaRequestType y SumaResponseType).

El siguiente paso consiste en sumar los dos valores y ponerlos en la variable OutputVariable para que BPEL regrese el resultado al terminar. Para esto tendremos que crear una actividad llamada Assign la cual se encuentra en la paleta de componentes del lado  Derecho:

Presionamos sobre “Assign” y sin soltar arrastramos hasta colocarlo en medio de las dos actividades existentes y le ponemos el nombre de SumaAssign quedando como se muestra en la figura anterior.

La actividad Assign sirve para asignar valores a cualquier variable que tengamos en el BPEL por lo cual daremos doble click sobre la actividad Assign:

Veremos la pantalla anterior la cual esta dividida en tres secciones:

• Izquierda: De esta parte tomaremos los valores para hacer las asignaciones
• Derecho: En esta sección ponemos los valores asignados mediante la sección de la izquierda.
• Abajo: Aquí solo se en listan las asignaciones que vamos haciendo.

Para sumar los dos valores necesitaremos mas de un campo por lo que tendremos que hacer una formula arrastrando la calculadora hasta el nodo llamado result:

En la pantalla siguiente solo seleccionamos el nodo num1 para que se coloque arriba agregamos el operador “+” y hacemos lo mismo para el num2, Con esto ya tenemos lista la formula y damos ok.

Finalmente tendremos la asignación en la parte de abajo y presionamos OK para finalizar la asignación.

Guardamos los cambios del proyecto y nuestro BPEL esta listo para deployarse

Paso 4: Deploy

Para hacer el deploy tendremos que tener corriendo una instancia de WebLogic con la SOA Suite instalada y seguir los siguientes pasos.

Sobre el proyecto hacemos click derecho y precionamos /Deploy/Composite… y nos saldrá una pantalla nueva. Seleccionamos Deploy to Aplicaction server/Next en la pantalla siguiente Next sin hacer ningún cambio, en la siguiente pantalla seleccionamos el servidor al que queremos hacer deploy o damos de alta uno nuevo en caso de no tener ninguno registrado, En la siguiente pantalla solo seleccionamos next, y finish.

Con estos pasos tendremos la composicion SOA y el BPEL deployados y ya solo faltara hacer una prueba con algún cliente de WebServices como soapUI o la consola de Weblogic.

Paso 5: Prueba

Para obtener la URL del webservice nos vamos al portal EnterpriceManager el cual esta en la url

http://localhost:7001/em en caso de no estar instalado el weblogic en la misma maquina cambiar localhost por la IP.

Una vez autenticados del lado izquierdo entramos a la ruta /SOA/soa-infra/default/Calculadora

nos abrirá un dashboard solo de la composición y en ella veremos un icono con un mondo y una pieza de rompecabeza, damos click y aparecera una url que termina en ?wsdl esa la copiamos y la usamos en cualquier cliente para consumir webservices.

NOTA: Mas adelante publicare como instalar JDeveloper, WebLogic, SOA Suite y OSB.. 

Hoy en día los sistemas de información generan una gran cantidad de información mediante la operación del día a día. Estos sistemas generalmente están comunicados con otros sistemas o módulos para compartir o extraer información.  Esta comunicación entre sistemas es llamado “Integraciones” y son muy importantes ya que de no existir los sistemas no se podrían comunicar y se generaría un caos.

Un ejemplo claro de integración:

Imagínate un sistema de punto de venta en donde se capturan las ventas diarias, se cobra y se consulta inventario. El punto de venta cada vez que realiza una venta tiene que descontar del almacén las unidades vendidas las cuales el Sistema de Almacén resta y lleva la cuenta para hacer los pedidos cuando la existencia esta bajando. Por otra parte las vendedoras consultan el inventario para saber si algún producto lo aun lo tiene en existencia y poder dar cotizaciones a los clientes.

Al finalizar el día todas las ventas se van al sistema de contabilidad para hacer las pólizas contables.

Si nos damos cuenta el sistema de ventas necesita una “Integración” constante con el sistema de Almacén ya que desde allí consulta la existencia pero también la modifica cuando venden.

Al final del día el sistema se tiene que “Integrar” con el sistema de contabilidad para realizar las pólizas.

Hora imaginemos que estas integraciones no existieran!!, Te imaginas como se pudiera operar si esta comunicación con los sistemas no se pudiera dar o no fuera eficiente?

SOA Composite

Bien un composite es donde diseñamos a un alto nivel la integración o Integraciones las cuales serán expuestas como servicios para que los sistemas los consuman y logren la integración.

Una composición SOA se divide en tres secciones:

• Exposed Services: En esta sección describimos la forma en que expondremos los servicios ante los consumidores(Aplicaciones), esta sección podemos exponer WebServices, EJB, Servicios HTTP, Sockets los cuales sirven para que los clientes puedan iniciar la integración bajo demanda, pero también existen métodos que hacen que muestra integración se ejecutaba bajo algún evento en especial como por ejemplo, Colas de mensaje(Queue) JMS, Base de datos(Poolling), B2B. En resumen esta sección representa la entrada de la integración y el inicio de su ejecución.
• External References: En esta sección ponemos los servicios externos que requeriremos para que nuestra integración se pueda realizar. Aquí podemos poner WebServices, Base de datos, HTTP, Colas de mensaje, B2B,etc.
• Components: Aquí es donde se programa las acciones a seguir para que nuestra integración realice lo que esperamos, A qui podemos poner BPEL, Human Task, Business Rules,BPM las cuales son componentes diseñados para atacar diferentes problemáticas.

Un composite para la integración del sistema de punto de ventas y almacén se vería algo a sí

Fig.1: Composite para integrar Punto de venta con Almacén.

En la figura anterior podemos ver que tenemos dos servicios del lado izquierdo los cuales representa los servicios que estamos exponiendo para ser consumidos por el Punto de venta.

En medio vemos dos BPEL(En Azul) los cuales se encargan de Orquestar las acciones necesarias para realizar la operación deseada.

Y del lado derecho tenemos el WebService que expone el almacén, el cual tiene las operaciones consultaExistencia y actualizarExistencia necesarias para realizar la integración.

Por ultimo les dejo esta liga donde donde podrán encontrar mucha mas información de lo que es un Composite

http://docs.oracle.com/cd/E14571_01/integration.1111/e10223/arch_02.htm