Засоби middleware та їх класифікація
До засобів middleware (проміжного або міжплатформного, програмного забезпечення) зараз проявляється великий інтерес. Ринок цих коштів зростав останнім часом експоненційно, і за різними оцінками, найближчими роками така тенденція збережеться. У цій статті робиться спроба відповісти на запитання “Що таке middleware?”, пропонується класифікація засобів middleware та визначення сфери їх застосування.
Термін "проміжне програмне забезпечення" (ППО) є досить усталеним, але в той же час його нерідко використовують для позначення різних понять. З загальної точки зору ППО є типом програмного забезпечення, що надає API між додатком та ресурсами, необхідними для нормального функціонування. Виходячи з цього, проміжним може бути назване будь-яке програмне забезпечення, що дозволяє спростити процес взаємодії додатків один з одним або з ресурсами. Виникає логічне питання: а чи є операційна система ППО? У загальноприйнятому сенсі - ні, тому є доцільним більш вузьке визначення: проміжним називається програмне забезпечення, що надає інтерфейси між додатком і необхідними програмними ресурсами (які також можуть бути додатками).
ППО виконує дві основні функції. Перша – полегшення доступу додатків до ресурсів. Така функціональність важлива передусім для розробників інформаційних систем, оскільки дозволяє їм більшу частину часу приділяти створенню бізнес-логіки, а не розробці механізмів доступу до ресурсів. Друга функція ППО – прискорення процесів взаємодії. Дійсно, ПЗ, спеціально спроектоване для забезпечення взаємодії, як правило, має кращу продуктивність порівняно з неспеціалізованим рішенням, створеним розробником.
Всі засоби middleware можна розділити на дві великі групи: ППО першою з них забезпечує взаємодію між активним додатком та пасивним ресурсом (див. малюнок), другий – між активними додатками. Під активним ми маємо на увазі програму, що реалізує деяку бізнес-логіку, а роль пасивного ресурсу може виконувати, наприклад, сервер бази даних.
Класифікація засобів middleware
Першу групу можна розбити на дві основні підгрупи: ППО для роботи з базами даних та монітори транзакцій.
ППО для роботи з базами даних ППО для роботи з серверами БД є найвідомішим і найчастіше використовується. Найважливіша його функція - надання API для доступу до локальних чи віддалених баз. У цьому від розробника виявляються приховані як особливості ОС, а й локальність бази даних.
До цього типу ППО відносяться засоби реалізації специфікацій ODBC (Object Database Connectivity), OLE DB, JDBC (Java Object Database Connectivity). Засоби ODBC, зокрема, дають розробнику певний "базовий" набір функцій, які підтримують різні сервери реляційних баз даних. Програміст, який використовує цей API, не дбає про те, до якого сервера він звертається, - ці функції перекладені на ODBC, що дозволяє приділяти більше уваги основної логіки створюваної програми.
Монітори транзакцій. Якщо ППО доступу до БД вирішує саме проблему взаємодії з БД, монітори обробки транзакцій (в англомовній спец. літературі - TP-монітори) оптимізують роботу системи. TP-монітори розташовуються між клієнтом та сервером БД і є другим рівнем триланкової архітектури. Клієнтська програма ініціює транзакцію в моніторі. Той, у свою чергу, запускає за необхідності транзакцію бази даних, отримує їїрезультат та перенаправляє його назад клієнтському додатку.
Основна перевага транзакцій у тому, що вони дозволяють "оформити" частину програми як транзакцію. Транзакція відрізняється від простої послідовності команд своєю цілісністю: якщо під час її виконання виникає та чи інша критична ситуація (наприклад, відмова одного з ресурсів), ТР-монітор може автоматично повернути систему у вихідний стан (здійснити відкат транзакції). Підтримка транзакційності властива багатьом системам, а не лише ТР-моніторам. Що ж змушує виділяти в окрему групу ППО? Такою відмінністю є здатність оптимізації доступу до ресурсів. Зокрема, оскільки клієнти у триланковій архітектурі безпосередньо до СУБД не підключаються, монітор транзакцій може здійснювати мультиплексування (накопичення або змішування) запитів, спрямовуючи їхню пачку в рамках одного підключення до БД. Крім того, клієнтська програма може ініціювати транзакцію, що містить запити на зміну інформації в декількох базах даних, не обов'язково однорідних. Монітор транзакцій і в цьому випадку виконує функції ППО, надаючи програмі віртуальний доступ до різних БД.
Найбільш популярними моніторами транзакцій є Microsoft Transaction Server, Tuxedo фірми BEA Systems, CICS виробництва IBM, Encina компанії Transarc та ін.
ППО другого типу
ППО, віднесене за нашою класифікацією до другої групи (middleware, що забезпечує взаємодію між активними додатками), може бути умовно розбито на три основні типи: ППО віддаленого виклику процедур (RPC, Remots Procedure Call), ППО передачі повідомлень (MOM, Message Orientet middleware) та ППО брокерів об'єктних запитів (ORB, Object Request Broker).
Технологія RPC. RPC булапершої над ринком проміжного ПО (хоча тоді такого поняття немає). Кошти RPC з'явилися на початку 80-х років, а їх головним призначенням було забезпечення можливості виділення частини створюваної програми для виконання на віддаленій машині. При використанні RPC розробник організує виклик віддаленого методу програми так, ніби код цієї функції знаходився в локальній машині. Код RPC "приєднується" до обох додатків - джерела та приймача, здійснює необхідні перетворення даних та запускає підпрограми передачі даних по мережі.
Донедавна застосування RPC було пов'язане з чималими складнощами, коли доводилося звертатися до додатку, написаному іншою мовою програмування або працює під іншою ОС. Сучасні засоби RPC дозволяють розробнику діяти на вищому рівні абстракції, не замислюючись про специфіку мови програмування та ОС - RPC стала зручним механізмом для взаємодії додатків на різних програмно-апаратних платформах. Поширення Java викликало до життя аналог RPC для Java-додатків – RMI (Remote Method Invocation).
Використання RPC накладає певні обмеження на тип зв'язку між програмами. Справа в тому, що в RPC застосовується синхронний механізм взаємодії: додаток, що запитує, видає запит і чекає відповіді. На час очікування програма виявляється заблокованою. У зв'язку з цим розгортати засновані на RPC додатки є доцільним у локальних мережах, де час відповіді зазвичай дуже великий. Крім того, RPC є механізмом взаємодії, орієнтованим на з'єднання. Це означає, що якщо запитувана програма недоступна або неактивна в даний момент, RPC функціонуватиме некоректно. У зв'язку з цим RPC неможе бути застосована у глобальних мережах, оскільки ймовірність недоступності програми у разі досить велика. У принципі, обмеження, пов'язані як із синхронністю взаємодії, так і з недоступністю запитуваної програми, можуть бути обійдені за допомогою, наприклад, так званого асинхронного RPC, але це не вирішує проблеми повністю.
MOM. Наступним кроком у розробці ППО для взаємодії між активними програмами стали системи передачі повідомлень. Принцип їх побудови досить простий, проте вони надають величезні можливості зв'язування програм.
В основі систем передачі повідомлень лежить технологія черг повідомлень: програми обмінюються інформацією не безпосередньо один з одним, а використовуючи спеціальні буфери (черги). У разі необхідності обміну даними програма пересилає їх у чергу, що належить їй, і продовжує функціонування. Доставку повідомлення за призначенням та його зберігання забезпечує спеціальне ПЗ - МОМ. При цьому MOM, як правило, може працювати на різних програмно-апаратних платформах та з використанням різних мережевих протоколів. Багатоплатформність досягається за рахунок мінімізації функцій, що виконуються клієнтською частиною, а підтримка різних протоколів – за рахунок використання внутрішнього протоколу обміну інформацією. Розробнику ж надається нескладний та високорівневий API для роботи з чергами повідомлень.
Незважаючи на те, що основний режим взаємодії при використанні MOM - асинхронний, можливий обмін повідомленнями і в синхронному режимі. Повідомлення можуть передаватися всім приєднаним додаткам (broadcasting), додаткам, що включені до заздалегідь визначеного списку, або в якусь точку призначення.
Використання MOM дозволяє змішувати різні режими зв'язкуу межах однієї транзакції. Ця властивість досить важлива при проектуванні великих систем зі складною бізнес-логікою. Наявність черг повідомлень гарантує доставку інформації: у разі збоїв або відмов у мережі, а також при відмові серверів буде забезпечено або збереження повідомлення до відновлення з'єднання, або його повторна передача, або буде здійснено пошук нового шляху в обхід ділянки, що відмовила.
ППО черг повідомлень дозволяє призначати їм пріоритети, забезпечуючи першочергову доставку тих, що мають найвищий пріоритет. Таким чином, вдається реалізувати кілька “віртуальних” систем передачі повідомлень, де мережа з меншим пріоритетом не впливає на доставку повідомлень у більш високопріоритетній мережі.
MOM, аналогічно моніторам транзакцій, здатне оптимізувати процес взаємодії додатків. Однак, якщо монітори транзакцій керують доступом до бази даних, MOM оптимізує шляхи доставки повідомлень, виходячи з певного критерію. Наприклад, повідомлення може передаватися шляхом з найменшою “вартістю” доставки - у своїй “вартість” ділянок шляху може визначатися як і статичному, і у динамічному режимі.
Системи, побудовані на базі MOM, схожі на системи електронної пошти, але відрізняються від останніх тим, що забезпечують взаємодію між програмами, а не між людьми. Відповідно MOM призначена передачі структурованої інформації переважно технологічного типу (тобто. породжуваної без участі користувача), тоді як системи електронної пошти здійснюють у більшості випадків передачу неструктурованої інформації.
В даний час основна частка ринку MOM належить двом компаніям – IBM з її продуктом IBM MQSeries та Microsoft з MSMQ. IBM MQSeriesвідрізняється багатоплатформністю, підтримкою різних мережевих протоколів та відкритістю інтерфейсів, що дозволяють легко нарощувати функціональність системи. Головна перевага MSMQ – його тісна інтеграція з OC Windows, а також підтримка COM.
ORB. Технологія брокерів запитів до об'єктів є поряд з MOM типом ППО, що найбільш бурхливо розвивається. ORB управляють обміном повідомленнями у мережі. Подібно до “людського” брокера, ORB виконує функції інтелектуального посередника, тобто приймає запити від клієнта (клієнтського додатка), здійснює пошук та активізацію віддалених об'єктів, які можуть відповісти на запит, і передає відповідь об'єктам запитуючого додатка. ORB, як і RPC та MOM, приховує від користувача процес доступу до віддалених об'єктів. Запитуючий об'єкт повинен знати ім'я об'єкта, що активізується, і передати йому деякі параметри (як правило, це інформація про інтерфейс викликаного об'єкта - свого роду API для ORB). Інтерес до ORB підігрівається тим, що цей middleware підтримує об'єктну модель, що стала де-факто стандартом при розробці великих інформаційних систем. В даний час на ринку конкурують стандарт CORBA та технологія COM корпорації Microsoft.
Області застосування middleware
Найчастіше у розмові про проміжне ПЗ виникає питання, яке ППО має бути застосоване в тих чи інших випадках. Сама постановка цього питання показує, що сумнівів у тому, чи застосовувати ППО чи ні, залишається все менше і менше - слово “middleware” міцно увійшло до лексикону розробників інформаційних систем. Засоби middleware є незамінними, коли треба спростити процес створення розподіленої системи, перенісши основний упор на розробку бізнес-логіки, а не на взаємодію різних додатків та ресурсів.
АлеПовернемося до питання про застосування конкретних типів middleware. Тут можна надати такі рекомендації. Під час роботи з базами даних одного типу слід застосовувати ППО баз даних. Якщо необхідно здійснювати роботу з різними типами БД або оптимізувати процес доступу, доцільно застосування моніторів транзакцій. При взаємодії додатків для забезпечення синхронного з'єднання можна використовувати засоби RPC, а для організації спільної роботи слабозв'язаних додатків, з'єднання між якими не завжди надійне, - засоби MOM. Взагалі, MOM та ORB є найбільш універсальними засобами middleware і можуть застосовуватися в більшості випадків для організації зв'язку між додатками.
На закінчення слід зазначити, що були перераховані далеко не всі області застосування middleware. Основним принципом під час виборів тієї чи іншої типу проміжного ПЗ має бути його відповідність тим умовам, у яких здійснюється взаємодія, а чи не модність чи сучасність тієї чи іншої продукту. Крім того, у ряді випадків доцільно комбінування різних типів ППО для досягнення необхідної функціональності, тим більше, що багато з тих, що були розглянуті, надають зручні інтерфейси для взаємодії один з одним.