Взаимодействие систем в Интернете

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

1. Принципы взаимодействия программ в распределенных системах Модель взаимодействия КП И входит в состав модели разработки ПО и ПС [1—3]. К настоящему времени сформировались следующие модели:

• • генерирующая модель GDM {Generative Domain Model);
• • сервисно ориентированная модель SO A {Senice-Oriented Architecture);
• • архитектурно ориентированная модель MDA (Model Driven Architecture);
• • модель OSI {Open Systems Interconnection) и др.

В рамках генерирующей модели ПС приложение порождается из отдельных элементов — компонентов, сервисов, каркасов и т. п. В основе этой модели лежит ООП, дополненный механизмами порождения КИИ и средствами их взаимодействия. К модели взаимодействия {interconnection) в GDM предъявляется требование обеспечения взаимодействия разнородных компонентов, работающих в разных операционных средах.

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

Определение 1. Хост — компьютер, на котором взаимодействуют компоненты, входящие в единую систему.

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

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

В разных распределенных системах используются подходы к построению промежуточного слоя. В системах распределенных баз данных, таких как IBM CICS и Tuxedo, используется транзакционно-ориентированный промежуточный слой, который обеспечивает одинаковый механизм обработки транзакций для разных БД. Промежуточный слой, ориентированный на сообщения, применяется для обеспечения надежного обмена сообщениями между компонентами (примером может служить Java Message Queue). Удаленный вызов процедур (Remote Procedure Call, RPC), применяемый в операционных системах MS Windows, позволяет вызывать процедуры за пределами хостов. Такие технологии, как CORBA компании OMG, Microsoft СОМ, удаленный вызов методов (Remote Method Invocation, RMI) в системе Java, используют объектно ориентированный промежуточный слой, считающийся более перспективным.

Определение 3. Распределенная система — система, состоящая из компонентов, которые расположены на объединенных в сеть хостах, взаимодействуют через промежуточный слой, обладают свойством прозрачности (transparency) и внешне их механизмы взаимодействия не отличаются от таковых между компонентами в централизованной системе.

Общая модель взаимодействия компонентов в распределенной системе показана на рис. П3.1.

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

вызов, и компонентом, который этот вызов обрабатывает. Что касается уровня сессии, он обеспечивает связь между компонентами за счет одного или нескольких транспортных каналов, отображая ссылки на объекты в хосты, которые эти объекты содержат. В большинстве распределенных систем с объектно ориентированным промежуточным слоем уровень сессии имеет достаточно сложную структуру и не будет рассматривается [4].

2. Распределенная система CORBA.

Технология CORBA (Common Request Broker Architecture — общая архитектура брокера объектных запросов) позволяет организовать взаимодействие между компонентами с произвольными средами разработки и выполнения, а также предоставляет возможность удаленного взаимодействия. Объектно ориентированный промежуточный слой, используемый в CORBA, предусматривает объединение программного кода в объекты, интерфейс доступа к которым описывается на языке описания интерфейсов IDL (Interface Definition Language) [5].

В нем определены атомарные типы: boolean (логическая переменная), char (символ), short (целое число, 2 байта), long (целое число, 4 байта), float (число с плавающей запятой, 4 байта), string (символьная строка) и др.

С помощью атомарных типов строятся более сложные: списки {sequence), структуры (struct), массивы (array), объединения (union). КПИ определяются с использованием ключевого слова interface; объектная модель 1DL поддерживает ограничение доступа к полям объектов и обработку исключительных ситуаций.

ТД, поддерживаемые ЯП, определенным образом отображаются в типы 1DL и обратно. Стандартом установлены отображения для языков Ada, C++, С, Lisp, Smalltalk, Java, Кобол, Object Pascal, PL/1, Python; созданы отображения и для других языков и сред разработки, в том числе для языков среды .NET 161.

Промежуточный слой в технологии CORBA обеспечивается брокером объектных запросов (ORB). ORB производит компиляцию IDL-описаний компонентов, создание клиентских и серверных стабов (и скелетонов в терминологии CORBA). Существует большое количество реализаций брокеров, такие как Borland Enterprise Broker, MICO, omniORB, JacORB; ORB входит в пакет Java Development Kit. Помимо этого, существуют пакеты, которые расширяют функции брокера, позволяя компилировать IDL-описания и стабы для дополнительных ЯП (например, для языков платформы Microsoft .NET с помощью пакета IIOPNet). Схема работы распределенной системы CORBA изображена на рис. П3.2.

Рис. П3.2. Схема работы распределенной системы CORBA.

3. Реализация взаимодействия компонентов в распределенной среде Фрагменты кода на языках Java и C# для платформы .NET, приведенные ниже, используются для демонстрации основных принципов программирования распределенной системы.

3.1. Описание практической задачи В качестве теста для проверки взаимодействия сред используется программа шифрования с открытым ключом RSA. Согласно алгоритму шифрования случайным образом выбираются два достаточно больших простых числа р и q. Затем вычисляется их произведение N = pq и функция Эйлера от него (р (Л') = (р — 1)(г/ -1). В качестве открытого ключа используется пара (е, N), где е — некоторое небольшое число (одно из чисел Ферма 17, 257, 65 537); в качестве секретного — пара (d, N), где число d взаимно обратно к е но модулю <�р (Л'). Кодирование числа М состоит в вычислении Х = M^p(modjV), раскодирование — в вычислении А7 = X^(mod Л^г). Надежность шифрования для алгоритма зависит от величины числа N — надежным считается 1024-битный ключ. Для эффективной реализации RSA нужно, чтобы среда программирования поддерживала операции над большими числами. Одной из таких сред является Java, в ней большие числа реализованы в виде класса Biglnteger из модуля java. math, который предоставляет всю необходимую функциональность: арифметические операции, генерацию случайных простых чисел, модульную арифметику. Таким образом, в данном случае использование Java для серверной части приложения вполне естественно.

CORBA реализует объектный подход к проблеме взаимодействия, поэтому один из главных вопросов при работе с этой технологией состоит в определении структуры объектов. Объект RSAService, имплементирующий алгоритм шифрования RSA, содержит следующие методы:

• • newKey () — генерирует открытый и секретный ключи и возвращает открытый ключ;
• • encode (key, message) — кодирует текстовое сообщение message открытым ключом key, алгоритм которого предназначен для кодирования чисел, а сообщение разбивается на фрагменты, каждый из которых определенным образом переводится в число, не превосходящее N, и затем кодируется согласно вышеописанному методу;
• • decode (key, code) — декодирует закодированное сообщение секретным ключом, соответствующим открытому ключу key,
• • checkKey (key) — проверяет открытый ключ key на подлинность. Фактически, этот метод проверяет, существует ли секретный ключ с числом N таким же, как и в открытом ключе. Методы encode и decode будут выполнять эту проверку перед началом вычислений.

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

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

Таким образом, все данные, которыми обмениваются клиент и сервер, имеют строковый тип. Как в ЯП Java, так и среде .NET строки являются неизменяемыми (immutable) экземплярами класса String, причем поля и методы класса определяются по-разному. Из-за этого прямое преобразование строк при переходе от одной среды к другой затруднено. При этом в обеих средах программирования строки хранятся внутри объектов String в виде последовательности символов Unicode фиксированной длины и поэтому соответствуют стандартному ТД CORBA wstring, т. е. передача данных через CORBA не вызывает проблем.

3.2. Описание серверной части приложения Технология CORBA интегрирована в среду программирования Java. Регистрация объекта в этой распределенной системе подразумевает создание трех базовых частей приложения:

1) интерфейс объекта, содержащий описание удаленно доступных полей и методов объекта. Этот интерфейс наследуется от стандартного интерфейса Remote из модуля java. rmi; каждый его метод декларируется как потенциально вызывающий исключение RemoteException, поскольку это исключение возбуждается серверным скелетоном при возникновении каких-либо неполадок. С учетом описанной в разд. 3.1 архитектуры объекта, декларация интерфейса будет выглядеть так, как показано на рис. ПЗ.З. Помимо четырех функций, упомянутых ранее, в описании интерфейса также объявляется функция getVersion, возвращающая версию объекта;

Рис. ПЗ.З. Описание интерфейса доступа к объекту в среде Java.

• 2) класс, являющийся потомком класса PortableRemoteObject из модуля javax. rmi, который реализует описанный интерфейс. Этот класс определяется с публичным конструктором без аргументов (у PortableRemoteObject конструктор имеет область видимости protected), причем в простейшем случае никаких действий, помимо вызова родительского конструктора, внутри него не производится;
• 3) сервер, публикующий ссылку на класс, делая его доступным для других программ с помощью метода rebind сервиса именования Context. Этот метод связывает имплементацию объекта с его именем в виде строки; другие приложения, использующие технологию CORBA, после этого могут обращаться к этому объекту по его имени.

Как уже упоминалось в разд. 2, в комплект разработчика Java Development Kit встроен ORB. С помощью приложения rmic из этого пакета описание интерфейса на языке Java преобразуется в IDL-описание (рис. П3.4). Метод getVersion, исходя из его имени, при этом автоматически превращается в ноле строкового типа с доступом только для чтения (аналогично преобразуются методы set). Это же приложение генерирует стабы стандартным образом согласно имени интерфейса. В данном случае клиентский стаб и серверный скелетон будут называться _RSAService_Stub и _RSAServiceImpl_Tie соответственно, при этом фактически приложение будет использовать только скелетон, так как клиентская часть приложения написана не на Java.

Рис. ЮЛ. Описание объекта на языке IDL.

3.3. Описание клиентской части приложения В отличие от Java платформа .NET не располагает встроенными средствами работы с технологией CORBA. Для их взаимодействия используются пакеты сторонних разработчиков, одним из которых является IlOPNet с открытым исходным кодом. С помощью утилиты из этого пакета IDLонисание объекта преобразуется в CLS-совместимую библиотеку, которая затем присоединяется к приложению. Для рассматриваемого приложения библиотека будет содержать описание интерфейса RSAService.

Для связи с брокером ORB пакет IlOPNet предоставляет канал связи IiopClientChannel и сервис именования NamingContext, позволяющий получить ссылку на объект по его имени. Канал фактически играет роль клиентского стаба, выполняя маршалинг и демаршалинг передаваемых через него данных.

Метод resolve сервиса именования возвращает ссылку на объект по его имени, которое было задано вызовом метода rebind. В платформе Microsoft .NET возвращаемое значение имеет тип MarshalByRefObject, что позволяет трактовать все обращения к полям и методам объекта как удаленные вызовы. Использование канала и сервиса именования в клиентской части приложения показано на рис. П3.5.

Общая последовательность шагов построения приложения:

• 1) скомпилировать серверную часть приложения;
• 2) с помощью утилиты rmic создать серверный скелетон и описание объекта на языке IDL;
• 3) пользуясь пакетом IlOPNet, преобразовать полученное IDL-описание в CLS-совместимую библиотеку;
• 4) присоединить библиотеку к клиентской части приложения для использования сервиса.

Рис. П3.5. Использование объекта в клиентской части приложения.

Рис. П3.6. Интерфейс серверной части приложения Рис. П3.7. Интерфейс клиентской части приложения.

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

• • используется некорректное строковое представление чисел (т.е. открытого ключа или закодированного сообщения) при вызове функций encode и decode?;
• • предоставленный для кодирования или декодирования открытый ключ не является подлинным.

Спецификация CORBA включает в себя исключения, порождаемые методами объектов, однако использование стандартных исключений Java для этих целей невозможно, так как они не поддерживают маршалинг. Чтобы обойти эту проблему, в серверной части приложения определяется пользовательский тип исключения RSAException, имплементирующий интерфейс java.io.Serializable, так как в Java все объекты, в том числе и исключения, поддерживающие маршалинг, реализуют этот интерфейс. Способ преобразования данных к транспортному представлению и обратно при этом выбирается платформой Java автоматически. После изменения соответствующим образом деклараций методов encode и decode в интерфейсе RSAService при компиляции IDL-описания объекта будут автоматически сгенерированы описания объектного ТД (ключевое слово языка IDL valuetype) RSAException, соответствующего исключению, и его обертки — CORBA-совместимого исключения (exception) RSAEx.

Помимо этого, будут сгенерированы описания некоторых стандартных классов Java, связанных с пользовательским исключением, например Exception и Throwable из модуля java. lang, являющиеся его предками в иерархии классов. IDL-файлы в процессе компиляции преобразуются в интерфейсы и помещаются в CLS-совместимую библиотеку, так что их имплементация обеспечивается клиентской частью приложения. Исключение RSAEx после компиляции станет потомком класса пользовательского исключения AbstractUserException, определенного в пакете IIOPNet; аналогично IDL-оиисанию, оно будет содержать в себе экземпляр объекта RSAException.

Итак, проверка на возникновение исключительных ситуаций в клиентской части приложения будет осуществляться так, как показано на рис. П3.8.

Рис. П3.8. Обработка исключительных ситуаций клиентом Описание реализаций интерфейсов является задачей не программиста, пишущего клиентскую часть приложения, а ответственного за серверную часть. Поэтому в реальных приложениях имплементации пользовательских исключений и классов Java компонуются в отдельную CLS-совместимую библиотеку, которая поставляется вместе с интерфейсом CORBA-объекта.

Вывод. Таким образом, была представлена реализация задачи взаимодействия прикладных компонентов, разработанных в программных средах Microsoft .NET (клиентская часть приложения) и Java (серверная часть) через CORBA. Приведены общие принципы взаимодействия в распределенных системах, в частности в технологии CORBA, а также принципы написания КПП в программных средах MS.NET и Java. Разработана структура распределенного приложения, реализующего алгоритм шифрования с открытым ключом с возможностью обработки исключительных ситуаций. Полученный результат взаимодействия демонстрирует эффективность использования каждой из названных сред программирования.

• 1. Лаврщева, К. М. Генерувальне програмування програмних систем i Лмейств / К. М. Лаврпцева // Проблеми програмування. — 2009. — № 1. — С. 3−16.
• 2. Андон, II. /. Розвиток фабрик програм в шформацшному евт / П. I. Андон, К. М. Лаврщева // Вшник НАН Украши. — 2010. — № 10. — С. 15−41.
• 3. Лаврищева, Е. М. Проблемы интероперабельности разнородных объектов, компонентов и систем. Подходы к ее решению. Спец, выпуск международной конференции «УКРПрО — 2010» / Е. М. Лаврищева // Проблемы программирования. — 2010. — № 2—3. — С. 28—41.
• 4. Эммерих, В. Конструирование распределенных объектов. Методы и средства программирования интероперабельных объектов в архитектурах OMG/CORBA, Microsoft/COM и Java/RMI.: нер. с англ. / В. Эммерих — М.: Мир, 2002.
• 5. Лаврищева, Е. М. Методы и средства инженерии программного обеспечения: учеб, пособие / Е. М. Лаврищева, В. А. Петрухин. — М.: Изд-во МФТИ, 2007.
• 6. Островский, А. В. Подход к обеспечению взаимодействия программных сред Java и Ms.Net / А. В. Островский // Проблеми програмування. —
• 2011. -№ 2.-С. 37−44.
• 7. Радецький, I. О. Один з шдхо;ив до забезпечення взаемодп середовищ MS.Net i Eclipse / I. О. Радецький // Проблеми програмування. — 2011. — № 2. — С. 45−52.
• 8. Lavrischeva, Е. General Disciplines and Tools for E-learning Software Engineering / E. Lavrischeva, A. Ostrovski // 8th International Conf. ICTERI- 2013 «1СТ in Education, Research and Industrial Applications», Ukraine, June,
• 2012, Springer.com, Communication in Computer and Information Sciences. — P. 212−229.
• 9. Бабенко, Л. П. Онтологический подход к спецификации свойств программных систем и их компонент / Л. П. Бабенко // Кибернетика и системный анализ. — 2009. — № 1. — С. 30—37.