Какви ползи ви предоставя компонентната система на OSGi?
Е, ето доста голям списък:

Намалена сложност - Разработването с OSGi технология означава разработване на пакети: OSGi компонентите. Пакетите са модули. Те крият вътрешността си от други пакети и комуникират чрез добре дефинирани услуги. Скриването на вътрешни елементи означава повече свобода за промяна по-късно. Това не само намалява броя на грешките, но също така прави пакетите по-лесни за разработване, тъй като пакетите с правилен размер изпълняват част от функционалността чрез добре дефинирани интерфейси. Има интересен блог, който описва какво е направила OSGi технологията за техния процес на разработка.

Повторно използване - OSGi компонентният модел прави много лесно използването на много компоненти на трети страни в приложение. Все по-голям брой проекти с отворен код предоставят своите JAR файлове, готови за OSGi. Въпреки това търговските библиотеки също стават достъпни като готови пакети.

Реален свят - OSGi рамката е динамична. Той може да актуализира пакети в движение и услугите могат да идват и да си отиват. Разработчиците, свикнали с по-традиционната Java, виждат това като много проблематична функция и не виждат предимството. Оказва се обаче, че реалният свят е силно динамичен и наличието на динамични услуги, които могат да идват и си отиват, прави услугите перфектни за много сценарии от реалния свят. Например услуга може да моделира устройство в мрежата. Ако устройството бъде открито, услугата се регистрира. Ако устройството изчезне, услугата е нерегистрирана. Има изненадващ брой сценарии от реалния свят, които съответстват на този динамичен модел на обслужване. Следователно приложенията могат да използват повторно мощните примитиви на регистъра на услугите (регистриране, получаване, списък с експресивен филтърен език и изчакване услугите да се появят и изчезнат) в техния собствен домейн. Това не само спестява писане на код, но също така осигурява глобална видимост, инструменти за отстраняване на грешки и повече функционалност, отколкото би било приложено за специално решение. Писането на код в такава динамична среда звучи като кошмар, но за щастие има поддържащи класове и рамки, които премахват повечето, ако не и всички, от болката.

Лесно внедряване - OSGi технологията не е просто стандарт за компоненти. Той също така определя как компонентите се инсталират и управляват. Този API е използван от много пакети за предоставяне на агент за управление. Този агент за управление може да бъде толкова прост, колкото командна обвивка, драйвер за протокол за управление TR-69, драйвер за протокол OMA DM, облачен интерфейс за EC2 на Amazon или система за управление IBM Tivoli. Стандартизираният API за управление прави много лесно интегрирането на OSGi технология в съществуващи и бъдещи системи.

Динамични актуализации – OSGi компонентният модел е динамичен модел. Пакетите могат да бъдат инсталирани, стартирани, спрени, актуализирани и деинсталирани, без да се сваля цялата система. Много разработчици на Java не вярват, че това може да се направи надеждно и затова първоначално не го използват в производството. Въпреки това, след като използват това в разработката известно време, повечето започват да осъзнават, че действително работи и значително намалява времето за внедряване.

Адаптивен - OSGi компонентният модел е проектиран от самото начало, за да позволи смесването и съвпадението на компоненти. Това изисква зависимостите на компонентите да бъдат посочени и изисква компонентите да живеят в среда, в която техните незадължителни зависимости не винаги са налични. Регистърът на OSGi услугата е динамичен регистър, където пакетите могат да се регистрират, получават и слушат услуги. Този динамичен модел на услуга позволява на пакетите да открият какви възможности са налични в системата и да адаптират функционалността, която могат да предоставят. Това прави кода по-гъвкав и устойчив на промени.

Прозрачност - Пакетите и услугите са първокласни граждани в OSGi средата. API за управление предоставя достъп до вътрешното състояние на пакет, както и как е свързан с други пакети. Например, повечето рамки предоставят командна обвивка, която показва това вътрешно състояние. Части от приложенията могат да бъдат спрени за отстраняване на грешки при определен проблем или могат да бъдат въведени диагностични пакети. Вместо да се взират в милиони редове изходни данни и дълги времена за рестартиране, OSGi приложенията често могат да бъдат отстранени грешки с командна обвивка на живо.

Версии - Технологията OSGi разрешава ада на JAR. JAR адът е проблемът, че библиотека A работи с библиотека B;version=2, но библиотека C може да работи само с B;version=3. В стандартната Java нямате късмет. В OSGi средата всички пакети са внимателно версионирани и само пакети, които могат да си сътрудничат, са свързани заедно в едно и също класово пространство. Това позволява на двата пакета A и C да функционират със собствена библиотека. Въпреки че не се препоръчва да се проектират системи с този проблем с версиите, в някои случаи това може да бъде животоспасяващо.

Прост - OSGi API е изненадващо прост. Основният API е само един пакет и по-малко от 30 класа/интерфейса. Този основен API е достатъчен за писане на пакети, инсталирането им, стартирането, спирането, актуализирането и деинсталирането им и включва всички слушатели и класове за сигурност. Има много малко API, които предоставят толкова много функционалност за толкова малко API.

Малък - OSGi Release 4 Framework може да бъде внедрен в около 300KB JAR файл. Това са малки режийни разходи за количеството функционалност, която се добавя към приложението чрез включване на OSGi. Следователно OSGi работи на голям набор от устройства: от много малки, до малки, до мейнфрейми. Той изисква само минимална Java VM за стартиране и добавя много малко към него.

Бързо – Една от основните отговорности на рамката OSGi е зареждането на класовете от пакети. В традиционната Java JAR файловете са напълно видими и поставени в линеен списък. Търсенето на клас изисква търсене в този (често много дълъг, 150 не е необичайно) списък. Обратно, OSGi предварително свързва пакети и знае за всеки пакет точно кой пакет предоставя класа. Тази липса на търсене е значителен фактор за ускоряване при стартиране.

Мързелив - Мързелът в софтуера е добър и технологията OSGi разполага с много механизми, за да прави неща само когато наистина са необходими. Например, пакетите могат да бъдат стартирани с нетърпение, но също така могат да бъдат конфигурирани да стартират само когато други пакети ги използват. Услугите могат да бъдат регистрирани, но само когато се използват. Спецификациите са оптимизирани няколко пъти, за да позволят този вид мързеливи сценарии, които могат да спестят огромни разходи за изпълнение.

Сигурен - Java има много мощен фин модел за сигурност в долната част, но се оказа много труден за конфигуриране на практика. Резултатът е, че повечето защитени Java приложения работят с двоичен избор: без защита или с много ограничени възможности. Моделът за сигурност на OSGi използва модела за фина сигурност, но подобрява използваемостта (както и втвърдяването на оригиналния модел), като накара разработчика на пакета да уточни исканите подробности за сигурността в лесно проверена форма, докато операторът на средата остава изцяло отговорен. Като цяло OSGi вероятно осигурява една от най-сигурните среди за приложения, която все още може да се използва, освен хардуерно защитените компютърни платформи.

Ненатрапчиви - Приложенията (пакети) в OSGi среда са оставени сами. Те могат да използват практически всяко съоръжение на VM, без OSGi да ги ограничава. Най-добрата практика в OSGi е да се пишат обикновени стари Java обекти и поради тази причина не е необходим специален интерфейс за OSGi услуги, дори Java String обект може да действа като OSGi услуга. Тази стратегия прави кода на приложението по-лесен за пренасяне в друга среда.

Върви навсякъде - Е, зависи. Първоначалната цел на Java беше да работи навсякъде. Очевидно е, че не е възможно да се изпълнява целият код навсякъде, защото възможностите на Java VM се различават. VM в мобилен телефон вероятно няма да поддържа същите библиотеки като IBM мейнфрейм, работещ с банково приложение. Има два проблема, за които трябва да се погрижим. Първо, OSGi API не трябва да използват класове, които не са налични във всички среди. Второ, пакетът не трябва да стартира, ако съдържа код, който не е наличен в средата за изпълнение. И двата проблема са разгледани в спецификациите на OSGi.

Източник: www.osgi.org/Technology/WhyOSGi

Открих следните предимства от OSGi:

• Всеки плъгин е версионен артефакт, който има собствен зареждащ клас.
• Всеки плъгин зависи както от конкретни буркани, които съдържа, така и от други специфични версии на плъгини.
• Поради версията и изолираните зареждащи класове, различни версии на един и същ артефакт могат да бъдат заредени едновременно. Ако един компонент на вашето приложение разчита на една версия на добавка, а друг зависи от друга версия, и двата могат да бъдат заредени едновременно.

С това можете да структурирате приложението си като набор от артефакти на плъгини с версии, които се зареждат при поискване. Всеки плъгин е самостоятелен компонент. Точно както Maven ви помага да структурирате вашата компилация, така че да е повторяема и дефинирана от набор от специфични версии на артефакти, от които е създадена, OSGi ви помага да направите това по време на изпълнение.

Не ми пука много за възможността за горещо включване на OSGi модулите (поне в момента). Това е по-скоро наложената модулност. Липсата на милиони „обществени“ класове, налични на classpath по всяко време, предпазва добре от кръгови зависимости: Трябва наистина да помислите за своите публични интерфейси – не само от гледна точка на езиковата конструкция на Java „публичен“, но и от гледна точка на вашата библиотека /module: Какви (точно) са компонентите, които искате да направите достъпни за другите? Какви (точно) са интерфейсите (на други модули), от които наистина се нуждаете, за да реализирате вашата функционалност?

Хубаво е, че hotplug идва с него, но бих предпочел да рестартирам обичайните си приложения, отколкото да тествам всички комбинации от hotplugability...

• По аналогия можете да смените двигателя на колата си, без да я изключвате.
• Можете да персонализирате сложни системи за клиентите. Вижте силата на Eclipse.
• Можете да използвате повторно цели компоненти. По-добре от просто предмети.
• Използвате стабилна платформа за разработване на приложения, базирани на компоненти. Ползите от това са огромни.
• Можете да създавате компоненти с концепцията за черна кутия. Другите компоненти не трябва да знаят за скритите интерфейси, те виждат само публикуваните интерфейси.
• Можете да използвате в една и съща система няколко еднакви компонента, но в различни версии, без да компрометирате приложението. OSGi решава проблема с Jar Hell.
• С OSGi вие развивате мислене за проектиране на системи с CBD

Има много предимства (сега припомних само тези), достъпни за всеки, който използва Java.

редактирано за яснота. OSGi страницата даде по-добър прост отговор от моя

Прост отговор: OSGi Service Platform предоставя стандартизирана, компонентно ориентирана изчислителна среда за кооперирани мрежови услуги. Тази архитектура значително намалява цялостната сложност на изграждането, поддържането и внедряването на приложения. OSGi Service Platform предоставя функции за динамична промяна на състава на устройството на различни мрежи, без да се изисква рестартиране.

В една структура на приложение, да речем Eclipse IDE, не е голяма работа да рестартирате, когато инсталирате нов плъгин. Използвайки изцяло внедряването на OSGi, трябва да можете да добавяте плъгини по време на изпълнение, да получавате новата функционалност, но изобщо не трябва да рестартирате eclipse.

Отново, не е голяма работа за всеки ден, използване на малки приложения.

Но когато започнете да разглеждате многокомпютърни рамки за разпределени приложения, това е мястото, където започва да става интересно. Когато трябва да имате 100% непрекъсната работа за критични системи, възможността за бърза смяна на компоненти или добавяне на нова функционалност по време на изпълнение е полезна. Разбира се, има възможности за правене на това сега в по-голямата си част, но OSGi се опитва да обедини всичко в хубава малка рамка с общи интерфейси.

OSGi решава ли често срещани проблеми, не съм сигурен в това. Искам да кажа, че може, но режийните разходи може да не си струват за по-прости проблеми. Но това е нещо, което трябва да имате предвид, когато започвате да работите с по-големи, мрежови приложения.

Няколко неща, които ме подлудяват относно OSGi:

1) Имплементациите и техните контекстни зареждащи устройства имат много странности и могат да бъдат донякъде асинхронни (използваме felix вътре в confluence). В сравнение с чиста пролет (без DM), където [main] до голяма степен преминава през всичко синхронизирано.

2)Класовете не са равни след горещ товар. Да речем, че имате кеш слой tangosol в хибернация. Той е изпълнен с Fork.class, извън обхвата на OSGi. Зареждате нов буркан горещо и Fork не се е променил. Class[Fork] != Class[Fork]. Появява се и по време на сериализация поради същите основни причини.

3) Групиране.

Можете да заобиколите тези неща, но това е голяма голяма болка и прави вашата архитектура да изглежда недостатъчна.

И за онези от вас, които рекламират hotplugging... Клиент №1 на OSGi? Затъмнение. Какво прави Eclipse след зареждане на пакета?

Рестартира се.

OSGi кара вашия код да хвърля NoClassDefFoundError и ClassNotFoundException без видима причина (най-вероятно защото сте забравили да експортирате пакет в конфигурационния файл на OSGi); тъй като има ClassLoaders, той може да накара вашия клас com.example.Foo да не бъде прехвърлен към com.example.Foo, тъй като всъщност това са два различни класа, заредени от два различни classloaders. Може да накара вашия Eclipse да се зареди в OSGi конзола след инсталиране на приставка за Eclipse.

За мен OSGi само добави сложност (защото добави още един ментален модел, за да мога да хвърля), добави дразнене поради изключения; Никога не съм се нуждаел от динамиката, която "предлага". Беше натрапчиво, тъй като изискваше конфигурация на OSGi пакет за всички модули; определено не беше просто (в по-голям проект).

Поради лошия си опит съм склонен да стоя далеч от това чудовище, благодаря ви много. Предпочитам да страдам от ада на зависимостта от jar, тъй като това е много по-лесно разбираемо от ада за зареждане на класове, който OSGi въвежда.

Тепърва ще съм "фен" на OSGi...

Работил съм с корпоративно приложение в компании от Fortune 100. Наскоро продуктът, който използваме, е "надграден" до изпълнение на OSGi.

стартиране на локално разгръщане на CBA... [2/18/14 8:47:23:727 EST] 00000347 CheckForOasis

най-накрая разгърнати и „следните пакети ще бъдат задържани и след това рестартирани“ [2/18/14 9:38:33:108 EST] 00000143 AriesApplicat I CWSAI0054I: Като част от операция за актуализиране на приложение

51 минути... всеки път, когато кодът се променя... Предишната версия (не-OSGi) щеше да се внедри за по-малко от 5 минути на по-стари машини за разработка.

на машина с 16 гига RAM и 40 свободни гига диск и Intel i5-3437U 1.9 GHz CPU

„Ползата“ от това надграждане беше продадена като подобряване на (производствените) внедрявания – дейност, която извършваме около 4 пъти годишно с може би 2-4 малки внедрявания на корекции годишно. Добавянето на 45 минути на ден към 15 души (QA и разработчици) не мога да си представя, че някога ще бъда оправдано. В големите корпоративни приложения, ако вашето приложение е основно приложение, тогава промяната му е правилно (малките промени имат потенциал за далечни въздействия - трябва да бъдат комуникирани и планирани с потребителите в цялото предприятие), монументална дейност - грешна архитектура за OSGi. Ако вашето приложение не е корпоративно приложение - т.е. всеки потребител може да има свой собствен персонализиран модул, който вероятно да удря собствения си силоз от данни в собствената си силна база данни и да работи на сървър, който хоства много приложения, тогава може би погледнете OSGi. Поне това е моят опит досега.

Ако приложение, базирано на Java, изисква добавяне или премахване на модули (разширяване на основната функционалност на приложението), без да се изключва JVM, може да се използва OSGI. Обикновено, ако разходите за изключване на JVM са повече, само за актуализиране или за подобряване на функционалността.

Примери:

1. Eclipse: Предоставя платформа за плъгини за инсталиране, деинсталиране, актуализиране и взаимозависимост.
2. AEM: WCM приложение, където промяната на функционалността ще се ръководи от бизнеса, който не може да си позволи прекъсвания за поддръжка.

Забележка: Spring framework спря да поддържа OSGI spring пакети, считайки го за ненужна сложност за базирани на транзакции приложения или за някакъв момент в тези редове. Аз лично не разглеждам OSGI, освен ако не е абсолютно необходимо, в нещо голямо като изграждане на платформа.

Работя с OSGi почти 8 години и трябва да кажа, че трябва да обмислите OSGi само ако имате бизнес нужда да актуализирате, премахнете, инсталирате или замените компонент по време на изпълнение. Това също означава, че трябва да имате модулно мислене и да разбирате какво означава модулност. Има някои аргументи, че OSGi е лек - да, това е вярно, но има и някои други рамки, които са леки и по-лесни за поддръжка и развитие. Същото важи и за защитената java бла бла.

OSGi изисква солидна архитектура, за да се използва правилно и е доста лесно да се направи OSGi-система, която също толкова лесно може да бъде самостоятелен-изпълним буркан, без да е включен OSGi.

OSGi осигурява следните предимства:

■ Преносима и сигурна среда за изпълнение, базирана на Java

■ Система за управление на услуги, която може да се използва за регистриране и споделяне на услуги в пакети и отделяне на доставчиците на услуги от потребителите на услуги

■ Динамична модулна система, която може да се използва за динамично инсталиране и деинсталиране на Java модули, които OSGi нарича пакети

■ Леко и мащабируемо решение

Също така се използва за осигуряване на допълнителна преносимост на мидълуер и приложения от мобилната страна. Мобилната страна е достъпна за WinMo, Symbian, Android например. Веднага щом настъпи интеграция с функциите на устройството, може да се фрагментира.

Най-малкото, OSGi ви кара да МИСЛИТЕ за модулност, повторно използване на код, версии и като цяло водопровода на един проект.

Други вече очертаха предимствата подробно, с това обяснявам практическите случаи на употреба, които съм виждал или използвал OSGi.

1. В едно от нашите приложения имаме поток, базиран на събития, а потокът е дефиниран в плъгини, базирани на OSGi платформа, така че утре, ако някой клиент иска различен/допълнителен поток, тогава той просто трябва да внедри още един плъгин, да го конфигурира от нашата конзола и готово .
2. Използва се за разгръщане на различни конектори за Store, например, да предположим, че вече имаме Oracle DB конектор и утре mongodb трябва да бъде свързан, след това напишете нов конектор и го разположете и конфигурирайте подробностите чрез конзолата и отново сте готови. внедряването на конектори се управлява от OSGi plugin framework.

Вече има доста убедително изявление в официалния му сайт, мога да го цитирам

Основната причина OSGi технологията да е толкова успешна е, че предоставя много зряла компонентна система, която действително работи в изненадващ брой среди. Компонентната система OSGi всъщност се използва за изграждане на много сложни приложения като IDE (Eclipse), сървъри за приложения (GlassFish, IBM Websphere, Oracle/BEA Weblogic, Jonas, JBoss), рамки за приложения (Spring, Guice), индустриална автоматизация, жилищни шлюзове, телефони и много други.

Що се отнася до ползите за разработчика?

РАЗРАБОТЧИЦИ: OSGi намалява сложността, като предоставя модулна архитектура за днешните широкомащабни разпределени системи, както и малки, вградени приложения. Изграждането на системи от вътрешни и готови модули значително намалява сложността и по този начин разходите за разработка и поддръжка. Моделът за програмиране OSGi реализира обещанието за системи, базирани на компоненти.

Моля, проверете подробностите в Предимства от използването на OSGi.