Qu'apprendre à faire les services Web Java?

Question

La dernière fois que j'ai fait du développement web Java était en 2004 avec Java Servlets et JSP. Je n'ai jamais vraiment eu de succès avec les EJB. Je me souviens de mon expérience dans le développement de services web \ sites web dynamiques avec ceux-ci à être lent (en termes de temps de développement) et douloureux (en termes de déploiement facile).

Qu'est-ce que la plupart des entreprises utilisent pour développer des sites Web basés sur Java ces jours-ci? Utilisez-vous AXIS ou un autre cadre pour faire des services Web? Utilisez-vous JSP ou une autre technologie pour le frontal?

Answer 1

Les normes actuelles utilisent un JAX-WS (pour les services Web SOAP) et JAX-RS (pour les services Web RESTful).

Ce sont des normes qui ont plusieurs implémentations. JAX-WS a Metro, CXF, etc. JAX-RS n'a Jersey, RESTEasy, etc.

Answer 2

j'apprendrais pour ces

• RESTE
• XSD
• WSDL
• JAX- *
• Alternatives? (Thrift, Avro, Tampons de protocole, etc.)

Answer 3

Le support d'outillage et aussi la facilité de développement, a également parcouru un long chemin à partir de 2004. Avec l'accent mis sur les cadres légers (merci en partie au printemps), la mise en œuvre web les services en Java ne pourraient pas être plus faciles. Avant de décider de la mise en œuvre de services Web, vous devez répondre à une question simple. Savon ou REST.Je suggère que vous formez votre propre opinion, mais voici ce que je pouvais penser, sur le dessus de ma tête.

Pour de SOAP:

1. support d'outillage excellent.
2. Technologie la plus répandue.
3. La norme JAX-WS est très mature.
4. Facilité de développement. (Support d'annotation pour convertir un POJO en webservice).
5. Exemple METRO, Axis ...

inconvénients de SOAP. (Demander à Roy Fielding ..)

1. Bloated Protocole.
2. La personnalisation du protocole est possible mais compliquée. (utilisant la liaison wsdl, etc.)
3. Le client a besoin d'une bibliothèque complexe pour sérialiser et désérialiser les messages de savon.
4. Les plateformes comme Android ne supportent pas nativement SOAP.

Après diatribe Roy Fielding sur les protocoles de services Web pléthorique webservices et il mettant en avant l'argument de bon sens pour utiliser l'os arrière internet pour SOA, il y avait un mouvement progressif vers REST. Des entreprises plus agiles comme Google et Amazon ont adopté REST et défendent la cause des services Web basés sur REST.

Pour de REST:

1. protocole très léger.
2. Principalement Basé sur HTTP et donc la plupart des clients savent comment consommer. (mais REST ne doit pas être HTTP).
3. La gestion des erreurs et des idées comme Cache sont basées sur des technologies Internet éprouvées.
4. Java possède d'excellentes bibliothèques REST. Le propre Jersey de Sun est une excellente implémentation de référence Jax-RS et il y a Restlet, Jboss Rest Framework et Spring REST (bien que non conforme à JAX-RS).

Moins de repos:

1. support d'outillage relativement mauvais.
2. Sécurité L'implémentation dans REST est légèrement difficile.
3. La conception orientée ressources et la mise en œuvre pourraient être nouvelles pour certains programmeurs et architectes traditionnels.

Ma préférence est REST avec Jersey. C'est un cadre étonnant, un excellent support, une excellente documentation, de bonnes bibliothèques de support pour les tests.

Dans les deux cas, je vais télécharger l'EDI NetBeans et l'utiliser pour développer le code skeletol pour un service Web basé sur REST ou SOAP. Netbeans le rend très facile à démarrer. Une fois que vous êtes à l'aise avec le code, vous pouvez basculer vers votre IDE préféré. (En passant, je n'utilise pas Netbeans pour autre chose que le prototypage, il essaie de faire beaucoup et fait mal la plupart d'entre eux .. mon opinion de toute façon)

Answer 4

Ma préférence est Apache Avro (mentionné dans la réponse de @ rodrigoap). Là où je travaille maintenant, nous avons une architecture orientée services et utilisons Avro pour les services internes. Nous l'avons choisi parce qu'il est rapide, stable, peut fonctionner sur http (facilement accessible depuis Tomcat), peut générer des classes client automatiquement et fonctionne avec plusieurs langues. La génération de classes client a été une grande fonctionnalité pour nous car cela signifie que nous ne traitons que des objets Java et que Avro gère la sérialisation et l'envoi de données à travers le réseau. C'est aussi bien de ne pas avoir à gérer beaucoup d'URL différentes. Un service Web Avro est hébergé à partir d'une seule servlet et Avro se charge de mapper chaque requête à la méthode appropriée dans votre classe d'implémentation. Pour faire référence à la réponse de @ rodrigoap, il a placé plusieurs autres options avant Avro dans sa liste, et pour les services web accessibles en externe, je suis d'accord que ce sont de meilleurs choix, car vos utilisateurs de services externes ne sont probablement pas Je ne suis pas intéressé à utiliser Avro simplement parce que vous l'avez peut-être choisi.

Dans le cas où vous êtes intéressé par un exemple, voici un projet sample Avro web service à explorer et à voir comment cela fonctionne.