Моделі взаємодії програм, систем і операційних середовищ

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

Ausführliche Beschreibung

Gespeichert in:

Bibliographische Detailangaben
Datum:	2011
1. Verfasser:	Лавріщева, К.М.
Format:	Artikel
Sprache:	Ukrainian
Veröffentlicht:	Інститут програмних систем НАН України 2011
Schlagworte:	Теоретичні та методологічні основи програмування
Online Zugang:	http://dspace.nbuv.gov.ua/handle/123456789/50966
Tags:	Tag hinzufügen Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Zitieren:	Моделі взаємодії програм, систем і операційних середовищ / К.М. Лавріщева // Пробл. програмув. — 2011. — № 3. — С. 11-22. — Бібліогр.: 19 назв. — укр.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	irk-123456789-50966
record_format	dspace
spelling	irk-123456789-509662013-11-08T03:08:34Z Моделі взаємодії програм, систем і операційних середовищ Лавріщева, К.М. Теоретичні та методологічні основи програмування Розглядаються моделі взаємодії програм, що будуються в різнорідних середовищах, систем, що збираються з готових програм та середовищ, що забезпечують сумісне об’єднання програм, інтегрованих у репозиторію Eclipse. Дано опис реалізації моделей взаємодії програм з репозиторію через інтерфейси в середовищах Visual Studio.Net і CORBA. Визначені декілька конфліктів взаємодіючих програм у середовищах засобами системи WCF, що залежить від різних способів реалізації у них інтерфейсів. Сформульовані головні теоретичні та прикладні шляхи їх подолання у майбутньому проекті. 2011 Article Моделі взаємодії програм, систем і операційних середовищ / К.М. Лавріщева // Пробл. програмув. — 2011. — № 3. — С. 11-22. — Бібліогр.: 19 назв. — укр. 1727-4907 http://dspace.nbuv.gov.ua/handle/123456789/50966 681.03 uk Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Ukrainian
topic	Теоретичні та методологічні основи програмування Теоретичні та методологічні основи програмування
spellingShingle	Теоретичні та методологічні основи програмування Теоретичні та методологічні основи програмування Лавріщева, К.М. Моделі взаємодії програм, систем і операційних середовищ
description	Розглядаються моделі взаємодії програм, що будуються в різнорідних середовищах, систем, що збираються з готових програм та середовищ, що забезпечують сумісне об’єднання програм, інтегрованих у репозиторію Eclipse. Дано опис реалізації моделей взаємодії програм з репозиторію через інтерфейси в середовищах Visual Studio.Net і CORBA. Визначені декілька конфліктів взаємодіючих програм у середовищах засобами системи WCF, що залежить від різних способів реалізації у них інтерфейсів. Сформульовані головні теоретичні та прикладні шляхи їх подолання у майбутньому проекті.
format	Article
author	Лавріщева, К.М.
author_facet	Лавріщева, К.М.
author_sort	Лавріщева, К.М.
title	Моделі взаємодії програм, систем і операційних середовищ
title_short	Моделі взаємодії програм, систем і операційних середовищ
title_full	Моделі взаємодії програм, систем і операційних середовищ
title_fullStr	Моделі взаємодії програм, систем і операційних середовищ
title_full_unstemmed	Моделі взаємодії програм, систем і операційних середовищ
title_sort	моделі взаємодії програм, систем і операційних середовищ
publisher	Інститут програмних систем НАН України
publishDate	2011
topic_facet	Теоретичні та методологічні основи програмування
url	http://dspace.nbuv.gov.ua/handle/123456789/50966
citation_txt	Моделі взаємодії програм, систем і операційних середовищ / К.М. Лавріщева // Пробл. програмув. — 2011. — № 3. — С. 11-22. — Бібліогр.: 19 назв. — укр.
work_keys_str_mv	AT lavríŝevakm modelívzaêmodííprogramsistemíoperacíjnihseredoviŝ
first_indexed	2025-07-04T12:51:53Z
last_indexed	2025-07-04T12:51:53Z
_version_	1836720864364593152
fulltext	Теоретичні та методологічні основи програмування © К.М. Лавріщева, 2011 ISSN 1727-4907. Проблеми програмування. 2011. № 3 11 УДК 681.03 К.М. Лавріщева МОДЕЛІ ВЗАЄМОДІЇ ПРОГРАМ, СИСТЕМ І ОПЕРАЦІЙНИХ СЕРЕДОВИЩ Розглядаються моделі взаємодії програм, що будуються в різнорідних середовищах, систем, що збира- ються з готових програм та середовищ, що забезпечують сумісне об’єднання програм, інтегрованих у репозиторію Eclipse. Дано опис реалізації моделей взаємодії програм з репозиторію через інтерфейси в середовищах Visual Studio.Net і CORBA. Визначені декілька конфліктів взаємодіючих програм у сере- довищах засобами системи WCF, що залежить від різних способів реалізації у них інтерфейсів. Сфор- мульовані головні теоретичні та прикладні шляхи їх подолання у майбутньому проекті. Вступ Сьогодні побудова окремих приклад- них програмних систем (ПС) виконується масово в основному з використанням компонентного, сервісного та генеруваль- ного програмування (ГП). Ці методи під- тримуються сучасними системами автома- тизації у різних платформах і середови- щах. Постійно удосконалюються методи збирання (інтеграційного, композицій- ного) різнорідних програм і компоненттів, накопичених забагато в інформаційному світі Інтернету. Відповідно проведеного аналізу сучасних фабрик програм [1–4] нами зроблений висновок про те, що кож- не діюче операційне середовище або роз- поділена система загального призначення в основному підтримують розробку і збор- ку деякої сукупності готових чи знов роз- роблених програм. Зборка програм забез- печується на рівні інтерфейсного (брокер- ного), проміжного (middleware) або вихід- ного коду ПС. У випадку коли кінцевий результат розробки ПС необхідно викону- вати за межами середовища його виготов- лення, тобто в іншому середовищі, то як, правило, виникають деякі проблеми, що пов’язані з особливостями реалізації моде- лей взаємодії програм, систем і середовищ [2–5]. Індустрія програмної продукції (ПП) базується на готових і звичайних компо- нентах (артефактах, reuses, assets і даних) багаторазового використання, накопиче- них у різних бібліотеках, репозиторіях та нових «хмарних» сховищах Інтернету. Головним базисом індустріального розви- тку ПП є програмні компоненти і системи, які створюються у сучасних розподілених середовищах, та метод їх зборки у різні структури ПП з вбудованими механізмами взаємодії і зв’язками, необхідними при рі- шенні широкого класу наукових задач з e-sciense. Виходячи з того, що механізми взає- модії у кожному середовищі виробництва ПП відрізняються між собою, то в даній роботі розглядаються моделі взаємодії та вирішується задача інтеграції ПП у репо- зиторій іншого середовища з доробкою інтерфейсу взаємодії для виконання цього ПП у даному середовищі. Ця можливість підвищує ефективність вироблення про- грам з готових програмних ресурсів, що розміщені в інтегрованому репозиторію [6–8]. Далі наведено опис різних варіантів моделей взаємодії програм, розподілених систем і операційних середовищ, а також запропонований новий підхід до вирі- шення складних проблем взаємодії між різними сучасними середовищами, що ви- користовуються для побудови за їх життє- вим циклом (ЖЦ) прийнятої технології но- вих різнорідних програм (C#, Java, Basic). Варіанти цих моделей розроблені в межах фундаментального проекту III–1–07 [3] і Теоретичні та методологічні основи програмування 12 практично реалізовані для пар середовищ: VS.Net, Eclipse, Corba, Eclipse та VS.Net на прикладі програм у мовах Java і C#. Вони розширюють середовище Eclipse технологічними інструментами з розробки програм та засобами їх інтеграції у репози- торій. Характеристика моделей взаємодії програм, систем і середовищ Модель взаємодії призначена для обміну інформацією між різними компо- нентами при їх об’єднанні й обчисленні [4, 9]. Під взаємодією розуміються зв'язки двох і більше об'єктів і відношення між ними.. Даний термін має спеціальне зна- чення для програм, систем і середовищ [6–8]. Його основу містить процес обміну повідомленнями (викликами, запитами, протоколами) між програмами, системами і середовищами для сумісного рішення де- якої задачі. В повідомленні задається ін- терфейс, який специфікується загально прийнятою мовою IDL (Interface Definition Language) або іншими (APL, SIDL й ін.). На загальному рівні інтерфейс є механізмом забезпечення взаємодії (interconnection) різнорідних програм для сучасних середо- вищ, що забезпечують розроблення про- грам і систем. Нові механізми забезпечення взаємо- дії програмних компонентів (різномовних, різноплатформенних, різносередовищних) розробляються нами у рамках генеруваль- ної моделі GDM (Generative Domain Model) ПС у середовищі ГП [3]. Сукуп- ність ПС або сімейств систем (СПС) по- роджується за моделлю GDM і моделлю характеристик їх окремих елементів (ком- понентів, сервісів, каркасів і т. п.), що вхо- дять до складу СПС. Вони відповідають деяким функціям або поняттям предмет- ної області (ПрО), що специфікуються різ- ними мовами програмування (МП) і реалі- зуються в одному з діючих середовищ. Основу подання моделі ПрО містить об'єк- тно-орієнтований та компонентний підхід, доповнені механізмами породження гото- вих компонентів повторного використання (КПВ) і засобами забезпечення їхньої вза- ємодії між собою [4]. Формально під моделлю взаємодії ро- зуміється опис процесів для встановлення залежностей між різними параметрами елементів програмних чи інформаційних систем. Тобто така модель відображає систему відношень, що описує процес побудови ПП, як деяке явище. Ці відно- шення можуть задаватися математичними засобами – абстрактна алгебра, теорія множин тощо. Параметрами моделі взаємодії є про- грама (компонент), інтерфейс і повідом- лення. Модель має такий загальний вигляд: Мвз = {Мпр, Мсис, Мсеред}, де – Мпр = {Com, Int,, Prot} – модель про- грами, Мсис = {CPC, Int,, Prot }– модель системи, Мсеред = {ENVIR, INT, PROT}– модель середовища, в якому INT, PROT відображають сукупність інтерфейсів та протоколів стосовно. Програмний елемент моделі (Com, CPC, ENVIR) специфікується відповідною МП, інтерфейс – мовою IDL, протокол – мовою XDL, RDF тощо. Програмні елеме- нти й інтерфейси зберігаються в бібліо- теках і репозиторіях системи ГП, які вико- ристовуються для організації пошуку еле- мента типу КПВ, аналізу його функції і можливості застосування в нової системі. Розроблення самостійних програмних елементів виконується в інтегрованому середовищі Eclipse, MS.Net, CORBA, Java, COM з використанням взаємозв’язків між складними елементами. Теоретичні та методологічні основи програмування 13 Інтерфейс як самостійний об'єкт сформувався у зв'язку з об'єднанням мо- дулів і програм у великі системи або ком- плекси програм на mainframes [1, 2] у 80-х роках минулого сторіччя. Інтерфейси як тоді й нині завдають атрибути та набір операцій, які визначають необхідні дії та методи обробки типів даних з отриманням від викликаної програми результату. Він відігравав роль посередника між модуля- ми, що викликаються і викликають. Опе- ратор виклику CALL завдає список фак- тичних параметрів, який перевіряється на відповідність (кількість і порядок розта- шування) формальним параметрам описа- ної процедури чи функції. Якщо типи да- них параметрів, виявлялися не релевант- ними, то проводилося пряме і обернене перетворення даних з урахуванням струк- тури пам'яті комп'ютерів. У розподілених програмах, що розташовані у різних сере- довищах, використовуються нові засоби взаємодії – RPC, RMI, ORB (stub, skeleton), IContract тощо. Середовище розроблення програм. Розглядається операційне середовище з системними програмними засобами і ін- струментами для підтримки процесів роз- роблення окремих програм у МП і зборки їх у проект. Базисом інструментального середовища ГП обрано Eclipse, як засіб керування репозиторієм КПВ і викорис- тання їх при виробленні нових ПС мето- дом зборки. За життєвим циклом середо- вищ MS.Net, CORBA, Java знову розроб- ляються програми на допустимих МП. Кожне з цих середовищ містить свій спе- цифічний набір засобів і підходів до трансформації описаних програм в МП для вихідного коду, що відрізняються між собою. Загальна модель розподілених систем мережного середовища Інтернет показана на рис. 1. Кожне з показаних середовищ CORBA, IBM, VS.Net, Java, базується на своїх інтерфейсах взаємодії і включає за- гальні методи та засоби доступу до даних мережного середовища. Рис. 1. Загальна модель схеми розробки і взаємодії програм у Інтернет середовищі Програми, виготовлені в одному з середовищ, можуть бути інтегровані з од- ного середовища в інше через репозито- рій, наприклад Eclipse. У межах проекту ГП здійснено розширення середовища Eclipse за рахунок інтеграції нових про- грам, вироблених в одному з середовищ, інтегрованих у репозиторій системи ГП [3, 10 – 13]. Ці операційні середовища за- безпечують відповідні процеси ЖЦ розро- блення різнорідних програм та методи їх об’єднання у різні структури ПП через ме- ханізми взаємодії, реалізованому в цьому середовищі. Розглянемо основні методи вироблення, інтеграції і взаємодії програм у парах системних середовищ ГП: – Visual Studio.Net, Eclipse, на які орієнтується проект Grid і які застосову- ють технологію розробки окремих програм Теоретичні та методологічні основи програмування 14 у мові С# за стандартними процесами ЖЦ, специфікацію інтерфейсу з паспортними даними і з перенесенням готового продук- ту в репозиторій системи Eclipse, що відо- бражає зв'язок з даним середовищем роз- роблення програм через механізм плагинів або конфігураційний файл з параметрами і операціями обробки даних у тому чи ін- шому середовищі [14]; – CORBA, Java, MS.Net забезпечу- ють розробку програм на МП цього сере- довища та встановлення зв’язків між цими програмними середовищами в цілях забез- печення розміщення розроблених програм у репозитарії системи ГП та додавання до- ступу іншим розробникам його програм [15]; – IBM Sphere, Eclipse, де розробля- ються нові програми з використанням можливих МП, що допускаються у цьому середовищі чи у VSphere віртуального варіанта. Інтерфейс є головним параметром операційних середовищ, а також моделей взаємодії програм і систем. Дамо опис змі- сту моделей взаємодії. Модель взаємодії програм – це схе- ма зв’язків окремих частин програм між собою. Як зв’язки виступають оператори звернення (типу CALL) до процедур і функцій цієї програми з формальними па- раметрами. Програми, процедури і функції записуються в одній МП. Оператори звер- нення містять імена об'єктів (процедур і функцій), що викликаються, список фак- тичних параметрів з завданням їх значень і параметрів, для отримання результатів. Послідовність і число формальних параме- трів мають відповідати фактичним параме- трам. Виконання функції у програмі на од- ній МП не викликає проблем, коли типи даних параметрів збігаються. Моделі взаємодії систем найбільш пов'язані з використанням готових про- грам у процесі розробки нових ПС мето- дом зборки. Якщо всі готові програми по- дані в різних МП і розташовані на різних комп'ютерах мережі, то при їх збиранні можуть виникати проблеми неодноріднос- ті типів даних у цих програмах, структурах пам'яті платформ комп'ютерів і операцій- них середовищ, де вони виконуються. Зі- брані ПП враховують формати даних го- тових програм на платформах сучасних комп’ютерів, особливості структури вихі- дного коду програм після компіляторів з МП, який залежить від використання спе- ціальних бібліотек data types і routines або без них. Реально існуючі розходження в апаратній частині платформ і у вихідному коді програм враховуються у конфігура- ційному файлі ПП, який використовується при організації виконання ПП у сучасних обчислювальних або гетерогенних сере- довищах. Деяким питанням перебудови загальних типів даних (ЗТД) до фундамен- тальних типів даних присвячений стандарт ISO/IEC 11404–2007 General Data Types. Він пропонує механізми генерації склад- них типів даних (контракт, портфель тощо) до більш простих, що є в МП. Але фунда- ментальні типи даних МП підтримуються спеціальними засобами сучасних опера- ційних середовищ (Sun IBM, Microsofts.Net, CORBA, СОМ, JAVA й ін.). До них відносяться проміжний посередник типу stub, skeleton брокерного типу, що виконує перебудову типів даних від клієн- та для передачі серверу і навпаки, а також вихідної код типу MISL у проміжному коді або EXE для виконання в системах Linux, Windows Server, MS.Net, IBM Web Sphere і т. п. [2]. Модель взаємодії операційних се- редовищ між собою розглядається нами як послідовність дій з інтеграції програ- ми, створеної у одному середовищі в інше. Загальна схема розробки розподілених си- стем у середовищі ГП на основі інтерфей- сів програм і моделей взаємодії для сере- довищ IBM, VS.NET, JAVA, CORBA по- казано на рис. 2. Теоретичні та методологічні основи програмування 15 У центрі цієї cхеми розміщена систе- ма Eclipse, яка виконує по сутності функ- цію інтегратора програм у репозіторій з інших середовищ Інтернету та адміністра- тора цього репозиторію по збереженню, відбору і застосуванню готових програм- них ресурсів типу КПВ, а також для вико- нання ПП, виготовлених у цих середовищах. Рис. 2. Модель взаємодії розподіле- них систем з Eclipse Деякі середовищі, наприклад, VS.Net і JAVA вже мають прямі зв’язки і ство- рюють одне інтегроване середовище. У межах фундаментального проекту проведено реалізацію моделей взаємодії пар наступних операційних середовищ Visual Studio ↔ Eclipse та CORBA↔ Visual Studio за участю студентів КНУ імені Тараса Шевченка [14, 15]. Дамо короткий зміст процесів про- ектування програм і забезпечення їх взає- модії на прикладі вказаних пар середовищ. Модель Visual Studio ↔ Eclipse [14]. На прикладі побудови програм на мові C# у середовищі Visual Studio, реалі- зована модель взаємодії програм через розміщення їх у репозиторій середовища Eclipse. Взаємодія програми у мові C# у середовищі Eclipse виконана через спеціа- льний плагін Emonic та компонент NAnt із платформи (.Net). Створені з них архіви розархівуються при переносі їх в аналогі- чні папки середовища Eclipse. Для їх вико- нання в системі Eclipse створюється пус- тий проект, потім натискується права кнопка миші на назву цього проекту, із контекстного меню вибирається пункт Import → File System, й із файлової систе- ми імпортується вибраний проект. У кон- фігураційному файлі проекту (.build) змі- нюється його вміст шляхом завдання ви- хідних файлів, бібліотеки та файли ресур- сів. Тобто при переході в середовище Eclipse використовуються вихідні файли програми, dll-бібліотеки VS.Net та файли ресурсів (.resx). Коли необхідно знов пе- рейти із цього середовищf в Visual Studio, то весь проект імпортується. Обчислення програми і її зміни можуть виконуватися як у середовищі Eclipse, так і Visual Stu- dio. Net. Модель CORBA↔ Visual Studio [15]. На експериментальному прикладі програми у мові Java пакету Java Development Kit в системі CORBA і від- повідної компіляції IDL-опису її інтер- фейсу брокер ORB, що створює клієнтсь- кий і серверний посередник Stub і Skeleton, продемонстровано перенос цієї програми на платформу Microsoft.Net за допомогою пакета IIOPNet. Тобто реаліза- ція задачі взаємодії прикладних компоне- нтів, розроблених у заданих середовищах Microsoft.Net (клієнтська частина) і Java (серверна частина), виконана через систе- му CORBA. У платформі MS.Net значення після повернення мають тип Теоретичні та методологічні основи програмування 16 MarshalByRefObject. Це дозволяє тракту- вати всі звертання до полів і методів об'єк- та як вилучені виклики. Забезпечення вза- ємодії програм між двома середовищами Java і MS.NET виконано наступними про- цедурами: компіляція серверної частини застосування; створення серверного Skeleton й опис інтерфейсного об'єкта мо- вою IDL за допомогою утиліти rmic; пере- творення отриманого IDL-опису в CLS- сумісну бібліотеку, використовуючи пакет IIOPNet приєднання бібліотеки до клієнт- ської частини застосування для викорис- тання відповідного сервісу. Усі дані, що обмінюють між собою програми клієнта і сервера, є строкові, тобто є екземплярами класу String. У сис- темах програмування строки зберіга- ються усередині об’єктів String, як по- слідовність символів Unicode фіксованої довжини, тобто відповідають стандарт- ному типу даних CORBA wstring і викори- стовуються для передачі даних через сис- тему CORBA. Розміщення побудованої у мові Java програми у репозиторій Eclipse виконуєть- ся через плагін. При цьому формується па- спорт програми (табл. 1), відповідно шаб- лону специфікатора програм, який за своі- му змістом наближений до специфікаторів (програм, підсистем, систем, проектів, мо- дулів), прийнятих у системі Grid [10]. У межах ГП розроблений набір мо- делей: взаємодії (програм, систем і сере- довищ), а також моделей варіабельності (варіантності, змінюваності) [9, 10], живу- чості (надійності, відмовостійкості, відно- влюваності, адаптивності) [11] та життє- вого циклу (ТЛ, Product Line), конфігура- ційні (збіркові), трансформаційні, генера- ційні моделі [3] тощо. При цьому Eclipse виконує функції інтегратора готових для використання програм у репозиторій та керування інструментами і засобами, що входять до складу інтегрованого середо- вища ГП. Таблиця 1. Шаблон специфікатора Назва пара- метрів Зміст параметрів Розроб- ник Прізвище, ім’я по-батькові автора, власника компонента, що додається Дата ство- рення Дата створення КПВ автором (дата кінцевої, атестованої, специфікованої версії продукту) Дата зміни Дата внесення змін у КПВ Версія Версія компонента повторного використання Плат- форма Платформа, для якої створювався КПВ та на якій перевірена його працездатність Опера- ційна система Операційна система, для якої створювався КПВ та на якій перевірена його працездат- ність Розмір Загальний розмір КПВ (продукту, докумен- тації тощо) Опис Короткий опис КПВ, список внесених змін, системні вимоги, вимоги до користувачів, список необхідних програм для коректної роботи, довідка тощо Прави- ла ви- корис- тання Особливий опис КПВ, згідно побажань автора, правил розповсюдження тощо Зокрема, ця система забезпечує до- ступ до репозиторію програм і інтерфейсів користувачу ГП, а також до системи PROTÉGÉ для створення онтології деяко- го домену й отримання інформації про ті домени, які представлені в системі ГП. Інтерфейс як головний пара- метр запропонованих моделей взаємодії До нинішнього часу розроблені ін- терфейси різного призначення, які є го- ловним елементом при збиранні складних програм із готових програм типу КПВ [6, 7]. Нині використовуються інтерфейси програм, мов, даних, сервісів, процесів: – інтерфейс модульний, програмний (RPC, RMI, IDL, API, ISO тощо); – міжмовний інтерфейс (Java Native Interface, SIDL– Scientifical IDL, Fundamental Data Types, GDT – General Data Types); – сервісний інтерфейс (Icontract, web, ISO); Теоретичні та методологічні основи програмування 17 – проміжний інтерфейс (Middleware, Virtualware, ISO, міжсистемний, між– се- редовищний, між клієнтом і сервером то- що); – технічний інтерфейс (стандарт SEI на інтерфейсну карту МПО–16Е–2). У залежності від видів сучасних се- редовищ у табл. 2 наведено їх перелік, ін- терфейси і програмні елементи. Таблиця 2. Типи інтерфейсів Середовище виготовлення Інтерфейс взаємодії Програмні елементи IBM Sphere RPC Модуль, про- грама MS.Net, VSTS.Net MSIL Програма CОRBA (Skeleton) ORB Об’єкт (stub) JAVA RMI Розподілені ПС, програма COM API Компонент WCF Icontact Програма, сис- тема, розподі- лене ПС GRID Transport Connectivity Компонент, система, мо- дуль, пакет Eclipse Plug-in Системи і ін- струменти Наведені інтерфейси застосовуються у середовищах обчислення розроблених для спеціально доменів та готових елеме- нтів – КПВ, assets, reuses, які можуть об’єднуватися віртуальним композіром і виконуватися за допомогою нових хмар- них засобів (WCloud, Azure, Amazon, Mech, Wаpps), побудованих фірмами IBM- VSphere та Microsoft (рис. 3). На даному рисунку показана техно- логічна схема розподіленої обробки різ- норідних програм у мережному середови- щі, базованому на готових програмах і си- стемах сервера “Системи” та сховищах даних сервера “Сховища”, що займають центральне місце у мережному середови- щі. Виходячи з того що ці сервери підтри- мують обчислення програм за даними, що знаходяться у сховищах даних, це се- редовище завдає новий віртуальний про- шарок між Internet і засобами Cloud Computing. Цей прошарок надає сервіс з обробки даних великих розмірів у режимі online з віртуальних серверів Web-services, Sky-driven (www.cmswire.com), які забез- печують майбутню віртуальну обробку да- них. Такий напрям отримав назву хмарних обчислень задач глобального типу (Http://lenta.ru/articles/2010). Ці засоби зо- рієнтовані на збереження, синхронізацію даних великих розмірів даних та доступ до глобальних сховищ даних on-line, ви- кладених на віддалених серверах тощо. Рис. 3. Схема обчислення програм у віртуальному середовищі VSphere Організація хмарних обчислень по- требує реалізації нових методів взаємодії готових ресурсів і сервісів (наприклад, Теоретичні та методологічні основи програмування 18 через конфігураційний файл для обчис- лення наукових задач. Наведені сучасні середовища підтримують відповідні прин- ципи взаємодії (див. табл. 2) за наступни- ми типами інтерфейсів: 1) через брокер запитів між клієнтом і сервером, щодо отримання даних від stub клієнта, їх обробку під формати комп’ютера, передачу їх серверу і зворот- но від skeleton сервера, що обробляє ре- зультати обчислювань до форматів даних клієнта; 2) через проміжний прошарок за- гальносистемних засобів, сучасних сере- довищ або віртуальних серверів хмарних обчислень [12, 13]; 3) через пряму зборку трансльова- них програм за різними МП і їх інтерфей- сами у бібліотеках, наприклад, MS.Net [15]. Перший тип інтерфейсу практично забезпечується брокером ORB для класу МП у середовищі CORBA. Зборка компо- нентів базується на Client class з виклика- ми інших, Stub class з конвертування да- них, ORB class з передачі даних; Server class зі створення сервентів та посилання даних ORB; Skeleton class з конвертування форматів даних та породження різних ви- дів серверів [16]. Другий тип інтерфейсу забезпечує взаємодію між компонентами, розміще- ними на різних комп’ютерах через промі- жний прошарок (middleware) шляхом по- відомлень (наприклад, Java Message Queue), віддаленого виклику процедур RPC в MS Windows, ONS IBM, CORBA та виклику методів RMI у Java. Модель ISO/OSI також забезпечує проміжну взає- модію на рівнях (фізичному, канальному, мережному і транспортному) мережної ОС. Верхній рівень моделі (прикладний) забезпечує перетворення даних до транс- портного рівня шляхом їх маршалінгу й демаршалінгу за інтерфейсним stub. Сеансовий рівень моделі передає дані ін- шим рівням через транспортний канал за механізмами посилань. Третій тип інтерфейсу є проміжним (MSIL), реалізованим в MS.Net за допомо- гою таких бібліотек системи: CLR (Common Language Runtime), CTS (Common Type System) і CLS (Common Language Specification). CLR забезпечує виявлення і завантаження даних, керуван- ня ними у відповідності до завдань розро- бника програми. CTS визначає принципи взаємодії із іншими, відповідно представ- лення форматів мета–даних. Збірка різно- мовних програм виконується засобами CLS бібліотеки. Усі компілятори з МП створюють модулі DLL або EXE у промі- жній мові MSIL (Microsoft Intermediate Language) як механізм зборки програми незалежно від платформи, на якій вона бу- де виконуватися. При її запуску вона кон- вертується в специфічний код CPU, що ви- конується на різних архітектурах комп’ютерів [16]. Таким чином, у залежності від цілей вироблення програм в якості середовища вибирається те середовище, що найбільш підходить для організації процесів розроб- лення і зборки відповідних програмних ресурсів у межах деякої ПрО. Коло про- блем звужується, коли різні середовища можуть взаємодіяти між собою, створюю- чи одне велике, гнучке середовище з по- ширеними можливостями щодо виробниц- тва кінцевого ПП. Новий підхід до забезпечення взаємодії різних сучасних середовищ у WCF Головна ціль системи ГП міститься в виготовленні ПП шляхом: – побудови нових програм в одному з обраних середовищ – VS.Net –C# і CORBA Java; Теоретичні та методологічні основи програмування 19 – специфікації збудованих програм і заповнення шаблону специфікатора паспо- рта для розміщення їх репозиторії сис- теми ГП; – вибору готових КПВ або програм для збирання з них нових ПС для рішення деяких задачі ПрО; – перевірки інтерфейсів для збиран- ня готових компонентів у ПС, тестування цієї ПС, формування комплексного пас- порту з занесенням його разом з готовим продуктом у репозиторій системи Eclipse тощо. У системі ГП вперше зроблено спро- бу об’єднати готові продукти, що отрима- ні у різних середовищах, VS.Net – C# і CORBA Java і зберігаються у репозиторії Eclipse. ПП будуються різними мовами. У кожному з обраних середовищ ГП реалі- зується свій підхід до вирішення пробле- ми взаємозв’язку різномовних або однако- вої мови програм. Коли отриманий про- дукт з одного середовища переноситься в інше, в системі ГП є реалізований меха- нізм взаємодії [17]. Водночас ця проблема вирішувалася в межах WCF (Windows Communication Foundation) [18] іншим способом, а саме, за допомогою нового типу інтерфейсу, так званого контракту (IContract), як складової частини Consumer та Provider (рис. 4), який не звільняє розробників від різного роду конфліктів взаємодії. Інтерфейс Icontract містить опис ат- рибутів та операцій з передачі даних від одного сервісного об’єкта клієнта (Service consumer) до іншого (Service provider). Їх опис дається у мові XML. Передачу ін- терфейсів за контрактом виконує прото- кол, в якому задаються атрибути та опера- ції інтерфейсу для передачі відповідному об’єкту розподіленої системи при їх об’єднанні. Рис. 4. Зв’язок двох сервісних компонентів в архітектурі WCF В результаті проведеного досліджен- ня щодо використання нового типу інтер- фейсу взаємодії сервісів через контракт у системі WCF для розроблення з наявних сервісів деяких розподілених систем. У межах проекту WCF визначено чотири ви- ди інтерфейсів-контрактів для забезпечен- ня взаємозв’язків компонентів між собою: контракти служб описують опера- ції, що викликаються клієнтом на сервісі; контракти даних визначають типи даних, що приймаються і передаються службою, а також непрямі контракти убу- дованих типів (таких як int, float, string і тощо); контракти помилок визначають по- милки, що втримуються службою для пе- редачі їх клієнтам; контракти повідомлень – механізм прямої взаємодії об’єктів через повідом- лення. Повідомлення специфікується мо- вою XML і подається протоколом SOAP в XML наступного виду: <?xml version=»1.0» ?> <env:Envelope xmlns:env=» http://www.cbsystematics.com»> <!—Конверт протоколу SOAP <env:Header> <!— Заголовок протоколу SOAP Теоретичні та методологічні основи програмування 20 </env:Header> <env:Body> <!—Тело протоколу SOAP </env:Body> </env:Envelope> При взаємодії між користувачем і провайдером можуть виникнути різного роду конфлікти (рис. 5). Рис. 5. Схема взаємодії програм середовищ через протоколи і можливі конфлікти До варіантів конфліктів належать: – несумісність типів даних, які пе- редаються в інтерфейсах кожного компо- нента, що об’єднується разом з іншою різ- номовною програмою. Наприклад, переда- ча даного типу – ціла програму, де цей па- раметр поданий, як символьний; – відмінність конфігураційних файлів ПП за структурою та змістом інформації, що необхідно використати при обчислен- ні тої чи іншої програми з ПС; – різниця в мовах програмування, що використовуються для розробки окремих програм; – відмінність порядку в опису пара- метрів протоколів передачі інформації між різними сервісними об’єктами; – відмінності в архітектурі платформ об’єктів клієнта і серверу тощо. Для реалізації деяких конфліктів ге- неруються відповідні програми чи компо- ненти з відокремленням конфліктних си- туацій. Іншим способом подання проблем передачі й обробки даних є генерація типів даних відповідно стандарту ISO/IEC-11404. Надалі у майбутньому проекті, як продовженню фундаментального проекту ІІІ–07–01 для рішення цієї проблеми, бу- дуть прийняті проектні рішення щодо ви- користання сервісів при забезпеченні вза- ємодії програм у сучасних середовищах для проведення обчислень за готовому ПП. 1. Андон П.І., Лавріщева К.М. Розвиток фаб- рик програм в інформаційному світі // Вісник НАН України. – 2010.– № 10.– C. 15–41. 2. Лавріщева К.М. Концепція індустрії нау- кового софвера і підхід до обчислення нау- кових задач // Проблеми програмування. – 2011.– № 1. – С. 3–17. 3. Лавріщева К.М. Генерувальне програму- вання програмних систем і сімейств // Про- блеми програмування. – 2009.– № 1. – С. 3–16. 4. Лаврищева Е.М., Грищенко В.М. Сбороч- ное программирование. Основы индустрии программных продуктов. – Второе изда- ние. – Киев: Академпериодика, 2009.– 371 с. 5. Анісімов А.В., Лавріщева К.М., Шевчен- ко В.П. Про індустрію наукового софтвера. – Conf. Theoretical and Applied Aspects of Cybernetics, Kiev, 2011, Ukraine. 6. Лавріщева К.М. Програмна інженерія. – К.: Академперіодика. – 2008.–319 с. 7. Лаврищева Е.М. Интерфейс в программи- ровании // Проблеми програмування.– 2007. – № 2. – С. 126–139. 8. Лаврищева Е.М. Проблема интеропера- бельности разнородных объектов, компо- нентов и систем. Подходы к ее решению // Матер. 7-ї Міжнар. конф. з програмування “УкрПрог – 2008”. – 2008. – С. 28–41. 9. Лавріщева К.М., Слабоспицька О.О., Ко- валь Г.І., Колесник А.О. Теоретичні аспек- ти керування варіабельністю в сімействах програмних систем. – Вісник КГУ, серія фіз.-мат. наук. – 2011. – № 1. – С. 151–158. 10. Колесник А.Л. Механізми забезпечення варіабельності в сімействах програмних систем // Проблеми програмування. – 2010. – № 1. – C. 35 – 44. Теоретичні та методологічні основи програмування 21 11. Ігнатенко П.П., Бистров В.М. Особливості забезпечення життєздатності програмних систем в умовах генеруючого програму- вання // Проблеми програмування. – 2008. – № 2–3. – С. 270–278. 12. Таковицкий О. Технология Grid computing. – С. 1–9. 13. Ильин В.А. Сетка с облаками для интернета // В мире науки.– 2010.–С. 83–85. 14. Основы инженерии качества программных систем / Ф.И. Андон, Г.И. Коваль, Т.М. Коро- тун, Е.М. Лаврищева, В.Ю. Суслов // 2-е изд. – Киев: Академпериодика, 2007. – 672 с. 15. Радецький І.О. Один з підходів до забезпе- чення взаємодії середовищ MS.NET і ECLIPSE // Проблеми програмування. – 2011. – № 2. – С. 43–49. 16. Островский А.В. Подход к обеспечению взаимодействия программных сред JAVA и MS.NET // Проблеми програмування.– 2011. – № 2. – С. 34–42. 17. Коваль Г.І., Колесник А.Л., Лавріщева К.М., Слабоспицька О.О. Удосконалення проце- су розроблення сімейств програмних сис- тем елементами гнучких методологій // Проблеми програмування (Спецвипуск конф. УкрПрог–2010). – 2010. – № 2–3. – C. 261 – 270. 18. Слабоспицька О.О. Технологічна модель процесу автоматизованого виробництва сімейств програмних систем // Проблеми програмування. – 2011. – № 1. – С. 39–48. 19. Windows Communication Foundation –www. edu.cbsycemantic.com. Отримано 23.04.2011 Про автора: Лавріщева Катерина Михайлівна, доктор фізико-математичних наук, професор, завідуюча відділом. Місце роботи автора: Інститут програмних систем НАН України, 03187, Київ-187, проспект Академіка Глушкова, 40. Тел. (044) 526 3470.

Моделі взаємодії програм, систем і операційних середовищ

Institution

Ähnliche Einträge