Abordar los retos de interoperabilidad de la especificación WS-Security, Parte 1: Visión general del problema y cuatro métodos alternativos disponibles

¿Tiene dificultades con un problema de interoperabilidad de nivel de especificación WS-Security? Los servicios web son a menudo promocionados como la solución ideal para la interoperabilidad de aplicaciones, y son eficaces en la integración de aplicaciones independientemente de la plataforma, el proveedor, y el lenguaje de programación. Pero no son inmunes a problemas de interoperabilidad. Descubra algunos de los problemas comunes causados por las incompatibilidades entre las diferentes versiones de la especificación WS-Security, y encuentre la mejor manera de tratar con los problemas de su entorno. Asegúrese de extraer la útil gráfica al final de la solución.

David Leigh, Advisory Software Engineer, IBM

David LeighDavid Leigh es un Ingeniero de Software Sénior en la organización del laboratorio de análisis del Grupo de Sofware de IBM, está ubicada en Research Triangle Park, Carolina del Norte. Sus áreas de especialización incluyen IBM WebSphere Process Choreographer, la aplicación y el servidor de seguridad, alta disponibilidad, supervisión, IBM AIX®, y Linux®.



06-01-2012

Una visión general de los problemas de incompatibilidad

. La mayoría de los problemas de interoperabilidad no surgen de la base de la especificación de los servicios web (que es bastante madura y estable), sino más bien de las distintas extensiones de los servicios web WS-*, como WS-Security. A medida que estos estándares evolucionan, los proveedores deben elegir que especificaciones de borrador soportan, y ocasionalmente los desarrolladores necesitan hacer frente a problemas de incompatibilidad entre especificaciones diferentes

. El estándar WS-Security proporciona mecanismos para la aplicación de la autenticación, integridad y confidencialidad de los mensajes SOAP. Estas posibilidades son a menudo necesarias para la adopción de servicios web y la Arquitectura orientada a servicios (SOA) dentro de la empresa. IBM® middleware comienza proporcionándonos soporte para WS-Security con IBM WebSphere® Application Server V5.0.2. Esta implementación de WS-Security estaba basada en la especificación 13 del borrador de trabajo OASIS. WebSphere Application Server V5.1 y otro middleware de IBM basado en la plataforma Java™ 2 La plataforma, Enterprise Edition (J2EE) 1.3 tiempo de ejecución (como el IBM WebSphere Portal Server V5 y el IBM WebSphere Business Integration Server Foundation V5) también contiene implementaciones de WS-Security en base a la especificación 13 del borrador. Con el J2EE 1.4 tiempo de ejecución incluido en el WebSphere Application Server V6.0, IBM proporciona una implementación WS-Security en base a la especificación WS-Security 1.0. Servidor de Proceso WebSphere de IBM y otro middleware de IBM que utiliza J2EE 1.4 tiempo de ejecución contiene implementaciones WS-Security basadas en las especificaciones de la versión 1.0.

Desafortunadamente, debido a los cambios en el formato de conexión de las especificaciones de la cabecera WS-Security SOAP, las aplicaciones de consumidores de servicios web y servicios web de destino que de acuerdo a la especificación del borrador 13, no pueden interactuar con las aplicaciones del consumidor y servicios de destino que se ajusten a la especificación de la versión 1.0. Por ejemplo, una aplicación de consumidor de servicios web J2EE 1.3 ejecutándose en el Servidor de Portal WebSphere V5.1 no puede utilizar WS-Security para comunicarse con la aplicación del proveedor de servicio J2EE 1.4 ejecutándose en WebSphere Application Server V6.0. Y el problema no se limita a la pila IBM middleware software. Por ejemplo, la mejora del Microsoft® NET Web Services Enhancements (WSE) 1.0 también está basada en la versión borrador de la especificación WS-Security, y aparecen los mismos problemas de interoperabilidad, cuando se intenta la comunicación entre esta pila y cualquier otra que esté basada en la especificación WS-Security 1.0.

Figura 1. Problema de incompatibilidad de nivel de especificación de WS-Security
Problema de incompatibilidad de nivel de especificación de WS-Security

Si se enfrenta a esta incompatibilidad, dispone de algunas opciones para sortear el problema. El resto de este artículo describe estas opciones y proporciona algo de orientación hacia la elección de una solución adecuada en base a las necesidades y las limitaciones técnicas de su empresa.

En beneficio de la simplicidad, supongamos que un consumidor de una aplicación de servicios web utiliza la especificación 13 del borrador de WS-Security, y la aplicación de proveedor de servicio web utiliza la especificación WS-Security 1.0.Nota: el método alternativo que aquí se sugiere también se puede aplicar al caso de ejemplo inverso en el que el consumidor del servicio web utiliza la especificación WS-Security 1.0 y el proveedor de servicios web utiliza la especificación 13 del borrador.


Método alternativo 1: Actualizar las aplicaciones de consumidor de servicios web a J2EE 1.4

La forma más sencilla de evitar totalmente el problema es asegurarse de que sus aplicaciones de consumidor de servicios web utilizan la misma versión de la especificación de WS-Security que las aplicaciones de proveedor de servicios web. Esto requiere el actualizar la aplicación de consumidor de servicios web a J2EE 1.4, y posiblemente también actualizar su middleware a la versión que soporte las aplicaciones J2EE 1.4.

La actualización de las aplicaciones de consumidor de servicios web J2EE 1.3 a J2EE 1.4 es un ejercicio de desarrollo. El IBM Rational® Application Developer proporciona al asistente de migración J2EE el poder migrar proyectos Enterprise JavaBeans (EJB), proyectos Web , proyectos de arquitectura de conexión J2EE (JCA), y servicios web del nivel de especificación J2EE 1.3 al nivel de especificación J2EE 1.4.

Para utilizar el asistente de migración J2EE para migrar de la aplicación J2EE 1.3 a J2EE 1.4, simplemente haga clic en el proyecto Entrerprise Application en la vista del proyecto Explorer de la perspectiva J2EE, a continuación seleccione Migrate > J2EE Migratión Wizard desde el menú pop-up . Una vez completado el asistente, puede configurar el enlace del cliente WS-Security. Estos enlaces no se migran automáticamente a través del asistente, y deben configurarse de forma manual como una tarea de pos-migración.

Lo siguiente que necesita para asegurarse de que el servidor de aplicaciones para el cual la aplicación de consumidores de servicios web se ha desplegado puede soportar aplicaciones J2EE 1.4. Para aplicaciones de empresa, WebSphere Application Server V6.0 puede ejecutar aplicaciones J2EE 1.4. Y para los portlets, Servidor de Portal WebSphere V5.1.0.4 puede ejecutar un proyecto Web que ha sido migrado a J2EE 1.4. Si dispone de estas versiones o versiones posteriores, entonces las aplicaciones de consumidores de servicios web deben ejecutarse sin problemas. De lo contrario, puede que tenga que actualizar su middleware.

Figura 2. Actualización de la aplicación(es)de consumidor de servicios web a J2EE 1.4
Actualización de la aplicación(es)de consumidor de servicios web a J2EE 1.4
Tabla 1. Roles y tareas para actualizar las aplicaciones de consumidores de servicios web a J2EE 1.4
Rol Tarea
Desarrollador de aplicaciones Migración de desarrollo Aplicaciones de consumidores de servicios web a J2EE 1.4
ImplementadorConfiguración del entorno operativo J2EE 1.4 para las aplicaciones de consumidores de servicios web
Prueba de ingenieroVerificar que el consumidor de servicios web migrado funciona como se espera

Migración de la aplicación y (si es necesario) su middleware a J2EE 1.4 es la mejor forma de evitar el problema de interoperabilidad de nivel de las especificaciones WS-Security. Elimina el problema por completo y ofrece los beneficios estratégicos de estar en los últimos niveles de código middleware.

Sin embargo, dependiendo de sus aplicaciones y su entorno de middleware, puede resultar inconveniente o difícil migrar sus aplicaciones de consumidor de servicios web a J2EE 1.4. Además, el esfuerzo necesario para implementar este enfoque aumenta de forma lineal con cada aplicación de consumidor de servicios web adicional utilizando la especificación 13 del borrador de WS-Security que se debe migrar.


Método alternativo 2: La utilización de Web Services Gateway.

el Web Services Gateway del es un componente de software de IBM WebSphere Application Server Network Deployment, que puede se opcionalmente configurado una vez instalado el producto. Los aparatos IBM WebSphere DataPower SOA, son dispositivos de red expresamente diseñados y fáciles de usar. Ambos dispositivos Web Services Gateway y WebSphere DataPower SOA están diseñados para simplificar y garantizar la implementación de los servicios web en la empresa. Los dispositivos WebSphere DataPower SOA se pueden utilizar además para mejorar el rendimiento de las aplicaciones de servicios web.

Tanto los dispositivos Web Services Gateway o DataPower se puede utilizar para direccionar los problemas de interoperabilidad de nivel de especificación de WS-Security. Como se muestra en la Figura 3, ambas soluciones tienen la capacidad de proxy un servicios web que utiliza las especificaciones WS-Security 1.0 y hacer que este servicio se encuentre disponible para todos los consumidores de servicios web que utilizan la especificación 13 del borrador de WS-Security.

Nota: en el resto de este articulo, este método alternativo aparece como el enfoque proxy middleware .

Figura 3. Utilización del dispositivo Web Services Gateway o DataPower
Utilización del dispositivo Web Services Gateway o DataPower
Tabla 2. Roles y tareas en la utilización del enfoque middleware proxy
RolTarea
ImplementadorInstalación del dispositivo Web Services Gateway o DataPower
Configuración del servicio J2EE 1.4 en el dispositivo Web Services Gateway o DataPower
Prueba de ingeniero Verificar que el consumidor de servicios web funciona como se espera

Una ventaja del enfoque de middleware proxy es que no hay que realizar tareas de desarrollo de aplicaciones. El proveedor de servicios web y las aplicaciones de consumidor pueden interactuar a través del middleware proxy sin cambios. Por esta razón, el middleware proxy se adapta bien cuando hay muchos consumidores de servicios web utilizando la especificación 13 del borrador de WS-Security que necesitan integrarse con un proveedor de servicios web utilizando la especificación WS-Security 1.0. Después de la instalación y configuración de middleware proxy con un proveedor de servicios, se puede utilizar para integrar cualquier número de consumidores de servicios web sin ningún esfuerzo adicional.

Otra ventaja de este enfoque es que usted gana todos los beneficios del uso del dispositivo Web Services Gateway o DataPower. Estos componentes pueden simplificar la implementación y la gestión de los servicios web de la empresa, y por lo tanto mejorar la rentabilidad de la inversión de la infraestructura y aplicaciones de sus servicios web. Además, si usted elige utilizar un dispositivo de DataPower, las posibilidades en el dispositivo en realidad puede mejorar el rendimiento de las aplicaciones de sus servicios web. Para más información sobre los beneficios de los dispositivos Web Services Gateway y WebSphere DataPower SOA, vea los enlaces en la sección Recursos al final de este artículo.

Una desventaja del enfoque middleware proxy, es que introduce un conjunto de operaciones y tareas de administración non trivial. Debe instalar, configurar y administrar el componente middleware proxy como cualquier otro componente de infraestructura crítico. Si ha adquirido el WebSphere Application Server Network Deployment Edition, entonces ya tiene el componente de Web Services Gateway , y no es necesaria ninguna compra adicional. Por otro lado, si elije utilizar un dispositivo DataPower, puede que surjan costos asociados con la adquisición este dispositivo de red.

Otro inconveniente es que este enfoque podría romper el modelo de confianza entre el consumidor de servicios web y el proveedor de servicios web. Esto se debe a que, dependiendo de la seguridad que se aplica, el middleware proxy puede ser necesario para verificar y descifrar el mensaje SOAP entrante que envía al proxy el consumidor, y a continuación volver a aplicar la seguridad en el mensaje SOAP saliente que se envía al proveedor desde el proxy. Esto puede que tenga una seria implicación con la arquitectura de seguridad.


Método alternativo 3: la utilización de EJB proxy

Si está buscando una alternativa ligera y de bajo costo al enfoque middleware proxy , la utilización de un EJB proxy podría ser adecuada. En este enfoque, se desarrolla y se implementa una nueva aplicación EJB J2EE 1.4 en el nivel del middleware frontal, que además alberga la aplicación de consumidor de servicios web. Este enfoque requiere que el nivel del middleware frontal contenga el WebSphere Application Server V6.0 o posterior, u otro servidor de aplicaciones J2EE que pueda soportar aplicaciones J2EE 1.4.

La Figura 4 muestra cómo el enfoque de EJB proxy se utiliza para permitir la comunicación entre la aplicación del portal J2EE 1.3 y el proveedor de servicios web J2EE 1.4. La aplicación del portal se comunica con el servidor EJB proxy por medio de la interfaz de Invocación del Método Remoto (RMI) del EJB , y el EJB pasa la solicitud al proveedor de servicios web utilizando la especificación WS-Security 1.0.

Figura 4. Utilizar su EJB proxy
Figura 4. Utilizar su EJB proxy
Tabla 3. Roles y tareas en la utilización del enfoque EJB proxy
RolTarea
Desarrollador de aplicacionesCrear la aplicación EJB proxy
Integrar el consumidor de servicios web con la aplicación EJB proxy
Implementador Implementar y gestionar la aplicación EJB proxy
Prueba de ingenieroVerificar que el consumidor de servicios web funciona como se espera

El esfuerzo requerido para implementar el enfoque de EJB proxy es principalmente un trabajo de desarrollo de aplicación, aunque este método alternativo introduce otra aplicación que el equipo de operaciones debe implementar, asegurar, y gestionar.

El enfoque EJB proxy es el más adecuado al recinto de seguridad, prueba, o situaciones de prueba de concepto en las que actualizar las aplicaciones de consumidores de servicios web a J2EE 1.4, no es una opción y en el que el coste de la creación de un middleware proxy es prohibitivo. Un inconveniente de este enfoque, es que no se adapta bien cuando hay muchos consumidores de servicios web utilizando la especificación 13 del borrador de WS-Security que necesitan integrarse con un proveedor de servicios web que utilice la especificación WS-Security 1.0. En este caso, cada aplicación de consumidor de servicios web debe ser integrada por separado con el servidor EJB proxy, que puede hacer que el esfuerzo de desarrollo necesario sea mayor


Método alternativo 4: Añadir un nuevo punto final de proveedor

En este último enfoque, se añade un punto final de servicios web J2EE 1.3 a la aplicación de proveedor J2EE 1.4. Dependiendo de cómo se implemente la aplicación de proveedor de servicios web J2EE 1.4 , puede ser un ejercicio simple de añadir un proyecto web adicional basado en la especificación Java Servlet 2.2 (J2EE 1.3) y empaquetar este con la aplicación del proveedor. Su proveedor de aplicaciones contará entonces con dos puntos finales de servicios web como se muestra en la Figura 5

Figura 5. Añadir un nuevo punto final de proveedor
Añadir un nuevo punto final de proveedor
Tabla 4. Roles y tareas en la utilización del nuevo enfoque de punto final del proveedor
RolTarea
Desarrollador de aplicacionesCrea un nuevo punto final de servicios web en un nuevo proyecto Web Java Servlet 2.2
Paquete del nuevo proyecto Web en el archivo J2EE 1.4 EAR
ImplementadorImplementar y gestionar la aplicación de proveedor de servicios web
Prueba de ingenieroVerificar que el consumidor de servicios web funciona como se espera

Este enfoque se adapta bien cuando hay muchas aplicaciones de consumidor de servicios web. Una vez modificada la aplicación del proveedor de servicios web, de manera que proporcione un punto final de servicios web J2EE 1.3-compatible, pueden utilizar este nuevo punto final cualquier número de aplicaciones de consumidor de servicios web. Y a diferencia del enfoque EJB proxy o el enfoque middleware proxy, este enfoque no tiene ningún impacto en el rendimiento

Como con el enfoque EJB proxy, este método alternativo es principalmente un ejercicio de desarrollo de aplicación e introduce otro punto final de servicios web que se debe gestionar y proteger.

Este enfoque se utiliza mejor cuando las clases de implementación de servicios web de son simples componentes JavaBeans o componentes EJB. Si la lógica de implementación de servicios web es contenida en un servlet, en un componente Arquitectura de Componente de Servicio (SCA), o en un módulo de mediación Enterprise Service Bus (ESB), entonces es probable que resulte difícil crear un proyecto y paquete Web servlet de Java 2.2 (J2EE 1.3) con la aplicación de proveedor de servicios web.


Resumen

Tabla 4 comprende los beneficios e inconvenientes de los tres métodos alternativos descritos en este artículo para ayudarle a determinar el mejor enfoque del método alternativo.

Tabla 4. Comparación de los beneficios e inconvenientes del método alternativo
EnfoqueBeneficiosInconvenientesMás usado
Actualización de las aplicaciones de consumidor de servicios web a J2EE 1.4
  • Estar a los últimos niveles de especificación de middleware y J2EE
  • Sin impacto en el rendimiento
  • No muy escalable; cada aplicación de consumidor de servicios web debe migrarse por separado
  • También se necesita migración Middleware
  • Algunas aplicaciones y entornos middleware pueden resultar inconvenientes y difíciles de migrar
Cuando el número de aplicaciones de consumidor es pequeño, y especialmente cuando el entorno middleware de los consumidores secundarios ya puede soportar las aplicaciones J2EE 1.4
Utilizar un middleware proxy
  • Muy escalable; una vez configurado, el proxy puede soportar cualquier número de aplicaciones de consumidor
  • No se necesitan cambios en las aplicaciones de consumidor o proveedor
  • Fácil de gestionar los beneficios del dispositivo Web Services Gateway o DataPower
  • Beneficios de rendimiento al utilizar un dispositivo DataPower
  • Las tareas de administración y operaciones adicionales necesarias para soportar un nuevo componente de infraestructura crítica.
  • Algún impacto de rendimiento al utilizar el Web Services Gateway
  • Puede romper el modelo de confianza si el proxy tiene que verificar y descifrar el mensaje SOAP entrante y volver a aplicar la seguridad del mensaje saliente
Cuando hay un gran número de aplicaciones de consumo o cuando las aplicaciones de consumidor no se pueden modificar
Utilización de EJB proxy
  • La implementación es un ejercicio de programación básico, por lo tanto no necesita infraestructura extra
  • Algún impacto del rendimiento
  • No muy escalable; el EJB proxy se debe integrar con cada aplicación de consumidor
  • Introduce una nueva aplicación que debe ser, desplegada, protegida y administrada
Cuando necesita una ligera, solución de bajo coste para el recinto de seguridad, prueba o situación de prueba de concepto
Añadir un nuevo punto final de proveedor
  • La implementación es un ejercicio de programación básico, por lo tanto no necesita infraestructura extra
  • Sin impacto en el rendimiento
  • Muy escalable; una vez configurado, el proxy puede soportar cualquier número de aplicaciones de consumidor
  • No es fácil de implementar cuando la lógica implementación de un servicios web es más compleja que un simple componente JavaBeans o EJB
  • Introduce un nuevo punto final de proveedor que debe ser protegido y administrado
Cuando se busca una solución ligera y cuando la lógica implementación de un servicios web es un componente JavaBeans o EJB

Permanecer en sintonía para consiguientes artículos en esta serie, que proporcionará detalles y ejemplos que muestran cómo implementar los métodos alternativos middleware proxy y EJB proxy.

Acuse de recibo

Me gustaría agradecer a las siguientes personas sus comentarios y contribuciones a este artículo:

  • Hyen Chung, arquitecto y desarrollador principal de la seguridad de servicios web de la plataforma WebSphere
  • Billy Lo, sénior arquitecto de TI de, IBM Global Business Services

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=783819
ArticleTitle=Abordar los retos de interoperabilidad de la especificación WS-Security, Parte 1: Visión general del problema y cuatro métodos alternativos disponibles
publish-date=01062012