Разработать способ контроля легальности взаимодействия двух приложений

Московский Авиационный Институт

(Государственный Технический Университет) Курсовая работа по ПАЗИ по теме:

Разработать способ контроля легальности взаимодействия двух приложений Выполнил:

студент гр. 4О-304С Поздняков Дмитрий Москва, 2014

Введение

ООП и визуальное проектирование позволяют создавать прикладные программы самого разного назначения. Но в настоящее время приложения, разрабатываемые для различных предприятий и их подразделений, как правило, должны функционировать не сами по себе, а являться частью некоторой информационной системы. В этом случае один из основных вопросов — организация взаимного общения приложений друг с другом и с хранилищами информации — базами данных.

Как правило, приложения, работающие в составе информационной системы, черпают информацию из баз данных, к которым имеют доступ и другие приложения. При этом естественным образом создается возможность общения приложений через данные. Например, одно приложение может записать результаты своей работы в БД, а другое — прочитать эти данные и использовать их в своей работе. Такое простейшее общение требует только одного — унификации данных, форматов их хранения и языка запросов к БД. Последнее решается, чаще всего, с помощью языка SQL.

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

Запуск из одного приложения других приложений позволяет использовать результат работы дочернего процесса, но и только. Часто этого мало. Требуется обмен информацией между приложениями, выполняющимися параллельно. Причем, надо, чтобы этот обмен не зависел от того, на каком языке написано то или иное приложение. А при работе в сети компьютеров, использующих разные платформы (Windows, Unix, Solaris и др.), желательно обеспечить и независимость общения от платформы.

Простейшими средствами общения, появившимися еще на заре Windows, являются разделяемые файлы (файлы, к которым одновременно могут получать доступ разные приложения), буфер обмена Clipboard, доступный практически всем приложениям Windows, и технология DDE — динамического обмена данными. Использование разделяемых файлов, баз данных и буфера обмена достаточно актуальны и сейчас как простейшие средства связи приложений друг с другом. А технология DDE пожалуй, уступила место более современным способам общения.

Позднее появилась технология связывания и внедрения объектов (Object Linking and Embedding) — OLE 1. Она позволяла создавать составные документы, включая, например, в документ Word таблицу Excel. На смену этой технологии пришла OLE 2, позволявшая разным программам предоставлять друг другу свои функции. Пользуясь этой технологией, одно приложение может не просто вызвать другое, но и обратиться к отдельным его функциям, т. е. управлять им.

Следующим шагом на пути совершенствования способов взаимодействия приложений друг с другом явилась разработка COM (Component Object Model) — компонентной модели объектов. Это стандартизованное описание функций (служб) программы, к которым она дает доступ другим программам. При этом неважно, на каких языках написаны программы и где они выполняются: в одном потоке, в разных потоках, на разных компьютерах. Особенно расширяет эти возможности распределенная модификация СОМ — DCOM. Основой технологии СОМ является понятие интерфейса. Каждый объект СОМ имеет несколько интерфейсов, дающих доступ к его функциям. Клиенту передается указатель на требуемый ему интерфейс, после чего клиентское приложение может вызывать описанные в интерфейсе функции.

Основная часть Понятие межпроцессного взаимодействия Межпроцессное взаимодействие (англ. Inter-Process Communication, IPC) — набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов (RPC). Методы IPC зависят от пропускной способности и задержки взаимодействия между потоками и типа передаваемых данных.

IPC также может упоминаться как межпотоковое взаимодействие (англ. inter-thread communication), межпоточное взаимодействие и межпрограммное взаимодействие (англ. inter-application communication).

IPC наряду с концепцией адресного пространства является основой для разграничения адресного пространства.

Топология

Существует два подхода к организации маршрутов взаимодействия интегрируемых систем. Первый — прямое взаимодействие интегрированных систем по принципу «каждая с каждой», или «точка-точка». Второй — взаимодействие через центральный узел; подобную звездообразную архитектуру обычно называемую «хаб + спицы». Топология не зависит от физической архитектуры информационной системы, а определяет логические маршруты взаимодействия и передачи данных между интегрированными системами.

Точка-точка

При данном подходе интегрированные системы взаимодействуют напрямую. Преимущества подхода — простота, прозрачность и отсутствие необходимости в дополнительном программном обеспечении. Однако, есть и недостатки. Во-первых, интегрированные приложения должны общаться с использованием одинаковых методов взаимодействия и форматов вызовов/данных. При изменении одного из приложений (если оно повлекло за собой изменение интерфейса взаимодействия данного приложения) приходится модифицировать или как минимум перенастраивать все интегрированные с ним системы. Во-вторых, в информационной системе предприятия появляется слишком много связей, каждую из которых нужно контролировать и поддерживать в работоспособном состоянии.

Если взаимодействующих приложений много, стоимость сопровождения интегрированной таким образом информационной системы предприятия становится неприемлемо высокой. Тем не менее подход «точка-точка» широко используется. Это происходит, как правило, в тех случаях, когда при взаимодействии конкретных приложений необходимо передавать большие объемы данных или обеспечивать нормированное время взаимодействия, а также если эксплуатируемые на предприятии приложения имеют встроенные средства взаимодействия (это часто случается при внедрении нескольких систем от одного поставщика, а также если при разработке заказных программных систем или внедрении новых к ним изначально предъявляется требование по взаимодействию с уже имеющимися системами).

Здесь, однако, таится опасность «ползучей» интеграции, которая делает возможной ситуации, когда при необходимости поменять систему XYZ неожиданно обнаруживается, что сделать этого нельзя, поскольку справочник оргструктуры и сотрудников вашего предприятия, исторически ведущийся в XYZ, каждую ночь реплицируется еще в десяток систем.

Хаб + спицы

Взаимодействие по типу «точка-точка» создает в инфраструктуре предприятия слишком много связей и требует согласования интерфейсов и форматов данных между взаимодействующими приложениями. Эти недостатки призвана решить архитектура взаимодействия, в которой все приложения непосредственно соединены только с центральным узлом, решающим следующие задачи:

· организация маршрутизации взаимодействия между интегрированными приложениями;

· преобразование форматов файлов и данных;

· обеспечение взаимодействия приложений с использованием разных методов и протоколов взаимодействия.

Благодаря введению промежуточного звена, уменьшается число связей между приложениями, устраняются прямые связи, а система интеграции становится более гибкой и дешевой в эксплуатации. Если меняется одно из интегрированных приложений, то — при условии правильно спроектированной системы интеграции — нужно будет модифицировать только одну связь, между данным приложением и хабом.

Недостатком топологии «хаб + спицы» является высокая стоимость приобретения и сложность программного инструментария, играющего роль хаба, а также нехватка специалистов, имеющих опыт применения подобных программных средств.

Обзор основных технологий

Буфер обмена (clipboard)

Бумфер обмемна (англ. clipboard) — промежуточное хранилище данных, предоставляемое программным обеспечением и предназначенное для переноса или копирования между приложениями или частями одного приложения через операции вырезать, скопировать, вставить.

Как правило, приложения используют буфер обмена, предоставляемый операционной системой или другой средой через определённый интерфейс. Некоторые приложения могут использовать свой собственный буфер обмена, доступный только в них.

Приложение может записывать в буфер обмена одну и ту же информацию одновременно в нескольких различных форматах. Наиболее информативный формат помещается первым, за ним остальные по убыванию информативности. При вставке информации из буфера обмена обычно используется первый распознанный приложением формат, который будет наиболее информативен для данного приложения. Например, если текстовый процессор копирует в буфер обмена текст: в формате RTF, в виде рисунка WMF и в виде текста без форматирования, этот текст может быть вставлен в другой текстовый процессор с сохранением разметки, в графический редактор — рисунком и в простой текстовый редактор — неформатированным текстом. Операционная система может производить некоторые преобразования форматов информации, если запрошенный формат отсутствует в буфере обмена, но может быть получен из имеющегося, например, изменять кодировку текста.

Вставить объект из буфера обмена можно неограниченное число раз. При копировании информации в буфер его предыдущее содержимое, как правило, пропадает. Однако существуют реализации буфера обмена (например, в пакете Microsoft Office), позволяющие хранить в буфере одновременно несколько объектов и выбирать при вставке, который из объектов вставить.

Это одна из самых примитивных и хорошо известных форм IPC. Он появился еще в самых ранних версиях Windows. Основная его задача — обеспечивать обмен данными между программами по желанию и под контролем пользователя. Не рекомендуется использовать его для внутренних нужд приложения, и не стоит помещать туда то, что не предназначено для прямого просмотра пользователем.

Сообщение WM_COPYDATA

Стандартное сообщение для передачи участка памяти другому процессу. Работает однонаправленно, принимающий процесс должен расценивать полученные данные как read only. Посылать это сообщение необходимо только с помощью SendMessage, которая в отличие от PostMessage ждет завершения операции. Таким образом, посылающий поток «подвисает» на время передачи данных. Вы сами должны решить, насколько это приемлемо для вас. Это не имеет значения для небольших кусков данных, но для больших объемов данных или для real-time приложений этот способ вряд ли подходит.

Разделяемая память (shared memory)

Разделяемую память (англ. Shared memory) применяют для того, чтобы увеличить скорость прохождения данных между процессами. В обычной ситуации обмен информацией между процессами проходит через ядро. Техника разделяемой памяти позволяет осуществить обмен информацией не через ядро, а используя некоторую часть виртуального адресного пространства, куда помещаются и откуда считываются данные.

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

Примерный сценарий использования разделяемой памяти при реализации технологий «клиент—сервер» имеет вид:

1. сервер получает доступ к разделяемой памяти, используя семафор;

2. сервер производит запись данных в разделяемую память;

3. после завершения записи данных сервер освобождает доступ к разделяемой памяти с помощью семафора;

4. клиент получает доступ к разделяемой памяти, запирая доступ к этой памяти для других процессов с помощью семафора;

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

Для работы с разделяемой памятью используются системные вызовы:

· shmget — создание сегмента разделяемой памяти;

· shmctl — установка параметров;

· shmat — подсоединение сегмента памяти;

· shmdt — отсоединение сегмента.

В схеме обмена данными между двумя процессами — (клиентом и сервером), использующими разделяемую память, — должна функционировать группа из двух семафоров. Первый семафор служит для блокирования доступа к разделяемой памяти, его разрешающий сигнал — 1, а запрещающий — 0. Второй семафор служит для сигнализации сервера о том, что клиент начал работу, при этом доступ к разделяемой памяти блокируется, и клиент читает данные из памяти. Теперь при вызове операции сервером его работа будет приостановлена до освобождения памяти клиентом.

Этот способ взаимодействия реализуется не совсем напрямую, а через технологию File Mapping — отображения файлов на оперативную память. Вкратце, этот механизм позволяет осуществлять доступ к файлу таким образом, как будто это обыкновенный массив, хранящийся в памяти (не загружая файл в память явно). «Побочным эффектом» этой технологии является возможность работать с таким отображенным файлом сразу нескольким процессам. Таким образом, можно создать объект file mapping, но не ассоциировать его с каким-то конкретным файлом. Получаемая область памяти как раз и будет общей между процессами. Работая с этой памятью, потоки обязательно должны согласовывать свои действия с помощью объектов синхронизации.

Библиотеки динамической компоновки (DLL)

DLL (англ. Dynamic Link Library — «библиотека динамической компоновки», «динамически подключаемая библиотека») в операционных системах Microsoft Windows и IBM OS/2 — динамическая библиотека, позволяющая многократное использование различными программными приложениями. K DLL относятся также элементы управления ActiveX и драйверы. В мире UNIX аналогичные функции выполняют так называемые общие объекты.

Формат файлов DLL придерживается тех же соглашений, что и формат исполняемых файлов, сочетая код, таблицы и ресурсы, отличаясь лишь интерпретацией некоторых полей.

Библиотеки динамической компоновки также имеют способность обеспечивать обмен данными между процессами. Когда в рамках DLL объявляется переменная, ее можно сделать разделяемой (shared). Все процессы, обращающиеся к библиотеке, для таких переменных будут использовать одно и то же место в физической памяти. (Здесь также важно не забыть о синхронизации.)

Протокол динамического обмена данными (Dynamic Data Exchange, DDE)

Этот протокол выполняет все основные функции для обмена данными между приложениями. Он очень широко использовался до тех пор, пока для этих целей не стали применять OLE (впоследствии ActiveX). На данный момент DDE используется достаточно редко, в основном для обратной совместимости.

Больше всего этот протокол подходит для задач, не требующих продолжительного взаимодействия с пользователем. Пользователю в некоторых случаях нужно только установить соединение между программами, а обмен данными происходит без его участия. Замечу, что все это в равной степени относится и к технологии OLE/ActiveX.

OLE/ActiveX

OLE (англ. Object Linking and Embedding) — технология связывания и внедрения объектов в другие документы и объекты, разработанная корпорацией Майкрософт.

В 1996 году Microsoft переименовала технологию в ActiveX.

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

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

OLE используется при обработке составных документов, может быть использована при передаче данных между различными несвязанными между собой системами посредством интерфейса переноса, а также при выполнении операций с буфером обмена. Идея внедрения широко используется при работе с мультимедийным содержанием на веб-страницах, где используется передача изображения, звука, видео, анимации в страницах HTML либо в других файлах, также использующих текстовую разметку (например, XML и SGML). Однако, технология OLE использует архитектуру «толстого клиента», то есть сетевой ПК с избыточными вычислительными ресурсами. Это означает, что тип файла либо программа, которую пытаются внедрить, должна присутствовать на машине клиента. Например, если OLE оперирует таблицами Microsoft Excel, то программа Excel должна быть инсталлирована на машине пользователя.

В 1996 году Microsoft переименовала технологию OLE 2.0 в ActiveX. Были представлены элементы управления ActiveX, ActiveX документы и технология Active Scripting. Эта версия OLE в основном используется веб-дизайнерами для вставки в страницы мультимедийных данных.

Это действительно универсальная технология, и одно из многих ее применений — межпроцессный обмен данными. Хотя, стоит отметить, что OLE как раз для этой цели и создавалась (на смену DDE), и только потом была расширена. Специально для обмена данными существует интерфейс IDataObject. А для обмена данными по сети используется DCOM, которую под некоторым углом можно рассматривать как объединение ActiveX и RPC.

Каналы (pipes)

В среде операционной системы Microsoft Windows NT вам доступно такое удобное средство передачи данных между параллельно работающими процессами, как каналы типа Pipe. Это средство позволяет организовать передачу данных между локальными процессами, а также между процессами, запущенными на различных рабочих станциях в сети.

Каналы типа Pipe больше всего похожи на файлы, поэтому они достаточно просты в использовании.

Через канал можно передавать данные только между двумя процессами. Один из процессов создает канал, другой открывает его. После этого оба процесса могут передавать данные через канал в одну или обе стороны, используя для этого хорошо знакомые вам функции, предназначенные для работы с файлами, такие как ReadFile и WriteFile. Заметим, что приложения могут выполнять над каналами Pipe синхронные или асинхронные операции, аналогично тому, как это можно делать с файлами. В случае использования асинхронных операций необходимо отдельно побеспокоиться об организации синхронизации.

Каналы — это очень мощная технология обмена данными. Наверное, именно поэтому в полной мере они поддерживаются только в Windows NT/2000. В общем случае канал можно представить в виде трубы, соединяющей два процесса. Что попадает в трубу на одном конце, мгновенно появляется на другом. Чаще всего каналы используются для передачи непрерывного потока данных.

Именованные и анонимные каналы

Существуют две разновидности каналов Pipe — именованные (Named Pipes) и анонимные (Anonymous Pipes).

Как видно из названия, именованным каналам при создании присваивается имя, которое доступно для других процессов. Зная имя какой-либо рабочей станции в сети, процесс может получить доступ к каналу, созданному на этой рабочей станции.

Анонимные каналы обычно используются для организации передачи данных между родительскими и дочерними процессами, запущенными на одной рабочей станции или на «отдельно стоящем» компьютере.

Анонимные каналы используются достаточно редко, они просто передают поток вывода одного процесса на поток ввода другого. Именованные каналы передают произвольные данные и могут работать через сеть. (Именованные каналы поддерживаются только в WinNT/2000.)

Сокеты (sockets)

Сокеты (англ. socket — разъём) — название программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на различных ЭВМ, связанных между собой сетью. Сокет — абстрактный объект, представляющий конечную точку соединения.

Следует различать клиентские и серверные сокеты. Клиентские сокеты грубо можно сравнить с оконечными аппаратами телефонной сети, а серверные — с коммутаторами. Клиентское приложение (например, браузер) использует только клиентские сокеты, а серверное (например, веб-сервер, которому браузер посылает запросы) — как клиентские, так и серверные сокеты.

Интерфейс сокетов впервые появился в BSD Unix. Программный интерфейс сокетов описан в стандарте POSIX.1 и в той или иной мере поддерживается всеми современными операционными системами.

приложение память межпроцессный сокет

Принципы сокетов

Каждый процесс может создать слушающий сокет (серверный сокет) и привязать его к какому-нибудь порту операционной системы (в UNIX непривилегированные процессы не могут использовать порты меньше 1024). Слушающий процесс обычно находится в цикле ожидания, то есть просыпается при появлении нового соединения. При этом сохраняется возможность проверить наличие соединений на данный момент, установить тайм-аут для операции и т. д.

Каждый сокет имеет свой адрес. ОС семейства UNIX могут поддерживать много типов адресов, но обязательными являются INET-адрес и UNIX-адрес. Если привязать сокет к UNIX-адресу, то будет создан специальный файл по заданному пути, через который смогут сообщаться любые локальные процессы путём чтения/записи из него (см. Доменный сокет Unix). Сокеты типа INET доступны из сети и требуют выделения номера порта.

Обычно клиент явно подсоединяется к слушателю, после чего любое чтение или запись через его файловый дескриптор будут передавать данные между ним и сервером.

Это очень важная технология, т.к. именно она отвечает за обмен данными в Интернет. Сокеты также часто используются в крупных ЛВС. Взаимодействие происходит через т.н. разъемы-" сокеты", которые представляют собой абстракцию конечных точек коммуникационной линии, соединяющей два приложения. С этими объектами программа и должна работать, например, ждать соединения, посылать данные и т. д. В Windows входит достаточно мощный API для работы с сокетами.

Почтовые слоты (mailslots)

Почтовые слоты — это механизм однонаправленного IPC. Если приложению известно имя слота, оно может помещать туда сообщения, а приложение-хозяин этого слота (приемник) может их оттуда извлекать и соответствующим образом обрабатывать. Основное преимущество этого способа — возможность передавать сообщения по локальной сети сразу нескольким компьютерам за одну операцию. Для этого приложения-приемники создают почтовые слоты с одним и тем же именем. Когда в дальнейшем какое-либо приложение помещает сообщение в этот слот, приложения-приемники получают его одновременно.

Объекты синхронизации

Как ни странно, объекты синхронизации тоже можно отнести к механизмам IPC. Конечно, объем передаваемых данных в данном случае очень невелик. Но именно эти объекты следует использовать, если одному процессу нужно передать другому что-то вроде «я закончил работу» или «я начинаю работать с общей памятью» .

Microsoft Message Queue (MSMQ)

Расшифровывается это как Message Queuing (MSMQ) или Сервер очередей сообщений Microsoft. Очередь сообщений создана для взаимодействия приложений в распределенной среде (на разных компьютерах). Мы уже рассматривали подобные механизмы, например, socket или DCOM. Особенность MSMQ в том, что компьютеры не обязательно должны быть одновременно в сети. То есть можно отправить сообщение, можно получить, а за всем этим следит сервер MSMQ.

Есть несколько деталей, которые отличают очереди сообщений от других механизмов обмена данными в распределенной системе.

Доставка между клиентами одновременно не подключенными Очередь сообщений поддерживается операционной системой Очередь сообщений поддерживает транзакции

MSMQ 1.0 используется в Windows NT 4.0, Windows 95, and Windows 98.

MSMQ 2.0 используется в Microsoft® Windows® 2000.

Этот протокол действительно оправдывает свое название — он обеспечивает посылку сообщений между приложениями с помощью очереди сообщений. Основное его отличие от стандартной очереди сообщений Windows в том, что он может работать с удаленными процессами и даже с процессами, которые на данный момент недоступны (например, не запущены). Доставка сообщения по адресу гарантируется. Оно ставится в специальную очередь сообщений и находится там до тех пор, пока не появляется возможность его доставить.

Удаленный вызов процедур (Remote Procedure Call, RPC)

Строго говоря, это не совсем технология IPC, а скорее способ значительно расширить возможности других механизмов IPC. С помощью этой технологии общение через сеть становится совешенно прозрачным как для сервера, так и для клиента. Им обоим начинает казаться, что их «собеседник» расположен локально по отношению к ним .

Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC)) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).

Принцип Идея вызова удалённых процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова удалённых процедур являются:

· Асимметричность, то есть одна из взаимодействующих сторон является инициатором;

· Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:

· Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация.

· В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика.

· Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удалённо вызванные процедуры станут «осиротевшими», а при аварийном завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удалённых процедур.

· Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.

Разработка способа взаимодействия 2х приложений В качестве способа взаимодействия приложений была выбрана технология разделяемых файлов. В нашем примере одно приложение будет формировать XML файл, и записывать в него данные, необходимые для работы другого приложения. Второе приложение считывает выходной XML файл первого приложения и обрабатывает содержащиеся в нем значения. Данная технология была выбрана в первую очередь в виду простоты ее реализации.

Наши приложения работают на одном локальном компьютере и необходимость их сетевого взаимодействия отсутствует. В случае, когда приложения должны будут работать на разных компьютерах, будет нетрудно организовать взаимодействие с применением технологии веб-сервисов. В этом случае сообщения так же будут иметь структуру XML с небольшими изменениями, вносимыми спецификацией SOAP. Главным отличием будет то, что одно из приложений будет работать в качестве веб-срвиса (сервер), а другое в качестве клиента данного веб — сервиса.

Так же в данном примере отсутствует необходимость запуска второго приложения или получения доступа его функционалу в рамках работы другого приложения. Для решения этих задач лучше всего было бы воспользоваться технологией OLE/ActiveX, которая делает возможным связывание и внедрение объектов в другие документы и объекты.

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

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

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

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

Приложение Пример XML файла

fRa5HLoE4P8k2Bqq9/aVheND5RY=

pV16GUJMtAYQq/qkx4EBWqhb2jyuLx1ni6z20Lp0jA16VZoU1Ltemi6MviNLm4UMbi7boSGG7bN27+vrFZJUv5o+zJBE7sC/fiZkNgQ3xQOC4cxLyrRWeuqobbWDuuut1ayG13m1hzpzWd4uxAKpnmPmMkgM3z2+BNvTUtc0RM4=

Исходный код первой программы

namespace WindowsFormsApplication5

{

public partial class Form1: Form

{

private XmlDocument doc = new XmlDocument ();

public Form1()

{

InitializeComponent ();

}

private void button1_Click (object sender, EventArgs e)

{

if (saveFileDialog.ShowDialog () == DialogResult. OK)

{

int firstNumber = Convert. ToInt32(textBox1.Text);

int secondNumber = Convert. ToInt32(textBox2.Text);

XmlDeclaration newDec = doc. CreateXmlDeclaration («1.0», null, null);

doc.AppendChild (newDec);

XmlElement newRoot = doc. CreateElement («numbers»);

XmlElement firstEl = doc. CreateElement («firstEl»);

firstEl.InnerText = firstNumber. ToString ();

newRoot.AppendChild (firstEl);

XmlElement secondEl = doc. CreateElement («secondEl»);

secondEl.InnerText = secondNumber. ToString ();

newRoot.AppendChild (secondEl);

doc.AppendChild (newRoot);

// Создание контейнера ключей

CspParameters cspParams = new CspParameters ();

cspParams.KeyContainerName = «XML_DSIG_RSA_KEY» ;

// Создание и сохранения в контейнере ключа

RSACryptoServiceProvider rsaKey = new RSACryptoServiceProvider (cspParams);

SignXml (doc, rsaKey);

XmlTextWriter tr = new XmlTextWriter (saveFileDialog.FileName, null);

tr.Formatting = Formatting. Indented;

doc.WriteContentTo (tr);

tr.Close ();

doc = new XmlDocument ();

}

}

public static void SignXml (XmlDocument xmlDoc, RSA Key)

{

// Проверка аргументов

if (xmlDoc == null)

throw new ArgumentException («xmlDoc»);

if (Key == null)

throw new ArgumentException («Key»);

SignedXml signedXml = new SignedXml (xmlDoc);

// Добавление ключа в SignedXml

signedXml.SigningKey = Key;

// Ссылка на подписываемый элемент документа

Reference reference = new Reference ();

reference.Uri = «» ;

// Создание трансформации документа для корректного восстановления

XmlDsigEnvelopedSignatureTransform env = new XmlDsigEnvelopedSignatureTransform ();

reference.AddTransform (env);

signedXml.AddReference (reference);

// Вычисление подписи

signedXml.ComputeSignature ();

// Создание Xml элемента содержащего подпись

XmlElement xmlDigitalSignature = signedXml. GetXml ();

// Добаление подписи в исходный документ

xmlDoc.DocumentElement.AppendChild (xmlDoc.ImportNode (xmlDigitalSignature, true));

}

}

}

Исходный код второй программы

namespace WindowsFormsApplication6

{

public partial class Form1: Form

{

string fileName;

XmlDocument doc = new XmlDocument ();

int numb1;

int numb2;

int sum;

public Form1()

{

InitializeComponent ();

}

private void button1_Click (object sender, EventArgs e)

{

if (openFileDialog.ShowDialog () == DialogResult. OK)

{

fileName = openFileDialog. FileName;

doc.Load (fileName);

}

// Создание объекта CspParameters и добавление контейнера ключей

CspParameters cspParams = new CspParameters ();

cspParams.KeyContainerName = «XML_DSIG_RSA_KEY» ;

// Создание ключа из контейнера

RSACryptoServiceProvider rsaKey = new RSACryptoServiceProvider (cspParams);

// Проверка подписи

bool result = VerifyXml (doc, rsaKey);

// Отображение результатов проверки

if (result)

{

MessageBox.Show («Проверка пройдена»);

}

else

{

MessageBox.Show («Проверка не пройдена»);

}

}

private void button2_Click (object sender, EventArgs e)

{

XmlNode firstEl = doc. SelectSingleNode («numbers/firstEl»);

numb1 = Convert. ToInt32(firstEl.InnerText);

XmlNode secondEl = doc. SelectSingleNode («numbers/secondEl»);

numb2 = Convert. ToInt32(secondEl.InnerText);

sum = numb1 + numb2;

label1.Text = sum. ToString ();

}

public static Boolean VerifyXml (XmlDocument Doc, RSA Key)

{

// Создание SignedXml объекта из документа

SignedXml signedXml = new SignedXml (Doc);

// Поиск элемента Signature

XmlNodeList nodeList = Doc. GetElementsByTagName («Signature»);

// Загрузка первой записи

signedXml.LoadXml ((XmlElement)nodeList[0]);

// Проверка подписи

return signedXml. CheckSignature (Key);

}

private void Form1_Load (object sender, EventArgs e)

{

}

}

}

1. Практическое руководство. Подписание XML-документов с помощью цифровых подписей http://msdn.microsoft.com/ru-ru/library/ms229745%28v=vs.110%29.aspx

2. Интеграция приложений: методы взаимодействия, топология, инструменты http://www.osp.ru/os/2006/09/3 776 464/

3. IPC: основы межпроцессного взаимодействия http://www.rsdn.ru/article/baseserv/ipc.xml

4. Межпроцессное взаимодействие http://ru.wikipedia.org/wiki/Межпроцессное_взаимодействие

5. Службы криптографии http://msdn.microsoft.com/ru-ru/library/92f9ye3s%28v=vs.110%29.aspx

6. Нейгел К., Ивьен Б., Глинн Дж., Уотсон К. — C# 4.0 и платформа .NET 4 для профессионалов — 2011