лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

Інформаційні технології віртуальних організацій

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

Розділ 3
ТЕХНОЛОГІЇ ІНТЕГРАЦІЇ
РОЗПОДІЛЕНИХ WEB-ДОДАТКІВ — CORBA, WEB-СЕРВІСИ та ін.
1. Загальна характеристика
технологій інтеграції розподілених систем
У розд. 2 було розглянуто популярні засоби розробки додатків для Web. Їх розмаїття у поєднанні з використанням різних систем керування базами даних (СКБД) забезпечує можливість створення окремих додатків для кожної компанії, що найповніше задовольняють поставленим вимогам.
Проте для створення віртуальних організацій виникає необхідність інтеграції розподілених у Web-середовищі додатків різних компаній та забезпечення взаємодії між ними.
Набір розрізнених інформаційних систем, які необхідно об’єд-
нати, можна розглядати як єдину розподілену систему. Розподілена інформаційна система, як відомо, складається із сукупності програмних компонентів, що взаємодіють один з одним. І компоненти можуть бути взаємозв’язані на різних рівнях. Виділимо основні підходи до вирішення цієї проблеми, що існують на сьо-
годні.
1.1. Інтеграція на рівні даних
Така інтеграція передбачає використання окремими компонен-
тами розподіленої системи єдиної СКБД, яка забезпечуватиме всі необхідні функції пов’язані з організацією бази даних в розподіленій системі та її використанням. Зрозуміло, що СКБД має бути досить потужною — рівня Oracle, Informix тощо.
Такий підхід може з успіхом використовуватися в рамках однієї компанії, що має розгалужену структуру, корпорації. Однак його використання для об’єднання інформаційних систем різних компаній в рамках віртуальних організацій є неприйнятним. Кож-
на компанія вже має певну інформаційну систему, використовує певну СКБД, а переробка існуючої системи, наприклад під Oracle, вимагатиме вкладення значних коштів. Тому, коли мова йде про різні додатки і різні компанії, інтегрувати на рівні даних ми не можемо.
1.2. Інтеграція на рівні об’єктів
Використання об’єктно-орієнтованого підходу дозволяє розглядати компоненти інформаційної системи на різних рівнях абстракції як об’єкти, кожний з яких має визначені функції.

Рис. 3.1. Модель розподілених об’єктів
Таким чином, система, побудована за моделлю розподілених об’єктів (рис. 3.1), складатиметься з набору компонентів (об’єк-
тів), що взаємодіють один з одним. При цьому об’єкти, як правило, розкидані по мережі і виконуються окремо один від одного.
Взаємодія таких об’єктів, у більшості випадків, здійснюється на базі деякого середовища, основною метою якого є реалізація механізму обміну повідомленнями в гетерогенних розподілених середовищах.
Побудова середовища взаємодії є одним із найскладніших питань при розробці інформаційної системи на основі моделі розподілених об’єктів. Як показує практика, створення власного, уні-
кального середовища взаємодії об’єктів приводить, з однієї сторони, до різкого збільшення витрат на реалізацію проекту, а з іншої — до неповноти отриманого рішення. Таким чином, необхідно використовувати вже існуючі програмні продукти, що від-
носяться до рівня проміжного програмного забезпечення (mіddle-
ware) і реалізують необхідні середовища взаємодії.
На сьогоднішній день виділяють три різні технології, що підтримують концепцію розподілених об’єктних систем та дозво-
ляють реалізувати середовище взаємодії об’єктів: RMІ, DCOM, CORBA.
1. RMІ (Remote Method Іnvocatіon — виклик віддаленого методу) є розробкою компанії JavaSoft, що інтегрована з JDK1.1. Найпростіший і найшвидший спосіб створення розподілених систем і гарний вибір для створення RAD-компонентів і невеликих додатків мовою Java. Є менш потужною технологією, ніж DCOM чи CORBA, використовує свій рідний, не CORBA/ІІOP-сумісний, протокол передачі JRMP і може взаємодіяти лише з іншими Java-об’єктами. Підтримка тільки однієї мови унеможливлює взаємодію з об’єктами, написаними не мовою Java. Тим самим, роль RMІ в створенні великих розподілених систем знижується.
2. DCOM (Dіstrіbuted Component Object Model) була розроблена компанією Mіcrosoft як рішення для розподілених систем у 1996 р. Натепер контролюється групою TOG (The Open Group) і є відкритим стандартом. Серед переваг технології можна назвати мовну незалежність, можливість динамічного або статичного виклику об’єктів, масштабованість. Недоліками є орієнтація на плат-
форми Mіcrosoft (хоча цей недолік може бути виправлений з часом), а також відсутність безпеки при виконанні ActіveХ компо-
нентів. Зараз DCOM є головним конкурентом CORBA.
3. CORBA (Common Object Request Broker Archіtecture) розроблена OMG (Object Managment Group). На сьогодні є найпо-
тужнішою серед трьох технологій, мовно незалежною, платформ-
но-незалежною та має широку індустріальну підтримку. Саме CORBA у поєднанні із Java найкраще підходить для інтегрування Web-систем на рівні об’єктів. У п. 2 даного розділу технологію CORBA буде розглянуто детальніше.
Використання моделі розподілених об’єктів дозволяє скористатися всіма перевагами об’єктно-орієнтованого підходу:

  • скорочення часу розробки (ізольована розробка) завдяки розбиттю системи на модулі (взаємодія між модулями здійснюється на основі встановлених протоколів та інтерфейсів);
  • повторне використання програмних компонентів;
  • полегшення майбутніх змін системи (зміна коду лише в потрібних модулях);
  • можливість побудови «тонких клієнтів», придатних для швид-
    кого завантаження через мережу (Іnternet) і запуску на комп’ютері клієнта (до такого роду додатків можна віднести Java-аплети чи Actіve-X компоненти); вся функціональна логіка системи переноситься на серверну частину.

Проте складність розробки стримує інтеграцію розподілених систем на рівні об’єктів.
1.3. Поняття сервіс-орієнтованої архітектури,
інтеграція на рівні передачі повідомлень
Із розвитком електронного бізнесу і появою віртуальних організацій виникла необхідність інтеграції бізнесів-процесів різних компаній на основі Web.
У 1999 р. з’явилась концепція сервісно-орієнтованої архітектури (Service-Oriented Arhitecture — SOA) побудови розподілених систем, в основу якої покладена орієнтація саме на бізнес-процеси [2].
SOA є агрегацією компонентів, сервісів і процесів. Компоненти є програмами для виконання специфічних задач. Вони мають визначений інтерфейс і, зазвичай, одну функцію (наприклад: перевірити користувача чи отримати оцінку кредиту тощо). Сервіс є простим групуванням компонентів (програм) для виконання пев-
ної задачі (наприклад, отримання позики). Бізнес-процеси є ключовими пунктами в SOA, оскільки компоненти мають бути підібрані таким чином, щоб їх задовольняти.
Виділяють три типи компонентів:

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

В рамках SOA виділяють також три типи сервісів:
1. на основі Угод (Сontracts);
2. на основі Повідомлень (Messages);
3. на основі Сховищ (Repository).
Сервіси першого типу передбачають наявність домовленостей, придатних для визначення інтерфейсу (наприклад, такими домовленностями в CORBA виступає мова IDL).
Використання повідомлень (закінчених блоків даних з заголов-
ком, транспортною інформацією тощо) є іншим механізмом для визначення інтерфейсу сервісу.
Останній тип сервісів передбачає задання інтерфейсу через сховища шляхом посилання на міжкомпонентні та міжсервісні ресурси.
На сьогоднішній день спостерігається еволюційний перехід від сервісів першого типу до інтеграції розподілених систем на рівні передачі повідомлень. Повідомлення при цьому формуються у вигляді XML-документів (див. розділ 2). У п. 3 даного розділу буде розглянуто Web-сервіси, які реалізують сервіс-орієн-
товану архітектуру на основі повідомлень — їх стандарти та засоби побудови.
2. CORBA-технології
Міжнародним консорціумом OMG (Object Management Group) (www.omg.org) запропоновано низку стандартів, що можуть використовуватися для побудови розподілених систем на основі об’єктної моделі. Основним серед цих стандартів є CORBA (його та пов’язані з ним стандарти можна переписати з сайту OMG).
 До складу OMG на сьогодні входить більше 700 членів (компаній-виробників програмних продуктів, комп’ютерів, телекомунікаційних систем, розробників прикладних систем і кінцевих користувачів). Цікаво, що в OMG входять практично всі найбільші виробники ПО, за винятком Mіcrosoft.
На сьогоднішній день CORBA-технології використовуються для розробки розподілених об’єктно-орієнтованих додатків у мережах масштабів підприємства; також вони можуть використовуватися і при створенні віртуальних організацій (див. п. 2.4).
Стандарт підтримується великою кількістю розробників, серед яких: Sun Microsystems, IBM, Hewlett-Packard, DEC та ін.
Як недоліки розробки CORBA-систем виділяють складність та значну вартість.
2.1. Архітектура CORBA-систем
Проектування архітектури розподіленої інформаційної системи передбачає виділення базових компонент, їх інтерфейсів, а також визначення правил та принципів взаємодії цих компонент.
Основою стандарту CORBA є архітектура керування об’єк-
тами — Object Management Argitecture (OMA). Ключова ідея цієї архітектури полягає в представленні будь-якої задачі у фор-
мі взаємодії об’єктів, розподілених по різних комп’ютерах. Об’єктна модель CORBA визначає порядок взаємодії між ци-
ми об’єктами — клієнтами і серверами. (Клієнти — це додатки, що запитують послуги, а сервери — додатки, що надають ці послуги.)
ОМА складається з чотирьох основних компонент-специфі-
кацій (рис. 3.2), що відносяться до двох верхніх рівнів семирівневої моделі взаємодії відкритих систем (OSI):

Рис. 3.2. Архітектура керування об’єктами (ОМА)

  • архітектури брокера об’єктних запитів (Common Object Re-
    quest Brocer Architecture — CORBA) — встановлює механізми взаємодії об’єктів в гетерогенній мережі;
  • об’єктних сервісів (Object Services) — системних служб, що використовуються розробниками для створення додатків;
  • універсальних засобів (Common Facilities), орієнтованих на підтримку користувацьких додатків;
  • об’єктів додатків (Application Objects), призначених для роз-
    в’язання конкретних прикладних задач.

2.2. Стандарт CORBA
Стандарт CORBA визначає механізм, що забезпечує взаємодію додатків у розподіленій системі.
Головними компонентами стандарту CORBA є:

  • ORB (Object Request Broker) — брокер об’єктних запитів;
  • IDL (Interface Definition Language) — мова визначення інтерфейсів;
  • ОА (Object Adapter) — об’єктний адаптер;
  • IR (Interface Repository) — репозиторій інтерфейсів.

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

Рис. 3.3.
Dynamіc Іnvocatіon Іnterface (DІІ) дозволяє клієнту знаходити сервери і викликати їхні методи під час роботи системи.
ІDL Stubs визначає, яким чином клієнт робить виклик сервера.
ORB Іnterface визначає загальні як для клієнта, так і для сервера сервіси.
ІDL Skeleton забезпечує статичні інтерфейси для об’єктів визначеного типу.
Dynamіc Skeleton Іnerface — загальні інтерфейси для об’єк-
тів, незалежно від їхнього типу, що не були визначені в ІDL Skeleton.
Object Adapter — об’єктний адаптер — забезпечує засоби для доступу клієнтів до сервісів ORB.
Існує цілий ряд програмного забезпечення ORB від різних розробників, яке дозволяє розробляти CORBA-системи. Список ORB з зазначенням мов, на яких вони дозволяють здійснювати відображення, підтримуваних протоколів, сервісів та ін., можна подивитися на http://www.puder.org/projects/.
Можливі різноманітні ORB-реалізації в рамках єдиної архітек-
тури ОМА:

  • реалізація ORB у вигляді резидентних підпрограм на клієнтських машинах і в системі об’єктної реалізації;
  • сервер-основані ORB (звичайна програма на сервері під керуванням ОС);
  • системоосновані ORB (як базисний сервіс операційної системи);
  • бібліотечно-основані ORB.

На сьогоднішній день все більше розробників орієнтуються на сервер-основані ORB.
Для зв’язку між брокерами в гетерогенній мережі був розроблений протокол General Inter ORB Protocol (GIOP), який стандартизує низькорівневе представлення даних і множину форматів повідомлень.
Internet Inter-ORB Protocol (IIOP) визначає обмін повідомлень в форматі GIOP на основі використання протоколу ТСР/ІР.
Мова визначення інтерфейсів IDL є деякою універсальною мовою, призначеною для опису інтерфейсів.
Інтерфейс передбачає деяку множину операцій та їх параметрів, необхідних для реалізації запитів. Мова опису інтерфейсів надає засоби визначення цих операції для звернення клієнтів до серверних об’єктів.
Інтерфейси складаються із заголовка та тіла опису.
В заголовку вказується назва інтерфейсу та інтерфейси, що наслідуються.
В тілі інтерфейса оголошуються константи, типи, атрибути, операції.
Наприклад:
Interface Account {
Attribute long Balance;
long deposit (in long dollars);
};
Тобто, IDL не є повною мовою програмування, а забезпечує лише опис операцій звернення до об’єктів та їх параметрів. Синтаксис і семантика ІDL описані в http://www.omg.org/cgibin/doc?
formal/01-12-07
.
Для конкретної реалізації об’єкта генерується його відображення з IDL-опису на одну з мов програмування (С++, С, Small-
talk…). На сервері OMG представлені специфікації відображення ІDL на різні мови програмування.
Об’єктний адаптер — ОА — забезпечує засоби доступу клі-
єнтів до сервісів об’єктного брокера запитів ORB. Основні задачі об’єктного адаптера:

  • генерація посилань на віддалені об’єкти;
  • виклик методу об’єкта, визначеного в ІDL;
  • безпека взаємодії;
  • активація і деактивація об’єктів;
  • встановлення відповідності між посиланнями на віддалені об’єкти і реальними екземплярами об’єктів;
  • реєстрація об’єктів.

Специфікація CORBA визначає базовий об’єктний адаптер (Basic Object Adapter — BOA), який повинен бути реалізований в усіх ORB.
Репозитарій інтерфейсів — IR — є засобом зберігання та обробки інформації, необхідної для опису інтерфейсів CORBA-об’єктів.
На основі IR можлива генерація динамічних запитів. Це зручно для побудови додатків, в яких дані, параметри та функції можуть змінюватися під час роботи додатків.
IR дозволяє здійснювати взаємодію об’єктних брокерів різних виробників.

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2017 BPK Group.