На конкурс на кращу наукову роботу студентів за розділом
"Технічна кібернетика, обчислювальна, мікропроцесорна техніка та інформатика "
Студентська наукова робота
за темою:
РОЗРОБКА СЕРВІС-ОРІЄНТОВАНОГО ІНТЕРФЕЙСУ РОЗПОДІЛЕНОГО МОДЕЛЮЮЧОГО СЕРЕДОВИЩА
ДЕВІЗ: ІНТЕГРАЦІЯ ЗАРАДИ ЕФЕКТИВНОСТІ МОДЕЛЮВАННЯ
2006 р.
РЕФЕРАТ
Студентська наукова робота: 17 с., 6 рис., 5 посилань
Об’єкт дослідження: сервіс-орієнтований інтерфейс розподіленого моделюючого середовища.
Метою роботи є винаходження ефективної концепції інтерфейсу.
Галузь застосування – моделювання динамічних об’єктів.
МОДЕЛЮЮЧЕ СЕРЕДОВИЩЕ, SOA-АРХІТЕКТУРА, WEB-СЕРВІС, ІНТЕРФЕЙС.
ЗМІСТ
Вступ 4
Загальні вимоги до інтерфейсу 4
Концепція SOA-архітектури 6
Засоби для реалізації SOA-архітектури 10
Принципи функціонування інтерфейсу 13
Заключна частина 16
Перелік посилань 17
ВСТУП
Розробка моделей різноманітних об’єктів промислових або наукових галузей на ступені, що передує їх реалізації, впровадженню або відновленню, необхідна сьогодні у тій ж мірі, як і наявність проекта для будівлі. Якісні моделі є основою взаємодії учасників проекту та гарантують коректність структури. Оскільки складеність систем підвищується, важливо мати високоякісні та ефективні засоби моделювання. Коли мова постає про засоби комп’ютерного моделювання, найпершим засобом для забезпечення повної функціональності та високого рівня ефективності моделюючого середовища постає його інтерфейс, або засоби спілкування системи з користувачем.
ЗАГАЛЬНІ ВИМОГИ ДО ІНТЕРФЕЙСУ
Прогрес сучасних галузей техніки залежить від рівня теорії та практичної реалізації методів проектування автоматизованих технічних об’єктів, технологічних установок та ліній, що визначаються як складні динамічні системи (ДС). Найголовнішим засобом розробки та проектування ДС на сьогодні є їх моделювання комп’ютерними засобами, тому методи та засоби моделювання динамічних систем, які можуть використовуватись на всіх етапах проекту ДС від формулювання техніко-економічних вимог до випробувань та початку експлуатації, займають чільне місце.
Сьогодні та в найближчій перспективі розробники та користувачі моделей динамічних систем одержують апаратні ресурси за структурою, що наведена на рис. 1 і має чітко виражений простірно розподілений характер:
Рисунок 1 - Територіальна розподіленість паралельного моделюючого середовища.
Доступ можливо мати як з робочих місць, територіально наближених до надпотужних обчислювальних систем (суперSISD, SIMD, MIMD), так і з суттєво віддалених. В останньому випадку має використовуватись INTERNET-технологія доступу. Передбачені структурою локальні сервери можуть мати паралельні ресурси, модельно орієнтоване периферійне обладнання та засоби побудови напівнатурних моделюючих комплексів.
Важливою частиною комп’ютерного моделюючого середовища є інтерфейс, тобто засоби ведення діалогу з користувачем, інформування його про поточний стан розв’язання задач та прийом від нього керуючої інформації. Основними вимогами до реалізації інтерфейсу моделюючого середовища є:
1. Дружність та запобігливість до користувача – спеціаліста предметної області, що розробляє та досліджує моделі динамічних систем. Ця вимога означає, що інтерфейс повинен давати користувачу можливість зосереджуватись на проблемах моделювання в своїй галузі знань, а не на необхідності опановувати апаратно-програмні ресурси, складність яких адекватна складності об'єктів моделювання.
2. Високоінтелектуальна діалогова підтримка користувача (розробника) на всіх етапах моделювання моделюючого середовища від специфікації об’єктів до візуалізації та документування результатів моделювання.
КОНЦЕПЦІЯ SOA-АРХІТЕКТУРИ
Сьогодні спостерігається стійкий ріст інтересу до концепції сервіс-орієнтованої архітектури (service-oriented architecture, SOA). Свідчення тому - оцінки аналітичних компаній і зусилля великих постачальників програмного забезпечення по просуванню цього підходу. SOA - це не технологія, а спосіб проектування й організації інформаційної архітектури.
Визначення SOA: це парадигма, призначена для проектування, розробки й керування дискретних одиниць логіки (сервисів) в обчислювальному середовищі. Застосування цього підходу жадає від розроблювачів проектування додатків як набору сервисів, навіть якщо переваги такого рішення відразу неочевидні. Розроблювачі повинні "вийти за межі" своїх додатків і подумати, як скористатися вже існуючими сервісами, або вивчити, як їх сервіси можуть бути використані їхніми колегами.
SOA "підштовхує" до використання альтернативних технологій і підходів (таких як обмін повідомленнями) для побудови додатків за допомогою зв'язування сервисів, а не за допомогою написання нового програмного коду. У цьому випадку, при належному проектуванні, застосування повідомлень дозволяє компаніям вчасно реагувати на зміну ринкових умов - "набудовувати" процес обміну повідомленнями, а не розробляти нові додатки.
Припустимо, ви бажаєте послухати музику, що записана на компак-диску: берете диск, кладете його до плеєра, вмикаєте та слухаєте. Таким чином CD-плеєр пропонує вам сервіс «програвання CD-дисків». Якщо потрібно, ви можете замінити цей плеєр на інший, кращий за якістю. Ви можете покласти такий самий CD до портативного плеєра або до потужної стереосистеми. Всі ці прилади пропонуватимуть вам один і той же самий сервіс, але різної якості. Таким ж чином у SOA сервіс пропонують програмні компоненти, які можуть бути замінені іншими, якщо виникне потреба у зміні якості.
Цей приклад ілюструє принципове відрізнення SOA від об’єктно-орієнтованої архітектури, в якій дані та їх обробка нерозривно пов’язані: кожен CD повинен би був постачатися зі своїм власним плеєром.
У самому загальному виді SOA припускає наявність трьох основних учасників: постачальника сервісу, споживача сервісу й реєстру сервисів (рис. 2). Взаємодія учасників виглядає досить просто: постачальник сервісу реєструє свої сервіси в реєстрі, а споживач звертається до реєстру із запитом.
Рисунок 2 – Загальна схема SOA
Перш ніж перелічити переваги використання SOA, буде доречним нагадати, що переваги бувають різні: стратегічні й тактичні. SOA володіє рядом достоїнств як стратегічних, так і тактичних.
Стратегічна цінність SOA:
§ Скорочення часу реалізації проектів, або "часу виходу на ринок".
§ Підвищення продуктивності.
§ Більш швидка й менш дорога інтеграція додатків.
Відомо, що реалізація традиційних рішень для інтеграції прикладних програм - непросте завдання, що вимагає істотних капіталовкладень. Крім того, часто при впровадження необхідне написання програмного коду. SOA передбачає розміщення сервисів у мережі в режимі виконання, тобто дозволяє автоматизувати ці ресурсномісткі процеси, завдяки чому істотно скорочуються всі витрати на інтеграцію.
Тактичні переваги SOA:
§ Більш прості розробка й впровадження додатків.
§ Використання поточних інвестицій.
§ Зменшення ризику, пов'язаного із впровадженням проектів в області автоматизацією послуг і процесів.
§ Можливість безперервного поліпшення надаваної послуги.
§ Скорочення числа обігів за технічною підтримкою.
§ Підвищення показника повернення інвестицій (ROI).
Достоїнство такого роду служб – це простота створення. Це можна пояснити, насамперед, існуванням усякого роду кодогенераторов і майстрів.
Отже, технологія Web Services призначена для створення розподілених додатків, що функціонують у середовищі Інтернет (і всіх його варіацій типу інтранет та екстранет), компоненти яких взаємодіють на базі стандартних Web-протоколів. На думку експертів, Web Services повинні замінити вже досить давно існуючі технології для зв'язування вилучених компонентів (такі, як DCOM й CORBA), які є несумісними між собою й, більше того, реалізовані на основі закритих корпоративних стандартів. Однак найголовніше те, що всі ці технології створювалися у свій час для забезпечення зв'язку програмних компонентів в однорідних локальних обчислювальних мережах з підтримкою обмеженого числа транспортних протоколів.
Таким рішенням, як CORBA та DCOM, не вистачає універсальності. Використання CORBA сильно залежало від реалізації у програмних продуктах різних постачальників, з’являлися нові об’єктні моделі, що не підтримували CORBA, рівень інтеграції залишався недостатньо високим, що майже не дозволяло динамічно змінювати зв’язки між додатками під час роботи. Важливо ще й те, що такі засоби інтеграції фокусуються на технологічних особливостях реалізації додатків та не враховують специфіку тих галузей, де ці додатки використовуються.
Таким чином, можна бачити, що залучення SOA у якості парадигми розробки інтерфейса паралельного моделюючого середовища має чисельні переваги. Традиційним на сьогодні засобом одержання розподілених апаратних ресурсів є проста консоль (наприклад, Telnet), у якій користувач повинен вводити команди та отримувати результати рішення задач майже без яких-небудь засобів інтерфейсу. Користувач повинен пам’ятати усі необхідні для роботи команди, самостійно перетворювати результати у зручний для нього вигляд і, таким чином, багато часу витрачає на роботу, не пов’язану безпосередньо з його діяльністю, з метою його звернення до паралельних обчислювальних ресурсів. Щось казати про дружність та запобігливість до користувача у даному випадку неможливо.
Інтерфейс на основі SOA зможе позбавити користувача займатися будь-якою зайвою роботою та надати йому можливість зосередитися саме на рішенні потрібних йому задач. У системі розподіленого моделюючого середовища, розробленій на основі SOA-архітектури, інтерфейс візьме на себе функції, наведені на рис. 3, серед яких реєстрація, авторизація користувачів, надання їм прав доступу, генерація та розв’язання рівнянь, що описують об’єкт моделювання.
ЗАСОБИ ДЛЯ РЕАЛІЗАЦІЇ SOA-АРХІТЕКТУРИ
Допоміжними засобами для реалізації SOA-архітектури є середовище розробки Java, сервер-контейнер Tomcat, база даних MySQL та мова розмітки гіпертексту XML.
Рисунок 3 – Функції інтерфейсу розподіленого моделюючого середовища, який реалізований за допомогою SOA
Java стає усе більше популярна як основа для створення різних масштабних незалежних від платформи рішень. Одним з найбільш запитуваних застосувань Java є її використання на ринку сервіс- та веб- провайдерів ASP (Application Service Provider). Java є підходящим рішенням для таких ринків, з наступними перевагами:
· Незалежність від платформи
· Широке визнання в галузі
· Масштабованість
· Надійність роботи
· Розподіленість
· Багатопоточність
· Безпека
Дуже важливою технологією, що виросла з Java та значно розвивається, є JSP (JavaServer Pages™).
JSP (JavaServer Pages) являє собою серверну технологію, яка створена компанією Sun Microsystems, що дає простий і швидкий спосіб генерації динамічного змісту зі сторінок HTML. У ній використаються теги XML і скріпти Java, що дозволяють відокремити логіку від особливостей дизайну. При виклику сторінки JSP вона динамічно перетворюється в сервлет та обробляється сервером для генерації кінцевої сторінки HTML/XML для клієнта. Коли JSP використовується разом з JavaBeans, можливо створювати найрізноманітніші, масштабовані додатки.
Tomcat є реалізацією технологій сервлетів Java та JavaServer Pages з відкритим кодом, розробленою в рамках проекту Jakarta організацією Apache Software Foundation. Tomcat реалізує нову Servlet-технологію (за назвою Catalina), засновану на абсолютно новій архітектурі за специфікаціями Servlet 2.3 й JSP 1.2. До неї включено багато додаткових можливостей, які роблять її зручною платформою для розробки й впровадження Web-додатків та сервисів. Суттєво Tomcat є сервером додатків, написаним на 100% винятково мовою Java.
MySQL – це компактний багатопоточний сервер баз даних. MySQL характеризується великою швидкістю, стійкістю і легкістю у використанні. MySQL був розроблений компанією Tcх для вирішення внутрішніх незручностей, що полягали у швидкій обробці дуже великих баз даних. Компанія стверджує, що використовує MySQL з 1996 долі на сервері з більш ніж 40 БД, що містять 10,000 таблиць, з яких більш ніж 500 мають більш 7 мільйонів рядків.
MySQL є ідеальним рішенням для малих і середніх додатків. Ісходники сервера компілюються на безлічі платформ. Найбільш повно можливості сервера виявляються на Unix-серверах, де є підтримка багатопоточності, що дає значний приріст продуктивності.
XML являє собою розширений та доповнений варіант традиційної мови гіпертексту HTML. Необхідність її виникнення була пов’язана з тим, що теги HTML можуть лише визначити зовнішній вигляд сторінки, але їх ніяк не цікавить її зміст. Мова XML має розширений набір тегів, що дозволяють розподілити зміст за смисловими категоріями, які задає програміст, та використовувати різноманітну перевірку на змістовність тексту у роботі своїх додатків. XML не залежить від платформи.
Для того, щоб HTML-код сторінки не змішувався з Java-кодом, що ускладнює роботу як програміста, так і дизайнера, була вигадана технологія JSP – JavaServer Pages. При першому виклику jsp-сторінки код незримо від розроблювача переробляється в сервлет і компілюється, після чого при наступних запусках веб-сервер викликає вже не саму jsp-сторінку, а відкомпільований сервлет. При внесенні змін в jsp-сторінку веб-сервер виявляє, що сторінка змінилася, та знову обновляє сервлет, що відповідає цій сторінці.
ПРИНЦИПИ ФУНКЦІОНУВАННЯ ІНТЕРФЕЙСУ
У технологіях Servlets та JSP введене поняття "контейнера" (container). Servlets-контейнер відповідає за виконання Servlet-ов. JSP-контейнер відповідає за перетворення js-сторінок у сервлети та передачу цих сервлетів Servlets-контейнеру. Оскільки сервлети та jsp-сторінки викликаються через HTTP-протокол, Servlets-контейнер та JSP-контейнер часто супроводжує ще один компонент - web-сервер, який теж може бути написаний на Java.
Як видно на рис. 4, веб-сервер, написаний на Java, одержує запити від броузера на виконання того або іншого сервлета або jsp-сторінки на сервері, передає запит у контейнер, що виконує той або інший сервлет. Результати виконання повертаються контейнером веб-серверу, що у свою чергу пересилає його броузеру.
Рисунок 4 – Схема роботи Java Web-сервера
Явний поділ програмних обов’язків забезпечує так звана модель Model-View-Controller (MVC, рис. 5). В архітектурі MVC центральний servlet, відомий як Контролер, одержує всі запити до додатка. Контролер обробляє запит і починає працювати з Моделлю, щоб підготувати дані, які необхідні Відображенню (яке звичайно JSP), і передає дані JSP. JSP використає дані, підготовлені Контролером для генерування відповіді браузеру. У цій архітектурі, логіка рішення та логіка відображення відділені одна від іншої. Це розподілення забезпечує багаторазове використання коду.
На рис. 6 та ж сама архітектура показана більш детально, з усіма сервізами, що необхідні для реалізації функцій адміністрування.
Рисунок 6 – Детальна архітектура MVC
Загальну кількість Web-сервісів розподіленого моделюючого середовища можна розділити на такі складові частини:
1. Сервіси, що реалізують функції адміністрування, такі, як авторизація та реєстрація користувачів.
2. Сервіси, що реалізують засоби для рішення задач моделювання, такі, як топологічний аналізатор, генератор та розв’язувач рівнянь.
Сервіси, що реалізують функції адміністрування, надають можливість реєструвати користувачів системи, які можуть задавати список своїх праць. Адміністратор може проглянути список користувачів, створити або видалити користувача та модифікувати дані користувача.
Адміністратор реєструє користувача, заповнюючи форму із загальною інформацією про нього, як ім'я, пошта, пароль і т.ін. Він може видалити користувача або змінити інформацію реєстрації. Також адміністратор може за даними, які уведені користувачем про свою роботу, формувати звіти за заданим фільтром.
При завершенні роботи користувач може вийти із системи й розірвати з'єднання. Якщо відбулася помилка в ході роботи, то відобразиться її докладний опис.
Повний перелік функцій сервісів моделюючого середовища, що реалізують засоби рішення задач, виглядає таким чином:
1. Загальна підсистема діалогу (топологічний аналізатор, генератор рівнянь, розв’язувач рівнянь).
2. Відображення поточних моделей (додання моделі, редагування моделі, видалення моделі).
3. Забезпечення введення даних для топологічного аналізатора (завантаження файлу в потрібному форматі або ручне введення, збереження у базі даних).
4. Зміна параметрів.
5. Генерація рівнянь для моделі.
6. Завантаження та відображення результатів у вигляді матриці.
7. Введення параметрів для рішення.
8. Розв’язання рівнянь.
9. Вказівка типа ресурсу (де розв’язувати рівняння).
10. Параметри запуску.
ЗАКЛЮЧНА ЧАСТИНА
Була виконана розробка ефективної концепції інтерфейсу для розподіленого моделюючого середовища. Концепція може бути застосована у різноманітних промислових та наукових галузях, де потребується моделювання складних динамічних об’єктів.
ПЕРЕЛІК ПОСИЛАНЬ
1. Святний В.А., Солонін О.М., Надєєв Д.В., Степанов І., Ротермель К., Цайтц М. Розподілене паралельне моделююче середовище.- Наукові праці ДонДТУ. Серія “Проблеми моделювання та автоматизації проектування динамічних систем”. Випуск 29:-Донецьк, ДонДТУ, 2001. – С.229 – 234.
2. Аноприенко А.Я., Святный В.А. Высокопроизводительные информационно-моделирующие среды для исследования, разработки и сопровождения сложных динамических систем.- Наукові праці ДонДТУ. Серія “Проблеми моделювання та автоматизації проектування динамічних систем”. Випуск 29:-Донецьк, ДонДТУ, 2001. – С.346 – 367.
3. Святний В.А. Проблеми паралельного моделювання складних динамiчних систем.- Науковi працi ДонДТУ, серiя IКОТ, вип. 6, Донецьк, 1999, С. 6-14.
4. Наталья Дубова.SOA: подходы к реализации. - Открытые системы, №06/2004.
5. Mike Robinson, Ellen Finkelstein. Jakarta Struts for Dummies. – ISBN: 0-7645-5957-5, April 2004.