Apache ActiveMQ 5.0

Desde Apache, a la que aún considero la mejor factoría de software Open Source hoy en día, han lanzado una nueva versión de uno de sus mejores productos, el servidor de mensajería ActiveMQ (http://activemq.apache.org). Este software es el utilizado por la gran parte de herramientas de integración Open Source, como es el caso de Apache Service Mix, como soporte para su mensajería asíncrona.

En esta nueva versión, se han añadido multitud de nuevas funcionalidades (http://activemq.apache.org/new-features-in-50.html) y se han mejorado aspectos tales como el rendimiento de la persistencia, el soporte a Blobs en los mensajes y, por último, ya vienen definidos la mayor parte de los “Enterprise Integration Patterns” gracias a la herramienta Camel de Apache. Incluso proporciona un API para poder invocarlo directamente desde JavaScript, ideal para el escalado de los clientes web ricos que utilizan AJAX como tecnología subyacente.

Con todo lo anterior, creo que para todos aquellos que estáis interesados en el mundo de la integración, os recomiendo que os la descarguéis y le echéis un vistazo. Incluso aquellos que estáis acostumbrados a trabajar con otras herramientas, comerciales en su mayoría, creo que podréis encontrarlo interesante.

Yo, por el momento, haré lo propio y echaré un vistazo para ver realmente lo que ofrece. Conforme vaya avanzando, os iré contando mis impresiones.

SOA. Rendimiento vs Seguridad

En los sistemas de información en general, y en las Arquitecturas Orientadas a Servicios en particular, la seguridad de acceso es uno de los factores más importantes. Más, cuando las empresas no sólo ofrecen sus servicios entre sus diferentes equipos de desarrollo o áreas de la misma, sino cuando estos servicios son ofrecidos a entidad externas. Estas entidades, pueden llegar a ser individuos particulares que, con algo de pericia, pueden llegar a construir sus propios Mashups utilizando alguna de las herramientas gratuitas existentes: Yahoo Pipes http://pipes.yahoo.com/pipes/ , Microsoft Popfly http://www.popfly.com , etc.

Incluso, para ciertos servicios como son los ligados a las tramitaciones y gestiones de expedientes en las Administraciones Públicas, estas seguridades adquieren un carácter legal que implica dejar ciertos registros de Auditoría, garantizar el no-repudio, etcétera.

Por todo lo anterior es preciso dotar a los sistemas de determinadas herramientas que proporcionen seguridad en la invocación a los servicios. Seguridad no sólo de autenticación y autorización, sino también seguridad en el transporte (SSL con certificados, IPSEC, etcétera).

Todas estas capas de seguridad no hacen sino ralentizar el rendimiento de cada uno de los servicios, bien dentro de la plataforma de exposición de servicios en el caso de que se delegue esta funcionalidad dicha infraestructura, o bien en el servicio individual expuesto. Pero, ¿es necesario dotar de seguridad a todos los servicios? Pues lo cierto es que no. El “café para todos” no es algo que puede aplicarse dentro de este contexto. Por ejemplo, ¿tiene sentido dotar del mismo nivel de seguridad a los servicios expuestos internamente dentro de una compañía que a los expuestos para la interoperabilidad con terceros?¿y aquellos que tienen algún carácter económico o legal con el simple servicio de consultar la previsión del tiempo?

Es, por tanto, necesario realizar una catalogación de los servicios en base a los aspectos de seguridad requerida para los mismos e, incluso, esta seguridad puede terminar influyendo en el mecanismo de despliegue.

Consejo: A la hora de definir una Arquitectura Orientada a Servicios, no olvidar nunca los aspectos relativos a la seguridad. El sistema debe contar con el nivel de seguridad justo para proporcionar la funcionalidad requerida, pero el que un sistema o servicio sea seguro, no implica que esté necesariamente bien diseñado. En la seguridad, como en casi todo en esta vida, todo está bien en su justa medida.