Geum.ru

Доклад/Технічні науки інформатика, обчислювальна техніка та автоматизація

Вид материалаДоклад

Содержание


Рис.1 Перетин множин підзадач різних АІС
Подобный материал:
Доклад/Технічні науки – інформатика, обчислювальна техніка та автоматизація

УДК 681.3.07

Бойцов К. О. ., Савицький А. Й.

ЗАСТОСУВАННЯ СЕРВІС-ОРІЕНТОВАНОГО ПІДХОДУ ПРИ ПОБУДОВІ АРХІТЕКТУРИ ЄДИНОГО ІНФОРМАЦІЙНОГО СЕРЕДОВИЩА УНІВЕРСИТЕТУ

Національний технічний університет України „Київський політехнічний інститут”, КБ інформаційних систем


Побудова архітектури системи розглядається на основі технічного завдання (ТЗ) на розробку й впровадження єдиного інформаційного середовища (ЄІС) НТУУ «Київський політехнічний інститут».

ЄІС університету повинна мати в своєму складі більше 80 автоматизованих інформаційних систем (АІС), в яких буде вирішуватись біль ніж 700 задач. Причому підзадачі, як складові задач, одних АІС можуть реалізовуватись в складі задач та підзадач інших АІС, відрізняючись лише параметрами за входом та виходом (Рис.1).


Рис.1 Перетин множин підзадач різних АІС

Для ЄІС характерним є: наявність множини програмних модулів для вирішення задач та підзадач, єдиний інтерфейс їх взаємодії, географічна розподіленність АІС, розподілений доступ до даних, централізоване управління. Наведені характеристики дають підставу розгляду можливості побудови архітектури системи ЄІС на основі СОА – сервіс-орієнтованої архітектури.

Основним компонентом СОА є сервіс – програмна одиниця, модуль, що реалізує деяку функціональність. В СОА цей логічний модуль повинен мати високий потенціал повторного використання (його функціонал багаторазово використовується у процесах вирішення задач або підзадач системи). В основу СОА покладений принцип взаємодії трьох елементів структури: постачальника сервісу, споживача сервісу та реєстру сервісів. Аспектами їх взаємодії є публікація, пошук, підключення та використання сервісів.

В основу СОА покладено чотири компоненти – сервіси, фронт-енди додатків, репозиторій опису сервісів та сервісна шина. Головні задачі шини: технологічне з‘єднання систем та надання інтегрованого підходу до ведення протоколів операцій та забезпечення засобів безпеки. Фронт-енди додатків – це основні клієнти сервісів. Переважно це клієнтські додатки АІС та АРМ різного роду. Задача репозиторію полягає в зберіганні опису сервісів. Основні принципи: опис всіх інтерфейсів має бути уніфікований, репозиторій повинен бути єдиним для всієї системи (однак, можуть бути локальні копії).

Визначене коло проблем щодо побудови сервіс-орієнтованої системи „ЄІС” університету: аналіз функціональних задач та під задач всіх АІС та АРМ (згідно ТЗ на систему), формування множини кандидатів у сервіси (на основі сервіс-орієнтованого аналізу за критерієм повторюваності функціоналів в різних АІС та АРМ), раціоналізація множини кандидатів у сервіси (з врахуванням особливостей організаційної структури управління університетом та розподілу ресурсів), розробка механізмів взаємодії сервісів (оркестрування та диспетчеризації), синтез СОА системи (відповідно вимогам ТЗ).

На етапі сервіс-орієнтованого аналізу формується множина кандидатів у сервіси за виконанням умов:
  1. Кожній задачі ставиться у відповідність один або декілька сервісів.
  2. Однакові підзадачі забезпечуються одним сервісом.
  3. Загальна множина сервісів повинна виявитися набагато меншою, ніж кількість підзадач у всіх АІС.

Коротко це можна записати так:

Нехай А – множина АІС, а Ві – множина підзадач і-ї АІС, де i=1,2 .. n, а n – кількість АІС. Тоді, якщо S – множина сервісів, то

, де j=1,2 .. mi, k=1,2 .. l, причому

Тут l – кількість сервісів, mi – кількість підзадач, що входять до складу і-ї АІС.

При виконанні наведеної умови можна отримати множину сервісів, які повністю перекривають множину всіх підзадач всіх задач всіх АІС з усіх підсистем. Причому, в загальному випадку, сервіси не можна віднести до певної АІС або підсистеми. Однак, можна виділити деякі їх різновиди відповідно до потенціалу повторного використання. Так сервіси, які реалізують підзадачі з перетину множин задач щонайменше двох задач з різних АІС і складають базовий набір сервісів. Сервіси, що забезпечують підзадачі, які не перетинаються, відповідають підзадачам, що не входять до інших задач різних АІС. Серед таких сервісів теж можна визначити різну інтенсивність використання. Побудова ЄІС, згідно базового ТЗ, передбачає використання деяких АІС у кількох екземплярах – наприклад, кожен факультет має однаковий набір АІС і тому при переході до СОА сервіси, що відповідають цим АІС, будуть задіяні багаторазово – за кількістю факультетів. Однакові сервіси можуть використовуватись і у вертикалі ієрархії системи управління університетом (на кафедральному, факультетському та університетському рівнях). Сервіс є унікальним в межах ЄІС, якщо він поставлений у відповідність одній підзадачі, яка більше ніде не вирішується окрім однієї АІС. Решта сервісів займає проміжне положення між унікальними та базовими сервісами. Таким чином для заданої множини АІС можна утворити ієрархію сервісів щодо ефективності їх використання.

Інструментом подальшої раціоналізації набору сервісів може служити аналіз частот застосування сервісів у підсистемах та кількості задач, прив‘язаних до одного сервісу. На основі розгляду результатів такого аналізу можна закласти основи прогнозування навантаження на компоненти системи.

Розглянуті наступні різновиди архітектур:
  1. Централізована архітектура: централізовані банк сервісів, банк даних, системи оркестрування та диспетчеризація.
  2. Розподілена архітектура: розгалужені по вузлах банки сервісів, банки даних, системи оркестрування та диспетчеризація.
  3. Централізована архітектура з реплікацією: централізовані реплікаційні банки сервісів, банки даних, системи оркестрування та диспетчеризація, розгалужені по вузлах банки сервісів, банки даних, системи оркестрування та диспетчеризація.

Найскладнішим випадком з точки зору завантаження обладнання є централізована архітектура. При такому розташуванні ресурсів всі запити будуть направлятись до центрального сховища. Якщо при цьому всі процеси обробки даних також мають виконуватись на центральному сервері, а не на машинах-клієнтах, то вимоги до потужності цього серверу будуть надзвичайно великі. Однак, така архітектура є досить простою з точки зору логіки побудови процесів керування обслуговуванням, маршрутизації і взагалі структури всієї системи. Потужності сучасних комп’ютерів та можливості мереж дають підстави не відкидати такий варіант на першому ж кроці. Однак, необхідне проведення дослідження економічного характеру після визначення необхідних вимог до обладнання. Скоріше за все, розподілена система виявиться хоч і більш складною в організаційному плані, однак економічно більш вигідною та обґрунтованою. Розподілена система також має більш високу надійність, особливо якщо застосоване резервне копіювання, надлишкова реплікація та інші заходи щодо підвищення стійкості до відмов. Вірогідність відмови одразу багатьох вузлів розподіленої мережі надзвичайно мала, тоді як вихід з ладу деякої важливої частини єдиного надпотужного серверу загрожує функціонуванню системи в цілому.

Принципово, задача диспетчеризації та управління обслуговуванням для всіх архітектур в основі своїй однакова. Необхідно визначити: максимальну кількість екземплярів одного сервісу, що можуть бути запущені в роботу одночасно, максимальну кількість наборів різних сервісів, що можуть бути запущені в роботу одночасно, пріоритети перемикання між сервісами та механізм формування черги, коли вже існує максимально допустима кількість екземплярів деякого сервісу. Для сервісів, що працюють зі збереженням стану у режимі сесій актуальною задачею є переведення сервісу в режим очікування відповіді на переривання зі звільненням ресурсів для іншого сервісу, а також пріоритети відновлення роботи таких сервісів. Обов’язково необхідний механізм контролю наявності помилок. У найпростішому випадку, при відсутності відповіді на надісланий запит впродовж певного контрольного періоду часу, цей запит має бути відісланий знову. Ця задача також лягає на підсистему диспетчеризації. Такі обставини однакові як для централізованої, так і для розподіленої систем. При цьому для розподіленої системи існує ще диспетчеризація між окремими підсистемами. Для сервісів, що знаходяться за межами даної підсистеми існує окрема підсистема диспетчеризації, що діє за подібними правилами, однак має свою чергу і індивідуальні пріоритети порівняно з локальними. Для розподіленої системи з наявним центральним сховищем потрібен ще механізм реплікації та синхронізації сервісів між центральним сховищем та локальними серверами. Оскільки зміна сервісів не є частою процедурою, реплікацію та синхронізацію можна виконувати за розкладом під час найменшого мережевого навантаження (наприклад, в нічні або неробочі години). Тому визначення навантаження на обладнання менш актуальне для цієї задачі. Для виконання цієї операції в системі мають зберігатися відомості про розподіл сервісів на локальних серверах підсистем та механізм контролю версій сервісів, щоб оновлення не відбувалося, коли версії співпадають.