miércoles, 17 de diciembre de 2014

Componente Carbon UI para gestionar la clusterización (III) Final

Pues como pudieron ver en la entrada anterior, se mostró la visualización del plugin desarrollado para gestionar de manera gráfica la configuración necesaria para clusterizar las herramientas de la Suite de WSO2, hasta el momento se encuentra funcional solo que se está implementando las respectivas validaciones para no permitir que se introduzcan errores en los parámetros.

Ahora les daré una breve descripción de como es que se desarrollan los componentes visuales (Carbon UI) para la Suite de WSO2.Y cualquier apoyo que nos quieran brindar o duda que tengan nos pueden dejar sus comentarios.

Para el desarrollo de un Carbon UI Bundle Project es necesario que nos descarguemos el WSO2 Developer Studio, que no es más que un plugin desarrollado por WSO2 y que está montado en Eclipse, en este link se puede descargar el plugin por separado separado o un Eclipse en este caso la versión Kepler que ya trae instalado el plugins Developer Studio lo cual es lo que recomiendo para evitar algun problema de configuración que tengamos.

Para entender como se desarrolla un carbon UI Bundle pueden acceder a la documentación online del Developer Studio.

Para comprender como es que funciona el core de Carbon y como se puede personalizar les sugiero que sigan estos enlaces en los que se da una explicación bien detallada de como es que funciona y como está compuesto:
Una vez descargada la herramienta, podemos ejecutarla y visualizamos el Dashboard del Developer Studio como la imagen que verán a continuación:

Paso 1

 Damos click en la opción Carbon UI Bundle Project para poder crear un UI Bundle y seleccionamos la primera opción porque vamos a desarrollar uno desde cero: 

Paso 2
Después de darle siguiente en la captura anterior, nos encontraríamos con la siguiente pantalla, en la que definimos cual va a ser el nombre de nuestro proyecto, si deseamos crear una clase Activator que va a ser ejecutada una vez que se cargue nuestro bundle y se definen otros atributos necesarios para el mismo, además de definir el path donde se van a desplegar nuestras vistas:

Paso 3
Una vez que hayamos completado el paso anterior se especifica en quñe grupo y qué id va a tener nuestro bundle en maven:

Paso 4
Le damos Finish y nos quedaría un proyecto en nuestro workspace con una estructura similar a esta:

Paso 5
Como verán tenemos creada nuesta clase Activator en la que podemos definir que hacer en el momento en que se cargue nuestro bundle esto se define en el metodo:

    public void start(BundleContext bundleContext) throws Exception {
        Activator.context = bundleContext;
        //TODO Aquí podemos poner nuestra implementación.
    }

También tenemos creada nuesta carpeta clustermanager dentro de la carpeta web en la que estarán contenidas todas nuestras vistas, css, imágenes y js. 

En la carpeta META-INF encontrarán el fichero MANIFEST.MF y component.xml, en el primero se especifica todas las características relacionadas con el bundle y en el segundo es donde se le configura la región en la que va a estar situado el plugins en el menú de las herramientas así como cuales son las páginas de inicio del mismo yel recurso donde va a estar la internacionalización quedando este ejemplo como se muestra a continuación:

<?xml version="1.0" encoding="UTF-8" ?>
<component xmlns="http://products.wso2.org/carbon">
<menus>
        <menu>
            <id>clustermanager_menu</id>
            <i18n-key>clustermanager.managername</i18n-key>
            <i18n-bundle>com.wso2.clustermanager.mgt.ui.i18n.Resources</i18n-bundle>
            <parent-menu>configure_menu</parent-menu>
            <link>#</link>
            <region>region1</region>
            <order>20</order>
            <style-class>manage</style-class>
            <icon>../clustermanager/images/applications.gif</icon>
            <require-permission>/permission/protected/manage</require-permission>
        </menu>
        <menu>
            <id>clustermanager_configuration</id>
            <i18n-key>clustermanager.configuration</i18n-key>
            <i18n-bundle>com.wso2.clustermanager.mgt.ui.i18n.Resources</i18n-bundle>
            <parent-menu>clustermanager_menu</parent-menu>
            <link>../clustermanager/index.jsp</link>
            <region>region1</region>
            <order>14</order>
            <style-class>manage</style-class>
            <icon>../clustermanager/images/list.gif</icon>
            <require-permission>/permission/protected/manage</require-permission> 
        </menu>
    </menus>
</component>

La tendencia según la implementación que se ha visto y según lo que se propone por los desarrolladores de las herramientas es que en el plugin esté bien separada la interfaz de la lógica de negocio y que la comunicación entre la misma sea por lo general mediante el consumo de Servicios Web, pero en nuestro caso como no existe mucha más lógica que allá que leer y escribir un fichero XML por lo tanto no se hizo necesario esta separación, no obstante si usted cuando lo esté leyendo cree que no está totalmente correcto puede dejar su impresión y siempre serán bien recibidos sus comentarios :-).

Bueno vayamos al grano del asunto.

En nuestra página index.jsp que será la que se visualizará una vez que se haya dado click en el menú de la herramienta es donde se escribe todo el código html para lograr visualizar la información que se desea recoger y mostrar de la configuración que se encuentra en la sección clustering del fichero axis2.xml, para ello es necesario que respetemos las clases CSS que usan las herramientas para lograr mantener el estilo de la vista.

Se creó una clase nombrada Axis2HandlerXML.java que es la encargada de escribir y leer del fichero axis2.xml mediante el uso del DOM y SAX que es bastante sencilla debido al negocio que tiene que resolver.

La información que se recoge en la vista es enviada a un JSP que hace función de Servlet la que interactúa directamente con la clase Axis2HandlerXML.java para almacenar toda la información recogida de la vista y escribirla directamente en el fichero axis2.xml dentro de la sección de clustering, automáticamente se actualiza la vista.

Para evitar que cualquier usuario pueda realizar un cambio en la configuración de los servidores se utiliza el tag <require-permission/> en el fichero component.xml dentro del directorio META-INF, en nuestro caso estos son los permisos que usamos: <require-permission>/permission/protected/manage</require-permission>

Una vez que hayamos realizado todos los cambios en la configuración debemos reiniciar el servidor para que los mismos se hagan efectivos y lograr disfrutar de las ventajas y mejoras que nos brinda la clusterización.

Espero que les haya interesado el desarrollo de este plugins, como ven se puediera automatizar el proceso de configuración de muchas funcionalidades de las herramientas para evitar que introduzcamos errores en los mismos y para facilitar el proceso que en no pocas ocasiones se torna algo engorroso.

Nos vemos pronto ;-)



lunes, 6 de octubre de 2014

En la entrada anterior vimos cómo implementar usando el ESB de WSO2 un problema planteado en StackOverFlow. En esta entrada veremos con más nivel de detalle la solución propuesta y terminaremos la implementación pues nos faltó realizar la transformación para que el mensaje de salida cumpliera con el WSDL del servicio proxy desarrollado.

El WSDL del servicio proxy visto a través del editor gráfico del Eclipse luce como sigue (nos centraremos en los mensajes de entrada y salida):

Mensaje de entrada
mensaje_entrada

Mensaje de salida:
mensaje_salida

Como se puede apreciar la salida debe ser un listado de direcciones y cada dirección debe tener los elementos del complexType addressType.

La parte que nos interesa del servicio proxy que se implementó es la del flujo de salida, que es donde se reciben los mensajes y estos son agregados para luego pasar a una transformación.
De la entrada anterior a esta se hicieron pequeños cambios en la secuencia así que la mostramos nuevamente.


<outSequence>
 <property name="root" scope="default">
 <root:rootelement xmlns:root="http://ws.wso2.org/dataservice"/>
 </property>
 <aggregate id="iterate1">
 <completeCondition>
    <messageCount min="-1" max="-1"/>
 </completeCondition>
 <onComplete xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
    xmlns:add="http://ws.wso2.org/dataservice"
    xmlns:s11="http://schemas.xmlsoap.org/soap/envelope/"
    expression="//add:Addresses/add:Address"
    enclosingElementProperty="root">
    <log level="full"/>
 </onComplete>
 </aggregate>
 <xslt key="conf:/xslt/Tranformacion_DS_to_ESB.xsl"/>
 <send/>
</outSequence>


Lo primero diferente que se puede apreciar es que hemos creado una property de nombre root que está asociada a un namespace y que posee un elemento rootelement. Esta property la necesitaremos pues cuando los mensajes son agregados el resultado del mediador aggregate no posee un nodo raíz, así que se lo ponemos usando esta propiedad y el parámetro enclosingElementProperty="root" que pueden ver en el mediador aggregate. Ambos nos permiten generar un XML válido para que sea procesado sin problemas por la transformación. Para más información pueden ver esta pregunta en stackoverflow.


La transformación entonces sería la siguiente:


<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:fn="http://www.w3.org/2005/xpath-functions" xmlns:a="http://ws.wso2.org/dataservice" xmlns:b="http://www.example.org/Address/" exclude-result-prefixes="a fn xs">
 <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
 <xsl:template match="/">
  <b:getAddressResponse>
   <xsl:for-each select="//a:rootelement/a:Address">
     <address>
      <address>
       <xsl:value-of select="a:address"/>
      </address>
      <partybranchid>
       <xsl:value-of select="a:partybranchid"/>
      </partybranchid>
      <clientid>
       <xsl:value-of select="a:clientid"/>
      </clientid>
     </address>
   </xsl:for-each>
  </b:getAddressResponse>
 </xsl:template>
</xsl:stylesheet>


Como pueden observar a la hora de obtener los nodos ya tenemos en cuenta que existirá un elemento raíz “rooelement” y basicamente lo que hacemos es iterar por cada nodo Address y generar nodos address los cuales estarán contenidos dentro de un nodo raíz getAddressResponse.


Ya con esta transformación se logra que el mensaje de salida cumpla con el WSDL del servicio proxy, lo cual pueden comprobar usando el SOAPUI y validando contra el Schema del servicio.


Espero les sea de utilidad.

jueves, 25 de septiembre de 2014

Introducción al ESB de WSO2 a través de ejemplos prácticos.V

En esta entrada quiero mostrarles una pequeña implementación motivada a partir de una pregunta lanzada en StackOverFlow.
Basicamente se quiere obtener a partir de la consulta de un servicio de datos un listado de IDs y con ese listado se desea iterar sobre el mismo y por cada elemento lanzar una llamada a otro servicio de acceso a datos, y las respuestas obtenidas unirlas para devolver una única respuesta al cliente.
Veamos como se hace.

El servicio proxy queda como sigue:
<?xml version="1.0" encoding="UTF-8"?>
<proxy xmlns="http://ws.apache.org/ns/synapse"
       name="AddressProxy"
       transports="https,http"
       statistics="disable"
       trace="disable"
       startOnLoad="true">
   <target>
      <inSequence>
         <property xmlns:p="http://www.example.org/Address/"
                   name="clientid"
                   expression="//p:getAddress/clientid"
                   scope="default"
                   type="STRING"/>
         <sequence key="conf:/sequencesStackOverFlow/getmpartybranch"/>
      </inSequence>
      <outSequence>
         <aggregate>
            <completeCondition>
               <messageCount min="-1" max="2"/>
            </completeCondition>
            <onComplete xmlns:add="http://ws.wso2.org/dataservice"
                        expression="//add:Addresses/add:Address">
               <send/>
            </onComplete>
         </aggregate>
      </outSequence>
   </target>
   <publishWSDL key="conf:/wsdls/Address.wsdl"/>
   <description/>
</proxy>



Como pueden ver en la secuencia de entrada primero guardo en una property el valor del clientid que es la entrada del servicio proxy, y luego hago una llamada a la secuencia getmpartybranch, que está en el registro del ESB y que veremos a continuación.


<sequence xmlns="http://ws.apache.org/ns/synapse">
   <payloadFactory media-type="xml">
      <format>
         <dat:getmpartybranch xmlns:dat="http://ws.wso2.org/dataservice">            
            <dat:clientid>$1</dat:clientid>         
         </dat:getmpartybranch>
      </format>
      <args>
         <arg xmlns:ns="http://org.apache.synapse/xsd" expression="get-property('clientid')" evaluator="xml"></arg>
      </args>
   </payloadFactory>
   <send receive="conf:/sequencesStackOverFlow/iterOvermpartybranch">
      <endpoint>
         <address uri="http://127.0.0.1:9765/services/mpartybranch"></address>
      </endpoint>
   </send>
</sequence>



En esta secuencia creo un nuevo mensaje para consultar el servicio de acceso a datos que me dará dado el clientid el listado sobre el cual deberé iterar. Este resultado lo obtengo de invocar al servicio http://127.0.0.1:5555/services/mpartybranch y será enviado a la secuencia iterOvermpartybranch, que veremos a continuación.


<sequence xmlns="http://ws.apache.org/ns/synapse">
   <iterate xmlns:ns="http://org.apache.synapse/xsd" xmlns:ds="http://ws.wso2.org/dataservice" expression="//ds:DataCollection/ds:Datalist" id="iterate1" sequential="true">
      <target>
         <sequence>
            <property name="partybranchid" expression="//ds:partybranchid/text()" scope="default" type="STRING"></property>
            <property name="clientid" expression="//ds:clientid/text()" scope="default" type="STRING"></property>
            <log>
               <property name="PARTYID" expression="get-property('partybranchid')"></property>
               <property name="CLIENTID" expression="get-property('clientid')"></property>
            </log>
            <payloadFactory media-type="xml">
               <format>
                  <dat:getselect_addresses xmlns:dat="http://ws.wso2.org/dataservice">                     
                     <dat:objectid>$1</dat:objectid>                     
                     <dat:clientid>$2</dat:clientid>                  
                  </dat:getselect_addresses>
               </format>
               <args>
                  <arg expression="get-property('partybranchid')" evaluator="xml"></arg>
                  <arg expression="get-property('clientid')" evaluator="xml"></arg>
               </args>
            </payloadFactory>
            <log level="full"></log>
            <send>
               <endpoint>
                  <address uri="http://127.0.0.1:9765/services/getAddress" format="soap12"></address>
               </endpoint>
            </send>
         </sequence>
      </target>
   </iterate>
</sequence>



En  el mediador iteramos para llegar a cada nodo //ds:DataCollection/ds:Datalist y obtenemos las propiedades que vamos a utilizar, estas las imprimimos en consola para comprobar que efectivamente el servicio está funcionando. Algo que es muy útil cuando lo estamos desarrollando.


Luego creamos otro mensaje usando el mediador payload factory y lo enviamos al servicio de datos correspondiente. En base de datos tengo 2 tuplas en mi ejemplo, así que se realizaría 2 recorridos y se consultaría 2 veces al servicio http://127.0.0.1:9765/services/getAddress


La respuesta de esta secuencia entraría por la secuencia de salida del servicio proxy, la cual pueden ver en la definición del servicio. En la secuencia se usa el mediador aggregate para agregar las respuestas. Solo queda pendiente realizar una transformación para cumplir con el formato del mensaje de salida. Esto lo veremos en la siguiente entrada.

jueves, 11 de septiembre de 2014

WSO2 Identificando y solucionando errores.


Cuando se comienza a trabajar en soluciones de integración usando un ESB el tema de Troubleshooting es fundamental tenerlo claro.

Para aquellos que se enfrenta a desarrollos de este tipo usando la suite de WSO2 y su ESB les recomendamos descargar este PDF, que les dará una guía muy útil sobre como identificar los problemas y proceder a resolverlos eficientemente.

Los principales puntos que aborda son:


  • Troubleshooting Techniques
    1. Debug logs
      Trace logs
  • Monitoring Messages
    1. TCPMon
      Wire Logs
  • Solutions for Commonly Occurring Exceptions
  • Troubleshooting Timeout Issues
  • Mediation Fault Handling

Esperamos que les sea de utilidad.

Tomado de: http://wso2.com/library/articles/2014/05/wso2-esb-a-guide-to-troubleshoot/

miércoles, 3 de septiembre de 2014

WSO2 con un IDE en la Nube.


WSO2 no deja de sorprendernos y como parte de su solución en la nube "WSO2 Cloud" tenemos la  funcionalidad de poder editar nuestro código y subir los cambios desde un repo temporal de git en la nube hacia el repo remoto. Nos provee de un autocompletamiento de código que si no está al nivel de los IDEs a los que estamos acostumbrados, si para realizar un trabajo rápido o un cambio menor cumple con las espectativas.

Para llegar a esta pantalla del IDE nos vamos a un proyecto en la solución Cloud y seleccionamos del menú de la derecha la opción "Repos & Builds".

De ahí vamos al final y damos clic en el botón "Edit Code", y ya con esto tendremos acceso al IDE y poder realizar los cambios que queramos.

Espero les sea de utilidad y les agilice el desarrollo, es una buena opción para aquellos que se dan cuenta de un cambio a última hora y no tienen a mano su PC o Laptop con su IDE de preferencia. :-D

martes, 2 de septiembre de 2014

WSO2 ESB y el manejo de los logs para la detección de errores

En esta entrada quisieramos mostrarles algo que es básico en cualquier suite para desarrollar soluciones de integración y es la forma en que capturamos los logs generados por los eventos que ocurren con los servicios desplegados.

En el WSO2 ESB existen 3 formas de capturar los logs de los servicios proxy:

  1. Usando el mediador log, dentro de la misma configuración del servicio proxy, algo muy útil durante el desarrollo y para los temas de troubleshooting.
  2. Generando los logs propios del servicio proxy en un fichero a parte del de los logs del propio ESB. A veces dada la cantidad de logs generados se hace un poco complicado seguirle la traza a lo que ocurre con determinado servicio. Esto es muy útil en los ambientes de producción.
  3. Extendiendo las funcionalidades del Synapse, framework base del WSO2 ESB, para incluir lo que se conoce como Observadores. Los cuales se programan para capturar la información que querramos y son adjuntados al servicio proxy en cuestión, especificando incluso el fichero de salida hacia donde se escribirán los logs.

Veamos ahora como podemos usar cada una de estas formas. Para ello usaremos el servicio JAX-WS desplegado en el WSO2 AS de la entrada anterior  y crearemos un servicio proxy.

El servicio JAX-WS lo pueden ver en la siguiente imagen:



El servicio proxy que creamos para la primera forma de captura de los logs lo pueden ver en la siguiente imagen.



Así los logs capturados se pueden ver en la consola o en el fichero de los logs en el ESB, como se muestra en la siguiente imagen.



La segunda forma de capturar los logs, aunque sería mejor decir que es de separar los logs que nos interesan de los logs propios de la ejecución del ESB, es modificar el fichero log4j.properties y añadir las siguientes líneas:

# Configuracion de appender para capturar los logs generados por el servicio UserCollectionProxy
log4j.category.SERVICE_LOGGER.UserCollectionProxy=INFO, PROXY_APPENDER
log4j.additivity.PROXY_APPENDER=false
log4j.appender.PROXY_APPENDER=org.apache.log4j.DailyRollingFileAppender
log4j.appender.PROXY_APPENDER.File=${carbon.home}/repository/logs/${instance.log}/wso2-esb-UserCollectionProxy${instance.log}.log
log4j.appender.PROXY_APPENDER.Append=true
log4j.appender.PROXY_APPENDER.layout=org.apache.log4j.PatternLayout
log4j.appender.PROXY_APPENDER.layout.ConversionPattern=%d{HH:mm:ss,SSS} [%X{ip}-%X{host}] [%t] %5p %c{1} %m%


De esta manera se creará un fichero de nombre wso2-esb-UserCollectionProxy.log que tendrá los logs generados solo por el servicio proxy indicado.

La tercera variante es una implementación más general de la segunda. En la variante 2 para cada servicio debíamos realizar una modificación en el fichero log4j.properties y esto es conveniente cuando no nos interesa observar los logs de todos los servicios si no de algunos en particular. Pero cuando nos interesa observar los logs de todos los servicios, entonces la 3ra opción es la mejor.

Básicamente consiste en implementar un observer que extiende de la clase AbstractSynapseObserver de synapse y posee un método: private void setLogger(ProxyService proxy) throws IOException

Este método es donde se implementa el comportamiento tal y como se puede observar en la siguiente clase java.



package org.jorgesoftdev;

import org.apache.synapse.config.AbstractSynapseObserver;
import org.apache.synapse.core.axis2.ProxyService;
import org.apache.log4j.DailyRollingFileAppender;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.PatternLayout;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

import java.io.IOException;

/**
 * Created by Jorge on 30/08/14.
 */
public class CustomSynapseObserverForLogging extends AbstractSynapseObserver  {

    private static final Log log = LogFactory.getLog(CustomSynapseObserverForLogging.class);

    public void proxyServiceAdded(ProxyService proxy) {
        try {
            setLogger(proxy);
        } catch (IOException e) {
            log.error("CustomProxyObserver could not set service level logger for the proxy : " + proxy.getName(), e);
        }
    }

    public void proxyServiceRemoved(ProxyService proxy) {
        try {
            setLogger(proxy);
        } catch (IOException e) {
            log.error("CustomProxyObserver could not set service level logger for the proxy : " + proxy.getName(), e);
        }
    }

    private void setLogger(ProxyService proxy) throws IOException {
        String filename = "repository/logs/" + proxy.getName() + ".log";
        String datePattern = "yyyy-MM-dd";
        String SYSTEM_LOG_PATTERN = "[%d] %5p - %x %m {%c}%n";
        PatternLayout layout = new PatternLayout(SYSTEM_LOG_PATTERN);
        DailyRollingFileAppender appender = null;
        appender = new DailyRollingFileAppender(layout, filename, datePattern);
        Logger proxyLogger = Logger.getLogger("SERVICE_LOGGER." + proxy.getName());
        proxyLogger.setLevel(Level.ALL);
        proxyLogger.setAdditivity(false);
        proxyLogger.addAppender(appender);
    }

}




Para implementar la tercera variante he creado un proyecto maven con esta clase implementada, he generado el jar y lo he copiado en la carpeta [ESB_HOME]\repository\components\lib\

Luego he ido al fichero [ESB_HOME]\repository\conf\synapse.properties y he actualizado la línea:
synapse.observers=org.wso2.carbon.mediation.dependency.mgt.DependencyTracker

con la línea:

synapse.observers=org.jorgesoftdev.CustomSynapseObserverForLogging

Luego de reiniciar el servidor en el directorio [ESB_HOME]\repository\logs\ aparecen los ficheros [nombre_servicio_proxy].log con los logs de los respectivos servicios, cada uno por separado.


Cada variante depende de las necesidades de los desarrolladores,  del ambiente en el que se esté ejecutando el ESB, pero al menos a nuestro equipo para un ambiente de desarrollo una combinación de las variantes 1 y 3 es la mejor opción.

La información utilizada para esta entrada fue obtenida de aquí.

Esperamos les sea de utilidad.

lunes, 1 de septiembre de 2014

Introducción a WSO2 Cloud. Nueva propuesta de WSO2.

Hola a todos.

En junio, durante el evento WSO2 Con - Europe 2014 en Barcelona se lanzó la versión beta del servicio WSO2 Cloud de la empresa WSO2. Esta fue la nueva iniciativa luego de la entrega por parte de la empresa a Apache de la solución para la nube StratosLive.

Este nuevo servicio es sumamento fácil de usar. Si ya tienes una cuenta en wso2.com puedes usarla para acceder al mismo, en caso contrario y a través de esta pantalla puedes registrarte y acceder.


La primera prueba que hice fue pasar la implementación de un servicio web desarrollado en jax-ws para esta nueva plataforma y básicamente luego de autenticarse aparece la siguiente pantalla.


Ahí se selecciona App Cloud pues nuestro servicio web estará dentro de un war, ya cuando entramos a la UI debemos crear una aplicación web y esto automáticamente nos provee de un repositorio git y un espacio en jenkin para el despliegue de la aplicación.

Usando el proyecto Example3_JAX-WS expuesto en esta entrada hice los cambios necesarios en el mismo para moverlo al nuevo repo git, cuidando de no modificar los parámetros del pom.xml pues aunque les compile abajo, cuando se trate de subir al repo online les dará problemas.



En nuestro caso usamos SourceTree como cliente GIT para clonar el repo, implementamos los cambios en el servicio y automaticamente cuando se hace un commit al repo online se lanza la tarea en jenkin de compilar y desplegar la aplicación.

Ya con la aplicación desplegada y corriendo usamos el SOAPUI para crear un proyecto y probar el consumo del servicio web desarrollado con JAX-WS.

Para cerrar, revisando los blogs de los desarrolladores de WSO2 me encontré con esta entrada donde se hace un resumen de las principales funcionalidades de este servicio:

WSO2 App Cloud

  • Create applications from scratch - JSP, Jaggery, JAX-WS, JAX-RS
  • Upload existing web applications - JSP, Jaggery
  • Database provisioning for your apps
  • Life cycle management for your app - Dev, Test and Prod environments
  • Team work - A team can collaboratively work on the app
  • Issue tracking tool
  • A Git repository per each application and a build tool.
  • Cloud IDE - For your app development work
  •  And more...

WSO2 API Cloud

  • Create APIs and publish to API store (a store per tenant)
  • Subscribe to APIs in the API store
  • Tier management
  • Throttling
  • Statistics
  • Documentations for APIs

lunes, 25 de agosto de 2014

Componente Carbon UI para gestionar la clusterización (II)

Pues bien como les comenté en la entrada anterior, aquí les dejaré unas capturas de pantalla del componente y una breve descripción de las secciones en las que fui dividiendo el mismo para lograr una mayor usabilidad en el momento de interactuar con el plugin.

Esta es una vista general del plugin:


Para mejorar la usabilidad como les comenté anteriormente fui dividiendo la interfaz por regiones que se corresponden con las regiones del anterior blog. A continuación se las iré mostrando.

Para acceder al mismo, se encuentra ubicado en esta región del menú:


Para activar el clúster y definir la clase que vamos a utilizar para su gestión sería en el siguiente captura:

Para configurarle algunos parámetros que son necesarios a tener presentes en la configuración sería en esta sección:


Para la configuración de propiedades necesarias en esta sección:


Y por último para definir si el host va a ser el administrador del grupo y los grupos que van a intervenir en el clúster diseñe la última sección:


Espero que hasta el momento les haya gustado la interfaz propuesta para el plugin Carbon UI.

Componente Carbon UI para gestionar la clusterización (I)


Como plantea el título de la entrada, creo que hoy en día es muy poco probable que vayamos a usar la Suite de WSO2 sin que clustericemos todas o partes de las herramientas que conformaran nuestra Arquitectura de Infraestructura.

Las herramientas de la plataforma WSO2 realizan el proceso de configuración de la clusterización a través de un fichero en formato XML específicamente en el fichero axis2.xml que se encuentra en WSO2_HOME/repository/conf/axis2/axis2.xml, donde están predefinidos los parámetros que activan su funcionabilidad; sin embargo, la suite no ofrece facilidades para la configuración de este fichero de forma gráfica, el que si bien posee una estructura sugerente, sólo puede actualizarse de forma manual. Se requiere conocimientos avanzados en ficheros con formato XML y por supuesto de clustering.
En ese archivo existen una serie de etiquetas XML correspondientes a los servicios web, la seguridad, los puertos que utilizará la herramienta y los protocolos que estarán activados.

En la sección de configuración del clúster en el fichero axi2.xml, consta de cuatro partes fundamentales: 

Nodo Administrador: Es la que se encarga de la funcionalidad de gestión de los nodos que formarán parte del clúster.


Grupo Administrador: Es la parte que se encarga de administrar cada grupo que es gestionado por el clúster.

Miembros: Es la parte encargada de especificar los miembros estáticos o conocidos en clúster, debiendo especificarse el nombre de host y el puerto principal de estos miembros. 

Agente de Clusterización: Esta parte es la responsable de inicializar todas las funciones relacionadas con el clúster y de los nodos miembros que formarán parte del mismo. 

Para encontrar una mayor descripción de las elementos que componen la configuración de la clusterización de la Suite pueden revisar este enlace Clustering.

Como pueden ver son muchos parámetros a tener en cuenta en el momento de poner en funcionamiento varias herramientas clusterizadas, por lo que me di a la tarea de implementar un plugins Carbon UI para facilitar este proceso, quitándole la responsabilidad al usuario de cometer posibles errores de configuración si se editara de manera manual el fichero de configuración.

En la siguiente entrada verán la propueta de diseño gráfico de la solución.


jueves, 22 de mayo de 2014

Exponiendo datos de nuestra BD a través de APIs con WSO2


En esta entrada quiero mostrar cómo usando varios elementos ya tratados en el blog podemos muy fácilmente exponer nuestros datos a través de APIs y realizar operaciones CRUD sobre ellos.

En esta entrada vimos como crear un servicio de acceso a datos muy fácilmente y en tan solo 3 minutos, que incluyera las operaciones CRUD necesarias para manipular la información de una tabla.

Luego en esta otra entrada vimos como podíamos exponer dichas operaciones de una forma RESTful, lo que en este caso la información la obteníamos como un XML y no en formato JSON.

Así que en esta otra entrada entonces se mostró como podíamos indicarle a la herramienta de WSO2 AS que queríamos también mostrar la información como un JSON.

Hasta aquí tenemos un servicio de acceso a datos desplegado en el WSO2 AS que puede ser consumido por SOAP o por REST y en este último caso las respuestas las puede dar tanto en POX como en JSON, pero eso no es todo.

WSO2 está apostando fuerte por el tema de las APIs, y con su herramienta WSO2 API Manager se ha posicionado entre las mejores empresas en brindar soluciones de este tipo.

Guiándonos por esta otra entrada podemos ir directamente al paso 2 y registrar nuestro servicio en el WSO2 API Publisher para luego gestionarlo en el WSO2 API Store y generar las claves de acceso que nos permitirán probarlo, tal y como se explica en el paso 3.

Ya aquí podemos usar curl o un cliente RESTful para consumir la API siempre usando el token de autorización generado por el API Store.

Por último si deseamos monitorizar el consumo del API solo basta configurar el BAM para que se establezca una conexión entre el AM y el BAM tal y como se muestra aquí.