Ну доклад вводный. Оратор не блеск какой, но мне понравилось. Может многие вещи банальны или спорны, однако от вас я и этого не услышал.   
Кстати, если отбросить рекламную составляющую, а чем она плоха? Ну посоветуйте что нить путное тогда..   

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


не могу по советывать ничего в плане расширения аппаратных платформ ибо опыт в этом отсутствует. 

serger, вы пояснить можете, по поводу толщины ПО и ajax, это я туплю?

Не помню такого, если честно, я ж тоже не всё внимательно слушал..
Ну часто бывает, что докладчики сбиваются и тп., всякое бывает - сам часто такие перлы выдавал!   

Вопрос по поводу толщины клиента очень спорный.

Если по уму -  тонкий клиент, это приложение не обремененное никакой логикой, кроме логики отображения.


Впринципе, я не видел чтоб JS выполнял какую-либо логику, кроме отображения, ну, может еще валидацию (но в любом случае она должна быть дублирована на стороне сервера).

Другое дело Flash - тут вполне может быть логика не относящаяся к отображению, так браузер загрузивший какое-нибудь flash приложение  уже толстый клиент? Или еще тонкий?

Добавлено через 7 минут и 49 секунд
Хотя если говорить о flash - то браузер тут как бы не причем. Flash может вполне обойтись и без него. 

Это сообщение отредактировал(а) Vasay - 14.12.2009, 15:49

Vasay, ну ваше определение, ИМХО, весьма логично.

в прочем как и ява-аплет. видимо действительно, с ajax он перегнул.

ок, понял, спасибо.

Это сообщение отредактировал(а) DimW - 15.12.2009, 09:48

 В свое время, в документации по Oracle 9I я прочитал "Режим клиент/сервер устарел". В то время это заявление меня это сильно озадачило. 
Принятие решения об архитектуре приложения вопрос весьма важный. Заказчик говорит - "У нас всегда будет мало клиентов, мы всегда будем работать в локальной сети". Он обманываться рад. Такие прогнозы как правило не оправдываются.
Писать бизнес логику и презентационную логику на ХП, извините меня это решение не только черевато последствиями, но - день вчерашний. БД должна информацию эффективно сохранять и извлекать, а не картинки делать (хотя и может). Попробуйте усложнить такое приложение и выполнить одновременно больше запросов и выяснится, что ваше приложение масштабировать невозможно. Его надо переписывать.
Использование Ajax диктует свои права. Валидация на клиенте запросы с клиента информации и ее обработка. Это, извините, и есть толстый, а иногда и претолстый клиент. Я думаю никого не обманывает эвфемизм "rich".
После нескольких лет работы с JEE и чтения авторизованных курсов SUN по архитектуре распределенных приложений я для себя решил, что ребята из Oracle правы и теперь, при разработке даже небольших приложений я сначала спрашиваю себя - а не сделать ли его Web приложением, даже если сначала и база данных и сервер приложений будут на одной машине. Это конечно первоначально снизит производительность по сравнению с архитектурой клиент/сервер, но потом ...

пример последствий, привести можете?


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


странно вы рассуждаете, как будто при использовании веб приложения запросы выполняются вне БД  


ну давайте подумаем как валидация делает вдруг "клиента толстым "...
по скольку вы реализуете БЛ на аппсерве, то логично бы было валидировать что то на том же уровне, т.е. грубо говоря вы пишете сервлет который лезет в БД, что то там берет, потом э то что то вы анализируете в сервлете и возвращаете в качестве ответа ассинхронного запроса(ajax) true или false. и что же в данном случае делает клиента "толстым"?

Лекцию посмотрел после предыдущего сообщения. По-моему зря вы его так сильно, в грязь.
Оратор из него никудышний, конечно. Про пул подключений толком сказать не мог, как будто это всем понятно. От того и вопрос возник, на который он так же невразумительно ответил.
Когда говорил о кэшировании забыл, что на клиенте можно кэшировать помимо куки в объекте JavaScript. По поводу кэширования в базе не знает, что Oracle позволяет кэшировать информацию клиентского сеанса в оперативной памяти. Ясно, что парень работает со специфическими интернет приложениями. Однако дело свое, похоже знает и многие аспекты доклада перекликаются с тем, что предлагает SUN в своих курсах и я с этим согласен.

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

По поводу Ajax еще добавлю. Думаю сам по себе он не обязывает делать толстого клиента, но стимулирует и подталкивает. Еще недавно пуристы JEE говорили - на клиенте только HTML и больше ничего. Я видел недавно одно приложение где всего то была одна страница, а дальше все EXT-GWT. При этом серверная часть только и делала, что пасовала задачи на сервер базы. Крайности всегда отвратительны.

Ну вспомните историю.
- Сначала у нас были ES, которые делали все, а клиент перфокарты или терминал.
- Затем PC и десктоп приложения.
- Потом мы с трудом по капле "выдавливали из себя раба" переходили на клиент/сервер
  (сервер мощный - пусть делает все, вплоть до презентационной логики)
- Потом пришло отрезвление, каким бы мощным не был сервер базы данных, возможности его не безграничны. И мы окунулись в распределенные приложения.
- Сегодня кластеризация и кэширование стало общим местом.
- Что то будет завтра?
 

mbasil, по поводу аратора я не высказывался, просто высказал свое субъективное мнение по поводу полезности лекции.

To DimW

Последствия выполнения все на сервере приложений в ХП:
 - Приложение плохо структурировано (мы же говорим о корпоративных приложениях). Вспомните старую книгу Тейта "Горький вкус Java" - она до сих пор актуальна.
 - Сервер базы данных вместо эффективной выборки данных и выполнения DML занимается созданием страниц.

Были у меня на курсе работники одного банка, в котором начальство вдруг решило, что все филиалы должны работать непосредственно на мощном сервере, который они приобрели. Приложение на ХП просто привело к колапсу сервера.
-------
Использовать ХП обязательно надо, но для тех задач, для которых они хорошо подходят. ХП это условно пакетные задачи, которые должны обрабатывать данные непосредственно на сервере базы без пересылки по сети больших объемов и решать специфические задачи. Пример, который считаю характерным - закрытие банковского операционного дня: надо пересчитать остатки по счетам на конец рабочего дня и выполнить ряд других операций за один вызов. Пример отрицательный - один мой слушатель рассказывал, что для разборки больших объемов XML они использовали парсер в виде хранимой процедуры на Java. Результат понятен.
-----------
Валидация и не только. Я уже только что писал свое мнение, что Ajax стимулирует переносить часть обработки информации на клиента - не только обработки презентационной логики (это само собой подразумевается), но и части бизнес логики. А что это, как не толстый клиент. Когда нам говорили "на клиенте - только HTML) я полагал, что это долго не продлится. Тенденция сегодняшняя налицо. SUN даже не переписывает курс по шаблонам JEE, так как мы находимся в переходном периоде: часть шаблонов JEE устарела, а новые неоднозначны.
------
Если бы реализации, использующие Ajax работали только так, как вы это описываете, то разумеется говорить о "толстом" клиенте было бы нельзя. Но сегодня все больше работы переносится на клиента. Одни всем известные фреймворки чего стоят (уже упоминавшиеся мной EXT, GWT, Dojo и т.п). Бросьте, если вам эта тенденция не нравится, это не означает, что ее нет.  

Это сообщение отредактировал(а) mbasil - 16.12.2009, 10:45

Ну да, в лекции нет технических подробностей, материал преподнесен через призму специалиста, которому ближе Интернет, чем корпоративные приложения, но надо признать - он неплохо очертил необходимость количественного подхода к оценке качества архитектуры распределенных приложений. Мы как разработчики часто забываем о необходимости тестирования под нагрузкой и на репрезентативных данных. Мы больше заботимся о функциональных качествах приложения. Задачи архитектора в другой плоскости. К сожалению в России разделение труда в нашей области плохо  приживается. Я даже горжусь, что я сам себе системный аналитик, архитектор, девелопер, кодер, тестировщик и администратор базы данных. Есть такое подозрение, что я что-то делаю плохо. Психология разработчика плохо вяжется, например с психологией архитектора.  

Очень понравилось - постоянно себя приходится в связи с этим изменять в течении дня.

mbasil, 

Спасибо за интересные посты, единственное, я все же не согласился бы с тем что Ajax подталкивает нас делать на JS толстого клиента.  Современные JS/Ajax фрэймворки даже валидацию выполняют на стороне сервера и вряд ли в ближайшее время начнут выполнять какую-либо логику (кроме логики "рисования").

вы случайно не про oracle HTML DB( или как его сейчас - APEX)?   
mbasil, мы говорим видимо о разных вещах - вы, как можно, а я как нужно.
ведь ни кто насильно не заставляет вас, формирование интерфейсов выносить на уровень БД, пусть этим занимается сервер приложений.
по этому утверждение что ХП это плохо в данном контексте - не верно.


да, то что не запрещено,  то можно. 


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

Это сообщение отредактировал(а) DimW - 16.12.2009, 11:57