wso2 esb habilitar consola basedatos H2 y error UM_DIALECT not found

El Enterprise Service Bus WSO2, viene por defecto con una base de datos H2 interna (embedded), que la usa principalmente para el manejo del Registry (backup o registro de la configuración del ESB).

La base de datos H2 (http://www.h2database.com) es una base de datos ligera que viene con su propia consola de administración Web(H2 Console Server), que permite administrar la base de datos, y se accede en el puerto 8082 (por defecto). ejemplo:

http://localhost:8082/login.jsp

En “WSO2 Carbon” esta consola viene inhabilitada, hablamos WSO2 Carbon en forma generica porque aplica a la mayoria de las aplicaciones WSO2 incluido el ESB.

Para Habilitarla se debe “descomentar” la siguiente sección en el archivo de configuración “carbon.xml” que normalmente se encuentra en “optwso2esbrepositoryconf”:

    
        
        8082
        
        
        9092
        
        
        5435
        
        ${carbon.home}
    

Pero al reiniciar el servidor WSO2 puede dra el siguiente error:

ERROR – DatabaseUtil Database Error – Tabla “UM_DIALECT” no encontrada, Table “UM_DIALECT” not found

Esto porque durante la instalación por defecto no se crea la tabla “UM_DIALECT”, luego hay que forzar su creación iniciando el servidor con la opción “-DSETUP”:

sh wso2server.sh -Dsetup (Linux)

wso2server.bat -Dsetup (Windows)

Esto se requiere hacer solo una vez, el resto de las subidas dels ervidor pueden ser con el comando que estemos usando, o como servicio de Linux o Windows.

Luego se puede entrar en la consola Web (http://localhost:8082/login.jsp)

login h2 console wso2

Los datos para conectarse son (basados en configuración por defecto wso2):

  • Server Setting:  Generic H2 (Embedded)
  • Setting Name: xxx
  • Driver class: org.h2.Driver
  • JDBC URL: jdbc:h2:repository/database/WSO2CARBON_DB
  • User Name: wso2carbon
  • Password: wso2carbon

Otras referencias

Utilizar Oracle como base de datos WSO2

http://docs.wso2.org/display/Governance411/Setting+up+with+Oracle

Tutorial rapido de H2

http://wso2.org/blog/sumedha/3734

WAS NetWork Deployment en Pocas Palabras

Parte importante de la infraestructura (plataforma) que soporta a SOA y BPM son lo servidores de aplicaciones, y las aplicaciones sobre estas tecnologia demanda alta disponibilidad y un alto desempeño, por lo tanto deben contemplar una configuración adecuada. A continuación analizaremos los principales conceptos de una plataforma de este tipo, y especialmente nos centraremos en como lo maneja la solución de IBM.

El WebSphere Application Server Network Deployment (WAS ND) es una configuración que provee: alta disponibilidad (HA High Availability), tolerancia a fallas (FailOver), mejoras de desempeño (performance), mejoras de Seguridad, y escalabilidad (simplifica crecimiento servidores). Esto a través de:

§ manejo de clúster

§ balanceo de carga (WLM WorkLoad Management)

§ WebServices GateWay (versión 6.0)

§ manejo de cache (antememoria) para los recursos Web y J2ee (java).

§ Backup Clúster

WAS ND puede manejar varios nodos (servidores WAS), en cada nodo puede haber varios servidores de aplicaciones (lógicos), y en cada servidor varias aplicaciones.

WebSphere Application Server Network Deployment

Alta Disponibilidad a nivel de Servidor de Aplicaciones, hay que destacar que WAS-ND es una solución para manejo de clúster de servidores de aplicaciones, no para servidores Web (IBM Http Server) para este último existen otros productos o tecnología como IP Sprayer , o WebSphere Edge Server. Luego WAS-HD esta orientado a distribuir las solicitudes (request) J2EE: Servlet Request , y EJB request.

Clusters conjunto de servidores de aplicaciones (lógicos) que tienen instaladas las mismas aplicaciones, cada clúster es un clon de un servidor de aplicaciones (lógico), un clúster sirve para balanceo de carga (WLM), y alta disponibilidad.

Celda (cell) aquí corresponde al conjunto (dominio) de nodos según una agrupación lógica con el fin de facilitar la administración, por ejemplo sirve para sincronizar los clusters (clones de Serv. app lógicos).

Deployment Manager es el panel de control y de administración del ambiente WAS-ND, el Deployment Manager es un WAS de administración, pero “no” participa directamente en la distribución de los request (Servlet o EJB Request), luego este modulo no participa directamente en balanceo de carga, son otros los componeles de WAS-ND que participan en la distribución de los request: el “HTTP PlugIn”, y el “WLM PlugIn”. El Deployment Manager es el encargado de sincronizar la configuración y el deployment entre los distintos nodos y clusters, luego su participación es en tiempo de deployment.

WAS Network Deployment WorkLoad

HTTP PlugIn modulo que se asocia al “Http Server”, encargado de rutear y balancear los Servlet Request. Este plugin determina que clúster (servidor app lógico clonado) atenderá el request según un esquema de balanceo de carga.

Balanceo Carga del Http Plugin si el request tiene “session” lo rutea directamente al clúster que esta manejando dicha session (para que no se pierda), si no tiene “session” entonces selecciona un clúster según un criterio de balanceo que se basa: en un peso especifico para cada clúster (que el usuario administrador asigna) y la carga de trabajo que tiene en el momento cada clúster, según esquema de round robin (recorrido circular).

Persistencia de Session, y Alta Disponibilidad: la session no se pierde porque siempre se asigna el mismo clúster, pero que sucede si ese clúster se encuentra abajo (el proceso o el nodo no responden), entonces se le debe asignar otro clúster. El WAS-ND maneja distintos esquemas para la persistencia de la session en estos casos: in memory (sin persistencia), in database (sesión en la base de datos), y memory2memory (a través de mensajes JMS). El problema es que la persistencia de datos degrada el performance, y no asegura consistencia 100%, además en el caso de la base datos agrega un punto falla: sin base de datos no hay sesiones, y el sistema no va a funcionar. Sin persistencia de sesión puede haber mejor performance con el manejo de clusters, pero “no” va haber alta disponibilidad al 100%(el usuario va a tener que volver a logearse). La persistencia de sesión se puede configurar a nivel de aplicación, o a nivel servidor de aplicación lógico (se define en un app server, y sesión compartida por clústeres).

WLM PlugIn es el modulo que se encarga de rutear y balancear los “EJB request”. Este plugin determina que clúster atenderá el request de acuerdo a un algoritmo de balanceo. Este modulo se encuentra en todo Nodo del WAS ND, porque en este caso un nodo puede ser cliente o servidor (clúster) de los EJB.

Balanceo Carga WLM PlugIn si el request tiene una transacción, se asigna al mismo clúster que inicio la transacción, si el request corresponde a un objeto existente en un clúster se le sigue asignando es clúster, si el request corresponde a la creación de un objeto entonces se le asigna un clúster según un esquema round robin (mismo de Http PlugIn), pero con la posibilidad de manejo de la siguiente condición previa (preferencias): “in Process” (mismo clúster cliente), “Prefer Local” (mismo nodo cliente).

Persistencia de EJB, y Alta Disponibilidad: existen 3 tipos de EJB los Entity Beans, los Session Bean Stateless, y los Session Bean Stateful, en los 3 casos se mantiene su persistencia debido a que siempre se asigna el mismo clúster en el cual se crearon, pero cuando ese clúster no responde se le asigna otro clúster, ¿Que pasa entonces con la persistencia del EJB?, la respuesta depende del tipo de EJB: si es Entity Bean no se pierde porque esta se mantiene en la base de datos, si es un Session Bean Stateless tampoco hay problema porque no hay nada que perder (no maneja datos en la sesión), pero si es Session Bean Stateful en WAS 6.0 se debe configurar un esquema memory2memory de persistencia, y en WAS 5.0 simplemente se pierde el estado de este session bean (usuario debe volver a logearse).

Escalabilidad Vertical: definir múltiples clones de un servidor de aplicaciones (lógico) en la misma maquina. En ciertos casos un servidor de app. que se implementa con un solo proceso JVM no utiliza todo el poder de la CPU llevando la carga de la cpu al 100%, la escalabilidad vertical permite crear múltiple procesos JVM, utilizando todo el poder de CPU, y obteniendo failover a nivel de procesos.

WAS Network Deployment Vertical Clusters

Escalabilidad Horizontal: definir múltiples clones de un servidor de aplicaciones (lógico) en distintas maquinas, esta solución incrementa el performance.

WAS Network Deployment Horizontal Clusters

Que son los FrameWorks

FrameWork es un concepto sumamente genérico, se refiere a “ambiente de trabajo, y ejecución”, por ejemplo “.Net” es considerado un “framework” para desarrollar aplicaciones (Aplicaciones sobre Windows). En general los framework son soluciones completas que contemplan herramientas de apoyo a la construcción (ambiente de trabajo o desarrollo) y motores de ejecución (ambiente de ejecución).

Siguiendo con el ejemplo: “.Net” ofrece el “Visual Studio .net” (ambiente construcción o desarrollo) que le permite a lo desarrolladores construir aplicaciones, y su motor es el “.Net framework” que permite ejecutar dichas aplicaciones. El motor de “.net” es una anexo al sistema operativo (un componente que se instala sobre el sistema operativo), y que ahora viene incluido en la mayoría de los sistema operativos de Microsoft.

FrameWork puede ser algo tan grande como “.NET” o Java (también es un framework), pero también el concepto se aplica a ámbitos mas específicos, por ejemplo; dentro de Java en el ámbito especifico de aplicaciones Web tenemos los framework: Struts, “Java Server Faces”, o Spring. Estos frameworks de Java en la practica son conjuntos de librerías (API’s) para desarrollar aplicaciones Web , más librerías para su ejecución (o motor), y más un conjunto de herramientas para facilitar esta tarea (debuggers, ambientes de desarrollo como Eclipse, etc).

Otros ejemplos de frameworks para ámbitos específicos:

  • Ámbito: Webservices => FrameWork: Axis.
  • Ámbito: Interfaz de Usuario Web Dinámica => FrameWork: Ajax – DWR
  • Ambito: Procesos de Negocio => BPMS (WebSphere, AquaLogic, o Oracle)

Por eso antes se debe acotar que ámbito se desea “apoyar” con un FrameWork.

El ámbito más común es el de desarrollo de aplicaciones o sistemas (genérico), bajo el cual algunos buenos ejemplos de Framework sobre Java son:

  • Spring en combinación con Eclipse (eclipse es el equivalente a Visual Studio .NET pero para Java)
  • Struts en combinación con Eclipse.

Las anteriores se recomiendan porque son las mas “estándares”, es decir los más usados, y por lo tanto se encuentra un montón de documentación e información al respecto, además si se buscan proveedores que manejen esas tecnologías, se van a poder encontrar fácilmente, y por ser tecnologías que están en “boga” también existen mas herramientas e implementaciones, que van a facilitar el desarrollo de aplicaciones. Por otro lado son tecnologías abiertas, es decir. funcionan prácticamente sobre cualquiera HW y Sistema Operativo, y en esta caso si hablamos de aplicaciones Web, funcionan sobre cualquier Servidor de Aplicaciones conocido (IBM WebSphere, BEA WebLogic, o JBoss). Y en cuanto a costos prácticamente no hay costos de licencias: Spring, Struts, y Eclipse no tienen costos de licencias.

Y si no se maneja Java, y se viene de la escuela de Visual Basic la solución es

  • Net en combinación con “Visual Studio .net”

Referencias: