Добре известно е, че в езика за програмиране Java не поддържа модулност. Този проблем е забелязал, за дълго време, има неколкократни опити за коригиране на ситуацията. Ние сме преди всичко говорим за проекта Jigsaw.
Пъзел - пъзел (пъзел игра, в която отделни парчета, за да получите картинката трябва да добавите нагоре). Всяка част (модул) е свързан към другия (чрез интерфейси), за да се получи пълна картина (софтуера).
Така че това, което е модулността, които са предимствата на модулната архитектура на софтуера и какво да направите, преди появата на Java 9? Модулна софтуерна архитектура - е подход за проектиране, в която програмата е разделена на независими компоненти, които могат да взаимодействат помежду си чрез ясно описани договори. Тези компоненти - модули - трябва да имат няколко характеристики. Първо - капсулиране (те трябва да се скрие тяхното изпълнение от външната среда), а вторият - слаба връзка (модули взаимодействат само с помощта на предварително сключени договори), трети - динамика (възможно смяна "в движение", без да се налага да се спре цялото приложение).
Какво да правим, когато задачата е да се разработи истинска модулна архитектура в Java? Помощ идва OSGi (Gateway Инициатива отворено Services) - динамична спецификация модул на системата и платформа за услуги за Java-базирани приложения, разработени от OSGi Alliance. Спецификацията описва модел на развитие на софтуер, в които компонентите имат всички три характеристики, описани по-горе. В основата на концепцията за OSGi са 2 лица: комплекти (краищата) и услуги (услуги).
определя OSGi
За разработката на софтуер в Java, който обикновено се използва библиотеки на трети страни. В света на Java библиотеките са опаковани в специални файлове с буркана (Java архив). Това е нормална ZIP-файл, който съдържа Java-класа (с файлове за разширението .class). Използването на библиотеките може да бъде свързано с определени трудности.
След като започнете да използвате някоя библиотека в кандидатурата си, обикновено ще бъде на разположение за всички класове в библиотеката. Факт е, че библиотеката на разработчиците няма как да се скрие класове, които се използват за реализиране на тяхната вътрешна логика. По този начин, ако използвате код, който не е предвидено за използване извън библиотеката, може да попаднете на несъвместимост с новата версия на библиотеката, или да наруши правилното му функциониране.
Друг проблем е, така наречената JAR ада. Много разработчици са разбити много копия от него. Долната линия е, че след като имате началото на проекта трябва да се използва на различни версии на една и съща библиотека (обикновено мащабни проекти, които се развиват във времето), може да се сблъскате със ситуация, в която един и същи клас има различни методи в различните версии на библиотеката. Java е проектиран така, че първата версия на библиотеката, която ще се използва воля клас товарач. По този начин, като се позовава на кода за всеки клас по време на изпълнение, ще получите съобщение за грешка, че методът, към която се отнасят, не съществува. Това се дължи на факта, че Java Runtime не знае нищо за версията на библиотеката, за да се използва във всеки конкретен случай.
Заслужава да се отбележи, че разработчиците са решили да не променят OSGi JAR-файл структура да се гарантира, модулност и просто да добавят към тях допълнителна информация, която се използва OSGi среда. Нещо повече, тази допълнителна информация не засяга използването на JAR-файла в обичайните Java-приложения. Така че, за да JAR-файл е станал OSGi-комплект, добавя данни да се определи кои пакети от комплекта са достъпни за използване извън (Export-пакет) и всякакви други групи от пакети, необходими за този набор (Внос-пакет). Това е възможно да се определи като версия на API, който предвижда набор от други групи, както и версията или гама от версии на API, който е набор от изисквания за работата си от тях. Всички набор от класове, които не са сред вписванията за износ, не са налични извън снимачната площадка (Private). По този начин, набор от OSGi-изпълни изискването на слаба свързаност.
Сега повечето от Java-библиотеки вече са готови OSGi, т.е. предоставяне на информация на възможността на контейнера за в-OSGi. Също така има много инструменти и помощни програми, които ви позволяват да се създаде от обикновените JAR-файлове модулите за OSGi.
Фиг. 1. Импорт / Експорт пакети в OSGi-комплекти
Тъй като връзката между сериите и интерфейси, осигурени от тези договорености имат ясна версия, направете рамка OSGi го прави лесно да се избегне JAR Hell ситуации, които сме описани по-горе.
По този начин, леко разширение на обичайното описание JAR-файл и добавянето на поддръжка за тази спецификация в издръжливостта й, OSGi-общност реши проблема за създаване на модули в Java. OSGi по време на работа да динамично натоварване и разтоварване на нови комплекти по време на изпълнение. Освен това, OSGi проследява зависимости между сериите и динамично ги решава.
OSGi услуги
Така че, с OSGi набори, ние можем да разработим модулни приложения, които взаимодействат чрез интерфейси (API). Възниква въпросът: откъде да вземе клас, който реализира необходимата интерфейс? Добавяне на клас в набора от API - лошо решение, защото Модулната архитектура, ние се съгласихме да не използва вътрешни класове, определени извън тези комплекти. Това ще бъде възможно да се използва "фабрика" модел за изпълнение на интерфейса и да го добавите към набора от API, но всеки път, за разработване на нов клас да се скрие изпълнението на интерфейса също не изглежда най-добрата идея.
OSGi решава проблема с намирането на изпълнението на интерфейса чрез регистър услуга. Комплектът може да се регистрира с изпълнението описан от неговия интерфейс към регистъра на услуги. Комплект, който използва интерфейс от друга група да търсите в регистъра на изискваното изпълнение на желания интерфейс към него. Обикновено, декорите са регистрирани в началото услуги в OSGi-контейнера. Освен това, същия интерфейс с различни приложения и допълнителни данни за идентификация може да бъде вписан в служба регистър. В този комплект, който го търси в регистъра на исканата услуга може да избере най-подходящият (например чрез филтриране).
Mikroservisnaya архитектура в Java Virtual Machine
- Лекотата (в развитието на mikroservisa изпълнение се извършва само една определена част от тази функция. В този случай, няма нужда да се притеснявате за други части на програмата).
- Лесна за подмяна (ако решите, че сегашната изпълнението на услугата не си върши работата, лесно можете да го копирате и да го замени с нова версия, без да засягат другите части на програмата. Освен това, без да се спира на текущия софтуер).
- Повторно използване (като mikroservis изпълнява един малък проблем, може да се използва повторно, когато е необходимо).
Както се вижда от горното описание, разработчиците на приложения, използващи модулни OSGi отдавна се радва на всички предимства на mikroservisnoy архитектура, но само в рамките на виртуалната машина на Java. Всеки комплект с OSGi, която публикува на услугата до регистъра, е mikroservisom в рамките на Java Virtual Machine, JVM (в света на OSGi се наричат mikroservisy μServices).
Red Hat JBoss Fuse
Ние сме в центъра на софтуерни решения се използват всички предимства на OSGi за разработка на софтуер за телекомуникационни оператори, застрахователни компании за обработка на компании. За да направите това, ние използваме продукта Red Hat JBoss Fuse, а именно неговата конфигурация Fuse плат. JBoss Fuse платформа предоставя гъвкава среда за OSGi-производителни модулни приложения.
Днес, за да софтуерни такива изисквания, както непрекъсваемост на работата, предоставя възможност за лесно мащабиране, лесно използване, както и наличието на инструменти за управление на клъстер за клъстерните софтуер. Fuse Fabric решава тези проблеми. Технологията позволява да се разположи няколко екземпляра на Red Hat JBoss Fuse и да ги комбинира в един клъстер и осигурява централизиран инструмент за управление в резултат на околната среда.
Като част от Fuse материала следващите черпене:
- Функции (функции) - набор от най-OSGi набори, които прилагат никакви функции.
- Профили (профили) - набор от функции, които трябва да се извършат в един контейнер, както и настройки за конфигурация за сетове, които са включени в тази функция.
- Контейнери (съдове) - индивидуални JVM-процеси се изпълняват за конкретен възел клъстер Предпазител Fabric използвате Red Hat JBoss Предпазител контейнер.
Фиг. 3. йерархията на лица в Fuse Fabric
По този начин, всеки софтуер, който се основава на Fuse Fabric технология се състои от OSGi-комплекти са групирани в функции и разгърнати в рамките на една JVM-процес на един или повече възли в клъстера, в съответствие с предварително определен профил.
Сряда Fuse Fabric съдържа много инструменти, които позволяват лесно да се контролира производството на клъстери. Ние можем да създадем профили, профил базираната да създаде контейнери, създаване / изтриване / пускане / спиране на контейнерите за всеки хост, който е част от една група, свържете новия клъстер възли и т.н. И всички тези действия можем да извършват онлайн, т.е. без да се прекъсва работата на други възли в клъстера. Околна среда поддържа способността да съхранява няколко версии на профили, функции OSGi-комплекти.
В резултат среда OSGi настройки могат да не си взаимодействат само в рамките на един контейнер, но също така да се обадите един до друг в различни контейнери (дори и в рамките на отделните хостове). Тази възможност предоставя Разпределени OSGi технология. В допълнение - с минимални разходи за развойна дейност - всяка услуга, която предоставя OSGi-комплект може да се превърне REST / уеб-услуга, която може да бъде наречена от външни системи.
По този начин, с помощта на Fuse плат, можем да създадем mikroservisnuyu архитектура, която поддържа лесно конфигуриране и внедряване, изолираната извършването на услуги в рамките на своите JVM-процеси (с техните специфични настройки, например, различни настройки на събирачът), услугите, взаимодействат помежду си по мрежа с помощта на лек протокол.
защото продукт Red Hat JBoss Fuse се базира на Open Source стека на Apache ServiceMix технология, с които разполагаме, има мощни технологии, като Apache ActiveMQ (прилагане на спецификацията JMS), Apache Camel (изготвяне на конструктивна предприятие заявление модели), Apache CXF (библиотека за REST / уеб програмиране -Service), Blueprint (предоставя възможности зависимост инжектиране), пружина и т.н. Тъй като тези технологии безпроблемно интегрирани един с друг в Red Hat JBoss предпазител, това значително намалява времето за развитие изисква функционалност.
Свързани статии