Web-Service vs Client-Serveur Distribué Technologie de l'Informatique

En disant d'abord que je suis un newbie dans les technologies de Services Web, et je suis seulement au début de l'étude, je n'étais pas en mesure de comprendre de façon précise pourquoi devrais-je mettre en œuvre un Service Web plutôt qu'un protocole Client/Serveur.

1 - quelqu'un Peut-il m'aider à comprendre?

J'ai trouvé sur le web quelques indications mais voulez-vous de les confirmer ou de les prolonger, afin de m'aider à mettre toutes les pièces ensemble.

2 - la déclaration suivante correcte et pouvez-vous m'expliquer à moi?

1.

A guideline that I was told: 
If you plan on reaching out to multiple clients (Linux, Windows, etc.), 
then use Web Services; otherwise, use Client /Server.

2.

If your application needs to be run on machines that would access the data 
over a public network (internet) then you should go with web services because 
the traditional client/server model is not acceptable due to not wanting 
to expose your server publicly.
The web services you would expose publicly could be secure (HTTPS),
require some kind of authentication and only expose what you WANT to expose, 
versus exposing a whole database

3.

One of the better reasons to use remoting is that it gives a large increase in
performance. But one of the down falls is that it is a good bit more complicated
to program than Web Services.

4.

The proper use of web services is really based on your "remote connectivity"
needs. If your application is going to be run in a controlled environment such as
a LAN/WAN where you can see the server thru a private or secure (VPN) network,
then you can build a traditional client/server application

5.

Web Services:

Though there are no major differences in the output of service with both these
models, the mobility and accessibility is definitely an advantage. 
However, the lack of a great deal of personalization does come as a con against 
the web-server based model.

Client Server:

The added security of client server is definitely a one up and it also gives the 
option of controlling the updates and upgrades if any. 
Initially though, client servers may come with a higher front-end cost.

Des déclarations ont été extraites à partir des liens suivants:

ajout de liens vers des sources

OriginalL'auteur Matteo | 2012-04-14

  1. 8

    Peu de temps a passé, et après avoir étudié de nombreux tutoriels sur l'argument que je peux enfin répondre à ma propre question:

    1. Pourquoi devrais-je mettre en œuvre un Service Web plutôt qu'un protocole Client/Serveur

    Réalité des Services Web est encore un autre technologie de calcul distribué (comme CORBA, RMI, EJB,...). Ils nous permettent de nous exactement pour créer des applications client/serveur, et ne sont donc pas de substitution.

    Des programmes Clients qui veulent accéder au Service Web) contactez le Service Web (le Serveur), et envoyer une demande de service en demandant de l'information. Le Serveur renvoie l'information voulue, par le biais d'un service de réponse.

    De sûr, c'est un très sommaire exemple de la façon dont un Service Web fonctionne, mais vous pouvez voir que c'est exactement le même concept de la façon normale protocole Client/Serveur fonctionne.

    Donc, ce qui rend des Services Web spécial?

    Bien, les Services Web ont certains avantages par rapport à d'autres technologies:

    • Des Services Web est indépendant de la plateforme et indépendant de la langue, car ils utilisent la norme
      Langages XML. Cela signifie que mon programme client peut être programmé en C++ et
      fonctionnant sous Windows, tandis que le Service Web est programmé en Java et en cours d'exécution en vertu de l'
      Linux.

    • La plupart des Services Web utilisent le protocole HTTP pour la transmission de messages (tels que la demande de service et
      la réponse). Ceci est un avantage important si vous voulez construire une échelle d'Internet de l'application, puisque la plupart de l'Internet les procurations et les pare-feu ne plaisante pas avec le trafic HTTP (contrairement à CORBA, qui a habituellement de la difficulté avec les pare-feu).

    Bien sûr, les Services Web ont aussi quelques inconvénients:

    • Frais généraux. La transmission de l'ensemble de vos données en XML n'est évidemment pas aussi efficace que l'utilisation d'un
      propriétaires code binaire. Ce que vous gagnez à la portabilité, vous perdez en efficacité. Même ainsi, ce
      la surcharge est généralement acceptable pour la plupart des applications, mais vous aurez probablement jamais à en trouver un
      critiques en temps réel de l'application qui utilise les Services Web.

    • Manque de polyvalence. Actuellement, les Services Web ne sont pas très polyvalent, car ils permettent seulement de quelques formes de base de l'invocation des services. CORBA, par exemple, propose des programmeurs beaucoup de services de soutien (tels que la persistance, les notifications, gestion du cycle de vie, transactions, etc.). Heureusement, il y a beaucoup de pays émergents les spécifications de services Web (y compris WSRF) qui aident à la création de services Web plus et plus polyvalent.

    Cependant, il est important de caractéristiques qui la distingue des Web Services. Alors que les technologies telles que CORBA et les EJB sont orientées vers les très couplé systèmes distribués, où le client et le serveur sont très dépendants les uns des autres, les Services Web sont plus appropriées pour les systèmes faiblement couplés, où le client peut avoir aucune connaissance préalable du Service du site Web jusqu'à ce qu'il l'invoque. Très couplé systèmes sont idéales pour les applications intranet, mais les résultats sont médiocres sur Internet à l'échelle. Des Services Web, cependant, sont mieux adaptés pour répondre aux exigences d'une large application.

    2. Sont les suivantes déclaration correcte et pouvez-vous m'expliquer à moi?

    1) Si vous prévoyez sur plusieurs clients (Linux, Windows,
    etc.), ensuite, utiliser des Services Web; sinon, utiliser le Client /Serveur.

    VRAI

    Comme indiqué ci-dessus:

    Des Services Web est indépendant de la plateforme et indépendant de la langue, car ils utilisent la norme XML langues. Cela signifie que mon programme client peut être programmé en C++ et en cours d'exécution sous Windows, tandis que le Service Web est programmé en Java et fonctionnant sous Linux.

    Si, au contraire, architecture distribuée de système est connu et homogène sur tous les nœuds, vous pouvez écrire plus simple et plus couplé à des applications client/serveur dans un langage de programmation.

    2) Si votre application doit être exécuté sur des machines qui aurait accès aux données sur un public
    réseau (internet), alors vous devriez aller avec web
    services parce que le traditionnel modèle client/serveur n'est pas
    acceptable en raison de ne pas vouloir exposer votre serveur public. Le web
    services de vous exposer publiquement pourrait être sécurisés (HTTPS), exiger
    une sorte d'authentification et d'exposer uniquement ce que vous SOUHAITEZ exposer,
    rapport d'exposer l'ensemble de la base de données

    VRAI

    Avec les Services Web de ce que la seule chose que vous exposer publiquement vers le monde extérieur est un Serveur Web standard (à laquelle les clients peuvent envoyer des requêtes HTTP). Toutes les précieuses données et les méthodes sont plutôt protégés au pas accessible.

    Si, au lieu de vous fournir un point d'accès à votre serveur de processus (par exemple, adresse IP et numéro de port du service) directement à l'internet, ce serait faire de vos données et de méthodes accessibles par n'importe quel processus.

    3) l'Une des meilleures raisons d'utiliser l'accès distant est qu'il donne une grande
    augmentation de la performance. Mais l'une des chutes, c'est que c'est un
    de bons peu plus compliqué à programmer que des Services Web.

    VRAI

    Remoting permet de construire plus polyvalent des services, et d'éviter le passage de beaucoup de données XML, donc plus performant.

    4) La bonne utilisation des services web est vraiment basé sur votre "à distance
    la connectivité". Si votre application doit être exécuté dans un
    environnement contrôlé comme un LAN/WAN, où vous pouvez voir le serveur
    grâce à un privé ou sécurisé (VPN) réseau, vous pouvez ensuite créer un
    application client/serveur classiques

    VRAI

    Citant à nouveau la première partie de la réponse:

    Services Web sont plus appropriées pour les systèmes faiblement couplés, où le client peut avoir aucune connaissance préalable du Service du site Web jusqu'à ce qu'il l'invoque. Très couplé systèmes sont idéales pour les applications intranet, mais les résultats sont médiocres sur Internet à l'échelle. Des Services Web, cependant, sont mieux adaptés pour répondre aux exigences d'une large application.

    5) Services Web:

    Si il n'y a pas de grandes différences dans la sortie de service avec
    ces deux modèles, la mobilité et l'accessibilité des Services Web est certainement un
    avantage par rapport à la norme C/S de paradigme. Toutefois, l'absence d'une grande partie de
    la personnalisation ne viennent comme un con contre le web-serveur basée sur un modèle.

    Client-Serveur:

    Le plus de sécurité de serveur de client est certainement l'une et elle aussi
    donne la possibilité de contrôler les mises à jour et mises à niveau le cas échéant.
    Au départ cependant, les serveurs clients peuvent venir avec un supérieur avant la fin de l'
    coût.

    VRAI

    La première partie de cette déclaration se réfère au fait que les Services Web sont de plus plate-forme et indépendante de la langue, et donc plus accessible, mais comme indiqué plus fois moins polyvalent.

    La deuxième partie des remarques sur le fait qu'avec plus de polyvalence, vous pouvez plus facilement de contrôle et de masquer les mises à jour et mises à niveau.

    Par exemple, si les responsables du service Web de décider de changer d'interface du service et, ainsi, sa description WSDL, le client doit passer par la phase de découverte de nouveau. Ce ne serait pas le cas si vous utilisez un standard C/S protocole.

    OriginalL'auteur Matteo

  2. 1

    webservices sont client/serveur "apps".

    avec votre navigateur , lorsque vous vous connectez à un site web , le serveur sorties html ou autre chose lisible par votre navigateur. html peut être généré à partir d'une application comme php ou .net. Vous navigateur est un client.

    une application web(php /java /etc... ) lui-même peut être un client d'une autre webapplication. Imaginez que votre app besoin pour afficher , rapports météorologiques , pour le servir d'un navigateur.

    de votre application sur le serveur de se connecter à une autre application par le biais d'un protocole ( rest /soap /xml-rpc /etc ... ) pour pousser ou tirer des données à partir d'un serveur d'application , le serveur d'application peut être n'importe quoi, php, java , dotnet , votre application cliente ne s'inquiète pas, car ils parlent à travers un protocole défini.

    donc un webservice permet à un client et un serveur à parler ensemble.

    et il n'y a pas de webservice vs client serveur , parce que les services web sont tout au sujet de la communication client/serveur.

    edit : je ne sais pas vraiment ce que votre texte cité en parle ... s'il vous plaît donner la source de ce texte.

    merci pour l'explication claire, je ne peux pas comprendre ce que tu veux dire avec a web application(php / java /etc... ) itself can be a client of another webapplication. Je pense que mon problème est que je continue à penser en C/S de la mode, pourquoi mon appli servir les bulletins météorologiques pour le navigateur client d'une autre application? Concernant les citations, elles sont des extraits que j'ai eu plus de nombreux liens et je me demandais si ils avaient le sens et si quelqu'un était en mesure d'expliquer au mieux.
    ce que la technologie de serveur le savez-vous ?
    ce langage, je veux dire
    J'ai toujours utilisé le Linux + APACHE + MySql + php plates-formes pour mon développement
    votre application php peut faire des requêtes http , comme un navigateur , mais ne peut pas afficher le code html , mais peut rendre les utilisations de données json. par exemple, vous pouvez utiliser l'api twitter en php pour obtenir les tweets de twitter ,à l'intérieur de php, puis de les afficher les tweets en html , twitter serait le serveur et votre script php le client.

    OriginalL'auteur mpm