Раньше распределенными могли быть только тонкие клиенты на SOA.
C помощью облачных технологий распределенными могут быть и толстые клиенты, так как БД стала таким же ресурсом, как и сервис.
Понятно, что удаленный доступ к БД был возможен и раньше,
но облачные технологии обеспечивают делают этот доступ менее трудоемким и более функциональным (безопасность, балансировка нагрузки).
Правильно ли понимаю?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
IB>Понятно, что удаленный доступ к БД был возможен и раньше, IB>но облачные технологии обеспечивают делают этот доступ менее трудоемким и более функциональным (безопасность, балансировка нагрузки).
Проблема толстого клиента всегда была в том, что он толстый. Т.е. тянет себе локально большой объем данных. Кроме того, так как база близко, то сходить на нее лишний раз не составляет труда -- как следствие большое количество запросов в базу по делу и нет.
Если теперь базу переместить из локальной сети куда-то там, то появятся тормоза. Нет, конечно, если один из серверов облака находится не далеко, то становится проще, но не сильно.
Тонкий клиент. Тонкий клиент не так "тонок", на самом деле. App-сервер, с которым работает тонкий клиент, сам будет "толстым клиентом" к серверу БД. В том ключе, что база близко и сделать "лишний" или тяжелый запрос не составляет проблем.
Ну и не стоит забывать о толстых клиентах, который при инициализации тянут много данных с сервера, а потом работают автономно, периодчески синхронизируя состояние. Как Janus для RSDN. Для них побарабану где сервер.
A>Проблема толстого клиента всегда была в том, что он толстый. Т.е. тянет себе локально большой объем данных. A>Если теперь базу переместить из локальной сети куда-то там, то появятся тормоза.
Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз.
Второе облачные технологии для того и существуют, чтобы бороться с этими тормозами за счет распределения вычислений и распределения хранения данных. Раньше сервер БД и сервер приложения должен был находится в локальной сети. Теперь Вы можете купить услугу хостинга БД и серверного ПО у дата центра. Причем не у одного физического дата центра, а у сети дата центров. Ваша БД и серверное ПО будет распределено по физическим дата центрам, таким образом чтобы снизить нагрузку на каналы связи. Но для Вас, то есть Вашего толсто клиента, будет видна одна БД и один сервер приложений. То есть единая логическая точка доступа на множество физических хостов.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
A>>Проблема толстого клиента всегда была в том, что он толстый. Т.е. тянет себе локально большой объем данных. A>>Если теперь базу переместить из локальной сети куда-то там, то появятся тормоза.
IB>Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз.
Скорость фигня, тут важна латентность. Скорость света еще никто не отменял.
IB>Второе облачные технологии для того и существуют, чтобы бороться с этими тормозами за счет распределения вычислений и распределения хранения данных. Раньше сервер БД и сервер приложения должен был находится в локальной сети.
Что распределять если у меня строго императивный код, который на 1 открытие формы использует 5-10 запросов к серверу, который находится, дай бог, в той же стране что и я (а скорее всего где-нить в голандии или, супер, в москве)? Если пинг до сервера у нас, скажем 20mc (сравни с <1mc для локалки), то только на то чтобы достучаться к серверу у нас уйдет 5*20-10*20mc=100mc-200mc. А теперь добавь сюда расходы на соединение и передачу данных, будет хз сколько, но не меньше 300mc. Добавь сюда тяжелые запросы, которые мы любим писать. Твои пользователи готовы работать с приложением, которое будет работать на 0,1-0,3 сек медленней, чем если бы оно работало в той же сети? А для чего? Только для того, чтобы руководство отчиталось, что мы используем олачные технологии?
IB>Теперь Вы можете купить услугу хостинга БД и серверного ПО у дата центра. Причем не у одного физического дата центра, а у сети дата центров. Ваша БД и серверное ПО будет распределено по физическим дата центрам, таким образом чтобы снизить нагрузку на каналы связи. Но для Вас, то есть Вашего толсто клиента, будет видна одна БД и один сервер приложений. То есть единая логическая точка доступа на множество физических хостов.
Что это меняет если у ближайший датацентр в 300 километрах от меня?
Тут дело в том, что нужно менять подход к программированию, менять архитектуру толстого клиента, а это уже будет не толстый клиент.
IB>Понятно, что удаленный доступ к БД был возможен и раньше, IB>но облачные технологии обеспечивают делают этот доступ менее трудоемким и более функциональным (безопасность, балансировка нагрузки).
CAP-теорему пока еще никто не отменял, так что "классическая" реляционная БД в облаке не будет маштабироваться бесконечно.
IB>>Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз. A>Скорость фигня, тут важна латентность. Скорость света еще никто не отменял.
Время пинга это такая же техническая проблема. С ростом сети дата центров она решится. Так как чем больше дата центров, тем больше вероятность что рядом с Вами находится один из них. Это вопрос времени.
A>Тут дело в том, что нужно менять подход к программированию, менять архитектуру толстого клиента, а это уже будет не толстый клиент.
Основная идея облачных технологий заключается в том, что код клиента абстрагирован от того где физически находится нужный сервис (БД). Код толстого клиента не зависит от того где находится БД в облаке или локальной сети. Меняется только конфигурация: connection string.
Кстати, Вы также абстрагированы от масштабов (количества одновременно работающих пользователей (клиентов)). Если у Вас резко увеличивается количество пользователей просто докупите у дата центра машинное время и увеличьте степень распределения хранилища данных.
A>Что распределять если у меня строго императивный код
Вы наверное имеете ввиду что декларативный код может быть автоматически распараллерен? Да хранилище данных должно быть поддерживать распределенность. Но это дело хранилища данных и облачных технологий, а не кода толстого клиента. Код толстого клиента остается императивным. Программист БД, так же по сути должен быть абстрагирован от распределенности.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
А>CAP-теорему пока еще никто не отменял, так что "классическая" реляционная БД в облаке не будет маштабироваться бесконечно.
CAP-теорема: http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP не доказана. Она эвристическая. Поэтому пока до конца непонятно, то ли она описывает фундаментальные ограничения, то ли ограничения обусловленные текущим уровнем развития облачных технологий. Хотя теорема интересная, спасибо.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Кстати, Вы также абстрагированы от масштабов (количества одновременно работающих пользователей (клиентов)). Если у Вас резко увеличивается количество пользователей просто докупите у дата центра машинное время и увеличьте степень распределения хранилища данных.
Это легко только для чтения. А вот как обеспечить нормальную запись при сохранении всех тех же гарантий? Ведь обновление одного и того же объекта могут запросить на разных узлах.
IB>Код толстого клиента остается императивным. Программист БД, так же по сути должен быть абстрагирован от распределенности.
Не получится. Если сохранять все старые гарантии, запись будет тормозить. Либо запись будет вестись только на master node, либо узлы облака будут как-то согласовывать общие блокировки. Оба варианта — потеря скорости по сравнению с одной базой. А если не обеспечивать клоассическую транзакционность, то это будет уже совсем другой подход на клиенте (другая модель операций, необходимость учитывать конкретные варианты потери данных и т.п.).
Здравствуйте, igor-booch, Вы писали:
IB>Понятно, что удаленный доступ к БД был возможен и раньше, IB>но облачные технологии обеспечивают делают этот доступ менее трудоемким и более функциональным (безопасность, балансировка нагрузки).
IB>Правильно ли понимаю?
Откуда там безопасность? Если облако "чужое", то ее никогда и не было. А если свое, то безопасность может оказаться сложнее обеспечить, чем для одной базы. Одна база банально закрывается брэндмауэром от внешнего мира, а для облака нужно синхронизацию настраивать.
Да и "балансировка нагрузки" пойдет только на чтение (запись нужно распространять по остальным узлам). Вероятно, при этом еще и задержку на распространение данных придется учитывать. Если я что-то считал, а потом пошел делать update этого с optimistic locking (where version = ...), обновление может обломаться (что ожидаемо). Но после этого я хочу получить последнюю (!) версию данных (или с версией не ниже, чем...). Догадается ли облако сделать это "прозрачно" для меня?
Здравствуйте, igor-booch, Вы писали:
IB>>>Тормоза это проблема прошлого. Сейчас тенденция такова, что скорость интернет сетей постоянно растет. Это раз. A>>Скорость фигня, тут важна латентность. Скорость света еще никто не отменял. IB>Время пинга это такая же техническая проблема. С ростом сети дата центров она решится. Так как чем больше дата центров, тем больше вероятность что рядом с Вами находится один из них. Это вопрос времени.
С таким подходом тебе в философию нужно, а не сюда.
M>Это легко только для чтения. А вот как обеспечить нормальную запись при сохранении всех тех же гарантий? Ведь обновление одного и того же объекта могут запросить на разных узлах. M>Либо запись будет вестись только на master node, либо узлы облака будут как-то согласовывать общие блокировки.
Да, для записи потребуется координатор распределенных транзакций, то есть некий центральный узел.
Облачная технология рассчитана на ассиметричность чтения\записи. Типичный клиент читает больше чем пишет.
А какая альтернатива? Web и тонкие клиенты? Там все через центральный узел: и чтение и запись.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
M>>Это легко только для чтения. А вот как обеспечить нормальную запись при сохранении всех тех же гарантий? Ведь обновление одного и того же объекта могут запросить на разных узлах. M>>Либо запись будет вестись только на master node, либо узлы облака будут как-то согласовывать общие блокировки.
IB>Да, для записи потребуется координатор распределенных транзакций, то есть некий центральный узел. IB>Облачная технология рассчитана на ассиметричность чтения\записи. Типичный клиент читает больше чем пишет. IB>А какая альтернатива? Web и тонкие клиенты? Там все через центральный узел: и чтение и запись.
Для начала нужно определиться, с чем и как ведется работа. Да и с облачными технологиями. Что такое облако? Если я правильно понимаю, "облачные технологии" предполагают два сервиса. Первый — это некий хостинг ресурсов в вакууме где угодно, но только не в вакууме (в вакууме проблемы с охлаждением). Второй — это API доступа к этому хостингу (напоминающий обычный API). И нужно разобраться, какие же проблемы хочется решать путем получения ресурсов в облаке.
1. У нас клиенты работают по всему миру и важна латентность обращения к серверам (ping пресловутый). Облако нам этого в общем случае гарантировать не может. Провайдер будет оптимизировать расположение узлов так, как выгоднее ему. Они могут уехать в антарктиду (дешевое охлаждение) или туда, где интернет дешевый. Но совсем не туда, куда нужно бы для удобства клиентов. Кроме того, латентность может иметь смысл бороть. Ручной выбор хостинга (и настройка клиентов на правильные адреса) лучше.
2. Важна вычислительная мощность на сервере (именно считать!). Да, до тех пор, пока запросы не упираются в тот же балансировщик, например. И только до тех пор, пока важен throughput, а не latency (потому что на тот же вычислительный узел внезапно может приехать много клиентов). Здесь физическое расположение хостинга не важно, API доступа не принципиален.
3. Важна вычислительная мощность (выборка данных). Разница только в том, насколько клиент знает о различии между операциями чтения и записи. Если операции "только чтение" и "возможна запись" различимы, то технологии есть (с различным уровнем гарантии). Любая реплиация это гарантирует. Точно есть в Oracle. Есть в нескольких видах в postgresql. Автоматическое руление запросами для постгреса умеет pgpool. В этом случае запросы на запись пойдут на одну базу. Запросы на чтение — на любую базу. При синхронной репликации даже задержек заметных не будет. Здесь API доступа к данным важен. Могут быть важны и особенности хостинга, так что облако плохо подходит.
4. Важно дисковое хранилище. Опять зависит от того, нужно ли нам throughput (и неважно, где и как) или latency (тогда важно, где, и как выполняется доступ)
В общем, все упирается в то, что в первую очередь нужно от хостинга и что мы готовы сделать с приложением. Ну и банально все упирается в деньги. В облаке может быть удобнее хостить приложения с низкой нагрузкой, с высокой вычислительной нагрузкой, с высокими требованиями к хранению. В общем, либо совсем некритичные задачи, либо задачи ориентированные на throughput (вычисления или хранения, "больше", но не "быстрее"). Провайдер облака ведь тоже будет оптимизировать свои издержки, так что без минусов не обойдется. Оптимизации быстродействия имеет смысл рулить вручную. По тем же базам нанять кого-нибудь для балансировки нагрузки, и получите почти облако. Географически распределенную сеть построить. И т.п.
Кстати, не вижу проблем с тонким клиентом. Ни с "читать", ни с "писать". Для клиента, который знает о распределенности, вообще никаких проблем нет (уровень обмена данными достаточно низок и если мы различаем запросы, мы можем их рулить по разным серверам). Который не знает можно порулить round-robin'ом и несколькими записями в DNS. Или redirect на нужный адрес по IP клиента делать. А за фронтендом можно свое "облако" поднимать. Ну будет к базе ходить 5 узлов вместо одного. На тех (веб)-узлах тоже все способы балансировки можно применять. И локальные реплики базы делать, и в сервере данные кэшировать (кстати, дополнительный уровень для повышения производительности при доступе к данным!)
Итого. Облачные технологии не делают доступ ни проще, ни функциональнее. Они делают сервис дешевле (потому что провайдер заботится о дешевизне ресурсов) и поэтому могут быть интересны для бизнеса. А все остальные требования вроде безопасности и балансировки нагрузки все равно придется учитывать вручную. Возможно — доделывать код под то же облако (или собранную вручную распределенную сеть).
M>И нужно разобраться, какие же проблемы хочется решать путем получения ресурсов в облаке.
Я уже написал в исходном сообщении какие проблемы решают облака. Если Вы не согласны с этого нужно было и начинать.
Построюсь. Сейчас информационные системы уровня предприятия выходят за рамки локальной сети здания. Бизнес становится распределенным, интеграция информационных систем повышается. Раньше единственным средством создания распределенных клиентов был Web. Но Web разработка (тонкий клиент) дороже, чем для настольных приложений (толстый клиент). Если сравнить стоимость двух приложений с одинаковым набором возможностей, но отличающих только тем, что одно Web, а другое настольное приложение, то дороже будет Web. Облачные технологии позволяют сделать распределенными толстые клиенты. Да, это удешевлении при увеличении набора возможностей. Но в этом и заключается развитие технологий.
Про остальное либо уже писал, либо не понял.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
M>>И нужно разобраться, какие же проблемы хочется решать путем получения ресурсов в облаке.
IB>Я уже написал в исходном сообщении какие проблемы решают облака. Если Вы не согласны с этого нужно было и начинать. IB>Построюсь. Сейчас информационные системы уровня предприятия выходят за рамки локальной сети здания. Бизнес становится распределенным, интеграция информационных систем повышается.
И "клиент" в этой интеграции — капля в море. Основная интеграция информационных систем выполняется на уровне "система-система". А там web services/soap/rest/rpc/etc... Это, конечно, тоже "веб", но ни к тонким, ни к толстым клиентам отношения не имеет. Девушка, сидящая в "банк-клинете" и сверяющая там проводки, все-таки не элемент интеграции предприятия с банком.
А "веб" сейчас часто используется по вполне прагматичным причинам. Веб-сервер обеспечивает дополнительный уровень проверок доступа (привелегий и т.п.). Отдать наружу логин с паролем к базе предприятия — это странное решение. Можно (и нужно все равно) рулить полномочиями в базе и т.п., но дополнительный уровень делает этот момент проще (хотя добавляет свои уязвимости). Толстые клиенты были в локальной сети тоже по соображениям безопасности (хоть там и пароль с открытым текстом, снаружи в базу никто не залезет и изучать не будет).
IB>Раньше единственным средством создания распределенных клиентов был Web.
Давайте определимся, что такое "распределенный клиент". Это много клиентов по всему миру? Ну да, это делалось (и будет делаться) через дополнительную прослойку между клиентом и базой. А со стороны "распределенного клиента" облака вообще не видно. Какая разница, что там за url-ом — облако или внешний адрес базы данных предприятия. А еще "распределенные клиенты" впервые были изобретены очень и очень давно. Были это "толстые приложения" и назывались "банк-клиент". Если мне не изменяет память, они дозванивалиь (да, по телефону через модем!) до банка и проводили нужные операции. И только гораздо позже появились "клиенты в браузере".
IB>Но Web разработка (тонкий клиент) дороже, чем для настольных приложений (толстый клиент). Если сравнить стоимость двух приложений с одинаковым набором возможностей, но отличающих только тем, что одно Web, а другое настольное приложение, то дороже будет Web.
А обосновать? С моей личной точки зрения, как раз веб-разработка дешевле. В браузере очень хорошие механизмы layout'ов. Подобное реализовывать в "толстом клиенте" не удобно. Ну да, можно взять какой-нибудь html-движок. И разницы между "страница в браузере" и "страница в толстом клиенте" уже не будет.
В толстых клиентах можно выполнять какие-то дополнительные операции врдое кэширования. Но, опять же, нужно изучать конкретные примеры. Может оказаться выгоднее держать "веб-сервер" с одним общим кэшем на всех, чем выдавать каждому клиенту его порцию данных, которые он потом закэширует.
Хотя есть одно неосопоримое преимущество у толстых клиентов по сравнению с веб. Это интеграция с инфраструктурой предприятия (active directory, outlook, прочие сервисы). Но в этом случае приложению, рассчитаному на работу в домене, облако никак не поможет.
IB>Да, это удешевлении при увеличении набора возможностей. Но в этом и заключается развитие технологий.
А вот с этим я не согласен. И лично я этого нигде не утверждал. Удешевление есть. Но там не "увеличение набора возможностей", а "другой баланс приоритетов в платформе" скорее всего. Т.е. что-то получаем, а что-то теряем. Другой набор компроммисов. В общем, в некоторых случаях может быть оправдано. Но это обычно ортогонально толщине клиента, который работает с данными.
Здравствуйте, igor-booch, Вы писали:
A>>Тут дело в том, что нужно менять подход к программированию, менять архитектуру толстого клиента, а это уже будет не толстый клиент. IB>Основная идея облачных технологий заключается в том, что код клиента абстрагирован от того где физически находится нужный сервис (БД). Код толстого клиента не зависит от того где находится БД в облаке или локальной сети. Меняется только конфигурация: connection string.
Нет, вы путаете. Такое абстрагирование делается относительно легко, и точно так же connection string меняется на "внешний адрес базы" вместо "внутреннего. Ну и к облакам оно отношения не имеет.
Идея у облаков другая. Состоит она в том, что вы можете покупать ресурсы более "гранулировано", чем раньше. Вот раньше можно было у хостера купить "хостинг на одной машине". Был фиксирован объем хранилища, выделяемая память, выделяемая машинная память и т.п. Использовали вы эту мощность или нет — цена от этого не зависела. Примерно то же самое, что вы подключаетесь к электричеству и платите только за подведенную мощность. Есть у вас 10Квт гарантированные, за них и платите. Не важно, не делали вы ничего, или постоянно жгли электричество на полную мощность. А в облаке основная схема оплаты другая. Облако обычно предполагает оплату "по счетчику". Использовали 1 гигатакт процесора, за него и платите. Использовали 3,6 мегаджоулей электричества — и платите только за них. Или просто гораздо лучшая гранулярность (для диска) и какой-то суммарный учет (по вычислительной мощности).
Очевидно, что архитектуры облаков имеет некоторые ограничения. Например, это может быть более низкая скорость отклика на изменение загрузки (т.е. пока вас с загруженного хоста куда-нибудь на посвободнее мигрируют). Так что если нам важна для ряда задач гарантированное время отклика, придется искать облако с соответствующим сервисом. Ну и просто под конец месяца у всего облака может не оказаться достаточно ресурсов (все бросились месячные отчеты считать). Требования к безопасности — вообще отдельная песня.
Так что к "виду" клиента это отношения не имеет. Облако можно использовать и на серверах, обслуживающих веб. И в отдельных клиентах (легких и толстых). Технически это все делается обычно легко — просто меняются настройки. Точно так же, как при реогранизации сети внутри предприятия. Разница в первую очередь в оплате ресурсов, а потом уже в технических моментах. И "легче" в технических моментах не будет, будет просто "по-другому"
Здравствуйте, igor-booch, Вы писали:
IB>CAP-теорема: не доказана.
Доказана. Правда, в несколько отличной от первоначальной фомулировке.
В таких вопросах русской вики доверия почти нет, нужно сразу смотреть английскую.
Здравствуйте, igor-booch, Вы писали:
IB>Время пинга это такая же техническая проблема. С ростом сети дата центров она решится. Так как чем больше дата центров, тем больше вероятность что рядом с Вами находится один из них. Это вопрос времени.
Пришли мыши к сове и спрашивают, как им от котов спастись. Сова говорит: "Станьте ежиками." Мыши радуются, празднуют, потом подумали, возвращаются к сове и спрашивают: "Сова, а как же нам ежиками стать, мы же мыши?" А Сова им: "Мое дело — стратегия!".
M>И "клиент" в этой интеграции — капля в море. Основная интеграция информационных систем выполняется на уровне "система-система". Девушка, сидящая в "банк-клинете" и сверяющая там проводки, все-таки не элемент интеграции предприятия с банком.
Ну так при интеграции двух систем одна из них может выступать в роли сервера, другая в роли клиента. Причем клиент в этом случае (при использовании облачных технологий) может быть толстым и распределенным. Если каждая из систем будет выступать и в роли клиента и роли сервера, получите двунаправленное взаимодействие.
M>А там web services/soap/rest/rpc/etc... Это, конечно, тоже "веб", но ни к тонким, ни к толстым клиентам отношения не имеет.
Сейчас да, а я говорю про перспективу и тенденцию развития технологий.
M>А "веб" сейчас часто используется по вполне прагматичным причинам. Веб-сервер обеспечивает дополнительный уровень проверок доступа (привелегий и т.п.). Отдать наружу логин с паролем к базе предприятия — это странное решение. Можно (и нужно все равно) рулить полномочиями в базе и т.п., но дополнительный уровень делает этот момент проще (хотя добавляет свои уязвимости).
Как это проще? Вы создаете дополнительный слой. На это требуются дополнительные трудозатраты: и капитальные и эксплуатационные. По моим наблюдениям в 80% проектов возможности конфигурирования безопасности БД используются лишь на 20%. Почему бы не использовать средства обеспечения безопасности БД на 100%? Зачем усложнять, если технологии позволяют обойтись без дополнительного слоя? Средства обеспечения безопасности БД постоянно совершенствуются, не зря же в это вкладывают деньги.
IB>>Раньше единственным средством создания распределенных клиентов был Web. M>Давайте определимся, что такое "распределенный клиент". Это много клиентов по всему миру? Ну да, это делалось (и будет делаться) через дополнительную прослойку между клиентом и базой.
А как же технический прогресс? Или Вы считаете, что существующие технологии и архитектуры это вершина эволюции и лучше уже не будет?
M>А обосновать? С моей личной точки зрения, как раз веб-разработка дешевле.
В web много кода пишется для обеспечения взаимодействия между клиентом (javascript) и сервером. В web вы вынуждены тратить время на создание и поддержку дополнительного слоя между клиентом и БД. Уточню что, чем богаче пользовательский интерфейс, чем дороже будет 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
M>В браузере очень хорошие механизмы layout'ов. Подобное реализовывать в "толстом клиенте" не удобно.
WPF, JavaFX
M>В толстых клиентах можно выполнять какие-то дополнительные операции врдое кэширования. Но, опять же, нужно изучать конкретные примеры. Может оказаться выгоднее держать "веб-сервер" с одним общим кэшем на всех, чем выдавать каждому клиенту его порцию данных, которые он потом закэширует.
Кэширование на клиенте было невыгодно, когда когда была дорогая память и вообще дорогое железо. Сейчас тенденция такова, что память дешевеет, быстродействие растет, а это делает резонным утолщение клиентов. Web был выгоден когда было дорогое железо. Сейчас Web не может на 100% использовать появившееся возможности увеличения быстродействия клиентов и многопоточность. А бизнес требует все более и более навороченный и в тоже время отзывчивый пользовательский интерфейс.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
M>Нет, вы путаете. Такое абстрагирование делается относительно легко, и точно так же connection string меняется на "внешний адрес базы" вместо "внутреннего. Ну и к облакам оно отношения не имеет.
Я же писал уже, в случае облачных технологий connection string не к одной удаленной БД, а распределенному хранилищу.
IB>Ваша БД и серверное ПО будет распределено по физическим дата центрам, таким образом чтобы снизить нагрузку на каналы связи. Но для Вас, то есть Вашего толсто клиента, будет видна одна БД и один сервер приложений. То есть единая логическая точка доступа на множество физических хостов.
Про остальное тоже писал.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
M>>Нет, вы путаете. Такое абстрагирование делается относительно легко, и точно так же connection string меняется на "внешний адрес базы" вместо "внутреннего. Ну и к облакам оно отношения не имеет.
IB>Я же писал уже, в случае облачных технологий connection string не к одной удаленной БД, а распределенному хранилищу.
Как это реализзовано, можно поинтересоваться? Свой собственный протокол или все же стандартное TCP/IP?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
On 29.04.2013 11:55, igor-booch wrote:
> M>Нет, вы путаете. Такое абстрагирование делается относительно легко, и > точно так же connection string меняется на "внешний адрес базы" вместо > "внутреннего. Ну и к облакам оно отношения не имеет. > > Я же писал уже, в случае облачных технологий connection string не к > одной удаленной БД, а распределенному хранилищу.
В чём отличие, с точки зрения приложения?
Т.е. с точки зрения DriverManager.getConnection(db_url)?
Ни в чем,
в этом то и цель облачных технологий, чтобы архитектура клиентов не зависла от того где расположены серверы (БД, приложений), хоть в локальной сети хоть в соседней стране.
Это глобализация.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
On 29.04.2013 13:00, igor-booch wrote:
> в этом то и цель облачных технологий, чтобы архитектура клиентов не > зависла от того где расположены серверы (БД, приложений), хоть в > локальной сети хоть в соседней стране.
С практической точки зрения — она не может от этого не зависеть ввиду
наличия латентности. Перенесите MS-SQL от вашего 1С в Амазон и вы
ощутите это сразу.
А с теоретической это всегда было так (если мы рассматриваем базы,
доступные по сетевым протоколам вроде TCP/IP).
H>С практической точки зрения — она не может от этого не зависеть ввиду H>наличия латентности.
По поводу латентность я уже высказывался в этом топике.
H>А с теоретической это всегда было так (если мы рассматриваем базы, H>доступные по сетевым протоколам вроде TCP/IP).
С теоретической точки зрения может и так, но с практической сейчас существует разные архитектуры: Web и настольные приложения.
По поводу БД доступных по сетевым протоколам TCP/IP я тоже уже высказывался.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, 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, но плохо).
Если Вы имеете ввиду 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.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
AK>Пришли мыши к сове и спрашивают, как им от котов спастись. Сова говорит: "Станьте ежиками." Мыши радуются, празднуют, потом подумали, возвращаются к сове и спрашивают: "Сова, а как же нам ежиками стать, мы же мыши?" А Сова им: "Мое дело — стратегия!".
Им нужна генная инженерия
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Если Вы имеете ввиду http://en.wikipedia.org/wiki/CAP_theorem, то IB>1) непонятно в рамках какой научной теории или хотя бы в рамках какой формальной модели доказана теорема (теорем без теорий не бывает)
Публикацию читал? Или это теперь не обязательно для предметного обсуждения?
W>Публикацию читал? Или это теперь не обязательно для предметного обсуждения?
Или давайте точные ссылки (url, или хотя бы название с авторами) на материалы, которые Вы хотите предметно обсудить. Я не должен догадываться какую публикацию Вы имеете ввиду.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Или давайте точные ссылки (url, или хотя бы название с авторами) на материалы, которые Вы хотите предметно обсудить. Я не должен догадываться какую публикацию Вы имеете ввиду.
Ссылка на публикацию — в английской Вики под номером 1. На это я и указал. Зачем догадываться, нужно просто посмотреть.
W>Ссылка на публикацию — в английской Вики под номером 1. На это я и указал. Зачем догадываться, нужно просто посмотреть.
В упор не вижу ни в одном из ваших предыдущих сообщений ссылки на публикацию под номером 1. Неужели сложно URL скопипастить?
Ну да ладно неважно. Буду полагать что вы имеете ввиду http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf
W>Предметно обсудить хочу не я.
Возникает вопрос: а что Вы тогда делаете в этой ветке?
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.
Thus the theorem doesn't rule out achieving consistency in a distributed system, and says nothing about cloud computing per se or about scalability.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
M>А при чем здесь облако? Каждый клиент видит другую систему как некоторый "удаленный URL". M>А при чем здесь облако? Основная масса клиентов как ходила по этим протоколам, так и будет ходить. M>А где здесь прогресс? Ну был один URL для доступа к базе, стал другой. M>Облако — коммерческая модель в первую очередь. M>Облака в первую очередь отличаются новым подходом к предоставлению (provisioning) различных вычислительных ресурсов.
По моему Вы сводите облачные технологии к виртуализации. Виртуализация это один из аспектов реализации облачных принципов.
M>А как вы это будете в толстом клиенте обрабатывать? Каждую работу с базой в try/catch оборачивать? Так их там тонны, этих запросов.
Точно также как Вы это делаете на web сервере средствами вашего языка программирования.
M>А многопоточность клиентам обычно не нужна. Что-то тяжелое считать — это редкий случай.
В простых системах наверное так и есть.
M>Есть отличная асинхронность. Без шуток — отличная.
Не понял. Где есть? Многопоточность это реализация ассинхронности.
M>А еще веб был выгоден, когда пользователи не хотели ставить всякие трояны на свои машины.
То есть городить дополнительные слои вместо того-что развивать антивирусное ПО? Каждый должен заниматься своим делом. Программисты должны сосредотачиваться на бизнес логике. Антивирусы ловить вирусы. Сетевики проектировать сети. И никто друг от друга зависеть не должен. В этом и есть прогресс, в разделении труда.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
M>Архитектуры разные потому, что платформа (целевой API) для настольных приложений (окна, активные области, ручная перерисовка) и для веб (tree document model, "active" components, system-controlled rendering, system event propagation, явная асинхронность) отличаются. Т.е. сначала "платформа", потом — архитектура.
А мне как разработчику хочется потратить больше времени на проработку бизнес логики и удовлетворение потребностей заказчика, а не на разбирательство отличий API и платформ. И конечному пользователю наплевать на платформу и каким API сделано ПО. У заказчика требования одни и не зависят от платформы и API и где находится БД и т.д. Чем больше времени разработчики будут тратить на непосредственные нужды заказчиков, и меньше времени тратить на всякие чисто технические или инфраструктурные моменты, тем выше будет производительность труда разработчиков. Повышение производительности труда является целью технического прогресса.
Не понимаю про ручную перерисовку в настольных приложениях и system-controlled rendering в веб.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
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>Ну и в качестве бонуса, вы все-таки ознакомились с первоисточником и вероятно почерпнули для себя что-то полезное.
Да, действительно, спасибо
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, maxkar, Вы писали:
M>Далеко не всегда "стандартные" контролы удобны (в чистом HTML сделать нестандартный контрол гораздо проще, чем во фреймоврках и десктопе). А если отбросить подход (мы все делаем как на десктопе) и использовать легковесные подходы, то все становится легко и просто. Кнопка — это не нечто громадное и сложно взаимодействующее по куче аспектов со всем приложением, а любой элемент, биндящийся к action, реагирующий на клик и умеющий поддерживать состояние "disabled".
Только в терминах десктопа это не "кнопка".
Вообще "веб" воспитал замечательных пользователей. Они смиренно ждут перересовки страницы(а то и рефреша), терпят глючный вырвиглазный UI, за который на десктопе закапывали за забором еще в начале 90-х и как откровение воспринимают вот такие "легковесные кнопки"... Ну а уж контекстное меню по правой кнопке или хоткеи(без возможности перенасройки, разумеется) — это вообще фантастика, "будущее уже здесь".
On 02.05.2013 12:13, Yoriсk wrote: > Ну а уж > контекстное меню по правой кнопке или хоткеи(без возможности > перенасройки, разумеется) — это вообще фантастика, "будущее уже здесь".
Вот неоднозначно это в вебе, с контекстным меню по правой кнопке. И
вроде можно туда много полезного вставить, и вроде "против технологии",
т.к. люди подсознательно ждут браузерного меню при right-click.
Здравствуйте, igor-booch, Вы писали:
M>>Облака в первую очередь отличаются новым подходом к предоставлению (provisioning) различных вычислительных ресурсов. IB>По моему Вы сводите облачные технологии к виртуализации. Виртуализация это один из аспектов реализации облачных принципов.
Виртуализация + распределенность. Одного из двух недостаточно. А вот все остальное, о чем вы пишете (балансировка нагрузки и т.п.) — это следствие этих двух решений. Применяется для того, чтобы сделать использование и программирование под данные системы удобнее. Например, избавиться от узких мест в вычислительной системе (балансировка нагрузки), обеспечить прозрачное обращение при переконфигурировании сети (виртуализация, единая точка доступа). Никто не запрещает часть из наработок использовать без облаков в соответствующей среде (например, распределенной). Я пока не вижу ничего, что не вытекало бы из первых двух предпосылок.
M>>А как вы это будете в толстом клиенте обрабатывать? Каждую работу с базой в try/catch оборачивать? Так их там тонны, этих запросов. IB>Точно также как Вы это делаете на web сервере средствами вашего языка программирования.
"Точно так же" не получится. На web-сервере есть очень удобная и естественная (в выбранной архитектуре) точка для обработки подобных ошибок — где-то недалеко от входа запроса и формирования ответа. Т.е. мы получили запрос, начали обработку. Если при обработке произошла ошибка, выдали соответствующее сообщение (там единицы типов ошибок всего). Концептуально схема выглядит (клиент <-> протокол <-> обработчик). Здесь протокол один, "клиентов" и обработчиков много. В толстом клиенте аналога протокола нет. Его можно вводить, что будет иметь свои ограничения (потеря типизации/реализация проксирования через рефлексию/куча ручного кода для обработки в промежуточном слое). Оно все при желании делается, но совсем не так, как на веб-сервере (где всего один фильтр добавляется).
M>>Есть отличная асинхронность. Без шуток — отличная. IB>Не понял. Где есть? Многопоточность это реализация ассинхронности.
Да. Многопоточность — реализация асинхронности. Но из асинхронности не следует возможность выполнения кода во многих потоках. С точки зрения UI-разработчика в JavaScript достаточно хороший Ajax API. Он по-умолчанию асинхронный, т.е. нельзя подвесить пользовательский интерфейс (чтобы он не перерисовывался) только потому, что мы медленно файлик читаем или база задумалась (хотя флажок все-таки есть, что плохо). Во flash еще лучше — там флажка "синхронно" вообще нет. Поэтому обработка асинхронная, а вот потоков нет (в последних версиях flashplayer правда что-то начало появляться).
M>>А еще веб был выгоден, когда пользователи не хотели ставить всякие трояны на свои машины. IB>То есть городить дополнительные слои вместо того-что развивать антивирусное ПО? Каждый должен заниматься своим делом. Программисты должны сосредотачиваться на бизнес логике. Антивирусы ловить вирусы. Сетевики проектировать сети. И никто друг от друга зависеть не должен. В этом и есть прогресс, в разделении труда.
Какие дополнительные слои? Слой есть, но для программы не слишком большой. "Трояны" — это в широком смысле, имелся в виду злонамеренный код в толстом клиенте. Какой-то распространенный вирус антивирусы найдут. А вот банк-клиента, который потихоньку ходит по вашему диску и что-то отправляет по своему протоколу — вряд ли. Против неизвестной угрозы как раз хорошо подходят песочницы, виртуализация и т.п. Но вот загнать в песочницу небольшой API (вроде javascript + html) все-таки проще, чем весь системный API. Хотя есть и варианты контроля приложений на уровне API системы (apparmor и что-то еще), но их можно дополнительно вместе с песочницой/виртуалкой использовать.
На чем должны сосредотачиваться программисты я совсем не знаю. Аспектов много. Это реализация бизнес-логики, юзабилити, реализация протоколов и среды обмены данными, обеспечение нужного быстродействия, достаточного уровня управления приложением (настройки, резервное копирование и т.п.), управление балансом между сроками/качеством/дальнейшей изменчивостью приложения. В общем, много всего. И в обозначенных областях разработчик (не программист, я не знаю, что такое "программист") должен неплохо ориентироваться. Может быть, еще и специализироваться в некоторых областях (но об остальных все равно нужно иметь представление). Ваш программист "бизнес-логики" либо может быть использован в качестве "аналитика" и на ранних фазах прототипирования (если ему интересно заниматься именно бизнес-логикой), либо в качестве банального кодера рутинных мест, которые пока еще лень автоматизировать (это если программисту уже ничего не интересно). А вот ряд других решений (в том числе — глобальные архитектурные) я бы ему не давал — ну не интересно такое ему. Я не оцениваю здесь "лучше/хуже", нужны и те, и другие. Только разные люди лучше подходят для разных задач.
А вот с "никто друг от друга зависеть не должен" я категорически не согласен. Должны зависеть! Иначе сетевики что-нибудь придумают, только это никому в ближайшие 20 лет будет все равно не нужно. Так что сетевеки должны знать нужны приложений. Разработчики ПО должны знать что-то по сетям, чтобы правильно ставить задачи, использовать текущие технологии и т.п. Еще все зависят от методологии управления проектом. И так далее. Это на конвеере можно не зависеть друг от друга, но в IT конвееры встречаются далеко не так часто. IT ближе к научно-технической разработке. Вы же не предложите проектировать автомобиль независимым специалистам по двигателям, трансмиссии, колесам и кузову? Они ведь должны друг с другом взаимодействовать, иначе вы просто не объедините их наработки в одну машину. Так и в IT, изоляция не получится, нужен диалог.
Здравствуйте, igor-booch, Вы писали:
M>>Архитектуры разные потому, что платформа (целевой API) для настольных приложений (окна, активные области, ручная перерисовка) и для веб (tree document model, "active" components, system-controlled rendering, system event propagation, явная асинхронность) отличаются. Т.е. сначала "платформа", потом — архитектура.
IB>А мне как разработчику хочется потратить больше времени на проработку бизнес логики и удовлетворение потребностей заказчика, а не на разбирательство отличий API и платформ. И конечному пользователю наплевать на платформу и каким API сделано ПО. У заказчика требования одни и не зависят от платформы и API и где находится БД и т.д. Чем больше времени разработчики будут тратить на непосредственные нужды заказчиков, и меньше времени тратить на всякие чисто технические или инфраструктурные моменты, тем выше будет производительность труда разработчиков. Повышение производительности труда является целью технического прогресса.
Инфраструктурные моменты упускать нельзя. И выбор инфраструктуры должен быть осознанным. Она очень сильно влияет на нефункциональные требования. Например, потом могут появиться новые типы клиентов (с планшетов/телефонов!). И в зависимости от выбранной архитектуры и технологий переход может быть как простым, так и очень сложным. Если есть достаточная уверенность в требованиях, что-то может не понадобиться, какие-то технологии могут быть применены или наборот исключены из рассмотрения. Те же приложения, где предполагаются разные типы клиентов (наше приложение и API для других приложений) я бы сразу делал на основе web. Обработчики для UI и API будут очень похожие (если не одни и те же) с небольшими различиями в форматах данных (если вообще будут такие различия). В стиле "толстый клиент" не совсем понятно, как такое делать.
Я в предыдущем сообщении ответил, примерно на какие области разработки я бы вас с вашими интересами поставил. А на технические моменты — других людей. Про инфраструктуру см. предыдущий абзац. Отбор API, языка и т.п. — тоже немаловажный фактор. Я в ближайшее время буду смотреть и собирать инфраструктуру для серверной части не на java, а на scala. Как оказалось, нужные для мена задачи там делаются в разы короче по коду, правда с небольшой потерей производительности результирующего кода. И это в данном случае осознанное решение. Мне нужна простота и скорость разработки кода (с возможностью переписать потом все обратно). Если бы я сосредотачивался на бизнес-логике, я бы не смотрел по сторонам и писал тонны кода на java.
IB>Не понимаю про ручную перерисовку в настольных приложениях и system-controlled rendering в веб.
В UI везде (где я знаю), есть paintComponent и его аналоги. Т.е. компонент сам знает, как он отрисовывается и мы можем переопределить это поведение. Плюс есть возможность вызвать перерисовку вручную, обновить layout и т.п. В веб такого нет — метод форсирования перерисовки компонента в его публичное API не входит.
Здравствуйте, Yoriсk, Вы писали:
Y>Здравствуйте, maxkar, Вы писали:
M>>Далеко не всегда "стандартные" контролы удобны (в чистом HTML сделать нестандартный контрол гораздо проще, чем во фреймоврках и десктопе). А если отбросить подход (мы все делаем как на десктопе) и использовать легковесные подходы, то все становится легко и просто. Кнопка — это не нечто громадное и сложно взаимодействующее по куче аспектов со всем приложением, а любой элемент, биндящийся к action, реагирующий на клик и умеющий поддерживать состояние "disabled".
Y>Только в терминах десктопа это не "кнопка".
А почему не кнопка? Я ведь не писал, как оно выглядит . А выглядит оно для пользователя так же, как десктопная кнопка. Бордюры/тени/градиенты/тексты/иконки/цвета и т.п. Так же реагирует на наведение/нажатие. Собственно, с точки зрения пользователя "кнопка" — это нечто "квадратное", на что можно нажать и выполнить действие. А вот внутри это может быть реалзовано через div, span, td, a и много чего еще. Кстати, гиперссылка — еще один вариант отображения Action. С точки зрения кода вполне взаимозаменяем с кнопками. Так что в коде мы вызываем метод "создать кнопку" и получаем на выходе Element (без конкретизации). Так что, да, это не та Button, что в desktop API, но вот пользователь разницы не видит (проверено, никто из пользователей на кнопки не жаловался а сделаны они через "легковесные" объекты).
Y>Вообще "веб" воспитал замечательных пользователей. Они смиренно ждут перересовки страницы(а то и рефреша), терпят глючный вырвиглазный UI, за который на десктопе закапывали за забором еще в начале 90-х и как откровение воспринимают вот такие "легковесные кнопки"... Ну а уж контекстное меню по правой кнопке или хоткеи(без возможности перенасройки, разумеется) — это вообще фантастика, "будущее уже здесь".
Пользователи вообще не видят разницы между кнопками. Они видят кнопку. Она выглядит как кнопка, ведет себя как кнопка, значит, это кнопка. А как она реализована внутри — это другое дело. Перерисовка страницы — аналог "белого прямоугольника окна", когда в UI-потоке приложение решило уйти в базу, а сети нет. В браузере хотя бы закрыть страницу можно, а приложение еще и не сразу убъется (потому что UI события не обрабатывает). Глючность и вырвиглазность можно где угодно сделать. В десктопе сложнее делать "сложное" состояние экрана (нет нормальных реактивных биндингов к модели), в веб — сложнее сделать простые кирпичики, но с использованием удобных биндингов (динамика javascript и т.п.) сложные стурктуры управления собираются проще. Контекстное меню — спорный вопрос (я в вебе его не люблю). Хоткеи деляются примерно одинаково что на десктопе, что в вебе. Было бы желание. Кстати, на десктопе вполне бывает ужасно убогий таб-ордер. В общем, если заниматься аспектами, в веб тоже можно все сделать и много усилий это не потребует. Вот порог вхождения в web вроде бы ниже, поэтому и больше всевозможного отстоя вылезает. А пользователи терпели, терпят и будут терпеть до тех пор, пока приложение выполняет нужные для них (или их работодателей) функции
M>А пользователи терпели, терпят и будут терпеть до тех пор, пока приложение выполняет нужные для них (или их работодателей) функции
Паровые двигатели тоже терпели, пока не появились электродвигатели
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
M>Виртуализация + распределенность. Одного из двух недостаточно.
Недостаточно для чего? Почему не может быть распределенности без виртуализации? Например, распределенные тонкие клиенты web: всё без виртуализации обходится. И виртуализация без распределенности может быть, если о сервере знает только один клиент, а сервер работает в виртуальной среде. Например, клиентом является веб приложение, а сервером база данных, работающая в виртуальной среде.
M>Никто не запрещает часть из наработок использовать без облаков в соответствующей среде (например, распределенной).
Никто не запрещает, не спорю. И что тогда значит "без облаков"? Что тогда Вы подразумеваете под облаками?
M>Применяется для того, чтобы сделать использование и программирование под данные системы удобнее.
Какие системы?
M>Я пока не вижу ничего, что не вытекало бы из первых двух предпосылок.
Вы хотите сказать что я вижу что-то вытекающее? Я даже пока не понял каких предпосылок и что может вытекать.
M>"Точно так же" не получится. На web-сервере есть очень удобная и естественная (в выбранной архитектуре) точка для обработки подобных ошибок — где-то недалеко от входа запроса и формирования ответа. Т.е. мы получили запрос, начали обработку. Если при обработке произошла ошибка, выдали соответствующее сообщение (там единицы типов ошибок всего).
Неужели вы считаете, что в ООП нет приемлемых средств и приемов для обработки ошибок и лорнирования (в т. ч. логирования на удаленный сервер)? Да в любом нормальном языке программирования есть.
M>Какие дополнительные слои? Серверный слой, который необходим для работы тонких клиентов (web)
М>Какой-то распространенный вирус антивирусы найдут. Да да аньтивирусы отстой. Даешь всем веб — универсальную защиту от вирусов.
М>Против неизвестной угрозы как раз хорошо подходят песочницы, виртуализация и т.п.
Песочницы это разовое решение чтобы запустить кейген, например. Строить на них технологию и архитектуру, это все равно, что всех солдат заставить постоянно носить противогазы, так на всякий случай.
М>"Трояны" — это в широком смысле, имелся в виду злонамеренный код в толстом клиенте.
Код толстого клиента можно защитить от модификации путем обфускации, электронной подписи и т. д.
M>Ваш программист "бизнес-логики" либо может быть использован в качестве "аналитика" и на ранних фазах прототипирования (если ему интересно заниматься именно бизнес-логикой), либо в качестве банального кодера рутинных мест, которые пока еще лень автоматизировать (это если программисту уже ничего не интересно).
Программист бизнес логики может быть использован для программирования бизнес логики.
M>А вот с "никто друг от друга зависеть не должен" я категорически не согласен. Должны зависеть!
Все борются за loose coupling и Single Responsibility Principle, а Вы такое говорите.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
M>Инфраструктурные моменты упускать нельзя. И выбор инфраструктуры должен быть осознанным.
Вот для того чтобы меньше времени тратить на инфраструктурные моменты и направлены облачные технологии. Инфраструктура нужна разработчику, что реализовать бизнес требования. Конечному заказчику нужна только реализация бизнес требований и не важно какой инфраструктурой это будет достигнуто.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Aikin, Вы писали:
A>Что распределять если у меня строго императивный код, который на 1 открытие формы использует 5-10 запросов к серверу, который находится, дай бог, в той же стране что и я (а скорее всего где-нить в голандии или, супер, в москве)? Если пинг до сервера у нас, скажем 20mc (сравни с <1mc для локалки), то только на то чтобы достучаться к серверу у нас уйдет 5*20-10*20mc=100mc-200mc. А теперь добавь сюда расходы на соединение и передачу данных, будет хз сколько, но не меньше 300mc. Добавь сюда тяжелые запросы, которые мы любим писать. Твои пользователи готовы работать с приложением, которое будет работать на 0,1-0,3 сек медленней, чем если бы оно работало в той же сети? А для чего? Только для того, чтобы руководство отчиталось, что мы используем олачные технологии?
Реально разница может быть в секунды а иногда даже и десятки секунд.
Здравствуйте, igor-booch, Вы писали:
IB>Время пинга это такая же техническая проблема. С ростом сети дата центров она решится. Так как чем больше дата центров, тем больше вероятность что рядом с Вами находится один из них. Это вопрос времени.
CAP теорема говорит о том, что рост сети датацентров никак не решит эту проблему. Вместо большого пинга будут или временные отказы или невалидные данные или что нибудь еще.
I>CAP теорема говорит о том, что рост сети датацентров никак не решит эту проблему. Вместо большого пинга будут или временные отказы или невалидные данные или что нибудь еще.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
M>>Виртуализация + распределенность. Одного из двух недостаточно. IB>Недостаточно для чего?
Для облаков. Иначе это, скорее всего, будет не облако.
IB>Почему не может быть распределенности без виртуализации?
Да может прекрасно, это я знаю.
M>>Никто не запрещает часть из наработок использовать без облаков в соответствующей среде (например, распределенной). IB>Никто не запрещает, не спорю. И что тогда значит "без облаков"? Что тогда Вы подразумеваете под облаками?
Под облаками я понимаю "распределенную виртуализованную среду". Если есть другое определение — давайте, я ничего лучше пока придумать не могу. Все остальное — не облака. В связи с этим и вопрос, почему вы что-то в первых постах называете преимуществом облаков? Это может быть развитием виртуализации и ее преимуществом. Единственное, для чего необходимо оба этих фактора — способы оплаты ресурсов. Все остальное что я вижу, вытекает только из одного из этих факторов. Поэтому преимуществом облаков являться не может (может быть использовано и без облаков при наличии соответствующего условия).
M>>Применяется для того, чтобы сделать использование и программирование под данные системы удобнее. IB>Какие системы?
Те, для которых было принято решение "платить только за потребленные ресурсы". Для других систем я не вижу никаких преимуществ облаков. Можно, например, построить распределенную систему со всеми "улучшалками распределенности" из облаков.
M>>Я пока не вижу ничего, что не вытекало бы из первых двух предпосылок. IB>Вы хотите сказать что я вижу что-то вытекающее? Я даже пока не понял каких предпосылок и что может вытекать.
Из начальных ограничений на среду (виртуализация, распределенности). Они приносят некоторые неудобства по сравнению с системами без них (на одной физической машине). Все описанные вами "преимущества" — способ борьбы с неудобствами (чтобы не нужно было сервера вручную искать, переключаться под нагрузкой и т.п.). Поэтому "преимущества" имеет смысл рассматривать только в определенном контексте. Потому что иначе не понятно, чем же именно лучше облака, чем распределенные системы без виртуализации.
M>>"Точно так же" не получится. На web-сервере есть очень удобная и естественная (в выбранной архитектуре) точка для обработки подобных ошибок — где-то недалеко от входа запроса и формирования ответа. Т.е. мы получили запрос, начали обработку. Если при обработке произошла ошибка, выдали соответствующее сообщение (там единицы типов ошибок всего). IB>Неужели вы считаете, что в ООП нет приемлемых средств и приемов для обработки ошибок и лорнирования (в т. ч. логирования на удаленный сервер)? Да в любом нормальном языке программирования есть.
В каком именно ООП? В java и javascript оно очень сильно разное... И проблема даже не в ООП. Проблема в строгой типизации, неудобной динамике, отсутствию некоторых сущностей как first-class (т.е. невозможностью ими просто оперировать в runtime). Некоторые от безисходности предлагают AOP (да, да, для обработки ошибок, а также для логирования и security — это все фильтрами на границе системы делается!).
Если вы считаете, что в ООП есть средства, то как вы предлагаете решать простейшую задачу. Есть десяток различных сервисов в приложении, работающих с базой данных (ну там справочники предметов, пользователей, логи всякие и операции). Ну и работа с ними идет на десятке экранов. Для определенности будем только 10 кнопочек рассматривать, которые данные сохраняют. И вот при нажатии любой из этих 10 кнопочек может произойти ошибка доступа к базе (выключена/обслуживается). Нужно обработать эту ошибку (и только эту!), показать пользователю окошечко и предложить ему повторить опреацию. Вопрос — сколько (и какого) кода нужно написать для решения этой проблемы? Писать 10 оберток (по одной для каждого менеджера) не хочется. Писать 10 однотипных try/catch в кнопке — тоже не хочется. Если предложите приемлемое решение, я его утащу для кэширующих оберток сервисов (там очень похожая проблема, а вот с запросами то проблем нет ).
M>>Какие дополнительные слои? IB> Серверный слой, который необходим для работы тонких клиентов (web)
Он небольшой и очень полезный. Пропускает макароны зависимостей через мясорубку и на выходе получаются те же макароны, но "параллельные" (несвязные друг с другом ). Плюс много чего туда навесить можно, что иначе по-отдельности к куче сервисов прикручивать нужно.
М>>"Трояны" — это в широком смысле, имелся в виду злонамеренный код в толстом клиенте. IB>Код толстого клиента можно защитить от модификации путем обфускации, электронной подписи и т. д.
Мы не поняли друг друга. Я никогда не предлагал защищать толстого клиента от пользователя. Я предлагал защищать пользователя от толстого клиента! Причем не от "случайно заразившегося" толстого клиента, а злонамеренного толстого клиента. Веб от этого полностью не защищает, но возможности украть (или просто нагадить) в нем пока меньше и за возможными уязвимостями "песочницы" следить как раз лучше. Я не вижу, зачем большинству приложений полный доступ к (пользовательской) системе. Им как раз вполне хватит своих песочниц. Хотя некоторым "толстым клиентам" требуется плотная интеграция с клиентской средой (да, есть такое иногда), но в этом случае облака не помогут — нужна специальная настройка клиентской машины.
M>>Ваш программист "бизнес-логики" либо может быть использован в качестве "аналитика" и на ранних фазах прототипирования (если ему интересно заниматься именно бизнес-логикой), либо в качестве банального кодера рутинных мест, которые пока еще лень автоматизировать (это если программисту уже ничего не интересно). IB>Программист бизнес логики может быть использован для программирования бизнес логики.
Но не для определения архитектуры! Так что все будут счастливы. Кстати, а что такое "бизнес-логика". Вывод формочек — это бизнес-логика? А учет пользовательских сценариев для рисования и проектирования этих формочек?
M>>А вот с "никто друг от друга зависеть не должен" я категорически не согласен. Должны зависеть! IB>Все борются за loose coupling и Single Responsibility Principle, а Вы такое говорите.
Все нормально я говорю. SRP не отменяет environment awareness (возможность знания о среде выполнения). Т.е. какой-то объект выполняет определенную обязанность, при этом учитывает, в каком контексте он работает (т.е. что-то выполняется лучше, что-то хуже). Также нельзя не учитывать, что программы разработкой и дизайном не занимаются, там конвеер работает (с соответствующими ограничениями). А еще loose coupling и SRP относятся в первую очередь к интерфейсу класса. Я вполне нормально отношусь к классу, который реализует сразу 5 интерфейсов, но раздается пользователям как реализация только одного из интерфейсов. Бывают причины, когда несколько обязанностей из-за соображений эффективности приходится сочетать в одном лице. Только при этом другие не должны закладываться на такую возможность (кроме директора, который процесс организует).
M>Под облаками я понимаю "распределенную виртуализованную среду".
С этим определением согласен.
M>В связи с этим и вопрос, почему вы что-то в первых постах называете преимуществом облаков? Единственное, для чего необходимо оба этих фактора — способы оплаты ресурсов. M>Те, для которых было принято решение "платить только за потребленные ресурсы". Для других систем я не вижу никаких преимуществ облаков.
Как-то слабо верится, что облачные технологии предназначены только для удобства оплаты. Еще не верится, что существующие архитектуры и технологии распределенных систем это вершина эволюции и дальше стремиться не к чему. По Вашим словам получается именно так.
M>Все остальное что я вижу, вытекает только из одного из этих факторов. Поэтому преимуществом облаков являться не может (может быть использовано и без облаков при наличии соответствующего условия).
А я вижу: виртуализация + распределенность = распределенные толстые клиенты. (Предположу, что под факторами Вы понимаете виртуализацию и распределенность). Прорывы в науке и технологиях получаются, когда несколько наук или технологий соединяются вместе.
М>Проблема в строгой типизации
Для сложных систем это не проблема, а преимущество. Строгая типизация позволяет больше ошибок отловить при компиляции, и не пустить их в runtime. Может чтобы быстро накропать простое приложение-скрипт какому-нибудь веб дизайнеру, строгая типизация будет балластом.
M>Если вы считаете, что в ООП есть средства, то как вы предлагаете решать простейшую задачу. M>Некоторые от безисходности предлагают AOP (да, да, для обработки ошибок, а также для логирования и security — это все фильтрами на границе системы делается!).
Здесь два решения: либо Вы можете использовать возможности функционального программирования. Например на C#:
public static Result ExecuteDbAction(this Action action)
{
try
{
action()
}
catch...
}
и потом любую операцию с БД выполняете так:
(() => SaveUser(...)).ExecuteDbAction();
либо имитируйте Ваши системы и их границы через классы:
public class ActionExecutor
{
private Dictionary<string, Action<IEnumerable<object>> _actions;
public Result Execute(string actionName, paramas object[] arguments)
{
// делайте все ваши проверки доступности БДtry
{
_actions[actionName](arguments);
}
catch...
}
}
ActionExecutor.Execute("SaveUser", ...);
В этом случае мы теряем строгую типизацию.
IB>> Серверный слой, который необходим для работы тонких клиентов (web) M>Он небольшой и очень полезный. Пропускает макароны зависимостей через мясорубку и на выходе получаются те же макароны, но "параллельные" (несвязные друг с другом ). Плюс много чего туда навесить можно, что иначе по-отдельности к куче сервисов прикручивать нужно.
Все можно сделать через классы, функциональное программирование и т. д. Все будет на одном языке, в одном процессе ОС, строго типизированно и в некоторых местах декларативно. Кстати движение от императивности к декларативности тоже тенденция развития программирования.
M>Мы не поняли друг друга. Я никогда не предлагал защищать толстого клиента от пользователя. Я предлагал защищать пользователя от толстого клиента!
Не понимаю что значит защищать толстого клиента от пользователя в Ваших словах. Толстый клиент это что такое же живое существо как и пользователь? Защищать толстого клиента нужно в смысле того чтобы в него нельзя было внедрить посторонний код. Но в конечном итоге это делается для защиты пользователя и его данных.
M>Я не вижу, зачем большинству приложений полный доступ к (пользовательской) системе. Им как раз вполне хватит своих песочниц. Хотя некоторым "толстым клиентам" требуется плотная интеграция с клиентской средой (да, есть такое иногда), но в этом случае облака не помогут — нужна специальная настройка клиентской машины.
Я тоже не вижу, только достигнуть неполного доступа можно без песочниц, а за счет систем безопасности самой ОС. В этом случае настройка безопасности может более тонкой, чем в случае использования песочниц. Песочницы это тяжелая артилерия.
IB>>Программист бизнес логики может быть использован для программирования бизнес логики. M>Но не для определения архитектуры! Так что все будут счастливы. Кстати, а что такое "бизнес-логика". Вывод формочек — это бизнес-логика? А учет пользовательских сценариев для рисования и проектирования этих формочек?
Конечно от чисто технологических и инфраструктурных моментов полностью на 100% не абстрагироваться. Но тенденция развития технологий программирования на лицо: все большее отделение бизнес логики от технологических моментов: C++ -> C#. И ООП для этого и создан, чтобы абстрагировать бизнес логику от её технической реализации. То есть наружу у класса только то, что необходимо для реализации бизнес логики, а внутри инкапсулированы все технологические и инфраструктурные моменты. И облачные технологии это шаг в этом направлении.
M>>>А вот с "никто друг от друга зависеть не должен" я категорически не согласен. Должны зависеть! IB>>Все борются за loose coupling и Single Responsibility Principle, а Вы такое говорите. M>Т.е. какой-то объект выполняет определенную обязанность, при этом учитывает, в каком контексте он работает (т.е. что-то выполняется лучше, что-то хуже).
Класс выполняет определенную обязанность. Знания этой обязанности вполне достаточно для проектирования класса. Зачем еще контекст вызова класса? Если контекст требует от класса тех обязанностей, для выполнения которых класс не предназначен, значит виноват контекст, а не класс.
Сетевая модель OSI: каждый слой выполняет определенные функции и слои друг от друга не зависят. На этом построен интернет.
В бизнес приложении можно также выделить два уровня: инфраструктурный и прикладной. Инфраструктурный отвечает за то будет ли клиент распределенным или локальным. Прикладной это бизнес логика. В web эти уровни смешаны или жестко связаны. Облачные технологии позволят разделить эти уровни и сделать их независимыми.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
M>>В связи с этим и вопрос, почему вы что-то в первых постах называете преимуществом облаков? Единственное, для чего необходимо оба этих фактора — способы оплаты ресурсов. M>>Те, для которых было принято решение "платить только за потребленные ресурсы". Для других систем я не вижу никаких преимуществ облаков. IB>Как-то слабо верится, что облачные технологии предназначены только для удобства оплаты. Еще не верится, что существующие архитектуры и технологии распределенных систем это вершина эволюции и дальше стремиться не к чему. По Вашим словам получается именно так.
А для чего еще предназначены облачные технологии? Точнее, "не для чего предназначены", а "какие основные преимущества по сравнению с отказом от виртуализации/распределенности". Я пока ничего другого не вижу. Та же "балансировка нагрузки" — следствия распределенности, например (хотя виртуализация добавляет небольшие мелочи). А прогресс будет, но, скорее всего, без революций. Потихоньку, маленькими шагами. Вот в облаках сделали интересные provisioning (и только его), потом что-то еще сделают. А удобный provisioning стал возможен потому, что развиваются load balancing (распределенная среда!), архитектура приложений (конфигурируемая точка доступа к базе данных в приложении) и т.п. Понятно, что облака тоже тянут вперед соответствующие области, но ничего уникального в них не предлагают.
M>>Все остальное что я вижу, вытекает только из одного из этих факторов. Поэтому преимуществом облаков являться не может (может быть использовано и без облаков при наличии соответствующего условия). IB>А я вижу: виртуализация + распределенность = распределенные толстые клиенты.
А кто такой "распределенный толстый клиент"? Это то, что выполняется в облаке и является толстым клиентом? Тогда к ней нужна виртуализованная распределенная ОС + нормальный доступ к этой ОС с клиентского компьютера. Вот это будет интересным вариантом. Тогда толстый клиент не будет иметь доступа к компьютеру пользователя (ура, песочница!). Но, опять же, это не будет революция. Это будет эволюция определенных сценариев.
М>>Проблема в строгой типизации IB>Для сложных систем это не проблема, а преимущество. Строгая типизация позволяет больше ошибок отловить при компиляции, и не пустить их в runtime.
Ну... Как сказать. Часто получается так, что проще (и меньше времени требутеся) запустить приложение, поймать ошибку и исправить ее, чем глобально (по всей программе!) доказывать невозможность этой ошибки. Примерно про это дискуссия есть в философии программирования. И вообще, я хочу локальные системы типов. Где нужно — использую строгую типизацию. Где не нужно — слабую. Банальнейший пример, где рулит слабая типизация — способ сделать из функции функцию с кэшированием. Javascript:
function cacheFunction(cache, func) {
return function() {
var guess = cache.get(arguments);
if (guess != null)
return guess;
var res = func.apply(null, toArray(arguments));
cache.put(arguments, res);
return res;
}
}
Хотя вру. Есть здесь строгая типизация (я могу типы всего указать). Только вот ни одна распространненая система типов не позволяет правильно записать тип функции cacheFunction. А у меня с подобными фокусами еще реактивное программирование и комбинаторы асинхронных блоков. Так что пока типизация не станет мощной, в некоторых задачах удобнее слабая типизация.
M>>Если вы считаете, что в ООП есть средства, то как вы предлагаете решать простейшую задачу. IB>Здесь два решения: либо Вы можете использовать возможности функционального программирования. Например на C#:
Это немного перебор у вас. Можно проще (scala).
trait ErrorContext {
def execute[T](action: () => T) : T
}
class AppErrorContext extends ErrorContenxt {
def execute[T](action: () => T) : T {
try {
action()
} catch {
...
}
}
}
// client:
val res = errCtx.execute({
...
})
Минусы:
* этот ErrorContext нужно по всем классам с собой таскать (или как-то еще иметь к нему доступ). В ErrorContext тоже ссылки на части приложения (ui manager, etc...), методом он быть не может.
* По всем местам использования базы нужно будет писать этот код errCtx.execute... Это мне не нравится. Действие вполне обычное и очень частое. Хотелось бы все-таки автоматически все это делать. Да и тестировать не очень интересно — зависимостей больше, типы ошибок включают еще и инфраструктурные.
Хотя все равно спасибо. Может быть, где-нибудь в простеньком клиенет и этот подход использую.
IB>либо имитируйте Ваши системы и их границы через классы: IB>В этом случае мы теряем строгую типизацию.
Зато приобретаем:
* Вы бесплатно получили толстый клиент, а также "средний" клиент и сервер. Вот из ActionExecutor можно вполне естественным образом выделить интерфейс. Одна из реализаций — то, что вы показали. Вторая — ходит на удаленный сервер и получает оттуда данные. Третья — делегирует вызовы другому ActionExecutor и обрабатывать часть ошибок. Можно еще простенький "клиент" написать, который получает запросы от второго ActionExecutor, расшифровывает их и передает своему. В общем, с точностью до используемого языка веб-клиент получился . Кстати, примерно такой подход у меня во всех удаленных клиентах и используется — служба одна, клиентов много. Аргументы, правда, по имени передаются (а не позиционно), но это небольшое отличие. Почти вся "инфраструктура" уже давным давно написана. Останется написать небольшие биндинги (на то, как именно вы сериализуете/десериализуете данные и как адресуете службы).
* С этим ActionExecutor можно выполнять "высокоуровневые" операции. Написать фильтр, который разрешает только некоторые операции. Переопределить некоторые "action" и т.п.
* ActionExecutor — очень удобный механизм протаскивать зависимости частей приложения от других частей/компонентов. Теперь вместо строго типизированных интерфейсов под каждую часть (и их реализаций) передается один ActionExecutor. С использованием предыдущего пункта, можно все необходимые фильтры навесить, чтобы компонент не занимался несвойственной ему функциональностью.
* Теперь легко можно заменять реализацию Action. Раньше они ходили в базу, теперь могут использовать другие сервисы для выполнения своей работы.
Там может, ну ее, эту строгую типизацию? Ошибку в имени сервиса/типах аргументов мы увидим при первом же тестировании (при написании/изменении). Исправить ее — одна/две минуты. Строго типизированный вариант потребует разных интерфейсов для разных aciton, в результате лишние интерфейсы выльются в те же минуты.
IB>>> Серверный слой, который необходим для работы тонких клиентов (web) M>>Он небольшой и очень полезный. Пропускает макароны зависимостей через мясорубку и на выходе получаются те же макароны, но "параллельные" (несвязные друг с другом ). Плюс много чего туда навесить можно, что иначе по-отдельности к куче сервисов прикручивать нужно. IB>Все можно сделать через классы, функциональное программирование и т. д.
Можно. А при чем здесь "серверный слой"? Он ведь тоже через те же классы делается. Собственно, во втором примере вы уже почти все сделали. Можно на "клиент/сервер" делить не сразу, а только после того, как появится необходимость (благо при выбранном подходе это очень просто). И ведь разница между "толстым клиентом" и "сервис-ориентированным клиентом" только в коде инициализации приложения (создании правильных сервисов). Т.е. совершенно не задумываясь "о распределенности приложения" у вас получилась такая архитектура, в которой распределенность делается очень легко.
IB>Кстати движение от императивности к декларативности тоже тенденция развития программирования.
Это да. И на этом пути тоже встает типизация
var buttonEnabled : ReactiveValue = Reactive.apply(isButtonEnabled, [condition1, condition2, condition3])
var loadingProcess : ReactiveValue = Async.applyAsync(startFinalLoading, [prerequisite1, "doFinalLoading"])
var myFunction = Caches.caching(myFuncitonImpl)
myFunction(1,2,3)
Первые два — реальные примеры. Кэширование — полезный, но выдуманный. Количество типов и массивах и их типы совместимы с соответствующими функциями перед ними. Тип Reactive.apply и Async.applyAsync — строгий, но в рамках текущих систем типов не выразимый (он требует "совместимости" типов первого аргумента и элементов второго).
Кстати, декларативность никак разделению на клиент/сервер не мешает. Возможно, даже и помогает.
IB>Я тоже не вижу, только достигнуть неполного доступа можно без песочниц, а за счет систем безопасности самой ОС. В этом случае настройка безопасности может более тонкой, чем в случае использования песочниц.
Ну да, это наилучший вариант. Но при этом для большинства приложений настройка будет выглядеть так: "приложение выполняется в полной изоляции от остальных, доступ дан в веб по адресам ... и каталогу XYZ". Не "разрешить все, потом ограничить", а наоборот. Вот "наоборот" далеко не везде исползьуется.
IB>>>Программист бизнес логики может быть использован для программирования бизнес логики. M>>Но не для определения архитектуры! Так что все будут счастливы. Кстати, а что такое "бизнес-логика". Вывод формочек — это бизнес-логика? А учет пользовательских сценариев для рисования и проектирования этих формочек? IB>Конечно от чисто технологических и инфраструктурных моментов полностью на 100% не абстрагироваться. Но тенденция развития технологий программирования на лицо: все большее отделение бизнес логики от технологических моментов: C++ -> C#.
На самом деле очень много вещей можно сделать и без поддержки языка. Только на архитектуре (см. опять ваш второй пример). Хотя некоторые вещи (вроде сборки мусора) без поддержки языка делаются действительно плохо.
IB>И ООП для этого и создан, чтобы абстрагировать бизнес логику от её технической реализации.
Не для этого он создан. Он создан для моделирования систем из взаимодействующих объектов. Да, с его помощью можно абстрагировать логику от технической реализации. Но точно так же ее можно абстрагировать при наличии любого вида полиморфизма (те же указатели на функцию в C)/
IB>То есть наружу у класса только то, что необходимо для реализации бизнес логики, а внутри инкапсулированы все технологические и инфраструктурные моменты. И облачные технологии это шаг в этом направлении.
Не, это неправильная архитектура. В правильной архитектуре бизнес-логика инкапсулирована в одни классы, инфраструктура — в другие. Классы бизнес-логики пользуются классами инфраструктуры через некоторые интерфейсы. Поэтому без особых проблем я могу заменить "инфраструктуру" на любую другую, изменив очень мало кода в приложении. Это все — правильная архитектура приложения, в которой учитывается возможность изменения некоторых инфраструктурных моментов. При чем здесь облака — пока еще не понятно. Что они делают проще? Чем проще написать ActionExecutor, который ходит в облако, чем тот, который ходит на наш веб-сервер? Так что не вижу я существенных достоинств с технической точки зрения. Инфраструктура как инфраструктура, чем-то лучше "классического веб", чем-то хуже.
M>>>>А вот с "никто друг от друга зависеть не должен" я категорически не согласен. Должны зависеть! IB>>>Все борются за loose coupling и Single Responsibility Principle, а Вы такое говорите. M>>Т.е. какой-то объект выполняет определенную обязанность, при этом учитывает, в каком контексте он работает (т.е. что-то выполняется лучше, что-то хуже). IB>Класс выполняет определенную обязанность. Знания этой обязанности вполне достаточно для проектирования класса. Зачем еще контекст вызова класса? Если контекст требует от класса тех обязанностей, для выполнения которых класс не предназначен, значит виноват контекст, а не класс.
Ну вот простой пример. Обязанность класса — передача данных с клиенту серверу. Сразу будете реализовывать? Или все-таки попытаетесь узнать, что именно передает клиент? Это могут быть данные для сохранения в базу, и тогда нужно брать протокол TCP (или даже высокоуровневый HTTP). Это могут быть какие-то несущественные данные для мониторинга/быстро меняющиеся и устаревающие данные (вроде игр), и тогда можно взять протокол UDP. А может, клиент передает видео с веб-камеры и тогда имеет смысл смотреть на потоковые протоколы?
А вообще, есть разные типы "обязанностей":
* Класс является библиотечным и предоставляет некоторые функции. В этом случае SRP полезен (в определенных пределах, фанатизм может привести к неудобству использования библиотеки).
* Обязанность необходима для работы другого компонента и выражена в виде интерфейса (потом она инжектируется в нужный объект). В этом случае из соображений эффективности один класс может реализовывать несколько интерфейсов. При этом сам класс будет видеть только код инициализации прилжоения, все остальные будут работать через интерфейсы. На уровне интерфейсов SRP выполняется, на уровне класса — может нарушаться.
* Класс является "контроллером верхнего уровня". Это всякие формочки и т.п. Основная его задача — связь кучи различных простых компонентов в один большой экран. Там внутри бывает много всего (и доступ к другим сервисам, и инфраструктурная инициализация, и обработка событий кнопочек). И выполнение SRP будет зависет от того, как именно определить ответственность этого класса. А дробить его на "много мелких классов" смысла нет — все равно он используется только в одном месте и вообще может быть переписан на процедурный код с замыканиями.
IB>Сетевая модель OSI: каждый слой выполняет определенные функции и слои друг от друга не зависят. На этом построен интернет.
Которая семиуровневая? Так она как раз и не используется. Используется четырехуровневая TCP/IP модель. Можете посмотреть на http://en.wikipedia.org/wiki/Transport_layer . Очень интересная картина. Вот взять тот же IGMP. Это internet layer. Тот же, на котором живут IPv4/IPv6. Вас не смущает, что этот протокол очень хорошо знает, для какой цели обычно используется? Вот я плохо представляют UDP over IGMP. Ну и назначение различных транспортных протоколов вроде TCP/UDP/SCTP/RSVP можете посмотреть. Два последних под вполне определенные задачи из Application layer делались (передача мультимедиа). В общем, та еще специализация.
IB>В бизнес приложении можно также выделить два уровня: инфраструктурный и прикладной. Инфраструктурный отвечает за то будет ли клиент распределенным или локальным.
Почему? Вот ваш второй пример показывает, что инфраструктурный момент за это не отвечает. Очень просто сделать из локального клиента распределенный, заменив немного кода. Определяющим здесь является не это. Определяющим является выбор технологии для UI (браузер/родная платформа/что-нибудь платформо-независимое вроде qt). Вот если в браузер подтащить драйвера для доступа к базе данных (заставить в нем работать node.js), то точно так же весь клиент будет выполняться "в веб".
IB>Прикладной это бизнес логика. В web эти уровни смешаны или жестко связаны. Облачные технологии позволят разделить эти уровни и сделать их независимыми.
Вы так и не ответили, что такое "бизнес-логика". Это формочки? Или это доступ к базе данных? Но ведь хранение данных — это тоже инфраструктурный момент. При этом я не вижу, где же в веб эти уровни связаны:
* Уровень UI рисует формочки. При необходимости вызывает ActionExecutor с нужными параметрами. Да, сейчас обычно этот ActionExecutor идет на сервер, но в целом это не обязательно.
* Ниже ActionExecutor все обработчики обрабатывают запросы с конкретными параметрами. Пришел ли запрос по сети или из того же приложения — разницы нет.
В общем, если я делаю "native client", то без проблем сделаю его как со всей логикой на нем (LocalActionExecutor), так и с логикой на сервере (RemoteActionExecutor). И облака мне здесь не нужны. Если же речь идет о "приложении в браузере", то облака здесь просто не помогут — как были ограничения браузер (вроде отсутствия библиотек доступа к базе данных), так их и не будет. Будет "сервер в облаке" (чем он отличается от моего сервера с точки зрения программирования — совершенно не ясно). А если вдруг появятся нужные библиотеки, то я точно так же смогу их использовать и без облаков.
M>Здравствуйте, igor-booch, Вы писали: M>А для чего еще предназначены облачные технологии? Точнее, "не для чего предназначены", а "какие основные преимущества по сравнению с отказом от виртуализации/распределенности". Я пока ничего другого не вижу.
Да я уже понял давно, что Вы не видите. Говорить "я не вижу" не конструктивно. Вы скажите конкретно почему Вы считаете невозможными распределенные толстые клиента через облака, за счет того что БД станет таким же облачным ресурсом что и все остальные. Пока от Вас я услышал следующее:
1) Полагаться на средства безопасности БД нельзя, поэтому прямой доступ к ней распределенных толстых клиентов невозможен. Я Вам ответил, что средства безопасности БД постоянно развиваются и в будущем это станет возможно.
2) Дополнительный слой между БД и клиентом в виде отдельного процесса ОС (веб-приложение) все-равно нужен, так как в нем реализованы проверки, логирование и т. д. Я Вам показал, что этот слой можно организовать на толстом клиенте средствами ООП без дополнительного процесса ОС (веб-приложения).
По этим пунктам разногласия зафиксировали. Что ещё по существу топика? Давайте дальше двигаться. Все остальное о чем мы говорим конечно интересно, но это уже имеет косвенное отношение в этим пунктам, и в рамках данного топика считаю отступлением от основной темы данного топика. Предлагая создать отдельные топики и обсудить.
M>А кто такой "распределенный толстый клиент"?
Толстый клиент, который напрямую обращается к БД без посредников. Распределенный клиент, это клиент, который может находиться территориально где угодно и не привязан к какой-любо локальной сети.
М>>>Проблема в строгой типизации IB>>Для сложных систем это не проблема, а преимущество. Строгая типизация позволяет больше ошибок отловить при компиляции, и не пустить их в runtime. M>И вообще, я хочу локальные системы типов. Где нужно — использую строгую типизацию. Где не нужно — слабую. Банальнейший пример, где рулит слабая типизация — способ сделать из функции функцию с кэшированием.
Reflection — слабая типизация в строго тапизированных языках. И Вашу функцию с кэшированием можно через него реализовать. Только отладка затруднится.
M> * этот ErrorContext нужно по всем классам с собой таскать М> Хотелось бы все-таки автоматически все это делать.
А при использование Веб Вы таскаете по всему коду клиента ссылку на Веб сервис, причем не автоматически.
М> Да и тестировать не очень интересно — зависимостей больше
Столько же зависимостей. Либо код клиента зависит от errCtx.execute, либо от ссылки на веб сервис. А что Веб сервис не может выдавать инфраструктурные ошибки? Может, так же как и errCtx.execute. БД может отвалиться и при тестировании. На можете сделать тестировочную заглушку errCtx.execute
M> * Вы бесплатно получили толстый клиент, а также "средний" клиент и сервер. Вот из ActionExecutor можно вполне естественным образом выделить интерфейс.
В C# я естественным образом вывожу интерфейс через ключевое слова interface.
M> Можно еще простенький "клиент" написать, который получает запросы от второго ActionExecutor, расшифровывает их и передает своему. В общем, с точностью до используемого языка веб-клиент получился .
Можно реализовать через паттерн Цепочка обязанностей. Зачем для этого веб?
M> * С этим ActionExecutor можно выполнять "высокоуровневые" операции. Написать фильтр, который разрешает только некоторые операции. Переопределить некоторые "action" и т.п.
Атрибуты на методы интерфейса или на методы в реализующем классе и звено в цепочке обязанностей, которое эти атрибуты будет обрабатывать.
M> Переопределить некоторые "action" и т.п.
Тоже цепочку обязанностей. Причем она хорошо проецируется на предметную область. Подчиненный сотрудник о чем то попросил начальника, начальник просьбы отрабатывает и передает вышестоящему начальству. То они все звенья цепочки. А фильтры и всякие переопределители это искусственные понятия не имеющие аналога в реальном мире. Систему проще проектировать, когда в программном коде Вы оперируете объектами реального мира. Это одно из предназначений ООП.
M> * ActionExecutor — очень удобный механизм протаскивать зависимости частей приложения от других частей/компонентов.
IoC
M> * Теперь легко можно заменять реализацию Action. Раньше они ходили в базу, теперь могут использовать другие сервисы для выполнения своей работы.
IoC
M>Там может, ну ее, эту строгую типизацию? Ошибку в имени сервиса/типах аргументов мы увидим при первом же тестировании (при написании/изменении).
Особенно после рефакторинга, когда заказчик вдруг поменял требования. Будете долго ловить то ли Вы допустили ошибку на не внимательность при рефакторинге, то ли это логическая ошибка.
M>Можно. А при чем здесь "серверный слой"? Он ведь тоже через те же классы делается.
При том что серверный слой это отдельный процесс ОС (еще одно приложение). Чтобы передавать объекты через серверный слой нужна их сериализация. Реализация вызовов несколько методов серверного слоя в одной транзакции нетривиальна. Зачем дополнительный гемор для решения простых вопросов (логирование, проверки доступа)?
M>Кстати, декларативность никак разделению на клиент/сервер не мешает. Возможно, даже и помогает.
Согласен. Я имел ввиду, что все Ваши дополнительные проверки и логирование, можно реализовать не через прослойку между БД и клиентом, выполняющуюся в отдельном процессе ОС, а средствами декларативности в одном процессе ОС. Например, АОП.
M>Ну да, это наилучший вариант. Но при этом для большинства приложений настройка будет выглядеть так: "приложение выполняется в полной изоляции от остальных, доступ дан в веб по адресам ... и каталогу XYZ". Не "разрешить все, потом ограничить", а наоборот. Вот "наоборот" далеко не везде исползьуется.
Значит будет использоваться, что мешает? Я говорю про перспективу, а Вы мне опять начинаете про текущее положение вещей.
IB>>И ООП для этого и создан, чтобы абстрагировать бизнес логику от её технической реализации. M>Не для этого он создан. Он создан для моделирования систем из взаимодействующих объектов.
В том числе и для этого. IB>>То есть наружу у класса только то, что необходимо для реализации бизнес логики, а внутри инкапсулированы все технологические и инфраструктурные моменты. И облачные технологии это шаг в этом направлении. M>Не, это неправильная архитектура. В правильной архитектуре бизнес-логика инкапсулирована в одни классы, инфраструктура — в другие. Классы бизнес-логики пользуются классами инфраструктуры через некоторые интерфейсы.
Это каркасы, есть другой допустимый подход — библиотеки, о котором я сначала написал.
M>При чем здесь облака — пока еще не понятно. Что они делают проще?
Написание библиотек и каркасов абстрагирующих от инфраструктуры. Создать библиотеку или каркас для прямого доступа в БД, проще чем для доступа в БД через дополнительный слой, который является отдельным процессом ОС. Конечная цель всех приложений это изменение данных БД.
M>Ну вот простой пример. Обязанность класса — передача данных с клиенту серверу. Сразу будете реализовывать? Или все-таки попытаетесь узнать, что именно передает клиент?
Конечно буду узнавать, обязанность будет заключаться в том, чтобы передавать конкретные типы данных (строгая типизация!).
IB>>Сетевая модель OSI: каждый слой выполняет определенные функции и слои друг от друга не зависят. На этом построен интернет. M>Которая семиуровневая? Так она как раз и не используется. Используется четырехуровневая TCP/IP модель. Можете посмотреть на http://en.wikipedia.org/wiki/Transport_layer . Очень интересная картина. Вот взять тот же IGMP. Это internet layer. Тот же, на котором живут IPv4/IPv6. Вас не смущает, что этот протокол очень хорошо знает, для какой цели обычно используется?
Не смущает. ПО клиента может использовать напрямую любой уровень OSI. То есть зависеть от этого уровня. Если я делаю HTTP запрос я завишу только от HTTP и ни от одного из нижележащих уровней. Если я посылаю запрос IGMP, я завишу только от IGMP и IP и ни от одного из нижележащих уровней. IGMP и IP работают впаре на одном уровне модели OSI: на сетевом. Принципы OSI сохраняются.
IB>>В бизнес приложении можно также выделить два уровня: инфраструктурный и прикладной. Инфраструктурный отвечает за то будет ли клиент распределенным или локальным. M>Почему? Вот ваш второй пример показывает, что инфраструктурный момент за это не отвечает.
Пример показывает ловлю ошибок соединения с БД. Если БД считать инфраструктурой, то отвечает.
M>Очень просто сделать из локального клиента распределенный, заменив немного кода.
Если на локальном клиенте используется процедурное программирование, то просто, перенёс реализацию методов (процедур) в веб сервис и всё (а в самих методах клиента тогда вызываешь методы веб сервиса). А если на клиенте полноценно используется ООП и ORM, то непросто, здесь уже расчет на прямой доступ к БД.
M>Вот если в браузер подтащить драйвера для доступа к базе данных (заставить в нем работать node.js).
Это уже изврат.
IB>>Прикладной это бизнес логика. В web эти уровни смешаны или жестко связаны. Облачные технологии позволят разделить эти уровни и сделать их независимыми. M>Вы так и не ответили, что такое "бизнес-логика". Это формочки? Или это доступ к базе данных? Но ведь хранение данных — это тоже инфраструктурный момент.
Есть классицистические понятия слой доступа к данным, слой бизнес логики и слой представления. Бизнес-логика это все кроме формочек и доступа к данным. Формочеками занимаются дизайнеры, а не программисты. WPF к этому идет. Доступ к данным делается прозрачным через ORM. Только ORM предполагает прямой доступ к БД. И здесь становится необходимым сделать БД облачным ресурсом для организации распределенных толстых клиентов на ORM.
M>При этом я не вижу, где же в веб эти уровни связаны: M> * Уровень UI рисует формочки.
В простых web приложениях согласен. Только в отзывчивом Rich Web Application бизнес логика упорно хочет перетечь на клиента.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
M>>Здравствуйте, igor-booch, Вы писали: M>>А для чего еще предназначены облачные технологии? Точнее, "не для чего предназначены", а "какие основные преимущества по сравнению с отказом от виртуализации/распределенности". Я пока ничего другого не вижу. IB>Вы скажите конкретно почему Вы считаете невозможными распределенные толстые клиента через облака, за счет того что БД станет таким же облачным ресурсом что и все остальные.
Почему считаю невозможным? Они вполне возможны. Но с точки зрения архитектуры "толстый клиент через облако" ничем не отличается просто от "удаленного толстого клиента". Так что бенефиты в архитектурной (именно в архитектурной) плоскости поймать не получится. А вот по другим аспектам (экономическим) облака выгодны, поэтому в некоторых случаях может иметь смысл делать толстый клиент и на них.
Это, естественно, при прочих равных. Например, при условии, что у нас уже есть база, которую мы можем распределить на несколько машин. Иначе бенефит получается в первую очередь от новой базы данных, а не от облаков, например.
M>>А кто такой "распределенный толстый клиент"? IB>Толстый клиент, который напрямую обращается к БД без посредников. Распределенный клиент, это клиент, который может находиться территориально где угодно и не привязан к какой-любо локальной сети.
M>> Можно еще простенький "клиент" написать, который получает запросы от второго ActionExecutor, расшифровывает их и передает своему. В общем, с точностью до используемого языка веб-клиент получился . IB>Можно реализовать через паттерн Цепочка обязанностей. Зачем для этого веб?
Не за чем. В этом то и дело. При вашей архитектуре совершенно нет разницы, построено все на "облаке", на "веб" или вообще напрямую ходит в базу. Мы очень удачно изолировали инфраструктурный вопрос. Повторю — это достоинство архитектуры, которая нормально ложится на что угодно.
M>> * ActionExecutor — очень удобный механизм протаскивать зависимости частей приложения от других частей/компонентов. IB>IoC IB>IoC
Не забыли еще одну C? Inversion of Control Container? IoC пользуюсь. IoCC — нет. Связывание на типах не рулит, у меня может быть пара дестяков объектов одного типа. Связывание на именах (парметров или аннотаций) — интрузивно по отношению к основному коду, почти не отличается от registry lookup. А еще в IoC-контейнерах не получается делать функции (вроде того же кэширования — сделать из обычного экземпляра службы кэширующий). Хотя, может мне просто не везло с контейнерами. В общем, разница не слишком большая. Хотя в последнем моем проекте зависимости погут подтягиваться асинхронно (ну т.е. модуль, загружающий данные с сервера, может быть подгружен при первом запросе (и только при запросе!) к этому модулю).
M>>Там может, ну ее, эту строгую типизацию? Ошибку в имени сервиса/типах аргументов мы увидим при первом же тестировании (при написании/изменении). IB>Особенно после рефакторинга, когда заказчик вдруг поменял требования. Будете долго ловить то ли Вы допустили ошибку на не внимательность при рефакторинге, то ли это логическая ошибка.
Не, не долго. Я даже инфраструктурный слой (middle-tier, через который все части приложения между собой связаны) менял со слабой типизацией. Пропустили одну ошибку, потом легко поправили. Хотя все зависит от архитектуры. В моем случае с макаронами (все зависит от всего) я боролся, так что большинство зависимостей нужно было искать только в трех местах — первый инициализатор (более "инфраструктурный"), второй инициализатор (бизнес-логика) и конфиг внешних сервисов.
M>>Кстати, декларативность никак разделению на клиент/сервер не мешает. Возможно, даже и помогает. IB>Согласен. Я имел ввиду, что все Ваши дополнительные проверки и логирование, можно реализовать не через прослойку между БД и клиентом, выполняющуюся в отдельном процессе ОС, а средствами декларативности в одном процессе ОС. Например, АОП.
АОП — читерская декларативность. Она привязывается не к тому (либо к текстовым именам, кстати, может слетать при рефакторинге), либо интрузивна (аннотации в самом классе). Вот через мета-трансформации мне нравится больше всего. Она остается такой же декларативной (someService = caching(someCache, logging(someServiceBaseImpl(dbConnection))), как и через аннотации/логирование.
M>>При чем здесь облака — пока еще не понятно. Что они делают проще? IB>Написание библиотек и каркасов абстрагирующих от инфраструктуры. Создать библиотеку или каркас для прямого доступа в БД, проще чем для доступа в БД через дополнительный слой, который является отдельным процессом ОС. Конечная цель всех приложений это изменение данных БД.
Так мы же обычно не пишем такой каркас вручную. Берется драйвер базы данных, прикручивается через стандартный интерфейс платформы и вперед! Да, сам драйвер для такой базы писать сложнее. Только вот очень редко это нужно. Я люблю транспорты для веб писать, но они тоже через одно узкое место прикручиваются. Хорошо, если вся инфраструктура займет 1% времени от написания/тестирования приложения, на практике выходит еще меньше. Если же выбирать между двумя драйверами, написанными за нас (в облаке и для локальной машины), то сложность этих драйверов будет иметь еще меньшее значение (хотя косвенно и влияет на
M>>Ну вот простой пример. Обязанность класса — передача данных с клиенту серверу. Сразу будете реализовывать? Или все-таки попытаетесь узнать, что именно передает клиент? IB>Конечно буду узнавать, обязанность будет заключаться в том, чтобы передавать конкретные типы данных (строгая типизация!).
Ну для определенности, там пять интов нужно передавать. Я вам в метод эти инты в виде пяти параметров отдам. Все равно ведь спросите, зачем, с какой надежностью и т.п.
IB>>>Сетевая модель OSI: каждый слой выполняет определенные функции и слои друг от друга не зависят. На этом построен интернет. M>>Вас не смущает, что этот протокол очень хорошо знает, для какой цели обычно используется? IB>Не смущает. ПО клиента может использовать напрямую любой уровень OSI. То есть зависеть от этого уровня. Если я делаю HTTP запрос я завишу только от HTTP и ни от одного из нижележащих уровней.
А, в таком виде. Понял. У вас просто инъекции зависимостей нет. Т.е. протокол HTTP выбирает наилучший с его точки зрения протокол более низкого уровня. Т.е. он жестко прошит. А вот если бы я мог собирать сетевой стек вручную (ну например, http over robust udp или http over ip) с нужными посредниками, то выбирал бы протокол, который лучше всего подходит для более высокоуровневого http (т.е., скорее всего, tcp). У меня все классы с нарушением SRP отрезаны через подобные интерфейсы. В вашей терминологии, в SRP нарушения SRP нет (или есть, но в гораздо меньших масштабах, чем в реализациях интерфейсов). В общем, даже в терминах "библиотек" эти библиотеки все равно знают, под какой контекст разрабатываются (TCP — под потоковую передачу данных вроде HTTP/FTP и аналогов, SCTP — для передачи мультимедиа и т.п.). Т.е. они напрямую не зависят от контекста, но все равно на него ориентированы. Здесь у нас принципиальных противоречий нет.
M>>Очень просто сделать из локального клиента распределенный, заменив немного кода. IB>Если на локальном клиенте используется процедурное программирование, то просто, перенёс реализацию методов (процедур) в веб сервис и всё (а в самих методах клиента тогда вызываешь методы веб сервиса). А если на клиенте полноценно используется ООП и ORM, то непросто, здесь уже расчет на прямой доступ к БД.
Хм. Да, с ORM согласен. Не пользуюсь по идеологическим причинам. Не встречалось что-то мест, где нужно строить сложные запросы на стороне клиента и подобными "неопределенными" границами ранзакций рулить. А все остальное нормально в "запрос/ответ" ложится.
M>>Вот если в браузер подтащить драйвера для доступа к базе данных (заставить в нем работать node.js). IB>Это уже изврат.
Технически — наверное, да. А вот если сервер на node.js написан, то кода придется менять очень мало (только инициализацию приложения). И будет у вас "распределенный толстый клиент" в браузере.
IB>И здесь становится необходимым сделать БД облачным ресурсом для организации распределенных толстых клиентов на ORM.
Погодите. Зачем делать БД облачным ресурсом? Вот первый вопрос, на который нужно ответить. Почему "распределенный толстый клиент" не может работать с фиксированной базой на хостинге в организации? Ответ именно на этот вопрос и будет говорить о пользе облаков. А все остальное уже следствия "база стала в облаке", о чем я раньше и писал. И load balancing я могу на фиксированной базе (нескольких экземплярах) сделать. И драйвера взять, которые нормально с ними работают (или тот же pgpool для постгреса, например). И база будет конфигурироваться в одном месте, точно так же, как и для облаков.
M>>При этом я не вижу, где же в веб эти уровни связаны: M>> * Уровень UI рисует формочки. IB>В простых web приложениях согласен. Только в отзывчивом Rich Web Application бизнес логика упорно хочет перетечь на клиента.
Мне кажется, он немного по дргуим причинам на клиента хочет переехать. Для отзывчивого Application UI хочется делать много и разных запросов. А вот здесь при классическом подходе нужно завести DTO (только с нужным набором полей), интерфейс в методе, реализовать метод, реализовать биндинг, реализовать выполнение запроса на сервере. Если же сделать легким написание всех подобных запросов (плюс настраиваемое кэширование обертками на клиенте), то особой разницы не будет, где и как выполнять запросы. У меня клиент умеет нужные данные поднимать из локального кэша и остальные догружать с сервера. Хотя это не совсем типичный сценарий, у него все кэши под нужную задачу настроены. Но в целом в моих наработках проброс значения на сервер — одна строчка в конфиге клиента. На сервере в новой версии будет полторы строчки (одна — на конфигурацию адреса, вторая — на подсовывание зависимостей обработчику запроса). Ах да, DTO. На сервере — в одну строчку DTO описывается (это если хочется, а я могу ведь и сразу json собирать, например, зачем мне DTO и ORM, если я знаю, что именно строю и хочу отдать).
M>При вашей архитектуре совершенно нет разницы, построено все на "облаке", на "веб" или вообще напрямую ходит в базу.
Это я и имел ввиду под независимостью от инфраструктуры и принципом разделения обязанностей.
M>Не забыли еще одну C? Inversion of Control Container? IoC пользуюсь. IoCC — нет. Связывание на типах не рулит, у меня может быть пара дестяков объектов одного типа.
Да я имел ввиду IoCC. У меня есть своя реализация IOCC, там для одного интерфейса (типа) можно задать несколько именованных реализаций (объектов).
M>А еще в IoC-контейнерах не получается делать функции (вроде того же кэширования — сделать из обычного экземпляра службы кэширующий).
Я наверное чего-то не понял, но IOCC позволяет Вам только динамически выбрать реализацию: кэширующую или простую. Но реализации Вы должны сами сделать.
M>Вот через мета-трансформации мне нравится больше всего. Она остается такой же декларативной (someService = caching(someCache, logging(someServiceBaseImpl(dbConnection))), как и через аннотации/логирование.
Это через функциональное программирование. АОП это инъекции в код по атрибутам или по именам методов. Инъекции в код можно также делать и императивно, как у Вас. Но это шаг в сторону императивности.
M>Связывание на именах (парметров или аннотаций) — интрузивно по отношению к основному коду, почти не отличается от registry lookup. M>АОП — читерская декларативность. Она привязывается не к тому (либо к текстовым именам, кстати, может слетать при рефакторинге), либо интрузивна (аннотации в самом классе).
У АОП фреймворка есть обязанность: cделать инъекцию в методы, помеченные такими-то атрибутами. Конечно ему наплевать какой именно это метод. Это тоже принцип разделения обязанностей.
M>>>Ну вот простой пример. Обязанность класса — передача данных с клиенту серверу. Сразу будете реализовывать? Или все-таки попытаетесь узнать, что именно передает клиент? IB>>Конечно буду узнавать, обязанность будет заключаться в том, чтобы передавать конкретные типы данных (строгая типизация!). M>Ну для определенности, там пять интов нужно передавать. Я вам в метод эти инты в виде пяти параметров отдам.
Оберните 5 интов в тип и передавайте этот тип. Я предполагаю что 5 интов могут соответствовать нескольким разным типам. Тогда нужен еще один класс — парсер. Его обязанность будет паковать 5 интов в нужный тип. Получается 2 класса с разделенными обязанностями. Если Вам придет обрабатывать распарсенные типа еще где-нибудь сможете повторно использовать парсер.
IB>>>>Сетевая модель OSI: каждый слой выполняет определенные функции и слои друг от друга не зависят. На этом построен интернет. M>>>Вас не смущает, что этот протокол очень хорошо знает, для какой цели обычно используется? IB>>Не смущает. ПО клиента может использовать напрямую любой уровень OSI. То есть зависеть от этого уровня. Если я делаю HTTP запрос я завишу только от HTTP и ни от одного из нижележащих уровней. M>А, в таком виде. Понял. У вас просто инъекции зависимостей нет. Т.е. протокол HTTP выбирает наилучший с его точки зрения протокол более низкого уровня. Т.е. он жестко прошит. А вот если бы я мог собирать сетевой стек вручную (ну например, http over robust udp или http over ip) с нужными посредниками, то выбирал бы протокол, который лучше всего подходит для более высокоуровневого http (т.е., скорее всего, tcp).
Все равно нет нарушения OSI. Единственное отличие от моего примера это то, что Вы обращаетесь напрямую не к одному уровню OSI, а к нескольким.
IB>>И здесь становится необходимым сделать БД облачным ресурсом для организации распределенных толстых клиентов на ORM. M>Погодите. Зачем делать БД облачным ресурсом? Вот первый вопрос, на который нужно ответить. Почему "распределенный толстый клиент" не может работать с фиксированной базой на хостинге в организации?
А зачем распределенные БД? А считаю распределенные БД облачной технологией. Ну или технологией, смежной с облачными, если Вам так больше нравится (или следствием облачных технологий).
Если Фиксированная БД на хостинге в организации будет очень далеко территориально от толстого клиента, будет высокая latency, сложности с резким увеличением количества толстых клиентов, сложности с обеспечение безопасности. Технологий безопасности это конечно не облачные технологии, но это опять же технологии, которые за собой тянут облачные технологии. Для простоты я их все называю облачными.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Re[21]: Облака
От:
Аноним
Дата:
22.05.13 15:34
Оценка:
Здравствуйте, igor-booch, Вы писали:
M>>При вашей архитектуре совершенно нет разницы, построено все на "облаке", на "веб" или вообще напрямую ходит в базу. IB>Это я и имел ввиду под независимостью от инфраструктуры и принципом разделения обязанностей.
Ок. Но при чем здесь облака тогда? Они никак не помогают, но и не мешают. Совсем никак. Чисто инфраструктурный момент.
M>>Вот через мета-трансформации мне нравится больше всего. Она остается такой же декларативной (someService = caching(someCache, logging(someServiceBaseImpl(dbConnection))), как и через аннотации/логирование. IB>Это через функциональное программирование. АОП это инъекции в код по атрибутам или по именам методов. Инъекции в код можно также делать и императивно, как у Вас. Но это шаг в сторону императивности.
Почему это у меня императивно? У мени никто не меняет состояние "внутренних" служб. Так что это и "мета-трансформации", и "декларативное описание" сразу. Никакой "императивности" (в смысле операций над глобальным состоянием) здесь нигде нет.
M>>Ну для определенности, там пять интов нужно передавать. Я вам в метод эти инты в виде пяти параметров отдам. IB>Оберните 5 интов в тип и передавайте этот тип...
А протокол то какой сетевой возьмете? Http, tcp, udp или что-то еще? Формат вызова вашего метода я описал. Если хотите, передам объектом. Как ваш метод внутри реализован, меня не сильно интересует. Интересует только, какой протокол вы выберете, не зная, зачем я пять чисел передаю.
IB>Все равно нет нарушения OSI. Единственное отличие от моего примера это то, что Вы обращаетесь напрямую не к одному уровню OSI, а к нескольким.
Так все основные сервисы приложения тоже к одному уровню обращаются. О нескольких уровнях знает только код инициализации приложения.
IB>>>И здесь становится необходимым сделать БД облачным ресурсом для организации распределенных толстых клиентов на ORM. M>>Погодите. Зачем делать БД облачным ресурсом? Вот первый вопрос, на который нужно ответить. Почему "распределенный толстый клиент" не может работать с фиксированной базой на хостинге в организации? IB>А зачем распределенные БД?
Здесь все просто:
* Обеспечение надежности. hot standby базы данных — возможность с минимальным временем простоя (и небольшими потерями данных, зависит от настройки) вернуть систему в рабочее состояние.
* Работа с нагрузкой. На slave-репликах можно выполнять запросы к данным, если не требуется слишком высокая актуальность данных (порядка секунд). На тех же slave можно выполнять сложные выборки (аналитика по многим таблицам) а на master-базе выполнять только CRUD-операции. Ей и так нагрузки хватит. Можно даже географически распределенные slave забабахать и снизить латентность на чтение у клиентов (как вы где-то писали, у вас чтений гораздо больше, чем записей).
* Шардинг. Как в целях ускорения запросов (при нужной базе), так и просто для хранения большого количества данных (которые на одной базе не помещаются). Не знаю, реализован ли он где-нибудь в sql (в no-sql в mongo по-моему есть).
Этим применениям уже очень много лет. И они использовались в production задолго до того, как облака стали известны (и стали рекламироваться).
IB>А считаю распределенные БД облачной технологией. Ну или технологией, смежной с облачными, если Вам так больше нравится (или следствием облачных технологий).
Зря. Из вашего определения следует, что для "распределенных БД" нужно брать облако (со всеми его недостатками). А если считать "распределенные БД" просто "распределенными БД", можно их где-нибудь взять без присущих ему недостатков. Я согласен, что ряд достоинств, присущих распределенным БД, будет присущ этим же БД в облаках. Но это не делает эти технологии "облачными".
IB>Если Фиксированная БД на хостинге в организации будет очень далеко территориально от толстого клиента, будет высокая latency,
Да, для клиента. Особенно характерно для "ORM" и прочих извращений (где куча запросов вместо одного-двух). Избыточные запросы сильно уменьшаются нормальной архитектурой. При желании на чтение ставятся дополнительные локальные реплики базы. Мастер остается централизованным (например). Тогда у нас нет высокой latency на запись, обеспеченной синхронизацией распределенных узлов в "облаке". А может, и на чтении ниже latency (когда облачные узлы тоже блокировки какие-то не проверяют).
IB>сложности с резким увеличением количества толстых клиентов,
А откуда сложности? Хотя да, знаю. У вас толстые клиенты держат долгие транзаци... На коротких транзакциях (желательно — с autocommit=on) такая база масштабируется точно так же, как и при всех локальных клиентах.
IB>сложности с обеспечение безопасности.
Ну да, правильно. База торчит во внешний мир. С чем я вас и поздравляю. Кстати, с базой в облаке будут все те же проблемы по той же причине.
Вообще, три абзаца выше (после цитирования абзацы) очень весомы только при неправильной архитектуре. А при правильной более-менее актуален только первый абзац, который может быть облегчен
"обычными" репликами базы данных.
Что интересно, неправильная архитектура обычно вытекает из "формочки рисуют дизайнеры", "есть стандартные слои: UI, бизнес-логика и база данных" и "программистам бизнес-логики инфраструктура не интересна". На самом то деле "формочки" являются еще какой бизнес-логикой. Не единственной (есть и внутренние правила), но бизнес-логикой является! Или у вас пользователи ПО не занимаются бизнесом, а так, штаны просиживают? Поэтому "формочки" предназначены для бизнес-действий. А вот теперь бизнес-действия нужно отбразить на архитектуру. И вот здесь "не учитывать инфраструктуру" нельзя — иначе получатся монстры, которые на каждое "бизнес-действие" выполняют кучу запросов (последовательных, блин!), открывают длинные транзакции и при этом еще весь UI замораживают. Ведь "достать все данные одним/двумя точными запросами" в бизнес-логику не ложится. И архитекутра не позволяет нормально писать такие доставалки (слишком много кода, да и не понятно, куда же "бизнес-логика" ложится), поэтому берется монструозный ОРМ. Теперь доставалки писать вроде бы не надо, но запросов стало горы.
Если же аспекты формочек и инфраструктуры учитывать, все более-менее нормально получается. На формочку получается служба, которая достает нужные данные и умеет выполнять нужные операции (при желании она может и из данных других служб собирать, а может и прямым запросом ходить в базу, зависит от многих условий). При необходимости эту службу можно унести на удаленный сервер (тогда будет один запрос и один ответ на "бизнес-действие", а в базу будет ходить сервер логики, к нему база гораздо ближе). В общем, latency все равно виляет (не сильно, нужно стремиться минимизировать количество запросов), а вот "проблем с масштабированием" нет.
Я же уже выше писал, что таких "программистов бизнес-логики" к архитектуре подпускать нельзя, иначе будут проблемы. Ничего личного, проблемы (и их причины) вполне характерные. И при этих проблемах облака не помогут. Лечить их нужно совсем по-другому. Так что в нормальных условиях здесь облака не продать .
IB>Технологий безопасности это конечно не облачные технологии, но это опять же технологии, которые за собой тянут облачные технологии.
Нет, их тянут распределенные технологии
IB>Для простоты я их все называю облачными.
Вас никто не поймет. Называйте эти технологии правильно (и для простоты) — распределенными. Пару постов выше мы вроде договорились, что облака — это "виртуальность и распределенность". Вот нигде в вашем посте не было использования "виртуализации". Понимаете, все "преимущества" выше обеспечиваются не облаками, они обеспечиваются распределенностью. Если взять облака, эти бенефиты будут. Но вот чтобы получить эти же бенефиты, не обязательно брать облака. Так что не понятно, кого с кем вы сравниваете (и чем обсусловлен выбор), когда говорите о "преимуществах облаков". Ну да, по сравнению с писаниной "на ассемблере" облака будут нереально круты. А вот в группе "похожих" технологий у облаков будет очень мало преимуществ.
IB>Технологий безопасности это конечно не облачные технологии, но это опять же технологии, которые за собой тянут облачные технологии. M>Нет, их тянут распределенные технологии
IB>Для простоты я их все называю облачными. M>Вас никто не поймет. Называйте эти технологии правильно (и для простоты) — распределенными. Пару постов выше мы вроде договорились, что облака — это "виртуальность и распределенность". Вот нигде в вашем посте не было использования "виртуализации". Понимаете, все "преимущества" выше обеспечиваются не облаками, они обеспечиваются распределенностью.
IB>А считаю распределенные БД облачной технологией. Ну или технологией, смежной с облачными, если Вам так больше нравится (или следствием облачных технологий). M>Зря.
Вы говорите что "облака = виртуальность + распределенность", но при это рассматриваете виртуализацию и распределенность отдельно друг от друга. Зачем тогда был введен термин "облачные технологии"? Пользовались бы все по прежнему терминами виртуализация и распределенность. Для меня облачные технологии это нечто большее чем способ назвать "виртуализацию" и "распределенность" одним словом. Это тот случай когда целое нечто большее чем сумма частей. Для Вас это видимо не так. Я считаю нужно зафиксировать это разногласие и закончить дискуссию.
А>На самом то деле "формочки" являются еще какой бизнес-логикой. Не единственной (есть и внутренние правила), но бизнес-логикой является!
Слой представления может зависеть от слоя бизнес логики, но не может являться его частью. Наверное это разногласие тоже причина по которой у нас разные взгляды на облака. Спорить с Вами про то что бизнес логика должна быть отделена от уровня предствления я не буду. Зафиксируем это разногласие.
IB>>сложности с обеспечение безопасности. А>Ну да, правильно. База торчит во внешний мир. С чем я вас и поздравляю. Кстати, с базой в облаке будут все те же проблемы по той же причине.
Вы опять говорите про текущее положение вещей и забываете что технологии безопасности могут развиваться. Зафиксируем это различие в наших взглядах.
M>>>Ну для определенности, там пять интов нужно передавать. Я вам в метод эти инты в виде пяти параметров отдам. IB>>Оберните 5 интов в тип и передавайте этот тип... А>А протокол то какой сетевой возьмете?
Значит нужен еще один класс ProtocolSelector, которому будет передаваться информация для выбора протокола и его обязанность будет заключаться в выборе правильного протокола на основе этой информации. Контекст должен зависеть от класса, который он использует. Но класс не должен зависеть от контекста. Иначе получится перекрестная ссылка. Спорить больше с тем, что класс не должен зависеть от контекста своего вызова, я не буду. Зафиксируем это разногласие.
M>>>Погодите. Зачем делать БД облачным ресурсом? Вот первый вопрос, на который нужно ответить. Почему "распределенный толстый клиент" не может работать с фиксированной базой на хостинге в организации? IB>>А зачем распределенные БД? А>Здесь все просто:
Согласен, репликация, кластеризация, шардирование были и без облаков. А зачем тогда ОС Windows Azure, и БД SQL Azure? Опять отделяете распределенность от облаков.
IB>>Все равно нет нарушения OSI. Единственное отличие от моего примера это то, что Вы обращаетесь напрямую не к одному уровню OSI, а к нескольким. А>Так все основные сервисы приложения тоже к одному уровню обращаются. О нескольких уровнях знает только код инициализации приложения.
Значит Вы реализуете принципы OSI сами в своем приложение, а не полагаетесь на реализацию стека сетевых протоколов ОС.
А>Почему это у меня императивно?
Вот это императивная строчка: M>someService = caching(someCache, logging(someServiceBaseImpl(dbConnection))
Вы приказываете someServiceBaseImpl стать кушируемым и логируемым. Вам же потом везде надо будет использовать someService, значит Вы меняете глобальное состояние.
А если Вы напишите
[Caching]
[Logging]
public class SomeServiceBaseImpl
{
...
}
Здесь Вы декларируете SomeServiceBaseImpl как кэшируемый и логируемый. Это уже более декларативный стиль. В независимость от того применили ли Вы атрибуты Caching и Logging, Вы везде используете SomeServiceBaseImpl.
M>Никакой "императивности" (в смысле операций над глобальным состоянием) здесь нигде нет.
Декларативность это нечто большее чем отсутствие операций над глобальным состоянием. Отсутствие операций над глобальным состоянием можно добиться и за счет инкапсуляции, но это не будет декларативность.
IB>>сложности с резким увеличением количества толстых клиентов, А>А откуда сложности? Хотя да, знаю. У вас толстые клиенты держат долгие транзаци...
Да нет, ресурсов одного инстанца БД может не хватить даже на множество коротких транзакций. И каналы связи могут не ведержать. Здесь нужна распределенная БД, отдельные узлы, которой виртуализированы в дата центрах. В общем облачные технологии.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>>А считаю распределенные БД облачной технологией. Ну или технологией, смежной с облачными, если Вам так больше нравится (или следствием облачных технологий). M>>Зря.
IB>Вы говорите что "облака = виртуальность + распределенность", но при это рассматриваете виртуализацию и распределенность отдельно друг от друга.
Не отдельно. Просто я все заявленные "преимущества" раскладываю на "базовые" технологии, которыми эти преимущества предоставляются на самом деле. Где-то в дискуссии я ведь нашел, что требует одновременно и того, и другого, а значит является преимуществом именно облачных технологий. Но преимущество было только одно, а все остальное почему-то успешно разложилось по технологиям-первоисточникам. Если вы назовете что-то еще, для чего требуется сразу виртуальность и распределенность, я охотно признаю это преимуществом облачности.
IB>Зачем тогда был введен термин "облачные технологии"? Пользовались бы все по прежнему терминами виртуализация и распределенность.
Чтобы продавать воздух. Термин был введен продажниками и ориентирован на нетехническую аудиторию. Ну не продавалась "вирутальность". И "распределенность" не продавалось. Пришлось придумать новое модное название и раскрутить hype. Это основное применение. Хотя есть и валидные применения — купить на время вычислительных ресурсов, которые в обычной жизни не нужны (посчитать одноразово что-нибудь тяжелое, например). Это "новые опции pricing'а", о которых я говорил.
IB>Для меня облачные технологии это нечто большее чем способ назвать "виртуализацию" и "распределенность" одним словом. Это тот случай когда целое нечто большее чем сумма частей.
Оно дает. Я не отрицаю. Только пока на стыке получается совсем не то, что вы предподносите. Вот "pricing" — на стыке, а все остальное вроде бы и без стыка может быть.
IB>>>А зачем распределенные БД? А>>Здесь все просто: IB>Согласен, репликация, кластеризация, шардирование были и без облаков. А зачем тогда ОС Windows Azure, и БД SQL Azure? Опять отделяете распределенность от облаков.
Чтобы деньги зарабатывать, наверное. "Продать продукт" и "сделать что-то новое" конечно, связано, но из первого второе обычно не следует. А по конкретным вопросам нужно смотреть, что именно нового они предлагают. Может быть, там есть что-то интересное, о чем вы не упоминали. А может, просто маркетинговое (или нетехническое) решение продавать только облака, но не распределенность.
А>>Почему это у меня императивно? IB>Вот это императивная строчка: M>>someService = caching(someCache, logging(someServiceBaseImpl(dbConnection)) IB>Вы приказываете someServiceBaseImpl стать кушируемым и логируемым. Вам же потом везде надо будет использовать someService, значит Вы меняете глобальное состояние.
Не приказываю. Она так и остается нелогируемой и некэшируемой. А вот someService — ее кэширующия и логирующая версия. "Везде использовать someSerivce" делается элементарно — она уже и так инжектится во все остальное. На самом деле "someService" — в первую очередь "application-wide some service". А то, что она реализуется через someServiceBaseImpl — особенности ее конфигурации, не более. При желании я могу изменить эту строчку, и никто ничего не заметит.
IB>А если Вы напишите
IB>[Caching] IB>[Logging] IB>public class SomeServiceBaseImpl IB>{ IB>... IB>} IB>Здесь Вы декларируете SomeServiceBaseImpl как кэшируемый и логируемый. Это уже более декларативный стиль.
Это менее декларативный стиль. Вы приказали SomeServiceBaseImpl стать кэширующей и логирующей. Теперь у вас нет некэширующией и нелогирующей службы. А я могу свою someServiceBaseImpl в отдельную переменную вынести и передать туда, где нужна именно "некэширующая" версия. У вашего подхода начинаются проблемы, когда у интерфейса SomeService по каким-то причинам нужно сделать несколько реализаций. Кстати, у меня еще и кэш явно и очевидно инжектится. А у вас интерфейс SomeServiceBaseImpl пострадает. Другое дело, что у вас преобразования выполняются во время компиляции (а у меня — во время выполнения).
IB>>>сложности с резким увеличением количества толстых клиентов, А>>А откуда сложности? Хотя да, знаю. У вас толстые клиенты держат долгие транзаци... IB>Да нет, ресурсов одного инстанца БД может не хватить даже на множество коротких транзакций. И каналы связи могут не ведержать. Здесь нужна распределенная БД, отдельные узлы, которой виртуализированы в дата центрах. В общем облачные технологии.
А зачем нужно виртуализировать БД в датацентрах? Почему бы просто не распределить их "невирутально" по тем же датацентрам?
Здравствуйте, igor-booch, Вы писали:
IB>Понятно, что удаленный доступ к БД был возможен и раньше, IB>но облачные технологии обеспечивают делают этот доступ менее трудоемким и более функциональным (безопасность, балансировка нагрузки). IB>Правильно ли понимаю?
Нет. Доступ к классической РБД напрямую из приложений — дохлый путь, хотя бы из-за латентности.
Попытки использовать обычные запросы быстро проваливаются, так как всего несколько штук запросов при латентности в 100мс. быстро дают тормозной интерфейс. Дальше будет секс с хранимыми процедурами и прочей радостью в попытке превратить БД в сервер приложений.
Здравствуйте, igor-booch, Вы писали:
IB>CAP-теорема: http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP не доказана. Она эвристическая. Поэтому пока до конца непонятно, то ли она описывает фундаментальные ограничения, то ли ограничения обусловленные текущим уровнем развития облачных технологий. Хотя теорема интересная, спасибо.
Что значит "эвристическая"? Известные протоколы консенсуса требуют наличия связного кворума. Т.е. сделать распределённую БД с атомарными коммитами без сильно избыточной коммуникации невозможно.
C>Что значит "эвристическая"?
Эвристическая значит доказанная не в рамках научной теории, а в рамках заранее заданной эвристической модели.
Постройте другую модель и получите другие выводы. Научная теория более строгое в этом отношении понятие.
Ссылки на списание модели и её ограниченность с точки зрения практического применения см. http://rsdn.ru/forum/design/5155590.1
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, igor-booch, Вы писали:
IB>>CAP-теорема: http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP не доказана. Она эвристическая. Поэтому пока до конца непонятно, то ли она описывает фундаментальные ограничения, то ли ограничения обусловленные текущим уровнем развития облачных технологий. Хотя теорема интересная, спасибо. C>Что значит "эвристическая"? Известные протоколы консенсуса требуют наличия связного кворума. Т.е. сделать распределённую БД с атомарными коммитами без сильно избыточной коммуникации невозможно.
Осталось малость: понять что значит "сильно избыточными", и как эта "сильно избыточность" влияет на других.
Это кстати основная слабость cap теоремы. Она не описывает понятия доступности (availability). Будет ли это недоступность узла, или всей системы, или просто ожидание завершения транзакции, как в обычных БД. В принципе если все свести к ожиданию завершения транзакции и сделать это время ожидания не сильно отличающимся от обычных БД, то проблем какбы и нет.
Здравствуйте, igor-booch, Вы писали:
C>>Что значит "эвристическая"? IB>Эвристическая значит доказанная не в рамках научной теории, а в рамках заранее заданной эвристической модели.
Что за бред? CAP-теорема формально доказана (блин, да она очевидна).
IB>Постройте другую модель и получите другие выводы. Научная теория более строгое в этом отношении понятие.
Ну да. Можно сказать, что consistency — это количество сливочного мороженного в каждом узле. В такой теории оно будет вообще классно доказано. Указанное сообщение в http://rsdn.ru/forum/design/5155590.1
Здравствуйте, gandjustas, Вы писали:
C>>Что значит "эвристическая"? Известные протоколы консенсуса требуют наличия связного кворума. Т.е. сделать распределённую БД с атомарными коммитами без сильно избыточной коммуникации невозможно. G>Осталось малость: понять что значит "сильно избыточными", и как эта "сильно избыточность" влияет на других.
Это означает, что если мы хотим Consistency (традиционные РБД) и Availability (распределённость), то мы теряем устойчивость к разделению. ВСЕ существующие протоколы распределённого консенсуса (которые все так или иначе сводятся к http://en.wikipedia.org/wiki/Byzantine_fault_tolerance) требуют, чтобы между всеми узлами кворума была постоянная связь. Если мы теряем кворум, то останавливается вся система.
Хотя протоколы Византийских генералов гарантируют, что мы не увидим повреждения целостности.
G>Это кстати основная слабость cap теоремы. Она не описывает понятия доступности (availability). Будет ли это недоступность узла, или всей системы, или просто ожидание завершения транзакции, как в обычных БД.
Это означает полную недоступность всей системы из-за невозможности достоверно узнать в каком она состоянии.
На практике можно слегка ослабить требования к consistency, понадеяться на "авось", и пережить некоторые типы сценариев отказа.
Здравствуйте, igor-booch, Вы писали:
IB>Реальные системы или их части могут занимать промежуточное положение или быть гибридными.
На практике БД может быть заменена текстовыми файлами, которые носят почтальоны.
IB>Consistency — в теореме сформулировано требованием, того чтобы во всех вычислительных узлах в любой момент времени данные не противоречат друг другу. То есть устаревание кэша узла распределенной БД не допускается. На практике считается допустимым и даже необходимым, если конечные пользователи видят устаревшие данные.
Пожалуйста, отказываемся от consistency — и получаем availability + partition tolerance. Ровно по CAP-теореме.
Пассаж с "данные меняются 20 раз в секунду" — это вообще ни к чему. Если нам нужен consistency, то часто нам нужно это из-за бизнес-задачи. К примеру, классическая задача — резервирование мест в самолёте. Если два агента выпишут билет на одно место, то покупателям это вряд ли понравится. Именно для этого и нужна гарантия consistency.
IB>Availability — в теореме сформулировано требованием, того чтобы любой запрос к распределённой системе завершается корректным откликом. Это означает что если удаленный ресурс не может выполнить запрос он должен сказать об этом, а не молчать. На практике на запросы к удаленным ресурсам ставятся таймауты.
Опять бредим. Если таймаут вызван не техническими причинами, а отсутствием связи между узлами, то мы жертвуем availability по её определению для CAP-теоремы. И получаем consistency+partition tolerance, ровно по CAP.
IB>Partition tolerance — расщепление распределённой системы на несколько изолированных секций не приводит к не приводит к некорректности отклика от каждой из секций. Это значит что если Вы записали в одну из изолированных секций (секция — это множество узлов, между которым есть связь), а в другой секции потом читаете, Вам должна четко сказать что чтение невозможно (жертвуем Consistency) и задержать ответ пока связь между секциями не восстановится (жертвуем Availability). На практике для одних данных допустим один вариант, для других другой.
Необязательно. В ряде PT-систем вполне возможны локальные операции, и при появлении связи происходит разрешение возможных конфликтов.
IB>Да и разделение интернета на секции возможно только в случае мировой войны или катаклизма.
Ха. Это более чем реально — имеем два дата-центра и теряем связность между ними. Встречается даже в "большом" Интернете с завидной регулярностью.
IB>Также хочу заметить: IB>1) В модели отсутствует центральный узел. А он необходим в распределенных БД для координации транзакций.
Не нужен совершенно. Читаем про http://en.wikipedia.org/wiki/Byzantine_fault_tolerance , в частности про http://www.pmg.lcs.mit.edu/bft/
И существование центрального узла НИЧЕГО не меняет, CAP-теорема точно так же применима.
IB>2) Теорема накладывает ограничения не на облачные технологии в частности, а на распределенные системы вообще. В http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf повествование ведется с отсылками на Web сервисы.
И что?
IB>3) Формальная модель в рамках которой формулируется теорема (http://read.pudn.com/downloads95/ebook/386159/Distributed.Algorithms.pdf) не опирается на стандартную сетевую модель OSI, использующуюся в реальных сетях.
Формальная модель работает с ФОРМАЛИЗАЦИЕЙ каналов связи.
IB>Availability и Partition tolerance могут быть обеспечены как на транспортном уровне (TCP), так на более вышележащих уровнях, например MSMQ.
Не могут.
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.
Учимся читать. Если сильно ослабить строгое требование consistency, то можно достичь её на практике в AP-системах. Eventual consistency означает, что агенты могут видеть разное состояние системы и лишь при t->inf они достигнут консенсуса.
Этого достаточно для ряда систем (самая крупная подобного вида — это BGP), но совершенно недостаточно для того же примера бронирования билетов.
Здравствуйте, Cyberax, Вы писали:
G>>Это кстати основная слабость cap теоремы. Она не описывает понятия доступности (availability). Будет ли это недоступность узла, или всей системы, или просто ожидание завершения транзакции, как в обычных БД. C>Это означает полную недоступность всей системы из-за невозможности достоверно узнать в каком она состоянии.
Еще раз, что означает "недоступность", не количественно, а качественно.
1) Отваливается соединение\возвращается ошибка при любом запросе
2) Возвращается ошибка при попытке обратиться к бд\таблице\диапазону индексов, где было изменение
3) То же что выше, но не ошибка, а ожидание завершения
C>На практике можно слегка ослабить требования к consistency, понадеяться на "авось", и пережить некоторые типы сценариев отказа.
Это кстати легко, вот Оракл даже сериализуемости честной не обеспечивает, но живет как-то с не консистентными изменениями.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Cyberax, Вы писали:
G>>>Это кстати основная слабость cap теоремы. Она не описывает понятия доступности (availability). Будет ли это недоступность узла, или всей системы, или просто ожидание завершения транзакции, как в обычных БД. C>>Это означает полную недоступность всей системы из-за невозможности достоверно узнать в каком она состоянии. G>Еще раз, что означает "недоступность", не количественно, а качественно. G>1) Отваливается соединение\возвращается ошибка при любом запросе G>2) Возвращается ошибка при попытке обратиться к бд\таблице\диапазону индексов, где было изменение G>3) То же что выше, но не ошибка, а ожидание завершения
А вот меня как раз интересует недоступность количественно. Потому что "качественной" доступности в природе (в отличие от математики) вообще не бывает. Поэтому в реальности availability — это не bool, а число в диапазоне [0..1). Теорема, которая это не учитывает, инженерам неинтересна. Инженеров интересует способ получить нужную availability, который, в свою очередь, зависит от частоты сбоев, длительности сбоев, и скорости восстановления после сбоев.
G>Это кстати легко, вот Оракл даже сериализуемости честной не обеспечивает, но живет как-то с не консистентными изменениями.
Тут секрет очень простой, как и везде. Уровни изоляции — это всего лишь договорённость между клиентом и сервером о том, в каких ситуациях сервер берёт на себя гарантии сериализуемости. То есть, даже при уровне read committed можно получить вполне себе сериализуемые протоколы, если клиент ведёт себя соответственно выбранному уровню. Обычно от уровня serializable интуитивно ожидают того, что "теперь можно всё", то есть сервер обеспечит сериализуемость во всех мыслимых сценариях.
Ну да, у Оракла это не так, но в подавляющем большинстве практических случаев клиенты ведут себя аккуратно, так что "дырка" не проявляется.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, gandjustas, Вы писали:
C>>Это означает полную недоступность всей системы из-за невозможности достоверно узнать в каком она состоянии. G>Еще раз, что означает "недоступность", не количественно, а качественно. G>1) Отваливается соединение\возвращается ошибка при любом запросе G>2) Возвращается ошибка при попытке обратиться к бд\таблице\диапазону индексов, где было изменение G>3) То же что выше, но не ошибка, а ожидание завершения
В теории, можно изолировать только те таблицы и записи, которые остались в потенциально конфликтном состоянии. Я не уверен, что это полностью реализовано в какой-либо РБД.
C>>На практике можно слегка ослабить требования к consistency, понадеяться на "авось", и пережить некоторые типы сценариев отказа. G>Это кстати легко, вот Оракл даже сериализуемости честной не обеспечивает, но живет как-то с не консистентными изменениями.
Это неважно, в Оракле есть средства, чтобы избежать конфликтов типа "двойного резервирования места в самолёте".
Речь о том, что мы можем сознательно пойти на возможность таких конфликтов, чтобы ускорить работу. Можно решить, что мы лучше обеспечим непрерывную работу с отказоустойчивостью, а в случае конфликта заплатим компенсацию и отправим пассажира на частном самолёте. Но опять же, это чисто бизнес-решение и к валидности CAP-теоремы отношения не имеет.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Это означает полную недоступность всей системы из-за невозможности достоверно узнать в каком она состоянии. G>>Еще раз, что означает "недоступность", не количественно, а качественно. G>>1) Отваливается соединение\возвращается ошибка при любом запросе G>>2) Возвращается ошибка при попытке обратиться к бд\таблице\диапазону индексов, где было изменение G>>3) То же что выше, но не ошибка, а ожидание завершения C>В теории, можно изолировать только те таблицы и записи, которые остались в потенциально конфликтном состоянии. Я не уверен, что это полностью реализовано в какой-либо РБД.
В любой блокировочной.
C>>>На практике можно слегка ослабить требования к consistency, понадеяться на "авось", и пережить некоторые типы сценариев отказа. G>>Это кстати легко, вот Оракл даже сериализуемости честной не обеспечивает, но живет как-то с не консистентными изменениями. C>Это неважно, в Оракле есть средства, чтобы избежать конфликтов типа "двойного резервирования места в самолёте".
Не используя блокировки — нельзя. Не знаю как сейчас, но раньше оракл этого не делал. Теоретически можно придумать структуру, при которой не потребуются блокировки чтобы избежть двойного резервирования, но я как-то не смог сходу это сделать.
C>Речь о том, что мы можем сознательно пойти на возможность таких конфликтов, чтобы ускорить работу. Можно решить, что мы лучше обеспечим непрерывную работу с отказоустойчивостью, а в случае конфликта заплатим компенсацию и отправим пассажира на частном самолёте. Но опять же, это чисто бизнес-решение и к валидности CAP-теоремы отношения не имеет.
Ну вот отказывается что CAP не так страшна и её не надо пугать детей.
Здравствуйте, gandjustas, Вы писали:
C>>В теории, можно изолировать только те таблицы и записи, которые остались в потенциально конфликтном состоянии. Я не уверен, что это полностью реализовано в какой-либо РБД. G>В любой блокировочной.
В теории можно блокировать только диапазоны ключей.
C>>Это неважно, в Оракле есть средства, чтобы избежать конфликтов типа "двойного резервирования места в самолёте". G>Не используя блокировки — нельзя. Не знаю как сейчас, но раньше оракл этого не делал. Теоретически можно придумать структуру, при которой не потребуются блокировки чтобы избежть двойного резервирования, но я как-то не смог сходу это сделать.
Элементарно можно, по типу compare-and-set алгоритмов.
C>>Речь о том, что мы можем сознательно пойти на возможность таких конфликтов, чтобы ускорить работу. Можно решить, что мы лучше обеспечим непрерывную работу с отказоустойчивостью, а в случае конфликта заплатим компенсацию и отправим пассажира на частном самолёте. Но опять же, это чисто бизнес-решение и к валидности CAP-теоремы отношения не имеет. G>Ну вот отказывается что CAP не так страшна и её не надо пугать детей.
Кроме фундаментального CAP есть и другие проблемы, чисто практические.
И основная из них — скорость света. Абсолютно минимальное время для roundtrip между двумя дата-центрами на разных побережьях США будет порядка 50мс. (на практике около 70мс.), а даже самые простые алгоритмы распределённого коммита будут требовать два roundtrip'а для синхронизации. И во время одного из них БД может быть частично блокирована.
Если же мы делаем прыжки через океан (Европа-США, США-Азия и т.п.), то всё становится ещё хуже — можно легко попасть на секунду на коммит и даже больше.
. Сложность расширяемости — недостатками архитектуры: не заложились на расширяемость. В standalone все то же будет. А еще "много сложностей" RIA объясняется желанием (не пойму только, разработчиков или производителей) притащить подохды со standalone в web. Поэтому получаются монструозные фреймворки с самостоятельной реализацией всего (включая ручные layouts, управление фокусом, обработка событий и прочие радости). И к этим фреймворкам потом еще вручную фиг что прикрутишь (т.е. только работа со стандартнмыи компонентами). Кто работал и пробовал делать удобные для пользователя UI, меня поймет. Далеко не всегда "стандартные" контролы удобны (в чистом HTML сделать нестандартный контрол гораздо проще, чем во фреймоврках и десктопе). А если отбросить подход (мы все делаем как на десктопе) и использовать легковесные подходы, то все становится легко и просто. Кнопка — это не нечто громадное и сложно взаимодействующее по куче аспектов со всем приложением, а любой элемент, биндящийся к action, реагирующий на клик и умеющий поддерживать состояние "disabled". Вот недавно меня коллега спросил, сколько займет реализовать "grid". Ну и изобразил я "grid" в 5 строк на js+html+helpers. Так что это все надуманные проблемы.
Серверный слой, который необходим для работы тонких клиентов (web) 
