Введення в Microsoft. NET для початківців

Не маючи чіткого уявлення про Microsoft. NET і ролі, яку відіграє в цій новій ініціативі Microsoft мову С #, вам буде важко розібратися в ключових елементах С #, підтримуваних платформою Microsoft. NET. Представлений в цьому розділі огляд технології Microsoft. NET допоможе вам засвоїти термінологію, яка застосовується в цій книзі, і зрозуміти, чому деякі елементи мови С # ведуть себе так, а не інакше. Якщо переглянути в Інтернеті матеріали за Microsoft. NET, можна помітити різнобій у трактуванні і вживанні термінів цієї технології. Двозначні, а часом і просто суперечливі висловлювання заважають вловити суть викладається,. Багато в чому це пояснюється новизною проблеми. Тому насамперед я постараюся розігнати туман навколо цієї теми і роз'яснити деякі терміни, пов'язані з Microsoft. NET.

Не маючи чіткого уявлення про Microsoft. NET і ролі, яку відіграє в цій новій ініціативі Microsoft мову С #, вам буде важко розібратися в ключових елементах С #, підтримуваних платформою Microsoft. NET. Представлений в цьому розділі огляд технології Microsoft. NET допоможе вам засвоїти термінологію, яка застосовується в цій книзі, і зрозуміти, чому деякі елементи мови С # ведуть себе так, а не інакше. Якщо переглянути в Інтернеті матеріали за Microsoft. NET, можна помітити різнобій у трактуванні і вживанні термінів цієї технології. Двозначні, а часом і просто суперечливі висловлювання заважають вловити суть викладається,. Багато в чому це пояснюється новизною проблеми. Тому насамперед я постараюся розігнати туман навколо цієї теми і роз'яснити деякі терміни, пов'язані з Microsoft. NET.

Платформа Microsoft. NET

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

. NET Building Block Services - засоби програмного доступу до таких служб, як сховище файлів (file storage), календар (calendar), служба аутентифікації "Passport.NET";

ПЗ для пристроїв. NET, яке буде виконуватися на нових пристроях Інтернету;

кошти. NET для роботи з користувачами, що включають природний інтерфейс (natural interface), інформаційні агенти (information agents) та інтелектуальні теги (smart tags) - технологію, яка автоматизує перехід за гіперпосиланнями до інформації, пов'язаної зі словами і фразами в документах користувачів;

інфраструктура. NET, що складається з. NET Framework, Microsoft Visual Studio.NET,. NET Enterprise Servers і Microsoft Wmdows.NET.

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

NET Framework складається з Common Language Runtime (CLR) і набору бібліотек класів. NET Framework, який іноді називають Base Class Library (BCL). CLR - це по суті віртуальна машина, в якій функціонують додатки. NET. Всі мови. NET мають у своєму розпорядженні бібліотеки класів . NET Framework. Якщо ви знайомі з Microsoft Foundation Classes (MFC) або Object Windows Library (OWL) компанії Borland, то вам не треба пояснювати, що це таке. Бібліотеки класів. NET Framework включають підтримку практично всіх технологій від файлового вводу-виводу та обміну з БД до XML і SOAP. Взагалі бібліотеки класів. NET Framework настільки великі, що навіть поверховий огляд всіх підтримуваних класів потребують окремої книги.

Зауважу, що під терміном "віртуальна машина "тут не мається на увазі Java Virtual Machine (JVM). Фактично я застосовую цей термін в його традиційному значенні. Кілька десятиліть тому, коли Java означало лише темний, гарячий напій, IBM ввела в обіг словосполучення "віртуальна машина" ( "virtual machine"). Цим дивним словосполученням була позначена абстракція високорівневої ОС, усередині якої могли функціонувати в повністю інкапсульованими середовищі інші ОС. Говорячи про CLR як про віртуальній машині, я маю на увазі те, що код, що виконується в інкапсульованими і керованої середовищі, відокремлений від інших процесів на цій машині.

. NET Framework

Що ж являє собою. NET Framework і що він дає? Спочатку ми порівняємо. NET з іншої більш ранньої середовищем розробки розподілених додатків. Потім я перерахую можливості. NET, що дозволяють створювати потужні розподілені додатки в стислі терміни.

Windows DMA і. NET

Фраза, якою я охарактеризував. NET: "нова середа для створення та запуску надійних, масштабованих, розподілених програм "- звучить знайомо, так? Справа в тому, що. NET є продовженням попередньої спроби досягти цієї мети. Та платформа називалася Windows DNA. Однак перспектив у. NET в порівнянні з Windows DNA незрівнянно більше. Платформа Windows DNA була націлена на рішення для бізнесу за допомогою серверних продуктів Microsoft. До Windows DNA часом застосовували слово "клей" в такому, наприклад, контексті: "DNA - це клей, за допомогою якого з'єднуються надійні, масштабовані, розподілені системи ". Проте, будучи тільки технічної специфікації, Windows DNA не мало якихось відчутних компонентів. Це тільки один із низки основних відмінностей між Windows DNA і. NET. У Microsoft. NET, крім набору специфікацій, входить кілька реальних продуктів: компілятори, бібліотеки класів і навіть цілі програми для кінцевих користувачів.

Common Language Runtime

Common Language Runtime (CLR) - це серце технології Microsoft. NET. Як випливає з назви, це середовище часу виконання коду, в якій забезпечується ефективна взаємодія додатків, що перетинає кордону різних мов програмування (cross-language interoperability). Як досягається ця взаємодія? Common Language Specification (CLS) - це набір правил, яких повинен дотримуватися компілятор мови при створенні . NET-додатків, що запускаються в середовищі CLR. Будь-хто, хто захоче написати компілятор для. NET, повинен дотримуватися цих правил і - будь ласка! - Додатки, згенеровані цим компілятором, будуть працювати поряд з іншими . NET-прог-женіямі і будуть мати таку ж можливість взаємодії.

З CLR пов'язана важлива концепція керованого коду (managed code) - коду, що виконується тільки в середовищі CLR і керованого нею. Нагадаю, що під час виконання в нинішніх ОС Microsoft Windows ми маємо справу з різнорідними незалежними один від одного процесами. Єдина вимога, яким повинні відповідати програми в середовищі Windows, полягає в тому, щоб вони правильно працювали. Ці програми створюються абсолютно різними компіляторами. Інакше кажучи, додатки повинні підкорятися тільки найбільш загальними правилами роботи під Windows.

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

Бібліотеки класів. NET Framework

Бібліотеки класів. NET Framework відіграють надзвичайно важливу роль у забезпеченні міжмовного взаємодії додатків, тому що вони дозволяють розробникам використовувати єдиний програмний інтерфейс до всіх функціональним засобам CLR. Якщо вам доводилося писати програми для Windows на декількох мовах, то вам сподобається це нововведення. Бібліотеки класів. NET Framework роблять фактично революційний прорив у розробці компіляторів. До . NET майже кожен автор компілятора розробляв мову, що має здатність робити більшу частину своєї власної роботи. Навіть C + +, розроблений як набір функціональних можливостей, що працюють спільно з бібліотекою класів, має деякі засоби для власних потреб. Тоді як роль мов в оточенні. NET не вичерпується наданням синтаксичних інтерфейсів до бібліотекам класів. NET Framework.

Як ілюстрацію до сказаного можна порівняти версії традиційного програми "Hello, World" на мовах C + + і С #.

tfinclude

int main (int argc, char * argv []) (

cout " "Hello, World!" "Endl;

return 0;)

На початок програми включено заголовки з оголошенням функції cout. Функція main - вхідна точка будь-якої програми на C/C + + - виводить на стандартний пристрій виводу за допомогою функції cout рядок "Hello, World". Тут для нас важливо те, що написати такий додаток мовою. NET без бібліотек класів. NET Framework не можна. Це дійсно так: в. NET-мовах немає властивих звичайним компіляторам основних елементів, які, наприклад, виводять на консоль рядок тексту. Так, з точки зору технології, реалізація функції cout знаходиться в тій частині C/C + +, яка сама є бібліотекою. І все-таки основні завдання C + +, такі як форматування рядків, файловий ввід-висновок і висновок на екран, хоча б формально вважаються частиною вихідного мови. Що стосується С # (і це характерно для будь-кого. NET-мови), то він не в змозі виконати навіть саму примітивну завдання без залучення бібліотеки класів. NET Framework. А так виглядає приклад "Hello, World "на мові С #:

using System;

class Hello (

public static void Main ()

(

Console.WriteLine ( "Hello, World ");

)>

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

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

Ще один частий запитання: "Якщо все. NET-мови можуть робити одне й те ж, навіщо нам багато таких мов? "Відповідь треба шукати в тому, що програмісти - це люди, які рідко відмовляються від своїх звичок. Microsoft, звичайно, прагне виділити з безлічі мов якийсь один і нав'язати його мільйонам програмістів, які мають багаторічний досвід роботи з іншими мовами. Мало того, що розробнику потрібно познайомитися з новим API, йому доведеться еше освоїти зовсім інший синтаксис. Хай уже розробник продовжує писати на тій мові, яка найкраще підходить для його завдання. Як ніяк, наша головна мета - продуктивність. А заміна того, що не повинно змінюватися, - не те, до чого ми повинні прагнути.

ПРИМІТКА В ідеалі бібліотеки класів. NET Framework відкривають користувачам мови всі функціональні можливості CLR, однак на насправді так буває не завжди. Каменем спотикання між розробниками бібліотек класів. NET Framework і розробниками компіляторів є те, що перший хоча і спробували відкрити для будь-яких мов всі функціональні можливості бібліотек класів, останніх все-таки ніщо не зобов'язує робити реалізацію кожної такої можливості (не нехтуючи, правда, мінімальними стандартами CLS). Коли я запитав в Microsoft про це протиріччя, мені відповіли, що навряд чи кожна мова буде мати доступ до всіх функціональних можливостям. NET Framework, оскільки кожна бригада розробників компіляторів вправі реа ^ лізовать тільки те, що вони вважають найбільш потрібними для своїх користувачів. На наше щастя, С # - поідімому, та мова, в якому є інтерфейс практично до всіх функціональних можливостей. NET Framework.

Microsoft Intermediate Language і компілятори JITter

Для полегшення перекладу мов в середу. NET в Microsoft розроблений проміжна мова - Microsoft Intermediate Language (MSIL). Щоб відкомпілювати додаток для. NET, компілятори беруть вихідний код і створюють з нього MSIL-код. MSIL - це повноцінний мову, придатний для написання додатків. Однак, як у випадку з асемблерні мовою, вам навряд чи доведеться цим займатися, крім якихось особливих обставин. Кожна група розробників компілятора вирішує, якою мірою він буде підтримувати MSIL. Але якщо творці компіляторів захочуть, щоб їхня мова повноцінно взаємодіяв з іншими мовами, їм доведеться обмежити себе рамками, обумовленими специфікаціями CLS.

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

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

Ви пишете вихідний код на С #.

Потім ви компіліруете його за допомогою компілятора мови З # в ЕХЕ-файл.

компілятор створює MSIL-код і поміщає в розділ "тільки-на-чте-ние" вихідного файлу стандартний РЕ-заголовок (ознака машино-незалежної виконуваної програми для Win32). Поки що все добре. Але тут з'являється дуже важлива деталь: при створенні вихідного файлу компілятор імпортує з CLR функцію _CorExeMain.

Коли програма починає виконуватися, ОС завантажує цей РЕ (втім, як і звичайний РЕ), а також усі потрібні DLL, зокрема, бібліотеку, яка експортує функцію _CorExeMain (mscoree.dll).

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

Однак так як ОС не в змозі виконати MSIL-код, то фактично в точці входу міститься заглушка, в якій встановлена команда переходу до функції jCorExeMain з mscoree.dll.

Функція JCorExeMain переходить до виконання MSIL-коду, розміщеного в РЕ.

Так як MSIL-код не може бути виконаний безпосередньо (адже це не машинний код), CLR компілює його за допомогою оперативного (just-in-time, або JIТ) компілятора (його ще називають JITter) в команди процесора. Ця компіляція виконується тільки для безпосередньо викликаються методів програми. Скомпільованій виконуваний код зберігається на машині і перекомпілюються тільки у разі зміни початкового коду. Для перетворення MSIL в даний машинний код можна застосувати один з таких JIТ-компіляторів.

Генератор коду при установці (Install-time code generation) Виконує компіляцію всієї збірки в двійковий код, специфічний для даного процесора, подібно до того, як це робить компілятор С #. Збірка (assembly) - це комплект модулів коду, що посилається компілятору. (О збірках докладніше я розповім нижче в розділі "Розгортання".) Ця компіляція виконується під час установки, коли обробка Складання ЛТ-компілятором менше всього помітна для кінцевого користувача. Перевага цього типу генерації двійкового коду в тому, що компіляція всієї збірки виконується один раз ще до запуску програми. Оскільки код скомпільовано, то про втрати продуктивності під час першого виклику методу програми можна не турбуватися. Це аналогічно тому, як квартиронаймач, щоб кожен місяць не боліла голова, де взяти гроші на чергову виплату, платить вперед відразу за весь період. Питання про доцільність застосування цієї утиліти вирішується в залежності від розміру конкретної системи і середовища, в якому відбувається її розгортання. Якщо ви, як це часто буває, збираєтеся створити для своєї системи настановне додаток, використовуйте цей ЛТ-компілятор, щоб у користувача була вже повністю оптимізована версія системи "з голочки".

JIT Стандартний JITter, що викликається при виконанні програми кожного разу для вперше керуючі методу (у порядку, описаному вище). Це нагадує плату в намічений термін. Цей режим працює за замовчуванням, якщо ви не запускаєте явно компілятор РrеJIТ.

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

Уніфікована система типів

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

Метадані і відображення

Як уже говорилося в розділі "Microsoft Intermediate Language і компілятори JITter ", CLS-сумісні компілятори створюють з вашого вихідного коду MSIL-код, що підлягає компіляції (за допомогою ЛТ-ком-піляторов) перед своїм виконанням. Крім перекладу вихідного коду в MSIL-послідовність, CLS-сумісні компілятори виконують і іншу настільки ж важливе завдання: впровадження метаданих у вихідний ЕХЕ-файл.

Метадані (metadata) - це дані описують інші дані. У нашому контексті - це набір програмних елементів ЕХЕ-файла, таких як типи і реалізації методів. Чи не правда, звучить знайомо? Ці метадані схожі на бібліотеки типів (typelib), що генеруються компонентами Component Object Model (COM). Метадані, що породжуються. NET-компілятором, як правило, не тільки набагато виразніше й повніше, ніж бібліотеки типів СОМ, до яких ми встигли звикнути. Метадані також завжди впроваджені в ЕХЕ-файл. Завдяки цьому виключені випадкові втрати метаданих програми та неузгодженість файлів.

Причина використання метаданих очевидна. Завдяки цієї технології CLR дізнається, які під час виконання будуть потрібні типи і які методи повинні бути викликані. Це дає середовищі можливість виконати належну налаштування для більш ефективного виконання програми. Механізм запиту метаданих називається відображенням (reflection). Бібліотеки класів. NET Framework мають цілий набір методів відображення, дозволяють будь-якому додатку (і не тільки CLR) запросити метадані іншої програми.

Такі інструменти, як Visual Studio.NET, використовують методи відбиття для реалізації коштів подібних IntelliSense. За наявності Inte-lliSense ви, набираючи ім'я методу, бачите на екрані спливаючий список з аргументами цього методу. Visual Studio.NET доповнює це засіб, показуючи ще і всі члени типу. Про API відображення див. розділ 15.

Ще один надзвичайно корисний. NET-інструмент, використовує перевагу відбиття, - Microsoft. NET Framework IL Disassembler (ILDASM). Ця потужна утиліта виконує синтаксичний розбір метаданих обраної програми, а потім відображає інформацію про нього у вигляді дерева. Ось як виглядає програма "Hello, World" на С # в ILDASM (рис. 2-1):

Рис 2.1. Додаток З # "Hello, World!", відображене в ILDASM.

На другому плані - головне вікно IL Disassembler. Якщо двічі клацнути метод Main в ієрархічному дереві, на передньому плані з'явиться вікно, яке відображає подробиці методу Main.

Безпека

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

Розгортання

Розгортання - найбільш неприємна процедура розробки великих розподілених систем. Будь-який розробник Windows-програм може сказати, що, зіткнувшись з масою різноманітних двійкових файлів, проблемами реєстру Windows, компонентами СОМ, установкою бібліотек підтримки таких продуктів, як Open Database Connectivity (ODBC) і Data Access Objects (DAO), ви міцно задумаєтеся, а чи правильно ви вибрали рід занять. Слава Богу, розгортання - це та частина. NET, над якою проектувальники добре потрудилися.

Ключ до розгортання. NET-додатків - концепція збірок (assemblies). Збиранням називають пакет з семантично близьких об'єктів, що складається з одного або декількох файлів. Особливості розгортання залежать від того, що ви розробляєте: Web-серверний додаток або персональне додаток для Windows. Однак з введенням збирання як повністю інкапсульованими набору функціональних можливостей розгортання зводиться до простого копіювання потрібних зборок в місце призначення.

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

Взаємодія з некерованим кодом

Як ви, мабуть, здогадалися, некерованим (unmanaged code) називається код, який не перебуває під наглядом. NET. Пояснимо: цей код теж запускається засобами. NET. Однак у некерованого коду немає тих переваг, якими володіє керований: збору сміття, уніфікованої системи типів і метаданих. Ви питаєте, навіщо запускати некерований код в середовищі . NET? Правильно, без особливої потреби цього робити не варто. Однак ви підете на це, коли у вас не буде іншого виходу. Ось кілька ситуацій, які показують, що можна подякувати Microsoft за те, що в. NET закладена ця особливість.

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

Керований код, який використовує компоненти СОМ З тієї ж причини, з якої потрібно викликати зі свого. NET-додатки функції з DLL, написаної на С, вам потрібно продовжувати підтримку компонентів СОМ. Вихід у тому, щоб створити. NET-оболонку для компонента СОМ так, щоб керований клієнт вважав, ніби він працює з. NET-класом. Цей випадок також розглядається в главі 16.

Некерований код, який використовує. NET-служби Тут протилежна проблема: вам потрібен доступ до. NET з некерованого коду. Вона вирішується за допомогою зворотного підходу: клієнт СОМ вводиться в оману, ніби він працює з СОМ-сервером, який насправді є. NET-службою того ж виду. Приклад такої ситуації також див у главі 16.

Підіб'ємо підсумки

Microsoft. NET - це перехід на обчислювальну модель, в якій пристрої, служби та комп'ютери працюють спільно, забезпечуючи створення рішень для користувачів. Центром цього переходу є розробка . NET Framework і CLR (рис. 2-2). . NET Framework містить бібліотеки класів, спільно використовуються різними мовами, які компілюються для запуску в середовищі CLR. Оскільки С # розроблений для CLR, ви не зможете вирішити навіть найпростіші завдання без CLR і бібліотек класів. NET Framework. Розуміння особливостей цих технологій є необхідною умовою для отримання максимальної користі від С #, а як цього домогтися, ви дізнаєтеся з основної частини цієї книги.

Рис 2.2. В. NET Framework включені бібліотеки, призначені для полегшення взаємодії між службами, пристроями і комп'ютерами.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.realcoding.net