Я работаю в фирме, которая разрабатывает и суппортит систему программного обеспечения американских школ. Система выглядит как рабочий стол в окне браузера, т.е. пользователь в браузере логинится, у него загружается что-то типа удаленного десктопа, с таскбаром, окнами, рабочим столом с ярлыками, меню "пуск" и кучей приложений. Все это в окне браузера, написано на PHP, JavaScript и HTML. В целом систем очень неплохая, правда жрет достаточно много трафика. Мне очень инетересно, можно ли что-то подобное реализовать средствами Java. Т.е. сделать в аплете некое подобие десктопа удаленной операционной системы, с полноценными элементами управления, окнами, ярлыками, панелями. Насколько это сложно реализовать?

Можно.
Сложно.

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

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

Единственное, что можно - заменить PHP на JSP(JSF) и более активно использовать AJAX. Если это конечно возможно сделать на клиентской стороне.

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



Не соглашусь.
1. В случае с аплетом можно больше логики вынести на клиента и часть операций можно проводить на клиенте, без обращения к серверу.
2. Можно использовать для передачи бинарные протоколы и сжатие.
3. Можно использовать нотификации от сервера, вместо постоянных опросов состояния. Открыть на сервере порт, для масштабного проекта - не проблема.
4. Yahoo в своё время провела исследование, согласно которому браузеры очень хреново кешируют картинки и скрипты. Даже если у них включено кеширование, очень часто они заново грузят все скрипты и картинки.
В общем пути для оптимизации - есть. Насколько существенную экономию трафика она даст - вопрос остается открытым.

По-моему JavaScript тоже может с этим справится.


Ну это не факт - я бы не рискнул открывать много портов - вот одного достаточно - 80 для HTTP. Это раз. Во вторых - HTTP 1.1 прекрасно сжимает. Так же тот же DWR тоже может компрессировать.


Опять же - не факт. Да я бы сам будучи сис.админом долго бы ругался и плевался, если бы меня попросили открыть еще каккой-то порт, по которому будут бегать двоичные данные.


Ну они тоже развиваются.

Тот же IE очень долго подымает JVM. И версия JVM у него еще та. Значит надо будет загружать JRE. Что вообщем-то трафик пожрет немерянно в любом случае. Думаю, что хороший интерфейс на AWT написать удет дорогого стоить. Значит Swing -> грузим JRE.
А тот же ExtJS весит всего 500 Кб. По сравнению с JRE просто слезы.

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

У Java возможностей больше. Например прочитать файл с диска и отобразить его содержимое, можно без обращения к серверу. На AJAX придётся вначале закачать его на сервер, а потом уже получить их с сервера.





1. Я решительно не понимаю, как количество открытых портов влияет на безопасность. Если в нашем приложении есть баги, то как улучшит ситуацию, то что приложение будет работать через один 80 порт, а не через два или три произвольных порта?
2. Это не дело админа указывать, как разрабатывать приложение.




Это недавние исследование, как раз посвящённое AJAX.



Это сам ExtJS, а сколько будут весить скрипты написанные с его использованием?
Например, сколько весить текстовый редактор в Google Docs?

Еще у апплетов преимущество в том, что UI выглядит везде одинаково. В отличии от JS, не нужно учитывать специфику браузера, ибо даже <input type='file'> имеет разное поведение в IE и FF.
Кроме того, мне кажется те времена когда 1 раз скачать 20 метров было слишком дорогим удовольствием уже прошли. JRE устанавливается очень просто, в несколько кликов. Плюс еще Java Kernel анонсируют...




полностью согласен. 
 

Это сообщение отредактировал(а) powerOn - 30.12.2008, 23:52

Ну вообщем-то тут надо решать исходя из потребностей и возможностей.
У Java несомненный плюс - работает практически везде одинакого и имеет все-таки больше возможностей. Может апплет и неплохое решение.


Если в Интернет выставлен какой-либо компьютер и на нем открыто несоклько портов - это значит что есть не одна дырка на порту 80, а больше. Значит через них будут пытаться пролезать. И сделать ту же DoS атаку - никаких проблем.


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

Спасибо всем высказавшимся. Думаю, я для начала я попробую написать пару апплетов именно для внутреннего использования,  а не для конечных пользователей, ибо некоторые девелоперские приложения крайне неудобные и медленные. Просто сделаю аналог на аплете с учетом тех недостатков, которые всем мешают, но никто не хочет лезть их фиксить, ибо писалось неизвестно когда и кем, а работы и без этого хватает. И попытаюсь встроит в общий интерфейс системы, что бы было тоже самое окошко во фрейме, но внутри него уже не html а апплет. Буду пользоваться сам, пара хороших друзей как минимум попробуют. А если работать будет действительно лучше, то рано или поздно начальство тоже заметит, что некоторые пользуются каким-то другим файловым менеджером или утилитой для синхронизации версий и тоже как минимум пропробуют. А там кто знает, во что это выльется.... Если приживется, то у меня уже будет возможность иногда отвлечься от рутины ковыряния в огромных запутанных php-файлах и пописать на своем любимом языке для пользы тех кто сидит "здесь", в офисе, а не где-то "там, за океаном". Кроме того, появится своя "свой огород", где меня никто не сможет заменить, т.к. никто даже отдаленно не имеет понятия о java. 
Донести java до конечных пользователей врядли получится, будут отчаянно сопративляться установке jre, да и никто из "тамошнего" начальства на это ни за что не согласится. Хотя java-kernel может в корне поменять ситуацию. 

Сам по себе открытый порт не опасен. Опасность представляют ошибки которые есть в приложении которое работает по этому порту. И минимизировать надо количество приложений доступных извне, а не количество портов которые они используют. А приложение то у нас и так одно. Если веб приложение сделать доступным по 80 и 8080 порту, это как-то уменьшит безопасность системы?
Насчёт DoS атаки, тоже не вижу почему дополнительный открытый порт как-то способствует DoS атаке.




Рекомендации по защите это пожалуйста, но вот ультиматумы типа: "этот порт я не открою" это не дело.

Полностью согласен. Но где уверенность в том, что приложение сможет себя защитить от всяких любителей что-то поломать ?

Про "порты" :

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

Эффективность HTTP, случается, недооценивают. Я же согласен с мнением , что "HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня". 

PS.

to Tembegon


Для "в корне", наверное, лучше сменить работу   




  

Это сообщение отредактировал(а) COVD - 4.1.2009, 02:12