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