Інтерфейс
програмної компоненти та технології подання інформації в розподілених системах
6.1
Опис інтерфейсу програмної компоненти
6.1.1 Мова і схеми XML (Extensible Markup
Language)
Мова
XML нині набула низки різноманітних застосувань і є основою для великої
кількості загальноприйнятих специфікацій, які використовують у ро-зподілених
системах (зокрема у мовах XML, XSD, SOAP, WSDL) (рис. 42).
Рисунок
42 – Спеціфікації, які мають в основі XML-формат
Мова
XML –
це мова розмітки текстового документа, поданого у вигляді сукупності
іменованих, деревоподібних вкладених елементів, кожний з яких може мати деяке
текстове значення й набір атрибутів, у яких є ім’я і просте значення (рядок).
Мова XML є абстрактною мовою розмітки, яка не визначає ніякого змісту елементів
документа. Документи XML добре читає як лю-дина, так і численні програмні
аналізатори. У разі природного підходу до імен елементів і
атрибутів вона є мовою, яка самодокументується. Перед деревоподібною структурою
елементів, що мають єдиний корінь, можуть пере-бувати окремі елементи з
метаінформацією, яка свідчить, зокрема, про кодування документа й версію мови.
Основними недоліками
XML з погляду обміну повідомленнями – є незручне, через його деревоподібну
структуру, подання відносин «багато до багатьох», а також більші витрати часу
на передачу й обробку повідомлень мовою XML порівняно з двійковим
представленням аналогічних даних.
Оскільки властиве XML
відкрите подання інформації не завжди зручне з погляду безпеки, то наявні
специфікації XML-DigitalSignature і XML-Encrypton, призначені для передачі в
XML-форматі конфіденційної інформації. Перша спеціфікація дозволяє додати до
XML-документа цифровий підпис, друга – зашифрувати XML-документ або окремі його
елементи.
Однією з переваг XML є
наявність мов специфікацій, що визначають правильний XML-документ. Спочатку цю
функцію виконував DTD (Document Type Definition), однак нині загальноприйнятим
стандартом є специфікація схем XML (XML Schema Definition, XSD). Файл з описом
схеми XML визначає такі параметри: словник документа (імена елементів і
атрибутів); синтаксис коректного документа; складні типи даних.
6.1.2 SOAP: мова
повідомлень розподіленої системи
Стандартизація опису
мови XML дала широкі можливості для побудови на його основі мов опису
повідомлень, переданих між програмними компонентами, і мов опису сервісів
програмних компонент. Наприкінці 90-х років роз-почали розробляти дві
специфікації для побудови розподілених гетерогенних систем – SOAP і XML RPC.
Специфікація XML RPC підтримується нині більшою кількістю мов, але має менше
можливостей і не підтримується стандартною бібліотекою .NET Framework.
Оскільки в момент
розробки таких специфікацій протокол HTTP був най-поширенішим у міжмережних
екранах, то його було обрано як стандартний транспортний протокол для створення
гетерогенних проміжних середовищ. Хоча специфікація SOAP не прив’язана жорстко
до якого-небудь транспортного протоколу, який використовує
SOAP і WSDL, проміжне середовище названо web-службою (web services).
Web-сервіси використовують дві мови приклад-них програм – мову опису
повідомлень SOAP і мову опису сервісів й інтерфейсів WSDL.
Рекомендацію
SOAP спочатку розробляли як специфікацію для віддале-ного виклику методів і
розшифровували як Simple Object Access Protocol. Повідомлення SOAP є
XML-документом, який називають конвертом або пакетом (envelope). Цей документ
містить заголовки з метаінформацією в елементі soap:Header і тіло повідомлення
в елементі soap:Body. У заголовках пакета міститься інформація прикладної
програми, яка може використовуватися проміжним середовищем. Завдяки тому, що
основний стандарт не обмежує змісту заголовків, SOAP є розширюваною
специфікацією, і нині триває процес стандартизації її розширень.
Через
різні причини нині розрізняють два різні способи представлення інформації в
тілі пакета SOAP: кодування SOAP RPC (у двох варіантах) і кодування SOAP
Document. Кодування SOAP RPC призначено винятково для передачі параметрів
віддаленого виклику й визначає повідомлення як ім’я методу і список параметрів.
У разі використання кодування SOAP Document, що є нині фактичним стандартом,
повідомлення являє собою XML-документ, який має схему і простір імен, які
задано в описі сервісу мовою WSDL (Web Service Definition Language). Зазвичай
повідомлення складається з імені методу віддаленого об’єкта і списку його
параметрів, сама специфікація кодування ніяк не фіксує його змісту.
Опис
типів переданих даних за специфікацією SOAP Document містить схему XML, яка
визначає коректні повідомлення, що отримуються програм-ним компонентом у тілі
пакета SOAP, та включає такі параметри:
·
опис вхідних і вихідних
повідомлень, які зв’язуються з описаними типами даних;
·
опис операцій (сервісів
програмної компоненти), з кожною з яких зв’язується вхідне й вихідне повідомлення;
·
опис типів портів
(ідентифікаторів програмних компонент), з кожним з яких зв’язується деякий
набір операцій;
·
опис прив’язок (binding), що
зв’язують типи портів і їх повідомлень з певним типом кодування тіла пакета, а
також із версією протоколу SOAP;
·
опис портів, що зв’язують типи
портів і відповідні прив’язки з конкретними URL;
·
загальний опис служби
(інтерфейсу програмної компоненти) як сукупності портів.
6.1.3 WSDL: опис інтерфейсу програмної компоненти
Для опису інтерфейсу програмної компоненти,
включаючи специфікацію коректних повідомлень, було розроблено мову WSDL. Опис
мовою WSDL містить сім складових
(рис. 43).
6.1.4 Серіалізація
об’єктів .NET
Framework
На
відміну від прикладних програм на некерованому коді, прикладна програма .NET
Framework не обов’язково виконується у вигляді окремих процесів, а може
перебувати в межах одного процесу операційної системи у власних областях –
доменах прикладної програми, які можна розглядати як деякі логічні процеси
віртуальної машини Common Language Runtime (CLR).
Рисунок
43 – Складові WSDL-документа
Використання керованого коду за таких умов
дозволяє гарантувати ізоляцію прикладної програми у межах своїх областей. У
процесі передачі повідомлення між доменами прикладної програми деякого об’єкта
для його класу слід визначати такі параметри: процедуру серіалізації, що
дозволяє зберегти стан об’єкта в деякому зовнішньому сховищі (наприклад, у
файлі або в повідомленні транспортного протоколу) за допомогою потоків
введення-виведення; процедуру десеріалізації, що створює копію об’єкта за
збереженим станом (рис. 44).
Рисунок
44 – Серіалізація й десеріалізація
об’єкта
Слід
зазначити, що загалом такі об’єкти можуть бути об’єктами різних класів і навіть
створеними в різних системах розробки прикладних програм. Завдання серіалізації
об’єкта, який містить лише поля з елементарних типів значень (спадкоємців класу
System.ValueType) і рядків, не становить принципових труднощів. Для
такого об’єкта у процесі серіалізації в потік записують самі значення всіх
полів об’єкта, однак загалом об’єкт містить посилання на інші об’єкти, які, у
свою чергу, можуть посилатися один на одного, утворюючи граф об’єктів (object
graph). Самі посилання не можуть зберігатися в потоці введення-виведення,
тому основне питання серіалізації – у який спосіб заміняти посилання.
Граф
об’єктів – орієнтований граф G = < V, E >, у якому вершини – це
об’єкти (множина V), а ребра направлені від об’єктів, що містять
посилання, до об’єктів, на які посилаються
(рис. 45). Усі об’єкти, які розглядаються у процесах серіалізації або
десеріалізації описують у термінах об’єктно-орієнтованого підходу. В такому
разі об’єкти, властивості яких наслідують інші об’єкти, є батьками, а об’єкти,
які наслідують властивості батьків, є дітьми.
Наявність
посилання на об’єкт B у об’єкті A є приналежністю пари <A,B>
множині E. У графі всі поля об’єктів, які належать до простих типів
значень і рядків, можна вилучити з розгляду в силу тривіальності їх
серіалізації. Хоча формально рядки є посилальними типами, обмеженням реалізації
рядків у CLI є те, що немає можливості змінити вже створений рядок, але є
можливість тривіально обробляти рядки під час серіалізації, зберігаючи в потоці
їх вміст.
Рисунок
45 – Граф об’єктів
Існує окремий випадок,
коли серіалізація виконується тривіально, у такому разі граф повинен мати
вигляд орієнтованого дерева. У кожну вершину дерева, відмінну від кореня,
направлене єдине ребро, існує єдина вершина, у яку не направлене жодне ребро, –
корінь. За таких умов серіалізація може виконуватися від кореня методом у
глибину, серіалізація полів-посилань функціонує аналогічно до серіалізації
полів-значень. Якщо виявлено посилання на об’єкт, то замість нього у сховище
розміщують значення полів об’єкта, на який поси-лаються, і деяку інформацію
прикладної програми щодо типу об’єкта. Наприклад, якщо наявні ребра <A, B1>,
... <A, Bn>, то функцію серіалізації S для
об’єкта A можна подати як S(A) = <V(A), <S(B1), ...
S(Bn)>>, де функція V – значення полів-значень і
рядків цього об’єкта.
Проблема серіалізації
графу об’єктів полягає в тому, що посилання на той самий об’єкт може бути
значенням поля різних об’єктів (наявні ребра <A1, B> і
<A2, B>). Можлива також наявність циклів у вигляді
A 
... 
A.
У
цьому разі у процесі серіалізації об’єктам
мають відповідати деякі ідентифікатори, й у сховищі окремо зберігається список
об’єктів, позначений ідентифікаторами, а під час серіалізації замість посилань
записують ідентифікатори об’єктів, на які посилаються. Якщо A1,
... An – всі вершини графа, то після
серіалізації утвориться множина {<id1, S(A1)>,
... <idAn, S(An)>}, де S(A) = < V(A),
<id1, ... idBn> > , а B1,
... Bn – об’єкти, посилання на які безпосе-редньо
міститься в об’єкті А. У програмі роль ідентифікатора об’єкта виконує
його адреса, але замість неї зручніше обрати деякі ідентифікатори у процедурі
серіалізації для більш легкого читання людиною отриманого образу. Під час
серіалізації потрібно включити список адрес уже записаних об’єктів як для
ведення списку ідентифікаторів, так і для виявлення можливих циклів у разі
обходу графу методом у глибину.
Слід зазначити, що
результат серіалізації дерева легко подати у вигляді XML, коли вміст кожного
об’єкта є одним елементом з деяким набором атрибутів і вкладених елементів,
тому, розглядаючи проблему серіалізації, можна сформулювати рекомендацію, щоб
класи, передані між віддаленими компонентами, були коренем дерева об’єктів.
Зокрема це дерево може бути навіть виродженим, тобто клас не містить
полів-посилань взагалі.
6.2
Базові технології подання інформації в розподілених системах
6.2.1. Вимоги до прикладних програм серверної
сторони
Розглядаючи
платформи для створення прикладних програм серверної сторони, необхідно
виокремити такі основні підходи: безпосередня обробка запитів і формування
відповідей; вбудовування програмного коду в шаблони HTML-сторінок.
Перший
підхід надає найбільші можливості з керування обробкою і підвищенням
продуктивності, оскільки він передбачає передачу всіх даних про запит
безпосередньо виконуваного коду, який може як сформувати відповідь зі сторінкою
для користувача, так і відкрити процес передачі потоку бітів, наприклад для
передачі зображення. Однак за такого підходу всі дані для передачі формуються
програмно, що уповільнює розробку простих сторінок і ускладнює взаємодію між
розробником дизайну сторінки і програмістом. Прикладами цього підходу є
технології CGI (Common Gateway Interface), Java Servlets.
Другий
підхід використовує шаблони сторінок користувача, оформлені таким чином, щоб
дозволити вставляти в них ділянки програмного коду. Цей підхід особливо
ефективний під час створення простих прикладних програм, основна інформація в
яких статична, а динамічна інформація може бути ге-нерована простими
програмними конструкціями. У процесі розробки склад-них програмних систем цей
варіант ускладнює взаємодію між компонентами і реалізацію складної архітектури,
а також він менш ефективний за продукти-вністю й обмежує можливості з
реалізації складних сторінок. Прикладами цього підходу є найпоширеніші нині
технології Personal Home Page (PHP), Active Server Pages (ASP), Java Server
Pages (JSP).
Крім різних підходів до
генерації сторінок сучасні платформи розробки складних Web-систем мають
задовольняти вимогам, дотримання яких робить систему зручною у використанні:
·
платформна незалежність;
·
мова реалізації;
·
продуктивність;
·
масштабованість;
·
можливість розширення й
інтеграції;
·
простота використання,
наявність засобів розробки;
·
наявність необхідних
програмних бібліотек.
Розглянемо найбільш
популярні нині платформи, їх особливості, а також оцінку з погляду наведених
критеріїв.
6.2.2 Огляд базових технологій
Нині є безліч
розроблених технологій серверної сторони, як комерційних, так і вільно
поширюваних.
Платформи розглядаємо з
погляду побудови на них складних гетерогенних Web-систем, тому деякі з
популярних технологій не наводимо в детальному огляді через неможливість або
недоцільність їх використання як базової платформи. Наприклад, технологія ISAPI
та інші технології, які розширюють можливості Web-серверів, не підходять для
застосування внаслідок прив’язки до конкретного
Web-сервера. Наведемо тільки основні технології, потенційно здатні створити
складні гетерогенні Web-системи.
Технологія Common
Gateway Interface. Технологія CGI вирізняється серед
інших розглянутих технологій тим, що є найбільш низькорівневим стандартом
інтерфейсу, який забезпечує зв’язок зовнішньої програми з web-сервером.
Сам протокол розроблено
таким чином, щоб можна було використовувати будь-яку мову програмування та
працювати зі стандартними пристроями введення/виведення. Оскільки така
можливість надається на рівні операційної системи, то використовують або
скрипт, написаний на відповідною мовою програмування, або простіше його подання
- командний файл.
Розглянемо основні
переваги та недоліки технології CGI за окремими критеріями:
·
технологія CGI не передбачає
особливих обмежень для використання платформи та web-сервера, тому працює на
всіх популярних платформах і web-серверах, а також технологія не прив’язана до
конкретної мови програмування й може бути використана будь-якою мовою, що
працює зі стандартними потоками введення/виведення;
·
продуктивність CGI-програм
невисока, основною причиною чого є те, що у разі чергового звертання до сервера
для роботи CGI-програми створюється окремий процес, який вимагає великої
кількості системних ресурсів;
·
технологія не передбачає
вбудованих засобів масштабованості, це потребує додаткового доопрацювання
програмного забезпечення розробниками;
·
CGI-програма являє собою
готовий до виконання файл, що перешкоджає легкому розширенню системи.
Із зазначених причин на
сьогодні віддають перевагу більш розвиненим платформам, які надають більше
зручності розробникам та мають підвищену продуктивність. Однак велика кількість
уже розробленого програмного забезпечення змушує розвивати й використовувати
технологію CGI, потрібну для розуміння принципів роботи високорівневих
платформ.
Технологія Personal
Home Page. Технологія PHP набула значного поширення
завдяки своїй безкоштовності й підтримання найбільш популярних платформ,
оскільки грунтується на принципі побудови сторінок із шаблонів, який вперше
запропоновано в технології ASP. Технологія PHP розвиває і доповнює цей принцип.
Сторінки РНР мають вигляд звичайних HTML-сторінок, у яких можуть
використовуватися спеціальні теги <? Php і?>, між якими
вставляються рядки програмного коду спеціальною мовою сценаріїв РНР.
Принцип
шаблонів дозволив розробникам писати програми набагато швидше і без помилок,
властивих традиційним CGI-програмам, які пересилають HTML-вміст у потік
виведення. На сьогодні низка систем, побудова-них на шаблонах, містить як
прості сторінки з вибірками з бази даних, так і великі прикладні програми
електронної комерції, в основі яких лежить мова XML. Системи з використанням
шаблонів мають велику популярність, оскільки найбільше підходять для типових
сайтів. Такі рішення розробляються за допомогою технологій ColdFusion, PHP, JSP
і ASP, з яких РНР є найбільш поширеною.
Розглянемо основні переваги та недоліки
платформи:
·
застосовувана в РНР мова
проста і зручна, однак не є, в повному розумінні, об’єктно-орієнтованою;
·
для РНР наявні великі бібліотеки,
а також безліч вбудованих функцій для вирішення найрізноманітніших завдань;
·
у разі використання РНР з
Web-сервером Apache є можливість ефективного виконання ядра як розширення
сервера, інакше продуктивність платформи невисока;
·
власних засобів масштабування
РНР не має, всі можливості з кластеризації цілком покладено на Web-сервер;
·
можливості інтеграції обмежені
наявністю лише функцій включення модулів і використання зовнішніх функцій, що
не відповідає сучасним вимогам;
·
підхід РНР, в основу якого
покладено шаблони, за умови наявності значних переваг разом з тим має і
серйозні недоліки.
Із
загальних недоліків цього підходу, застосовуваних як до РНР, так і ASP, JSP
необхідно звернути увагу на такі:
·
файл-сторінку може
підтримувати тільки людина, яка добре володіє як мовами програмування, так і
мовою HTML, що вимагає підвищеної кваліфікації;
·
один файл у конкретний момент
часу може правити лише одна людина. Це означає, що працює або програміст, або
дизайнер, тобто неможливий розподіл праці між групою фахівців;
·
зберігання бізнес-логіки у
файлах–сторінках у розподіленому між керівними елементами вигляді ускладнює її
винесення в об’єкти другого рівня.
Таким чином, завдяки
простоті використання, наявності великої кількості функцій і бібліотек, поширеності
й підтримки більшості наявних Web-серверів і платформ, РНР є дуже зручним
засобом розробки невеликих систем.
У той же час, обмеження щодо продуктивності, масштабованості,
неповноти як мови програмування, а також можливостей розширення та інтеграції
перешкоджають використанню платформи для розробки масштабних систем.
Технологія Java
Servlets. Технологію Java Servlets (сервлети) було
роз-роблено компанією Sun Microsystems, щоб використовувати переваги плат-форми
Java для розв’язання проблем технології CGI та API-розширень сервера, зокрема
проблеми продуктивності, виконуючи всі запити як нитки в одному процесі.
Сервлети також можуть легко розділяти ресурси і не залежать від платформи,
оскільки виконуються всередині Java Virtual Machine (JVM).
Технологія має широкі
функціональні можливості, оскільки велика кіль-кість бібліотек надає
найрізноманітніші засоби, необхідні під час розробки. Модель безпеки Java
уможливлює точне керування рівнем доступу, наприклад дозволяючи доступ тільки
до певної частини файлової системи. Завдяки обробці винятків Java-сервлети
стають більш надійним засобом, ніж розширення серверів на мовах програмування
C/C#.
Будь-який
сервлет є класом Java, тому має бути виконаний усередині JVM
сервлет-контейнером (servlet container, servlet engine), який
завантажує клас сервлета під час першого звертання до нього або відразу
в момент запуску сервера за спеціальною вказівкою. Далі
сервлет залишається завантаженим для обробки запитів, поки він не
вивантажується явно, або до зупинення контейнера.
Технологія
є поширеною і може бути використана для створення програмного забезпечення, яке
працює з усіма популярними Web-серверами (Enterprise Server від Netscape,
Microsoft Internet Information Server (IIS), Apache, Java Web-сервер від Sun).
Програмний
інтерфейс дозволяє сервлетам обробляти запити на будь-якому рівні, у разі
потреби використовуючи низькорівневі дані, такі як заголовки запитів, їх тип,
що надає великої гнучкості під час розробки нестандартних обробників, наприклад
для роботи з двійковим або мультимедійним вмістом.
Оскільки
сервлети обробляють в одному процесі за рахунок створення потоків усередині,
програмний код сервлетів, який міститься у потоці, має бути безпечним. Це
накладає певну відповідальність на програміста, але за допомогою стандартних
прийомів, таких як відмова від використання полів у класах сервлетів і
зберігання необхідних даних у контексті або зовнішньому сховищі, такі
властивості коду легко досягаються. За таких умов сервлети набувають таку
перевагу, як масштабованість.
Отже,
сервлети забезпечують компонентний, платформо-незалежний метод для побудови
web-орієнтованого прикладного програмного забезпечення, яке не має обмежень
продуктивності CGI-програм. Вони мають широкий діапазон доступних прикладних
API, дозволяють використовувати всі переваги Java, легко розширюються і
масштабуються, підтримуються всіма популярними Web-серверами. Все це робить їх
засобом розробки великих Web-систем.
Технологія
Java Server Pages. Технологія JSP від компанії Sun Microsystems стала
надбудовою над технологією Java Servlets та забезпечує більш швидку і просту
розробку web-прикладних програм за рахунок застосування підходу, який
використовує шаблони програмування.
Для
розуміння архітектури і переваг JSP необхідно знати технологію Java Servlets,
оскільки вони тісно пов’язані. Сторінки JSP являють собою шаблони сторінок
HTML, аналогічні шаблонам РНР і ASP. Основною відмінністю від інших подібних
технологій є те, що код, який міститься всередині спеціальних тегів, не
інтерпретується під час звертання до сторінки, попередньо
компілюється в Java Servlet. Статичні ділянки шаблона перетворюються на виклики
до функцій для їх розміщення в потік виведення. Код компілюється так, неначе
він міститься всередині сервлета. Компіляція JSP сторінок у сервлети є
трудомісткою, але виконується одноразово або під час першого звертання до
сторінки, або у процесі запуску сервлет-контейнера.
Технологія JSP вдало
поєднує підхід з використанням шаблонів до побудови сайтів і всі переваги
Java-платформи, завдяки чому набула значного поширення як для створення
професійних комерційних розробок, так і для відкритих безкоштовних проектів.
Важливим кроком до розширення підходу з використанням шаблонів стали бібліотеки
тегів (tag libraries), які створили можливість інтегрувати стандартні, сторонні
або власні програмні компоненти у сторінки. Простота створення та використання
зумовила популярність бібліотек тегів.
Завдяки роботі на
основі Java технологія JSP не прив’язана до конкретної апаратної або програмної
платформи, тому JSP є зручним рішенням для використання в гетерогенних
середовищах.
Продуктивність
технології обмежена такими об’єктивними особливостями архітектури: по-перше,
сторінки мають бути відкомпільованими в сервлети, що потребує багато часу;
по-друге, сервлети виконуються в середовищі Java, тобто в режимі інтерпретації.
Однак ці обмеження
компенсуються додатковими можливостями, оскільки сучасні контейнери підтримують
кластеризацію серверів, то навантаження перекладається на апаратне
забезпечення. Це є економічно виправданим і простим рішенням. Завдання
компіляції в сервлети є одноразовим та виконується або під час першого
звертання, або у процесі запуску сервлет-контейнера, тому не позначається на
загальній продуктивності системи у разі розгляду за достатній період.
Основними перевагами
JSP є простота програмування, характерна для підходу з використанням шаблонів,
наявність великої кількості сторонніх бібліотек, легкість їх застосування,
потужні й різноманітні середовища розробки. Завдяки цим факторам JSP є найбільш
перспективною базовою технологією розробки у процесі створення Web-сайтів.
Однак у разі створення складних Web-систем обмеження, які
накладаються підходом з використанням шаблонів, стають серйозною перешкодою для
розвитку цієї технології.
Технологія
Microsoft.NET і середовище ASP.NET. Технологія .NET є
новітньою розробкою компанії Microsoft і позиціонується як новий етап у
розвитку засобів взаємодії між прикладними програмами. Нині вона доступна як
доповнення .NET Framework до сімейства операційних систем Microsoft Windows, у
продуктах Windows Server, а також ведуться роботи зі створення .NET Framework
для інших операційних систем. Платформа .NET спрощує розробку прикладних
програм і підвищує надійність коду, зокрема забезпечує автоматичне керування
часом життя об’єктів, незалежні від мов програмування бібліотеки класів,
обробку винятків і налагодження.
Основа
.NET – середовище CLR (загальне середовище виконання мов) спирається на
системні служби операційної системи і керує виконанням коду, написаного
будь-якою сучасною мовою програмування. Набір базових класів надає доступ до
сервісів платформи, які розробники можуть використовувати будь-якою мовою
програмування. Середовище CLR і базові класи разом становлять основу .NET
платформи, яка пропонує такі високорівневі сервіси:
·
ADO.NET – нове покоління ADO,
яке використовує XML і SOAP для обміну даними;
·
ASP.NET – нова версія ASP, що
дозволяє використовувати будь-яку (.NET сумісну) мову для програмування
Web-сторінок;
·
Windows Forms і Web Forms –
набір класів для побудови користуваць-кого інтерфейсу локальних та
Web-орієнтованих прикладних програм.
Розгортання
систем на платформі .NET здійснюється особливим чином; вихідні коди
компілюються не в команди процесора х86 або інші машинні коди, замість цього
компілятор створює код мовою проміжного шару програмного забезпечення,
запропонованою Microsoft (Microsoft Intermediate Language – MSIL). Файл, що
містить MSIL, може виконуватися на платформі будь-якого процесора, якщо
операційна система має у складі .NET CLR.
Важливою складовою
частиною платформи .NET є нове середовище ASP.NET. Можливості ASP.NET значно
розширено, в його основі лежить інша платформа, і базовими мовами програмування
для неї обрано С# і Visual Basic, замість колишніх
скриптових мов. У той же час, нова технологія дозволяє писати ASP-сторінки
будь-якою відповідною мовою.
В ASP.NET закладено все для того,
щоб зробити весь цикл розробки web-орієнтованих програм швидшим, а підтримку
простішою. Основні можливості й принципи роботи ASP.NET такі:
·
компілювання коду під час
першого звертання;
·
широкий вибір бібліотек
компонентів, що постачаються з .NET;
·
підтримка потужного засобу
розробки – Visual Studio .NET;
·
мовна незалежність у межах
платформ, для яких реалізовано загальне мовне середовище виконання программ –
CLR;
·
можливості розширення за
допомогою мультипроцесорних і кластер-них рішень;
·
нові можливості з обробки
помилок;
·
об’єктно-орієнтовані мови
розробки (нова мова С#);
·
розширені можливості
повторного використання компонент.
Очевидно,
що платформи .NET і ASP.NET надали нових можливостей для розробки Web-систем,
задовольняють усім сучасним вимогам й дозволя-ють значно прискорити і спростити
розробку складних прикладних програм. Однак на сьогодні .NET у повному обсязі
наявне тільки для платформи Windows, а його перенесення на інші системи
перебуває на стадії розробки, але ще не завершено, і майбутні результати
оцінити важко. Оскільки ASP.NET сильно прив’язана до сервера IIS, хоча
архітектура .NET дозволяє перенести прикладну програму ASP.NET на іншу
платформу, нині реальної можливості розробляти сайти як кросплатформні рішення
немає. Таким чином, найважливіша вимога до Web-орієнтованого програмного
забезпечення – багатоплатформність поки що не може бути виконана платформою
.NET, тобто її використання для створення Web-системи не завжди виправдано.
Однак слід відзначити, що Web-система має інтегруватися з платформою. NET
(передусім з Web-сервісами), оскільки її широке використання у майбутньому не
викликає сумнівів.
Порівняння
технологій. Розгляд найбільш популярних базових технологій
побудови прикладних програм серверної сторони дозволяє назвати такі основні
особливості їх архітектури:
·
окреме виконання запитів,
тобто під час кожного запиту динамічного вмісту запускається певна програма для
його обробки, яка генерує вміст, що передається клієнтові,- цей підхід
використовується у класичних CGI-скриптах;
·
накопичення виконуваних
процесів – підхід, аналогічний попередньо-му, але, якщо запит виконується
повторно, нового запуску програми не відбувається, а обробка передається
існуючому процесу,- такий підхід застосовують в технологіях Java Servlets, Fast
CGI;
·
шаблони сторінок, тобто під
час запиту шаблони заповнюються динамічним вмістом, але необов’язково, вміст
інтерпретується мовою сценаріїв, цей підхід застосовують в технологіях ASP,
JSP, PHP;
·
розширення Web-сервера,- який
звертається до особливих розширень для опрацювання динамічного вмісту, причому
ці розширення специфічні для Web-сервера, цей підхід використовують в ISAPI,
NSAPI, mod_perl.
Кожен із зазначених
підходів має свої переваги та недоліки і, відповідно, свою сферу застосування.
Модель окремого виконання запитів істотно обмежує продуктивність. Варіант
моделі з накопиченням процесів є розвитком технології побудови Web-орієнтованих
прикладних програм, підвищує продуктивність, зберігаючи при цьому максимальну
гнучкість розробки. Підхід, який використовує шаблони, надзвичайно зручний у
разі розробки невеликих систем, однак зі збільшенням складності він починає
гальмувати, тому процес розробки не підходить для великих систем. Він також
вирізняється невисокою продуктивністю, хоча дослідження показують, що за певних
умов може демонструвати досить високі показники і конкурувати з іншими
підходами. Розширення Web-сервера не є найзручнішим засобом розробки, оскільки
не-обхідно буде жорстко прив’язувати систему до певного Web-сервера, але
система при цьому демонструє максимальну продуктивність і дає найбільшу
гнучкість у процесі розробки прикладних сервісів.
За схемою обробки
запитів платформи поділяють таким чином (технологію CGI не розглядається через
незручність у використанні, низьку ефективність і те, що розширення серверів
занадто сильно прив’язані до конкретних програмних продуктів):
·
РНР-шаблони, під час виконання
на Web-сервері Apache використовують як розширення сервера інтерпретатор (в
експериментальному режимі можна також застосовувати сервер IIS);
·
Java Servlets – накопичення
процесів для кожного сервлета;
·
JSP-шаблони – у процесі
обробки виконується їх предкомпіляція в Java Servlets, що дозволяє
використовувати схему накопичення процесів;
·
ASP.NET шаблони -
використовується схема попередньої компіляції, а не інтерпретації коду, для
цього необхідною є наявність розширення Web-сервера IIS, також можна
застосовувати і низькорівневі обробники.
Порівняльну оцінку
основних характеристик платформ (табл. 2), у якій «–» – немає підтримки; «–/+»
– недостатня підтримка; «+/–» – підтримка не в повному обсязі; «+» – повна
підтримка. Для порівняльних характеристик, таких як мова реалізації або
продуктивність, оцінки відповідають ступеню переваги технології.
Таблиця 2 –
Порівняльна
оцінка основних характеристик платформ
|
|
РНР |
Java
Servlets |
JSP |
ASP
.NET |
|
Багатоплатформність |
+/– |
+ |
+ |
–/+ |
|
Продуктивність |
–/+ |
+/– |
+/– |
+ |
|
Масштабованість |
– |
+ |
+ |
+ |
|
Мова реалізації |
+/– |
+ |
+ |
+ |
|
Можливості розширення й інтеграції |
– |
+ |
+/– |
+ |
|
Простота використання, наявність засобів розробки |
+/– |
+/– |
+ |
+ |
|
Наявність необхідних програмних бібліотек |
+ |
+ |
+ |
+ |
|
Поділ дизайну і логіки |
+/– |
–/+ |
+/– |
+ |
|
Засоби
візуальної розробки |
–/+ |
+/– |
+ |
+ |
|
Можливість побудови компонентної архітектури |
– |
+ |
+/– |
+ |
