Скажем, складская программа. БД PostgreSQL. Возможность работы "толстого" и "тонкого" (web браузер) клиента. Среда - локальная сеть или Internet соответственно. Ввод данных, получение прогностики, отчетов и т.п.
Повторюсь, какими бы средствами вы реализовали подобное? Спасибо.

P.S. Cам не программист, но непосредственно связан с разработкой.

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

О СУБД уже сказали. Я бы выбор поддержал.

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

Видимо толстый и тонкий клиенты будут использовать одни и те же программные компоненты. Чтобы проще ими управлять неплохо было бы использовать какой-нибудь облегченный контейнер компонентов, например, Spring или PicoContainer. Кроме того, в Spring входит множество собственных различных компонентов, решающих некоторые часто встречающие задачи. А вообще в данном случае использовать контейнер или нет - это как кому нравится. Каких-то стопроцентно очевидных плюсов, заметно облегчающих работу у контейнеров компонентов нет. Хотя это сугубо имхо мнение, хотелось бы услышать что думают другие.

При разработке веб-приложения настоятельно рекомендовал бы использовать какой-нибудь веб-фреймворк, что заметно упрощает процесс разработки. Самый популярный фреймворк - это Struts. Но популярный не значит лучший, на мой взгляд это один сплошной антипаттерн. Рекомендовал бы посмотреть опять-таки в сторону Spring. Вот здесь эта тема обсуждалась - http://forum.vingrad.ru/index.php?showtopic=64922&hl=. Был еще опыт использования Turbine, можно сказать что положительный.

Если архитектура системы будет трехзвенной, то есть предполагается еще и слой объектов, к которым клиенты системы будут обращаться удаленно, то придется кроме вышеописанного использовать еще и какую-то технологию вызова удаленных методов. Если не предполагается никакой кроссплатформенности и интероперабельности, то целесообразно использовать Remote Method Invocation. RMI имеется в поставке JDK. Но это точно целесообразно если все работает в локальной сети потому как в RMI передаваемые в сети объекты размер имеют не маленький. Могут возникнуть проблемы с файрволами если закрыты используемые RMI порты. Если проблема мотивацией сисадмина не решается, стоит посмотреть в сторону протоколов Hessian или Burlap.

Тема о генераторах отчетов обсуждалась здесь - http://forum.vingrad.ru/index.php?showtopic=54897&hl=.

Это сообщение отредактировал(а) tux - 20.10.2005, 03:15

5 коп по поводу того, что написал tux
1. Поддержку распределенных транзакций можно реализовать и без полновесных серверов приложений. Использовать можно, например, JOTM, который можно встроить в томкат, да и в любое java приложение.
2. Turbine используем постоянно. Вещь неплохая.
3. Про Axis-то чего забыли?

Это сообщение отредактировал(а) pvo - 20.10.2005, 15:09

Цитата

Могут возникнуть проблемы с файрволами если закрыты используемые RMI порты.

Как раз RMI и должен уметь эти проблемы обходить. В таких случаях клиент общается с сервером через HTTP протокол и RMI это поддерживает. У него есть несколько встроенных протоколов, и он их пытается использовать при возникновении проблем с соединением. Собственно, как я понимаю, в этом и заключается одно из удобств применения RMI.

Спасибо за ответы, изучаю матчасть .
Небольшой вопрос: какое место здесь может иметь JBJBoss?
Спасибо.

Цитата(pvo @ 20.10.2005, 20:08)

Про Axis-то чего забыли?

Не забыли, просто по-моему в данном случае его использование неоправданно.

Цитата(COVD @ 20.10.2005, 20:21)

клиент общается с сервером через HTTP протокол и RMI это поддерживает

Действительно умеет, не знал.

Цитата(Guest @ 20.10.2005, 23:34)

какое место здесь может иметь JBJBoss?

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

tux
Разобрался, спасибо за подробности!

Цитата

Как раз RMI и должен уметь эти проблемы обходить

Да, RMI использует HTTP-туннелирование для прохождения трафика через файерволы.

Цитата(vzf @ 24.10.2005, 15:31)

Да, RMI использует HTTP-туннелирование для прохождения трафика через файерволы.

Не хочется разбираться, поэтому задам вопрос
Возможно совместить трафик RMI когда используется HTTP-туннелирование с обычным HTTP-трафиком?

Мне бы тоже было интересно. HTTP - туннелирование имеет смысл при использовании 80 порта (иначе файервол запретит), а он занят для веб. Т.е. RMI должен быть как-то интегрирован с веб-сервером.
Мы обошли эту проблему, создав сервлет, который обслуживает клиентов, не смогших соединиться напрямую через сокеты. Простое доморощенное решение. Но интересно, насколько просто и элегантно это сделать в RMI? Кто-нибудь делал?

Я сам не делал, не знаю. Но вот, что об этом говорят умные люди. Тут правдо про брандмауэры, но все равно думаю по теме.

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

Поскольку транспортный уровень RMI открывает динамические соединения сокетов между клиентом и сервером, трафик JRMP обычно блокируется большинством брандмауэров. К счастью, разработчики RMI предвидели эту проблему. Ее решение обеспечивается самим транспортным уровнем RMI. Для прохождения через брандмауэры RMI использует HTTP-туннелирование, помещая вызовы RMI в запрос HTTP POST.

Теперь исследуем, как работает HTTP-туннелирование трафика RMI, более детально рассмотрев возможные сценарии: RMI-клиент, сервер или оба вместе могут исполняться за брандмауэром. На следующей диаграмме показан сценарий, когда RMI-клиент, расположенный за брандмауэром, взаимодействует с внешним сервером.
RMI-клиент, расположенный за брандмауэром, взаимодействует с внешним сервером

В этом сценарии транспортный уровень при попытке установить соединение с сервером блокируется брандмауэром. Если это происходит, транспортный уровень RMI автоматически повторяет попытку, помещая данные вызова JRMP в запрос HTTP POST. Заголовок HTTP POST для вызова выглядит так:

http://hostname:port

Если клиент находится за брандмауэром, важно также установить в соответствующее значение системное свойство http.proxyHost. Поскольку большинство брандмауэров распознают HTTP-протокол, указанный прокси-сервер должен быть способен направлять запрос прямо в порт, который прослушивает удаленный сервер. Как только заключенные в HTTP данные JRMP принимаются сервером, они автоматически декодируются и отправляются по назначению транспортным уровнем RMI. Ответ также передается клиенту в виде заключенных в HTTP данных.

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

В этом случае транспортный уровень RMI использует еще один дополнительный обходной уровень. Причиной этого является то, что клиент не может больше передавать заключенные в HTTP JRMP-вызовы в произвольные порты, поскольку сервер находится за брандмауэром. Вместо этого, транспортный уровень RMI размещает JRMP-вызов внутри HTTP-пакетов и передает эти пакеты в порт 80 сервера. Заголовок HTTP POST имеет теперь следующую форму:

http://hostname:80/cgi-bin/java-rmi?forward=<port>

Это вызывает выполнение сценария CGI, java-rmi.cgi, который в свою очередь вызывает локальную JVM, распаковывает HTTP-пакет и направляет вызов серверному процессу в назначенный порт. RMI JRMP-ответы от сервера передаются назад как пакеты HTTP REPLY в нужный порт клиента, где RMI опять распаковывает информацию и передает ее в соответствующую заглушку RMI.

Естественно, для того, чтобы все это работало, сценарий java-rmi.cgi, который включен в стандартный JDK 1.1 или в платформу Java 2, должен: быть предварительно сконфигурирован, указывать путь к интерпретатору Java и располагаться в каталоге веб-сервера cgi-bin. Также очень важно при запуске RMI-сервера указывать полное доменное имя хоста в системном свойстве для устранения любых проблем разрешения DNS-имен, например:

java.rmi.server.hostname=host.domain.com

Примечание: Вместо использования CGI-сценария для направления вызова более эффективной является реализация той же задачи с использованием сервлета. Вы можете получить исходный код такого сервлета из RMI FAQ от Sun (http://java.sun.com/products/jdk/1.2/docs/guide/rmi/faq.html).

Необходимо отметить, что, несмотря на встроенный механизм прохождения через брандмауэр, RMI испытывает значительное снижение производительности из-за HTTP-туннелирования. Существуют также и другие трудности при использовании HTTP-туннелирования. Например, ваше RMI-приложение не сможет больше мультиплексировать JRMP-вызовы в одном соединении, поскольку в этом случае применяется дискретный протокол типа запрос-ответ. Кроме того, использование сценария java-rmi.cgi открывает довольно большую дыру в безопасности вашего сервера, так как теперь сценарий может перенаправить любой входящий запрос на любой порт, полностью обходя механизм защиты брандмауэра. Разработчики должны также отметить, что использование HTTP-туннелирования запрещает RMI-приложениям использовать обратные вызовы, что может быть основным ограничением при разработке. Поэтому, если клиент обнаружит брандмауэр, он всегда может запретить имеющуюся по умолчанию возможность HTTP-туннелирования, установив свойство:

java.rmi.server.disableHttp=true

Цитата(tux @ 21.10.2005, 04:21)

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

Гм... что значит "увесистый"?
JBoss позволяет организовать приложение с компонентами практически не заморачиваясь транзакциями, пулом коннектов, etc. Там уже все это есть. Если смотреть в сторону JBoss 4.0.x +ejb3 - есть рабочий ORM на базе того же hibernate3.
ИМХО, главное преимущество такого контейнера - не надо самому ничто ни куда встраивать. Поставил - и оно работает. Сам так начинал :-)

Про использование компонет: очень часто слышу крики о том, что контейнер для бизнес-компонет не нужен. Достаточно jsp-servlet контейнера и все.
Конечно, если так рассуждать - достаточно. Но паттерны и антипаттерны для чего-то же придуманы. Пропагандируемые многими решения на базе одного лишь servlet-контейнера - это решение однодневки с заранее обрубленными возможностями качественного развития.
Разделение логики и представление позволяет в будущем изменить напрочь логику не затрагивая представление, расширить спектр клиентов без изменения логики. В противном случае что получаем: захотели на автомобиле поменять приборную панель на более "красивую" - пришлось двигатель перебирать/менять/совершенствовать. Ну не бред ли?

Цитата(sandello @ 25.10.2005, 08:46)

Гм... что значит "увесистый"?

Большой, тяжеловесный, с избыточным(в большинстве случаев) функционалом.

Цитата(sandello @ 25.10.2005, 08:46)

Но паттерны и антипаттерны для чего-то же придуманы

Основной паттерн, имхо, - это то, что нужно стараться находить максимально простые и эффективные решения для конкретной задачи. Использование таких серверов приложений, как JBoss очень часто усложняет программу в угоду мифическим "возможностям качественного развития". Тогда как использование легких контейнеров - spring, turbine, делает решение более простым и изящным.

Цитата(sandello @ 25.10.2005, 08:46)

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

К примеру, встраивание менеджера транзакций JOTM в томкат занимает 15 минут и состоит из:
1. 10 минут чтения документации
2. 5 минут на изменение конфигурационных файлов.
Так что не вижу особых проблем.

Цитата(sandello @ 25.10.2005, 08:46)

Разделение логики и представление позволяет в будущем изменить напрочь логику не затрагивая представление, расширить спектр клиентов без изменения логики.

Безусловно. Но для разделения логики от представления не обязательно использовать JBoss или другие полновесные серверы приложений.

Насчет спектра клиентов. У нас есть приложение, работающее под управлением томкат/turbine, которое представляет POJO, CORBA и WS интерфейсы. По-моему вполне достаточный набор. Если в будущем возникнет необходимость добавить в него еще и поддержку RMI, то сделать это не составит особого труда - нужно будет лишь написать очередные обертки.

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

Это сообщение отредактировал(а) pvo - 25.10.2005, 09:16

Цитата(pvo @ 25.10.2005, 11:15)

Основной паттерн, имхо, - это то, что нужно стараться находить максимально простые и эффективные решения для конкретной задачи. Использование таких серверов приложений, как JBoss очень часто усложняет программу в угоду мифическим "возможностям качественного развития". Тогда как использование легких контейнеров - spring, turbine, делает решение более простым и изящным.

Я привел JBoss в качестве примера просто по тому, что использую его и с другими подобными решениями не знаком. Речь не о обязательном EJB, а об обязательной компонентной модели - отделении логики от представления. В противном случае получаются волшебные сервлеты различной степени запущенности.

Цитата(pvo @ 25.10.2005, 11:15)

К примеру, встраивание менеджера транзакций JOTM в томкат занимает 15 минут и состоит из: 1. 10 минут чтения документации 2. 5 минут на изменение конфигурационных файлов. Так что не вижу особых проблем.

Томкат - это servlet-jsp контейнер. Я идеологически против запихивания логики в него. Пусть "думает" другой контейнер, специально для этого придуманный. Томкат пусть рисует.

Цитата(pvo @ 25.10.2005, 11:15)

Безусловно. Но для разделения логики от представления не обязательно использовать JBoss или другие полновесные серверы приложений.

Ээх, забыл сразу написать, что на JBoss и EJB свет клином не сошелся. Просто это решение, знакомое мне

Цитата(sandello @ 25.10.2005, 09:58)

Я привел JBoss в качестве примера просто по тому, что использую его и с другими подобными решениями не знаком. Речь не о обязательном EJB, а об обязательной компонентной модели - отделении логики от представления. В противном случае получаются волшебные сервлеты различной степени запущенности.

Согласен. Первоначально я воспринял это как апологетику EJB.

Цитата(sandello @ 25.10.2005, 09:58)

Томкат - это servlet-jsp контейнер.

А вот тут категорически не согласен Во-первых, Томкат это J2EE сервер без поддержки EJB. Только в самом примитивном случае он используется только как среда для выполнения сервлетов/jsp.

В качестве примера о5 же приведу Turbine. Хотя он может работать без томката, при разработке веб приложения использование turbine в standalone mode не разумно по соображениям производительности и усложнения архитектуры.

Turbine, как я уже говорил, фактически представляет из себя легковесный контейнер для бизнес компонентов + фрейморк для создания HTML страниц. Он использует томкат лишь для управления управления жизненным циклом - при запуске webapp запускается и turbine, при остановке webapp - освобождает ресурсы и останавливается. .

Таким образом, в данном случае томкат является контейнером для одного или нескольких контейнеров бизнес объектов.

Цитата(sandello @ 25.10.2005, 09:58)

Я идеологически против запихивания логики в него. Пусть "думает" другой контейнер, специально для этого придуманный. Томкат пусть рисует.

Что значит - "запихивание логики в томкат"? ИМХО, будет плохо, если совмещаются логика и отображение, но тут-то не идет речь об этом...
Для отображния используются сервлеты/jsp вместе с соотв. фреймворками, а для реализации логики как раз "другой контейнер" (Spring/Turbine) . Это, конечно, актуально в случае не очень больших нагрузок. Если нагрузки велики, то тут - да, нужно использовать другие средства, например, JBoss

Это сообщение отредактировал(а) pvo - 25.10.2005, 11:04