Фреймворк полностью интегрированный с JavaEE мечта или реальность?

Стек я выбрал сам. 1) Java нужен для разработки микросервисов на данном этапе, 2) Нужен был JPA, JAX WS , JSF для простенького админ интерфейса, так как c javascript возится не хочется. 3) Netbeans \ и стек с официальных курсов Oracle, хотя Intelli тоже использовал, но в Netbeans больше удобных визуальных средств. 4) Насчет модности и молодежности Spring , и удобных визуальных визуальных инструментов. Вот как раз в примерах на сайте я не увидел уклона на RAD и визуальные инструменты, только куча магических деклараций в коде, которых по впечатлению больше чем в стеке от Oracle. Я понимаю что если их начать изучать, то это уже инвестиция времени только в spring. Пока нет задачи быть модным, есть конкретные задачи которые нужно реализовать.

Тут как говорится "тебе шашечки или ехать?". По очевидным причинам, всегда правильнее использовать стандартный стек технологий. В случае с актуальной Java разработкой стандартом, де-факто, является Spring Boot и все святое семейство: Spring Web, Spring Security, Spring Data. Если ты не умеешь пользоваться этими инструментами, а учиться по какой-то причине не хочешь - это твое право, но тогда просто делай так как умеешь. Третьего не дано. Или ты хочешь быть программистом, но ничего не учить и код не писать и вообще что бы оно как-то само делалось? 😁 Мечта бизнеса должен сказать... к счастью, пока несбыточная.

1. Ну микросервисы сейчас по стандарту оборачиваются в докер и управляются чаще всего оркестратором, чтобы избавить себя от необходимости ручного деплоя и мониторинга. Но опять же может ваш путь не этот и хотите по своему ) 2. Спринг вполне спокойно уживается с jsp/jsf, ну так к тому, что эти аргументы не очень критичные 3. Со временем разница будет видее, у идеи больше интеграций и возможностей именно для разработки, тут уже статистика использования говорит. Но опять же каждый выбирает удобные себе инструмент. 4. В спринге магии особо нет, там есть рефлексия и большой объем готовых инструментов. Ну вот как пример тот же persistance.xml который спрингу не нужен, все теже настройки задаются в application.properties и спринг передаст их jpa, то есть тоже самое, но немного по другому. Либо же прямо в коде можно создать datasource и передать его спрингу, он уже передаст его настройки всем кому они необходимы. Но если вы выбрали свой набор инструментов, то придется уживаться с ним. Вам тут ответили, что есть примерно то, что вы ищите, но для этого используются другие инструменты ) Конечно я могу чего-то не знать и кто-то ответит вам на ваши вопросы лучше ) Ну и на последок, есть проект jhipster который все генерит из коробки. Провда фронт там на react или angular, но для простого интерфейса они не сильно сложнее jsf, тот же ангуляр строит mvc структуру. А для отрисовки есть библиотеки компонентов, типа prime faces для jsf

>>Сергеев Виктор Убедили , покопать поглубже Spring boot (заодно гляну https://www.jmix.io/ jhipster ) может вольюсь А до оркестрации микросервисов это не мой случай если понимать это в смысле ( https://habr.com/ru/post/544714/?ysclid=l7f3bhwtak154474961 ) я как раз хотел деплоить их в одном application server как более менее самостоятельные приложения А серьезные альтернативы Spring по уровню реализации сейчас есть?

По части микросервисов Spring считается очень хорошим. Исторически JEE развивался в парадигме монолита, а Spring - микросервисов. Сейчас, конечно, это уже не так: можно разрабатывать и так, и так, и там, и там :) В Spring есть (или интегрировано) много всего готового, например, Spring Cloud для организации взаимодействия микросервисов, Swagger для автоматической документации, HATEOAS для автоматического создания дополнительных REST-точек. Под модно-молодёжно я понимаю популярность фреймворка, а это значит что на любой вопрос можно найти ответ за 5-10 минут. Я бы рекомендовал пройти этот курс - это реально то, за что не жалко заплатить! Плюс дополнительно вот это. Ну дальше по микросервисам - уже сам, основа уже будет. Что касается User Interface - не совсем понятно что имеется в виду применительно к микросервисам. Желание избавиться от JS понятно, я сам на всякий случай поизучал Swing. Но это путь немножко в никуда. Вэб настолько везде пролез что в мире Java без него никуда. Есть, конечно, Qt, он он для Java поддерживается энтузиастами и непонятно что дальше. Есть Vaadin - странная вещь, но можешь ознакомиться. Есть JavaFX. Обычный путь для Spring - это использование шаблонизаторов, когда создаётся HTML-разметка и в неё в определённом синтаксисе внедряются Java-объекты, создавая динамику. Но по-настоящему продвинутый путь - создание обычного фротнэнда с использованием всей мощи современных фронт-технологий и прикручивание к нему бэкэнда на Java+Spring. Я тоже хотел найти что-то простенькое для фронта для чисто утилитарных задач. В итоге изучаю Angular :)

>>Денис "Или ты хочешь быть программистом, но ничего не учить и код не писать и вообще что бы оно как-то само делалось? 😁 Мечта бизнеса должен сказать... к счастью, пока несбыточная. " Я просто избалован одной хорошей прикладной платформой , в которой можно сосредоточится на бизнес процессе, а не на окружении (настройка подсистем, деплое, поиска магических конструкций) . Пока количество мест где нужно сделать аннотации или отредактировать в xml превосходят мои представления о эффективности разработки. Ихмо JPA и Spring data они ничего не упрощают, а настройка взаимодействия с БД превращается в квест. Подозреваю когда будут работать с группой связанных таблиц, меня ожидают интересные открытия >>wan-derer.ru "Что касается User Interface - не совсем понятно что имеется в виду применительно к микросервисам." Имеется ввиду интерфейс администратора для управления и подгрузки начальных данных для функционирования. Можно конечно это делать скриптами, но это для готового микросервиса будет выглядеть как костыль

Ихмо JPA и Spring data
они ничего не упрощают, а настройка взаимодействия с БД превращается в квест

Скорее всего вы нашли какой-то старый туториал, xml в спринге отходит на второй план начиная с 3 спринга, а уже 5 и на походе 6) Сейчас вся настройка ограничивается либо прописываением дсотупов (4 параметра) в application.properties либо созданием бина Datasource Далее проставка jpa аннотаций на entity (это не спринг, а jpa, но спринг умеет с этим работать) И на этом настройка бд закончена ) Можно еще подтянуть liqubase или flyway тогда спринг их увидит и еще бд автоматически обновит при появлении новых скриптов в момент запуска

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

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

Кроме визуальных инструментов как минимум прозвучали такие вещи как микросервисная архитектура и базы данных. Для решения подобных задач есть конвенциональный подход. То, что человек смотрел в сторону спринга как минимум говорит что он гуглил что-то с ним родственное. В общем шанс что оно ему действительно помогло бы решить задачу достаточно высокий. Так же очевидно, что об этом инструменте у него, мягко говоря, не самые актуальные данные. Именно потому я и рекомендовал ознакомиться с информацией посвежее. А все остальное были мысли в слух :) Конечно же автор сам решит, что ему делать.

>> интерфейс администратора для управления и подгрузки начальных данных для функционирования Я так понимаю, для этого создаётся отдельный микросервис, который: - взаимодействует с пользователем, например, через web-страничку; - хранит (у себя или в каком-нить Redis или Zookeeper) конфиги и раздаёт их другим микросервисам.

>>Justinian "А коли контекст неизвестен, то при гаданиях на кофейной гуще попасть мимо очень высока вероятность." Контекст простой, нужно сделать несколько микросервисов вокруг прикладной системы на базе 1С. Один микросервис для обслуживания баз (там более 1000 таблиц метаданных связанных определенной логикой что типично для конфигураций 1С) . Соотвественно микросервис будет получать описание метаданных на вход, создавать из них скрипты для обслуживания, запускать в параллельных потоках. Второй микросервис будет на постоянной основе читать данные шины rabbitMQ и раскладывать XML поля таблиц СУБД (первый этап уже реализован и давно работает на JavaSE) . Важно распараллеливание обработки данных. Канал управления с 1С легко сделать через SOAP - благо 1С поддерживает основные веб протоколы Есть еще ряд задач, которые можно реализовать микросервисами. Конечно эти задачи можно сделать другими средствами (можно даже на том же 1С сделать отдельную конфигурацию, прикрутить 1С Шина и т.д.), но когда объемы сообщений превышают 6 миллионов в день здесь нужно решение с запасом производительности для новых видов операций. Если у когото вопрос а как это будет хранится в 1С? Там все в порядке, база 5 терабайт нормально работает уже 8 лет и лишнее сдается в архив, 1С имеет возможности ворочать такими объемами если все грамотно делать . Java для таких задач, выбран по причине наличия большого количества решений\библиотек для разных шин, интерфейсов т.е. при интеграции всегда можно быть уверенным что на Java это есть. Можно конечно все както написать на JavaSE , но для любого микросервиса такого плана нужен а) Админ User интерфейс для инициализации и загрузки настроек (JSF иои подобное) б) Экосистема для деплоя и мониторинга (JavaEE , Spring boot) в) Хранение настроек метаданных, правил обработки (JPA) д) Каналы управления по SOAP (Jax WS или подобное) Оркестрация пока не нужна. Т.е. особо сложных запросов нет

ну почти все это есть в спринге ) интеграция с rabbitMq есть, так же как с БД указываете куда подсоединяться и делаете слушателей Для мониторига есть micrometer который может отдавать множество метрик в популярных форматах, spring boot так же из коробки умеет работать с ним и мониторить интеграции Для деплоя и мониторинга, можно придумать что-то свое, а можено взять кубер, он умеет мониторить приложения и поддерживать определенное количество запущенных реплик/нод. Про админку, попробуйте jhipster он дает отличную админку по управлению из коробки, но там уже не jsf а реакт или ангуляр, но получается прикольно

Ну, вот это уже разговор. Поддерживаю Виктора, попробуй jhipster, админка с коробки, много вещей на себя берет, а с остальным ты разберешься, покрутишь - в гугле тонны информации на любой манер по возникающим вопросам, главное гуглить на английском, чтобы не сужать выборку. ну и разобраться со средой, приловчиться, Intellij IDEA Ultimate содержит много плюшек и это джава ИДЕ #1, хотя на Нетбинсе и Эклипсе тоже можно работать, но фишек там меньше, впрочем не всем они и нужны. При этом сами конфигурации в экосистеме спринга последние лет 5-6 уже давно на аннотациях, есть конечно легаси или необходимость хотсвопа и другие специфические кейсы, спринг бут это фактически базовый спринг IoC фреймворк + автоконфигурации , в которых за тебя много чего наконфигурировано. В своем первоначальном посте ты писал что на сайте спринга только за H2 все просто , а по другим ХМЛ, но это не так, поскольку к другим БД принцип конфигурирования применяется такой же как H2, здесь уже просто точечно нужно разбирать момент , и научный метод тыка + стековерфлоу. По поводу джава стека, аргумент хороший по универсальности, но универсальность джава избыточна, ведь джава решения применяются повсюду, от трейдинга на биржах и хайлоад до написания на джаве драйверов для физических устройств. Экосистема спринг бут достаточно френдли, чуть инвестируешь время и разберешься, я видел много кейсов, когда программисты с других языков просто брали и писали и получали что хотели, ну главное чтобы статики по меньше, то есть не забывать про IoC ну и базовое ООП, а все остальное лишь бы работало и было попроще. Так что разберешься, успехов

У меня вопрос не о полноте реализации спецификаций JavaEE (Jpa , JSF) а о визуальных инструментах разработки, в NetBeans и Intelli они работают в полной мере на уровне JavaSE , а когда разрабатываешь для application server то выясняется что все настройки коннектов приходится переделывать под конкретную реализацию application server javaEE, да на уровне тут отредактируйте persistence.xml а тут внедрите зависимости в pom.xml чтобы работало. А ведь хочется получить просто коннект к mySql например, ну а как куда она это сохраняет в JavaEE чисто информативно понимать. А сейчас получается наоборот приходится перерыть кучу мест что сделать коннект к mySQl

так gui интерфейсы работают над jee. Так где приложение будет запускаться нет gui средств разработки, там даже исходного кода часто нету. Поэтому ide используют стандарты разработки и вытягивают инфу из них. Т.е. persistence.xml и pom.xml первоисточники а не ide. И это правильно, в ином случае если первоисточником была бы ide, то, чтобы запустить свой код на другом компе или сервере, необходимо было бы переносить все настройки своей ide, что чаще всего невозможно. "выясняется что все настройки коннектов приходится переделывать под конкретную реализацию application server javaEE" - если есть необходимость часто менять jee сервер, то стоит придерживаться разработке только на основе jee спецификаций, тогда переезд будет более простым, т.к. любое jee сервер приложений имеет в себе реализацию этой спецификации, которая дает одинаоквое поведение. Это как sql, у каждой бд есть свои бонусы, но если необходимо часто менять БД, то можно разрабатывать используя функционал sql92, т.к. большинство (возможно все) БД его реализуют. Ну и в принципе стоит выбрать 1 вариант jee сервера и остановиться на нем. Сейчас популярный фреймворк spring boot, который содержит embedded сервер. Ну или можно руками поднимать embedded, например jetty / tomcat

>>"Так где приложение будет запускаться нет gui средств разработки, там даже исходного кода часто нету. Поэтому ide используют стандарты разработки и вытягивают инфу из них. Т.е. persistence.xml и pom.xml первоисточники а не ide." Спасибо, но это не обнадеживает - для деплоя на application server мы как раз должны сконструировать совместимый persistent.xml и pom.xml c помощью IDE . В Netbeans для Payara есть официальный плагин, который вроде как должен облегчать разработку под этот application server. И видно что от отображает в разделе Services специфику коннектов , а в разделе библиотек перечень библиотек Payara-JakartaEE . Я ожидал, что с такими плагинами будет проще делать настройки и сохранять их в persistent.xml и pom.xml (а это только в JavaSE норм работает) Глубоко лезть в Spring boot на данном этапе получения опыта на Java пока нет желания, Я посмотрел примеры с их сайта, понял что он требует изучения массы Spring аннотаций, по сути отдельный язык заклинаний. К тому же в Spring не увидел упора на визуальные средства разработки, что существенно облегчает процесс. Сейчас в планах только небольшие микросервисы, Марка сервера приложений для меня не принципиальна, главное чтобы полностью спецификацию JavaEE поддерживала и работала. Напр Payara взял, потому что Grassfish с JSF даже hello word не мог отработать, и ошибок не выдавал

Спасибо, но это не обнадеживает - для деплоя на application server мы как раз должны сконструировать совместимый persistent.xml и pom.xml c помощью IDE .

хз у кого как я обычно помник руками заполняю, а persistent.xml заполнял последний раз несколько лет назад на учебном проекте

Марка сервера приложений для меня не принципиальна, главное чтобы полностью спецификацию JavaEE поддерживала и работала

Любой jee application server полностью поддерживает jee спецификацию и имеет реализации всей спецификации. Иначе он не называет application server

Глубоко лезть в Spring boot на данном этапе получения опыта на Java пока нет желания,

Ну не обязательно Spring boot, можно взять обычный спринг и embedded сервер. Но кажется, что генерация persistent.xml и pom.xml отвалилась за ненадобностью. Во всяком случае для меня. persistent.xml не использую, потому что есть спринг, даже при деполе на wildfly, pom.xml всегда заполнял руками, по другому даже особо не представляю как, мало ли че там система нагенерит, сиди потом разгребай ) Да и создание проекта обычно начинаю с пустого проекта + pom.xml, если использовать бут, то модно инициализатором набить все нужное