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.

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.

Volver arriba

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.

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.

Volver arriba

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 .

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.

Volver arriba

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.

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

Volver arriba

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

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.

Volver arriba

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.

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

• Aprenda más acerca de la especificación de seguridad de servicios web (developerWorks, marzo 2004), incluye una visión general de WS-Security, enlace con las especificaciones actuales, y temas relacionados.
  
  
• Aprenda más acerca de Los dispositivos IBM WebSphere DataPower SOA .
  
  
• IBM Redbooks: "Implementación y Desarrollo Manual de servicios web WebSphere Versión 6" describe el concepto de los servicios web desde diferentes puntos de vista. Representa los pilares fundamentales sobre los que se basan los servicios web. Aquí, se presentan y comentan los nuevos conceptos y estándares bien definidos.
  
  
• La zona de servicios web y SOA en IBM developerWorks alberga cientos de artículos informativos y tutoriales introductorios, intermedios y avanzados sobre cómo desarrollar aplicaciones de servicios web.
  
  
• El web site IBM SOA ofrece una visión general de SOA y como IBM puede ayudarle.
  
  
• Visite el área de arquitectura de developerWorks para los recursos que necesita para mejorar sus habilidades en el campo de la arquitectura.
  
  
• Permanezca actualizado(a) con los eventos técnicos y webcasts de developerWorks.
  
  
• Busque libros sobre estos y otros temas técnicos en Safari bookstore.
  
  
• Obtenga el feed RSS para esta serie. (Descubra más acerca de RSS.)
  
  

Obtener los productos y tecnologías

• Innovar el siguiente proyecto de desarrollo con software de prueba IBM, disponible para descarga o en DVD.
  
  

Comentar

• Participar en el foro de debate.
  
  
• Visite los blogs de developerWorks, y forme parte en la comunidad developerWorks.
  
  

Sobre el autor

David 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®.

Califique este artículo

Comentario

Volver arriba

Tabla de contenidos

• Una visión general de los problemas de incompatibilidad
• Método alternativo 1: Actualizar las aplicaciones de consumidor de servicios web a J2EE 1.4
• Método alternativo 2: La utilización de Web Services Gateway.
• Método alternativo 3: la utilización de EJB proxy
• Método alternativo 4: Añadir un nuevo punto final de proveedor
• Resumen
• Acuse de recibo
• Recursos
• Sobre el autor
• Comentarios