Como os aplicativos de área de trabalho se comunicam com o servidor remoto antes dos serviços da web?

11

Não tenho muita experiência com aplicativos de desktop, mas se eu tivesse que criar um aplicativo de desktop do servidor cliente, o acesso aos dados seria feito por meio de um serviço da web. Acredito que o acesso a dados através de um serviço da web fornece segurança - não preciso passar o nome de usuário e a senha do servidor db, etc.

Antes dos serviços da web, como os aplicativos de banco de dados faziam isso? Todas as informações importantes do banco de dados foram passadas para a instalação do aplicativo de desktop? Em caso afirmativo, como os programadores gerenciavam o aspecto de segurança? Ou os programadores usaram algo semelhante aos serviços da web?

programming-practices security

— Uivos Hagrid
fonte

5

Havia coisas engraçadas para chamadas de procedimento remoto, como DCOM (Distributed COM), CORBA, Java RMI ... Eu nunca entendi completamente nenhuma delas, enquanto solicitava alguns dados via HTTP fazia sentido instantaneamente. Eu acho que usando navegadores web todos os dias fez webservices mais fácil Grokar :-)

— marcus

3

@marcus: provavelmente porque o HTTP possui resposta de solicitação incorporada, enquanto "algum protocolo em um soquete" resulta em todo mundo que inventa essa roda com uma forma ligeiramente diferente.

— 21715 Steve Jobs (

11

Dependendo do que você chama de serviço da web.

Antes do WSDL e do REST, ainda havia HTTP, então basicamente tudo o que você pode fazer agora também pode ser feito antes.

Havia uma falta de uniformidade (razão pela qual o WSDL e o REST foram criados em primeiro lugar), mas forneceu o mesmo nível de confidencialidade e segurança dos dados dos quais você está falando.

Na verdade, você também pode evitar o uso do HTTP: você pode redigir seu próprio protocolo e usar um servidor personalizado e clientes personalizados que abririam um soquete para esse servidor e obteriam os dados necessários (ou publicariam os dados). Aqui, você perde todo o benefício de padronização do HTTP, mas, mais uma vez, não dá acesso ao banco de dados aos clientes.

— Arseni Mourzenko
fonte

17

Ah, quando tínhamos paus e pedras.

Antes da Internet, tínhamos algo chamado arquitetura "cliente / servidor" e redes locais. Se você não estava tentando estabelecer uma conexão com um servidor a vários quilômetros de distância, essas redes funcionavam perfeitamente bem para realizar quase tudo. Você pode até estabelecer letras de unidade e usar conexões com servidores de arquivos como um disco rígido remoto, se quiser. Se você estivesse a vários quilômetros de distância, poderia usar uma rede de área ampla para fazer essencialmente a mesma coisa, embora a uma velocidade mais lenta e a um custo maior.

A maneira mais barata de conversar remotamente era passar informações pelas linhas telefônicas usando dispositivos chamados modems, e se você quisesse criar algo em que dois computadores conversassem entre si por meio de aplicativos, você faria da mesma maneira que faz hoje: estabelecendo um protocolo de comunicação. Não há nada de mágico nisso; ambos os lados precisam concordar com o significado de todos os bytes.

Desde os estágios iniciais da Internet, havia maneiras de as máquinas se comunicarem através dela. Serviços da Web são apenas o sabor mais recente da semana.

— Robert Harvey
fonte

5

"Não há nada mágico em tudo sobre isso, ambos os lados só tem que concordar com o que todos os bytes média." E endianness :)

— HJK

2

@hjk, isso é fácil: little-endian é evidentemente superior a todas as outras opções :-)

— Mark

3

Eu chegaria ao ponto de dizer que a definição de internet exige que haja maneiras de as máquinas se comunicarem através dela. Se eles não podem fazer isso, não é a Internet, é um monte de cabos com ilusões de grandeza.

— 21715 Steve Jobs (

2

@ SteveJessop: Você está errado, " é uma série de tubos ".

— Deduplicator

3

Apenas para esclarecer alguns conceitos primeiro ...

Acredito que o acesso a dados através de um serviço da web fornece segurança - não preciso passar o nome de usuário e a senha do servidor db, etc.

Acho que você está confundindo os conceitos de (1) Transport Layer Security (TLS) e (2) controles de acesso na declaração acima ... Se um nome de usuário e senha precisam ser fornecidos ou não, isso não tem relação com o fato de um serviço da Web ser fornecida através de (1) um canal criptografado e (2) autenticação (por exemplo, uma chave API).

Um serviço da Web extremamente mal escrito ainda pode exigir que as senhas sejam enviadas em texto sem formatação por HTTP. Uma pessoa mal escrita pode fazer isso por HTTPS (seguro, mas uma vez quebrado, por exemplo, através de um ataque do tipo intermediário , aberto a abusos). Um serviço da Web melhor escrito deve lidar com a conectividade do banco de dados internamente com base em outras entradas, por exemplo, IDs de sessão, após a validação dos controles de autenticação e direito.

De volta ao ponto principal, o comentário de @ marcus sobre sua pergunta é basicamente isso. Os aspectos de segurança não são tratados de maneira diferente das tecnologias "modernas" e cobrem questões de implementação, como:

Se o seu protocolo de comunicação (emprestando um pouco da resposta do @ RobertHarvey) suporta a transmissão de dados criptografados.
A estrutura de carga útil da mensagem que é retransmitida entre o servidor e o cliente.
- O cliente simplesmente instrui o servidor a persistir no endereço residencial desse usuário ou a se conectar a um banco de dados no IP X.X.X.Xcom um nome de usuário e senha e depois executar a consultaINSERT INTO user_address ... ?
Como o servidor gerencia sua conectividade com o banco de dados (que realmente é isolado do cliente, consulte o primeiro parágrafo).

Para maiores informações:

— hjk
fonte