Технологія corba. Вступ 2007 Зміст


НазваТехнологія corba. Вступ 2007 Зміст
Дата конвертації09.04.2013
Розмір445 b.
ТипПрезентации


Технологія CORBA. Вступ

  • 2007


Зміст

  • Стратегічна мета CORBA.

  • CORBA як технологія. Два аспекти: архітектура та стандарти (специфікації).

  • Архітектура OMA. Концепції. Категорії об'єктів OMA.

  • Стандарти (специфікації) CORBA.

  • Брокер об'єктних запитів.

  • Підґрунтя CORBA. Використання CORBA.

  • Об'єктні типи, IDL-транслятори, proxy-об'єкти.

  • Взаємодії клієнт-сервер у CORBA. “Статична” CORBA.

  • Використання Smart Agent (VisiBroker). (Нестандартна служба Location Service).



Назва та призначення

  • CORBA – це абревіатура від Common Object Request Broker Architecture (загальна архітектура брокера об'єктних запитів).

  • Стратегічним напрямком технології CORBA є розподілені програмні системи.

  • Загалом, на CORBA, як і на COM, покладаються задачі "склеювання", тобто функції проміжного рівня, "середньої" ланки – middleware. При тому на відміну від COM, технологія CORBA із самого початку свого існування орієнтувалась саме на розподілені системи, більш того – на розподілені системи у неоднорідному (гетерогенному) мережному середовищі.

  • Перша специфікація CORBA з'явилася у 1991 р.



Компоненти CORBA

  • Отже, стратегічною задачею CORBA є корпоративні системи у неоднорідному (гетерогенному) мережному середовищі, яке може, зокрема, містити різноманітні складові, починаючи від мейнфреймів та Unix-комп'ютерів і закінчуючи персональними комп'ютерами.

  • Відзначимо наступні вимоги до компонентної архітектури CORBA:

    • незалежність від платформи – компоненти можуть виконуватись на різних апаратних платформах, у різних операційних середовищах (зауважимо, інтеграція на рівні двійкових кодів, притаманна COM, можлива тільки на одній операційно-апаратній платформі);
    • незалежність від фізичного розташування – компоненти можуть міститися у різних процесах однієї машини чи на різних машинах;
    • незалежність від інструментальних засобів – компоненти можуть розроблятись з використанням різних мов та інструментальних середовищ.


OMG

  • Розвитком CORBA опікується консорціум OMG (Object Management Group), заснований у 1989 році одинадцятьма компаніями. Серед компаній, що заснували OMG, були в основному виробники комп'ютерних систем різного рівня й інтегратори зі світовим ім'ям.

  • Зараз у консорціум входять більш ніж 1000 компаній. Серед них такі, наприклад, як IBM, DEC, Hewlett-Packard, Canon, Sun Microsystems, 3M, Fujitsu, Oracle, Bank of America, Chevron, Ford, Boeing, Hitachi, Xerox, VISA, AT&T, NT&T тощо.

  • OMG пропагує і просуває CORBA під девізом "Middleware that's Everywhere" ("Середня ланка – всюди").



CORBA як технологія. Два аспекти

  • З поняттям "технологія" у випадку CORBA пов'язують два аспекти:

      • архітектура розподілених програмних систем (на основі зв'язків між об'єктами з різних компонент);
      • стандарти (специфікації), які забезпечують підтримку такої архітектури (з урахуванням усіх зазначених вище вимог).
  • Архітектура технології CORBA відома під назвою OMA – Object Management Arсhіtecture (Архітектура Управління Об'єктами). Вона була опублікована в 1992 р. і з того часу практично не зазнала змін.

  • Стандарти (специфікації), навпаки, інтенсивно розвиваються й доповнюються.



Архітектура OMA. Концепції

  • Програмні продукти можуть призначатись для вирішення зовсім різних задач з різних предметних областей, разом з тим програмні продукти ґрунтуються на використанні багатьох однакових функціональних рішень:

    • об'єкти створюються і ліквідуються;
    • об'єкти можуть змінювати місце розташування (мігрувати);
    • одні об'єкти можуть зв'язуватися з іншими, сповіщати про події, що відбуваються.


Архітектура OMA. Концепції (прод.)

  • При більш детальному розгляді процесів використання об'єктів в окремих галузях виявляється, що в них використовується ще більше однакових функціональних рішень.

  • Виходячи з цього, OMG був запропонований підхід, що базується на виділенні й абстрагуванні таких загальних функціональних рішень і подальшому їх описі (з використанням стандарту-специфікації – мови IDL) як

  • специфікованих стандартних інтерфейсів або об'єктів.

  • (Зауважимо, що у технології CORBA об'єктні типи по суті визначаються за типами інтерфейсів).



Категорії об'єктів OMA Архітектури Управління Об'єктами

  • Об'єкти, в цілому, знаходяться в центрі уваги OMA і технології CORBA у відповідності до гасла, висунутого OMG:

  • "Об'єктна технологія здатна об'єднати світ".

  • В OMA визначаються чотири категорії об'єктів:

    • служби CORBA (CORBAservices);
    • засоби CORBA (CORBAfacilities);
    • об'єкти прикладних галузей
    • (об'єкти CORBAdomain);
    • прикладні об'єкти.
  • Для об'єктів другої та третьої

  • категорій іноді використовують

  • узагальнюючу назву засоби

  • CORBA (CORBAfacilities), класифікуючи їх відповідно як горизонтальні та вертикальні засоби CORBA (CORBAfacilities).



CORBA. Архітектура OMA

  • OMA – Object Management Arсhіtecture (Архітектура Управління Об'єктами).

  • C O R B A – Common Object Request Broker Architecture (загальна архітектура брокера об'єктних запитів)



Служби CORBA (CORBAservices)

  • Згідно термінології OMG служби CORBA є механізмом, який є обов'язковою основою конструювання розподілених систем.

  • Більшість таких служб надають базову функціональність – виконання різних системних функцій на зразок тих, що використовуються, наприклад, в системних бібліотеках операційних систем.

  • Визначено 15 загальних служб CORBA (різного рівня важливості): іменування (naming); подій (events); життєвого циклу (life cycle); довгострокового збереження об'єктів (persistent); транзакцій (transactions); контролю за доступом до поділюваних ресурсів (concurrency control); відносин (relationsips); імпорту/експорту (externalization); запитів (query); ліцензування (licensing); властивостей (property); часу (time); захисту (security); трейдінгу (object trader); колекцій об'єктів (object collections).



Служби CORBA (CORBAservices) (прод.)

  • Виходячи із загальних принципів CORBA, інтерфейси її об'єктних служб (CORBAservices) специфіковані з використанням IDL.

  • Найпоширенішими серед об'єктних служб CORBA є служба іменування, служба управління життєвим циклом, служба управління подіями, які були першими з прийнятих OMG.

  • Над базовим набором сервісів (служб) можна надбудовувати прикладні сервіси.



Засоби CORBA (CORBAfacility, горизонтальні CORBAfacility)

  • Засоби CORBA (CORBAfacilities) на відміну від служб CORBA не є обов'язковими при конструюванні розподілених систем, але є потенційно корисними для різних прикладних областей.

  • Є чотири категорії горизонтальних CORBAfacility, виділених спеціальною комісією OMG :

      • засіб організації друку незалежно від операційної системи – Printing Facility;
      • засіб безпечного одержання часу – Secure Time Facility;
      • засіб для роботи з мобільними агентами – Mobile Agent Facility;
      • засіб інтернаціоналізації (перекладу повідомлень і т.п.) – Internationalization Facility.
  • CORBAfacility – категорія об'єктів (інтерфейсів) в OMA, для якої однак в OMG не створено жодної окремої робочої групи.



Галузеві об'єкти CORBA (об'єкти CORBAdomain) – вертикальні засоби CORBA

  • Об'єкти прикладних галузей, чи, інакше, галузеві об'єкти CORBA (об'єкти CORBAdomain) – це стандартні стосовно до тієї чи іншої галузі об'єкти. Запити на створення і підтримку таких об'єктів надходили від настільки великої кількості компаній з різних галузей, що для координації цих робіт у 1996 році було створено Галузевий Технологічний Комітет.

  • Для багатьох галузей (фінанси, електронна комерція, транспорт, охорона здоров'я, телекомунікації, страхування тощо) створені свої власні робочі групи в складі OMG.

  • На сьогодні кілька специфікацій вже затверджено, зокрема затверджено інтерфейс Currency, підготовлений робочою групою з фінансів, інтерфейс Air Traffic Control Display Manager – робочою групою з транспорту.



Прикладні об'єкти

  • Четверту категорію об'єктів архітектури OMA складають прикладні об'єкти.

  • Прикладні об'єкти – це такі об'єкти, що розробляються стосовно до цілком конкретних програмних додатків.



Стандарти (специфікації) CORBA

  • Основу діяльності OMG складає розробка загальних стандартів (специфікацій), пов'язаних з архітектурою OMA.

  • Специфікуються IDL, ORB, служби CORBA (вже на основі IDL), протоколи тощо.

  • Розробка конкретних реалізацій, пов'язаних з OMA, не є задачею OMG. (Важливий наслідок цього принципу – відсутність лобіювання інтересів фірм!). Проблеми розробки залишаються фірмам-розробникам ПЗ.

  • Що дають стандарти?

  • По-перше, на основі таких стандартів різні компанії мають можливість цілеспрямовано створювати власні реалізації закладених у специфікаціях концепцій та виходити на ринок.

  • По-друге, слідування стандартам забезпечує можливість спільного використання різних реалізацій, зокрема у неоднорідних (гетерогенних) середовищах.



До використання CORBA

  • Підтримка різних мов програмування. Існують стандарти відображень у мови C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, IDLscript, реалізації, орієнтовані на Pascal (Delphі), Visual Basic, Perl та інші мови програмування.

  • Підтримка різних платформ. Існують продукти CORBA на платформах мейнфреймів, основних платформах UNIX, OS/2, Windows, Vax. Багато розробок здійснено на основі Java, які, зрозуміло, можуть бути завжди використані при наявності для відповідної платформи JVM.

  • Підтримка інтернет. ORB на основі Java (наприклад, від Borland Inprise чи Iona можуть завантажуватись інтернет-браузерами разом з аплетами Java та надалі використовуватись для коммунікації із серверними CORBA-об'єктами.

  • Підтримка різних фірм-розробників ПЗ: IBM (а отже “контроль” мейнфреймів), Sun MicroSystems (а отже “контроль” Java), Borland Inprise, Iona Technologies, BEA Systems, Olivetti, Oracle Reseach Lab.

  • Наявність продуктів, що вільно розповсюджуються: OmniORB (Olivetti, Oracle Reseach Lab), JacORB, MICO тощо (див. www.omg.org/corba/freestuff.html).



CORBA. Реалізації

  • Специфікації CORBA не обтяжені деталями реалізацій. Реалізації залишаються на долю компаній-розробників програмного забезпечення.

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

  • Inprise Corporation (VisiBroker, CosNaming, CosTransaction, CosEvents);

  • Iona Technologies (Orbix ORB, OrbixTrader, OrbixSecurity, OrbixEvent);

  • Olivetti, Oracle Reseach Lab (OmniORB);

  • JacORB (вільно розповсюджується, Java ORB, CosNaming, CosEvents, CosTrading)

  • PrismTech(пакет OpenFusion: CosNaming, CosEvent, CosTrading, ... - 9 служб)

  • Jorba (умовно безкоштовна версія ORB);

  • Object Oriented Concepts, Inc (ORB, CosNaming, CosTrading);

  • PeerLogic (ORB, CosNaming, CosTrading, CosTransaction, CosEvents);

  • Expersoft (ORB, CosNaming, CosTrading, CosEvents);

  • JavaSoft Organization Sun MicroSystems (Java IDL: ORB, CosNaming);

  • MICO (безкоштовна версія ORB, CosNaming);

  • BEA Systems (ORB M3);

  • Hewlett-Packard (ORB+ ).

  • Використовують: BEA, Oracle, Netscape (Communicator оснащено ORB Visigenic)



Брокер об'єктних запитів ORB (Object Request Broker)



Брокер об'єктних запитів ORB (Object Request Broker)

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

  • При цьому задачею ORB є якнайретельніше маскувати наявність розподіленості та неоднорідності програмної системи. (Прозорість!)



Брокер об'єктних запитів. Реалізації

  • CORBA тільки описує стандарт (специфікацію) на брокер, його реалізацією займаються різні програмні фірми. Серед найбільш відомих брокерів – VisiBroker (Inprise), Orbix (Iona), ORB Plus (HP), SOM (IBM), ObjectBroker (DEC), NEO/Joe (SUN), M3 (BEA), PowerBroker (Expersoft).

  • Нагадаємо, що на ORB покладається роль посередника при взаємодії окремих компонент (об'єктів) розподіленої системи:



Підґрунтя CORBA

  • В основу CORBA закладено наступні програмістські концепції, технології та підходи:

    • технологія об'єктно-орієнтованого програмування (ООП). Об'єктний підхід, як відомо, забезпечує: можливість інкапсуляції, більш високу ефективність розробки ПЗ, надійність та спрощення обслуговування ПЗ, широкі можливості масштабування та повторного використання. У технології CORBA об'єктний підхід є одним з найпринциповіших,
    • рішеннями CORBA фактично є розподілені об'єктні системи, а про саму технологію CORBA говорять як про об'єктну технологію.
    • (Проте середовище реалізації може бути навіть без підтримки ООП!);
    • концепція мережного середовища. Саме мережі роблять можливим використання географічно розподілених програмних систем;


Підґрунтя CORBA (прод.)

    • клієнт-серверні технології. Вони визначають взаємодію між розподіленими в мережі об'єктами. При цьому роль клієнта чи сервера не є постійно закріпленою за об'єктом. Відповідна роль встановлюються тільки на один запит, і, зокрема, не виключено, що в об'єкта вона може помінятись на протилежну при реалізації якогось іншого запиту;
    • концепція інтерфейсів. Можливі запити (або, іншими словами, можливості використання об'єктів у ролі серверів) задаються на основі визначення інтерфейсів. (Ще раз зауважимо, що у технології CORBA об'єктні типи по суті визначаються за типами інтерфейсів).


Використання CORBA

  • Наявність стандартних інтерфейсів (об'єктів) та реалізації відповідних функцій (розробниками програмного забезпечення) дозволяють досягти більш ефективної розробки і супроводу програмних додатків:

    • процес створення додатків стає більш швидким, оскільки розробнику не потрібно реалізовувати значну кількість стандартних функцій;
    • системи, побудовані навколо стандартних служб, мають, як правило, якіснішу архітектуру.
    • Якісна архітектура, як мінімум, вимагає поділ усієї системи на окремі модулі (з об'єктів) за функціональним принципом – об'єктні функціональні модулі. При розробці згідно стратегії OMA, що сама базується на функціональному принципі, програмні системи ще на самому початку розробки мають функціональне підгрунтя;


Використання CORBA (прод.)

    • системні реалізації на основі OMA є більш надійними, вони краще масштабуються розробники програмного забезпечення при реалізації OMA-продуктів враховують потреби масштабування і роблять відповідні кроки для вирішення типових проблем і задач, що виникають при створенні корпоративних систем. (Використання стандартних служб – вагома підстава масштабованості).


Об'єктні типи, IDL-транслятори, proxy-об'єкти

  • Об'єктні типи CORBA по суті визначаються за типами інтерфейсів: для кожного об'єктного типу має описуватись лише інтерфейс (для відповідного опису використовується стандарт IDL).

  • На сьогодні наявні реалізації відображень (транслятори) IDL-описів інтерфейсів у більшість популярних мов програмування, причому не обов'язково об'єктних. Розроблено та затверджено стандарти відображень IDL у мови C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, IDLscript.

  • Існують також відображення у Pascal (Delphі), Visual Basic, Perl і ще на кілька мов, але вони (відображення) не є стандартизованими.

  • У CORBA використовується поняття повноважного представника (proxy). На боці клієнта повноважним представником серверного об'єкта виступає заглушка, стаб (stub), а на боці сервера – каркас, скелетон (skeleton).



Спрощена схема взаємодії клієнт-сервер у CORBA (“Статична” CORBA)



Взаємодія клієнта з об'єктом серверної програми



Статичний варіант взаємодії клієнт-сервер у CORBA. Заглушки та скелетони

  • Програмні коди як клієнтської заглушки, так і серверного скелетону генеруються з одного і того ж самого опису IDL-опису інтерфейса згаданими вище трансляторами.

  • З цього, по-перше, випливає, що у клієнтській програмі по суті відомо, якими методами серверного CORBA-об'єкта можна скористатися, відомі параметри методів, а отже можна контролювати правильність викликів функцій та забезпечувати маршалінг даних.

  • По-друге, при роботі з клієнтом у користувача створюється враження, начеб-то він оперує безпосередньо з екземпляром серверного об'єкта в межах локального процесу, однак насправді відбуваються звернення до методів заглушки.

  • Заглушка забезпечує передачу запитів на виконання (з використанням посередницьких послуг ORB) через код скелетона серверного об'єкта і, врешті решт, призводить до викликів інтерфейсних методів, реалізованих у сервері – у вигляді так званого серванта (servant).



Статичний варіант взаємодії клієнт-сервер у CORBA. Заглушки та скелетони

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

  • Більш того, те ж саме можна сказати і про віддалені виклики, тільки у цьому випадку для передачі запиту та його результату залучається ще один стандарт – стандартний протокол GIOP.



Використання Smart Agent (VisiBroker). (Нестандартна служба Location Service)



Приклад (BCB, Delphi)



Баланс навантаження. Приклад



Баланс навантаження. Приклад (різні сервери з підтримкою одного інтерфейсу)



Приклад з консольними проектами (сервер та один клієнт є консольними проектами)



Додаток



Консольні програмні додатки

  • Консольні програмні додатки є єдиним варіантом програмних додатків, який є впровадженим на будь-якій платформі на відміну, наприклад, від програм з графічним інтерфейсом користувача, котрі вимагають наявності відповідних графічних бібліотек або ОС, що підтримують GUI. (До того ж варто зазначити, що загалом ні на графічні бібліотеки, ні на операційні системи з GUI поки що не існує стандартів).

  • Отже, саме консольні програмні додатки є дійсно універсальним портабельним типом програм, тобто типом програм, що допускають перенесення на інші платформи.



Документація CORBA

  • Основними документами з технології CORBA є два:

      • "The Common Object Request Broker: Architecture and Specification";
      • "CORBAservices: Common Object Services Specification".
  • У назві першого з них додатково вказується номер версії: Revision 2.0 (1995), Revision 2.2 (1998) і т.д. Тим самим визначаються версії CORBA: CORBA 2.0, CORBA 2.2 тощо.

  • Крім вищезгаданих існує величезна кількість різного ступеня важливості документів CORBA. Однак далеко не все з описаного навіть у двох найважливіших реалізується розробниками.



"The Common Object Request Broker: Architecture and Specification"

  • У цьому документі описуються основи CORBA, а також багато складових частин фундаменту CORBA, у тому числі:

      • мова опису інтерфейсів (Interface Definition LanguageOMG IDL);
      • мережні протоколи GIOP і IIOP;
      • інтерфейс динамічних викликів (Dynamic Invocation Interface – DII), який надає DII-клієнтам можливість використовувати динамічні запити до об'єктів, тобто такі запити, що генеруються на стадії виконання програм, а не на стадії компіляції;


"The Common Object Request Broker: Architecture and Specification(прод.)

      • інтерфейс динамічних скелетонів (Dynamic Skeleton Interface – DSI), який дозволяє використовувати динамічний режим подібно DII, але тепер уже на стороні сервера. Якщо DII-клієнти обходяться без "стабів", орієнтованих на використання статичних запитів, то у випадку DSI сервери обходяться без "скелетонів";
      • портабельний (переносний) об'єктний адаптер (Portable Object Adaptor – POA). Відповідна специфікація ставить своєю метою створення систем, що можуть легко переноситися між різними ORB (від різних виробників);
      • специфікації трансляторів із вхідною мовою IDL та деякими вихідними мовами (C, C++, Smalltalk, Cobol, Java).


Служби CORBA (деталізація)

  • 1. Naming Service - базова служба імен. Підтримується ієрархічного виду каталог доступних у мережі сервісів. (Деякі постачальники CORBA використовують для реалізації даної служби каталог DCE - Distributed Computing Environment. Узагалі стандарт не забороняє використовувати для реалізації Naming Service будь-яку існуючу службу каталогів.

  • 2. Event Service описує можливості асинхронної взаємодії.

  • 3. Persistent Object Service - описує те, яким чином стан об'єкта може бути збережено, а потім відновлено.

  • 4. Life Cycle Service. Враховує моменти, породжені тим, що об'єкт протягом свого життєвого циклу може мігрувати між комп'ютерами.

  • 5. Concurrency Control Service. Специфікує регулювання доступу до об'єктів у конкурентному режимі. Механізм - різні типи блокувань.



Служби CORBA (деталізація) (прод.)

  • 6. Externalization Service описує спосіб представлення стану об'єкта у вигляді потоку даних. Використовується при збереженні у файлах чи переміщеннях між областями пам'яті.

  • 7. Relationship Service. Можливість безпосереднього представлення відношень між об'єктами подібно до класичної ER моделі Чена.

  • 8. Transaction Service. Дуже важливий сервіс. Його наявність і відсутність у реалізації CORBA і є гранню між ОО монітором транзакцій і просто об'єктним брокером запитів. Object Transaction Service відповідає за демаркацію транзакцій, координацію безлічі об'єктів, що можуть бути задіяні в транзакції, у тому числі й об'єктів, розподілених по вузлах мережі.

  • 9. Query Service. Яка мова запитів повинна використовуватися, явно не зазначено, хоча говориться про об'єктні розширення SQL.

  • 10. Licensing Service - управління ліцензуванням.



Служби CORBA (деталізація) (прод.)

  • 11. Property Service - можливість асоціювання з об'єктами властивостей, що не є атрибутами об'єкта.

  • 12. Time Service - служба часу.

  • 13. Security Service - важливий вид сервісу, безпека.

  • 14. Trading Object Service - дуже цікаве розширення служби імен. Замість того, щоб використовувати точне ім'я сервісу по Naming Service, клієнт указує необхідний йому тип об'єкта, а trader сам знаходить придатний.

  • 15. Object Collection. Регламентує базові операції над колекціями об'єктів.



General Inter-ORB Protocol

  • General Inter-ORB Protocol (GIOP) – загальний (універсальний) між-ORB (міжброкерний) протокол. Забезпечує інтероперабельність брокерів ORB.

  • Ця специфікація визначає загальні принципи передачі інформації (у випадку віддалених викликів) між двома ORB: ORB на стороні клієнта та ORB на стороні сервера. (Для забезпечення інтероперабельності формат повідомлень до останнього біта має бути стандартизованим).

  • Загалом описуються (з використанням IDL) вісім варіантів повідомлень:

  • enum MsgType_1_1 {

  • Request, Reply, CancelRequest, . . . }



General Inter-ORB Protocol. Структура заголовка повідомлень

  • Кожне повідомлення починається із заголовка, який має наступну структуру:

  • struct MessageHeader_1_1 {

  • char magic[4];

  • version GIOP_version;

  • octet flags; // спосіб представлення чисел

  • octet message_type;

  • unsigned long message_size;

  • };

  • Так само уточнюються інші частини для кожного із варіантів повідомлень.



Internet Inter-ORB Protocol

  • Інтернет між-ORB (міжброкерний) протокол (Internet Inter-ORB Protocol – IIOP). Цей протокол є спеціалізацією GIOP для мереж TCP/IP, коли як транспортний протокол використовується TCP (Transmission Control Protocol – протокол управління передачею).

  • Специфікація IIOP визначає так звані профілі інтероперабельних об’єктних посилань, де зокрема міститься адресна інформація TCP (хост, порт):

  • struct ProfileBody_1_1 {

  • version iiop_version;

  • string host;

  • unsigned short port;

  • sequence object_key; //об’єктне посилання

  • . . .

  • }



Схожі:

Технологія corba. Вступ 2007 Зміст iconТехнологія corba. Вступ 2007 Зміст

Технологія corba. Вступ 2007 Зміст iconТехнологія corba. Вступ 2005 Зміст

Технологія corba. Вступ 2007 Зміст iconТехнологія corba. Вступ 2006 Зміст

Технологія corba. Вступ 2007 Зміст iconТехнологія corba. Вступ 2003-2008 Зміст

Технологія corba. Вступ 2007 Зміст iconCorba-об'єкти та їх особливості 2007 Зміст

Технологія corba. Вступ 2007 Зміст iconJava rmi & corba 2007 Зміст

Технологія corba. Вступ 2007 Зміст iconCorba-об'єкти та їх особливості 2003-2007 Зміст

Технологія corba. Вступ 2007 Зміст iconJava rmi & corba 2007-2009 Зміст

Технологія corba. Вступ 2007 Зміст iconCorba orb. Об'єктні адаптери 2007 Зміст

Технологія corba. Вступ 2007 Зміст iconCorba orb. Об'єктні адаптери 2003-2007 Зміст


Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка