Технологія OSA/Parlay

Складність побудови єдиної мережі нового покоління полягає в тому, що існуючі мережі фіксованого та мобільного зв’язку, мережі Інтернет побудовані за різними стандартами і їхнє програмне забезпечення взаємно не переноситься, що подекуди гальмує розвиток ринку послуг. Це особливо актуально для мобільних мереж: на сьогодні співіснують мережі різних стандартів (GSM, CDMA, WCDMA, TDMA, NMT тощо), а загальна мета полягає в тому, щоб досягти універсальності при звертанні до аплікацій на рівні управління послугами мережі. Концепція відкритого доступу до послуг OSA (Open Servіce Access) покликана вирішити завдання побудови мережі з такою архітектурою, при якій програмне забезпечення послуг не залежало б від конкретного виду мережі або технології. Архітектура Parlay є однією з практичних реалізацій концепції OSA.

Відкрита технологія OSA/Parlay була розроблена Parlay-консорціумом, до якого входять провідні світові виробники, постачальники програмних технологій і мережних рішень, а також оператори телекомунікаційних мереж. Розробка архітектури Parlay почалась у 1998 році з ініціативи Brіtіsh Telecom, Mіcrosoft, Nortel Networks, Sіemens і Ultіcom, до них приєдналися Cіsco, Erіcsson, ІBM, Lucent й ін. Нині кількість учасників Parlay-групи перевищує 60.

Відкрита технологія OSA/Parlay дозволяє створювати послуги для телекомунікаційних мереж, використовуючи звичний інструментарій й відкриті стандартні специфікації для програмування. При цьому Parlay є мостом не тільки між розробниками аплікацій і операторами мереж зв’язку, але й між традиційними ТМЗК, мультисервісними мережами та мобільними мережами 3G (рис. 10.2.7).

Рис. 10.2.7. Місце технології OSA/Parlay в системі управління послугами

Як показано на рис. 10.2.7, різні мережі зв’язку мають різні мережні елементи, які відповідають за управління послугами, зокрема:

• мобільні мережі включають SGSN (Serving GPRS Support Node) та MSC (Mobile Switching Center);
• телефонна мережа загального користування включає SSP (Service Switching Point) вузол кумутації послуг у ТМЗК;
• мобільні мережі 3-го покоління включають S-CSCF (Serving Call Session Control Function);
• відомчі мережі включають PBX.

Кожний із цих мережних елементів виходить на шлюз (Gateway) за своїм протоколом, а завдання шлюзу, згідно з концепцією OSA/Parlay, полягає в тому, щоб звести всі протоколи до єдиних інтерфейсів APІ (Applіed Programmіng Іnterface). OSA/Parlay забезпечує не тільки механізм доступу користувачів до послуг (сервісних аплікацій), але й механізм доступу з боку сервісних аплікацій до ресурсів телекомунікаційної мережі.

Сервіс-орієнтована архітектура

Сервіс-орієнтована архітектура (Service-Oriented Architecture, SОА) — це модель для об’єднання мережних та обчислювальних ресурсів з вимогами щодо досягнення бажаних результатів для споживачів сервісів, які можуть бути представлені як кінцевими користувачами, так і іншими сервісами. Ключове поняття SOA — інтерфейси, саме вони є засобом для надання сервісу та організації взаємодії сервісів. В інтерфейсі сервісу визначені параметри звертання до нього та описаний результат, тобто інтерфейс визначає суть сервісу, а не технологію його реалізації. SOA пропонує єдину схему взаємодії сервісів незалежно від того, чи перебуває сервіс у тій самій аплікації, в іншому адресному просторі системи, на іншій апаратній платформі в мережі. Усе це забезпечує гнучкість SOA, здатність системи, реалізованої в такій архітектурі, реагувати на зміни в бізнес-процесах динамічно та без складних трансформацій на інтеграційному рівні.

Як сервіс у SOA може виступати не лише ціла аплікація, але й окремі її функціональні модулі. Сервісами можуть бути прикладні функції, що реалізують певну бізнес-логіку, бізнес-транзакції, що складаються з декількох функцій більш низького рівня, а також системні функції, що відображають специфіку різних операційних платформ. Сервіс-орієнтована архітектура заснована на таких базових принципах: слабка зв’язаність (Loosely coupled) та «крупнозерниста» (coarse-grained) структура сервісів, реалізація яких дозволяє зняти найбільш гострі проблеми інтеграції аплікацій.

З погляду реалізації SOA слабка зв’язаність сервісів означає їх повну або часткову незалежність їх один від одного: вони виконують певні дії за запитами, отриманими від інших сервісів, і повертають результати. Всі деталі цього виконання повністю приховані, а зміни в реалізації сервісу ніяк не вплинуть на прикладний компонент, що використовує цей сервіс, і навпаки. Слабка зв’язаність забезпечує просту й швидку адаптацію системи до змін у структурі та принципах реалізації сервісів. «Крупнозерниста» структура сервісів у SOA пов’язана з тим, що на практиці у відповідності до принципів модульності сервіси компонуватимуться у високорівневі групи сервісів, які реалізують певні етапи бізнес-процесу або весь процес у цілому. Важливо, що з погляду архітектури сервіс, незалежно від внутрішньої структури та мови реалізації, має вигляд єдиного цілого.

На даному етапі свого розвитку сервіс-орієнтованої архітектури для опису та організації взаємодії використовують базові стандарти веб-сервісів:

• eXtensible Markup Language (XML) — для представлення даних;
• Web Services Definition Language (WSDL) — для опису доступних веб-сервісів;
• Universal Description, Discovery, Integration (UDDI) — для створення каталогу доступних по мережі веб-сервісів;
• Simple Object Access Protocol (SOAP) — для обміну даними.

Взаємодія сервісів здійснюється за принципом «публікація — пошук — з’єднання» (рис. 10.2.8): аплікація, яка надає певний сервіс (провайдер сервісу), розміщує інформацію про нього в каталозі сервісів. Споживач сервісу — аплікація, якій необхідна функціональність даного сервісу, знаходить інформацію про нього в каталозі, для того щоб установити з’єднання із цим сервісом і надіслати запит.

Рис.10.2.8. Взаємодія сервісів за принципом «публікація — пошук — з’єднання»

Інтегроване середовище розробки. SOA має розглядатися не лише як архітектура для організації та виконання розподілених прикладних рішень, але і як модель програмування, у якій аплікації будуються виходячи з того, що вони надають у мережному середовищі сервіси іншим аплікаціям за допомогою опису та публікації відповідних інтерфейсів. Тому однією з основних вимог до реалізації SOA є розгортання середовища розробки на базі стандартної компонентної платформи (J2EE або .NET), що надасть інструментарій для розробки й тестування веб-сервісів, забезпечить багаторазове використання створюваних програмних модулів і дасть можливість представити існуючі прикладні функції за допомогою стандартних інтерфейсів.

Інфраструктура інтеграції та управління сервісами. Для організації взаємодії сервісів необхідне середовище, яке забезпечить динамічну маршрутизацію запитів від прикладного компонента — споживача сервісу та одержання результатів від аплікації — провайдера сервісу. Для цього може знадобитися підтримка синхронних і асинхронних комунікацій більш низького рівня між аплікаціями, трансформація та високошвидкісний розподіл даних, трансляція протоколів, кешування функцій веб-сервісів, віртуалізація введення/виведення тощо. Для розв’язання цих завдань все більшого поширення набуває технологія корпоративної сервісної шини (Enterprіse Servіce Bus, ESB), яка надає єдиний механізм для передачі запитів і отримання результатів сервісів, виконання необхідних перетворень повідомлень і транспортних протоколів, управління потоком звернень до сервісів.

Кінцева мета SOA полягає в забезпеченні подання бізнес-процесів як взаємодіючих сервісів. Засоби управління бізнес-процесами забезпечують інтеграцію в потрібній послідовності сервісів, які можуть бути як локальними — реалізованими в інформаційній інфраструктурі компанії, так і віддаленими, якщо процес на певних етапах звертається до ресурсів партнерських компаній. Стандартом для такої інтеграції стає розроблена фірмами ІBM та Mіcrosoft мова BPEL — Busіness Process Executіon Language.

У найбільш загальному вигляді SOA передбачає наявність трьох основних учасників: постачальника сервісу, споживача сервісу та реєстру сервісів (рис. 10.2.9). Взаємодія учасників має досить простий вигляд: постачальник сервісу реєструє свої сервіси в реєстрі, а споживач звертається до реєстру із запитом.

Рис. 10.2.9. Узагальнена схема SOA

Для використання сервісу необхідно відповідати положенням угоди про інтерфейс для звернення до сервісу — інтерфейс повинен не залежати від платформи. SOA реалізує масштабованість сервісів — можливість нарощування сервісів, а також їхню модернізацію. Постачальник сервісу та його споживач виявляються незв’язаними — вони спілкуються за допомогою повідомлень. Оскільки інтерфейс повинен не залежати від платформи, то й технологія, яка використовується для визначення повідомлень, також повинна не залежати від платформи. Тому, як правило, повідомлення є XML-документами, які відповідають XML-схемі.

Переваги використання SOA. Перш ніж перелічити переваги використання SOA, слід нагадати, що переваги бувають різні: стратегічні й тактичні.

До стратегічних переваг SOA слід віднести:

• скорочення часу реалізації проектів, або «часу виходу на ринок»;
• підвищення продуктивності системи;
• більша швидкість і менша вартість інтеграції аплікації.

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

До тактичних переваг SOA належать:

• більш проста розробка та впровадження аплікацій;
• використання поточних інвестицій;
• зменшення ризику, пов’язаного із впровадженням проектів у галузі автоматизації послуг і процесів;
• можливість безперервного поліпшення надаваної послуги;
• скорочення числа звернень за технічною підтримкою;
• підвищення показника повернення інвестицій.

Перспективи SOA. Компанія Sіemens Communіcatіons представила перші результати своєї ініціативи в галузі створення інструментарію SOA, заявивши про розширення застосування принципів SOA із внутрішніх проектів розробки до проектів, які проводилися разом з бізнес-партнерами. Компонентами SOA-інструментарію Sіemens, який реалізує багаторазово застосовувані телекомунікаційні сервіси, користуватимуться у своїх продуктах корпорації ІBM і SAP. Остання, зокрема, інтегрує розроблений у Sіemens компонент, відповідальний за управління ідентифікацією та доступом, у платформу побудови аплікацій NetWeaver. ІBM, у свою чергу, вмонтує низку телекомунікаційних функцій SOA-інструментарію Sіemens у запропоновані своїм замовникам бізнес-аплікації. Використовуючи комплект засобів розробки, створений у Sіemens, Mіcrosoft вмонтувала реалізовані SOA-інфраструктурою Sіemens функції підтримки розпізнавання мережного статусу в Wіndows Lіve Communіcatіons Server. Сама Sіemens на базі компонентів телекомунікаційної SOA багаторазового використання побудувала засоби адміністрування програмної ІP-АТС HіPath 800.