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


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


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

  • 2003-2008


Зміст

  • Стратегічна мета 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. Вступ 2003-2008 Зміст iconТехнологія corba. Вступ 2006 Зміст

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

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

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

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

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

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

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

Технологія corba. Вступ 2003-2008 Зміст iconОсобливості використання об'єктів у технології corba 2003 Об'єктні типи corba. Idl corba
Операція задається типом результата, списком параметрів та списком виключень. Параметри бувають трьох видів: in, out, inout
Технологія corba. Вступ 2003-2008 Зміст iconІ. Вступ І. Вступ ІІ. Використання інноваційних технологій навчання в практиці роботи вчителя
Технологія розвивального навчання Ігрові технології навчання Технологія розвитку критичного мислення Технологія інтерактивного навчання...

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


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