Gobernando Servicios de Alfresco ECM con WSO2

El beneficio principal de hacer SOA sobre hacer Integración es la capacidad de gobierno que tenemos sobre los servicios, es decir, la capacidad de control que alcanzamos al aplicar los principios SOA.

En la integración o construcción de aplicaciones muchas veces tenemos que integrar o consumir servicios externos “no gobernados”, hacerlo sin control es siempre un riesgo, por ejemplo, si el contrato (WSDL) cambia, nuestra aplicación integrada se quedaría al margen de los cambios y sin soporte.

Gobierno de los servicio de Alfresco con WSO2

Gobierno de los servicio de Alfresco con WSO2

En esta post aprenderemos cómo registrar servicios externos en WSO2 Registry, concretamente aquellos servicios SOAP de Alfresco ECM, y luego consumirlos usando el mismo WSDL (contrato) desde nuestras aplicaciones de negocio usando WSO2 ESB.

I. Estrategia:

Para iniciar con el Gobierno SOA es necesario gestionar los servicios que vamos a consumir, eso implica registrar los servicios en WSO2 Registry, una vez realizado esto alcanzaríamos otros beneficios como: capacidad de medir, ofrecer otra interficie SOA, controlar la QoS, mejorar la Seguridad, gestionar versiones, encadenar servicios, etc.

Por estos motivos, WSO2 Registry es una herramienta fundamental para hacer Gobierno SOA y a partir de este sencillo principio SOA se abren infinitos escenarios de aplicación y de negocio.

En este post sólo registraremos un servicio de Alfresco ECM en WSO2 Registry, pero podría ser posible extender de manera rápida y fácil al resto de servicios SOAP, incluso al resto de servicios REST de Alfresco, además aprovechar la capacidad integradora de WSO2 ESB para “jugar” un poco con los servicios de Alfresco llegando incluso a brindar una nueva capa “gobernada” de servicios de gestión documental, es decir, un API completo de gestión documental.

II. Objetivos:

  1. Saber identificar Aplicación externa y servicios externos (endpoints, WSDLs,..) a usar (integrarlos) en nuestra aplicación interna.
  2. Aprender a registrar servicios externos en WSO2 Registry.
  3. Aprender a crear EndPoint interno en WSO2 ESB.
  4. Aprender a crear Proxy para dicho servicio manteniendo mismo “contrato” y usando nuevo EndPoint desde WSO2 ESB.
  5. Saber consumir el nuevo servicio recientemente registrado con WSO2 TryIt y con soapUI.

III. Requerimientos:

Emplearemos WSO2 Stratos Live, para ello debemos crearenos una cuenta y nos asegurarmos de que WSO2 ESB y WSO2 Registry estén habilitados.

IV. Pasos:

1. Identificar Aplicación externa y sus servicios externos (Endpoints, WSDLs,..)

En este caso usaremos Alfresco ECM como aquella aplicación que queremos integrar a la nuestra interna pero consumiendo únicamente sus servicios. Alfresco brinda una serie de servicios de gestión documental, esto son:

  • Servicios SOAP ad-hoc
  • Servicios basados en CMIS
WSDLs de Alfresco ECM

WSDLs de Alfresco ECM

  • Servicios REST ad-hoc
Servicios REST de Alfresco ECM

Servicios REST de Alfresco ECM

2. Desde WSO2 Registry, añadir servicios a partir de WSDLs.

En este caso usaremos únicamente el servicio de autenticación de alfresco (SOAP), a modo de ejemplo, aunque dejamos también el servicio de Repositorio:

Registrando los WSDL en WSO2 Registry

Registrando los WSDL en WSO2 Registry

En WSO2 Registry aparecerán 2 servicios registrados (uno por cada WSDL).

Servicios registrados

Servicios registrados

3. En WSO2 ESB, crear un nuevo “Address Endpoint” y guardarlo en el Governance Registry.

Creando EndPoints

Creando EndPoints

Crear “Address Endpoint” con los sgtes datos:

Nombre Endpoint: “kns.alfr.authn.ep0”
Valor: “http://www.konosys.es:8014/alfresco/api/AuthenticationService” (verlo en el WSDL, como se muestra en la figura de abajo).
Key: “gov:/ kns.alfr.authn.ep0”
Obteniendo EndPoint desde el WSDL

Obteniendo EndPoint desde el WSDL

Durante el proceso de creación del Endpoint hacer click en el botón “Save As”, te solicitará dónde guardar dicha entrada. Elegir Governance Registry con el nombre de la entrada por defecto (mismo nombre del endpoint).

Asignando EndPoint a servicio

Asignando EndPoint a servicio

Finalmente, si todo ha ido bien, se mostrarán los Dynamic Endpoints, verificar que nuestro endpoint esté en la lista.

Dynamic EndPoint creado

Dynamic EndPoint creado

4. Desde WSO2 ESB, crear Proxy para dicho servicio manteniendo mismo WSDL y usando nuevo Endpoint.

Nombre Proxy: “kns.alfr.authn.ep0”
WSDL: seleccionarlo desde Governance Registry.
Endpoint: seleccionarlo desde Governance Registry.
WSO2 ESB - Creando un Custom Proxy

WSO2 ESB – Creando un Custom Proxy

Luego, asignarle un nombre al proxy y seleccionar el WSDL alojado en el Registry.

WSO2 ESB - Seleccionando el WSDL desde el registro

WSO2 ESB – Seleccionando el WSDL desde el registro

Luego, hacer click sobre el botón “Next” para continuar con la configuración del Proxy. En la nueva pantalla tendremos la oportunidad de seleccionar el Endpoint que habiamos creado inicialmente.

WSO2 ESB - Seleccionando el EndPoint desde el Registry

WSO2 ESB – Seleccionando el EndPoint desde el Registry

Haga click en “Next” y en el último paso hacer click sobre “Finish”.

WSO2 ESB - Finalizando la creación del Proxy

WSO2 ESB – Finalizando la creación del Proxy

Si hemos llegado a este punto, ya habremos creado un Proxy con el que ya podemos invocar el servicio desde cualquier aplicación cliente SOAP. En este caso para probarlo usaremos el servicio TryIt de WSO2, para ello hacer click sobre “Try this service”.

WSO2 ESB - Listo para probar el Proxy

WSO2 ESB – Listo para probar el Proxy

5. Probando el Servicio con WSO2 TryIt

WSO2 viene con una herramienta para probar servicios, se llama WSO2 TryIt. En este ejemplo usaremos esta herramienta, aunque también explicamos qué hay que hacer para emplear soapUI.

WSO2 TryIt - Probando Servicios

WSO2 TryIt – Probando Servicios

6. Probando el Servicio con soapUI.

En este caso asegurarse de que estemos usando el Endpoint correcto, para ello podéis copiar el Endpoint que se muestra en WSO2 TryIt, en nuestro caso sólo son válidos las implementaciones de SOAP 1.2 y SOAP 1.1, estas son:

Probando Servicio con soapUI

Probando Servicio con soapUI

V. Observaciones

  • Si se muestra este error, es probable que hayas configurado incorrectamente el Proxy. Para solucionarlo prueba revisando la configuración del Proxy, concretamente el Endpoint. Una forma rápida de probarlo sería reemplazar el Endpoint que se muestra en TryIt por el real (no pasamos por WSO2 ESB), concretamente usar:
WSO2 TryIt - Error

WSO2 TryIt – Error

  • Durante el desarrollo de este blog hicimos unos cambios en nuestra web de demos, reemplazamos el puerto 8014 por 80, asi que si algo no funciona, intenta cambiar los puertos.

VI. Recursos usados:

Fin.

Espero que esto os haya servido.

@Chilcano

Tagged with: , , , , ,
Posted in ECM, SOA

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Archives
%d bloggers like this: