On 01.08.2011 14:21, Donz wrote:
> H>Ещё раз повторюсь — речь именно про IoC, т.к. у спринга много ведь и > H>других фишек. > > Да, я понял. Но теперь хочу спросить От других вкусностей спринга тоже > отказался?
Из того, чем широко пользовались в сервисах вспоминается только
*Template (JdbcTemplate и т.п.). Аспекты и спринговую авторизацию не
пользовали. Транзакции всегда пользовали JTA-шные.
По поводу MVC/WebFlow — вопрос пока открытый. В вышеупомянутом
приложении UI не сильно большой, тысячи пользователей на него
одномоментно набежать не могут (т.к. сугубо интранетовское приложение),
так что JSF вполне хватает. Дальше будем смотреть по обстоятельствам —
как оно себя в поддержке покажет.
Здравствуйте, 20BW, Вы писали:
BW>Доброго времени суток, Господа.
BW>Задача следующая: написать на JavaEE продукт, который принимал данные с GPS трекеров. Т.е. трекер подключается к некоему приложению, и отправляет пакет данных, приложение пакет парсит и записывает в БД.
BW>Проблема в том, что я не совсем понимаю как выстроить данное приложение. Т.е. не ясна общая структура подобных систем на Java. Поэтому прошу дать толчек в нужное направление. Или линк на статейки/книги.
BW>Заранее прошу не пинать ногами и Спасибо!
Что за бред тут пишут вообще. Какие standalone...
Типичная задача message driven bean & canonical data model для обмена.
Даже сервер начального уровня справится с парой сотен клиентов.
Если начнутся заморочки с количеством клиентов раширяем это все добро до полноценной ESB, а mq/app серверы цепляем в кластер с лодбалансером.
Задача следующая: написать на JavaEE продукт, который принимал данные с GPS трекеров. Т.е. трекер подключается к некоему приложению, и отправляет пакет данных, приложение пакет парсит и записывает в БД.
Проблема в том, что я не совсем понимаю как выстроить данное приложение. Т.е. не ясна общая структура подобных систем на Java. Поэтому прошу дать толчек в нужное направление. Или линк на статейки/книги.
Здравствуйте, 20BW, Вы писали:
BW>Доброго времени суток, Господа.
BW>Задача следующая: написать на JavaEE продукт, который принимал данные с GPS трекеров. Т.е. трекер подключается к некоему приложению, и отправляет пакет данных, приложение пакет парсит и записывает в БД.
Ключевые слова: PostGIS, OpenLayers
Здравствуйте, 20BW, Вы писали:
BW>написать на JavaEE продукт
JEE здесь как бы ни причём, я думаю
BW>Проблема в том, что я не совсем понимаю как выстроить данное приложение
достаточно standalone приложения (на ioc-контейнере, например, spring framework), которое внутри себя будет иметь listener и некоторую простую логику приёма-записи данных в БД
даже не зная, какую гамму коммуникационных протоколов gps-трекеры готовы поддержать, рискну предположить, что обычного http(https) listener'а будет достаточно, а способ упаковки данных в http-запрос будет зависеть исключительно от сложности их структуры
Здравствуйте, 20BW, Вы писали:
BW>Задача следующая: написать на JavaEE продукт, который принимал данные с GPS трекеров. Т.е. трекер подключается к некоему приложению, и отправляет пакет данных, приложение пакет парсит и записывает в БД. BW>Проблема в том, что я не совсем понимаю как выстроить данное приложение. Т.е. не ясна общая структура подобных систем на Java. Поэтому прошу дать толчек в нужное направление. Или линк на статейки/книги.
Обычно три слоя. Зависимость между ними только сверху вниз, но не наоборот.
-Фронтовой (например, web-service). Принимает данные, проводит синтаксическую и интеграционную в рамках этих данных валидацию, трансформирует данные в доменные объекты и вызывает сервисный слой.
-Сервисный. В нем заложена вся бизнес-логика. Проводит валидацию интеграции поступивших данных со структурой БД и уже существующими данными. Выполняет саму логику работы.
-DAO. Содержит мэппинг доменных объектов на структуру БД. Выполняет примитивные операции с объектами: получить, сохранить, изменить. Не должен содержать какую-либо логику.
Фронт — веб-сервисы. Управление бинами через Spring Core (IoC контроллер). Если данных немного, то Hibernate в качестве ORM.
Здравствуйте, Donz, Вы писали:
D>Здравствуйте, 20BW, Вы писали:
BW>>Задача следующая: написать на JavaEE продукт, который принимал данные с GPS трекеров. Т.е. трекер подключается к некоему приложению, и отправляет пакет данных, приложение пакет парсит и записывает в БД. BW>>Проблема в том, что я не совсем понимаю как выстроить данное приложение. Т.е. не ясна общая структура подобных систем на Java. Поэтому прошу дать толчек в нужное направление. Или линк на статейки/книги.
D>Обычно три слоя. Зависимость между ними только сверху вниз, но не наоборот. D>-Фронтовой (например, web-service). Принимает данные, проводит синтаксическую и интеграционную в рамках этих данных валидацию, трансформирует данные в доменные объекты и вызывает сервисный слой. D>-Сервисный. В нем заложена вся бизнес-логика. Проводит валидацию интеграции поступивших данных со структурой БД и уже существующими данными. Выполняет саму логику работы. D>-DAO. Содержит мэппинг доменных объектов на структуру БД. Выполняет примитивные операции с объектами: получить, сохранить, изменить. Не должен содержать какую-либо логику.
D>Фронт — веб-сервисы. Управление бинами через Spring Core (IoC контроллер). Если данных немного, то Hibernate в качестве ORM.
Спасибо. Не могли бы Вы назвать книги/статьи, где про все это можно прочитать? Хотя бы про общие концепции.
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, 20BW, Вы писали:
BW>>написать на JavaEE продукт
C0s>JEE здесь как бы ни причём, я думаю
BW>>Проблема в том, что я не совсем понимаю как выстроить данное приложение
C0s>достаточно standalone приложения (на ioc-контейнере, например, spring framework), которое внутри себя будет иметь listener и некоторую простую логику приёма-записи данных в БД C0s>даже не зная, какую гамму коммуникационных протоколов gps-трекеры готовы поддержать, рискну предположить, что обычного http(https) listener'а будет достаточно, а способ упаковки данных в http-запрос будет зависеть исключительно от сложности их структуры
Проблема в том, что этих трекеров может быть несколько сотен (если не тысяч), и данные они передают каждые 1-10 минут, в зависимости от настроек. Поэтому я полагаю, нагрузка будет не слабая, и следовательно нужна возможность масштабирования.
Здравствуйте, 20BW, Вы писали:
BW>Проблема в том, что этих трекеров может быть несколько сотен (если не тысяч), и данные они передают каждые 1-10 минут, в зависимости от настроек. Поэтому я полагаю, нагрузка будет не слабая, и следовательно нужна возможность масштабирования.
так это, не задача JEE, а задача поиска грамотного сисадмина в команду развёртывания. (dns, мапящийся не несколько фронтовых http-серверов, которые в свою очередь раунд-робят на уже упомянутые standalone-приложения)
Здравствуйте, C0s, Вы писали:
BW>>написать на JavaEE продукт C0s>JEE здесь как бы ни причём, я думаю
ИМХО, веб-сервисы тут отлично подходят. Зачем изобретать велосипед через сокеты и стенд-алон приложение? С одной многопоточностью можно огрести проблемы.
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, 20BW, Вы писали:
BW>>Проблема в том, что этих трекеров может быть несколько сотен (если не тысяч), и данные они передают каждые 1-10 минут, в зависимости от настроек. Поэтому я полагаю, нагрузка будет не слабая, и следовательно нужна возможность масштабирования.
C0s>так это, не задача JEE, а задача поиска грамотного сисадмина в команду развёртывания. (dns, мапящийся не несколько фронтовых http-серверов, которые в свою очередь раунд-робят на уже упомянутые standalone-приложения)
Гм.. т.е. Вы советуете использовать обычное standalone-приложения... спасибо... подумаю...
Масштабируются jee приложения (судя по описанию задачи вам будет
достаточно web profile) нормально — просто размножаются в кластерах и
всё (разумеется, админам придётся в это вникнуть), главное не отходить
далеко от спеки и не тащить в HttpSession чего-нибудь тяжёлого или
несереализуемого.
Здравствуйте, Donz, Вы писали:
D>ИМХО, веб-сервисы тут отлично подходят. Зачем изобретать велосипед через сокеты и стенд-алон приложение? С одной многопоточностью можно огрести проблемы.
про сокеты я не говорил.
т.к. WS не на http-транспорте — это экзотика, то будем считать, что и там, и сям HTTP — будет.
дальше, я просто замечаю, что условия задачи никоим образом не требуют дополнительных библиотек или технологий "сверху", поэтому я бы обошёлся минимумом, а именно — http.
возможно, что минимум будет даже плюсом не только с точки зрения "учить и прикручивать на одну технологию меньше", но и в runtime — если там и вправду будет горячая нагрузка.
про многопоточность не понял. с ней, вообще, всегда можно огрести проблемы... ws здесь ничем не лучше, чем http handlers / servlets
Здравствуйте, C0s, Вы писали:
C0s>дальше, я просто замечаю, что условия задачи никоим образом не требуют дополнительных библиотек или технологий "сверху", поэтому я бы обошёлся минимумом, а именно — http. C0s>возможно, что минимум будет даже плюсом не только с точки зрения "учить и прикручивать на одну технологию меньше", но и в runtime — если там и вправду будет горячая нагрузка.
Мэппинг на БД нужен. Или берем готовый фреймворк, или изобретаем свой.
Управление бинами нужно. Или берем Spring IoC (или CDI, как советуют ниже), или вколачиваем все зависимости молотком, или опять же изобретаем свой IoC контейнер.
Если будут коннекты по HTTP, очевидно, нужен веб-сервер. И опять: или изобретаем свой, или берем уже готовый. А еще лучше готовый веб-сервер с готовым низкоуровневым фреймворком, скрывающий от нас детали протокола и имеющий тучу надстроек, которые вообще сделают неважным, откуда и каким образом до нас приходят данные, в приложении мы будем оперировать привычными ява-объектами, а не xml'ем или параметрами get-запроса.
Обещанная нагрузка — сотни, возможно тысячи, запросов за 1-10 минут. Возьмем 5000 устройств, отсылающих данные каждые пять минут. 1000 запросов в минуту. 17 запросов в секунду. Учитывая, что алгоритмически задача простейшая и надо только складировать данные в БД, о какой-либо серьезной нагрузке речи не идет. Если не хватит одного сервера, то, как ты и сказал, просто добавляется еще один и балансировка обеспечивается на административном уровне, а не на разработческом.
Пытаться здесб что-то оптимизировать путем написания собственного хттп-сервера — это однозначно преждевременная оптимизация.
C0s>про многопоточность не понял. с ней, вообще, всегда можно огрести проблемы... ws здесь ничем не лучше, чем http handlers / servlets
Сервлеты — это уже J2EE. И сервлеты, и WS гораздо лучше собственного велосипеда тем, что потоками управляет сервлет-контейнер. В собственном велосипеде придется вручную создавать нити и следить, чтобы они друг друга не испортили.
Здравствуйте, hrensgory, Вы писали:
H>On 01.08.2011 12:14, 20BW wrote:
>> Спасибо. Не могли бы Вы назвать книги/статьи, где про все это можно >> прочитать? Хотя бы про общие концепции.
H>http://download.oracle.com/javaee/6/firstcup/doc/
H>Подробнее:
H>http://download.oracle.com/javaee/6/tutorial/doc/
H>С выходом Java Enterprise Edition 6 нужда в спринге (если рассматривать H>его сугубо как IoC фреймворк) отпала:
H>http://download.oracle.com/javaee/6/tutorial/doc/gjbnr.html
H>Масштабируются jee приложения (судя по описанию задачи вам будет H>достаточно web profile) нормально — просто размножаются в кластерах и H>всё (разумеется, админам придётся в это вникнуть), главное не отходить H>далеко от спеки и не тащить в HttpSession чего-нибудь тяжёлого или H>несереализуемого.
H>-- H>WBR, H>Serge.
Вот! Вот это я и искал! Огромное спасибо. Буду изучать.
Здравствуйте, Donz, Вы писали:
D>Мэппинг на БД нужен. Или берем готовый фреймворк, или изобретаем свой.
очень спорно, что нужен "мапинг на БД". не вижу ни одной предпосылки. достаточно тупых инсертов.
D>Управление бинами нужно. Или берем Spring IoC (или CDI, как советуют ниже), или вколачиваем все зависимости молотком, или опять же изобретаем свой IoC контейнер.
ну да, я сразу упомянул spring, выбор другого — дело вкуса
D>Если будут коннекты по HTTP, очевидно, нужен веб-сервер. И опять: или изобретаем свой, или берем уже готовый.
да, я бы в упомянутый standalone заембеддил бы несколько кусочков jetty — только тех, что нужны под задачу
D>А еще лучше готовый веб-сервер с готовым низкоуровневым фреймворком, скрывающий от нас детали протокола и имеющий тучу надстроек, которые вообще сделают неважным, откуда и каким образом до нас приходят данные, в приложении мы будем оперировать привычными ява-объектами, а не xml'ем или параметрами get-запроса.
спорное удобство
D>Обещанная нагрузка — сотни, возможно тысячи, запросов за 1-10 минут. Возьмем 5000 устройств, отсылающих данные каждые пять минут. 1000 запросов в минуту. 17 запросов в секунду. Учитывая, что алгоритмически задача простейшая и надо только складировать данные в БД, о какой-либо серьезной нагрузке речи не идет. Если не хватит одного сервера, то, как ты и сказал, просто добавляется еще один и балансировка обеспечивается на административном уровне, а не на разработческом. D>Пытаться здесб что-то оптимизировать путем написания собственного хттп-сервера — это однозначно преждевременная оптимизация.
дело не в оптимизации, а в том, что более простой набор кубиков не сложнее в понимании и не сложнее в ассемблировании
повторюсь, не вижу ни одной серьёзной причины тащить в такого рода задачи больше кубиков, чем нужно
C0s>>про многопоточность не понял. с ней, вообще, всегда можно огрести проблемы... ws здесь ничем не лучше, чем http handlers / servlets
D>Сервлеты — это уже J2EE. И сервлеты, и WS гораздо лучше собственного велосипеда тем, что потоками управляет сервлет-контейнер. В собственном велосипеде придется вручную создавать нити и следить, чтобы они друг друга не испортили.
я, кстати, не говорил писать свой http-сервер, а тот же jetty позволяет оперировать не только в терминах сервлетов
пойми: слышать, что для решения простейшей задачи "получить данные по сети и положить их в БД" нужен jee... мне, по меньшей мере, странно, поэтому я и предлагаю необходимый минимум. далее, я показал, пусть и крайне кратко, что он достаточен, а если это не так — то аргументируйте
On 01.08.2011 13:33, Donz wrote:
> H>С выходом Java Enterprise Edition 6 нужда в спринге (если рассматривать > H>его сугубо как IoC фреймворк) отпала: > > Есть личный опыт? Можно вкратце, чем CDI лучше?
Личный опыт есть, но пока небольшой (сейчас как раз в процессе перехода
в production, в течении августа должны сдать проект).
Ничем особо не лучше (а большей частью это было уже давно, например
инжекция @EJB и @Resource в сервисном слое уже давно работает), просто
теперь отпала нужда в дополнительной библиотеке (Spring) и её
зависимостях, так же как после появления в стандарте JPA — отпала нужда
в Hibernate.
Ещё раз повторюсь — речь именно про IoC, т.к. у спринга много ведь и
других фишек.
Здравствуйте, C0s, Вы писали:
D>>Мэппинг на БД нужен. Или берем готовый фреймворк, или изобретаем свой. C0s>очень спорно, что нужен "мапинг на БД". не вижу ни одной предпосылки. достаточно тупых инсертов.
Мэппинг в любом случае будет. И в любом случае хранить запросы в отдельном ресурсе лучше, чем хардкодить. Если хибернейт кажется монструозным, то можно взять myBatis, например.
D>>Если будут коннекты по HTTP, очевидно, нужен веб-сервер. И опять: или изобретаем свой, или берем уже готовый. C0s>да, я бы в упомянутый standalone заембеддил бы несколько кусочков jetty — только тех, что нужны под задачу
Просто для интереса (ни разу сам подобным не занимался). Добавить в проект часть другого очень крупного проекта — это проще, чем взять тот же полноценный Jetty или Tomcat?
D>>А еще лучше готовый веб-сервер с готовым низкоуровневым фреймворком, скрывающий от нас детали протокола и имеющий тучу надстроек, которые вообще сделают неважным, откуда и каким образом до нас приходят данные, в приложении мы будем оперировать привычными ява-объектами, а не xml'ем или параметрами get-запроса. C0s>спорное удобство
Что именно смущает? Мне вот лень вручную парсить гет-запросы. И даже с мапой уже распарсенных параметров лень разбираться. Не проще ли на вход получить уже готовый объект, который будет гарантировано провалидирован на синтаксис и простейшие констрейнты?
Хотя тут, конечно, зависит от формата выдачи данных устройствами-клиентами.
C0s>дело не в оптимизации, а в том, что более простой набор кубиков не сложнее в понимании и не сложнее в ассемблировании C0s>повторюсь, не вижу ни одной серьёзной причины тащить в такого рода задачи больше кубиков, чем нужно
Все кубики в той или иной степени должны присутствовать в приложении. Зачем их выпиливать из дерева самому? Тем более, что в данном случае набор кубиков настолько типичный, что любая проблема будет решена копипастом в гугл полученной ошибки.
C0s>пойми: слышать, что для решения простейшей задачи "получить данные по сети и положить их в БД" нужен jee... мне, по меньшей мере, странно, поэтому я и предлагаю необходимый минимум. далее, я показал, пусть и крайне кратко, что он достаточен, а если это не так — то аргументируйте
А чем страшит J2EE? Спринг намного сложнее, чем те же сервлеты, которые делают работу по разбору запросов за программиста.
Здравствуйте, Donz, Вы писали:
D>>>Если будут коннекты по HTTP, очевидно, нужен веб-сервер. И опять: или изобретаем свой, или берем уже готовый. C0s>>да, я бы в упомянутый standalone заембеддил бы несколько кусочков jetty — только тех, что нужны под задачу D>Просто для интереса (ни разу сам подобным не занимался). Добавить в проект часть другого очень крупного проекта — это проще, чем взять тот же полноценный Jetty или Tomcat?
Jetty, однозначно. Её подключение — это примерно 20 строк кода и одна зависимость в POM'е.
Здравствуйте, Cyberax, Вы писали:
C>Jetty, однозначно. Её подключение — это примерно 20 строк кода и одна зависимость в POM'е.
В смысле полноценный Jetty или как раз embedded?
Для меня вот запуск в Томкате является простейшей операцией, и совсем непонятно, что в этом такого страшного. А вот разбираться в новом проекте, да еще брать оттуда какую-то часть — это действительно пугает.
Здравствуйте, hrensgory, Вы писали:
H>Ничем особо не лучше (а большей частью это было уже давно, например H>инжекция @EJB и @Resource в сервисном слое уже давно работает), просто H>теперь отпала нужда в дополнительной библиотеке (Spring) и её H>зависимостях, так же как после появления в стандарте JPA — отпала нужда H>в Hibernate.
Ясно, спасибо.
H>Ещё раз повторюсь — речь именно про IoC, т.к. у спринга много ведь и H>других фишек.
Да, я понял. Но теперь хочу спросить От других вкусностей спринга тоже отказался?
Здравствуйте, Donz, Вы писали:
D>Мэппинг в любом случае будет. И в любом случае хранить запросы в отдельном ресурсе лучше, чем хардкодить. Если хибернейт кажется монструозным, то можно взять myBatis, например.
у меня бы не было мапинга, spring jdbc template (поддержка именованых параметров) + инъекция текста вызова хранимки или insert
D>>>Если будут коннекты по HTTP, очевидно, нужен веб-сервер. И опять: или изобретаем свой, или берем уже готовый. C0s>>да, я бы в упомянутый standalone заембеддил бы несколько кусочков jetty — только тех, что нужны под задачу
D>Просто для интереса (ни разу сам подобным не занимался). Добавить в проект часть другого очень крупного проекта — это проще, чем взять тот же полноценный Jetty или Tomcat?
для меня нет разницы, jetty настолько тупо вставляется, что думать надо только над тем, какие части из него нужны.
ща глянул в один из проектов: простейший набор (логгер запросов, один коннектор, один handler с одним сервлетом и ещё парочка default+error handler) занимает разреженным xml с комментариями около 100 строк, писался тупо по примерам инстанцирования jetty в java-коде в течение полудня.
D>>>А еще лучше готовый веб-сервер с готовым низкоуровневым фреймворком, скрывающий от нас детали протокола и имеющий тучу надстроек, которые вообще сделают неважным, откуда и каким образом до нас приходят данные, в приложении мы будем оперировать привычными ява-объектами, а не xml'ем или параметрами get-запроса. C0s>>спорное удобство
D>Что именно смущает? Мне вот лень вручную парсить гет-запросы. И даже с мапой уже распарсенных параметров лень разбираться. Не проще ли на вход получить уже готовый объект, который будет гарантировано провалидирован на синтаксис и простейшие констрейнты? D>Хотя тут, конечно, зависит от формата выдачи данных устройствами-клиентами.
зависит от сложности структуры модели данных, скажем, 2-3 "просто" поля взять из http post проще, чем городить ws
а для 15 полей со вложенностью, defaults, обязательностью и типизацией — да, ws лучше, в этом смысле картина не меняется — спринг-ws позволяет сильно абстрагироваться от доставки данных, а xml-конфиг дополняется ещё 30ю строками
C0s>>дело не в оптимизации, а в том, что более простой набор кубиков не сложнее в понимании и не сложнее в ассемблировании C0s>>повторюсь, не вижу ни одной серьёзной причины тащить в такого рода задачи больше кубиков, чем нужно
D>Все кубики в той или иной степени должны присутствовать в приложении. Зачем их выпиливать из дерева самому? Тем более, что в данном случае набор кубиков настолько типичный, что любая проблема будет решена копипастом в гугл полученной ошибки.
C0s>>пойми: слышать, что для решения простейшей задачи "получить данные по сети и положить их в БД" нужен jee... мне, по меньшей мере, странно, поэтому я и предлагаю необходимый минимум. далее, я показал, пусть и крайне кратко, что он достаточен, а если это не так — то аргументируйте
D>А чем страшит J2EE? Спринг намного сложнее, чем те же сервлеты, которые делают работу по разбору запросов за программиста.
меня ничто не страшит, окромя необоснованных монстров
Здравствуйте, Donz, Вы писали:
C>>Jetty, однозначно. Её подключение — это примерно 20 строк кода и одна зависимость в POM'е. D>В смысле полноценный Jetty или как раз embedded?
Без разницы. Полноценный Jetty использует те же компоненты, что и embedded.
D>Для меня вот запуск в Томкате является простейшей операцией, и совсем непонятно, что в этом такого страшного. А вот разбираться в новом проекте, да еще брать оттуда какую-то часть — это действительно пугает.
Это не так-то просто, если нормально Tomcat встраивать.
Здравствуйте, Cyberax, Вы писали:
D>>Для меня вот запуск в Томкате является простейшей операцией, и совсем непонятно, что в этом такого страшного. А вот разбираться в новом проекте, да еще брать оттуда какую-то часть — это действительно пугает. C>Это не так-то просто, если нормально Tomcat встраивать.
Зачем его встраивать, если можно просто использовать?
Здравствуйте, akud, Вы писали:
A>Что за бред тут пишут вообще. Какие standalone...
я тут промолчу, но, не сомневаюсь, ты понял, что я подумал
A>Типичная задача message driven bean & canonical data model для обмена.
т.е. к одному (условно) insert'у собранного пакета информации ты решил добавить операцию сохранения JMS, операцию считывания JMS, и операцию обновления JMS,
а кроме того притащил излишнюю технологию, и, весьма вероятно, лишние транзакционные заморочки
A>Если начнутся заморочки с количеством клиентов раширяем это все добро до полноценной ESB, а mq/app серверы цепляем в кластер с лодбалансером.
ESB — это 5, особенно, если платный. пушки-по-воробьям плохо со складов стали продаваться?
---
mq здесь может пригодится только, если за счёт экономии хардвера потребуется сглаживать пики количества пакетов на единицу времени
однако, в условии задачи про пики ничего не сказано, что позволяет неявно предположить, что нагрузка константная, значит хардвер изначально должен успевать обслуживать одну и ту же нагрузку
узким местом в этой системе с вероятностью 80% будет БД (должна эффективно поддерживать параллельные инсерты)
а java может стать узким местом, чем монструознее пучок технологий будет засунут для решения типовой задачи "взять и положить"
Здравствуйте, Donz, Вы писали:
D>Зачем его встраивать, если можно просто использовать?
с моей точки зрения, задача подпадает в условный класс сетевых элементов сбора и распространения информации (характеризуются работой по разным протоколам приёма-передачи)
в таких задачах специфика приёма http должна быть отделена от остального
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, akud, Вы писали:
A>>Что за бред тут пишут вообще. Какие standalone... C0s>я тут промолчу, но, не сомневаюсь, ты понял, что я подумал
А на кой черт городить огород с коммутационным стеком вручную.
A>>Типичная задача message driven bean & canonical data model для обмена. C0s>т.е. к одному (условно) insert'у собранного пакета информации ты решил добавить операцию сохранения JMS, операцию считывания JMS, и операцию обновления JMS, C0s>а кроме того притащил излишнюю технологию, и, весьма вероятно, лишние транзакционные заморочки
Труд программиста дороже железа.
Это к вопросу о "ручном" управлении потоками, пулами и прочими jdbc, когда это все может сделать AS.
Не говоря уже о том, что эти операции проходят почти мгновенно (с jms).
Тут почти наверняка никакие XA не нужны, поэтому смело пишем: @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
A>>Если начнутся заморочки с количеством клиентов раширяем это все добро до полноценной ESB, а mq/app серверы цепляем в кластер с лодбалансером. C0s>ESB — это 5, особенно, если платный. пушки-по-воробьям плохо со складов стали продаваться?
Масштаб решения ж неизвестен, а это будет работать в любом случае. (для затравки можно какой нибудь serviceMix)
C0s>mq здесь может пригодится только, если за счёт экономии хардвера потребуется сглаживать пики количества пакетов на единицу времени C0s>однако, в условии задачи про пики ничего не сказано, что позволяет неявно предположить, что нагрузка константная, значит хардвер изначально должен успевать обслуживать одну и ту же нагрузку C0s>узким местом в этой системе с вероятностью 80% будет БД (должна эффективно поддерживать параллельные инсерты) C0s>а java может стать узким местом, чем монструознее пучок технологий будет засунут для решения типовой задачи "взять и положить"
1. я разрабатываю системы в промышленной автоматике и на такой архитектуре переваривают потоки сообщений нескольких десятков устройств, жалоб не поступало. требования по времени реакции системы на событие 100-150мс.;
2. oracle вполне себе справляется;
3. в случае если отвалится вебсервис (например по http-timeout из-за битого пакета) -- данным конец, как впрочем и чаннелу клиента;
4. никто не заставляет тащить весь пучок за собой, благо большинство AS позволяют это сделать;
Здравствуйте, akud, Вы писали:
A>А на кой черт городить огород с коммутационным стеком вручную. A>Труд программиста дороже железа. A>Это к вопросу о "ручном" управлении потоками, пулами и прочими jdbc, когда это все может сделать AS.
зависит от опыта, сравнивать нужно между теми, кто это умеет делать
потом, труд программиста — разов, а требовать от админов на этапе поддержки продукта знания AS — дороже, чем просто объяснить, как с "этими 10ю свойствами" жить.
старт-стоп standalone, опять же, существенно экономнее, поэтому проще делать updates
A>Не говоря уже о том, что эти операции проходят почти мгновенно (с jms).
быстрее — всего лишь сравнительная степень, а не аргумент
аргументация, которую я предлагаю, строится на понятиях "необходимо" и "достаточно", чего и остальным в этой дискуссии желаю
A>Тут почти наверняка никакие XA не нужны, поэтому смело пишем: @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
если not_supported позволительно, то и п. 3 ниже нерелевантен
A>>>Если начнутся заморочки с количеством клиентов раширяем это все добро до полноценной ESB, а mq/app серверы цепляем в кластер с лодбалансером. C0s>>ESB — это 5, особенно, если платный. пушки-по-воробьям плохо со складов стали продаваться?
A>Масштаб решения ж неизвестен, а это будет работать в любом случае. (для затравки можно какой нибудь serviceMix)
автору вопроса масштаб, возможно, известнее чем нам, но я исхожу из написанного, а не домысленного.
C0s>>mq здесь может пригодится только, если за счёт экономии хардвера потребуется сглаживать пики количества пакетов на единицу времени C0s>>однако, в условии задачи про пики ничего не сказано, что позволяет неявно предположить, что нагрузка константная, значит хардвер изначально должен успевать обслуживать одну и ту же нагрузку C0s>>узким местом в этой системе с вероятностью 80% будет БД (должна эффективно поддерживать параллельные инсерты) C0s>>а java может стать узким местом, чем монструознее пучок технологий будет засунут для решения типовой задачи "взять и положить"
A>1. я разрабатываю системы в промышленной автоматике и на такой архитектуре переваривают потоки сообщений нескольких десятков устройств, жалоб не поступало. требования по времени реакции системы на событие 100-150мс.;
все мои советы базируются на опыте, полученном в аналогичной ситуации
A>2. oracle вполне себе справляется;
вопрос автору, каков их бюджет.
я имею все основания предполагать, что если хватает денег на оракл, то и хватает денег на то, чтобы купить решение у готового специалиста, не ищущего ответы на форумах.
A>3. в случае если отвалится вебсервис (например по http-timeout из-за битого пакета) -- данным конец, как впрочем и чаннелу клиента;
см. выше
A>4. никто не заставляет тащить весь пучок за собой, благо большинство AS позволяют это сделать;
ассемблировать AS — тот ещё пилотаж.
причём того рода, что скрывает реальную работу тюнингом необоснованно навязанных сервисов.
A>ps. я для такого проекта лучше бы взял erlang
Здравствуйте, C0s, Вы писали:
C0s>если not_supported позволительно, то и п. 3 ниже нерелевантен
bad message queue ... или что нибудь другое из enterprise integration patterns
вариантов масса (см. apache camel)
A>>>>Если начнутся заморочки с количеством клиентов раширяем это все добро до полноценной ESB, а mq/app серверы цепляем в кластер с лодбалансером. C0s>>>ESB — это 5, особенно, если платный. пушки-по-воробьям плохо со складов стали продаваться? A>>Масштаб решения ж неизвестен, а это будет работать в любом случае. (для затравки можно какой нибудь serviceMix) C0s>автору вопроса масштаб, возможно, известнее чем нам, но я исхожу из написанного, а не домысленного.
Самопал он и в африке самопал. Надо использовать готовые решения, а не бредить оптимизацией.
A>>2. oracle вполне себе справляется; C0s>вопрос автору, каков их бюджет. C0s>я имею все основания предполагать, что если хватает денег на оракл, то и хватает денег на то, чтобы купить решение у готового специалиста, не ищущего ответы на форумах.
жизнь очень многогранна, особенно иногда поражает количество граней у решений, не побоюсь этого слова "российских топ-менеджеров"
здесь вам не тут, на железку денег не жалко, а людям отдавать жалко )
cassandra, mongodb...etc, правда nosql / но опять же по ТЗ не оговорена скульность базы
A>>3. в случае если отвалится вебсервис (например по http-timeout из-за битого пакета) -- данным конец, как впрочем и чаннелу клиента; C0s>см. выше A>>4. никто не заставляет тащить весь пучок за собой, благо большинство AS позволяют это сделать; C0s>ассемблировать AS — тот ещё пилотаж. C0s>причём того рода, что скрывает реальную работу тюнингом необоснованно навязанных сервисов.
в jboss например из "коробки" есть минимальный набор. добавь то что надо.
Здравствуйте, C0s, Вы писали:
D>>Зачем его встраивать, если можно просто использовать? C0s>с моей точки зрения, задача подпадает в условный класс сетевых элементов сбора и распространения информации (характеризуются работой по разным протоколам приёма-передачи) C0s>в таких задачах специфика приёма http должна быть отделена от остального
1)Почему в этой задаче ты подразумеваешь разные протоколы передачи данных? Было заявлено о тысяче однотипных устройств. Работать они будут явно по одному протоколу.
2)Если все-таки прием хттп должен быть отделен от бизнес-слоя, то каким образом встраивание части веб-сервера и сервлет-контейнера в проект поможет этому разделению? По-моему, совершенно наоборот. Если будет нужно добавить еще один протокол, то надо будет как-то избавляться от багажа в виде вколоченной хттп-составляющей.
От других вкусностей спринга тоже отказался?
