Quelle est la différence entre un service Web descendant et un service Web ascendant?

Top-down signifie que vous commencez avec un WSDL et que vous créez ensuite tout l’échafaudage nécessaire en Java.

La méthode ascendante signifie que vous commencez avec une méthode Java et générez le fichier WSDL à partir de celui-ci.

SOAP signifie que l’URL est la même pour tous les appels, et que seuls les parameters de la méthode Java sont différents. REST signifie que l’URL et la méthode HTTP invoquée reflètent l’opération à effectuer.

Contract-first versus Contract-last

Bottom-Up: l’ approche prend une définition de haut niveau du problème et la subdivise en sous-problèmes.

ie contrat-dernier . Il y a les avantages suivants pour préférer un style de développement Bottom-Up.

• Code en premier
• Étape initiale très facile à développer.

Désavantages:

• La maintenance est très difficile.
• Couplage étroit

Top-Down: Pensez aux fonctionnalités de base et aux composants nécessaires.

ie contrat-premier . Il y a les raisons suivantes pour préférer un style de développement Top-Down.

1. Fragilité Le dernier style de développement du contrat entraîne la génération de votre contrat de service Web (WSDL et votre XSD) à partir de votre contrat Java (généralement une interface). Si vous utilisez cette approche, vous n’aurez aucune garantie que le contrat rest constant dans le temps. Chaque fois que vous modifiez votre code Java et que vous le redéployez, le contrat de service Web peut être modifié ultérieurement. En outre, toutes les stacks SOAP ne génèrent pas le même contrat de service Web à partir d’un contrat Java. Cela signifie que la modification de votre stack SOAP actuelle pour une autre (pour quelque raison que ce soit) peut également modifier votre contrat de service Web. Lorsqu’un contrat de service Web change, les utilisateurs du contrat doivent être invités à obtenir le nouveau contrat et à modifier éventuellement leur code pour tenir compte de toute modification du contrat. Pour qu’un contrat soit utile, il doit restr constant le plus longtemps possible. Si un contrat change, vous devrez contacter tous les utilisateurs de votre service et leur demander d’obtenir la nouvelle version du contrat.

2. Performances Lorsque Java est automatiquement transformé en XML, il est impossible de savoir avec certitude ce qui est envoyé sur le réseau. Un object peut référencer un autre object, qui fait référence à un autre, etc. Au final, la moitié des objects du tas de votre machine virtuelle peut être convertie en XML, ce qui ralentit les temps de réponse. Lorsque vous utilisez contract-first, vous décrivez explicitement où XML est envoyé pour vous assurer que c’est exactement ce que vous voulez.

3. Réutilisation La définition de votre schéma dans un fichier distinct vous permet de réutiliser ce fichier dans différents scénarios.

4. Versioning Même si un contrat doit restr constant aussi longtemps que possible, il faut parfois le modifier. En Java, cela se traduit généralement par une nouvelle interface Java, telle que AirlineService2, et une (nouvelle) implémentation de cette interface. Bien entendu, l’ancien service doit être conservé, car certains clients n’ont pas encore migré. Si vous utilisez le contrat d’abord, nous pouvons avoir un couplage plus souple entre le contrat et la mise en œuvre. Un tel couplage plus souple nous permet d’implémenter les deux versions du contrat dans une classe.

Hiérarchie descendante vs ascendante

crédit d’image: google images

@mad_programmer – Vous voulez dire créer des services Web avec une approche ascendante ou descendante. Dans le premier cas, vous commencez à programmer les classes et la logique métier en tant que code Java, puis vous générez le contrat de service Web (WSDL) à partir de celui-ci. Cette dernière approche signifie le contraire (générer des stubs de classes à partir du WSDL).

Soutenant la réponse de andersen, je voudrais append un point. Fondamentalement, les gens ont tendance à utiliser l’approche Bottom-up, car dans la plupart des cas, nous aurions déjà commencé le processus d’écriture des beans, de la logique métier, puis dans la couche persistence, nous créons les web-services, comme dans un nouveau projet, où vous construisez quelque chose à partir de rien, nous pouvons utiliser une approche descendante, où nous écrivons simplement le wsdl et construire le squelette vous donnerait les beans, les implémentations, les interfaces, etc. la logique que vous voulez. Il vous faut donc passer par tout le projet et combler les lacunes.

Lorsque vous lancez un projet à partir de rien, l’approche habituelle consiste à créer une interface très simple, puis à en créer un. Cela vous évitera d’écrire des WSDl complexes. Ensuite, nous pouvons append des opérations spécifiques au projet dans WSDl directement et une fois que WSDl est finalisé, nous pouvons continuer avec une approche descendante.

En haut, vous définissez ce que vous allez faire en premier. c’est à dire votre wsdl. Et puis vous procédez au développement réel. Bien qu’il semble difficile de créer wsdl en premier, il est recommandé (reportez-vous à Eclipse) car, à long terme, cela simplifie votre développement.

Exactement opposé se passe en bas vers le haut. Nous commençons avec la partie code puis utilisons les outils intégrés que nous créons wsdl. Cela peut sembler facile au début mais cela crée beaucoup de confusion lorsque vous êtes gros avec la complexité de votre code.