In che modo le applicazioni desktop comunicavano con il server remoto prima dei servizi web?

A seconda di ciò che chiami un servizio web.

Prima di WSDL e REST, c'era ancora HTTP, quindi in pratica tutto ciò che puoi fare ora potrebbe essere fatto anche prima.

C'era una mancanza di uniformità (motivo per cui WSDL e REST sono stati creati in primo luogo), ma ha fornito lo stesso livello di riservatezza e sicurezza dei dati di cui si parla.

In realtà puoi evitare di usare anche HTTP: puoi creare il tuo protocollo personalizzato e utilizzare un server personalizzato e client personalizzati che aprirebbero un socket a questo server e otterranno i dati di cui hanno bisogno (o pubblicheranno i dati). Qui, si perde tutto il vantaggio di standardizzazione di HTTP, ma ancora una volta, non si concede l'accesso al database ai client.

Ah, quando avevamo bastoni e pietre.

Prima di Internet, avevamo qualcosa chiamato architettura "client / server" e reti locali. Se non stavi cercando di stabilire una connessione con un server a diverse miglia di distanza, queste reti funzionavano perfettamente per ottenere il massimo. Se lo si desidera, è persino possibile stabilire lettere di unità e utilizzare connessioni a file server come un disco rigido remoto. Se eri a diverse miglia di distanza, potresti utilizzare una Wide Area Network per fare essenzialmente la stessa cosa, anche se a una velocità inferiore e con costi maggiori.

Il modo economico per parlare in remoto era passare le informazioni attraverso le linee telefoniche usando i dispositivi chiamati modem, e se volevi installare qualcosa in cui due computer si scambiavano informazioni attraverso le applicazioni del computer, l'hai fatto nello stesso modo in cui lo fai oggi : per stabilire un protocollo di comunicazione. Non c'è nulla di magico in questo; entrambe le parti devono solo concordare su cosa significano tutti i byte.

Fin dalle primissime fasi di Internet, c'erano modi in cui le macchine potevano comunicare attraverso di essa. I servizi Web sono solo l'ultimo sapore della settimana.

Solo per chiarire alcuni concetti prima ...

I believe data access through a webservice provides security - I don't need to pass in the db server user name and password etc.

Penso che tu stia confondendo i concetti di (1) Transport Layer Security (TLS) e (2) controlli di accesso nella dichiarazione di cui sopra ... Se un nome utente e una password devono essere forniti o meno non è correlato a se un servizio web è fornito attraverso (1) un canale crittografato e (2) autenticazione (ad esempio una chiave API).

Un servizio web scritto in modo scadente potrebbe richiedere l'invio di password in formato testo su HTTP. Uno scritto male può farlo su HTTPS (sicuro, ma una volta rotto, ad esempio attraverso un man-in-the -middle attacco, aperto agli abusi). Un servizio web meglio scritto dovrebbe gestire la connettività del database internamente sulla base di altri input, ad es. ID di sessione, dopo che i controlli di autenticazione e autorizzazione sono stati convalidati.

Tornando al punto principale, il commento di @ marcus sulla tua domanda è essenzialmente esso. Gli aspetti di sicurezza non sono trattati in modo diverso dalle tecnologie "moderne" e copre domande di implementazione come:

• Se il tuo protocollo di comunicazione (prendendo in prestito un po 'dalla risposta di @ RobertHarvey) supporta la trasmissione di dati crittografati.
• La struttura payload del messaggio che viene inoltrata tra il server e il client.
  • Il client dice semplicemente al server di mantenere l'indirizzo residenziale di questo utente, o di connettersi a un database con IP X.X.X.X con un nome utente e una password, e quindi esegui la query INSERT INTO user_address ... ?
• In che modo il server gestisce la connettività del database (che è realmente isolata dal client, vedere il primo paragrafo).

Per ulteriori informazioni:

• Scheda Cheat Security Security (da OWASP)
• Architettura di Common Request Request Broker
• Chiamata di procedura remota