Ago 13

La ruta que se ha definido en Arquitectura de Sistemas para el desarrollo de soluciones o sistemas informáticos es SOA (Arquitectura Orientada a Servicios), la cual esta basada en la implementación de Servicios de Negocio, esto es; bloques funcionales de negocio que se pueden integrar, y compartir en distintas aplicaciones. La principal tecnología para implementar servicios SOA es WebServices, y es la que se recomienda, se promueve y exige, pero hay que tener cuidado, porque fácilmente se puede cometer errores, sino se asumen los siguientes principios:: 

·         Un Webservice no necesariamente es un Servicio SOA. 

·         Un Servicio SOA no necesariamente tiene que ser implementado como WebService. 

Para que un WebService se considere un Servicio SOA, debe cumplir con los estándares SOA, a grandes rasgos: debe corresponder a una funcionalidad del Negocio bien acotada (self cointained), independiente de la implementación tecnológica e independiente de los sistemas operacionales que lo soportan (loose coupling), y además debe poder ser compartido y reutilizado por otros procesos o sistemas (reuse). Por otro lado, un servicio SOA podría ser implementado con otras tecnologías, como HttpService, Mensajería, Ajax (DWR), etc, pero nuevamente para ser considerado como tal, debe cumplir los estándares SOA. 

SOA es una tecnología madura, y respaldada por los principales expertos y empresas, por ejemplo Gartner dentro de su HypeCycle (diagrama de madurez) ya el 2009 lo tiene entrando al nivel de plena productividad (plateau of productivity). (img1) 

Además Gartner la tiene dentro de las tecnologías Top Ten en la industria de Seguros (ref. “Gartner Outlines Top 10 Technologies to Impact Property and Casualty Insurance” – Harris Ferrante  - Marzo 2010).  

IBM se refiere a SOA como “la plataforma que alinea el Negocio con Tecnología” (IBM Smart SOA – Enero 2010, http://www-01.ibm.com/software/solutions/soa/smartsoa/), y ha desarrollado toda una metodología y set de herramientas para apoyar SOA.  

Oracle indica “SOA se ha movido de la sobreespectativa (hype) a una completa aceptación como estrategia de Tecnología (TI) para entregar soluciones de Negocio” (Oracle SOA Governance Solution -2009, http://www.oracle.com/technologies/soa/docs/soa-governance-datasheet.pdf). 

¿Y porque se debe implementar SOA usando WebServices?, en términos simples, porque es el estándar de facto, Webservices es una tecnología que opera en .Net y Java, que la mayoría de los motores de servicios contempla (bases de datos, ESB, ETL, etc), que las herramientas de diseño, desarrollo, y testing soportan, y que las grandes aplicaciones también manejan (CRM, ERP, SAP, SalesForce, etc.). Gartner de hecho tiene los webservices situados en “plena productividad” para Arquitectura de Aplicaciones  (ver “Hype Cycle for Application Architecture, 2009“, http://www.gartner.com/DisplayDocument?id=1077812).  

Los servicios SOA sirven para integrar sistemas, para construir procesos de negocio (orquestación de servicios), pero principalmente sirven para implementar aplicaciones Web. IBM lo ha promovido en el desarrollo de aplicaciones Web, en combinación con frameworks como Struts, Spring, lo ha promovido para el desarrollo de aplicaciones web “rich” (“Build rich Java Web applications with Apache Wink and Ajax“ – Febrero 2010) , y para el desarrollo  de aplicaciones Web dinámicas (“Build RESTful Web services and dynamic Web applications with the multi-tier architecture” –Junio 2009). Oracle lo contempla en su Arquitectura de aplicaciones; Oracle ADF. 

  Arquitectura Orientada a Servicios

Pero como toda tecnología, los WebServices pueden ser mal implementados, si no se siguen los estándares y buenas prácticas, que existen para el desarrollo de Servicios. Uno de los problemas más comunes es pretender que toda funcionalidad de un sistema se puede convertir en un servicio (WebService), y la verdad es que el enfoque es otro, las funcionalidades de Negocio, que pueden involucrar más de un sistema, son las que se deben convertir en Servicios. 

Se han mencionado buenas prácticas y antipatrones para el desarrollo de servicios, las buenas prácticas apuntan a como se deben hacer las cosas, y los antipatrones apuntan a mostrar en que problemas no debemos caer, ejemplos: ·         Servicio se nombra para maximizar consumo.Erróneo: insertarRegistroCliente()Correcto: crearNuevoCliente() 

·         Servicio tienen parámetros abultados (coarse grained)

Erróneo : crearNuevoCliente (rut, nombre, apellidos, email, fono, direccion)

Correcto: crearNuevoCliente (objetoCliente) 

·         Servicio encapsula detalles de implementación.

Erróneo : crearNuevoClientePsoft (schemaOracle, registroTablaCliente )

Correcto: crearNuevoCliente (objetoCliente) 

·         AntiPatrón, Servicio Parlanchines (Chatty Services)

Erróneo: consultaUF()

Correcto: (NO implementar ese tipo funciones como servicios) 

·         IBM SOA Antipatternshttp://www.ibm.com/developerworks/webservices/library/ws-antipatterns/ 

·         IBM SOA realization, Service design principleshttp://www-128.ibm.com/developerworks/webservices/library/ws-soa-design/ 

·         SOA Anti-Patterns: How Not to Do Service-Oriented Architecturehttp://www.oracle.com/technology/architect/entarch/pdf/oea_soa_antipatterns.pdf ·        

·         Best Practices for Web services: Web services performance considerationshttp://www.ibm.com/developerworks/webservices/library/ws-best9/index.html 

¿Pero solo basta con conocer los estándares y buenas prácticas para no equivocar el camino en la implementación de servicios y para lograr los beneficios que promete SOA?;  la verdad es que NO, se necesita más que eso, se pueden saber los patrones de diseño SOA, pero aun no interiorizarlos, o no poder lograrlo con tecnologías especificas como Java, porque solo la experiencia real, y la supervisión continua en la primeras etapas logra que el área de TI adopte de forma adecuada SOA, y aquí es donde entra a jugar otro enfoque; “SOA Governance” , que corresponde a implementar el soporte en procedimientos, metodologías, y herramientas, para lograr un SOA exitoso: 

  • SOA Governance ya no es una opción, es un imperativo, sin esta administración (governance) el retorno de la inversión es mucho menor, y todo proyecto SOA estará en riesgo (ref. “Service Oriented Architecture Craves Governance” - Gartner).
  • De hecho sin él (SOA Governance), muchas iniciativas SOA fallan” (“Oracle SOA Governance Solution” – 2009).

Si la implementación de Servicios SOA falla, entonces es determinante la implementación de un “SOA Governance”, y el primer y mas importante paso en Governance es establecer una área especializada; el “Centro de Excelencia SOA” (SOA COE), que permite enseñar y supervisar la adopción de SOA en una Empresa, un área clave liderada por Arquitectos de Sistemas. 

Ago 13

top ranking sitio Arquitectura de SistemassoaAgenda.com a escalado de forma considerable dentro de los sitios de Articulos de Interes en materias de Arquitectura de Sistemas, Arquitectura Orientada a Servicios (SOA) y Administración de Procesos de Negocio (BPM), estableciendose como referente en estos temas.

En Alexa.org estamos en la posición 200.000 a nivel de españa y 3.500.000 a nivel mundial, superando a muchos sitios de Tecnologia (TI) de varios paises.

Abr 23

A continuación veremos la problematica de las empresas en aplicar el enfoque SOA, como lo resuelve SOA Governance, y una guia practica de llevar Governance en una Empresa:

SOA Governace un enfoque práctico

Abr 19

A continuación veremos conceptos de Servicios SOA y WebServices, y algunos patrones de diseño de servicios SOA.

Servicios bajo SOA

Abr 19

Un paso importante en SOA es establecer un ambiente de colaboración. Un lugar donde se deje registro de todo el ciclo de visa de un Servicios, y donde todos los involucrados en el proceso de implementación administración de un servicio encuentren la información que necesitan. Aqui presentaremos un ejemplo redMine

Portal de Colaboración SOA

Jun 05

DWR (Direct Web Remoting)es una librería Javascript que permite el uso de Ajax (Asynchronous JavaScript and XML) de forma mucho más simple (Este artículo asume que se entiende los conceptos de Ajax, y de Java).

DWR es una librería mas orientada a apoyar la integración, que a apoyar la parte gráfica, de hecho si se buscan Widgets (objetos gráficos) esta no es la librería, pero por otro lado lo fuerte de DWR es que permite “publicar” fácilmente funcionalidad de clases Java para accederlas vía Javascript.

Luego si nuestra funcionalidad o lógica de negocio esta en Java, DWR es una de la mejores opciones para aprovecharla, ya que usar una clase Java que tenemos en un servidor de aplicaciones vía Javascript es tan fácil como definir un archivo de configuración en el servidor.

Ahora si se requiere además darle una interfaz más rica (rich interface) a los usuarios, es bueno combinar DWR con otras librerías Ajax como YUI (Yahoo User Interface), JQuery, Prototype, Scriptaculous, Dojo, o Spry.

Con Ajax se terminan las paginas JSP, o ASP (o deberían terminarse), porque Ajax solo necesita Javascript y HTML para la parte de presentación, esto lo explicaremos mejor en otro articulo, pero por ahora créannos. Y con DWR ni siquiera son necesarios los Servlets, esto en el sentido de que no se necesitan desarrollar servlets para implementar la lógica de negocio, porque DWR si internamente esta basado en Servlets, en otras palabras gracias a DWR no necesitamos implementar nuestros servlets sino solo necesitamos clases Java (POJO).

Si se conoce la tecnología Axis, que permite publicar clases Java como Webservices, este es el símil para publicar clases Java como objetos Ajax (objetos Javascripts), de hecho es muy fácil publicar con DWR un servicio realizado para Axis. Incluso las buenas prácticas o blueprints de Axis para publicar clases como Webservices se aplican totalmente para publicar clases para Ajax., ya que hay que tener los mismos cuidados en cuanto a seguridad y manejo de desempeño (performance).

La definición oficial de DWR es:

DWR permite a Javascript (en un Browser) interactuar con las clases Java en un Servidor, y ayuda a manipular las paginas Web con los resultados.

Si, porque otra característica importante de DWR es que ofrece funcionalidades Javascript que permiten fácilmente manipular el HTML de la página: como obtener los datos de un formulario (HTML Form), o de cualquier otro tag HTML, o setear fácilmente los valores de los tags HTML, ademas aporta facilidades para clonar tags, lo que permite por ejemplo crear nuevas filas (rows) en una tabla (HTML Table), muy útil para mostrar una consulta. DWR no nos provee ningun objeto grafico prehecho, pero si nos permite la flexibilidad para hacer cualquier cosa con el HTML.

Bueno basta de conceptos y vamos directo al código.

Hemos llamado a este tutorial “el Mejor”, solo para llamar su atención, pero la verdad es que es bastante bueno, por lo siguiente:

  • Es lo mas simple posible, tiene lo justo y necesario para entender el concepto principal de DWR, y como funciona.
  • Esta actualizado, otros ejemplos están basados en versiones anteriores de DWR.
  • Esta completo, otros ejemplo ponen solo parte del código.
  • Usa clases y colecciones de clases (Collection) como parámetros de entrada y parámetros de salida, que es lo que típicamente se va a usar en un sistema real, otros ejemplos usan datos más básicos. De esta forma también se muestra como se manejan las colecciones y las clases en Javascript.

Tutorial DWR en 10 Simples Pasos

  1. Lo primero es bajar DWR (http://getahead.org/dwr/download), basta bajar solo la librería (dwr.jar).
  2. Luego hay que modificar el archivo “web.xml”, este se encuentra bajo el directorio “WEB-INF”, ejemplo: ”\dwrEasy\WEB-INF”, se debe incluir las definiciones de los servlets que atienden los requerimientos DWR-AJAX.

Web.xml:

< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web_app>
  <display_name>dwrEasy</display_name>
  <servlet>
    <servlet_name>dwr-invoker</servlet_name>
    <display_name>DWR Servlet</display_name>
    <description>Direct Web Remoter Servlet</description>
    <servlet_class>org.directwebremoting.servlet.DwrServlet</servlet_class>
    <init_param>
      <param_name>debug</param_name>
      <param_value>true</param_value>
    </init_param>
  </servlet>
  <servlet_mapping>
    <servlet_name>dwr-invoker</servlet_name>
    <url_pattern>/dwr/*</url_pattern>
  </servlet_mapping>
</web_app>

  1. A continuación se debe implementar la clase Java que va a ofrecer los servicios, esta basta que sea un clase Java simple (POJO), con un constructor sin parámetros, y donde cada método de la clase es un “potencial” servicio Ajax.

Esta clase va a estar del lado del servidor de aplicaciones (ejemplo: Tomcat, JBoss, o Websphere) no necesariamente tiene que ser un servidor J2EE.

EasyService.java:

package com.soaagenda.services;

import com.soaagenda.valueobjects.*;

public class EasyService {
    public EasyService() {
    }

    public EasyResponse getProducts(EasyParameter parametersX){
        EasyResponse responseX= new EasyResponse();

        // si parametros vacios devuelve error, error if empty parameters
        if (parametersX==null || parametersX.getClientID()==null || parametersX.getClientID().length()< =0){
            responseX.setErrorCode(10001);
            responseX.setErrorDescription("Debe indicar ID Cliente. Give us Client ID");
            return responseX;
        }

        //crea lista productos del cliente, fill the client product list
        //para ejemplo en duro, for the example fixed data
        Product[] productsListX= new Product[2];

        Product productX= new Product();
        productX.setBarCode("0001");
        productX.setName("Tarjeta Visa, Visa Credit Card");
        productsListX[0]= productX;

        productX= new Product();
        productX.setBarCode("0002");
        productX.setName("Tarjeta American Express, American Express Credit Card");
        productsListX[1]= productX;

        //respuesta exitosa, sucessfull response
        responseX.setErrorCode(0);
        responseX.setErrorDescription("Consulta Banco Exitosa, Succesfull Bank Query");
        responseX.setProducts(productsListX);

        return responseX;
    }
}

Este ejemplo simula una consulta de los productos bancarios de un cliente como Tarjetas de Crédito (VISA, Master Card, Dinners, American Express), Cuentas Corrientes, o Creditos de Consumo, para esto se le pasa como parámetro un objeto que tiene el ID del cliente, y el tipo de producto a consultar, el servicio (o método) devuelve otra clase con el código de error, mensaje de error, y la lista de productos (un arreglo de clases producto).

  1. También hay que definir las clases de datos (Value Objects) que va a utilizar el servicio, esta clases deben ser javabeans (atributo privados, con getters y setters):

EasyParameter.java: define los parámetros de entrada del servicio.

package com.soaagenda.valueobjects;

public class EasyParameter {
    private String clientID;
    private String productType;
    public EasyParameter() {
    }

    public void setClientID(String clientID) {
        this.clientID = clientID;
    }

    public void setProductType(String productType) {
        this.productType = productType;
    }

    public String getClientID() {
        return clientID;
    }

    public String getProductType() {
        return productType;
    }
}

EasyResponse.java: define la estructura para los resultados del servicio.

package com.soaagenda.valueobjects;

public class EasyResponse {
    private int errorCode;
    private String errorDescription;
    private Product[] products;

    public EasyResponse() {
    }

    public void setErrorCode(int errorCode) {
        this.errorCode = errorCode;
    }

    public void setErrorDescription(String errorDescription) {
        this.errorDescription = errorDescription;
    }

    public void setProducts(Product[] products) {
        this.products = products;
    }

    public int getErrorCode() {
        return errorCode;
    }

    public String getErrorDescription() {
        return errorDescription;
    }

    public Product[] getProducts() {
        return products;
    }
}

Product.java: define la estructura de un producto.

package com.soaagenda.valueobjects;

public class Product {
    private String barCode;
    private String name;
    public Product() {
        try {
            jbInit();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }

    private void jbInit() throws Exception {
    }

    public void setBarCode(String barCode) {
        this.barCode = barCode;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getBarCode() {
        return barCode;
    }

    public String getName() {
        return name;
    }
}

  1. Vamos a indicarle a DWR que clases vamos a publicar para Javascript (Ajax), esto se hace en el archivo “dwr.xml”, y también corresponde a un esquema de seguridad porque podemos llegar a especificar solo que métodos de una clase queremos exponer, y que atributos.

Para nuestro ejemplo vamos a publicar toda la clase servicio (com.soaagenda.services.EasyService), es decir todos sus métodos, y todas las clases de datos (com.soaagenda.valueobjects.*).

dwr.xml

< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE dwr PUBLIC "-//GetAhead Limited//DTD Direct Web Remoting 2.0//EN" "http://getahead.org/dwr/dwr20.dtd">
<dwr>
  <allow>
    <!-- define la clase de servicios que se va a publicar mediante DWR -->
    <!-- defines the service class to share across DWR -->
    <create creator="new" javascript="EasyService">
      <param name="class" value="com.soaagenda.services.EasyService"/>
    </create>
    <!-- define las clases de datos que utiliza el servicio -->
    <!-- defines the data classes to share across DWR -->
    <convert converter="bean" match="com.soaagenda.valueobjects.*"/>
    </allow>
</dwr>

  1. Ahora si compilamos las clases, y publicamos nuestro ejemplo Web (deploy), DWR nos presta una utilidad para probar que todo anda bien, esta se accede desde un Browser, en el path “/dwr/”, dentro de nuestro sitio (ejemplo: http://localhost:8028/dwrEasy/dwr/)

DWR Test Page

Seleccionado el servicio, nos aparece primero las librerías javascript necesarias para implementar una pagina Web, luego la lista de servicios (métodos de las clase servicio) a los que tenemos acceso (getProducts).

DWR Test Page EasyService

Como no restringimos los métodos de la clase, incluso nos aparecen los métodos que hereda por ser una clase Java (como hashCode, getClass).

Si presionamos el botón “Execute”, ejecuta el servicio, y para el caso de nuestro ejemplo este retorna un error “Debe indicar ID Cliente”, lo que esta bien porque no le hemos indicado parámetros de entrada, con esto sabemos que todo anda bien, porque esa respuesta la da nuestra clase que esta en el servidor, es decir, ejecutamos desde Javascript (Browser) una clase que esta del lado del servidor, eso es Ajax y DWR!!.

  1. Lo siguiente es crear nuestra pagina HTML que va a consultar los resultados y mostrarlos, esta pagina es sumamente simple, tiene un formulario (Html Form), en realidad solo tiene las variables del form, porque ya no es necesario el tag “<form>” (recuerden que con Ajax la forma de hacer request al Server cambia, ahora es asíncrona), y tiene una tabla (html table) para mostrar el resultado.

Mi Primera Pagina DWR

dwrEasyPage.html

< !DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>Editable Table Demo</title>
  <meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
  <script type='text/javascript' src='/dwrEasy/dwr/interface/EasyService.js'></script>
  <script type='text/javascript' src='/dwrEasy/dwr/engine.js'></script>
  <script type='text/javascript' src='/dwrEasy/dwr/util.js'> </script>
  <script type="text/javascript" src='dwrEasyJS.js'> </script>
</head>

<body>
<h1>Easy DRW Demo</h1>
    <h3>Buscar / Search</h3>

   <table>
      <tr>
        <td>ID Cliente / Client ID:</td>
        <td><input name="formClientID" type="text" id="formClientID" size="15"/></td>
      </tr>
      <tr>
        <td>Tipo Producto / Product Type</td>
        <td><input name="formProductType" type="text" id="formProductType" size="15"/></td>
      </tr>
      <tr>
        <td colspan="2" align="right">
          <input type="button" value="OK" onclick="javascript:submitProductsRequest()"/>
        </td>
      </tr>
    </table>

    <h3>Productos / Products</h3>
    <p>Respuesta / Response:
      <input name="serviceResponse" type="text" id="serviceResponse" size="50"/>
    </p>

    <table border="1">
      <thead>
        <tr>
          <th>Codigo / BarCode</th>
          <th>Nombre / Name</th>
        </tr>
      </thead>
      <tbody id="myTable">
        <tr id="myPattern" style="display:none">
          <td>
            <span id="codePattern">code example</span></td>
          <td>
            <span id="namePattern">name example</span></td>
        </tr>
      </tbody>
    </table>
</body>
</html>

Si analizamos el código, lo primero es la referencia a las librerías Javascript (“EasyService.js”, “engine.js”, “util.js”), estas fueron generadas por DWR, luego aparece la librería (“dwrEasyJS.js”) que ya es propietaria (custom), y que debemos construir para realizar la lógica de interacción (esta redescribe a continuación).

Luego aparecen las variables del formulario a solicitar (formClientID, formProductType), y el botón que define la acción de consulta, ejecuta la función Javascript “javascript: submitProductsRequest()”, esta funcion es la que se encuentra definida en la librería (“dwrEasyJS.js), la cual vamos a tener que contruir.

Después viene la tabla que mostrará los datos (myTable).

Podemos ver que hay ciertas características especiales en el código Html, estas le van a servir a DWR para encontrar donde obtener, o donde mostrar los datos:

Los “Id” de los tags html le sirven a DWR para manejar los datos:

· Los id “formClientID”, “formProductType” le permiten encontrar loas parámetros de entrada.

· El id “myTable”, le servirá para saber que tabla limpiar.

· El id “myPattern”, le indicará a DWR que filas (rows) debe “clonar” para mostrar cada registro de producto de la lista, como es un “patrón” en principio va oculto (style=”display:none”).

· Los id “codePattern”, “namePattern” servirán para qeu DWR sepa donde colocar los datos de cada producto, en este caso se usan tags “<span>”.

Como vemos esta pagina es solo Html, y Javascript, que “hermosamente simple”, nada de JSP, ni de ASP, una pagina que se puede publicar en cualquier servidor Web.

  1. Lo que sigue es la librería Javascript propia.

dwrEasyJS.js

function submitProductsRequest() {
  var idX=dwr.util.getValue("formClientID");
  var typeX=dwr.util.getValue("formProductType");

  var parametersX={clientID:idX,productType:typeX};

  EasyService.getProducts(parametersX,showProducts);

 }

function showProducts(responseX) {

// borro filas excepto el patron, delete rows except pattern row
        dwr.util.removeAllRows("myTable", { filter:function(tr) { return (tr.id != "myPattern");}});

	if (responseX.errorCode!=0){
  	  alert('Error: '+responseX.errorDescription);
	  return;
	};
	var productsX=responseX.products;
	var lengthX=productsX.length;
	var itemProductX;

 	if (lengthX==0){
  	  alert('No hay productos, Cant find products');
	  return;
	};

	dwr.util.setValue("serviceResponse", responseX.errorDescription);

	var id="00";
	for (var i=0 ; i<lengthx ; i++)
        {
           temProductX= productsX[i];
           id="00"+i;
           dwr.util.cloneNode("myPattern", { idSuffix:id });
           dwr.util.setValue("codePattern" + id, itemProductX.barCode);
           dwr.util.setValue("namePattern" + id, itemProductX.name);
           $("myPattern" + id).style.display = "";
        }
}

  1. Esta librería tiene dos funciones: “submitProductsRequest” la que obtiene los parámetros de entrada y ejecuta el servicio correspondiente (clase Java EasyService.getProducts() vía DWR), y la función que muestra los datos (showProducts).

Finalmente hay que subir las páginas (Deploy) en el sitio Web, quedando el proyecto con la siguiente estructura:

.Proyecto DWR de Ejemplo

Ejecutamos la pagina de prueba “dwrEasyPage” en nuestro Browser (ejemplo “http://localhost:8028/dwrEasy/dwrEasyPage.html”), ponemos un dato en “ID Cliente”, presionamos “OK”, y listo!, nuestra primera aplicación Ajax-DWR.

  1. The End

May 28

Cuando nos da el siguiente error:

[ERROR, org.directwebremoting.impl.DefaultCreatorManager]Creator: ‘NewCreator[XXX]’ for XXX.js is returning null for type queries.

Se debe a que no encuentra el constructor de la clase que se esta exportando en DWR, esto se puede deber a los siguientes motivos:

  • El nombre de la clase o el package de la clase esta mal definido en el archivo “dwr.xml”.
  • La clase no tiene el constructor por defecto vacio.
  • La clase no se encuentra en el classpath, por ejemplo si es un proyecto Web no se encuentra en el directorio “..\WEB-INF\classes\”, o “..\WEB-INF\lib\” (si esta dentro de un jar).
  • Del anterior se desprende que; suele suceder que cuando se compila la clase no se incluye en ningun jar, luego en el fondo esta mal definido el proyecto en cuanto a la compilación, y generación de librerias (jars).
Dic 04

Existen tecnologías dentro del ambiente SOA, y BPM, que tienen mucho en común, y por lo tanto muchas veces no se logra visualizar de forma clara sus diferencias, estamos hablando de los “coordinadores de tareas”, u “orquestadores” en general , herramientas que permiten organizar actividades en un flujo. Bajo este concepto podemos tomar:

  • ETL (Extract Transform and Load)
  • WorkFlow tradicional
  • ESB (Enterprise Service Bus)
  • BPM o BPMS (Business Process Management Suite)

Estas herramientas en general permiten a través de asistentes gráficos crear un proceso a partir de la organización de tareas, o subprocesos.

Extract, Transform and Load (ETL)

Nacida para traspasar información desde un repositorio de datos origen a uno destino, esta tecnología esta orientada a los procesos de datos, procesos basados en repositorios como Base de Datos y archivos.

ETL es una de las tecnología mas antiguas de integración, integración a nivel de datos, y tal como las Bases de Datos relacionales su utilidad se ha consolidado en el tiempo. Incluso en la actualidad dentro de la “Arquitectura Orientada a Servicios” (SOA) tiene su puesto en lo que son los “Servicios de Información”, porque a pesar de que su principal uso es en procesos Batch (procesos de actualización masivos), también se puede usar para el desarrollo de funcionalidades especificas pero que involucran la integración de entidades de información dispares (distintas).

Tal como su nombre lo indica permite Extraer (Extract), Transformar (Transform), y Cargar (Load), información desde, y hacia distintas fuentes de datos.

  • Extraer: permite extraer la información de distintas fuentes de datos, principalmente bases de datos, y de la mayoría de los proveedores conocidos: Oracle, Sybase, DB2, MySQL, esto lo hace directamente desde las tablas, o usando “Stored Procedures” existentes. También permite extraer datos de archivos como XML, Excel, CSV, Texto, entre otros. Y han evolucionado hasta incluso obtener información de colas de mensajes, objetos Java, y Webservices, abarcando de cierta forma el terreno de los ESB.
  • Transformar: a través del manejo de Metadata (datos en un formato estándar desacoplado de la fuente) permite unir la brecha existente debido a la diferencia de los tipos de datos, por ejemplo el proceso de información “Actualizar Datos de un Cliente” que involucra actualizar en distintos lugares, puede requerir que un dato que esta en entero deba pasarse a tipo float (real), o que los apellidos que están separados en una base de datos deban guardarse juntos en un solo campo en otra base de datos, o que un código de comercio que esta en cierto estándar (como EAN) se deba traducir a otro estándar (como ISBN) porque así se maneja en el otro repositorio.
  • Cargar: permite guardar la información procesada en la misma diversidad de entidades que maneja dentro de la extracción: Bases de Datos, y archivos de distinto tipo.

En la actualidad las herramientas de ETL permiten componer estos procesos mediante asistentes gráficos, ambientes de desarrollo (IDE) que realizan una introspección de las fuentes de datos, obteniendo todos los objetos y sus campos de datos, permitiendo a través de “arrastrar y soltar” construir el flujo de proceso de datos. Además pueden incorporar reglas de negocio que permiten potenciar la funcionalidad del procesos.

Ejemplo: Proceso de Información Agrega Nuevo Producto

Proceso ETL

A este proceso ejemplo se le entrega un producto, el cual lo transforma en metadata, para poder por un lado obtener la marca asociada (desde una base Sybase), y por otro lado su código EAN (usando un Stored Procedure), si el código EAN no existe se busca en un archivo XML, luego finalmente toda la información se carga en la tablas de Productos (Base DB2), y además se registra en un archivo de Log (archivo txt). Mas que nada este ejemplo sirve para mostrar la relación que se puede establecer entre los distintos objetos ETL, pero la estructura definitiva de un diseño ETL dependerá de la herramienta que se utilice.

Los principales objetos que maneja un ETL son:

  • Tablas de Bases de Datos
  • Procedimiento Almacenados (Stored Procedures)
  • Archivos XML
  • Archivos de Texto, Archivos Excel.
  • Transformaciones de Datos.

Otra característica que ofrecen actualmente los ETL, y que es muy importante para la Arquitectura SOA, es que los procesos ETL se pueden ejecutar como WebServices, para lo cual el motor de ETL publica el proceso en formato SOAP, pudiendo ser ejecutado desde cualquier plataforma (Java, .Net), y ser integrado en tecnologías como ESB (Enterprise Service BUS).

Luego, en el contexto de SOA podríamos indicar que ETL es la herramienta que permite diseñar y construir procesos de información (servicios de información) basados en actividades (automatizadas) a nivel de datos.

Algunas herramientas ETL del mercado son:

WorkFlow Tradicional

Decimos WorkFlow “Tradicional”, porque la forma actual y bajo SOA de implementar un workflow es BPM, pero existen aun tecnologías WorkFlow tradicionales (no BPM), pero la mayoría se esta transformando en soluciones BPM.

La verdad es que actualmente muchas herramientas WorkFlow se acercan a lo que es BPM, viéndolo solo desde el punto de vista del flujo de los procesos de negocio, por eso aquí vamos a ver el concepto de WorkFlow Tradicional que se refiere al WorkFlow como era antes de evolucionar a BPM.

WorkFlow (Tradicional) es la tecnología que permite coordinar actividades humanas (realizadas por personas, Human Task), aquí se definen roles, actividades, reglas de negocio, en buenas cuentas un flujo de trabajo (WorkFlow), pero que a diferencia de BPM no contempla en forma natural los “servicios de negocio”, es decir no contempla las actividades de sistemas (System Task) bajo el estándar SOA.

Ejemplo: WorkFlow Actualizar Stock de Productos

Proceso WorkFlow

Este WorkFlow ejemplo define un procesos donde un ejecutivo ingresa Stock de productos, el supervisor verifica el stock ingresado, y si es un producto nuevo además verifica la ficha del producto, si por alguna razón no se valida el registro vuelve al ejecutivo, quien debe corregir el ingreso. Este es un ejemplo genérico, la estructura del diseño del proceso dependerá de la herramienta utilizada.

Luego en una solución (WorkFlow tradicional) el participante (usuario) debe indicar el cumpliendo de la tarea (cambio de estado), para de esta forma continúe el flujo de trabajo, y cuando debe interactuar con algún sistema, debe levantar dicho sistema y realizar la actividad en él, por ejemplo ejecutar el sistema de stock para agregar un nuevo producto.

Esa es otra gran diferencia con BPM, en BPM se trata de proveer una sola interfaz para un participante del proceso, ocultando la interacción con los sistemas, mientras en un WorkFlow (tradicional) la persona debe interactuar con distintos ambientes o aplicaciones, dicho de otra forma: la persona debe manejar distintas aplicaciones (sistemas), y además registrar su avance en el WorkFlow.

Con WorkFlow (al igual que BPM) se le da seguimiento y control a los procesos de negocio, es decir, podemos saber el estado actual de cada proceso, en que lugar del flujo se encuentra. Otra similitud con BPM , o dicho de otra forma; otra característica que BPM heredo de los WorkFlow, es que a través del proceso generalmente fluye información (documentos, datos), lo que se llama la metadata, u objeto de negocio (BPM).

Enterprise Service Bus (ESB)

Esta tecnología permite integrar sistemas a nivel de servicios, cuando se habla de tecnología para implementar SOA en una empresa la primera herramienta que se debe incorporar es el “Service Bus”.

Esta herramienta permite componer procesos a partir de servicios SOA, los servicios SOA son componentes funcionales encapsulados fuertemente reutilizables, haciendo el “típico” símil: son piezas de lego que permiten construir un sistema uniendo bloques, y en este caso construir un proceso uniendo servicios SOA.

Proceso ESB Actualiza Producto en Sistemas

Proceso ESB

En este proceso ejemplo se entrega el producto a actualizar se comprueba el tipo de producto (Ecommerce o SAP), usando una clase Java (conecto EJB), luego se actualiza en el sistema Ecommerce usando un WebService, o se actualiza en el sistema SAP usando un conector provisto por el ESB.

Al igual como BPM absorbió las funcionalidades de WorkFlow (a través de BPEL4People), también absorbió las funcionalidades del ESB (a través de BPEL), de hecho las BPMS (BPM Suite) suelen traer como parte de sus componentes el ESB.

La diferencia con BPM es que el ESB no maneja las actividades humanas (Human Task) solo maneja actividades automatizadas (System Task).

La diferencia con ETL (tradicional) es que ETL esta orientado a componentes de datos, y ESB esta orientado a componentes de Servicios.

Los objetos que principalmente maneja ESB son:

  • WebServices
  • Conectores a Colas de Mensajes, y JMS
  • Conectores a Aplicaciones de clase Mundial (PeopleSoft, SAP, JDEdwards)
  • Conectores a J2EE (EJB) y .Net
  • Transformaciones de Datos

Los ESB también manejan Metadata para la transformación de datos, y para lograr que los sistemas se entiendan a pesar de la diferencia en los tipos de datos que manejan.

Una característica importante es que los procesos se pueden ejecutar a través de WebServices, es decir un proceso de negocio ESB se puede publicar en protocolo SOAP, permitiendo que una gran variedad de plataformas puedan acceder a estos procesos.

Algunos ESB tienen conectores para Base de Datos, permitiendo integrar consultas a tablas (SQL Query), y procedimientos almacenados (Stored Procedures), con esto el ESB comienza abarcar terreno de los ETL, pero a decir verdad esta característica pone en riesgo la orientación a servicios (SOA), ya que los servicios deben corresponder a la capa de negocio, y no a la de datos.

Algunos ESB importantes:

Resumiendo ESB desde el punto de vista SOA es la herramienta que permite desarrollar procesos basado en servicios SOA.

BPM Suite.

BPM es la solución que permite construir procesos de negocio basado en coordinar tanto actividades interactivas (human task), como servicios (system task). BPM une lo mejor del mundo del WorkFlow Tradicional con el ESB.

En un mismo flujo se integran tareas realizadas por personas, con tareas automatizadas(sistemas), entregándole al participante de un proceso de negocio una sola interfaz, ocultando la interacción con los sistemas legados.

Ejemplo Proceso de Negocio Actualizar Stock de Productos

Proceso BPM

Basado en los ejemplos anteriores, en este proceso se integran 2 servicios al WorkFlow “Actualizar Stock”: una vez ingresado el stock, si el producto existe, entonces se obtiene los datos del producto usando un “WebService” (Obtiene Ficha Producto), y si el supervisor valida el ingreso al final se actualiza el producto usando otro “WebService” (Actualiza Producto), este ultimo servicio se supone es el proceso ESB “Actualiza Producto en Sistemas” publicado como WebService. Este es un ejemplo simplificado, en la realidad puede ser necesario incluir algunos servicios más.

La otras características de valor agregado de BPM son: que ofrece un grupo de herramientas para atender todo el ciclo de visa de un proceso de negocio, dentro de las cuales se destaca, el modelador (diseño procesos), el IDE (desarrollo de servicios), y el monitor (BAM), este ultimo que permite realizar un seguimiento y control mas acabado de los procesos de negocio.

Orquestadores en la Arquitectura de Referencia SOA

Desde el punto de vista de arquitectura marco SOA, los orquestadotes se organizan de la siguiente forma:

ETL, ESB, BPM, SOA

Nov 27

Technorati Profile

Nov 16

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