"Тонкий сервер (http://abava.blogspot.com/2008/02/blog-post_27.html)" - архитектура "тонкий сервер", когда логика обработки данных переносится на плечи клиента.URL: http://abava.blogspot.com/2008/02/blog-post_27.html
Новость: http://www.opennet.me/opennews/art.shtml?num=14444
>- за сервером остается только следующий функционал:
>a) безопасность
>б) бизнес-логика
>в) проксирование запросов к другим ресурсамчто то терзают смутные сомнения меня по поводу пункта а)
Статья эта должна заканчиваться советом по возможности не использовать эту технологию.
Т.к. функции безопасности в этом случае - фикция, в связи с чем бизнес-логику можно нарушить, лишний трафик между сервером и клиентом, более мощные и следовательно более дорогие машины для клиентов. Чем больше кода на стороне клиента и чем разношерстнее эти клиенты, тем больше багов и сложнее их устранение, и т.д. и т.п.
>Чем больше кода на стороне клиента и чем разношерстнее эти клиенты,вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы. Как он может быть разношерстным? И правится (в случае необходимости) он опять таки в одном месте - на сервере
>Соответственно, одна из основных проблем в разработке "толстых" клиентов - как >заставить пользователя загрузить и обновить приложение, когда что-то в логике >поменялось, здесь не существует. Обработчик автоматически загружается в браузер >клиента, когда он заходит на веб-страницу. Цель вполне очевидна - разгрузить >сервер, сделать приложение более масштабируемым.Боже, какой бред.....
Опус в стиле "пшик" в сторону распределённых вычислений. Почесать затылок и сказать себе честно - мы нихрена не понимаем в распределённых вычислениях или понимаем но нихрена никому не раскажем.
>Опус в стиле "пшик" в сторону распределённых вычислений. Почесать затылок и сказать
>себе честно - мы нихрена не понимаем в распределённых вычислениях или
>понимаем но нихрена никому не раскажем.нет, к распределенным вычислениям это отношения не имеет. Все централизованно, клиенты взаимодействуют только сервером etc. По факту для веб-приложений - это просто систематизация шаблонов проектирования, привязанных к слову JSON. Это там правильно написано - ноги отсюда растут
Интересно, каким образом можно к ЭТОМУ прикрутить безопасность?
>Интересно, каким образом можно к ЭТОМУ прикрутить безопасность?Подразумевается, что сервер отдает только данные в JSON, а JavaScript клиента стоит страницу. Безопасность получается даже выше, за счет выноса логики построения интерфейса с сервера. В обычных условиях сервер вернул те же данные по томуже запросу, но в красивой обертке.
А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных Java-скриптов) и отправить его на сервер?
>А что помешает клиенту сфабриковать подложный запрос (например, при помощи исправления полученных
>Java-скриптов) и отправить его на сервер?Вы же не в базу напрямую лезете, а говорите "хочу новости" и вам отдают блок новостей, тольно не в HTML, а в JSON, то что не положено вам не отдадут, точно также как если бы логика была целиком на сервере.
Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы:
1. неоднозначность выполнения скрипта на клиенте,
2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню будут доступны? Это безопасность?
3. "не в базу напрямую" - это круто, Jumla тоже не напрямую в базу дает лезть, а всего лишь через параметры, можно отправить лекторов к milw0rm.
4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от сбоев решение...
5. >>вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы.
Нет слов. А веб страница где? не на клиенте? Я почему-то думал, что страница живет в клиентском браузере, который может интерпретировать этот код, как ему заблагорассудится.
6. На кой черт проксировать запросы к другим ресурсам? Если ресурс мертв, данные проксика не валидны, если жив - их чудное приложение на клиенте может и само обрабатывать список зеркал, например.
7. Какая бизнес-логика? Кто решает, что будет видеть клиент? сервер? На основе тех данных и параметров, которые я могу задать в отладчике жабаскрипта?А давайте вернемся к отоплению жилья углем - от него дым прикольный... :)
А я вот увидел рациональное зерно в статейке (кроме кеширования запросов к другим серваисам %)
>Сдается мне, получим проблемы децентрализации, от которых старались уйти долгие годы:
>1. неоднозначность выполнения скрипта на клиенте,если уж на то пошло - то даже в HTML'е нет полной однозначности среди отображения
во всех браузерах. Так чем же JavaScript принципиально хуже? Хоть так хоть так пришлось бы
затачивать клиент-код под определенный браузер.
>2. возможность правки кода на клиенте: клиентская часть решает, какие пункты меню
>будут доступны? Это безопасность?ессьно, клиент пусть решает что ему взбредет. Но правомерность его запросов будет определятся на сервере. Это - безопасность.
>4. Кто в этом случае хранит обрабатываемые данные? Клиент? Очень защищенное от
>сбоев решение...Данные путем запросов отправляюццо на сервер, а там уже - как тебе нравится.
Так что да, защита от сбоев лишь в руках админа.
>5. >>вы оcновное в этом подходе не поняли - код не загружается отдельно клиентом. Он получает его с веб-страницы.
>Нет слов. А веб страница где? не на клиенте? Я почему-то думал,
>что страница живет в клиентском браузере, который может интерпретировать этот код,
>как ему заблагорассудится.криво заинтерпретирует - ниче не увидит. (как я говорил, в какой-то степени это справлдливо и для "чистого" HTML) Посему участки кода под разных клиентов должны подгружаццо по его же запросу в результате своих же желаний.
Ну а данные сервак отправляет всем видам клиентом в одинаковом формате.
>7. Какая бизнес-логика? Кто решает, что будет видеть клиент? сервер?
>На основе тех данных и параметров, которые я могу задать в отладчике жабаскрипта?с теми данными, что пожаловал клиенту сервер - делай что угодно :)
Это правомерно твои данные, которые выделенны тебе бизнес логикой.
С помощью нужных (сам, опять-таки, решишь каких) жабоскриптов устроишь себе просмотр в
любимом клиенте (броузере). И при желании - будешь слать новые запросы серверу (которые все также будут проверены той же бизнес-логикой).
Все на месте.
>А давайте вернемся к отоплению жилья углем - от него дым прикольный...
>:)нанюхамшись такого классного дыма - прикольнее сравнивать зеленое с длинным...
Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А те что со скриптами автоматом к "толстым" приравниваются?Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал о таком (компания Нестле такой точно юзала). Там есть сервер, но рулит не многим, транзакции, синхронизация, свой движок для бд, а копия данных все равно на стороне клиента есть(нужных ему и не нужных), которые он повредить может. А когда данные на стороне сервера, сервер ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты, то какой же он "толстый".
>Каша какая-то. Покажите мне "тонкий" клиент на хтмл но без java/javascript? А
>те что со скриптами автоматом к "толстым" приравниваются?читай сабж.
Речь о "тонком" сервере, а не о "толстом" клиенте.
Не нужно тут в поломанный телефон играть...
>Вот для меня "толстый" клиент, это например продукт ЕМЕ, может кто слышал
>о таком (компания Нестле такой точно юзала). Там есть сервер, но
>рулит не многим, транзакции, синхронизация, свой движок для бд, а копия
>данных все равно на стороне клиента есть(нужных ему и не нужных),
>которые он повредить может. А когда данные на стороне сервера, сервер
>ими распоряжается, а на стороне клиента только рендереинг и простейшие скрипты,
>то какой же он "толстый".Ну, сам придумал что тема о "толстом" клиенте - и понесло...
Не было об этом разговора.
так бреттодо или бреддото?
>Ну, сам придумал что тема о "толстом" клиенте - и понесло...
>
>Не было об этом разговора.А что, связка "тонкий" клиент и "тонкий" сервер может работать?
>А что, связка "тонкий" клиент и "тонкий" сервер может работать?напиши статейко и проанализируй это.
Какие-то глупости пошли уже не по существу