Моделі оцінки якості семантичного стану та надійності веб сервісів (ID:150118)

ВСТУП Актуальність. За останні роки сервіс-орієнтована архітектура стала однією з найбільш розповсюджених ІТ-сфер, фактично стандартом для взаємодії різних додатків. Веб-сервіси в даний час широко використовуються в розробці численних додатків бізнес-критичного застосування, серед яких слід особливо відзначити Інтернет-банкінг, онлайн-магазини, системи резервування і продажу туристичних послуг, системи електронного бізнесу та електронної науки. Сучасний план розробки та впровадження відмовостійких архітектур відображає нові виклики в сфері моделювання та оцінки якості та надійності: - у відмовостійких сервісах зростає число станів, в яких може перебувати система внаслідок відмов, обумовлених фізичними дефектами апаратного забезпечення, дефектами проектування програмного забезпечення і дефектами взаємодії Web-сервісів внаслідок різних атак; - для оцінки якості функціонування сервісів слід враховувати задоволення користувачів інформаційним наповненням сторінок ресурсу. Питаннями розвитку методів та моделей оцінювання якості інформаційних ресурсів упродовж останніх десятиліть активно займалися І. Ашманов, А. Іванов [7], Н. Нєєлова [8], Э. Энж, С. Спенсер [9]. Питаннями розвитку теорії відмовостійких систем, методів оцінювання і забезпечення безвідмовності та готовності сервісів впродовж останніх десятиліть активно займалися А. Авіженіс, Ж.-К. Лапрі, Б. Рендел [5], К. Тріведі [10], А. Боярчук [11-13]. При цьому основна увага приділялася узагальненим та спрощеним моделям видимості сайту у пошуковій системі та моделям функціонування апаратної компоненти Web-сервісів з урахуванням заходів відновлення і техобслуговування. Об’єкт дослідження – процеси розробки і супроводу Web-сервісів та їх інформаційних сторінок. Предмет дослідження – моделі оцінки якості семантичного стану та надійності Web-сервісів. Мета й задачі дослідження. Метою дипломної роботи є підвищення точності оцінювання якості функціонування Web-сервісу шляхом врахування семантичного стану його інформаційних сторінок та його надійності. Для досягнення поставленої мети вирішуються такі задачі: – аналіз існуючих методів і засобів розробки, оцінки та забезпечення якості Web-сервісів; – розробка методу оцінки семантичного стану Web-сервісу; – розробка і дослідження марковської моделі надійності Web-сервісу. Методи дослідження. Проведені в роботі дослідження базуються на методах теорії множин і комбінаторного аналізу, теорії ймовірності, системного і марковського аналізу, систем і мереж масового обслуговування, які використовувалися при розробці ймовірнісних моделей оцінки семантичного стану та марковських моделей оцінки надійності Web-сервісів. Наукова та практична значущість роботи засвідчується тим, що удосконалено методи оцінювання показників якості Web-сервісу шляхом врахування семантичного стану його інформаційних сторінок та надійності при проведенні профілактик прихованих відмов. Апробація роботи виконана на четвертій міжнародній науково-технічній конференції «Проблеми інформатизації». Робота складається з переліку умовних позначень; вступу; трьох розділів; висновків; списку використаних джерел; трьох додатків. РОЗДІЛ 1 АНАЛІЗ ІСНУЮЧИХ МЕТОДІВ І ЗАСОБІВ РОЗРОБКИ, ОЦІНКИ ТА ЗАБЕЗПЕЧЕННЯ ЯКОСТІ WEB-СЕРВІСІВ 1.1. Архітектури та технології розробки сучасних Web-систем 1.1.1. Вимоги до технічних характеристик Web-сервісів У парадигмі сервіс-орієнтованого комп'ютингу (service-oriented computing, SOC) [1] сервіси використовуються для підтримки розробки швидкодіючих, маловитратних, інтероперабельних, еволюціонуючих і розподілених додатків. Вони виконують різні функції: від відповідей на прості запити до виконання складних бізнес-процесів, для яких потрібні взаємозв'язки між різними рівнями споживачів і постачальників сервісів. Ключем до розуміння цієї концепції є сервіс-орієнтована архітектура (service-oriented architecture, SOA). Вона виступає як логічний засіб розробки програмних систем для надання сервісам додатків, орієнтованих на кінцевих користувачів, або інших сервісів, розподілених в мережі, шляхом публікації і виявлення інтерфейсів [2]. SOA забезпечує клієнтські організації гнучкою інфраструктурою і середовищем обробки за рахунок підтримки у вигляді сервісів незалежних, повторно використовуваних прикладних функцій і надання надійної основи для використання цих сервісів. В даний час найбільш перспективною технологією, що використовує парадигму SOA, є Web-сервіси. Під Web-сервісами розуміється клієнт-серверна технологія, що дозволяє додаткам взаємодіяти один з одним незалежно від платформи і мови програмування, на якій вони написані [3]. Фактично Web-сервіс являє собою набір інтерфейсів, що описують деякий набір функцій. Ці функції викликаються віддалено по мережі та використовують стандартизовані XML повідомлення. У цій технології Інтернет виступає в якості комунікаційного середовища, для передачі даних застосовується протокол SOAP (Simple Object Access Protocol), для визначення сервісів - мова WSDL (Web Services Description Language), і для їх адміністрування - мова BPEL4WS (Business Process Execution Language for Web Services). 1.1.2. Аналіз архітектури Web-систем Додатки Web-сервісів проектуються і розробляються з використанням трьох технологій (рис1.1) – мови опису Web-сервісів (Web Service Description Language, WSDL), протоколу простого доступу до об'єктів (Simple Object Access Protocol, SOAP) і специфікації універсального опису, дослідження і інтеграції (Universal Description , Discovery and Integration - UDDI). Рис.1.1. Схема взаємодії постачальника сервісу, споживача сервісу та реєстру сервісів SOAP - це стандарт для відсилання та отримання повідомлень по Internet [4]. Спочатку даний протокол був запропонований фірмою Microsoft в якості засобу для віддаленого виклику процедур (RPC, Remote Procedure Call) по протоколу HTTP, а специфікація SOAP 1.0 (Userland, Microsoft, Developmentor) була тісно пов'язана з Component Object Model. Специфікація SOAP визначає XML-«конверт» для передачі повідомлень, метод для кодування програмних структур даних в форматі XML, а також засоби зв'язку по протоколу HTTP. SOAP-повідомлення бувають двох типів: запит (Request) і відповідь (Response). Якщо запит викликає метод віддаленого об'єкта, то відповідь повертає результат виконання даного методу. Специфікація SOAP визначає формат кодування і спосіб представлення даних в XML-форматі. Для того щоб програми могли використовувати Web-сервіси, програмні інтерфейси останніх повинні бути детально описані - з цієї точки зору мова WSDL відіграє ту ж роль, що і мова Interface Definition Language (IDL) в розподілених обчисленнях. Опис може включати таку інформацію, як протокол, адреса сервера, номер використовуваного порту, список доступних операцій, формат запиту і відповіді і т.п. Для опису даної інформації було запропоновано кілька мов. Однією з них є мова Service Description Language (SDL), що входить в першу версію Microsoft SOAP Toolkit. Коли компанія IBM переробила специфікацію і, використавши специфікацію Network Accessible Service Specification Language (NASSL), випустила NASSL Toolkit як частину SOAP4J. Ідеї, реалізовані в NASSL, вплинули на специфікацію мови SOAP Contract Language (SCL), запропоновану Microsoft. В даний час обидві специфікації (NASSL і SDL/SCL), а також пропозиції інших фірм враховані в специфікації мови WSDL. Завдання UDDI - надати механізм для виявлення Web-сервісів. UDDI задає бізнес-реєстр, в якому провайдери Web-сервісів можуть реєструвати сервіси, а розробники - шукати необхідні їм послуги. Компанії IBM, Microsoft і Ariba створили власні UDDI-реєстри, в одному з яких розробники можуть зареєструвати свої Web-сервіси, після чого дані автоматично реплікуються в інші реєстри. Мова BPEL задає модель і граматику опису поведінки бізнес-процесів на основі взаємодії процесу (координатора) та його партнерів. Взаємодія з кожним партнером здійснюється за допомогою Web-сервісів. Процес, визначений у BPEL4WS, складається з наступних компонентів: - дій, які є окремими бізнес-етапами всередині процесу; - посилань на партнерів, що визначають зовнішні сутності, взаємодіючі з певним процесом чи, навпаки, використовують WSDL-інтерфейси; - змінних, що зберігають повідомлення, що передаються між діями, і, отже, представляють стан; - кореляційних наборів, що використовуються для кореляції кількох повідомлень запитів сервісу і відповідей з одним екземпляром бізнес-процесу; - обробників несправностей, що займаються винятковими ситуаціями, які можуть виникнути під час роботи бізнес-процесу; - обробників подій, які приймають і обробляють повідомлення паралельно зі звичайним виконанням процесу; - коригувальних обробників, що представляють логіку корекції для відкату дії або декількох дій при виникненні виняткової ситуації [5]. 1.1.3. Аналіз інструментальних засобів розробки Web-сервісів Серед множини комерційних програмних продуктів, що використовуються для розробки Web-сервісів, доцільно провести короткий огляд інструментальних засобів Borland, HP, IBM, Microsoft, Oracle і Sun. Фірму Borland можна назвати піонером в області розробки засобів створення Web-сервісів для різних платформ. Для розгортання додатків Borland пропонує Borland e-business platform - основу для створення повноцінної інформаційної інфраструктури сучасного підприємства. До цієї категорії можна віднести такі продукти, як Borland Enterprise Server (перший інтегрований комплекс засобів на основі новітніх промислових стандартів CORBA 2.4 і J2EE 1.3), Borland Enterprise Server AppServer Edition (дозволяє розробникам сконцентрувати свої зусилля на створенні прикладної логіки у вигляді компонентів EJB (Enterprise JavaBeans)), Borland Enterprise Server Web Edition (включає вдосконалені Web-сервер Apache і Web-контейнер Tomcat), Borland InterBase 6 (SQL-сервер баз даних, який характеризується простотою використання, мінімальними витратами на супровід для систем корпоративного рівня). Власну нішу на ринку засобів створення Web-сервісів займає Hewlett Packard - компанія, що володіє апаратними платформами для виконання Web-сервісів і програмними платформами для їх впровадження і адміністрування. Для розробки Web-сервісів пропонується використання засобу HP Service Composer. Цей засіб має графічний інтерфейс для створення WSDL-інтерфейсів для Java-об'єктів і підтримує автоматичне впровадження Web-сервісів на сервер додатків HP Application Server. З множини продуктів фірми IBM можна виділити дві лінійки, що представляють інтерес для розробників Web-сервісів: сімейство продуктів WebSphere Studio і сімейство продуктів Web Sphere Application Server. В якості платформи для Web-сервісів Microsoft пропонує .NET Framework і набір корпоративних серверних додатків (сімейство .NET Enterprise Servers). На сьогоднішній день .NET являє собою найбільш повну реалізацію технологій Web-сервісів. В системі розробки і використання Web-сервісів Microsoft пропонує Visual Studio .NET - візуальне середовище, що підтримує всі мови програмування і інтегрується з існуючими серверами компанії. Основним продуктом виступає Microsoft Visual Studio .NET - засіб для створення .NET-сервісів, що підтримує такі мови програмування, як Visual Basic, C # і J #. Остання, однак, формально підтримуючи синтаксис мови Java, не дозволяє створювати стандартні Java-додатки - написаний код буде працювати тільки під керуванням Microsoft .NET. Oracle відрізняє два підходи до створення і використання Web-сервісів: по-перше, фірма пропонує програмну інфраструктуру, яку розробники можуть використовувати для створення Web-сервісів, а по-друге, розробляє і продає програмні продукти як Web-сервіси [6]. Група засобів розробки Oracle 9i являє собою набір інтегрованих програмних продуктів, що використовуються для створення і впровадження Web-сервісів. Вона складається з трьох основних компонентів: Oracle 9i JDeveloper (розробка Web-сервісів), Oracle 9i Application Server (виконання Web-сервісів) і Oracle 9i Database (створення додатків, що працюють з даними, які можуть використовуватися спільно з Web-сервісами). Основний продукт компанії Sun - Sun ONE - включає в себе архітектуру, платформу і набір засобів для створення і впровадження Web-сервісів, які називаються в термінах Sun сервісами за запитом - Services on Demand [14]. Платформа Sun ONE базується на наступних основних компонентах: на операційній системі Solaris, платформі Java 2 Platform, наборі серверів сімейства iPlanet і засобах розробки Forte Development Tools. Java є ключовою технологією фірми Sun, обґрунтовує базу більшості її продуктів і сервісів. З точки зору фірми Sun, додатки, які будуть виконувати функції Web-сервісів, повинні бути написані на мові Java. Java-додатки можуть працювати на будь-якому пристрої, що містить Java VM, включаючи персональні комп'ютери, мобільні комп'ютери, мобільні телефони і бездротові пристрої. 1.2 Аналіз методів оцінки і забезпечення надійності Web-сервісів 1.2.1. Класифікація джерел, видів, наслідків відмов Web-сервісів Загрозами для комп'ютерних систем є помилки (errors), несправності (faults) і відмови (failures) [13]. Під помилкою розуміється стан системи, що приводить до подальшої її відмови; відмова відбувається, коли помилка впроваджується в інтерфейс системи і видозмінює системну послугу; тут несправність - реальна або гіпотетична причина помилки. Несправність може бути активною (active), коли вона призводить до помилки, в іншому випадку вона є прихованою (dormant). Несправності, так само як і їх джерела, відрізняються широким розмаїттям. На рис.1.2 представлена класифікація несправностей системи в залежності від критеріїв появи, меж системи, домену, джерела, впливу на систему, тривалості. Виходячи з представленої класифікації, всі несправності системи можуть бути об'єднані в одну з трьох груп: несправності розробки, фізичні несправності і несправності взаємодії. Несправності, як наслідок злочинних дій можуть бути, в свою чергу, розділені на несправності, завдані руйнівною логікою (троянські коні, віруси, черв'яки), і вторгнення. Для здійснення вторгнення зловмисником може бути використана внутрішня несправність системи або зовнішній вплив (виключення живлення, перехоплення трафіку). В даному випадку для побудови моделі важливий сам факт наявності несправностей в системі внаслідок вторгнення зловмисника. У таблиці 1.1 представлені потенційні порушення системи безпеки і методи забезпечення безпечного функціонування проектованої системи. Рис.1.2. Класифікація несправностей системи Таблиця 1.1 Потенційні загрози для системи безпеки Методи забезпечення безпеки Розмежування прав доступу на рівні Шифрування даних Інші методи криптографії ОС Web-сервера СУБД мови сценаріїв Простору документів сервера асиметричне симетричне комбіноване сертифікати VeriSign Електронний цифровий підпис Порушення системи безпеки Несанкціонований доступ до ресурсів * Відсутність доступу * Порушення конфіденційності * Порушення цілісності * Три основні загрози для Web-служб і XML-ресурсів - це атаки на основі фальсифікації ідентифікаційної інформації, спотворення контенту і операційні атаки [11]. 1. Фальсифікація ідентифікаційної інформації. Сфальсифікувати ідентифікаційну інформацію можна в процесі будь-якого обміну даними по протоколу HTTP. Хоча Web-служби не обмежуються тільки підтримкою протоколу HTTP, велика частина трафіку SOAP (Simple Object Access Protocol) передається саме таким чином. WSS 1.0 надає набір стандартів авторизації і аутентифікації для захисту від подібних атак. Існують технології безпеки XML, такі, як XML-Encryption і XML-Signature, які дозволяють відбити атаки рівня додатків. Захищені протоколи транспортного рівня - SSL для HTTP і TLS для SMTP - знижують ймовірність "підслуховування". Однак вони непридатні для Web-служб, оскільки останнім для обробки документа перед відправкою його в кінцеву точку іноді потрібен проміжний вузол SOAP. Для виключення такої ймовірності процеси шифрування і перевірки ідентичності повинні виконуватися на рівні додатків. 2. Контент-атака. Контент-атака спрямована на кінцеву точку (сервер) з метою несанкціонованих дій, наприклад, отримання або знищення даних, або маніпулювати вмістом SOAP-повідомлень. В результаті сервер споживає надлишкові ресурси і перестає відповідати на запити. 3. Операційні атаки. Метою операційної атаки є відмова служби, що досягається маніпуляцією XML-повідомлення. Спроба аналізу XML-документа, що містить рекурсивний опис XML-об'єктів або великий обсяг даних, здатна викликати зупинку роботи сервера внаслідок нестачі обсягу пам'яті або його істотне уповільнення через зайняття процесорного часу [11]. Захист від такого роду атак полягає в попередній обробці і перевірці вхідних SOAP-повідомлень на відповідність заявленій схемі, що включає перевірку на сумісність типів даних і перевірку на дотримання максимальної / мінімальної довжини строкових даних. Таким чином, для побудови графа станів системи з урахуванням впливів можна розділити їх на дві групи: несправності програмного і апаратного забезпечення системи і несправності, завдані вторгненням зловмисника. Для систем сервіс-орієнтованої архітектури виділяють наступні джерела відмов: - апаратне забезпечення (процесори, оперативна пам‘ять, блоки живлення, мережеві карти та ін.); - програмне забезпечення (ОС, додатки: Web-сервер, сервер додатків, СУБД); - цільові додатки Web-сервісів (сервлети і CGI-додатки; збережені процедури і тригери СУБД). В аспекті впливу відмов F на функціонування системи виділено унікальні групи відмов {F1, ..., F8} (Таблиця 1.2): Таблиця 1.2 Перелік відмов системи 1 CrashHWEnv CrashSWEnv StoredDataLoss SessionDataLos s Відмова апаратного забезпечення Відмова середовища оточення додатків Втрата даних, що зберігаються Втрата даних сесії F1 2 CrashHWEnv OSSuspension Відмова апаратного забезпечення Відмова ОС F2 3 OSSuspension SessionDataLoss Збій (зависання) ОС Втрата даних сесії F3 4 AppError Помилка програми F4 5 CrashSWEnv StoredDataLoss SessionDataLoss Відмова середовища оточення додатків Втрата даних, що зберігаються Втрата даних сесії F5 6 SWServSuspension SessionDataLoss Збій (зависання) Web-сервісу Втрата даних сесії F6 7 CrashSWApplication StoredDataLoss Відмова програмного додатку Втрата даних, що зберігаються F7 8 SWAppSuspension SessionDataLoss Збій (зависання) додатку Втрата даних сесії F8 Найбільш розповсюдженими причинами відмов є: HWCrash - збій в апаратному забезпеченні; SWCrash - збій в програмному забезпеченні; StoredDalaLoss - втрата даних, що зберігаються; SessionDataLoss - втрата даних сесії; OSSuspension - зависання ОС; AppError - помилка в додатку; AppSuspension - зависання програми. 1.2.2. Методи відновлення функціонування Можна виділити унікальні ланцюги процедур відновлення функціонування системи. Множина процедур відновлення R включає вісім процедур, згрупованих відповідно до логіки функціонування: R = {R1, ..., R8} Таблиця 1.3 Процедури відновлення системи 1 ReplaceCrashedHWComponent ReinstallSWComponent StoredDataRecovery SessionDataRecovery Заміна компонента, що відмовив Повторна інсталяція компонента ПЗ Відновлення даних, що зберігаються Відновлення даних сесії R1 2 ReplaceCrashedHWComponent SessionDataRecovery Заміна компонента, що відмовив Відновлення даних сесії R2 3 RestartHWSWEnvironment SessionDataRecovery Перезапуск середовища оточення Відновлення даних сесії R3 4 ReinstallSWEnvironment StoredDataRecovery SessionDataRecovery Повторна інсталяція середовища оточення ПЗ Відновлення даних, що зберігаються Відновлення даних сесії R4 5 RestartSWServices SessionDataRecovery Перезапуск Web-сервісів Відновлення даних сесії R5 6 ReinstallSWApplication StoredDataRecovery SessionDataRecovery Повторна інсталяція додатку Відновлення даних, що зберігаються Відновлення даних сесії R6 7 RestartSWApplication SessionDataRecovery Перезапуск додатку Відновлення даних сесії R7 8 NoSpecialProcedure Немає спеціальної процедури R8 На основі аналізу наведених множин можна припустити, що існує однозначна закономірність між вісьмома унікальними групами проявів відмов і вісьмома ланцюгами процедур відновлення системи після відповідних відмов: F1 – R1; F2 – R2; F3 – R3; F4 – R8; F5 – R4; F6 – R5; F7 – R6; F8 – R7. При встановленні вищевказаних відповідностей було зроблено припущення, згідно з яким система після прояву відмови F4 (помилка програми) може бути відновлена процедурою R8 (немає спеціального методу), що має на увазі виконання відновлення системи за допомогою деякого алгоритму в залежності від типу помилки програми. 1.2.3. Методи забезпечення відмовостійкості Згідно концепту попереднього розділу можна виділити унікальні ланцюги процедур забезпечення відмовостійкості системи (FT). Множина процедур FT включає в себе п'ять процедур, згрупованих відповідно до логіки функціонування: FT = {FT1, ..., FT5}. Таблиця 1.4 Процедури забезпечення відмовостійкості 1 Redundancy of HW environment Replication of SW environment Надмірність апаратного забезпечення Реплікація ОС FT1 2 Operation Retry Rollback recovery block Повтор операції Блок відкату транзакції FT2 3 Redundancy of HW environment Diversity of SW environment Надмірність апаратного забезпечення Диверсність ПЗ FT3 4 Application specific error exception handling Механізм обробки виключення FT4 5 N-version programming Багатоверсійність програмування FT5 1.3 Аналіз математичного апарату для моделювання та оцінки надійності і безпеки Web-сервісів 1.3.1 Особливості Web-сервісів як об'єкта моделювання Певні підходи до забезпечення відмовостійкості систем Web-сервісів були представлені в дослідженнях вітчизняних і зарубіжних авторів [10,12]. Однак сучасний план розробки та впровадження відмовостійких архітектур відображає нові виклики в сфері моделювання та оцінки надійності: - в відмовостійких сервісах зростає число станів, в яких може перебувати система внаслідок відмов, обумовлених фізичними дефектами апаратного забезпечення, дефектами проектування програмного забезпечення і дефектами взаємодії Web-сервісів внаслідок різних атак; - для кожної з процедур забезпечення відмовостійкості враховується вплив засобів їх реалізації на надійність Web-сервісів; - характеристики SOA і цільових сервісів, з яких формуються композитні SOA, які є невизначеними і змінними. Відомі кілька підходів до моделювання Web-сервісів, засновані на експериментуванні з реальними сервісами [13], методі Монте-Карло [20], аналітичних методах дослідження Байєсових [21] та Марковських моделей [13]. Далі розглянуто різні методи і апарати математичного моделювання для розрахунку надійності Web-сервісів.