Тестовий центр PC Week Labs вважає CORBA найсучаснішою технологією, але за DCOM варто сила Microsoft
Повідомляю гарну новину. Інтеграторам платформ, розробникам додатків і менеджерам робочих груп (вже найближчим часом) не доведеться вибирати між зручністю DCOM (модель розподілених складових об'єктів) і міццю підтримуваного багатьма виробниками стандарту CORBA (загальна архітектура посередника запитів до об'єктів), оскільки незабаром з'являться можливості їх спільної роботи , що дозволить додаткам використовувати переваги обох підходів.
Але є і погані новини. Так, обидві технології вимагають від розробника глибокого їх розуміння. Крім того, щоб зберегти звичний для традиційних додатків рівень продуктивності і багатство інтерактивних можливостей і одночасно надати розробникам гнучкість компонентного ПЗ і "запас міцності", необхідний для розподіленої середовища додатків, компаніям доведеться використовувати як CORBA, так і DCOM.
DCOM іноді називають "COM з подовженим проводом". Вона дозволяє програмам в настільних системах працювати з віддаленими компонентами через різноманітні види мережевих з'єднань, спираючись на звичні інтерфейси прикладного програмування COM API, які розробники вже застосовують в компонентних додатках для Windows.
COM API виростають з технології OLE корпорації Microsoft, і їх генеалогію можна простежити від кінця до самого початку - виходу ще дуже сирий технології Dynamic Data Exchange (динамічний обмін даними), вперше надала розробникам щось схоже на відкритий стандарт програмованого взаємодії додатків під управлінням Windows.
Звичність COM, проте, має і тіньові сторони. Дійсно, прості завдання в локальному середовищі легко вирішуються за допомогою COM, і перехід до мережевого розподіленого взаємодії на базі DCOM теж не важкий, але це зовсім не означає, що використання DCOM завжди краще застосування більш складної технології CORBA. Піднятися на дерево, звичайно, простіше, ніж побудувати і запустити ракету, але шукати дерево вище для подорожі на Місяць навряд чи розумно.
Слабкість моделі DCOM полягає в тому, що для додатків, побудованих на її базі, мережа виглядає, як локальна середу. В деякій мірі структура DCOM аналогічна структурі ПК, яка передбачає наявність одного користувача - центру управління системою - і локального пулу пам'яті - єдиного централізованого ресурсу, що підлягає поділу. Ці припущення перестають працювати або ж вимагають підтримки додаткових шарів ПО, як тільки DCOM вторгається в область більш далеких з'єднань небездоганною надійності, і безлічі конкуруючих в боротьбі за ресурси додатків.
DCOM створює і знищує об'єкти динамічно; кожен об'єкт є набором покажчиків на інтерфейси, що надаються їм іншим об'єктам. Якщо від об'єкта нічого не залежить, він зникає. Але до тих пір, поки це не так, він повинен залишатися активним.
В CORBA застосований інший підхід. У ньому об'єкти пов'язані з деякими сутностями, життя яких триває навіть тоді, коли об'єкта немає в пам'яті. Центральна завдання ORB (посередник запитів до об'єктів) - надати об'єктам доступ до послуг один одного, приховуючи при цьому всі аспекти їх розташування і стану. Якщо деякий CORBA-об'єкт звертається до послуг іншого, то справа ORB визначити, де цей інший об'єкт розташований, і активізувати його в разі потреби, причому непомітно для запитувача об'єкта.
Життєво важливо усвідомити практичні труднощі, що виникають з підходу, реалізованого в DCOM. Якщо у DCOM-сервера є активні клієнти, він повинен залишатися в пам'яті навіть в ті періоди часу, коли цим клієнтам уваги не потрібно. В CORBA сервер може видалити сам себе з пам'яті, щоб звільнити ресурси іншим завданням, оскільки через ORB будь-які об'єкти-клієнти можуть звернутися до цього сервера, як тільки їм це знадобиться.
Якщо мережу з DCOM-клієнтом пропадає, то сервер може зробити висновок, що клієнт більше не існує, і "самознищитися". При відновленні з'єднання об'єкту-клієнтові доведеться виявляти і вирішувати цю проблему самостійно. Такі "осиротілі" об'єкти повинні бути забезпечені логікою обробки помилок, яку краще було б реалізувати і оттестировать одного разу, в рамках ORB, ніж раз по раз винаходити заново.
На деякі з архітектурних вад DCOM, можливо, буде звернено увагу при створенні COM третього покоління. Очікується, що в COM 3 увійде середу періоду виконання, що підвищує надійність роботи системи за допомогою Java-подібних засобів обробки помилок.
Роль Microsoft на ринку настільки велика, що є потужний фінансовий стимул знайти рішення, хоч би неелегантно воно не було, і зробити-таки цукерку з того, що є зараз. Якщо цього не зробить Microsoft, прогалини будуть заповнені іншими компаніями.
Щодо DCOM, як і про будь-якої іншої програмної технології, майже неможливо впевнено сказати, що вона не зможе забезпечити якусь певну можливість. Завжди можна додати додаткові шари ПО (хоча зазвичай за рахунок втрати частки продуктивності, простоти і надійності). Як би там не було, DCOM має принаймні однією перевагою - ця модель контролюється єдиною компанією з багатою історією доведення продуктів до розуму в їх третіх версіях.
Удари у CORBA
Аргументація на користь CORBA заснована на тому неявному припущенні, що різні ORB можуть взаємодіяти, реалізуючи свої переваги в рамках гетерогенних мереж. Однак досвід минулих років показує, що сподіватися на це навряд чи варто. DCOM - це продукт, а CORBA - всього лише специфікація, і відмінностей між конкуруючими реалізаціями CORBA було досить для того, щоб спорудити серйозні бар'єри на шляху її практичного застосування.
Останнім часом сумісність версій ORB істотно покращилася. Це пов'язано з появою явних лідерів на ринку, наприклад фірми Visigenic Software. Ліцензії на її ORB купили Netscape Communications, Oracle і Novell, з основними виробниками (включаючи IBM, Netscape, Oracle і фірму Sun Microsystems) вона уклала також угоди про підтримку та взаємної сумісності ORB. Десятки мільйонів Web-клієнтів Netscape, які використовують Visigenic ORB, додадуть CORBA імпульс, цілком можна порівняти за потужністю з енергією "приливної хвилі", - тактикою, зазвичай застосовується Microsoft при просуванні своїх продуктів.
Перспективи розвитку многоплатформная компонентів тісно пов'язані з питанням створення многоплатформная ORB. DCOM від Microsoft представляє собою засіб обслуговування компонентів ActiveX, які зазвичай містять "рідний" код, специфічний для однієї платформи, наприклад Windows на X86-ПК. CORBA ж "подружилася" з технологією Java фірми Sun і моделлю компонентів JavaBeans. У ній з'явилася підтримка переносяться модулів в байт-коді, виконуваних на реалізованої для локальної платформи віртуальної машині Java.
Закінчивши період загравання зі специфічним для Java підходом, званим Remote Method Invocation (віддалений виклик методів), Sun і інші адепти Java тепер роблять вибір на користь CORBA як Java-рішення для мережевої взаємодії компонентів. Бібліотека Java-класів фірми Sun, JOE (Java Objects Everywhere - Java-об'єкти всюди) дозволяє Java-програмістам використовувати механізми CORBA з тим же самим зручністю (за рахунок інкапсуляції механізмів в класах), яке Java надає при роботі з іншими службами, наприклад Internet -з'єднаннями.
Компоненти JavaBeans, які взаємодіють один з одним в гетерогенних мережах на основі надійних стандартів CORBA і виконуються на будь-якому процесорі, що підтримує інтерпретатор віртуальної машини Java, надають промисловим розробникам просто приголомшливу гнучкість.
Ці перспективи набагато більш цікавим тих, які обіцяє зустрічну пропозицію Microsoft, засноване на многоплатформная підтримки DCOM. Microsoft всього лише обіцяє, що компоненти на різних платформах зможуть викликати один одного через однакові (але ненадійні) протоколи DCOM.
Проте ступінь присутності Microsoft на комп'ютерному ринку і широка підтримка DCOM в інструментах розробки, що випускаються сторонніми фірмами, гарантують, що на ІТ-професіоналів в промисловості буде надано сильний тиск, що схиляє їх до збереження вірності моделі DCOM при масштабуванні ними вгору додатків рівня підрозділів. У той же час прихильникам CORBA доведеться відповісти на виклик, довівши на ділі взаємну сумісність своїх продуктів. Їм також доведеться продемонструвати, що теоретична міць CORBA здатна втілитися в життя, і зробити це раніше, ніж Microsoft зміцнить DCOM настільки, що ця технологія зможе серйозно конкурувати з CORBA як великомасштабного рішення.
Пітер Коффі (PC Week Labs)
Версія для друку
Тільки зареєстровані користувачі можуть залишати коментарі.
<
