які переваги надає компонентна система 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; версія = 2, але бібліотека C може працювати лише з B; версія = 3. У стандартній Java вам не пощастило. У середовищі OSGi всі пакети ретельно впорядковані, і лише ті групи, які можуть співпрацювати, з'єднуються в одному просторі класу. Це дозволяє обидва пакети A і C функціонувати з власною бібліотекою. Хоча не рекомендується проектувати системи з цією версією версій, в деяких випадках це може врятувати життя.
Простий - API OSGi напрочуд простий. Основний API - це лише один пакет і менше 30 класів / інтерфейсів. Цього основного API достатньо для запису пакетів, їх встановлення, запуску, зупинки, оновлення та видалення та включає всі слухачі та класи безпеки. Є дуже мало API, які забезпечують стільки функціональних можливостей для так мало API.
Невеликий - OSGi Release 4 Framework може бути реалізований у файлі JAR розміром близько 300 Кб. Це невеликі накладні витрати на кількість функціональних можливостей, які додаються до програми, включаючи 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 відрізняються. Віртуальний мобільний телефон у мобільному телефоні, ймовірно, не підтримуватиме ті самі бібліотеки, що і основний модуль IBM, який працює з банківською програмою. Є два питання, про які слід подбати. По-перше, API OSGi не повинні використовувати класи, які доступні не у всіх середовищах. По-друге, пакет не повинен запускатися, якщо він містить код, який недоступний у середовищі виконання. Обидва ці питання були вирішені в специфікаціях OSGi.
Джерело: www.osgi.org/Technology/WhyOSGi