Соловяненко Д.В. Стратегія забеспечення онлайнового бібліотечного сервісу // Наук. праці Національної бібліотеки України імені В. І. Вернадського. Вип. 13 / Відп. ред. О. С. Онищенко. - К.: НБУВ, 2004.
Стратегія забезпечення онлайнового бібліотечного сервісу
Соловяненко Денис Володимирович
Національна бібліотека України імені В.І. Вернадського, КиївОстанніми роками бібліотеки відчувають гостру необхідність використання Інтернет-технологій для обслуговування користувачів. Сьогодні бібліотеки надають в онлайновому режимі доступ до своїх колекцій, на їх сайтах створюються спеціальні засоби навігації та інформаційного пошуку, онлайнова комунікація поступово стає невід’ємною частиною бібліотечно-інформаційного сервісу. Онлайновий бібліотечний сервіс (ОБС) уже набув системних рис, тобто всі види бібліотечних послуг, що надаються в онлайновому режимі, розглядаються у єдиному комплексі. Проте цей прогресивний напрямок інноваційної діяльності бібліотек вимагає від бібліотечних працівників чіткого розуміння динаміки розвитку сучасних програмних засобів створення такого роду систем. Ринок програмного забезпечення постійно змінюється, тому бібліотеки, якщо вони прагнуть залишатися популярними серед користувачів, повинні займатись вивченням нових технологій, аналізувати доцільність їх використання та постійно працювати над покращенням сервісних можливостей власних систем.
Питанням розробки, впровадження та використання програмного забезпечення сьогодні присвячується дуже багато спеціальної літератури як закордонних, так і вітчизняних авторів. У науково-практичних колах такі видання користуються великою популярністю, і з кожним днем інтерес до них все більше зростає. Виходить велика кількість періодичних видань інформаційно-аналітичного характеру, науковці пишуть монографії з питань програмування та публікації баз даних в обчислювальних мережах, вистачає й практичних рекомендацій щодо впровадження тих чи інших технологій. Проте питома вага публікацій, присвячених розробці систем ОБС як специфічного виду систем онлайнової взаємодії, ще досить мала. Існуючі сьогодні видання переважно присвячуються створенню комерційних Інтернет-проектів (систем е-торгівлі або сітьової реклами). В той самий час рішення, придатні для створення комерційних систем, далеко не завжди придатні для створення систем ОБС. По-перше, комерційні проекти створюються з метою отримання прибутку, тоді як основним призначенням систем ОБС є надання безкоштовних бібліотечних послуг. Крім того, користувачами комерційних проектів є обмежена цільова аудиторія, в той самий час як, система ОБС повинна бути доступною для якомога більшої частини користувачів, незалежно від їх апаратної та програмної платформи. Ще одним немаловажним фактором є те, що комерційні системи частіше за все створюються для продажу (надання у повний доступ) інформації, тоді як система ОБС повинна слідкувати за дотриманням авторських прав (тобто, до деяких видань надавати лише частковий доступ). Таких факторів можна навести багато. Отже, систему ОБС від інших видів онлайнових систем відрізняють мета створення, умови функціонування, цільове призначення тощо. У цій статті зроблено спробу створити технологічну стратегію розвитку ОБС: огляду ринку нових технологій з урахуванням специфіки ОБС, аналізу переваг та недоліків різних технологій та вибору оптимальних засобів для створення системи ОБС.
ОБС передбачає достатньо складну програмну взаємодію. У процесі реалізації ОБС взаємодіють дуже багато програмних компонентів: операційна система мережі, брандмауер, система ОБС, програмний шлюз HTTP-Z 39.50, сервери для кожного протоколу (HTTP, Z 39.50, FTP, SMTP, NNTP, IMAP, POP3 тощо), програми-утиліти та ін. Для надійної та точної роботи кожного з цих компонентів потрібно забезпечити якісну взаємодію між ними. Тобто, всі вони повинні працювати у єдиному комплексі, інакше роботі всієї системи неминуче загрожують помилконебезпечні ситуації та збої.
Більшість програмних компонентів (операційна система, основні сервери, утиліти) можуть бути отримані бібліотечними програмістами від третіх осіб. Розробка операційної платформи - завдання дуже складне для самостійного розроблення бібліотекою. Пересічній бібліотеці лише потрібно обрати найпридатнішу для своїх потреб платформу з тих, що представлені сьогодні на ринку.
Фактично, більш актуальним для бібліотеки питанням є координація зусиль при розробці програмних компонентів системи ОБС. Кожна система ОБС повинна мати певні обов’язкові компоненти, тому дуже важливим питанням є співпраця з питань розробки програмного забезпечення системи ОБС. Причому, при розробці цієї системи важливим є поєднання зусиль програмістів, адміністраторів комп’ютерних мереж, веб-майстрів та обслуговуючого штату бібліотеки. Найкращим варіантом створення масштабного Інтернет-проекту є корпоративна співпраця служб ОБС (тобто, спеціалізованих бібліотечних підрозділів) бібліотек різних систем і відомств з метою координації та кооперації своїх зусиль. Такий варіант вбачається більш раціональним як з точки зору економії коштів та зусиль працівників, так і з точки зору працездатності створюваного проекту.
У будь-якому разі служба ОБС повинна визначитись із програмною платформою системи ОБС. Оскільки система ОБС призначена для роботи у онлайновому режимі, її програми повинні розроблятися на відповідній програмній платформі.
Програмні компоненти системи ОБС (як і будь-якої іншої Інтернет-системи) можна розділити на дві групи: розширення клієнтської частини та розширення серверної частини1. Розширення клієнтської частини - це програми, що нарощують функціональні можливості браузерів (Java-аплети, компоненти ActiveX, скрипти JavaScript та VBScript тощо). Все це невеликі за обсягом програми, які призначені для виконання локальних завдань, створення потрібного інтерфейсу, елементарної арифметичної обробки даних, налагодження сценаріїв, перевірки даних у веб-формах тощо. Розширення серверної частини призначені для нарощення функціональних можливостей веб-серверів. Ці програми створюються для вирішення глобальних завдань сітьової взаємодії, основним із яких є доступ до баз даних на сервері.
Сьогодні існує досить багато програмних платформ, які призначені для розширення серверної частини. У моделі “клієнт-сервер” доступ до даних на сервері може реалізуватися за допомогою двох технологій - CGI та API.
Common Gateway Interface (CGI) - це “протокол, що визначає процес взаємодії HTTP-сервера з програмами маршрутизації на сервері”2. Тобто, протокол CGI - це шлюз між HTTP-сервером та тими програмними засобами, які не можуть напряму викликатися за протоколом HTTP. CGI-програми запускаються веб-сервером, який проводить хостінг (hosting) системи ОБС, тобто Web-сервер передає запити, отримані від користувача, CGI-програмам, які ці запити обробляють та повертають результати обробки веб-серверу, а веб-сервер передає ці результати користувачеві. CGI-програма може являти собою скрипт, тобто вихідний програмний код (здебільшого використовуються мови Perl та PHP) або відкомпільовану програму (написану будь-якою мовою: C/C++, Visual Basic, Delphi, Fortran тощо). У цій технології є декілька ключових моментів. По-перше, ця технологія не вимагає ніяких спеціальних програмних засобів на клієнтській частині (комп’ютері користувача), оскільки CGI-програми виконуються повністю на сервері та ніяк не залежать від клієнтського комп’ютера. Іншим ключовим моментом є атомарність роботи CGI-програм, безсистемність їх взаємодії. Кожна CGI-програма на сервері самодостатня, вона працює відносно незалежно від інших програм. Звісно, різні CGI-програми можуть використовувати якісь спільні програмні компоненти: БД, програмні додатки та бібліотеки тощо, але цілісну систему в рамках цієї технології побудувати все ж досить важко.
Іншою технологією доступу до даних є API. Application Program Interface (API) - це “набір правил, які визначають процедури виклику послуг/функцій за допомогою програмного пакета”3. Це стандартна технологія роботи комп’ютерних програм, проте як Інтернет-технологія вона почала використовуватись нещодавно. Якщо використовується технологія API, програмний пакет складається з однієї або декількох динамічних бібліотек DLL (Dynamic Linked Library) та об’єктів COM (Component Object Model) для доступу до них. На відміну від технології CGI, API передбачає інтеграцію програмного пакета з усією системою. Ця технологія набагато складніша, ніж CGI, але водночас вона є й набагато потужнішою. Якщо технологія CGI дає змогу створити шлюз, за допомогою якого на сервері зможуть виконуватися ті чи інші програмні процеси, то за допомогою API дозволяє сам клієнт може віддалено працювати з програмами на сервері і викликати потрібні функції не опосередковано через шлюз, а напряму. Тут важливими є декілька моментів. По-перше, ця технологія передбачає наявність на комп’ютері користувача спеціального клієнта для доступу до програм на сервері. Іншим важливим моментом є системність роботи всіх програмних компонентів API. Всі програмні додатки, бібліотеки, веб-сторінки тощо складають єдиний “комплект” (assembly) взаємопов’язаних компонентів, що використовують єдине програмне ядро. До того ж, така система інтегрується з операційною платформою і використовує деякі її програмні компоненти, що значно покращує працездатність системи.
Тобто, можна сказати, що технологія CGI передбачає створення на сервері великої кількості маленьких програм, які працюють відносно незалежно одна від одної. Технологія API, навпаки, передбачає створення однієї цілісної системи, різні компоненти якої працюють взаємопов’язано.
В порівнянні з технологією API, CGI-програми працюють набагато повільніше і вимагають більше серверних ресурсів. З іншого боку, CGI-програми невимогливі до клієнтського програмного забезпечення, в той самий час як API-технологія вимагає наявності на комп’ютері користувача спеціального клієнта API.
Звісно, для розробників набагато простіше створити веб-публікацію, в якій доступ клієнта до даних буде здійснюватися за допомогою форм, що обробляються CGI-програмами. Але потужну систему ОБС таким чином побудувати буде важко. Одразу ж виникнуть проблеми із синхронізацією даних, із захистом інформації, безпекою серверу тощо. API-технологія більш прогресивна, тому для розробки системи ОБС краще обрати саме її.
API-технологія розвивається, сьогодні з'являються нові технології, здатні суттєво покращити можливості сітьової взаємодії. Іде поступовий перехід від централізованих схем типу “клієнт-сервер” до розподіленої архітектури обчислень4. Якщо в моделі “клієнт-сервер” користувачі отримували доступ до певного серверу, то у моделі “клієнт-мережа” вони отримують доступ до певного сервісу, безвідносно до того, де він фізично розташований. Така технологія суттєво здешевлює рішення шляхом інтеграції роботи серверів у рамках однієї технології. Основою такого здешевлення є той факт, що сьогодні вартість передачі даних у мережі є суттєво меншою, ніж вартість обчислень на комп’ютері клієнта. Отже, розподілення обчислень між серверами дешевше, ніж виконання обчислень на одній машині.
З появою технології розподілених обчислень сітьова взаємодія перейшла на нову ланку розвитку, коли різні установи отримали змогу координувати свої зусилля і більш раціонально розпоряджатися своїми ресурсами, використовуючи можливості одне одного. Так з’явилася технологія веб-сервісів.
Веб-сервіси - це новий вид Інтернет-додатків, що забезпечують динамічний зв’язок різнорідних систем на основі використання спільних стандартів5. Тобто, веб-сервіс являє собою програмний додаток або інформаційний ресурс, доступ до якого в Інтернет/Інтранет/Екстранет-мережі здійснюється через стандартні веб-протоколи. Важливим тут є те, що веб-сервіси дозволяють отримувати доступ до програмних компонентів, незалежно від того, як ці компоненти працюють, на якій платформі вони працюють та які пристрої використовують. Говорячи більш конкретно, веб-сервіси використовують для обміну даними протокол HTTP та формат XML, які давно вже встигли стати загальновідомими. В результаті поєднання технологій HTTP та XML був отриманий протокол SOAP (Simple Object Access Protocol), який і є основою веб-сервісів. Отже, на появу технології веб-сервісів вплинули дві тенденції сучасної програмної індустрії: прийняття HTTP як стандартного протоколу, за допомогою якого здійснюється доступ в Інтернет, та визнання формату XML фактичним стандартом для передачі даних6.
Веб-сервіси базуються на трьох основних веб-стандартах:
- протокол SOAP (Simple Object Access Protocol) - стандарт для обміну (відсилання та отримання) повідомленнями між сервісами. SOAP являє собою XML-”конверт” із запитом (відповіддю на запит), у якому зазначені засоби представлення XML-структури та засоби зв’язку за протоколом HTTP.
- мова WSDL (Web Services Description Language) - засіб опису програмних інтерфейсів веб-сервісів. WSDL-опис являє собою документ формату XML, який містить дані про протокол взаємодії, адресу сервісу, формат конверта SOAP та його елементи.
- стандарт UDDI (Universal Description, Discovery and Integration) - це, по суті, реєстр веб-сервісів. За допомогою цього стандарту певний веб-сервіс може бути зареєстрований у веб-реєстрі UDDI для його подальшої ідентифікації серед багатьох інших. Тобто, зацікавлена організація може обрати з цього реєстру ті сервіси, якими вона хоче користуватися, та зареєструвати створені нею сервіси, щоб ними могли користуватись інші зацікавлені організації.
Веб-сервіси - це засіб інтеграції. Причому, інтеграція тут має декілька рівнів. На рівні даних програмні додатки можуть обмінюватись інформацією. Так, наприклад, програмний додаток, розташований на одному сервері, може використовувати дані з бази даних на іншому. Цей рівень передбачає інтеграцію даних, це найпростіша інтеграція. Наступний рівень - об’єктна взаємодія. Тут мова йде про те, що програмний додаток, розташований на одному сервері, може запускати програмні процеси на іншому. Тобто, якщо відомо, який об’єкт потрібно викликати для запуску певного процесу, цей об’єкт може бути викликаний. Але найскладнішим є третій рівень інтеграції - інтеграція на рівні стандартної семантики. На цьому рівні сервіси можуть “спілкуватися спільною мовою”7, обходячи технологічні розбіжності. Один сервіс може звертатись до іншого із “запитом на виконання покупки”, “запитом на виконання пошуку”, “запитом на отримання статистики” та ін. На цьому рівні інтеграції сервіси будуть потребувати лише стандартизації семантики, тобто, під словами “покупка”, “пошук” і “статистика” вони повинні розуміти одне й те ж саме. Якщо семантичних розбіжностей між ними немає, інтеграція не має особливих труднощів. Тобто, використовуючи специфікацію WSDL, програмний додаток може “говорити” системно-незалежною мовою і це буде виглядати приблизно так: “Якщо ви хочете зі мною поспілкуватись, то можете це зробити наступним чином”. З одного боку, системна незалежність додатків постає з використання мови XML при створенні WSDL-описів, а з іншого - специфікація SOAP дозволяє взаємодіяти серверному та клієнтському додаткам. Потрібно лише надати вхідні дані, а турботи про те, яким чином доставити їх додатку на обробку та повернути її результати назад, протокол SOAP повністю бере на себе8.
Слід сказати про переваги використання технології веб-сервісів для створення системи ОБС. Як говорилося вище, веб-сервіси базуються на єдиних стандартах. Отже, перш за все веб-сервіси цікаві як засіб інтеграції. Тут мається на увазі як інтеграція в рамках однієї установи, так і інтеграція на більш високому міжустановчому рівні. Сервер може використовувати веб-сервіси, створені третіми особами і вирішувати за їх допомогою свої потреби. Так, комп’ютери бібліотечної філії можуть використовувати веб-сервіси, які працюють на основному сервері бібліотеки. На цьому рівні інтеграції використання веб-сервісів є найдоцільнішим та найпростішим. Для цього навіть не потрібне використання технології UDDI, оскільки взаємодія проходить у рамках однієї організації, різні підрозділи якої завжди можуть домовитися про те, яким чином буде працювати веб-сервіс, та розробити внутрібібліотечний стандарт на його використання. Інтеграція роботи філій (зокрема, філій, розташованих у різних містах), яка раніше коштувала великих грошей та трудових ресурсів, за допомогою веб-сервісів може стати набагато легшою та економнішою. В той самий час, веб-сервіси здатні стати також засобом міжбібліотечної інтеграції (власне, в цьому і полягає їх основне значення). Припустимо, одна бібліотека створила дієвий засіб для вирішення певної проблеми (реєстрація користувачів, пошук в електронному каталозі, платіжна система Інтернет-магазину тощо). Якщо бібліотека оформить свій продукт у вигляді веб-сервісу, інші бібліотеки (як і всі інші організації) зможуть його використовувати у своїх цілях. Для цього їм не потрібно буде ніяких особливих програмних засобів. Веб-сервіси дозволяють бібліотекам “не винаходити велосипед”, а використовувати вже готові рішення, створені іншими організаціями. Це новий рівень кооперації та координації використання бібліотечних ресурсів. Одна бібліотека розробляє пошукові засоби, інша - інструменти для ведення статистики, третя - інтерактивні навчальні тури. В результаті задоволені всі, оскільки не є важливим навіть те, як працюють сервіси, створені іншими установами, важливий лише результат їх роботи. Сервіси працюють незалежно один від одного. У процесі розвитку системи ОБС бібліотека може замінювати одні веб-сервіси на інші, створювати нові сервіси, вдосконалювати їх або вилучати існуючі сервіси. І все це можна робити “на льоту”, без втрати ієрархії системи. Простота впровадження веб-сервісів зумовлюється простотою стандартів, на яких вони базуються. Розробка веб-сервісів теж не повинна викликати особливих проблем, адже сьогоднішній ринок програмних засобів пропонує велику кількість інструментів для розробки веб-сервісів.
В той самий час не зайвим буде сказати й про деякі недоліки технології веб-сервісів. Оглядачі здебільшого нарікають на три основні недоліки: неоднозначність специфікації SOAP, недостатню безпечність та недостатню швидкість роботи веб-сервісів. До певної міри ці нарікання є цілком слушними, принаймні відносно технології SOAP. Звісно, механізми безпеки протоколу SOAP поки продумані не зовсім досконало. Коли мова йде про невеликий проект, аналізаторів безпеки, передбачених протоколом SOAP, може цілком вистачити. Але при розробці масштабного Інтернет-проекту, з його розгалуженою системою об’єктів, схем та сценаріїв доступу, розробники можуть зіткнутися з проблемою недостатності стандартних процедур безпеки. В цьому випадку їм доведеться писати велику кількість додаткових засобів: аналізаторів, фільтрів та ін. Другий недолік - низька швидкість роботи веб-сервісів, заснованих на SOAP, - це вже більш складна проблема, хоча вона притаманна всій технології розподілених обчислень, а не лише веб-сервісам. Вирішення цієї проблеми безпосередньо залежить від потужності серверів та пропускної здатності каналів зв’язку. Тобто, тут до часу з’єднання клієнта із сервером додається ще й час з’єднання одного сервера з іншим. До того ж, менш потужний із серверів, по суті, стає “вузькою ланкою” взаємодії. Для потужних серверів зі швидкісними каналами зв’язку це не є великою проблемою, але в менш потужних системах ця проблема може суттєво вплинути на сітьовий трафік і на швидкість взаємодії в цілому. Але основні нарікання на веб-сервіси пов’язані з неоднозначністю специфікації SOAP9. Різні інтерпретації SOAP по-різному, іноді суперечливо, трактують деякі елементи. Специфікація, яка була розроблена для стандартизації веб-орієнтованого програмування, далеко не завжди забезпечує сумісність різних систем на практиці. Маємо ситуацію, коли є стандарт, але проблема стандартизації ще не вирішена. Веб-сервіси, розроблені різними організаціями, на практиці цілком можуть виявитись несумісними один з одним. Саме це насправді є великою проблемою.
В технології веб-сервісів є недоліки, цей факт не можна заперечити, але сьогодні це єдина технологія, яка реально може забезпечити інтеграцію веб-орієнтованих проектів. В інших подібних технологіях, таких як CORBA або DCOM, відсутні деякі з недоліків веб-сервісів, але в них є інші, не менш значні. Зокрема, складність цих технологій у порівнянні з технологією веб-сервісів. Стандарт XML, на якому базуються веб-сервіси, дуже легкий для сприйняття розробниками веб-орієнтованих додатків, він давно відомій всім, хто розробляє Інтернет-проекти, і вже встиг зарекомендувати себе як простий і водночас дієвий. Тут же можна сказати і про фінансовий бік питання. Як відомо, перехід на нові технології не завжди безболісний для бібліотеки, оскільки вимагає від неї певних фінансових витрат. Не є виключенням і технологія веб-сервісів. Але якщо порівняти “сукупну вартість володіння” проектом у традиційній моделі розподілених обчислень (наприклад, на базі технології DCOM) з моделлю, побудованою на технології веб-сервісів, то остання буде вигідно відрізнятися (переважно за рахунок скорочення витрат на підтримку системи та оновлення програмного забезпечення). В технології веб-сервісів основні витрати організації припадають на етап початкового впровадження та розробки системи (якщо система розробляється “із нуля”) або на етап переходу від старої технології до нової (якщо передбачається міграція існуючої системи на нову технологію). Веб-сервіси - це технологія, яка пропонується як стандарт, отже, сама по собі вона є безкоштовною як для комерційного, так і для некомерційного використання. Додаткових витрат потребують перепідготовка персоналу та купівля готових програмних рішень для розробки, налагодження та адміністрування веб-сервісів - серверів веб-сервісів. Рівень витрат тут майже повністю залежить від рівня кваліфікації бібліотечних програмістів. Деякі сервери веб-сервісів пропонують майже повну автоматизацію процесу розробки та адміністрування роботи веб-сервісів - швидко та якісно розробляти веб-сервіси в таких системах можуть навіть не дуже досвідчені веб-програмісти. Інші системи не пропонують такого високого рівня автоматизації, але вони й коштують набагато дешевше. Існують також і безкоштовні утиліти, включені у дистрибутиви платформ веб-сервісів, але, по-перше, розробляти та адмініструвати веб-сервіси за допомогою цих утиліт зможуть лише дуже досвідчені програмісти, а по-друге, така розробка буде дуже трудомісткою та кропіткою.
Але головна перевага технології веб-сервісів перед її старішими аналогами - у стандартизації веб-орієнтованих додатків та інтеграції їх роботи. Якщо до появи веб-сервісів мова йшла про інтеграцію шляхом взаємних домовленостей між організаціями та всередині цих організацій, то сьогодні ми говоримо про прийняття єдиних стандартів на розробку сервісів та уніфікацію сітьової програмної взаємодії. Іншим аспектом стандартизації є можливість міжустановчої співпраці, коли організації отримують можливість працювати над спільними проектами, не турбуючись про сумісність різних компонентів спільного проекту. Тому, вирішуючи питання про підтримку технології веб-сервісів, бібліотека вирішує питання про підтримку стандартів, призначених для інтеграції світового масштабу.
Отже, будемо виходити з того, що для розробки системи ОБС було обрано технологію веб-сервісів. Сьогодні існує дві великі платформи, які підтримують технологію веб-сервісів - .NET (дотнет) від компанії Microsoft та Java 2 Platform, Enterprise Edition (J2EE), основним розробником якої є компанія Sun Microsystems Inc. Багато фірм-виробників програмного забезпечення (Microsoft, Sun, Oracle, IBM, Borland, BEA, Macromedia та багато інших) займаються розробкою спеціалізованих інструментів для вирішення тих чи інших завдань розробки та адміністрування роботи веб-сервісів. Їх продукти різняться за своєю продуктивністю та складністю. Деякі підтримують лише .NET, деякі лише J2EE, деякі намагаються забезпечити інтеграцію цих платформ.
Хоча .NET і J2EE використовують стандарти веб-сервісів, вони суттєво різняться між собою. Розберемо детальніше кожну з цих платформ.
Згідно з визначенням самої Microsoft, .NET - це “закономірний етап у розвитку інформаційних технологій, додатків та сервісів, що дозволяє підприємствам скористатись перевагами сполучення відкритих стандартів та ефективної архітектури Windows 2000”10. Говорячи більш вузько, .NET є змістовно новим середовищем для розробки та виконання веб-орієнтованих програмних додатків, що написані на різних мовах програмування. .NET - це достатньо молода платформа, вперше вона була проанонсована у 2000 році, а перша версія була випущена на початку 2002 року. Основним (хоча і не єдиним) призначенням платформи .NET є виконання програмних додатків у віддаленому режимі (через Інтернет або іншу комп’ютерну мережу). Платформа MS .NET є дуже потужною, Microsoft стверджує, що сьогодні вона є найпотужнішою програмною платформою. Це фірмовий продукт, тобто компанія Microsoft розробила його для продажу. Розробники досить добре продумали питання безпеки роботи .NET-компонентів, розробивши дуже детальну схему безпеки, засновану на CLR, подбали про захист один від одного учасників комунікацій, розробили дієві механізми безвідбійної взаємодії різних програмних компонентів. Викликають повагу також можливості роботи .NET з розподіленими БД. Для системи ОБС ці можливості є особливо важливими, адже вона повинна працювати у гетерогенному середовищі, тобто з БД, які суттєво різняться за формою представлення, структурою та наповненням. Вона містить набір додатків, таких як Visual Studio .Net, Tablet PC та .Net My Services. Ще однією суттєвою перевагою платформи .NET є те, що програмні додатки можуть писатися різними мовами програмування (на початок 2003 року .NET підтримувала 22 мови11). Тобто, програмні додатки, написані різними мовами програмування (C#, C/C++, Visual Basic, JScript, COBOL, Perl тощо) компілюються у формат Microsoft Intermediate Language (MSIL), який інтерпретується за допомогою Common Language Runtime (CLR) у процедури, готові для виконання. Ця можливість вигідно відрізняє платформу .NET тим, що розробляти та підтримувати проект можуть різні програмісти, які працюють на різних мовах програмування. В той самий час Microsoft розробила для платформи .NET спеціалізовану мову C# (Сі-шарп), дуже схожу на мову Java, яка призначається спеціально для розробки веб-сервісів. До недоліків цієї технології слід віднести залежність .NET від операційної платформи. Сьогодні .NET може працювати під операційними системами Windows XP, Windows 2000, Windows NT4 SP6a, Windows Server 2003 та Windows ME/98. Під операційною системою Windows 95 .NET працювати не може. Є можливість роботи .NET під системою Linux. До того ж не на всіх цих операційних платформах можуть працювати всі компоненти .NET. Наприклад, ASP.NET може працювати лише під Windows XP Professional та Windows 2000. Під Windows 98/ME не можна розробляти .NET-компоненти. Як бачимо, платформа .NET працює лише під новими операційними системами, які можливо встановити лише на потужні комп’ютери. Тобто, якщо для розробки системи ОБС бібліотека обирає платформу .NET, значна частка користувачів, які мають доступ до Інтернету зі старих малопотужних комп’ютерів, одразу ж відсікається. До того ж, явний нахил у бік операційних систем Microsoft Windows відсікає частку користувачів, що працюють під іншими операційними системами (MS-DOS, Unix, Mac OS тощо). Сьогодні Microsoft включає цей пакет як обов’язковий у всі свої нові системи (Windows XP, Windows Server 2003), але частка користувачів, які працюють із найновішими операційними системами Microsoft, ще досить мала.
Друга програмна платформа, яку потрібно розглянути - це Java 2 Enterprise Edition (J2EE), основним розробником якої є компанія Sun Microsystems Inc. На відміну від .NET, J2EE не є власністю однієї організації. Її розробкою займається Java Community Process (JCP) - група експертів, що складається більш ніж з 400 компаній, організацій та приватних осіб. Цей факт є як плюсом, так і мінусом даної платформи. З одного боку, обираючи .NET, бібліотека може розраховувати на отримання сервісної підтримки з єдиного джерела - від фірми Microsoft. Сервісна підтримка платформи J2EE не буде такою централізованою. З іншого ж боку, J2EE - продукт співпраці групи спеціалістів із різних компаній, отже, і вдосконалення її будуть направлені на спільну користь всіх “гравців ринку”, а не на користь однієї компанії. На відміну від .NET, J2EE не потрібно купувати. Це набір специфікацій, безкоштовно доступний кожному. Купити можна готові програмні рішення на базі J2EE, інструменти для розробки, налагодження та адміністрування веб-сервісів. Платформа J2EE, заснована на технології Java, з’явилася значно раніше, ніж вищерозглянута MS .NET. За цей час вона встигла себе добре зарекомендувати серед розробників програмного забезпечення. За результатами опитування Evans Data Corp. Developer, сьогодні J2EE є платформою номер один для побудови веб-сервісів12. Популярність цієї платформи зумовлена цілою низкою факторів. Першим із таких факторів є безпека роботи Java-програм. Java-технології забезпечують досить високий рівень безпеки даних як на сервері, так і в клієнтському комп’ютері. Користувач завжди може бути спокійним відносно того, що робота з Java-програмою не матиме негативних наслідків для його комп’ютера. Будь-який програмний процес на сервері обмежений у своїх діях, тобто він не може самовільно спричинити якихось несанкціонованих дій. Розробники Java-технологій запевняють, що жодна Java-програма (або Java-аплет) не здатна допустити або пропустити порушення безпеки; ці аргументи дуже вагомі. Технологія Java є відкритою, будь-який бажаючий може завантажити й вивчати код Java-платформи. Microsoft відкриває для широкого загалу далеко не всі свої технології, що використовуються у платформі .NET. Іншим вагомим фактором, що говорить на користь J2EE, є можливість роботи з розподіленими даними, яка (про це вже говорилося вище) є дуже важливою для системи ОБС. Для роботи з розподіленими БД ефективним є використання технологій RMI та JDBC. Ці технології забезпечують весь набір необхідних інструментів для роботи з розподіленими даними та повністю підтримуються Java-програмами. Проте головною перевагою Java-технологій є незалежність від операційної платформи користувача, його апаратних можливостей, браузера, що використовується тощо. Компонент Java VM, який вимагається для виконання Java-програм, входить як обов’язковий майже в усі системи. Щоправда, Microsoft виключила Java VM із Windows XP та нових версій браузера Internet Explorer, однак можливість завантаження цього компоненту з Інтернету залишилася, тому J2EE із Windows XP також може працювати. Технології Java не потрібна потужна система. J2EE під системою Microsoft Windows буде працювати так само надійно, як і, наприклад, під системою Sun Solaris. Девіз Java “зроблено одного разу, працює всюди” сьогодні повністю себе виправдовує. Тому, якщо для розробки системи ОБС бібліотека обирає платформу J2EE, ні у розробників, ні у кінцевих користувачів не повинно виникати ніяких проблем щодо несумісності програмної та операційної платформ. Потрібно сказати і про саму мову Java, на якій будуються всі Java-технології. Мова Java - це об’єктно-орієнтована мова програмування, розроблена на основі мови C++ та призначена спеціально для створення Інтернет-програм. Те, що Java-платформа базується на мові Java, зумовлюється двома аспектами. З одного боку, мова Java давно відома багатьом програмістам і легка для сприйняття ними. Сьогодні Java - мова програмування номер один у світі13. Програма на мові Java компілюється в байт-код, який виконується під керівництвом Java Runtime Environment (JRE). Мова Java синтаксично споріднена з мовою JavaScript, без якої майже неможливо уявити більш-менш складний веб-інтерфейс, тому використання Java та JavaScript як споріднених мов програмування зробить систему ОБС достатньо потужною та легкою у використанні та адмініструванні. Але, з іншого боку, підтримувати програми, розроблені на платформі Java, можуть лише Java-програмісти (у порівнянні з платформою .NET тут явний програш). Тому, чи є цей фактор плюсом або мінусом Java-платформи, потрібно вирішувати кожній бібліотеці самостійно в залежності від наявності у її штаті Java-програмістів. До того ж, необхідно зауважити, що Microsoft розробила для платформи .NET аналог Java - мову C#. І ще один явний мінус Java-платформи: майже всі Java-технології дуже повільні, особливо це стосується віртуальної машини - JavaVM. У платформі Java акцент зроблено не на швидкодії, а на безпеці, всі алгоритми вельми надійні, проте іноді вони занадто скрупульозні. Коли ми говоримо про роботу з великими масивами інформації, фактор швидкості є одним із найважливіших, тому при виборі програмної платформи слід добре подумати, чи здатна буде система ОБС до роботи у реальному часі, якщо вона працюватиме на платформі Java.
Тут же доречно сказати і про простоту розробки веб-сервісів на .NET та на J2EE. Слід зауважити, що розробка веб-сервісів на основі технології J2EE потребує дещо більших обсягів роботи, ніж розробка сервісів на основі технології .NET. Хоча, на думку деяких аналітиків14, це не є мінусом Java-платформи, оскільки на даній стадії розвитку веб-сервісів чим такої роботи більше, тим краще.
Таким чином, ми розглянули дві найпотужніші та найскладніші платформи веб-сервісів - MS .NET та J2EE. Сьогодні ці технології є жорсткими конкурентами на ринку веб-сервісів. Погляди аналітиків із приводу лідерства цих платформ суттєво різняться між собою; якщо ж оцінювати статистику, то безперечним лідером є J2EE15. Проте боротьба триває. Якщо перемогу в цій боротьбі отримає платформа .NET, Microsoft монополізує ринок веб-сервісів подібно до того, як було монополізовано ринок операційних систем платформ Windows. Якщо ж перемогу отримає J2EE, технологія Java в черговий раз стане лідером на ринку засобів програмування для Інтернету. Проте деякі аналітики прогнозують поступову конвергенцію цих двох технологій, тому виробники програмного забезпечення намагаються зробити свої продукти придатними для обох технологій. По суті, різниця між .NET і J2EE не така велика. Здебільшого вона полягає у використанні різних методів проектування веб-сервісів. Самі веб-сервіси за структурою та функціональністю дуже схожі. Як у .NET, так і у J2EE вони використовують єдині стандарти, прийняті W3C (World Wide Web Consortium). До того ж, існують так звані “мости між .NET та Java”16 - програми, які дозволяють перенести веб-сервіс з однієї платформи на іншу. З цього випливає, що на кожній з цих платформ можна побудувати дієздатну та ефективну систему ОБС, тому остаточний вибір повинна робити кожна бібліотека самостійно. Можна приводити багато аргументів на користь одного з цих продуктів, але заперечувати доцільність використання самої технології веб-сервісів для створення системи ОБС досить важко. Підтримка веб-сервісів - це підтримка єдиних стандартів, дієвий механізм інтеграції та входження бібліотек до сучасного світового інформаційного співтовариства.
Посилання
1 Ланг К., Чоу Дж. Публикация баз данных в Интернете. - СПб: Символ-Плюс, 1998. - 480 с.
2 Мирончиков И. К., Павловцев В. А. Англо-русский толковый словарь по сети “Интернет”. - Минск: САДИ, 1997. - 76 с.
3 Там само.
4 Новые технологии в телекоммуникации: Выбор технологической архитектуры. Современные тенденции развития / под ред. С. А. Довгого. - К.: Укртелеком, 2001. - 281с.
5 Web-службы: новая парадигма интеграции? // Сетевой журнал. - 2003. - № 2.
6 Lurie J., Belanger R. J. The great debate: .Net vs. J2EE.
7 Web-службы: новая парадигма интеграции? // Сетевой журнал. - 2003. - № 2.
8 Маквитти Д. Web-сервисы и спецификация SOAP // Сети и системы связи. - 2003. - № 1. - С. 54-57.
9 Асаравала А. Нужны ли публичные Web-службы? // Сети и системы связи. - 2003. - № 4.
10 Переклад з офіційного сайту компанії “Microsoft Россия”: .NET: Платформа для интернета нового поколения.
11 Торопов Д. Платформа 2003: информатика должна понять бизнес // Windows 2000 Magazine/RE. - 2003. - № 1. - С. 2-3.
12 Lurie J., Belanger R. J. The great debate: .Net vs. J2EE.
13 За даними Evans Data Corp. на 2002 рік.
14 Див. напр.: Маквитти Д. Web-сервисы и спецификация SOAP // Сети и системы связи. - 2003. - № 1. - С. 54-57.
15 За даними Giga Information Group та ZDNet на початок 2002 року.
16 Гаврилов Е. Мосты между .Net и Java.
© Соловяненко Денис Володимирович, 2004
Національна бібліотека України імені В.І. Вернадського
www.nbuv.gov.ua