Питання впровадження сучасних інформаційних технологій в процеси проведення маркетингових та соціологічних опитувань

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ЗМІСТ

ВСТУП

1. Постановка задачі

1.1 Описання проблеми

1.1.1 Дослідження предметної області

1.1.2 Огляд існуючих інструментів автоматизації

1.2 Опис вимог до функціональності

1.3 Визначення основної функціональності

1.3.1 Функціональність серверної частини

1.3.2 Функціональність клієнтської частини

2. Дослідження інструментів реалізації

2.1 Аналіз методологій розробки програмного забезпечення

2.1.1 Методологія Microsoft Solution Framework

2.1.2 Ітеративна розробка

2.1.3 Методологія Rapid Application Development

2.1.4 Методологія Rational Unified Process

2.1.5 Методологія Extreme Programming

2.1.6 Agile - гнучка методологія розробки

2.1.7 Висновок

2.2 Порівняльний аналіз програмних технологій .NET та CORBA

2.3 Вибір системи керування базами даних

2.3.1 Визначення критеріїв порівняння

2.3.2 Порівняльний аналіз СКБД MS SQL Server та Oracle

2.4 Вибір технології доступу до даних

2.4.1 Огляд технології Language Integrated Query (LINQ)

2.4.2 Огляд технології ADO.NET Entity Framework

2.4.3 Огляд технології ADO.NET Data Services

2.4.4 Огляд технології Sync Framework

2.4.5 Вибір технологій доступу до даних

2.5 Визначення інструментів для розробки проекту

3. Реалізація проекту

3.1 Загальна схема проекту

3.1.1 Компонент зберігання інформації (глобально)

3.1.2 Компонент взаємодії адмінчастини з базою даних

3.1.3 Адміністративна частина

3.1.4 Компонент зберігання інформації (локально)

3.1.5 Компонент взаємодії клієнтської частини з базою

3.1.6 Клієнтська частина

3.2 Сценарій роботи системи

3.3 Проектування бази даних

3.3.1 Концептуальний рівень

3.3.2 Логічний рівень

3.3.3 Фізичний рівень

3.4 Реалізація функціональності системи

3.4.1 Визначення функціональних пріоритетів

3.4.2 Об'єктна модель системи

4. ВИСНОВОК

5. ЛІТЕРАТУРА

6. ДОДАТОК А. Лістинг коду основних компонентів

ВСТУП

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

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

· гнучка комбінація методів ринкового регулювання, заснованих на зворотних зв'язках;

· формування й функціонування ринкових господарюючих суб'єктів як відкритих, соціально орієнтованих систем, що означає "поворот" до ринку та споживача;

· самоврядування на всіх рівнях і перехід до поліцентричної системи господарювання;

· комбінація ринкових і адміністративних методів керування організаціями.

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

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

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

1. ПОСТАНОВКА ЗАДАЧІ

1.1 Описання проблеми

1.1.1 Дослідження предметної області

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

· Які проекти потрібно в першу черги розвивати і в яких напрямках;

· Що потрібно змінити, модернізувати;

· Які послуги варто призупинити/закрити;

· Які нововведення варто впровадити;

· Як найефективніше розподілити фінансування різних напрямків організації.

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

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

1. Визначення необхідності певної інформації;

2. Отримання інформації;

3. Аналіз;

4. Видача результатів.

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

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

Будь-яке маркетингове опитування потребує виконання певної послідовності дій (етапів). Ось основні з них:

· Концептуалізація - визначення мети дослідження, висування гіпотез, уточнення понять і знаходження їх операціональних відповідностей у даному опитуванні.

· Схематизація - встановлення процедур, які повинні бути застосовані під час опитування, і прийняття розв'язків про характер необхідної вибірки.

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

· Планування - розгляд фінансових, адміністративних, матеріально-технічних і кадрових проблем, пов'язаних із проведенням опитування.

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

· Інструктаж - підготовка інтерв'юерів і іншого обслуговуючого опитування персоналу до роботи з респондентами й до обробки даних; постачання персоналу необхідними матеріальними засобами.

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

· Опитування - поштове, телефонне або очне опитування учасників вибірки із застосуванням пілотажного інструментарію.

· Спостереження за ходом опитування (моніторинг) - перевірка коректності застосування методики, що опитують, а також контроль за тим, щоб були опитані тільки учасники вибірки.

· Контрольна перевірка - перевірка (за допомогою додаткових контактів з респондентами) того, чи всі члени вибірки виявилися реально охоплені опитуванням і всі чи з них повернули свої анкети.

· Кодування - перетворення зібраних даних у числову форму.

· Обробка - підготовка даних для аналізу

· Аналіз - переробка даних за допомогою статистичних і інших засобів з метою одержання змістовних висновків.

· Складання звіту - виклад результатів аналізу у формі дослідницького звіту.

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

1.1.2 Огляд існуючих інструментів автоматизації

На даний момент існує програмне забезпечення, що реалізує певний функціонал в даній сфері. Наприклад, програма «Пріс». За її допомогою можна створювати опитування, вводити інформацію по проведених опитуваннях та аналізувати результати. Формат реалізації програми - Windows-додаток. Встановлюється безпосередньо на комп'ютер під керівництвом операційної системи Windows. Працює з файлами Excel. Ліцензія на один екземпляр програми коштує приблизно 250грн. Ще один з інструментів проведення опитувань - «Соцопрос». Програма також дозволяє створювати нові опитування, дані зберігає в базі даних Access, що також потребує додаткової інсталяції екземпляру Microsoft Office. Працює під керівництвом операційних систем сімейства Windows. Аналітичних функцій по обробці результатів опитування практично немає. Ліцензія одного екземпляру коштує також приблизно 250грн.

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

1.2 Опис вимог до функціональності

Основна задача полягає в том, щоб спроектувати та розробити систему обробки та аналізу даних, отриманих в процесі маркетингових опитувань.

Кінцевий програмний продукт має задовольняти деякий ряд вимог:

· Система повинна передбачати отримання даних з певних джерел;

· Інформація має надходити до кінцевої точки незалежно від місцезнаходження джерела (мобільність);

· Кількість процесів отримання інформації, що виконуються одночасно повинні обмежуватись лише апаратними засобами системи (робота з багатьма джерелами);

· Використання технології «клієнт-сервер»;

· Отримання даних та первинна обробка здійснюються на клієнті;

· Основна обробка та аналіз даних виконується на сервері;

· Для збереження даних використовується СУБД;

· Клієнт повинен мати можливість приймати отримувати дані незалежно від наявності зв'язку із сервером;

· Система має передбачати інтерфейс для перегляду оброблених та проаналізованих даних, адміністрування та моніторингу протікаючи процесів;

· Термін - 2 місяці;

· Бюджет - 5000у.о.

1.3 Визначення основної функціональності

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

· Створення опитувань;

· Керування параметрами опитувань;

· Розподіл опитувань між інтерв'юерами;

· Моніторинг процесів;

· Імпорт опитувань, створених замовником в систему;

· Можливість отримання даних від джерела та збереження в системі;

· Безпечне зберігання інформації;

· Відображення результатів (статистики);

· Можливість автономної роботи (без постійного зв'язку з сервером);

· Реалізація безпеки даних (шифрування, авторизація);

· Синхронізація сервера з клієнтом.

Виходячи з того, що система створюватиметься на за технологією «клієнт-сервер», можна визначити, що вона буде складатися з декількох компонентів, що мають взаємодіяти між собою за певним сценарієм. Відповідно, описані вище функціональні вимоги можна розділити між складовими частинами системи.

1.3.1 Функціональність серверної частини

· Створення опитувань;

· Керування параметрами опитувань;

· Розподіл опитувань між інтерв'юерами;

· Моніторинг процесів;

· Імпорт опитувань, створених замовником в систему;

· Відображення результатів (статистики);

· Реалізація безпеки даних.

1.3.2 Функціональність клієнтської частини

· Отримання інформації безпосередньо від джерела;

· Автономна робота;

· Первинна обробка даних;

· Перетворення інформації в потрібний формат;

· Пересилання даних на сервер.

2. ДОСЛІДЖЕННЯ ІНСТРУМЕНТІВ РЕАЛІЗАЦІЇ

2.1 Аналіз методологій розробки програмного забезпечення

2.1.1 MSF (Microsoft Solutions Framework)

Основні принципи:

- Розподіл відповідальності при фіксації звітності

- Надання членам команди повноваженнями

- Концентрація на бізнес-пріорітетах

- Єдине бачення проекту

- Готовність до внесення змін

- Вільне спілкування

Етапи розробки:

- Вибірка концепції

- Планування

- Розробка

- Стабілізація

- Впровадження

Критерії використання:

- Складний проект

- Відносно великий бюджет

- Наявність відносно великої команди

- Недостатньо чітке формулювання вимог

2.1.2 Ітеративна розробка

Основні принципи:

- Зниження ризиків на ранніх стадіях проекту

- Ефективний зворотній зв'язок проектної команди із замовником

- Акцент зусиль на найбільш важливі та критичні напрямки проекту

- Безперервне ітеративне тестування

- Рівномірне навантаження на учасників проекту

Етапи розробки:

- Розробка вимог

- Аналіз та дизайн

- Реалізація

- Тестування

- Впровадження

Критерії використання:

- Довготривалий проект

- В кінці кожного етапу (ітерації) проект має бути готовим до використання

- Можливість підтримувати ефективний зв'язок із замовником

2.1.3 Rapid Application Development - швидка розробка додатків

Основні принципи:

- Використання інструментарію, направленого на мінімізацію часу розробки

- Створення прототипу для більш чіткого узгодження із замовником

- Мінімізація часу розробки за рахунок модернізації вже готових модулів

- Тісна співпраця розробників

- Управління проектом повинно мінімізувати довжину циклу розробки

Етапи розробки:

- Аналіз та планування вимог

- Проектування

- Розробка

- Впровадження

Критерії використання:

- Важлива швидкість розробки (до 90 днів)

- Невисока деталізація вимог до проекту

- Обмежений бюджет проекту

- Проект може бути розбитий на декілька функціональних компонентів

- ПЗ не має великої обчислювальної складності

2.1.4 RUP (Rational Unified Process)

Основні принципи:

- Швидка ідентифікація та безперервне усунення ризиків

- Концентрація на виконанні вимог замовника

- Очікування змін у вимогах, проектних рішеннях

- Компонентна архітектура, що реалізується та тестується на ранніх стадіях проекту

- Постійна підтримка якості на усіх етапах розробки

- Ключова роль в команді розробки належить архітекторам

Етапи розробки:

- Бізнес-моделювання

- Управління вимогами

- Аналіз та проектування

- Реалізація

- Тестування

- Впровадження

Критерії використання:

- Складний проект

- Нечітке описання вимог

- Основна частина роботи припадає на архітекторів

2.1.5 XP (Extreme Programming) - екстремальне програмування

Основні принципи:

- Розробка через тестування

- Гра в планування

- Замовник завжди поруч

- Парне програмування

- Безперервна інтеграція

- Рефакторінг

- Часті невеликі релізи

- Колективне володіння кодом

- Стандарт кодування

Етапи розробки:

- Планування релізу

- Розробка

- Випуск

Критерії використання:

- Стислі строки

- Невеликий проект

- Невелика команда розробників

- Різна кваліфікація членів команди

2.1.6 Agile - Гнучка методологія розробки

Основні принципи:

- Ітеративність та інкрементальність розробки

- Мінімізація ризиків

- Кожна ітерація завершується робочим продуктом

- Безпосереднє спілкування команди

- Зменшений обсяг письмової документації

Етапи розробки:

- Планування

- Аналіз вимог

- Проектування

- Кодування

- Тестування

- Документування

- Впровадження

Критерії використання:

- Нечітке описання вимог до проекту

- Необхідність на кожному етапі (ітерації) підтримувати проект в робочому стані

- Можливість команди спілкуватися безпосередньо між собою

2.1.7 Висновок

Виходячи з вимог до проекту, бюджет проекту невисокий. Відповідно, кількість членів команди також не буде великою. При терміні реалізації проекту в 2 календарні місяці потрібно вибрати ту методологію розробки програмного забезпечення, що дозволила б створити повноцінний продукт невеликою командою та в короткі строки. Також, враховуючи те, що проект відносно невеликий, в даному випадку можна виділи дві методології, що задовольнять цим вимогам: RAD (швидка розробка додатків) та XP (екстремальне програмування). Остання не вимагає більш-менш чіткого описання проекту, скоріше пропонує контролювати відповідність проекту вимогам за допомогою написання окремих тестів. В той самий час метод швидкої розробки дає можливість більш детально спроектувати етапи розробки, що дозволить дотримуватись певного плану в процесі роботи. Також, метод передбачає використання інструментальних засобів візуального моделювання та розробки, автоматичної генерації коду та готових компонентів, що можуть бути задіяні в даному проекті. Отже, найбільш актуальним в даному випадку методом розробки є RAD (швидка розробка додатків).

2.2 Порівняльний аналіз програмних технологій .NET та CORBA

Основними критеріями вибору програмних технологій для порівняння були висока надійність, стабільність технології та можливість швидкого створення повноцінних функціональних рішень. В кінцевому результаті для порівняння було вибрано дві сучасні програмні технології, що можуть бути використані для створення потужних інформаційних систем - .NET та CORBA. Дослідження буде проводитись за найбільш вагомими параметрами технології відносно даного проекту.

Доступ до реляційних баз даних.

· .Net

Основою доступу до баз даних технології .Net є бібліотека ADO.NET. З її допомогою можна отримати доступ до джерел даних використовуючи OLE DB провайдери, .Net провайдери або XML. З реляційними даними можна робити всі необхідні операції (вибірку, додавання, оновлення, видалення і т.д.).

В ADO.NET чітко розділяється доступ до даних і різні операції з даними за допомогою виділення різних функцій у компоненти, які можуть використовуватись окремо або разом. Результати вибірок можуть бути оброблені відразу, або можуть бути занесені в ADO.NET Dataset. Результати можуть бути сконструйовані із запитів до гетерогенних або розподілених баз даних. Причому, Dataset є частиною реляційної бази даних, що складається з колекції таблиць, і містить усі зв'язки цих таблиць, первинні ключі, індекси і т.д. Для обробки локальних даних або даних отриманих з XML, Dataset можна використовувати незалежно від провайдера даних (джерела даних).

ADO.NET підтримує нову програмну модель. Можна відзначити деякі ключові особливості моделі, такі як: можливість роботи з кешованими даними (disconnected data architecture), тісна інтеграція з XML (класи XML в. NET Framework і ADO.NET - частини архітектури системи), єдина модель відображення даних з можливістю комбінувати дані з різних і мінливих джерел даних, можливість оптимізації в ключових точках доступу до даних конкретних СКБД, багаторівнева архітектура додатків підтримується бібліотекою класів. Об'єкти класів ADO.NET можуть бути передані як за посиланням, так і за значенням. Розробники об'єктної моделі ADO.Net забезпечили сумісність із попередньою версією бібліотеки - ADO, тому програмістам не потрібно перенавчатись при переході на нову версію.

· Java-corba

Модель доступу до даным відрізняється від .Net тим, що замість Dataset і інших класів загального призначення, що здійснюють доступ до даних, створюються різні перехідники до конкретних структур реляційних і об'єктних баз даних. Наприклад, створюється клас, який представляє абсолютно конкретну таблицю або з'єднання таблиць бази даних. З реалізацій систем доступу до даних можна назвати служби доступу до об'єктно-реляційних баз даних на основі Oracle 8і. Але в цьому випадку знову ж, класи в програмі і їх екземпляри представляють собою зовсім конкретні об'єкти бази даних.

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

Очевидно, на практиці краще підхід прийнятий технологією .Net, тому що використання стандартних компонентів дозволяє швидше створити комерційні програмні продукти.

Доступ до об'єктів в інших процесах, на різних комп'ютерах і мережах.

· .Net

Підтримуються два типи додатків, що здійснюють міжпроцесорну взаємодію і видалений виклик об'єктів:

1. ASP.NET це інфраструктура, керована Internet Information Services (IIS). Підтримуються базові типи (класи). Додатки на основі технології ASP добре відомі розробникам програмного забезпечення, що використовували попередню версію бібліотеки.

2. Net Remoting. Надає ряд сервісів: активації об'єктів; контроль часу життя об'єктів; комунікаційні канали, відповідальні за транспортування повідомлень між видаленими додатками. Форматери використовуються для кодування й декодування повідомлень перед тем як вони будуть послані по комунікаційних каналах. Додатки можуть використовувати двійкове кодування, якщо вимоги до продуктивності критичні або Xml-кодування, якщо необхідна транспортування між різними операційними системами. Remoting розроблявся з урахуванням надання безпеки при передачі даних, передбачений ряд точок підключення додаткових модулів для шифрування-розшифрування повідомлень, а також інші стандартні й нестандартні механізми надання безпеки.

Інфраструктура remoting - абстрактний опис процесу міжпроцесорних комунікацій. Забезпечена повна прозорість цього процесу. Пошук об'єктів, що перебувають поза доменом додатка проводиться за допомогою URL. Це активаційні URL, які самі унікальні й представляють унікальні типи (об'єктів). За допомогою активаційних URL можна безпомилково викликати саме ті типи об'єктів, які необхідні для виконання функцій додатка. Далі, об'єкти, які можуть бути передані за значенням або скопійовані, автоматично передаються між додатками в різних доменах або на різних комп'ютерах. Необхідно тільки позначити класи як serializable.

Реальна міць remoting полягає в можливості взаємодії об'єктів, що перебувають у різних доменах додатків або процесах з використанням різних транспортних протоколів, різних форматів сериализации, схем життєвого циклу об'єктів і способів створення об'єктів. До того ж, можливо втручатися в цей процес на будь-якій стадії (підключати додаткові модулі, змінювати параметри і т.д.). Підтримуються два стандартні канали передачі даних: Tcpchannel і Httpchannel. Також, можуть реєструватися будь-які інші канали. І по HTTP і по TCP каналам повідомлення можуть транспортуватися як із застосуванням протоколу SOAP, так і у двійковому форматі. Крім того, можна підключати свої форматери повідомлень для інших форматів передачі даних. Вибір каналу визначається такими факторами, як швидкість передачі даних, безпека й деякими більш дрібними технічними деталями. Наприклад, безпека Http-каналу забезпечується протоколом HTTPS, а безпека Tcp-каналу протоколом TCP/IP. Tcp-канал більш продуктивний, ніж Http-канал, тощо.

Для того, щоб об'єкт певного типу був доступний видалено, необхідно надати системі дистанційного доступу наступну інформацію:

1. Необхідний тип активації класу об'єкта (типу).

2. Повний опис метаданих типу.

3. Комунікаційний канал, який потрібно зареєструвати для обробки запитів до типу.

4. URL об'єкт, що унікально ідентифікує даний тип. У випадку серверної активації це URI, який унікальний для даного типу. У випадку клієнтської активації це унікальний URL, який буде привласнений екземпляру даного типу.

· Java-corba

Ціль створення CORBA полягає в забезпеченні доступу до об'єктів в інших процесах, на різних комп'ютерах і мережах. Повністю описати дану технологію тут неможливо. Якщо коротко, то основний процес, що відбувається при функціонуванні CORBA - це виклик різних операцій об'єктів. Аналізуючи відмінності об'єктних ідеологій .Net і CORBA можна зробити трохи несподіваний висновок, що в. Net у різних доменах розподілені класи, а в CORBA - об'єкти. Наприклад, більшість базових класів бібліотеки .Net - "nonremotable" об'єкти. Тобто, при створенні екземплярів даних класів вони не можуть передаватися через межі процесів, як у вигляді посилань так і за значенням. Це й зрозуміло, тому що базові класи "існують" в. Net Framework, а .Net Framework встановлюється на кожний комп'ютер, що працює з даною технологією. Тому немає необхідності робити ці класи "remotable" - вони можуть бути успішно створені на кожному локальному комп'ютері. Інша справа, класи, специфічні для додатка. Такі класи швидше за все будуть "remotable", їхня імплементація буде розташовуватися в модулях, що перебувають на обраних мережних комп'ютерах (при виборі комп'ютера - сервера повинна враховуватися кількість клієнтів, частота створення й час життя об'єктів і т.д.), відповідно, посилання на них будуть проводитися по URL. URL унікальні по своїй природі й класи, специфічні для додатка також унікальні. URL - аналог сурогатного первинного ключа в реляційних базах даних. Так проводиться пошук об'єктів в. Net. В CORBA же способи пошуку об'єктів більш розвинені. В CORBA, за промовчанням, передбачається, що об'єкти існують постійно, якщо є посилання (узяте з репозиторію об'єктів, конфігураційного файлу програми або, навіть, просто жорстко вбита в програму), то передбачається, що є й об'єкт. На практиці, звичайно, використовуються різні механізми активації-деактивації, контролю часу життя об'єктів. Пошук об'єктів може проводитися:

1. За допомогою служби імен. Ця служба містить деревоподібну базу даних об'єктів. Запит до служби містить ім'я необхідного об'єкта. На запит вертається посилання на об'єкт. Служба імен - це сервіс CORBA, який вказується при завантаженні відповідного ORB. Окремі служби імен можна поєднувати з об'єднанням їх баз даних.

2. За допомогою служби комерції. Служба комерції - це також сервіс, що вказується при конфігуруванні ORB. Містить базу даних посилань на об'єкти із прикріпленою до них інформацією про властивості цих об'єктів, що називається пропозиціями. Пропозиції в службі комерції публікують сервера, що обслуговують опубліковані об'єкти. Інформація про властивості об'єкта містить список пар ім'я-значення. Значення може бути встановлене, а може бути позначене як динамічне. Це означає, що замість значення встановлюється адреса Callback-функції. Динамічні значення використовуються для властивостей, що часто змінюються. Пошук у службі комерції проводиться запитами, схожими на SQL Select c пропозицією Where. Можна задати діапазон необхідних властивостей об'єднаних логічними операціями. У відповідь на такий запит може бути отриманий набір посилань на об'єкти.

3. Можуть застосуються більш прості способи, такі як посилання на об'єкт у конфігураційному файлі у вигляді рядка, тверде кодування посилання в програмі і т.д.

Таким чином, .Net використовує спосіб пошуку об'єктів подібний служби імен CORBA, роль служби імен виконують Dns-сервера. Ще одна відмінність - те, що посилання на об'єкт .Net універсальна й унікальна в глобальному масштабі, а CORBA по первісному задуму використовує посилання специфічні для певного ORB. Можна зробити висновок, що пошук об'єктів .Net реалізований примітивніше, ніж в CORBA і має менші можливості - не можна одержувати набори об'єктів за умовами пошуку. Але, з іншого боку, перевагою технології .Net є те, що система пошуку об'єктів інтегрована в глобальне мережне оточення.

Доступ до Internet.

· .Net

Підтримується багаторівнева, розширювана й керована архітектура Internet services. Можна створювати модулі, що підключаються, для нових Internet-протоколів або ж використовувати "керовану" реалізацію Windows socket interface для роботи з мережею на рівні сокетов.

· Java-corba

Спостережувана картина подібна описаної для .Net при зовнішній несхожості. Також є можливість створення додатків (серверів і клієнтів), які будуть взаємодіяти через Internet або за допомогою протоколу IIOP, або застосовуючи технологію тунелювання протоколу HTTP або який-небудь ще з мережних протоколів CORBA. Основною проблемою, у відмінності від .Net, є подолання брандмауерів (Fierwall) при використанні протоколів,подібних IIOP. При створенні більшості існуючих брандмауерів не передбачалося існування протоколу IIOP. Була розроблена специфікація брандмауерів CORBA. Виробники брокерів об'єктних запитів пропонують Proxy- Брандмауерів, що використовують протокол IIOP, наприклад Wonderwall компанії IONA Technologies, або підтримку тунелювання HTTP (підтримуються Http-запити) для маскування IIOP повідомлень, що дозволяє останнім непомітно долати брандмауери, наприклад, продукт Gatekeeper компанії Inprise.

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

Active Directory.

· .Net

Простір імен System.Directoryservices - "керована" версія Active Directory Services Interfaces (ADSI). Відповідно, дозволяє робити всі те ж саме - працювати з ієрархією об'єктів Active Directory, модифікувати властивості об'єктів і т.д.

· Java-corba

Аналогом Active Directory є служба комерції й, почасти, служба імен CORBA. У цьому зв'язку можна відзначити різний підхід прийнятий в обговорюваних технологіях до керування розподіленими мережними ресурсами. Так, CORBA надає широкі можливості для створення мережних ресурсів будь-якого типу й, відповідно, потужні можливості пошуку цих ресурсів. Фірма ж Microsoft окреслила коло найбільш підходящих кандидатів на роль таких ресурсів, (принтери, каталоги, користувачі, комп'ютери і т.д.) і створила всеосяжну систему керування саме ресурсами вищеописаного типу, яка по своїх можливостях перевершує служби CORBA.

Яке з рішень краще? Відповідь на це питання знову ж можна одержати аналізуючи різний, можна сказати, протилежний підхід OMG і Microsoft до розробки специфікацій своїх продуктів і їх реалізації (із приводу відмінності методологій проектування й реалізацій програмних продуктів фірми Microsoft і консорціуму OMG). Абстрактний підхід OMG викликає меншу довіру, тому що вся історія розвитку людського суспільства вказує на правило поступального руху дрібними кроками методом спроб і помилок.

Створення розкладів виконання процесів на сервері

· .Net

Використовуючи компонент Timer можна створювати події які будуть збуджуватися на сервері через певні інтервали.

· Java-corba

Можна припустити, що така ж можливість є й в CORBA. Але для цього потрібно створити черговий сервер додатків, або службу.

Розробка компонентів

· .Net

Уведене поняття компонента, яке майже повністю подібно поняттю Delphi. Причому існують, так само як і в Delphi, Соntrоl's, які походять від компонентів. Також, існують контейнери компонентів і контролів. Відмінність у тому, що це - двійковий стандарт і компоненти, створені на одній з мов програмування платформи .Net повністю сумісні з компонентами створеними на іншій мові.

Наприклад, можна створювати похідні класи компонентів створених на різних мовах програмування. Але, втім, це ж можна сказати й про будь-які об'єкти в. Net. Одне ж з основних призначень компонентів - підтримка середовищ розробки додатків.

· Java-corba

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

Виходить, компонент взаємодіє із зовнішнім світом через який-небудь свій об'єкт.

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

Інтернаціоналізація додатків

· .Net

Підтримується наступний 3- х стадійний процес створення інтернаціоналізованих додатків:

1. Глобалізація.

2. Тестування на можливість локалізації

3. Локалізація.

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

· Java-corba

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

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

Одержання інформації про типи під час виконання додатків

· .Net

Простір імен Reflection підтримує набір функцій для роботи з метаданими. В. Net збірки містять модулі, модулі містять типи, типи містять члени. Reflection надає об'єкти, що інкапсулюють збірки, модулі й типи. За допомогою Reflection можна:

1. Визначати й завантажувати збірки; завантажувати модулі, що записані в маніфесті збірки; отримувати інформацію про місце розташування типу з даної збірки й створювати його екземпляр.

2. Отримувати інформацію про те, яка збірка містить даний модуль і класи цього модуля. Також можна одержувати інформацію про глобальні методи або інші специфічні не глобальні методи, зазначені у даному модулі.

3. Дізнаватись найменування, параметри, модифікатори доступу (public, private і т.д.), і деталі реалізації (abstract, virtual) конструктора. Далі, можна викликати конструктор якого-небудь типу (класу). Те ж саме можна проробляти з кожним з методів.

4. Одержувати інформацію про ім'я, модифікатори доступу (public, private і т.д.) деталях реалізації (static і т.д.) якого-небудь поля, читати або встановлювати значення поля. Те ж саме можна робити з подіями, властивостями, параметрами.

· Java-corba

Визначення інтерфейсів об'єктів під час виконання CORBA одержує двома способами: або витягаючи метадані, які перебувають у статично лінкованому Stub клієнта, або пошуком інтерфейсів у сховище інтерфейсів (Interface Repository).

Інтерфейси у сховищі перебувають у вигляді об'єктів. Основними властивостями об'єктів є ім'я й ідентифікатор. Пошук інтерфейсів може проводитися по імені. Репозиторій інтерфейсів (Interface Repository) використовується для перевірки типів сигнатур викликів незалежно від виду служби керування інтерфейсами (DII або ж інформація про типи з Stub), також, при перевірці графа спадкування інтерфейсів, при створенні мостів між різними ORB. У кожному разі в остаточному підсумку опису інтерфейсів представлені мовою IDL. При використанні DII генерується запит до об'єкта на виконання якої-небудь операції. Запит містить посилання на об'єкт, і інформацію для виклику, таку як ім'я операції, параметри, порушувані виключення, що вертають значення, контекст виклику. Метадані для створення опису операції беруться з опису IDL, а значення параметрів - надаються викликаючим клієнтом.

Одним з основних відмінності представлення метаданих в. Net і CORBA є спосіб зберігання цих метаданих. В. Net метадані зберігаються абсолютно децентралізовано. В CORBA застосовується комбінація децентралізованого й централізованого зберігання метаданих. Метадані .Net більш всеосяжні, у той час як метадані CORBA - це описи інтерфейсів з деякими можливостями опису інших структур і атрибутів об'єктів. Динамічна генерація метаданих застосовується як в. Net так і в CORBA але розуміється по-різному. Звичайний стан метаданих в. Net у простому, елементарному випадку це статично лінковані в збірку метадані, які використовуються при маніпулюванні об'єктами. В CORBA навпаки, звичайний процес генерації описів Idl-інтерфейсів під час виконання програми. З одного боку, методика керування метаданими CORBA видається більш гнучкою, але це очевидно, помилкове враження, тому що, по-перше, постійна генерація метаданих, імовірно, буде знижувати загальну продуктивність (цей процес подібний, наприклад, постійній конвертації яких-небудь даних з одного формату в іншій ), по-друге, в. Net при необхідності можна застосовувати точно таку ж методику. Але вся справа в тому, що необхідність виникає не так уже й часто. Таким чином, очевидно, на прикладі .Net ми бачимо просто більш оптимізовану версію того самого процесу керування метаданими. Крім того, у силу оптимізації в. Net надається можливість реалізувати більш розвинену модель метаданих, що дозволяє описувати більше типів різних сутностей. Але, імовірно, до недоліків моделі метаданих .Net можна віднести сугубо децентралізований спосіб їх зберігання. Не перешкодила б і стандартна можливість централізованого зберігання. Хоча натяки на це є вже зараз, наприклад, MetaData Services на платформі MS SQL Server.

Динамічна генерація виконуваних модулів

· .Net

Класи простору імен System.Reflection.Emit дозволяють редагувати метадані, створювати збірки, модулі й типи під час виконання. Reflection можна використовувати для створення браузерів об'єктів, компіляторів, серіализації об'єктів і т.д.

· Java-corba

В CORBA такого поняття не існує.

Розширення метаданих

· .Net

Для анотації типів, полів, методів і властивостей CLR дозволяє додавати описи, подібні ключових слів, які називаються атрибутами. Атрибути зберігаються разом з метаданими файлів .NET Framework і можуть бути використані для опису коду під час виконання або ж для зміни поведінки додатка під час виконання. Хоча в. NET Framework визначений ряд основних атрибутів, можна додавати визначення нових атрибутів. Атрибути також використовуються різними середовищами розробки, наприклад дизайнерами компонентів, середовищами розробки додатків подібними Delphi.

· Java-corba

В CORBA такого поняття не існує.

Генерація вихідного коду на різних мовах програмування під час проектування.

· .Net

Можна вважати, що спеціальним засобом проектування для платформи .Net є Microsoft Visio. За допомогою Visio можна розробити й реалізувати всі види діаграм, передбачені стандартом OMG UML. Далі, по схемах генерується вихідний код на мовах програмування, підтримуваних CLR. Також, можлива генерація моделі по вихідному коду. Причому, потрібно врахувати, що Visio інтегрується в Microsoft Office і Microsoft Visual Studio .Net.

· Java-corba

Моделі бізнес-процесів створюються за допомогою таких програмних продуктів, як Rational Rose, Select, Forte, Dynasty, Powertier компанії Persistense Software і Microsoft Visio. Підтримується генерація коду на будь-якій мові програмування.

У змісті створення моделей бізнес-процесів підхід технологій .Net і CORBA сходиться мовою UML - творінням OMG, підтверджуючи думку про те, що міць OMG проявляється в основному в області абстракції.

Генерація й компіляція вихідного коду на різних мовах програмування під час виконання

· .Net

За допомогою .NET Framework SDK можна під час виконання додатка генерувати вихідний текст програми кількома мовами програмування. Генерація проводиться по якійсь моделі, створеній за певними стандартами. Ця технологія називається Code Document Object Model (Codedom).

Структура моделі (графа) вихідного тексту незалежна від мови програмування й містить усі елементи, характерні для більшості основних мов програмування. Модель вихідного коду може бути створена програмно, під час виконання. Потім по ній може бути генерований вихідний код, який, у свою чергу, може бути скомпільований, а потім отримана збірка може бути запущена. Наприклад, Codedom використовують: ASP.NET, для створення графів об'єктів, які потім компілюються в збірки, які, потім формують Html-сторінки й елементи керування; простору імен System.Codedom і System.Codedom.Compiler і т.д. Можна підключати додаткові модулі для будь-яких мов програмування.

· Java-corba

В CORBA такого поняття не існує.

Групування даних у колекції

· .Net

Підтримуються колекції з усіма стандартними властивостями й методами: енумераторами і т.д.

· Java-corba

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

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

Обробка й порушення подій

· .Net

Події в. Net Framework представлені делегатами. Делегат це клас, який може містити посилання на метод. На відміну від інших класів, у делегата є сигнатура й він може містити посилання тільки на ті методи, які відповідають сигнатурі. Делегат - еквівалентний вказівнику на type-safe function або callback.

· Java-corba

Очевидно, аналогією подій .Net є асинхронні виклики CORBA із застосуванням Callback функцій. Хоча є специфікації й реалізації так званих "служб подій" CORBA, але це поняття скоріше є аналогією системи обміну повідомленнями Message Queue технології .Net.

Обробка й порушення виняткових ситуацій

· .Net

Усі операції в. NET Framework у випадку помилки під час виконання збуджують виняткові ситуації. Обробка виключень CLR проводиться з використанням наступних принципів:

1. Незалежність обробки від мови, що спровокувала виключення й, також, мови,що обробляє виключення.

2. Не вимагає від мов якогось певного синтаксису обробки виключень.

3. Виключення збуджуються через межі процесів і доменів додатків.

· Java-corba

Класичний випадок виникнення виняткової ситуації - помилка на сервері при виконанні запиту клієнта. Для цього в CORBA, як відзначалося вище, при формуванні запиту до сервера в описі операції виробленої над серверним об'єктом може вказуватись [rises(except1,…exception)]. Це список користувацьких виняткових ситуацій. Далі, при одержанні у відповіді (responce) виняткової ситуації організується її обробка.

Можна зробити висновок, що й .Net і CORBA забезпечують подібну функціональність при обробці виняткових ситуацій.

Взаємодія зі стороннім кодом.

· .Net

Net Framework може взаємодіяти з COM додатками, COM+ компонентами, зовнішніми бібліотеками типів, більшістю сервісів операційної системи. Також, можливі виклики .NET Framework з COM, COM+ додатків. Виникаючі проблеми: невідповідність типів даних, сигнатур методів, механізмів обробки помилок, які різняться при виконанні керованого й некерованого коду.

У випадку взаємодії .Net і COM виникає проблема подібна обговорюваної в підрозділі, присвяченому Java-corba (див. нижче). Але ця проблема набагато "м'якше" з кількох причин:

1. Взаємодію доводиться налагоджувати не часто, тому що в основному все можна зробити із застосуванням .Net.

2. Якщо й доведеться налагоджувати взаємодію, то це набагато легше зробити між двома родинними продуктами COM-.Net, ніж між Com-java-CORBA.

· Java-corba

По суті, можлива взаємодія з кожним, як процедурним, так і об'єктно-орієнтованим стороннім кодом. Але тільки виникає питання, чого це буде коштувати? Можна дати швидка відповідь - потрібно буде створити значну кількість саморобних перехідників, що будуть гальмувати процес. Стандартно ж реалізована взаємодія тільки з COM. У цьому зв'язку можна помітити, що якщо засновувати розробку корпоративної системи на CORBA, те неминуче доведеться налагоджувати взаємодію з Com-додатками. Як говорилося вище - користувачів Windows - більшість. Основна технологія для міжпроцесорної взаємодії, застосовувана в Windows - COM. Отже, неминуча інтеграція існуючих користувачів Windows у корпоративну систему на основі CORBA сполучена з налагодженням взаємодії з різними Com-службами Windows і Com-додатками. Але, COM - це застаріла технологія, яку Microsoft не збирається розбудовувати. Таким чином, маючи лише одну легальну можливість з'єднати воєдино різнорідні системи ми свідомо будемо опиратися на застарілу, отже й поступово втрачаючу підтримку фірми-розробника, технологію.

Асинхронні виклики й взаємодія додатків за допомогою повідомлень.

· .Net

Можливе асинхронне програмування з використанням моделей:

1. Callback.

2. Poll Completed.

3. Begin Invoke, End Invoke.

4. Begin Invoke, Wait Handle, End Invoke.

Для створення черг повідомлень (наприклад, повідомлень, що містять вилучені виклики клієнтами методів об'єктів створених на сервері) використовується Microsoft Message Queuing. За допомогою цього компонента можна виконувати запити, що втримуються в повідомленнях, які були відкладені, наприклад через того, що був відключений мобільний комп'ютер або обладнання або сервер був занадто завантажений і не міг обробити запити. Messagequeue - розвинена служба обміну повідомленнями, яка інтегрується з COM+ і, отже, запити на виклики видалених процедур можуть бути включені в довгочасні розподілені транзакції. Також, служба взаємодіє з багатьма основними сервісами ОС Windows.

· Java-corba

В CORBA асинхронне програмування й взаємодія за допомогою повідомлень практично не розділяється. Починаючи з більш примітивних способів асинхронних викликів (Callback) і закінчуючи службами подій і груповим обміном повідомлень CORBA підтримує практично ті ж можливості асинхроного програмування, що й .Net.

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

Груповий обмін повідомленнями - ще один спосіб обміну повідомленнями заснований на можливостях групового мовлення протоколу IP. Реалізоване в програмному продукті Orbixtalk.

Можна зробити висновок, що реалізації служб повідомлень мають достатні можливості як в. Net так і в CORBA. Але .Net не надає незалежну від платформи службу повідомлень і це означає, що всі переваги цієї служби .Net проявляються при використанні ОС Windows.

Транзакції

· .Net

CLR підтримує два типи транзакцій: автоматичні й неавтоматичні. Для того, щоб транзакції починалися автоматично, необхідно щоб класи були зареєстровані в Windows 2000 Component Services. Неавтоматичні транзакції підтримують Microsoft Activex Data Objects (ADO), OLE DB, Open Database Connectivity (ODBC), Microsoft Message Queuing (MSMQ).

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

Термін "serviced component" уведений в. Net Framework для позначення компонентів, які підготовані для використання разом з COM+. Таким чином, значно збільшується міць технології .Net відносно керування групами об'єктів, шляхом включення їх у добре структурований і керований транзакційний процес. Але дана технологія, очевидно, залежить від платформи.

· Java-corba

Технологія CORBA має високорозвинену інфраструктуру транзакційних служб. OMG визначив службу об'єктних транзакцій OTS (Object Transaction Service) як ту, що грає ключову роль у розподіленій обробці транзакцій на основі CORBA.

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

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

Стандарт X/Open Reference Model for Distributed Transaction Processing (DTP) визначає стандартні інтерфейси взаємодії компонентів Tp-моніторів. Якщо модель X/Open DTP визначає процедурні інтерфейси, що обмежують доступ на рівні процедур, то служба об'єктних транзакцій OTS визначає розподілені, об'єктно-орієнтовані інтерфейси для компонентів Tp-систем. Комерційні реалізації Tp-моніторів слідують цій тенденції, створюючи монітори транзакцій об'єктів на основі технології CORBA поверх існуючої технології Tp-моніторів, заснованої на моделі X/Open DTP. Наприклад, реалізація Orbixots компанії IONA Techologies базується на програмному продукті Encina компанії Transarc, а проміжне програмне забезпечення M3 компанії BEA Systems - на програмному продукті TUXEDO. Специфікація CORBA OTS розроблялася таким чином, щоб повністю сполучатися з моделлю X/Open DTP, завдяки чому відкриття технології може виглядати як процес еволюції, а не як повна заміна існуючої технології. Таким чином, реалізації служби CORBA OTS дозволяють використовувати всі переваги існуючої, перевіреної технології Tp-моніторів у сучасному об'єктно-орієнтованому середовищі CORBA.