2009-01-14 7 views
23

Actualmente estoy evaluando el número de frameworks de servicios web en Java. Necesito un marco de servicios web que me ayude a exponer algunas funcionalidades de las aplicaciones existentes que se ejecutan en JBoss. La aplicación se desarrolla principalmente con Spring y POJO (sin EJB).Framework/library de Java Web Service, ¿cuál es mejor y por qué?

Lo que necesito es un marco que tiene propiedades siguientes:

  1. debería proporcionar herramientas para la generación automática de código repetitivo y ahorrar tiempo al eliminar tareas repetitivas, por ejemplo, herramientas de generación de WSDL desde Java (Java2WSDL), herramientas generación de puntos finales, etc.
  2. Las aplicaciones se deben implementar fácilmente en la plataforma J2EE existente (JBoss), esto significa que debe contener menos archivos de configuración posible (como axis2.xml en framework axis2).
    • También se prefiere poder implementar el servicio web dentro del archivo .war de la aplicación existente. (Parece que Axis2 necesita un archivo separado para la aplicación de servicio web.)
    • Será genial usar una combinación de POJOs y Spring.
    • En general, la estructura debe tener una estructura y un diseño limpios (por ejemplo, Spring-WS carece de ella), una buena documentación y todo lo que caracteriza a una buena pieza de software.
    • Se prefiere que el marco incorpore algunas características estándar como JAX-WS etc. en lugar de métodos específicos del vendedor.

He examinado brevemente

  • Axis2
  • Apache CXF
  • y Metro de Sun
  • primavera WS

Pero aún así es difícil decidir qué para usar en mi caso:

  • Axis2 parece ser tan bajo nivel, se requiere archivo de la aplicación separada y una gran cantidad de configuraciones
  • primavera WS parece ser demasiado opaca y "sofisticado para propósitos de impresión (?)"
  • Apache CXF y Metro probablemente son dos marcos de los que prefiero elegir, pero todavía

Necesito su opinión y experiencia sobre el uso de algunos de ellos en aplicaciones del mundo real.

Respuesta

23

He usado el precursor de CXF, XFire, desde hace un tiempo y no ha sido tan malo. En ese momento, migramos de Axis por dos razones principales: el rendimiento y la facilidad de desarrollo. En ese momento (no sé si esto es cierto ahora), el rendimiento de XFire fue mucho mejor que cualquier otro, y con el desarrollo basado en anotaciones, en lugar de tener que ejecutar la generación de stub, fue realmente muy fácil agregar nuevos servicios web.

CXF parece ser más de lo mismo, pero mejor: no hemos migrado aún debido a limitaciones en el tiempo de desarrollo, así como no tener una razón urgente para hacerlo (además de la relativa falta de documentación hace 6-12 meses no fue muy alentador). Además, en realidad no he evaluado últimamente el mercado, así que no puedo decirles cómo CXF se enfrenta a sus competidores contemporáneos.

En cuanto a sus puntos:

  1. No hay código repetitivo que se generen, el WSDL se crea automáticamente a partir de las anotaciones de servicio de clase y publicado por el servidor.
  2. Despliegue en Tomcat fue relativamente simple. Simplemente defina otro servlet en web.xml y asigne un patrón de URL a este servlet.
  3. Nuestros servicios web se implementaron en archivos WAR, no estoy seguro de cuáles son las alternativas de hecho, pero esta parece ser la forma predeterminada y obvia de hacerlo.
  4. POJOs funcionan bien inicialmente; ahora hemos trasladado la mayor parte de la creación de objetos del servicio web a Spring para conectar dependencias condicional más complejas y no hemos tenido problemas con esto.
  5. La documentación era un punto débil con CXF originalmente, aunque acaba de echar un vistazo parece estar mejor ahora. El diseño general y la arquitectura parecen relativamente sanos; la asignación de espacio en los propios filtros para modificar los detalles de la transmisión no fue muy dolorosa, y en general se ha considerado extender las clases existentes (por lo que los métodos razonables se marcan protegidos en lugar de privados, por ejemplo).
  6. JAX-WS es totalmente compatible con CXF.

Así que probablemente soy un poco imparcial ya que no probé las otras, pero voy a dar mi visto bueno a echarle un vistazo a CXF. Es bastante rápido, relativamente simple de usar y bastante poderoso si necesita ajustarlo.

+0

He hecho tanto XFire como CXF y la actualización es relativamente sencilla. El archivo de configuración XML es un poco diferente, pero no mucho. –

3

Me gustaría ir con Spring WS primero y XFire segundo. Soy usuario de Spring, así que estoy acostumbrado a la opacidad.

2

XFire ahora Apache CXF era mucho más fácil de usar que Axis. Hice algo rápido al usarlo donde Axis parecía demasiado complicado. No miré Spring WS.

1

Solo he usado el Spring WS porque eso es lo que se me dijo que usara, pero era un marco de uso bastante fácil. Si tiene que ir con todo lo demás, iría con XFire debido al soporte de JAX-WS.

4

Hemos intentado con Metro y CXF y hemos mantenido CXF porque Metro incluye demasiadas dependencias como las API de Sun en sus archivos jar, lo que dificulta la integración en otro servidor de aplicaciones aparte de Glassfish. CXF tiene un empaquetado más limpio con dependencias externas explícitas. También fallamos al habilitar la compresión Gzip con Metro mientras funcionaba como un encanto con CXF.

2

Usaré CXF. Es fácil de usar que Axis2

Cuestiones relacionadas