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


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


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

  • 2005


Зміст

  • Призначення CORBA.

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

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

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

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

  • Підґрунтя 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 є розробка та підтримка корпоративних систем у неоднорідному (гетерогенному) мережному середовищі, яке може, зокрема, містити різноманітні складові, починаючи від мейнфреймів та Unix-комп'ютерів і закінчуючи персональними комп'ютерами. Загалом, компонентна архітектура CORBA забезпечує підтримку наступних принципів:

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


Авторство

  • Автором 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 р. і з того часу зазнала незначних змін.

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



CORBA як специфікація

  • Загалом консорціум OMG було організовано з метою підтримки розробки компонентного програмного забезпечення. Домогтися цієї мети, спираючись на рішення від якогось одного виробника, практично неможливо – компанія-розробник неминуче б віддавала пріоритет своїй апаратній чи операційній платформі. Ось чому група OMG в основу своєї діяльності поклала

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

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

  • Перші специфікації, нагадаємо, CORBA з'явилися у 1991 р.

  • Отже, розробка реалізацій – не є задачею OMG, а є задачею для фірм, що розробляють ПЗ.



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

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

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



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

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

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


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

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

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

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

  • або, іншими словами, наборів об'єктів (у CORBA інтерфейсам відповідають CORBA-об'єкти).



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

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

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

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

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

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

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

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



Служби 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.

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

  • Знати 15 служб, описаних у документі OMG "CORBAservices”, корисно, тому що за абстрактною "підтримкою CORBA" тим чи іншим виробником можуть стояти іноді зовсім різні речі.



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

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

  • Є кілька горизонтальних CORBAfacility:

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



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

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

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

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



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

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

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



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)

  • За взаємодію (посередництво) між об'єктами (усіх чотирьох категорій об'єктів OMA) згідно з архітектурою OMA відповідає брокер об'єктних запитів ORB (Object Request Broker).

  • Брокер об'єктних запитів є “головною фігуроюOMA. Саме назва цієї складової частини відображена у загальній назві технології.

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

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



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

  • CORBA тільки описує стандарт (специфікацію) на брокер, його реалізацією займаються різні програмні фірми. Серед найбільш відомих брокерів – VisiBroker (Inprise), Orbix (Iona), M3 (BEA), ORB+ (HP).

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



Підґрунтя CORBA

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

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


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

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


Переваги від використання CORBA (архітектури OMA та служб і засобів CORBA)

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

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


Переваги від використання CORBA (архітектури OMA) (прод.)

    • системні реалізації на основі 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-опису інтерфейса згаданими вище трансляторами.

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

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

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



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

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

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



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

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

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



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



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



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



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



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



Додаток



Документація 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. Вступ 2005 Зміст iconТехнологія corba. Вступ 2007 Зміст

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

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

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

Технологія corba. Вступ 2005 Зміст iconСтворення та використання corba-об'єктів 2005 Зміст

Технологія corba. Вступ 2005 Зміст iconCorba об'єктні адаптери. Portable Object Adapter (poa) 2005 Зміст

Технологія corba. Вступ 2005 Зміст iconІ. Вступ І. Вступ ІІ. Використання інноваційних технологій навчання в практиці роботи вчителя
Технологія розвивального навчання Ігрові технології навчання Технологія розвитку критичного мислення Технологія інтерактивного навчання...
Технологія corba. Вступ 2005 Зміст iconЗміст книги: Вступ
Технологія формування основних компетентностей учнів на основі розвитку критичного мислення на уроках хімії
Технологія corba. Вступ 2005 Зміст iconCorba. Динамічні виклики 2006 Зміст
Як статичний, так І динамічний клієнти здатні взаємодіяти із серверним corba-об'єктом (шляхом викликів методів останнього), тільки...
Технологія corba. Вступ 2005 Зміст iconРозробка corba-проектів. Використання “майстрів” 2005 “Статична” corba. Заглушки та скелетони
Заглушки та скелетони Заглушки та скелетони є основою того, що називають "статична"

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


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