Comment les applications de bureau communiquaient-elles avec le serveur distant avant les services Web?

11

Je n'ai pas beaucoup d'expérience avec les applications de bureau, mais si je devais créer une application de bureau client-serveur, l'accès aux données se ferait via un service Web. Je crois que l'accès aux données via un service Web offre une sécurité - je n'ai pas besoin de transmettre le nom d'utilisateur et le mot de passe du serveur db, etc.

Avant les services Web, comment les applications de base de données procédaient-elles? Toutes les informations importantes sur la base de données ont-elles été transmises à l'installation de l'application de bureau? Si oui, comment les programmeurs ont-ils géré l'aspect sécurité? Ou les programmeurs ont-ils utilisé quelque chose de similaire aux services Web?

programming-practices security

— Hurle Hagrid
source

5

Il y avait des choses amusantes pour les appels de procédure à distance, tels que DCOM (COM distribué), CORBA, Java RMI ... Je n'ai jamais complètement compris aucun d'entre eux, tout en demandant des données via HTTP était instantanément logique. Je suppose que l' aide de navigateurs web tous les jours fait webservices plus facile à grok :-)

— marcus

3

@marcus: probablement parce que HTTP contient une requête-réponse, alors que "certains protocoles sur un socket" font que tout le monde invente cette roue d'une forme légèrement différente.

— Steve Jessop

11

Selon ce que vous appelez un service Web.

Avant WSDL et REST, il y avait encore HTTP, donc fondamentalement tout ce que vous pouvez faire maintenant pouvait également être fait auparavant.

Il y avait un manque d'uniformité (c'est pourquoi WSDL et REST ont été créés en premier lieu), mais cela a fourni le même niveau de confidentialité et de sécurité des données que vous parlez.

Vous pouvez également éviter d'utiliser HTTP: vous pouvez rédiger votre propre protocole et utiliser un serveur personnalisé et des clients personnalisés qui ouvriraient un socket sur ce serveur et obtiendraient les données dont ils ont besoin (ou publier les données). Ici, vous perdez tous les avantages de la normalisation de HTTP, mais encore une fois, vous ne donnez pas accès à la base de données aux clients.

— Arseni Mourzenko
source

17

Ah, à l'époque où nous avions des bâtons et des pierres.

Avant Internet, nous avions quelque chose appelé architecture "client / serveur" et réseaux locaux. Si vous n'essayiez pas d'établir une connexion avec un serveur situé à plusieurs kilomètres, ces réseaux fonctionnaient parfaitement pour accomplir presque tout. Vous pouvez même établir des lettres de lecteur et utiliser des connexions à des serveurs de fichiers comme un disque dur distant, si vous le souhaitez. Si vous étiez à plusieurs kilomètres de distance, vous pourriez utiliser un réseau étendu pour faire essentiellement la même chose, mais à une vitesse plus lente et à un coût plus élevé.

La façon la moins chère de parler à distance était de transmettre des informations sur les lignes téléphoniques à l'aide de dispositifs appelés modems, et si vous vouliez configurer quelque chose où deux ordinateurs se parlaient via des applications informatiques, vous l'avez fait de la même manière qu'aujourd'hui: en établissant un protocole de communication. Il n'y a rien de magique à cela; les deux parties doivent juste se mettre d'accord sur la signification de tous les octets.

Dès les tout premiers stades d'Internet, les machines pouvaient communiquer entre elles. Les services Web ne sont que la dernière version de la semaine.

— Robert Harvey
source

5

« Il y a du tout à ce sujet magique de rien, les deux parties ont tout simplement se mettre d' accord sur ce que tous les octets moyenne. » Et boutisme :)

— HJK

2

@hjk, c'est facile: little-endian est évidemment supérieur à toutes les autres options :-)

— Mark

3

J'irais même jusqu'à dire que la définition d'Internet exige qu'il existe des moyens pour les machines de communiquer à travers lui. S'ils ne peuvent pas faire ça, ce n'est pas Internet, c'est un tas de câbles avec des illusions de grandeur.

— Steve Jessop

2

@SteveJessop: Vous vous trompez, " c'est une série de tubes ".

— Déduplicateur

3

Juste pour clarifier certains concepts d'abord ...

Je crois que l'accès aux données via un service Web offre une sécurité - je n'ai pas besoin de transmettre le nom d'utilisateur et le mot de passe du serveur db, etc.

Je pense que vous confondez les concepts de (1) TLS (Transport Layer Security) et (2) des contrôles d'accès dans la déclaration ci-dessus ... fourni par (1) un canal crypté et (2) l'authentification (par exemple une clé API).

Un service Web extrêmement mal écrit peut encore nécessiter l'envoi de mots de passe en texte clair via HTTP. Un document mal écrit peut le faire via HTTPS (sécurisé, mais une fois rompu, par exemple par une attaque de l' homme du milieu , ouvert aux abus). Un service Web mieux écrit devrait gérer la connectivité de la base de données en interne sur la base d'autres entrées, par exemple les identifiants de session, après la validation des contrôles d'authentification et d'autorisation.

Revenons au point principal, le commentaire de @ marcus sur votre question est essentiellement le cas. Les aspects de sécurité ne sont pas traités différemment des technologies "modernes" et couvrent des questions de mise en œuvre telles que:

Si votre protocole de communication (empruntant un peu à la réponse de @ RobertHarvey) prend en charge la transmission de données cryptées.
La structure de la charge utile du message qui est relayée entre le serveur et le client.
- Le client indique-t-il simplement au serveur de conserver l'adresse résidentielle de cet utilisateur ou de se connecter à une base de données sur IP X.X.X.Xavec un nom d'utilisateur et un mot de passe, puis d' exécuter la requêteINSERT INTO user_address ... ?
Comment le serveur gère sa connectivité à la base de données (qui est vraiment isolée du client, voir le premier paragraphe).

Pour plus d'informations:

— hjk
source