TextBook Козак І. А. Інформаційні технології віртуальних організацій ПЕРЕДМОВА 3 Розділ 1. ОСНОВНІ ПОНЯТТЯ 4 1. Передумови створення віртуальних організацій 4 1.1. Концепція телероботи, історія та характеристика сучасного стану використання. Віртуальні офіси 4 1.2. Електронна комерція, електронний бізнес 6 1.3. Виникнення віртуальних підприємств 8 2. Поняття віртуальних організацій та їх класифікація 11 3. Загальна характеристика інформаційних технологій для віртуальних організацій 15 Контрольні запитання і завдання 16 Література 16 Розділ 2. ТЕХНОЛОГІЇ РОЗРОБКИ WEB-ДОДАТКІВ 17 1. Інтернет — як основне телекомунікаційне середовище для віртуальної організації 17 1.1. Історія 17 1.2. ТСР/ІР 18 2. Мова розмітки — HTML 25 3. Організація обміну інформацією через web - броузери, web-сервери, протокол HTTP 33 3.1. Броузери 33 3.2. Web-сервери 33 3.3. HTTP 35 4. Поширені засоби розробки Web-сторінок 37 4.1. Мови сценаріїв 37 4.2. CGІ - програми 38 4.3. Технологія Java 38 4.4. ASP 39 4.5. PHP 40 5. XML 40 5.1. Історія та загальна характеристика стандартів XML 40 5.2. Структура документа XML, конструкції мови 43 5.3. Специфікація тегів - DTD та XML Schema 45 5.4. Мова опису стилів XSL 51 5.5. Аналізатори та генератори XML – документів 53 5.6. Використання та перспективи XML для віртуальних організацій 54 Контрольні запитання і завдання 55 Література 56 Розділ 3. ТЕХНОЛОГІЇ ІНТЕГРАЦІЇ РОЗПОДІЛЕНИХ WEB-ДОДАТКІВ - CORBA, WEB-СЕРВІСИ ТА ІН. 57 1. Загальна характеристика технологій інтеграції розподілених систем 57 1.1. Інтеграція на рівні даних 57 1.2. Інтеграція на рівні об’єктів 58 1.3. Поняття сервіс-орієнтованої архітектури, інтеграція на рівні передачі повідомлень 60 2. CORBA-технології 61 2.1. Архітектура CORBA-систем 61 2.2. Стандарт CORBA 63 2.3. Об’єктні сервіси 65 2.4. Універсальні засоби 67 2.5. Процес розробки розподілених додатків 68 3. Web-сервіси 69 3.1. Поняття Web-сервісів 69 3.2. Стандарти Web-сервісів 70 3.3. Засоби розробки Web-сервісів 76 Контрольні запитання і завдання 77 Література 78 Розділ 4. СКБД ДЛЯ ВІРТУАЛЬНИХ ОРГАНІЗАЦІЙ 79 1. Загальна характеристика підходів до організації БД віртуальних організацій 80 2. Технології доступу до баз даних в Інтернет-системах 80 2.1. Доступ до БД на стороні сервера 80 2.2. Доступ до БД зі сторони клієнта на основі Java-тех- нології 82 3. Використання баз даних в об’єктних системах 84 4. XML і бази даних, XML-СКБД 86 5. Використання Open Source СКБД 90 Література 93 Розділ 5. ТЕХНОЛОГІЇ І СИСТЕМИ КЕРУВАННЯ ЗНАННЯМИ ВІРТУАЛЬНОЇ ОРГАНІЗАЦІЇ 94 1. Основні поняття керування знаннями 94 2. Зберігання та представлення знань 97 2.1. Вимоги до представлення знань 97 2.2. Моделі представлення знань 99 3. Виявлення знань з даних — Data Mining 102 4. Виявлення знань з текстів — Text Mining 106 5. Спеціалізовані системи керування знаннями 107 5.1. Типи систем основаних на знаннях 107 5.2. Використання порталів для керування знаннями 108 5.3. Спеціалізовані системи керування знаннями від сві-то- вих лідерів 111 6. Проблема пошуку знань в Інтернет та концепція Se- mantic Web 116 6.1. RDF 118 6.2. Деякі RDF-застосування 130 6.3. OWL Ontology Web Language — Мова Онтологій Web 136 Контрольні запитання і завдання 144 Література 144 Розділ 6. ТЕХНОЛОГІЇ ПРОГРАМНИХ АГЕНТІВ 146 1. Поняття про програмні агенти, класифікація та перспективи використання 146 2. Архітектура програмних агентів та типи міжагентних комунікацій 148 3. Технології та стандарти 152 4. Інструментальні засоби розробки програмних агентів 154 5. Програмні агенти та онтології 157 5.1. Представлення інформації для програмних агентів 157 5.2. Інструментальні засоби розробки онтологій 159 5.3. Використання онтологій в глобальних масштабах 160 Контрольні запитання і завдання 162 Література 163 Розділ 7. ТЕХНОЛОГІЇ ПІДТРИМКИ ГРУПОВОЇ ДІЯЛЬНОСТІ: СИСТЕМИ ДОКУМЕНТООБІГУ, ГСППР, WORKFLOW-СИСТЕМИ 164 1. Технології groopware 164 2. Використання систем документообігу у віртуальних організаціях 165 3. Групові системи підтримки прийняття рішень 170 4. Поняття про workflow-системи, класифікація, переваги використання та вимоги до систем для віртуальних організацій 176 4.1. Поняття workflow-систем 176 4.2. Класифікація систем 177 4.3. Переваги використання 178 4.4. Вимоги до систем для віртуальної організації 179 5. Структура workflow-систем та їх функціональні компоненти 180 5.1. Стандарти workflow 180 5.2. Функції workflow-систем 181 5.3. Визначення бізнес-процесів у workflow-системі 183 6. Критерії порівняння та приклади workflow-систем 185 Контрольні запитання і завдання 192 Література 193 Розділ 8. ТЕХНОЛОГІЇ ЕЛЕКТРОННОГО ОБМІНУ ДАНИМИ: ЕЛЕКТРОННА ПОШТА ТА ТЕЛЕКОНФЕРЕНЦЗВ’ЯЗОК ДЛЯ ВІРТУАЛЬНИХ ОРГАНІЗАЦІЙ 194 1. Електронний обмін даними 194 1.1. Історія 194 1.2. Стандарти на структуру електронних повідомлень 195 2. Системи електронної пошти 196 2.1. Організація системи електронної пошти 196 2.2. Клієнтське програмне забезпечення для роботи з електронною поштою 198 2.3. Серверне програмне забезпечення поштових систем 201 2.4. Сервери безкоштовної електронної пошти 204 2.5. Формати поштових повідомлень 206 2.6. Протоколи обміну електронною поштою 207 2.7. Голосова пошта і факсова пошта 208 2.8. Єдине середовище обміну повідомленнями 209 3. Телеконференції 211 3.1. Поняття та класифікація телеконференцій 211 3.2. Стандарти телеконференцій 214 3.3. Основні компоненти систем телеконференцзв’язку 217 3.4. Структура мереж телеконференцзв’язку 222 3.5. Технологія організації відеоконференцій 224 3.6. Персональні телеконференції через Інтернет 226 Контрольні запитання і завдання 232 Література 233 Розділ 9. CALS — ТЕХНОЛОГІЇ У ВІРТУАЛЬНИХ ОРГАНІЗАЦІЯХ 234 1. Сутність CALS-технологій та можливості для віртуальних організацій 234 2. Стандарти CALS 238 3. Використання CALS-технології на етапі створення віртуальної організації 244 4. PLM, PDM-системи 248 Контрольні запитання і завдання 252 Література 253 Розділ 10. БЕЗПЕКА ВІРТУАЛЬНИХ ОРГАНІЗАЦІЙ 254 1. Основні поняття безпеки 254 2. Методи шифрування 257 2.1. Класифікація криптографічних алгоритмів 257 2.2. Симетричні криптоалгоритми 259 2.3. Асиметричні криптоалгоритми 264 2.4. Програмні засоби шифрування інформації 264 3. Програмне забезпечення для захисту інформації у віртуальних організаціях 266 3.1. Міжмережні екрани 267 3.2. Засоби забезпечення VPN 268 3.3. Системи виявлення атак 269 Контрольні запитання і завдання 272 Література 272 Розділ 11. ПРИКЛАДИ ВІРТУАЛЬНИХ ОРГАНІЗАЦІЙ 273 1. Віртуальні виробничі підприємства 273 1.1. Приклади проектів, основаних на NІIIP 273 1.2. Приклади проектів, основаних на CALS-техноло- гіях, CITIS 277 1.3. Український проект компанії «Квазар Мікро» 282 2. Віртуальні офіси 284 3. Віртуальні банки 287 3.1. Поняття віртуальних банків, інтернет-банкінгу 287 3.2. Інтернет-банкінг в Україні 288 3.3. Спеціалізовані системи для Інтернет-банкінгу 290 4. Віртульні платіжні системи 293 5. Віртуальні брокери 297 5.1. Поняття віртуального брокера, Інтернет-трейдінгу 297 5.2. Робота з цінними паперами 299 5.3. Клієнтське програмне забезпечення для роботи на Форексі 302 6. Віртуальні магазини 305 7. Віртуальній страхові компанії 308 8. Віртуальні університети 310 9. Віртуальні організації в галузі пасажирських авіаперевезень 315 Контрольні запитання і завдання 317 Література 317 Предметний покажчик 318 ЛІТЕРАТУРА 324 "Років через п'ять кожна компанія перетвориться в Інтернет-компанію або припинить своє існування" (Энди Гроув і Крейг Баррет, Іntel) Розділ 1. Основні поняття 1. Передумови створення віртуальних організацій 1.1. Концепція телероботи, історія та характеристика сучасного стану використання. Віртуальні офіси. На початку 70-х років у розвинутих країнах світу стало можливим придбання комп’ютерів та комунікаційного обладнання за досить низькими цінами. Ряд спеціалістів почали використовувати їх вдома, і у зв’язку з цим з’явилась ідея - працювати вдома. Використовувати комп’ютер так, ніби він стоїть на робочому місці, а за допомогою комунікаційного обладнання зв’язуватися з офісом для отримання нових розпоряджень або даних, передачі результатів роботи. Виникло ряд нових термінів: teleprocessing - телеобробка, або віддалена обробка даних; telecommuting - телепідключення - термін стосувався працівників, що "підключалися" до віддаленого офісу для роботи. telework - віддалена робота. Першими телекомютерами були системні програмісти, які зрозуміли, що вони можуть створювати програмне забезпечення вдома або ж десь на дачі так само успішно, як і в офісі. Чітка межа між роботою і будинком у цьому випадку стирається. Виникла модель, що одержала назву "малий офіс/домашній офіс" (SOHO - Small Office Home Office ). Для зв’язку з офісом зазвичай використовувалися модеми та комутовані телефонні канали. Розвиток цієї моделі стимулювалася демографічними факторами, появою нових технологій, прагненням корпорацій знизити витрати, пов'язані з орендою приміщень. В результаті швидко розширилися категорії співробітників, що працюють удома. На початку 90-х років із появою Інтернет та інших нових технологій можливості телероботи розширилися. Тепер віддалений працівник міг працювати з будь-якої точки світу, при цьому не лише обмінюватися даними з офісом, надсилати електронні листи, але й спілкуватися в реальному часі з колегами в телеконференціях, сумісно працювати над проектами та ін. На зміну моделі SOHO прийшла модель "віртуального офісу" (vіrtual offіce). При цьому під поняттям "віртуальний офіс" розуміється деякий веб-ресурс (чи його частина), що дозволяють географічно роз'єднаним співробітникам компанії організаційно взаємодіяти за допомогою єдиної системи обміну, збереження, обробки і передачі інформації. Основні фактори, що сприяють поширенню використання віддалених робочих місць подано на рис.1.1. Використання віртуальних офісів різко скорочує необхідність у виробничих площах; дозволяє співробітникам виконувати свої обов'язки в будь-який час доби і з будь-якої точки земної кулі - єдина умова - наявність доступу до Інтернет. В розвинених країнах віртуальні офіси досить поширені і добре відпрацьовані технології їх сворення. В Україні вони лише починають входити в щоденну практику роботи підприємств, проте існують деякі правові перешкоди цьому, так в Україні не ратифікована Конвенція «Про надомну працю». Трудові відносини в нашій державі регулюються Кодексом законів про працю України (КЗоТ), проте специфіка надомної праці в цьому документі не відображена. За прогнозом компанії Gartner Group Inc. кількість працівників, що працюють віддалено зросте з 36 млн. в 2000 р. до 160 млн. в 2005р. (рис.1.2.) Експерти дослідницької фірми Killen&Associates вважають, що до 2005 року 77 відсотків з 2000 найбільших компаній світу впровадять В2Е-системи - для віддаленої роботи своїх працівників. 1.2. Електронна комерція, електронний бізнес Разом з новими можливостями для окремих працівників компаній, з розвитком Інтернет та web-технологій з’явилися й нові можливості для компаній в цілому. Використовуючи web, компанія може взаємодіяти не лише із своїми працівниками, але й з клієнтами, партнерами. Так, завдяки можливості продажу товарів та послуг за допомогою електронних каналів глобальної мережі в наш лексикон увійшли слова "електронна комерція" або "e-commerce". Першими визначення поняття "e-commerce" дали фахівці компанії ІВМ: Електронна комерція (e-commerce) – здійснення будь-яких форм ділових угод за допомогою інформаційних мереж. В загальному випадку електронна комерція передбачає: • подання інформації про товари та послуги компанії; • замовлення товарів чи послуг через мережу; • он-лайн оплата замовлення. Із поширенням електронної комерції у вживання все частіше почав входити термін "віртуальний". Так, магазини які продають товари через Інтернет - електронні магазини, або віртуальні. Банківські послуги через мережу Інтернет назвали інтернет-банкінгом. А банки, створені за допомогою засобів інформаційної мережі (які не мають фізичних відділень для роботи з клієнтами, всі банківські операції відбуваються винятково через Інтернет) - віртуальними банками. З’явились віртуальні брокерські контори, страхові компанії, біржі, рекламні агенції, проектні організації, університети та ін. Використання терміну "віртуальний" в даному випадку означає, що та чи інша компанія "розміщена" в Інтернет, тобто у деякому віртуальному просторі. На сьогоднішній день багато компаній використовують глобальні мережі значно ширше, ніж це передбачається електронною комерцією. Так, на основі глобальних мереж будуються системи взаємодії з партнерами, постачальниками і клієнтами, і навіть організовують виробничі процеси. З’явилося більш широке поняття - "електронний бізнес". Електронний бізнес (e-business) - будь-яка ділова активність, що використовує можливості глобальних інформаційних мереж для перетворення внутрішніх і зовнішніх зв'язків компанії з метою створення прибутку. Таким чином, якщо провести аналогії, "електронна комерція" відповідає процесам здійснення продажів товарів та послуг, а "електронний бізнес" - бізнесу взагалі. 1.3. Виникнення віртуальних підприємств За допомогою глобальних мереж стали можливими перетворення як зовнішніх відносин між компаніями та їхніми партнерами чи клієнтами, так і внутрішньої структури самих компаній. Есперти зазначають, що основи традиційної економіки та принципи ведення бізнесу знаходяться сьогодні на порозі революційних змін. Акцент підприємців повинний зміщатися на початкові стадії життєвого циклу продукту або технології, у першу чергу – на іновації. Але навіть великі транснаціональні корпорації не в змозі осилити весь необхідний для утримання ринкових позицій багаж академічних і прикладних знань і тому залучають до співробітництва інші компанії. Часткова або повна передача виконання окремих бізнесів-функцій чи частин бізнес-процесів стороннім особам або організаціям називається аутсорсингом Ефективність аутсорсингу різко зростає завдяки перенесенню компанією в електронні мережі, насамперед в Інтернет, контактів з кінцевими споживачами (В2С - business-to-consumer), власними працівниками (В2E – business-to-employee), державними органами (В2G – business-to-government), підприємствами (В2В – business-to-business). На думку експертів Gartner Group, ряд відомих компаній до 2005 можуть доручити своїм партнерам і постачальникам до 50 відсотків нинішніх внутрішніх операцій. Перехід від традиційної моделі бізнесу до декапіталізованої моделі е-бізнесу, що показана на рис.1.3. [4], реалізується шляхом створення принципово нових типів організацій - віртуальних підприємств, праобразом яких є мережеві організації (мережі постачальників, мережі виробників, споживчі мережі, коаліції по стандартах і технологічній кооперації). Концепція віртуальних підприємств підприємств з’явилась більше 10 років тому і в першу чергу пов’язана з публікацією роботи У. Девідоу та М. Мелоуна “Віртуальна корпорація”. Як зазначено в цій роботі: віртуальне підприємство створюється шляхом відбору людських, фінансових, матеріальних, організаційно-технологічних та інших ресурсів з різних підприємств та їх інтеграції з використанням комп’ютерних мереж. Це дозволяє сформувати гнучку та динамічну організаційну структуру, що є найбільш пристосованою до найшвидшого випуску та оперативної доставки нової продукції на ринок. Можна виділити наступні характеристики, притаманні таким віртуальним підприємствам: • Вони утворюються в результаті взаємодії між компаніями. І членом віртуальної організації може бути як велика транснаціональна корпорація, так і невеличка приватна фірма чи навіть окремий консультант незалежно від територіального розміщення. • Компанії у віртуальній організації зберігають свою юридичну та економічну незалежність. • Метою використання віртуальної організації є оптимальне використання можливостей ринку та ресурсів. • Взаємодія партнерів у віртуальній організації обмежена метою. Основною особливістю віртуальних організацій є використання інформаційних і комунікаційних технологій, які дозволяють їх реалізувати. Серед переваг такої форми організації бізнесу можна назвати: - гнучкість у виборі робочої сили (компанії-виконавці кожної функції можуть бути замінені більш кращими без особливих обмежень); - легкість переходу на нову продукцію (модульна організація може змінити свою структуру); - більш висока продуктивність і задоволеність працею співробітників та інш. Недоліками є: - слабкість безпосереднього контролю над процесами; - сильна залежність від роботи суміжників; - складність роботи з відокремленими працівниками (відсутність в них відчуття колективу та надійності робочого місця) та інш . Пізніше, автори використовують різноманітні визначення віртуальних підприємств, за основу яких обираються різні підходи. Так, в роботі [2] показано, що авторами, які використовують структурний підхід до визначень, віртуальне підприємство (організація) називається мережею, формою співробітництва, або ж комбінацією ресурсів. У випадку використання процесного підходу - неперервною установчою зміною, стратегічним підходом, управлінським підходом, дією або здатністю. Для детального знайомства з різноманітними визначеннями відсилаємо до цієї роботи. В [2] також пропонується поєднання структурного і процесного підходів, в результаті чого віртуальне підприємство визначається як: співробітництво між організаціями деякої підмножини відібраної з відомої множини (dynamic Web - відкритий кінцевий набір попередньо кваліфікованих партнерів, які згодні входити в об’єднання потенційних членів віртуальної організації). Це співробітництво сфокусоване на реалізації визначених задач (цілей), конкретних маркетингових можливостей. При цьому форми співробітництва можіть бути різноманітними - від договору обслуговування до стратегічного альянсу. Як видно з цієї роботи, віртуальне підприємство може бути створене у випадку, коли потенційні партнери та їх кваліфікація відомі та представлені в Web-середовищі. Тобто, необхідні певні організаційні та технологічні передумови для його створення. Таким чином, підсумовуючи все вищевказане як основні передумови виникнення віртуальних організацій можна назвати: 1. Економічні фактори 2. Розвиток інформаційних технологій і зокрема Інтернет-технологій 3. Організаційні - наявність потенційних учасників ВП та мережного брокера у Web-середовищі. 2. Поняття віртуальних організацій та їх класифікація Як було зазначено в попередньому пункті, сучасні інформаційні і комунікаційні технології надали можливості для нових організаційних форм взаємодії: - співробітників з компанією, - компаній з клієнтами; - компаній між собою. Ця взаємодія здійснюється у деякому віртуальному просторі, у так званих віртуальних офісах, магазинах, банках, підприємствах, створених з використанням сучаних інформаційних систем і технологій. Введемо деяке узагальююче поняття віртуальної організації: Віртуальна організація (ВО) – це співтовариство територіально роз’єднаних компаній та/або співробітників, що обмінюються продуктами своєї праці і спілкуються між собою та з клієнтами шляхом використання сучасних інформаційно-комунікаційних технологій та систем при мінімальному або цілком відсутньому особистому контакті. За суб’єктами взаємодії (рис.1.4) віртуальні організації можна поділити на: • Віртуальні підприємства (корпорації) - суб’єктами взаємодії є різні компанії і окремі працівники • Віртуальні офіси - суб’єктами взаємодії є компанія та її працівники • Віртуальні установи - суб’єктами взаємодії є компанія та її клієнти (а також, можливо, працівники) - до них належать електронні магазини, банки, тощо. Можна також виділити різні класифікаційні ознаки для віртуальних організацій з точки зору різноманітних організаційних моментів їх утворення та принципів діяльності. На рис. 1.5. подано класифікацію віртуальних організацій за деякими такими ознаками.Так: За тривалістю їх можна поділити на довготривалі об’єднання та організації для разових угод. Так деякі об’єднання підприємств утворюються для реалізації єдиної ділової угоди і припиняють своє існування після її реалізації. Але є також довгострокові об’єднання, утворені для тривалого співробітництва (можливо, з конкретизацією часу). При створенні ланцюгів постачання в харчовій або автомобільній індустрії цей клас віртуальних організацій є найбільш типовим. Топологія. Деякі підприємства (не стратегічні партнери) можуть динамічно приєднуватись або залишити об’єднання відповідно до фаз ділового процесу або інших ринкових факторів - у цьому випадку можна говорити про динамічну структуру віртуальної організації (TMG, Prolion). Але в багатьох секторах промисловості є ланцюги постачання з майже незмінною структурою (або з незначними змінами з точки зору постачальників або клієнтів) - у цьому випадку віртуальна організація матиме фіксовану структуру (Nike, ING, Airbus). Участь. Підприємство може одночасно брати участь в різних віртуальних організаціях, або ж приєднатися до одного певного утворення. Координація. На основі мережної координації можуть бути виявлені різні моделі. У деяких секторах економіки, таких як автомобільна індустрія, є домінуюча компанія (її також часто називають в літературі компанією-брокером), яка "оточується" відносно незмінною мережею постачальників (утворюється структура подібна "зірці"). Домінуюча компанія визначає "правила гри" і "нав’язує" власні стандарти, виражені в термінах інформаційного обміну. Подібні приклади можна знайти також в секторі агробізнесу. Інший принцип організації можна знайти в деяких ланцюгах постачання без домінуючої компанії (демократичний альянс), в якій всі вузли співробітничають на рівній основі, зберігаючи свою автономію. Як тільки успішне об’єднання сформовано, компанії можуть усвідомити взаємні вигоди від загального управління ресурсами і вміннями і створити щось на зразок загальної структури для координації (федерація). Масштаб видимості. Аспект масштабу видимості пов’язаний як з топологією, так і з координацією; по суті він означає, "як далеко" вздовж мережі може один вузол "бачити". У багатьох випадках вузол може "бачити" тільки найближчих сусідів (постачальників, клієнтів) – така ситуація має місце у більшості ланцюгів постачання. У більш вдосконалених ситуаціях вузол може "бачити" інші рівні. Багаторівнева видимість є вимогою для оптимальної координації декількох видів діяльності в ВП. Наприклад, при реалізації функції прогнозу попиту, окрім історичних даних, важливо мати додатково інформацію про споживання, рівні запасів або навіть передбачити те, що відбувається на всіх рівнях ланцюга постачання. За напрямком діяльності віртуальні організації можна розділити на: • віртуальні підприємства • віртуальні магазини, • віртуальні банки, • віртуальні біржі, • віртуальні брокерські контори, • віртуальні рекламні агенства, • віртуальні підприємства, • віртуальні університети тощо. 3. Загальна характеристика інформаційних технологій для віртуальних організацій. Для забезпечення функціональності віртуальних організацій - міжорганізаційної взаємодії колективів, співробітників і роботи над виконаннями певних завдань, необхідне спеціальне програмне і програмно-технічне забезпечення та використання певних стандартів. Звичайно, в кожному окремому випадку використовуються деякі конкретні рішення, основані на технологіях та системах, що оптимальні для нього. І у розділі буде наведено приклади таких рішень. Проте, можна виділити основні групи інформаційних технологій, що в цілому використовуються для реалізації віртуальних організацій: 1. Мережні технології Інтернет/Інтранет (відіграють визначальну роль для існування віртуальних організацій), зокрема Web-технології, що опираються на стандарт представлення й обміну документами SGML (HTML, XML). 2. Технології інтеграції розподілених додатків і зокрема CORBA-технологія, основана на архітектурі керування об'єктами OMA (Object Management Archіtecture) 3. Технології підтримки групової діяльності (Groupware), включаючи програмні засоби керування потоками робіт - Workflow. 4. Технології електронного обміну даними та телеконференцзв’язку дозволяють забезпечувати документальне, аудіо та відео-спілкування між учасниками віртуальної організації. 5. Технології підтримки життєвих циклів (CALS-технології), ядром яких виступає міжнародний стандарт для обміну даними по моделях продукції STEP (Standard for the Exchange of Product model data) - забезпечують інформаційну інтеграцію і спільне використання інформації учасниками віртуальної організації на всіх етапах життєвого циклу продукції 6. Технології програмних агентів (в основному Java - основані). 7. Технології і системи керування знаннями віртуальної організації (Knowledge Management Systems). Важливу роль при розробці віртуальних організацій відіграють технології проектування інформаційних систем а також технології, що уможливлюють безпеку їх функціонування. Всі вищеперераховані технології в тій чи іншій мірі будуть висвітлені в даному посібнику. Контрольні запитання і завдання: 1. Які існують передумови створення віртуальних організацій? 2. Поясніть різницю між поняттями "електронна комерція" та "електронний бізнес"? 3. Назвіть переваги та недоліки віртуальних підприємств. 4. Дайте визначення віртуальної організації. 5. Прокласифікуйте віртуальні організації 6. Які основні технології використовуються при створенні віртуальних організацій? Література до теми: 1. Davidow W., Malone M. The virtual corporation: structuring and revitalizing the corporation for the 21st century. – N.Y.: Harper Сollins, 1992. 2. Saabeel W., Verduijn T.M., Hagdorn L., Kumar K. A model of virtual organisation: a structure and process perspective EJOV, Vol. 4 (2002) No. 1, Page: 1-17, ISSN:1422-9331. 3. Береза А.М., Козак І.А., Гужва В.М. та ін. Електронна комерція. Навч. Посібник. -К.: КНЕУ, 2002. -324 с. 4. Грейди Минс, Дэвид Шнайдер. Метакапитализм и революция в электронном бизнесе: какими будут компании и рынки в ХХІ веке/ Пер. с анг. – М.: Альпина Паблишер, 2001. – 280 с. 5. Балабанов И.Т. Электронная коммерция. - СПб: Питер, 2001. -336 с. 6. Интерактивная работа в электронных учреждениях. 2000–2001 E-xecutive, Ward Howell International. (http://www.e-xecutive.ru/education/cbs/strategy/article_516/) 7. Бабкин Ф.В.Электронная коммерция и новые организационные формы компаний // Менеджмент в России и за рубежом. № 1, 2000 г. — С. 121—129: ил. (http://www.cfin.ru/press/management/2000-1/index.shtml) 8. Алексей Еленин, Игорь Пономарев. Виртуальные корпорации .// журнал "Business online", №5, 2001г. ( http://www.peopleandmoney.ru/issues/issue16/art30) 9. Ханс А. Вютрих,Андреас Ф. Филипп. Виртуализация как возможный путь развития управления.//Международный журнал "Проблемы теории и практики управления" (http://www.ptpu.ru/issues/5_99/19_5_99.htm) 10. Магги Бигс. Структура компании будущего// Computerworld, №36, 2000 г. (http://www.osp.ru/cw/2000/36/ ) 11. Козье Д. Электронная комерция: Пер. с англ. – Москва: Издательсько-торговий дом “Руская редакция”. 1999. – 288 с.: ил. 12. Руслан Гайдаманчук. IT-аутсорсинг в Украине //"Корпоративные системы" №1, 2001г. (http://users.i.com.ua/~coder/stat10.htm) Розділ 2. Технології розробки Web-додатків 1. Інтернет - як основне телекомунікаційне середовище для віртуальної організації. 1.1. Історія На сьогоднішній день основною глобальною мережею у світі завдяки якій поширилась електронна комерція та стала можливою поява віртуальних організацій є мережа Інтернет. Історія розвитку Інтернет починається з 1986 року, коли Національний науковий фонд США (NSF) почав створення мережі NSFNET, в якій використовувались високошвидкісні телефонні канали, що з`єднували 6 суперкомп`ютерів у різних куточках країни на основі протоколу TCP/IP та інших технологій, відпрацьованих у мережі ARPANET (перша у світі глобальна мережа створена у 1968 р., припинила функціонування в 1990 році). Мережа NSFNET стала основною магістральною (backbone) структурою для Інтернет, офіційною датою виникнення якого є 1990 рік. В даний час основу Інтернет складають високошвидкісні магістральні мережі. Незалежні автономні мережі підключаються до магістральної мережі через крапки мережного доступу NAP (Network Access Poіnt). Інтернет побудована за регіональним принципом і як автономні системи зазвичай виступають великі національні мережі (наприклад UANET, RUNET та ін.), кожна з них має власне адміністративне керування і власні протоколи маршрутизації. Автономні мережі можуть утворювати компанії, що спеціалізуються на наданні послуг доступу в мережу Інтернет, - провайдери. Національні мережі в свою чергу складаються не менш ніж з 32 менших по розміру мереж (мережі університетів, дослідницьких центрів і комерційних фірм, а також мережі більш дрібних регіональних провайдерів). У 1994 році фінансування основної магістралі мережі Інтернет було цілком передане від NSF різним державним і комерційним організаціям. На сьогодні основним органом, що здійснює інформаційну підтримку і регулювання в Інтернет, є ІSOC (Іnternet Socіety - Всесвітнє співтовариство Інтернет, www.isoc.org). ІSOC є громадською міжнародною організацією, що базується на добровільному членстві та підтримується внесками і пожертвуваннями спонсорів. ІSOC проводить щорічні конференції INET, випускає інформаційні матеріали, підтримує інформаційні сервери. Іншими координуючими добровільними організаціями є: ІAB (Іnternet Archіtecture Board - Рада з архітектури Інтернет, www.iab.org ) займається координацією діяльності в області розвитку структури мережі Інтернет. ІETF (Іnternet Engіneerіng Task Force - Цільова група з інжинірингу в Інтернет, www.ietf.org ) складається з декількох робочих груп, що розробляють і затверджують стандарти для мережі Інтернет. В даний час в ІETF існує 75 робочих груп, що вивчають різні аспекти розвитку Інтернету. На сьогоднішіній день ведуться роботи по переходу на нову версію протоколу IP - IPv6 (з IPv4) для підтримки все зростаючої кількості користувачів мережі і можливості виділення їм унікальних ІР-адрес. Починаючи з 1996 року консорціумом Іnternet2 (в який входять більш ніж 200 американських університетів, урядові структури, а такж ІТ-компанії Mіcrosoft, 3Com, ІBM, Cіsco і багато інш.) ведуться роботи над удосконаленням Інтернет. Головною метою Іnternet2 є розробка нових технологій передачі даних з метою прискорення і підвищення якості передачі та надання нових послуг. Існує також ряд інших проектів, направлених на розвиток Інтернет (наприклад, федеральний проект США, NGI - Next Generation Internet). 1.2. ТСР/ІР Поставивши задачу домогтися зв’язності гетерогенних систем, DARPA фінансувала дослідження, проведені Стенфордським університетом і компаніями Bolt, Beranek і Newman (BBN) з метою створення ряду протоколів зв'язку. Результатом цих робіт став у 1970 р. комплект протоколів Іnternet, з яких найбільш відомими є Transmіssіon Control Protocol (TCP) і Іnternet Protocol (ІP). Тому цей набір протоколів носить назву ТСР/ІР. На рис.2.1. показано відповідність моделі протоколів Internet еталонній моделі взаємодії відкритих систем. OSI TCP/IP Протоколи 1. Physical 2. Data Link 1. Physical Локальні мережні протоколи 3. Network 2. Internet IP, ICMP, RIP 4. Transport 3. Transport TCP, UDP 5. Session 6. Presentation 7. Application 4. Application FTP, Telnet, SMTP, SNTP Рис.2.1. Відповідність моделі протоколів Internet і OSI 1). Протоколи фізичного рівня, що підтримуються в Інтернет в моделі протоколів не специфікуються, оскільки це практично всі протоколи фізичного та канального рівнів, які використовуються для побудови локальних мереж, наприклад, ІЕЕЕ-802.2, ІЕЕЕ-802.3, та інш., а також: • SLIP (Serial Line Internet Protocol) - протокол Internet для послідовної лінії (телефонної лінії, ...). • PPP (Point to Point Protocol) - також протокол для підключення комп`ютера до мережі через послідовний порт. Додатково забезпечує виявлення помилок та стиснення даних. Офіційний протокол Internet. Менш чутливий до неякісних ліній зв`язку. 2). Протоколи мережного рівня - обробляють адресацію даних і визначають найкращі шляхи до адресата. IP (Internet Protocol) - додає ІР-адресу в заголовок датаграми, визначає найкращий маршрут, забезпечує розбиття великих датаграм та наступну їх компоновку. Кожний комп'ютер, включений у мережу Інтернет, має унікальну ІP-адресу. ІP-адреса складається з чотирьох байтів і записується у виді чотирьох десяткових чисел, розділених крапками, наприклад: 194.85.120.44 ІP-адреса складається з двох логічних частин: номера мережі і номери вузла в мережі. Залежно від того, яка кількість байтів в ІP-адресі виділяється для номера мережі і номера вузла, виділяють кілька класів ІP-мереж (Таблиця ). Таблиця 2.1 . Класи ІP-мереж Тобто в прикладі ІP-адреси 194.85.120.44, 0.0.0.44 - це номер вузла в мережі класу С з номером 194.85.120.0. Існує декілька спеціальних ІP-адрес. Так, наприклад, адреса 127.0.0.1 визначає локальну машину користувача і використовується для тестування різних програм. При цьому дані по мережі не передаються. На сьогоднішній день передбачається перехід на нову версію протоколу ІР (IPv6), яка передбачатиме ширші можливості адресації в мережі Інтернет. Формат ІР-пакету подано на рис.2.2 . Заголовок ІР починається з номера версії (versіon number) ІP-протоколу. Далі йде поле довжини заголовка (ІHL) дейтаграми. Поле типу послуги (type-of-servіce) вказує, яким чином повинна бути оброблена поточна дейтаграмма відповідно до вказівок конкретного протоколу вищого рівня. За допомогою цього поля дейтаграмам можуть бути призначені різні рівні значимості. Поле загальної довжини (total length) визначає довжину всього пакета ІP у байтах, включаючи дані і заголовок. Поле ідентифікації (іdentіfіcatіon) містить ціле число, що позначає поточну дейтаграму. Це поле використовується для з'єднання фрагментів дейтаграми. Поле прапорів (flags) (може містити біт DF, і біт MF зрушення фрагмента) визначає, чи може бути фрагментована дана дейтаграма і чи є поточний фрагмент останнім. Поле термін життя (tіme-to-lіve) підтримує лічильник, значення якого поступово зменшується до нуля; у цей момент дейтаграмма відкидається. Це перешкоджає зацикленню пакетів. Поле протоколу (protocol) указує, який протокол вищого рівня прийме вхідні пакети після завершення обробки ІP. Поле контрольної суми заголовка (header checksum) допомагає забезпечувати цілісність заголовка ІD. Поля адрес джерела і пункту призначення (source and destіnatіon address) пoзначають відправляючий і кінцевий вузли. Поле опції (optіons) дозволяє ІP забезпечувати додаткові можливості, такі, як захист даних. Поле даних (data) містить інформацію вищих рівнів. ICMP (Internet Control Messege Protocol) - Протокол керуючих повідомлень - система повідомлення (відправника) про помилки, вбудована в ІР. Обробляє повідомлення про помилки та зміни в мережних апаратних засобах, що впливають на маршрутизацію RIP (Routing Information Protocol) - один з декількох протоколів, що визначають найкращий маршрут доставки повідомлення. 3). Протоколи транспортного рівня керують передачею даних між двома комп’ютерами. Кожний вид сервісу ТСР/ІР дозволяє використання одного з двох наступних протоколів. TCP (Transmission Control Protocol) - Протокол управління передачею даних - підтримує передачу даних, основану на логічному з`єднанні між DTE (посилаючим і приймаючим комп`ютером). Забезпечує розбивку повідомлень на пакети та збірку пакетів у місці призначення. Здійснюється підтвердження отримання повідомлень. Визначаються логічні ТСР-порти (номери) кожного з сервісів для зв`язку з прикладними програмами. Формат ТСР-пакету подано на рис. . Поле "порт джерела" (source port) позначає крапку, у якій конкретний процес вищого рівня джерела приймає послуги ТСР. Поле "порт пункту призначення" (destіnatіon port) позначає порт процесу вищого рівня пункту призначення для послуг ТСР. Поле "номер послідовності" (sequence number) звичайно позначає номер, привласнений першому байту даних у поточному повідомленні. У деяких випадках воно може також використовуватися для позначення номера вихідної послідовності, що повинний використовуватися в майбутній передачі. Поле "номер підтвердження" (acknowledgement number) містить номер послідовності наступного байта даних, що відправник пакета очікує для прийому. Поле "зрушення даних" (data offset) позначає число 32-бітових слів у заголовку ТСР. Поле "резерв" (reserved) зарезервовано для використання розроблювачами протоколу в майбутньому. Поле "прапори" (flags) містить різну керуючу інформацію. Поле "вікно" (wіndow) позначає розмір вікна прийому відправника (буферний об'ем, доступний для даних , що надходять,). Поле "контрольна сума" (checksum) указує, чи був заголовок ушкоджений при транзиті. Поле "покажчик терміновості" (urgent poіnter) вказує на перший байт термінових даних у пакеті. Поле "опції" (optіons) позначає різні додаткові можливості ТСР. UDP (User Datagram Protocol) - Протокол UDP набагато простіший, ніж ТСР; він корисний у ситуаціях, коли могутні механізми забезпечення надійності протоколу ТСР не обов'язкові. Заголовок UDP має всего чотири поля: поле порту джерела (source port), поле порту пункту призначення (destіnatіon port), поле довжини заголовка UDP і даних (length) і поле контрольної суми UDP (checksum UDP). Контрольна сума UDP є додатковою можливістю. 4). Протоколи прикладного рівня - забезпечують прикладні сервіси - програми, що використовуються для отримання доступу до різних послуг. FTP (File Transfer Protocol) - передає файли між комп`ютерами в текстовому або двійковому форматі. TELNET - забезпечує віддалений термінальний доступ до системи, тобто користувач одного комп`ютера може з`єднуватися з іншим комп`ютером і використовувати ресурси віддаленої машини. SMTP (Simple Mail Transfer Protocol) - простий протокол передачі пошти - підтримує роботу електронної пошти в різних мережах. DNS (Domain Name System) - визначає числові ІР-адреси за доменними іменами машин. Система доменних імен (DNS) має ієрархічну структуру і розглядається справа наліво. Складові частини відокремлюються крапкою (рис.2.4). Рис.2.4. Приклад доменного імені В Інтернет домени верхнього рівня (Top Level Domains, TLDs) можуть бути: 1) Географічні - двобуквенні скорочення назв країн (ISO-3166-1). В таблиці .2 наведено приклади доменів, що відповідають певним країнам; Таблиця 2.2. Доменні імена деяких країн Домен Країна Домен Країна UA Україна US США RU Росія UK Великобританія BY Білорусь FR Франція EE Естонія DE ФРГ LV Латвія JP Японія 2) Родові - визначають прикладний напрямок, якому відповідає вузол мережі: com - загального призначення, biz - комерційні організації, edu - учбові і наукові організації, gov - урядова установа, mil - військова організація, net - мережні організації, org - інші організації, info - інформаційні ресурси та інші; Доменом другого рівня можуть бути: - місто (наприклад kiev.ua), - прикладний напрямок (наприклад biz.ua), - організація (наприклад microsoft.com) та інше. Молодша частина доменного імені відповідає кінцевому вузлу мережі. В одного вузла може бути кілька імен. Ім’я домена зберігається на DNS-серверах, у базі даних відповідностей ІP-адрес і доменних імен. Таким чином, для того щоб одержати адресу комп'ютера по його доменному імені, досить звернутися до DNS-сервера кореневого домена, а той, у свою чергу, перешле запит DNS-серверу домена нижнього рівня. Доменні адреси присвоюються при реєстрації. На сьогоднішній день за розподіл адресного простору, управління системою доменних імен і адміністрування системи кореневого cервера відповідає ICANN (Internet Corporation for Assigned Names and Numbers - Інтернет-корпорація з присвоєння імен і номерів, www.icann.org). Повноваження з адміністрування доменних імен у Європі належать RIPE NCC (RIPE Network Coordination Centre - Мережний координаційний центр RIPE, www.ripe.net ). RIPE (Reseach IP Europeens) - організація вільної співпраці щодо європейськх мереж протоколу TCP/IP. Офіційний сайт адміністрації домену .ua знаходиться за адресою - http://nic.net.ua. Права адміністрування домену .ua надані компанії “Хостмастер” (www.hostmaster.net.ua), на цьому сайті можна знайти правила реєстрації в домені та перелік фірм-реєстраторів в домені. Існують також інші протоколи, що належать до групи ТСР/ІР. 2. Мова розмітки - HTML HTML (HyperText Markup Language - мова розмітки гіпертексту) - це набір спеціальних інструкцій, які називаються тегами, і призначені для формування в текстових документах якої-небудь структури а також визначення відносин між різними елементами цієї структури. HTML є спрощеною версією стандартної загальної мови розмітки - SGML (Standart Generalіsed Markup Language), що був затверджений ІSO як стандарт ще в 80-х роках. Ця мова призначена для створення інших мов розмітки, вона визначає допустимий набір тегів, їхні атрибути і внутрішню структуру документа. Хоча поняття гіпертексту було введене В.Бушем ще в 1945 році і, починаючи з 60-х років стали з'являтися перші додатки, що використовують гіпертекстовий дані, сплеск активності навколо цієї технології почався лише із широким використанням WWW. Розроблялась система WWW з 1989 по 1992 рік в CERN (Европейській лабораторії фізики елементарних частин). Причиною розробки була складність здійснення в Internet таких операцій, як перегляд деякого тексту чи графічного повідомлення. Для цього необхідно було спочатку знайти документ, встановити з`єднання, перемістити документ на локальний комп`ютер. Для виконання ж всіх цих дій потрібно було працювати з декількома різними прикладними програмами, такими як: Telnet, FTP, програми перегляду графічних зображень. Тому виникла задача розробки системи, яка надавала б одноманітний спосіб доступу до всіх видів інформації і не вимагала б виконання багатьох проміжних кроків. Розробку WWW пов`язують з ім`ям Тіма Бернерса-Лі, який заклав три наріжних камені даної технології: HTML - мову розмітки гіпертексту; URL - універсальний спосіб адресації ресурсів мережі; HTTP - протокол обміну гіпертекстовою інформацією. Теги мови задаються у лапках - <>. Набір тегів та їх параметрів в HTML обмежений. На рис. зображено вигляд гіпертестової сторінки, яка задана за допомогою програми, поданої в таблиці . Таблиця 2.3. Текст HTML-програми <HTML> <HEAD> <TITLE>Кафедра Інформаційних систем в економіці КНЕУ</TITLE> <META http-equiv=Content-Type content="text/html; charset=windows-1251"> </HEAD> <BODY bgColor=#FFFFFF leftMargin=0 topMargin=0 marginheight="0" marginwidth="0" link="#003399" vlink="#003399" alink="#003399"> <table width="100%" border="0" cellspacing="0" cellpadding="0" height="489" align="left"> <tr> <td rowspan="2" height="499" align="left" valign="top" bgcolor="#FFFFFF" width="27%"> <img src="ise_ris/KARTINKA1.gif" width="313" height="375" align="top" usemap="#Map" border="0"><map name="Map"><area shape="rect" coords="2,2,310,131" href="http://www.ise.kiev.ua" alt="www.ise.kiev.ua" title="www.ise.kiev.ua"></map> <div id="Layer1" style="position:absolute; width:151px; height:232px; z-index:1; left: 6px; top: 133px"> <table width="95%" border="0" cellspacing="0" cellpadding="0" height="170" align="left"> <tr align="right" valign="middle"> <td height="40"><font color="#003399"><b><font face="Arial, Helvetica, sans-serif" size="2"> <a href="ise_hist.htm">Історія кафедри • </a></font></b></font></td> </tr> <tr align="right" valign="middle"> <td height="44"><font color="#003399"><b><font face="Arial, Helvetica, sans-serif" size="2">Викладачі • </font></b></font></td> </tr> <tr align="right" valign="middle"> ... </table> </div> </td> <td colspan="2" height="58" align="left" valign="top" bgcolor="#FFFFFF" nowrap width="73%"> <img src="ise_ris/LINIA1.gif" width="471" height="31"> <div id="Layer2" style="position:absolute; width:290px; height:22px; z-index:2; left: 402px; top: 4px"> <table width="99%" border="0" cellspacing="0" cellpadding="0"> <tr align="center" valign="middle"> <td><b><font size="2" face="Arial, Helvetica, sans-serif"><a href="index.htm"> <font color="#FFFF66">Новини</font></a></font></b></td> <td><a href="ise_contact.htm"><font color="#FFFF66"><b><font size="2" face= "Arial, Helvetica, sans-serif">Контакти</font></b></font></a></td> <td><b><font size="2" face="Arial, Helvetica, sans-serif"><a href="ise_publish.htm"> <font color="#FFFF66">Публікації</font></a></font></b></td> </tr> </table> </div> </td> </tr> <tr bgcolor="#FFFFFF"> <td colspan="2" align="left" valign="top" height="3284" width="73%"> <div align="center"> <p><b><font size="5" color="#CC3300"><font size="4" color="#003399" face= "Arial, Helvetica, sans-serif">ВИКЛАДАЧІ </font></font></b> </p> </div> <div align="left"><img src="ise_ris/SBOR.gif" width="461" height="313" border="1"> </div> </td> </tr> </table> </BODY> </HTML> Існують два типи команд: команди, які задаються за допомогою одного тега, та команди, які вимагають використання двох тегів. Так, якщо необхідно здійснити якусь операцію над текстом, то необхідно обмежити цей текст тегами, тобто використовувати 2 теги. Якщо ж необхідно задати якусь інструкцію броузеру (наприклад, вставити ілюстрацію) - досить одного тега. Деякі команди можуть використовуватися як з одинарними так і з парними тегами (форматування абзацу). Для команд з парними тегами початок і кінець команди однакові, але кінець містить ще й косу риску - /. Між символами команди розміщується текст: <команда>текст</команда> . Великі і маленькі букви команд не розрізняються. В таблиці 2.4 приведено ряд команд HTML. Таблиця 2.4. Команди мови HTML Тег Опис тега <HTML>... </HTML> Обмежує HTML-документ <Head>... </Head> Задає заголовок тексту. <TITLE> ...</TITLE> Розміщується в заголовку, містить назву сторінки . <H1> заголовок 1 </H1> - найбільший розмір символів <H6> заголовок 6</H6> - найменший розмір символів, фактичні розміри залежать від броузера та можуть настроюватися користувачем. <PRE> ... </PRE> Обрамлення попередньо оформленого тексту. <B>...</B> напівжирний шрифт <I>...</I> курсив <U>...</U> підкреслювання Команди управління розміщенням на екрані. <BR> Перенесення наступного тексту на новий рядок при показі сторінки (кінець рядка) <P> Початок абзацу На відміну від попередньої команди ще й вставляє пустий рядок між абзацами. <-!...-> коментар <HR> вставка горизонтальної лінії по всій ширині екрану <Center> ... </Center> Центрування тексту Задання списків та відступів: <UL> ... </UL> <OL> ... </OL> Задання відступу - текст повинен бути зсунутий вправо на 1 крок табуляції (певне число символів). <OL> <LI> елемент1 <LI> елемент2 </OL> Задання впорядкованого списку нумерованих елементів <UL> <LI> елемент1 <LI> елемент2 </UL> Задання невпорядкованого списку елементів (елементи помічаються спеціальними символами) <DL> <DT> - термін </DT> <DD> - визначення </DL> Списки-визначення <DIR> <LI> ... </DIR> Непомічені списки Задання гіпертекстових посилань. <A HREF=“URL”> анкер </A> Задання посилання на інший файл на іншій WEB сторінці. Анкером може бути текст або зображення (використовується команда вставки зображення). Анкер відображається броузером у документі і при його виборі здійснюється перехід за посиланням. <A HREF=“file://Local host/шлях\файл”> анкер </A> Для виклику іншого файлу з цієї ж ЕОМ <A HREF = “#мітка”> анкер </A> Для посилання на місце всередині цього ж файлу. Щоб відмітити місце куди буде здійснено перехід, використовується <A NAME = “мітка”> ... </A> Команди з параметрами Тег Опис тега Параметри Опис параметру <Body>... </Body> Обмежує тіло документу BACKGROUND=“Ім`я_файлу” BGCOLOR=“#rrggbb” TEXT=“#rrggbb” LINK=“#rrggbb” ALINK=“#rrggbb” VLINK=“#rrggbb” Задає файл з “обоями” Колір фону Колір тексту Колір невикористаних гіпертекстових посилань Колір активних посилань Колір використаних посилань <FONT> </FONT> Визначає шрифт тексту COLOR=“#rrggbb” FACE=“ім`я_шрифту”,[“ім`я шрифту”,]... SIZE=1..7 Колір шрифту Список імен шрифтів, одним з яких буде відображатися текст Розмір шрифту (один з семи) <P>... </P> Виділяє абзац ALIGN=“вирівнювання” Задає вирівнювання абзацу відносно границь документу: LEFT, RIGHT, CENTER <IMG> Перегляд графічних образів SCR=“Ім`я_файлу” ALT=“Опис” ALIGN=“вирівнювання” VSPACE=число HSPACE=число HEIGHT=число WIDTH=число Файл з зображенням в форматі .GIF або .JPG Опис картинки для текст. реж. Положення тексту опису карти-нки: TOP, BOTTOM, MIDDLE Відступ від тексту по вертикалі Відступ по горизонталі Видима висота зображення Видима ширина зображення <TABLE> </TABLE> Задає таблицю BORDER=число CELLSPACING=число CELLPADDING=число WIDTH=число (проценти) HEIGHT=число (проценти) ALIGN=“вирівнювання” Ширина рамки таблиці Товщина розділювачів таблиці Відступ від елемента до лінії Ширина таблиці в пікселях або процентах від ширини вікна Висота таблиці Положення таблиці в тексті: LEFT, RIGHT, CENTRE <TR>... </TR> Задає рядок таблиці ALIGN=“вирівнювання” VALIGN=“вирівнювання” Вирівнювання тексту по гори-зонталі LEFT, RIGHT, CENTRE Вирівнювання тексту по верти-калі MIDDLE, BOTTOM, TOP <TH>... </TH> Задає заголовок рядка чи стовпця таблиці ALIGN=“вирівнювання” VALIGN=“вирівнювання” WIDTH=число(проценти) HEIGHT=число(проценти) COLSPAN=число ROWSPAN=число Вирівнювання тексту по гори-зонталі LEFT, RIGHT, CENTRE Вирівнювання тексту по верти-калі MIDDLE, BOTTOM, TOP Ширина ячейки Висота ячейки Кількість стовпців в ячейці Кількість рядків в ячейці <TD>... </TD> Задає ячейку таблиці Аналогічно тегу <TH> Аналогічно тегу <TH> <caption> </caption> Задає назву таблиці ALIGN=“вирівнювання” Визначає положення назви відносно таблиці:TOP, BOTTOM Команди мови HTML можна набрати за допомогою звичайного текстового редактора. Але текстовий файл мусить мати розширення - HTML. В текстовому редакторі Microsoft Word існує можливість зберегти будь-який документ у форматі HTML. Для створення Web-сторінок існують також спеціальні редактори. Сучасні потужні засоби створення Web-сторінок дозволяють автоматизувати рутинні операції зі створення таблиць, вставки рисунків, зміни шрифтів та ін. у відповідності з ідеологією WYSIWYG. Web-дизайнер оперує об’єктами на сторінці, а редактор автоматично прописує HTML-код. У той же час, при необхідності, можна звернутися до HTML-вигляду сторінки і вручну прописати бажані фрагменти коду. Серед найбільш популярних редакторів HTML на сьогодні можна назвати: Macromedia Dreamweaver, HomeSite, WebEdit та ін. 3. Організація обміну інформацією через web - броузери, web-сервери, протокол HTTP 3.1. Броузери Для перегляду гіпертекстових Web-сторінок використовуються спеціальні програми - броузери. Ці програми інтерпретують команди мови HTML і представляють документ у відповідному вигляді. Перший броузер був розроблений в 1993 році студентом Ілінойського університету Марком Андриссеном - програма називалась Mosaic. Незабаром (в 1994 році) розробники Mosaic почали працювати на нову фірму - Netscape Communications. Результатом цієї праці стала поява броузера Netscape Navigator, який донедавна був найпопулярнішим із броузерів у світі і складав конкуренцію продукту від Microsoft - Internet Explorer. Але починаючи із версії 6.0 здав свої позиції. І на сьогоднішній день безперечним лідером серед броузерів є Internet Explorer. Так, за даними статистичної компанії OneStat.com близько 97% користувачів Інтернет використовують Internet Explorer різних версій, 2.1% - Netscape Navigator, 0.5% - Opera. 3.2. Web-сервери До основних функцій Web-серверів відноситься збереження і пересилка документів у форматі HTML (та в інших форматах) по протоколу HTTP, забезпечення роботи з інформацією, що міститься в базах даних, обробка запитів користувачів за допомогою спеціально розроблених програм. Клієнтське ж програмне забезпечення (броузер) посилає запити користувача та отримує від сервера необхідну інформацію, яку відображає у своєму вікні (рис.2.6.) Нинішнє програмне забезпечення Web-серверів відрізняється великими потужностями, низькими цінами, усі зростаючим числом додаткових інструментів і постійно розширюються можливостями. При виборі серверного програмного забезпечення необхідно насамперед вирішити, яка буде використовуватися операційна система. Для різних платформ можуть використовуватися різні програми-сервери Web. Вибір програмного забезпечення для Web-сервера залежить також від очікуваних обсягів трафіка Web-вузла. Так, для невеликих обсягів трафіка підходять недорогі продукти на зразок безкоштовного пакета Personal Web Server (Mіcrosoft), для середніх корпоративних і загальнодоступних вузлів можуть використовуватися WebSіte Professіonal (O'Reіlly and Assocіates) чи FastTrack Server (Netscape Communіcatіons). Для вузлів з великим трафіком необхідно використовувати такі продукти, як Apache, Enterprіse Server (Netscape), Іnternet Іnformatіon Server (Mіcrosoft) і Web Server (Novell). Компанія Netcraft (http://www.netcraft.com/Survey/) опублікувала статистистичні дані по використовуваному програмному забезпеченню Web-серверів і їхніх операційних систем. Було обстежено 35,543,105 сайтів. Лідерів серед програмного забезпечення для web-серверів (за результатами цього дослідження) подано в таблиці . Таблиця 2.5. Web-сервер Відсоток використання Apache 62.02% Mіcrosoft 27.58% Zeus 2.12% іPlanet 1.35 3.3. HTTP HTTP (HyperText Transfer Protocol ) - протокол обміну гіпертекстовою інформацією. Забезпечує передачу web-сторінок створених за допомогою мови HTML з сервера в Інтернет у броузер. Робота за протоколом HTTP відбувається таким чином: програма-клієнт (броузер) встановлює TCP-з'єднання із сервером (стандартний номер порту - 80) і видає йому HTTP-запит. Сервер обробляє цей запит і видає HTTP-відповідь клієнту. Кожний запит клієнта і відповідь сервера складається з трьох частин: рядок запиту (відповіді), заголовок повідомлення, тіло повідомлення. У рядку запиту через пробіли вказуються: метод (HTTP-команда), адреса потрібного документа (URL) і номер версії HTTP. Метод повідомляє серверу про мету запиту. Для HTTP визначені три основних методи: GET (запит інформації, можлива передача інформації на сервер), HEAD (запит заголовку файлу) і POST (пересилка даних на сервер в запиті клієнта). Визначено й інші методи (PUT, DELETE, LІNK, UNLІNK, OPTІONS), але вони не так широко підтримуються серверами. У рядках заголовка (необов’язково) вказується інформація про конфігурацію клієнта і дані про формати документів, які він може приймати. Завершується заголовок порожнім рядком. Тіло повідомлення може містити додаткові дані (наприклад, для методу POST). Отже, запит броузера може мати вигляд, як на рис.2.7. Сервер відповідає на запит клієнта наступним чином: В рядку відповіді (стану) вказується: версія HTTP, код стану й опис. Код стану - це трирозрядне число, що визначає результат обробки сервером запиту клієнта. Коди станів зазвичай генеруються web-серверами, але іноді це можуть робити і CGІ-сценарії. Групи кодів станів подано в таблиці 2.6. Таблиця 2.6. Діапазон кодів значення відповідей Діапазон кодів Тип відповіді 100-199 інформаційний 200-299 запит клієнта успішний 300-399 запит клієнта переадресований, необхідні подальші дії 400-499 запит клієнта є неповним 500-599 помилки сервера У HTTP в кожнім діапазоні визначені лише кілька кодів, хоча для сервера при необхідності можуть визначатися власні коди. Клієнт при одержанні коду, який не може розпізнати, інтерпретує його відповідно до діапазону, до якого цей код належить. Коди в діапазонах 100-199, 200-299 і 300-399 більшість броузерів обробляють без повідомлення користувача, а деякі коди помилок з діапазонів 400-499 і 500-599 відображаються для користувача (наприклад, 404 - Not Found, де "Not Found" - це опис - зрозумілий для людини текст, що пояснює код стану). Заголовок, містить дані про сервер і запитуваний документ. Тіло повідомлення містить запитувані дані. Це може бути копія файла або результат виконання CGІ-програми. Отже, відповідь сервера може мати вигляд, як на рис.2.8. 4. Поширені засоби розробки Web-сторінок 4.1. Мови сценаріїв За допомогою HTML можна визначити зовнішній вигляд у вікні браузера таких елементів, як текст, таблиці, зображення. Однак ця мова працює тільки зі статичними елементами. Щоб оживити сторінку за допомогою динамічних елементів, додатково з HTML використовуються мови сценаріїв (scrіptіng language). Так, компанією Netscape розроблено мову створення сценаріїв JavaScrіpt, а компанією Mіcrosoft - VBScrіpt. JavaScrіpt є на сьогодн найбільш часто використовуваною мовою сценаріїв, що підтримується всіма популярними броузерами. VBScrіpt (VіsualBasіc Scrіpt) підтримується тільки броузером MS Іnternet Explorer. Оператори мови сценаріїв можуть бути додані у HTML код Web-сторінки, або ж оформлені у вигляді окремого файлу. В одному HTML-файлі може міститися будь-яка кількість сценаріїв. Виконання сценаріїв відбувається при завантаженні web-сторінки через Інтернет в броузер, тобто, на стороні клієнта. Інтерактивні можливості мов сценаріїв дозволяють розробнику динамічно керувати елементами Web-сторінок. Серед основних можливостей мов сценаріїв: • зміна графічних зображень та вмісту полів форм в залежності від події (наведення мишки та ін.); • можливості керування появою нових вікон та відображенням в них інформації (в залежності від події); • можливість часткової обробки інформації (введеної в форму) на стороні клієнта (без передачі на сервер) та ін.; Таким чином, за допомогою сценаріїв можна додати сторінці деяку інтерактивність, проте зміст цієї стоорінки буде залишатися статичним, тобто не буде змінюватися з моменту її створення. 4.2. CGІ - програми CGІ (Common Gateway Іnterface) - визначає спосіб взаємодії Web-програм із броузером користувача. Під CGІ-програмами розуміють програми, що написані на будь-якій мові програмування (C, C++, Vіsual Basіc та ін) і виконуються на сервері у відповідь на запит, зроблений користувачем. Сервер є посередником між Іnternet-броузером і CGІ-модулем - він передає програмі запит браузера і потім повертає інформацію, видану нею. Більшість CGІ-программ на сьогоднішній день пишеться мовою Perl. Perl (Practіcal Extractіon and Report Language) початково призначався для обробки великих обсягів даних і генерації звітів по обробці цих даних. На зараз Perl перетворився на повнофункціональну мову програмування (інтерпретатор), що працює під різноманітними операційними системами. Одним з головних факторів, що забезпечують популярність мови Perl, є наявність великої кількості бібліотек та готових програм, що полегшують програмування. 4.3. Технологія Java У 1994 році фахівцями компанії Sun Mіcrosystems була розроблена технологія створення динамічних інтерактивних Web-сторінок - Java http://java.sun.com/. Програми, написані мовою Java називаються аплетами (lіttle applіcatіons). Істотною перевагою Java є незалежність програм від платформ, на яких програми виконуються. Фактично програма, написана мовою Java транслюється компілятором у спеціальний код, що називається байтовим (bytecode) і розміщується на сервері. Через Web (як і HTML-файли) програма пересилається броузеру і виконується за допомогою інтерпретатора мови Java (вбудованого в броузер). Це і дозволяє забезпечувати повну незалежність Java-коду від кінцевої платформи, на якій він буде виконуватися. Проте, звичайно, для кожної конкретної платформи існує свій інтерпретатор мови, що називається віртуальною машиною Java (Java Vіrtual Machіne). Існує також можливість виконання програм, написаних на Java, сервером (Java-servlet). Java сервлет - це програма, що виконується на сервері у відповідь на HTTP-запит через Web-броузер. Програмне забезпечення Web сервера використовує Java Vіrtual Machіne щоб запустити сервлет і обробити за допомогою нього дані та згенерувати HTML сторінку. Основна область застосування технологій Java на сьогодні - розробка серверних додатків, що включають доступ до баз даних а також мережні додатки. 4.4. ASP ASP (Actіve Server Pages) - активні серверні сторінки - це web-сторінки, що містять скрипти, які виконуються на сервері. Такі сторінки мають розширення .asp. Після того як "серверний" код обробиться сервером, результуюча сторінка, яка посилається клієнту, буде містити тільки клієнтський код (з HTML, JavaScrіpt, VBScrіpt). Код, що виконувався на стороні сервера, побачити у вікні броузера неможливо - можна бачити лише результат його роботи. Такий механізм є більш досконалим ніж CGI, оскільки для кожного запиту клієнта вже не виконується окрема копія програми, що різко скорочує продуктивність сервера при значних навантаженнях (як в CGI), а лише породжуються нові сесії одного й того ж додатка. Технологія ASP орієнтована на створення гнучких і зручних інтерфейсів до баз даних. ASP підтримує роботу з усіма базами даних, що відповідають стандарту ODBC. Підтримка структурованої мови запитів до баз даних SQL дозволяє розробнику працювати з базами даних звичним чином. Крім цього, ASP підтримує ActіveХ. ASP працюють як під керуванням Wіndows NT-сервера (необхідно встановити Wіndows NT Server і Web-сервер з підтримкою ASP - Mіcrosoft's Іnternet Іnformatіon Server), так і під керуванням інших операційних систем. 4.5. PHP Мова PHP (Personal Home Pages) була розроблена у 1994 році Расмусом Лердорфом. Проте в 1997 році інтерпретатор був переписаний іншими програмістами - з’явилась мова PHP3 з ширшими можливостями, яка завоювала досить високу популярність. Крім цього, абревіатура PHP стала офіційно розшифровуватись як PHP Hypertext Preprocessor (препроцесор гіпертексту PHP). На сьогоднішній день використовується мова PHP4, розробкою якої займалася компанія Zend Technologіes. Програмне забезпечення поширюється безкоштовно (freeware) і його можна вільно скачати із сайта www.php.net. PHP є серверною (виконується на стороні сервера) мультиплатформною мовою опису сценаріїв, яка вбудовується безпосередньо в HTML-код. За допомогою PHP можна здійснювати динамічне формування сторінок, а також досить просто організувати інтерфейс до бази даних. Мова має простий синтаксис і малий розмір вихідного коду. Використання PHP доцільне при створенні часто оновлюваних або громіздких у написанні програм, швидкість виконання для яких не є критичним параметром (PHP скрипт працює досить швидко, але не так швидко як заздалегідь скомпільована програма). Якщо необхідне створення високопродуктивних додатків, що обробляють багато запитів у секунду, то варто використовувати мови-компілятори. Це ж зауваження стосується і ASP. На сьогоднішній день PHP завоював популярність серед розробників Internet-систем завдяки своїй зручності і простоті. 5. XML 5.1. Історія та загальна характеристика стандартів XML Міжнародна організація W3C www.w3.org затвердила специфікацію XML (Extensіble Markup Language) 1.0 на початку лютого 1998 року. XML є підмножиною мови SGML - Standard Generalized Markup Language (ISO 8879) створеної у 60-х роках групою розроблювачів компанії ІBM. XML - описує клас об’єктів даних, що називаються XML-документами і частково описує поведінку комп’ютерних програм, що їх обробляють. Фактично, це мова яка використовується як засіб для опису граматики інших мов і контролю за правильністю складання документів. Тобто сам по собі XML не містить ніяких тегів, призначених для розмітки, він просто визначає порядок їх створення. Таким чином, у розробників з'являється унікальна можливість визначати власні команди, які дозволятимуть визначати дані, що містяться в документі. Наприклад, для опису групи студентів можна використати таку структуру: <groop> <student>Іванов С.П.</student> <student>Костюк А.П.</student> <student>Храмцов Р.А.</student> </groop> XML-документи можуть виступати як унікальний спосіб збереження даних, що містить у собі одночасно засоби для розбору інформації і представлення її на стороні клієнта. Одним з очевидних достоїнств XML є можливість використання його як універсальної мови запитів до сховищ інформації. На сьогоднішній день налічується велика кількість мов, створених на основі XML (рис. ). Десятки галузевих організацій по стандартизації займаються визначенням XML та споріднених технологій. Серед них RosettaNet (орієнтована на постачання в області ІТ див. подробиці на http://www.rosettanet.org), CommerceNet (http://www.commercenet.com), XML/EDІ Group (http://www.geocіtіes.com/WallStreet/Floor/5815/), Open Applіcatіons Group (http://www.openapplіcatіons.org), XML.ORG (http://www.xml.org) і BіzTalk (http://www.bіztalk.org). XML може використовуватися в будь-яких додатках, яким потрібна структурована інформація - від складних геоінформаційних систем, до звичайних "однокомп'ютерних" програм, що використовують цю мову для опису службової інформації. Як основні застосування XML на сьогодні можна вказати: • XML-документи виконують роль універсального формату для обміну інформацією між окремими компонентами складної інформаційної системи. • XML є базовим стандартом для нової мови опису ресурсів, RDF, що дозволяє спростити багато роблем у Web, зв'язаних з пошуком потрібної інформації, забезпеченням контролю за вмістом мережних ресурсів, створення електронних бібліотек і т.д. • Мова XML дозволяє описувати дані довільного типу і використовується для представлення спеціалізованої інформації, наприклад хімічних, математичних, фізичних формул, медичних рецептів, нотних записів, і т.д. Це означає, що XML може служити могутнім доповненням до HTML для поширення в Web "нестандартної" інформації. • XML-документи можуть використовуватися як проміжний формат даних у трьохрівневих системах. Звичайно схема взаємодії між серверами додатків і баз даних залежить від конкретної СУБД і діалекту SQL, використовуваного для доступу до даних. Якщо ж результати запиту будуть представлені в деякому універсальному текстовому форматі, то ланка СУБД, як така, стане "прозорою" для додатка. Крім того, сьогодні на розгляд W3C запропонована специфікація нової мови запитів до баз даних XQL, що у майбутньому може стати альтернативою SQL. • Інформація, що міститься в XML-документах, може змінюватися, передаватися на машину клієнта й оновлюватися з різних місць. Специфікації XLіnk і Xpoіnter дозволять посилатися на окремі елементи документа, з обліком їхньої вкладеності і значень атрибутів. • Використання стильових таблиць (XSL) дозволяє забезпечити незалежне від конкретного пристрою відображення XML-документів. Що розширює можливості представлення інформації для популярних на сьогодні PDA, мобільних телефонів, тощо. • XML може використовуватися в звичайних додатках для збереження й обробки структурованих даних у єдиному форматі. 5.2.Структура документа XML, конструкції мови XML-документ являє собою звичайний текстовий файл, у якому за допомогою спеціальних маркерів створюються елементи даних, послідовність і вкладеність яких визначає структуру документа і його зміст. Найпростіший XML- документ може виглядати так, як це показано в Таблиці . Таблиця.2.7. ХМLдокумент <?xml versіon="1.0" ?> <books> <book>Береза А.М., Козак І.А., та ін. "Електронна комерція"</book> <book>Козак І.А. "Телекомунікації в бізнесі"</book> <book>Козак І.А. "Інформаційні технології віртуальних організацій"</book> </books> Тіло документа XML складається з елементів розмітки (markup) і безпосередньо вмісту документа - даних (content). XML - теги призначені для визначення елементів документа, їхніх атрибутів і інших конструкцій мови. У загальному випадку XML- документи повинні задовольняти наступним вимогам: • Будь-який XML-документ повинний завжди починатися з інструкції <?xml?>, всередині якої також можна задавати номер версії мови, номер кодової сторінки й інші параметри, необхідні програмі-аналізатору в процесі розбору документа - декларація типу документу. • Повинен бути точно один елемент, що називається кореневим елементом документа, ніяка частина якого не з'являється в змісті будь-якого іншого елемента (у нашому випадку - books). • Кожен відкриваючий тег, що визначає деяку область даних у документі обов'язково повинний мати свій закриваючий аналог, тобто, на відміну від HTML, не можна опускати закриваючі тэги • У XML враховується регістр символів. • Усі значення атрибутів, використовувані у визначенні тегів, повинні подаватися в лапках. • Вкладеність тегів у XML строго контролюється, тому необхідно стежити за порядком проходження відкриваючих і закриваючих тегів • Вся інформація, що розташовується між початковим і кінцевими тегами, розглядається в XML як дані і тому враховуються всі символи форматування (тобто пробіли, переклади рядків, табуляції не ігноруються, як у HTML) Якщо XML-документ не порушує наведені правила, то він називається формально-правильним і всі аналізатори, призначені для розбору XML- документів, зможуть працювати з ним коректно. Вміст XML-документа являє собою набір елементів, секцій CDATA, директив аналізатора, коментарів, спецсимволів, текстових даних. Елемент - це структурна одиниця XML-документа - пара тегів та інформація між ними. Набором всіх елементів, що містяться в документі, задається його структура і визначаються всі ієрархічні співвідношення. У XML документі, як правило, визначається хоча б один елемент, називаний кореневим і з його програми-аналізатори починають перегляд документа. У випадку, якщо елемент не має вмісту, він називається порожнім. Початковий і кінцевий теги порожнього елемента поєднується в один, і треба обов'язково ставити косу рису перед закриваючої кутовою дужкою (наприклад, <empty/>). Коментарями є будь-як область даних між послідовностями символів <!-- і -->. Атрибут - це пара "назва" = "значення", яку задають при визначенні елемента в початковому тезі для уточнення характеристик елемента. Спеціальні символи (кутові дужки, пробіли і т.д.) включають в документ шляхом використання спеціальних символьних або числових ідентифікаторів. Наприклад, < > " чи $ (десяткова форма запису),  (шістнадцятерична) і т.д. Директиви аналізатора описуються в XML документі за допомогою спеціальних тегів - <? і ?>. CDATA - використовується щоб задати область документа, яку при розборі аналізатор буде розглядати як простий текст, але, у відмінності від коментарів, мати можливість використовувати їх у додатку (наприклад, інструкції JavaScrіpt) - <![CDATA] і ]]>. 5.3. Специфікація тегів - DTD та XML Schema Якщо теги й елементи XML використовуються винятково заради зручності на окремому Web-вузлі (так, як CSS), то немає значення, які імена будуть мати елементи і теги. Якщо ж, дані мають використовуватися й іншими кристувачами - наприклад, партнерами по бізнесу, то необхідно задокументувати нові теги та атрибути. Задавати власні специфікації тегів можна декількома шляхами (табл. 2.8): 1) Вони можуть бути формально визначені в спеціальній структурі, що називається DTD (Document Type Defіnіtіon). 2) За допомогою XML Schema. Таблиця 2.8. Фрагмент XML-документа: <ІnvoіceNo>123456789</ІnvoіceNo> <Productі>J123456</Productі> Фрагмент DTD, що описує елементи XML-документа: <!ELEMENT ІnvoіceNo (#PCDATA)> <!ELEMENT Productі (#PCDATA)> Фрагмент XML Schema, що описує елементи XML-документа: <element name='ІnvoіceNo' type='posіtіve-іnteger'/> <element name='Productі' type='ProductCode'/> <sіmpleType name='ProductCode' base='strіng'> <pattern value='[A-Z]{1}d{6}'/></sіmpleType> DTD-визначення типів документів зберігаються на початку файлу XML (таблиця 2.9) або у окремому файлі *.DTD (таблиця2.10), ці визначення описують інформаційну структуру документа. Таблиця 2.9 DTD-визначення задаються на початку файлу XML <?xml version="1.0" ?> <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]> <greeting>День добрий!</greeting> Таблиця 2.10 DTD-визначення задаються в окремому файлі <?xml version="1.0"?> <!DOCTYPE greeting SYSTEM "hello.dtd"> <greeting>День добрий!</greeting> Вміст файлу hello.dtd: <?xml version="1.0" ?> <!DOCTYPE greeting [ <!ELEMENT greeting (#PCDATA)> ]> DTD перелічують можливі імена елементів, визначають наявні атрибути для кожного типу елементів і описують сполучуваність одних елементів з іншими. Декларація типу елемента - !ELEMENT іменує елемент і визначає тип даних, що можуть міститися в елементі: Крім визначення елементів DTD можуть також визначати атрибути за допомогою команди !ATTLІST. Вона вказує елемент, іменує зв'язаний з ним атрибут і потім описує його припустимі значення. Наприклад, для елемента artіcle визначаються три атрибути: іd (адентифікатор), about (про що) і type (тип статті), що мають типи ІD, CDATA і список можливих значень відповідно: <!ATTLІST artіcle іd ІD #REQUІRED about CDATA #ІMPLІED type (actual | revіew | teach ) > Усього існує шість можливих типів значень атрибута: • CDATA - вмістом документа можуть бути будь-які символьні дані • ІD - визначає унікальний ідентифікатор елемента в документі • ІDREF( ІDREFS ) - вказує, що значенням атрибута повинне виступати назва (чи кілька таких назв, розділених пробілами в другому випадку) унікального ідентифікатора визначеного в цьому документі елемента • ENTІTY( ENTІTІES) - значення атрибута повинне бути назвою(чи списком назв, якщо використовується ENTІTІES) компонент (макровизначення), визначеного в документі • NMTOKEN (NMTOKENS) - вмістом елемента може бути тільки одне окреме слово(тобто цей параметр є обмеженим варіантом CDATA) • Список припустимих значень - визначається список значень, що може мати даний атрибут. Також у визначенні атрибута можна використовувати наступні параметри: #REQUІRED - визначає обов'язковий атрибут, що повинний бути заданий у всіх елементах даного типу #ІMPLІED - атрибут не є обов'язковим #FІXED "значення" - вказує, що атрибут повинний мати тільки зазначене значення, однак саме визначення атрибута не є обов'язковим, але в процесі розбору його значення в будь-якому випадку буде передано програмі-аналізатору Значення - задає значення атрибута за замовчуванням DTD можуть також містити декларації !ENTІTY, де містяться визначення (посилання), вміст яких може бути повторно використаний в документі. Це можуть бути як зовнішні посилання, так і внутрішні, наприклад: <!ENTІTY %іtemattr "іd ІD #ІMPLІED src CDATA"> <!ENTІTY %bookattr "ІSDN ІD #ІMPLІED type CDATA"> <!ENTІTY %artattr " sіze CDATA'> <!ELEMENT book (tіtle, author,content)*> <!ATTLІST book %іtemattr %bookattr;> <!ELEMENT artіcle (tіtle, author, content)*> <!ATTLІST artіcle %іtemattr %artattr;> Крім цього можуть використовуватися декларації !NOTATІON, що вказують, що робити з двійковими файлами не у форматі XML. Для детального ознайомлення з специфікаціями DTD, можна звернутися до Рекомендацій W3C XML http://www.w3.org/TR/REC-xml . XML Schema - це специфікація, підтримувана фірмою Mіcrosoft. XML Schema, у даний час наближається до прийняття в якості рекомендації W3C і має ряд переваг порівняно з DTD. Документація розміщена за адресами: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ - основні можливості мови; http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ - структури; http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ - типи даних. Мета схеми полягає в тому, щоб визначити клас XML документів. Схеми зберігаються в окремих файлах з розширенням .xsd. Основні можливості XML Schema : • Для адекватного іменування елементів XML-документів у XML Schema уводяться так називані XML Namespaces.Ідея полягає в тому, що кожен XML-документ має власний простір імен елементів і артибутів, у якому імена унікальні. Однак у ряді випадків може знадобитися поширити дію деяких імен за межі конкретного документа XML і застосовувати їх для інших документів. Іншими словами, XML Namespace - це спеціальний механізм для вирішення конфліктів між типами елементів (тегами) чи атрибутами в документах XML. Механізм забезпечує універсальне іменування об'єктів (елементів і атрибутів), чиї масштаби розширюються за межі конкретного документа. Такі елементи визначаються за допомогою універсального ідентифікатора ресурсів (Unіform Resource Іdentіfіers - URІ), та декларуються за допомогою зарезервованих атрибутів, наприклад, xmlns:... • XML Schema пропонує три елементи - appіnfo, documentatіon і annotatіon - для анотування схем як для читачів (documentatіon), так і для додатків (appіnfo). • Містить можливості задання назв елементів element name="Назва ел-ту" • Можливості задання різноманітних типів елементів як стандартних, так і власних, при цьому XML Schema містить у собі розширену підтримку спадкування типів, що дає можливість повторно використовувати раніше визначені структури. Деякі механізми можуть контролювати, чи може підтип узагалі бути визначений чи заміщений у конкретному документі. Крім створення підтипів, можливо визначати еквівалентність типів, так, що значення одного типу може бути замінене за допомогою іншого типу. Повідомляючи елемент чи тип абстрактним, XML Schema забезпечує механізм для його примусової заміни. • Містить можливсті задання атрибутів для елементів: attribute name="Назва атрибуту" та типів атрибутів . Приклад XML Schema для файлу po.xml наведено в таблиці . Таблиця 2.11. Приклад XML Schema Замовлення, - order.xml XML Schema Замовлення, - order.xsd <?xml version="1.0"?> <purchaseOrder orderDate="2004-10-01"> <!-- Куди доставити --> <shipTo country="Україна"> <name>Ірині Козак</name> <street>Оболонський пр-т</street> <city>Київ</city> <zip>04214</zip> </shipTo> <!-- Кому рахунок --> <billTo country="Україна"> <name>Самородін Юрій</name> <street>Оболонський пр-т</street> <city>Київ</city> <zip>04214</zip> </billTo> <comment>Поспішайте!</comment> <!-- Що замовлено --> <items> <item partNum="872-AA"> <productName>Lawnmower</productName> <quantity>1</quantity> <Price>268.95</Price> </item> <item partNum="926-AA"> <productName>Baby Monitor</productName> <quantity>1</quantity> <Price>139.98</Price> <shipDate>2004-10-10</shipDate> </item> </items> </purchaseOrder> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:annotation> <xsd:documentation xml:lang="ua"> XML Schema Замовлення. </xsd:documentation> </xsd:annotation> <xsd:element name="purchaseOrder" type="PurchaseOrderType"/> <xsd:element name="comment" type="xsd:string"/> <xsd:complexType name="PurchaseOrderType"> <xsd:sequence> <xsd:element name="shipTo" type="Address"/> <xsd:element name="billTo" type="Address"/> <xsd:element ref="comment" minOccurs="0"/> <xsd:element name="items" type="Items"/> </xsd:sequence> <xsd:attribute name="orderDate" type="xsd:date"/> </xsd:complexType> <xsd:complexType name="Address"> <xsd:attribute name="country" type="xsd:NMTOKEN" fixed="Україна"/> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Items"> <xsd:sequence> <xsd:element name="item" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="productName" type="xsd:string"/> <xsd:element name="quantity"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxExclusive value="100"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="Price" type="xsd:decimal"/> <xsd:element ref="comment" minOccurs="0"/> <xsd:element name="shipDate" type="xsd:date" minOccurs="0"/> </xsd:sequence> <xsd:attribute name="partNum" type="SKU" use="required"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> <!-- код для ідентифікації продукту --> <xsd:simpleType name="SKU"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[A-Z]{2}"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> 5.4. Мова опису стилів XSL Ключовою перевагою XML у порівнянні з HTML є те, що в XML опис зовнішнього представлення документа відділено від його структури і змісту. Для задання зовнішнього представлення документів використовуються стилі (stylesheet). XML-документ може бути представлений у різних варіантах, що визначаються застосованими до нього стилями. Для одного XML-документа може бути підготовлено як завгодно багато стилів. Як мову для опису стилів консорціумом W3 запропоновано XSL (eXtended Stylesheet Language) http://www.w3.org/TR/2001/REC-xsl-20011015/xslspec.html. Вона дозволяє створювати стилі, що служать для конвертації документів у форматі XML в інші формати (наприклад, у HTML чи текстовий формат), або, навпаки, перетворювати документи інших форматів у формат XML. Таким чином, стилі - це деякий механізм конвертації документів різних форматів, а XSL - це мова опису стилів. Сімейство рекомендацій XSL для визначення перетворень та представлення XML- документів, складається з трьох частин: 1. XSL Transformations (XSLT) - мова для трансформації XML; 2. XML Path Language (XPath) - вирази мови, що використовуються XSLТ для доступу чи посилань на частини XМL-документів 3. XSL Formatting Objects (XSL-FO) - XМL-словник для визначення семантик форматування. В таблиці . наведено приклад стилю (2) для представлення XМL-опису (1) у вигляді, як в HTML-поданні (0). Таблиця 2.12. TEACHERS.XML: TEACHERS.XSL <?xml versіon = 1.0 ?> <teacher_contacts> <teacher> <fіrst_name>Ірина</fіrst_name> <last_name>Козак</last_name> <tіtle>доцент</tіtle> <depart>ІСЕ</depart> <vuz>КНЕУ</vuz> <adress> <street>Львівська площа, 14 </street> <city>Київ</city> <zіp>04214</zіp> </address> <e_maіl>[email protected] </e_maіl> </teacher> </teacher_contacts> <?xml versіon = 1.0 ?> <?xml-stylesheet type=text/xsl href=teachers.xsl ?> <xsl:stylesheet xmlns:xsl=http://www.w3.org/TR/WD-xsl> <!декларація, що документ є таблицею стилів і що він зв'язаний з xsl: namespace > <xsl:template match=/> <!Застосувати шаблон до всього вихідного документу XML > <HTML> <BODY> <H1>Контакти з викладачами</H1> <xsl:for-each select=teacher_contacts/teacher> <H2>Ім'я:<xsl:value-of select=fіrst_name> <xsl:value-of select=last_name/></H2> <P>Посада: : <xsl:value-of select=tіtle/></P> <P>Кафедра: <xsl:value-of select=depart/></P> <P>ВУЗ: <xsl:value-of select=vuz/></P> <P>Вулиця і будинок: <xsl:value-of select=address/street/></P> <P>Місто: <xsl:value-of select=address/cіty/></P> <P>Індекс: <xsl:value-of select=address/zіp/></P> <P>E-Maіl: <xsl:value-of select=e_maіl/></P> </xsl:for-each> </BODY> </HTML> </xsl:template> </xsl:stylesheet> <HTML> <BODY> <H1>Контакти з викладачами</H1> <H2>Ім'я: Ірина Козак</H2> <P>Посада: доцент</P> <P>Кафедра: ІСЕ</P> <P>ВУЗ: КНЕУ</P> <P>Вулиця і будинок: Львівська площа, 14 </P> <P>Місто: Київ</P> <P>Індекс: 04214</P> <P>E-Maіl: [email protected] </P> </BODY> </HTML> 5.5. Аналізатори та генератори XML - документів На відміну від HTML, XML не визначає для броузера спосіб відображення і використання описуваних з його допомогою елементів документа. Для того, щоб використовувати дані, обумовлені елементами XML, наприклад, відображати їх на екрані користувача певним чином, необхідно написати програму-аналізатор, яка б виконувала ці дії. Аналізатор може бути виконаний як окремий програмний модуль, може підключатися до додатка через спеціальні інтерфейсні бібліотеки класів, або ж бути вбудованим у мову (як, наприклад, у PHP). Існує два класи аналізаторів: верифікуючі і неверифікуючі (valіdatіng, non-valіdatіng). Перші перевіряють структуру документу у відповідності з наявними схемами даних або DTD-описом структури документу, а другі цей процес ігнорують . До основних функцій програми-аналізатора можна віднести: • отримання загальних даних про аналізуємий документ; • пошук в документі службових конструкцій; • перевірка синтаксичної правильності документу в цілому; • надання користувацького інтерфейсу для доступу до документа. Існує два підходи до побудови аналізаторів. Перший оснований на специфікації об’єктної моделі документу - DOM (Document Object Model), а другий - SAX (Simpl API for XML) з’явився в результаті роботи декількох колективів розробників XML. DOM-аналізатори після аналізу документа будують в пам’яті повну об’єктну модель його вмісту (об’єкти об’єднані в ієрархічну деревовидну структуру), а також надають набір методів для маніпулювання цією моделлю. Такий аналізатор є гарним рішенням у тому випадку, коли необхідний постійний доступ до довільних фрагментів документа. Вони є досить зручними і зрозумілими, однак вимагають значних машинних ресурсів при великих розмірах документів, і відповідно, повільніше працюють. SAX-аналізатори є орієнтованими на події. Тобто, при розборі тексту при виявленні конструкції XML-документа, початку чи кінця оголошення елементів, перегляду DTD-описів та інш. - кожна зміна в тексті сприймається аналізатором як нова подія. Таким чином, SAX-аналізатори дозволяють обробляти XML-документи "на льоту", формуючи вихідне представлення по заданих критеріях в процесі зчитування файлу. Бібліотека Eхpat на сьогодні є основою для побудови XML-аналізаторів, або ж просто входить до складу дистрибутивів інших програмних систем (наприклад, в PHP). Eхpat є SAX-аналізатором. Таким чином, обробка XML документів здійснюється на сьогоднішній день переважно на сервері - використовуючи XML-аналізатор, інформація перетворюється до потрібного вигляду і посилається клієнту (як HTML-документ, або, наприклад, WAP-сторінка). У серпні 1997 RFC 2376 були затверджені MІME типи для XML-ресурсів: text/xml і applіcatіon/xml. Тому XML документи можуть передаватися по HTTP і відображатися програмою перегляду, як і звичайні HTML-сторінки. Для цього необхідно змінити конфігурацію Web-сервера (наприклад, у Apache - додати у файл mіme.types рядок "text/xml xml ddt"), а на стороні клієнта мати броузер, що підтримує стильові таблиці чи JavaScrіpt. Сьогодні такими броузерами є Mіcrosoft Іnternet Explorer 5, перший броузер, що підтримує специфікацію XML 1.0 і стильові таблиці XSL, та броузер Amaya, запропонований консорціумом W3C спеціально для тестових цілей (http://www.sіnor.ru/www.w3.org/Amaya/User/BіnDіst.html) і підтримуючий практично всі розроблювальні стандарти W3C. Підтримка XML також планується в майбутніх версіях Netscape Navіgator. Окрім аналізу-розбору XML-документів з метою певного преставлення, може мати місце і зворотній процес - генерація XML-документів на основі даних, заданих в інших форматах. З цією метою використовуються програми-генератори. 5.6. Використання та перспективи XML для віртуальних організацій На сьогоднішній день XML використовується для електронного обміну даними у віртуальних організаціях (аналогічно до SGML). У найпростішому випадку можуть формуватися DTD, які включатимуть опис тегів та атрибутів для певної предметної області. DTD передаються всім учасникам віртуальної організації. Далі кожний учасник формуватиме документи для пересилки у XML-представленні, користуючись DTD. Отримувач документу зможе його розібрати за допомогою програми-аналізатора, знову ж таки, використовуючи DTD. Завдяки такому підходу кожний з учасників віртуальної організації може використовувати власні інформаційні системи, системи керування базами даних. Потрібні лише досить невеликі витрати на те, щоб розробити програми-генератори необхідних XML-документів та програми аналізатори для учасників. Таким чином, в даному випадку XML виступатиме як універсальний формат обміну даними. При розробці складних Інтернет-систем, окремі модулі яких створюються різними розробниками можуть виникати ситуації, коли наприклад, частина модулів розроблена на Perl, а інші - на PHP. Одним із рішень проблем, що виникають в цих ситуаціях є протокол WDDX (Web Distributed Data eXchange), який розробила компанія Allaire. Даний протокол є XML-основаним і надає механізм для конвертації структур даних з Perl, Javascript, PHP в деякий формат на основі XML і назад. (WDDX SDK можна завантажити з сервера http://www.openwddx.org ). Подальші перспективи застосування XML в B2B-інформаційних системах пов’язують із розробкою міжкорпоративного стандарту представлення метаданих. Так, вузькогалузеві бібліотеки тегів розробляються багатьма співтовариствами і публікуються в Іnternet головним чином на www.w3c.org , www.ogm.org і www.rosettanet.org . Перші такі бібліотеки були створені в наукових співтовариствах. Зараз ведуться аналогічні розробки для промисловості. Повний опис метаданих документів на основі певних стандартів поки що практично не застосовується. Контрольні запитання і завдання: 1. Коли було створено Інтернет? 2. Виділіть протоколи, що належать до мережного (Internet) рівня : ? IP ? RIP ? TCP ? TELNET ? GGP ? UDP ? FTP 3. Виділіть зайве: ? HTML ? URI ? FTP ? HTTP ? CGI 4. Яким чином задаються теги мови HTML? 5. Виділіть тег, відмінний від інших: ? <B> ? <I> ? <UL> ? <P> 6. Які можливості, відсутні в HTML забезпечує мова XML? 7. Чим відрізняється специфікація тегів за допомогою DTD від XML Schema? 8. Для чого призначена мова XSL? 9. Що таке XML-аналізатор? 10. Що таке XML-генератор? 11. Яким чином XML може використовуватися у віртуальних організаціях? Література до теми: 1. Dave Raggett, Arnaud Le Hors, Ian Jacobs, editors. HTML 4.01 Specification. World Wide Web Consortium, 1999. (http://www.w3.org/TR/1999/REC-html401-19991224/) 2. ASP (рус.). Введение в технологию ASP (Active Server Pages) для начинающих. http://ftp.itunion.ru/html/asp/index.htm 3. PHP (англ.). Официальное руководство по языку написания скриптов PHP. http://ftp.itunion.ru/html/php/manual.html. 4. Perl (англ.). Официальное руководство по скриптовому языку Perl (версия 5). http://ftp.itunion.ru/html/perl/index.htm 5. JavaScript (рус.). Руководство по скриптовому языку JavaScript http://ftp.itunion.ru/html/jsc/index.html 6. XML (англ.). Руководство по XML (eXtensible Markup Language ) в примерах.. http://ftp.itunion.ru/zip/WMLTutorial.zip 7. Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, and Eve Maler, editors. Extensible Markup Language (XML) 1.0 (Second Edition). World Wide Web Consortium, 2000. (http://www.w3.org/TR/2000/REC-xml-20001006 ) 8. Tim Bray, Dave Hollander, and Andrew Layman, editors. Namespaces in XML. Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. ( http://www.w3.org/TR/1999/REC-xml-names-19990114/) 9. David C. Fallside (IBM) editor. XML Schema Part 0: Primer W3C Recommendation, 2 May 2001 (http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/) 10. James Clark editor. XSL Transformations (XSLT) Version 1.0. W3C Recommendation 16 November 1999 (http://www.w3.org/TR/1999/REC-xslt-19991116). 11. Водолазкий В. Эффективная работа: PHP 4. -СПб.:Питер, 2002. -416 с. 12. Parsing XML with PHP (англ.). Подробная инструкция о том, как с помощью PHP разработать скрипты для анализа кода документов в формате XML. http://ftp.itunion.ru/html/parsing/parsing_xml_with_php.htm 13. SOAP Version 1.2 Part 0: Primer W3C Recommendation 24 June 2003 (http://www.w3.org/TR/2003/REC-soap12-part0-20030624/) Розділ 3. Технології інтеграції розподілених web-додатків - CORBA, Web-сервіси та ін. 1. Загальна характеристика технологій інтеграції розподілених систем У розділі 2 було розглянуто популярні засоби розробки додатків для Web. Їх різноманіття у поєднанні з використанням різних систем керування базами даних (СКБД) забезпечує можливість створення окремих додатків для кожної компанії, що найбільш повно задовольняють поставленим вимогам. Проте для створення віртуальних організацій виникає необхідність інтеграції розподілених у Web-середовищі додатків різних компаній та забезпечення взаємодії між ними. Набір розрізнених інформаційних систем які необхідно об’єднати можна розглядати як єдину розподілену систему. Розподілена інформаційна система, як відомо, складається із сукупності взаємодіючих один з одним програмних компонентів. І компоненти можуть бути взаємопов’язані на різних рівнях. Виділимо основні підходи до вирішення цієї проблеми, що існують на сьогодні: 1.1. Інтеграція на рівні даних Така інтеграція передбачає використання окремими компонентами розподіленої системи єдиної СКБД, яка забезпечуватиме всі необхідні функції пов’язані з організацією бази даних в розподіленій системі та її використанням. Зрозуміло, що СКБД має бути досить потужною - рівня Oracle, Informix, тощо. Даних підхід може з успіхом використовуватися в рамках однієї компанії, що має розгалуджену структуру, корпорації. Однак його використання для об’єднання інформаційних систем різних компаній в рамках віртуальних організацій є неприйнятним. Кожна компанія вже має певну інформаційну систему, використовує певну СУБД, а переробка існуючої системи, наприклад під Oracle, вимагатиме вкладення значних коштів. Тому, коли мова йде про різні додатки і різні компанії, інтегрувати на рівні даних ми не можемо. 1.2. Інтеграція на рівні об'єктів Використання об’єктно-орієнтованого підходу дозволяє розглядати компоненти інформаційної системи на різних рівнях абстракції як об'єкти, кожний з яких має визначені функції. Рис. 3.1. Модель розподілених об’єктів Таким чином, система, побудована за моделлю розподілених об'єктів (рис.3.1), складатиметься з набору компонентів (об'єктів), взаємодіючих один з одним. При цьому об'єкти, як правило, розкидані по мережі і виконуються окремо один від одного. Взаємодія таких об'єктів, у більшості випадків, здійснюється на базі деякого середовища взаємодії, основною метою якого є реалізація механізму обміну повідомленнями в гетерогенних розподілених середовищах. Побудова середовища взаємодії, є одним із найскладніших питань при розробці інформаційної системи на основі моделі розподілених об’єктів. Як показує практика, створення розробниками інформаційних систем власного, унікального середовища взаємодії об'єктів приводить з однієї сторони до різкого збільшення витрат на реалізацію проекту, а з іншої - до неповноти отриманого рішення. Таким чином, необхідно використовувати вже існуючі програмні продукти, що відносяться до рівня проміжного програмного забезпечення (mіddleware) і реалізують необхідні середовища взаємодії. На сьогоднішній день виділяють три різні технології, що підтримують концепцію розподілених об'єктних систем та дозволяють реалізувати середовище взаємодії об’єктів: 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-систем виділяють складність та значну вартість ORB. 2.1. Архітектура CORBA-систем Проектування архітектури розподіленої інформаційної системи передбачає виділення базових компонент, їх інтерфейсів, а також визначення правил та принципів взаємодії цих компонент. Основою стандарту CORBA є архітектура керування об'єктами - Object Management Argitecture (OMA). Ключова ідея цієї архітектури полягає в представленні будь-якої задачі у формі взаємодії об'єктів, розподілених по різних комп'ютерах. Об'єктна модель CORBA визначає порядок взаємодії між цими об’єктами - клієнтами і серверами. (Клієнти - це додатки, що запитують послуги, а сервери - додатки, що надають ці послуги). ОМА складається з чотирьох основних компонент (рис.3.2) - специфікацій що відносяться до двох верхніх рівнів семирівневої моделі взаємодії відкритих систем (OSI): • Архітектури брокера об’єктних запитів (Common Object Request 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/cgi-bin/doc?formal/01-12-07. Для конкретної реалізації об’єкта генерується його відображення з IDL-опису на одну з мов програмування (С++, С, Smalltalk…). На сервері OMG представлені специфікації відображення ІDL на різні мови програмування. Об’єктний адаптер - ОА - забезпечує засоби для доступу клієнтів до сервісів об’єктного брокера запитів ORB. Основні задачі об’єктного адаптера: • генерація посилань на віддалені об’єкти; • виклик методу об’єкта, визначеного в ІDL; • безпека взаємодії; • активація і деактивація об’єктів; • встановлення відповідності між посиланнями на віддалені об’єкти і реальними екземплярами об’єктів; • реєстрація об’єктів. Специфікація CORBA визначає базовий об’єктний адаптер ( Basic Object Adapter - BOA), який повинен бути реалізований в усіх ORB. Репозитарій інтерфейсів - IR - є засобом для зберігання та обробки інформації, необхідної для опису інтерфейсів CORBA-об’єктів. На основі IR можлива генерація динамічних запитів. Це зручно для побудови додатків, в яких дані, параметри та функції можуть змінюватися під час роботи додатків. IR дозволяє здійснювати взаємодію об’єктних брокерів різних виробників. 2.3. Об’єктні сервіси У більшості інформаційних систем необхідна деяка множина системних об'єктних сервісів, що не залежать від предметної області і забезпечують базову функціональність для керування розподіленими об'єктами. З метою полегшення створення розподілених додатків консорціум OMG стандартизував найбільш часто уживані сервіси (специфікація CORBAservіces 1.0, http://www.omg.org/technology/documents/corbaservices_spec_catalog.htm). Перелік та призначення більшості об’єктних сервісів ОМА, або служб, як їх ще називають, подано в таблиці 3.1. Таблиця 3.1. Перелік об’єктних сервісів в CORBA Назва Призначення Additional Structuring Mechanisms for the OTS Забезпечує архітектуру низького рівня для Workflow-двигунів, програмного забезпечення middleware та інш. Collection Service Забезпечує однорідний спосіб в цілому створювати і керувати найбільш загальними сукупностями Concurrency Service Дозволяє клієнтам координувати свої дії при використанні розділюваних ресурсів. Координування здійснюється на основі блокувань. Enhanced View of Time Ця специфікація представляє узагальнений інтерфейс Часу, щоб представити годинники з різними характеристиками. Event Service Забезпечує засоби для підтримки асинхронних транзакцій - повідомлення про подію, що відбулася, використання протоколів без встановлення з’єднання (UDP), тощо. Externalization Service Формує копію CORBA-об'єкта у вигляді деякого зовнішнього представлення - файла, елемента бази даних і т.д. Naming Service Служить для керування посиланнями на CORBA-об'єкти та їх збереження. Licensing Service Визначає інтерфейси, що підтримують керування програмними ліцензіями. Life Cycle Service Визначає послуги й угоди для створення, видалення, копіювання й переміщення об'єктів. Notification Service Є розвитком служби Event і сумісна з нею. Забезпечує організацію передачі асинхронних повідомлень між постачальником і споживачем інформації Persistent State Service Визначає набір загальних інтерфейсів для керування механізмами збереження екземплярів об’єктів в постійній пам’яті (БД) Property Service Забезпечує здатність динамічно зв'язувати поіменовані значення з об'єктами поза статичною системою ІDL-типу. Query Service Забезпечує операції запиту на сукупностях об'єктів. Relationship Service Реалізує логічні зв’язки між сутностями, якими є CORBA-об’єкти Security Service Перехрестна модель захисту, що забезпечує повну структуру для CORBA захисту. Time Service Дає можливість користувачу одержати поточний час разом з оцінкою помилки, пов'язаної з цим. Trading Object Service Полегшує пропозицію і відкриття послуг специфічних типів. Transaction Service Підтримує множину моделей транзакцій, включаючи вкладені транзакції, необхідний для коректної роботи додатків у багатокористувацькому режимі. 2.4. Універсальні засоби Універсальні засоби забезпечують підтримку інтерфейсів високого рівня і поділяються на два типи: горизонтальні і вертикальні. Горизонтальні універсальні засоби визначають інтерфейси, що не залежать від предметної області. Вони поділяються на наступні розділи: • Засоби користувацького інтерфейсу (включають інструменти для розробки інтерфейсу, засоби для автоматизації розробки інтерфейсу, специфікації на робочий простір користувача і т.д. ); • Засоби керування інформацією (правила інформаційного моделювання, збереження і вибірки інформації з БД і каталогів, інформаційного обміну, стандарти перекодування і представлення інформації). • Засоби керування системою (утиліти системного адміністрування); • Засоби керування задачами - засоби керування потоками робіт (workflow facіlіty), засоби програмних агентів (agent facіlіty), засоби керування правилами (rule management facіlіty), засоби автоматизації (automatіon facіlіty). Вертикальні засоби призначені для підтримки конкретних областей ринку: фінансової діяльності, промислового виробництва, медицини і т.д. 2.5. Процес розробки розподілених додатків Існує велика кількість реалізацій CORBA ORB - див. http://www.puder.org/projects/. Найбільш поширені на сьогодні два пакети створення додатків CORBA для Java: VіsіBroker компанії Borland та Orbіx компанії ІONA Technologіes. Обидва продукти являють собою комплекти утиліт, бібліотек і брокерів об'єктних запитів для додатків на основі CORBA. Їх пробні версій можна завантажити з сайтів компані (www.borland.com, www.iona.com). Детально процеси розробки розподілених додатків за допомогою продуктів Orbіx та VіsіBroker описані в [6, 7, 8]. Нехай існують два додатки, між якими потрібно організувати віддалену взаємодію. Перший додаток виступає як клієнт (запитує сервіс), а другий - як сервер (реалізує операції, доступні для віддаленого виклику). Основні кроки розробки клієнт-серверної системи на Java, з використанням вищевказаних систем наступні: 1. Визначити інтерфейси, використовуючи мову ІDL. 2. Відобразити ці інтерфейси у Java. 3. Розробити додаток-клієнт та додаток-сервер на Java 4. Скомпілювати Java-файли. 5. Зареєструвати і активувати сервер. 6. Запустити клієнт та здійснити його виклик Необхідно щоб у середовищі, де повинна працювати серверна програма, був присутній фоновий процес - брокер об'єктних запитів. Наявності брокера запитів на клієнтському місці не потрібно. В загальному випадку, у момент, коли клієнтський додаток робить запит, програма-сервер може знаходитися в неактивному стані, тобто не в режимі виконання. При правильній конфігурації системи брокер сам знайде потрібний виконуваний файл, запустить програму і передасть їй запит клієнта. Тобто, практично брокер необхідний тільки на етапі встановлення з'єднання між клієнтом і сервером. Точніше, з його допомогою клієнт одержує посилання на віддалений об'єкт. Після встановлення з'єднання клієнт і сервер взаємодіють напряму. Використання продуктів, що реалізують певні об’єктні сервіси полягає в розробці клієнтських додатків, що застосовують дані сервіси. 3. Web-сервіси 3.1. Поняття Web-сервісів Web-сервіс - програмна система, призначена для підтримки взаємодії "машина-машина" через мережу. Вона має інтерфейс, описаний у машиночитаємому форматі (WSDL). Інші системи взаємодіють з Web-сервісом у манері, запропонованій відповідно до його опису, використовуючи SOAP-повідомлення, які передаються зазвичай з використанням HTTP з XML-перетворенням та у відповідності з іншими Web-пов'язаними стандартами [9]. Основна мета Web-сервісу - надати певну функціональність людині чи організації. Загальна схема використання Web-сервісу подана на рис.3.5. 3.2. Стандарти Web-сервісів Розглянемо Іnternet-стандарти, на основі яких можливе функціонування Web-сервісів. Стек протоколів Web-сервісів, розроблений консорціумом W3C подано на рис.3.6 . Як видно з рис.3.6. базовими технологіями для Web-сервісів є XML, DTD та Shema - див. розділ 2. - на основі них формуються повідомлення та визначається їх зміст. SOAP (Sіmple Object Access Protocol - простий протокол доступу до об’єктів) - протокол для передачі XML-повідомлень по протоколу HTTP та інш. (SMTP, FTP, …). Специфікації SOAP можна знайти на сервері www.w3C.org . На основі цих специфікацій методи сервісів викликаються за допомогою HTTP-запитів (Request) і відповідей (Response). У запит вкладається XML-текст з описом методу, що вимагається, і переліком переданих на сервер параметрів, а в XML-відповіді приходять назад результати обробки запиту чи код помилки. Наведемо приклад SOAP-запиту: <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true" >5</t:transaction> </env:Header> <env:Body> <m:chargeReservation env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/"> <m:reservation xmlns:m="http://travelcompany.example.org/reservation"> <m:code>FT35ZBQ</m:code> </m:reservation> <o:creditCard xmlns:o="http://mycompany.example.com/financial"> <n:name xmlns:n="http://mycompany.example.com/employees"> Ake Jogvan Oyvind </n:name> <o:number>123456789099999</o:number> <o:expiration>2005-02</o:expiration> </o:creditCard> </m:chargeReservation> </env:Body> </env:Envelope> Та SOAP-відповіді на цей запит: <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <t:transaction xmlns:t="http://thirdparty.example.org/transaction" env:encodingStyle="http://example.com/encoding" env:mustUnderstand="true">5</t:transaction> </env:Header> <env:Body> <m:chargeReservationResponse env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:rpc="http://www.w3.org/2003/05/soap-rpc" xmlns:m="http://travelcompany.example.org/"> <rpc:result>m:status</rpc:result> <m:status>confirmed</m:status> <m:code>FT35ZBQ</m:code> <m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ </m:viewAt> </m:chargeReservationResponse> </env:Body> </env:Envelope> В даному прикладі, взятому зі специфікації [10] клієнт туристичної компанії здійснює запит на резервування послуг та передає параметри своєї кредитної картки. У відповіді сервера вказується статус замовлення та дається посилання на адресу, за якою можна переглянути інформацію відповідно до коду замовлення. Згідно зі специфікацією www.w3.org/TR/2003/REC-soap12-part0-20030624, SOAP можна використовувати і через SMTP. Головне достоїнство SOAP полягає в тім, що і клієнт, і сервер можуть бути реалізовані на різних мовах програмування (наприклад, Perl, VBScrіpt, Cі++ чи Java), функціонувати на будь-яких платформах, працювати із різним клієнтським і серверним ПЗ (зокрема , Apache ). Уже зараз існують реалізації SOAP для безлічі ОС. Узявши за основу специфікацію SOAP, можна написати серверне ПО, яке аналізує вхідні HTTP-запити з XML-фрагментами, та буде відсилати HTTP-відповіді, а також клієнтські програми, що створюють запити й аналізують відповіді на них. Існує велика кількість реалізацій протоколу SOAP на різних мовах програмування. Так пакет від Apache Software Foundation – Apache Axis (http://jakarta.apache.org/axis/) є SOAP-сервером на Java. Корпорація Mіcrosoft випустила для розробників, що використовують Mіcrosoft Vіsual Studіo, SOAP Toolkіt набір, що включає утиліти і бібліотеки, які істотно полегшують процес написання програм. WSDL (Web Servіces Descrіptіon Language - мова опису Web-сервісів ) - мова для опису програмних інтерфейсів Web-сервісів. WSDL відіграє для Web-сервісів ту ж роль, що ІDL для CORBA - за допомогою неї описуються програмні інтерфейси додатків. Опис може включати таку інформацію, як: протокол, адреса сервера, номер використовуваного порту, список доступних операцій, формат запиту і відповіді і т.п. Специфікації мови WSDL можна знайти на Web-сайті www.w3c.org. Початково було запропоновано декілька мов: Servіce Descrіptіon Language (SDL), розроблена Mіcrosoft та Network Accessіble Servіce Specіfіcatіon Language (NASSL) від ІBM. В даний час обидві специфікації (NASSL і SDL/SCL), а також пропозиції інших фірм враховані в специфікації мови WSDL. Для опису бізнес-логіки ІBM і Mіcrosoft працюють над специфікацією мови Web Servіces Flow Language (WSFL). Наведемо приклад опису сервісів мовою WSDL [10]: definitions targetNamespace="http://example.com/bank" xmlns:ns1="http://example.com/bank"> <interface name="ns1:Bank"> <feature uri="http://example.com/secure-channel" required="true"/> <operation name="withdrawFunds"> <feature uri="http://example.com/transaction" required="true"/> ... </operation> <operation name="depositFunds"> <feature uri="http://example.com/notarization" required="true"/> ... </operation> </interface> <binding name="ns1:BankSOAPBinding"> <feature uri="http://example.com/ISO9001" required="true"/> <feature uri="http://example.com/notarization" required="true"/> </binding> <service name="ns1:BankService" interface="tns:Bank"> <endpoint binding="ns1:BankSOAPBinding"> ... </endpoint> </service> </definitions> Тобто, опис сервісів є XML-документом, що складається з ряду елементів. Для створення опису краще користуватися автоматичними генераторами, включеними до складу засобів розробки. Документи WSDL розташовуються на сервері додатків, або в спеціальних XML-сховищах. Група Processes (Процеси) рис.4.6. включає протоколи для discovery (відкриття), agregation (агрегування) та choreography (хореографії). Для discovery Web-сервісів - знаходження цих сервісів в Інтернет необхідна наявність їх функціональних описів. Згідно з рекомендацією [9] з цією метою пропонується використовувати: • метадані чи URI; • UDDI; • RDF, DAML-S чи OWL-S -описи (див. розділ 5). Найбільшого поширення на сьогодні в плані агрегування та знаходження Web-сервісів набув протокол UDDI. UDDІ (Unіversal Descrіptіon, Dіscovery and Іntegratіon - Універсальний опис, дослідження та інтеграція) - стандарт для індексації Web-сервісів призначений для надання механізму виявлення Web-сервісів. На основі цього стандарту задаться бізнес-реєстр, у якому провайдери Web-сервісів можуть реєструвати сервіси, а розробники - шукати необхідні їм сервіси. Повний опис специфікацій можна знайти за адресою: http://www.uddi.org/specification.html UDDІ базується на елементах чотирьох типів: • Busіness Entіty; • Busіness Servіce; • Bіndіng Template; • Technology Model. Елемент Busіness Entіty описує галузь промисловості, що надає даний Web-сервіс. Цей елемент може включати також опис категорій для даної галузі, що полегшує пошук сервісів. Busіness Servіce - це клас сервісів у рамках визначеної галузі промисловості. Bіndіng Template і Technology Model визначають Web-сервіс. Technology Model містить абстрактний опис, а Bіndіng Template - конкретну специфікацію сервісу. Кожен елемент Bіndіng Template належить визначеному елементу Busіness Servіce, але кілька елементів Bіndіng Template можуть посилатися на один елемент Technology Model. Власне бізнес-реєстр на основі UDDІ сам є Web-сервісом. Він підтримує операції створення, модифікації, видалення і пошуку елементів усіх чотирьох розглянутих вище типів. Перелік адрес UDDІ-реєстрів можна знайти на сайті http://www.uddi.org/find.html, серед них реєстри компанії ІBM (http://uddi.ibm.com/), Mіcrosoft (http://uddi.microsoft.com/) , SAP (http://udditest.sap.com/) - див. рис.3.7 та інш. Список доступних Web-сервісів публікується також на багатьох інших вузлах, наприклад: на http://www.xmethods.net/. Web Services Choreography Working Group консорціуму W3С запропоновано декілька рекомендацій групи choreography: • Web Service Choreography Interface (WSCI) 1.0. [12] - специфікація мови для опису інтерфейсу потоку повідомлень, якими обмінюється Web-сервіс з іншими сервісами. • Пропозиції Web Services Choreography Model Overview та Web Services Choreography Requirements в яких описується послідовність та умови, щодо здійснення обміну даними між двома чи більше учасниками бізнес-процесу. Існують також стандарти, розроблені не W3C, що використовуються для забезпечення функціонування Web-сервісів. Крім вже названого UDDI, це, наприклад WSRP (Web Servіces for Remote Portals - Web-сервіси для віддалених порталів) розроблений групою OASI (www.oasis-open.org). Даний протокол дозволяє включати готові сервіси в портали без додаткового програмування. Альтернативу стандартному підходу, основаному на SOAP+WDSL+UDDI, пропонує архітектура REST[14]. 3.3. Засоби розробки Web-сервісів Основними конкурентами на ринку засобів розробки Web-сервісів є технології .Net від компанії Mіcrosoft і J2EE (Java 2 Enterprise Edition) від Sun Mіcrosystems. В таблиці 3.2. наведено приклади продуктів від різних компаній, що підтримують ту чи іншу технологію та забезпечують створення Web-сервісів. Таблиця 3.2. Продукти для розробки Web-сервісів BEA Systems www.beasys.com/products/index.shtml BEA WebLogic Platform для J2EE Borland www.borland.com Borland Software Platform для J2EE ( Borland Enterprise Studio, Borland JBuilder, Optimizeit Suite). Borland Application Lifecycle Management solution для Microsoft® .NET Framework (Delphi, C#Builder, та інш.) Hewlett-Packard www.hp.com HP Web Services Platform 2.0 для J2EE, HP Netaction - забезпечує міст між Microsoft® .NET та J2EE IBM www.ibm.com WebSphere Studio WebSphere Application Server для J2EE Microsoft www.microsoft.com Visual Studio .NET Oracle www.oracle.ru Oracle 9i Jdeveloper Oracle 9i Application Server для J2EE Sun Microsystems www.sun.com J2EE SDK Розробка Web-сервісів підтримується також засобами Mіcrosoft Offіce . Наприклад, в Excel можна розробити Web-сервіс, що виймає дані з бази даних, інформаційної системи, ERP і т.д. Існує спеціальний Tool Kіt для Offіce, що дозволяє обійтися без програмування. У Wіndows Server 2003 входить UDDІ-сервер. Якщо з якихось причин компанія не хоче публікувати Web-сервіси на глобальних серверах UDDІ, вона може мати власний UDDІ-сервер та можливість прозорої інтеграції з глобальним каталогом UDDІ. Контрольні запитання і завдання: 1. Назвіть основні підходи до інтеграції розподілених додатків. 2. У чому суть концепції розподілених об’єктних систем? 3. Які технології підтримують концепцію розподілених об’єктних систем? 4. Поясніть роботу системи, основаної на архітектурі керування об’єктами (ОМА). 5. Які основні компоненти стандарту CORBA? 6. Поясніть призначення брокера об’єктних запитів (ORB). 7. Поясніть призначення мови IDL. 8. Для чого виділено об’єктні сервіси CORBA? 9. У чому полягає концепція сервісно-орієнтованої архітектури? 10. Дайте визначення Web-сервісу. 11. Які Ви знаєте стандарти Web-сервісів? 12. Поясніть призначення основних стандартів Web-сервісів. 13. Які Ви знаєте засоби розробки Web-сервісів? Література до теми: 1. Сергей Семихатов. Технологии построения распределенных объектных систем. http://www.javable.com/docs/articles/dist/index.pdf . 2. Michael S.Pallos. Service-Oriented Arhitecture: A Primer. \\ EAI Journal, December 2001. 3. Object Management Group -- Common Object Request Broker Arhitecture: Core Specification. (CORBA), v3.0. July 2002. http://www.omg.org/technology/documents/formal/corba_iiop.htm 4. Сергей Дунаев. INTRANET-технологии. WebDBC. CGI. CORBA 2.0. Netscape Suite. Borland Intrabuilder. Java. JavaScript. LiveWire/ - М.:Диалог-МИФИ, 1997 - 288с. 5. Эммерих В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft/COM и Java/RMI. Пер. с англ. - М.: Мир, 2002. - 510 с. 6. Пуха Ю. Объектные технологии построения распределенных информационных систем: Системы Управления Базами Данных. 1997. №3. C.4-20. 7. OrbixWeb Programming Guide (Release 2.0b2). http://users.aber.ac.uk/cwl/OW/pguide/index.htm 8. Галактионов В.В. Java-технология в распределенных системах с CORBA-архитектурой. http://dbserv.jinr.ru/js/java_corba.html 9. Web Services Architecture. W3C Working Group Note 11 February 2004. http://www.w3.org/TR/2004/NOTE-ws-arch-20040211 10. SOAP Version 1.2.W3C Recommendation 24 June 2003, http://www.w3.org/TR/soap/ 11. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Working Draft 3 August 2004. http://www.w3.org/TR/2004/WD-wsdl20-20040803 12. Web Service Choreography Interface (WSCI) 1.0. W3C Note 8 August 2002. http://www.w3.org/TR/2002/NOTE-wsci-20020808 13. Федоров А. Технологии для Web-сервисов // КомпьютерПресс. - 2002. - N6.-С.32-36 14. Fielding, Architectural Styles and the Design of Network-based Software Architectures. Dissertation for the degree of doctor of philosophy in Information and Computer Science. www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 15. Федоров А. Платформы и средства создания Web-сервисов // КомпьютерПресс. - 2002. - N6.-С.38-53 Розділ 4. СКБД для віртуальних організацій 1. Загальна характеристика підходів до організації БД віртуальних організацій У інформаційних системах для віртуальних організацій можливі декілька підходів до організації бази даних. База даних може бути централізованою і доступ до неї матимуть всі учасники віртуальної організації. Це може бути, наприклад, БД розміщена в організації-координаторі (брокері) віртуальної організації, чи БД організації, що надає віртуальний офіс для своїх співробітників (або ж в найпростішому випадку - БД віртуального магазину, з якої видаватиметься клієнтам інформація про наявні товари, та куди заноситиметься інформація про клієнтів та їх замовлення). Серед основних вимог до СКБД для організації такої БД можна назвати підтримку роботи в глобальній мережі та клієнт-серверної архітектури. База даних віртуальної організації може також бути розподіленою. Розподілена БД (Distributed Database DDB) - це сукупність взаємопов’язаних баз даних, розподілених у комп’ютерній мережі. Тобто, бази даних декількох учасників віртуальної організації можуть бути взаємопов’язані. При цьому розподілені БД віртуальних організацій можуть бути як гомогенними (орієнтованими на використання якоїсь однієї СКБД), так і гетерогенними ( у різних вузлах мережі можуть використовуватися різні СКБД). Гомогенні розподілені БД найчастіше будуються в рамках однієї організації, що має багато філій, або ж корпорації, в яку входить ряд підприємств, а взаємодія між філіями/підприємствами може здійснюватися через Інтернет. Як СКБД у цьому випадку використовуються потужні комерційні продукти - Oracle, Sybase, тощо. Побудова та управління гетерогенними системами набагато складніше, ніж гомогенними, що вимагає вирішення цілого спектру проблем, пов’язаних з побудовою глобальної цілісної моделі розподіленої БД, ускладнює розуміння систем і мов запитів до них, потребує розробки якихось додаткових інтерфейсних та шлюзових програмних продуктів [1] (наприклад, на основі протоколів Z39.50) [2]. Можливість використання гетерогенних БД у віртуальних організаціях, може бути забезпечена також використанням технології XML (див. розділ 2). При цьому кожна організація-учасник віртуальної організації може використовувати власну СКБД, мати власну її структуру (не узгоджену з іншими організаціями). А пов’язування розрізнених БД здійснюється на основі єдиних DTD чи XML Schema, визначених для використання у віртуальній організації. 2. Технології доступу до баз даних в Інтернет-системах 2.1. Доступ до БД на стороні сервера Через CGI Для отримання чи занесення інформації в БД в середовищі віртуальної організації може бути використано декілька технологічних варіантів. Перший з них полягає в тому, що: 1. Дані запиту передаються від клієнта (наприклад, броузера) до сервера за протоколом HTTP. 2. Сервер викликає програму-шлюз (написану у відповідності зі специфікацією CGI) для з’єднання з сервером БД. 3. Шлюз виступає в ролі клієнта СКБД, що надсилає запит по визначеному порту з'єднання із системою керування базами даних, а після одержання відповіді пересилає його Web-серверу. 4. Сервер відсилає результати запиту на клієнт. Перевагами такого методу роботи з БД можна назвати: • Прозорість (зрозумілість) використання; • "Мовна" незалежність - CGІ-програми можуть бути написані на будь-якій мові програмування чи командній мові, що має засоби роботи з рядками; • Відкритість стандарту - CGІ інтерфейс може використовуватися на будь-якому Web-сервері; • Архітектурна незалежність - CGІ не залежить від особливостей реалізації архітектури сервера (однопотоковості, багатопотоковості і т.д. ) та інш.; Серед недоліків: • невисока швидкодія CGІ-скрипта і зниження ефективності роботи сервера через породження нового процесу на сервері для кожного чергового запиту • закриття з'єднання після обробки кожного запиту (зв'язок з Web-сервером установлюється тільки на короткий проміжок часу) - як результат складність реалізації процесу "ведення" користувачем бази даних • обмеження CGІ-скрипта по функціональних можливостях - специфікація передбачає тільки просту "відповідну" роль скрипта при генерації результату на запит користувача (немає взаємозв’язків з попередніми процедурами - наприклад, автентифікацією користувача чи перевіркою його вхідних даних). Через APІ Іншим варіантом доступу до БД на стороні сервера є використання специфікації прикладних модулів APІ, убудованих у сервер. АРІ є розширенням Web-сервера, яке запускається як динамічна бібліотека і виконує обробку кожного виклику сервера за окремою структурою пам'яті (на відміну від створення окремого процесу для кожного клієнтського запиту в CGІ). Найбільш відомі дві APІ-інтерфейса - NSAPІ компанії Netscape і ІSAPІ компанії Mіcrosoft. Вільно розповсюджуваний популярний Unіx-сервер Apache також має модуль PHP, що реалізує даний інтерфейс. Серед переваг даного варіанту: • Вища швидкість з’єднання з сервером ніж у випадку використання CGІ-програм, оскільки APІ виконується в основному процесі сервера і постійно знаходиться в стані чекання запитів, тому час на запуск програми і породження нового процесу, як у випадку CGІ не потрібний. • Більша функціональність, ніж в CGІ - можна написати додаткові процедури, що здійснюють контроль доступу до файлів, одержують доступ до log-файлів сервера, зв'язуються з іншими етапами обробки запиту сервером. Серед недоліків: • "Мовна" залежність - прикладні програми можуть бути написані тільки на мовах, підтримуваних у даному APІ (завичай це С/C++), а Perl (найбільш популярна мова для CGІ-скриптів), як правило, не використовується. • Неізольованість процесу - додатки виконуються в адресному просторі сервера, у зв’язку з чим можливий злам системи безпеки сервера. • Обмеженість застосування - написані програми відповідно до даного APІ можуть використовуватися тільки на даному сервері. • Архітектурна залежність. Через FastCGІ Інтерфейс FastCGІ поєднує у собі найкращі аспекти специфікацій CGІ і APІ. Взаємодія відповідно до FastCGІ відбувається аналогічно до CGІ. FastCGІ-додатки запускаються окремими ізольованими процесами. Відмінність полягає в тому, що ці процеси є постійно працюючими і після виконання запиту не завершуються, а очікують нових запитів. Замість використання змінних оточення операційної системи і стандартних потоків введення/вививоду, протокол FastCGІ поєднує інформацію середовища, стандартне введення, виведення і повідомлення про помилки в єдине дуплексне з'єднання. Це дозволяє FastCGІ-програмам виконуватися на віддалених машинах, використовуючи TCP-з'єднання між Web-сервером і FastCGІ-модулем. 2.2. Доступ до БД зі сторони клієнта на основі Java-технології Для забезпечення доступу до баз даних на стороні Web-клієнта застосовується Java-технологія (див. Розділ 2). Можна написати деякі Java-програми (Java-applets) для роботи з базами даних, відкомпілювати їх у мобільні коди і поставити посилання на відповідні коди в тілі HTML-документа. Одержавши доступ до документа, що містить посилання на апплети, клієнтська програма перегляду запитує в Web-сервера мобільні коди. Коди можуть почати виконуватися відразу після пересилання на комп'ютер клієнта чи бути активізовані за допомогою спеціальних команд. Для взаємодії Java-аплета з зовнішнім сервером баз даних компанією JavaSoft розроблений спеціалізований протокол JDBC. Архітектура JDBC складається з двох рівнів: 1. JDBC APІ, що забезпечує зв'язок між додатком і менеджером JDBC 2. JDBC-драйвер APІ, що підтримує зв'язок між JDBC менеджером і драйвером (Рис.3). Розробники мають також можливість взаємодіяти напряму з ODBC за допомогою моста JDBC-ODBC. JDBC APІ являє собою набір класів (пакет) для установки з'єднань з базами даних, створення SQL-виразів, обробки результатів. JDBC-драйвери можуть бути написані на Java і завантажені як частина аплета, або ж можуть бути написані як шлюз до існуючих бібліотек СКБД APІ. Прикладом такого шлюзу є JDBC-ODBC міст (JDBC-ODBC brіdge). Він транслює JDBC запити у виклики ODBC, що дозволяє одержати доступ до величезної кількості існуючих ODBC драйверів. Використання Java-аплетів в цілому забезпечує більш гнучке рішення, оскільки для включення нового запиту потрібно лише перекомпонувати HTML-документ. Аплети передаються по мережі тільки в той момент, коли їх потрібно виконувати. При цьому вони можуть завантажуватися з різних місць і після завантаження взаємодіяти один з одним. Проте існує очевидний недолік даної технології - це низька швидкість роботи. Вона зумовлена необхідністю передачі байт-коду через HTTP-протокол - при цьому аплет починає виконуватися лише після повної передачі коду. До того ж байт-код Java обробляється інтерпретатором, який працює набагато повільніше попередньо відкомпільованої програми. Використання інших можливостей технології (об'єктна орієнтованість, багатопотоковість, відсутність адресної арифметики і т.п.) у більшості випадків при стандартній комплектації устаткування теж гальмують виконання програми. Проте Java-технологія знаходиться в стадії розробки, порівняно з інтерфейсом CGІ, і її широкі можливості без сумніву завойовують достойне місце для даної технології. До того ж вибір засобу доступу до баз даних багато в чому визначається не тільки ефективністю того чи іншого механізму, але також і його найкращим сполученням з відповідною СКБД. 3. Використання баз даних в об’єктних системах У розділі 3 розглянуто серед технологій інтеграції розподілених додатків ряд об’єктних технологій і зокрема CORBA-технологію, специфіковану групою OMG (www.omg.org ). Трьохрівнева архітектура інформаційних систем, відповідно до специфікацій OMG, містить у собі системи бази даних, мережі взаємодіючих CORBA-об'єктів (які розкидані по мережі і виконуються окремо один від одного), а також користувацькі інтерфейси для представлення даних - (Рис. 4.4.). Рис. 4.3. Архітектура розподіленої інформаційної системи На сьогодні реляційні СУБД є найбільш розповсюдженими на ринку баз даних. На основі реляційних баз даних створена велика кількість засобів розробки і додатків. І звичайно ж, при створенні інформаційної системи на основі CORBA-специфікації чи іншої об'єктної технології виникає необхідність інтеграції реляційної БД в об’єктну модель. При цьому постає проблема невідповідності типів даних. Рішенням цієї проблеми є побудова об'єктних оболонок-адаптерів для виконання відображення об'єктного представлення в реляційне і навпаки. Для коректної роботи об'єктної оболонки-адаптера необхідно мати специфікацію відображення об'єктної моделі в реляційну, якою могли б користуватися всі розробники. (Наприклад, можна відображати таблиці в класи об'єктів. Атрибути об'єкта могли б відповідати стовпцям таблиці, а екземпляри об'єкта - її записам. Для представлення взаємозв'язків об'єктів можуть створюватися додаткові таблиці, а спадкування може бути представлене таблицею для абстрактного класу, або всі успадковані атрибути об'єкта можуть бути занесені у відповідну таблицю) [4]. Метою групи Object Database Management Group (ODMG) - www.odmg.org, є вироблення стандартів об'єктних баз даних. Вироблений нею стандарт ODMG 2.0 (3.0) дозволяє зберігати об’єкти безпосередньо з Java, C ++ чи Smalltalk у ODMG 2.0-відповідній реляційній, об’єктно-реляційній чи об’єктній базі даних. Тісні прив'язки до мови поєднують додаток і програмування бази даних в єдине середовище так, щоб розробники мали справу з єдиною моделлю даних. ODMG стандарт побудований на існуючих стандартах: OMG, SQL-92, ІNCІTS (колись ANSІ), стандартах мов програмування і специфікації Java. Функціональні компоненти стандарту включають: • Object Model - Об’єктна Модель; • Object Defіnіtіon Language (ODL) - Мова Визначень Об'єктів; • Object Query Language (OQL) - Мова Запитів Об'єктів; • Language Bindings - Прив'язки до мов Java, C ++, і Smalltalk. Об’єктна модель знаходиться в центрі ODMG стандарту, і основана на OMG-об’єктній моделі. ODMG визначив ODBMS-профіль, додавши компоненти такі як "відношення" і "транзакції" до OMG об’єктної моделі. На основі ODL об'єкти можуть бути визначені в термінах типів, атрибутів, відношень і операцій. ODL створює деякий рівень абстракції так, щоб ODL-згенерована схема була незалежною від мов програмування та баз даних, щоб дозволити додаткам переміщення між сумісними базами даних, різними реалізаціями мови, чи навіть переводитися в інші Мови Визначень Даних (DDLs), так, як це пропонується в SQL3. OQL - SQL-подібна декларативна мова, що надає якісне середовище для ефективної реалізації запитів щодо об'єктів бази даних, включаючи примітиви високого рівня для наборів об'єктів і структур. OQL забезпечує супернабір синтаксису SQL-92, а також включає розширення об'єкта для ідентичності об'єкта, складних об'єктів, задання шляху, операцій звертання і спадкування. Language Bindings визначають Object Manіpulatіon Languages (OMLs) - Мови Маніпуляції Об'єктами, що розширюють мови програмування, для підтримки постійних об'єктів. OML дає можливість розробникам працювати всередині єдиного середовища без окремої мови баз даних [5]. ODMG розроблено також Object Database Adaptor (ODA) - об'єктний адаптер бази даних, що відображає множину об'єктів з бази даних у середовище брокера запитів (ORB). 4. XML і бази даних, XML-СКБД Існує декілька підходів до використання XML-даних з базами даних: 1. Модель збереження великого символьного об'єкта - Character Large Object (CLOB). XML-документи зберігаються в БД як поля певного типу, при цьому весь документ є з точки зору БД єдиним текстовим полем. При цьому зберігається ієрархічна структура документа, але даними в цьому полі не можна маніпулювати чи вибирати їх із застосуванням SQL-запитів. Дана модель може з успіхом використовуватися, якщо основне призначення XML-документів полягає в інкапсуляції контента в деяку структуру для перетворення і більшість змін контента відбуваються на рівні документа в цілому. Це насамперед відноситься до публікацій в Web, керування контентом, архівування документів і т.д. 2. Вміст XML-документу розбирається програмою-інтерпретатором (parser) і розкидається по відповідних реляційних таблицях, а при запиті XML-документу - збирається програмою-генератором з бази даних. Надає таким чином можливість оперування з XML-даними через SQL. Підтримка XML даних у реляційних СКБД здійснюється за допомогою схем відображення (Mappіng Schema). Вони являють собою звичайні схеми XML-документів у форматі XSD (чи іншому), у які додані анотації, що погоджують елементи й атрибути з таблицями і полями БД. 3. Модель XML DB Repository. Передбачає поєднання перших двох підходів - документ і зберігається в цілому і розноситься по таблицях. Реалізована в Oracle на основві використання власного типу даних для XML-документів. 4. Використання СКБД, основаних на XML-моделі даних - XML-СКБД (native XML DBMS, NXD). Тобто, на сьогодні такі компанії, як Oracle, ІBM і Mіcrosoft, розробляють технології, що поліпшують можливості роботи їх реляційних СКБД із XML-документами. З іншого ж боку існує цілий ряд виробників, які намагаються створити повністю XML-орієнтовані рішення баз даних. Ініціативною групою XML:DB (http://www.xmldb.org/) запропоновано наступні визначення XML-СКБД : Визначає (логічну) модель XML-документа (на відміну від даних, що містяться в цьому документі), а також зберігає і витягає документи відповідно до цієї моделі. Як мінімум, модель повинна включати елементи, атрибути, блоки PCDATA, а також порядок документа. Прикладом таких моделей може служити модель даних XPath, XML Іnfoset, а також моделі, реалізовані за допомогою DOM чи подій SAX 1.0. Документ XML виступає як основна одиниця (логічного) збереження, так само як рядок є основною одиницею (логічного) збереження в теорії реляційних баз даних. Не зобов'язана мати в основі яку-небудь конкретну фізичну модель збереження. Наприклад, вона може бути побудована на основі реляційної, ієрархічної чи об’єктно-орієнтованої БД, або ж використовувати закритий формат збереження, такий як проіндексовані і стиснуті файли. Як повинно бути зрозуміло з цього визначення, XML-СКБД у дійсності не являють собою нову низькорівневу модель баз даних, і вони не покликані замінити вже існуючі бази даних. Це просто інструментарій, мета якого - допомогти розробнику, забезпечуючи надійне збереження і маніпулювання XML-документами. Архітектура XML-СКБД подана на рис.4.4. Для реалізації запитів до XML-орієнтованих баз даних розроблено цілий ряд мов запитів, серед яких: Xpath, QL, YATL, Lorel, XQL. Найбільш вдалим на сьогодні вважається XQL. Мова XQL є природним розширенням синтаксису XSL і являє собою специфікацію для пошуку окремих елементів чи вузлів з відповідними характеристиками в документі. Запит складається з двох частин: оператор шаблона та оператор фільтра. XQL не має операторів конструювання. Замість них результат запиту визначається виразами шаблона. Мова XQL забезпечує обробку операторів порівняння, логічних операторів, наборів ключових слів, розширених кванторами спільності й існування, множинних операторів об'єднання і перетину. Повний список реалізованих на сьогодні XML-баз даних можна знайти на: http://www.rpbourret.com/xml/XMLDatabaseProds.htm. Серед найбільш відомих XML- рішень для збереження даних можна назвати: XML-сервер Tamіno від компанії Software AG (www.softwareag.com). Сервер Tamіno включає XML-СУБД, що дозволяє оперувати XML-об'єктами. Ця СУБД забезпечує доступ до всіх популярних типів даних, у тому числі і з традиційних СУБД, а також їхню конвертацію в XML-об'єкти. У Tamіno використана філософія відкритих СУБД, а звертання до нього можливі через стандартні інтерфейси: OLE DB, DCOM, ODBC і JDBC. Tamіno підтримує XML V.1.0, мову посилань XLL, таблиці стилів XSL і підмножину мови запитів XQL, концепцію простору імен XML, а для опису схем XML-даних використовується мова опису схем Tamіno (Tamіno Schema Language). У ядрі Tamіno також представлені засоби повнотекстового пошуку, що забезпечують пошук з урахуванням структури документа, що робить Tamіno особливо привабливим для Інтернет. СКБД Іpedo XML Database від компанії Іpedo (www.іpedo.com). В Іpedo XML Database використовується стандарт запитів W3C Xpath, що дозволяє робити запити до бази XML-документів безпосередньо в синтаксисі XML. Крім цього, ця СКБД містить у собі механізм XSLT, що поєднує доступ до даних і їх трансформацію в єдиний процес. До числа плюсів цього продукту варто віднести його роботу на J2EE-сумісних веб-серверах додатків під керуванням Wіndows 2000, Wіndows NT, Sun Solarіs і Red Hat Lіnux. Ця система здатна також здійснювати на XML-основі пошук і генерацію веб-сторінок, перетворювати документи XML у формати інших додатків (HTML чи WML). СКБД Extensіble Іnformatіon Server (eXcelon) від компанії Excelon (www.exceloncorp.com). У відмінності від більшості інших XML- СКБД, ця СКБД здатна працювати з окремими сегментами XML-документів, а не тільки з документами в цілому. Цей сервер був розроблений на базі об'єктної СУБД ObjectStore компанії Object Desіgn і забезпечує уніфіковане ведення даних у XML-форматі, витягаючи їх з різних джерел, конвертуючи в XML і зберігаючи у власному репозиторії (XML Store). XML-дані, збережені в репозиторії, індексуються для забезпечення ефективного доступу до них. Сервер eXcelon у першу чергу призначений для створення інтернет-додатків, він може бути підключений до web-сервера і забезпечувати генерацію динамічних сторінок. XQEngіne (www.fatdog.com) - це повнотекстова пошукова система для XML-документів. Вона дозволяє здійснювати пошук по колекції XML-документів, використовуючи як запит логічні вирази, складені з ключових слів, у комбінації з XQL-запитами. СКБД XMS (XML Management System) від компанії NeoCore (www.neocore.com). Кожний елемент XML зберігається в цій СКБД в природному вигляді зі збереженням ієрархії відносин. Система XMS забезпечує самоопис структури бази даних. Ця база даних автоматично індексується, а також містить широкі можливості розширення і модифікації. Мова запитів тут також базується на XQuery і Xpath і забезпечує пошук документів, їхніх фрагментів і окремих елементів. Cache - постреляційна СКБД американської компанії ІnterSystems (www.іntersystems.com) містить у собі багатовимірний сервер даних Cache для доступу до реляційних даних через SQL і сервер додатків Cache. Крім сумісності з попередніми продуктами ІnterSystems і з традиційними реляційними СКБД, комплекс Cash дозволяє автоматично відображати дані в XML-документи. Проекція об'єктів може бути також використана для формування DTD. XML-документи можуть бути автоматично трансформовані в об'єкти, для реалізації бізнес-логіки додатків. Система також дозволяє користувачам розробляти власні сервери чи створювати власні механізми XML-імпорту. XML-орієнтовані СКБД стають реальним доповненням до традиційних реляційних систем. Оскільки саме з їх допомогою стає можливим: • представлення складно структурованих даних; • виконання повнотекстового пошуку; • реалізація сховищ даних, тощо. Вони є гарним рішенням для збереження даних: • Корпоративних інформаційних порталів; • Каталогів; • Систем керування документами; • Журналів B2B-транзакцій та інш. 5. Використання Open Source СКБД На сьогоднішній день досить популярним є використання при створенні віртуальних організацій Open Source СКБД - тобто рішень з відкритим кодом. Це зумовлено тим, що в ряді невеликих проектів, де немає необхідності організації розподіленої БД та обсяги даних порівняно малі, використання таких продуктів є економічно білььш виправданим. Як приклади таких віртуальних організацій можна навести віртуальні магазини, віртуальні страхові компанії, та інш. Розглянемо можливості двох найбільш розповсюджених Open Source СКБД MySQL (www.mysql.com) і PostgreSQL (www.postgresql.org). В таблиці 4.1. наведено їх порівняння за рядом критеріїв. Таблиця 4.1. Порівняння Open Source СКБД Критерій MySQL <> PostgreSQL Поточна версія 4.1.0 - 7.2 Максимальний розмір бази близько 60 тис. таблиць і 5 млрд. записів теоретичний максимальний розмір таблиці - 8 млн. терабайт (однак кожна ОС має свої обмеження) < максимальний розмір бази не обмежений, максимальний розмір таблиці 60 терабайт на всіх ОС, максимальний розмір запису не обмежений Швидкість вважається однією з найшвидших СУБД на простих операціях (іnsert, select, update) > існують тести, що показують гарні результати на складних запитах (sub-select, group, vіew) Транзакції так (для типів таблиць BDB/ІnnoGB/Gemіnі ) < так Підзапити ні < так Представлення (vіew) ні < так Процедури потрібно писати бібліотеки на C, що імпортуються в СКБД < так (мови SQL, Pl/PgSQL, PL/Perl, PL/TCL, PL/Python) Тригери ні < так Посилальна цілісність даних ні < так Курсори ні < так Автореплікація даних так > ні, але легко реалізувати Додаткові функції FULLTEXT-індекси, пошук і підрахунок релевантності > - Операційні системи UNІX,Wіn32 > UNІX,Wіn32 Стабільність Відмінна = Відмінна Допомога і підтримка, документація Відмінна, списки розсилання, документація, форуми = Відмінна, списки розсилання, документація, форуми Проблеми в роботі не помічено > необхідно регулярно робити VACUUM ANALYZE для оптимізації швидкості, під час якого база блокується (в останній версії блокування знято); проблеми з експортом представлень, що використовують процедури Інструменти для моделювання - < Sybase PowerDesіgner Тип СКБД Реляційна < Постреляційна (можл. зберігання як елементів кортежа багатовимірних масивів та даних з визначеними користувачем типами) Як видно з таблиці, PostgreSQL має більше можливостей в тому, що стосується підтримки транзакцій, тригерів, процедур, ніж MySQL. Це в першу чергу обумовлено різними стратегіями розвитку двох СКБД - в MySQL це орієнтованість на удосконалення існуючих можливостей, тоді як в PostgreSQL - на підтримку широкого спектру можливостей, притаманних комерційним СКБД. У той же час, розробники MySQL анонсують підтримку цілого ряду покищо нереалізованих можливостей в наступних версіях своєї СКБД. Таким чином, якщо говорити про сучасний рівень цих двох СКБД, то можна відмітити, що MySQL з успіхом може використовуватися в маленьких і середніх централізованих системах, що вимагають високої швидкості, надійності при порівняно простих додатках. Тоді як PostgreSQL може використовуватися як досить швидка, безкоштовна альтернатива комерційним СУБД рівня Oracle в складних Інтернет (Інтранет) - системах. Література: 1. Ситник Н.В. Проектування баз і сховищ даних: Навч. Посібник. -К.: КНЕУ, 2004. -248с. 2. ANSI/NISO Z39.50-1995. Information Retrieval (Z39.50): Application Service Definition and Protocol Specification. Z39.50 Maintenance Agency Offical Text for Z39.50-1995, July 1995. 3. Булах Е.В. Средства доступа к базам данных в Internet и свободно доступная СУБД POSTGRES95. Центр Информационных Технологий. http://zeus.sai.msu.ru:7000/database/postgres95/index.shtml 4. Пуха Ю. Объектные технологии построения распределенных информационных систем: Системы Управления Базами Данных. 1997. №3. C.4-20. 5. Doug Barry. ODMG 2.0: A Standard for Object Storage. ODMG 2.0 builds on database, object and programming language standards to give developers portability and ease of use. Component Strategies - July 1998. www.odmg.org. 6. Марк Скардина. Модели хранения XML-данных: единственного варианта на все случаи нет. Oracle Magazine RE Январь/Февраль 2004 http://zeus.sai.msu.ru:7000/internet/xml/storage_models/ 7. Кимбро Стэйкин. Знакомство с естественными XML-базами данных. http://xml.com/pub/a/2001/10/31/nativexmldb.html 8. XML и технологии баз данных В. Веселов, А. Долженков 16.05.2000 Открытые системы, #05-06/2000. http://www.osp.ru/os/2000/05-06/076.htm 9. "ЧИП-УКРАИНА" 5/2003 Дмитрий ЛАНДЭ НА ГРАНИЦЕ СТИХИЙ http://www.visti.net/~dwl/art/xml/index1.html 10. Проектирование баз данных на основе XML Марк Грейвс - М: "Вильямс", 2002 г. 11. Справочное руководство по MySQL версии 4.1.0-alpha. http://ais.khstu.ru/MySQL/manual.ru_toc.html 12. Поль Дюбуа. MySQL: Пер. с англ.: -М.: Издательский дом "Вильямс", 2001. -816 с. Розділ 5. Технології і системи керування знаннями віртуальної організації 1. Основні поняття керування знаннями На сьогодні практично кожна організація чи її окремі працівники (особливо ті, що займаються аналітичною роботою) стикаються з однією і тією ж проблемою: інформації дуже багато - в базах даних, у старих звітах, в листах, на сайтах в Інтернет, у власних папках на комп’ютері, а от знайти потрібну досить складно. Доводиться непродуктивно витрачати надзвичайно багато часу на її пошук. Обстеження, проведене компанією Reuters серед 1300 міжнародних менеджерів, показало, що багато з них страждають від "синдрому інформаційної утоми". Для ефективної роботи їм необхідна інформація для знаходження якої доводиться опрацьовувати величезні обсяги даних. Так, 38% опитаних Reuters менеджерів стверджують, що "витрачають багато часу, намагаючись знайти потрібну інформацію". Тому значна увага провідними компаніями світу останнім часом приділяється так званому керуванню знаннями. Перш ніж пояснити, що розуміють під цим терміном, слід визначити, що ж таке "знання". Різницю між даними, інформацією і знаннями можна пояснити наступним чином. Дані - це новини, записи, відомості про ті чи інші процеси і т.п.; інформація - це відібрані і проструктуровані дані, що можуть використовуватися для прийняття рішень по певній задачі; знання - є результатом переробки інформації, містять певну ідею в контексті того, як і де використовувати інформацію. Енциклопедичний словник Webster дає цілий ряд визначень поняття "знання" : knowledge (знання) - 1) розуміння, що здобувається фактичним досвідом (наприклад, знання якогось ремесла). 2) А: стан поінформованості про щось чи володіння інформацією, Б: діапазон інформованості чи поінформованості. 3) акт розуміння: ясне сприйняття істини. 4) щось зрозуміле і тримається в розумі. Знання - це зв'язки і закономірності предметної області, отримані в результаті практичної діяльності. За формою знання поділяються на неявні і явні. Явні знання можуть бути формалізовані у виді документів, баз знань, протоколів, норм, правил. Неявні знання, або приховані - існують у свідомості спеціалістів - звички, шаблони мислення і поводження, інтуїція - те, що вони знають, але не можуть виразити словами. Існують різні визначення того, що слід розуміти під керуванням знаннями: Визначення Gartner Group: "Керування знаннями - це дисципліна, що забезпечує інтегрований підхід до створення, збору, організації і використання інформаційних ресурсів підприємства і доступу до них. Ці ресурси включають структуровані БД, текстову інформацію, таку, як документи, що описують правила і процедури, і, що найбільш важливо, неявні знання й експертизу, що знаходяться в головах співробітників" [1]. Визначення ІDC: "Керування знаннями - це формальний процес, що складається в оцінці організаційних процедур, людей і технологій і в створенні системи, що використовує взаємозв'язки між цими компонентами з метою надання потрібної інформації потрібним людям у потрібний час, що приводить до підвищення продуктивності" [2]. Керування знаннями (Knowledge Management - KM) - це встановлений в організації порядок роботи з інформаційними ресурсами для збору знань, полегшення доступу до них і повторного їх використання за допомогою сучасних інформаційних технологій. Виділяють наступні основні процеси керування знаннями: 1. виявлення знань; 2. зберігання; 3. використання. Існує також поняття "інтелектуальності бізнесу" - busіness іntellіgence - BІ. Його слід відрізняти від "керування знаннями". Під busіness іntellіgence зазвичай розуміють засоби, що дають кінцевому користувачу можливості доступу до структурованих даних, і наступного їх аналізу з метою прогнозування і прийняття рішень. Технологія керування знаннями організації включає дві сторони: 1. Керування знаннями як організаційна функція, що регулює порядок виявлення, нагромадження і використання знань в організації; 2. Система керування знаннями як технології та інструментальні засоби, що забезпечують процеси організаційної функції. Керування знаннями як організаційна функція - це політика компанії у відношенні керування знаннями, тобто різноманітні управлінські важелі і процедури, що дозволяють компанії виявляти та зберігати знання для того, щоб ефективно їх використовувати в сьогоденні і майбутньому. Технології допомагають здійснити ці управлінські процедури, але не можуть їх замінити. Системи керування знаннями з одного боку, дозволяють мінімізувати рутинну роботу, пов’язану зі знаходженням та накопиченням знань, а з іншого боку - зафіксувати адміністративні регламенти (зробити їх обов'язковими для виконання) на рівні технології. Всі процеси керування знаннями можуть бути в тій чи іншій мірі підтримані інформаційними технологіями. Вибір тих чи інших технологій залежить від конкретної організації, вже наявних в ній інформаційних систем та задач, які необхідно вирішувати. На сьогодні організаціями застосовується широкий спектр інформаційних систем, які поодинці чи у певному поєднанні дозволяють керувати знаннями - табл. 5.1. Таблиця 5.1. Системи керування знаннями Системи, що забезпечують накопичення даних і знань • бази і сховища даних (data warehouse); • традиційні системи автоматизації • інформаційно-пошукові системи; • системи електронної пошти; • системи електронного документообігу; • системи керування потоками робіт • системи керування контентом сайту • портали знань • семантичні мережі, що зберігають значення документів Засоби, що забезпечують "добування" знань • Пакети статистичного аналізу; • Засоби Data Mining • Засоби Text Mining Спеціалізовані системи керування знаннями • системи представлення знань і бази знань; • системи категоризації, пошуку і навігації накопичених знань. Технології керування знаннями на сьогодні проходять етап становлення, але очевидною є необхідність їх використання для віртуальних організацій. Саме для таких компаній, в яких часто змінюється склад колективів, особливо актуальним є використання ефективних механізмів пошуку знань, а також збереження і накопичення знань, з тим, щоб у подальшому використовувати їх у новому складі чи для нових задач. Серед задач віртуальної організації, які можуть бути ефективно підтримані технологіями керування знаннями, можна назвати: • Розробка процесів, необхідних для здійснення виробництва; • Прогнозування ринкових можливостей щодо розміру необхідних ресурсів та постійне коригування їх; • Маркетинг запланованого товару (послуги); • Укладання контрактів на необхідні ресурси; • Ревізія забезпечених послуг у термінах якості; • Постійний бенчмаркінг використовуваних ресурсів та переукладання договорів де це необхідно та інш. 2. Зберігання та представлення знань 2.1. Вимоги до представлення знань Традиційно вважається, що знання, аналогічно до того, як дані зберігаються в базі даних, мають зберігатися в базі знань. Виділяють декілька основних вимог до представлення елементів знань у базі знань: Внутрішня інтерпретуємість (поіменованість) - кожна інформаційна одиниця повинна мати унікальне ім'я, по якому її знаходять. Крім самих інформаційних одиниць в базі знань має зберігатися їх опис (метадані). В даний час СКБД забезпечують реалізацію внутрішньої інтерпретуємості. Структурованість - повинна існувати можливість довільного встановлення між окремими інформаційними одиницями відносин типу "частина - ціле", "рід - вид" чи "елемент - клас". Зв’язність - між інформаційними одиницями повинна бути передбачена можливість встановлення зв'язків (відносин) різного типу. Семантика відносин може носити декларативний чи процедурний характер. Наприклад, декларативні відносини: "одночасно", "причина - наслідок", "бути поруч". Якщо між двома інформаційними одиницями встановлене відношення "аргумент - функція", то воно характеризує процедурне знання, зв'язане з обчисленням визначених функцій. Також розрізняють відносини структуризації, функціональні, каузальні і семантичні відносини. За допомогою перших задаються ієрархії інформаційних одиниць, другі несуть процедурну інформацію, що дозволяє знаходити (обчислювати) одні інформаційні одиниці через інші, треті задають причинно-наслідкові зв'язки, четверті відповідають всім іншим відносинам. Семантична метрика - на множині інформаційних одиниць у деяких випадках корисно задавати відношення, що характеризує ситуаційну близькість інформаційних одиниць, тобто силу асоціативного зв'язку між інформаційними одиницями. Його можна було б назвати відношенням релевантності для інформаційних одиниць. Відношення релевантності при роботі з інформаційними одиницями дозволяє знаходити знання, близькі до вже знайденого. Активність - з моменту появи ЕОМ і поділу використовуваних у ній інформаційних одиниць на дані і команди створилася ситуація, при якій дані пасивні, а команди активні. Усі процеси, що протікають в ЕОМ, ініціюються командами, а дані використовуються цими командами лише в разі потреби. Для ІС ця ситуація не прийнятна. Як і в людини, у ІС актуалізації тих чи інших дій сприяють знання, що маються в системі. Таким чином, виконання програм у ІС повинно ініціюватися поточним станом інформаційної бази. Поява в базі фактів чи описів подій, встановлення зв'язків може стати джерелом активності системи [6]. Сукупність засобів, що забезпечують роботу зі знаннями, утворює систему керування базою знань (СКБЗ). В даний час не існує систем керування базами знань, у яких повною мірою були б реалізовані вищеописані вимоги до представлення знань. Системою представлення знань (СПЗ) називають засоби, що дозволяють описувати знання про предметну область за допомогою мови представлення знань, організовувати збереження знань у системі (нагромадження, аналіз, узагальнення й організація структурованості знань), вводити нові знання і поєднувати їх з наявними, виводити нові знання з наявних, знаходити необхідні знання, усувати застарілі знання, перевіряти несуперечність накопичених знань, здійснювати інтерфейс між користувачем і знаннями. Центральне місце в СПЗ займає мова представлення знань (МПЗ). Можливості МПЗ визначаються моделлю представлення знань, що покладена в її основу (іноді ці поняття ототожнюють). 2.2. Моделі представлення знань Модель представлення знань є формалізмом, покликаним відобразити статичні і динамічні властивості предметної області (ПО), тобто відобразити об'єкти і відносини ПО, зв'язки між ними, ієрархію понять ПО і зміну відносин між об'єктами. Модель представлення знань може бути універсальною (застосовною для більшості ПО) чи спеціалізованою (розробленою для конкретної ПО). Найчастіше використовуються наступні основні універсальні моделі представлення знань: • семантичні мережі; • фрейми; • логічні моделі; • продукційні системи й інші. Семантичні мережі. Мережні моделі формально можна задати у вигляді H = <І, C1, C2, ..., Cn, Г>. І - множина інформаційних одиниць; C1, C2, ..., Cn - множини типів зв'язків між інформаційними одиницями; Г задає зв'язки між інформаційними одиницями, що входять в І, з заданого набору типів зв'язків. Залежно від типів зв'язків, використовуваних у моделі, розрізняють: класифікуючі мережі, функціональні мережі і сценарії. У класифікуючих мережах, використовуються відносини структуризації. Такі мережі дозволяють у базах знань вводити різні ієрархічні відносини між інформаційними одиницями. Функціональні мережі характеризуються наявністю функціональних відносин. Їх часто називають обчислювальними моделями, тому що вони дозволяють описувати процедури "обчислень" одних інформаційних одиниць через інші. У сценаріях використовуються каузальні відносини, а також відносини типів "засіб - результат", "знаряддя - дія" і т.п. Якщо в мережній моделі допускаються зв'язки різного типу, то її називають семантичною мережею. Фреймові моделі. На відміну від моделей інших типів у фреймових моделях фіксується тверда структура інформаційних одиниць, що називається протофреймом. У загальному випадку вона виглядає в такий спосіб: (Ім'я фрейму: Ім'я слота 1(значення слота 1) Ім'я слота 2(значення слота 2) . . . . . . . . . . . . . . . . . . . . . Ім'я слота N (значення слота N)). Значенням слота може бути практично що завгодно (числа чи математичні співвідношення, тексти природною мовою чи програми, правила виведення чи посилання на інші слоти даного фрейму чи інших фреймів). Як значення слота може виступати набір слотов більш низького рівня. Фрейму і слотам присвоюють конкретні імена і заповнюють слоти. Таким чином, із протофреймів будують фрейми-екземпляри. Наведемо приклад протофрейма: (Список працівників: Прізвище (значення слота 1); Рік народження (значення слота 2); Спеціальність (значення слота 3); Стаж (значення слота 4)). Фрейм - екземпляр може мати наступний вигляд: (Список працівників: Прізвище (Попов - Сидоров - Іванов - Петров); Рік народження (1965 - 1946 - 1925 - 1937); Спеціальність (слюсар - токар - токар - сантехник); Стаж (5 - 20 - 30 - 25)). Зв'язки між фреймами задаються значеннями спеціального слота з ім'ям "Зв'язок". Логічні моделі. В основі моделей такого типу лежить формальна система, що задається четвіркою виду: M = <T, P, A, B>. Множина T є множиною базових елементів різної природи, наприклад слів з деякого обмеженого словника, деталей дитячого конструктора, що входять до складу деякого набору і т.п. Важливо, що для множини T існує деякий спосіб визначення належності чи неналежності довільного елемента до цієї множини. Процедура такої перевірки може бути будь-яка, але за кінцеве число кроків вона повинна давати позитивну чи негативну відповідь на питання, чи є x елементом множини T. Позначимо цю процедуру П(T). Множина P є множиною синтаксичних правил. За ними з елементів T утворюють синтаксично правильні сукупності. Наприклад, зі слів обмеженого словника будуються синтаксично правильні фрази, з деталей дитячого конструктора за допомогою гайок і болтів збираються нові конструкції. Декларується існування процедури П(P), за допомогою якої за кінцеве число кроків можна одержати відповідь на питання, чи є сукупність X синтаксично правильною. У множині синтаксично правильних сукупностей виділяється деяка підмножина A. Елементи A називаються аксіомами. Як і для інших складових формальної системи, повинна існувати процедура П(A), за допомогою якої для будь-якої синтаксично правильної сукупності можна одержати відповідь на питання про належність її до множини A. Множина B є множиною правил виведення. Застосовуючи їх до елементів A, можна одержувати нові синтаксично правильні сукупності, до яких знову можна застосовувати правила з B. Так формується множина виведених у даній формальній системі сукупностей. Якщо мається процедура П(B), за допомогою якої можна визначити для будь-якої синтаксично правильної сукупності, чи є вона виведеною, то відповідна формальна система називається розв'язною. Саме правила виведення є найбільш складноюскладовою формальної системи. Для знань, що входять у базу знань, можна вважати, що множину A утворять всі інформаційні одиниці, що введені в базу знань, а за допомогою правил виведення з них виводяться нові похідні знання. Продукційні моделі. У загальному випадку під продукцією розуміється вираз наступного виду: (і); Q; P; AЮВ; N. Де: і - ім'я продукції, за допомогою якого дана продукція виділяється з усієї множини продукцій; Q - характеризує сферу застосування продукції; AЮB - ядро продукції, - інтерпретація ядра продукції може бути різною, зазвичай воно читається: ЯКЩО А, ТО В; Р - умова застосовності ядра продукції, зазвичай Р є логічним виразом (предикат) - коли Р приймає значення "істина", ядро продукції активізується, якщо Р "не істина", то ядро продукції не може бути використане; N - описує післяумови продукції - дії і процедури, які необхідно виконати лише в тому випадку, коли ядро продукції реалізувалося. Якщо в пам'яті системи зберігається деякий набір продукцій, то вони утворюють систему продукцій. У системі продукцій повинні бути задані спеціальні процедури керування продукціями, за допомогою яких відбувається актуалізація продукцій і вибір для виконання тієї чи іншої продукції з числа актуалізованих. 3. Виявлення знань з даних - Data Mining Для автоматизованого виявлення знань з вже існуючих накопичених і структурованих даних на сьогодні широко використовуються так звані методи Data Мining. За визначенням спеціалістів SAS Institute: Data Мining (DM) — це процес виділення (selecting), дослідження і моделювання великих обсягів даних для виявлення невідомих до цього структур (patterns) з метою досягнення переваг у бізнесі. Синонімом терміну Data Мining є термін "інтелектуальний аналіз даних". Згідно з [3], DM складається з двох стадій: 1. Виявлення закономірностей, або вільний пошук (Discovery) ; 2. Використання виявлених закономірностей для передбачення невідомих значень - прогностичне моделювання (Predictive Modeling). Можлива також третя стадія - аналіз виключень (Forensic Analysis), призначений для виявлення і тлумачення аномалій у знайдених закономірностях. Усі методи Data Мining підрозділяються на дві великі групи за принципом роботи з вхідними навчальними даними (рис.5.1). Методи безпосереднього використання навчаючих даних (міркувань на основі аналізу прецедентів) передбачають, що вхідні дані можуть зберігатися в явному деталізованому вигляді і безпосередньо використовуватися для прогностичного моделювання і/або аналізу винятків. Головною проблемою цієї групи методів є утрудненість їхнього використання на великих обсягах даних. При використанні даної групи методів стадія вільного пошуку відсутня. Методи аналізу на основі формалізованих закономірностей - інформація спочатку витягається з первинних даних і перетворюється в деякі формальні конструкції (їхній вигляд залежить від конкретного методу - можуть бути або "прозорими", або "чорними шухлядами"). Далі ці конструкції використовуються для прогностичного моделювання й аналізу виключень. Для розв’язання задач прогнозування, які складають 75% сьогоднішнього застосування Data Mining, найчастіше використовуються класичні методи статистичного аналізу. Існує цілий ряд спеціально розроблених програмних продуктів, що реалізують ті чи інші методи Data Mining. Наприклад: Статистичні пакети STATGRAPHICS, SPSS, STATISTICA та SAS для вирішення ряду аналітичних задач в сфері бізнесу та фінансів. В програмних пакетах NeuroPro та WinNet реалізовані нейромережеві алгоритми. В популярному пакеті WizWhy використовується алгоритм обмеженого перебору для формування системи if-then правил тощо. В таблиці 5.2. наведено використання тих чи інших методів у деяких популярних пакетах. Таблиця 5.2. Порівняльна характеристика аналітичного програмного забезпечення Характеристика SPSS PolyAnalyst Deductor Excel Neural Package Фірма-продавець SPSS, Inc. Megaputer Intelligence Лабораторія BaseGroup Клас Універсальний пакет аналізу даних Напівуніверсальний пакет аналізу Напівуніверсальний пакет аналізу Нейроімітатор (add-ins for Microsoft Excel) Методи набір методів математичної статистики та методів Data Mining • нейронні мережі, МГУА ; • еволюційне прогр.; • n- мірний аналіз розп.; • n – мірний кластери затор; • метод “найближчого сусіда” та генетичних алгоритмів; • транзакційний кластери затор; • багатопараметрична лінійна регресія; • класифікація за цільовою змінною; • “дерева рішень”; • методи статистики • багатошарові нейронні мережі; • OLAP - багатомірний аналіз даних; • самоорзанізуючі карти; • дерева рішень; нейронні мережі (багатошаровий персептрон; карти Кохонена) Модулі • SPSS Base • Regression Models • Advanced Models • Tables, Amos • AnswerTree • Categories, Clemetine • Conjoint, Data Entry • Extract Test • GOLDMineR • SamplerPower • SPSS Missing Value Analysis • Trends • SPSS Data Mining • Find Laws Algorithm; • PolyNet Predictor Algorithm; • Find Dependencies Algorithm; • Market Basket Analysis; • Linear Regression; • Cluster Algorithm; • Classify Algorithm; • Disciminate; • Decision Trees; • Summary Statistic • Cube Analyzer - багатомірний аналіз даних; • RawData Analyzer - передобробка даних; • Neural Analyzer - багатошарові нейронні мережі; • SOMap Analyzer - аналіз на основі самоорганізуючих карт; • Tree Analyzer - дерева рішень. • Winnet 3.0. – програма-емулятор нейромережі для побудови нелінійних моделей; • Kohonen Map 1.0. - програма для побудови самоорганізуючих карт Кохонена. Легкість використання вимагає знань статистиски; “майстер” для вибраного методу формування правил для вибраного методу “майстер підключення до джерела даних”; “майстер навчання” Загрузка даних – область Excel-sheet; “майстер навчання” Формат даних csv еxcel, dbase, csv, mdb еxcel,word,html,xml,sql, dbase, csv,diff, sylk,txt еxcel майстер “майстер” для конкретного методу Формувавання правил з оцінками точності за вибраним модулем “майстер підключення до джерела даних”; “майстер навчання” “майстер навчання” вибір методів: Вибір методів Необхідні знання щодо можливостей використання методів Бажані знання щодо можливості та доцільності використання методів Для вирішення різного класу задач використовуються різні методи – на вибір користувача. На вибір користувача вихідні функції – лінійна, гіперболічний тангенс (алгоритм – backpropagation) Візуалізація Гістормами, двомірні, трьохмірні графіки Гістормами, двомірні, трьохмірні графіки Графік виходів мережі Зображення структура сформованої мережі Основними стандартами, якими мають керуватися розробники Data Mining-систем є: • CRISP-DM - CRoss Industry Standard Process for Data Mining; • PMML - Predictive Model Markup Language . CRISP-DM - міжгалузевий стандарт процесів Data Mining - http://www.crisp-dm.org/index.htm - визначає основні етапи роботи Data Mining-систем (модель процесу добування даних). Використання даного стандарту має забезпечити швидшу, більш дешеву, більш надійну і більш керовану розробку систем Data Mining. PMML - мова розмітки прогнозних моделей - XML-основана мова, яка забезпечує швидкий і простий шлях для визначення прогнозних і загальних моделей Data Mining, що використовуватимуться для обміну між додатками компаній. Розроблена Data Mining Group (DMG) - http://www.dmg.org/. Структура моделей описана в DTD, що зветься PMML DTD (можна переписати з сайту) і використовується всіма компаніями, що беруть участь в процесі. Одна чи більша кількість моделей може міститися в PMML документі. Загальна структура PMML документа наступна: <?xml version="1.0"?> <DOCTYPE PMML PUBLIC "PMML 1.1" "pmml-1-1.dtd"> <PMML version="1.1"> ... </PMML> Керуючись стандартом PMML можна створювати моделі в рамках додатку однієї компанії, і використовувати їх в додатках інших компаній (для візуалізації, аналізу, оцінки чи інш.) віртуальної організації. Серед інших стандартів можна назвати: • OMG Common Warehouse Metamodel (CWM)- http://www.omg.org/ (Глава 14 присвячена Data Mining); • ISO/IEC JTC1 SC32 WG4: SQL/MM Part 6 Data Mining www.acm.org/sigmod/record/issues/0112/standards.pdf ; • The Java Data Mining standard (JDM) - www.jcp.org/jsr/detail/73.jsp; • The OLE DB for Data Mining standard of Microsoft www.microsoft.com/data/oledb/. 4. Виявлення знань з текстів - Text Mining Технологія Data Mining передбачає роботу лише зі структурованими даними, що зберігаються у базах і сховищах даних, або ж у файлах певної структури. У той час як переважну частину інформації, необхідної для продуктивної і безперебійної роботи практично будь-якої організації на сьогодні складають електронні текстові документи. Так, великі обсяги текстової інформації передаються за допомогою систем електронної пошти, використовуються в системах електронного документообороту, або в системах керування потоками робіт, чи просто розміщуються на порталах компаній. Допомогти виявити знання із текстової інформації покликана технологія Тext mіnіng. Тext mіnіng (ТМ) - процес видобування знань з текстових неструктурованих даних, що передбачає аналіз великих обсягів текстової інформації, пошук тенденцій, шаблонів і взаємозв'язків, здатних допомогти в прийнятті стратегічних рішень. Основними елементами Text Mіnіng є сумаризація (summarіzatіon), тематичний пошук (feature extractіon), кластеризація (clusterіng), класифікація (classіfіcatіon), відповідь на запити (questіon answerіng), тематичне індексування (thematіc іndexіng) і пошук по ключових словах (keyword searchіng). Також у деяких випадках використовують засоби підтримки і створення офтаксономії (oftaxonomіes) і тезаурусів (thesaurі). Виробники програмного забезпечення поєднують більшість засобів Text Mіnіng в єдиний програмний комплекс. Існує цілий ряд програмних продуктів, що реалізують технологію Text Mіnіng. Це, наприклад, ІBM Іntellіgent Mіner for Text, Oracle ІnterMedіa Text, Megaputer Text-Analyst та інш. Cеред вітчизняних розробок даного напрямку можна назвати систему пошуку й аналітичної обробки інформації Galaktіka-Zoom - демонстраційну версію системи можна подивитись за адресою http://zoom.galaktika.ru/tst.asp . 5. Спеціалізовані системи керування знаннями 5.1. Типи систем основаних на знаннях Велике різноманіття систем, основаних на знаннях, що існують на даний час можна прокласифікувати за різними ознаками: 1) За способом використання • Індивідуального використання; • Колективного використання; 2) За рівнем автоматизації процесів керування знаяннями • Інформаційні Системи Знань • Інструментальні засоби Керування Знаннями • Динамічні Системи Знань Інформаційні Системи Знань (ІKS) зазвичай зберігають знання та керують ними на основі підходу "про всяк випадок потрібно". Знання збираються та в довільній формі зберігаютьсяз тим, що, можливо, вони знадобляться комусь в майбутньому. Типові приклади таких систем: Дані соціологічних досліджень (Case study), бази даних Досвіду (Experiens), бази даних Кращих Практик (Best Practice), Каталоги Експертів (Expert Diectories) тощо. Інструментальні засоби Керування Знаннями (KMT) - використовують інформацію і знання, що уже збережені, щоб відповісти на питання, стимулювати розуміння, і навіть визначити місце розташування поки ще недоступного знання. Типові приклади включають: засоби пошуку, портальні додатки, і інші засоби фільтрування інформації чи знань. Динамічні Системи Знань (DKS) - системи, що виявляють за вимогою, "у контексті", своєчасну, і доречну інформацію і знання від людей, коли це необхідно, фіксують їх, а також дозволяють видавати їх у відповідь на ідентифіковану потребу, спільно використовувати існуючі знання і забепечують створення нових знань. До прикладів цього виду систем можна віднести деякі типи інструментальних засобів співробітництва, а такождеякі спеціалізовані системи керування знаннями. 3) За використовуваними технологіями: • Системи, основані на Інтернет-порталах; • Системи, основані на системах електронного документообороту; • Системи, що використовують Text Mining (аналітичні системи) або Data Mining. На сьогоднішній день компанії-виробники програмного забезпечення пропонують рішення для керування знаннями в яких у тій чи іншій мірі можуть бути поєднані вищеперераховані основні технології. 5. 2. Використання порталів для керування знаннями Портали знань підприємства (enterprіse knowledge portal - EKP) на сьогодні надзвичайно популярні в Іnternet. Корпоративний портал може вирішувати декілька задач, актуальних з точки зору керування знаннями: 1. Забезпечення співробітників необхідною інформацією 2. Забезпечення контактів з необхідними людьми Тобто на порталі може бути здійснене не лише відповідне представлення, каталогізація знань, надання можливості пошуку необхідної інформації, але й можливість персонального обміну знаннями. Слід зазначити, що критичним моментом використання порталу для керування знаннями є каталогізація знань. Тому з цією метою можуть використовуватися спеціалісти, на яких покладатимуться функції категоризації (всі подібні документи повинні мати одну категорію), створення професійного тезаурусу в процесі каталогізації та пошуку потрібних документів за необхідності. Технологічні можливості, використовувані на порталі можуть в значній мірі відрізнятися залежно від потреб компанії. Як приклади компаній, що використовують корпоративні портали для керування знаннями є міжнародні консалтингові компанії, траснаціональні концерни (Shell, Motorola, General Motors), гіганти ІТ-індустрії (ІBM, Compaq, Dell, Oracle, SAP). Систематизовані знання з великих сховищ передового досвіду доступні співробітникам цих фірм із будь-якої крапки світу, і їхні менеджери та фахівці мають можливість у потрібний момент "підглянути" успішний досвід своїх колег з різних галузей і підрозділів. А також при необхідності зв'язатися з визнаними експертами з конкретної предметної області. Існує велике різноманіття програмних продуктів від різних розробників, зокрема розробників groopware, які підтримують створення порталів знань підприємств. Як приклади, можна назвати рішення від компаній Lotus, Mіcrosoft, а також Hummіngbіrd (див. п.5.3). Продукти Lotus для керування знаннями Програма компанії Lotus (http://www.lotus.com) Knowledge Dіscovery System (KDS) направлена на те, щоб засобами Іnternet-технологій утворювати віртуальне середовище, де можна здійснювати пошук експертів, носіїв знань і тих документів, у яких корпоративні знання відбиті з найбільшою повнотою. Lotus Knowledge Dіscovery System реалізує формулу керування знаннями "Люди, Місця й Інформація" (People, Places and Thіngs). Як "Місця" використовуються портали знань і спільної роботи, а під "Інформацією" маються на увазі засоби каталогізації контенту. У своєму нинішньому вигляді KDS складається з двох компонентів: портал знань Lotus K-statіon і сервер керування знаннями Lotus Dіscovery Server. Lotus K-statіon - корпоративний портал знань, що забезпечує засоби створення індивідуальних профілів (віртуальних робочих місць), засоби керування персональними даними й інформацією. Lotus Dіscovery Server збирає, аналізує, класифікує структуровану і неструктуровану інформацію для виявлення зв'язків між змістом, людьми, темами і користувачами в організації. Серед ключових можливостей сервера: • Візуальний пошук знань. Пошук і перегляд інформації та даних про експертів за допомогою простої у роботі інтегрованої Карти знань. Можна одночасно переглядати інформацію про документи, людей, місця, категорії і їхні взаємозв'язки. • Пошук повних відповідей. Ефективний пошук у всій інтрамережі і за її межами, включаючи пошук на Web-сайтах, у системах типу back-end, у додатках Lotus Domіno і багатьох інших місцях. Упорядкування результатів пошуку по релевантності. • Пошук експертів. Можна з'ясувати, хто є експертом у конкретній області, одержуючи цю інформацію у вигляді профілю інтересів, навичок і досягнень. • Автоматичне створення і відновлення Карти знань і профілів експертів. Dіscovery Server виконує також Knowledge Audіt - аудит знань - перегляд і ранжування документів по частоті звертань. Основна увага в рішенні компанії Lotus, таким чином приділена організації групової роботи й обміну інформацією між співробітниками. Платформа керування знаннями Mіcrosoft Як зазначається на сайті компанії Mіcrosoft (www.microsoft.com), щоб зробити можливим керування знаннями, необхідно мати дві базові системи: 1. систему спільної роботи й обміну повідомленнями; 2. корпоративну інтрамережу. Головні задачі системи керування знаннями пропонується вирішувати на основі наступних продуктів : 1. організація спільної роботи - Offіce 2000 і Exchange Server. 2. керування вмістом - Exchange, Mіcrosoft Sіte Server і Offіce. 3. аналіз - Mіcrosoft Access і Mіcrosoft Excel, Mіcrosoft OLAP Servіces 4. збір, пошук і доставка - Sіte Server 3.0. 5. відстеження і документообіг - агенти папок і об'єкти маршрутизації Exchange Конкурентом Exchange Server як засобу організації спільної роботи може бути також Microsoft SharePoint Portal Server (MS SPP Server), який дозволяє створити універсальний корпоративний портал, є засобом керування та маршрутизації документів і могутньою пошуковою машиною. У ньому реалізовані практично усі функції Exchange, крім поштового сервера. Основна увага в підході Microsoft до керування знаннями зосереджена на керуванні документами та їх пошукові. 5.3. Спеціалізовані системи керування знаннями від світових лідерів Серед світових лідерів в галузі розробки спеціалізованих систем керування знаннями можна назвати компанії: Hummіngbіrd (http://www.hummіngbіrd.com), Convera (раніше Excalіbur, http://www.convera.com, http://www.convera.su/ru/ ), Cognіtіve Technologіes (http://www.cognіtіve.ru). Розглянемо основні особливості пропонованих ними систем. Hummіngbіrd - технології Fulcrum Продукти Hummіngbіrd (http://www.hummіngbіrd.com) по керуванню документами і знаннями підтримують широкий спектр апаратно-програмних платформ, роботу з різними джерелами даних (включаючи web-контент) і більш ніж 200 форматами документів. Ці продукти доступні на 20 різних мовах (включаючи російську), що значно перевершує можливості всіх інших постачальників. На сьогодні більш ніж 5000 організацій в усьому світі використовують продукти Hummіngbіrd для керування своїми інтелектуальними активами. Всі продукти компанії Hummіngbіrd цілком інтегровані в стратегію корпоративного інформаційного порталу (див. п.5.2). Логіка роботи з корпоративним порталом полягає в наступному. Користувач за допомогою броузера звертається до HTML-сервера, через який виконується доступ до внутрішньокорпоративних і зовнішніх ресурсів (рис.5.2). При цьому у вузькому лівому вікні екрана розміщається ієрархічний зміст доступних засобів, а праве є вікном для інформаційного обміну. Склад засобів, підтримуваних даним порталом: системи керування документами (CyberDOCS, Documentum і ін.), поштові служби (Lotus Notes, MS Exchange), ERP-системи (SAP R/3), системи керування знаннями (Fulcrum), а також різноманітні сховища даних і OLAP-системи. Ознайомитись з можливостями Hummingbird EIP можна за адресою http://eip.hummingbird.com/ Користувач може також створювати власні папки, у яких він формує власні індивідуальні інтерфейси для інтерактивного спілкування з зовнішніми ресурсами (у тому числі і Web-серверами). Це досягається за допомогою спеціальних програмних компонентів E-Clіp, що забезпечують взаємодію порталу з конкретними ресурсами і додатками, а також набору для розробника E-CLІ Developer Kіt, за допомогою якого можна створювати власні програми. Реалізована підтримка обміну знаннями між співробітниками щодо загального списку "обраних" Web-ресурсів - користувач у будь-який момент може поставити оцінку корисності конкретного сервера і записати свої коментарі. Таким чином, співробітник може орієнтуватись в цих ресурсах, спираючи на думку своїх колег. Клієнт може також запустити механізм фонового опитування й індексації цікавлячих його серверів із різноманітними варіантами автоматичної фільтрації й обробки одержуваних даних. Технології Fulcrum у даний час реалізовані в двох основних продуктах: SearchServer 5.0 і KnowledgeServer 4.0. SearchServer - реалізує функції індексування і пошуку текстової інформації з застосуванням паралельної обробки даних, що служить ядром усього сімейства. Даний продукт призначений у першу чергу для вбудовування в різні користувацькі додатки. Однак у нього є і користувацький інтерфейс, що забезпечує перегляд документів за допомогою засобу Fulcrum FullVіew. Технологія повнотекстового пошуку Fulcrum WordSense, основана на семантичних мережах, автоматично перетворює запити на природних мовах у логічну розширену форму. Архітектура даних SearchServer нагадує реляційну базу даних, де інформація структурується за допомогою таблиць, кожен рядок у який відповідає документу чи об'єкту. Однак на відміну від традиційних СУБД SearchServer не зберігає документи у своїх таблицях фізично, створюючи лише їхній індекс. Адміністрування виконується за допомогою графічного засобу SearchServer Admіnіstrator. Тобто, інформація з різних джерел не завантажується в спеціальну "систему керування знаннями", а навпаки, на мережу джерел накладається єдина інформаційно-пошукова система, що забезпечує прозорий пошук і категоризацію документів. Для взаємодії з додатками незалежних розробників існує програмний інтерфейс спеціальною мовою запитів SearshSQL, реалізований на базі протоколів ODBC і JDBC. Для макетування, розробки і розгортання рішень на базі SearchServer можна використовувати інструмент SearchBuіlder, сумісний з такими популярними середовищами, як Vіsual Basіc, Vіsual C++ і Java. KnowledgeServer продукт, що вирішує наступні основні задачі: • наскрізний пошук інформації з безлічі джерел даних незалежно від їхнього формату; • інтуїтивний пошук документів, аналогічних заданому шаблону; • представлення всіх інформаційних ресурсів підприємства у виді єдиного систематизованого ієрархічного змісту (Enterprіse Table of Contents); • автоматичне відстеження надходження нових документів по заданих темах за допомогою спеціальних агентів - ProActіve Agents; • автоматичне створення анотацій і категоризація документів. Масштабуєма архітектура допускає використання декількох серверів Fulcrum, до яких підключені як робочі місця клієнт-серверного ПО, так і "тонкі" клієнти на основі Web-броузера. Працює сервер Fulcrum у середовищі Wіndows NT, але може також звертатися до даних, розташованим на інших платформах, таких як UNІХ. Convera RetrievalWare (RW) Для керування знаннями, представленими в текстовому вигляді компанія Convera (http://www.convera.com, http://www.convera.su/ru/) пропонує програмний продукт RetrіevalWare (RW) з набором додаткових сервісних програм. Сімейство продуктів RW забезпечує пошук, аналіз і виділення інформації за допомогою задання користувачем пошукових запитів природною мовою до інформації, що зберігається як у неструктурованому виді так і формалізованих базах даних, розташованої як у локальній мережі організації так і в мережі Іnternet. Серед основних переваг RW наступні: 1. У RW реалізована можливість асоціативного пошуку на основі семантичної мережі. При цьому можна використовувати кілька семантичних мереж одночасно. Кожен користувач може створювати свої власні семантичні мережі на додаток до загальних. Таким чином забезпечується висока точність витягу інформації і автоматичне знаходження документів (чи записів в БД) не тільки по термінах заданих у запиті, але і по інших термінах, зв'язаним за змістом із заданим. 2. У RW реалізована технологія "нечіткого" пошуку, що дозволяє знаходити інформацію не на основі точного збігу запиту з даними, а на ступені подібності запиту, із вмістом у джерелах інформації. 3. RW має можливість включати в єдиний пошуковий простір як інформацію, збережену у файловій системі, так і в СУБД (Oracle, MS SQL, Sybase, Іnformіx, Teradata, ODBC DBS), поштових і корпоративних системах (MS Exchange, Lotus) і системах документообігу (StaffWare, Documentum, FіleNet Panagon). RW забезпечує користувачу перегляд документів більш ніж у 250 форматах, серед яких як широко відомі: doc, rtf, txt, pdf, html, так і специфічні формати, наприклад, формати САПР (dxf, dwg). В останній версії RW реалізована можливість пошуку інформації в архівах (ZІР, ...). Система фільтрації, що працює з використанням технології компанії "Outsіde Іn", забезпечує користувачу перегляд документів у їхньому рідному форматі. За допомогою RW можна організовувати доступ і індексувати віддалені сховища даних. Розвинута система безпеки, що успадковує властивості безпеки джерел інформації, у сукупності з Web-технологією дозволяє використовувати RW як засіб для створення територіально розподілених автоматизованих систем. 4. У RW реалізована можливість динамічної рубрикації всієї інформації, що надходить, на основі запитів, створених користувачами. Таким чином, значно скорочується час ознайомлення з новою інформацією, тому що вона представляється користувачу в структурованому виді, тобто попередньо розкладеною по рубриках. 5. У RW реалізована функція крос-мовного пошуку. Користувачу досить задавати питання рідною мовою, система на основі встановленої відповідності семантичних мереж для різних мов, повертає документи на інших мовах. В даний час проводяться роботи зі створення українського семантичного сервера. 6. RW може автоматично витягати атрибути з текстових документів визначеної структури і поміщати їх у СУБД (створювати формуляри для документів). 7. RW має необмежені можливості масштабування як по обсягах оброблюваної інформації, так і по кількості оброблюваних запитів. 8. RW має додаткові сервісні програми: - RW FіleRoom - для забезпечення роботи з паперовими архівами. - RW Іnternet Spіder - для пошуку в визначених областях Інтернет та Інтранет. - RW WebExpress - для обслуговування провайдерів, забезпечення пошуку по вмісту веб-сайта й електронної торгівлі через Інтернет. - RW CDExpress - для створення портативних баз даних на компакт-дисках, що містять пошуковий механізм RW. - ScreenіngRoom (SR) - засоби керування відео архівом, окрім візуального пошуку дозволяє виділяти з відеозображень текст, що відповідає субтитрам чи телетексту і перетворювати в текст супровідну аудіодоріжку. - RetrіevalWare SDK і Vіsual RetrіevalWare SDK - засоби для системних інтеграторів і розробників програмних систем, що використовують рішення компанії Convera - дозволяють розробляти додатковий функціонал до RW для забезпечення рішення задач конкретної організації. Серед користувачів продукції компанії "Convera": уряди - Росії, США, Великобританії, Ізраїлю, Польщі, Чехії, Угорщині і Швеції; патентні відомства - Швейцарії, Англії, США, Узбекистану і Росії (ФИПС); світові банки - Worldbank, ЦБ Росії, Внешторгбанк Росії, Swіss Bank; найбільші організації - НК "Юкос", "Лукойл-Пермь", NASA, Авиа космічний центр Росії, Boeіng Company, General Electrіc, Іntel, Ford Motor Company, AUDІ; СМИ - CNN, "The Fіnancіal Tіmes", "Медиа Міст", "ABC News"; фінансові компанії - Vіsa Іnternatіonal. Усього більше 5000 компаній, організацій і підприємств, розташованих у всіх країнах світу. Астарта Інформаційно-аналітична система "Астарта" розроблена компанією Cognіtіve Technologіes (http://www.cognitive.ru) у 2000 році і орієнтована на обробку текстових матеріалів, у першу чергу з ЗМІ, їх аналіз і складання звітів. Її основні функції: введення інформації з різних джерел, первинна обробка (приведення документів до єдиного формату), повнотекстова індексація, аналітична обробка (автоматичне рубрикування, груповання і т.п.), повний набір пошукових операцій, підготовка звітів для друку і/чи електронного розсилання. Система побудована на використанні семантичного аналізу текстів. Основний модуль "Астарти" розроблявся на основі технологій пакета "Євфрат" ( Останній являє собою комплекс засобів створення і ведення електронних архівів, як персональних, так і корпоративних, у яких документи представлені у виді файлів різних форматів: графічних, текстових (файли Mіcrosoft Word), структурованих (файли Mіcrosoft Excel) і змішаних, що складаються з декількох файлів. Одне з ключових нововведень системи - повнотекстова індексація інформації, що вводиться, і нормалізація індексу. Це означає, що при введенні, чи вірніше сказати, при реєстрації документів система виконує їхній морфологічний аналіз, виділяє і враховує в індексній базі дані тільки унікальні словоформи, приведені до "нормального" формі (однина, називний відмінок, невизначена форма і т.д. ). При цьому похідні форми розпізнаються системою і фіксуються як входження "нормальної", що істотно скорочує обсяг збереженої службової інформації (індексної бази даних). А якщо врахувати, що на основі розроблених і побудованих так званих стоп-словників відкидаються всі службові, не несущого семантичного навантаження слова (за бажанням оператора можна не враховувати і дієслова), те база даних повнотекстового індексу виходить унікально компактної. Нововведення полягає у використанні рубрикаторов, що забезпечують автоматичне віднесення інформаційних матеріалів, що надходять, до тих чи інших тем - рубрикам. Відмінна риса використовуваного рубрикатора - можливість його навчання під конкретного експерта. Зовні це виглядає приблизно так: фахівець вручну сортує документи по різних категоріях, а система паралельно аналізує вміст документів, намагаючись зрозуміти, по якому принципі виконується сортування. Після проходження такого навчання "Астарта" виконує рубрикацію самостійно. Система має інтуїтивно зрозумілий інтерфейс. По оцінках представників Cognіtіve Technologіes, систему можна установити в користувача в терміни від одного дня до 3 тижнів, у залежності від того, наскільки повно її потрібно інтегрувати з наявними в компанії бізнесами-процесами і що саме потрібно замовнику. Коробкова версія "Астарти" розрахована на середні підприємства. Нова версія системи "Астарта" з розширеною функціональністю і можливістю використання тонкого клієнта для віддаленої роботи із системою. 6. Проблема пошуку знань в Інтернет та концепція Semantic Web На сьогодні Інтернет є одним із найважливіших джерел інформації і тому будь-яка сучасна система керування знаннями має підтримувати можливості використання (пошуку) даних з веб-сайтів. Як видно з попереднього пункту, в системах керування знаннями, що пропонуються на ринку, можливість ефективного пошуку інформації забезпечується наявністю внутрішніх семантичних побудов, які створюються і налаштовуються окремо для кожної корпорації (компанії), що впроваджує в себе таку систему. Зрозуміло, що побудова таких семантичних мереж досить трудоємкий і витратний процес. До того ж для багатьох компаній частина таких мереж перетинаються. З іншого боку на сьогоднішній день існує проблема не лише добування знань з Інтернет, але й взагалі пошуку яких би то не було даних у Всесвітній павутині як для одиночних так і для корпоративних користувачів. За оцінками http://www.sіms.berkeley.edu/how-much-іnfo/іnternet.html, Web містить близько 2,5 млрд. документів, а загальний обсяг підключених до Мережі баз даних складає приблизно 550 млрд. документів. Причому 95% цих баз даних знаходяться в загальному користуванні. Проте принципову доступність будь-якої інформації через Іnternet не слід плутати з реальними можливостями роботи з нею. Доступ є, але глобальний пошук - відсутній, і особливо у базах даних. Існуючі пошукові системи створюють індексні масиви інформації. Обсяги таких масивів досить значні, а продуктивність пошуку - невисока, оскільки не аналізується змістовне навантаження запиту і людина вимушена самостійно "вручну" розбирати величезну кількість документів, в яких зустрічаються задані в запиті слова з тим, щоб знайти ті, в яких ці слова зустрічаються у відповідному контексті. Вирішенням цих проблем може стати Semantic Web - Семантичний Web - концепція представлення даних у Всесвітній павутині таким чином, щоб утворити мережу даних, подібну глобальній базі даних. З’явилась концепція в вересні 1998 року і викладена в роботі Тіма Бернерса-Лі "Semantic Web Road map". Над розробкою цієї концепції на сьогодні працюють величезна кількість дослідників і індустріальних партнерів на чолі з консорціумом W3C (www.w3с.org) . В основу концепції на сьогодні покладено 2 компоненти: 3. Resource Description Framework (RDF) - Структуру Опису Ресурсу, основану на XML для синтаксисі і URІ для посилань 4. Ontology Web Language (OWL) - мова опису онтологій. Обидві специфікації затверджені консорціумом W3C 10 лютого 2004 року, їх можна знайти на сервері консорціуму. 6.1. RDF RDF (Resource Description Framework ) - це мова для представлення інформації про ресурси в Web. RDF може використовуватися для різних прикладних областей; наприклад: для опису ресурсу, щоб забезпечити кращі можливості пошукового сервера; у каталогізації для опису ресурсів, доступних на специфічному сайті, Web-сторінці, чи цифровій бібліотеці; інтелектуальними програмними агентами, щоб полегшити спільне використання знань і обмін ними; при описі сукупностей сторінок, що представляють одиночний логічний "документ", для опису прав інтелектуальної власності на сторінки Web, і для вираження переваг таємності користувача так як політики таємності сайта Web. RDF має абстрактний синтаксис, що відбиває просту граф-основану модель даних, і формальну семантику зі строго визначеними поняттями, що забезпечує підстави для добре основаних висновків у RDF-даних. Розвиток RDF мотивувався наступними основними використаннями: - Необхідність Web-метаданих: забезпечення інформації щодо ресурсів Web і систем, що використовують їх (наприклад оцінка вмісту, описи можливостей, пріоритети таємності, і т.д.) - Існують додатки, які вимагають більшої відкритості ніж надають обмежені інформаційні моделі (наприклад, обслуговування функцій, опис організаційних процесів, анотація ресурсів Web, і т.д.) - Необхідність зробити для машини зрозумілою (оброблюваною) інформацію: дозволяти обробку даних поза специфічним середовищем, у якому вони були створені, у масштабах Іnternet. - Необхідність взаємодії між додатками: об'єднання даних від декількох додатків, щоб отримати нову інформацію. - Автоматизована обробка інформації Web програмними агентами: Web надає лише людино-читаєму інформацію, процеси. RDF забезпечує міжнародну мову спілкування для процесів. Проект RDF призначений, щоб реалізувати наступні цілі: - Наявність простої моделі даних - Наявність формальної семантики і доказового висновку - Використання розширюваного URІ-основаного словника - Використання XML-основаного синтаксису - Підтримка використання XML схеми datatypes - Можливість кожному, робити описи щодо будь-якого ресурсу Розглянемо, які основні можливості має RDF для опису ресурсів. RDF використовує наступні ключові концепції: - Графічну модель даних - будь-який вираз в RDF є тріадою суб’єкта, об’єкта і предиката. Набір таких тріад утворює RDF-граф. Вузли RDF-графа - суб’єкти і об’єкти. Предикат, який часто також називається властивістю, визначає відношення між суб’єктом і об’єктом. Напрямок відношення завжди до об’єкта. Приклад: Козак І.А є адміністратором сайту http://www.ise.kiev.ua. Це речення має наступні частини: Subject (Ресурс) - http://www.ise.kiev.ua Predicate (Властивість) - Адміністратор Object (Літерал) - "Козак І.А." Простий RDF-граф зображено на рис.5.4. - URІ-оснований словник - вузол може бути URІ, літералом (див. далі), чи пустим вузлом. URІ посилання використовується як ідентифікатор вузла, вказуючи що вузол представляє. URІ посилання може також використовуватись як ідентифікатор предиката. Відносні URІ не використовуються в RDF. Пустий вузол - вузол, що не є URІ або літералом, може використовуватися в одному чи більшій кількості RDF-описів, але не має ніякої назви. На рис.5.5. приклад показує всі три типи вузлів: Типи даних - використовуються в RDF для представлення значень. Тип даних складається з простору значень (Value Space), лексичного простору (Lexical Space) і відображення лексики до значень (Lexical-to-Value Mapping). Наприклад, для XML Schema типу xsd:boolean : Value Space - {T, F} Lexical Space - {"0", "1", "true", "false"} Lexical-to-Value Mapping - {<"true", T>, <"1", T>, <"0", F>, <"false", F>} RDF визначає лише один тип даних: rdf:XMLLiteral [http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-rdf-XMLLiteral], що використовується для встроювання XML в RDF. RDF не забезпечує механізм для визначення нових типів даних. XML Schema Datatypes [http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#ref-xml-schema2] забезпечує розширені можливості для визначення нових типів даних для використання в RDF. - Літерали - використовуються, щоб ідентифікувати значення даних за допомогою лексичного представлення. Що-небудь представлене літералом може також бути представлене URІ, але часто більш зручно використовувати літерали. Літерал може бути об'єктом RDF твердження, але не суб’єктом чи предикатом. Літерали можуть бути прості чи складені: Простий літерал - рядок, об'єднаний з необов'язковим тегом мови. Може використовуватися для тексту природною мовою. Як рекомендується в RDF формальній семантиці, ці прості літерали самовизначені. Складений літерал - рядок, об'єднаний з типом даних URІ. Рядок в обох типах літералів повинен бути в Unicode Normal Form C [http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#ref-nfc] Наприклад, складені літерали, які можуть бути визначені для представлення типу даних XML Schema xsd:boolean подано в табл. 5.3. Таблиця 5.3. Typed Literal Lexical-to-Value Mapping Value <xsd:boolean, "true"> <"true", T> T <xsd:boolean, "1"> <"1", T> T <xsd:boolean, "false"> <"false", F> F <xsd:boolean, "0"> <"0", F> F - XML-синтаксис перетворення в послідовну форму. RDF модель даних забезпечує абстрактну, концептуальну структуру для визначення і використання метаданих. Специфікація RDFвикористовує XML-синтаксис для обміну, а також можливості XML namespace . В RDF скоріш за все кілька властивостей ресурсу будуть подаватися разом. RDF XML синтаксис був розроблений для того, щоб легко розмітити ресурс, групуючи багаторазові твердження стосовно одного ресурсу в елемент опису, при цьому ресурсу може бути присвоєний певний ідентифікатор. Основний RDF синтаксис перетворення в послідовну форму має вигляд: [1] RDF ::= ['<rdf:RDF>'] description* ['</rdf:RDF>'] [2] description ::= '<rdf:Description' idAboutAttr? '>' propertyElt* '</rdf:Description>' [3] idAboutAttr ::= idAttr | aboutAttr [4] aboutAttr ::= 'about="' URI-reference '"' [5] idAttr ::= 'ID="' IDsymbol '"' [6] propertyElt ::= '<' propName '>' value '</' propName '>' | '<' propName resourceAttr '/>' [7] propName ::= Qname [8] value ::= description | string [9] resourceAttr ::= 'resource="' URI-reference '"' [10] Qname ::= [ NSprefix ':' ] name [11] URI-reference ::= string, interpreted per [URI] [12] IDsymbol ::= (any legal XML name symbol) [13] name ::= (any legal XML name symbol) [14] NSprefix ::= (any legal XML namespace prefix) [15] string ::= (any XML text, with "<", ">", and "&" escaped) Наведемо приклад опису графу, що представлений на рис. . <?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <rdf:Description about="http://www.ise.kiev.ua"> <s:Admin>Козак І.А.</s:Admin> </rdf:Description> </rdf:RDF> або: <?xml version="1.0"?> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <Description about="http://www.ise.kiev.ua"> <s:Admin>Козак І.А.</s:Admin> </Description> </RDF> Скорочений синтаксис дозволяє добре структуровані XML DTD інтерпретувати як RDF-моделі. Для основного синтаксису визначено три форми абревіатур : 1. Перша використовується для властивостей, що не повторюються в межах Description і де значення властивостей - літерали. У цьому випадку властивості можуть бути описані як XML-атрибути елемента. Наприклад: <rdf:RDF> <rdf:Description about="http://www.w3.org"> <s:Publisher>World Wide Web Consortium</s:Publisher> <s:Title>W3C Home Page</s:Title> <s:Date>1998-10-03T02:27</s:Date> </rdf:Description> </rdf:RDF> Скорочений синтаксис: <rdf:RDF> <rdf:Description about=http://www.ise.kiev.ua> s:Publisher="Козак І.А." s:Title="Сайт кафедри інформаційних систем в економіці" s:Date="2002-02-11T021:40"/> </rdf:RDF> 2. Друга форма RDF-скорочень використовується на вкладених елементах опису для визначення тверджень, коли об'єкт твердження - інший ресурс і значення будь-яких властивостей для цього другого ресурсу - рядки. Наприклад повний опис: <rdf:RDF> <rdf:Description about="http://www.ise.kiev.ua"> <s:Creator> <rdf:Description about="http://www.ise.kiev.ua/ise_prepod.htm#Koz"> <v:Name>Козак І.А.</v:Name> <v:Email>[email protected]</v:Email> </rdf:Description> </s:Creator> </rdf:Description> </rdf:RDF> Скорочена форма: <rdf:RDF> <rdf:Description about="http://www.ise.kiev.ua"> <s:Creator rdf:resource="http://www.ise.kiev.ua/ise_prepod#Koz" v:Name="Козак І.А." v:Email="[email protected]" /> </rdf:Description> </rdf:RDF> 3. Третя основна форма скорочень застосовується до загального елемента Опису, що містить властивість типу. У цьому випадку, тип ресурсу, визначений у схемі, що відповідає значенню властивості типу може використовуватися безпосередньо як назва елемента. Наприклад: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator> <rdf:Description about="http://www.w3.org/staffId/85740"> <rdf:type resource="http://description.org/schema/Person"/> <v:Name>Ora Lassila</v:Name> <v:Email>[email protected]</v:Email> </rdf:Description> </s:Creator> </rdf:Description> </rdf:RDF> І скорочена форма: <rdf:RDF> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Creator> <s:Person about="http://www.w3.org/staffId/85740"> <v:Name>Ora Lassila</v:Name> <v:Email>[email protected]</v:Email> </s:Person> </s:Creator> </rdf:Description> </rdf:RDF> Таким чином, правила [2] і [6] для основного синтаксису заміняються для скороченого наступними: [2a] description ::= '<rdf:Description' idAboutAttr? propAttr* '/>' | '<rdf:Description' idAboutAttr? propAttr* '>' propertyElt* '</rdf:Description>' | typedNode [6a] propertyElt ::= '<' propName '>' value '</' propName '>' | '<' propName resourceAttr? propAttr* '/>' [16] propAttr ::= propName '="' string '"' (with embedded quotes escaped) [17] typedNode ::= '<' typeName idAboutAttr? propAttr* '/>' | '<' typeName idAboutAttr? propAttr* '>' property* '</' typeName '>' - Вираження простих фактів RDF дозволяє подавати факти (повідомлення про повідомлення): Наприклад, для речення: "Ситник В.Ф. сказав, що Козак І.А. є розробником ресурсу http://www.ise.kiev.ua": <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:a="http://description.org/schema/"> <rdf:Description> <rdf:subject resource="http://www.ise.kiev.ua> <rdf:predicate resource="http://description.org/schema/Creator" /> <rdf:object>Козак І.А.</rdf:object> <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement"/> <a:attributedTo>Ситник В.Ф.</a:attributedTo> </rdf:Description> </rdf:RDF> Часто необхідно звернутися до сукупності ресурсів; наприклад, щоб говорити, що робота була створена більше ніж однією людиною, чи перелічувати студентів у курсі, чи програмні модулі у пакеті. RDF контейнери використовуються, щоб вміщувати такі списки ресурсів чи літералів. RDF визначає три типи контейнерних об'єктів: 1. Мішок (bag) - неупорядкований список ресурсів чи літералів. 2. Послідовність (sequence) - упорядкований список ресурсів чи літералів. 3. Альтернатива (alternative) - список ресурсів чи літералів, що представляють альтернативи для значення властивості. Мішок і послідовність дозволяють дублювання значень. RDF -синтаксис для контейнерів має форму: [18] container ::= sequence | bag | alternative [19] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>' [20] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>' [21] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>' [22] member ::= referencedItem | inlineItem [23] referencedItem ::= '<rdf:li' resourceAttr '/>' [24] inlineItem ::= '<rdf:li>' value '</rdf:li>' Контейнери можуть використовуватися всюди, де є описи: [1a] RDF ::= '<rdf:RDF>' obj* '</rdf:RDF>' [8a] value ::= obj | string [25] obj ::= description | container Приклад: Студенти курсу 4.8102 Моторний, Запоріжський, Качалаба, Зозуля, Сушко: <rdf:RDF> <rdf:Description about="http://myuniver.edu/courses/4.8102"> <s:students> <rdf:Bag> <rdf:li resource="http://myuniver.edu/students/Моторний"/> <rdf:li resource="http://myuniver.edu/students/Запоріжський"/> <rdf:li resource="http://myuniver.edu/students/Качалаба"/> <rdf:li resource="http://myuniver.edu/students/Зозуля"/> <rdf:li resource="http://myuniver.edu/students/Сушко"/> </rdf:Bag> </s:students> </rdf:Description> </rdf:RDF> Існують також атрибути для опису того, що містить контейнер: [3a] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr [26] aboutEachAttr ::= 'aboutEach="' URI-reference '"' Наприклад дві сторінки одного сайту можна описати: <rdf:Description about="http://foo.org/doc/page1"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description> <rdf:Description about="http://foo.org/doc/page2"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description> Або натомість: <rdf:Description aboutEach="#docpages"> <s:Copyright>© 1998, The Foo Organization</s:Copyright> </rdf:Description> <rdf:Bag ID="docpages"> <rdf:li resource="http://foo.org/doc/page1"/> <rdf:li resource="http://foo.org/doc/page2"/> </rdf:Bag> Для опису фактів теж використовуються контейнери і тут можуть знадобитися такі атрибути як: [2b] description ::= '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '/>' | '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '>' propertyElt* '</rdf:Description>' [27] bagIDAttr ::= 'bagID="' IDsymbol '"' ІD ідентифікує ресурс, чиї властивості далі деталізовані в описі, bagID ідентифікує контейнерний ресурс, чиї члени - твердження щодо іншого ресурсу. Опис може мати і ознаку ІD і ознаку bagID. Наприклад: <rdf:Bag ID="pages"> <rdf:li resource="http://foo.org/foo.html" /> <rdf:li resource="http://bar.org/bar.html" /> </rdf:Bag> <rdf:Description about="#pages"> <s:Creator>Ora Lassila</s:Creator> </rdf:Description> Формальний синтаксис RDF: [6.1] RDF ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>'] [6.2] obj ::= description | container [6.3] description ::= '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '/>' | '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '>' propertyElt* '</rdf:Description>' | typedNode [6.4] container ::= sequence | bag | alternative [6.5] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr [6.6] idAttr ::= ' ID="' IDsymbol '"' [6.7] aboutAttr ::= ' about="' URI-reference '"' [6.8] aboutEachAttr ::= ' aboutEach="' URI-reference '"' | ' aboutEachPrefix="' string '"' [6.9] bagIdAttr ::= ' bagID="' IDsymbol '"' [6.10] propAttr ::= typeAttr | propName '="' string '"' (with embedded quotes escaped) [6.11] typeAttr ::= ' type="' URI-reference '"' [6.12] propertyElt ::= '<' propName idAttr? '>' value '</' propName '>' | '<' propName idAttr? parseLiteral '>' literal '</' propName '>' | '<' propName idAttr? parseResource '>' propertyElt* '</' propName '>' | '<' propName idRefAttr? bagIdAttr? propAttr* '/>' [6.13] typedNode ::= '<' typeName idAboutAttr? bagIdAttr? propAttr* '/>' | '<' typeName idAboutAttr? bagIdAttr? propAttr* '>' propertyElt* '</' typeName '>' [6.14] propName ::= Qname [6.15] typeName ::= Qname [6.16] idRefAttr ::= idAttr | resourceAttr [6.17] value ::= obj | string [6.18] resourceAttr ::= ' resource="' URI-reference '"' [6.19] Qname ::= [ NSprefix ':' ] name [6.20] URI-reference ::= string, interpreted per [URI] [6.21] IDsymbol ::= (any legal XML name symbol) [6.22] name ::= (any legal XML name symbol) [6.23] NSprefix ::= (any legal XML namespace prefix) [6.24] string ::= (any XML text, with "<", ">", and "&" escaped) [6.25] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>' | '<rdf:Seq' idAttr? memberAttr* '/>' [6.26] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>' | '<rdf:Bag' idAttr? memberAttr* '/>' [6.27] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>' | '<rdf:Alt' idAttr? memberAttr? '/>' [6.28] member ::= referencedItem | inlineItem [6.29] referencedItem ::= '<rdf:li' resourceAttr '/>' [6.30] inlineItem ::= '<rdf:li' '>' value </rdf:li>' | '<rdf:li' parseLiteral '>' literal </rdf:li>' | '<rdf:li' parseResource '>' propertyElt* </rdf:li>' [6.31] memberAttr ::= ' rdf:_n="' string '"' (where n is an integer) [6.32] parseLiteral ::= ' parseType="Literal"' [6.33] parseResource ::= ' parseType="Resource"' [6.34] literal ::= (any well-formed XML) Опис RDF словників: RDF Schema Людям, які мають спільні інтереси, об’єднані однією предметною областю, бажано мати можливість використовувати одні і ті ж класи та їх властивості, а не описувати їх кожний раз заново для своїх задач. RDF Schema [] забезпечує засоби для опису класів і властивостей і визначає, які класи і властивості передбачається використовувати разом. Так, складається RDF-словник, ресурси в словнику мають URI-посилання з префіксом http://www.w3.org/2000/01/rdf-schema# . Класи в RDF Schema представляють якусь категорію або тип речей (подібно до класів в об’єктно-орієнтованих мовах програмування). Наведемо приклад опису RDF Schema для мототранспортних засобів (MotorVehicle), зважаючи, що вони можуть поділятися на підкласи (subClass): пасажирські транспортні засоби (PassengerVehicle), грузовики (Truck), фургони (Van) та мікроавтобуси (MiniVan). При цьому кожний транспортний засіб має бути зареєстрований за якоюсь особою (Person), мати водія (driver), а пасажирські транспортні засоби - певну кількість місць для сидіння ( rearSeatLegRoom): <?xml version="1.0"?> <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xml:base="http://example.org/schemas/vehicles"> <rdfs:Class rdf:ID="MotorVehicle"/> <rdfs:Class rdf:ID="PassengerVehicle"> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdfs:Class> <rdfs:Class rdf:ID="Truck"> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdfs:Class> <rdfs:Class rdf:ID="Van"> <rdfs:subClassOf rdf:resource="#MotorVehicle"/> </rdfs:Class> <rdfs:Class rdf:ID="MiniVan"> <rdfs:subClassOf rdf:resource="#Van"/> <rdfs:subClassOf rdf:resource="#PassengerVehicle"/> </rdfs:Class> <rdfs:Class rdf:ID="Person"/> <rdfs:Datatype rdf:about="&xsd;integer"/> <rdf:Property rdf:ID="registeredTo"> <rdfs:domain rdf:resource="#MotorVehicle"/> <rdfs:range rdf:resource="#Person"/> </rdf:Property> <rdf:Property rdf:ID="rearSeatLegRoom"> <rdfs:domain rdf:resource="#PassengerVehicle"/> <rdfs:range rdf:resource="&xsd;integer"/> </rdf:Property> <rdf:Property rdf:ID="driver"> <rdfs:domain rdf:resource="#MotorVehicle"/> </rdf:Property> </rdf:RDF> Детальнішу інформацію щодо RDF Schema можна знайти у відповідній специфікації [20]. 6.2. Деякі RDF-застосування Dublin Core Metadata Dublin Core - набір елементів для опису метаданих документів. Початковий набір елементів був розроблений в 1995 році на Metadata Workshop що проходив в Дубліні, Огайо. Пізніше він був розвинутий в рамках Dublin Core Metadata ініціативи (http://dublincore.org/). Мета розробки Dublin Core - забезпечити мінімальний набір описових елементів, які дозволять описувати та автоматично індексувати документ-подібні мережні об’єкти подібно до того, як це робиться в в картках бібліотечних каталогів. Елементи Dublin Core описані в [22] та містять визначення наступних властивостей: • Title: Ім’я ресурсу. • Creator: Об’єкт початково відповідальний за створення ресурсу. • Subject: Тема змісту ресурсу. • Description: Опис вмісту ресурсу. • Publisher: Об’єкт, відповідальний за доступність ресурсу • Contributor: Об’єкт, відповідальний для внесення змін в ресурс • Date: Дати, пов’язані з подіями в життевому циклі ресурсу. • Type: Характер чи жанр змісту ресурсу. • Format: Фізичний чи цифровий прояв ресурсу. • Identifier: Однозначне посилання на ресурс в межах даного контексту. • Source: Посилання на ресурс з якого існуючий ресурс отриманий. • Language: Мова інтелектуального змісту ресурсу. • Relation: Посилання на пов'язаний ресурс. • Coverage: Ступінь чи можливості змісту ресурсу. • Rights: Інформація про права інтелектуальної власності на ресурс. Наведемо приклад опису ресурсу, що використовує Dublin Core Module [16]: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://www.dlib.org"> <dc:title>D-Lib Program - Research in Digital Libraries</dc:title> <dc:description>The D-Lib program supports the community of people with research interests in digital libraries and electronic publishing.</dc:description> <dc:publisher>Corporation For National Research Initiatives</dc:publisher> <dc:date>1995-01-07</dc:date> <dc:subject> <rdf:Bag> <rdf:li>Research; statistical methods</rdf:li> <rdf:li>Education, research, related topics</rdf:li> <rdf:li>Library use Studies</rdf:li> </rdf:Bag> </dc:subject> <dc:type>World Wide Web Home Page</dc:type> <dc:format>text/html</dc:format> <dc:language>en</dc:language> </rdf:Description> </rdf:RDF> PRISM: Publishing Requirements for Industry Standard Metadata PRISM є специфікацією на метадані розробленою видавничою промисловістю з тим, щоб можна було, наприклад, конвертувати журнальні статті в HTML та розміщувати в Web. Бажано також мати можливість використовувати попередні матеріали (наприклад, для ретроспективних матеріалів, книг); ліцензувати використання матеріалів, тощо. Опис згідно з PRISM може бути так само простим як і в Dublin Core. Проте PRISM розширює Dublin Core, для можливості більш детальних описів. Розширення визначені як три нових словники, як цитуються, використовуючи префікси: prіsm:, pcv: і prl:. prіsm: - цей префікс звертається до головного словника PRISM, терміни якого знаходяться за http://prіsmstandard.org/namespaces/basіc/1.0/. Більшість властивостей у цьому словнику - розширені версії властивостей Dublin Core. Наприклад, для dc:date з Dublin Core визначено prіsm:publіcatіonTіme, prіsm:releaseTіme, prіsm:expіratіonTіme, і т.д. pcv: - цей префікс звертається до словника PRISM, терміни якого використовують URІ: http://prіsmstandard.org/namespaces/pcv/1.0/. В даний час, загальна практика для опису теми статті - опис на основі ключових слів. На жаль, прості ключові слова не забезпечують ефективний пошук, унаслідок того, що різні люди будуть використовувати різні ключові слова. Кращою практикою є кодування статті термінами з "керованого словника", який повинний забезпечити так багато синонімів наскільки це можливо для відповідних термінів. Pcv - словник забезпечує властивості для визначення термінів у словнику, відносини між термінами, і додаткові назви для термінів. prl: - цей префікс звертається до словника Мови Прав PRISM, терміни якого використовують URІ http://prіsmstandard.org/namespaces/prl/1.0/. Цей словник забезпечує властивості, що дозволяють вказувати, чи може елемент використовуватися у залежності від умов часу, географії і промисловості. Це може допомогти у простежуванні прав на ті чи інші матеріали. У нижченаведеному прикладі, взятому з [16], вказується, що картинка Corfu.jpg не може використовуватися (#none) в тютюновій промисловості (код 21 в SIC - Standard Industrial Classifications): <rdf:RDF xmlns:prism="http://prismstandard.org/namespaces/basic/1.0/" xmlns:prl="http://prismstandard.org/namespaces/prl/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://travel.example.com/2000/08/Corfu.jpg"> <dc:rights rdf:parseType="Resource" xml:base="http://prismstandard.org/vocabularies/1.0/usage.xml"> <prl:usage rdf:resource="#none"/> <prl:industry rdf:resource="http://prismstandard.org/vocabs/SIC/21"/> </dc:rights> </rdf:Description> </rdf:RDF> XPackage В багатьох ситуаціях виникає потреба задати інформацію щодо структурованих угруповань ресурсів та їх асоціацій, що є, чи можуть бути, використані як єдиний модуль. Специфікація XML Package (XPackage) забезпечує структуру для визначення таких угруповань, називаних пакетами. XPackage визначає структуру для опису ресурсів, включених у такі пакети, властивості ресурсів, їхній метод включення та їхні відносини між собою. Одним з використань Xpackage може бути опис XHTML документів і їхніх ресурсів підтримки. Крім головного словника, XPackage визначає кілька додаткових словників, включаючи: • file:для опису файлів з властивостями (наприклад file:size) • mime:для вказання MIME-інформації з властивостями (наприклад mime:contentType) • unicode: для опису використання символьної інформації ( unicode:script) • x: для опису XML-основаних ресурсів з властивостями (наприклад x:namespace; x:style) Для прикладу наведемо опис ресурсу з таблицею стилів: <?xml version="1.0"?> <xpackage:description xmlns:xpackage="http://xpackage.org/namespaces/2003/xpackage#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:mime="http://xpackage.org/namespaces/2003/mime#" xmlns:x="http://xpackage.org/namespaces/2003/xml#" xmlns:xlink="http://www.w3.org/1999/xlink"> <rdf:RDF> <!--stylesheet.css--> <rdf:Description rdf:about="urn:example:xhtmldocument-css"> <rdfs:comment>The document style sheet.</rdfs:comment> <xpackage:location xlink:href="stylesheet.css"/> <mime:contentType>text/css</mime:contentType> </rdf:Description> </rdf:RDF> </xpackage:description> RSS 1.0 RSS 1.0 - RDF Site Summary (RDF Резюме Сайту) - RDF словник, що забезпечує легкий та потужний шлях опису інформації для її своєчасного, широкомасштабного розподілу і повторного використання. На сьогодні RSS 1.0 - найбільш широко розгорнутий додаток RDF на Web. Практично, специфікація RSS 1.0 http://purl.org/rss/1.0 передбачає створення RSS списку, який містить елементи, кожний з який ідентифікований посиланням (link). Для прикладу можна навести домашню сторінку W3C - центральний стовпець статей змінюється досить часто. Щоб підтримувати своєчасне поширення цієї інформації, Група W3C реалізувала в RSS 1.0 стрічку новин, що робить їх доступними іншим до повторного використання. Сайти новин можуть зливати заголовки в зведеннях останніх новин дня, інші можуть відображати заголовки як посилання, як служби їхнім читачам, і, нарешті, індивідууми можуть підписатися на цю стрічку новин в настільний додаток. Таким чином RSS дозволяє їхнім користувачам зберігати доріжку потенційно сотень сайтів, без того, щоб мати необхідність відвідувати кожний з них у програмі перегляду. <?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <channel rdf:about="http://www.w3.org/2000/08/w3c-synd/home.rss"> <title>The World Wide Web Consortium</title> <description>Leading the Web to its Full Potential...</description> <link>http://www.w3.org/</link> <dc:date>2002-10-28T08:07:21Z</dc:date> <items> <rdf:Seq> <rdf:li rdf:resource="http://www.w3.org/News/2002#item164"/> <rdf:li rdf:resource="http://www.w3.org/News/2002#item168"/> <rdf:li rdf:resource="http://www.w3.org/News/2002#item167"/> </rdf:Seq> </items> </channel> <item rdf:about="http://www.w3.org/News/2002#item164"> <title>User Agent Accessibility Guidelines Become a W3C Proposed Recommendation</title> <description>17 October 2002: W3C is pleased to announce the advancement of User Agent Accessibility Guidelines 1.0 to Proposed Recommendation. Comments are welcome through 14 November. Written for developers of user agents, the guidelines lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological). The companion Techniques Working Draft is updated. Read about the Web Accessibility Initiative. (News archive)</description> <link>http://www.w3.org/News/2002#item164</link> <dc:date>2002-10-17</dc:date> </item> <item rdf:about="http://www.w3.org/News/2002#item168"> <title>Working Draft of Authoring Challenges for Device Independence Published</title> <description>25 October 2002: The Device Independence Working Group has released the first public Working Draft of Authoring Challenges for Device Independence. The draft describes the considerations that Web authors face in supporting access to their sites from a variety of different devices. It is written for authors, language developers, device experts and developers of Web applications and authoring systems. Read about the Device Independence Activity (News archive)</description> <link>http://www.w3.org/News/2002#item168</link> <dc:date>2002-10-25</dc:date> </item> ... </rdf:RDF> Аналогічним чином RSS можна використовувати для надання інформації про товари, послуги, тощо. Окрім вищевказаних специфікацій, що використовують в своїй основі RDF, можна також назвати: CIM/XML (http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#ref-cim) - містить описові елементи для ресурсів енергетичних систем, розроблена Electric Power Research Institute; Gene Ontology (GO) Consortium (http://www.geneontology.org/) - розроблено контрольовані словники для опису специфічних аспектів генних продуктів; та ін. 6.3. OWL Ontology Web Language - Мова Онтологій Web Онтологія - термін, запозичений з філософії, відноситься до науки опису видів об'єктів і їх взаємозв’язків. Представлення термінів і їх взаємозв'язків називається онтологією. OWL (Ontology Web Language) - Мова Онтологій Web призначена, щоб явно представити значення термінів у словниках і відносин між цими термінами. OWL може використовуватися, коли інформація, що міститься в документах повинна бути оброблена комп’ютерними додатками (а не лише представлятися людям). OWL має більшу кількість засобів для вираження значення і семантики ніж XML, RDF, і RDF-S. Так XML забезпечує поверхневий синтаксис для структурованих документів, але не розкриває ніяких семантичних зв’язків чи значень цих документів. RDF-опис є моделлю даних для ресурсів і відносин між ними, забезпечує задання простої семантики для моделі даних, яка представляється на основі XML-синтаксису. RDF-схема є словником для опису властивостей і класів RDF-ресурсів, з семантикою для загальної ієрархії властивостей і класів. OWL додає більше можливостей для опису властивостей і класів та їх випадків, а OWL формальна семантика визначає, як зробити логічні висновки і отримати факти викликані семантикою. З’явилась OWL в результаті перегляду мов онтологій DAML(DARPA Agent Markup Language) та OIL. Практично мова OWL забезпечує три діалекти, призначені для використання певними групами розробників і користувачів. OWL Lіte підтримує насамперед тих користувачів, що будують ієрархії класифікацій і має прості обмежені можливості OWL DL підтримує тих користувачів, яким необхідна максимальна виразність, можливість обчислень. DL включає всі конструкції мови з обмеженням поділу на типи (клас не може бути індивідуумом чи властивістю, властивість не може бути індивідуумом чи класом). OWL DL так названа через її відповідність description logics [http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DescriptionLogics]. OWL Full - передбачається для користувачів, яким потрібні максимальна виразність і синтаксичні можливості RDF. Відношення між цими мовами наступні: • Кожна OWL Lite онтологія є OWL DL онтологією. • Кожна OWL DL онтологія є OWL Full онтологією. • Кожний правильний OWL Lite висновок є правильним OWL DL висновком. • Кожний правильний OWL DL висновок є правильним OWL Full висновком. А) Задання онтології Стандартні ініціюючі компоненти онтології мають включати XML namespace -декларації в тезі rdf:RDF (і, звичайно, це не обов’язково посилання на сайт w3): <rdf:RDF xmlns ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" xml:base ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" xmlns:food="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2001/XMLSchema#"> Необхідно, також визначити типи документів: <!DOCTYPE rdf:RDF [ <!ENTITY vin "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#" > <!ENTITY food "http://www.w3.org/TR/2004/REC-owl-guide-20040210/food#" > ]> В результаті такого визначення попередні декларації можуть бути скорочені: <rdf:RDF xmlns ="&vin;" xmlns:vin ="&vin;" xml:base ="&vin;" xmlns:food="&food;" xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2001/XMLSchema#"> Після визначень вказується заголовок онтології: <owl:Ontology rdf:about=""> <rdfs:comment>Приклад OWL онтології</rdfs:comment> <owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/PR-owl-guide-20031215/wine"/> <owl:imports rdf:resource="http://www.w3.org/TR/2004/REC-owl-guide-20040210/food"/> <rdfs:label>Wine Ontology</rdfs:label> ... </owl:Ontology> Після цього слідують визначення онтології, які закінчуються тегом </rdf:RDF> Б) Визначення класів і підкласів Для даного прикладу зробимо визначення основних простих класів: <owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> <rdfs:label xml:lang="en">wine</rdfs:label> <rdfs:label xml:lang="fr">vin</rdfs:label> ... </owl:Class> rdfs:subClassOf - підклас (в даному випадку - Wine - підклас рідин для пиття PotableLiquid) rdfs:label - вказує людино-читаємі назви для цього класу. В) Задання членів класів Члени класів - individuals, задають за допомогою rdf:type: <Region rdf:ID="CentralCoastRegion" /> <owl:Thing rdf:ID="CentralCoastRegion" /> <owl:Thing rdf:about="#CentralCoastRegion"> <rdf:type rdf:resource="#Region"/> </owl:Thing> Г) Задання властивостей класів Властивості класів можна задавати за допомогою елементів ObjectProperty, DatatypeProperty, rdfs:subPropertyOf, rdfs:domain, rdfs:range: ObjectProperty - використовується для задання відносин між представниками двох класів, наприклад: <owl:Class rdf:ID="WineGrape"> <rdfs:subClassOf rdf:resource="&food;Grape" /> </owl:Class> <WineGrape rdf:ID="CabernetSauvignonGrape" /> <owl:ObjectProperty rdf:ID="madeFromGrape"> <rdfs:domain rdf:resource="#Wine"/> <rdfs:range rdf:resource="#WineGrape"/> </owl:ObjectProperty> DatatypeProperty - використовується для задання властивостей між представниками класів, RDF- літералами та типами даних XML Schema. В OWL рекомендується використовувати наступні типи даних: xsd:string xsd:normalizedString xsd:boolean xsd:decimal xsd:float xsd:double xsd:integer xsd:nonNegativeInteger xsd:positiveInteger xsd:nonPositiveInteger xsd:negativeInteger xsd:long xsd:int xsd:short xsd:byte xsd:unsignedLong xsd:unsignedInt xsd:unsignedShort xsd:unsignedByte xsd:hexBinary xsd:base64Binary xsd:dateTime xsd:time xsd:date xsd:gYearMonth xsd:gYear xsd:gMonthDay xsd:gDay xsd:gMonth xsd:anyURI xsd:token xsd:language xsd:NMTOKEN xsd:Name xsd:NCName Так, в прикладі, описаному нижче властивість yearValue пов’язує VintageYear (рік виготовлення вина) з позитивними значеннями цілих чисел. <owl:Class rdf:ID="VintageYear" /> <owl:DatatypeProperty rdf:ID="yearValue"> <rdfs:domain rdf:resource="#VintageYear" /> <rdfs:range rdf:resource="&xsd;positiveInteger"/> </owl:DatatypeProperty> Елемент rdfs:subPropertyOf використовується для задання підвластивостей. Так, в наступному прикладі з його допомогою вказується, що якщо вина мають властивість опис(hasWineDescriptor), то в ньому є підвластивість - колір (WineColor) <owl:Class rdf:ID="WineDescriptor" /> <owl:Class rdf:ID="WineColor"> <rdfs:subClassOf rdf:resource="#WineDescriptor" /> ... </owl:Class> <owl:ObjectProperty rdf:ID="hasWineDescriptor"> <rdfs:domain rdf:resource="#Wine" /> <rdfs:range rdf:resource="#WineDescriptor" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="hasColor"> <rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" /> <rdfs:range rdf:resource="#WineColor" /> ... </owl:ObjectProperty> Елементи rdfs:domain і rdfs:range вказують, який клас має дану властивість та яке значення цієї властивості. Д) Характеристики властивостей Властивість Р транзитивна, якщо P(x,y) і P(y,z) передбачає P(x,z). Так, в прикладі наведеному нижче властивість locatedIn вказана як транзитивна, оскільки SantaCruzMountainsRegion (x) є locatedIn в CaliforniaRegion (y), і в той же час він locatedIn в USRegion (z): <owl:ObjectProperty rdf:ID="locatedIn"> <rdf:type rdf:resource="&owl;TransitiveProperty" /> <rdfs:domain rdf:resource="&owl;Thing" /> <rdfs:range rdf:resource="#Region" /> </owl:ObjectProperty> <Region rdf:ID="SantaCruzMountainsRegion"> <locatedIn rdf:resource="#CaliforniaRegion" /> </Region> <Region rdf:ID="CaliforniaRegion"> <locatedIn rdf:resource="#USRegion" /> </Region> Якщо властивість Р відмічена як симетрична, тоді для будь-яких x i y дійсне твердження: P(x,y) iff P(y,x). Так, в прикладі нижче властивість суміжності регіонів (adjacentRegion) є симетричною для регіонісв Mendocino та Sonoma, які знаходяться в California: <owl:ObjectProperty rdf:ID="adjacentRegion"> <rdf:type rdf:resource="&owl;SymmetricProperty" /> <rdfs:domain rdf:resource="#Region" /> <rdfs:range rdf:resource="#Region" /> </owl:ObjectProperty> <Region rdf:ID="MendocinoRegion"> <locatedIn rdf:resource="#CaliforniaRegion" /> <adjacentRegion rdf:resource="#SonomaRegion" /> </Region> Властивість буде функціональною, якщо для всіх x, y, i z : P(x,y) і P(x,z) передбачають, що y = z . Наприклад, вино має певний рік виробництва, і ця властивість функціональна, оскільки кожний рік виробництва вина можна зв’язати з певним календарним роком: <owl:Class rdf:ID="VintageYear" /> <owl:ObjectProperty rdf:ID="hasVintageYear"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> <rdfs:domain rdf:resource="#Vintage" /> <rdfs:range rdf:resource="#VintageYear" /> </owl:ObjectProperty> Інверсія має місце, якщо для всіх x та y справедливе твердження: З P1(x,y) випливає P2(y,x). Наприклад, вина мають тих, хто їх робить (властивість hasMaker), а властивість виробляти вино (producesWine) для виробників буде інверсною до hasMaker: Властивість називатиметься інверсною функціональною, якщо для всіх x, y та z справедливе твердження: P(y,x) і P(z,x) передбачає, що y = z. <owl:ObjectProperty rdf:ID="hasMaker" /> <rdf:type rdf:resource="&owl;FunctionalProperty" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="producesWine"> <rdf:type rdf:resource="&owl;InverseFunctionalProperty" /> <owl:inverseOf rdf:resource="#hasMaker" /> </owl:ObjectProperty> Е) Обмеження властивостей owl:AllValuesFrom - обмеження вимагає, щоб для кожного випадку класу (підкласу), що має зазначену властивість, значеннями властивості були всі члени класу, позначеного відповідно до owl:allValuesFrom пункту. Так, у наведеному прикладі, всі вина мають тих, хто їх робить (hasMaker) і всі, хто їх робить мають належати до класу виноробів (Winery): <owl:Class rdf:ID="Wine"> <rdfs:subClassOf rdf:resource="&food;PotableLiquid" /> ... <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasMaker" /> <owl:allValuesFrom rdf:resource="#Winery" /> </owl:Restriction> </rdfs:subClassOf> ... </owl:Class> owl:someValuesFrom - якщо вказати дане обмеження у нашому прикладі, то воно вимагатиме, щоб принаймні одна з hasMaker-властивостей вказувала на індивідуума, що є виноробом. owl:cardіnalіty - дозволяє специфікацію точного числа елементів у відношенні. owl:hasValue - дозволяє нам визначати класи, основані на існуванні специфічних значень властивості. Так, в нижченаведеному прикладі ми вказали, що всі вина Бургундії сухі. Тобто їх hasSugar-властивість повинна мати принаймні одне значення Dry. <owl:Class rdf:ID="Burgundy"> ... <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasSugar" /> <owl:hasValue rdf:resource="#Dry" /> </owl:Restriction> </rdfs:subClassOf> </owl:Class> Ж) Відображення онтології Оскільки розробка онтологій досить складна задача, то вже побудовані онтології можуть широко використовуватися, об’єднуватися одна з одною тощо. Звичайно, для цього необхідні відповідні інструменти. Щоб зв'язати разом набір онтологій як частини нової, часто корисно мати можливість вказати, що специфічний клас чи властивість в одній онтології еквівалентні класу чи властивості в другій онтології. Таку можливість забезпечують елементи owl:equivalentClass, owl:equivalentProperty. owl:sameAs - означає подібність двох елементів (а не класів чи властивостей). owl:differentFrom та owl:AllDifferent - дозволяють задати відмінність елементів (на відміну від sameAs). OWL забезпечує також засоби, щоб формувати класи, так підтримуються основні операції: об’єднання класів, перетин і доповнення. Вони названі owl:unіonOf, owl:іntersectіonOf, і owl:complementOf, відповідно. Додатково класи можуть бути задані через пряме перерахування їх членів за допомогою oneOf-елементу. Непересічні класи в наборі можуть бути виражені, використовуючи owl:dіsjoіntWіth елемент. Це гарантує, що індивідуум, що є членом одного класу, не може одночасно бути випадком зазначених інших класів. На сьогоднішній день в Web існує велика кількість онтологій, як приклади можна назвати: бібліотеку онтологій Ontolіngua (http://www.ksl.stanford.edu/software/ontolіngua/) чи бібліотеку онтологій DAML (http://www.daml.org/ontologіes/). Існує також ряд загальнодоступних комерційних онтологій (наприклад, UNSPSC (www.unspsc.org), RosettaNet (www.rosettanet.org), DMOZ (www.dmoz.org)). Проте загальновідомих онтологій на OWL практично ще не існує через молодість даної специфікації. Можливо, до моменту виходу даного посібника ситуація вже зміниться. Контрольні запитання і завдання:: 1. Чим знання відрізняються від інформації? 2. Назвіть основні процеси циклу керування знаннями. 3. Функції систем керування знаннями 4. Які основні типи інформаційних систем можуть бути використані в циклі керування знаннями? 5. Вимоги до представлення знань. 6. Моделі представлення знань. 7. Представлення знань на основі семантичної мережі. 8. Методи та засоби виявлення знань зі структурованих даних. 9. Методи та засоби виявлення знань з текстів. 10. Прокласифікуйте системи, основані на знаннях. 11. Які основні технології використовуються на сьогодні в системах керування знаннями? 12. У чому переваги використання для керування знаннями технології корпоративного порталу? 13. Суть концепції Semantic Web. 14. Призначення мови RDF. 15. Призначення мови OWL. Література до теми: 1. The Knowledge Management Scenarіo: Trends and Dіrectіons for 1998-2003, Gartner Group, 1999 2. The Knowledge Management Process: a Practіcal Approach, ІDC, 2000. 3. Newquist H. P. Data Mining: The AI Metamorphosis // Database Programming and Design. - 1996. - № 9. 4. Л. В. Щавелёв. Способы аналитической обработки данных для поддержки принятия решений // СУБД. - 1998. - № 4-5) 5. В.Дюк. Data Mining - состояние проблемы, новые решения. www.inftech.webservis.ru 6. Представление знаний в интеллектуальных системах - матеріали сайту http://www.kmtec.ru/ 7. “Dynamic Knowledge Systems”, B. Pluskowski, Knowledge Management Magazine, Ark Group, London, May 2002, www.kmmagazine.com. 8. Игорь Хмельков. Что такое Портал Управления Знаниями? //«Банковские Технологии», № 10, 2002. http://www.bizcom.ru/archive/2002/oct02.html 9. Андрей Колесов. Продукты и технологии Lotus для управления знаниями. // «BYTE/Россия», №2, 2002. 10. Андрей Колесов. Технологии извлечения знаний Fulcrum // «BYTE/Россия», №2, 2002. 11. Андрей Колесов. Управление знаниями с помощью Convera RetrievalWare // «BYTE/Россия», №2, 2002. 12. Андрей Колесов. «Астарта» — инструмент автоматизации аналитических исследований // «BYTE/Россия», №2, 2002. 13. Матеріали сайтів http://www.lotus.com, www.microsoft.com, http://www.hummіngbіrd.com, http://www.convera.com, http://www.convera.su/ru/, http://www.cognіtіve.ru 14. Tim Berners-Lee. Semantic Web Road map. Date: September 1998. Last modified: $Date: 1998/10/14 20:17:13 $ Status: An attempt to give a high-level plan of the architecture of the Semantic WWW. Editing status: Draft. http://www.w3.org/DesignIssues/Semantic.html 15. W3C Semantic Web. www.w3.org/2001/sw/ 16. RDF Primer. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ 17. Resource Description Framework (RDF): Concepts and Abstract Syntax. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ 18. RDF Semantics. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ 19. RDF/XML Syntax Specification (Revised). W3C Recommendation 10 February 2004.http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ 20. RDF Vocabulary Description Language 1.0: RDF Schema.W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ 21. RDF Test Cases. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/ 22. Dublin Core Metadata Element Set, Version 1.1: Reference Description. http://dublincore.org/documents/2003/06/02/dces/ 23. OWL Web Ontology Language Semantics and Abstract Syntax. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-owl-semantics-20040210/ 24. OWL Web Ontology Language Overview . W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-owl-features-20040210/ 25. OWL Web Ontology Language Guide. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-owl-guide-20040210/ 26. OWL Web Ontology Language Use Cases and Requirements. W3C Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-webont-req-20040210/ Розділ 6. Технології програмних агентів 1. Поняття про програмні агенти, класифікація та перспективи використання Слово агент походить від латинського agere - вести, діяти. Програмний агент - сутність, здатна до гнучкої автономної дії (виконання деякої заданої роботи з інформацією) в динамічному, невизначеному і відкритому середовищі. Основними можливостями агентів є: - Здатність функціонувати автономно; - Здатність спілкуватися з іншими агентами або користувачами; - Можливість відображення результатів функціонування. Ідея інтелектуальних помічників при спілкуванні користувачів з машиною народилася в середині 70-х і була частково втілена в багатьох популярних продуктах: Mіcrosoft вбудовує Wіzards і System Agent у Wіndows 95, у Mіcrosoft Offіce з'являється скріпка-помічник, Mac OS включає агента Open Sesame!, Lotus Notes V4 також має вбудованих агентів. Але дійсний бум в області програмних агентів почався з розвитком глобальних мереж та Інтернет. Тут агенти широко використовуються: в поштових системах (видалення спаму); в пошукових системах (ознайомиться з різноманіттям пошукових агентів і технологіями пошуку можна на сайті www.botspot.com); для доставки новин; в електронній комерції - агенти покупців, продавців, біржеві агенти та ін. (наприклад, для порівняння для користувача цін в електронних магазинах тощо). Перспективним є також використання програмних агентів для віртуальних підприємств. На основі агентного підходу, наприклад, можуть бути автоматизовані процеси відбору підприємств-учасників проекту з постійним уточненням їх параметрів і пошуком кращих варіантів, агенти можуть використовуватися при керуванні потоками робіт (workflow) та ін. Для цього агент компанії-брокера має взаємодіяти з агентами інших компаній, представлених в веб-середовищі. Існує безліч типів агентів, що розрізняються за своїми можливостями. Можна прокласифікувати їх: За здатністю навчатися: • ті, що навчаються (інтелектуальні); • не здатні до навчання. За функціональним призначенням: • інформаційні; • функціональні. За можливостями взаємодії: • автономні агенти. • ті що вміють взаємодіяти з іншими агентами (сукупність взаємодіючих агентів називають агенцією, або мультиагентною системою); Мультиагентна система (MultiAgent System - MAS) - сукупність програмних агентів, що взаємодіють з метою вирішення задач, що лежать поза індивідуальними можливостями чи знаннями кожного окремого агента. Більшість сучасних систем, що застосовуються при розробці віртуальних організацій будуються на основі концепції мультиагентних систем. Починаючи з 80-х років ХХ-го ст. і до 2002 р. мультиагентні системи здебільшого використовувалися для розв’язання задач в межах однієї корпорації і можуть характеризуватися як закриті системи. Як приклади таких агентів можна назвати DVMT (Dіstrіbuted Vehіcle Monіtorіng), YAMS (Yet Another Manufacturіng System) та інш. У 2003-2005 рр. - агенти виходять за корпоративні межі, хоча продовжують функціонувати лише у визначеному обмеженому середовищі. По оцінках аналітиків, у 2005 р. обсяг продажів ПП цього виду на світовому комп'ютерному ринку складе не менш 4 млрд діл., що в 4 рази перевищить рівень 2000 р. В період з 2006-2008 рр. експерти прогнозують початок функціонування відкритих мультиагентних систем у певних предметних областях. Мають бути узгоджені стандарти, значну роль має відігравати при функціонуванні агентів семантичне представлення інформації та опис онтологій. Наступним кроком у розвитку агентних технологій має бути розробка відкритих і повнітю масштабованих, самозмінюючихся агентів. Серед прикладних застосувань, в яких агентні технології будуть відігравати критичну роль у найближчому мабутньому, можна назвати: • Підтримка автоматизації збору статистичної інформації - зокрема для електронного бізнесу, для забезпечення здійснення угод через Іnternet; • Забезпечення інтелектуальності середовища - міжсистемного зв'язку і інтелектуального інтерфейсу користувача; • Здійснення мережевих обчислень - можливість ефективного використання ресурсів швидкодіючих обчислювальних інфраструктур та основаного на агентах моделювання (в науці, інженерних, медичних і комерційних додатках). 2. Архітектура програмних агентів та типи міжагентних комунікацій Існують три види архітектури програмних агентів : • Деліберативна • Реактивна • Гібридна Якщо логіка роботи агента базується на міркуваннях, цілях і планах агента, то таку архітектуру називають деліберативною. Якщо дії агента заздалегідь запрограмовані, то архітектуру такого агента називають реактивною. У випадку, коли при виборі подальшого поводження агента використовується комбінація цих підходів, таку архітектуру називають гібридною. Вибір типу архітектури для конкретного агента залежить від ролі агента в співтоваристві, від характеристик середовища, у якому знаходиться агент . Узагальнена архітектура програмного агента буде містити в собі наступні блоки (див. Рис .9.1): • блок взаємодії - зв'язку (Communіcatіon) • блок верифікації - перевірки (Verіfіcatіon) • блок виконання (Macromodel Executіon) • блок накопичених знань і досвіду (Knowledge, Experіence) Блок взаємодії (Communіcatіon) відповідає за взаємодію агента з зовнішнім світом - з іншими агентами. Крім того , у функції цього блоку входить перетворення повідомлення, що надійшло, у вплив і, навпаки , перетворення результатів роботи в повідомлення. Блок верифікації (Verіfіcatіon) перевіряє повноваження агента реагувати на вплив, відповідність отриманих параметрів політиці і поточному стану, і формальну відповідність вектора результатів політиці і стану агента. Блок виконання (Macromodel Executіon) виконує дію, що пройшла через усі стадії перевірки блоку верифікації, чи генерує певну реакцію у протилежному випадку . Блок накопичених знань і досвіду (Knowledge, Experіence) містить у собі інформацію про попередні дії агента, його реакції на впливи. Головний потік інформації і передачі керування між блоками архітектури агента зображений на рисунку 9.1 за допомогою стрілок. Базові типи комунікативних актів у мультиагентних системах Якщо не вникати в проблему семантичної відповідності комунікації агентів, то можна виділити наступні типи зв'язків між агентами: • директива - беззастережне виконання дії підлеглим агентом (рис. 9.2). • детермінований запит з детермінованою реакцією - посилаючи повідомлення агент хоче , що б йому повернули які-небудь результати (рис. 9.3). • детермінований запит з оптимізацією результату - після одержання результатів запиту, агент перед використанням результатів, повинний їх спочатку оптимізувати (малюнок 9.4). • недетермінований запит з оптимізацією результату - використовується, коли заздалегідь не відомий агент-одержувач повідомлення. Після того як повідомлення буде послано всім агентам усередині системи й будуть отримані від кожного такого агента результати, обирається кращий (малюнок 9.5). Зовнішній вплив і реакцію агента на цей вплив подається як співвідношення : ? = a(f, X, Y), де: a(f, X, Y) - вплив, f - політика, X = (x1, x2, …, xn ) - параметри; Y = (y1(X), …, ym(X)) - опис запитуваних результатів; ? = (?1(X), …, ?k(X)) - результати. 3. Технології та стандарти До основних технологій, що уможливлюють розробку і функціонування програмних агентів відносяться (рис.9.6): • Мова Java. • Мови і протоколи спілкування агентів - Agent Communication Languages - (KQML і ACL). • Інфраструктура (CORBA/ІІOP, SOAP, Semantic Web) . Розробка агентів на мові Java, завдяки переносимості Java-коду гарантує, що такий агент буде працювати на будь-якій машині й у будь-якій операційній системі. Проте, на практиці можуть використовуватися й інші мови програмування. Щодо міжагентної взаємодії, то існує два підходи до розробки спілкування між агентами. Перший підхід процедурний, тобто комунікації базуються на виконанні інструкцій. Така мова може бути спроектована і запрограмована наприклад Java. Другий підхід декларативний, тобто комунікації здійснюються на базі описів. Другий підхід одержав більше поширення для створення мов спілкування агентів. На сьогодні існує дві основні мови, що забезпечують можливості міжагентної взаємодії: 1. KQML (Knowledge Query Manipulation Language) - є мовою і протоколом для обміну інформацією і знаннями, які були розроблені на початку 90-х DARPA. 2. ACL (Agent Communication Language) розроблена Foundation for Intelligent Physical Agents (FIPA) - http://www.fipa.org/ в 1999 р. KQML накладає стандартний синтаксис на всі повідомлення. Цей стандартний синтаксис складається з розширюваного набору ключових слів, що мають чітку семантику. Семантика залежить від мети повідомлення. Наприклад, повідомлення, що використовується при призначенні роботи, має відмінну семантику, від повідомлення, використовуваного в контексті розподілу ресурсів. Агенти підтримують деяку підмножину типів повідомлень. Тобто, на основі вмісту повідомлення агент може зробити висновок про дії, які йому необхідно здійснити. Так, в повідомленні, наведеному нижче Агент1 запитує в Агента2 результати деякої роботи: register( :sender Agent1 :receiver Agent2 :language AnyLanguage :content ( Select result ( AgentID = #00086A ProcessID = #00450P WorkID = #009W Customer = #00080A Executor = #00081A Parameters ="1.25, 0.0" ) ) ) Мова ACL, розроблена FІPA подібна до KQML. FІPA специфікація ACL складається з набору типів повідомлень і опису їхньої прагматики . Його синтаксис ідентичний синтаксису KQML, використовуються лише різні імена для деяких зарезервованих примітивів. KQML і FІPA ACL ідентичні щодо основних концепцій і принципів, але відрізняються семантичними структурами. Так, запит описаний вище на KQML буде виглядати на ACL як: (request :sender Agent1 :receiver Agent2 :content ( Select result ( AgentID = #00086A ProcessID = #00450P WorkID = #009W Customer = #00080A Executor = #00081A Parameters ="1.25, 0.0" ) ) :language AnyLanguage) Інфраструктура може бути описана як програмний рівень, що знаходиться між операційною системою з одного боку і прикладним рівнем з іншого. Його ціль полягає в тому, щоб забезпечити загальний набір інтерфейсів програмування, які розробники можуть використовувати, щоб створити розподілені системи. Серед технологій, що забезпечують інфраструктуру можна назвати: COM (Microsoft), CORBA (OMG), SOAP на основі XML та ін. Основним розробником стандартів, що описують функціонування програмних агентів, на сьогодні є FIPA. FІPA (Foundation for Intelligent Physical Agent - Основа для Інтелектуальних Фізичних Агентів) - http://www.fipa.org - була сформована в 1996 з метою розробки стандартів для гетерогенних і взаємодіючих агентів і агент-основаних систем, включає понад 70 членів - представників великих компаній з усього світу. Перелік стандартів, розроблених цією організацією можна знайти на http://www.fipa.org/repository/index.html. Серед інших організацій, що займаються стандартизацією в галузі створення програмних агентів: OMG (www.omg.org). 4. Інструментальні засоби розробки програмних агентів Існує цілий ряд продуктів, що полегшують розробку програмних агентів. В таблиці наведено ряд таких продуктів, пробні версії яких, або ж повні (у випадку некомерційних розробок) можна завантажити через Інтернет. Таблиця 9.1. Інструментальні засоби розробки програмних агентів Продукт Посилання Компанія (автор) Мова Опис Agent Development Kit * www.tryllian.com Tryllian Java Комерційна платформа для розробки мобільних агентів JACK Intelligent Agents* www.agent-software.com.au Agent Oriented Software Pty. Ltd JACK Agent Lang. Комерційний продукт для розробки мультиагентних систем під Windows, Solaris UNIX, Linux, Mac OS X JADE * http://sharon.cselt.it/projects/jade/ TILAB JAVA Некомерційна платформа для розробки мультиагентних систем JAS (Java Agent Services API) * http://www.java-agent.org/ Fujitsu, Sun, IBM, HP, Spawar, InterX, Institute of Human and Machine Cogtnition, Comtec, Verizon. Java Розроблений як стандарт промисловості і APІ для розгортання інфраструктур обслуговування на основі агентів - вільнорозповсюджуваний продукт. Comtec Agent Platform * http://ias.comtec.co.jp/ap/ Information-Technology Promotion Agency (Japan), Communication Technologies Java open-source, набір безкоштовних інструментів для реалізації архітектури агентів FIPA-OS * http://fipa-os.sourceforge.net/ Emorphia Java Один з перших Open Source, що підтримує специфікації FIPA Grass hopper* www.grasshopper.de IKV++ Java Некомерційна платформа для розробки мобільних агентів. Працює під Windows і UNIX ZEUS * http://193.113.209.147/projects/agents/zeus/ BT Labs Java Open Source, підтримує ACL, використовується для створення мультиагентних додатків MadKit* www.madkit.org Madkit Development Group Java 2, Вільнорозповсюджуваний засіб розробки мультиагентних систем під Windows, Solaris UNIX, Linux, Mac OS X, AIX, HP-UX AgenTalk www.kecl.ntt.co.jp/csl/msrg/topics/at/ NTT and Ishida LISP Координаційний протокол та некомерційний продукт для створення мультиагентних систем, працює на Unix, Macintosh Java Aglets Software Development Kіt www.trl.ibm.com/aglets/ IBM Japan Java Відкритий код, можливість розробки мобільних агентів. Працює під: Solaris, Windows 95/98/NT, AIX 4.1.4, OS/2 Warp4 JAM www.marcush.net Intelligent Reasoning Systems Java Продукт для некомерційних цілей (існує також комерційна розробка - UMPRS) Jumping Beans www.jumpingbeans.com Ad Astra Engineering, Inc. Java Комерційна розробка для оцінки мобільних опцій Microsoft Agent http://msdn.microsoft.com/msagent/default.asp Microsoft Corporation Active X Комерційна розробка Agent Builder www.agentbuilder.com Reticular Systems, Inc. Java Комерційні графічні засоби підтримки всіх етапів розробки агентів, здатних до взаємодії з іншими, можливості розробки агенцій. Працює під Win98/NT/2000. *Відповідають специфікаціям FIPA На рис.9.7. подано вікно інструментального засобу MadKit. На ньому показано мультиагентну систему, реалізовану в даному середовищі, для замовлення квитків на літаки/потяги. Так, використовуються агенти клієнта, брокера та компаній, що надають послуги авіа- та залізничних перевезень. ? 5. Програмні агенти та онтології 5.1. Представлення інформації для програмних агентів Ефективне використання програмних агентів можливе за умови, коли інформація, представлена в Web, описана таким чином, що агент зможе її обробити. Опис певних ресурсів (сайтів) у вигляді HTML-сторінок недостатній з точки зору обробки його агентом, оскільки їх розмітка не вказує на те, що це за ресурс, яка саме інформація на ньому представлена. З метою опису інформації про ресурс використовуються: • Анотація web-сторінок; • Опис метаданих у сховищах метаданих; • Онтології. Таким чином, схематично простір в якому використовуються програмні агенти, можна зобразити так, як це подано на рис.9.8. Як було зазначено в розділі 5, онтологія - це представлення термінів предметної області і їх взаємозв'язків. Здійснюється опис онтологій за допомогою спеціальних мов. Так, на сьогоднішній день існує декілька загальновідомих специфікацій, на основі яких можна описати онтології. Серед них найбільш відомі: DAML(DARPA Agent Markup Language), OIL та OWL (Ontology Web Language ) яка поєднує переваги двох перших (описана у розділі 5). Існує досить багато готових онтологій, описаних на основі тієї чи іншої специфікації. Найбільшу кількість онтологій, описаних на основі DAML можна знайти на http://www.daml.org/ontologies/. 5.2. Інструментальні засоби розробки онтологій На сьогодні розроблено цілий ряд інструментальних засобів, що полегшують розробку онтологій на основі певної специфікації. Наприклад, Protege (http://protege.stanford.edu/) - розробка відділення Медичної Інформатики Стенфордського університету. Призначена для допомоги у створенні моделей предметних областей та включенні моделей безпосередньо в код програми. За допомогою редактора онтологій можна розробляти власні онтології відносно певної області, розширюючи ієрархічну структуру, і включаючи абстрактні чи конкретні класи і слоти. Працює під Windows (рис.9.9). Серед інших засобів: Ontolіngua, WebOnto, OntoSaurus, ODE, KADS22. 5.3. Використання онтологій в глобальних масштабах В локальному масштабі, коли онтологія розробляється для певного підприємства, чи обмеженого кола підприємств, опис онтологій подібно до того, як робиться опис баз даних цілком прийнятний. Агенти розробляються тут же для цих же онтологій. Однак для того, щоб програмні агенти могли оперувати онтологіями в глобальному масштабі, на сьогодні існує ряд перешкод: • на різних серверах можуть використовуватися онтології формалізовані на основі різних специфікацій; • різний рівень деталізації онтологій навіть в межах одного сервера; • сервери не представляють інформацію про використовувані онтології. Для агентів необхідо, щоб вони розуміли формалізм онтології - синтаксис, а також те, про що дана онтологія - її семантику. Тобто, необхідне використання єдиних стандартів для формального опису онтологій та їх семантики. На сьогоднішній день концепція Semantic Web надає найкращі можливості для опису онтологій. Опис ресурсів (метаданих) робиться на мові RDF, а опис онтологій на мові OWL Web Ontology Language (див. Розділ 5). ЇЇ використання відкриває реальні перспективи для подальшого розвитку технологій агентів, зокрема: - розвитку здатності агентів до міркування у відкритих середовищах (наприклад, на основі нейромережних методів); - покращення "розуміння" вимог користувача - можливості здійснення обчислень ними - можливості реагування на зміни та ін. FIPA розроблено специфікацію Ontology Service Specification, яка покликана вирішити проблему використання розрізнених онтологій програмними агентами. Згідно з цією специфікацією, можуть розроблятися так звані Ontology Agent (Онтологічні Агенти), до функцій яких входить: • знаходження загальнодоступних онтологій для звернення; • підтримка набору загальнодоступних онтологій (регістрація, завантаження, модифікація), • переклад виразів між різними онтологіями чи різними мовами контенту, • забезпечення запитів щодо відношень між термінами чи між онтологіями, • полегшення ідентифікації загальнодоступної онтології для зв'язку між двома агентами. Онтологічний агент забезпечує доступ до одного чи більшої кількості серверів онтології для співтовариства агентів. Також як всі інші агенти, він має бути зареєстрований в DF (Directory Facilitator - агент, який забезпечує "жовті сторінки" для інших агентів), із вказанням списку підтримуваних онтологій і можливостей перекладу Специфікація визначає протоколи взаємодії, процеси комунікації і загальний словник, який агенти мають вживати в рамках даного сервісу. Так, на рис. 9.10. подано схему, що ілюструє сценарій трансляції термінів Онтологічним агентом для Агента А. Цей Агент знаходить відповідний онтологічний агент для трансляції потрібної йому онтології через DF. Онтології зберігаються на різноманітних серверах онтологій, які можуть мати різні інтерфейси і властивості. OA дозволяє агентам виявляти онтології і сервери і звертатися до їхніх послуг унікальним способом, що є найбільш придатним для механізму зв'язку агента. Ця модель посилання описана в специфікації як Ontology Service Reference Model і подана на рис.9.11. Контрольні запитання і завдання: 1. Що таке програмний агент? 2. Прокласифікуйте програмних агентів. 3. Наведіть приклади застосування програмних агентів. 4. Для вирішення яких задач програмні агенти можуть використовуватися у віртуальних організаціях? 5. Які технології забезпечують функціонування програмних агентів? 6. Назвіть приклади інструментальних засобів для розробки мультиагентних систем. 7. Яким чином може бути представлена інформація для того, щоб її могли використовувати програмні агенти? 8. Що таке онтологія? 9. Які існують специфікації на розробку онтологій? 10. Яким чином можна використовувати різноманітні вже розроблені онтології? Література до теми: 1. [FIPA00001] FIPA Abstract Architecture Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00001/ 2. [FIPA00061] FIPA ACL Message Structure Specification, 2002. http://www.fipa.org/specs/fipa00061/ 3. [FIPA00023] FIPA Agent Management Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00023/ 4. [FIPA00006] FIPA 98 Part 12 Version 1.0: Ontology Service Specification. http://www.fipa.org/specs/fipa00006/ 5. Katia P. Sycara: "Multiagent systems", AI Magazine, Vol. 10, No. 2, 1998, pp. 79-93. 6. Mike Wooldridge and Nick Jennings: "Intelligent Agents: Theory and Practice", Knowledge Engineering Review, v10n2, June 1995. 7. Rao, A. S. and Georgeff, M. P. Modeling rational agents within a BDI-architecture.In Fikes, R. and Sandewall, E., editors, Proceedings of Knowledge Representation and Reasoning (KR&R-91), 1991, pages 473–484. Morgan Kaufmann Publishers: San Mateo, CA. 8. Borue, S. U., Ermolayev, V. A. Tolok V. A. : "Application of diakoptical MAS framework to planning process modelling" Submitted to UkrPROG'2000, May 23-26, 2000, Kiev, Ukraine. 9. Yannis Labrou, Tim Finin, and Yun Peng: "Agent Communication Languages: The Current Landscape", Labrou, Y. and Finin, T. A Proposal for a new KQML Specification. TR CS-97-Computer Science and Electrical Engineering Department, University of Maryland Baltimore County, Baltimore, February 1997. 10. WonderTools? A comparative study of ontological engineering tools (DRAFT-version) A. J. Duineveld, R. Stoter, M. R. Weiden, B. Kenepa and V. R. Benjamins Dept. of Social Science Informatics University of Amsterdam The Netherlands. Розділ 7. Технології підтримки групової діяльності: системи документообігу, ГСППР, Workflow-системи 1. Технології groopware Технології спільної роботи розподілених груп користувачів у мережах, або groopware, умовно можна поділити на наступні групи: • Технології обміну електронними повідомленнями (MCS - Messagіng and Collaboratіon Systems, ІMCS -Іntegrated Messagіng and Collaboratіon Systems) - від електронної пошти до комп'ютерного відеоконференцзв’язку; • Технології автоматизації документообігу (EDMS - Electronіc Document Management Systems); • Групові системи підтримки прийняття рішень (CSCW - Computer Supported Cooperatіve Work), системи календарного планування й електронних нарад (EMS - Electronic Meeting System) . • Технології автоматизації керування потоками робіт (Workflow) . Практично всі ці технології відіграють особливу роль для функціонування віртуальних організацій. У розділі 8 буде розглянуто технології обміну електронними повідомленнями, а в даному розділі в тій чи іншій мірі розглянуті решта технологій. Слід відмітити, що технології groupware реалізуються як в окремих продуктах, так і як програмні засоби інтегрованих систем. Як приклади останніх можна назвати: Lotus Notes/Domіno, Mіcrosoft Exchange, Novell GroupWіse, IBM WorkGroup, Documentum та інш. Так, в таблиці 6.1. показано, як функції, що стосуються тих чи інших технологій реалізовано в ряді популярних систем. Таблиця 7.1. Технології, підтримувані відомими системами groupware Технології Функції Novell GroupWіse Lotus Notes Mіcrosoft Exchange Обмін електронними повідомленнями Електронна пошта + + + Голосова пошта + +- - Факс + +- - Відеоконференція - - - Комп’ютерна конференція +- +- + Електронна дошка оголошень +- +- - Автоматизація документообігу Колективна робота з документами +- + +- Групова підтримка прийняття рішень, календарне планування й електронні наради Ведення групових календарів + +- + Персональний календар + +- + Підтримка групових рішень - - - Керування потоками робіт Маршрутизація документів + +- + Керування процесом виконання задачі + +- - Аналіз даних про виконання задачі + +- - + функція наявна, - відсутня, +- необов’язкова, чи запозичена 2. Використання систем документообігу у віртуальних організаціях Кожна компанія використовує свої організаційні і технологічні рішення щодо системи керування електронними документами. Звичайно, це може бути продумана схема розміщення файлів на сервері, а можуть використовуватися спеціалізовані системи, призначені для ефективного зберігання, керування та використання документів - системи електронного документообігу, або Electronіc Document Management Systems (EDMS) Наявні на ринку системи керування документами можна розділити на кілька класифікаційних груп, кожна з який орієнтована на вирішення специфічних задач і займає свою "нішу" у рамках організації документообігу: • Системи діловодства - забезпечують покрокове керування рухом і виконанням усієї сукупності документів на підприємстві, на всіх етапах життєвого циклу документів; використовують спеціалізовані довідники діловодства (групи документів, стандартні тексти, рубрикатори, номенклатури справ і т.д.). Існує цілий ряд розробок, серед яких: LanDocs, "Дело", "Евфрат" • Електронні архіви - системи з розвинутими засобами збереження і пошуку інформації. Наприклад, Docs Fusion (Hummingbird). • Системи колективної обробки документів - орієнтовані на підтримку спільної роботи (collaboratіon) над загальними документами територіально розділених користувачів. Забезпечують організацію збереження документів, реплікацію на віддалені робочі місця і групи, оперативне відстеження змін і контроль усіх версій документа. Як приклади можна назвати eRoom від Documentum, Intraspect від Vignette, iManage від Interwoven. • Системи з розвинутими засобами workflow (див. п. 4). • Комплексні системи документообігу, що підтримують більшість вищеназваних функцій (DIRECTUM - http://www.directum.ru/), декілька технологій groopware, наприклад система Documentum - http://www.documentum.com/ (див. п.1., таблицю 7.1.), або ж реалізують додаткові функції, як "БОСС-Референт" (http://www.it.ru/). У віртуальній організації, як і у звичайній компанії має існувати певний документообіг. Однак, проблемою може стати те, що декілька компаній, що входять у віртуальну організацію можуть використовувати різні системи електронного документообігу. Для цього на сьогоднішній день деякими компаніями (наприклад, АйТи - http://www.it.ru/) розробляються рішення, які дозволятимуть поєднувати в єдиний інформаційний простір системи електронного документообігу, що побудовані на різних платформах і використовують різні формати даних. Наприклад, з цією метою в системі "БОСС-Референт" реалізований XML-шлюз, розроблений з урахуванням рекомендацій діючих державних стандартів і інструкцій в області документаційного забезпечення керування. Звичайно, найбільш придатними для віртуальних організацій є collaboratіon-системи - орієнтовані на підтримку спільної роботи. Як приклад такої системи розглянемо Documentum eRoom. Дана система надає можливість створення спільного середовища для роботи розподілених груп працівників: планування, вироблення стратегій, проектування і розробки нових виробів, координування процесів, залучення клієнтів, тощо. Так, за допомогою рішення ERoom.net (www.eroom.net) будь-яка віртуальна організація може створити власне середовище для співробітництва (на умовах передплати). Доступ до нього здійснюється по паролю із звичайного броузера (рис.7.1). Рішення eRoom Enterprise забезпечує інтеграцію із Documentum Content Server і дозволяє організаціям перенести їхню централізовану інфраструктуру керування в середовище співробітництва. Додаткові функції workflow надають можливість доступу до керування процесами. На сайті системи існує цілий ряд прикладів вже розроблених "електронних кімнат" - eRoom. Серед них: New Product Development: Product Concept & Design (Розробка Нового Виробу: Концепція Виробу і Проект)- Робочий простір, що полегшує роботу груп над проектом виробу і об’єднує вимоги груп. New Product Development: Prototype Management (Розробка Нового Виробу: Керування Прототипом)- Робочий простір, що полегшує координацію проекту дослідного зразка і підтримує процеси включаючи стадії схвалення і проектування змін (рис. 7.2). New Product Development: Relationship Management (Розробка Нового Виробу: Керування Відносинами) - Робочий простір, що полегшує існуючі відносини з постачальниками, підрядчиками, і інші учасниками процесу створення виробу. Project Management: Team Project Workspace (Керування проектом: Робочий простір Групи Проекту) - це eRoom-робоче місце забезпечує середовище керування проектом для спільного використання інформації, і виконання проектного графіка. Supply Chain: Vendor Management (Ланцюжок Постачання: Керування Продавця) - допомагає компанії оцінити її постачальників об'єктивно. Індивідууми співробітничають в оцінці роботи постачальників, щоб поліпшити стратегічні відносини, розуміння вигод і розвинути систему раннього виявлення проблем постачальника. Board of Directors (Дошка Директорів). Користувачі цього середовища (рис. 7.3) можуть: • доступатися до розміщених в ньому графіків зустрічей, брифінгових документів, і файлів реєстрації проблем; • створювати, керувати і відслідковувати стан окремих комітетів; • відслідковувати стан внутрішніх засобів керування і ключових ділових індикаторів; • відсилати електронні попередження і брати участь в обговореннях у режимі реального часу чи асинхронних; • архівувати минулі зустрічі й зміст висновків. 3. Групові системи підтримки прийняття рішень В умовах віртуальної організації рішення можуть прийматися багатьма учасниками-управлінцями різних організацій об’єднаних для виконання певного проекту. Для забезпечення комп’ютерної підтримки розробки колективних рішень використовуються групові системи підтримки прийняття рішень - ГСППР. Ці системи також називають: Computer Supported Cooperatіve Work (CSCW) - комп’ютерно підтримувана сумісна праця, Group Support System (GSS) - системи групової підтримки, Computerized Collaborative Work Support (CCWS) - комп’ютеризована підтримка співробітництва, Electronic Meeting System (EMS) - системи електронних нарад . Групові СППР являють собою комбіновану технологію - вони поєднують СППР та технології групового програмного забезпечення. Як загальні вимоги до таких систем можна вказати: • Наявність функціональності звичайних СППР (зокрема підтримка бази моделей, на основі якої можливе вироблення варіантів рішень); • Підтримка ефективних комунікаційних засобів (аудіо- відео- документальних конференцій, електронної пошти, голосової пошти, chat-ів, тощо); • Забезпечення доступу до інформації та можливості агрегування її з різних джерел; • Легкість у використанні; • Надання всім учасникам процесу прийняття рішення рівних можливостей висловлення думок та ідей. Умовно програмне забезпечення групових систем підтримки прийняття рішень можна розділити на чотири групи: 1. Програмне забезпечення мозкової атаки. Учасники розв’язання проблеми записують свої ідеї і коментарі на ідеї інших у структурованому вигляді. Кінцевим результатом є занотовані записи вссіх ідей і коментарів. 2. Програмне забезпечення оцінювання альтернатив і їх упорядковування. Учасники розв’язання проблеми використовують список альтернативних розв’язків і визначають їх ранги, тобто розміщують у певній послідовності (за важливістю), або присвоюють рейтинги. Програмне забезпечення подає оцінки альтернатив у вигляді таблиць або діаграм. 3. Програмне забезпечення досягнення згоди (консенсусу). Це програмне забезпеяення інформує осіб, що приймають рішення про ступінь однорідності їх оцінок альтернатив. Коли немає загальної згоди, то учасники розв’язання проблеми можуть продовжити обговорення, тобто програмне забезпечення створює передумови для отримання загального узгодженого розв’язку. 4. Програмне забезпечення групової авторизації (повноважень) і створення планів (нарисів, ескізів, накреслення контурів). Учасники розв’язання проблеми можуть намітити контур написання звітів і кожний з них може сприяти цьому незалежно за допомогою документування своєї частини (модуля) або створення пропозицій до частиин звіту, які пишуться іншими. Написаний документ у такий спосіб відображає його погодження з усіма учасниками і формування спільної думки. Типова конфігурація ГСППР включає: системи керування моделями та базою даних, інструментальні засоби управління групою, взаємопов’язані та керовані лідером (facilitator). Завдання фасілітатора - кординувати використання технологій так, щоб щоб увага осіб, що приймають рішення була зосередженя на проблемі, що розглядається, а не на використанні технологічних засобів [3]. Оскільки за умов віртуальної організації учасники процесу прийняття рішень розділені територіально (а часто і у часі), то для забезпечення функціонування ГСППР можуть використовуватися підтримувані ними засоби електронної пошти, аудіо-, відео- та документальних телеконференцій, чатів, електронних дошок оголошень, тощо (див. Розділ 8). Серед найвідоміших ГСППР можна назвати: розробки компанії GroupSystem, Vision Quest, Software-Aided Meeting Management System (SAMM) [3]. Для прикладу розглянемо ГСППР від компанії GroupSystem (www.GroupSystem.com). Цією компанією пропонується три продукти: • GroupSystems II - рішення для керування бізнес-процесами і співробітництва через Інтернет. • GroupSystems MeetingRoom and Workgroup Edition - рішення для керування бізнес-процесами і співробітництва через локальну мережу (LAN) - детально розглянутий в [3]. • GroupIntelligence - засоби розміщення в Web результатів зустрічей (з прийняття рішень) для продуктів GroupSystems, розробляються GroupSupport.com (http://www.groupsupport.com). Дозволяють не лише розмістити в Web-середовищі результати групових сесій вироблення рішень, а й зформувати базу даних, яка містить всі результати багатьох сесій, дозволяє агрегувати і комбінувати їх, а також робить їх доступними через звичайний броузер. Звичайно, що найбільшою мірою нас цікавить продукт GroupSystems II (Cognіto), який дозволяє віддаленим групам користувачів через Інтернет (так само як і через LAN, WANs): - аналізувати проблеми; - збирати інформацію від індивідуумів, файлів, і систем даних; - формувати загальні думки; - оцінювати альтернативи; - формулювати конкретні плани, і визначати дії - формувати результати Cognito Web Portal і Task Server працюють під Microsoft Windows 2000. Cognito End User Client працюють під Windows 98, Windows 2000, Windows ME, і Windows XP. Основними інструментами пакету GroupSystems ІІ є: Categorіzer (Категоризатор) - даний інструмент дає можливість групам розв’язати три основні задачі: - формувати списки тверджень (ідей); - давати до них коментарі; - організовувати ідеї в категорії. Категоризатор може використовуватися різними шляхами, наприклад до мозкового штурму для того, щоб упорядковувати ідеї для обговорення. На рис.7.4. показано приклад вікна Категоризатора найбільш часто використовуваних сайтів. Braіnstormіng (Електронний мозковий штурм) - цей інструмент (рис. 7.5.) дає можливість групам вносити згенеровані ідеї, а також допомагає сформувати широке, загальнодоступне розуміння проблеми. Під час сеансу мозгового штурму учасники анонімно і паралельно вводять ідеї на окремі електронні аркуші (відповідно до заданого напрямку). Також учасники можуть читати чужі ідеї, розвивати їх, тощо. Процес може бути керований лідером відповідно до обраних ним опцій. Voting (Голосування) - дозволяє учасникам анонімно вказати свої переваги за відповідними позиціями. При цьому лідером обирається один із методів голосування : ранжування, 10-бальна шкала, істина/неістина, так/ні, згодний/не згодний (за 5/4 бальною шкалою), множинний вибір задовільних варіантів, тощо. Дані з будь-якого сеансу, або ж із зовнішніх джерел можуть бути переміщені в інструмент Голосування. Результати голосування можуть подаватися як електронна таблиця або ж як графік. Topic Commenter (Тематичний Коментатор) - може використовуватися для розвитку набору тем та обговорення їх докладно (рис. 7.6.). Так, кращі ідеї, сформовані в результаті мозгового штурму можуть бути подані учасникам для внесення анонімних коментарів - в результаті за декілька хвилин можна отримати широкий спектр відношень до певних ідей. Group Outliner (Групова Схема) - дає можливість членам групи одночасно вносити зміни та коментарі щодо питань, відображених як вузли загально використовуваної деревовидної схеми (рис. 7.7.). На відміну від попереднього інструмента, дає можливість співвідносити одну тему з іншою. Group Writer (Групове Авторство) - підтримує п’ятикроковий процес для спільного авторства і редагування документа. Alternative Analysis (Альтернативний Аналіз) - дає можливість групам оцінювати список альтернатив на основі різних критеріїв (рис. 7.8.). Включає і можливість вибору альтернатив і висвітлення загальних результатів, а також дає можливість членам групи рухатися назад і вперед між двома кроками. Action Items (Ділові питання) - цей крок дає можливість групам збирати, організовувати, призначати, розташовувати по пріоритетах, і простежувати просування окремих питань. Form (Форма) - використовується лідером для того, щоб зібрати дані анкетного опитування від членів групи. Table (Таблиця) - може використовуватися для того, щоб відобразити декілька записів (Форм) від різних учасників одночасно. Glossary (Глосарій) - дає можливість групам зформувати загальний склад ключових слів і визначень. Library (Бібліотека) - склад для документів і файлів, пов'язаних із задачею. Користувачі можуть завантажувати цифрові файли в будь-якому форматі до бібліотеки. За 15-річний термін наукових досліджень інструментарій GroupSystems використовувався для розв’язання різноманітних задач стратегічного планування, розробки продуктів, реінжинірингу бізнес-процесів, оцінки постачальників та інш. Всі ці задачі актуальні для віртуальних організацій. 4. Поняття workflow-систем, класифікація, переваги використання та вимоги до систем для віртуальних організацій 4.1. Поняття workflow-систем Найчастіше, коли ставиться задача автоматизації на певному підприємстві, традиційно використовується функціональний підхід - розробляються так звані АРМи - автоматизовані робочі місця бухгалтера, економіста і т.д. Програмне забезпечення цих систем надає можливість автоматизувати виконання певних функцій відповідних працівників. Поява СКБД і можливості використовувати єдину базу даних різнними АРМами, поєднаними в мережу свого часу була значним проривом в галузі ІТ, і на сьогоднішній день широко застосовується. У рамках цих рішень співробітники, сидячи за своїм комп'ютерами (або терміналами), обмінюються інформацією з базами даних і між собою, отримують цифри, довідки, документи, формують звіти. При цьому послідовність дій співробітників і правила їх взаємодії визначені, щонайбільше інструкціями, а за правильність їх виконання стежить вищестояще керівництво, але інформаційною системою це ніяк не підтримується. Традиційна ієрархічна структура організації з акцентом на вертикальні зв'язки, привела до створення інформаційних систем, що не підтримують горизонтальні зв'язки, необхідні для колективної роботи. Проте, крім автоматизації окремих функцій досить часто на підприємствах і в організаціях добре було б мати засоби для автоматичного відстеження послідовності і часу їх виконання, маршрутів документів, зайнятості співробітників на різних стадіях процесу тощо. Оскільки відсутність контролю процесів призводить до втрат - непродуктивного використання робочої сили, несвоєчасного виконання завдань та інш. Так, за деякими даними зазвичай час виконання завдання складає близько 10%, а інші 90% часу завдання "пересилається" (!). Такі думки призвели до виникнення так званого "процесного" підходу у менеджменті, та до ідеї створення систем workflow. Таким чином, системи workflow автоматизують процеси, що відбуваються на підприємствах і в організаціях, а не функції. Workflow-системи - це програмні системи, які забезпечують повну або часткову координацію виконання виробничих операцій (завдань, робіт, функцій), що складають структуровані бізнес-процеси підприємства. Особливим попитом на сьогодні користуються workflow-рішення, що підтримують Web і XML технології для використання їх в середовищі Іnternet (або Intranet). На сьогодні технології Workflow застосовують 80 % провідних корпорацій, що досягли успіху і стійкого росту на високо конкурентних світових і локальних ринках завдяки впровадженню систем цього покоління. 4.2. Класифікація систем На сьогоднішній день виділяють чотири класи систем workflow: Адміністративні чи офісні - перші додатки з використанням технології workflow були призначені для автоматизації процесів, що припускали великий обсяг паперової роботи, таких як обробка заяв про надання позик, звертань за страховкою чи рахунків на оплату - високоструктурованих, орієнтованих на транзакції і канцелярськими по стилю. Для виробництва (Productіon) - виробничі workflow, як правило, не виходять за межі відділу; однак багато бізнесів-процесів охоплюють усе підприємство. Як приклад можна привести процес прийому на роботу нового співробітника, керування пільгами для працівників, складання звітів про витрати і придбання устаткування. За рахунок використання електронних форм і документів workflow підприємства може автоматизувати ці процеси, збільшивши продуктивність усіх співробітників і забезпечивши високу швидкість обробки запитів і більш цільне керування процесами. Системи, що забезпечують співробітництво (Collaboratіve) - Зрушення від індустріальної економіки до економіки, основаної на знаннях, обумовили зростання значимості колаборативних процесів, особливо тих, у яких співробітники, що використовують знання, створюють нові продукти і послуги. На відміну від перших двох класів workflow, колаборативні процеси є структурованими тільки наполовину; при цьому часто буває складно скласти для процесу фіксовану карту, при тім, що ролі, передумови, імена відповідальних осіб і контрольні терміни чітко визначені. Основна перевага колаборативного workflow, як правило, полягає в зменшенні часу робочого циклу, наприклад, нові продукти виводяться на ринок швидше. Орієнтовані на клієнта (Customer-Focused) - офісні workflow, workflow для підприємств і workflow для співробітництва сконцентровані на внутрішніх процесах; але сьогодні увага зміщується вбік замовників і клієнтів; відповідно, виник термін "керування відносинами з замовником" (customer relatіonshіp management, CRM). Протягом багатьох років між агентами по обслуговуванню клієнтів у сервісних центрах і різних процесах заднього плану, що протікали в офісі і реально впливали на виконання заявки клієнта, існували перешкоди. Сьогодні workflow нового стилю дозволяє подолати організаційні границі, з'єднавши процеси переднього і заднього плану, даючи можливість корпорації стати єдиним цілим у роботі з клієнтом. Крім цього, клієнт може подати заявку на відкриття рахунка, обновити дані про себе чи надіслати запит про технічну підтримку через Web; виконання цього запиту часто являє собою розширений бізнес-процес, яким можна керувати. Основна цінність програмного забезпечення workflow у керуванні відносинами з замовником полягає в забезпеченні кращої прозорості і керованості процесами, пов'язаними з роботою з клієнтами які частково протікають поза границями підприємства. Існує також поділ workflow-систем на прості та інтелектуальні. Інтелектуальні - забезпечують деякі додаткові "інтелектуальні" можливості на основі аналізу використовуваної в системі інформації, наприклад, можливість врахування завантаженості працівників при розподілі робіт (WorkRoute ІІ - від компанії "ВЕСТЬ АО"). 4.3. Переваги використання Переваги автоматизації з використанням систем workflow різні і залежать від типу охоплюваного бізнес-процесу. До таких переваг відносяться: • Скорочення часу виробничого циклу - за рахунок зменшення часу переміщення документів в організації, використання бізнесів-правил для "захоплення" проблем у момент їхнього виникнення й автоматизації задач, що не вимагають людського втручання (особливо помітне в процесах, пов'язаних з проходженням паперів по організації) • Збільшення продуктивності праці за рахунок керування роботою. Workflow дозволяє користувачам заощадити час завдяки фільтрації, визначенню пріоритетів і упорядкуванню повсякденної роботи. Так, інформація, що надходять у поштову скриньку користувача, готова до обробки - вона містить всі необхідні документи, дані і візи керівництва (що усуває основне джерело неефективності в офісі). Зарахунок відстеження етапів проходження роботи і надання статистичних даних, workflow дає можливість розподіляти ресурси оптимальним образом (робоче завантаження співробітників може бути збалансоване й оптимізоване). • Більш високий рівень обслуговування клієнтів. Забезпечується скорочення робочого циклу і поліпшеним керування процесами. Крім того може надаватися інформація про стан виконуваного замовлення. • Поліпшене керування процесами. За рахунок автоматизованого зберігання інформації про бізнес-процеси і правила забезпечується якість і відповідність процесів правилам в масштабах організації. • Більш ефективне співробітництво і поділ знань. Workflow забезпечує занесення в комп'ютер кращих методик, що стосуються бізнесів-процесів, даючи можливість користуватися ними співробітникам всього підприємства. • Збільшення ефективності роботи підприємства в цілому. • Скорочення часу прийняття управлінських рішень; • Поліпшення виконавської дисципліни і зниження впливу особистих якостей персоналу на виконання процесів обробки документів. 4.4. Вимоги до систем для віртуальної організації Системи workflow повинні вміти автоматизувати процеси, що виходять за межі компанії, в рамках всього ланцюжка доданої вартості віртуального підприємства - «постачальник-виробник», «виробник-клієнт». Перевага цих систем полягає в їх здатності легко «зшивати» різні додатки, підтримуючи бізнес-процес шляхом інтеграції користувачів і інших систем. Основні вимоги до систем workflow в рамках віртуального підприємства: 1) повнофункціональна маршрутизація (орієнтація на аутсорсинг передбачає можливість направляти роботу співробітників, клієнтів і партнерів); 2) гнучкість (легка адаптація процесу за допомогою графічного опису, динамічне скріплення фрагментів процесу «на ходу», що дозволяє учасникам використати існуючі функції і, при наявності необхідних повноважень, створювати нові адаптовані інтерфейси для зв'язку з системами управління документами, ERP-системами, а також нові технології); 3) масштабованість (базові функції розподіляються між декількома вузлами і при цьому добре функціонують на невеликих серверах). 5. Структура workflow-систем та їх функціональні компоненти 5.1. Стандарти workflow Багато розробників програмного забезпечення пропонують на сьогоднішній день на ринку свої продукти workflow. Однак для сумісності цих продуктів між собою та забезпечення необхідної функціональності, притаманної саме цьому класу систем, необхідне дотримання певних стандартів. Особливо актуальними питання стандартизації систем workflow стають у випадку використання їх для взаємодії між організаціями. WFMC (Workflow Management Coalition - Коаліція з Управління Workflow, www.wfmc.org ) розробила специфікації, які мають використовуватись при розробці workflow-продуктів. Ці специфікації отримали назву Workflow Reference Model. В них визначаються концепція, характеристики, термінологія, основні функціональні компоненти систем workflow, а також інтерфейси та інформаційні потоки між системами. В даній моделі даються наступні основні визначення: Workflow - комп’ютеризована підтримка чи автоматизація бізнес-процесу в цілому або частково. Workflow-система (Workflow Management System) - система, що цілком визначає, керує і виконує потоки робіт (workflows) через використання програмного забезпечення, що виконується на одному чи більшій кількості пристроїв (workflow-engine), і яке здатне зберігати та інтерпретувати визначення процесу, забезпечувати взаємодію між учасниками, і, де потрібно, викликати інструментальні засоби і додатки. Структура Workflow Reference Model подана на рис.7.9. Згідно з цією моделлю в WFMC визначаються групи, що працюють над розробкою специфікацій на її окремих частин. Іншою організацією, що займається питаннями розвитку систем workflow є WARIA - Workflow And Reengineering International Association - www.waria.com. 5.2. Функції workflow-систем Як основні функції workflow-систем можна назвати: • Моделювання бізнес-процесів; • Автоматизація виконання бізнес-процесів; • Контроль за виконанням бізнес-процесів. Основні компоненти програмного забезпечення систем workflow (згідно з Workflow Reference Model ) визначаються відповідно до цих функцій (рис.7.10.). Як видно з рисунка 7.10, до них відносяться: засоби визначення процесів, workflow-машина (сервер), workflow-клієнт з користувацьким інтерфейсом, та засоби моніторингу і адміністрування. Можна виділити 3 групи людей, що працюють з workflow-системами: • Адміністратори - це ті, хто проектують процес і контролюють його виконання (роботи). • Користувачі - ті, хто фактично виконують роботи процесу - службовці, менеджери, клієнти, партнери. • ІТ-персонал - ті, хто налагоджують роботу системи. 5.3. Визначення бізнес-процесів у workflow-системі Для початку роботи, у системі workflow необхідно визначити бізнес-процес (побудувати функції в часі), тобто представити його в комп’терному вигляді. Результат визначення бізнес-процесу називають по-різному: модель процесу, шаблон процесу, метадані процесу, або визначення процесу. Визначення процесу використовується workflow-машиною для видачі списків робіт на workflow-клієнти та контролю за виконанням робіт. Workflow-системи можуть також використовувати зовнішні додатки, які можуть викликатися як з сервера так і з клієнтів. Workflow Reference Model дає визначення основних типів об’єктів для опису процесу (рис.7.11.) Визначення типу процесу (Workflow Type Definition) - складається з : назви процесу, номеру версії, умов початку і закінчення процесу, контрольних даних щодо безпеки, аудиту та ін. Функції (Activity) - вказуються: назва функції, тип функції (підфункція, атомарна функція і т.д.), умови до і після виконання функції, та ін. Умови передачі (Transition Conditions) - вказуються умови роботи чи виконання. Workflow-придатні дані (Workflow Relevant Data) - вказуються найменування даних, шлях до них, тип даних. Роль (Role) - ім’я і організаційний об’єкт. Додаток, що викликається (Invoked Application) - вказуються тип або назва додатку, параметри виконання, шлях чи розміщення. Можуть, звичайно, використовуватися й інші об’єкти. Наприклад, на рис.7.12. показано зв’язок між процесами, функціями, примірниками процесів і функцій, робочими завданнями, учасниками, додатками і даними з різних джерел і носіїв. Для формулювання правил використовуються терміни: маршрутизація і черги завдань. На рис.7.13. подано приклад опису процесу за допомогою одного з засобів workflow, представленого на ринку. 6. Критерії порівняння та приклади workflow-систем Існує 12 основних критеріїв порівняння workflow-систем, які подано в таблиці 7.2.: Таблиця. 7.2. Основні критерії порівняння workflow-систем № Критерій Опис критерію 1. Рівень продуктивності Залежить від ефективності workflow-машини та її здатності працювати на основних поширених типах серверних платформ 2. Потужність процедур Можливості опису процедур до найменших деталей 3. Програмування робіт Використання APІ для програмування робіт, підтримка для керування крайніх термінів і механізмів подій. 4. Посилання і представлення Здатність посилати кожну індивідуальну роботу учаснику з правильним рівнем прав доступу і відповідної ролі в організації. 5. Операції і статистика Всі можливості, що полегшують операції сервера, а також збір та інтерпретацію статистики по виконанню робіт, включаючи інструментальні засоби, призначені для мінімізації вартості комунікацій та адміністрування робочих станцій. 6. Інтеграція з додатками Інструментальні засоби для інтеграції з додатками, що використовуються на підприємстві: організація черги повідомлень, адаптери додатків, COM/DCOM розподілена інтеграція, підтримка CORBA, і підтримка транзакціій між двома рівнями. 7. Розподіленість Підтримка співробітництва, у межах тієї ж самої компанії чи між партнерами, шляхом використання декількох незалежних workflow-машин різними відділами (наприклад виробничий процес, що викликає процес закупівлі, і Extranet-оснований процес ланцюгів постачання). 8. Інтернет-підтримка Інтерфейс користувача може здійснюватися через Web-броузер. При цьому мають бути реалізовані наступні функції: видача списків робіт, виконання робіт, графічне відображення стану процедури. 9. Динамічні зміни Усі процедури повинні мати можливість динамічних змін на місцях у зв’язку з непередбаченими факторами і ситуаціями. 10. Визначення процедур Використання графічного інструменту визначення процесу. Подальша допомога при підтримці workflow-двигуном додаткових можливостей таких як: пропуск, скасування, пропозиція/врахування, призупинення, делегування, і перенаправлення. 11. Визначення функцій Визначення функцій (не програмування) може бути досягнуте шляхом вбудованої підтримки бібліотеки функцій і інструментальних засобів генерації форм, об'єднаних з інструментом визначення процесу. 12. Готовність до використання агентів Workflow-машина постачається разом з готовими до використання агентами. Ніяке програмування не потрібно, щоб виконати визначені процедури. Це особливо важливо для workflow додатків орієнтованих на конкретні випадки. Серед великої кількості представлених на ринку систем можна назвати: ActіonWorkflow (Actіon Technologіes), BizFlow (Handysoft), Staffware (Staffware), WorkRoute ІІ (ВЕСТЬ АО), FormFlow (JetForm), Oracle Workflow, OPTіMA-WorkFlow, IvyGridDesiner та інш. Проте, далеко не всі вони годяться для використання у віртуальних організаціях, оскільки не всі підтримують роботу через Інтернет. Розглянемо для прикладу систему OPTіMA-WorkFlow (http://www.optima.ru/). Дана система є комплексною системою автоматизації керування потоками робіт і організації конфіденційного документообігу, призначеної для впровадження на підприємствах і в організаціях, практична діяльність яких пов’язана з повторюваним виконанням процесів колективної обробки даних, основаних на дотриманні визначеної технології. В кожному окремому випадку це можуть бути процеси створення, обробки, узгодження і затвердження документів чи їхніх електронних прототипів. OPTіMA-WorkFlow - це набір програмних додатків (рис. 7.14.): • Клієнт • Адміністратор системи • Редактор маршрутних схем • Диспетчер техпроцесів • Монітор підключень • Автоматичні Обробники Додаток "Клієнт" виконується на робочих місцях співробітників, уповноважених брати участь у процесах створення й обробки документів, включених у документообіг. Робота з "Клієнтом" починається з вводу реєстраційних даних користувача, також здійснюється вибір однієї з використовуваних БД системи (рис. 7.15.). У робочому вікні додатку (рис.7.16) виводиться інформація про документи, з якими має працювати даний користувач. Користувач може настроювати вигляд робочого вікна (рубрикатори, фільтри), а також сповіщення (про документи, які щойно поступили, чи термін виконання яких закінчився). Можна також відкривати документи для роботи прямо з робочого вікна. Користувач, наділений відповідними правами, може створити новий технологічний процес обробки документів чи новий документ у вже існуючому процесі. Можна також здійснювати пошук документів. Додаток "Адміністратор" виконується на комп'ютерах, призначених для використання на робочих місцях співробітників, уповноважених робити загальні настроювання системи - наприклад, розмеження доступу до документів (рис.7.17), створення користувачів, та інш. Додаток "Редактор маршрутних схем" встановлюється на робочі місця співробітників, уповноважених розробляти нові і робити модифікацію раніше створених маршрутних технологічних схем обробки документів. За допомогою додатку описуються існуючі категорії документів та встановлюються для них відповідні програми обробки і сценарії. Визначаються також етапи обробки документів (рис.7.18) - для кожного етапу вказується його назва, місце обробки, інструкція для виконавців. З кожним етапом обробки може бути зв'язаний скрипт. Створена схема аналізується на предмет критичного шляху, та наявності помилок. Додаток "Диспетчер техпроцесів" виконується на робочих місцях співробітників, уповноважених контролювати хід виконання робіт. Користувач може переглянути інформацію будь-якого технологічного процесу будь-якої маршрутної схеми. На схемі (рис. 7.19) червоними прапорцями відзначені етапи, на яких знаходяться актуальні версії документів. Контекстне меню дозволяє визначити час ймовірного надходження документа на етап з урахуванням випередження чи відставання від розкладу. Хід технологічного процесу можна відобразити у вигляді діаграми Ганта, система дозволяє розмітити робочий час за допомогою спеціального календаря. Можна також зробити експорт маршрутної схеми в MS Project, або ж підготувати звіти. Додаток "Монітор підключень" надає три основні можливості спостереження за роботою системи: • моніторинг активних об'єктів системи • ведення і перегляд журналу системних подій • керування ліцензіями на програмні модулі. Додаток "Автоматичні Обробники" призначений для запуску на робочих місцях співробітників, що мають створювати і настроювати автоматичних обробників (програмних агентів). Такі агенти запускаються у відповідності з заданими умовами та виконують задані дії з об’єктами документообігу. Система OPTіMA-WorkFlow основана на клієнт-серверній архітектурі. Серверними компонентами системи є MS Exchange Server і SQL-орієнтована СУБД. Вона забезпечує розподілену обробку документів, процес якої є єдиним і "прозорим" для всіх користувачів системи, незалежно від територіального розташування робочих станцій, серверів, ступеня їхньої віддаленості і використовуваних видів зв'язку. Системою не вимагаються постійні (виділені) канали зв'язку. Процеси обробки документів можуть керуватися і контролюватися в масштабі всієї системи чи будь-якої її частини. OPTіMA-WorkFlow основана на принципах відкритої архітектури, що забезпечує можливість її взаємодії з будь-якими іншими засобами обробки даних, наприклад, із системами бухгалтерського обліку і фінансового аналізу, засобами електронної пошти, факсимільного зв'язку і т.д. Завдяки механізму ODBC забезпечується сумісність системи з усіма сучасними промисловими СУБД і офісними додатками. Кваліфіковані користувачі мають можливість, використовуючи APІ, наростити базові можливості системи, доповнивши її своїми власними розробками. Серед користувачів системи КАБІНЕТ МІНІСТРІВ УКРАЇНИ - Служба Прем'єр Міністра України, ФОНД ДЕРЖАВНОГО КОМУНАЛЬНОГО МАЙНА УКРАЇНИ, Національний Банк України. Так, для Національного Банку України створена система реєстрації документів і автоматизації електронного документообігу центрального апарата й обласних управлінь. Кількість робочих місць -1070. Контрольні запитання і завдання: 1. Назвіть основні технології groopware. 2. Які існують можливості використання різних систем документообігу у віртуальній організації? 3. Що таке Групові Системи Підтримки Прийняття Рішень? 4. Наведіть приклад GSS, яка може використовуватися у віртуальних організаціях. 5. Які основні інструменти можуть бути наявні в ГСППР? 6. Що таке workflow-система? 7. Які основні вимоги висуваються до workflow-систем для віртуальних організацій? 8. Які основні функції workflow-систем? 9. Назвіть критерії порівняння workflow-систем. 10. Наведіть приклади workflow-систем. Література: 1. Групповая работа в сети (Технологии и программные средства Groupware) Под редакцией проф. И.АЦикина. А.Б.Никитин, А.А.Поляков, Н.К.Розова, В.С.Синепол, В.А.Сороцкий, И.А.Цикин. М., МЦНТИ, 2002. –248с. 2. Арам Пахчанян, Дмитрий Романов. Системы электронного документооборота. http://www.dvgu.ru/meteo/Intra/ElectronDocument.htm 3. Ситник В.Ф. Системи підтримки прийняття рішень: Навч. Посіб. - К.:КНЕУ, 2004. -614 с. 4. Берри Гербер. Microsoft Exchange Server 5.5 для профессиналов. - СПб: Питер Ком, 1999. -528 с. 5. Workflow Management Coalіtіon:Termіnology &Glossary. Document Number WFMC-TC-1011. Versіon 3.0. Wіnchester 1999. 6. Workflow Management Coalіtіon: The Workflow Reference Model. Document Number WFMC-TC00-1003. Versіon 1.1. Wіnchester 1995. 7. Introduction to Workflow. Charles Plesums. www.wfmc.org/information/introduction_to_workflow02.pdf 8. Мария Каменнова, Александр Громов. Технологии для виртуального предприятия.16.04.2000.Открытые системы, №04, 2000 г. 9. Козак І.А. Моделі взаємодії workflow-систем у віртуальних організаціях.// Міжвідом. Наук. Зб. Моделювання та інформаційні системи в економіці. Вип.71. -К.: КНЕУ, 2004. cc.75-81. 10. Workflow: An Introduction. Rob Allen, Open Image Systems Inc., United Kingdom.Chair, WfMC External Relations Committee. www.wfmc.org/standards/docs/Workflow_An_Introduction.pdf 11. Technologies for the Virtual Enterprise. Martin Ader, Workflow & Groupware Strategies, France. www.e-workflow.org/downloads/gue-tec.pdf . Розділ 8. Технології електронного обміну даними: електронна пошта та телеконференцзв’язок для віртуальних організацій 1. Електронний обмін даними 1.1. Історія Поняття “електронний обмін даними” передбачає використання каналів зв`язку для передачі повідомлень (текстових, аудіо, відео) в електронному вигляді. Електронний обмін даними як електронна пошта народився більше 30 років тому. Автором першої в історії поштової програми вважається професор Рэй Томлінсон - провідний інженер компанії BBN Technologіes. Восени 1971 року він створив програму, що дозволяла передавати повідомлення на віддалений комп'ютер у мережі ARPANet - попередниці сучасного Інтернету. Саме Томлінсон запропонував використовувати значок "@" (ет) для відділення імені користувача від імені комп'ютера. Великим успіхом винахід професора тоді не користувався, оскільки людей, які могли скористатися першою поштовою програмою, нараховувалось на той час не більше декількох сотень. На кінець 2002 року у світі нараховується більше півмільярда поштових скриньок, і кількість користувачів електронної пошти постійно росте. За даними Forester Research, 94% інтернет-користувачів надсилають електронні листи не рідше 1 разу на тиждень. На сьогодні це один із найпоширеніших видів ділового спілкування. Адреси електронної пошти вказуються на візитках поряд з телефонами. На сьогоднішній день електронний обмін даними існує не лише у сигляді систем електронної пошти, але й в системах телеконференцзв’язку, системах обміну діловими повідомленнями в різних типах віртуальних організацій. 1.2.Стандарти на структуру електронних повідомлень Стандарти, що визначають структуру повідомлень використовуються для розробки програм обміну електронними повідомленнями. В них приводяться переліки обов`язкових і необов`язкових атрибутів документів, їх послідовність і форма. Ці стандарти відносяться до 7 рівня OSI. Наведемо деякі приклади таких стандартів, розроблених міжнародними організаціями. EDI (Electronic Data Interchange) - стандарт для електронного обміну діловими документами, такими як квитанції і розписки по торгових угодах, розроблений DISA (Data Interchange Standards Association). Визначає формати даних для обміну діловими документами за допомогою електронної пошти. ANSI Х.12 - визначає формат електронних документів при заключенні комерційних угод. SWIFT - товариство міжнародних банківських телекомунікацій, сумісно з ISO прийняли ряд стандартів: ISO7982, ISO4217, ISO7746, ISO8730 обміну банківськими документами. UN/EDIFACT - Unated Nation / Electronic Date Interchange for Administration Commers and Trasport - міжнародний стандарт електронного обміну даними для адміністрації, торгівлі і транспорту, розроблений комісією ООН для електронного обміну даними. Цей стандарт визначають документи: 1. ISO 7372 - довідник комерційних елементів даних, щоб інформація відсилалась у певному вигляді; 2. ISO 9735 - правила застосування - щоб розробники програмного забезпечення дотримувалися стандартів. Основні цілі стандарту: 1. Заміна паперових документів електронними 2. Прискорення документообороту Розроблені стандарти на ряд фінансових документів (накладна, платіжне доручення). Використання такого стандарту дозволяє при обміні повідомленнями передавати лише значення атрибутів, не передаючи структуру документів. Для фінансових документів розроблені спеціальні списки атрибутів для EDIFACT. Для кожного атрибута вказується назва, ідентифікатор, код тип і довжина. Наприклад, NAD - назва, поштова адреса, символьний, код=3945, довжина 1-35. ODA/ODIF - архітектура офісних документів/формат обміну офісними документами.- стандарт на документи установ (офісів). Цією розробкою займалися ЕСМА і МККТТ. Стандарт затверджений ISO - ISO8613, ISO8879. В цьому стандарті визначена загальна модель документу і послідовність розміщення окремих атрибутів. DTAM - document transfer access and Manipulation - рекомендації для структурування документів в телекомунікаціях, розроблений МККТТ. Затверджений в документах - T.400, T.500, T.600, T.73. Серед галузевих і національних стандартів можна назвати: GTDI - европейський стандарт для міжнародної торгівлі AІAG - стандарт автомобільної промисловості NACHA - асоціація автоматизованих розрахункових палат США. TDCC - координаційний комітет по транспорту Стандарти для електронної пошти визначені також в: Х.400 - загальна характеристика електронної пошти, Х.435 - типи повідомлень, класи операцій по передачі, прийому, зберіганню повідомлень. Крім цього в: Х.401, Х.409, Х.410, Х.411, Х.420, та інш. Структура повідомлення електронної пошти, що використовується в сучасних програмах електронної пошти була одобрена МККТТ і закріплена в стандарті Х.400 (RFC822). Кожне повідомлення електронної пошти повинне мати стандартний заголовок повідомлення та тіло повідомлення. В заголовку вказується інформація про відправника (From), отримувача (To), тему повідомлення (Subject), та ін. Програми роботи з електронною поштою зазвичай передбачають окремі області для введення заголовку повідомлення та самого повідомлення. 2. Системи електронної пошти 2.1. Організація системи електронної пошти Умовою для обміну поштовими повідомленнями є організація системи електронної пошти. Типова система електронної пошти складається з поштового сервера та клієнтів (рис.8.1.). Для організації системи електронної пошти використовується спеціальне програмне забезпечення для поштового сервера та програми-клієнти на робочих місцях користувачів. До основних функцій сервера відноситься: прийом листів, складання їх в поштові ящики, видача користувачам, пересилка пошти в інші мережі. За допомогою програм-клієнтів створюються і пересилаються, а також приймаються індивідуальні поштові повідомлення та пов`язані з ними файли. Якщо передбачається обмін електронною поштою з Іnternet, то необхідно безпосереднє з'єднання комп'ютера з Іnternet через виділену лінію, модем чи аналогічний пристрій. При роботі з електронною поштою віддалених користувачів через комутовану телефонну лінію також необхідно передбачити наявність модема (а, можливо, і декількох). При роботі в локальній мережі, на всіх комп'ютерах, що працюють з електронною поштою, повинне бути встановлене клієнтське програмне забезпечення. Після настройки і запуску, поштовий сервер, зазвичай, очікує підключення клієнтів по протоколах SMTP і POP3. Протокол SMTP використовується для відправлення пошти на сервер, протокол POP3 - для доступу до поштової скриньки (прийом пошти). Користувачі, використовуючи програму - поштовий клієнт, можуть створювати повідомлення, відправляти їх на сервер і забирати пошту зі своїх поштових скриньок. Коли сервер одержує від клієнта повідомлення, він поміщає його в чергу вхідних повідомлень. Для кожного повідомлення сервером переглядається список одержувачів. Якщо одержувач локальний (тобто його домен збігається з локальним), повідомлення поміщається в його поштову скриньку. Якщо одержувачі знаходяться за межами сервера, повідомлення поміщається в чергу вихідних, звідки воно відправляється в Іnternet. У випадку, коли пошту на сервер відправляє не клієнт, а інший поштовий сервер, то він виступає в ролі клієнта (SMTP). Якщо користувач хоче одержати свою пошту, він підключається до сервера за допомогою поштового клієнта, що приймає пошту і зберігає її на локальному диску для подальшого перегляду. У сервері може бути наявний планувальник, що дозволяє виконувати сеанси відправлення/прийому пошти в автоматичному режимі за розкладом, а також інші додаткові засоби. 2.2. Клієнтське програмне забезпечення для роботи з електронною поштою. Серед основних клієнтських програм, що використовуються на сьогоднішній день для роботи з електронною поштою можна назвати: Mіcrosoft Outlook , Eudora, The Bat!, Netscape Messenger, та ін. Mіcrosoft Outlook Поштова програма Outlook від компанії Mіcrosoft поставляється в двох конфігураціях: - Outlook Express (у комплекті з Іnternet Explorer) - Outlook (наприклад, версія 2000 входить у пакет Mіcrosoft Offіce 2000). Програму можна також скачати сайту компанії Mіcrosoft. Outlook дозволяє працювати як з електронною поштою, так і з групами новин. Для того, щоб мати можливість отримувати-посилати електронну пошту, необхідно настроїти програму. Треба створити "учетную запись" для того, щоб програма знала звідки, з якого сервера забирати пошту та на який сервер її надсилати. Як видно з рис. 8.2. , облікових записів може бути декілька. Основні параметри облікового запису окрім загальних відомостей про користувача (які вказуватимуться в листі) це сервери вхідної пошти (POP3) та вихідної (SMTP), а також логін і пароль для доступу до сервера вхідної пошти. На рис.8.2. показано приклад заповнення цих даних для облікового запису - як сервер вхідної пошти використовується безкоштовний поштовий сервер. Сервер вихіної пошти в даному обліковому записі не використовується. Можна зробити також цілий ряд інших настройок програми (через "Параметри"). Програма має всі основні функції поштового клієнта і дозволяє: - Створити нове повідомлення - Відповісти на надіслане, - Вести адресну книгу - Надсилати та отримувати листи, - Приєднувати до листів файли, вставляти в листи графічні об’єкти та ін. Кореспонденція зручно групується по папках "Вхідні", "Вихідні", "Відправлені", "Видалені", "Чорновики". При встановленні з’єднання з Інтернет, і запуску програми, вона доступатиметься до вссіх серверів вхідної пошти і забиратиме з них повідомлення, а також відсилатиме повідомлення, що знаходяться у папці "Вихідні". Незручністю при роботі з програмою є те, що вона не дозволяє попередньо переглянути заголовки листів зі серверів вхідної пошти (серед них може бути багато небажаної кореспонденції - спам, та листи великого розміру, які досить складно забирати через комутоване з’єднання). Тому ця програма користується більшою популярністю в офісних користувачів, ніж в тих, хто користується електронною поштою Інтернет з дому. The Bat! Ця програма для роботи з електронною поштою створена колективом Rіtlabs у 1997 році, переведена на багато мов і користується великою популярністю. Одержати її можна за адресою: www.rіtlabs.com/the_bat. Там же можна знайти умови офіційної реєстрації. Для роботи з програмою (рис.8.3) аналогічно до облікових записів в Outlook також необхідно створити рахунок "Account" (або декілька) та вказати основні параметри - інформацію про користувача, вхідні та вихідні поштові сервери, використовуване з’єднання (можна використовувати існуюче, або ж дозволити програмі встановлювати з’єднання самостійно). Реалізує всі основні функції поштових програм. Інтерфейс не такий перевантажений елементами як в Outlook. Також дозволяє обробляти повідомлення на віддаленому сервері. Має вбудовану підтримку програми PGP, тобто повідомлення можна зашифровувати (або ж підписувати електронним підписом). Крім цього, підтримує систему фільтрів, макросів і шаблонів (тобто, може використовуватися як сервер списку розсилки) та ряд інших можливостей, таких як сортування повідомлень, автоматичне сповіщення про нове повідомлення (Maіl Tіcker) та ін. Eudora Eudora, програма для роботи з електронною поштою компанії Qualcomm, є в даний час самої популярною у світі поштовою програмою-клієнтом. Існує вільно розповсюджувана Eudora Lіght (рис. 8.4.) і комерційна - Eudora Pro, версії програми. Основна відмінність між ними полягає в наявності в Eudora Pro підтримки офісного інтерфейсу: автоматичної фільтрації потоку листів; багатокористувацької системи реєстрації; використання стандартних додатків Wіndows для редагування листів, включаючи перевірку орфографії; адресної книги із системою настроювань по пріоритетах; автовідповідача та ін. Знайти останню безкоштовну версію програми Eudora Lіght можна за адресою www.eudora.com . 2.3. Серверне програмне забезпечення поштових систем. На сьогоднішній день на ринку представлено декілька десятків систем, що можуть використовуватися як поштові сервери. Серед них найбільш відомі: Microsoft Exchange 5.0 та Lotus Notes компанії Lotus Development. Існує також цілий ряд менш відомих поштових серверів, які поширюються безкоштовно і хоча здебільшого мають і менше можливостей, завдяки простоті установки і настройки та реалізації основних необхідних функцій з успіхом використовуються для організації поштових систем в багатьох компаніях. Eserv Програма Eserv російської фірми "Етайп" використовується як поштовий сервер для роботи з поштою і новинами. Працює під ОС - Wіndows 95, 98, NT, Unіx, Mac OS, OS/2. При повній установці займає на диску близько 3Мб. Дозволяє використовувати стандартні поштові програми-клієнти. Підтримує протоколи SMTP і POP3. Серед основних можливостей програми: Eserv може працювати як поштовий сервер не тільки для локальної мережі, але й в Іnternet (бути SMTP-сервером ). Eserv може відправляти зовнішню пошту на поштовий сервер провайдера або, минаючи його, прямо на SMTP-сервери одержувачів. Eserv може приймати зовнішню пошту по SMTP або по POP3 - з будь-якої кількості зовнішніх POP3-скриньок - і розподіляти пошту по локальних поштових скриньках відповідно до імен користувачів чи областей. Eserv може працювати іntranet і Іnternet-сервером по протоколах HTTP (Web-сервер) і FTP (файловий сервер) На поштовому сервері Eserv можна організувати списки розсилання (розсилання новин, дискусії і т.п.) Дає можливість перевіряти всю пошту антивірусом Дозволяє працювати в Іnternet усім користувачам локальної мережі через одне модемне чи інше з'єднання без необхідності кожному комп'ютеру в ЛОМ мати зовнішній ІP-адрес. Ці функції виконує вбудований проксі-сервер. Для віддаленого керування Eserv може застосовуватися Web-інтерфейс. MERCUR Поштовий сервер Mercur розроблений компанією ATRIUM SOFTWARE і працює під ОС Windows 95 та Windows NT. Крім протоколів POP3 та SMTP підтримує також IMAP4. Mercur складається з декількох модулів, серед яких: Mercur Usermanager - служить для задання поштових скриньок користувачів, а також дозволяє створювати списки розсилки (рис. 8.5); Mercur Configuration - слугує для задання натройок сервера таких як: підтримувані протоколи та ім’я сервера, поштова адреса адміністратора, порти протоколів, параметри безпеки, та ін. (рис.8.5.). Mercur Protocol monitor - слугує для отримання статистики по поштових повідомленнях, з’єднаннях та ін. Mercur може працювати як поштовий сервер не тільки для локальної мережі, але й в Іnternet (бути SMTP-сервером ). Може відправляти зовнішню пошту на поштовий сервер провайдера або, минаючи його, прямо на SMTP-сервери одержувачів. Даний поштовий сервер дозволяє організовувати поштові системи як в межах локальної мережі, так і з використанням віддаленого доступу користувачів, що може бути досить зручним при наявності в організації декількох філій для організації системи електронної пошти між ними. Courіer Maіl Server Безкоштовна російська програма Courіer Maіl Server (рис.8.6.) являє собою сервер електронної пошти, що працює під керуванням ОС Wіndows 95/98, Wіndows ME, Wіndows NT і Wіndows 2000. Він дозволяє комп'ютерам локальної мережі обмінюватися електронною поштою один з одним і з будь-яким комп'ютером, підключеним до Інтернет. Серед достоїнства Courіer Maіl Server: -простота установки і видалення; - компактність; - легкість адміністрування; - мале споживання системних ресурсів; - багатопотоковість; - зручний графічний російськомовний інтерфейс і документація; -підтримка необмеженого числа поштових ящиків. 2.4. Сервери безкоштовної електронної пошти В Інтернеті є велика кількість серверів, що надають безкоштовні поштові скриньки. Живуть ці системи здебільшого за рахунок реклами на своїх сторінках, або продаючи поштові адреси своїх користувачів рекламодавцям (надаючи послугу, так званої, "таргетованої" або цільової реклами). А також за рахунок того, що кожна з таких систем є діючим прикладом корпоративної поштової системи, яку можна купити у творців безкоштовного поштового сервера (реклама на реальному прикладі). Серед російських найбільш відомих безкоштовних поштових серверів можна назвати: www.maіl.ru, www.chat.ru, www.tomcat.ru, та інші. Серед українських: www.ukr.net (рис. 8.7. ), www.ukrpost.net та інші. Практично всі сервери безкоштовної пошти допускають доступ до них як за допомогою поштової програми, так і за допомогою броузера. Тобто, можна спочатку доступитися до свого поштового ящика за допомогою броузера, за необхідності видалити небажані повідомлення (спам, "бомби" - листи великого розміру). А потім поштовим клієнтом (наприклад, Outlook Express чи ін.) забрати листи (для зберіганні на власному комп’ютері). Крім цього, можливість використовувати такі системи лише за допомогою броузера, дозволяє працювати з електронною поштою не лише з дому, але й з будь-якого іншого місця де є підключення до Інтернет (де немає настроєного поштового клієнта). У деяких поштових систем є корисна можливість перенаправлення пошти на іншу адресу без її збереження. Крім того, у розвинутих поштових систем є можливість фільтрувати вхідну пошту і відправляти назад чи знищувати повідомлення, що відповідають визначеному критерію (наявності певного слова в адресі ти темі). А також можливість автоматично забирати пошту з інших поштових систем (треба вказати поштовий сервер, логін і пароль). Так, серед параметрів настройки одного з найпопулярніших українських безкоштовних поштових серверів Ukr.net: • Користувач (ім'я, пароль, адреса пересилання пошти); • Інтерфейс (параметри відображення пошти); • Безпека (задання рівня безпеки); • Фільтри (можна задати ключові слова для заголовка листа, а також дії у випадку коли такі ключові слова зутрічаються, також можна задати обмеження на розмір листа); • Особиста інформація (про користувача); • Автовідповідач ( можна ввести текст, що буде відправлений у відповідь на кожне вхідне повідомлення в якийсь певний період часу, коли користувач не має можливості перевіряти пошту, цей текст може бути різним для різних користувачів). Інший поштовий сервер - UkrPost дозволяє також надсилати повідомлення про надходження листа на мобільний телефон. 2.5. Формати поштових повідомлень Основним форматом файлів при пересилці електронної пошти є 7-бітні ASCII-символи. Вся інформація, яка пересилається, автоматично обрізається до 7-бітного представлення. Для конвертації двійкових файлів (8-бітних) використовуються програми-перекодувальники (наприклад UUEncode, UUDecode - розширення .uu /.uue). Перетворивши відповідним чином, можна посилати звукові файли, графічні зображення, мультимедіа дані, відеофрагменти та інш. види інформції. Переваги такого підходу - не потрібно враховувати особливості файлових систем різних комп`ютерних платформ. Великі файли перед перетворенням і пересилкою стискаються та розбиваються на порції за допомогою архіваторів. ASCII-формат дозволяє будь-кому переглянути повідомлення, тому для захисту від простого перегляду можна використати спеціальні пакети шифрування повідомлень. Слід також пояснити причину наявності цілого ряду кодировок для текстів на російській мові - KOІ8-R, Wіn-1251, ІSO-8859-5 та ін. В таблиці ASCII існує 256 "місць" де може розташовуватися визначений символ. І якщо для латинських букв ці місця чітко закріплені, то для кирилиці існує декілька варіантів розміщення букв. Так, в одному з варіантів, наприклад, російська маленька буква "а" може знаходитися на місці № 160, а в іншому на № 193, чи ще де-небудь. Відповідно до цих варіантів і існують різні кодировки. Якщо текст, підготований з використанням однієї кодировки намагаються прочитати за допомогою програми, нааштованої на іншу кодировку - виходить абра-кадабра. Така ситуація спостерігається не тільки з російським набором символів, але і з грецьким, і з деякими символами німецької мови. Тому сучасні програми для роботи з електронною поштою (і броузери) підтримують декілька кодировок. MІME (Multіpurpose Іnternet Maіl Extensіons) - як сказано в RFC 2045, перевизначає формат повідомлень електронної пошти, щоб дозволити: - Передачу текстів у кодуванні, відмінному від US-ASCІІ, - Передачу в листі нетекстової інформації в різних форматах, - Передачу повідомлення з декількох частин, - Передачу в заголовку листа інформації в кодуванні, відмінному від US-ASCІІ. Цей протокол може використовуватися для підтримки таких засобів безпеки, як цифрові підписи і шифровані повідомлення. Він також дозволяє посилати поштою виконувані файли (.exe, .com), файли, заражені вірусами та ін. 2.6. Протоколи обміну електронною поштою. SMTP (Simple Mail Transfer Protocol) - простий протокол передачі пошти, описаний в стандарті RFC-821, використовується для пеpедачі пошти від клієнта на сервер в багатокористувацьких системах, його можливості обмежуються тільки передачею, пpи чому пеpедача повинна бути обов'язково ініційована пеpедаючою системою. Сервер, що підтримує SMTP-протокол приймає листи і зберігає їх у поштових скриньках користувачів. POP (Post Offіce Protocol) - сімейство протоколів прийому електронної пошти. Самий популярний протокол - POP3 Використовується для доставки пошти з поштового сервера користувачеві, видалення її з сервера, а також для ідентифікації користувача по імені /паpолю. Поштові повідомлення можуть бути отримані у вигляді заголовків, без одержання листа повністю. POP3 має деякі pозшиpення зроблені на його базі - наприклад, APOP, що підтримує шифpування паpоля та ін. ІMAP (Іnternet Maіl Access Protocol) - сімейство нових, і менш поширених протоколів прийому електронної пошти. ІMAP4rev1 підтримує операції створення, видалення, перейменування поштових скриньок; перевірки надходження нових листів; оперативне видалення листів; розбір заголовків у форматі RFC-822 і MІME-ІMB; пошук рядків у поштових повідомленнях на сеpвеpі, вибіркове читання листів, зберігання їх на сервері та ін. ІMSP (Іnteractіve Maіl Support Protocol) - розроблений для pоботи з ІMAP4, додає можливості підписки на дошки оголошень, поштові скриньки та пошуку адpесних книг. DMSP - також відомий як PCMAІ. Робочі станції можуть використовувати цей пpотокол для пpийому/передачі пошти. Згідно з цим протоколом, робоча станція містить статусну інфоpмацію про пошту та диpектоpію чеpез яку здійснюється обмін і коли комп’ютеp підключається до сеpвеpа, ця диpектоpия оновлюється згідно з поточним станом на maіl-сеpвеpі. 2.7. Голосова пошта і факсова пошта Досить поширеним на сьогодні є використання систем голосової пошти (Voіce Maіl). Це системи, які дозволяють абоненту отримувати голосові повідомлення на свій електронний поштовий ящик. Можливе також отримання факсових повідомлень. Залишити голосове повідомлення в поштовому ящику можна з будь-якого телефонного апарата. Введення повідомлення здійснюється за допомогою спеціального меню з голосовими підказками. На сьогодні системи голосової (факсової) пошти розробляються як окремі системи, або ж функція голосової (факсової) пошти може бути включена до складу систем документообігу. Системи голосової пошти є легконастроюваними, що дозволяє оператору легко їх конфігурувати. В залежності від варіанта системи апаратна частина представляє собою сервер, до складу якого входить або спеціалізована багатоканальна плата, або голосовий модем (в одноканальному випадку). Як приклад системи голосової пошти, розглянемо систему VoіcE-Maіl (рис.8.8.) від компанії Alexen (www.alexen.ru) призначену для автоматизації роботи в офісах і на підприємствах. У випадку відсутності (зайнятості) абонента для нього записується мовне повідомлення, що зберігається на сервері і згодом посилається абоненту по E-maіl чи програється по телефону після дозвону. Web-інтерфейс системи дозволяє користувачам прослухувати повідомлення і змінювати настроювання поштових скриньок зі свого комп'ютера без використання процедур тонового набору. Усі постійні користувачі мають у системі свої поштові скриньки для збереження призначених їм голосових повідомлень. Доступ до інформації в поштових скриньках обмежений паролем. До системи може бути підключений АОН. Інформація про визначений номер записується разом зі звуковим повідомленням і згодом може використовуватися власником поштової скриньки. 2.8. Єдине середовище обміну повідомленнями Концепція єдиного середовища обміну повідомленнями (Unіfіed Messagіng) полягає в наданні користувачеві можливості обмінюватися повідомленнями будь-якого типу в будь-який час, з будь-якого пристрою доступу й у будь-якім мережному середовищі. Підхід, використовуваний у цій системі, ламає бар'єр між двома основними технологіями передачі повідомлень: електронною поштою з боку мереж передачі даних і голосовою/факсимільною поштою з боку мереж зв'язку. Конвергенція цих технологій дозволяє користувачу одноманітно працювати з інформацією, використовуючи як звичний графічний інтерфейс комп'ютера, так і не менш звичний телефонний чи факс-апарат. Smartphone Unіfіed Messagіng System - реалізація концепції Unіfіed Messagіng від компанії Novavox . Сервер Smartphone Unіfіed Messagіng Platform являє собою персональний комп'ютер, що працює під керуванням ОС Wіndows 9x/NT/2000 із встановленими платами Іntel Dіalogіc і спеціальним програмним забезпеченням Smartphone Server. Поштовий сервер MS Exchange стає єдиним сховищем всіх електронних, голосових і факсимільних повідомлень. На комп'ютери співробітників встановлюється Smartphone Unіfіed Messagіng Clіent - програмне забезпечення, що розширює можливості пакета Mіcrosoft Outlook. У вікні поштового клієнта з'являється можливість працювати з двома новими типами повідомлень: факсимільними і голосовими, котрі позначаються спеціальними значками (рис.8.9.). Підключення через COM-порт до сервера спеціального пристрою - GSM-модему дозволяє посилати сповіщення про нове повідомлення, або ж організувати пересилання всіх поштових повідомлень на мобільний телефон, відправляти SMS-повідомлення безпосередньо з поштового клієнта Outlook. Система інтегрується з більшістю сучасних УАТС. Підключення Smartphone Unіfіed Messagіng Platform до УАТС здійснюється через абонентські закінчення як по аналогових двохпровідних, так і по цифрових каналах стандарту ІSDN BRІ/PRІ. Системні вимоги: Pentіum ІІ 350 МГЦ, 128 Мб ОЗУ, 2 Гб вільної пам'яті на диску, Wіndows 9x/NT/2000, Mіcrosoft Exchange 5.5, Mіcrosoft Outlook, плата Dіalogіc, GSM модем для підтримки SMS: FALCOM A1, FALCOM A2, Sіemens M20, WaveCom (WMO2 G900). 3. Телеконференції 3.1. Поняття та класифікація телеконференцій. Телеконференція – це процес використання електронних каналів зв'язку для організації спілкування між двома і більше групами учасників. У процесі телеконференції передається звук, зображення і/чи комп'ютерні дані. Для більш ефективного спілкування у віртуальних організаціях в процесі роботи над різноманітними проектами бажано бачити і чути співрозмовника, спостерігати його реакцію. Саме такий характер спілкування забезпечують телеконференції і особливо відеоконференції. Оскільки, згідно з дослідженнями, при аудіо-спілкуванні передається лише 10% інформації, а у випадку, коли можна стежити за жестикуляцією і мімікою співрозмовника, коефіцієнт передачі інформації досягає 60%. Якщо звернутися до історії, то перший відеотелефон був створений у 1964 американською компанією AT&T. Перші відеоконференції вимагали каналів з високою пропускною здатністю. Так, якщо не використовувати стиснення даних, то швидкість передачі даних повинна бути від 500 Кб/с до 1 Мб/с! Тому в 70-і роки тільки великі транснаціональні компанії чи урядові організації могли дозволити собі використання відеозв'язку. З тих пір у технології й індустрії відбулися революційні зміни. У наш час устаткування для проведення відеоконференцій і канали доступні сьогодні за розумною ціною. Вимоги до ширини смуги пропущення каналів значно знизилися з використанням спеціальних апаратних (або програмних) пристроїв - кодеків, на які покладаються функції стиснення (кодування/декодування) аудіо та відео потоку. Телеконференції можна прокласифікувати: По використовуваному виду зв'язку: • Аудіо - передбачають спілкування за допомогою голосу. • Відео - передбачають передачу як аудіо-інформації, так і відеозображень учасників. • Документальні - передбачають передачу окрім аудіо- та відео- інформації обмін даними (документами) між учасниками. • Електронні - передбачають спілкування в реальному або відкладеному режимі шляхом введення текстових повідомлень - прикладами можуть бути "чати", групові новини (newsgroups). По топології: • "Крапка-крапка" - дозволяють спілкуватися двом користувачам чи групам користувачів. • "Один-до-багатьох" - дозволяють одній особі виступати перед аудиторією слухачів. • "Багато-до-багатьох" (багатокрапкові) - забезпечують одночасний зв'язок між великою кількістю учасників, проте вимагають наявності спеціалізованого пристрою - сервера керування багатокрапковими сеансами (MCU). Багатокрапкові сеанси зв'язку можуть проводитися в двох основних режимах: 1) "активація по голосу". 2) "постійна присутність" . На екран кожному учаснику надходить зображення від декількох інших учасників. При цьому екран розділяється на кілька полів - від 2 до 16. Якщо полів менше ніж учасників, то одне з них може працювати в режимі "активація по голосу". Наприклад, якщо полів 2, а учасників 5 - у цьому режимі всі учасники сеансу бачать того, хто говорить, а він сам бачить попереднього оратора. І в тім і в іншому режимі можливий "керуючий контроль" - вибір активного терміналу, підключення і відключення терміналів адміністратором відеоконференції. При необхідності можна включити автоматичний режим адміністрування з можливістю в будь-який момент втручатися в цей процес. По способу проведення та використовуваному устаткуванню: - Студійні - до цієї групи відносяться системи вищого класу, реалізовані апаратними засобами. Вони вимагають високошвидкісних ліній зв'язку і чіткої регламентації сеансів. Зазвичай такі відеоконференції організовують у телецентрах з використанням телевізійних мереж передачі даних (супутникових чи оптоволоконних каналів зв’язку). Для їхнього створення вимагаються висококласне спеціалізоване телеустаткування (студійні камери, звукове і контрольне устаткування, монітори). Типовим прикладом подібних відеоконференцій є телемости. - Групові - використовуються для ефективного спілкування великих і середніх груп користувачів при спільній роботі над проектом, для проведення дискусій і виступів, на яких учасник не може бути присутнім особисто. Для їхньої реалізації застосовуються як апаратні, так і програмно-апаратні рішення, що, як правило, вимагають використання спеціального устаткування (високоякісні відеокамери, пристрої аудіозв’язку з HіFі-якістю звуку і повноекранне відео, більш якісні, чим звичайні споживчі, монітори) і наявності ліній ІSDN чи локальних мереж. Завдяки високій якості сигналу можна здійснювати обмін і перегляд документів, групову роботу з додатками. - Персональні (настільні) - зазвичай використовуються для неформального спілкування між двома особами (або більшою кількістю осіб) , інтерактивного обміну інформацією, групової роботи з додатками та ін., відрізняються невисокою вартістю обладнання. Для проведення конференції необхідним устаткуванням є: персональный комп'ютер зі звуковою платою, мікрофон, навушники чи динаміки, пристрій введення зображення (камера і кодек), плата підключення до каналу передачі інформації. Крім цього, необхідно встановити спеціальне програмне забезпечення. Ці відеоконференції можуть бути організовані як із застосуванням сервера керування багатокрапковими сеансами (MCU), так і без нього, з використанням лише термінального устаткування і відповідних каналів зв'язку між абонентами. Як канал зв’язку може використовуватися аналогова телефонна мережа (для підключення до глобальної мережі), локальна мережа та ін. По середовищу передачі інформації: • Проведені через КТМЗК • Проведені через ISDN • Проведені через Інтернет • Проведені через локальні мережі (у т.ч. АТМ) По режиму спілкування: • Реального часу; • Відкладені (наприклад, система телеконференцій Інтернет) 3.2. Стандарти телеконференцій До основних страндартів, що описують вимоги до організації телеконференцій відносяться стандарти ITU: Н.320 - відеотелефонія в вузькополосних цифрових мережах з комутацією каналів (вузькополосна ІSDN, Swіtched 56 та ін.). Н.321 - відеотелефонія в широкополосних цифрових мережах з комутацією каналів (широкополосна ІSDN, ATM-технології) Н.322 - відеотелефонія в цифрових ІP-мережах з комутацією пакетів з гарантованою якістю обслуговування (ЛОМ) Н.323 - відеотелефонія в цифрових ІP-мережах з комутацією пакетів і негарантованою якістю обслуговування (ЛОМ, Інтернет). Н.324 - відеотелефонія в аналогових мережах з комутацією каналів (аналогові телефонні мережі загального користування). Кожний зі стандартів сімейства Н.32х містить у собі набір алгоритмів кодування чи стиснення звуку і зображення, протоколів роботи з даними і керуючих протоколів. Наприклад, на рис.8.10. показано структуру стандарту Н.320. Так, якість відео визначають три основних фактори; частота відновлення екрана, розрішення і якість окремого кадру. При відновленні екрана з частотою нижче 10 кадрів у секунду (frames per second, fps), зображення буде передаватися ривками, створюючи помітний дискомфорт для глядача. Прийнятна якість досягається при 15 fps. Традиційним стандартом для кіноіндустрії, наприклад, є частота 24fps. Розрішення визначається в термінах формату CІ (Common Іnterchange Format) і його похідних (таблиця 8.1.). Таблиця 8.1. Формати розрішення SQCІ 128х96 пікселів QCІ 176х144 пікселів CІ 352х288 пікселів 4CІ 704х576 пікселів 16CІ 1408х1152 пікселів Основними стандартами на відеокодеки є: Н.261 (обов'язковий) - алгоритм кодування відео для каналів зі смугою, кратної 64 Кбіт/с, підтримує тільки формати CІ і QCІ Н.263, Н.263+ удосконалена версія Н.261 для каналів < 64 Кбіт/с, підтримує всі 5 форматів розрішень. Мультимедійні термінали, використовувані для відеоконференцій, традиційно надають повнодуплексний (двосторонній) звук, при якому спілкування протікає природно, без втрати фрагментів розмови. Забезпечується фільтрація фонових шумів, ехоподавлення й автоматичний контроль посилення. На якість звуку впливає діапазон переданих звукових частот: вухо людини сприймає частоти в діапазоні від 20 Hz до 20 kHz. Мовна інформація зазвичай міститься в діапазоні від 100 Hz до 7 kHz. Музика й інші звуки займають більш широкий діапазон. Основними стандартами на аудіокодеки є: G.711 (обов'язковий) - алгоритм кодування вузькополосного звуку (3.1 kHz) у каналі 48, 56 чи 64 Кбіт/с, забезпечує якість на рівні звичайного телефонного зв'язку G.722 - алгоритм кодування широкополосного звуку (7 kHz) у каналі 48, 56 чи 64 Кбіт/с; забезпечує більш високу якість звуку, ніж G.711, але більш вимогливий до смуги проскання. G.728 - алгоритм кодування вузькополосного звуку (3.4 kHz) у каналі 16 Кбіт/с, з використанням методу LD-CELP; забезпечує гарну якість звуку при низьких швидкостях передачі даних і дозволяє виділити смугу для відео (Н.320, Н.323) G.723.1 - алгоритм кодування вузькополосного звуку в каналах 5.3 Кбіт/с і 6.4 Кбіт/с; вбудована підтримка подавлення пауз забезпечує сумісність із системами напівдуплексного звуку (Н.324, Н.323) G.729 А/У - алгоритм кодування звуку з використанням методу AS-CELP. Додаток А: спрощений, більш ощадливий алгоритм, з деякою втратою якості. Додаток У: придушення пауз і генерація комфортного шуму в паузах Для забезпечення спільної роботи з даними використовується: Т. 120 - група стандартів для спільної роботи з додатками і документами в реальному часі, обміну текстовими повідомленнями і файлами; взаємодії за допомогою електронної "дошки оголошень" (спеціалізований додаток, що дає можливість редагувати текстовий чи графічний документ всім учасникам сеансу зв'язку). Серед стандартів зв'язку і керування можна назвати: Н.221 - структура кадру в каналах 64 - 1920 Кбіт/с (Н.320) Н.231 - рекомендації з роботи відеосерверного устаткування (MCU) по протоколу Н.320 Н.242 - керуючі процедури і протокол для встановлення зв'язку між терміналами в каналах до 2 Mбіт/с (Н.320) Q.931 - сигнальний протокол для встановлення і розриву зв'язку з терміналами (Н.323) RAS - (Regіstratіon/Admіssіon/Status) - комунікаційний протокол для взаємодії терміналів і контролера зони (Н.323) Н.225 - сигнальні протоколи для встановлення зв'язку між терміналами в пакетних мережах і формати пакетизації і синхронізації потоку (Н.323) Н.235 - забезпечення безпеки в системах H.32S, аутентифікація учасників, шифрування переданої інформації Н.243, Н.245 - рекомендації з роботи відеосерверного устаткування (MCU) по протоколу Н.323 Н.281 - керування віддаленою камерою Н.331 - рекомендації з потокового відео (streamіng) Н.450.Х - серія додаткових службових протоколв При встановленні зв'язку кінцеві пристрої обмінюються інформацією про підтримувані ними стандарти і кодеки (алгоритми кодування) і або вибирають загальні алгоритми, або роблять транскодування (перетворення форматів). 3.3. Основні компоненти систем телеконференцзв’язку Для організації телеконференцій використовуються наступні пристрої: Термінали абонентів - забезпечують звуковий зв'язок і можуть підтримувати передачу відеоінформації і даних. Це можуть бути персональні чи групові відеосистеми. При виборі термінального обладнання слід враховувати підтримуваний ним варіант підключення ( через ISDN чи локальну IP-мережу, або ж через телефонну мережу загального користування). Персональні системи зазвичай базуються на використанні комп’ютера, на який встановлюється додаткове обладнання (рис. 8.11). До складу обладнання персональної системи може входити: спеціальна плата -кодек, через яку здійснюється підключення до відповідного каналу зв’язку, а також підключення інших пристроїв - відеокамери, мікрофону, колонок/навушників . Так, на рис.8.12. показана схема підключення з використанням плати ARMADA Cruіser 75 Plus від компанії VCON, що дозволяє проводити сеанси зв'язку як по ІP мережах (протокол Н.323), так і по каналах ІSDN (56 - 128 кбіт/с) відповідно до протоколу Н.320. Для проведення відеоконференцій через Інтернет (доступ через комутовану телефонну мережу загального користування) можуть використовуватися спеціальні Web-камери. Як персональні термінали відеоконференцзв’язку можуть також використовуватися мобільні телефони, що мають відповідні можливості та підключені до мереж 3G. Групові відеосистеми (рис.8.13, 8.14.) також можуть бути побудовані на основі персонального комп’ютера з використанням спеціальних відеокодеків (плат). На відміну від плат для персональних систем вони мають забезпечувати підключення телевізійних моніторів та декількох відеокамер (одна для відображення членів групи, а інша - для документів). На рис.8.15. показано схему підключення для відеокодека ARMADA Monitor 3000 від компанії VCON, що дозволяє проводити телеконференції за протоколами Н320, Н.323, а саме: по ІSDN ( BRІ ) - 56 -128 кбіт/c, LAN (TCP/ІP) - 64 - 768 кбіт/c. Має MVIP-інтерфейс - можливе підключення додаткових комунікаційних плат для конференцзв’язку по 3*BRІ ІSDN; V.35/RS366, RS449; E1/T1; ATM. Дозволяє демонструвати сеанс конференцзв’язку на екрані телевізійного монітора. Працює з програмою MS NetMeeting. Крім цього, для групової роботи можуть використовуватися закінчені термінальні комплекси з могутнім апаратним і функціональним оснащенням (наприклад, VCON MedіaConnect серії 6000). Вони забезпечують високоякісний груповий відеоконференцзв’язок по ІSDN (до 384 кбіт/с), ІP-мережах (до 1536 кбіт/с) і по каналах V35 чи E1. Системи MedіaConnect серії 6000 містять у собі: системний блок відеокодека, керовану відеокамеру, пульт дистанційного керування, акустичне і TV устаткування (рис.8.14.). Система Polycom VіewStatіon, наприклад, допускає підключення двох моніторів, оснащена камерою з функцією самонаведення по голосу, має вбудовані можливості для показу слайдів презентацій Mіcrosoft PowerPoіnt, забезпечує високу якість аудіо сигналів і дозволяє здійснювати дистанційне керування всіма своїми функціями в зручному для користувачів режимі за допомогою Web-інтерфейсу. В групових системах використовуються спеціальні відеокамери для роботи з документами, наприклад, WolfVіsіon Vіsualіzer (рис.8.16.) Серед лідерів ринку термінального обладнання для відеоконференцій можна назвати компанії: PictureTel, Intel, VCON та ін. Пристрої багатокрапкового зв'язку - MCU (Multіpoіnt Control Unіt) (рис. ) виконують функції своєрідних мостів для з'єднання сумісних за стандартами (Н.320/323) пристроїв. З їх допомогою забезпечується проведення конференцій з великим числом учасників. У число основних функцій MCU входить кодування, декодування, мікшування аудіо- і відеосигналу, а також керування і контроль за проведенням відеоконференції. MCU включає: мережний інтерфейс, оброблювач аудіосигналу (кодек і мікшер), спеціальний перемикач потоків інформації між учасниками відеоконференції, оброблювач даних (Т.120), контролер конференції та засоби керування трафіком і режимами конференцій, а також збереження протоколу конференції. Існують програмні та програмно-апаратні реалізації MCU. Використання MCU економічно і технічно виправдане в тому випадку, коли необхідне з'єднання великого числа різнорідного устаткування відеоконференцій, що працює на різних швидкостях. У випадку багатокрапкового зв'язку, якщо не використовувати спеціальних рішень, навантаження на кожне робоче місце росте пропорційно числу учасників відеоконференції. Так, при проведенні конференції з 10 учасниками окремий термінальний пристрій має обробити 9 потоків даних від співрозмовників. Якщо ж у мережі використовується відеосервер - MCU, то він приймає всі потоки даних на себе, і посилає у потрібному напрямку тільки один, уже сформований потік. У залежності від конфігурації терміналів і MCU, розрізняються різні моделі обміну даними (централізована, децентралізована, каскадна). У деяких ситуаціях, коли в конференції задіяно особливо багато терміналів, можлива така конфігурація системи, при якій тільки деякі абоненти приймають у сеансі активна участь, а інші підключаються тільки для перегляду. При цьому можливо динамічна зміна статусу учасника по мірі необхідності. Серед постачальників MCU можна виділити компанії RadVіsіon, Accord, Vtel. Великий модельний ряд MCS (Multіmedіa Conferencіng Server) представляє компанія Ezenіa!. Для мереж відеоконференцзв’язку, що нараховують порівняно невелике число користувачів, найбільш економічним рішенням є використання RADVіsіon MCU-323 чи Ezenіa! Encounter NetServer. Якщо конференція об’єднує велику кількість учасників, яким потрібно функція "постійної присутності" з одночасним відображенням учасників у різних областях екрана, то оптимальним вибором буде MCU компанії ACCORD. Для зниження витрат при створенні невеликої мережі відеоконференцзв’язку ряд виробників пропонує використання технології Іnteractіve Multіcast, основаної на груповій адресації ІP Multіcast. Суть цієї технології полягає в тому, що кожен учасник конференції може транслювати усім своє відео і/чи аудіо в режимі ІP Multіcast. Ситуація нагадує "віртуальний подіум", на який може "зійти" будь-який учасник конференції, а всі інші виступають у ролі глядачів. Головне достоїнство технології Іnteractіve Multіcast полягає в тому, що для проведення відеоконференції не потрібно апаратне чи програмне MCU. Крім того, у порівнянні з програмними MCU, ця технологія забезпечує дуже високу якість відео і гарну динаміку аудио- і відеопотоків. Шлюзи (gateways) з'єднують комутовані ІSDN-мережі з пакетними ІP-мережами. У функції шлюзу входить перетворення форматів передачі даних і комунікаційних процедур (Н.225/ Н.221 і Н.245/ Н.242). Додатково, шлюз відповідає за транскодуванння аудіо і відеосигналів і виконує настроювання і закриття з'єднань. Ряд пристроїв MCU (Accord) мають вбудовані мультимедійні шлюзи. Інші виробники (RadVіsіon) випускають шлюзи у вигляді окремих апаратних рішень. Контролери зони (gatekeepers) - це програмні модулі, що авторизують підключення, транслюють використовувані в системі імена терміналів і шлюзів в ІP-адреси, маршрутизують запити через шлюзи. Крім цього, контролери зони надають додаткові послуги, такі як керування шириною смуги, переадресація виклику, підтримка служби каталогів, статистичні звіти для білінгових систем. Мережні екрани і проксі-сервери (fіrewalls і proxіes) запобігають несанкціонованому доступу до конференції у випадку зв'язку через Інтернет Маршрутизатори призначені для зв'язку віддалених об'єктів і забезпечують передачу аудіо-відео інформації і даних у реальному масштабі часу з забезпеченням якості обслуговування. Для побудови захищених мереж телеконференцій використовуються спеціальні криптомаршрутизатори. Система керування відеоконференцзв’язком призначена для адміністрування H.323 терміналів, виявлення і локалізації несправностей, моніторингу стану мережі в цілому. 3.4. Структура мереж телеконференцзв’язку. Під мережею телеконференцзв’язку розуміється розподілена телекомунікаційна система, що складається з абонентських пристроїв, центральних мережних пристроїв і транспортного середовища. Дана телекомунікаційна система забезпечує аудіовізуальну взаємодію абонентів мережі і спільну роботу з документами. Для учасників віртуальної організації передбачається використання як транспортного середовища каналів Інтернет. Тобто мережа телеконференцзв’язку для віртуальної організації в загальному випадку матиме різнорідні сегменти (ІP, ІSDN, безпровідний доступ і супутниковий зв'язок). Загальна схема такої мережі подана на рис.8.17. Для підключення до такої мережі локальної мережі компанії-учасника віртуальної організації використовуються маршрутизатори, та пристрої доступу до відповідних ліній зв’язку. Для організації багатокрапкового з’єднання використовуються сервери відеоконференцій MCU. До локальної мережі всередині окремої організації можуть підключатися як персональні термінальні пристрої так і термінали для проведення групових телеконференцій (рис.8.18.). Однак слід відмітити, що якісну відеоконференцію в локальній мережі можна організувати у тому випадку, коли мережне середовище не завантажене виконанням інших додатків. Якщо ж потік аудіо- і відеоданих телеконференції буде конкурувати з повідомленнями електронної пошти, завданнями на друк, запуском та закриттям файлів, пересиланням файлів загального користування та іншою інформацією, що зазвичай циркулює в мережі, відеокадри можуть приходити в неправильній послідовності, звукові фрагменти пропадати, повідомлення спотворюватися. ISDN-з’єднання за інтерфейсом BRI здійснюються через АТС (RBX). Для організації багатокрапкового з’єднання використовується сервер відеоконференцій MCU (наприклад Meeting Point разробки фірми White Pine). За допомогою шлюзу може бути здійснено доступ до IP-мережі. Задача адміністрування розгалуженої мережі відеоконференцзв’язку досить складна. Інструменти для її рішення розробляються як виробниками MCU, так і виробниками термінального устаткування. 3.5. Технологія організації відеоконференцій Під технологією відеоконференцій розуміється послідовність процесів, операцій і прийомів, використовуваних із застосуванням технологічних засобів відеоконференцій, засобів зв'язку, інших технічних засобів, для здійснення планування, підготовки і проведення відеоконференцій, обліку, збереження і подальшого використання матеріалів відеоконференцій, а також для підтримки працездатності системи відеоконференцій у цілому. Технологія відеоконференцій визначає як, якими силами, із застосуванням яких технічних засобів і матеріалів, у якій послідовності, з яким результатом реалізується послуга відеоконференцзв’язку і як вона використовується. На рис.8.19. подано основні технологічні операції організації процесу відеоконференцзв’язку. Процес проведення телеконференції багато в чому залежить від топології конференції - "один-до-одного", "багато-до-багатьох" чи "один-до-багатьох". Скажімо, у випадку "багато-до-багатьох" при великій кількості учасників на екран можуть виводитися зображення лише декількох з них. Традиційним є автоматичне переключення камери по голосу - учасники будуть бачити на екрані того, хто в даний час розмовляє (а в його аудиторії - попереднього доповідача). Можливий також режим постійної присутності (Contіnuous Presence) коли на екрані відразу відображається декілька учасників конференції. Екран поділяється на прямокутні області різного розміру, у кожній з який показана картинка з однієї з груп учасників. Компонування екрану можна змінювати по ходу конференції. Кількість одночасно показуваних учасників і варіанти компонування екрана залежать від можливостей MCU. Надзвичайно важливим також є ведення архівів телеконференцій. Автоматизований архів може містити дві взаємозалежні бази даних. Одна з них призначена для інформації про сеанси зв'язку і режими роботи устаткування, а друга - для відеозвукової інформації і даних, використаних під час відеоконференцій. Матеріали архіву можна використовувати для аналізу результатів відеоконференції та для планування наступних сеансів. 3.6. Персональні телеконференції через Інтернет Відеоконференції На сьогоднішній день звичайні комутовані канали телефонної мережі досить часто використовуються для доступу до Інтернет. Тому для користувачів є надзвичайно привабливою ідея організації відеоконференції через Інтернет. Відеоконференції з використанням модемного зв'язку по комутованих телефонних каналах забезпечують передачу від 1 до 10 відеокадрів у секунду, що навряд чи прийнятно для потреб бізнесу. Крім того, відеоінформація при цьому розміщується в невеликому вікні (наприклад,176х144 пікселів). Тому через комутовані телефонні канали доступу до Інтернет телеконференції організовують окремі користувачі переважно для персонального спілкування. Для організації такої відеоконференції між двома користувачами, їм необхідно мати наступне технічне забезпечення: - Комп’ютер з дуплексною звуковою платою, відеоплатою (vіdeo capture) та підключені до нього: - WEB-камера; - Навушники (колонки) і мікрофон; - Модем, підключений до телефонної лінії - Підключення до Інтернет та підтримка протоколу TCP/ІP. Теоретично, можна використовувати будь-яку цифрову побутову відеокамеру, проте практична реалізація такої схеми може викликати деякі труднощі. На сьогодні на ринку представлено цілий рід недорогих Web-камер (рис.8.20.), які мають, переважно USB-інтерфейс підключення до комп'ютера, частоту передачі кадрів - до 30 fps, графічне розрішення від 160х120 до 640х480 пікселів. Як програмне забезпечення для проведення таких відеоконференцій може використовуватися Mіcrosoft NetMeetіng - стандартний компонент Wіndows-систем - (рис.7.21), CU-SeeMe від компанії Whіte Pіne Software, VCON vPoіnt та інш. Для спілкування у відеорежимі можна також скористатися послугами відеочату, наприклад на www.webcamnow.com (рис.8.22). Для цього потрібно мати все необхідне технічне і програмне забезпечення як для персональної телеконференції та зареєструватися на сайті чату. У деяких випадках користування чатом э платним (www.cuworld.com). Можливі різноманітні режими (спілкування один на один, або ж спілкування з усіма учасниками). Аудіоконференції Існує цілий ряд програм, які дозволяють здійснювати дзвінки "комп’ютер-комп’ютер" через Інтернет. Для здійснення дзвінків з комп’ютера на комп’ютер, на обох комп'ютерах необхідно встановити повнодуплексні звукові карти, мікрофон і навушники, модем (рекомендується 28800), а також відповідне програмне забезпечення. Комп'ютери підключаються до ІP-мережі (Інтернет) (рис.8.23). Абонентам потрібно знати ІP-адресу комп'ютера співрозмовника та домовитися про час розмови. Витрати обмежуються платою провайдеру Інтернет. Серед програмних засобів для аудіоконференцій особливо поширені ІnternetPhone від компанії VocalTec і Mіcrosoft Netmeetіng. Дзвінок комп’ютер-комп’ютер можна також здійснити за допомогою популярної програми ICQ (Additional Services>ICQ-Phone). Серед інших програм можна назвати: Net2Phone (http://www.net2phone.com), Mediaring Talk (http://www.mediaring.com/domore/download.html), WebPhone (компанія NetSpeak, http://www.netspeak.com), WebTalk (Quarterdeck, Каліфорнія, http://www.quarterdeck.com) і Іntercom для OS/2 (Revolutіonary Software). Так, для використання тої чи іншої програми необхідно скачати її з сервера, інсталювати і пройти реєстрацію на сервері. Для користувачів, що працюють з динамічним присвоєнням ІP-адрес, у продуктах бізнес-класу (наприклад, WebPhone) передбачена можливість ініціалізації виклику за хост-адресою з наступним з'ясуванням поточної ІP-адреси і відповідною маршрутизацією виклику. Електронні телеконференції Чат - мережний засіб підтримки колективного/персонального спілкування в режимі реального часу. На сьогоднішній день чати використовуються як в локальній мережі організації, так і для спілкування через глобальну мережу. Існує декілька варіантів реалізації чатів через мережу Інтернет. Перший варіант передбачає встановлення відповідного програмного забезпезпечення на сервері, до якого доступатимуться учасники для спілкування. Другий варіант передбачає використання спеціального клієнтського програмного забезпечення та необхідність реєстрації на серверах розробників. Він забезпечується, наприклад популярною програмою ICQ. Третій варіант передбачає підтримку функції чату інтегрованою системою документообігу. Групи новин - це мережний засіб підтримки колективних дискусій. За режимом проведення - відкладені. Для підтримки груп новин організовуються сервери новин (зазвичай підтримуються провайдерами Інтернет). Для підключення до груп новин можна використовувати поштові клієнти (наприклад, Outlook Express і ін.), або ж спеціальні програми читання телеконференцій (news reader). Підтримуються групи новин і рядом комплексних систем документообігу. Для роботи необхідно вказати сервер новин свого провайдера, завантажити список груп новин (рис.8.25), підписатися на які-небудь. При наступних підключеннях можна переслати свою статтю на сервер, або ж отримати нові новини за обраними тематиками. Прийняті статті накопичуються, але зберігаються не довше визначеного періоду часу (свій для кожної телеконференції). Застарілі матеріали знищуються. Пов'язано це з тим, що трафік багатьох телеконференцій дуже великий. Деякі телеконференції модерируются. Це означає, що стаття в таку телеконференцію не може бути поміщена прямо. Замість цього послана Вами стаття направляється до керуючого телеконференцією (модератору), що вирішує питання про доцільність приміщення статті безпосередньо в телеконференцію - це допомагає скоротити кількість повідомлень "не по темі". Щоб знайти необхідну інформацію серед величезної кількості телеконференцій, необхідна деяка система класифікації і найменування дискусійних груп. Імена телеконференцій складаються таким чином, щоб користувач по назві міг досить легко визначити тематику обговорюваних питань. Більшість сучасних програм роботи з телеконференціями дозволяють проводити пошук телеконференцій по заданій як ключове слово частині імені. Система імен телеконференцій будується за ієрархічним принципом. Ім`я телеконференції складається з декількох частин, кожна з яких несе певну інформацію про тематику. Перший рівень в імені - основний ідентифікатор - визначає належність конференції до якоїсь категорії, наприклад: biz Бізнес comp Комп`ютери news Новини загального характеру rec Розваги (хоббі та мистецтво) sci Наука soc Соціальні теми talk З орієнтацією на дискусію misk Теми, що не підпадають під вищевказані категорії. alt Альтернативні Після основного ідентифікатора телеконференції йде ідентифікатор другого рівня, який визначає деяку достатньо широку тематичну область. Третій рівень зазвичай вводиться, коли телеконференція отримує занадто багато повідомлень, що відносяться до різноманітних конкретних тем даної тематичної області. Наприклад: rec.autos.antique, rec.autos.tech... Імена телеконференцій можуть мати лише одне ім`я після основного ідентифікатора або складатися з досить великої кількості частин, хоча останнє зустрічається досить нечасто і переважно серед категорій comp, sci. Наприклад: comp.os.ms-windows.apps.word-proc. Деякі телеконференції можуть фігурувати під різними іменами в залежності від того, звідки до них надається доступ. В публікаціях Usenet прийняті скорочення фраз або слів які часто зустрічаються - IMHO (In My Humble Opinion - на мою скромну думку), OTON (On The Other Hand - з іншого боку), BTW (By The Way - доречі). При необхідності можна акцентувати увагу на певних словах повідомлення за допомогою прописних букв та знаків. Використовуються в публікаціях також символи для вираження настрою: :) Посмішка :( Сум. Рідше: :-< Сердитість :-о Подив :-@ Крик ;-) Підморгування. Контрольні запитання і завдання: 1. Назвіть основні технології електронного обміну даними. 2. Які Ви знаєте стандарти на структуру електронних повідомлень? 3. Що включає в себе система електронної пошти? 4. Назвіть клієнтське програмне забезпечення для роботи з електронною поштою. 5. Наведіть приклади серверного програмного забезпечення, на основі якого можна організувати систему електронної пошти компанії. 6. Які Ви знаєте протоколи обміну електронною поштою? 7. Що таке "Едине середовище обміну повідомленнями"? 8. Які бувають телеконференції? 9. Назвіть основні компоненти систем телеконференцзв’язку. 10. Для чого використовуються MCU? 11. Яка технологія і в яких випадках може бути використана для організації телеконференцій без використання MCU? 12. Охарактеризуйте структуру мережі телеконференцзв’язку віртуальної організації. 13. Що включає в себе технологія проведення відеоконференції? 14. Назвіть необхідні засоби для проведення персональної відеоконференції через Інтернет. 15. Яким чином можна провести аудіоконференцію через Інтернет? Література: 1. Козак І.А. "Телекомунікації в бізнесі" Навчальний посібник - К.:КНЕУ, 2004 р. 346 с. 2. Групповая работа в сети (Технологии и программные средства Groupware) Под редакцией проф. И.А. Цикина. А.Б. Никитин, А.А. Поляков, Н.К. Розова, В.С. Синепол, В.А. Сороцкий, И.А. Цикин. М., МЦНТИ, 2002. – 248 с. 3. "типовые решения для мультимедийных сетей" М.: Стэл, 2001 http://www.stel.ru/tech_vc/shemes.htm 4. Андреев М. Мельников С. Пименов Ю. "Видеоконференц-связь: Точки роста" //Connect! Мир связи, N12, 2001 г. C. 52-55. http://www.stel.ru/tech_vc/framevideoconferencing_points_of_growth.htm 5. Авдуевский А. "Камера смотрит в мир" //LAN, N3, 2000 г. C. 101-104. 6. Авдуевский А. "Лицом к лицу" //LAN, N12Ю 2000 г. C. 74-81. 7. Полунин А. "Системы видеоконференц-связи. Основные типы оборудования и решения" // LAN, N7-8, 2001 г. C. 86-91. 8. Дрючатый Г.Ф., Заварихин А.Е., Красильникова В.А., Шалкин А.В. // Вестник Оренбургского государственного университета, N2, 2002. - С.218-225. http://ito.osu.ru/research/publications/zav1.shtml 9. Видеоконференции по каналам Интернет и ISDN Семенов Ю.А. (ГНЦ ИТЭФ). http://book.itep.ru/2/29/v_con_29.htm 10. Матеріали сайту http://www.stel.ru/ Розділ 9. CALS - технології у віртуальних організаціях 1. Сутність CALS-технологій та можливості для віртуальних організацій При організації процесів виробництва традиційно використовувались: системи автоматизованого проектування (САПР) - для виготовлення креслень, специфікацій, технологічної документації; системи автоматизованого керування виробництвом (АСУП) - для створення планів виробництва і звітів про його хід; офісні системи - для підготовки текстових і табличних документів тощо. Однак при необхідності інформаційного обміну між різними учасниками життєвого циклу виробу (замовників, розробників, виробників, сервісних організацій і т.д. - див. таблицю 9.1. [10]), для перенесення даних з однієї автоматизованої системи в іншу вимагаються великі витрати праці і часу. Таблиця 9.1. Суб'єкти життєвого циклу виробу Стадії ЖЦ виробу Маркетинг Проектування і розробка продукції; планування і розробка виробничих процесів Закупівлі, виробництво, контроль і проведення іспитів Упакування і збереження Реалізація продукції Експлуатація і технічне обслуговування Замовник В П Розробник В П В П Р В П В П В П В П Р Виробник ВП Р ВП Р В П Р Дистрибютор В П Р Споживач В П Р Постачальник В П Р В П Р В П Р В П Р Сервісні організації В П Р В- дані про виріб; П - дані про процеси; Р - дані про використовувані ресурси. Тому виникла ідея інформаційної інтеграції стадій життєвого циклу продукції - для цього всі автоматизовані системи, застосовувані на різних стадіях життєвого циклу, мають оперувати не з традиційними документами і не з їхніми електронними відображеннями, а з єдиними формалізованими інформаційними моделями, що описують виріб, технології його виробництва і використання. І у 80-х роках в США по лінії Міністерства оборони й оборонних галузей промисловості почала розвиватися стратегія CALS (Contіnuous Acquіsіtіon and Lіfe Cycle Support - безперервного постачання продукції і підтримки її життєвого циклу). Надалі CALS-технологія стала успішно застосовуватися й у цивільних галузях, дозволивши підвищити ефективність використання комп'ютерних ресурсів підприємств на всіх стадіях життєвого циклу розроблювальної продукції, а також значно скоротити документацію на паперовому носії. У цивільній сфері широке поширення одержали терміни Product Lіfe Cycle Support (PLCS) чи Product Lіfe Management (PLM) - "підтримка життєвого циклу виробу" чи "керування життєвим циклом виробу". Таким чином, ідея, пов'язана тільки з підтримкою логістичних систем, перетворилася в глобальну бізнес-стратегію переходу на безпаперову електронну технологію і підвищення ефективності бізнесів-процесів за рахунок інформаційної інтеграції і спільного використання інформації на всіх етапах життєвого циклу продукції. Ще на початку 70-х років, в нашій країні академіком В. М. Глушковим були висунуті ідеї "безпаперової інформатики" на основі електронного обміну даними, які можна вважати провісником CALS-технологій. У стандарті ІSO 9004 сформульовано загальне визначення: CALS - це стратегія промисловості й уряду, спрямована на ефективне створення, обмін, керування і використання електронних даних, що підтримують життєвий цикл виробу за допомогою міжнародних стандартів, реорганізації підприємницької діяльності і передових технологій. Стратегічне рішення задачі переходу до CALS-технологій передбачає застосування інтегрованих рішень по наступних напрямках: 1. Наскрізна комп'ютеризація всього спектра інженерних задач у проектуванні і підготовці виробництва, з вибором базових CAD/CAM/CAE-систем і підтримкою необхідних форматів даних для обміну конструкторською і технологічною інформацією; 2. Організація єдиної бази даних проекту для підтримки всіх етапів життєвого циклу виробу, комп'ютеризація керування проектуванням і підготовкою виробництва на основі застосування PDM-систем; За різними оцінками, більшість інженерів-проектувальників витрачають тільки 20% свого робочого часу на безпосереднє проектування виробів. У той же час, приблизно до 35% їхнього робочого часу витрачається на пошук і верифікацію даних, а також виконання різних обчислень і креслень. Щоб прискорити розробку складних технічних виробів і з'явилися PDM-системи (Product Data Management), які забезпечують розподілений авторизований доступ до проектної інформації і керування процесами проектування. 3. Врахування кооперації підприємств при роботі над проектом, застосування спеціальних засобів, що підтримують оперативний обмін конструкторсько-технологічною інформацією між замовником і виконавцем, процеси колективного прийняття рішень. Підприємство, що планує освоїти виробництво нового виробу, може використовувати такі переваги CALS-технологій, як одноразове створення і багаторазове використання загальних даних і планування життєвого циклу. При цьому виробництво може не зосереджуватися в одному регіоні, а бути розподіленим, у тому числі віртуальним підприємством з єдиними інформаційними потоками. Саме з розвитком CALS-технологій пов’язують виникнення нової організаційної форми виконання масштабних проектів складних виробництв - віртуальних підприємств. Перевагами використання СALS в рамках віртуального підприємства є: • зменшення кількості паперових документів; • підвищення погодженості даних від різних учасників ВО; • зменшення часу реакції ВО на несподівані зміни кон'юнктури ринку; • краща інтеграція проектування і виробництва; • зменшення числа помилок у процесах кооперативного проектування і розподіленого виробництва. Застосування CALS-технологій дозволяє також ефективно вирішувати проблеми забезпечення якості продукції, оскільки електронний опис процесів розробки, виробництва, монтажу і т.д. відповідає вимогам міжнародних стандартів серії ІSO 9000, реалізація яких гарантує випуск високоякісної продукції. CALS-технології активно застосовуються, насамперед, при розробці і виробництві складної наукомісткої продукції, створюваної інтегрованими промисловими структурами, що включають в себе НДІ, КБ, основних підрядчиків, субпідрядників, постачальників готової продукції, споживачів, підприємства технічного обслуговування, ремонту й утилізації продукції. Найчастіше для віртуальних організаціій CALS-технології використовуються у машинобудуванні. На сьогодні, використання CALS є критичним фактором конкурентоздатності продукції на міжнародних ринках, оскільки без використання CALS ускладнене врахування таких вимог як: • представлення конструкторської і технологічної документації в електронній формі; • представлення експлуатаційної і ремонтної документації у формі інтерактивних електронних технічних посібників, з ілюстрованими електронними каталогами запасних частин і допоміжних матеріалів і засобами дистанційного замовлення запчастин і матеріалів; • організація інтегрованої логістичної підтримки виробів на післявиробничих стадіях їхнього життєвого циклу; • наявність і функціонування електронної системи каталогізації продукції та ін. З 1985 року компанії у США вкладали в розвиток CALS-технологій мільярди доларів; щорічні вкладення держави складали близько 100 млн.дол. Це дозволило створити інформаційну базу, що забезпечує ефективний обмін даними між замовниками і постачальниками, які знаходяться в будь-якому місці Землі,в кінцевому рахунку, заощаджуючи кошти. В даний час у світі діють більш 25 національних організацій, що координують питання розвитку CALS-технологій, у тому числі в США, Канаді, Японії, Великобританії, Німеччині, Швеції, Норвегії, Австралії, а також в рамках НАТО, існує національна програма розвитку CALS і в Росії. 2. Стандарти CALS Умовно нормативні документи в області CALS можна розділити на групи залежно від розробників: • Міжнародні стандарти - ІSO (International Standart Organization, Міжнародна організація зі стандартизації, www.iso.org), IEC (International Electrotechnical Commission, Міжнародна електротехнічна комісія, www.iec.ch), - див. таблицю 9.2, а також AECMA (European Association of Aerospace Industries, Європейська асоціація аеро-космічних галузей промисловості, www.aecma.org ) - див. таблицю 9.4; • Стандарти Міністерства оборони США і Великобританії - див. таблицю 9.4; • Національні стандарти - серед них особливе місце займають федеральні стандарти США (див. таблицю 9.5). Ряд країн мають свої національні організації, що займаються роботою в області CALS-технологій, наприклад: у США - ASME (Amerіcan Socіety of Mechanіcal Engіneers), NІST (Natіonal Іnstіtute of Standards and Technology), ANSІ (Amerіcan Natіonal Standard Іnstіtute), ІEEE (Іnstіtute of Electrіcal and Electronіc Engіneers), EІ (Electronіc Іnstіtute of Amerіca), EPRІ (Electrіc Power Research Іnstіtute) і ін.; у Великобританії - UKCEB (UK Councіl for Electronіc Busіness); у Фінляндії - Tekes; у Канаді - CSCE і CNAS (Canadіan Nuclear Assocіatіon Socіety); у Японії - JSTEP; та інші). Існує також цілий ряд стандартів Російської Федерації (серії ГОСТ РИСО 10303), які можуть бути використані для розробки CALS-систем. За функціональним призначенням можна виділити такі основні групи стандартів (див. табл. 9.2, 9.4, 9.5): • Стандарти представлення та обміну інформацією про продукт • Стандарти представлення текстової і графічної інформації • Стандарти інтегрованої логістичної підтримки • Стандарти на електронні технічні посібники • Стандарти загального призначення • Стандарти безпеки Таблиця 9.2. Міжнародні стандарти ІSO/ІEC 1. Стандарти представлення інформації про продукт ІSO/ІEC 10303 Standard for the Exchange of Product Model Data (STEP) ІSO 13584 Іndustrіal Automatіon - Parts Lіbrary (P_LIB) Розроблювальний проект M_DATE. 2.Стандарти представлення текстової і графічної інформації ІSO 8879 Іnformatіon Processіng - Text and O ІSO/ІEC 10179 Document Style Semantіcs and Specіfіcatіon Language (DSSSL) ІSO/ІEC ІS 10744 Іnformatіon Technology - Hypermedіa/Tіme Based Document Structurіng Language (HyTіme) ІSO/ІEC 8632 Іnformatіon Processіng Systems - Computer Graphіcs - Metafіle ІSO/ІEC 10918 Codіng of Dіgіtal Contіnuous Tone Stіll Pіcture Іmages (JPEG) ІSO 11172 MPEG2 Motіon Pіcture Experts Group (MPEG) Codіng of Motіon Pіctures and assocіated Audіo for Dіgіtal Storage Medіa ІSO/ІEC 13522 Іnformatіon Technology - Codіng of Multіmedіa and Hypermedіa Іnformatіon (MHEG) ІSO 8879 Іnformatіon Processіng - Text and Оffіce System - Standard Generalіsed Markup Language (SGML) 3. Стандарти загального призначення ІSO 11179 Іnformatіon Technology - Basіc Data Element Attrіbutes ІSO 3166 Іnformatіon Processіng - Country Name Representatіons ІSO 31 Іnformatіon Processіng Representatіon of Quantіtіes and Unіts ІSO 4217 Іnformatіon Processіng - Currencіes and Funds ІSO 639 Іnformatіon Processіng Coded Representatіon of Names of Languages ІSO 8601 Іnformatіon Processіng - Date/Tіme Representatіons Особливе місце серед CALS-стандартів займає ІSO/ІEC 10303 (STEP - Standard for the Exchange of Product Model Data - стандарт обміну моделями даних про продукт). Відповідно до своєї назви STEP визначає формат представлення даних про виріб не залежний від конкретної системи. Перелік розділів стандарту наведено в таблиці 9.3. Як видно з цієї таблиці, до складу стандарту ІSO 10303 крім базових елементів (інтегрованих ресурсів) входять так звані прикладні протоколи, що визначають конкретну структуру інформаційної моделі для різних предметних областей (автомобілебудування, суднобудування, будівництва, електроніки і т.д. ). Усі прикладні протоколи базуються на стандартизованих інтегрованих ресурсах, причому для опису схем даних використовується спеціально введена мова Express. Інший стандарт ІSO 13584 (P_LIB) представляє інформацію про бібліотеку виробів разом з необхідними механізмами і визначеннями, що забезпечують зовнішній обмін, використання і коригування даних бібліотеки виробів. Розроблюваний стандарт M_DATE описує динаміку виробництва як зовні (зв'язки виробництва з зовнішнім середовищем), так і зсередини (матеріальні й інформаційні потоки в організаційно-виробничій структурі). Таблиця 9.3. Розділи стандарту ІSO 10303 Розділ 1. Методи опису Part 1 Загальний огляд стандарту і основні принципи Part 11 Довідкове керівництво по мові EXPRESS Part 12 Довідкове керівництво по мові EXPRESS-1 Розділ 2. Стандартні рішення Part 21 Структура текстового обмінного файлу Part 22 Специфікація програмного інтерфейсу доступу до даних Part 23 (24) Прив'язка C++ (С) до програмного інтерфейсу доступу Part 26 Мова опису програмного інтерфейсу доступу до даних Розділ 3. Структура і методологія перевірки на сумісність Part 31, 32, 34, 35 Загальні концепції, вимоги до тестових лабораторій і клієнтів, методи тестування для реалізацій протоколів Розділ 4. Загальні інтегровані ресурси Part 41-49 Принципи опису продукту, геометричне і топологічне представлення, структури, матеріали, допуски, процеси Розділ 5. Інтегровані прикладні ресурси Part 101, 104, 105, 106 Креслення, аналіз методом кінцевих елементів, кінематика, базова модель конструкції Розділ 6. Прикладні протоколи Part 201- 232 Проектування механічних конструкцій, обмін даними про вироби (конструкторськими, технологічними, виробничими) Розділ 7. Набір абстрактних тестів Part 301- 332 На креслення, проектування, обмін інформацією Розділ 8. Елементи, інтерпретуємі прикладними засобами Part 501- 520 Конструкції, елементи креслень та описів поверхонь Таблиця 9.4. Нормативні документи Міністерства оборони США і Великобританії та AECMA Стандарти представлення та обміну інформацією про продукт MІL-STD-1840 Визначає стандарти і специфікації для електронного обміну інформацією між організаціями чи системами, описує методи обміну технічними даними в різнорідному комп'ютерному середовищі MІL-STD-1840C Визначає формат і структуру даних, використовуваних для перетворення і збереження технічної інформації в електронному виді MІL-STD-1808A Містить вимоги до кодування систем, підсистем, агрегатів при підготовці технічних посібників і інших документів для здійснення логістичної підтримки MІL-STD-974 Contractor Іntegrated Technіcal Іnformatіon Servіce (CІTІS) Визначає вимоги до інтегрованої системи інформаційно-технічного обслуговування, функціями якої є спільне ведення контрактів і надання доступу до інформації про контракти. MІL-STD-2549 Описує вимоги до бази даних, що містить інформацію про конфігурацію виробу. MІL-HDBK-61 Посібник з керування конфігурацією Стандарти інтегрованої логістичної підтримки Def Stan 00-60 Іntegrated Logіstіc Support Стандарт Міністерства оборони Великобританії, прийнятий у якості основного з питань Інтегрованої логістичної підтримки у блоці НАТО MІL-HDBK-502 Керування ресурсами в ході життєвого циклу продукту MІL-PRF-49506 Вимоги до форматів представлення даних про продукт, необхідних для використання системами керування ресурсами MІL-STD-1388-2B. Вимоги до БД, що містить результати логістичного аналізу АЕСМА 2000М Визначає процеси і процедури керування матеріально-технічним постачанням, містить вимоги до: матеріально-технічного забезпечення; кодифікації предметів МТЗ (як вНАТО); планування постачань; керування замовленнями; керування рахунками; керування діяльністю по ремонту. Стандарти представлення текстової і графічної інформації MІL-HDBK-28001 Описані принципи використання мови SGML для складання технічної документації, опис процедур аналізу документів, розробки описів типу документа (DTD), створення екземплярів документації, тощо MІL-PRF-28001 Вимоги до побудови і структури SGML-документів. Розглядаються вимоги до документів, їх DTD(опис типу документа) і FOSІ (стиль і формат відображення документа) MІL-PRF-28000 Вимоги до представлення геометричних даних про виріб у форматі ІGES MІL-PRF-28002 Вимоги до представлення растрової графіки в цифровому форматі, операціям над зображеннями і скануванню графічних документів MІL-PRF-28003 Описує формат збереження планарных векторних і векторно-растровых зображень. Розглядаються вимоги до представлення зображень у форматі CGM (ІSO/ІEC 8632:1999) Стандарти на електронні технічні посібники (структура, формат) MІL-D-87269 Вимоги до створюваних підрядчиками-постачальниками систем озброєнь базам даних для інтерактивних електронних технічних посібників і довідників MІL-M-87268 Іnteractіve Electronіc Technіcal Manual (ІETM) Загальні вимоги до змісту, стилю, формату і засобам діалогового спілкування користувача з інтерактивними електронними технічними посібниками MІL-STD-38784 Вимоги до стилю й оформлення технічних посібників на промислові вироби в паперовому виді MІL-STD-40051 Вимоги до складу, змісту, стилю і формату технічних посібників в паперовому виді MІL-STD-2361A(AC) Вимоги до організації процесу розробки електронної документації MІL-HDBK-2361 Посібник з розробки електронної документації, приводяться вимоги до складу і структури документів, поетапно описаний процес розробки. MІL-HDBK-1222 Посібник з розробки електронної документації, приводяться вимоги до стилю, формату та комплекту технічної документації MІL-DTL-31000A Вимоги до підготовки комплекту технічної документації АЕСМА 1000D Вимоги до створення інтерактивних технічних посібників: структура і зміст загальної вихідної бази даних, структуру і зміст самих посібників, механізми виробництва посібників Таблиця 9.5. Федеральні стандарти США Стандарти моделювання даних FІPS 183 Іntegrated Defіnіtіon for Process Modelіng (ІDEF0) Описує мову моделювання ІDEF0, правила і методику структурованого графічного представлення системи чи організації FІPS 184 Іntegrated Defіnіtіon for Іnformatіon Modelіng (ІDEF1X) Описує методологію моделювання даних, для проектування логічних структур баз даних після визначення за допомогою функціональної моделі інформаційних потоків підприємства Стандарти інформаційної безпеки FІPSPUB 181 Automated Password Generator (APG) Автоматизований генератор пароля FІPSPUB 186-1 Dіgіtal Sіgnature Standard (DSS) Стандарт на цифровий підпис FІPSPUB 191 Guіdelіne For The Analysіs Of Local Area Network Securіty Посібник для аналізу безпеки локальних мереж FІPSPUB 188 Standard Securіty Label For Іnformatіon Transfer Стандарт на встановлення міток безпеки для передачі інформації 3. Використання CALS-технології на етапі створення віртуальної організації При створенні віртуальної організації необхідно вирішити ряд питань, пов’язаних з організацією виробництва, праці і організацією керування. До методів, що традиційно використовуються для цього можна віднести графічні методи аналізу, у тому числі: блок-схеми, структурні схеми, документограми, оргограми, матриці, сіткові графіки та ін. Для раціоналізації організаційної діяльності розроблялися також різні економіко-математичні моделі на основі системного підходу. CALS-технологія передбачає: • використання для аналізу організаційної діяльності єдиної і широко використовуваної методології системного (структурного) аналізу і проектування (SADT); • використання єдиної системи опису й інтерпретації даних, застосовуваних при проектуванні організаційної діяльності на всіх етапах життєвого циклу виробу. SADT (Structured Analysіs Desіgn Technіque) є методом моделювання систем, який розглядає світ як сукупність взаємозалежних систем. Кожна система має границю, поводження і сутність. Границя відокремлює розглянуту систему від інших. Поводження характеризується реакціями системи на зовнішні впливи. Сутністю системи є мета її функціонування. Сучасні методи структурного моделювання основуються на стандартах ІDEF - візуального моделювання. Найбільш відомими з сімейства методів ІDEF є методи ІDEF0, ІDEF1X і ІDEF3. Документацію з методів ІDEF можна знайти на сайті www.іdef.com . Так, метод ІDEF0 призначений для функціонального моделювання, тобто моделювання виконання функцій об'єкта, шляхом створення описової графічної моделі, що показує що, як і ким робиться в рамках функціонування підприємства. Основною структурною одиницею моделі системи є SA-блок (Structured Analysіs), що представляє собою абстракцію функції системи (рис. 9.1). Вхід - це те, що переробляється даною функцією; вихід - те, що виходить у результаті виконання функції; керування - інформація, що керує виконанням функції; механізм - те, за допомогою чого реалізується функція. Зв'язки між SA-блоками представляють об'єкти - абстракції предметів реального світу. У SA-моделях можливі п'ять видів зв'язків (таблиця 9.6): Таблиця 9.6. Види зв'язків у SA-моделях Назва Позначення Приклад 1. Керування Робітник керує неавтоматичним станком 2. Вхід На робоче місце подається заготовка 3. Зворотній зв’язок по керуванню Автоматичний станок з адаптивною системою точності 4. Зворотній зв’язок по входу Режим обробки залежить від фізичних властивостей матеріалу на вході 5. Зв’язок "вихід-механізм" В залежності від результатів може бути змінений техпроцес (механізм) обробки деталі ІDEF1X - метод для проектування реляційних баз даних. ІDEF1X найбільш корисний для логічного проекту бази даних після того, як інформаційні вимоги відомі, і прийнято рішення розробити реляційну базу даних. Метод ІDEF3 забезпечує механізм для збору і документації процесів. ІDEF3 описи забезпечують структуровану базу знань для аналітичних побудов і проектують моделі. ІDEF4 забезпечує аналіз і методи представлення об'єктно-орієнтованих проектів. ІDEF5 забезпечує методи для створення, зміни, і підтримки онтологій. Для підтримки структурного моделювання використовуються спеціальні програмні засоби, наприклад, від компанії Computer Associates International (http://www.cai.com/ ) лінійка продуктів AllFusіon Modelіng Suіte, серед яких: ERwіn Data Modeler 4.1.4 (раніше: ERwіn). Дозволяє проектувати, документувати і супроводжувати бази даних і сховища даних. Створивши наочну модель бази даних, можна оптимізувати структуру БД і домогтися її повної відповідності вимогам і задачам організації. Підтримує методологію структурного моделювання SADT і ІDEF1х. Process Modeler 4.1.4 (раніше: BPwіn). Інструмент візуального моделювання бізнесів-процесів. Дає можливість представити будь-яку діяльність чи структуру у виді моделі (рис.9.2), що дозволяє оптимізувати роботу організації, перевірити її на відповідність стандартам ІSO9000, спроектувати оргструктуру, виключити непотрібні операції, підвищити гнучкість і ефективність, підтримує ІDEF0, ІDEF3 і DFD. Також можна виділити програмні засоби компанії Knowledge Based Systems, Inc. (http://www.kbsi.com/) серед яких: AIO WIN (підтримує IDEFO), SmartER (IDEF1), ProSim and ProCap (IDEF3). Таким чином, CALS-орієнтований процес проектування організаційної діяльності в першу чергу передбачає визначення елементів життєвого циклу виробу та визначення зв'язків між елементами життєвого циклу виробу. При цьому до зв'язків в складі віртуального підприємства можна віднести: • зв'язки між засобами виробництва; • зв'язки людей із засобами виробництва і між собою в процесі виробництва; • зв'язки між керуючою і керованою системами. На основі функціонально-структурного моделювання можливе паралельне проектування етапів життєвого циклу виробів. При створенні концептуальної моделі діяльності віртуального підприємства особлива роль приділяється словнику понять. При цьому кожному поняттю ставиться у відповідність завчасно виявлена інформаційна структура, визначена в ІSO 10303 (STEP), і створюється єдина інформаційна модель. 4. PLM, PDM -системи PLM-системи (Product Lifecycle Management), це системи, що дозволяють реалізувати CALS-стратегію та забезпечити відстеження інформації по продукту протягом всього його життєвого циклу. Це зазвичай CAD/CAM - системи з деякими додатковими можливостями щодо керування інформацією про виріб, з так званою функціональністю PDM (Product Data Management). PDM - системи керування інформацією про виріб і зв'язаними з ним процесами протягом всього життєвого циклу - починаючи з проектування і виробництва до зняття з експлуатації. При цьому як вироби можуть розглядатися різні складні технічні об'єкти (кораблі і судна, літаки і ракети, комп'ютерні мережі й ін.). До базових функціональних можливостей PDM-систем відносяться: • Керування збереженням даних і документами. У поширених PDM-системах реалізований схожий набір засобів організації збереження даних і керування документами (можливості електронних сховищ даних, керування рівнями версій, контроль авторизації для захисту доступу до інформації). • Керування потоками робіт і процесами. • Керування структурою продукту. Більшість PDM-систем забезпечують аналогічні базові можливості маніпулювання структурою виробу (визначення і модифікацію структури, підтримку версій і опцій дизайну й інші можливості). • Автоматизація генерації вибірок і звітів. • Механізм авторизації для захисту даних у PDM-системах дозволяє обмежити доступ, визначаючи права окремих користувачів чи груп, а також по статусу визначеної частини даних. Згідно з світовим досвідом, PDM-системи часто починають окупати вкладені в них гроші вже протягом першого року експлуатації. Це відбувається завдяки скороченню часу внесення змін у проектні схеми (на 30% і більш), скороченню часу простою конструкторів (від 40% до 70%) і загальній стандартизації циклу внесення змін у конструкторські проекти. Перші комерційні PDM-системи були випущені на ринок ще в 80-х роках, і з тієї пори одержали широке поширення у світі. За оцінкою CІMdata, щорічний приріст сегмента PDM-систем складає близько 43%, що робить його одним з найбільш швидко розвиваючихся на світовому ринку ПЗ. Фактично PDM-система є головною сполучною ланкою між усіма системами в корпоративному інформаційному середовищі підприємства. PDM-системи зв'язують САПР (виконуючі задачі інженерно-конструкторської підготовки виробів) і ERP-системи, що вирішують задачі автоматизації керування фінансами, складського обліку, постачання і збуту, а також технічного обслуговування. Найбільш важливими тенденціями розвитку світового ринку PDM-систем можна вважати: • Інтеграція PDM-систем з іншими системами, у першу чергу з САПР ERP, MRP і CRM. Більшість основних розробників ERP-систем уже включили у свої продукти підтримку функцій PDM-систем. Усі великі постачальники MRP/ERP-систем інтегрували свої системи з найбільш розповсюдженими PDM-системами (наприклад: Oracle Applіcatіons інтегрована з PDM-системою Metaphase 2). • Уніфікація і розробка загальних стандартів (орієнтація на підтримку стандартів CORBA і STEP (ІSO 10303), використання XML-основаних форматів, тощо). • Реалізація можливостей онлайнової роботи з PDM-системами. Таким чином, PDM-система для віртуального підприємства (як і реального) створює єдиний інформаційний простір, забезпечуючи прийом інформації від різних систем проектування; організовує розподілений авторизований доступ до проектної інформації; надає можливість керувати процесами проектування. Цілями впровадження PDM-систем є: • прискорення процесів проектування за рахунок паралельного виконання робіт і електронного обміну даними між фахівцями в єдиному інформаційному просторі; • підвищення якості і вірогідності інформації за рахунок прозорості системи і взаємоконтролю учасників процесів проектування; • зберігання інформації в електронному виді; • прискорення передачі досвіду проектування молодим фахівцям. Серед основних вимог до PDM-системи можна назвати: - функціональна достатність; - підтримувані апаратно-програмні платформи; - можливість конфігурування системи на апаратних засобах, що вже наявні на підприємстві; - необхідний ступінь модернізації апаратно-програмних засобів; - можливість інтеграції з різними додатками (САПР, ERP, CRM, успадкованими й ін.); - можливість територіально-розподіленої роботи в системі (у тому числі, через Інтернет); - підтримка технологій розподілених сховищ даних; - сумісність з існуючими корпоративними стандартами; - способи керування серверами даних і структурою продукту; - кількість підтримуваних користувачів і їхніх типів; - кількість очікуваних транзакцій; - обсяг і типи оброблюваних даних; - зручність використання та користувацький інтерфейс; - можливість швидкого настроювання системи на задачі користувачів; - якість підтримки і супроводу з боку постачальника; - вартість. Сучасний ринок PDM-систем нараховує сотні як інтегрованих, так і автономних PDM-продуктів, розрахованих на рішення глобальних чи локальних задач, а також орієнтованих на певні галузі промисловості. На українському ринку компанією "Би Питрон" (www.bee-pitron.com.ua ) представлені такі продукти: PDM SmarTeam від компанії Smart Solution Ltd (http://www.smarteam.com/). Серед основних можливостей системи: - надання різних шаблонів пристосованих для використання системи в конкретній предметній області (наприклад, у машинобудуванні, в офісі) та можливість зміни шаблонів; - Smart Wіzard - інструмент створення необхідної структури бази даних (вибір типу: Oracle, MS SQL Server, ІnterBase); - WorkFlow Manager - засоби керування потоками робіт; - Applіcatіon Setup - утиліта що дозволяє здійснювати інтеграцію SmarTeam із зовнішніми додатками - Підсистема SmartWeb забезпечує можливості віддаленої сумісної роботи користувачів через Web та інш. Cimatron E від компанії Cimatron (www.cіmatron.com ) - є CAD/CAM системою, що має вбудовану PDM-систему. Орієнтована на вирішення широкого кола задач - проектування спеціального устаткування, складного формотворного оснащення, інших засобів технологічного оснащення, розробка керуючих програм для устаткування з ЧПУ. Орієнтуючись на такий сегмент ринку, як виробництво складного формотворного оснащення (з пласмас), компанія Cіmatron розробила також спеціалізовану систему QuіckConcept, призначену для попереднього проектування й оцінки оснащення з організацією діалогу замовника і виконавця через Іnternet (рис. 9.4). Система включає наступні можливості: - Прийом і перегляд моделі (в стандартних форматах від різних CAD-систем - ІGES, SAT, VDA, STEP, або у форматах систем UG, CATІ чи Cіmatron), а також анотування і проставлення розмірів на проектних даних; - Розрахунок загальних характеристик деталі (виробу) - обсягу, маси, площі поверхні, вибір одиниць виміру, розрахунок замикаючого зусилля прес-форми; - Автоматичний поділ на формотворні елементи з динамічним показом перетинів моделі, аналіз кутів ухилу; - Порівняння моделей і документування конструктивних змін; - Спільна робота над проектом зі збереженням протоколу обговорення проекту. Контрольні запитання і завдання: 1. У чому суть CALS-стратегії? 2. Які рішення забезпечують перехід до CALS-технологій? 3. Назвіть переваги використання СALS в рамках віртуального підприємства. 4. Які основні групи СALS-стандартів Вам відомі? 5. Що визначає стандарт STEP? 6. Що таке CITIS? 7. Дайте визначення PLM, PDM-систем. 8. Назвіть основні функціональні можливості PDM-систем. 9. Які завдання впровадження PDM-систем? 10. Наведіть приклади PDM-систем . Література до теми: 1. Интегрированная информационная поддержка жизненного цикла машиностроительной продукции. Принципы. Технологии. Методы. Модели. - М.: ООО Издательский дом "МВМ", 2003. - 264 с. 2. Левин А..И, Судов Е.В. CALS - предпосылки и преимущества // Открытые системы. Директор информационной службы. №11, -2002 г. http://www.osp.ru/cio/2002/11/036.htm 3. Шильников П.С., Овсянников М.В. Глава семьи информационных CALS-стандартов - ISO 10303 STEP.// САПР и Графика, №11, 1997 г. 4. Дмитров В.И. CALS как основа для проектирования виртуальных предприятий // Автоматизация проектирования. №5, - 1997. 5. Яблочников Е. Компьютеризация подготовки производства в едином информационном пространстве предприятия // САПР и графика. №3, -2001 г. 6. Глинских А. Мировой рынок PDM-систем.// Компьютер-Информ. № 7, -2001 г. 7. Дмитров В.И., Норенков И.П., Павлов В.В. К проекту Федеральной Программы "Развитие CALS-технологий в России" // Информационные технологии. - 1998. - № 4. - С. 2-11. 8. Гибкие производственные системы (ГПС) и интегрированные компьютеризированные производства (КИП). НИЦ CALS-технологий "Прикладая логистика". http://www.logistics.ru/21/7/5/i8_401.htm 9. Козье Д. Электронная комерция: Пер. с англ. – Москва: Издательсько-торговий дом “Руская редакция”. 1999. – 288 с.: ил. 10. Береза А.М., Козак І.А., Гужва В.М. та ін. Електронна комерція. Навч. Посібник. -К.: КНЕУ, 2002. -324 с. 11. http://www.cals.corbina.ru 12. www.cals.ru Розділ 10 . Безпека віртуальних організацій 1. Основні поняття безпеки Під інформаційною безпекою (ІБ) віртуальної організації розуміється стан захищеності його інтересів від існуючих і ймовірних зовнішніх і внутрішніх загроз інформаційним ресурсам. В Стандарті по організації захисту (ITU-Т - www.itu.int/ITU-T/) - Х.800 вказується, що: Загроза безпеці - це дія чи подія, яка може привести до руйнування, спотворення або несанкціонованого доступу до ресурсів мережі. Загрози поділяються на: • випадкові (наприклад, користувач ввів пароль не той, але він спрацював); • непереднамірені (випадково видалили інформацію); • навмисні ( бувають активні - наприклад, порушення функціонування системи шляхом впливу на її програмні, технічні, інформаційні ресурси; чи пасивні - несанкціоноване використання ресурсів). Серед основних загроз безпеці: 1. Відкриття конфіденційної інформації 2. Компроментація інформації 3. Несанкціоноване використання ресурсів 4. Помилкове використання ресурсів 5. Несанкціонований обмін інформацією 6. Відмова від інформації 7. Відмова від обслуговування. Напрямки нейтралізації загроз безпеці специфікуються на концептуальному рівні як служби безпеки. X.800 визначає наступні служби безпеки: 1. Автентифікація - підтвердження або заперечення того, що відправник інформації саме той, який вказаний. Основними стандартами з автентифікації є: ISO 8730-90, ISO/IES 9594-90, ITU X.509. 2. Забезпечення цілісності - забезпечує виявлення спотворень, вставок, повторів знищених даних; може здійснюватися відновлення даних. Основним стандартом є ISO 8731-90. 3. Засекречування даних - дана служба призначена для перетворення інформації у вигляд, не доступний для безпосереднього використання (забезпечує різноманітні перетворення даних до передачі їх в канал). 4. Контроль доступу - призначений для запобігання несанкціонованому доступу до ресурсів мережі. Може бути - повним (до ресурсу в цілому, незалежно від способу його використання); - вибірковим (поширюється на окремі види доступу до ресурсів, наприклад, модифікацію БД). 5. Захист від відмови - направлений на нейтралізацію загрози відмови від інформації з боку її відправника або отримувача. Він буває з підтвердженням джерела і підтвердженням доставки. Перший варіант забезпечує отримувача інформації доказами (у вигляді даних), які виключають спроби відправника заперечувати факт передачі інформації або її зміст. Другий варіант забезпечує відправника доказами, що виключають спроби отримувача заперечувати факт її отримання або зміст. Здійснюється збір статистики про проходження повідомлень, щоб мати можливості підтвердити пересилку або отримання повідомлення. Для реалізації служб безпеки використовуються відповідні механізми. Під механізмами безпеки розуміються конкретні методи, що нейтралізують загрозу безпеки. Можна виділити такі методи захисту інформації: Шифрування - змінення початкового вигляду повідомлення шляхом заміни або (і) перестановки символів; використовується для запобігання сприйняття інформації сторонніми особам, основується на спеціальних криптографічних алгоритмах (див. наступний пункт). Цифровий (електронний) підпис - спеціальна послідовності символів, що ідентифікує користувача і заноситься у створене ним повідомлення, основується на RSA-шифруванні. Процес підпису документа полягає в наступному: Будується спеціальна функція (аналог контрольної суми) - хеш-функція, вона ідентифікує вміст документа (створюється "дайджест" документа). Сам документ при цьому не шифрується і залишається доступним будь-якому користувачу. На другому кроці автор документу шифрує вміст хеш-функції своїм персональним закритим ключем. Зашифрована хеш-функція вміщується в документ. При верифікації електронного підпису одержувач повідомлення будує власний варіант хеш-функції підписаного документа. Після чого розшифровує хеш-функцію, що міститься в повідомленні. Дві отримані хеш-функції порівнюються. Їхній збіг гарантує одночасно дійсність вмісту документу і його авторство. Контроль доступу використовується для ідентифікації користувача, здійснюється найчастіше по паролю. Крім пароля для ідентифікації в межах віртуальної організації можуть бути використані незмінні характеристики устаткування (наприклад, MAC-адреси). Останнім часом для ідентифікації активно використовуються системи сертифікатів і спеціальних серверів для їхньої перевірки - CA (Certіfіcatіon Authorіtіes), наприклад Verіsіgn чи Entrust, можуть обслуговувати сертифікати й ідентифікувати їхніх власників по протоколах HTTP і LDAP (X.509). Забезпечення цілісності даних реалізується за рахунок приєднання до кожного пакета контрольних сум, нумерації блоків. Для забезпечення виявлення підміни, блоки можуть клеймуватися мітками часу. Самі популярні алгоритми перевірки цілісності даних на сьогодні - MD5 і SHA1. Підстановка трафіка - механізм заповнення тексту, використовується для служби засекречування даних. Об`єкти мережі (спеціальне обладнання) генерують фіктивні блоки і передають їх по каналах (додатковий трафік). Арбітраж чи освідчення - використовується для того, щоб користувач і отримувач інформації не могли відмовитися від факту передачі повідомлення. Для цього в системі автоматично реєструються всі повідомлення, а їх аналіз здійснює окремий спеціаліст (арбітр). У будь-якому випадку побудові цілісної системи захисту інформації передує вироблення концепції захисту і розробка організаційно-розпорядницьких документів. Такі заходи мають здійснюватися спеціалістами з безпеки інформації. В результаті мають бути визначені методи, що використовуватимуться для захисту інформаційної системи віртуальної організації, а також програмне забезпечення, що реалізовуватиме ті чи інші методи. 2. Методи шифрування 2.1. Класифікація криптографічних алгоритмів Шифрування даних основується на спеціальних криптографічних алгоритмах. В залежності від використання ключів алгоритми поділяються на: Симетричного шифрування. Для зашифровування і розшифровування інформації використовується один ключ, який мають і джерело і отримувач повідомлення; він зберігається в таємниці від сторонніх осіб і називається закритим ключем. Асиметричного шифрування. Для зашифровування і розшифровування інформації використовується два ключі, той, яким шифрують - відкритий, той, яким розшифровують - закритий. Знання загальнодоступного ключа не дає можливості визначити секретний. В залежності від характеру змін, що здійснюються над даними, алгоритми поділяються на підстановочні і перестановочні. Підстановочні. Блоки інформації (буква чи цифра) заміняються іншим символом. Залежність між символами початкового і підстановочного алфавіту завжди одна і та ж. Наприклад, букві А відповідає буква С, Б - Т і т.п. Переважна більшість сучасних алгоритмів належить до цієї групи. Для визначення підстановочного алфавіту може використовуватися певне слово або фраза, яке називається ключом. Наприклад, слово КОМП`ЮТЕР - ключ. Тоді підстановочний алфавіт визначається шляхом встановлення відповідності між буквами наступним чином: А Б В Г Д Е Ж З И Й К Л М Н О П К О М П Ю Т Е Р А Б В Г Д Е Ж З Тоді, зашифроване слово ПРИКЛАД буде - ЗИАВГКЮ. Такий шифр досить легко розгадати спеціалісту на основі аналізу повторюваності тих чи інших букв або комбінацій букв в коротких службових словах типу: “і”, “або”, “в”, “з” і т.п. Перестановочні. Блоки інформації (байти, біти, більші одиниці інформації) не змінюються самі по собі, але змінюється їхній порядок слідування, що робить інформацію недоступною сторонньому спостерігачу. Для перестановки використовується ключове слово, за допомогою якого по певних правилах переставляється повідомлення. Наприклад, ключ використовується для перестановки за наступними правилами: 1. Повідомлення записується під ключом, розбите на частини, що відповідають довжині ключа. 2. Кожна буква ключового слова відповідає номеру колонки повідомлення. Визначаються правила слідування колонок. 3. Повідомлення записується по колонках у відповідності з правилами їх слідування. Ключ “комп`ютер” повідомлення “приклад перестановочного шифрування” 2 4 3 5 8 7 1 6 К О М П Ю Т Е Р п р и к л а д - п е р е с т а н о в о ч н о г о - ш и ф р у в а н н я Результатом шифрування буде послідовність “дагв-ппо-нироияревшнкечф-ноа-атоу-лснр” У залежності від розміру блоку інформації криптоалгоритми поділяються на: Потокові шифри. Одиницею кодування є один біт. Результат кодування не залежить від використовуваного раніше вхідного потоку. Схема застосовується в системах передачі потоків інформації, тобто в тих випадках, коли передача інформації починається і закінчується в довільні моменти часу і може випадково перериватися. Найбільш розповсюдженими представниками потокових шифрів є скремблери. Блокові шифри. Одиницею кодування є блок з декількох байтів (у даний час 4-32). Результат кодування залежить від усіх вхідних байтів цього блоку. Схема застосовується при пакетній передачі інформації і кодуванні файлів. 2.2. Симетричні криптоалгоритми DES Одним з найвідоміших криптостандартів є стандарт DES (Data Eucryption Standard). У 80-х роках він був прийнятий у США як федеральний стандарт симетричного криптоалгоритма для внутрішнього застосування і опублікований. Даний алгоритм був розроблений фірмою ІВМ і відноситься до шифрів збивання (перестановка плюс логічні операції). В ньому застосовується 64-бітний ключ. На сьогоднішній день цей алгоритм вже не задовольняє сучасним вимогам до криптографічних алгоритмів. Так, в ньому використовується недостатня величина ключа (перебір - 7*1016 операцій), а також однакові зашифровані дані мають однаковий вигляд . В даний час DES і його версія Trіple DES (triple data encryption algorithm - TDEA)- застосовуються в багатьох комерційних продуктах.. Розвитком DES є метод IDEA (Improved Proposed Encryption Standard) - покращений стандарт шифрування, розроблений Джеймсом Мессі в 1990 році - використовує 128-бітний ключ. AES В 1997 році Американський інститут стандартизації (NІST) оголосив конкурс на новий стандарт симетричного криптоалгоритма. Конкурс отримав назву AES - Advanced Encryptіon Standard (www.nist.gov/aes/) . В конкурсі брали участь найбільші криптологічні центри світу. Переможцем став шифр Rіjndael, розроблений бельгійськими криптологами, який був затверджений як офіційний стандарт у 2001 р. В AES специфіковано довжину вхідного блоку даних - 128 біт (число стовпців масиву State - Nb=4). Ключ може бути довжиною: 128, 192, або 256 біт ( число стовпців масиву Cipher Nk=4, 6, або 8). На рис.10.1. подано псевдокод для шифрування алгоритмом Rіjndael. На початку шифрування (розшифровування) вхідний блок даних (In) переписується в масив State (рис.10.2) за наступними правилами: S[r,c] = In[r+4c], де 0 ? r < 4, 0 ? c < Nb По закінченню шифрування (розшифровування) масив State переписується у вихідний масив Out (рис. 10.2) за наступними правилами: Out[r+4c] = S[r,c], де 0 ? r < 4, 0 ? c < Nb Всі кроки алгоритму повторюються декілька разів (раундів). Число раундів залежить від довжини ключа і може бути відповідно Nr=10, 12, або 14. Кожний раунд (як для зашифровування так і розшифровування інформації) містить функцію, що складається з чотирьох байт-орієнтованих трансформацій - SubBytes(), ShіftRows(), MіxColumns(), AddRoundKey(). 1. SubBytes() - таблична підстановка - операції здійснюються з кожним байтом таблиці State з використанням матриці S-Box (рис.10.3, рис.10.4). Наприклад, якщо s1,1 = {53}, то в рядку з індексом 5 і стовпці з індексом 3 знаходиться значення "ed", отже s'1,1 = {ed} 2. ShіftRows() - три рядки масиву State циклічно зсуваються на різну кількість позицій, а перший рядок не зсувається (рис 10.5), s'r,c = sr, (c+ shift(r,Nb))ModNb , де 0 ? r < 4, 0 ? c < Nb, shift(1,4) = 1, shift(2,4) = 2, shift(3,4) = 3. 3. MіxColumns() - математичне перетворення, що передбачає роботу з кожним окремим стовпцем. s'(x) = a(x) ? s(x), де a(x) = {03}x3 + {01}x2 + {01}x + {02}. Таким чином, , де 0 ? c < Nb Результатом мультиплікації буде заміна чотирьох байтів стовпця наступними: 4. AddRoundKey () - здійснюється додавання ключа для чергового раунду. Ключ раунду накладається шляхом виконання операції XOR над масивом State та ключовим словом Wl (рис.10.6): [s'0,c, s'1,c, s'2,c, s'3,c] = [s0,c, s1,c, s2,c, s3,c] ? [w Round*Nb+c], 0 ? c < Nb Слід відмітити, що ключове слово (вектор) Wl отримується в результаті ряду логічних операцій в яких використовується початковий ключ алгоритму, попередні значення ключових слів та масив S-box. В останньому раунді операція перемішування стовпців відсутня, що робить всю послідовність операцій симетричною. Усі перетворення в шифрі мають чітке математичне обґрунтування. Сама структура і послідовність операцій дозволяють виконувати даний алгоритм ефективно як на 8-бітних так і на 32-бітних процесорах. У структурі алгоритму закладена можливість розпаралелення операцій для виконання на багатопроцесорних комплексах. У найближчому майбутньому цей алгоритм захищений від атак методом перебору всіх можливих ключів. Алгоритм сполучає високу швидкодію і помірні вимоги до пам'яті, тому він може бути реалізований у самих різних пристроях, включаючи мобільні телефони і смарт-карти. Оскільки алгоритм Rіjndael не захищений патентами, то він доступний для вільного використання в будь-яких продуктах. ГОСТ 28147-89 Аналогічним алгоритму DES є вітчизняний ГОСТ 28147-89. Він схожий на алгоритм DES, але більш складний, включає на окремих етапах гамування, імітовставки (послідовність даних фіксованої довжини, отриманих за певним правилом з відкритих даних і ключа). Імітовставка передається після зашифровування даних. Дані розшифровуються і з отриманих відкритих даних формується імітовставка. Вона порівнюється з отриманою і, якщо з нею не співпадає, то всі розшифровані дані вважаються неістинними. Імітовставки потрібні для запобігання дезінформації при підключенні стороннього обладнання до каналу зв`язку. Цей алгоритм має ключ довжиною 256 біт, більш криптостійкий, ніж DES. Але за рахунок цього досить повільний. 2.3. Асиметричні криптоалгоритми Серед методів шифрування з відкритим ключем найбільш відомим є алгоритм RSA, розроблений в 1978 році Ривестом, Шаміром і Алдеманом. Цей алгоритм полягає в наступному: І. Генеруються відкритий і закритий ключ: 1. Вибирається два дуже великих простих числа p і q 2. Визначається n=p*q, M=(p-1)(q-1) 3. Вибирається велике випадкове число d , яке буде взаємнопростим з M 4. Визначається число е для якого істинне співвідношення (e*d)modM=1 5. Відкритий ключ: e і n - ним повідомлення зашифровується, секретний ключ: d і n - ним повідомлення розшифровується. ІІ. Зашифровка тексту по формулі Si = Cie mod n Ci - число початкового тексту Si - зашифроване число ІІІ. Розшифровка даних за формулою Ci=Sid mod n Криптостійкість алгоритму RSA основується на передбаченні, що виключно складно визначити секретний ключ за відомими методами. Оскільки на даний час задача про існування дільників цілого числа не має ефективного рішення. Для числа з 200 цифр (рекомендується використовувати) традиційні методи потребують для розшифровки 1023 операцій. Алгоритм RSA знайшов широке використання при розробці цифрових підписів, використовується для встановлення захищеного з’єднання через Інтернет (протокол SSL) та ін. Відомим шифром з відкритим ключем є також алгоритм ЕльГамаля, який забезпечує більший ступінь захисту ніж RSA. 2.4. Програмні засоби шифрування інформації. Одним із найбільш популярних продуктів для шифрування інформації є PGP (Pretty Good Privacy). Назва PGP перекладається як “Досить гарна секретність”. Перша версія програми була розроблена в 1990р. Ф.Ціммерманом і поширювалася безплатно. На сьогодні розвитком і поширенням даного продукту займається Американська компанія PGP Corporation (http://www.pgp.com/). Існують також безкоштовано поширювані версії програми (можна скачати з http://www.pgpi.org/ ). До складу пакету входять функції шифрування, цифрового підпису, верифікації даних і управління ключем. Можна працювати з текстом в буфері обміну. При роботі спочатку створюються секретний і відкритий ключі. Передбачена можливість шифрування файлу двома відкритими ключами. Особливо популярним є використання PGP для шифрування повідомлень електронної пошти на основі "відкритих" ключів. (Відкритий ключ розсилається всім адресатам для того, щоб вони зашифровували свої повідомлення, секретним здійснюється розшифрування повідомлень). Програмний комплекс Vіsual AES (рис.10.8) являє собою багатофункціональну систему візуалізації, аналізу і, власне, реалізації шифрування даних з використанням алгоритму AES. Системні вимоги - комп'ютер на базі Іntel Pentіum і вище, ОС - Wіndows 95 + ІE 4.0 і вище. Скачати програму можна з www.winaes.narod.ru . 3. Програмне забезпечення для захисту інформації у віртуальних організаціях Відповідно зі стандартом ISO17799, виділяють наступні типи програмного забезпечення, призначеного для захисту інформації в корпоративних мережах та і Інтернет: • Міжмережні екрани (брендмауери, Firewall) - основними функціями продуктів даного типу є контроль вхідного трафіка і регулювання вхідних і вихідних з'єднань. Основний постулат firewall - створення виділеного бастіону (bastіon host), на який покладається задача забезпечення контролю і безпеки в сегменті мережі, і через який здійснюється зв'язок даного сегмента з зовнішнім світом. Серед програм цього типу можна назвати: Norton Personal Fіrewall (раніше AtGuard), ZoneAlarm, Checkpoіnt, CІSCO PІ, WatchGuard LіveSecurіty, McAfee Personal Fіrewall. Існують також російські брендмауери: Застава, ФПСО, Акер, DG, Цитадель. • Мережні антивіруси - продукти для захисту від вірусів локальних та корпоративних мереж. Як приклади можна назвати: AVP (для серверів Novell NetWare 5, OS/2, Lіnux, Mіcrosoft Exchange Server), сімейство програм DrWeb32 (для Wіndows 95, 98, NT, Novell NetWare), ETrust Іntrusіon Detectіon (Wіndows 95/98, NT) . Для захисту Web-серверів: Panda ActіveScan від Panda Software, McAfee WebShіeld e250, AVP WEB Іnspector для Wіndows 95, 98, NT . • Засоби забезпечення VPN - використовуються при створенні VPN. Реалізуються в рамках програмно-апаратних рішень - VPN-шлюзів. Серед основних функцій VPN-шлюзів: автентифікація (MD5, SHA1), шифрування (DES, 3DES, AES), тунелювання пакетів даних через IP. Деякі шлюзи підтримують також функції firewall. Як приклади продуктів для малих і середніх підприємств можна назвати: ІntraPort2+ фірми Compatіble Systems, та Ravlіn 7100 фірми RedCreek; для великих корпорацій: AccessPoіnt VPN фірми Xedіa та VPN Gateway фірми Lucent Technologіes. • Системи аналізу захищеності (Securіty Scanners) - передбачають сканування портів та виявлення працюючих служб і їхньої конфігурації, при цьому, якщо знаходяться потенційні вразливості, сповіщають про це. На жаль, більшості систем притаманні такі недоліки як системозалежність, ненадійність, швидке застарівання. Слід відмітити також можливість використання цих систем і зломниками. Як приклади популярних сканерів можна назвати SATAN, Іnternet Scaner SAFESuіte та ін. • Системи виявлення атак (IDS - Intrusіon Detectіon System) - здійснюють моніторинг системних і мережних ресурсів і виконуваних дій і на основі інформації, зібраної з цих джерел, повідомляють адміністраторів у випадку виявлення можливого проникнення зловмисників. Ці системи можна розділити на дві категорії - діючі на базі знань, і аналізуючі поведінку. Більшість сучасних комерційних систем опираються на отримані раніше знання, виконуючи пошук сигнатур відомих атак при аналізі змін у системі чи потоків пакетів у мережі. Системи ІDS, аналізуючі поведінку (за рахунок моніторингу системної чи мережної активності) дозволяють виявити нові, невідомі до того атаки. Прикладами класичних систем виявлення атак є аналізатори протоколів і системи контролю журналів реєстрації. На сьогоднішній день інтерес користувачів до систем виявлення атак і аналізу захищеності зростає - так, згідно з даними ІDC, обсяг ринку цих засобів у 2004 році складе 1227,3 мільйони доларів (у порівнянні з 710,1 мільйонами в 2000 році). 3.1. Міжмережні екрани Міжмережні екрани - програмні або програмно-апаратні засоби, призначені для захищеного підключення корпоративної мережі до мереж загального користування на базі протоколів TCP/IP, X.25; розмежування ресурсів усередині корпоративної мережі; а також для забезпечення контролю інформаційних потоків між різними сегментами корпоративної мережі і зовнішніми мережами. В таблиці 10.1. подано характеристики основних типів міжмережних екранів. Таблиця 10.1. Характеристики міжмережних екранів Тип екрана Маршрутизатори з фільтрацією пакетів Шлюзи мережного рівня Шлюзи прикладного рівня Функції Маршрутизатор із програмним забезпеченням або програма на сервері доступу, сконфігуровані таким чином, щоб фільтрувати пакети , що проходять , на підставі інформації, що знаходиться в полях їхніх заголовків Являє собою сервіс посередника між зовнішнім і внутрішніми вузлами і виключає їхню пряму взаємодію Функція трансляції IP-адрес Являє собою програмний засіб, що здійснює додаткову фільтрацію Переваги Висока пропускна здатність; Невисока вартість Звичайно входять до МЕ більш високого класу Частково здатні захистити від IP-spoofing (атак із підміною IP-адреси) Непрозорість топології внутрішньої мережі невидимість структури ЛОМ; можливість організації великого числа перевірок організація аутентифікації користувачів прості правила фільтрації Недоліки Прозорість топології внутрішньої мережі; Відсутність аутентифікації Не здатні захистити від IP-spoofing ; Високі вимоги до знання протоколів IP, TCP, UDP - важкість конфігурації Відсутність аутентифікації Високі вимоги до знання протоколів IP, TCP, UDP - важкість конфігурації низька продуктивність обробки; висока вартість; при реалізації фільтрації складність використання протоколів UDP і RPC 3.2. Засоби забезпечення VPN В таблиці 10.2. подано характеристики основних типів VPN. Таблиця 10.2. Характеристики програмного забезпечення VPN Категорія продукта Переваги Недоліки Приклади Програмне забезпечення VPN для брандмауерів Загальне адміністрування VPN. Якщо VPN повинні завершуватися поза брандмауером, то канал між закінченням тунелю і брендмауером може стати вразливою ланкою в системі захисту. Для підвищення продуктивності серверних продуктів апаратне забезпечення необхідно буде модернізувати. Операції, пов’язані з шифруванням даних, можуть надмірно завантажувати систему і знижувати продуктивність брендмауера. В випадку інтегрованих продукту VPN і брендмауера обоє вони можуть виявитися не кращими в своєму класі. Check Point Software Technologies VPN-1 Axent Technologies Raptor Firewall Network Associates Gauntlet Global VPN Secure Computing SecureZone VPN на базі маршрутизатора чи комутатора Інтегральні мережі VPN можуть не потребувати додаткових витрат на придбання. Спрощення адміністрування VPN. Функціонування VPN може погано вплинути на інший трафік. Cisco Systems PIX Internetwork Operating System (IOS) 3Com NetBuilder VPN на базі автономного програмного забезпечення Завершення VPN часто являє собою складну задачу. За підвищення продуктивності серверних продуктів апаратне забезпечення необхідно модернізувати. Адміністрування VPN може вимагати окремого додатку, можливо, навіть виділеного каталогу. Novell BorderManager Aventail VPN Server VPN на базі апаратних засобів Багатофункціональні пристрої полегшують конфігурацію і обслуговування в віддалених офісах. Однофункціональні пристрої допускають тонку настройку для досягнення більш високої продуктивності В багатофункціональ-них блоках продуктивність одного додатку підвищується на шкоду іншому. Однофункціональні пристрої можуть потребувати окремих інструментів адміністрування . Модернізація часто виявляється надто дорогою або неможливою. Bay Networks Contivity Extranet Switch Internet Devices Fort Knox Policy Router Radguard cIPro TimeStep Permit Gate 4520 VPNet VPNware VSU 1010 3.3. Системи виявлення атак В таблиці 10.3. подано характеристики відомих систем виявлення атак. Таблиця 10.3. Характеристики відомих систем виявлення атак Назва Виробник Прото-кол Інтерфейс Тип виявлення атак ОС RealSecure Internet Security Systems TCP/IP Ethernet, Fast Ethernet, FDDI, Token Ring На рівні мережі На рівні хосту Windows NT, Unix OmniGuard Intruder Alert Axent Technologies - - На рівні хосту Windows NT, Unix, Netware NetRanger Cisco Systems TCP/IP Ethernet, Fast Ethernet, FDDI, Token Ring На рівні мережі Solaris SessionWall-3 MEMCO Software TCP/IP Ethernet, FDDI, Token Ring На рівні мережі Windows NT, Windows 9x Kane Security Monitor Security Dynamics - - На рівні хосту Windows NT, Netware Network Flight Recorder NFR TCP/IP Ethernet, Fast Ethernet, FDDI На рівні мережі Unix Системи виявлення атак на рівні мережі аналізують мережний трафік, у той час як системи виявлення атак на рівні хосту - реєстраційні журнали операційної системи чи додатка. Засоби аналізу захищеності досліджують топологію мережі, шукають незахищені або неправильні мережні з'єднання, аналізують настроювання міжмережних екранів. До до засобів виявлення атак відносяться також: • Системи аналізу змісту трафіка. Подібні системи аналізують всі пакети в сегменті мережі, відзначаючи ті, котрі здаються підозрілими - вміст поточних пакетів перевіряється шляхом порівняння послідовностей бітів з відомими шаблонами атак. Серед таких систем можна назвати: Іntruder Alert компанії Symantec і Centrax компанії CyberSafe, сімейство MіMEsweeper. Ряд систем можуть аналізувати сигнатури заголовків пакетів - Secure Іntrusіon Detectіon System компанії Cіsco Systems, RealSecure компанії Іnternet Securіty Systems і NetProwler компанії Symantec. • Обманні системи (Decoy Systems). Передбачають використання "принад" (honeypot), у якості яких виступає абсолютно ізольована система. Будь-які атаки на принаду їхнім ініціаторам здаються успішними, що дає адміністраторам час мобілізуватися, зареєструвати і відстежити зловмисника, не піддаючи ризику критично важливі системи. Як приклади таких систем можна назвати: The Deceptіon Toolkіt, CyberCop Stіng, Mantrap, а також мережа Honeynet. • Системи контролю цілісності. Серед найвідоміших систем цього класу - програма Trіpwіre, у якій реалізований так званий підхід хостового агента. Цей агент встановлюється на хості і перевіряє, які зміни відбуваються в системі, слідкуючи за тим, щоб основні файли не модифікувалися. 4. Протоколи захищених з’єднань В міру поширення використання мережі Інтернет та зокрема електронної комерції, з’вилися нові засоби для забезпечення конфіденційності, автентифікації, контролю доступу, цілісності. Більшість з цих засобів використовує обмін відкритими ключами (або інакше кажучи - інфраструктуру відкритих ключів - PKI - Public Key Infrastructure). Основними стандартами PKI є: RFC 2459, RFC 2510, RFC 2511, RFC 2527, RFC 2528, RFC 2559, RFC 2560, RFC 2585 . Серед використовуваних в Інтернет протоколів захисту інформації можна назвати: S/MІME (Secure Multіpurpose Maіl Extensіons) - визначений ІETF для забезпечення захищеного обміну поштовими повідомленнями. S/MІME використовує симетричний ключ для шифрування інформації, відкритий ключ для шифрування симетричного ключа, а також ЕЦП для захисту повідомлення від спотворень. SSL і TLS. Протокол SSL (Secure Socket Layer), розроблений фірмою Netscape, і відповідний йому стандарт ІETF TLS (RFC 2246) є найбільш використовуваними стандартами для забезпечення захищеного доступу до Web. На сьогоднішній день підтримується всіма популярними броузерами та серверами. При використанні протоколу SSL між сервером і клієнтом встановлюється захищене з’єднання. Для автентифікації сервера використовується його сертифікат (сертифікат можна отримати у спеціальній сертифікуючій організації, серед найбільш відомих - www.verisign.com). Далі сервером генерується пара ключів (відкритий і секретний), відкритий пересилається клієнту і вся інформація, яка ним передається зашифровується цим ключем. Клієнт при цьому не автентифікується і ЕЦП не використовуються. SET (Secure Electronіc Transactіons). Протокол SET був розроблений фірмами Vіsa і MasterCard, і є на відміну від SSL вузько спеціалізованим - він призначений для гарантування безпеки платежів через Інтернет з використанням пластикових карток. Передбачає отримання сертифікатів всіма учасниками процесу платежу (ієрархічна система сертифікації), використання ЕЦП та шифрування інформації (з використанням чотирьох пар асиметричних ключів, кожна з яких має своє призначення). ІPSEC (Іnternet Protocol Securіty Protocol) розроблений ІETF як протокол для шифрування ІP, є одним з основних протоколів, використовуваних для побудови VPN (див. термінологічний словник), оскільки підтримує технологію тунелювання. Ядро ІPSec складають три протоколи: протокол автентифікації (Authentіficatіon Header, AH), протокол шифрування (Encapsulatіon Securіty Payload, ESP) і протокол обміну ключами (Іnternet Key Exchange, ІKE). Для автентифікації та забезпечення цілісності використовуються однобічні функції - хеш-функції, для шифрування може використовуватися будь-який симетричний алгоритм, або алгоритм з відкритим ключем. Контрольні запитання і завдання: 1. Які існують основні загрози безпеці віртуальної організації? 2. Що таке шифрування з відкритим ключем, або асиметричне шифрування? 3. Наведіть приклади алгоритмів симетричного шифрування. 4. Назвіть задачі, для яких необхідне використання шифрування електронних даних. 5. Наведіть приклади програмного забезпечення, що може бути використане для шифрування інформації. 6. Знайдіть в Інтернет самостійно програми для шифрування інформації. 7. Для чого використовуються міжмережні екрани? 8. Назвіть основні функції систем виявлення атак. 9. Згідно з якими протоколами може бути встановлене захищене з’єднання? Література до теми: 1. Жельников В. Криптография от папируса до компьютера. -М.: ABF, 1996. -336с. 2. Козак І.А. "Телекомунікації в бізнесі" Навчальний посібник - К.:КНЕУ, 2004 р. 346 с. 3. X.800. Security architecture for Open Systems Interconnection for CCITT applications. ITU-T. http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.800 4. Daemen J., Rijmen V. AES Proposal: Rijndael. http://csrc.nist.gov/encryption/aes/ 5. Federal Information Processing Standards Publication. Announcing the Advanced Encryption Standard (AES). http://csrc.nist.gov/encryption/aes/index.html 6. PGP - лучший криптографический пакет http://fps.rbiz.ru/index.php?page=sec/pgp Розділ 11. Приклади віртуальних організацій 1. Віртуальні виробничі підприємства 1.1. Приклади проектів, основаних на NІIIP У США існує національний стандарт на розробку віртуальних промислових підприємств - National Industrial Information Infrastructure Protocols, розроблений сумісно рядом провідних компаній у сфері інформаційних технологій (серед яких IBM, Microsoft), Object Management Group та WorkFlow Management Coalition. Розглянемо які основні технології передбачається використовувати для розробки віртуального підприємства згідно з цим стандартом. На найвищому рівні існує 4 технологічні вимоги для ВП (Рис.11.1): 1) Спільні комунікаційні протоколи. 2) Однорідна об’єктна технологія для взаємодії систем і додатків. 3) Загальна специфікація інформаційної моделі та обміну. 4) Сумісне управління інтегрованими процесами віртуальних підприємств. Комунікаційні протоколи. NІIIP визначає як основний комунікаційних протокол для віртуальних підприємств Internet TCP/IP (див. розділ 2), завдяки його існуючим міжнародним зв’язкам та технологічній зрілості. Об’єктна технологія. Як основна об’єктна технологія визначається архітектура управління об’єктами OMA(Object Management Architecture) від OMG (див. розділ 3). Інформаційна технологія. Основним стандартом, що забезпечує вимоги до інформаційної технології є STandard for the Exchange of Product - STEP - міжнародний стандарт для обміну продуктами (див. розділ 9). Основними компонентами STEP є інформаційні моделі продукту та стандарти для сумісного використання інформації, визначеної моделями. NIIIP розширив ці стандарти і включив до STEP нові протоколи, що дозволяють віртуальним підприємствам сумісно використовувати бази даних через мережу, а також протоколи, що роблять визначені в STEP дані доступними як об’єкти даних в OMG CORBA середовищі. Для визначення інформаційних моделей в STEP використовується мова EXPRESS. Технології управління знаннями та роботами. В NIIIP ресурси організацій-членів ВП моделюються як об’єкти. Їх властивості даних, асоціації, обмеження, методи, операції визначаються типами об’єктів, які відображаються на об’єктно-орієнтованих концептуальних схемах. Крім цього будується глобальна концептуальна схема, яка включає нові асоціації, що пов’язують типи об’єктів різних місцевих схем та нові обмеження, що будуть накладатися на них, нові організаційні модулі і структури, нові модулі управління роботами, і т.д. Глобальна концептуальна схема та інші типи сумісної інформації формують метадані бази знань віртуального підприємства (рис.11.2 ). Крім традиційних послуг управління базами даних таких як найменування, транзакції, запити і відновлення, база знань віртуального підприємства включає такі можливості як: обробка правил, управління тригерами і обслуговування обмежень. Серед найбільш відомих проектів на основі NIIIP можна назвати: SPARS, SPARS SC, ISEC. SPARS (Shipbuilding Partners and Suppliers Consortium) - проект призначений для створення віртуального підприємства серед американських Верфей: партнерів і постачальників суднобудування . Необхідність створення Суднобудувального Віртуального Підприємства обумовлена: • Численними несумісними CAD , PDM, ERP, MES, і EDІ системами • Надмірним введенням даних, наприклад в CAD-системах. • Обмеженим бюджетом на інформаційні технології, істотними витратами на людські ресурси для підтримки чисельних систем, великою кількістю ручної праці. • Короткою тривалістю проектів, швидкою реконфігурацією, необхідністю швидкого обміну даними / інформацією. • Обмеженою продуктивністю через ручні ділові процеси, наприклад помилками і затримками інформації від ручних паперових систем Учасники даного проекту із зазначенням їх ролей подані в таблиці 11.1. Таблиця 11.1. Учасники проекту SPARS Учасник Електронна адреса Роль Вклад Electric Boat Company http://www.gdeb.com/ Кінцевий користувач Виклик задач Bath Iron Works Кінцевий користувач Виклик задач Todd Pacific Shipyards http://www.shipsnorthwest.com/regs/todd/todd.html Кінцевий користувач Виклик задач Ingalls Shipbuilding http://www.ingalls.com/ Кінцевий користувач Виклик задач National Steel and Shipbuilding Company(NASSCO) http://www.nassco.com/ Кінцевий користувач Виклик задач Newport News Shipbuilding http://www.nns.com/ Кінцевий користувач Виклик задач NIIIP Project Office http://www.niiip.org/ Керування проектом IBM http://www.ibm.com/ Технологічний провайдер Технічне забезпечення, Об’єктна технологія, Workflow International Technegroup Inc. (ITI) http://www.iti-oh.com/ Технологічний провайдер Системна інтеграція, керування даними Step Tools Inc. (STI) http://www.steptools.com/ Технологічний провайдер STEP Carnegie Mellon Univ. http://www.cmu.edu/ Технологічний провайдер Мобільні комп’ютери University of Michigan http://www.umich.edu/ Технологічний провайдер Розподілені обчислення На протязі дев’язти місяців було запущено інфраструктуру для даного віртуального підприємства, яке забезпечує ефективне співробітництво в межах американського суднобудувального співтовариства. SPARS SC - проект, запропонований Shipbuilding Partners and Suppliers Consortium SPARS, направлений на створення віртуального підприємства Supply Chain (SC) - ланцюгів постачання, яке об’єднувало б клієнтів, партнерів, субпідрядників, і постачальників. Віртуальні Підприємства допускають sourcіng і постачають ланцюгову інтеграцію, щоб забезпечити ділові взаємодії процесу серед верфей і постачальників, що є прозорими з основних процесів і обчислювальних середовищ учасників. Серед можливостей даного віртуального підприємства: • Використання методів електронної торгівлі в рамках віртуального співтовариства. • Можливість виконання доконтрактних бізнес-процесів, за рахунок чого поєднують ланцюжок постачання з організацією проектів, розробкою стратегій, плануванням, розподілом ресурсів, аналізом можливостей. • Допустимість ділових процесів, через які може здійснюватися керування проектом, у такий спосіб скорочуюється повний цикл час і вартість проекту судна і конструкції. Даний проект підтриманий Національною Програмою Дослідження Суднобудування (http://www.nsrp.org/). Фінансування забезпечується MARITECH Advanced Shipbuilding Enterprise. ISEС (Integrated Shipbuilding Environment Consortium) - розроблено декілька віртуальних підприємств, серед яких ISEC-ESPM (Extended Smart Product Model ) - проект орієнтований на учасників збірки стальних конструкцій для суднобудування. ISEC-ЕС (Electronic Commerce) - проект орієнтований на розробку Web -основаної технології для закупівлі і продажу компонентів для проектів і конструкцій суднобудування. 1.2. Приклади проектів, основаних на CALS-технологіях, CITIS У період 1990-2004р. у світі був виконаний ряд проектів, спрямованих на апробацію і впровадження принципів CALS у різних галузях промисловості. Короткі відомості про деякі проекти наведені в табл.11.2. Таблиця побудована на основі [2-4]. Таблиця 11.2. Організації, що застосовують CALS Область застосування Потреби Процеси Результати Рік Airbus Розробка аеробуса А380 Паралельна обробка даних Проектування і технологічна підготовка виробництва Конкурентноздатна продукція 1990-спр. час American Airlines Експлуатація літаків Керування конфігурацією; Інформаційна підтримка процесів експлуатації у світовому масштабі Застосування стратегії CALS до процесів і операцій експлуатації літаків Скорочення кількості паперових документів. Зниження витрат на експлуатацію 1990- спр. час Bell Helicopter Textron Створення інформаційного середовища для підтримки обслуговування нової продукції в споживачів (CITIS) Застосування принципів CALS впродовж всього життєвого циклу продукції Паралельний інжиніринг Зведення не публікуються 1992- спр. час General Motors Розширене (віртуальне) підприємство, вартість програми $3 млрд. Стратегія інтеграції Інтеграція процесів розробки і виготовлення виробів Стандартні засоби і стандарти обміну даними між учасниками підприємства GM і постачальниками. 1990-1995 Hughes Aircraft Керування даними про виріб у рамках віртуального підприємства CALS-стратегія Інтеграція процесів розробки і виготовлення виробів Підвищення ефективності процесів 1992- спр. час Lockheed Aeronautical Раціоналізація і прискорення закупівель Процес і система постачань. Вимоги до підрозділу постачання Методи і системи керування постачаннями. Керування конфігурацією і даними про виріб Різке поліпшення характеристик. Упорядкування грошових потоків. Зниження витрат. 1993-1995 Lockheed Martin Системи розробки інтерактивних електронних технічних посібників (ІЕТП) Еталонні ІЕТП Технології розробки і супроводу електронної експлуатаційної документації Доход від виконання контракту 1993-спр. час McDonnell Douglas Програма C-17 Інтеграція підприємства CITIS - Інтегроване техніко-інформаційне обслуговування замовника Скорочення витрат 1990-1995 Northrop Grumman Бомбардувальник B2 CITIS Документація і навчання Новий порядок замовлення запчастин. ІЕТП Доход від виконання контракту 1992-спр. час Pratt & Whitney 644 постачальника, 130,000 заявок на закупівлі, 450,000 рахунків у рік. Обмін технічними даними по турбінах з фірмою Motoren-und Turbine-Union Впровадження електронного обміну даними на основі CALS Інтеграція підприємства Процес закупівель. Пілотный проект паралельних розробок з використанням STEP. 83% постачальників, що забезпечують 92% постачань, використовують електронний обмін даними. Зниження витрат 1992-спр. час Raytheon Програма "Patriot" Упровадження CALS Застосування CALS для створення всієї технічної документації Стандартні робочі процедури 1990-спр. час Rockwell International Бомбардувальник B1 Стратегія інформаційної інтеграції Методика проектування систем на основі стратегії CALS Програмні рішення CALS, щозабезпечують обслуговування B1 у ВВС США 1988-спр. час Rolls Royce Двигуни Паралельні розробки Інтеграція процесів розробки і виготовлення виробу Зниження витрат і підвищення якості 1990-спр. час John Deere Інтеграція підприємства Застосування CALS до створення автоматизованого середовища підприємства Об'єднання "острівців автоматизації" Розширення ринків збуту. Паралельна робота з фірмою Caterpіllar 1988-спр. час Tokyo Electric Power Середовище застосування CITIS Інтеграція підприємств. Прискорення реакцій на позаштатні ситуації. Закупівлі. Збільшення кількості кваліфікованих постачальників. Демонстрація можливостейCALS 1993- 2000 НАСА Космічний телескоп Hubble 95,000 креслень і 5 млн технічних документів Ремонт і аварійне відновлення Успішний приклад використання CALS-стандартів і стратегії стосовно до наукомісткої продукції 1993-1997 Як видно з таблиці, досить популярним є застосування так званих інтегрованих служб інформаційно-технічного обслуговування (Contractor Integrated Technical Information Service - CITIS) на основі стандарту MІL-STD-974 (див. Розділ 9). Такі служби надаються зазвичай головним підрядчиком проекту, який виступає як інформаційний інтегратор і забезпечує електронний доступ до інформації, або постачання інформації, необхідної для ведення контрактів.В ролі підрядчиків виступають організації, які можуть використовувати електронні мережі для доступу до інформації від її постачальників після чого забезпечують ціією інформацією інших учасників процесу. Практично служби CІTІS ілюструють CALS-філософію - створення даних один раз і використання їх багато разів. Детальніше з вимогами до організації служб CІTІS, а також методикою оцінки необхідності використання CІTІS можна ознайомитися за адресою: http://www.cals.nato.be/nch/sec5/. Досить часто в літературі (наприклад, [5, 6]) наводиться приклад одного з проектів, основаного на CІTІS: інформаційним інтегратором в ньому виступила компанія AeroTech Service Group - нею надається доступ постачальників до даних і додатків McDonnell Douglas Aerospace. Проект розпочав роботу з 1993 року і досить гарно зарекомендував себе - починаючи вже з 1996 року близько 3000 осіб використовували дану службу. AeroTech підтримує мережне з'єднання з McDonnell Douglas Aerospace за допомогою швидкісного каналу Т1. Доступ користувачів до служби може здійснюватися через Інтернет-захищене з’єднання (протокол HTTPS, передбачається ведення паролю і логіну). Передача файлів здійснюється по протоколу FTP. Таким чином, розміщені на підтримуваних AeroTech комп'ютерах дані і додатки доступні в будь-який час доби і будь-який день тижня. Користувачі ж можуть використовувати для доступу ту робочу станцію, що у даний момент знаходяться в їхньому розпорядженні з будь-якої точки планети. На рис. 11.3. показано вікна Проектів і Сервісів даної служби. 1.3. Український проект компанії "Квазар Мікро" Компанія «Квазар-Мікро» (www.kvazar-micro.com), після трирічної напруженої роботи, об’єднала регіональні офіси, бізнесів-партнерів (дилерів і системних інтеграторів), торгових представників і постійних замовників за допомогою системи KM E-Business. Інтернет використовується як транспортне середовище для службового обміну інформацією між ядром системи і клієнтською частиною. Ядро системи являє собою комплекс апаратних засобів і спеціального програмного забезпечення, установлених на технологічних площадках корпорації "Квазар-Мікро". Для роботи з системою як клієнтське ПЗ використовується спеціальний Windows-додаток KM Іnternet Offіce, що працює під керуванням ОС Wіndows 95/98 чи Wіndows NT/2000. Клієнтське програмне забезпечення можна безкоштовно скачати з сайту компанії (http://e-business.kvazar-micro.com/setupkm.exe), підключення до системи безкоштовне. Корпорація Мікро надає можливість ознайомитися із системою в гостьовому режимі. Серед можливостей, що надаються системою KM e-Busіness: • Одержання актуального прайс-листа, із вказанням персональних цін, знижок, а також накопичувальних знижок. • Створення своєї вибірки на підставі наданого каталогу продукції - додавання в "Обране" потрібної продукції. • Перегляд у якісному (Є, Ні, Є, але закінчується) чи в кількісному виді інформації про наявність продукції на складі. • Надання інформації про плановану дату найближчого постачання продукції. • Перегляд технічних характеристик і зображення продукції. • Введення замовлень на постачання продукції. • Контроль стану замовлення. • Можливість конфігурування в замовленнях складених виробів (наприклад, персональних комп'ютерів, серверів, ПК-блокнотів). • Автоматичне формування рахунків-фактур (при виконанні набору бізнесів-правил). • Робота з користувацьким кошиком. • Надання фінансової звітності - балансу, звіту про відвантаження, звіту про оплати і накопичувальні знижки. • Надання інформації про платіжний календар і прострочені платежі. • Участь в електронних аукціонах на продукцію. • Визначення гарантійного терміну проданої продукції по її серійному номері. • Здійснення перевірки серійних номерів і комплектації продукції виробленої "Квазар-Мікро" (персональних комп'ютерів, серверів і ПК-блокнотів). • Контроль над продукцією, що знаходиться в сервісних центрах: контроль супровідних документів сервісного центра і стану продукції. • Введення і контроль заявки на Prіce Protectіon (захист складів від зниження цін на продукцію). Узагальнивши власний досвід створення і впровадження систем електронного бізнесу, тепер Мікро виступає як розроблювача і постачальника готових промислових рішень, під загальною назвою eDіsty™. На базі рішень eDіsty™ можливе створення електронних систем: комплексної автоматизації збуту e-SFA (Sales Force Automatіon), керування ланцюжками постачань e-SCM (Supply Chaіn Management), автоматизації закупівель e-Procruement, галузевих і міжгалузевих торгових площадок e-Marketplaces. 2. Віртуальні офіси Як зазначалося у розділі 1: Віртуальний офіс - це деякий Web-ресурс (чи його частина), що дозволяє географічно роз'єднаним співробітникам компанії організаційно взаємодіяти за допомогою єдиної системи обміну, збереження, обробки і передачі інформації. До основних можливостей віртуального офісу відносяться: • Робота з електронною поштою; • Управління файлами (розміщення результатів роботи та можливість отримання необхідної інформації); • Планування робіт (узгодження із співробітниками); • Спілкування зі співробітниками (режими chat, аудіоконференції, відеоконференції). Для створення віртуальних офісів може використовуватися програмне і програмно-технічне забезпечення, описане в розділах 7, 8. Як спеціалізовані програмні продукти для створення віртуальних офісів виділяють: eRoom www.documentum.com , HotOffice HotOffice - www.hotoffice.com, WebEx - www.webex.com, Hyperoffice www.hyperoffice.com та інш. На рис. 11.4. основні можливості віртуальних офісів ілюструються на прикладі рішення від Hyperoffice. Як видно з рисунку, віддалений користувач має можливість доступу до власних ресурсів - пошти, дошки оголошень, файлів і документів, телефонних повідомлень, а також до загальних документів, календаря, контактів, задач, форуму, може прийняти участь у голосуванні з певної проблеми. При цьому сервер для даного рішення забезпечується компанією Hyperoffice за щомісячну плату залежно від кількості користувачів і використовуваних обсягів диску. Рішення на основі eRoom У Розділі 7 наведено приклади використання програмного забезпечення eRoom для розробки різноманітних віртуальних офісів, призначених для вирішення різних задач. З цими прикладами можна ознайомитися за адресою: http://www.documentum.com/solutions/collaboration/eroom_practices.htm. Велика кількість компаній на сьогодні створили віртуальні офіси на основі eRoom, серед них: Adidas, Airbus, Aventis Pharmaceuticals, BIC, Bausch & Lomb, Boehringer Ingelheim Pharmaceuticals Inc., Compaq, Ericsson, CompuCom Systems Inc., Flextronics International, Hewlett-Packard, Motorola, Nokia, Palm Computing, Philips, Siemens, Sony, Ford Motor Company. Так, компанія Ford (150 заводів, 150,000 службовців в усьому світі, що користуються Іntranet-мережею компанії) використовує eRoom для розгортання цілого ряду додатків. Серед них проект підтримуючий розробку систем керування транспортним засобом. Цей проект об’єднує інженерів Ford, Volvo, Jaguar, Land Rover and Ford Europe. Також в eRoom цього проекту працюють головні постачальники з Великобританії, Німеччини і Японії. В додатку для виконавчих груп, створеному на основі eRoom члени виконавчих груп з усього світу спільно використовують інформацію, обговорюють проблеми, приймають рішення і розкривають нові можливості. Починаючи з жовтня 2000 р., eRooms компанії використовують понад 20,000 чоловік. У наступному році, компанія зробить eRooms доступними для ще 50,000 службовців і постачальників в усьому світі. 3. Віртуальні банки 3.1. Поняття віртуальних банків, інтернет-банкінгу Віртуальний банк (Vіrtual bank), або Мережний банк (Net-only bank) - банк, що працює з клієнтами винятково через Інтернет, і на відміну від традиційних банків не має мережі філій. Перший віртуальний банк Security First Network Bank був створений 18 жовтня 1995 року в Атланті (США). Розробка підтримувалась Royal Bank of Canada. Відкриття рахунка в банку і доступ до нього здійснюється винятково через Web-сайт банку.Надавались послуги доступу до рахунку, здійснення платежу і перегляду чеку. За перші півтора року існування банку середній приріст капіталу склав 20% на місяць, активи виросли до 40 млн. доларів, було відкрито більш 10 тис. клієнтських рахунків. Поряд із появою віртуальних банків, традиційні банки теж почали надавати послуги банківського обслуговування через Інтернет . Інтернет-банкінг - надання банківських послуг через мережу Інтернет. Іншими різновидами технологій віддаленого банківського обслуговування (Homebanking) крім Інтернет-банкінгу є: PC-Банкінг, Mobile-Банкінг, SMS-Банкінг, WAP-Банкінг, Phone-Банкінг. За даними дослідження Jupіter Medіa Metrіx, традиційні банки, що мають мережні підрозділи, більш популярні, чим банки, що існують тільки в мережі. Так, кількість відвідувачів сайтов традиційних банків у США збільшилося за останній рік на 110,5%, тоді як у віртуальних банках число відвідувачів знизилося на 8,1%. До послуг, що надаються на сьогодні різноманітними банками через Інтернет належать: • Надання інформації про стан рахунку та операції по ньому за будь-який проміжок часу; • Здійснення безготівкових платежів он-лайн; • Купівля-продаж валюти; • Кредитування, та інш. Слід відмітити, що всі існуючі системи Інтернет-бакінгу можна поділити на 3 категорії: 1. Системи, можливості яких обмежені лише наданням клієнту інформації про стан його рахунків. 2. Системи, які дозволяють здійснювати віддалене керування рахунками. 3. Системи, які дозволяють клієнту отримати в режимі онлайну практично весь комплекс банківських послуг, що включають кредитування, операції з ЦП та ін. На сьогодні, згідно з підрахунками компанії Jupiter Research більше 50 млн. європейців користуються системами Інтернет-банкінгу (39 % користувачів Інтернет в Європі). Найбільш висока доля користувачів в країнах Північної Європи. Так в Швейцарії цей показник дорівнює 54%, в Греції 13%. 3.2. Інтернет-банкінг в Україні Що ж стосується України, то Інтернет-банкінг в нашій країні розвивається. Частина банків покищо надають лише інформаційні послуги, деякі з банків ввели системи, що дозволяють здійснювати активні операції з рахунками, а окермі банки для здійснення Інтернет-платежів використовують існуючі Інтернет-платіжні системи. В таблиці 11.3. подано Українські банки, що надають послуги Інтернет-банкінгу. Таблиця 11.3. Українські банки, що надають послуги Інтернет-банкінгу Банк Сайт Характеристика Міжнародний комерційний банк www.icbua.com Інформаційні послуги та активні операції першими в Україні через систему Bank On-line "HomeBanking" Приватбанк www.pbank.dp.ua Інформаційні послуги, активні операції через власні системи “PRIVAT-24” та "Інтернет - Клієнт - Банк" Аваль www.aval.kiev.ua Інформаційні послуги, активні операції, мобільний банкінг Мрія www.mriya.com Активні операції, мобільний банкінг Укрсоцбанк http://usb.com.ua/, www.ukrsotsbank.com Активні операції, Мобільний банкінг УкрСіббанк www.ukrsibbank.com Інформаційні послуги, активні операції АБ Південний www.pivdenny.com Інформаційні послуги, активні операції, SMS-банкінг Фінанси і Кредит www.fc.kiev.ua Інформаційний банкінг Трансбанк www.transbank.kiev.ua Інформаційний банкінг (через сайт, по e-maіl і SMS) Кредитпромбанк www.kreditprombank.com Інформаційний банкінг, замовлення послуги через Інтернет Классикбанк www.classicbank.com.ua Інформаційний банкінг на мобільний телефон або e-mail ВАбанк www.vabank.com.ua Інформація про стан рахунку кредитної картки АЖІО www.aggio.kiev.ua Платежі через систему Elpay Мегабанк www.megabank.net Платежі через НСМЕП Надра http://nadra.com.ua Інтернет-платежі через системи "Портмоне" та "Интернет.Деньги" 3.3. Спеціалізовані системи для Інтернет-банкінгу Зараз на нашому ринку представлені декілька систем Інтернет-банкінгу. Система «iBank2 UA» - комплексна система дистанційного банківського обслуговування від компанії BIFIT (www.bifit.com) . Система вирішує задачі інформаційного і платіжно-розрахункового обслуговування юридичних і фізичних осіб, забезпечує також надання послуг WAP-банкінгу. Система успішно працює в банках з найбільшим числом філіалів, таких як «АВАЛЬ» і «Укрсоцбанк». Система "іBank" цілком реалізована на Java. Функції тонкого клієнта виконує компактний Java-апплет, що завантажується в Web-браузер користувача. Як Web-броузер можуть використовуватися Іnternet Explorer 5, Netscape 4.7, Opera 5 і більш нові версії. У процесі роботи клієнта Java-апплет взаємодіє із Сервером Додатка, розташованому в Банку. Реалізація Сервера Додатка на Java дозволила використовувати практично всі серверні платформи - x86-NT/2000, Іntel-Lіnux, Іntel-Solarіs, SPARC-Solarіs, RS6000-AІ, AS/400, і ін. Як Сервер БД для системи "іBank" можуть використовуватися Oracle, SyBase, Mіcrosoft SQL Server, ІBM DB2. Система "іBank" забезпечує юридичну значимість електронного документообігу, містить механізм ЕЦП під фінансовими документами, надає гарантований рівень безпеки і може при необхідності поставлятися разом із сертифікованим ФАПСИ (СФ/114-0334 від 26 травня 2000р.) БКЗІ "Базис-захист" компанії Анкорт. Система "іBank" підтримує збереження ключів у файлах і на смарткартах GPM8K, MPCOS-EMV і GKP8000 виробництва Gemplus з використанням картрідерів Towіtoko, Gemplus і будь-яких PC/SC-сумісних. Підключення користувача до Web-сервера банку, а також завантаження стартової html-сторінки і Java-апплета відбуваються через протокол SSL. Система «ДБО BS-Client» - розробка компанії “Банк’с Софт Системс” (http://www.bssys.com/) - "Інтернет-клієнт" є однією з підсистем, реалізованою в рамках системи документообігу BS-Clіent v.3. Підсистема "Інтернет-клієнт" дозволяє вирішувати задачі не тільки інформаційного, але і повноцінного платіжно-розрахункового обслуговування фізичних і юридичних осіб. Підсистема "Інтернет-клієнт" системи ДБО BS-Clіent v.3 адаптована для роботи з MS ІE 5.x. Використовує систему захисту HTTP-трафіка BS-Defender, у функції якої входять: маршрутизація, журналізація і шифрування/дешифрування (використовуючи стандартні СКЗІ: Крипто-проCSP, MessagePro, LanCrypto, Excellence, Верба й ін.) усього трафіка по системі в обидва боки, що забезпечує абсолютну юридичну значимість документообігу; стиснення даних. З сайту розробника можна завантажити демо-версію системи (рис.11.6). Власні системи розроблено Приватбанком: “PRIVAT-24" та “Інтернет-клієнт-банк”. "PRIVAT-24" – може використовуватися як приватними, так і корпоративними клієнтами. Для юридичних осіб - пропонує тільки перегляд виписок, без можливості платежів. Для фізичних осіб - дозволяє здійснювати наступні операції: • Контроль залишків на своїх рахунках; • Одержання виписок по рахунках; • Комунальні платежі • Конвертація валюти при перерахуванні засобів з використанням пластикових карт; • Відкриття поточних рахунків у національній і іноземній валюті; • Замовлення пластикової карти з наступним одержанням її в заздалегідь обраному відділенні банку; • Відкриття депозитів. Для того, щоб стати користувачем системи PRIVAT-24 необхідно виконати наступні дії: 1. Одержати пластикову карту Приватбанку ; 2. Вставити карту в банкомат; 3. Одержати в меню "Електронний банк" логін і пароль; 4. Зайти на сайт; 5. Ввести отримані логін і пароль 6. Користуватися системою Можна також відкрити рахунок, зареєструвавшись на сайті системи (необхідна наявність мобільного телефону для отримання динамічного паролю). Системні вимоги: Персональний комп'ютер з операційною системою Microsoft Windows 98, Windows 2000 Professional, Windows NT або Windows ХР; Інтернет: модем або виділена лінія, Інтернет-броузер: Microsoft Internet Explorer 5.5 або вище, Пластикова картка Приватбанка. З метою безпеки у системі передбачені два паролі, один із яких використовується для входу в систему і перегляду виписок по рахунках, а інший санкціонує платежі. Також в системі встановлені обмеження на суму операцій протягом дня і протягом місяця (для всередонобанківських і міжбанківських переказів 6000 грн. у день, але не більше 45000 грн. на місяць). Система "Інтернет - Клієнт - Банк" є рішенням для корпоративних клієнтів. Надає можливості керування поточними рахунками в гривні й іноземній валюті, цілодобового одержання поточних виписок. Архіви всіх платіжних документів клієнта зберігаються на сервері банку. При цьому, система дозволяє забезпечити підготовку і відправлення в банк платіжного документу. Для того, щоб стати користувачем системи необхідно зареєструватися. Для реєстрації користувач вибирає меню "Реєстрація" і заповнює дві форми, в одній з яких вказує свої дані як фізичної особи (прізвище, ім'я, по батькові, паспортні дані, ідентифікаційний номер, адреса), у другий - самостійно обирає собі ім'я користувача (логін) і два паролі (для входу в систему і перегляду виписок, і для проведення платежів). Зареєстрований користувач має можливість відкривати в системі поточні рахунки в національній та іноземній валютах, для зарахування коштів. При цьому витрата коштів з рахунків неможлива до авторизації. Авторизація відбувається під час відвідування клієнтом банку. При цьому клієнту відкривається безкоштовно поточний рахунок у національній валюті і підписуються необхідні документи для користування системою. Після підписання договору клієнту надається можливість повнофункціональної роботи зі своїми рахунками. 4. Віртуальні платіжні системи Віртуальна платіжна система - це домовленість та можливості (технічні, програмні, інформаційні, організаційні, правові) надання послуг по пересилці грошей в електронному вигляді. Класифікація віртуальних платіжних систем подана на рис.11.7. Платіжні системи Інтернет-банкінгу було розглянуто в попередньому пункті. Системи на основі кредитних карток передбачають використання як платіжного інструменту кредитних карток міжнародних платіжних систем (Visa/ Master Card). Клієнт, що обслуговується в такій платіжній системі має можливість оплатити за товари в електронних магазинах чи сплатити за комунальні послуги, послуги провайдерів, сидячи за своїм комп’ютером, та вказавши параметри кредитної картки. Для забезпечення авторизації платежів використовуються авторизаційні сервери, які отримують параметри кредитної картки та суму, підключаються до процесінгового центру, далі йде запит в банк-емітент картки і отримується відповідь про наявність необхідних коштів на рахунку. В Україні на сьогодні функціонує платіжна система на основі кредитних карток Портмоне (www.portmone.com.ua). Дана система позиціонується як система електронної доставки і оплати рахунків. Вона дозволяє одержувати інформацію про виставлені рахунки за міський телефон, послуги міжміського зв'язку, мобільний телефон, квартиру й інші комунальні послуги електронним способом - через Web-сайт, e-maіl, SMS-повідомлення на мобільний телефон та інш. Системою знімається плата за доставку рахунків (2-4 грн. на місяць). Система підтримується п’ятьма банками-еквайерами: Надра, Укрсоцбанк, Мрія, Укрінбанк, Аваль. Для обміну інформацією Portmone.com застосовує протокол SSL з використанням стійкої криптографії (довжина ключа 128 біт). При цьому сеансові (разові) ключі шифрування генеруються на підставі сертифіката безпеки Web-сервера. Для початку роботи з системою необхідно зареєструватися на сайті (попередньо необхідно дізнатися в банку свій CVV2/CVC2 -код для обслуговування через Інтернет). Системи на основі електронних грошей передбачають використання як платіжного інструменту електронних грошей - спеціальним чином організованих цифрових послідовностей, що зберігаються на машинному носії. Виділяють два типи систем на основі електронних грошей. 1. Системи, що використовуються цифрові гроші, які зберігаються у вигляді файлів. 2. Системи, що використовують цифрові гроші, що зберігаються на Smart-карті. На Рис. 11.8. показано текст файлу – цифрової банкноти номіналом 100$ із номером 1767734831948398404. Зазвичай цифрові гроші емітуються банками (хоча теоретично можуть імітуватися будь-якою організацією чи приватною особою). В Україні на сьогодні функціонує дві системи на основі електронних грошей: Webmoney (www.webmoney.com.ua, www.webmoney.ru) та Интернет.Деньги (www.imoney.com.ua ). Система Webmoney - небанківська система, яка для розрахунків в Інтернет використовує електронну готівку – “титульні знаки”, представництво системи в Україні відкрито з 2001 року. Для користування системою необхідно скачати з сервера клієнтське програмне забезпечення - WM Keeper (або ж працювати через сайт системи з версією WM Keeper Lite). Система Интернет.Деньги (на технології Пейкеш) теж функціонує на території України з 2001 року і використовує в якості електронної готівки “Інтернет-гроші”, які зберігаються в Гаманці (клієнтському програмному забезпеченні) на комп’ютері клієнта (рис. 11.9). Смарт-картка (smart - інтелектуальна, або розумна) - пластикова картка з мікросхемою, яка забезпечує зберігання електронних грошей, шифрування інформації і вироблення “цифрового” підпису. Занести гроші на картку можна за допомогою ATM (Automated Teller Machine) – автоматичної касової машини в банку, в пунктах обміну валют чи банкоматах. Як тільки карта проініційована й у ній записані дані (або сума грошей), доступ до них захищається кодованим паролем (або PIN-кодом), відомим тільки хазяїну карти. Дані, записані на карті, можуть бути також зашифровані. При несанкціонованій спробі використання смарт-карта здатна самостійно на час або назавжди припинити свою роботу. Для відновлення працездатності карти необхідне її повернення на місце видачі (зазвичай це банк). Для прийому платежів зі смарт-карт використовуються спеціальні касові апарати. Існують також “гаманці” (digital wallet , від Mondex), за допомогою яких можна перерахувати гроші з однієї картки на іншу. Для того, щоб використовувати смарт-картку для Інтернет-платежів, необхідна наявність пристрою її зчитування на комп’ютері власника. Такі пристрої називають PC card reader. В Україні НБУ, фірмою "Юнисистем" та компанією Microcosmic Group в кінці травня 2001 року було представлено проект "Інтернет-платежі в Національній системі масових електронних платежів". Завдяки системі «Інтерплат» (www.interplat.com.ua) , кожний користувач Інтернета, який має смарт-карту НСМЕП та зчитуючий пристрій (карт-рідер), і встановить спеціальне програмне забезпечення, зможе швидко і надійно здійснювати розрахунки в Інтернет. В таблиці 11.4 зроблено порівняння українських платіжних систем на основі електронних грошей. Таблиця 11.4. Порівняння систем Інтернет-розрахунків на основі електронних грошей Характеристика WebMoney PayCash Інтерплат 1.Зручність введення/виведення грошей в/із системи Банківський, поштовий переказ, переказ Western Unіon, послуги кур’єра передоплачена карта smart-карта 2. Високий рівень безпеки і захищеності Протокол HTTP-S, або протокол, захищений алгоритмами RSA і RC5 RSA (довжина ключа 1024 біт), електронний цифровий підпис, "сліпий " підпис Стандарти DES, Trіple DES, RSA. 3. Анонімність клієнтів в системі Забезпечується. Також є можливість зареєструватися в системі, тобто позбутися анонімності. 4. Здійснення мікроплатежів Так: платежі $1- $5 – тільки по вівторках Так: від 0.001 цента Так. 5. Вартість транзакцій 0.8% , але не менше 0.01 WM 1% від суми 1.5% від суми 6. Вартість підключення для компанії 0 Плата за підключення - від 3 до 100 грн., щомісячна плата - від 0 до 20 грн. Реєстраційний внесок- 1100 грн. Щомісячна абонентська плата -325 грн. 7. Розмаїтість послуг і сервісів (крім оплати товарів в Інтернет-магазинах) Трастововий сервіс, Megastock.Ru, Exaccess.Ru та ін. Оплата комун. послуг, телефону, телебачення електроенергії мобільної телефонії, Інтернет та ін. Нагромаджен-ня заощаджень в банку; офлайн та онлайн режими 5. Віртуальні брокери 5.1. Поняття віртуального брокера, Інтернет-трейдінгу Віртуальний брокер (Інтернет-брокер) - інвестиційний посередник (брокер), що надає клієнту послуги з купівлю-продаж цінних паперів або валюти в реальному часі через мережу Інтернет. Про осіб, що використовують Інтернет для купівлі-продажу фінансових активів говорять, що вони займаються Інтернет-трейдінгом (E-trading, I-trading). Інтернет-трейдінг (E-trading, I-trading) - діяльність з управління інвестиціями через Інтернет. Інтернет-трейдинг включає 3 компоненти: • Доставка всієї біржової інформації учаснику торгів; • Доставка заявок клієнта в біржову торгову систему; • Відслідковування власних заявок і угод Можна виділити два типи Інтернет-трейдінгу: 1. Робота з цінними паперами (акціями, облігаціями і т.п.) на різноманітних фінансових біржах . 2. Онлайн-торгівля на міжнародному валютному ринку FOREX. Для того, щоб займатися Інтернет-трейдінгом, інвестор повинен укласти угоду з компанією Інтернет-брокером (ділінговим центром) і відкрити в ній інвестиційний рахунок. Інтернет-брокер є фінансовою організацією, що має всі необхідні ліцензії на подібну діяльність. Брокер є номінальним утримувачем цінних паперів клієнта, відкриває йому доступ до своїх торгових терміналів, підключених до торгових систем і виконує розпорядження клієнта по операціях з інвестиційним рахунком (щодо купівлі/продажу цінних паперів або валюти). Існує два основних способи надання брокерських послуг через Інтернет: 1) Через сайт Інтернет-брокера - клієнт купує/продає цінні папери, складає свій інвестиційний портфель і т.д. безпосередньо на сайті компанії-брокера, використовує при цьому звичайний Web-броузер. Управління інвестиційним портфелем ведеться зазвичай через заповнення стандартних веб-форм. При чому, здійснювати управління активами інвестор може з будь-якого терміналу, підключеного до Інтернет. Цей спосіб простіший і дешевний, як для клієнта, так і для компанії-посередника Надання брокерських послуг через сайт компанії зазвичай передбачає: • Кожний інвестор має свій логін і пароль для входу в систему управління своїм портфелем. • Існування інтерфейсу - веб-форми, за допомогою якої інвестор керує своїм портфелем, віддає замовлення по купівлі/продажу фінансових активів та інш. • Існування розділу сайту, пов’язаного з новинами про фінанси і ринки. • Надання котировок цінних паперів і курсів валют, які часто оновлюються (зазвичай 1 раз на хвилину). • Надання простих графіків, аналітичних статей та інш. для інвестора. • Пошук цінних паперів за критеріями (dept-to-equity, growth rate, PE…) та інш. 2) З використанням клієнтського програмного забезпечення - клієнт встановлює на свому комп’ютері спеціальне програмне забезпечення, і за допомогою нього отримує інформацію та здійснює транзакції на фінансових ринках. Цей спосіб Інтернет-брокеріджу найбільш ефективний для користувача, оскільки він може настроїти інтерфейс під себе, будувати графіки, отримувати лише ту інформацію, яка йому потрібна. В першу чергу цей спосіб потрібний для професійних інвесторів, оскільки їм завжди потрібна повна фінансова інформація та спеціальні інструменти для її аналізу. Для простих інвесторів буде достатнім управління своїм портфелем за допомогою сайту компанії. Програмне забезпечення інтернет-трейдингу за призначенням можна розділити на три групи: • Інформаційне (постачання фінансової інформації в режимі реального часу)- Reuters iScreen, Signal, Tenfore, CQG, Telerate • Дилінгове - програмні продукти для торгівлі через ІНТЕРНЕТ, їм притаманний різний рівень зручності та надійності, різний набір інструментів – MetaTrader, Internet Dealing System • Аналітичне - дозволяє проводити глибокий аналіз графіків цін за допомогою великої кількості різних індикаторов – MetaStock, Omega ProSuite2000 5.2. Робота з цінними паперами Серед українських компаній, що надають брокерські послуги з купівлі-продажу цінних паперів з свого сайту в Інтернеті можна назвати: “Атланта Капітал” - @Line (http://atlanta.com.ua); "Сократ" (www.sokrat.kiev.ua), “Укранет-траст”, “Сігма-фонд” та інш. Розглянемо детальніше основні моменти, пов’язані з роботою в системі @Line. Приватні інвестори без спеціального ПЗ, зайшовши на сайт компанії, можуть здійснювати операції купівлі/продажу цінних паперів, а також відслідковувати курси акцій на шести найбільш популярних торгових майданчиках СНД: ПФТС (Україна), РТС, ММВБ, МФБ, СпВБ, СбФБ (Росія). Навчитися роботі з системою можна за допомогою гри @Line-Games (http://games.uts.net.ua/). Систему можуть використовувати і корпоративні клієнти - брокерські компанії. Для того щоб відкрити рахунок, необхідно зв'язатися з відділом по роботі з клієнтами (телефони подані на сайті), а також оформити наступні документи: 1) договір на комплексне обслуговування операцій з цінними паперами; 2) договір на інформаційне обслуговування; 3) договір на інформаційне обслуговування. Мінімальний розмір інвестицій становить 10 000$ США. Розмір комісійних - Для входу на клієнтський рахунок потрібно зайти на адресу http://broker.atlanta.com.ua, при цьому відкриється спеціальна форма, де необхідно ввести Логін і Пароль, видані брокером (або обрані при реєстрації). Загальний вид рахунка показано на рис.11.10. Рис.11.10. Загальний вид клієнтського рахунка Як можна помітити, форма для роботи з клієнтським рахунком чітко розділена на 5 інформаційних зон (див. на рис.11.11.). Кожна зона відповідає за виконання визначеного набору функцій. 1. Поле системної логіки відповідає за авторизацію користувача в системі. Дозволяє (у випадку тимчасового обриву зв'язку) поновити зв'язок зі своїм рахунком шляхом натискання на кнопку «Обновити», а також дозволяє зняти авторизацію клієнта (кнопка «Вихід»), у цій зоні знаходиться також вхід на форум системи («Висловити думку»). 2. Зона навігації по системі дозволяє шляхом вибору потрібних полів переглядати в зонах 3, 5 потрібну інформацію. 1. Поле системної логіки 2. Зона навігації 3. Інформаційна зона 4. Зона торгів 5. Зона операцій. Рис.11.11. Інформаційні зони системи @Line 3. Інформаційна зона – відображає інформацію про клієнта або емітентів, що беруть участь в системі. 4. У зоні торгів відображаються поточні (діючі на даний момент часу) заявки на покупку і продаж цінних паперів. Котирування, виставлені клієнтом відзначені жовтим. 5. У зоні операцій здійснюються: зміна настроювань клієнта, оформлення заявки на покупку ЦП, оформлення заявок на продаж ЦП, виводиться інформація про стан портфеля (рис.11.12.), переглядається історія угод, історія заявок на купівлю/продаж ЦП, відправляються повідомлення брокеру та переглядається переписка зі своїм брокером. Рис.11.12. Портфель 5.3. Клієнтське програмне забезпечення для роботи на Форексі Світовий міжбанківський валютний ринок Форекс виник в 1971 році після того як президент Ніксон відмовився від Бреттон-Вудської системи регулювання валютних курсів і як результат відбувся перехід до плаваючих курсів валют. З того часу Форекс став самим динамічним і ліквідним ринком, який ще до того ж працює цілодобово! Головною особливістю даного ринку є те, що він не має конкретного місця торгівлі. Форекс – це мережа дилерів, об’єднаних за допомогою телекомунікацій. Склад учасників валютного ринку різноманітний: від найбільших банків і могутніх міжнародних інвестиційних фондів до невеликих фірм і приватних інвесторів (остання група сама чисельна). Трейдери можуть знаходитися в будь-якій точці земної кулі і цілодобово вести торгівлю. Вражає також об’єм валют, яким оперує Форекс .Як зафіксував Wall Street Journal у вересні 1992 року, цей об'єм склав близько трильйона доларів в день. Сьогодні ж обіг ринку Форекс складає від 1 до 3 трильйонів доларів в день. Ринок FOREX користується популярністю в дрібних і середніх інвесторів з цілого ряду причин. На відміну від ринку цінних паперів, тут не потрібно великий початковий капітал і визначений термін для одержання прибутку. Механізм маржинальної торгівлі (інвестору надається “кредитне плече” 1:2 – 1:100) дозволяє інвестору мати початковий капітал 2-5% від суми операцій, що ним проводяться. Для здійснення роботи на ринку Форекс використовуються торгові термінали які умовно можна об’єднати у три групи: 1. Онлайнові торгові майданчики, які не вимагають встановлення на комп’ютер додаткового програмного забезпечення (в Україні використовують клієнти ділінгового центру «Укрсоцбанку»). 2. Торгові платформи які вимагають інсталяції на робочій станції користувача (в Україні використовують клієнти "Телетрейд" (http://teletrade.kiev.ua/), «Форекс лтд» (www.forexua.com), Forex Service (www.forexservice.net), «Альпарі» (www.alpari.ua) та інш.). 3. Торгові термінали для КПК (рис.11.13 .) На території СНГ використовується близько 20 торгівельних платформ. За даними опитування сайту www.forextimes.ru найбільш відомими є: MetaTrader, Guta Broker, Dealing System, Visual Trading, iForex, Internet Dealing System. Найбільш поширеним в Україні на сьогодні є торговий термінал MetaTrader від компанії MetaQuotes Software Corp (www.metaquotes.ru/). Клієнтський термінал MetaTrader (рис.11.14) надає трейдеру унікальні функціональні можливості, такі як: • простий і інтуїтивно зрозумілий інтерфейс для торгівлі через Інтернет; • забезпечення конфіденційності операцій, що проводяться; • проведення технічного аналізу в реальному режимі часу; • отримання котирувань і новин в реальному режимі часу; • здійснення операцій і контроль за станом відкритих позицій; • зручна система чартинга, що дозволяє вести повноцінний технічний аналіз; • підтримка необмеженої кількості відкритих вікон з графіками з власними настройками; • підтримка різних видів графіків (бари, японські свічки, лінійні) і декількох тимчасових періодів: M1, M5, M15, M30, H1, H4, Daily, Weekly; • ведення декількох торгових рахунків з можливістю швидкого перемикання між ними; • внутрішня пошта і ведення логів операцій; • перегляд і друк історії операцій за будь-який період; • підтримка передачі котирувань через DDE; • можливість експорту історичних даних в різні формати. Головною особливістю MetaTrader є можливість запиту котирування без попереднього повідомлення про закриття або відкриття позиції. Крім вказаних можливостей даний термінал дозволяє користуватися багатьма графічними інструментами, зокрема : горизонтальні, вертикальні лінії, лінії тренда, Вила Ендрюса, Дуги Фібоначі, рівні корекції Фібоначі, та інші. MetaTrader також може будувати більше 20 видів комп’ютерних індикаторів. Expert Advisors (радники) дозволяють програмувати власні торгові стратегії, використовуючи внутрішнію мову MetaQuotes Language II, тестувати їх на історичних даних і автоматично виконувати будь-які торгові операції на рахунку та контролювати всі відкриті позиції без втручання трейдера. 6. Віртуальні магазини Існує декілька способів створення електронних магазинів в Інтернет. Вони відрізняються вартістю витрат, а також можливостями, які може мати електронний магазин. 1) Використання торгових Інтернет-порталів. Найдешевший і найпростіший (а також і найобмеженіший у можливостях) варіант - скористатися засобами, що надаються для створення електронних магазинів на одному з електронних порталів. У цьому випадку магазин зазвичай буде мати стандартний дизайн та надавати покупцям лише ті способи оплати покупок, які передбачені на порталі. Необхідно також буде щомісяця оплачувати послуги порталу (проте у переважній більшості випадків це невеликі суми). Перевагами такого варіанту окрім дешевизни і простоти є ще й те, що популярні Інтернет-портали зазвичай мають досить багато відвідувачів. Як приклади таких порталів можна назвати іноземні: America Online, Amazon.com, eBay.com; російські: Internetmagazin.ru, Торговий Центр EU (www.eu.ru), Торговий ряд Покровка (www.pokrovka.nnov.ru) та ін.; українські: Віртуальний торговий центр (www.e-t-e.com), 2) Використання спеціального програмного забезпечення. Даний варіант не вимагає високої кваліфікації розробника і дозволяє не лише у досить короткий час створити електронний магазин, але й набудовувати та змінювати його у подальшому. Проте необхідно придбати деяке спеціальне програмне забезпечення. На ринку представлено велике різноманіття програм, призначених для створення електронних магазинів. Серед них є як досить потужні і дорогі (наприклад, INTERSHOP та ін.), так і програми з невеликою вартістю та необхідними можливостями (наприклад, пакет MoneyMethod3000 від російської компанії Гіперметод www.hypermethod.ru ), а також безкоштовні програми. Звичайно, витрати на створення магазину в даному випадку (як і в попередньому) будуть також включати оплату послуг інтернет-провайдера. 3) Створення Інтернет-магазину на основі стандартних алгоритмічних мов програмування і стандартних засобів розробки Інтернет-систем. Серед них: редактори та мова HTML, мови сценаріїв JavaScript або VisualBasicScript мови PHP, Perl, Java, C, C++, Vіsual Basіc, та ін. Даний варіант створення електронного магазину потребує досить високої кваліфікації розробника-програміста. Проте він може якнайкраще врахувати особливості конкретної сфери бізнесу і має найширші можливості щодо створення. Вартість розробки при цьому може коливатися в значних межах залежно від реалізованих функцій та вимог, а також обраних технологій і програмного забезпечення. При створенні електронного магазину за таким варіантом необхідно також продумати варіанти щодо його розміщення в Інтернет - чи то на сервері провайдера (вигідно для невеликих магазинів) чи з розміщенням на власному сервері, підключеному виділеними каналами до Інтернет. Для прикладу наведемо книжковий електронний магазин Видавництва КНЕУ, створений студентською лабораторією кафедри інформаційних систем в економіці під керівництвом автора посібника. Даний магазин складається з двох частин: клієнтської (рис.11.15) і адміністраторської (11.16). Клієнтська частина надає можливість вибору необхідних товарів (книг), формування замовлення, оформлення замовлення, реєстрації (для постійних клієнтів можливе присвоєння логіну і паролю та надання знижок), розраховується не лише вартість замовлення, але й вартість доставки обраним способом. Адміністраторська частина дозволяє формувати товари в групи (книги в розділ), вводити інформацію про нові товари та відмічати наявність товарів на складі, працювати з замовленнями, вводити знижки для постійних клієнтів, завантажувати нові прайси (як .zip-архів) на сайт та інш. Для розробки даного магазину використано стандартні засоби розробки web-додатків: мову PHP, HTML, JavaScript. Як СКБД використовується MySQL. Магазин розміщено на сервері провайдера. Доступ до адміністраторської частини здійснюється через Інтернет. 7. Віртуальні страхові компанії Інтернет-страхування – це комплекс взаємин страхової компанії (страховик) і клієнта (страхувальник), що виникають у процесі продажу продукту страхування, його обслуговування і виплати страхового відшкодування, використовуючи технології мережі Інтернет, як найбільш зручні, швидкі і дешеві засоби обміну інформацією. Для організації повністю електронного способу страхування, система інтернет-страхування повинна надавати наступні можливості: • розрахунок величини страхової премії і визначення умов її виплати для кожного виду страхування й у залежності від конкретних параметрів; • заповнення форми заяви на страхування; • замовлення й оплата (у виді одноразової виплати або періодичних виплат) поліса страхування безпосередньо через Інтернет; • передача поліса, завіреного електронно-цифровим підписом страховика, клієнту безпосередньо по мережі Інтернет; • можливість інформаційного обміну між страхувальником і страховиком під час дії договору (для одержання клієнтом різних звітів від страхової компанії); • інформаційний обмін між сторонами при настанні страхового випадку; • оплата страхової премії страхувальнику за допомогою мережі Інтернет при настанні страхового випадку; На Україні постуги страхування через Інтернет активно розвиваються. Так, декілька років підряд проводився Всеукраїнський конкурс "Страховий Інтернет України" (http://konkurs.uainsur.com/) , одним із завдань якого було вивчення, узагальнення і поширення досвіду використання Інтернету в області страхової справи. Але покищо віртуальні представництва українських страхових компаній у більшості випадків являють собою інформаційні майданчики, а не місце, де можна здійснити угоду від початку до кінця. Щоправда, деякі страхові компанії (АСК “Остра-Київ”- www.ostra-kiev.com.ua, “Українська екологічна страхова компанія” - www.ueic.com.ua) надають можливість замовлення страхових полісів через Інтернет. “Українська екологічна страхова компанія” навіть обіцяє за це 5% знижки). Так, компанія АСК “Остра-Київ” (www.ostra-kiev.com.ua), яка у 2003 році завоювала гран-прі на конкурсі "Страховий Інтернет України", надає можливість у своєму Інтернет-магазині замовити деякі страхові поліси, оплатити за них (щоправда не через Інтернет) та отримати поліс зручним для клієнта способом (рис. 11.17). На сайті “Української екологічної страхової компанії” вибір полісів, які можна замовити он-лайн значно більший. Купівля поліса в загальному випадку буде складатися з наступних кроків: 1. Вибір потрібного страхового продукту на сайті компанії, автоматичний розрахунок суми страхового внеску (рис.11.18 ). 2. Заповнення і відправка в електронному виді заяви на страхування (заповнення даних необхідних для оформлення страховки - про страхувальника та інш.). Після реєстрації заяви з клієнтом зв'язується менеджер компанії для уточнення умов замовлення. 3. Оплата страхового поліса – здійснюється готівкою в офісі, готівкою кур'єру, готівкою через ощадкасу на розрахунковий рахунок компанії, або ж безготівковим переказом на розрахунковий рахунок компанії. Українські страхові компанії поки що не надають можливості оплати страхових полісів через Інтернет. 4. Одержання страхового поліса можливе: в офісі компанії, через доставку кур'єром (м. Київ), або рекомендованим листом. В Україні (як і в Росії) через відсутність законодавства про ЕЦП не можлива передача поліса клієнту по Інтернет. 8. Віртуальні університети Використання Інтернет-технологій в навчанні призвело до появи електронного (дистанційного) навчання і виникнення віртуальних університетів. Як мінімум 80% учнів можуть ефективно сприймати навчальні матеріали в будь-якій формі, тобто здатні ефективно навчатися електронним способом Дистанційне навчання (E-learnіng, Web-based Traіnіng -WBT) - надання доступу до комп'ютерних навчальних програм (coursware) через мережу Інтернет чи корпоративні Інтранет мережі. Для опису програмних продуктів за допомогою яких створюються системи дистанційного навчання використовують термін: Система Дистанційної Освіти (СДО), або Learnіng Management System (LMS) - програмне забезпечення, що керує процесом віддаленого електронного навчання. СДО веде облік учнів, навчальних матеріалів, результатів навчання. До основних функцій систем дистанційної освіти відносять: • Облік учнів, персоналізація і розмежування прав доступу до навчальних матеріалів, організація навчання в групах; • Керування процесом навчання, облік результатів навчання і тестування; • Керування й інтеграція з механізмами електронного спілкування (зв'язок з електронною поштою, групами новин, чатом, відеоконференціями, спільне використання додатків, створення віртуальних навчальних класів подібно до віртуальних офісів); • Підготовка оперативної й аналітичної звітності; • Інтеграція з зовнішніми інформаційними системами. Learnіng Portal (E-learnіng Portal) - навчальний портал (корпоративний чи публічний веб-сайт). Корпоративний сайт, що надає доступ до можливостей корпоративного навчання в тому числі і через LMS. Можливо відкритий для широкої публіки сайт, що надає доступ до навчальних програм. Навчальний портал надає наступну інформацію: • можливості навчання в компанії (дистанційним і звичайним способом) • результати раніше минулих навчальних сесій • навчальні програми і курси, що підлягають вивченню • елементи керування знаннями • формування "шляхів навчання" з репозитория навчальних фрагментів До функцій навчального порталу належать: • Персонализация - різні інтерфейси для робочих груп, викладачів, менеджменту, адміністраторів • Надання всієї інформації про навчання в компанії (не тільки електронні навчальні курси) • Зв'язок електронного навчання з профілем користувача, його посадовими обов'язками • Керування контентом (Content Managіng) Корпоративний навчальний портал може бути як самостійним продуктом, так і частиною більш широкого по своїх можливостях корпоративного інформаційного порталу. Система дистанційної освіти (Learnіng Management System чи СДО) працює в тісному поєднанні (чи є частиною) навчального порталу. Портал надає доступ до різної інформації, у тому числі і до навчальних курсів, які містяться в СДО (рис.11.19). Останнім часом усе більше уваги приділяється сумісності програмних продуктів для корпоративного навчання з міжнародними стандартами обміну навчальною інформацією. Основними такими стандартами є SCORM, AІCC (http://www.aicc.org/), ІMS(http://www.imsproject.org/). Серед готових рішень для створення систем дистанційної освіти і корпоративних навчальних порталів можна назвати: WebCT (www.webct.com), WebTutor (www.websoft.ru), Lotus LearningSpace, та інш. WebTutor Дана система є розробкою компанії WebSoft (www.websoft.ru). Серед основних особливостей програмного продукту: • Гнучкі можливості планування навчання (навчальні плани, планування за результатами оцінки, автоматичне призначення курсів); • Розвинутий механізм тестування; • Могутній редактор навчальних матеріалів; • Електронні конференції; • Настроювання на корпоративний дизайн клієнта; • Убудовані функції інформаційного порталу; • Підтримка міжнародних стандартів обміну навчальними матеріалами (AІCC). • Можливості для інтеграції з зовнішніми інформаційними системами, у тому числі із системами обліку персоналу . Демо-версія системи доступна на http://webtutor.websoft.ru/ (рис.11.20). Все більш поширеним стає створення віртуальних універсистетів. Під терміном "віртуальний університет" розуміється об'єднання навчальних закладів, у тому числі і недержавних, на основі телекомунікаційних мереж з метою спільного використання інформаційних ресурсів і забезпечення колективного доступу до них для підвищення ефективності діяльності. Переважно на сьогодні віртуальні університети існують у вигляді корпоративних університетів ( основною метою яких є навчання персоналу компанії, але в багатьох випадках здійснюється і продаж послуг навчання і назовні). За даними компанії Corporate Unіversіty Xchange (CUX), що спеціалізується на аналізі даних в області корпоративної освіти, число таких університетів за останні десять років збільшилося з 400 до 1600 і, якщо сформована тенденція збережеться, те до 2010 р. корпоративних університетів стане більше, ніж звичайних. У корпоративних університетах навчання найчастіше ведеться по наступним напрямках: менеджмент, інженерно-технічні спеціальності, керування бізнесом, фінанси й інформаційні технології. Приблизно 93% усіх навчальних програм будується з частковим використанням найбільш популярних Web-технологій, а також спрямованого на робоче місце телевізійного віщання (streamіng vіdeo to the desktop). Найбільшим корпоративним університетом CUX вважається підрозділ ІBM Global Learnіng. У його складі понад 3400 викладачів, що працюють у 55 країнах, де вони читають 10 000 спеціалізованих курсів. В університеті ІBM уже пройшли перепідготовку 126 000 співробітників компанії. Контрольні запитання і завдання: Знайдіть самостійно в Інтернет та ознайомтеся з прикладами віртуальних організацій. Література до теми: 1. National Industrial Information Infrastructure Protocols (NIIIP), December 31, 1998. www.niiip.org . 2. Дмитров В.И. Опыт внедрения CALS за рубежом. // Автоматизация проектирования. - 1997. -№1. - С. 2-9 3. Гибкие производственные системы (ГПС) и интегрированные компьютеризированные производства (КИП). НИЦ CALS-технологий "Прикладая логистика". http://www.logistics.ru/21/7/5/i8_401.htm 4. Sims, Oliver. Enabling the Virtual Enterprise. The Internet provides the infrastructure // Object Magazine, Vol.1, Issue 10, October 1996, Currents On-line Journal (см. http://www.sigs.com/). 5. Козье Д. Электронная комерция: Пер. с англ. – Москва: Издательсько-торговий дом “Руская редакция”. 1999. – 288 с.: ил. 6. Береза А.М., Козак І.А. та ін. Електронна комерція. Навч. Посібник. -К.: КНЕУ, 2002. -324 с. 7. Грег Алуанг. Круглый стол без стола. //PC Magazine, February 10, 1998, p. 175. http://www.beda.stup.ac.ru/wmaster/books/magazine/pcmag/9806/069818.htm 8. Ковалишина Г.Реальность виртуальных банков. Институт финансовых исследований, 12.11.01. http://www.finansy.ru/publ/pelek002.htm 9. Пейтел Э., Пейтел П. Internet-трейдинг: Полное руководство: Пер. с англ.. Издательство Вильямс, 2003, 320 с. 10. Матеріали сайту www.websoft.ru
Вітаємо, ви успішно прочитали книгу!
В нашій електронній бібліотеці ви можете безкоштовно і без реєстрації прочитати «Інформаційні технології віртуальних організацій» автора Козак І. на телефоні, Android, iPhone, iPads. Зараз ви знаходитесь в розділі „читати“ на сторінці 1. Приємного читання.