Quand un service Web ne devrait-il pas être utilisé?

Question

À l'aide d'un service web est souvent une excellente approche architecturale. Et, avec l'avènement de la WCF dans .Net, c'est encore mieux.

Mais, dans mon expérience, certaines personnes semblent penser que les services web doivent toujours être utilisés dans la couche d'accès aux données pour les appels à la base de données. Je ne pense pas que les services web sont la solution universelle.

Je pense de plus petites applications intranet avec quelques dizaines d'utilisateurs. L'application web et son service web sont déployés sur un serveur web, et non pas une batterie de serveurs web. Il ne va pas être une autre application web dans l'avenir qui peut utiliser ce service web. Il me semble que le coût de l'appel du service web augmente inutilement le fardeau sur le serveur web. Il y a un gain de performance de l'inter-traiter les appels. Le maintien et le débogage du code de l'application web et le web service est plus compliqué. Donc, est de déploiement. Je ne vois pas les avantages de l'utilisation d'un service web ici.

On a pu tester ce par la création de deux versions de l'application web, avec et sans le service web, et faire les tests de stress, mais je ne l'ai pas fait.

Avez-vous une opinion sur l'utilisation de web services pour les petites web app? Toutes autres occasions lorsque les services web ne sont pas un bon choix architectural?

Answer 1

Les Services Web sont absolument horrible choix pour l'accès aux données. C'est une tonne de surcharge et de la complexité de presque zéro en bénéficier.

Si votre application va s'exécuter sur une machine, pourquoi le nier la capacité à faire des données en cours de processus d'appels d'accès? Je ne parle pas d'accéder directement à la base de données à partir de votre code de l'INTERFACE utilisateur, je parle de l'abstraction de vos dépôts loin, mais encore, y compris leurs assemblées dans votre site web.

Il y a des cas où je recommanderais les services web (et je suppose que tu veux dire SAVON) mais c'est surtout pour l'interopérabilité.

La granularité des services est également en question ici. Un service dans la SOA sens va encapsuler une opération ou d'un processus métier. Méthodes d'accès aux données ne sont qu'une partie de ce processus.

En d'autres termes:

  - someService.SaveOrder(order);  // <-- bad
    // some other code for shipping, charging, emailing, etc

  - someService.FulfillOrder(order);  //<-- better
    //the service encapsulates the entire process

Des services Web pour l'amour de services web est irresponsable de la programmation.

Answer 2

Nick Harrison, un développeur brillant à Charlotte, a suggéré ces scénarios où l'utilisation d'un service web est logique:

• Sur une ferme Web, où il ya plusieurs serveurs Web hébergeant site Web (s), tous pointant vers le service web (s) en cours d'exécution sur un autre serveur Web. Cela permet de distribuer la charge sur plusieurs serveurs.
• Client/serveur, où les applications de formulaires Windows peuvent appeler un service Web.
• Plateforme transversale
• Passer à travers un pare-feu

Answer 3

Tout simplement parce que l'outil génère un tas de talons de ne pas dire que c'est une bonne utilisation. WS-* excelle dans les scénarios où vous exposer des services à des parties externes. Cela signifie que chaque opération doit être sur la granularité des processus d'affaires, par opposition à l'accès aux données.

La multitude de normes peuvent être utilisés pour décrire les différentes facettes de votre contrat dans les moindres détails et une (hypothétique) entièrement compatible WS pile peut emporter beaucoup de douleur à partir de la troisième partie des développeurs, et même de permettre le fameux point et cliquez sur l'intégration d'un menu à la Yahoo Pipes. Avec de la bonne gouvernance de contrôles que vous pouvez faire évoluer votre interface publique et de gérer la compatibilité descendante en tant que de besoin.

Tout cela est presque impossible d'être généré automatiquement. Le C# stub generator ne connaît que l'interface physique de votre classe, mais qui n'ont pas la moindre idée sur la sémantique impliqués. Consultez ce document pour plus de détails.

Si vous êtes à la construction d'un site web, puis construire un site web. Si vous voulez de messagerie asynchrone à l'intérieur de votre application, utilisez MSMQ. Si vous souhaitez exposer des données à des clients internes, l'utilisation de la SHARKA. Si vous avez besoin d'binaire efficace format de message, vérifiez Google Tampons de Protocole, ou si vous avez besoin d'RPC vérifier Hesse pour C# ou DCOM.

Les services Web sont un grain grossier de la solution d'intégration. Ils sont rigides, ils sont plus lents que les autres, ils prennent trop d'effort pour bien faire (et lorsqu'il n'est pas bien fait sont à côté des inutiles).

Pour résumer: "Quand un service web pas être utilisé?" - à tout moment, vous pouvez sortir sans elle

Answer 4

Si vous ne faites que codifier une application web minuscule (moins de 50 utilisateurs) pour votre intranet, un service web semble exagéré. Surtout si sa fonction principale (fournir un point unique d'accès à de nombreux services) ne sera pas utilisée.

Answer 5

Je conviens que l'utilisation d'un service Web dans une application Web à petite échelle ajoute une couche de complexité qui ne semble pas justifiée. La plupart de mes solutions, Internet et intranet, 10 à 50 utilisateurs, n'utilisent pas de services Web. Je suis content que les autres ressentent la même chose ... Je pensais que j'étais le seul.