Quel devrait être le rôle des services Web dans un site Web?

Question

Je construis un site Web qui comprend un contrôle qui utilisera beaucoup de données. J'ai donc pensé à le faire via le web-service, afin d'améliorer la scalabalité - de cette façon, je serai capable d'utiliser un serveur différent à cette fin.
Est-ce une bonne idée? Si oui, où s'arrête-t-il? Pourquoi ne pas avoir des web-services tout autour, et un site web très "mince"? Quels sont les avantages et contre. de ça?
Est-ce que je ne comprends pas le but des services Web?

Answer 1

Ma compréhension est que le but principal des services Web est leur capacité à être en mesure d'exposer les fonctionnalités des applications à applications externes de manière à couplage lâche. Afin d'améliorer l'évolutivité, ce qui est généralement important, c'est l'approche en couches de votre application, dans laquelle vos couches peuvent être mises à l'échelle indépendamment selon les besoins. Maintenant, oui, il est très possible que du point de vue de la mise en œuvre, vous puissiez implémenter cette couche en tant que service Web, mais ce n'est pas vraiment l'option performante.

Si l'intégration externe n'est pas une exigence, il est généralement préférable d'utiliser des moyens de communication plus rapides entre les couches telles que les canaux TCP/nommés. Si vous êtes sur la plate-forme .NET et que vous utilisez WCF pour créer vos services, TCP/MSMQ/Named Pipes sont des options considérées comme plus performantes que les services Web classiques (HTTP). Dans les versions précédentes de .NET, il était courant d'utiliser .NET remoting pour communiquer entre les couches et cela aussi était beaucoup plus performant que les services Web. En ce qui concerne les services Web, il y a un coût qui leur est associé et c'est ce qui fait que vous ne les voulez pas, sauf dans les endroits où vous en tirerez vraiment profit. Dans la plupart des cas, l'exposition de la logique métier à des applications externes via une couche Service au-dessus de votre couche de gestion est généralement l'un des lieux les plus courants pour les services.

Answer 2

Rich Internet/Intranet Les applications, s'exécutant dans le navigateur, avec de beaux widgets de présentation sont assez courantes aujourd'hui. La plupart des entreprises sérieuses avec lesquelles je traite veulent au moins un certain degré de RIA dans leur présence sur le Web. Par conséquent, AJAX, Flash, etc. sont très largement utilisés.

De telles applications ont besoin d'obtenir les données qu'elles affichent quelque part et généralement c'est un appel de service de fond (asynchrone étant un terme souvent utilisé). Il s'agit souvent d'un appel de service REST, mais il peut également s'agir d'un appel de service WSDL traditionnel.

Je dirais:

1. La séparation logique de la logique de présentation et la logique métier est une bonne chose.
2. Dans le cas de RIA, il est parfaitement naturel de séparer la logique métier d'un niveau différent de la présentation, lorsque celle-ci se trouve dans le navigateur.
3. L'argument d'évolutivité que vous faites est alors un avantage limité de cette architecture. Dans le monde de Java EE, les serveurs d'applications effectuent ce type de mise à l'échelle de manière tout à fait naturelle.
4. Dans les cas où le login de présentation s'exécute dans le même niveau que la logique métier, vous pouvez constater que les coûts de sérialisation des services Web sont remarquables et que vous préférerez peut-être utiliser des appels de procédure simples.