Здравствуйте, 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 встраивать.
Зачем его встраивать, если можно просто использовать?
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 серверы цепляем в кластер с лодбалансером.
Здравствуйте, 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)Если все-таки прием хттп должен быть отделен от бизнес-слоя, то каким образом встраивание части веб-сервера и сервлет-контейнера в проект поможет этому разделению? По-моему, совершенно наоборот. Если будет нужно добавить еще один протокол, то надо будет как-то избавляться от багажа в виде вколоченной хттп-составляющей.
От других вкусностей спринга тоже отказался?
