Posts Tagged ‘web services’

h1

Suites de Gestion de Procesos de Negocio de Codigo Abierto: el caso Mexicano

03/28/2014

Wizdoc [Icon By Buuf]  Tips & Tricks.

[Se ha estimado] que el proceso de negocio como servicio (BPaaS) y el mercado de BPM en la nube crecerán en valor desde USD 1 mil millones en 2013 hasta 7,120 millones de dólares en 2018.

The next evolution of BPM. Lance Harris. (Business Technology News and Information, 2013).

Hace algunas semanas nuestro country head me encargó encontrar los BPMS (Business Process Management SuitesSuites de Gestión de Procesos de Negocio) de mayor uso en México, y si entre éstos existe una opción basada en código abierto lo suficientemente competitiva como para incluirla dentro de nuestra oferta de servicios. Los resultados se obtuvieron en su mayoría a partir de información encontrada libremente en la web, por lo que me es posible compartir una buena parte de éstos:

Esta investigación presenta las opciones más utilizadas para el software de código abierto con respecto a Business Process Management Suites (BPMS) en México. Los resultados se presentan tomando en cuenta que el software BPMS es poco utilizado en México y el resto de América Latina. El conjunto de opciones mostradas a continuación está pensado principalmente con la finalidad de fomentar la evaluación de opciones de código abierto durante la generación de nuestras propuestas de solución y servicios. Se entiende que el mercado de software, especialmente la rama de código abierto, es un entorno de desarrollo muy dinámico y las opciones que figuran en este documento pueden quedar obsoletas rápidamente. Aun así, esta lista tiene como objetivo ser de utilidad para los clientes potenciales que consideren el código abierto como una opción, y para ayudar a darle mayor credibilidad y seguridad a nuestras propuestas.

Contexto

Típicamente, los beneficios del software de código abierto incluyen precios más bajos de adquisición, bajos o nulos costes de licencia, interoperabilidad, así como integración y personalización fácil de implementar; menos barreras para la reutilización, conformidad con los estándares abiertos de tecnología y datos que dan autonomía sobre su propia información. Finalmente, proporciona la posibilidad de no tener que “casarse” con un proveedor determinado.

El código abierto es poco o en absoluto utilizado en las organizaciones mexicanas de gran tamaño. Los integradores de sistemas y fabricantes no consideran al software de código abierto para sus soluciones de TI. Esto se puede demostrar en el Cuadrante Mágico de Gartner para BPMS (2010):

pic: Magic Quadrant for Business Management Suites (Oct 2010)

Cuadrante Mágico de Gartner para suites de gestión de procesos de negocio (Octubre 2010). (Fuente: avoka.com)

De entre 27 opciones diferentes, sólo una (Intalio) es de código abierto. Éste cae dentro del grupo de visionarios.

Hay importantes obstáculos al código abierto en México. Algunos de ellos incluyen una falta de una orientación clara para su adquisición, resistencia por parte de los proveedores, preocupaciones sobre las obligaciones de licenciamiento y – desde que el TLCAN comenzó su existencia hace más de 20 años – el tema de las patentes, malos entendidos acerca del proceso de acreditación de seguridad y mitos alrededor de la calidad y el soporte técnico del código abierto.

Cómo interpretar este documento

Este documento presenta el software de código abierto para ser considerado en nuevas soluciones BPM que cumplan con los requerimientos del negocio, o como sustitutos de software propietario ya existente. Se ofrecen varias opciones sobre la base de las implementaciones ya liberadas en el mercado mexicano hasta marzo de 2014. Este conjunto de opciones se puede utilizar para:

• Informar durante el diseño de nuevas soluciones de TI.

• Sugerir oportunidades de TI de servicios o soluciones nuevas.

• Retar propuestas de solución que no utilicen las tecnologías de código abierto.

El criterio general para que un software de código abierto sea listado entre las opciones sugeridas es que debe existir una oportunidad real para su uso. Un uso significativo y probado es un factor clave, en el que “probado” puede significar:

• Uso a gran escala, volumen o en escenarios de alto rendimiento.

• Uso en funciones críticas, tales como salud o seguridad.

• Historial de uso, de preferencia durante muchos años.

Uso de los BPMS

La mayoría de los proveedores de BPMS proporcionan análisis de procesos, diseño y herramientas de modelado de flujos de trabajo dentro de sus suites.
Por otro lado, la mayoría de las organizaciones optan por invertir en BPMS porque necesitan apoyo para un programa de mejora continua de procesos, el apoyo a un proyecto de transformación de negocios, y/o el middleware necesario para implementar una arquitectura orientada a servicios (SOA). Las organizaciones también pueden buscar adoptar un BPMS para guiar el proceso de implementación de una solución de procesos específica.

Las soluciones BPM han sido adoptadas principalmente por los organismos financieros, donde la visibilidad y la adherencia a las regulaciones de cumplimiento son una parte integral de este sector (por ejemplo, la ley Sarbanes-Oxley). BPM también se ha aplicado en las organizaciones de servicios donde la productividad y la eficacia del personal desempeñan un papel clave en el rendimiento del proceso. La mayoría de las organizaciones deciden adoptar BPM porque prevén que los cambios en sus procesos se producen con frecuencia. Sin embargo, muchas organizaciones también están comenzando a ver más allá de BPM como un simple documentación y rastreo de procesos, considerándolo como una oportunidad para transformar su negocio, mejorar los procesos y reducir costos.

Adopción de los BPMS

La mayoría de las herramientas y software de BPM utilizados hoy en día son productos comerciales caros. El mercado está siendo liderado por IBM (Lombardi) y Oracle (Oracle BPM 11g), acaparando más de la mitad de la cuota de mercado. Sólo un pequeño porcentaje (aproximadamente 15%) de las empresas en México han adoptado una solución de código abierto para BPMS. Estos están dirigidos por Intalio y jBPM de JBoss. Otros jugadores incluyen BonitaSoft, ProcessMaker y Activiti, que representan una pequeña fracción de la cuota de mercado. Estos tres son adoptados en su mayoría por organizaciones pequeñas y medianas (PYMEs).

BPMS Clientes
IBM Afore Banamex, CaixaBank, Financiera Independencia, GNP Seguros, AXA Seguros, Coca-Cola, Redpack, Telcel
Oracle AXA Financials, Banamex Gpo. Financiero, Bimbo, Comex, Nextel, Movistar, Cablemas, Televisa, Casas GEO
Intalio Sky, Santander, Samsung de México, Costco, Sears de México, DHL
JBoss jBPM BBVA, Toyota, Grupo Posadas
BonitaSoft DirecTV, Xerox (gestión de documentos)
ProcessMaker Banregio, Mexbrit, Lenovo LatAm
Activiti CONACyT (Gobierno Mexicano)

Principales clientes de las suites BPM más utilizadas en México. Los clientes fueron obtenidos de las páginas web de cada proveedor.

Por qué código abierto y cuáles son los retos para su adopción

Antes de cualquier otra consideración, el principal motivo de adopción de una solución de código abierto u open source consiste en los costos de licenciamiento y servicios profesionales necesarios para su implementación. Los productos comerciales se encuentran en el orden de USD 250,000 por implementación, generalmente a través de pagos por adelantado. Por el contrario, las herramientas BPM de código abierto están atrayendo más atención en el mercado debido a los posibles ahorros en costos y términos de licenciamiento más flexibles. Los usuarios también pueden ampliar las prestaciones de los productos y su escalabilidad sin costes adicionales. En caso de que la solución requiera una personalización específica o corrección de bugs, es posible buscar la ayuda de un tercero o de la comunidad open source, en lugar de esperar los lentos tiempos de respuesta de los proveedores comerciales.

Los principales retos a los que se enfrenta cualquier adopción BPMS se enumeran a continuación:

• Fuerte dependencia de operadores que realizan sus tareas de forma manual, sin automatización ni flexibilidad para satisfacer las cambiantes necesidades del negocio.

• Falta de procesos y prácticas bien documentadas.

• Escasa colaboración en equipo; todo se hace a través de correo electrónico y llamadas telefónicas. Los documentos son almacenados en formato físico (hard-copy).

• Los proveedores actuales se centran en el departamento IT para proveer las necesidades de BPM de la organización; en realidad, BPM debería ser responsabilidad del área de negocios.

• Muchas organizaciones están centradas en datos (data-centric) en lugar de estar centradas en el proceso (process-centric).

• A menos que el cumplimiento normativo o de continuidad del negocio sean un factor, muchas organizaciones siguen un crecimiento orgánico, dejando la gestión de procesos en un segundo plano.

• Falta de confianza en BPM. Muchas organizaciones esperan resultados verificables en menos de 6 meses desde la adopción de BPM.

Principales Suites BPM Open Source

Intalio

Intalio es una plataforma de procesos de negocio de código abierto construido alrededor del modelador BPMN STP de Eclipse y el motor Apache ODE BPEL 2.0, ambos originalmente aportados por Intalio. La versión Enterprise proporciona los componentes necesarios para el diseño, la implementación y la gestión de varios procesos de negocio, tales como:

• BRE (Business Rules Engine – Motor de reglas de negocio).

• BAM (Business Activity Monitoring – Monitoreo de Actividades de Negocio).

• Portal.

• ESB (Enterprise Service Bus – Bus de Servicios Empresarial).

• ECM (Enterprise Content Management – Gestión de Contenidos Empresarial).

Intalio está disponible en varias ediciones, pero la versión relevante para este documento es la edición de comunidad libre (free community edition) de Intalio. Ésta se compone de dos módulos: Intalio Designer e Intalio Server. Intalio Designer permite el modelado de los procesos para ser eventualmente desplegados en el Intalio Server. Intalio Designer permite que modelos BPMN se conviertan en procesos BPEL ejecutables. De acuerdo a la filosofía de Intalio, el área de negocio podría generar, editar y ejecutar los procesos, sin requerir de un desarrollador técnico para traducir la visión de negocio en código.

JBoss jBPM

jBPM es una plataforma de código abierto para diferentes lenguajes de procesos ejecutables que van desde la gestión de procesos empresariales (BPM) hasta el flujo de trabajo para la orquestación de servicios. jBPM admite tres lenguajes de proceso diferentes. Cada uno de ellos está dirigido a una función y entorno específico:

• jPDL (lenguaje de definición de proceso propio de JBoss).

• BPMN 2.0

• Pageflow

jBPM genera todos estos lenguajes de proceso de forma nativa en la parte superior de la Máquina Virtual de Procesos (Process Virtual Machine – PVM). Así mismo, jBPM es independiente de las bases de datos, servidores y es integrable en otras aplicaciones (embeddable). Finalmente, esta suite es altamente personalizable – desde el punto de vista de los desarrolladores.

jBPM es modular. Funciona con el middleware empresarial de JBoss o cualquier otra plataforma de middleware que cumpla con la especificación Java EE. Está disponible a través de suscripciones que incluyen software certificado, soporte por industria, actualizaciones y parches, documentación y política de mantenimiento de varios años. El modelador es una aplicación Java estándar y no necesita un servidor de aplicaciones; las empresas que estén interesadas en jBPM pueden utilizarlo sin añadir más complejidad. Los formularios que pertenecen a los procesos modelados pueden implementarse como aplicaciones web o aplicaciones de escritorio (standalone) en Java.

Bonita Open Solution

Bonita BPM es un gestor de procesos de negocio de código abierto y suite de modelado de flujos de trabajo, creado en el 2001. El proyecto se inició en el Instituto Nacional de Investigación en Informática y Automática (Francia), para luego incubarse por varios años en el interior de la empresa informática francesa Groupe Bull. Desde 2009, el desarrollo y soporte de Bonita es realizado por Bonitasoft, una empresa creada específicamente para esta actividad.

Bonita consta de tres módulos principales:

• Bonita Studio: permite al usuario modificar gráficamente los procesos de negocio siguiendo el estándar BPMN. El usuario también puede conectar los procesos a otras piezas del sistema de información (tales como mensajería, planificación de recursos empresariales, administración de contenido empresarial y bases de datos) con el fin de generar una aplicación de negocio autónoma, accesible como un formulario web. Bonita Studio también permite al usuario diseñar gráficamente las formas que se mostrarán al usuario final con el fin de interactuar con el proceso. Por otra parte, el modelador permite al usuario empezar a trabajar con procesos diseñados con otros estándares y tecnologías como XPDL o jBPM. Se basa en Eclipse.

• Bonita BPM Engine: El motor de BPM es una API Java que permite al programador interactuar mediante programación de los procesos. Se basa en Hibernate.

• Bonita Portal: es un portal que permite a cada usuario final administrar en una interfaz parecida a webmail todas las tareas en las que él o ella está involucrada. El portal también permite que el propietario de un proceso pueda administrar y obtener informes sobre los procesos. Se basa en GWT.

ProcessMaker

ProcessMaker está diseñado estrictamente para las pequeñas y medianas empresas (PYMEs). Al igual que Intalio, ProcessMaker tiene la filosofía de que los usuarios de negocios y expertos en procesos que no tienen experiencia en programación puedan diseñar y ejecutar flujos de trabajo, así como automatizar los procesos de todos los sistemas. ProcessMaker tiene varios módulos con los que el usuario puede crear mapas de flujo de trabajo, formas de diseño personalizadas, extracción de datos de desde fuentes externas y otras características para generar y optimizar las operaciones de gestión del flujo de trabajo y de negocios:

• Diseñador de Mapa de Procesos

• Dynaform Builder (formularios personalizados para los procesos de la organización)

• Output Document Builder (diseñador de documentos de salida de proceso) / Gestión Documental

• Motor de reglas de negocio

• IDE para construcción de web services

• Gestión de usuarios

• Bandeja de entrada de casos

ProcessMaker posee una biblioteca en línea que proporciona plantillas de proceso que el usuario puede descargar y editar. La curva de aprendizaje también se puede reducir ya que el desarrollo puede basarse desde una plantilla ya construida y probada. Algunas plantillas de muestra incluyen:

• Solicitud de tarjeta de crédito

• Proceso de informe de gastos

• Solicitud de zonificación de distrito

Activiti

Activiti es una plataforma BPM de código abierto para un entorno basado en Java. Originalmente desarrollada por Alfresco, su código fuente se distribuye bajo la licencia Apache. Dentro de la plataforma Activiti BPM se encuentran los siguientes componentes:

• Modelado: Activiti Modeler, Designer y Kickstart

• Ejecución: Activiti Engine

• Gestión: Activiti Explorer, REST.

Activiti es soportada y desarrollada por varias empresas como SpringSource, Atos Origin, Signavio, Camunda y otros. Así mismo, la plataforma se puede integrar a mule, un popular ESB de código abierto, para la entrega de soluciones basadas en SOA. Su modelador soporta BPMN y jPDL; posee extensiones que permiten la integración con el middleware de JBoss.

Benchmark entre los diferentes BPMS

Finalmente, se presenta un comparativo de los diferentes BPMS, incluyendo los productos de IBM y Oracle:

BPMS Tipo Interfaz de Usuario Notación Workflows Binding
IBM Lombardi Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Oracle BPM 11g Workflow, Process Designer, ESB, ECM, Portal Todos BPMN BPEL J2EE, WSDL/WS
Intalio Workflow, Process Designer, ESB, ECM, Portal, BRE Web 2.0 BPMN WS-BPEL J2EE
JBoss jBPM Workflow, Process Designer Todos jPDL, BPMN, Pageflow BPEL WSDL/WS
BonitaSoft Workflow, Process Designer, Portal Java BPMN XPDL, BPEL J2EE
ProcessMaker Workflow, Process Designer, ECM Todos BPMN BPEL J2EE
Activiti Workflow, Process Designer Todos BPMN BPEL REST

Comparativo con las características de los BPMS más usados en México.

Análisis y recomendaciones

Para clientes pequeños con un gasto menor a USD 100,000 anuales dedicados a BPM, es recomendable adquirir un producto de código abierto. Dependiendo del requerimiento del cliente, puede utilizarse alguna de las opciones mostradas en el documento; sin embargo si el cliente tiene esperado un fuerte crecimiento en la demanda de su solución BPM, las mejores opciones son jBPM o Intalio, ya que ambos productos permiten conexión con plataformas de alta escalabilidad, incluyendo middleware y bases de datos comerciales. En el caso de jBPM, este producto permite utilizar la vasta gama de productos ofrecidos por Red Hat, mientras Intalio permite al cliente utilizar la Community Edition hasta que haya alcanzado la masa crítica necesaria para adquirir sus licencias. Basándose en una comparación a juicio de experto entre ambos productos, NO existe una clara ventaja competitiva de alguno sobre otro, por lo que dependiendo de las características del cliente variará el criterio de selección del BPMS a implementar.

h1

Usando Telnet para llamar Web Services

10/23/2009

Wizdoc [Icon By Buuf]  Tips & Tricks.
Hace tiempo publiqué un post donde hablo un poco acerca de las herramientas que todo desarrollador debe conocer para simplificar el trabajo y mejorar su productividad. Entre ellas incluyo a SOAP UI, que nos facilita integrar web services en una aplicación. Como mencioné anteriormente, SOAP UI permite generar peticiones a un web service, ya sea mediante el WSDL de manera local o a través de la URL donde se encuentra remotamente dicho documento, en caso de ser accesible desde nuestra computadora.

Sin embargo, muchas veces al integrar web services resulta que por cuestiones de seguridad, existen dos servidores de prueba – uno de nuestro lado y otro del lado del servicio que estamos integrando – con restricciones de IP. Esto complica nuestro trabajo porque no podremos probar la funcionalidad de manera directa desde nuestra máquina pues al intentar llamar al web service, nuestro cliente marcará un Connection Refused o Connection Timeout.

Existen versiones de SOAP UI para Solaris y Linux, pero puede llegar a dificultarse instalar la herramienta ya que en más de una ocasión he visto que a los desarrolladores se les proporcionan usuarios sin permisos mas que de ejecución, y sólo en ciertos directorios aprobados por el área de seguridad.

¿Qué hacer al respecto? Valiéndonos de SOAP UI y el pedestre pero poderoso cliente Telnet podremos avanzar sin muchas complicaciones:

Para generar nuestras peticiones debemos contar con el WSDL que describe la funcionalidad del servicio. La manera más fácil de obtenerlo es apuntar al URL donde está publicado y recuperarlo mediante la ejecución de telnet <ip o nombre del servidor> <puerto> de la siguiente manera:

# telnet 192.168.100.105 8080
Trying 192.168.100.105…
Connected to 192.168.100.105.
Escape character is ‘^]’.
_

Una vez que hemos abierto una nueva conexión, ejecutamos una petición HTTP GET para recuperar el WSDL que estamos buscando mediante GET <URI del WSDL> más dos <Enters>, como se muestra a continuación:

# telnet 192.168.100.105 8080
Trying 192.168.100.105…
Connected to 192.168.100.105.
Escape character is ‘^]’.
GET /axis/services/RemoteWebService?wsdl
<Enter>
<Enter>

Y esto generará como respuesta el WSDL completo. Para aquellos que cuenten con los permisos correspondientes, es posible utilizar el comando wget (localizado en /usr/bin/wget o en /usr/sfw/bin/wget) con la dirección completa del WSDL para recuperarlo:

# wget http://192.168.100.105:8080/axis/services/RemoteWebService?wsdl
–19:35:26– http://192.168.100.105:8080/axis/services/RemoteWebService?wsdl
Connecting to 192.168.100.105:8080… connected.
HTTP request sent, awaiting response… 200 OK
Length: unspecified [text/xml]
Saving to: `RemoteWebService?wsdl’

[ <=> ] 16,010 39.5K/s in 0.4s

19:35:27 (39.5 KB/s) – `RemoteWebService?wsdl’ saved [16010]

# _

Ahora, mediante SOAP UI o alguna otra herramienta como XML Spy podemos generar los XML de las peticiones al web service y editar dichos documentos para agregarles los valores necesarios. Un ejemplo con SOAP UI es el siguiente:

SOAP UI XML Request

Ejemplo de una petición XML-SOAP con un WSDL importado mediante SOAP UI. (Dar click en imagen para ver versión original).

Al haber creado un nuevo proyecto en SOAP UI mediante el WSDL, tenemos un template de petición al web service que vamos a llamar. Podemos editarlo y agregar los valores faltantes, incluyendo la etiqueta <?xml version="1.0" encoding="UTF-8"?> que es indispensable incluir al inicio de nuestro mensaje:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:ser="http://in.dustry.com/web/services"&gt;
  <soapenv:Header/>
  <soapenv:Body>
    <ser:getUserProfile soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"&gt;
      <seq_id xsi:type="xsd:string">11223344</seq_id>
      <client_id xsi:type="xsd:string">1122</client_id>
    </ser:getUserProfile>
  </soapenv:Body>
</soapenv:Envelope>

Debemos remover los espacios e indentaciones para simplificar nuestro copy-paste final en el cliente de Telnet (en un momento veremos por qué):

<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:ser="http://in.dustry.com/web/services"><soapenv:Header/><soapenv:Body><ser:getUserProfile soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><seq_id xsi:type="xsd:string">11223344</seq_id><client_id xsi:type="xsd:string">1122</client_id></ser:getUserProfile></soapenv:Body></soapenv:Envelope>

Y hacemos el paso de la muerte, ejecutando nuevamente nuestro cliente Telnet, pero en ves de realizar un HTTP GET, generaremos una petición HTTP POST con ciertos parámetros que son tomados por el cliente Telnet como el encabezado de nuestra petición:

# telnet 192.168.100.105 8080
Trying 192.168.100.105…
Connected to 192.168.100.105.
Escape character is ‘^]’.
POST /axis/services/RemoteWebService HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: ""
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 123.456.789.101
Content-Length: 527
<Enter>
<Enter>

A continuación explico qué significa cada línea del encabezado:

• La primera línea indica que realizaremos una petición HTTP POST a la dirección del web service remoto en /axis/services/RemoteWebService, usando el protocolo HTTP versión 1.1.
• La línea dos indica que podremos enviar mensajes comprimidos. Esta línea es opcional.
• La línea tres indica la codificación de nuestro mensaje.
• La línea cuatro indica que este es un mensaje SOAP y que realizaremos una acción con esta llamada. Puede dejarse vacía, pero es indispensable incluirla pues de lo contrario el servidor nos responderá con el mensaje de error "no SOAPAction header!".
• Las líneas cinco y seis indican el user-agent o cliente que está realizando la petición, así como la IP desde la que se está llamando. Conviene incluirlas en caso de que el web service remoto realice algún tipo de filtrado por IP o tipo de cliente.
• Finalmente, la longitud del mensaje que debe ser exactamente la misma del mensaje SOAP enviado.

Luego copiamos el XML de nuestra llamada al web service y tecleamos dos <enters> nuevamente;

# telnet 192.168.100.105 8080
Trying 192.168.100.105…
Connected to 192.168.100.105.
Escape character is ‘^]’.
POST /axis/services/RemoteWebService HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/xml;charset=UTF-8
SOAPAction: ""
User-Agent: Jakarta Commons-HttpClient/3.1
Host: 123.456.789.101
Content-Length: 527
 
 
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:xsd="http://www.w3.org/2001/XMLSchema&quot; xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:ser="http://in.dustry.com/web/services"><soapenv:Header/><soapenv:Body><ser:getUserProfile soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><seq_id xsi:type="xsd:string">11223344</seq_id><client_id xsi:type="xsd:string">1122</client_id></ser:getUserProfile></soapenv:Body></soapenv:Envelope>
<Enter>
<Enter>

Con esta llamada al web service, se deberá generar una respuesta que nos será devuelta en forma de otro mensaje XML-SOAP:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605)/Tomcat-5.5
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Wed, 21 Oct 2009 16:34:56 GMT

4b8
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope>
  <soapenv:Body>
    <ns1:getUserProfileResponse>
      <userprofile href="#id0"/>
    </ns1:getUserProfileResponse>
    <multiRef id="id0" soapenc:root="0">
      <SEQ_ID xsi:type="soapenc:string">556677889900</SEQ_ID>
      <regionId href="#id1"/><userType href="#id2"/>
    </multiRef>
    <multiRef id="id1" soapenc:root="0">9</multiRef>
    <multiRef id="id2" soapenc:root="0">1</multiRef>
  </soapenv:Body>
</soapenv:Envelope>
0

¡Voila! Algo talachuda pero exitosa llamada a un web service desde un cliente Telnet.

Troubleshooting

Hay un par de detalles que debemos observar cuando realicemos la llamada:

La primera, algo trivial, es el detalle de la codificación del mensaje. Siempre es importante saber el tipo de codificación que están usando tanto el cliente como el web service, pues en caso de ser diferentes podemos toparnos con errores debido a que cualquiera de los dos puntos, ya sea el de publicación o el de consumo, no reconozcan algunos de los caracteres del XML enviado o la respuesta retornada. Por ello, si el servidor codifica UTF-8, el cliente deberá ajustarse a UTF-8.

Segunda y más importante es el tamaño del mensaje en la última línea del encabezado HTTP así como los dos <enters> que tecleamos entre encabezado y mensaje y al final del mensaje. Por ello es mejor eliminar espacios e indentación del mensaje: disminuyen el riesgo que incluyamos "caracteres demás" ya que pueden aparecernos cualquiera de los siguientes errores:

• java.net.SocketTimeoutException: Read timed out. Debido a que el web service está esperando el resto del mensaje "faltante". Esto es porque la longitud es incorrecta o nos faltaron los dos <enters> al final del propio mensaje.

• org.xml.sax.SAXParseException: Reference is not allowed in prolog. Debido a que encuentra un ampersand (&) en el encabezado de la petición. Esto es porque nos faltó un <enter> entre el encabezado y el mensaje o la longitud que se incluyó es demasiada.

• org.xml.sax.SAXParseException: The processing instruction target matching &quot;[xX][mM][lL]&quot; is not allowed. Esto se debe a que el parser del lado del servidor está encontrando un caracter menor-que (<), mayor-que (>), comillas (") ó ampersand (&) en el encabezado de la petición. De nueva cuenta, puede ser porque nos faltó un <enter> entre el encabezado y el mensaje XML o nos quedamos cortos con la longitud que se incluyó en el encabezado.

Conclusiones

Y así podemos hacer de manera rápida y puntual una pequeña prueba de concepto para verificar que un web service está arriba, parsee correctamente un mensaje y nos regrese una respuesta válida. Claro que si vamos a desarrollar algo más que un par de peticiones, siempre será mejor instalar SOAP UI o pedir a los administradores que nos echen la mano con el firewall para poder ver el web service publicado desde las máquinas de desarrollo, con el fin de que mejoremos nuestra productividad, acabemos más rápido y todos seamos más felices.

h1

SOA (Parte 2)

09/11/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

En el anterior post describimos de manera general qué es un SOA, cuáles son sus orígenes y sus elementos más característicos. En esta ocasión nos enfocaremos en la parte funcional del SOA: qué elementos arquitectónicos lo componen y cómo interactúan entre sí. Adicionalmente veremos los frameworks SOA comerciales más fuertes en el mercado y revisaremos sus principales ventajas y desventajas.

Los elementos arquitectónicos de un SOA

Como comentamos anteriormente, un SOA es un modelo de diseño de arquitecturas empresariales; sin embargo, la implementación del mismo no sólo consiste en publicar web services y ya: aunque en un principio esto puede funcionar para facilitar la adopción de SOA, poco a poco conforme vayamos publicando más y más servicios, volveremos a un esquema desordenado. Así entonces, tarde o temprano el volumen de servicios será tal que:

• Será difícil encontrar los servicios que se necesitan. Esto es progresivamente más frecuente conforme publiquemos un más servicios.

• No será posible realizar una efectiva administración de los servicios y forzar su adhesión a un estándar organizacional, incluyendo características tales como seguridad o políticas de publicación y consumo.

Comúnmente este tipo de problemas son resueltos sobre la marcha, sin embargo es importante considerarlos y atacarlos desde la fase de diseño del SOA para evitar futuros cuellos de botella, facilitando la adopción del nuevo paradigma y lograr ver desde un principio los beneficios asociados a este tipo de arquitecturas:

Un esquema que muestra los componentes del SOA y las relaciones (publicación, descubrimiento, consumo) entre éstos.

[Click en imagen para ver a mayor escala]

A continuación se describen los componentes del SOA en mayor detalle:

• Capa aplicativa. Este elemento contiene las interfaces de usuario final; principalmente las aplicaciones web o cliente-servidor que consumen los procesos construidos a través del Gestor de Procesos y aquellos servicios que han sido publicados por terceros. La capa aplicativa es más dependiente de lenguajes o frameworks de desarrollo (por ejemplo, interfaces web desarrolladas en Java o aplicaciones que interactúan con sistemas legados desarrolladas en C/C++).

• Capa de servicios de terceros. Son los servicios publicados por organizaciones ajenas a la nuestra (por ejemplo, el servicio SOAP publicado por Google para explotar su motor de búsquedas). Dichos servicios son consumidos por la Capa Aplicativa y el Gestor de Servicios, siendo publicados en el Directorio de Servicios[1].

• Orquestador de Datos/Gestor de Servicios. El gestor de servicios u orquestador de datos[2] es el componente cuya función principal es la construcción de los procesos de negocio que utilizará la organización en su capa aplicativa mediante el uso de los servicios que han sido publicados en el Service Registry, incluyendo los servicios publicados por terceros[1]. Adicionalmente, este elemento interactúa con el Directorio de Servicios para extraer los metadatos de los servicios que se integrarán, aunque también hace uso de otro tipo de características como monitoreo o gestión del ciclo de vida de los procesos generados. Por otro lado, es frecuente que este componente incluya una interfaz de usuario que permita construir los procesos mediante la representación diagramática de BPEL (Business Process Execution Language – Lenguaje de Ejecución de Procesos de Negocio)[3].

• Directorio de Servicios. Este elemento es en su forma más simple un repositorio de los servicios publicados así como una "sección amarilla" que utilizará el Gestor de Servicios para construir los procesos de negocio. En versiones más sofisticadas incluye un componente de gestión y gobierno de los servicios incluyendo características tales como gestión del ciclo de vida de los servicios, versionamiento y gobernabilidad (es decir, adhesión a las políticas de negocio y seguridad que permean toda la arquitectura).

• Adaptadores ESB/ETL/EAI y Conexión XDMS[4]. No todas las fuentes de datos o lógica de negocio son fácilmente convertibles a servicios. En algunos casos, es necesario primero utilizar conectores o drivers nativos que son accedidos mediante "servicios empaquetadores" (wrapper services) para su uso por el resto de la arquitectura. Un ejemplo clásico es extraer la información de una AS400 utilizando un adaptador basado en la especificación JCA (Java EE Connector Architecture).

• Repositorio de Datos. Son las fuentes de información como Bases de Datos o archivos planos así como de lógica de negocio, incluyendo sistemas de Planeación de Recursos Empresariales (Enterprise Resource PlanningERP) como SAP R/3. Como se vio en el punto anterior, algunas de estas fuentes de datos no cuentan con interfaces de extracción de datos homogéneas que puedan usarse en un SOA, por lo que la extracción de la información de éstas requiere de adaptadores[4] para su explotación.

El Enterprise Service Bus

Un tema que no hemos visto hasta ahora ha sido, de entre todos estos componentes, ¿quien funciona como el "pegamento" que los une y permite su interacción? ¿Quién realiza la validación de mensajes entre servicios, reforzando las políticas de negocio y seguridad definidas? ¿Quién se dedica a realizar las transformaciones de los mensajes del formato seleccionado para nuestro SOA a los formatos utilizados por la capa aplicativa?

Presentamos el Enterprise Service Bus (o Bus de Servicios Empresariales – ESB) cuya función principal, de manera análoga al bus de las placas base o motherboards, es conectar los diferentes componentes del SOA, permitiendo el intercambio de información entre todos los elementos de la arquitectura:

Vista esquemática del Enterprise Service Bus. Éste es el middleware que gestiona el transporte, ruteo y seguridad de los mensajes entre los consumidores y publicadores de los servicios.

[Click en imagen para ver a mayor escala]

Como puede verse en el diagrama, el ESB es un bus de datos que facilita el transporte de los mensajes entre los consumidores y los publicadores de servicios realizando la tarea de mediación entre éstos:

• Transformaciones: conversiones XML a XML, búsquedas en base de datos y agregaciones (jerarquías de documentos).

• Validación de Mensajes: verificación de campos de datos o combinación de éstos contra reglas específicas de negocio.

• Selecciones de servicio de contenido o calidad: Selección de servicios basada en el contenido o calidad del servicio requeridos. En pocas palabras, balanceo de carga y failover.

• Ruteo basado en contenido: Como ejemplo, si los parámetros del servicio contienen información del país de origen, la petición puede ser redirigida al proveedor designado para ese país.

• Logueo personalizado: Este es un requerimiento legal que puede ser necesario para algunas interacciones entre servicios.

• Monitoreo y métricas de funcionamiento: Un bus debe poseer los puntos de control necesarios para controlar su comportamiento y de los servicios integrados:

Consola de monitoreo del AquaLogic Enterprise Service Bus de BEA/Oracle. (Original obtenido de BEA AquaLogic Service Bus 2.1 Documentation > User Guide > Monitoring )

[Click en imagen para ver a mayor escala]

• Comportamiento automático: Debe existir alguna funcionalidad que permita la auto-configuración, alta disponibilidad y optimización de recursos.

• Administración de políticas: Descripción de las reglas de comportamiento requeridas por todos los puntos anteriores y fácilmente configurables a través de archivos de metadatos basados en XML o algún otro lenguaje descriptivo.

Visto desde el punto de vista de implementación, el ESB es el framework de desarrollo o producto comercial con el cual construiremos nuestro SOA, siendo tan sencillo o tan complejo como deseemos; la mejor opción es utilizar frameworks que contengan todos los elementos de un SOA ya integrados para facilitar la adopción de la nueva arquitectura, como veremos en la siguiente sección.

Implementaciones SOA/ESB

Actualmente existen de manera dominante tres suites, frameworks o implementaciones comerciales del middleware SOA/ESB que permiten la adopción de una arquitectura orientada a servicios:

• AquaLogic de BEA/Oracle.

• Java Composite Application Platform Suite (Java CAPS) de Sun Microsystems.

• Connected Services Framework (CSF) de Microsoft.

Adicionalmente existen otras implementaciones (Como OpenESB) pero su principal limitante es el escaso soporte que ofrecen, un punto muy importante en un proyecto tan complejo como puede ser SOA y que podría requerir una alta curva de aprendizaje; por otro lado a menos que el presupuesto de migración a SOA sea muy reducido[5], es mejor contar con las soluciones que estos proveedores ofrecen.

Ahora bien, haciendo la comparación entre las tres plataformas:

•  AquaLogic es el mejor producto de su clase pero el precio que manejan, aún con el modelo de ventas utilizado por Oracle[6], es astronómico.

• El producto de Sun es muy bueno, pero le falta un poco de pulido a sus interfaces de usuario (esencialmente porque en ocasiones la construcción de procesos puede volverse una pesadilla de micromanagement y "necesitamos" un monitor de 24 pulgadas):

Interfaz de usuario del Process Manager (vista de alto nivel de un proceso, sin detallar los servicios individuales) en el Java CAPS. (Original obtenido de From Java CAPS 5.1.x to Java CAPS 6 and Open ESB – Reuse or Rewrite)

[Click en imagen para ver a mayor escala]

• Finalmente CSF tiene que ver con la penetración de la tecnología Microsoft: si nuestra infraestructura está montada en una arquitectura Wintel, adelante; de lo contrario estamos saltando de la sartén al fuego.

Conclusiones

Hemos visto que la implementación de un SOA no sólo es publicar y consumir web services: se trata de hacer disponibles los servicios de datos y lógica de negocio de una manera estandarizada para que puedan ser utilizados por las diferentes áreas de una organización; todo ello mediante un marco tecnológico – el Enterprise Service Bus – que nos permita realizar de manera efectiva las tareas de gestión, transporte y mediación de los servicios y procesos que componen nuestro SOA. Por otro lado, hemos visto que Sun, BEA/Oracle y Microsoft son los proveedores de soluciones tecnológicas de implementación SOA más importantes del mercado, siendo AquaLogic la mejor pero más cara, JCAPS la de mayor curva de aprendizaje y Microsoft una solución efectiva si disponemos de una infraestructura Wintel.

Notas y pies de página

1. ¿Por qué publicar servicios de terceros en nuestro Directorio de Servicios? Porque adicionalmente a la "sección amarilla" que ofrece, incluye otras funcionalidades como el cache y versionamiento de servicios; características que pueden ser útiles cuando hay que integrar a terceros en nuestros procesos de negocio.

2. Se denomina orquestador de datos porque en su forma más pura, éste componente sólo utiliza servicios de extracción de datos para conformar – orquestar – los procesos de negocio que requiere la capa aplicativa.

3. BPEL es un lenguaje basado en XML que posee una representación diagramática (ver aquí un ejemplo de un algoritmo de transformación) que permite la construcción de procesos de negocio y que fue originalmente desarrollado por la Organización para el Avance de Estándares Estructurados de Información (Organization for the Advancement of Structured Information StandardsOASIS). Actualmente, en la versión 2.0, dicho leguaje ha sido tomado por proveedores para desarrollar sus implementaciones de ESB y frameworks SOA.

4. Los adaptadores ESB (Enterprise Service Bus) son aquellos que de manera nativa pueden ser utilizados para un SOA (por ejemplo, si nuestro protocolo es HTTP y nuestro formato es SOAP, implicaría que nuestra fuente de datos puede regresar queries en forma de documentos XML). Los adaptadores ETL (Extract, Transform and Load – Extraer, Transformar y Cargar) son aplicaciones que obtienen consultas de las fuentes de información y las transforman de manera no nativa al formato que estamos buscando. Los adaptadores EAI (Enterprise Application Integration – Integración de Aplicaciones Empresariales) son, en resumidas cuentas, aquellos que se conforman a un estándar de integración como JCA. Finalmente, XDMS (XML Document Management Server – Servidor de Gestión de Documentos XML) es el equivalente a una base de datos que en vez de almacenar esquemas entidad-relación, almacena jerarquías de documentos XML.

5. Sin embargo, queda la interrogante: si el cliente escatima en un proyecto de tal envergadura – que por poner un ejemplo, puede consistir de unas 20,000 horas/hombre – ¿no es probable que no esté entendiendo el alcance de SOA o los beneficios que ofrece?

6. El modelo de ventas de Oracle es en resumidas cuentas: el costo de licencia por cada producto se multiplica por el número de CPUs en los que está corriendo, considerando los siguientes tabuladores: si el CPU es específicamente un Sun UltraSPARC T1 con 4, 6 u 8 cores, las licencias se multiplican 0.25 por cada core; en el caso de AMD es 0.5 por cada core y en el caso de cualquier otro fabricante multicore – es decir, Intel o alguno de sus partners – se multiplica 0.75 por cada core. Para procesadores de un solo core se contabiliza una licencia por CPU.

h1

SOA (Parte 1)

09/06/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks.

Había una vez un paradigma de diseño de arquitecturas IT – si es que así lo podemos llamar – donde todos los sistemas y recursos de una organización se localizaban y eran ejecutados desde una computadora central o mainframe. Dicho paradigma, denominado monolítico, tenía como misión generar reportes mediante procesos por lotes para facilitar la toma de decisiones de la alta dirección.

Sin embargo, a partir de la década de 1960 y con la creación del microprocesador, este paradigma comenzó a menguar en favor de las arquitecturas cliente-servidor, donde una computadora (el cliente) generaba una petición a otra (el servidor), que tomaba dicha petición, realizaba un procesamiento y devolvía un resultado; todo ello a través de un medio electrónico.

Desde ese momento la información de una organización y los procesos que la "masajeaban" ya no residían en una misma máquina, lo que desembocó en una explosión de requerimientos de las unidades de negocio hacia sus respectivas áreas IT para diseñar, construir y liberar cada vez más soluciones de acuerdo a sus necesidades específicas. Con la venida del Internet se reforzó la tendencia, pues aunadas a los sistemas de apoyo a la toma de decisiones, ahora se demandaban soluciones IT para prácticamente cualquier ámbito dentro de la organización: desde catálogos, órdenes de compra o administración de los recursos humanos hasta soluciones de mensajería y chat.

Sin embargo, esta explosión de sistemas de información trajo consigo un problema de gestión de arquitecturas: conforme aumentaba el número de aplicaciones, mayor necesidad había de integrar la información y los procesos que operaban sobre ésta, degenerando en un esquema como se muestra a continuación:


Una arquitectura empresarial convencional.
[Click en imagen para ver a mayor escala]

Este desorden genera estructuras rígidas y difíciles de adaptar a los requerimientos de una organización o sus necesidades de negocio. Así entonces, se encontró que la mejor forma de atacar el problema era diseñando una arquitectura que hiciera provecho de las tecnologías que facilitaban la interconexión entre plataformas de un ambiente heterogéneo generando un nuevo modelo de implementación arquitectónica. CORBA y SOAP son las tecnologías de mayor relevancia, aunque EDI fue el precursor de dichas plataformas de integración.

¿El resultado? La Arquitectura Orientada a Servicios (Service Oriented Architecture – SOA):

SOA es un paradigma de diseño de arquitecturas empresariales que facilita la conexión de las diferentes aplicaciones y fuentes de información mediante componentes seguros y estandarizados (los servicios) de tal manera que puedan ser reutilizados y combinados de manera flexible para atacar las cambiantes prioridades del negocio:

Una Arquitectura Orientada a Servicios. Nótese que el Gestor de Procesos es el encargado de combinar los servicios para generar procesos coherentes que sirvan a las necesidades de la organización, mientras que el Directorio de Servicios funciona como una "Sección amarilla" que permite listar y encontrar todos los servicios que contiene la organización.


[Click en imagen para ver a mayor escala]

Los servicios que componen un SOA

Una arquitectura orientada a servicios está compuesta por unidades lógicas individuales que existen de manera autónoma sin estar aisladas totalmente unas de otras. Estas unidades deben ajustarse a una serie de reglas y principios que les permiten evolucionar de manera independiente, manteniendo al mismo tiempo cohesión entre ellas y hacia un estándar. Dichas unidades son conocidas como los servicios:

Cuando se realiza la transformación de una arquitectura convencional a un SOA, comúnmente la generación de servicios se implementa sobre soluciones con procesos claramente definidos:

Los servicios pueden encapsular fragmentos de lógica de negocio de diferente "tamaño", "peso" o complejidad.

Como puede apreciarse en el diagrama, podemos fragmentar los procesos en unidades lógicas más sencillas que encapsulen operaciones con mayor o menor complejidad; si generamos nuestro SOA a partir de aplicaciones implementadas bajo el modelo de Programación Orientada a Objetos (Object-Oriented Programming – OOP), esta tarea puede ser llevada a cabo con mayor facilidad pues las operaciones de los objetos pueden ser publicadas como servicios:

Un Objeto de Acceso a Datos (Data Access Object – DAO) y un componente de negocio (en este caso un Enterprise Java Bean – EJB) tienen publicados sus métodos como servicios.


[Click en imagen para ver a mayor escala]

Frecuentemente se asocia un SOA y los servicios que lo componen a los llamados web services o servicios web, sin embargo la implementación de web services no es un SOA por sí mismo ni un SOA tiene que estar compuesto necesariamente por web services: los web services son una plataforma de interoperabilidad que facilita la generación y envío de mensajes entre sistemas heterogéneos. Es decir, mientras existan (1) un protocolo de transporte y (2) un formato de codificación y decodificación de los mensajes, cualquier medio puede ser utilizado para construir un SOA:

• SOAP – Simple Object Access Protocol.
• CORBA – Common Object Request Broker Architecture.
• SNMP – Simple Network Management Protocol.
• FTP – File Transfer Protocol.
• SMTP – Simple Mail Transfer Protocol.

Por ejemplo, es posible construir un SOA basado en SOAP para definir el formato de los mensajes y SMTP como medio de envío. Dicho de otra manera: llamadas a través de mensajes XML sobre correos electrónicos para ejecutar los servicios (aquí se muestra un ejemplo de esta implementación en el lenguaje de programación Python).

Conclusiones

SOA es un paradigma de construcción de arquitecturas empresariales como en un momento lo llegaron a ser los sistemas monolíticos, el cliente-servidor o las arquitecturas de N-Capas. SOA es un compendio de todas las buenas prácticas de desarrollo e implementación de soluciones de hardware, software y gestión de sistemas basándose en la modularidad de componentes y procesos, agilizando el desarrollo de nuevas aplicaciones que sirvan a las necesidades de negocio de una organización. Por otro lado, un SOA no sólo se trata de UDDI, WSDL y HTTP: los web services sólo son una plataforma de interconexión mientras que SOA es un modelo arquitectónico.

Por el momento, sólo hemos visto la punta del iceberg. En el próximo post veremos que una Arquitectura Orientada a Servicios no sólo se trata de publicar servicios sin ton ni son, sino que la implementación – véase las "tripas" – de un SOA está compuesta por una multitud de elementos arquitectónicos como BPEL (Business Process Execution Language), XDMS (XML Document Management Server) o el tan cacareado ESB (Enterprise Service Bus).

h1

Desarrollo de servicios web sin SOAP con XMLBeans

06/03/2008

Wizdoc [Icon By Buuf]

 Tips & Tricks

Generalmente se piensa que los Web Services [o Servicios Web] son sinónimo de servicios ofrecidos a través de SOAP. Esta es una visión limitada de los web services. Cualquier pieza de código con una descripción WSDL de sus aspectos funcionales y protocolos de acceso puede ser considerada un Web Service.

— Nirmal Mukhi, Web service invocation sans SOAP, 01 Sep 2001

Especificación General

Como puede verse en la siguiente figura, se requiere hacer la llamada al sistema Y desde el sistema X mediante el envío de un XML sobre una conexión HTTP/POST síncrona. Del lado del servicio publicado se encontrará un servlet que recibirá las peticiones y fungirá como un Service Facade, atrapando las peticiones y remitiéndolas a los componentes de parseo, validación y ejecución correspondientes para este servicio (denominados Core API del sistema o capa de negocio). Del lado del cliente o consumidor del servicio se espera implementar un componente que realice una conexión HTTP con el servicio y envíe el XML esperado a través del método POST. Más tarde, el servicio responderá con otro XML detallando el éxito o error resultante de la llamada que a su vez será parseado y validado por el cliente para tomar las acciones pertinentes.

Diagrama de componentes UML 2.0 (no estándar) que contempla la distribución a grosso modo de los elementos que conforman el servicio.

[Click en imagen para ver original]

Especificación de los mensajes

En la siguiente tabla se especifican los puntos requeridos en forma y formato de los mensajes a enviar. Nótese que entre los requerimientos no se incluye la necesidad de implementar SOAP como protocolo de envío.

Protocolo

XML codificado en UTF-8 sobre HTTP versión 1.1

Método de petición al servidor

HTTP/POST

Formato XML petición (X a Y)

<?xml version="1.0" encoding="UTF-8"?>
<ProvisioningRQ>
  <IdTransaction>0</IdTransaction>
  <TypeTransaction>BAJA</TypeTransaction>
  <Dn>1234567890</Dn>
</ProvisioningRQ>

Formato XML respuesta (Y a X)

<?xml version="1.0" encoding="UTF-8"?>
<ProvisioningRS>
  <IdTransaction>0</IdTransaction>
  <CodError>0</CodError >
  <DescError>OK</DescError >
</ProvisioningRS>

Aunque no es requerido, debemos generar un WSDL como referencia para saber cómo se realizará la llamada al servicio:

<?xml version="1.0" ?>
<definitions
 targetNamespace="http://everac99.spaces.live.com/wsdlexample&quot;
 xmlns:ytox="http://everac99.spaces.live.com/ytoxxsd&quot;
 xmlns:xsd="http://www.w3.org/1999/XMLSchema&quot;
 xmlns="http://schemas.xmlsoap.org/wsdl/"&gt;

  <message name="ProvisionInput">
   <part name="ProvisionRequest" type="ytox:ProvisioningRQ"/>
  </message>

  <message name="ProvisionOutput">
   <part name="ProvisionResponse" type="ytox:ProvisioningRS"/>
  </message>

  <portType name="ProvisionPT">
   <operation name="Provision">
    <input message="tns:ProvisionInput"/>
    <output message="tns:ProvisionOutput"/>
   </operation>
  </portType>
</definitions>

Los componentes e información seguirán el siguiente flujo:

Diagrama de secuencia UML que contempla el flujo de eventos a seguir por el servicio.
Notas:
1.Si la sintaxis o valores de negocio de la petición al servicio son incorrectos, se construirá la respuesta correspondiente.
2.Si la sintaxis o valores de negocio son correctos, se prosigue con la llamada a las funciones que requiere la operación.
3.Por "operaciones necesarias" contemplamos la llamada a una o más funciones del sistema "Y", tratando todo como una sola unidad transaccional.

[Click en imagen para ver original]

A partir del diagrama, podemos ver que se requiere un framework XML basado en DOM que nos facilite el trabajo de parsear y validar los valores contenidos en el XML; adicionalmente nos debe permitir construir documentos XML de forma eficiente y con un buen desempeño al generar nuestra respuesta. Por ello, se decidió utilizar la implementación 2.3.0 de XMLBeans. Este framework nos permite utilizar las funciones de parseo, validación o generación de XMLs en base a una jerarquía de componentes de java generados mediante las herramientas que posee dicho framework. A continuación describiremos el proceso de generación de nuestros componentes en base a tan sólo los XMLs de prueba que tenemos más arriba y cómo utilizarlos en un servicio web que recibe y envía los XMLs a través de la conexión HTTP.

Paso 1: Generando un XSD

Uno de los buenos hábitos al utilizar XML, es que siempre es recomendable definir un XSD (XML Schema Definition) para gestionar nuestros XMLs de manera centralizada. Adicionalmente, para generar los correspondientes XMLBeans requerimos un XSD.

Puesto que sólo disponemos de los XML de petición y respuesta deberemos generar el XSD a través de éstos. Existen varias herramientas de conversión XML a XSD en el mercado, pero podemos utilizar la herramienta de conversión on-line ofrecida por HiT Software donde podemos transformar nuestros XMLs en los XSDs que necesitamos.

Herramienta de conversion xml a xsd
Un screenshot de la herramienta de conversión de XML a XSD y el archivo XML con el ProvisioningRQ de nuestro servicio. NOTA: La herramienta no parsea correctamente XMLs con varios elementos, es decir, hay que generar un XSD con el merge de los resultados la transformación de ProvisioningRQ y ProvisioningRS.

[Click en imagen para ver original]

El resultado de la conversión de nuestros XMLs será algo así:

<?xml version="1.0" encoding="UTF-8" ?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;
 <xs:element name="Dn">
  <xs:complexType mixed="true"/>
 </xs:element>

 <xs:element name="IdTransaction">
  <xs:complexType mixed="true"/>
 </xs:element>

 <xs:element name="ProvisioningRQ">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="IdTransaction"/>
    <xs:element ref="TypeTransaction"/>
    <xs:element ref="Dn" />
   </xs:sequence>
  </xs:complexType>
 </xs:element>

 <xs:element name="TypeTransaction">
  <xs:complexType mixed="true"/>
 </xs:element>

</xs:schema>

El código mostrado es el XSD del elemento ProvisioningRQ. Para generar el XSD de la aplicación, es necesario realizar un merge de los XSDs del request y response e incluir las reglas de formato, tipos de datos o restricciones que sean requeridas para parsear correctamente los XMLs que utilizará la aplicación. Las propiedades que pueden tomar estos elementos pueden verse en el tutorial sobre XSDs del W3Schools; para validar los XMLs contra nuestra XSD refinada podemos utilizar una pequeña herramienta llamada XmlValidator. La definición final para esta aplicación sería la siguiente:

<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

 <!– Tipos de datos –>
 <xs:element name="IdTransaction" type="xs:string"/>
 <xs:element name="Dn" type="xs:string"/>
 <xs:element name="TypeTransaction" type="xs:string"/>
 <xs:element name="CodError" type="xs:string"/>
 <xs:element name="DescError" type="xs:string"/>

 <xs:element name="ProvisioningRQ">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="IdTransaction" minOccurs="1" maxOccurs="1"/>
    <xs:element ref="TypeTransaction" minOccurs="1" maxOccurs="1"/>
    <xs:element ref="Dn" minOccurs="1" maxOccurs="1"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>

 <xs:element name="ProvisioningRS">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="IdTransaction" minOccurs="0" maxOccurs="1"/>
    <xs:element ref="CodError" minOccurs="0" maxOccurs="1"/>
    <xs:element ref="DescError" minOccurs="0" maxOccurs="1"/>
   </xs:sequence>
  </xs:complexType>
 </xs:element>

</xs:schema>

Paso 2: Generando los XMLBeans

En Adictos al Trabajo podemos encontrar un buen tutorial para instalar y ejecutar las herramientas de conversión de los XMLBeans. Sin embargo, existen tres detalles que es necesario observar:

•  Hay que tener cuidado con qué versión de Java estamos trabajando. Es decir, necesitamos verificar que el compilador y el ambiente de ejecución (javac.exe y java.exe, respectivamente) estén correctamente configurados en el path del ambiente de desarrollo y en el archivo ${XMLB_HOME}binscomp(.cmd) porque puede surgir el error "CreateProcess Exception" al tratar de compilar el XSD (En el Java Boutique se encuentra la explicación y solución al problema).

•  Por otro lado, si estamos usando una versión anterior a Java 1.5, adicionalmente a la librería base de XMLBeans llamada xbean.jar, deberemos incluir en la distribución de la aplicación el archivo xmlbeans-qname.jar para poder utilizar correctamente esta funcionalidad.

•  Finalmente, la tarea de ant para generación de XMLBeans deja mucho que desear. La forma más flexible de crear y empaquetar correctamente los componentes es mediante la línea de comando:

>${XMLB_HOME}/bin/scomp -javasource 1.4 -out ${ProjectHome}/lib/xmltypes.jar ${ProjectHome}/config/xsd/ytoxxsd.xsd ${ProjectHome}/config/xsd/ytox.xsdconfig
Time to build schema type system: 0.937 seconds
Time to generate code: 0.328 seconds
Time to compile code: 3.422 seconds
Compiled types to: ${ProjectHome}/lib/xmltypes.jar
>

Donde:
•  ${XMLB_HOME} Es el directorio donde está instalado el framework.
•  ${ProjectHome} Es el directorio donde está nuestro proyecto.
•  ytoxxsd.xsd Es el XSD que generamos en el paso anterior.
•  ytox.xsdconfig Es un archivo de configuración XML que permite mapear los namespaces del XSD con paquetes de java:

<?xml version="1.0" encoding="UTF-8"?>
<xb:config xmlns:xb="http://xml.apache.org/xmlbeans/2004/02/xbean/config"&gt;
  <xb:namespace uri="##any">
    <xb:package>
     com.spaces.everac99.xml.types
    </xb:package>
  </xb:namespace>
</xb:config>

Esto dará por resultado un JAR con los componentes de Java que podrán ser utilizados en el proyecto de Eclipse:

El JAR con XMLBeans en nuestro proyecto de Eclipse
El JAR con XMLBeans en nuestro proyecto de Eclipse.

Paso 3: Usando los XMLBeans

Como puede verse en el siguiente fragmento de código:

public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException {

/* Parseo del HttpRequest InputStream para construir un XMLBean */
BufferedInputStream in = new BufferedInputStream(request.getInputStream());
ProvisioningDocument req = ProvisioningDocument.Factory.parse(in);
String idTransaction = req.getProvisioning().getIdTransaction();

/* Validacion de reglas de negocio y ejecucion de operacion (llamada a Core API)*/

/* Construccion de un nuevo XMLBean desde cero y envio al HttpResponse OutputStream*/
ProvisioningResponseDocument res = ProvisioningResponseDocument.Factory.newInstance();
res.documentProperties().setVersion("1.0");
res.documentProperties().setEncoding("UTF-8");
res.addNewProvisioningResponse();
res.getProvisioningResponse().setIdTransaction("12345");
res.getProvisioningResponse().setCodError("007");
res.getProvisioningResponse().setDescError("UNKNOWN ERROR");

BufferedWriter out = new BufferedWriter(response.getWriter());
res.save(out);
out.flush();
out.close();

}

Construir y manipular los XMLBeans generados a partir del XSD es muy intuitivo: En el primer segmento de código se está construyendo un XMLBean a través de la secuencia de llamadas BeanClassDocument.Factory.parse(InputStream). Por otro lado se está construyendo un nuevo documento mediante la secuencia BeanClassDocument.Factory.newInstance() y se está almacenando en la respuesta de la petición mediante el método BeanObjectDocument.save(OutputStream).

XMLs con elementos mixtos

Un detalle que puede presentarse durante la construcción de un servicio de este tipo es la generación o parseo de documentos XML que poseen elementos mixtos: es decir, nodos que pueden contener más subnodos, texto o combinaciones de ambos:

<?xml version="1.0" encoding="UTF-8"?>
<Response>
  <RESULT msisdn="telefono1">ABCD999999A1B</RESULT>
  <RESULT msisdn="telefono2">
    <ERROR id="045">UNKNOWN NUMBER</ERROR>
  </RESULT>
</Response>

En el ejemplo se muestra la respuesta a un servicio de búsqueda donde puede traer de 1 a 10 elementos de tipo RESULT. Cada elemento contiene una propiedad denominada msisdn y dentro de la etiqueta en sí puede existir un texto o un elemento de tipo ERROR.

Sin embargo, esta situación no tiene por qué generar preocupación, pues con un XSD de este tipo de documento podremos generar los XMLBeans que necesitamos:

<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"&gt;

 <xs:element name="ERROR">
  <xs:complexType mixed="true">
   <xs:attribute name="id" type="xs:string"/>
  </xs:complexType>
 </xs:element>

 <xs:element name="RESULT">
  <xs:complexType mixed="true">
   <xs:sequence>
    <xs:element ref="ERROR" minOccurs="0" maxOccurs="1"/>
   </xs:sequence>
   <xs:attribute name="msisdn" type="xs:string" use="required"/>
  </xs:complexType>
 </xs:element>

 <xs:element name="RESPONSE">
  <xs:complexType>
   <xs:sequence>
    <xs:element ref="RESULT" minOccurs="1" maxOccurs="10" />
   </xs:sequence>
  </xs:complexType>
 </xs:element>

</xs:schema>

Al utilizar este tipo de documentos tendremos que utilizar una característica algo enredosa de los XMLBeans denominada XMLCursor:

/* Leyendo un elemento de tipo mixed de un XMLBean */
BufferedInputStream in = new BufferedInputStream(request.getInputStream());

ResponseDocument res = ResponseDocument.Factory.parse(in);

if(res.getResponse().getRESULTArray(0).getERROR() == null) {
  /* Significa que este elemento contiene texto */
  XmlCursor cursor = res.getResponse().getRESULTArray(0).newCursor();
  cursor.toFirstContentToken();
  String valor = cursor.getChars();
} else {
  /* Significa que este elemento contiene un subnodo */
  String errorId = res.getResponse().getRESULTArray(0).getError().getId();
}

/* Escribiendo texto en un elemento de tipo mixed en un XMLBean*/
ResponseDocument doc = ResponseDocument.Factory.newInstance();
doc.addNewResponse();
doc.getResponse().addNewRESULT();
doc.getResponse().getRESULTArray(0).setMsisdn("telefono1");
XmlCursor cursor = doc.getResponse().getRESULTArray(0).newCursor();
cursor.setTextValue("ABCD999999A1B");
cursor.dispose();

Esta interfaz nos permite saltar a lo largo de la estructura del documento XML facilitando la modificación de los valores e incluso agregar nuevas etiquetas de elementos.

Conclusiones

Como hemos visto, no es difícil construir un servicio web utilizando los XMLBeans como framework de conversión XML a Java, pues como tienen métodos que nos permiten cargar o enviar nuestros XMLs desde o hacia streams de datos, podemos utilizar sus características para ahorrar tiempo, dinero y esfuerzo a la hora de construir la solución. Un beneficio adicional: si necesitamos implementar web services con SOAP también podemos utilizar XMLBeans y trabajar sobre clases de Java, no sobre cadenas de XML que son bastante difíciles de codificar y peor aún de mantener.

h1

Frameworks de desarrollo de web services: ¿Cuál es el mejor?

01/08/2008

Wizdoc [Icon By Buuf]  Tips & Tricks.
Con cierta regularidad, ya sea para la integración de plataformas mediante web services o para los pininos de una arquitectura orientada a servicios, es necesario seleccionar puntualmente una tecnología mediante la cual implementaremos la publicación o consumo de dichos servicios que componen nuestra solución.

En la actualidad existen cuatro excelentes frameworks – tres de los cuales son opensource – mediante los cuales pueden generarse los servicios y clientes correspondientes de la solución; sin embargo todos tienen sus ventajas y desventajas dependiendo del contexto bajo el que realizaremos nuestros web services. A continuación, una descripción breve de dichos frameworks con sus pros y contras:

Framework Descripción
BEA Workshop Más IDE que framework debido a su capacidad de generar desarrollos completos que incluyen EJBs o páginas web, el Workshop permite la implementación de web services de forma más o menos sencilla, utilizando una interfaz gráfica en conjunto con tablas de propiedades.


Vista típica en el Workshop al generar un web service.

Como es costumbre con el software de BEA, aunque el producto en sí es excelente y cuenta con mucha flexibilidad, el precio es estratosférico al grado que muchas empresas medianas no tienen los recursos para utilizarlo. Peor aún si se considera que los servicios que genera están casados con el Weblogic y no es posible migrarlos a otro servidor más que a pata.

Apache Axis Siendo un framework maduro patrocinado por Apache, Axis permite implementar de forma bastante sencilla los web services. Dicho framework tiene una gran ventaja sobre los demás: para los web services RPC-Style[1] no hay ninguno que se le compare: es la mejor implementación en existencia. Por otro lado, su mayor defecto es la limitada capacidad de soporte para web services DOC-style[1]; los plugins de Axis para Eclipse son chafitas y de acuerdo al tipo de codificación del mensaje[2] la integración entre estos servicios y plataformas como Weblogic pueden generar dolores de cabeza.
Apache Axis 2 Esta es la otra cara de la moneda: Axis 2 es la mejor implementación de servicios DOC-style, al grado que por sus características técnicas es el único framework comparable a la implementación de referencia de Sun (Glassfish Metro). El principal detalle con el que me he encontrado en este framewrok es la parte del databinding[3], que puede convertirse en un desmother de administración de la configuración:


99 clases (paquete org.xmlsoap.schemas.soap.encoding) para sólo un web service
[Click aquí para ver tamaño original]
Glassfish Metro Siendo no oficialmente la implementación de referencia – pues existe mucha retroalimentación con equipos de desarrollo de Sun – Metro podría ser el mejor framework opensource de web services existente salvo por un pequeño detalle: sólo opera bajo el JEE 5, lo que nos limita a unos cuantos contenedores[4] y es algo que muchos clientes no pueden o no están dispuestos a adquirir; Máxime que aquí en México la mayoría tiene Weblogic 8.x o JBoss (certificados para JEE 4).

Como hemos visto – a grandes rasgos – dependiendo de que tipo de web services vamos a implementar y cómo se da el contexto de nuestro proyecto, podremos decidir qué framework se adapta mejor a nuestras necesidades:

  • Cuando no hay limitaciones en cuanto al costo de las licencias (sobre todo para SOAs de gran envergadura o empresas que tienen la capacidad económica), Workshop nos puede dar todo lo que necesitamos.
  • Cuando requerimos web services síncronos, estemos integrando plataformas homogéneas (es decir, JEE con JEE) o que por razones de desempeño requieran de estilo RPC, Axis es nuestro gallo.
  • Si es necesario generar web services con entrega garantizada de mensajes – o en pocas palabras, con un modelo asíncrono -, estemos integrando plataformas heterogéneas (por ejemplo JEE con .NET) o de plano nuestro usuario requiere una implementación de estilo documental, podemos ofrecer las bondades de Axis 2.
  • Finalmente, si nuestro cliente requiere una combinación de las anteriores y está dispuesto a lanzarse a adquirir lo último en tecnología, podremos proponerle Metro como una solución a sus problemas de integración.
Notas y pies de página

  1. Los web services de tipo RPC (también conocidos como JAX-RPC) indican que el framework convierte los mensajes SOAP a objetos de Java – es decir, del lado del servicio nunca vemos un XML de por medio. Para los web services de tipo documental (o que implementan JAXM), el mensaje llega directo a la aplicación como un XML, siendo deber de ésta manipular el mensaje de acuerdo a las necesidades de la lógica de negocio.
  2. Los mensajes SOAP enviados por un web service tienen dos tipos de estructura: codificados y literales. Los codificados están construidos de acuerdo a un modelo de datos definido por SOAP; los literales se construyen de acuerdo a un schema (el famoso archivito con terminación .xsd). El problema con ambas estructuras es que en el caso de los mensajes codificados, no existe una definición final de dicha codificación, por lo que puede haber diferencias de implementación – de hecho .NET o Axis 2 no los soportan – y en el caso de los mensajes literales se incrementa la complejidad de las aplicaciones que conforman el web service debido a la manipulación de los XMLs o la integración de frameworks de terceros para poder utilizar la información contenida en éstos.
  3. Por experiencia, el databinding es en realidad una conversión Java-Documento XML que realizamos en las implementaciones de web services. Un ejemplo es el framework XMLBeans, implementado por Apache.
  4. Hasta este momento (08/01/2007) sólo existen 6 servidores certificados con JEE5:
    • Sun Java System Application Server 9.x (también conocido como Glassfish)
    • BEA Weblogic 10.x
    • SAP NetWeaver Application Server, Java EE 5 Edition
    • TmaxSoft JEUS 6
    • Apache Geronimo 2.0
    • IBM WebSphere Application Server Community Edition 2.0

h1

5 Herramientas Opensource y 10 Frameworks de desarrollo que todo delivery engineer debería conocer (Parte II)

08/02/2007

Wizdoc [Icon By Buuf]  Tips & Tricks.
Continuando con el tema iniciado la semana pasada, donde describí 5 herramientas opensource indispensables para cualquier developer, hoy concluyo con los 10 frameworks que, aventurándose a un proyecto sin ellos, tenemos la mejor receta para el desastre: recuerdo un proyecto en una anterior vida donde se requería la generación y/o parseo de archivos XML de varios Megabytes de longitud. El arquitecto decidió que …los frameworks no tienen utilidad y es mejor hacerlo a mano… y así fue, hasta que todo reventó espectacularmente.

Dejando los rodeos, éstos son los frameworks que no sólo pueden salvar un proyecto, sino también un trabajo (o dos o más, si el equipo esta muy comprometido con el proyecto):

Framework: Echo2
Tipo: AJAX (Asynchronous JavaScript and XML)
Desarrollado originalmente por NextApp y liberado posteriormente como opensource bajo las licencias Mozilla Public License o GNU LGPL, es EL framework por excelencia en cuanto a AJAX se refiere: cuando se necesite una aplicación web con cliente rico (parecido al meebo), este framework es como implementar una aplicación AWT/Swing pero sin la necesidad de conocer HTML o Javascript.


Demo de Echo2

Ya en una ocasión anterior resumí una comparación originalmente realizada en The Server Side entre este framework y el Google Web Toolkit proporcionando los pros y contras de ambas tecnologías; por supuesto ambos destronan al infame JackBe.

Framework: Hibernate
Tipo: ORM (Object Relational Mapping)
Desde el principio: ORM se refiere a aquellas tecnologías dedicadas a la integración y comunicación de sistemas de datos relacionales (es decir, cualquier base de datos existente como Oracle) con lenguajes orientados a objetos (por ejemplo, Java).

La principal característica de Hibernate es que permite realizar el mapeo casi transparente entre clases de Java y tablas en la base de datos; los queries son generados por el framework liberando al programador de las tareas de generación de conexión, conversiones a partir del ResultSet y demás labor de bajo nivel. Por esta simple funcionalidad, Hibernate en conjunto con Spring, provocará la desaparición de los EJBs – especialmente los Entity Beans. Al grado que prácticamente la especificación EJB 3.0 fue diseñada tomando a Hibernate y Spring como modelos a seguir por Sun para evitar la desaparición de su propia tecnología.

Framework: Jasper Reports (+ Herramienta iReport)
Tipo: Reporteo
Concebido desde el principio como un proyecto opensource, Jasper Reports es el framework de su tipo más utilizado en la industria, permitiendo la generación de reportes con los formatos "más buscados" (desde PDF o HTML hasta XML). Adicionalmente tiene algunos "extras" que facilitan la labor del programador o mejoran los resultados del producto terminado: añadir gráficas (en conjunto con el framework JFreeChart, descrito más abajo), funciones tales como cálculo de consolidados, números de página, promedios, mínimo, máximo, etcétera.


El "primer reporte" en Jasper

Por otro lado, la herramienta de diseño iReport tiene una curva de aprendizaje muy baja, y en conjunto estas dos tecnologías ayudan a generar reportes en un dos por tres.

Framework: JCSP (Java Communicating Sequential Processes)
Tipo: Multithreading
Desarrollado inicialmente como un proyecto académico por parte de Peter Welch, de la Universidad de Kent (Canterbury, Reino Unido), este framework está basado en la investigación relacionada a los Procesos de Comunicación Secuencial, que básicamente son una rama de la teoría de la computación relacionada a la descripción de patrones de interacción en sistemas concurrentes. En pocas palabras, tanto la teoría como la implementación realizada por el framework abstraen la capa de multithreading (Threads/Runnable) y evitan que el programador "meta las cuatro" al construir un sistema con este tipo de requerimientos.
Framework: JFreeChart
Tipo: Graficación (Histogramas, gráficas de pie, líneas, dispersión)
De acuerdo a la información desplegada en el home del proyecto:

El proyecto JFreeChart fue fundado hace siete años, en febrero del 2000, por David Gilbert. En la actualidad, JFreeChart es usado por aproximadamente 40-50 mil desarrolladores (ver aquí una lista de los proyectos que utilizan JFreeChart). El proyecto continúa siendo administrado por Gilbert, con las contribuciones de una diversa comunidad de desarrolladores.

El financiamiento del proyecto es proporcionado por Object Refinery Limited, la compañía de David Gilbert basada en el Reino Unido. Object Refinery vende la documentación y servicios de consultoría relacionados a JFreeChart.


Uno de los muchos tipos de gráficas obtenidos mediante JFreeChart

Así entonces, JFreeChart utiliza el mismo modelo comercial de JBoss o Sun Microsystems: como desarrollador puedes descargar el software y utilizarlo de forma libre, pero si requieres documentación o soporte, ahí te la dejamos ir.

Framework: Log4J
Tipo: Bitácoras/depuración
Parece difícil que a estas alturas todavía existan proyectos donde se siga utilizando System.out.println() para depurar programas; especialmente aquellos donde el desempeño de la aplicación está en juego. Sin embargo, he visto aplicaciones donde el nivel de transaccionalidad es altísimo (300 o más transacciones compuestas por segundo) y aún así para cada paso de la transacción lo utilizan. La respuesta es Log4J, que adicionalmente a ser un proceso ligero (es decir, el memory footprint y el overhead resultantes de integrarlo a nuestra aplicación son muy bajos), permite varios niveles de depuración (o lo que es lo mismo: sólo "imprime" los mensajes del tipo asignado, desde el aburrido DEBUG hasta el temido FATAL) es muy sencillo de instalar e integrar a cualquier componente, desde stand-alones hasta JSPs, servlets o EJBs. De hecho, cualquier framework que se respete contiene por ahí su archivo de configuración del log4j para que podamos depurarlo.
Framework: OSCache
Tipo: Sistema de Cacheo (Caching System)
Cuando se requiere algo más que sólo un Hashtable para implementar nuestro cache (por ejemplo, caches que automáticamente se actualicen cada cierto tiempo, o que requieran ser persistidos en disco) podemos utilizar la implementación ofrecida por OpenSymphony: adicionalmente a las características antes mencionadas, incluye otros features que agregan robustez y escalabilidad al framework, como tags de JSP para el manejo dinámico del cache o plugins de persistencia con JDBC y OLAP. Finalmente, lo que me pareció realmente interesante del proyecto es que puede integrarse a Hibernate, proporcionando funcionalidad de cache sobre la base de datos (de primera instancia, cargar en el cache los catálogos de la aplicación me parece un buen inicio).
Framework: Quartz
Tipo: Calendarización de eventos
Implementado también por OpenSymphony, Quartz es un framework que nos permite calendarizar eventos, extendiendo la funcionalidad básica de las clases de Java java.util.Timer y java.util.TimerTask para incluir novedades tales como manejo del estado resultante del evento (éxito/fracaso), JobListeners y TriggerListeners que escuchan cuándo sucede la ejecución de un evento, implementación de transaccionalidad (JTA), entre otras. Adicionalmente, al igual que OSCache, este framework ha sido diseñado tomando en cuenta su integración a Hibernate y Spring.

Nota: El único detalle que le he encontrado es que para ciertos servidores de aplicaciones (específicamente el Sybase EAServer) puede generar errores fatales que tiran el servidor debido a la manera en que maneja los hilos de ejecución.

Framework: Spring
Tipo: Middleware / Reemplazo de la especificación EJB
Altamente basado en las técnicas de Inversión de Control (Inversion of Control – IoC) y Programación Orientada a Aspectos (Aspect-Oriented Programming – AOP), Spring es un framework que ha revolucionado la manera en que se desarrollan sistemas de alta escalabilidad y robustez. Genuinamente llevando a cabo las promesas incumplidas por los EJBs, Spring permite desarrollos más orientados al negocio (en vez de ser orientados a la tecnología implementada). Adicionalmente, es un framework muy completo que puede funcionar como middleware por las siguientes características y/o módulos que lo componen:

  • Es un lightweight container (En términos simples, mantiene y gestiona pools de Java Beans).
  • Mediante la AOP que lo integra, logra implementar una capa de abstracción para la gestión de la transaccionalidad.
  • También posee una capa de abstracción para las implementaciones de JDBC.
  • Es integrable con un sinnúmero de frameworks (Quartz, Hibernate, Tapestry, entre otros).
  • Posee su propio submódulo MVC que opera bastante bien al integrarlo con web frameworks como Struts o Tapestry.

Aunque la curva de aprendizaje de Spring es algo elevada, es bastante menor que la de los EJBs y como mencioné anteriormente, ha incluso afectado el cómo se definió la propia especificación EJB 3.0 y probablemente, tarde o temprano la reemplace o elimine por completo.

Framework: Tapestry
Tipo: Presentación (Web)
Mi favorito en cuanto a MVCs, aunque poco utilizado en la industria (espero que con la llegada de los JSF esto cambie), Tapestry es un framework que por su excelente documentación, facilidad de aprendizaje, mantenibilidad y relativa escalabilidad, cada que implemento un proyecto web y puedo seleccionar las tecnologías de implementación, me voy por éste.


El Tapestry Component Workbench

Nota: Por ahí llegué a escuchar que no funciona del todo montado sobre el Websphere, pero ya lo he visto correr sin problemas sobre Sun Application Server, Weblogic y hasta Sybase EAServer.

Conclusiones

Ahhh listo; por supuesto que hay muchos otros frameworks que son igualmente útiles para nuestros proyectos de JEE delivery (como Apache Axis), pero estos son los más significativos en cuanto a capacidad y uso. Tomando prestada la leyenda en la entrada del Infierno de La Divina Comedia (con un poco de mi cosecha, claro está): "¡Oh vosotros los que entráis a este proyecto sin sus frameworks al hombro abandonad toda esperanza!"