РОЗДІЛ 2. МЕТОДИ ПОБУДОВИ ТА ДОСЛІДЖЕННЯ ПРОГРАМНОЇ МОДЕЛІ САНП
У даному розділі описується сервісно-орієнтована архітектура програмної моделі САНП та основні принципи її функціонування. Описується представлення програмної моделі САНП в якості дискретної системи, з метою вирішення та дослідження проблем ефективного функціонування паралельних процесів з використанням розподілених компонентах. Також пропонується розроблена методика пошуку стабільних станів системи, що забезпечує можливість впровадження існуючих алгоритмів підтримки стабільності системи.
При побудові програмної моделі САНП повинні задовольнятися основні функціональні вимоги:
- керування широким аспектом навчальних процесів;
- багатофункціональні можливості системи, для виконання ролі платформи новостворюваним додаткам;
- гнучке налаштування інтерфейсів взаємодії з системою, для забезпечення максимальної інтероперабельності з широким колом систем;
- гнучкі схеми інтеграції з популярними САНП;
- ефективне використання існуючої інфраструктури закладу та платформи, на базі якої виконується реалізація моделі САНП;
- гнучкі та потужні механізми розширення функціональності системи;
- технологічна та платформна незалежність розроблюваних модулів, та користувачів системи.
2.1. Сервісно-орієнтована архітектура САНП
В основу існуючої сервісно-орієнтованої архітектури[89-91] (Service Oriented Architecture - SOA) покладено ідею про те, що інформаційні системи, програмне забезпечення, пристрої та служби мають легко інтегруватись і взаємодіяти одне з одним, навіть якщо деякі з них не розроблялися спеціально з такою метою. Для відкритості системи SOA, зазвичай реалізуються на базі XML Web-служб, а компоненти конструюються як набори взаємодіючих служб багаторазового використання, кожна з яких відповідає за одне чи більше чітко визначених прикладних завдань, учбових процесів або інформаційних послуг. Для реалізації ефективної програмної моделі САНП необхідно розглянути основні принципи SOA, та доповнити існуючу архітектуру необхідними для САНП елементами.
У існуючій моделі часто немає рівня подання, оскільки тут необхідна сумісність лише на міжкомп'ютерному рівні, а не на рівні подання інформації для користувача. В той же час компоненти нижчих рівнів зазвичай містять функції та інтерфейси, придатні для використання незалежно розробленими рівнями подання. Інформація на рівні подання може відображатися за допомогою Web- браузера або клієнтського додатку, розробленого на базі відкритих стандартів, наприклад програми з пакету Microsoft Office, що виконується на персональному комп'ютері. Для цього і компоненти нижчих рівнів мають підтримувати відкриті стандарти, бо інакше вони не будуть доступними для жодного рівня подання. Тож інтерфейси цих компонентів (що реалізують функціональність) повинні мати форму, зрозумілу і зручну для рівнів подання.
Рис. 2.1 Сервісно-орієнтована архітектура
Якщо в моделі САНП взаємодія служб із зовнішнім середовищем забезпечується за допомогою Web-служб, то вона базується на таких стандартах:
* XML - розширювана мова розмітки (eXtensible Markup Language), що, як було сказано вище, забезпечує незалежну від виробників взаємодію систем
* SOAP[92] - текстовий (XML) протокол доступу до об'єктів (Simple Object Access Protocol), що визначає синтаксис доступу до служб
* WSDL[93] - мова опису Web- служб (Web Services Description Language), за допомогою якої можна визначити для служби вхідні й вихідні дані
Таким чином, сервісно-орієнтована архітектура складається з трьох компонентів:
* інтерфейси служб
* повний набір служб
* додатки на базі служб, з яких складаються або які підтримують важливі бізнес-системи і процеси
Рис. 2.2. Інтеграція продуктів різних виробників в SOA архітектурі.
Модель SOA базується на промислових стандартах, які забезпечують виконання служб на багатьох різних платформах і можливість їхньої взаємодії, що безперечно є необхідною умовою програмної моделі САНП. Служби можуть бути з'єднані з інтерфейсом користувача, що виконується на довільному пристрої або платформі, які є сумісними з інтерфейсами служб. Єдиною вимогою до прикладного програмного забезпечення є підтримка і використання ним відповідних стандартів.
При такому підході Web-службу ,скажімо на, .NET можуть використовувати додатки Windows, що є "товстими" клієнтами, програмне забезпечення смартфонів, кишенькових персональних комп'ютерів, Web-браузери, застосування Java тощо. Web-служби J2EE можуть використовувати ті самі клієнти. Крім того, самі Web-служби, працюючи на різних платформах, можуть "спілкуватися" одна з одною. Для навчальних систем здатність сервісів, базованих на різних технологіях і функціонуючих на різних платформах, взаємодіяти як у межах одного факультету, так і між різними факультетами закладу, або і між зовнішніми користувачами (такими як батьки студентів та ін.) є ключовою і абсолютно необхідною.
Є різні методи інтеграції успадкованих компонентів в архітектуру SOA. Вибір методу залежить від конкретних обставин. Скажімо, можна розробити для додатку компонентну обгортку, що буде експонувати його функції і дані як Web-служби, що використовують XML. Технічно це можуть бути розроблені в рамках закладу компоненти, API та інші інтерфейси. Для переходу до SOA перш за все необхідно здійснити фундаментальний аналіз наявних систем та розробити схему, у якій буде відображено їх місце в глобальній архітектурі електронних служб.
До застосувань, що використовуються в навчальних системах, часто висуваються вимоги масштабованості, доступності та відповідності певним критеріям продуктивності, особливо коли вони є складовими загальної інфраструктури, закладу. SOA дозволяє функціям, що спроектовані, реалізовані та надаються для загального доступу як служби, використовувати інші служби незалежно від місця їхнього розташування, зокрема незалежно від того, на якому комп'ютері вони розгорнуті. Зібрані разом, служби утворюють систему, що надає користувачу широкий діапазон можливостей.
- Київ+380960830922