Как на J2ee делается smart-client ?

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

И потом автономно работает или обновляется частично или работает через веб.

На каких технологичных кусках это делается ?



Как лучше- делать универсальный интерфейс через браузер ?

Или все-таки иногда SWING ? Но ведь этот вариант неуниверсален ?



Спасибо

Одно из решений Eclipse RCP с реализацией Update Site
или его коммерческий аналог IBM Workplace

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

V>Как на J2ee делается smart-client ?
V>т.е. приложение которое загружается, частично инсталлируется,т.е. второй раз
V>загружаться не будет,

Поищи по ключевым словам Java Web Start и JNLP.



V>Как лучше- делать универсальный интерфейс через браузер ?
V>Или все-таки иногда SWING ? Но ведь этот вариант неуниверсален ?

Вопрос из разряда to beer or not to beer...
Говорят, что web поуниверсальней, но у меня перед глазами яркий пример на swing: клиент вообще грузится по сети при каждом запуске — достаточно криворуко, но в тепличных условиях практической неограниченности ресурсов локальной сети — работает... В общем зависит от условий решаемой задачи...

V>Поищи по ключевым словам Java Web Start и JNLP.

Интересно...

Я читал их White Paper,
пока не нашел как сопрягается именно с J2EE системами,
это важно т.к. системы уровня предприятия имют большую инфраструктуру с которой надо стыковаться,
и лучше как-то ненапряжно — не искусственно нагораживая свои решения,
т.е. вероятно это как-то предусморено.


Не предполагаете как?


V>>Как лучше- делать универсальный интерфейс через браузер ?
V>>Или все-таки иногда SWING ? Но ведь этот вариант неуниверсален ?

V>Вопрос из разряда to beer or not to beer...
V>Говорят, что web поуниверсальней, но у меня перед глазами яркий пример на swing: клиент вообще грузится по сети при каждом запуске — достаточно криворуко, но в тепличных условиях практической неограниченности ресурсов локальной сети — работает... В общем зависит от условий решаемой задачи...


Спасибо.

У меня системя- уровня предприятия,
т.е. довольно сложная логика. Грузиться каждый раз — неразумно.

Swing тогда впишется в Java Web Start и J2EE?

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

V>>Поищи по ключевым словам Java Web Start и JNLP.

V>пока не нашел как сопрягается именно с J2EE системами,
V>это важно т.к. системы уровня предприятия имют большую инфраструктуру с которой надо стыковаться,
V>и лучше как-то ненапряжно — не искусственно нагораживая свои решения, т.е. вероятно это как-то предусморено.

основная идея — динамическое построение jnlp-файла. т.е. запрос обрабатывает сервлет, который в общем случае на основе параметров запроса может скорректировать командную строку запуска webstart-приложения. соответственно, насколько сложным будет клиент и разнообразной его командная строка — все можно разрулить этим сервлетом

V>>>Как лучше- делать универсальный интерфейс через браузер ?
V>>>Или все-таки иногда SWING ? Но ведь этот вариант неуниверсален ?

V>>Говорят, что web поуниверсальней, но у меня перед глазами яркий пример на swing: клиент вообще грузится по сети при каждом запуске — достаточно криворуко, но в тепличных условиях практической неограниченности ресурсов локальной сети — работает... В общем зависит от условий решаемой задачи...

V>У меня системя- уровня предприятия, т.е. довольно сложная логика. Грузиться каждый раз — неразумно.

это странно, что в том примере грузится каждый раз. наверное, что-то неправильно на apache, впрочем это не суть данного топика
реально это не так, с ровными руками и работать будет нормально
web start работает таким образом, что приложение кэшируется на клиенте. при очередном запуске web start проверяет, не изменились ли jars, и скачивает только измененные (что, собственно, облегчает обновление приложения — не надо бегать по клиентским местам и что-то переставлять)

V>Swing тогда впишется в Java Web Start и J2EE?

да вполне

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



V>Спасибо.

V>У меня системя- уровня предприятия,
V>т.е. довольно сложная логика. Грузиться каждый раз — неразумно.

V>Swing тогда впишется в Java Web Start и J2EE?

Что вы подразумиваете под словом J2EE?
Если у вас система уровня предприятия, выделяете сервер, на нем реализуете какую угодно сложную логику, это ваш middle-уровень. Как с него работать с БД, это уже отдельная тема, как варианты hibernate, entity bean, JDBC. У этого middle-уровня выделяем API которое будет доступно клиентам (тонкий, толстый без разницы), делайте его доступ через (RMI, session bean, web service, ...).
И пишите клиента.

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

T>Что вы подразумиваете под словом J2EE?
T>Если у вас система уровня предприятия, выделяете сервер, на нем реализуете какую угодно сложную логику, это ваш middle-уровень. Как с него работать с БД, это уже отдельная тема, как варианты hibernate, entity bean, JDBC. У этого middle-уровня выделяем API которое будет доступно клиентам (тонкий, толстый без разницы), делайте его доступ через (RMI, session bean, web service, ...).
T>И пишите клиента.

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

Да, я пишу четырех -звенную архитектуру. Не знаете какой четвертый слой?

Дело вот в чем:
Действителльно есть серьезная инфраструктура создания приложения
на J2EE -hibernate, entity bean, JDBC,
но все это бизнес-часть,

а само приложение это вообще-то что видно пользоватлю,

поэтому надо с одной строны использовать то что было,
а с дургой строны применить современную технологию —

т.е. Smart-client в виде когда он кэширует и функции и данные на клиенте
т.е. Swing.

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

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

Спасибо, понятно все.

V>>Swing тогда впишется в Java Web Start и J2EE?
C0s>да вполне

А не скажете какая вообще существует инфраструктура стыковки Swing и J2EE ?
(толстый интерфейс и бизнес слой)

По Ajax — вручную ? Или как не вручную?

Или По обращению к бинам с клиента через интенет — я слышал что это всемерно проклятое решение,
ввиду крайней неэффективности.

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

V>А не скажете какая вообще существует инфраструктура стыковки Swing и J2EE ?
V>(толстый интерфейс и бизнес слой)

V>По Ajax — вручную ? Или как не вручную?

про ajax ничего не скажу, вроде это out-of-scope этого обсуждения

V>Или По обращению к бинам с клиента через интенет — я слышал что это всемерно проклятое решение,
V>ввиду крайней неэффективности.

это если сервер выбран неудачно, то будет неэффективно. но у нормальных производителей все давно отточено и по стандартам iiop
session bean client, общающийся обычно по rmi-over-iiop — это эффекитвнее всего остального, ибо трафик бинарный. если задумываться над количеством вызовов со стороны клиента и не делать их слишком много, то работать будет хорошо

тут другое:
аспект доступа через интернет — сложно сделать безопасно, открыть https на весь мир и иметь web-интерфейс — нормально, открыть ejb — сродни безумию
для доступа со стороны толстых клиентов лучше создавать vpn поверх защищенного транспорта
но это уже деплоймент, который к java отношения вообще не имеет, и с вопросами относительно этого надо ходить к админам

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

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

V>>А не скажете какая вообще существует инфраструктура стыковки Swing и J2EE ?
V>>(толстый интерфейс и бизнес слой)

V>>По Ajax — вручную ? Или как не вручную?

C0s>про ajax ничего не скажу, вроде это out-of-scope этого обсуждения

Многие просто делают именно так.
И "особенно эффективно" — именно так.

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

я думаю поэтому — не из другой области.

V>>Или По обращению к бинам с клиента через интенет — я слышал что это всемерно проклятое решение,
V>>ввиду крайней неэффективности.

C0s>это если сервер выбран неудачно, то будет неэффективно. но у нормальных производителей все давно отточено и по стандартам iiop
C0s>session bean client, общающийся обычно по rmi-over-iiop — это эффекитвнее всего остального, ибо трафик бинарный. если задумываться над количеством вызовов со стороны клиента и не делать их слишком много, то работать будет хорошо


Я вот читал что применяются системы типа Light-weight containers,
с control-inversion,
вместо тяжелых J2EE потому что гонять много раз по сети даже бинарный трафик- ненормально,
а именно это делает класический J2EE.


C0s>тут другое:
C0s>аспект доступа через интернет — сложно сделать безопасно, открыть https на весь мир и иметь web-интерфейс — нормально, открыть ejb — сродни безумию
C0s>для доступа со стороны толстых клиентов лучше создавать vpn поверх защищенного транспорта
C0s>но это уже деплоймент, который к java отношения вообще не имеет, и с вопросами относительно этого надо ходить к админам.

Вообще J2EE бина проектировались лдя работы через интеренет,
поэтому должен быть обеспечен слой авторизации,
под "простым програмным доступом", типа идентификации http, включения ssl,и.т.д
но не заметно для программера.

Поэтому ругаются именно на крайнюю неэффективность J2EE бинов.

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

Все больше считают J2EE вчерашним днем,
не оправдашим надежд,
уходя на легковесные системы.

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

V>>>Говорят, что web поуниверсальней, но у меня перед глазами яркий пример на swing: клиент вообще грузится по сети при каждом запуске — достаточно криворуко, но в тепличных условиях практической неограниченности ресурсов локальной сети — работает... В общем зависит от условий решаемой задачи...

V>>У меня системя- уровня предприятия, т.е. довольно сложная логика. Грузиться каждый раз — неразумно.

C0s>это странно, что в том примере грузится каждый раз. наверное, что-то неправильно на apache, впрочем это не суть данного топика
C0s>реально это не так, с ровными руками и работать будет нормально
C0s>web start работает таким образом, что приложение кэшируется на клиенте. при очередном запуске web start проверяет, не изменились ли jars, и скачивает только измененные (что, собственно, облегчает обновление приложения — не надо бегать по клиентским местам и что-то переставлять)

Была похожая проблема. Использовали JWS и заметили, что после каждого (пусть даже незначительного) update'а приложения, на клиент качались все jar'ы, даже те, которые не менялись. Как оказалось проблема была не JWS а в Tomcat и JDK:jar

jar does not preserve file modification dates during extract
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4225317

ExpandWar doesn't set the lastModified attribute
http://issues.apache.org/bugzilla/show_bug.cgi?id=33636

При распаковке war'а происходила потеря даты модификации файлов и в результате, при использовании basic download protocol, клиентский JWS выкачивал все jar'ы заново.

Решения:
1. использовать version-based download protocol, вместо basic
2. распаковке war'а вместо jar следует пользоваться unzip (баг в JDK все еще не пофикшен)
3. использовть Tomcat версии 5.5.9 и позднее

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

D>Была похожая проблема. Использовали JWS и заметили, что после каждого (пусть даже незначительного) update'а приложения, на клиент качались все jar'ы, даже те, которые не менялись. Как оказалось проблема была не JWS а в Tomcat и JDK:jar

D>При распаковке war'а происходила потеря даты модификации файлов и в результате, при использовании basic download protocol, клиентский JWS выкачивал все jar'ы заново.

D>Решения:

jar-ы клиентского приложения не надо в war класть, и раздавать их задача чего-нибудь нормального типа apache

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

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

D>>Была похожая проблема. Использовали JWS и заметили, что после каждого (пусть даже незначительного) update'а приложения, на клиент качались все jar'ы, даже те, которые не менялись. Как оказалось проблема была не JWS а в Tomcat и JDK:jar

D>>При распаковке war'а происходила потеря даты модификации файлов и в результате, при использовании basic download protocol, клиентский JWS выкачивал все jar'ы заново.

D>>Решения:

C0s>jar-ы клиентского приложения не надо в war класть, и раздавать их задача чего-нибудь нормального типа apache

Зависит от задачи. Почему бы и не положить? Кроме того, поддержку version-based download protocol для apache надо еще реализовать, а для Tomcat'а вполне подойдет существующий JNLPServlet.

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

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

D>>>Решения:

C0s>>jar-ы клиентского приложения не надо в war класть, и раздавать их задача чего-нибудь нормального типа apache

В качестве еще одного возможного варианта решения задачи подойдет. Согласен.