¿Cómo se comunicaron las aplicaciones de escritorio con el servidor remoto antes de los servicios web?

11

No tengo mucha experiencia con las aplicaciones de escritorio, pero si tuviera que crear una aplicación de escritorio del servidor cliente, el acceso a los datos se realizaría a través de un servicio web. Creo que el acceso a datos a través de un servicio web proporciona seguridad: no necesito pasar el nombre de usuario y la contraseña del servidor db, etc.

Antes de los servicios web, ¿cómo hicieron esto las aplicaciones de bases de datos? ¿Se pasó toda la información db importante a la instalación de la aplicación de escritorio? Si es así, ¿cómo gestionaron los programadores el aspecto de seguridad? ¿O los programadores usaron algo similar a los servicios web?

programming-practices security

— Aullidos Hagrid
fuente

55

Hubo cosas divertidas para las llamadas a procedimientos remotos, como DCOM (COM distribuido), CORBA, Java RMI ... Nunca entendí completamente ninguno de ellos, mientras que pedir algunos datos a través de HTTP tenía sentido al instante. Supongo que usar navegadores web todos los días hizo que los servicios web fueran más fáciles de asimilar :-)

— marcus

3

@marcus: probablemente porque HTTP tiene una solicitud-respuesta incorporada, mientras que "algún protocolo sobre un socket" hace que todos inventen esa rueda con una forma ligeramente diferente.

— Steve Jessop

11

Dependiendo de lo que llame un servicio web.

Antes de WSDL y REST, todavía había HTTP, por lo que básicamente todo lo que puede hacer ahora también se podría hacer antes.

Hubo una falta de uniformidad (por eso se crearon WSDL y REST en primer lugar), pero proporcionó el mismo nivel de confidencialidad y seguridad de los datos de los que habla.

En realidad, también puede evitar el uso de HTTP: puede redactar su propio protocolo y utilizar un servidor personalizado y clientes personalizados que abrirían un socket a este servidor y obtendrían los datos que necesitan (o publicarán los datos). Aquí, pierde todos los beneficios de estandarización de HTTP, pero una vez más, no da acceso a la base de datos a los clientes.

— Arseni Mourzenko
fuente

17

Ah, cuando teníamos palos y piedras.

Antes de Internet, teníamos algo llamado arquitectura "cliente / servidor" y redes de área local. Si no estaba tratando de establecer una conexión con un servidor a varias millas de distancia, estas redes funcionaron perfectamente bien para lograr casi cualquier cosa. Incluso podría establecer letras de unidad y utilizar conexiones a servidores de archivos como un disco duro remoto, si así lo desea. Si estuviera a varias millas de distancia, podría usar una red de área amplia para hacer esencialmente lo mismo, aunque a una velocidad más lenta y a un costo mayor.

La forma barata de hablar de forma remota era pasar información a través de líneas telefónicas utilizando dispositivos llamados módems, y si deseaba armar algo donde dos computadoras se comunicaban entre sí a través de aplicaciones informáticas, lo hizo de la misma manera que lo hace hoy: estableciendo Un protocolo de comunicaciones. No hay nada mágico en eso; ambas partes solo tienen que ponerse de acuerdo sobre el significado de todos los bytes

Desde las primeras etapas de Internet, las máquinas tenían formas de comunicarse a través de ellas. Los servicios web son solo el último sabor de la semana.

— Robert Harvey
fuente

55

"No hay nada mágico en absoluto acerca de eso, ambas partes sólo tienen que ponerse de acuerdo sobre lo que todos los bytes media." Y endianness :)

— HJK

2

@hjk, eso es fácil: little-endian es evidentemente superior a todas las demás opciones :-)

— Mark

3

Incluso iría tan lejos como para decir que la definición de internet requiere que las máquinas tengan formas de comunicarse a través de ella. Si no pueden hacer eso, no es Internet, es un montón de cables con delirios de grandeza.

— Steve Jessop

2

@SteveJessop: Estás equivocado, " Es una serie de tubos ".

— Deduplicador

3

Solo para aclarar algunos conceptos primero ...

Creo que el acceso a datos a través de un servicio web proporciona seguridad: no necesito pasar el nombre de usuario y la contraseña del servidor db, etc.

Creo que está combinando los conceptos de (1) Seguridad de la capa de transporte (TLS) y (2) controles de acceso en la declaración anterior ... Si un nombre de usuario y contraseña deben ser proporcionados o no no está relacionado con si un servicio web es proporcionado a través de (1) un canal encriptado y (2) autenticación (por ejemplo, una clave API).

Un servicio web extremadamente mal escrito aún puede requerir que se envíen contraseñas en texto plano a través de HTTP. Una persona mal escrita puede hacerlo a través de HTTPS (seguro, pero una vez roto, por ejemplo, a través de un ataque de hombre en el medio , abierto al abuso). Un servicio web mejor escrito debe manejar la conectividad de la base de datos internamente en función de otras entradas, por ejemplo, ID de sesión, después de validar los controles de autenticación y derechos.

Volviendo al punto principal, el comentario de @marcus sobre su pregunta es esencialmente eso. Los aspectos de seguridad no se tratan de manera diferente a las tecnologías "modernas", y eso cubre cuestiones de implementación tales como:

Si su protocolo de comunicaciones (tomando un poco de la respuesta de @ RobertHarvey) admite la transmisión de datos cifrados.
La estructura de carga de mensajes que se transmite entre el servidor y el cliente.
- ¿El cliente simplemente le dice al servidor que persista la dirección residencial de este usuario, o que se conecte a una base de datos en IP X.X.X.Xcon un nombre de usuario y contraseña, y luego ejecute la consultaINSERT INTO user_address ... ?
Cómo gestiona el servidor la conectividad de su base de datos (que realmente está aislada del cliente, consulte el primer párrafo).

Para más información:

— hjk
fuente