Сервери програм на дієті Класичні сервери додатків все ще мають майбутній JAXenter

сервери

Чи є сервери корпоративних додатків, як ми їх пізнавали і любимо за останні десять років, як і раніше доречні сьогодні? Або модель всебічного безтурботного середовища робочого процесу, включаючи функції управління та моніторингу, застаріла? Гарне запитання, на яке намагається відповісти EnterpriseTales.

Нещодавно на конференції я прочитав лекцію на тему "Мікропослуги: розмір не має значення - чи це?" Під час бесіди, серед іншого, обговорювались «середовища робочого циклу» для мікросервісів, таких як Spring Boot або Dropwizard. Згодом один із учасників звернувся до мене з цікавим запитанням, яке я не хотів би замовчувати читачам колонки EnterpriseTales: "Чи є у класичних серверів додатків ще майбутнє?"

JAX - Конференція для Java, архітектури та інновацій програмного забезпечення

Типові архітектурні помилки - третя вас шокує!

з Еберхардом Вольфом | INNOQ Німеччина GmbH

Семінар: Нові цікаві функції Java - кращий код з Java 9 до 16

з Майклом Інденом | фрілансер

Великий навчальний пакет 3-в-1, що включає понад 20 тренерів та близько 18 інтенсивних семінарів

Тестування API та мікросервісів

з Арне Лімбург | open knowledge GmbH

Семінар: Як правильно розробити API-дизайн - Дизайн для участі

з Уве Фрідріхсеном | кодоцентричний

Кінець епохи

Слід визнати, що сценарії, описані мною в розмові, насправді не пропонують жирний сервер додатків як середовище виконання. Оскільки головна перевага класичного сервера додатків полягає в тому кілька Програми можуть працювати на ній або в ній паралельно і в той же час чисто відокремлено одне від одного. То чому тоді? один Використовуйте лише сервер додатків a Додаток або послуга хоче працювати на них?

Звичайно, сервер додатків пропонує трохи більше доданої вартості, ніж просто середовище чистого виконання. Наприклад, він забезпечує інфраструктуру, необхідну для програми - наприклад, підключення до бази даних або черги JMS, - а також підтримку розгортання, управління та моніторингу програми. Крім того, сервер, як правило, поєднує в собі ряд бібліотек, які відповідають одна одній у версіях - тобто сумісних -, які надають корисні послуги додатку та роблять ручний пошук цих бібліотек застарілим. Бібліотеки можуть або відповідати стандарту, як у випадку з серверами додатків Java EE, або просто бути комбінацією, яка має сенс для певних цілей, як ми знаємо з одного чи іншого дистрибутива Tomcat, наприклад. Той, хто хоч раз намагався додати бажаний набір бібліотек до власного додатку і випадково потрапив у завантажувач класів та версію пекла, знає, про що я говорю.

Отже, сервер буде ідеальним, що приносить щойно згадані переваги, але в той же час - з точки зору програми, яка буде доступною - позбавляється непотрібного баласту. Якби сервер тоді все ще міг стати частиною самої програми, і, отже, не потрібна була окрема установка та управління сервером, так, наш світ був би ідеальним.

Вузькоколійний сервер

Саме описаний сценарій базується на існуючих рішеннях, таких як 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.