Задача следующая: написать на 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?
Для меня вот запуск в Томкате является простейшей операцией, и совсем непонятно, что в этом такого страшного. А вот разбираться в новом проекте, да еще брать оттуда какую-то часть — это действительно пугает.
