Сървърите на приложения на диета Класическите сървъри на приложения все още имат бъдещ JAXenter
Подходящи ли са днес сървърите за корпоративни приложения, както ги познаваме и обичаме през последните десет години? Или моделът на всестранната безгрижна работна среда, включително функционалността за управление и наблюдение, е остарял? Добър въпрос, на който EnterpriseTales се опитва да отговори.
Наскоро на конференция изнесох лекция на тема „Микроуслуги: Размерът няма значение - или е така?“ Като част от беседата, наред с други неща, бяха обсъдени „среди на работния процес“ за микроуслуги, като Spring Boot или Dropwizard. След това един от участниците се обърна към мен с интересен въпрос, който не бих искал да премълча от читателите на колоната EnterpriseTales: „Имат ли бъдеще класическите сървъри за приложения?“
JAX - Конференцията за Java, архитектура и софтуерни иновации
Типични архитектурни недостатъци - третият ще ви шокира!
с Еберхард Волф | INNOQ Германия GmbH
Работилница: Готини нови функции на Java - по-добър код с Java 9 до 16
с Майкъл Инден | на свободна практика
Големият пакет за обучение 3 в 1 с повече от 20 обучители и около 18 интензивни семинара
API за тестване и микроуслуги
с Арне Лимбург | отворено знание GmbH
Уъркшоп: Правилно проектиране на API - Дизайн за участие
с Уве Фридрихсен | кодоцентричен
Краят на една ера
Разбира се, сценариите, които описах в беседата, всъщност не предлагат дебел сървър за приложения като среда за изпълнение. Основното предимство на класическия сървър за приложения е това няколко Приложенията могат да се изпълняват на или в него успоредно и в същото време чисто отделени едно от друго. Тогава защо? един Използвайте сървъра за приложения само ако сте а Приложението или услугата иска да работи на тях?
Разбира се, сървърът на приложения предлага малко повече добавена стойност, отколкото просто чиста среда на изпълнение. Например, той осигурява инфраструктурата, необходима за приложението - като например връзката към база данни или JMS опашки - както и поддръжка за разполагане, управление и наблюдение на приложението. Освен това сървърът обикновено обединява редица библиотеки, които са съпоставени една с друга във версиите - т.е. съвместими - библиотеки, които предоставят полезни услуги на приложението и правят ръчното търсене на тези библиотеки остаряло. Библиотеките могат или да отговарят на стандарт, както при Java EE Application Servers, или просто да бъдат комбинация, която има смисъл за определени цели, както я познаваме от едната или другата дистрибуция на Tomcat, например. Всеки, който някога се е опитвал да добави желания набор от библиотеки към собственото си приложение и случайно е попаднал в load loader и версия ад, знае за какво говоря.
Следователно сървърът би бил идеален, който носи току-що споменатите предимства, но в същото време - от гледна точка на приложението, което трябва да бъде предоставено - се освобождава от ненужен баласт. Ако сървърът все още можеше да стане част от самото приложение и по този начин не бяха необходими отделна инсталация и управление на сървъра, да, нашият свят би бил идеален.
Сървър с тесен габарит
Точно описаният току-що сценарий се основава на съществуващи решения като Spring Boot, Dropwizard или Play. Досега те направиха име за себе си по-специално (но не само) в микросервизната среда. Но представителите на стандартизирания корпоративен свят на Java сървъри сега също са признали необходимостта и предлагат подходящи решения. В момента най-интересните представители са TomEE Shades, WildFly Swarm, Payara Micro GlassFish и KumuluzEE. Общото между всички решения е, че те прехвърлят подхода „вземете само това, от което се нуждаете“, известен от Dropwizard, в света на Java EE и като вграден сървър може да стане част от приложението, внедрено като JAR.
Поддръжник вместо сървър
Теснолинеен сървър или среда за изпълнение на яйца Wollmichsau?
Сървърите на приложения с претенцията да предоставят вълнена среда за снасяне на яйца, включително център за управление и наблюдение, изглеждат остарели в наши дни. И не само в средата на микроуслугите. От друга страна, процесните среди, които могат да бъдат индивидуално адаптирани към нуждите на съответното приложение, се оказват по-подходящи. Решения като Dropwizard и Spring Boot демонстрират, че двата свята не са напълно взаимно изключващи се и че дори и с вграден сървър с тесен габарит човек не трябва да се отказва от удобството и необходимите корпоративни функции. Първите доставчици от Java EE средата вече следват примера им, така че в бъдеще също така ще бъде възможно да се действа много по-гъвкаво в света на Java Enterprise Standard. Между другото: Можем да очакваме нов скок по отношение на гъвкавостта с проекта за модулация на Jigsaw. Тъй като обаче Jigsaw ще се предлага само с Java 9 и следователно не е задължително да се очаква, че той вече ще окаже влияние върху Java EE 8, ще трябва да изчакаме до 2020 г. от страна на стандартизирания сървър. Други решения, от друга страна, трябва да адаптират Jigsaw много по-рано. Имайки предвид това: Следете ...
Кажете в колоната Enterprise Tales Ларс Рьовекамп, Свен Кьолпин и Арне Лимбург (отворени знания) интересни истории и дава информативна информация за Java EE и цветния свят на Enterprise Java.