Спочатку World Wide Web (WWW) представлялася її творцям як "простір обміну інформацією, у якому люди і комп'ютери можуть спілкуватися між собою". Тому перші Веб-додатки являли собою примітивні файлові сервери, які повертали статичні HTML-сторінки клієнтам, що їх запросили. Таким чином, Інтернет починалася як документоорієнтована.

Наступним етапом розвитку Інтернет стала поява поняття додатків, що базувалися на таких інтерфейсах, як CGI (або FastCGI), а надалі – на ISAPI. Common Gateway Interface (CGI) – це стандартний інтерфейс роботи з серверами, що дозволяє виконувати серверні програми, що викликаються через URL. Вхідною інформацією для таких додатків був вміст HTTP-заголовка (і тіло запиту при використанні протоколу POST). CGI-програми генерували HTML-код, який повертався браузеру. Основною проблемою CGI-додатків було те, що при кожному клієнтському запиті сервер виконував програму CGI в реальному часі, завантажуючи її в окремий адресний простір.

Поява Internet Server API (ISAPI) дозволило як вирішити проблеми продуктивності, що виникали з CGI-додатками, а й надати розпорядників більш багатий програмний інтерфейс. ISAPI DLL можна було порівнювати з розширеннями імен файлів через спеціальну мета-базу. Ці два механізми (CGI і ISAPI) послужили основою створення першого типу Веб-додатків, у яких, залежно від будь-яких клієнтських дій, виконувався серверний код. Таким чином, стала можливою динамічна генерація вмісту веб-сторінок і наповнення веб перестало бути чисто статичним.

Інтерфейс ISAPI – це особливість Microsoft Internet Information Server. ISAPI-додатки являють собою динамічні бібліотеки, що завантажуються (DLL), які виконуються в адресному просторі Веб-сервера. В інших Веб-серверів через деякий час також з'явилася можливість виконувати програми, реалізовані у вигляді бібліотек. У разі Веб-серверів Netscape цей програмний інтерфейс називався NSAPI (Netscape Server API). У досить популярного Веб-сервера Apache є можливість виконувати Веб-додатки, реалізовані у вигляді бібліотек; такі бібліотеки називаються Apache DSO (Dynamic Shared Objects).

Природно, що при використанні як CGI-, так і ISAPI-додатків розробники в основному вирішували одні і ті ж завдання, тому природним кроком стала поява нового високорівневого інтерфейсу, який спростив завдання генерації HTML-коду, дозволив звертатися до компонентів і використовувати бази даних . Таким інтерфейсом стала об'єктна модель Active Server Pages (ASP), побудована з урахуванням ISAPI-фильтра.

Основною ідеєю ASP з точки зору створення інтерфейсу програми є те, що на веб-сторінці присутні фрагменти коду, який інтерпретується веб-сервером і замість якого користувач отримує результат виконання цих фрагментів коду.

Незабаром після появи ASP були створені й інші технології, що реалізують ідею розміщення всередині веб-сторінки коду, що виконується веб-сервером. Найбільш відома з них на сьогоднішній день – технологія JSP (Java Server Pages), основною ідеєю якої є одноразова компіляція Java-коду (сервлета) при першому зверненні до нього, виконання методів цього сервлету та поміщення результатів виконання цих методів набір даних, що надсилаються в браузер.

Найновіша версія технології Active Server Pages – ASP .NET, що є ключовою в архітектурі Microsoft .NET Framework. За допомогою ASP. .

У випадку клієнтом Веб-сервера може бути не тільки персональний комп'ютер, оснащений звичайним Веб-браузером. Одночасно з широким поширенням мобільних пристроїв постала і проблема надання Веб-серверами даних, які можуть бути інтерпретовані цими пристроями. Оскільки мобільні пристрої мають характеристики, відмінні від характеристик персональних комп'ютерів (обмеженим розміром екрану, малим об'ємом пам'яті, а нерідко і неможливістю відобразити що-небудь, крім кількох рядків чорно-білого тексту), для них існують інші протоколи передачі даних (WAP – Wireless) Access Protocol) та відповідні мови розмітки (WML – Wireless Markup Language, СHTML – Compact HTML тощо). При цьому виникає завдання передачі даних на мобільний пристрій у відповідному форматі (і для цієї мети існують спеціальні сайти), або, що більш зручним, відбувається упізнання типу пристрою в момент його звернення до сервера і перетворення вихідного документа (наприклад, у форматі XML) у формат, потрібний цьому мобільного пристрою(наприклад, за допомогою XSLT-перетворення).

Іншим способом підтримки різних типів клієнтів є створення розумних серверних компонентів, які здатні генерувати різний код залежно від типу клієнта. Такий підхід, зокрема, реалізований у Microsoft ASP.

Іншим напрямком розвитку клієнтських елементів Веб-додатків стало розміщення деякої частини логіки додатка (такий як перевірка коректності даних, що вводяться) в самому Веб-браузері. Зокрема, сучасні Веб-браузери здатні інтерпретувати скриптові мови (VBScript, JavaScript), код якими, як і ASP-код, впроваджується у Веб-сторінку, але інтерпретується не Веб-сервером, а браузером і відповідно виконується на клієнтському пристрої. Крім того, сучасні браузериздатні відображати та виконувати Java-аплети – спеціальні Java-додатки, які користувач отримує у складі Веб-сторінки, а деякі з браузерів можуть також служити контейнерами для елементів керування ActiveX – спеціальних COM-серверів, що отримуються в адресному просторі браузера, також одержуваних у складі Веб-сторінки. -Сторінки. І в Java-аплетах, і в елементах керування ActiveX можна реалізувати практично будь-яку функціональність.

Зазначимо, що зі зростанням обсягу використовуваних даних та числа відвідувачів Веб-сайтів зростають і вимоги до надійності, продуктивності та масштабованості Веб-додатків. Наступним етапом еволюції подібних додатків стало відділення бізнес-логіки, реалізованої у Веб-додатку, а нерідко і сервісів обробки даних та реалізації транзакцій від його інтерфейсу. В цьому випадку в самому Веб-додатку зазвичай залишається так звана презентаційна частина, а бізнес-логіка, обробка даних та реалізація транзакцій переносяться в сервер додатківяк бізнес-об'єктів. Залежно від типу сервера додатківподібні бізнес-об'єкти можуть бути самостійно виконуються COM-серверами, CORBA-серверами, а також об'єктами COM+, що виконуються за допомогою служб компонентів Windows 2000, або об'єктами EJB (Enterprise Java Beans), що виконуються сервером додатків, що підтримує специфікацію J2EE (Java 2 Enterprise Edition). В якості механізму доступу до данихподібні об'єкти можуть використовувати OLE DB, ODBC, JDBC (це залежить від того, як реалізовано бізнес-об'єкт).

Нерідко подібні бізнес-об'єкти надають доступ до даних корпоративних інформаційних систем або реалізують якусь частину їхньої функціональності. Нерідко вони дозволяють, наприклад, інтегрувати Веб-сайт із CRM-системами (Customer Relationship Management) або ERP-системами (Enterprise Resource Planning), зберігаючи в корпоративних системах відомості про відвідувачів сайту і надаючи потенційним клієнтам відомості про наявну продукцію для здійснення замовлень.

Оскільки сучасний Інтернет – це не так засіб демонстрації присутності компанії на ринку або інструмент маркетингу, як інструмент ведення бізнесу, досить важливими стають завдання реалізації організації через Інтернет таких взаємин із клієнтами, як продаж товарів та послуг. І тут досить важливими є рішення для електронної комерції типу "підприємство-клієнт" (B2C - business-to-consumer). Не менш важливими стають і завдання інтеграції Веб-додатків з даними та додатками партнерів з метою реалізації схеми "підприємство-підприємство" (B2B – business-to-business), що дозволяє укладати торгові угоди між підприємствами, обмінюватися каталогами товарів, проводити аукціони, створювати електронні торгових майданчиків.

Зазначимо, що будучи складовоюподібного рішення, Веб-сервер повинен вміти не тільки виконувати додатки та взаємодіяти з сервером додатків, а й використовувати послуги інтеграції, послуги управління додатками та даними, і навіть послуги для розробників.

Наступним кроком еволюції Веб-додатків, окрім доступу до корпоративних даних та даних партнерів, стало отримання доступу до корпоративних програм. Для вирішення цього завдання інтеграції Веб-додатків із внутрішніми інформаційними системами підприємств та з додатками, що забезпечують взаємодію з клієнтами та партнерами, використовуються спеціальні рішення, Звані корпоративними порталами.

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

Узагальнюючи вищесказане, можна виділити основні особливості веб-архітектури [ , ]:

• відсутність необхідності використовувати додаткове програмне забезпечення на стороні клієнта – це дозволяє автоматично реалізувати клієнтську частину на всіх платформах;
• можливість підключення практично необмеженої кількості клієнтів;
• завдяки єдиному місцю зберігання даних та наявності системи управління базами даних забезпечуються мінімальні вимоги підтримки цілісності даних;
• доступність при працездатності сервера та каналів зв'язку;
• недоступність за відсутності працездатності сервера чи каналів зв'язку;
• досить низька швидкість Веб сервера та каналів передачі даних;
• щодо обсягу даних – архітектура Веб систем немає істотних обмежень.

Схематично таку архітектуру (у триланковому варіанті) можна уявити, як показано на рис. 5.9.

Мал. 5.9.

5.1.8. Сервіс-орієнтована архітектура

Вирішення багатьох описаних вище завдань, що виникають при створенні сучасних Веб-додатків, тепер починає покладатися на Веб-сервіси – програмні компоненти, що не залежать від платформи, об'єктної моделі та клієнта, які можна викликати з клієнтських Веб-додатків (а також із самих Веб-сервісів) ) через базований на протоколі HTTP та мові XML протокол SOAP . Для опису Веб-сервісів використовується XML-подібна мова WSDL, а для організації реєстрів Веб-сервісів, в яких розробники та компанії можуть шукати необхідні їм сервіси, а також публікувати дані про свої сервіси – інтерфейс UDDI.

Підтримка Веб-сервісів стала одним із головних стратегічних напрямків для багатьох компаній, що спеціалізуються на випуску серверів додатків, систем управління базами даних та засобів розробки додатків.

(SOA, service-oriented architecture)– модульний підхід до розробки програмного забезпечення, що базується на використанні сервісів (служб) зі стандартизованими інтерфейсами.

OASIS (Організація з розповсюдження відкритих стандартів структурованої інформації) визначає SOA наступним чином (OASIS Reference Model for Service Oriented Architecture V 1.0): Сервісно-орієнтована архітектура– це парадигма організації та використання розподілених інформаційних ресурсів таких як: додатки та дані, що знаходяться у сфері відповідальності різних власників, для досягнення бажаних результатів споживачем, яким може бути: кінцевий користувачабо інший додаток.

В основі SOA лежать принципи багаторазового використання функціональних елементів ІТ, ліквідації дублювання функціональності в ПЗ, уніфікації типових операційних процесів, забезпечення переведення операційної моделі компанії на централізовані процеси та функціональну організаціюз урахуванням промислової платформи інтеграції.

Компоненти програми можуть бути розподілені по різних вузлах мережі, і пропонуються як незалежні, слабко пов'язані сервіси-додатки, що замінюються. Програмні комплекси, розроблені відповідно до SOA, часто реалізуються як набір веб-сервісів, інтегрованих за допомогою відомих стандартних протоколів (SOAP, WSDL тощо)

Інтерфейс компонентів SОА-программы надає інкапсуляцію деталей реалізації конкретного компонента (ОС, платформи, мови програмування, вендора, тощо. п.) з інших компонентів. Таким чином, SOA надає гнучкий та елегантний спосіб комбінування та багаторазового використання компонентів для побудови складних розподілених програмних комплексів.

SOA добре зарекомендувала себе для побудови великих корпоративних програмних програм. Ряд розробників та інтеграторів пропонують інструменти та рішення на основі SOA (наприклад, платформи IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ІВК Юпітер, TIBCO, Diasoft).

Основними цілями застосування SOA для великих інформаційних систем, рівня підприємства, і вище є:

• скорочення витрат розробки додатків, з допомогою упорядкування процесу розробки;
• розширення повторного використання коду;
• незалежність від платформ, інструментів, мов розробки;
• підвищення масштабованості створюваних систем;
• покращення керованості створюваних систем.

Принципи SOA:

• архітектура, як така, не прив'язана до якоїсь певної технології;
• незалежність організації системи від використовуваної обчислювальної платформи (платформ);
• незалежність організації системи від мов програмування;
• використання сервісів, незалежних від конкретних додатківз одноманітними інтерфейсами доступу до них;
• організація послуг як слабопов'язаних компонентів для побудови систем.

Архітектура не прив'язана до певної технології. Вона може бути реалізована з використанням широкого спектру технологій, включаючи такі технології, як REST, RPC, DCOM, CORBA або веб-сервіси. SOA може бути реалізована, використовуючи один із цих протоколів і, наприклад, може використовувати, додатково, механізм файлової системидля обміну даними.

Головне, що відрізняє SOA, це використання незалежних сервісів, з чітко визначеними інтерфейсами, які для виконання своїх завдань можуть бути викликані якимось стандартним способом, за умови, що сервіси заздалегідь нічого не знають про додаток, який їх викличе, а додаток не знає , яким чином послуги виконують своє завдання.

SOA також може розглядатися як стиль архітектури інформаційних систем, який дозволяє створювати додатки, побудовані шляхомкомбінації слабопов'язаних та взаємодіючих сервісів. Ці сервіси взаємодіють на основі будь-якого строго певного платформо-незалежного та мовно-незалежного інтерфейсу (наприклад, WSDL). Визначення інтерфейсу приховує мовно-залежну реалізацію сервісу.

Таким чином, системи, засновані на SOA, можуть бути незалежними від технологій розробки та платформ (таких як Java, .NET і т. д.). Наприклад, послуги, написані на C#, що працюють на платформах.Net і послуги на Java, що працюють на платформах Java EE, можуть бути з однаковим успіхом викликані загальним складовим додатком. Програми, що працюють на одних платформах, можуть викликати послуги, що працюють на інших платформах, що полегшує повторне використаннякомпонентів.

, , Термінал , Сервер додатків, Сервер бази даних, Архітектура розподілених систем, , Сервіс-орієнтована архітектура.

Відкрите програмне забезпечення стало основним структурним елементом для створення деяких найбільших веб-сайтів. Зі зростанням цих веб-сайтів виникли передові практичні методи та керівні принципи їхньої архітектури. Цей розділ прагне охопити деякі ключові питання, які слід враховувати при проектуванні великих веб-сайтів, а також деякі базові компоненти, які використовуються для досягнення цих цілей.

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

1.1 Принципи побудови розподілених веб-систем

Що саме означає створення та керування масштабованим веб-сайтом або програмою? На примітивному рівні це просто з'єднання користувачів з віддаленими ресурсамичерез Інтернет. А ресурси або доступ до цих ресурсів, які розосереджені на множині серверів і є ланкою, що забезпечує масштабування веб-сайту.

Як більшість речей у житті, час, витрачений заздалегідь на планування побудови веб-служби може допомогти надалі; розуміння деяких міркувань і компромісів, що стоять позаду великих веб-сайтів, може принести плоди у вигляді розумніших рішень при створенні менших веб-сайтів. Нижче наведено деякі ключові принципи, що впливають на проектування великомасштабних веб-систем:

• Доступність:тривалість працездатного станувеб-сайту критично важлива по відношенню до репутації та функціональності багатьох компаній. Для деяких великих онлайнових роздрібних магазинів, недоступність навіть протягом декількох хвилин може призвести до тисяч або мільйонів доларів втраченого доходу. Таким чином, розробка їх постійно доступних та еластичних до відмови систем і є і фундаментальною діловою та технологічною вимогою. Висока доступність у розподілених системах вимагає уважного розгляду надмірності для ключових компонентів, швидкого відновленняпісля часткових системних відмов та згладженого скорочення можливостей у разі виникнення проблем.
• Продуктивність:Продуктивність веб-сайту стала важливим показникомдля більшості веб-сайтів. Швидкість веб-сайту впливає на роботу та задоволеність користувачів, а також ранжування пошуковими системами – фактор, який безпосередньо впливає на утримання аудиторії та дохід. У результаті ключем є створення системи, яка оптимізована для швидких відповідей та низьких затримок.
• Надійність:система повинна бути надійною, таким чином, щоб певний запитотримання даних одноманітно повертав певні дані. У разі зміни даних або оновлення, той самий запит повинен повертати нові дані. Користувачі повинні знати, якщо щось записано в систему або зберігатися в ній, то можна бути впевненим, що воно залишатиметься на своєму місці для можливості отримання даних згодом.
• Масштабованість:Коли справа доходить до будь-якої великої розподіленої системи, розмір виявляється лише одним пунктом із цілого списку, який необхідно враховувати. Не менш важливими є зусилля, спрямовані на збільшення пропускної спроможності для обробки великих обсягівнавантаження, яке зазвичай і називається масштабованість системи. Масштабованість може відноситися до різних параметрів системи: кількість додаткового трафіку, з яким вона може впоратися, наскільки легко наростити ємність пристрою, або наскільки більше інших транзакцій може бути оброблено.
• Керованість:проектування системи, яка є простою в експлуатації ще один важливий фактор. Керованість системи прирівнюється до масштабованості операцій «обслуговування» та «оновлення». Для забезпечення керованості необхідно розглянути питання простоти діагностики та розуміння виникаючих проблем, легкості проведення оновлень або модифікації, вибагливості системи в експлуатації. винятків?)
• Вартість:Вартість є важливим фактором. Вона, очевидно, може включати витрати на апаратне та програмне забезпечення, проте важливо також розглядати інші аспекти, необхідні для розгортання та підтримки системи. Кількість часу розробників, потрібна для побудови системи, обсяг оперативних зусиль, необхідних для запуску системи, і навіть достатній рівень навчання - все має бути передбачено. Вартість є загальну вартість володіння.

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

При розробці будь-якого виду веб-застосунку важливо розглянути ці ключові принципи, навіть якщо це має підтвердити, що проект може пожертвувати один або більше з них.

1.2 Основи

При розгляді архітектури системи є кілька питань, які необхідно висвітлити, наприклад: які компоненти варто використовувати, як вони поєднуються один з одним, і які компроміси можна піти. Вкладення грошей у масштабування без очевидної необхідності в ній не може вважатися розумним діловим рішенням. Проте, певна передбачливість у плануванні може суттєво заощадити час та ресурси у майбутньому.

Цей розділ присвячується деяким базовим факторам, які є найважливішими для багатьох великих веб-додатків: сервіси,
надмірність, сегментування, і обробка відмов. Кожен із цих факторів передбачає вибір та компроміси, особливо у контексті принципів, описаних у попередньому розділі. Для пояснення наведемо приклад.

Приклад: Програма хостингу зображень

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

Уявіть систему, де користувачі мають можливість завантажити свої зображення на центральний сервер, і при цьому зображення можуть вимагати через посилання на сайт або API, аналогічно Flickr або Picasa. Для спрощення опису давайте припустимо, що ця програма має дві основні завдання: можливість завантажувати (записувати) зображення на сервер і запитувати зображення. Безумовно, ефективне завантаження є важливим критерієм, проте пріоритетом буде швидка доставкана запит користувачів (наприклад, зображення можуть бути запитані для відображення на веб-сторінці або іншою програмою). Ця функціональність аналогічна тій, яку може забезпечити веб-сервер або граничний сервер мережі доставки контенту (Content Delivery Network, CDN). Сервер CDN зазвичай зберігає об'єкти даних у багатьох розташуваннях, таким чином, їхнє географічне/фізичне розміщення виявляється ближче до користувачів, що призводить до зростання продуктивності.

Інші важливі аспекти системи:

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

Інша потенційна проблема з цим дизайном полягає в тому, що у веб-сервера, такого як Apache або lighttpd зазвичай існує верхня межа кількості одночасних з'єднань, які він може обслужити (значення за умовчанням - приблизно 500, але воно може бути набагато вище), і при високому трафіку записи можуть швидко витратити цю межу. Так як читання можуть бути асинхронними або використовувати в своїх інтересах іншу оптимізацію продуктивності як gzip-стиснення або передача з поділом на порції, веб-сервер може переключити читання подачі швидше і переключитися між клієнтами, обслуговуючи набагато більше запитів, ніж максимальна кількістьз'єднань (з Apache та максимальною кількістю з'єднань, встановленою в 500, цілком реально обслуговувати кілька тисяч запитів читання за секунду). З іншого боку, записи мають тенденцію підтримувати відкрите з'єднання протягом усього часу завантаження. Так, передача файлу розміром 1 МБ на сервер могла зайняти більше 1 секунди в більшості домашніх мереж, в результаті веб-сервер зможе обробити лише 500 таких одночасних записів.

Рисунок 1.2: Поділ читання та запису

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

Перевага цього підходу полягає в тому, що ми можемо вирішити проблеми незалежно один від одного - при цьому нам не доведеться думати про необхідність запису та отримання нових зображень в одному контексті. Обидві з цих служб все ще використовують глобальний корпус зображень, але при використанні методів, що відповідають певній службі, вони здатні оптимізувати свою власну продуктивність(наприклад, поміщаючи запити в чергу, або кешуючи популярні зображення - докладніше про це йтиметься далі). Як з погляду обслуговування, і вартості кожна служба може бути масштабована незалежно за необхідності. І це є позитивним фактором, оскільки їхнє об'єднання та змішування могло б ненавмисно впливати на їхню продуктивність, як у сценарії, описаному вище.

Звичайно, робота вищезгаданої моделі буде оптимальною, у разі наявності двох різних кінцевих точок (фактично, це дуже схоже на кілька реалізацій провайдерів «хмарного» сховища та мереж доставки контенту). Існує багато способів вирішення подібних проблемі в кожному випадку можна знайти компроміс.

Наприклад, Flickr вирішує цю проблему читання-запису, розподіляючи користувачі між різними модулями, таким чином, що кожен модуль може обслуговувати лише обмежену кількість певних користувачів, і коли кількість користувачів збільшується, більше модулів додається до кластера (див. презентацію масштабування Flickr,
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). У першому прикладі простіше масштабувати апаратні засоби на основі фактичного навантаження використання (кількість читань і записів у всій системі), тоді як масштабування Flickr проситься на основі бази користувачів (проте, тут використовується припущення рівномірного використання у різних користувачів, таким чином, потужність потрібно планувати з запасом). У минулому недоступність або проблема з однією із служб призводили до неробочого стану функціональність цілої системи(наприклад, ніхто не може записати файли), тоді недоступність одного з модулів Flickr впливатиме лише на користувачів, що належать до нього. У першому прикладі простіше виконати операції з цілим набором даних - наприклад, оновлюючи службу запису, щоб включити нові метадані, або виконуючи пошук за всіма метаданими зображеннями - тоді як з архітектурою Flickr кожен модуль повинен був бути підданий оновленню або пошуку (або пошукова служба повинна бути створена, щоб сортувати ті метадані, які фактично для цього призначені).

Щодо цих систем - не існує жодної панацеї, але завжди слід виходити з принципів, описаних на початку цього розділу: визначити системні потреби (навантаження операціями «читання» або «запису» або всім одразу, рівень паралелізму, запити щодо наборів даних, діапазони, сортування і т.д.), провести порівняльне еталонне тестування різних альтернатив, зрозуміти умови потенційного збою системи та розробити комплексний план на випадок виникнення відмови.

Надмірність

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

Цей же принцип застосовний і до служб. Від відмови єдиного вузла можна захиститися, якщо передбачити невід'ємну частину функціональності для програми, що гарантує одночасну роботуйого кілька копій чи версій.

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

.

Інша ключова роль надмірності служби - створення архітектури, що не передбачає поділу ресурсів. З цією архітектурою кожен вузол в змозі працювати самостійно і, більше того, відсутність центрального «мозку», що управляє станами або координує дії інших вузлів. Вона сприяє масштабованості, оскільки додавання нових вузлів не потребує спеціальних умов чи знань. І що найважливіше, у цих системах не знайдеться жодної критично уразливої ​​точки відмови, що робить їх набагато еластичними до відмови.

.

Наприклад, у нашому додатку сервера зображення всі зображення мали б надмірні копії де-небудь в іншій частині апаратних засобів (ідеально - з різним географічним розташуванням у разі такої катастрофи, як землетрус або пожежа в центрі обробки даних), і служби отримання доступу до зображень будуть надмірними, при тому, що всі вони потенційно обслуговуватимуть запити. (Див. .)
Забігаючи вперед, балансувальники навантаження – чудовий спосіб зробити це можливим, але докладніше про це нижче.

Малюнок 1.3: Додаток хостингу зображень з надмірністю

Сегментування

Набори даних можуть бути настільки великими, що їх неможливо буде розмістити на одному сервері. Може також статися, що обчислювальні операції вимагатимуть надто великих комп'ютерних ресурсів, зменшуючи продуктивність і роблячи необхідним збільшення потужності. У будь-якому випадку у вас є два варіанти: вертикальне або горизонтальне масштабування.

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

Горизонтальне масштабування, з іншого боку, передбачає додавання більшої кількості вузлів. У разі великого набору даних це означало б додавання другого сервера для зберігання частини всього обсягу даних, а обчислювального ресурсу це означало б поділ роботи або завантаження через деякі додаткові вузли. Щоб повною мірою скористатися потенціалом горизонтального масштабування, його необхідно реалізувати як внутрішній принципрозробка архітектури системи. В іншому випадку зміна та виділення контексту, необхідного для горизонтального масштабування може виявитися проблематичною.

Найбільш поширеним методом горизонтального масштабування вважається поділ служб на сегменти чи модулі. Їх можна розподілити таким чином, що кожен логічний набір функціональності працюватиме окремо. Це можна зробити за географічними межами, або іншим критеріям таким, як користувачі, що платять і не платять. Перевага цих схем у тому, що вони надають послугу чи сховище даних із розширеною функціональністю.

У прикладі сервера зображення, можливо, що єдиний файловий сервер, використовуваний для зберігання зображення, можна замінити безліччю файлових серверів, у своїй кожен із них міститиме свій власний унікальний набір зображень. (Див. .) Така архітектура дозволить системі заповнювати кожен файловий сервер зображеннями, додаючи додаткові сервери, у міру заповнення дискового простору. Дизайн потребує схеми іменування, яка зв'яже ім'я файлу зображення з сервером, що його містить. Ім'я зображення може бути сформоване із консистентної схеми хешування, прив'язаної до серверів. Або альтернативно, кожне зображення може мати інкрементний ідентифікатор, що дозволить службі доставки при запиті зображення обробити лише діапазон ідентифікаторів, прив'язаних до кожного сервера (як індекс).

Малюнок 1.4: Додаток хостингу зображень з надмірністю та сегментуванням

Звичайно, є труднощі у розподілі даних або функціональності на безліч серверів. Одне з ключових питань - розташування даних; у розподілених системах, чим ближче дані до місця проведення операцій або точки обчислення, тим краще продуктивністьсистеми. Отже, розподіл даних на безліч серверів потенційно проблематично, так як у будь-який момент, коли ці дані можуть знадобитися, з'являється ризик того, що їх може не виявитися за місцем вимоги, серверу доведеться виконати витратну вибірку необхідної інформації по мережі.

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

.

Є, звичайно, деякі перешкоди, пов'язані з сегментуванням даних, але сегментування дозволяє виділяти кожну з проблем з інших: за даними, завантаження, за зразками використання, і т.д. у керовані блоки. Це може допомогти з масштабованістю та керованістю, але ризик все одно є. Є багато способів зменшення ризику та обробки збоїв; однак, на користь стислості вони не охоплені в цьому розділі. Якщо Ви хочете отримати більше інформації на цю тему, вам слід подивитися на блог-пост з відмовостійкості та моніторингу.

1.3. Структурні компоненти швидкого та масштабованого доступу до даних

Розглянувши деякі базові принципи у розробці розподілених систем, тепер перейдемо до складнішого моменту - масштабування доступу до даних.

Найпростіші веб-програми, наприклад, програми стека LAMP, схожі із зображенням на .

Рисунок 1.5: Прості веб-програми

Зі зростанням програми виникають дві основні складності: масштабування доступу до сервера додатків та до бази даних. У добре масштабованому дизайні програм веб-сервер або сервер програм зазвичай мінімізується і часто втілює архітектуру, що не передбачає спільного поділу ресурсів. Це робить рівень сервера програм системи горизонтально масштабованим. В результаті використання такого дизайну важка праця зміститься вниз стеком до сервера бази даних і допоміжним службам; саме на цьому шарі і вступають у гру справжні проблеми масштабування та продуктивності.

Решта цієї глави присвячена деяким найбільш поширеним стратегіям та методам підвищення продуктивності та забезпечення масштабованості подібних типів служб шляхом надання швидкого доступу до даних.

Рисунок 1.6: Спрощений веб-додаток

Більшість систем може бути спрощено до схеми на ,
яка є гарною відправною точкою для початку розгляду. Якщо у Вас є багато даних, можна припустити, що Ви хочете мати до них такий самий легкий доступ і швидкий доступ, як до коробки з льодяниками у верхній скриньці вашого столу. Хоча це порівняннянадмірно спрощено, воно вказує на дві складні проблеми: масштабування сховища даних та швидкий доступ до даних.

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

Малюнок 1.7: Доступ до певних даних

Це особливо важко, тому що завантаження терабайтів даних на згадку може бути дуже накладною і безпосередньо впливає на кількість дискових операцій введення-виведення. Швидкість читання з диска в кілька разів нижча за швидкість читання з оперативної пам'яті- можна сказати, що доступ до пам'яті з так само швидкий, як Чак Норріс, тоді як доступ до диска повільніше за чергу в поліклініці. Ця різниця у швидкості особливо відчутна для великих наборів даних; у сухих цифрах доступ до пам'яті 6 разів швидше, ніж читання з диска для послідовних операцій читання, і в 100,000 разів - для читань у випадковому порядку (див. Патології Великих Даних, http://queue.acm.org/detail). cfm?id=1563874).). Крім того, навіть з унікальними ідентифікаторами, вирішення проблеми знаходження місцезнаходження невеликої порції даних може бути таким же важким завданням, як і спроба не дивлячись витягнути останню цукерку із шоколадною начинкою із коробки із сотнею інших цукерок.

На щастя існує багато підходів, які можна застосувати для спрощення, з них чотири найбільш важливі підходи - це використання кешів, проксі, індексів та балансувальників навантаження. У частині цього розділу обговорюється те, як кожне з цих понять може бути використане для того, щоб зробити доступ до даних набагато швидше.

Кеші

Кешування дає вигоду за рахунок характерної риси базового принципу: нещодавно запитані дані мабуть знадобляться ще раз. Кеші використовуються майже на кожному рівні обчислень: апаратні засоби, операційні системи, веб-браузери, веб-програми і не тільки. Кеш схожий на короткочасну пам'ять: обмежений за обсягом, але швидше, ніж вихідне джерело даних, і містить елементи, до яких нещодавно отримували доступ. Кеші можуть існувати на всіх рівнях в архітектурі, але часто знаходяться на найближчому рівні до фронтенду, де вони реалізовані, щоб повернути дані швидко без значного навантаження бекенда.

Яким чином кеш може використовуватися для прискорення доступу до даних у нашому прикладі API? У цьому випадку існує кілька місць, які підходять для розміщення кешу. Як один з можливих варіантів розміщення можна вибрати вузли на рівні запиту, як показано на
.

Рисунок 1.8: Розміщення кешу на вузлі рівня запиту

Розміщення кешу безпосередньо на вузлі рівня запиту дозволяє локальне зберігання даних відповіді. Щоразу, коли виконуватиметься запит до служби, вузол швидко поверне локальні, кешовані дані, якщо такі існують. Якщо це не буде в кеші, то запит запиту запитає дані від диска. Кеш на одному вузлі рівня запиту міг бути розташований як у пам'яті (яка дуже швидка), так і на локальному дискувузла (швидше, ніж спроба звернення до мережевого сховища).

Малюнок 1.9: Системи кешів

Що відбувається, коли ви поширюєте кешування на багато вузлів? Як Ви бачите, якщо рівень запиту буде включати безліч вузлів, то цілком ймовірно, що кожен вузол буде і власний кеш. Однак, якщо ваш балансувальник навантаження у довільному порядку розподілить запити між вузлами, той же запит перейде до різних вузлів, таким чином збільшуючи невдалі звернення до кешу. Двома способами подолання цієї перешкоди є глобальні та розподілені кеші.

Глобальний кеш

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

Є дві стандартних формглобальних кешів, зображених у схемах. На зображена ситуація, коли кешований відповідь не знайдено в кеші, сам кеш стає відповідальним за отримання частини даних від базового сховища. На проілюстрований обов'язок вузлів запиту отримати будь-які дані, які не знайдені в кеші.

Рисунок 1.10: Глобальний кеш, де кеш відповідальний за вилучення

Рисунок 1.11: Глобальний кеш, де вузли запиту відповідальні за вилучення

Більшість додатків, що посилюють глобальні кеші, схильно використовувати перший тип, де сам кеш управляє заміщенням та даними вибірки, щоб запобігти лавинній розсилці запитів на ті ж дані від клієнтів. Однак є деякі випадки, де друга реалізація має більше сенсу. Наприклад, якщо кеш використовується для великих файлів, низький відсоток вдалого звернення в кеш призведе до перевантаження кеша буфера невдалими зверненнями в кеш; у цій ситуації це допомагає мати великий відсоток загального набору даних (або гарячого набору даних) у кеші. Інший приклад - архітектура, де файли, що зберігаються в кеші, є статичними і не повинні бути видалені. (Це може статися через основні експлуатаційні характеристики щодо такої затримки даних - можливо, певні частини даних повинні виявитися дуже швидкими для великих наборів даних - коли логіка програми розуміє стратегію заміщення або гарячі точки краще, ніж кеш.)

Розподілений кеш

Дані індекси часто зберігаються в пам'яті або десь дуже локально по відношенню до запиту клієнта. Berkeley DB (BDB) та деревоподібні структури даних, які зазвичай використовуються, щоб зберігати дані в упорядкованих списках, ідеально підходять для доступу до індексу.

Часто є багато рівнів індексів, які є картою, переміщуючи вас від одного розташування до іншого, і т.д., доки ви не отримаєте ту частину даних, яка вам необхідна. (Див.)

Малюнок 1.17: Багаторівневі індекси

Індекси можуть також використовуватися для створення кількох інших уявлень тих самих даних. Для великих наборів даних це - відмінний спосіб визначити різні фільтри та види, не вдаючись до створення багатьох додаткових копійданих.

Наприклад, припустимо, що система хостингу зображень, згадана вище, насправді розміщує зображення книжкових сторінок, і сервіс забезпечує можливість клієнтських запитів по тексту в цих зображеннях, шукаючи весь текстовий вміст по заданій темі, як пошукові системи дозволяють вам шукати по HTML- вмісту. У цьому випадку всі ці книжкові зображення використовують дуже багато серверів для зберігання файлів, і знаходження однієї сторінки для представлення користувачеві може бути складним. Спочатку зворотні індекси для запиту довільних слів та наборів слів повинні бути доступними; тоді існує завдання переміщення до точної сторінки та місця в цій книзі та вилучення правильного зображеннядля результатів пошуку. Таким чином, у цьому випадку інвертований індекс відобразився б на місцезнаходження (такому як книга B), а потім B може містити індекс з усіма словами, місцезнаходженнями та числом виникнення в кожній частині.

Інвертований індекс, який може відобразити Index1 у схемі вище, буде виглядати приблизно так: кожне слово або набір слів є індексом для тих книг, які їх містять.

Проміжний індекс виглядатиме схоже, але міститиме лише слова, місцезнаходження та інформацію для книги B. Така архітектура, що містить кілька рівнів, дозволяє кожному з індексів займати менше місця, ніж, якби вся ця інформація була збережена в один великий інвертований індекс.

І це ключовий момент у великомасштабних системах, тому що навіть будучи стислими, ці індекси можуть бути досить великими та витратними для зберігання. Припустимо, що у нас є багато книг з усього світу в цій системі, - 100,000,000 (див. запис блогу "Всередині Google Books")- і що кожна книга складається тільки з 10 сторінок (з метою спрощення розрахунків) з 250 словами на одній сторінці : це сумарно дає нам 250 мільярдів слів Якщо ми приймаємо середню кількість символів у слові за 5, і кожен символ закодуємо 8 бітами (або 1 байтом, навіть при тому, що деякі символи насправді займають 2 байти), витративши таким чином по 5 байтів на слово, то індекс , Що містить кожне слово лише один раз, вимагатиме сховище ємністю понад 1 терабайт. Таким чином, ви бачите, що індекси, в яких є ще й інша інформація, така, як набори слів, розташування даних та кількості вжитків, можуть зростати в обсягах дуже швидко.

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

Дуже важлива можливість швидко та легко знайти ваші дані, та індекси – найпростіший та найефективніший інструмент для досягнення цієї мети.

Балансувальники навантаження

Нарешті, інша критично важлива частина будь-якої розподіленої системи – балансувальник навантаження. Балансувальники навантаження - основна частина будь-якої архітектури, оскільки їхня роль полягає у розподілі навантаження між вузлами, відповідальними за обслуговування запитів. Це дозволяє безлічі вузлів прозоро обслуговувати ту саму функцію в системі. (Див. .) Їхня основна мета полягає в тому, щоб обробляти багато одночасних з'єднань і спрямовувати ці з'єднання до одного з вузлів, що запитуються, дозволяючи системі масштабуватися, просто додаючи вузли, щоб обслужити Велика кількістьзапитів.

Малюнок 1.18: Балансувальник навантаження

існує багато різних алгоритмівобслуговування запитів, включаючи вибір випадкового вузла, циклічного алгоритму або навіть вибір вузла на основі певних критеріїв, таких як використання центрального процесорачи оперативної пам'яті. Балансувальники навантаження можуть бути реалізовані як апаратні пристрої чи програмне забезпечення. Серед балансувальників навантаження на програмному забезпеченні з відкритим вихідним кодом найбільшого поширення набув HAProxy.

У розподіленій системі балансувальники навантаження часто знаходяться на «передньому краю» системи, тому всі запити, що входять, проходять безпосередньо через них. Цілком імовірно, що в складній розподіленій системі запиту доведеться пройти через кілька балансувальників, як показано на
.

Малюнок 1.19: Множинні балансувальники навантаження

Як і проксі, деякі балансувальники навантаження можуть надсилати запити по-різному, залежно від типу запиту. Вони також відомі як реверсивні (зворотні) проксі.

Керування даними, специфічними для певного сеансу користувача, є однією з проблем під час використання балансувальників навантажень. На сайті електронної комерції, коли у Вас є тільки один клієнт, дуже просто дозволити користувачам поміщати речі в свій кошик і зберігати його вміст між візитами (це важливо, тому що ймовірність продажу товару значно зростає, якщо після повернення користувача на сайт продукт все ще знаходиться у його кошику). Однак якщо користувач спрямований до одного вузла для першого сеансу, а потім до іншого вузла під час його наступного відвідування, можуть виникати невідповідності, так як новий вузол може не мати даних щодо вмісту кошика цього користувача. (Хіба ви не засмутитеся, якщо помістите упаковку напою Mountain Dew у Ваш кошик, і, коли повернетеся, її там уже не буде?) Одне з рішень може полягати в тому, щоб зробити сеанси «липкими», так щоб користувач завжди був направлений до того ж вузла. Однак використання у своїх інтересах деяких функцій надійності, таких як автоматична стійкість до відмов, буде істотно утруднено. У цьому випадку кошик користувача завжди матиме зміст, але якщо їх липкий вузол стане недоступним, то буде необхідний особливий підхід, і припущення про зміст кошика не буде більш вірним (хоча варто сподіватися, що це припущення не буде вбудовано в додаток). Звичайно, цю проблему можна вирішити за допомогою інших стратегій та інструментів, як описаних у цьому розділі, таких як служби, так і багатьох інших (як кеші браузера, cookie та перезапис URL).

Якщо у системи лише кілька вузлів, то такі прийоми, як DNS-карусель, швидше за все виявляться практичнішими, ніж балансувальники завантаження, які можуть бути дорогими та збільшувати складність системи додаванням непотрібного рівня. Звичайно, у великих системахє всі види різних алгоритмів планування та вирівнювання навантаження, включаючи як прості начебто випадкового виборуабо карусельного алгоритму, так і більше складні механізми, які беруть до уваги продуктивність особливості моделі використання системи. Всі ці алгоритми дозволяють розподілити трафік і запити, і можуть забезпечити корисні інструменти надійності, такі як автоматична стійкість до відмови або автоматичне видалення пошкодженого вузла (наприклад, коли він перестає відповідати на запити). Однак ці розширені функції можуть зробити діагностику проблем громіздкою. Наприклад, у ситуаціях з високим навантаженням, балансувальники навантаження будуть видаляти вузли, які можуть працювати повільно або перевищувати час очікування (через шквал запитів), що тільки посилить ситуацію для інших вузлів. У цих випадках важливий великий контроль тому, що навіть якщо здається, що повний системний трафік і навантаження знижуються (оскільки вузли обслуговують меншу кількість запитів) - окремі вузлиможуть виявитися навантаженими до краю.

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

Черги

До цього часу нами було розглянуто безліч способів швидкого зчитування даних. У той же час, ще однією важливою частиною масштабування рівня даних є ефективне управління записами. Коли системи прості і характеризуються мінімальними завантаженнями обробки та невеликими базами даних, запис може бути передбачувано швидким. Проте, у складніших системах цей процес може зайняти невизначено тривалий час. Так, наприклад, дані, можливо, доведеться записати в кількох місцях на різних серверах чи індексах, або система може просто перебувати під високим навантаженням. У тих випадках, коли записи або навіть будь-яке завдання займають тривалий час, досягнення продуктивності і доступності вимагає вбудовування асинхронності в систему. Поширений спосіб зробити це – організувати чергу запитів.

Малюнок 1.20: Синхронний запит

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

Такий вид синхронної поведінки може значно погіршити продуктивність клієнта; фактично простоюючи, клієнт змушений чекати, доки отримає відповідь запит. Додавання додаткових серверів з метою впоратися із навантаженням системи, по суті, не вирішує проблеми; навіть з ефективним вирівнюванням навантаження на місці, надзвичайно важко забезпечити рівномірний та справедливий розподіл навантаження необхідний для максимізації продуктивності клієнта. Більш того, якщо сервер для обробки цього запиту недоступний (або він вийшов з ладу), клієнт, підключений до нього, також перестане працювати. Ефективне вирішення цієї проблеми вимагає абстракції між запитом клієнта та фактичною роботою, яка виконується для його обслуговування.

Малюнок 1.21: Використання черг для керування запитами

Черги входу. Механізм роботи черги дуже простий: завдання приходить, потрапляє в чергу, і потім «робітники» приймають наступне завдання, як тільки у них з'являється можливість опрацювати його. (Див. .) Ці завдання можуть бути прості записи в базу даних або щось таке ж складне як генерація зображення попереднього переглядудля документів. Коли клієнт відправляє запити постановки завдань у чергу, йому більше потрібно очікувати результатів виконання; натомість запити потребують лише підтвердження факту їх отримання належним чином. Це підтвердження може бути посиланням на результати роботи, коли клієнт зажадає їх.

Черги дозволяють клієнтам працювати асинхронним способом, забезпечуючи стратегічну абстракцію запиту клієнта та відповіді на нього. З іншого боку, в синхронній системі немає ніякого диференціювання між запитом і відповіддю, і тому ними не можна керувати окремо. В асинхронній системі клієнт ставить завдання, служба відповідає повідомленням, підтверджуючи, що завдання було отримано, і потім клієнт може періодично перевіряти стан завдання, тільки запитуючи результат, як це завершилося. У той час як клієнт виконує асинхронний запит, він вільний для того, щоб займатися іншою роботою, і навіть виконувати асинхронні запити інших служб. Останнє - це приклад того, як черги та повідомлення працюють у розподілених системах.

Черги також забезпечують певний захист від припинення обслуговування та відмов. Наприклад, досить просто створити дуже стійку чергу, яка може повторити запити на обслуговування, які перестали працювати через короткочасні відмови сервера. Краще використовувати чергу, щоб реалізовувати гарантії якості обслуговування, ніж показувати клієнтам тимчасові перебої у роботі сервісу, вимагаючи складної та часто суперечливої ​​обробки помилок за клієнтів.

Черги - основний принцип в управлінні розподіленою передачею між різними частинами будь-якої великомасштабної розподіленої системи, і є багато способів їх реалізувати. Є досить багато реалізацій черг з відкритим вихідним кодом як RabbitMQ,
ActiveMQ,
BeanstalkD , але деякі також використовують служби як

масштабування

distributed computing

web-розробка

Kate Matsudaira

Додати теги

ПРОЕКТУВАННЯ НА ОСНОВІ ТЕХНОЛОГІЇ ВЕБ-СЕРВІСІВ

Спеціальність: 05. 13. 12 – Системи автоматизації проектування

Санкт Петербург 2013 2

Робота виконана у федеральній державній бюджетній освітній установі вищої професійної освіти«Санкт-Петербурзький державний електротехнічний університет «ЛЕТІ» ім. В. І. Ульянова (Леніна), кафедра системи автоматизованого проектування

Науковий керівник– доктор технічних наук, професор Дмитрович Геннадій Данилович

Офіційні опоненти:

доктор технічних наук, професор, Санкт-Петербурзький державний електротехнічний університет «ЛЕТИ» ім. В. І.

Ульянова (Леніна), кафедра автоматизованої системи обробки інформації та управління Кутузов Олег Іванович кандидат технічних наук, Відкрите Акціонерне Товариство "Концерн

«НАУКОВО-ВИРОБНИЧЕ ОБ'ЄДНАННЯ «АВРОРА»,

начальник лабораторії Пахоменков Юрій Михайлович

Провідна організація: Федеральна державна бюджетна освітня установа вищої професійної освіти «Санкт-Петербурзький національний дослідний університет інформаційних технологій, механіки та оптики»

Захист дисертації відбудеться «23» травня 2013 р. о 16.30 годині на засіданні спеціалізованої вченої ради Д212.238.02 Санкт-Петербурзького державного електротехнічного університету «ЛЕТИ» ім. В.І.

Ульянова (Леніна) за адресою: 197376, м. Санкт-Петербург, вул. Професора Попова, буд. 5.

З дисертацією можна ознайомитись у бібліотеці СПбГЕТУ Автореферат розісланий «_» 2013 р.

Вчений секретар Дисертаційної ради Д212.238.02 Н. М. Саф'янніков

ЗАГАЛЬНА ХАРАКТЕРИСТИКА РОБОТИ

Актуальністьдослідження Широке впровадження систем автоматизованого проектування у практику інженерних завдань суттєво обмежується високою вартістюліцензійне програмне забезпечення. Поруч із створення власних САПР пов'язані з величезними витратами ресурсів і може бути реалізовано в стислі рядки, оскільки розробку сучасних САПР потрібні сотні человеколет. Проблема ускладнюється також тому, що в реальних ситуаціях експлуатації багатофункціональні інтегровані САПР використовуються, як правило, вкрай неефективно, оскільки при вирішенні конкретних завданьз основного складу цих систем часто застосовується трохи більше 10-20% програмного забезпечення, найбільш специфічного кожному за підрозділи.

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

Такі незалежно керовані програми є автономними і можуть взаємодіяти один з одним у процесі виконання спільного завдання.

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

Найефективнішим методом об'єднання підсистем у розподілене додаток слід вважати організацію віддаленого виклику процедур на базі сервіс-орієнтованої архітектури з використанням веб-сервісів. Інтеграція на базі веб-сервісів при розробці децентралізованих САПР дозволяє перейти до опису інтерфейсів та взаємодій на базі XML, забезпечуючи можливість модифікації та розвитку побудованого програмного забезпечення в умовах збереження вибраного інтерфейсу. Це дозволяє внаслідок слабозв'язаності окремих підсистем забезпечувати взаємодію між сервісами на довільній платформі та проводити адаптацію існуючих додатків до змінних умов проектування.

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

додаток консольного типу, додаток віконного типу та веб-додаток.

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

Програми віконного типу дають можливість якнайкраще реалізувати графічні засобиі найкраще підходять розробки розподілених систем з урахуванням веб-сервісів. Для будь-якого вебсервісу надається можливість побудови кількох клієнтських програм з різними способами реалізації діалогової взаємодії.

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

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

Мета роботита основні завдання дослідження Ця дисертація присвячена дослідженню та розробці методів побудови платформно-незалежних розподілених САПР з використанням веб-сервісів. Для конкретної реалізації обрано завдання розробки розподіленої системи автоматизації схемотехнічного проектування.

Для досягнення поставленої мети слід вирішити такі завдання:

1. Розробити загальну методику побудови, автономного тестування та розгортання на вибраному сервері веб-сервісів Java.

програмного забезпечення веб-сервісів Java для розподіленої системи автоматизації схемотехнічного проектування

3. Дослідити та розробити методику побудови веб-сервісів Java з використанням технології стиснення даних.

4. Провести дослідження та розробку загальної методики побудови шаблонів клієнтських додатків консольного та віконного типів, а також клієнтських веб-додатків.

5. Розробити методику реалізації функціонування веб-сервісів та клієнтських додатків у гетерогенних середовищах.

Методи дослідження При виконанні поставлених завдань у дисертації використано основи загальної теоріїСАПР, торія систем моделювання, основи теорії матриць та графів.

Достовірність наукових результатів Підтверджується основними положеннями загальної теорії САПР, теорії моделювання, коректністю застосовуваного математичного апарату та результатами, отриманими при тестуванні створеного програмного забезпечення веб-сервісів та клієнтських додатків.

Нові наукові результати розподіленої САПР із використанням веб-сервісів.

2. Розроблено загальну методику реалізації, автономного тестування, а також розгортання на сервері розподіленої САПР веб-сервісів Java.

3. Досліджено та розроблено методи побудови програмного забезпечення веб-сервісів Java для вирішення типових завдань проектування електронних схем.

5. Розроблено загальну методику побудови консольних та віконних клієнтських додатків, а також клієнтських веб-додатків.

6. Розроблено методику реалізації програмного забезпечення розподіленої САПР для організації взаємодії в гетерогенних середовищах веб-сервісів та клієнтських додатків.

Основні положення, що виносяться на захист 1. Архітектура розподіленої сервіс-орієнтованої САПР на основі веб-сервісів.

2. Загальна методика висхідного проектування веб-сервісів Java 3. Методика реалізації програмного забезпечення веб-сервісів Java з урахуванням стиснення даних.

Практична цінність 1. Запропонована структура розподіленої САПР забезпечує можливість організувати взаємодію між різними веб-сервісами на обраній платформі та адаптувати додатки до умов проектування, що змінюються.

2. Побудована бібліотека допоміжних функцій на основі стиснення даних підвищує ефективність створення програмного забезпечення веб-сервісів Java для систем автоматизації схемотехнічного проектування. 3. Розроблена методика реалізації клієнт-серверної взаємодії забезпечує роботу розподілених САПР у середовищах гетерогенного типу.

4. Програмне забезпечення розробленої розподіленої системи автоматизації схемотехнічного проектування містить інваріантне ядро ​​для організації як символьного, так і чисельного етапів роботи Java-програм, яке можна використовувати як базу при побудові систем проектування широкого переліку об'єктів.

Реалізація та впровадження результатів Розроблена в дисертації розподілена САПР з використанням веб-сервісів була реалізована мовою Java з використанням платформи WTP (Web Tools Platform). Практичним результатом є платформно-незалежна розподілена схемотехнічна САПР, яка здійснює багатоваріантне моделювання нелінійних схем у стаціонарному режимі, динамічному режимі, для розрахунку частотних характеристик, а також забезпечує розрахунок чутливості передатних функцій та чутливості змінних стаціонарного режиму до варіації параметрів.

Результати дисертаційної роботи використовувалися у держбюджетних НДР на тему «Розробка моделей та методів аналізу та синтезу інтелектуальних системпідтримки прийняття рішень для управління складними розподіленими об'єктами» (шифр САПР-47 тем. плану СПбГЕТУ 2011 р.) та за темою «Математико-логічні основи побудови середовищ віртуальних інструментів» (шифр САПР-49 тем. плану СПбГЕТУ 2012 р.) Результати впроваджено в інженерну практику науково-виробничої фірми «Модем» та використовуються у навчальному процесі кафедри САПР СПБГЕТУ для вивчення методики побудови програмного забезпечення систем автоматизації схемотехнічного проектування при підготовці бакалаврів та магістрів за напрямом «Інформатика та обчислювальна техніка».

Апробація роботиОсновні положення дисертації доповідалися та обговорювалися на наступних конференціях:

1. 9-а конференція молодих вчених «Навігація та управління рухом». – СПб.;

2. 5-а міжнародна конференція «Приладобудування в екології та безпеці людини». - СПб., ГУАП;

3. XIII, XIV, XVII-а міжнародні конференції«Сучасна освіта: зміст, технології, якість». – СПб., 4. 60, 61, 63-та науково-технічні конференції професорсько-викладацького складу ГЕТУ.

ПублікаціїОсновний теоретичний та практичний зміст дисертації опубліковано у 16 ​​наукових працях, серед яких 4 статті у провідних виданнях, що рецензуються, рекомендованих у чинному переліку ВАК, 1 свідоцтво про офіційної реєстраціїпрограми для ЕОМ, зареєстрованої у Федеральній службі з інтелектуальної власності, патентів та товарних знаків.

Структура та обсяг дисертаціїДисертація містить вступ, чотири розділи основного змісту, висновок та список літератури, що містить 69 джерел. Робота викладена на 154 сторінках тексту, містить 21 малюнок і одну таблицю.

У вступідається обґрунтування актуальності теми дисертації, сформульовано цілі дослідження та наведено перелік розв'язуваних у роботі завдань.

У першому розділірозглядаються питання побудови архітектури розподілених додатків, що визначає загальну структуру, виконувані функції та взаємозв'язок окремих компонентів системи.

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

У дисертаційній роботі показано, що такий механізм найбільш ефективно забезпечується при використанні архітектури, заснованої на взаємодії між підсистемами за допомогою віддаленого виклику процедур, що використовується для взаємообміну даними та виконання певних дій. У випадку, якщо програма потребує отримання або зміни будь-якої інформації, що підтримується іншою програмою, вона звертається до неї через виклик деякої функції.

Для побудови розподілених САПР у дисертації пропонується використовувати сервіс-орієнтовану архітектуру (SOA) на основі модульної структури програмного забезпечення та стандартизованих інтерфейсів. SOA використовує уніфікацію основних операційних процесів, принципи неодноразового застосування функціональних елементів, організацію з урахуванням платформи інтеграції. Хоча архітектура SOA не пов'язана з певною технологією віддаленого виклику процедур, програмні підсистеми, розроблені згідно з SOA, зазвичай реалізуються як сукупність веб-сервісів, пов'язаних за допомогою основних протоколів (SOAP, WSDL).

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

Веб-сервіси засновані на XML-стандарті та надають можливість користувачам забезпечити взаємодію із зовнішніми системними засобами через мережу Інтернет, будучи слабопов'язаними компонентами системи програмного забезпечення, які доступні для використання через Інтернет-протоколи. У дисертаційній роботі показано, що при практичній реалізації розподілених САПР з використанням веб-сервісів істотну увагу слід приділяти правильному поділу функціональних обов'язків, що покладаються на основний клієнтський додаток та на веб-сервіс, що взаємодіє з цим додатком.

Конкретна методика реалізації веб-сервісів залежить від обраного мови програмування. У роботі показано, що перевагу при виборі мови програмування для побудови веб-сервісів слід надати мові Java, яка найбільш повно забезпечує платформну незалежність реалізованих рішень. Важливою обставиною на користь такого вибору є наявність потужної інструментальної підтримки розробки веб-орієнтованих додатків на Java, що забезпечується середовищем WTP (Web Tools Platform).

У дисертаційній роботі проведено порівняльний аналіз двох основних методів побудови веб-сервісів Java – висхідного (Bottom-Up), коли спочатку створюється Java-клас веб-сервісу, а потім на його основі генерується WSDL-документ та низхідного (Top-Down), коли спочатку створюється потрібний документ WSDL, а потім на його базі формується код реалізації веб-сервісу. На підставі порівняльної оцінки показано, що проектування веб-сервісів слід виконувати висхідним методом, оскільки при цьому WSDL-документ формується на підставі створеного заздалегідь Java-класу, в якому описані всі параметри, що передаються методу вебсервісу, і значення, що повертаються цим методом. При цьому вся наявна в Java-класі інформація автоматично перетворюється на відповідний WSDL-документ, зміст якого точно відповідає базовій структурі специфікації WSDL і основним характеристикам методу веб-сервісу, що викликається, що забезпечує повну достовірність інформації, що міститься в WSDL-документі.

Для можливості практичної реалізації проектування вебсервісів висхідним методом у дисертації пропонується методика побудови динамічного веб-проекту та Java-класу реалізації веб-сервісу, що міститься в ньому, з описом викликуваних методів, серед яких, крім основних робочих методів, обов'язково повинен утримуватися допоміжний метод без аргументів, який повертає рядкову змінну, де містяться всі відомості про основні методи, що забезпечують функціонування веб-сервісу та опис форматів параметрів, що передаються, а також повертаються даних, що забезпечує самодокументованість веб-сервісу та можливість створення та постійного вдосконалення клієнтських додатків незалежно від розробника веб-сервісу.

У дисертації наводиться методика організації виклику інформаційного методу веб-сервісу безпосередньо з інтегрованого середовища розробки Java-додатків, в якій за URL-адресою веб-сервісу можна отримати доступ до Soap-відповіді інформаційного методу, та до змісту його значення, що повертається.

У другому розділірозглядаються методи побудови веб-сервісів розподіленої САПР, за допомогою якої здійснюється розрахунок нелінійних схем у стаціонарному режимі, розрахунок схемних функцій лінійних та лінеаризованих схем для частотної області, виконується розрахунок нелінійних схем у динамічних режимах. Крім цього, число включаються до розподіленої системи підсистем входить веб-сервіс для розрахунку чутливості схемних функцій в частотній області, і вебсервіс для розрахунку чутливості змінних стаціонарного режиму нелінійних схем до варіації параметрів. Як компоненти проектованих на базі розроблених веб-сервісів схем можна використовувати двополюсники типу R, C, L, лінійні частотно-залежні керовані джерела, нелінійні керовані джерела, трансформатори, біполярні та уніполярні транзистори, операційні підсилювачі, а також джерела струму і напруги, що задають.

Основою таких методів є загальна структура математичного опису систем схемотехнічного проектування. У дисертації дається порівняльна оцінка можливих способів вибору координатного базису для формування опису лінеаризованих схем, при цьому перевага надається розширеному базису вузлових потенціалів. Зазначається, що поряд з безперечними перевагами, суттєвим обмеженням цього базису є неможливість математичного опису компонентів схеми рівняннями в неявній формі, що часто ускладнює, а іноді унеможливлює його практичне застосування. Для реалізації можливості опису компонентів схеми рівняннями у неявній формі в роботі наводиться модифікована версія розширеного базису вузлових напруг, яка береться за основу під час побудови програмного забезпечення веб-сервісів.

При розгляді питань, пов'язаних із побудовою веб-сервісів для задач розрахунку частотних властивостей електронних схем, наголошується, що завдання цього типу можна поділити на дві групи. У першу групу входять завдання розрахунку лінійних схем, параметри компонентів яких мають фіксовані значення, що не залежать у процесі вирішення задачі від значень координат робочих точок компонентів. Друга група пов'язана з розрахунком частотних характеристик лінеаризованих схем, параметри яких залежать від координат робочих точок компонентів і ці координати, а також значення відповідних їм лінеаризованих параметрів повинні бути попередньо розраховані.

Для вирішення першої групи завдань розрахунку частотних властивостей електронних схем під час виконання дисертаційної роботи побудовано вебсервіс ModService_Java. Для можливості роботи з комплексними числами при його побудові створено клас Complex, оскільки на момент виконання цієї роботи такий клас не входить до складу стандартних засобів API Java. Клас Complex містить конструктори та допоміжні функції для обробки комплексних даних та все необхідні функціїдля виконання арифметичних та логічних операційз комплексними числами, оскільки у мові Java відсутня оператор перевизначення цих операцій. Веб-сервіс отримує як аргументи опис компонентів схеми та директиви розрахунку та повертає масив з описом результатів розрахунку частотних характеристик.

Для розрахунку стаціонарного режиму не лінійних систему дисертації пропонується загальна методика побудови програмного забезпечення відповідних веб-сервісів, реалізована під час створення веб-сервісу StaticService_Java. Веб-сервіс також отримує як аргументи опис компонентів схеми та директиви розрахунку та повертає масив з описом результатів розрахунку базисних змінних та координат стаціонарного режиму для всіх нелінійних компонентів (діоди, біполярні транзистори, Уніполярні транзистори, операційні підсилювачі, нелінійні керовані джерела). Нульовий елемент масиву, що повертається, резервується для передачі на клієнтську сторону інформації у разі відсутності збіжності обчислювального процесу, що вимагає зміни директив розрахунку та повторного звернення до методу веб-сервісу.

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

При розробці методики побудови веб-сервісу для розрахунку динамічних режимів нелінійних систем використовується математичний опис схеми в модифікованому розширеному базисі вузлових потенціалів, що дозволяє отримати найбільш загальну форму системи рівнянь алгебро-диференціального типу. Виняток похідних із компонентних рівнянь виконується на основі формул корекції, які випливають із багатокрокових неявних методів вищих порядків, при цьому прийнятий як основний метод Гіру другого порядку з можливістю збільшення його порядку. Як компоненти, з рівнянь яких виключаються похідні, виступають двополюсники типу С і L, діоди, трансформатори, біполярні та уніполярні транзистори, операційні підсилювачі, а також частотно-залежні керовані джерела. Для обчислення значень автономних джерел, що зберігають значення відповідних змінних на попередніх кроках, побудовано допоміжні функції дискретизації dis_cmp для всіх перерахованих компонент cmp з частотно-залежними властивостями.

Розроблена методика реалізована при побудові веб-сервісу Dyn2Service_Java, який повертає на клієнтську сторону масив із описом результатів розрахунку динамічних характеристик.

У третьому розділірозглянуто питання побудови веб-сервісів із використанням методів стиснення даних. Актуальність цих питань визначається тим, що структура реальних систем характеризується слабким зв'язком компонентів між собою, результатом чого є їхній математичний опис у вигляді матриць розрідженого типу, в яких лише незначна частина елементів має змістовну інформацію.

Ця обставина ставить завдання зміни загальноприйнятих підходів до формування та вирішення рівнянь з метою економії пам'яті та підвищення швидкодії, що має вирішальне значення для функціонування веборієнтованих систем.

У дисертаційній роботі проведено аналіз ефективності можливих методів перетворення даних на компактні масиви, на підставі якого зроблено висновок про доцільність вибору методу, заснованого на використанні стиснення за Шерманом і що вимагає реалізації двоетапної процедури виконання символьної та чисельної обробки даних. Істотною перевагою прийнятої двоетапної процедури є поділ її на дві незалежні частини символьного та чисельного етапу. Оскільки всі реальні завдання проектування схем пов'язані з багатоваріантним розрахунком схеми постійної структури, то символьний етап виконується кожної структури єдиний раз, тоді як чисельний етап реалізується десятки, сотні, котрий іноді тисячі раз.

Однак, двоетапна процедура характеризуються досить складною логікою побудови програмного коду і при переході до опису на основі стиснення даних потрібна істотна зміна раніше створеного повного опису завдання.

У дисертації розглянуто блок-схему реалізації двоетапної обробки даних при побудові Java-додатків, згідно з якою на етапі символьного аналізу формується індексна матриця цілого типу, для якої проводиться символьний етап LU-факторизації, де виконується впорядкування рядків (стовпців) з метою мінімізації числа знову елементів, що з'являються з ненульовими значеннями. На заключному етапі символьного етапу здійснюється побудова координатних матриць, в яких міститься інформація про структуру індексної матриці, внаслідок чого цю матрицю можна видалити.

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

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

Другий підхід використовується у разі відсутності прототипу для розробки методу на основі стиснення даних. При цьому як символьний, так і чисельний етап реалізуються в умовах відсутності повного опису схеми, що моделюється, у формі розрідженої матриці, що істотно ускладнює процес програмування. У дисертації другий підхід застосовано для побудови веб-сервісів, що реалізують розрахунок чутливості схемних передач та змінних стаціонарного режиму схем до варіації параметрів їх компонентів.

Для розрахунку чутливості частотних характеристик схемних функцій побудовано веб-сервіс VaryService, який містить метод, що базується на диференціюванні рівнянь, та метод, в основі якого лежать приєднані схеми.

Заснований на диференціюванні рівнянь метод веб-сервісу VaryService дозволяє розрахувати значення абсолютної та відносної векторної чутливості схемних функцій для частотної області до вибраного параметру, що варіюється, для всієї сукупності базисних змінних. В якості параметрів, що варіюються, можуть виступати значення опору, ємності, або індуктивності довільного двополюсника схеми типу R, C або L, і параметри передач керованих частотнозалежних джерел типу ІТУН, ІНУН, ІТУТ або ІНУТ.

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

Для розрахунку чутливості змінних, що задають стаціонарний режим нелінійних схем, до варіації їх параметрів, розроблено веб-сервіс StVaryService, який також містить два методи, один з яких заснований на диференціюванні рівнянь, а другий на приєднаній схемі. Як параметр, що варіюється, в обох методах можуть виступати значення опорів резисторів і параметри передачі керованих джерел типу ІТУН, ІНУН, ІТУТ або ІНУТ.

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

Практична реалізація методу заснована на диференціюванні рівнянь компонентів, що варіюються, з використанням результатів розрахунку базисних змінних стаціонарного режиму нелінійної схеми.

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

У четвертому розділі розглядаються методи побудови клієнтських додатків, що забезпечують взаємодію з веб-сервісами, які після закінчення їх побудови в інструментальному середовищі розробки Java-додатків повинні бути розгорнуті на сервері розподіленої САПР. Для розгортання вебсервісу необхідно знати його основні характеристики, серед яких ім'я сервісу, клас, ім'я методів, тип WSDL-документа.

Відповідна інформація про розроблені та описані вище веб-сервіси для розподіленої системи схемотехнічного проектування наводиться в дисертації, та в інформаційних методах з ім'ям getInf, які входять до всіх розроблених веб-сервісів. У роботі пропонується проста методика безпосереднього розгортання на сервері веб-сервісів, і розглядаються можливі способиімпортування на клієнтський бік файлу WSDL. На основі порівняльного аналізу в роботі показується, що коректність виконання операції доставки WSDL файлу з віддаленого веб-сервісу до клієнтської програми найбільш ефективно може бути забезпечена шляхом використання інструменту Web Services Explorer, і встановлюється найбільш оптимальна послідовність імпортування файлу WSDL в початковий каркас клієнтської програми.

Після доставки WSDL-файлу в проект клієнтської програми подальші перетворення початкового каркасу проекту в закінчений клієнтський додаток пропонується проводити у два етапи. Першим етапом такого перетворення є створення проксі-об'єкта в початковому каркасі проекту, а другим етапом – формування класів, що містять методи, що підтримують функціонування проксі-об'єкта та взаємодію віддаленого сервісуз клієнтським додатком. Реалізація першого етапу зводиться до доповнення проекту операторами, що створюють проксі-об'єкт, другий етап виконується за допомогою інструменту Web Services платформи WTP, найбільш ефективні способи використання якого наводяться в дисертації.

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

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

Клієнтські програми віконного типу надають найбільші можливостідля функціонування в розподіленій САПР, оскільки дають можливість найбільше використовувати графічні елементи. Для даного веб-сервісу можна побудувати різні варіанти клієнтських програм з різними способами організації діалогу з користувачем та відображення результатів розрахунку. Діяльність встановлено мінімальний набір діалогових коштів, які забезпечують повноцінне взаємодію Космосу з сервісом. Такий набір містить віконне меню та сукупність діалогових вікон для введення даних та відображення результатів розрахунку, а також управління директивами розрахунку.

У дисертації запропоновано методику побудови клієнтських веб-додатків, на базі якої розроблено шаблони JSP-сторінок, що виконують функції вибору та переходу до інших сторінок, введення деякої сукупності змінних з переходом до початкової сторінки, циклічного введення деякої сукупності змінних з переходом до наступної сторінки відповідно до значень цих змінних , виклику необхідного веб-сервісу та результатів його роботи. Використання клієнтських веб-програм дозволяє розмістити весь програмний код розподіленої системи в мережі, при цьому, залежно від прийнятого способу розміщення в мережі клієнтського та серверного додатків, виклик сервісу можливий або з однієї, або з декількох веб-сторінок.

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

У дисертації побудовано методику організації процесу розгортання клієнтських додатків, метою якого є забезпечення можливості запуску клієнтського додатка загальносистемними засобами без використання інструментального середовища розробки додатка, при цьому як для клієнтських додатків консольного типу, так і для клієнтських додатків віконного типу, запуск повинен здійснюватися через командний рядок, а для веб-застосунків – з броузера. Інформація про місце розташування веб-сервісу передається через об'єкт проксі-класу, для якого має бути попередньо здійснено налаштування на відповідну URL-адресу.

У роботі наголошується, що при розгортанні консольної програми має бути попередньо здійснено зміну кодової сторінки проекту, для чого необхідно перейти від кодової сторінки, в якій текст з кирилицею відображається у всіх інтегрованих інструментальних системах, що працюють з Java-кодом, до кодової сторінки, в якій текст з кирилицею буде нормально відображатися у вікні командного рядка.

У дисертації показано, що при використанні клієнтських веб-додатків залежно від вибраної структури зв'язку між клієнтським та серверним комп'ютером, інформація про розташування веб-сервісу може передаватися як через об'єкт проксі-класу, так і через URL-адресу, що вводиться з браузера. Відповідні методи взаємодії клієнта з сервісом під час реалізації їх функціональних завдань обраної структури зв'язку також розглянуті у роботі.

Стандартизація SOAP надає можливість з'єднання між собою слабко пов'язаних додатків незалежно від платформи їх реалізації, що дозволяє при використанні веб-сервісів забезпечити ефективне та оптимальне використання широкого ряду гетерогенних, слабко пов'язаних ресурсів у розподілених додатках. У дисертації наводиться загальна методика побудови програмного забезпечення для здійснення взаємодії об'єкта проксі-класу програми середовища .NET із сервісом середовища Java/J2EE. На підставі цієї методики реалізовано організацію взаємодії розроблених веб-сервісів Java з клієнтськими Windows додатками, побудованими в середовищі .NET на основі мови C#.

Можливість функціонування розподіленої САПР у гетерогенних середовищах суттєво розширює сферу її застосування.

В ув'язненнісформульовано основні наукові та практичні результати, отримані на основі проведених у дисертації досліджень.

Основні результатироботи 1. Розроблено архітектуру розподіленої сервісорієнтованої САПР на основі веб-сервісів, що відрізняється децентралізованою структурою, платформною незалежністю та можливістю проведення безперервної модернізації окремих підсистем для адаптації їх властивостей до умов проектування, що змінюються.

2. Реалізовано загальну методику побудови висхідним методом веб-сервісів Java та відповідних WSDL-документів, а також доставки їх на сервер розподіленої САПР після проведення автономного тестування в середовищі розробки.

3. Розроблено методику побудови програмного забезпечення веб-сервісів Java для вирішення типових завдань моделювання безперервних систем під час автоматизованого проектування електронних схем.

4. Побудовано бібліотеку допоміжних функцій для реалізації програмного забезпечення веб-сервісів Java на основі стиснення даних.

5. Розроблено загальну методику побудови шаблонів консольних та віконних клієнтських додатків розподіленої системи автоматизації схемотехнічного проектування та реалізовано організацію функціонування розподіленої САПР із клієнтськими веб-додатками.

6. Розроблено методику побудови розподілених САПР, що забезпечує взаємодію веб-сервісів Java та клієнтських додатків довільного типуу гетерогенних середовищах.

1. Анісімов Д.А. Побудова систем автоматизованого проектування з урахуванням Web-сервісів [Текст] / Анісімов Д.А. Гридін В.М., Дмитрович Г.Д. // Автоматизація у промисловості – 2011. – №1 – С. 9-12.

2. Анісімов Д.А. Побудова систем автоматизованого проектування на основі Web-технологій [Текст]/Грідін В.М., Дмитрович Г.Д., Анісімов Д.А // Інформаційні технології – 2011. – №5. - С. 23-27.

3. Анісімов Д.А. Побудова веб-сервісів систем автоматизації схемотехнічного проектування [Текст] / Гридін В.М., Дмитрович Г.Д., Анісімов Д.А // Інформаційні технології та обчислювальні системи - 2012. - №4. - С. 79-84.

4. Анісімов Д.А. Методи побудови систем автоматизації схемотехнічного проектування на основі веб-сервісів. - СПб.: Вид-во СПбГЕТУ «ЛЕТИ», - С. 56-61.

5. Анісімов Д.А. Доступ до Web-ресурсів у САПР систем навігації та управління [Текст]/Ларистов Д.А., Анісімов Д.А. // Гіроскопія та навігація. 2007. № 2. -С. 106.

Web-сервіси- нове слово у технології розподілених систем. Специфікація Open Net Environment (ONE)корпорації Sun Microsystems та ініціатива. Net корпорації Microsoft забезпечують інфраструктури для написання та розгортання Web-сервісів. У теперішній моментє кілька визначень Web-сервісу. Web-сервісом може бути будь-яка програма, що має доступ до Web, наприклад, Web-сторінка з динамічним вмістом. У вужчому сенсі Web-сервіс - це додаток, який надає відкритий інтерфейс, придатний використання іншими додатками в Web. Специфікація ONE Sun вимагає, щоб Web-сервіси були доступні через HTTP та інші Web-протоколи, щоб дати можливість обмінюватися інформацією за допомогою XML-повідомлень і щоб їх можна було знайти через спеціальні сервіси- сервіси пошуку. Для доступу до Web-сервісів розроблено спеціальний протокол - Simple Object Access Protocol (SOAP), який представляє засоби взаємодії з урахуванням XML багатьом Web -сервисов. Web-сервіси особливо привабливі тим, що можуть забезпечити високий рівень сумісності між різними системами.

Гіпотетичний Web-сервіс, розроблений відповідно до архітектури ONE Sun, може набувати форми, в якій реєстр сервісів публікує опис Web-сервісу у вигляді документа .

Величезний потенціал Web-сервісів визначається не технологією, використаною для їх створення. HTTP, XML та інші протоколи, що використовуються Web-сервісами, не нові. Функціональна сумісністьі масштабованість Web-сервісів передбачає, що розробники можуть швидко створювати великі додатки та більші Web-сервіси з менших Web-сервісів. Специфікація Sun Open Net Environment описує архітектуру для створення інтелектуальних Web-сервісів.Інтелектуальні Web-сервіси залучають загальне операційне оточення. Спільно використовуючи контекст, інтелектуальні Web-сервіси можуть виконувати стандартну автентифікацію для фінансових транзакцій, надавати рекомендації та вказівки залежно від географічного розташування компаній, що беруть участь у електронному бізнесі.

Для того щоб створити програму, що є Web-сервісом, необхідно застосувати цілу низку технологій.

Взаємозв'язок цих технологій умовно представлений на рис. 10.1.

Мал. 10.1.

По суті, Web-сервіси є одним із варіантів реалізації компонентної архітектури, коли додаток розглядається як сукупність компонентів, взаємодіючих друг з одним. Як уже неодноразово говорилося, взаємодія компонентів, що виконуються на різних платформах, являє собою досить складне завдання, зокрема, вимагає розробки комунікаційного протоколу , що враховує особливості передачі між різними платформами. Однією з основних ідей, покладених в основу розглянутої технології Web-сервісів, є відмова від бінарного комунікаційного протоколу. Обмін повідомленнями між компонентами системи здійснюється за допомогою передачі XML-повідомлень. Оскільки XML-повідомлення є текстовими файлами, транспортний протокол передачі може бути найрізноманітніший - XML-повідомлення можна передавати за HTTP-, SMTP-, FTP-протоколами, причому використання різних транспортних протоколів прозоро для додатків. Як мовилося раніше, протокол, який би можливість взаємодії Web -сервисов, називається SOAP (Simple Object Access Protocol). Він визначений на основі XML. SOAPзабезпечує взаємодію розподілених систем, незалежно від об'єктної моделі або використовуваної платформи. Дані в рамках SOAPпередаються як XML -документів особливого формату. SOAPне нав'язує будь-якого певного транспортного протоколу. Однак у реальних додаткахнайчастіше реалізується передача SOAP-повідомлень за протоколом HTTP. Також широко поширене використання як транспортного протоколу SMTP, FTP і навіть "чистий" TCP . Отже, SOAPвизначає механізм, з допомогою якого Web -сервіси можуть викликати функції одне одного. В якомусь сенсі робота цього протоколу нагадує виклик віддаленої процедури - сторона, що викликає, знає ім'я Web-сервісу, ім'я його методу, параметри, які метод приймає, оформляє виклик цього методу у вигляді SOAP-повідомлення та відсилає його Web-сервісу.

Проте описаний підхід годиться лише тому випадку, якщо заздалегідь відомі " сигнатури " методів, які реалізує Web -сервис. Але що робити, якщо це не так? Для вирішення цієї проблеми модель Web-сервісу введено додатковий шар - шар опису інтерфейсів сервісів. Цей шар представлений у вигляді опису WSDL.

Згідно з визначенням W3C, " WSDL - формат XMLдля опису мережевих сервісівяк набору кінцевих операцій, що працюють за допомогою повідомлень, що містять документно-орієнтовану або процедурно-орієнтовану інформацію". Документ WSDLповністю визначає інтерфейс Web-сервісу із зовнішнім світом. Він надає інформацію про послуги, які можна отримати, скориставшись методами сервісу, та способи звернення до цих методів. Таким чином, якщо сигнатура методу Web-сервісу точно не відома (наприклад, вона змінилася з часом), у цільового Web-сервісу може бути запрошено WSDL-Опис - файл, в якому ця інформація буде міститися.

Наступним шаром технології є сервіс Universal Description, Discovery and Integration (UDDI).Ця технологія передбачає ведення реєстру Web-сервісів. Підключившись до цього реєстру, споживач зможе знайти Web-сервіси, які найкраще підходять для вирішення його завдань. Технологія UDDIдає можливість пошуку та публікації потрібного сервісу, причому ці операції можуть бути виконані як людиною, так і іншим Web-сервісом або спеціальною програмою-клієнтом. UDDI, своєю чергою, також є Web -сервис.

Таким чином, Web-сервіси є ще однією реалізацією системного програмного забезпечення проміжного шару. Відмінною рисою цієї технології є її незалежність від використовуваного програмного забезпечення. апаратного забезпечення, а також використання широко застосовуваних відкритих стандартів(таких як XML) та стандартних комунікаційних протоколів.

В даний час Web-сервіси є дуже активно технологією, що просувається і позиціонуються як засіб вирішення цілого ряду завдань.

Слід зазначити, що з їх застосуванням можуть будуватися і так звані "стандартні" додатки, де як Web-сервіс оформляється серверна частина.

Простий протокол доступу до об'єктів (SOAP)

Базовим протоколом, що забезпечує взаємодію у середовищі Web-сервісів, є протокол

Глава 1. Загальна методика побудови розподілених систем з урахуванням веб-сервісів

1.1. Сервіс-орієнтована архітектура.

1-2. Методика побудови веб-сервісів Java.

1-3. Попереднє тестування веб-сервісів.

Розділ 2. Методи побудови програмного забезпечення веб-сервісів розподіленої системи автоматизації схемотехнічного проектування

2-1. Математичне забезпечення систем автоматизації схемотехнічного проектування.

2-2. Веб-сервіс для проектування лінійних систем у частотній області.

2-3. Веб-сервіс для розрахунку стаціонарного режиму нелінійних систем.

2-4. Сервіс-орієнтована інтегрована система для частотного аналізу лінеаризованих схем.

2-5. Веб-сервіс для розрахунку нелінійних систем динамічного режиму.

Глава 3. Побудова веб-сервісів з урахуванням методів стиснення даних.

3-1. Методи усунення нульових елементівпри зберіганні та обробці матриць.

3-2. Методика розробки модифікованих версій веб-сервісів.

3-2-1. Модифікація символьному етапі.

3-2-2. Модифікація на чисельному етапі.

3-3. Веб-сервіс для розрахунку чутливості схемних функцій для варіації параметрів.

3-3-1. Побудова методу веб-сервісу з урахуванням диференціювання рівнянь.

3-3-2. Метод веб-сервісу на основі приєднаної схеми.

3-4. Веб-сервіс для розрахунку чутливості змінних стаціонарного режиму.

3-4-1. Побудова способу веб-сервісу для розрахунку векторної чутливості змінних.

3-4-2. Метод веб-сервісу для розрахунку скалярної чутливості змінних.

Глава 4. Методи побудови клієнтських програм розподілених САПР.

4-1. Методика побудови клієнтських додатків з урахуванням WSDL-документа.

4-1-1. Розгортання веб-сервісів на сервері Apache Tomcat.

4-1-2. Методика імпортування файлу WSDL та побудови каркасу клієнтської програми.

4-2. Клієнтські програми розподіленої системи схемотехнічного проектування.

4-2-1. Методика побудови консольних клієнтів.

4-2-2. Методика побудови віконних клієнтських програм.

4-2-3. Методика побудови клієнтських веб-додатків.

4-3. Розгортання клієнтських Java-додатків.

4-3-1. Розгортання клієнтських Java-додатків, які запускаються з командного рядка.

4-3-2. Розгортання клієнтських Java-застосунків, що запускаються з веб-броузера.

4-4. Організація взаємодії клієнтських додатків з веб-сервісами в гетерогенних середовищах.

Введення дисертації (частина автореферату) на тему "Дослідження та розробка методів побудови розподілених систем автоматизованого проектування на основі технології веб-сервісів"

Широке впровадження систем автоматизованого проектування у практику вирішення інженерних завдань суттєво обмежується високою вартістю ліцензійного програмного забезпечення САПР. Разом з тим створення власних систем автоматизованого проектування пов'язане з величезними витратами ресурсів і не може бути реалізовано в стислий рядок, оскільки на розробку сучасних САПР потрібні сотні людиноліт. Проблема ускладнюється також і тим, що в реальних ситуаціях експлуатації багатофункціональні інтегровані САПР (наприклад, Micro-Cap 7, PSPICE, DISPC) використовуються, як правило, вкрай неефективно, оскільки в процесі вирішення конкретних завдань із базового програмного забезпечення цих систем часто застосовується не більше 10-20% програмного забезпечення, найспецифічнішого для кожного підрозділу.

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

Найбільш ефективним методом інтеграції окремих підсистем у розподілене додаток є віддалений виклик процедур на основі сервіс-орієнтованої архітектури з використанням технології веб-сервісів. Інтеграція на основі веб-сервісів при розробці децентралізованих САПР дозволяє перейти до опису інтерфейсів та взаємодій на основі XML, забезпечуючи можливість модифікації та розвитку програмного забезпечення за умови збереження вибраного інтерфейсу. Це дозволяє внаслідок слабозв'язаності окремих підсистем забезпечувати взаємодію між різними сервісами на будь-якій платформі та проводити адаптацію існуючих додатків до змінних умов проектування.

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

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

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

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

Для будь-якого типу клієнтської програми виклик веб-сервісів здійснюється однаковим способом, при цьому для кожного веб-сервісу можна використовувати будь-які способи побудови клієнтських додатків, написаних різними мовами програмування. У разі потреби такі клієнтські програми можна легко модифікувати відповідно до умов проектування, що змінюються, можливе також розширення веб-сервісу за рахунок включення до його складу додаткових методів.

Метою цієї дисертаційної роботи є дослідження та розробка методів побудови платформно-незалежних розподілених систем автоматизованого проектування на основі сервіс-орієнтованої архітектури з використанням технології веб-сервісів. Для конкретної реалізації обрано завдання побудови розподіленої системи автоматизації схемотехнічного проектування, яка має здійснювати багатоваріантне моделювання лінійних та нелінійних електронних схем у стаціонарному режимі, у частотній області, у часовій області, а також виконувати розрахунок чутливості схемних (передаточних) функцій та чутливості змінних стаціонарного режиму до варіації параметрів.

Для досягнення поставленого завдання необхідно:

Розробити загальну методику побудови, автономного тестування та розгортання на сервері веб-сервісів Java.

Виконати дослідження та розробку програмного забезпечення веб-сервісів Java для розподіленої системи автоматизації схемотехнічного проектування.

Дослідити та розробити методику побудови веб-сервісів Java на основі технології стиснення даних.

Провести дослідження та розробку загальної методики побудови шаблонів клієнтських програм консольного та віконного типів, а також клієнтських веб-додатків.

Розробити методику реалізації функціонування веб-сервісів у гетерогенних середовищах.

Дисертаційна робота містить вступ, чотири розділи основного змісту, висновок та список літератури, що містить 69 найменувань. Робота викладена на 154 сторінці тексту, і включає 21 малюнок та одну таблицю.

Висновок дисертації на тему "Системи автоматизації проектування (за галузями)", Анісімов, Денис Андрійович

Основні результати дисертаційної роботи зводяться до:

1. Розроблено архітектуру розподіленої сервіс-орієнтованої САПР на основі веб-сервісів, що відрізняється децентралізованою структурою, платформною незалежністю та можливістю проведення безперервної модернізації окремих підсистем для адаптації їх властивостей до умов проектування, що змінюються.

2. Реалізовано загальну методику побудови висхідним методом веб-сервісів Java та відповідних WSDL-документів, а також доставки їх на сервер розподіленої САПР після проведення автономного тестування в середовищі розробки.

3. Розроблено методику побудови програмного забезпечення веб-сервісів Java для вирішення типових задач моделювання безперервних системпід час автоматизованого проектування електронних схем.

4. Побудовано бібліотеку допоміжних функцій для реалізації програмного забезпечення веб-сервісів Java на основі стиснення даних.

5. Розроблено загальну методику побудови шаблонів консольних та віконних клієнтських додатків розподіленої системи автоматизації схемотехнічного проектування та реалізовано організацію функціонування розподіленої САПР із клієнтськими веб-додатками.

6. Розроблено методику побудови розподілених САПР, що забезпечує взаємодію веб-сервісів Java та клієнтських додатків довільного типу в гетерогенних середовищах.

Висновок

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

У роботі показано, що використання веб-сервісів при побудові програмного забезпечення децентралізованих САПР дозволяє здійснити опис інтерфейсів та взаємодій на базі XML, надаючи можливість модифікації та розвитку системи за умови збереження необхідного інтерфейсу. Це дозволяє організувати взаємодію між сервісами на будь-яких платформах і адаптувати використовувані додатки до умов проектування, що змінюються.

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

Для організації ефективної взаємодії користувача з веб-сервісом розроблено загальна методикапобудови шаблонів клієнтських додатків консольного та віконного типів, а також клієнтських веб-додатків та реалізовано функціонування веб-сервісів у гетерогенних середовищах.

Список літератури дисертаційного дослідження кандидат технічних наук Анісімов, Денис Андрійович, 2013 рік

1. Автоматизація схемотехнічного проектування Текст.: монографія / В.Н.Ільїн [та ін]; за ред. В.Н.Ільїна. М.: Радіо та зв'язок, 1987. – 368 с.

2. Автоматизація схемотехнічного проектування на міні-ЕОМ Текст.: Навчальний посібник / В.І.Анісімов [та ін.]. JL: Вид-во Ленінгр. ун-ту, 1983. - 199 с.

3. Анісімов, В.І. Комплекс діалогових пакетів моделювання аналогових та цифрових електронних схем на IBM/PC Текст. / В.І.Анісімов, К.Б.Скобельцин, А.В.Нікітін // Автоматизоване проектування в радіоелектроніці та приладобудуванні: 1991.-С.3-6.

4. Анісімов, В.І. Чутливість нелінійних систем до змін параметрів Текст. / В.І.Анісімов, Ю.М.Амахвр // Изв.СПБГЭТУ «ЛЕТИ». Сер. Інформатика, управління та комп'ютерні технології, -2007. Вип.2. – С. 22-26.

5. Анісімов, В.І. Моделювання безперервних систем Текст.: навчальний посібник/В.І.Анісімов. СПб.: ЛЕТИ, 2006. – 172 с.

6. Белліньясо, М. Розробка Web-додатків у середовищі ASP.NET 2.0 Текст.: монографія / М. Белліньясо.; пров. з англ. за ред. Ю.М. Артеменко. М.: ТОВ «І.Д.Вільямс», 2007. – 640 с.

7. Беллман, Р. Введення в теорію матриць Текст.: монографія / Р. Беллман.; пров. з англ. за ред. В.Б. Лідського. М.: Наука, 1969. – 336 с.

8. Богданов, А.В. Сервіс-орієнтована архітектура: нові можливості у світлі розвитку GRID технологій / А.В.Богданов, Є.Н.Станкова, В.В.Марєєв 5639)

9. Влах, І. Машинні методи аналізу та проектування електронних схем Текст.: монографія / І. Влах, К. Сінгхал.; пров. з англ. М: Радіо і зв'язок, 1988. - 560 с.

10. Гамма, Е. Прийоми об'єктно-орієнтованого проектування Текст.: монографія / Е. Гамма, Р.Хелм.; пров. з англ. СПб.: Пітер, 2001.

11. І. Гербер, Ш. Повний довідник по С # Текст.: монографія / Ш. Гербер.; пров. з англ. СПб.: Пітер, 2006. – 740 с.

12. Глоріозов, Є.Л. Введення в автоматизацію схемотехнічного проектування Текст: монографія / Є.Л.Глоріозов, В.Г.Сорін, П.П.Сипчук. М.: Радянське радіо, 1976. – 232 с.

13. Даконта, М. XML та Java 2. Бібліотека програміста Текст.: монографія / М. Даконта, А. Саганич.; пров. з англ. СПб.: 2001. – 384 с.

14. Дей, Н. Eclipse: Платформа Web-інструментів Текст.: монографія / Н.Дей, Л.Мандел, А.Райман.; пров. з англ. М.:, 2008. - 688 с.

15. Дейтел, Х.М. Технологія програмування на Java 2: Книга 1. Графіка, JavaBeans, інтерфейс користувача Текст: монографія / Х.М.Дейтел, П.Д.Дейтел, С.І.Сантрі.; М: ТОВ «Біном-Прес», 2003.-560 с.

16. Дейтел, Х.М. Технологія програмування на Java 2: Книга 2. Розподілені додатки Текст: монографія / Х.М. Дейтел, П.Д.Дейтел, С.І.Сантрі.; М: ТОВ «Біном-Прес», 2003.-464 с.

17. Дейтел, Х.М. Технологія програмування на Java 2: Книга 3. Корпоративні системи, сервлети, JSP, Web-сервіси Текст: монографія / Х.М.Дейтел, П.Д.Дейтел, С.І.Сантрі.; пров. з англ. М.: ТОВ «Біном-Прес», 2003. - 672 с.

18. Демидович, Б.П. Основи обчислювальної математики Текст: монографія / Б.П.Демидович, І.А.Марон. М.: Фізматгіз, 1963. – 658 с.

19. Джеймс, О. Ітераційні методи вирішення нелінійних систем рівнянь Текст.: монографія / О. Джеймс, Р. Венер.; пров. з англ. за ред. Е.В. Вершкова, Н.П. Жідкова, І.В. Коновальцева. М.: Світ, 1975. - 551 с.

20. Джордж, А. Чисельне рішення великих розріджених систем рівнянь Текст.: монографія / А. Джордж, Дж. Лю.; пров. з англ. Х.Д. Ікрамова М.: Світ, 1984. – 333 с.

21. Діалогові системи схемотехнічного проектування Текст.: монографія / В. І. Анісімов [та ін.]. М: Радіо і зв'язок, 1988. - 287 с.

22. Дунаєв С.Б. Java для Internet у Windows та Linux Текст.: монографія / С.Б.Дунаєв. М.: ДІАЛОГ-МІФІ, 2004. – 496 с.

23. Зеленухіна, В.А. Розробка Інтернет-орієнтованих віртуальних лабораторій математичного моделювання за допомогою поділу обчислювальних та візуалізаційних задач Текст. / В.А.Зеленухіна, //Інформаційні технології, 2010. №10. - З.

24. Зиков, A.A. Основи теорії графів Текст.: монографія / А. А. Зиков. -М: Наука, 1987.-256 с.

25. Ільїн, В.М. Основи автоматизації схемотехнічного проектування Текст.: монографія/В.Н.Ільїн. М.: Енергія, 1979. – 391 с.

26. Імітаційне моделювання виробничих систем Текст.: монографія / А. А. Вавілов [та ін.]. Київ: Техніка, 1983. – 415 с.

27. Як програмувати на XML Текст.: монографія / Х.М.Дейтел, [та ін]; пров. з англ. М: ЗАТ «Видавництво БІНОМ», 2001. - 944 с.

28. Каліткін, H.H. Чисельні методи Текст.: монографія / Н.Н.Каліткін. -М: Наука, 1978, - 519 с.

29. Кнут, Д. Мистецтво програмування для ЕОМ Текст: монографія / Д.Кнут.; пров. з англ. Г.П.Бавенко, Ю.М.Ваяковського.; за ред. К.І.Бабенко, В.С.Штаркмана. М.: Світ, 1976. – 734 с.

30. Крістофідес, Н. Теорія графів. Алгоритмічний підхід Текст.: монографія / Н.Крістофідес.; пров. з англ. за ред. Г.П.Гаврилова. М: Мир, 1978.-432 з.

31. Мак-Дональд, М. Microsoft ASP.NET 2.0 з прикладами на С# 2005 для професіоналів Текст.: монографія / М. Мак-Дональд, М.Шпушта; пров. з англ. за ред. Ю.М. Артеменко. М.: ТОВ «І.Д.Вільямс», 2006. – 1408 с.

32. Михайлов, В.Б. Чисельно-аналітичні методи розв'язання надтвердих диференціально-алгебраїчних систем рівнянь Текст: монографія / В.Б.Михайлов. СПб.: Наука, 2005. – 223 с.

33. Норенков, І.П. Введення в автоматизоване проектування технічних пристроїв та систем Текст.: монографія / І.П.Норенков. -М: Вища школа, 1986. 302 с.

34. Норенков, І.П. Основи теорії та проектування САПР Текст.: монографія / І.П.Норенков, В.Б.Маничев. М.: 1990. -334 с.

35. Норенков, І.П. Системи автоматизованого проектування електронної та обчислювальної апаратури Текст.: монографія / І.П.Норенков, В.Б.Маничев. -М: Вища школа, 1983. 272 ​​с.

36. Ноутон, П. Java 2 Текст.: монографія / П. Ноутон, Г. Шілдт. ; пров. з англ. СПб.: БХВ-Петербург, 2001. – 1072 с.

37. Петренко, А.І. Основи побудови систем автоматизованого проектування Текст: монографія / А.І.Петренко, О.І.Семенков. -Київ: Вища школа, 1984. 293 с.

38. Петренко, А.І. Табличні методимоделювання електронних схем на ЕЦОМ Текст: монографія / А.І. Петренко, А.І.Власов, А.П.Тимченко. -Київ: Вища школа, 1977. 186 с.

39. Пісанецькі, С. Технологія розріджених матриць Текст.: монографія / С.Пісанецькі.; пров. з англ. за ред. Х.Д.Ікрамова. М.: Світ, 1988. – 410 с.

40. Разевіг, В. Схемотехнічне моделювання за допомогою Micro-Cap 7 Текст: монографія / В.Разевіг. М.: Телеком, 2003. – 368 с.

41. Розробка розподілених програм на платформі Microsoft . Net FrameworkТекст.: монографія / С.Морган [та ін]; пров. з англ. М.: «Російська Редакція», 2008. – 608 с.

42. Розробка клієнтських веб-додатків на платформі Microsoft .Net Framework Текст.: монографія / Гленн Д. [та ін]; пров. з англ. М.: «Російська Редакція», 2007. – 768 с.

43. Керівництво розробника Borland JBuilder Текст.: монографія / М.Ленді [та ін.]; пров. з англ. М: Видавничий дім «Вільямі», 2004. -864 с.

44. Райє, Дж. Матричні обчислення та математичне забезпечення Текст.: монографія / Дж. Райс.; пров. з англ. М.: Світ, 1984. – 264 с.

45. С# для професіоналів Текст.: монографія / Симон Робінсон [та ін].; пров. з англ. С.Коротигін [та ін]. М.: Лорі, 2005. – 1002 с.

46. ​​Саймон, P. Microsoft Windows 2000 API. Енциклопедія програміста Текст.: монографія/Р.Саймон.; СПб.: ДіаСофт, 2002.-1088 с.

47. Секрети програмування для Internet на Java Текст.: монографія / М. Томас [та ін].; пров. з англ. СПб.: Пітер, 1997. – 640 с.

48. Сешу, С. Лінійні графи та електричні ланцюгиТекст.: монографія/С.Сешу, М.Б.Рід.; пров. з англ. М.: Вища школа, 1971. – 448 с.

49. Сигірський, В.П. Алгоритми аналізу електронних схем Текст: /

50. B.П.Сігорський, А.І.Петренко. М.: Радянське радіо, 1976. – 606 с.

51. Сигірський, В.П. Математичний апарат інженера Текст.: монографія/В.П.Сігорський. Київ: Техніка, 1975. – 765 с.

52. Сліпченко, В.Г. Машинні алгоритмита програми моделювання електронних схем Текст.: монографія / В.Г.Сліпченко, В.Г.Табарний -Київ: Техніка, 1976. 157 с.

53. Рад, Б.Я. Моделювання систем Текст.: монографія / Б. Я. Рад,

54. C.А.Яковлєв. М.: Вища школа, 1985. – 271 с.

55. Сольніцев, Р.І. Автоматизація проектування систем автоматичного керуванняТекст.: монографія / Р.І.Сольніцев. М.: Вища школа, 1991. – 328 с.

56. Сольніцев, Р.І. Основи автоматизації проектування гіроскопічних систем. Текст.: монографія/Р.І. Сільниці. М.: Вища школа, 1985. – 240 с.

57. Степаненко, І.П. Основи мікроелектроніки: навч. посібник для вузів Текст / І.П.Степаненко. М: Радянське радіо, 1980. -567 с.

58. Тарасік, В.П. Математичне моделювання технічних систем Текст: монографія / В.П. Тарасик. Мінськ: Дизайн ПРО, 2004. – 639 с.

59. Троєлсен, Е. Мова програмування С# 2005 та платформа.NET 2.0 Текст.: монографія / Е. Троєлсен,; пров. з англ. за ред. А.Г.Співака. М.: ТОВ «І.Д.Вільямс», 2007. – 1168 с.

60. Тьюарсон, Ф.Р. Розріджені матриці Текст.: монографія / Ф.Р.Тьюарсон.; пров. з англ. М.: Світ, 1977. – 189 с.

61. Фадєєв, Д.К. Обчислювальні методи лінійної алгебри Текст.: монографія / Д. К. Фадєєв, В.М. Фадєєва. М.: Изд-во Фіз-мат літератури, 1963. – 734 с.

62. Феррара, А. Програмування web-сервісів для .NET Текст.: монографія / А.Феррара, М. Мак-Дональд. СПб.: Пітер, 2003. – 422 с.

63. Форсайт, Дж. Машинні методи математичних обчисленьТекст.: монографія / Дж. Форсайт, М. Малькольм, К. Моулер.; пров. з англ. за ред. Х.Д.Ікрамова. М.: Світ, 1980. – 277 с.

64. Цимбал, A.A. Технологія створення розподілених систем Текст: монографія / А.А.Цимбал, М.Л.Аншина. СПб.: Пітер, 2003. – 576 с.

65. Чуа, Л.О. Машинний аналіз електронних схем Текст: монографія / Л.О.Чуа, Лін.Пен-Мін.; пров. з англ. -М: Енергія, 1980. 631с.

66. Хайнеман, P. PSPICE Моделювання роботи електронних схем Текст: монографія / Р. Хайнеман. -М: Видавництво ДМК, 2005. 327с.

67. Хабібулін, І. Розробка Web-служб засобами Java Текст.: монографія / І. Хабібулін. СПб.: БХВ-Петербург, 2003. – 400 с.

68. Холл, М. Сервлети та JavaServer Pages Текст.: монографія / М.Холл.; пров. з англ. -СПб.: Пітер, 2001. 496 с.

69. Естербю, О. Прямі методи для розріджених матриць Текст.: монографія / О. Естербю, З. Златєв.; пров. з англ. М.: Світ, 1987. – 111 с.

70. Янг, М.Д. Microsoft XML. Крок за кроком Текст: монографія / М.Д.Янг.; пров. з англ. -М.: Видавництво ЕКОМ, 2002. 384с.69. http://bigor.bmstu.ru/?doc=080IS/ai006.mod/?cou-140CADedu/CAD.cou

Зверніть увагу, представлені вище наукові текстирозміщені для ознайомлення та отримані за допомогою розпізнавання оригінальних текстів дисертацій (OCR). У зв'язку з чим у них можуть бути помилки, пов'язані з недосконалістю алгоритмів розпізнавання. У PDF файлах дисертацій та авторефератів, які ми доставляємо, таких помилок немає.