A>Как это реализзовано, можно поинтересоваться? Свой собственный протокол или все же стандартное TCP/IP?
На транспортном уровне конечно TCP/IP, на вышележащих уровнях наверное свой протокол https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI

http://ru.wikipedia.org/wiki/SQL_Azure
http://msdn.microsoft.com/en-us/magazine/gg309175.aspx
http://www.windowsazure.com/ru-ru/home/features/data-management/
http://www.microsoft.com/en-us/sqlserver/solutions-technologies/hybrid-it/private-cloud.aspx

On 29.04.2013 11:55, igor-booch wrote:

> M>Нет, вы путаете. Такое абстрагирование делается относительно легко, и
> точно так же connection string меняется на "внешний адрес базы" вместо
> "внутреннего. Ну и к облакам оно отношения не имеет.
>
> Я же писал уже, в случае облачных технологий connection string не к
> одной удаленной БД, а распределенному хранилищу.

В чём отличие, с точки зрения приложения?
Т.е. с точки зрения DriverManager.getConnection(db_url)?

--
WBR,
Serge.

H>В чём отличие, с точки зрения приложения?

Ни в чем,
в этом то и цель облачных технологий, чтобы архитектура клиентов не зависла от того где расположены серверы (БД, приложений), хоть в локальной сети хоть в соседней стране.
Это глобализация.

W>Доказана.

Дайте url пожалуйста

On 29.04.2013 13:00, igor-booch wrote:

> в этом то и цель облачных технологий, чтобы архитектура клиентов не
> зависла от того где расположены серверы (БД, приложений), хоть в
> локальной сети хоть в соседней стране.

С практической точки зрения — она не может от этого не зависеть ввиду
наличия латентности. Перенесите MS-SQL от вашего 1С в Амазон и вы
ощутите это сразу.

А с теоретической это всегда было так (если мы рассматриваем базы,
доступные по сетевым протоколам вроде TCP/IP).

--
WBR,
Serge.

Здравствуйте, igor-booch, Вы писали:

IB>Дайте url пожалуйста
Уже дал.

H>С практической точки зрения — она не может от этого не зависеть ввиду
H>наличия латентности.
По поводу латентность я уже высказывался в этом топике.


H>А с теоретической это всегда было так (если мы рассматриваем базы,
H>доступные по сетевым протоколам вроде TCP/IP).
С теоретической точки зрения может и так, но с практической сейчас существует разные архитектуры: Web и настольные приложения.
По поводу БД доступных по сетевым протоколам TCP/IP я тоже уже высказывался.

Здравствуйте, igor-booch, Вы писали:

M>>И "клиент" в этой интеграции — капля в море. Основная интеграция информационных систем выполняется на уровне "система-система". Девушка, сидящая в "банк-клинете" и сверяющая там проводки, все-таки не элемент интеграции предприятия с банком.
IB>Ну так при интеграции двух систем одна из них может выступать в роли сервера, другая в роли клиента. Причем клиент в этом случае (при использовании облачных технологий) может быть толстым и распределенным. Если каждая из систем будет выступать и в роли клиента и роли сервера, получите двунаправленное взаимодействие.

А при чем здесь облако? Каждый клиент видит другую систему как некоторый "удаленный URL". Находится вторая система где-то локально у ее изготовителя или в облаке — нет никакой разницы.

M>>А там web services/soap/rest/rpc/etc... Это, конечно, тоже "веб", но ни к тонким, ни к толстым клиентам отношения не имеет.
IB>Сейчас да, а я говорю про перспективу и тенденцию развития технологий.
А при чем здесь облако? Основная масса клиентов как ходила по этим протоколам, так и будет ходить. Только теперь адреса, по которым они будут ходить, будут находится "в облаке", а не на стороне предприятия. Со стороны приложения-клиента разницы вообще никакой. А доступ в базу приложению никто не даст.

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

M>>А "веб" сейчас часто используется по вполне прагматичным причинам. Веб-сервер обеспечивает дополнительный уровень проверок доступа (привелегий и т.п.). Отдать наружу логин с паролем к базе предприятия — это странное решение. Можно (и нужно все равно) рулить полномочиями в базе и т.п., но дополнительный уровень делает этот момент проще (хотя добавляет свои уязвимости).
IB>Как это проще? Вы создаете дополнительный слой.
Вместе со слоем я создают разделение между "уровнем клиентских операций" и "реализацией этих операций на схеме данных". После чего обе части начинают функционировать независимо. Да, есть небольшие (совсем небольшие!) расходы на формализацию этого интерфейса. Но гибкость того стоит.

IB>На это требуются дополнительные трудозатраты: и капитальные и эксплуатационные. По моим наблюдениям в 80% проектов возможности конфигурирования безопасности БД используются лишь на 20%. Почему бы не использовать средства обеспечения безопасности БД на 100%? Зачем усложнять, если технологии позволяют обойтись без дополнительного слоя? Средства обеспечения безопасности БД постоянно совершенствуются, не зря же в это вкладывают деньги.

Средства обеспечения безопасности БД предназначены для тех сценариев, где без них никак не обойтись. Это либо legacy, либо какие-то совершенно сумасшедшие (сложные) сценарии. 80% пользователей это не нужно. Поэтому "средства обеспечения безопасности" БД не используются (они сложны в настройке, тяжелы в сопровождении, очень тяжелы при меняющихся требованиях) и используют более гибкие механизмы реализации безопасности на клиенте. Ну и "дополнительный слой" защиты доступа к данным тоже лишним не бывает.

IB>>>Раньше единственным средством создания распределенных клиентов был Web.
M>>Давайте определимся, что такое "распределенный клиент". Это много клиентов по всему миру? Ну да, это делалось (и будет делаться) через дополнительную прослойку между клиентом и базой.
IB>А как же технический прогресс? Или Вы считаете, что существующие технологии и архитектуры это вершина эволюции и лучше уже не будет?

А где здесь прогресс? Ну был один URL для доступа к базе, стал другой. Клиент вообще никак не поменялся. И "облака" с точки зрения реализации клиента ну вообще никак не влияют на архитектуру. Вот серверная реализация (которая поехала в облако) — это да, изменения в архитектуре. Но тоже не слишком большие. Кластеризация делалась и раньше при необходимости. Ну да, константы латентности другие, но принципиально нового там тоже ничего нет. Облака в первую очередь отличаются новым подходом к предоставлению (provisioning) различных вычислительных ресурсов. Это действительно достижение, но на "архитектуру" клиента влияет слабо. Можно только говорит о каких-то внутренних достижениях (которые при реализации облака исползьуются). Но это общие достижения вообще для распределенных технологий. Облако — коммерческая модель в первую очередь.

Или вы предлагаете "толстого клиента" запускать на виртуальной машине, расположенной в облаке? Вот это будет интересно. Но до этого еще далеко, да и сценарии подобные будут скорее от безысходности (не осилили веб), чем от необходимости.

M>>А обосновать? С моей личной точки зрения, как раз веб-разработка дешевле.
IB>В web много кода пишется для обеспечения взаимодействия между клиентом (javascript) и сервером.
Эм... Много? Полный интеграционный слой (с комментариями, достаточно жестким форматированием и полезными фичами вроде релогина и повтора запроса) — 2 тысячи строк (меньше). При этом подобный слой пишется ровно 1 раз для организации и допиливается под каждый проект. Преобразование данных из DTO в JSON на сервере делается элементарно (при выборе нужных языков/библиотек), а на клиенте их вооще распаковывать не нужно, раз они в JSON приходят.

IB>В web вы вынуждены тратить время на создание и поддержку дополнительного слоя между клиентом и БД.
Этот слой оказывается очень полезен и удобен. В нем, например, обрабатываются ошибки при работе с базой (соединение пропало и т.п.). Именно на этом уровне они прекрасно заворачиваются в "internal-server-error" и передаются на клиент. На клиенте обрабатываются один раз (на все приложение), см. абзац выше. А как вы это будете в толстом клиенте обрабатывать? Каждую работу с базой в try/catch оборачивать? Так их там тонны, этих запросов. Или "прослойку" напишете?

IB> Уточню что, чем богаче пользовательский интерфейс, чем дороже будет web по сравнению с толстым клиентом. http://ru.wikipedia.org/wiki/Rich_Internet_Application#.D0.9D.D0.B5.D0.B4.D0.BE.D1.81.D1.82.D0.B0.D1.82.D0.BA.D0.B8

Это про недостатки? Так некоторые вы все равно игнорируете (скорость загрузки страниц). Часть есть и у вас (зависимость от интернета, неиндексируемость поисковиками). А некоторые зависят от прямых рук разработчиков. О "прямизне рук" чуть ниже. Если же вы про "сложности разработки приложений", то примерно все то же будет и в толстом клиенте (те же латентности, асинхронности (или подвисающий интерфейс)) и т.п.

Возвращаясь к прямым рукам. Технологическая сложность (из сложностей) обеспечена в первую очередь богатыми возможностями . Сложность расширяемости — недостатками архитектуры: не заложились на расширяемость. В standalone все то же будет. А еще "много сложностей" RIA объясняется желанием (не пойму только, разработчиков или производителей) притащить подохды со standalone в web. Поэтому получаются монструозные фреймворки с самостоятельной реализацией всего (включая ручные layouts, управление фокусом, обработка событий и прочие радости). И к этим фреймворкам потом еще вручную фиг что прикрутишь (т.е. только работа со стандартнмыи компонентами). Кто работал и пробовал делать удобные для пользователя UI, меня поймет. Далеко не всегда "стандартные" контролы удобны (в чистом HTML сделать нестандартный контрол гораздо проще, чем во фреймоврках и десктопе). А если отбросить подход (мы все делаем как на десктопе) и использовать легковесные подходы, то все становится легко и просто. Кнопка — это не нечто громадное и сложно взаимодействующее по куче аспектов со всем приложением, а любой элемент, биндящийся к action, реагирующий на клик и умеющий поддерживать состояние "disabled". Вот недавно меня коллега спросил, сколько займет реализовать "grid". Ну и изобразил я "grid" в 5 строк на js+html+helpers. Так что это все надуманные проблемы.

M>>В браузере очень хорошие механизмы layout'ов. Подобное реализовывать в "толстом клиенте" не удобно.
IB>WPF, JavaFX

В JavaFX нет нормальных биндингов. Там еще по зависимостям, типам и прочим ужасам можно походить. Почти весь этот ужас (у меня не было observable collections) реализуется один раз в 1-1,5 тысячи строк и примерно 10 методов в общем виде. После чего прекрасно работает на клиенте. А в том же JavaFX еще интерфейсы анонимные придется писать на функцию от нескольких изменяющихся значений (это еще не считая разницы в API, когда я могу кормить observable/non-observable в перемешку одной и той же функции).

M>>В толстых клиентах можно выполнять какие-то дополнительные операции врдое кэширования. Но, опять же, нужно изучать конкретные примеры. Может оказаться выгоднее держать "веб-сервер" с одним общим кэшем на всех, чем выдавать каждому клиенту его порцию данных, которые он потом закэширует.
IB>Кэширование на клиенте было невыгодно, когда когда была дорогая память и вообще дорогое железо. Сейчас тенденция такова, что память дешевеет, быстродействие растет, а это делает резонным утолщение клиентов. Web был выгоден когда было дорогое железо. Сейчас Web не может на 100% использовать появившееся возможности увеличения быстродействия клиентов и многопоточность. А бизнес требует все более и более навороченный и в тоже время отзывчивый пользовательский интерфейс.

Кэш на клиенте — это хорошо. Но это может быть дополнительной нагрузкой на сервер, если вы не поставите дополнительную "кэширующую" прослойку для выдачи данных . А многопоточность клиентам обычно не нужна. Есть отличная асинхронность. Без шуток — отличная. Она не позволяет программисту делать "залипающий" интерфейс. Что-то тяжелое считать — это редкий случай. Обычно клиент ходит на сервер за данными и их отображает. Т.е. весь тяжелый процессинг — на сервере.

А еще веб был выгоден, когда пользователи не хотели ставить всякие трояны на свои машины. Или не могли (ну нет у меня windows!). Или вообще не могут (а может, у меня андроид!). Поэтому веб был (и остается) удобной и доступной платформой.

Здравствуйте, igor-booch, Вы писали:

H>>А с теоретической это всегда было так (если мы рассматриваем базы,
H>>доступные по сетевым протоколам вроде TCP/IP).
IB>С теоретической точки зрения может и так, но с практической сейчас существует разные архитектуры: Web и настольные приложения.
IB>По поводу БД доступных по сетевым протоколам TCP/IP я тоже уже высказывался.

Архитектуры разные потому, что платформа (целевой API) для настольных приложений (окна, активные области, ручная перерисовка) и для веб (tree document model, "active" components, system-controlled rendering, system event propagation, явная асинхронность) отличаются. Т.е. сначала "платформа", потом — архитектура. Были бы "окна и все остальное", были бы архитектуры похожи. На GWT посмотрите — почти "настольное приложение" по архитектуре получится. А работает в web (и мимикрирует под "настольное" API, но плохо).

IB>>Дайте url пожалуйста
W>Уже дал.

Если Вы имеете ввиду http://en.wikipedia.org/wiki/CAP_theorem, то
1) непонятно в рамках какой научной теории или хотя бы в рамках какой формальной модели доказана теорема (теорем без теорий не бывает)
2)

Thus the theorem doesn't rule out achieving consistency in a distributed system, and says nothing about cloud computing per se or about scalability.

AK>Пришли мыши к сове и спрашивают, как им от котов спастись. Сова говорит: "Станьте ежиками." Мыши радуются, празднуют, потом подумали, возвращаются к сове и спрашивают: "Сова, а как же нам ежиками стать, мы же мыши?" А Сова им: "Мое дело — стратегия!".

Им нужна генная инженерия

Здравствуйте, igor-booch, Вы писали:

IB>Если Вы имеете ввиду http://en.wikipedia.org/wiki/CAP_theorem, то
IB>1) непонятно в рамках какой научной теории или хотя бы в рамках какой формальной модели доказана теорема (теорем без теорий не бывает)

Публикацию читал? Или это теперь не обязательно для предметного обсуждения?

W>Публикацию читал? Или это теперь не обязательно для предметного обсуждения?
Или давайте точные ссылки (url, или хотя бы название с авторами) на материалы, которые Вы хотите предметно обсудить. Я не должен догадываться какую публикацию Вы имеете ввиду.

Здравствуйте, igor-booch, Вы писали:

IB>Или давайте точные ссылки (url, или хотя бы название с авторами) на материалы, которые Вы хотите предметно обсудить. Я не должен догадываться какую публикацию Вы имеете ввиду.

Ссылка на публикацию — в английской Вики под номером 1. На это я и указал. Зачем догадываться, нужно просто посмотреть.

Предметно обсудить хочу не я.

W>Ссылка на публикацию — в английской Вики под номером 1. На это я и указал. Зачем догадываться, нужно просто посмотреть.
В упор не вижу ни в одном из ваших предыдущих сообщений ссылки на публикацию под номером 1. Неужели сложно URL скопипастить?
Ну да ладно неважно. Буду полагать что вы имеете ввиду http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf

W>Предметно обсудить хочу не я.
Возникает вопрос: а что Вы тогда делаете в этой ветке?

CAP теорема конечно интересная и полезная. Она дает возможность классифицировать распределенные системы (CA, CP, AP в http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP и пункты 3.2.1 — 3.2.3 в http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf). Но эти классы распределенных систем являются крайними случаями. Реальные системы или их части могут занимать промежуточное положение или быть гибридными. Так как:

Consistency — в теореме сформулировано требованием, того чтобы во всех вычислительных узлах в любой момент времени данные не противоречат друг другу. То есть устаревание кэша узла распределенной БД не допускается. На практике считается допустимым и даже необходимым, если конечные пользователи видят устаревшие данные. Если данные на мониторе будут меняться 20 раз в секунду, пользователю это не понравится. Но слишком устаревшие данные тоже плохо. Так что это требование на практике неформализуемо, завит от того какие именно данные имеются ввиду и кем они используются. Если из за использования устаревших данных была произведена некорректная транзакция, то такая транзакция откатывается. На практике это допустимо.

Availability — в теореме сформулировано требованием, того чтобы любой запрос к распределённой системе завершается корректным откликом. Это означает что если удаленный ресурс не может выполнить запрос он должен сказать об этом, а не молчать. На практике на запросы к удаленным ресурсам ставятся таймауты. Если сработал таймаут пользователю либо предлагается сделать запрос позже, либо запрос ставится в очередь и с заданным интервалом времени делаются повторные попытки сделать запрос.

Partition tolerance — расщепление распределённой системы на несколько изолированных секций не приводит к не приводит к некорректности отклика от каждой из секций. Это значит что если Вы записали в одну из изолированных секций (секция — это множество узлов, между которым есть связь), а в другой секции потом читаете, Вам должна четко сказать что чтение невозможно (жертвуем Consistency) и задержать ответ пока связь между секциями не восстановится (жертвуем Availability). На практике для одних данных допустим один вариант, для других другой. Да и разделение интернета на секции возможно только в случае мировой войны или катаклизма.

Также хочу заметить:
1) В модели отсутствует центральный узел. А он необходим в распределенных БД для координации транзакций.
2) Теорема накладывает ограничения не на облачные технологии в частности, а на распределенные системы вообще. В http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf повествование ведется с отсылками на Web сервисы.
3) Формальная модель в рамках которой формулируется теорема (http://read.pudn.com/downloads95/ebook/386159/Distributed.Algorithms.pdf) не опирается на стандартную сетевую модель OSI, использующуюся в реальных сетях. Availability и Partition tolerance могут быть обеспечены как на транспортном уровне (TCP), так на более вышележащих уровнях, например MSMQ.

Надеюсь теперь понятен смысл фразы из http://en.wikipedia.org/wiki/CAP_theorem

Thus the theorem doesn't rule out achieving consistency in a distributed system, and says nothing about cloud computing per se or about scalability.

M>А при чем здесь облако? Каждый клиент видит другую систему как некоторый "удаленный URL".
M>А при чем здесь облако? Основная масса клиентов как ходила по этим протоколам, так и будет ходить.
M>А где здесь прогресс? Ну был один URL для доступа к базе, стал другой.
M>Облако — коммерческая модель в первую очередь.
M>Облака в первую очередь отличаются новым подходом к предоставлению (provisioning) различных вычислительных ресурсов.
По моему Вы сводите облачные технологии к виртуализации. Виртуализация это один из аспектов реализации облачных принципов.

M>А как вы это будете в толстом клиенте обрабатывать? Каждую работу с базой в try/catch оборачивать? Так их там тонны, этих запросов.
Точно также как Вы это делаете на web сервере средствами вашего языка программирования.

M>А многопоточность клиентам обычно не нужна. Что-то тяжелое считать — это редкий случай.
В простых системах наверное так и есть.

M>Есть отличная асинхронность. Без шуток — отличная.
Не понял. Где есть? Многопоточность это реализация ассинхронности.

M>А еще веб был выгоден, когда пользователи не хотели ставить всякие трояны на свои машины.
То есть городить дополнительные слои вместо того-что развивать антивирусное ПО? Каждый должен заниматься своим делом. Программисты должны сосредотачиваться на бизнес логике. Антивирусы ловить вирусы. Сетевики проектировать сети. И никто друг от друга зависеть не должен. В этом и есть прогресс, в разделении труда.

M>Архитектуры разные потому, что платформа (целевой API) для настольных приложений (окна, активные области, ручная перерисовка) и для веб (tree document model, "active" components, system-controlled rendering, system event propagation, явная асинхронность) отличаются. Т.е. сначала "платформа", потом — архитектура.

А мне как разработчику хочется потратить больше времени на проработку бизнес логики и удовлетворение потребностей заказчика, а не на разбирательство отличий API и платформ. И конечному пользователю наплевать на платформу и каким API сделано ПО. У заказчика требования одни и не зависят от платформы и API и где находится БД и т.д. Чем больше времени разработчики будут тратить на непосредственные нужды заказчиков, и меньше времени тратить на всякие чисто технические или инфраструктурные моменты, тем выше будет производительность труда разработчиков. Повышение производительности труда является целью технического прогресса.
Не понимаю про ручную перерисовку в настольных приложениях и system-controlled rendering в веб.

Здравствуйте, igor-booch, Вы писали:

IB>Возникает вопрос: а что Вы тогда делаете в этой ветке?
Я просто зашел, чтобы поправить вас в части "не доказана". Ни на что другое, из того что вы пишете, я не возражал. Так что мне оппонировать не нужно.

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


IB>Надеюсь теперь понятен смысл фразы из http://en.wikipedia.org/wiki/CAP_theorem
IB>

IB>Thus the theorem doesn't rule out achieving consistency in a distributed system, and says nothing about cloud computing per se or about scalability.

И и теперь, и раньше был прекрасно понятен.

W>Ну и в качестве бонуса, вы все-таки ознакомились с первоисточником и вероятно почерпнули для себя что-то полезное.
Да, действительно, спасибо

Здравствуйте, maxkar, Вы писали:

M>Далеко не всегда "стандартные" контролы удобны (в чистом HTML сделать нестандартный контрол гораздо проще, чем во фреймоврках и десктопе). А если отбросить подход (мы все делаем как на десктопе) и использовать легковесные подходы, то все становится легко и просто. Кнопка — это не нечто громадное и сложно взаимодействующее по куче аспектов со всем приложением, а любой элемент, биндящийся к action, реагирующий на клик и умеющий поддерживать состояние "disabled".

Только в терминах десктопа это не "кнопка".
Вообще "веб" воспитал замечательных пользователей. Они смиренно ждут перересовки страницы(а то и рефреша), терпят глючный вырвиглазный UI, за который на десктопе закапывали за забором еще в начале 90-х и как откровение воспринимают вот такие "легковесные кнопки"... Ну а уж контекстное меню по правой кнопке или хоткеи(без возможности перенасройки, разумеется) — это вообще фантастика, "будущее уже здесь".