¿Qué suele utilizar para conectarse a un servicio web cuando está desarrollando un proyecto Java?Servicios web en Java
Existen diferentes API-s que pueden hacer el trabajo. De diferentes libros y tutoriales sobre los que he leído: JAX-WS, JAXB, JAXM, JAXR, JAX-RPC, Axis ans y demás.
Me interesa saber qué es exactamente lo que usa y cuánto? Tome esto como una encuesta si lo desea :)
Para Responda su pregunta, primero debemos diferenciar entre las herramientas que enumeró.
JAX-WS, JAXB, JAXM, JAXR, JAX-RPC son XML y API relacionadas con servicios web mientras que Axis 1 y 2 son implementaciones de cero, una o más de estas API dependiendo de la versión.
JAX-B 1 y 2 son API de enlace XML a objeto, JAX-WS es una API de servicio web WSDL y SOAP y el antecesor de JAX-RPC, JAX-M es una API de mensajería XML anterior y JAX-R es una API de abstracción para interactuar con registros como UDDI y ebXML.
Desde la página de JAX-RPC Java.net:
El grupo de expertos JAX-RPC tiene la participación de toda la industria con Sun Microsystems como el plomo EG. La especificación inicial (JAX-RPC 1.0) era JSR-101 y se lanzó en junio de 2002. A continuación se publicó una versión de mantenimiento en octubre de 2003 que proporciona una mejor integración con JAXB 1.0 y una mejor compatibilidad con doc/literal.
La siguiente versión de la especificación se renombró de JAX-RPC 2.0 a JAX-WS 2.0 y se está desarrollando como JSR-224; esta versión abordará una serie de requisitos adicionales en el área, y aumentará la sinergia entre las especificaciones JAXB y JAX-WS. Puede acceder a la página del proyecto JAX-WS aquí.
Desde pilas de SOAP han recorrido un largo camino desde JAX-B 1.0 y JAX-RPC 1.0 recomiendo alojarse lejos del eje 1.0 y XFire (que si mal no recuerdo ni siquiera implementar JAX-RPC 1) . Existen numerosas pilas de SOAP que implementan las nuevas API (JAX-WS 2.x y JAX-B 2.x).
Como han mencionado otros, Axis 2, JAX-WS RI y CXF son opciones válidas. Estas pilas SOAP son mucho más maduras y admiten muchas especificaciones modernas WS- *.
Una palabra de advertencia acerca de los comentarios sobre el uso de su IDE para autogenerar el código del cliente. Si bien soy un gran defensor de la generación de código de enlace de datos XML y las interfaces JAX-WS de XSD y WSDL, respectivamente, advierto que debe usar un asistente integrado en su IDE para realizar la autogeneración. Si trabaja en un equipo con más de un desarrollador o planea modificar el código generado, debe considerar la mantenibilidad de dicho enfoque.
Si tiene más de un desarrollador, llegará el momento en que uno de ellos utilice una versión diferente de la herramienta de generación automática, un IDE diferente o una configuración diferente en su herramienta. Además, si genera automáticamente desde un asistente, corresponde a los desarrolladores recordar cómo generaron el código en caso de que necesite volver a generarlo en el futuro. Si cambia el XSD y no recuerda su configuración desde la última vez que se generó automáticamente, es posible que el código generado no se alinee con el código existente que ya se utiliza en su programa.
Si planea modificar el código generado, asegúrese de que solo necesita hacerlo una vez y que a partir de ese momento se siente cómodo manteniendo el código a mano o fusionando el código regenerado con sus modificaciones de forma regular.
Ambos problemas se pueden evitar escribiendo la generación de código en el proceso de compilación. JAX-WS y JAX-B vienen con tareas Ant y/o complementos Maven 2 que son fáciles de usar en sus compilaciones. Tome estas advertencias en serio ya que he visto varios proyectos sufrir a través de estos problemas cuando tenían que modificar el código que se generó hace 5 años por un empleado que había dejado la empresa.
Mis últimas palabras de precaución son tener cuidado al permitir que una herramienta genere automáticamente sus interfaces de servicios web desde sus WSDL. A la herramienta JAX-WS RI WSDL2Java le gusta colocar rutas de acceso codificadas al WSDL en las interfaces generadas.En mi opinión, debe generar automáticamente las interfaces una vez y luego eliminar las URL codificadas y las referencias QName para que la interfaz sea aplicable a todos los servicios web que implementan la vinculación WSDL que representa la interfaz y no solo al punto final que su WSDL describe.
http://cxf.apache.org/ es agradable.
Porque tenemos bastante inversión en Spring, usamos Spring-WS con JAXB.
puede usar, eje apache. Esto generará los talones de Java automáticamente si proporciona el WSDL. una vez que se generan los talones, es como llamar a una clase normal de Java.
He usado tanto JAX-WS RI como Apache CXF. Si está usando Spring, entonces CXF es una muy buena opción. Como Phill mencionó, también existe Spring-WS, pero CXF se basa en las especificaciones de JAX-WS. Si no está utilizando Spring, diría que RI es el camino a seguir, especialmente porque está incluido en Java 6.
Para POX + HTTP o servicios web RESTful, Restlet o un decente HTTP client implementation son completamente suficientes.
+1 para Apache Axis.
Pero JAX-WS también sería una buena opción.
Si leo su pregunta correctamente, está intentando ** consumir ** un servicio web. Parece que ya se tomaron decisiones sobre si se debe RESTful o si se basa en RPC. –
He usado tanto Axis como Axis2 y los encuentro muy buenos.
Creo que el uso más común es con Apache Axis2. Es muy fácil crear servicios con él y encontrarás muchos tutoriales.
Los defensores del eje aquí deben ser precisos.
El proyecto Axis 1.x se abandonó después del lanzamiento de Axis 1.4 en abril de 2006, hace más de tres años. Recientemente hemos encontrado varios errores de seguridad de hilos muy críticos en las bibliotecas de cliente de Axis 1.4, que incluyen giros y bloqueos del 100% de la CPU. Están bien documentados (y aún no están resueltos) en la base de datos de errores de Axis 1.x. No hace falta decir que estamos renunciando a Axis 1.x (y solo usando el código de cliente Apache HTTP sin procesar).
Axis 2 es una base de código completamente nueva ... quizás otra persona pueda comentar al respecto.
basada en nuestra experiencia nos consideraríamos metro, CXF, codificación manual, y (tal vez) Eje 2 para los servicios web SOAP. (Se recomienda enfoques basados en REST más de jabón cada vez que tenga una opción, y estamos utilizando el marco Restlet, que nos encanta)
OMI, que estaría completamente loco para ir con Eje 1.x
Además, Eclipse viene con un asistente de "Nuevo cliente del servicio web" que simplifica todo el proceso. Simplemente proporcione el WSDL y ni siquiera tendrá que preocuparse por AXIS. –
AXIS solía ser fácil, pero ahora es complicado. Ahora hay algo así como 59 archivos distintos Jar requeridos por AXIS2. ¡Santo fuma! Hora de cambiar caballos – Cheeso