Com технології в centura team developer просто і доступно кожному програмісту - програмні

Зміст

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

СОМ технології Centura забезпечують три основні можливості:

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

Останні дві можливості СОМ розглянуті в іншій статті - ActiveX компоненти в Centura Team Developer: принципи і технологія застосування. Тому тут ми в першу чергу торкнемося питань побудови СОМ серверів і додатків взаємодіючих з ними.

СОМ технології та СОМ об'єкти

Модель програм орієнтована на компоненти Component Object Model (COM) - це специфікація (стандарт) розробки Microsoft для побудови складних програмних систем, заснованих на об'єктно-орієнтованої концепції. Компоненти представляються "чорним ящиком", є повно-достатніми з позицій: настройки, методів поведінки, властивостей-атрибутів, довідкової системи, обробки виняткових ситуацій і т.д. СОМ об'єкти або інтегруються в додатку клієнта, або забезпечують їх обробку на видаленні, причому клієнт може і не знати, що обробка виконується на інших обчислювальних ресурсах.

Такий підхід забезпечує розподілену обробку даних, можливість автономної розробки і налагодження значних частин програмного продукту і високий рівень взаємозамінності і модифікованості створюваного програмного забезпечення. Таким чином, до розробок, практично кожної програмної системи, залучаються значні інтелектуальні сили, що, в кінцевому рахунку, і забезпечує бурхливий розвиток інформаційних технологій. Зазначу принагідно, що COM компоненти, набувають властивостей програмного продукту і, безсумнівно, ми їх скоро побачимо на нашому ринку програмних продуктів в окремому виконанні, а не тільки в складі інших програмних виробів. В Інтернет їх вже зараз можна знайти у великій кількості.

З цілого ряду переваг, що надаються СОМ, можна виділити наступні основні переваги цих технологій:

  • Можливості побудови многозвенной архітектури програмних систем (N-Tier). Найпростішим елементом такої архітектури є двухзвенная: "клієнт-сервер". Розширюючи можливості клієнта, який для інших програм може виступати як сервер, можна побудувати архітектуру програмної системи з будь-яким числом ланок (наприклад, сервери додатків або WEB додатки). В цьому випадку може здійснюватися розподілена обробка даних, а за рахунок універсальних протоколів і в мережах і в Інтернет дуже складна архітектура програмних систем. CTD забезпечує таку можливість на основі механізмів СОМ.
  • Незалежність від мов програмування. СОМ сервери і клієнти можуть бути написані на різних мовах, але взаємодія між ними забезпечується за рахунок стандартизованого інтерфейсу. Так, наприклад, клієнт може бути побудований на базі ASP, а сервер на основі CTD.
  • Використання двійкових файлів для СОМ дозволяє їх багаторазово викликати, оновлювати версії, не зачіпаючи при цьому працюють систем. Супровід таких систем спрощується: досить оновити СОМ складову і додаток буде працювати з новим інтерфейсом і навіть виконувати нові функції, які вміщені в СОМ.

Інтерфейси і CoClass

Для побудови СОМ сервера в його програмі повинні бути визначені дві складові: інтерфейс і клас СОМ об'єкта - CoClass. Інтерфейс містить функціональність сервера, тобто набір функцій і набір даних СОМ об'єктів. Серед даних можуть виділятися змінні створюваних об'єктів (змінні об'єкта) і загальні змінні для всіх об'єктів (змінні класу). Останні, по суті, є статичними змінними класу. Функції, визначені в інтерфейсної частини, доступні користувачеві клієнтської частини програми. Дані вміщені в об'єкті, який породжується на сервері, але вони доступні за допомогою спеціальних функцій-методів класу, які може описати сам користувач. Інтерфейс має глобальний унікальний ідентифікатор GUID - IID.

Для забезпечення можливості взаємодії з північчю визначається CoClass, який успадковується від класу інтерфейсу. CoClass фактично являє об'єкт на сервері, і забезпечує обробку подій, що відбуваються на сервері в клієнтської частини програми. CoClass також має глобальний унікальний ідентифікатор GUID - CLSID. Опису CoClass відповідає в клієнтської частини Proxy class, який автоматично генерується. Можна створювати CoClass і з множинним спадкуванням від класів інтерфейсу, в той разі, ми можемо отримати комбінований СОМ сервер. В одному сервері - додатку ми можемо генерувати довільне число класів інтерфейсу і класів СОМ об'єктів.

Для уніфікації опису інтерфейсу і CoClass-ів в CTD передбачені спеціальні механізми підказок і майстер (Wizadr). Налаштування змінних класу, змінних об'єкта і методів класу виконуються автоматизовано. Не виключається можливість і ручного кодування тексту в OUTLINE.

Побудова COM серверів і їх особливості

Нижче на малюнку показаний фрагмент вікна дизайнера CTD при створенні класу інтерфейсу для найпростішого прикладу програми. Цей СОМ сервер підсумовує два цілих числа.


Мал. 1 Опис класу інтерфейсу для СОМ сервера.

Клас інтерфейсу названий IISerge, він містить автоматично генерується GUID (можна задавати і власний) і опис функцій, одна з яких (summa) і виконує безпосередньо підсумовування двох цілих параметрів. По завершенню підсумовування в клієнтському додатку ініціюється подія evEndSum (обробку див. Нижче). Крім того, в класі інтерфейсу визначені: одна змінна класу - nServerContact, що зберігає кількість підключених клієнтів, і одна змінна об'єкта - nSumm, що містить значення суми.

На наступному малюнку дано опис CoClass, успадкованого від класу інтерфейсу. У цьому описі присутній генерується або задається GUID - CLSID і опис подій, які будуть відпрацьовуватися у клієнта: evEndCum і evEndObj. Ці події ініціюються всередині функцій-методів интерфейсного класу, а, отже, через успадкування і CoClass.


Мал. 2 Опис класу ISerge і подій evEndCum і evEndObj в ньому.

При створенні подій їм, як і методам, автоматично присвоюється спеціальний номер диспетчеризації (Dispath Number). Після опису методів, змінних і подій СОМ сервер готовий до компіляції.

Реєстрація, компіляція та налагодження

Компіляція і створення виконуваного модуля для СОМ сервера проводиться звичайним способом, за невеликим винятком. При генерації СОМ потрібно вказати тип сервера. Можливі три варіанти:

  • СОМ створюється як DLL для локального спільного використання (in-process).
  • СОМ створюється як ЕХЕ для локального використання як процес (out-of-process)
  • СОМ створюється як ЕХЕ для використання на мережі за допомогою MST (Microsoft Transaction Server).

Ці режими задаються у вікні настройки режимів створення СОМ (Build exe). Після успішного створення сервер необхідно зареєструвати, причому, якщо зроблені зміни і автоматично генерується GUID для класів і інтерфейсу, то необхідно виконати реєстрацію заново і заново відкомпілювати клієнтську програму. Для СОМ сервера задається універсальний ідентифікатор, званий Universally Unique Identifiers (UUID). Після всіх цих операцій СОМ сервер готовий до роботи. Ви можете запустити його під керуванням CTD або автономно. У другому випадку необхідно задати параметр, що визначає число користувачів. Для налагодження сервера нудно створити клієнтську програму і запустити його автономно.

Побудова клієнтських додатків і їх особливості

Для побудови клієнтської програми необхідно згенерувати интерфейсную APL. Генерація виконується за допомогою АХ Exprorer CTD - вбудованої утиліти. Детально робота з нею описана в іншій статті (Centura Team Developer - ActiveX компоненти: принципи і технологія застосування), тому ми тут не будемо на цьому зупинятися. Зазначу тільки, що генерація грунтується на виборі бібліотеки типів (* .tlb), яка автоматично генерується спільно зі створенням исполнимого модуля СОМ сервера і поміщається в той же каталог. Після вибору відповідної бібліотеки типів для генерації необхідно виконати повну генерацію всіх класів, подій і перерахувань. У створюване нове клієнтське додаток в розділ бібліотек повинна бути додана ця APL. Нижче на малюнку показано вікно найпростішого клієнтського додатка, створеного для ілюстрації основних положень СОМ. Ця програма підсумовує на сервері СОМ два цілих числа, що вводяться в полях форми.


Мал. 3 Приклад клієнтської програми підсумовує на сервері.

Крім кнопки підсумовування у вікні програми виконується індикація змінної класу, змінної об'єкта і числа підключених користувачів. При натисканні на кнопки додатки викликаються функції СОМ сервера, результати роботи виводяться на екран у відповідні поля. На малюнку вище представлена ​​робота одного користувача. На наступному малюнку представлена ​​робота двох клієнтських додатків. У цьому випадку ми бачимо, що загальні змінні класу (Число користувачів і змінна класу) однакові, а змінні об'єкта різні.


Мал. 4 Два клієнтських програми, що працюють з сервером.

Розглянемо тепер особливості побудови клієнтських додатків на основі СОМ технології. Після підключення APL, для даного СОМ сервера, в розділ класів додаються класи, які відповідають описам об'єктів сервера. Це такі класи: функціональний клас - samplCom_IISerge для створення інтерфейсу (виконання функцій) і Com Proxy class - samplCom_Iserge для обробки подій. Класи видно в лівій частині вікна дизайнера CTD на малюнку нижче.


Мал. 5 Класи СОМ і обробка подій в evEndSumm в програмі клієнта.

При необхідності визначення обробників подій потрібно: створити спадкоємця Com Proxy class і створити доступний об'єкт цього класу. На малюнку показаний новий клас App_Serge, який забезпечує обробку події evEndSumm. Нижче на малюнку дана ілюстрація результатів генерації интерфейсного класу. Дан весь перелік доступних функцій-методів (в лівій частині вікна) і розгорнуто опису функції підсумовування - summa (в правій частині вікна).


Мал. 6 Клас інтерфейсу samplCom_IISerge і метод summa.

Як видно з прикладу, перед викликом методу за допомогою універсальної функції INVOKE, що передаються параметри поміщаються в стек (PushNumber), а після виконання функції - викликаються з стека (PopNumber). Потім стек очищається (FlushArgs). Ця функція (summa) згенерована автоматично за допомогою АХ Explorer, і таке зв'язування називається статичним. Однак, створивши необхідні класи і об'єкти, користувач може сам в динаміці виконувати операції виклику функцій. При цьому можна забезпечити і динамічне зв'язування. Для динамічного зв'язування може бути використана змінна типу VARIANT, яка дозволяє викликати функції незалежно від типів параметрів.

Змінні класів і об'єктів, налагодження СОМ

У СОМ сервері, як уже зазначалося, можуть бути передбачені змінні класу і змінні об'єкта. Змінні об'єкта є індивідуальними прихованими даними, доступ до яких можна отримати за допомогою функцій-методів. Змінні класу (статичні змінні) є загальними для всіх об'єктів класу і зберігають свої значення поки сервер запущений. Ці змінні можуть бути доступні за допомогою методів-функцій. Крім цього в CTD додатку можуть бути оголошені загальні змінні, які можуть бути загальними для групи СОМ серверів. Такі змінні описуються в глобальній частини програми. На малюнку нижче показаний фрагмент клієнтського додатка, в якому викликаються СОМ функції і, зокрема функції доступу до змінних класу і змінним об'єкта.

В принципі, на стороні СОМ сервера немає необхідності оголошувати опис вікон інтерфейсу. Однак при налагодженні сервера такі вікна можуть знадобитися. У цьому випадку, ми можемо описати вікна, і їх використовувати при налагодженні програм сервера, спільно з додатками клієнта. Якщо ресурсів комп'ютера досить, то можна запустити дві версії CTD і проводити одночасну налагодження і клієнтського додатка і програми СОМ сервера.


Мал. 7 Виклик методів summa, GetObjVar, GetClassVar і GetCountUser в програмі.

Якщо ми хочемо ізолювати об'єкти один від одного, то CTD пропонує можливість побудувати СОМ сервер на основі Tread технологій. Для цього достатньо при генерації СОМ сервера вказати спеціальний режим. У цьому випадку можливі різні настройки, в залежності від використання сервера в локальному або віддаленому режимі.

Для зручної роботи в СОМ сервері в CTD можливе створення класів і об'єктів типу колекція. Колекції можуть використовуватися для зберігання перелічуваних констант (enum) або для зберігання вибірок (наприклад, словників списків). Визначено методи цього класу, можливості налаштування. Класи колекцій можуть використовуватися для наслідування інших класів і включатися в інтерфейсну частину об'єкту. Робота з колекціями детально описана в документації, в бібліотеку прикладів включені спеціальні приклади з використанням колекцій.

З використанням спеціальних WEB класів (Centura WEB Extention) будуються СОМ додатки для роботи під керуванням WEB. Ці програми забезпечують оперативний доступ до БД, вони працюють під управлінням WEB Application manager. Процес побудови клієнтських і серверних додатків багато в чому повторює процес побудови звичайних додатків, особливості його детально викладені в документації на CTD. До складу бібліотеки прикладів входить спеціальне СОМ додаток, яке забезпечує автоматичне перемикання режимів роботи для роботи в режимі WEB і в звичайному режимі.

Зазначу, що в рамках даної статті важко висвітлити всі питання і проблеми використання СОМ технологій. Однак думаю, що дана інформація буде корисна розробникам складних інформаційних систем для визначення стратегії їх побудови і вибору засобів реалізації. На мій погляд, варіант, запропонований в CTD, є одночасно простим і забезпечує високий рівень професіоналізму при програмуванні.