Как настольные приложения взаимодействовали с удаленным сервером до веб-сервисов?

11

У меня нет большого опыта работы с настольными приложениями, но если бы мне пришлось создавать настольное приложение клиент-сервер, доступ к данным осуществлялся бы через веб-сервис. Я считаю, что доступ к данным через веб-сервис обеспечивает безопасность - мне не нужно передавать имя пользователя и пароль на сервере db и т. Д.

До веб-сервисов, как приложения баз данных делали это? Была ли вся важная информация БД передана при установке настольного приложения? Если так, как программисты управляли аспектом безопасности? Или программисты использовали что-то похожее на веб-сервисы?

programming-practices security

— Вой Хагрида
источник

5

Для удаленных вызовов процедур были забавные вещи, такие как DCOM (Distributed COM), CORBA, Java RMI ... Я никогда полностью не понимал ни одного из них, хотя запрос некоторых данных через HTTP имел смысл сразу. Я полагаю, что использование веб-браузеров каждый день делает веб-сервисы более легкими в использовании :-)

— marcus

3

@marcus: возможно, потому что в HTTP встроен запрос-ответ, а «некоторый протокол через сокет» приводит к тому, что каждый изобретает это колесо немного другой формы.

— Стив Джессоп

11

В зависимости от того, что вы называете веб-сервисом.

До WSDL и REST был еще HTTP, поэтому в принципе все, что вы можете сделать сейчас, можно было бы сделать и раньше.

Не было единообразия (именно поэтому WSDL и REST были созданы в первую очередь), но это обеспечивало тот же уровень конфиденциальности и безопасности данных, о котором вы говорите.

Вы также можете на самом деле избежать использования HTTP: вы можете составить собственный протокол и использовать собственный сервер и собственные клиенты, которые открывают сокет для этого сервера и получают необходимые данные (или публикуют данные). Здесь вы теряете все преимущества стандартизации HTTP, но опять же, вы не предоставляете клиентам доступ к базе данных.

— Арсений Мурзенко
источник

17

Ах, назад, когда у нас были палки и камни.

До появления Интернета у нас было нечто, называемое архитектурой «клиент / сервер» и локальными сетями. Если вы не пытались установить соединение с сервером, находящимся за несколько миль, эти сети прекрасно работали, чтобы выполнить практически все. Вы можете даже установить буквы дисков и использовать подключения к файловым серверам, например, к удаленному жесткому диску, если хотите. Если бы вы были в нескольких милях от вас, вы могли бы использовать глобальную сеть, чтобы сделать по существу то же самое, хотя и на более медленной скорости и с большими затратами.

Дешевый способ удаленного общения состоял в том, чтобы передавать информацию по телефонным линиям с помощью устройств, называемых модемами, и если вы хотели подключить что-то, где два компьютера общались друг с другом через компьютерные приложения, вы сделали это так же, как сегодня: установив протокол связи. В этом нет ничего волшебного; обе стороны просто должны договориться о том, что означают все байты.

С самых ранних стадий Интернета машины могли взаимодействовать друг с другом. Веб-сервисы - это только последний аромат недели.

— Роберт Харви
источник

5

«В этом нет ничего волшебного; обе стороны просто должны договориться о том, что означают все байты.» И endianness :)

— hjk

2

@hjk, это просто: little-endian самоочевидно превосходит все остальные варианты :-)

— Mark

3

Я бы даже сказал, что определение интернета требует, чтобы машины могли общаться через него. Если они не могут этого сделать, то это не Интернет, а куча кабелей с манией величия.

— Стив Джессоп

2

@ SteveJessop: Вы не правы, « это серия трубок ».

— Дедупликатор

3

Просто сначала прояснить некоторые понятия ...

Я считаю, что доступ к данным через веб-сервис обеспечивает безопасность - мне не нужно передавать имя пользователя и пароль на сервере db и т. Д.

Я думаю, что вы объединяете понятия (1) безопасности транспортного уровня (TLS) и (2) контроля доступа в приведенном выше утверждении ... Требуется ли указывать имя пользователя и пароль или нет, не связано с тем, является ли веб-служба предоставляется через (1) зашифрованный канал и (2) аутентификацию (например, ключ API).

Чрезвычайно плохо написанный веб-сервис может по-прежнему требовать, чтобы пароли отправлялись в виде открытого текста по HTTP. Плохо написанный может сделать это через HTTPS (безопасный, но однажды сломанный, например, через атаку «человек посередине» , открытый для злоупотреблений). Более качественный веб-сервис должен обрабатывать соединение с базой данных внутренне на основе других входных данных, например идентификаторов сеансов, после проверки подлинности и контроля прав.

Возвращаясь к основному вопросу, комментарий @ marcus по вашему вопросу, по сути, таков. Аспекты безопасности рассматриваются не иначе, как "современные" технологии, и это охватывает вопросы реализации, такие как:

Поддерживает ли ваш протокол связи (немного заимствуя из ответа @ RobertHarvey) передачу зашифрованных данных.
Структура полезной нагрузки сообщения, которая передается между сервером и клиентом.
- Клиент просто говорит серверу сохранить постоянный адрес этого пользователя или подключиться к базе данных по IP X.X.X.Xс именем пользователя и паролем, а затем выполнить запросINSERT INTO user_address ... ?
Как сервер управляет подключением к своей базе данных (которая действительно изолирована от клиента, см. Первый абзац).

За дополнительной информацией:

— ХИК
источник