Approach to interconnection support between Java and MS.NET programming environments
Introduced is the problem of interconnection between reusable components in the heterogeneous environments. The theoretical basis of interconnection support with distributed systems is considered, as well as its implementation in CORBA technology. This knowledge is then used in solving the practical...
Saved in:
| Date: | 2025 |
|---|---|
| Main Author: | |
| Format: | Article |
| Language: | Russian |
| Published: |
PROBLEMS IN PROGRAMMING
2025
|
| Subjects: | |
| Online Access: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/806 |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| Journal Title: | Problems in programming |
| Download file: |  |
Institution
Problems in programming| id |
pp_isofts_kiev_ua-article-806 |
|---|---|
| record_format |
ojs |
| resource_txt_mv |
ppisoftskievua/d3/eb201342c3055a8b497649b8a8a785d3.pdf |
| spelling |
pp_isofts_kiev_ua-article-8062025-08-28T20:52:26Z Approach to interconnection support between Java and MS.NET programming environments Подход к обеспечению взаимодействия программных средств JAVA И MS.NET Підхід до забезпечення взаємодії програмних середовищ Java та MS.NET Ostrovskii, A.V. UDC 681.3 УДК 681.03 УДК 681.3 Introduced is the problem of interconnection between reusable components in the heterogeneous environments. The theoretical basis of interconnection support with distributed systems is considered, as well as its implementation in CORBA technology. This knowledge is then used in solving the practical problem – the interconnection support between Java and Microsoft .NET programming environments via CORBA.Prombles in programming 2011; 2: 34-42 В работе ставится проблема взаимодействия между компонентами в разнородных средах. Рассматриваются теоретические основы обеспечения взаимодействия с помощью распределенных систем, а также их реализация в технологии CORBA. Полученные результаты применяются для решения практической задачи – наладки взаимодействия между платформами Java и Microsoft .NET с использованием CORBA.Prombles in programming 2011; 2: 34-42 У роботі ставиться проблема взаємодії між компонентами у гетерогенних середовищах. Розглядаються теоретичні основи забезпечення взаємодії за допомогою розподілених систем, а також їхня реалізація у технології CORBA. Отримані результати застосовуються для вирішення практичної задачі – налагодження взаємодії між платформами Java і Microsoft .NET з використанням CORBA.Prombles in programming 2011; 2: 34-42 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-08-28 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/806 PROBLEMS IN PROGRAMMING; No 2 (2011); 34-42 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2 (2011); 34-42 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2 (2011); 34-42 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/806/858 Copyright (c) 2025 PROBLEMS IN PROGRAMMING |
| institution |
Problems in programming |
| baseUrl_str |
https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| datestamp_date |
2025-08-28T20:52:26Z |
| collection |
OJS |
| language |
Russian |
| topic |
UDC 681.3 |
| spellingShingle |
UDC 681.3 Ostrovskii, A.V. Approach to interconnection support between Java and MS.NET programming environments |
| topic_facet |
UDC 681.3 УДК 681.03 УДК 681.3 |
| format |
Article |
| author |
Ostrovskii, A.V. |
| author_facet |
Ostrovskii, A.V. |
| author_sort |
Ostrovskii, A.V. |
| title |
Approach to interconnection support between Java and MS.NET programming environments |
| title_short |
Approach to interconnection support between Java and MS.NET programming environments |
| title_full |
Approach to interconnection support between Java and MS.NET programming environments |
| title_fullStr |
Approach to interconnection support between Java and MS.NET programming environments |
| title_full_unstemmed |
Approach to interconnection support between Java and MS.NET programming environments |
| title_sort |
approach to interconnection support between java and ms.net programming environments |
| title_alt |
Подход к обеспечению взаимодействия программных средств JAVA И MS.NET Підхід до забезпечення взаємодії програмних середовищ Java та MS.NET |
| description |
Introduced is the problem of interconnection between reusable components in the heterogeneous environments. The theoretical basis of interconnection support with distributed systems is considered, as well as its implementation in CORBA technology. This knowledge is then used in solving the practical problem – the interconnection support between Java and Microsoft .NET programming environments via CORBA.Prombles in programming 2011; 2: 34-42 |
| publisher |
PROBLEMS IN PROGRAMMING |
| publishDate |
2025 |
| url |
https://pp.isofts.kiev.ua/index.php/ojs1/article/view/806 |
| work_keys_str_mv |
AT ostrovskiiav approachtointerconnectionsupportbetweenjavaandmsnetprogrammingenvironments AT ostrovskiiav podhodkobespečeniûvzaimodejstviâprogrammnyhsredstvjavaimsnet AT ostrovskiiav pídhíddozabezpečennâvzaêmodííprogramnihseredoviŝjavatamsnet |
| first_indexed |
2025-09-17T09:23:31Z |
| last_indexed |
2025-09-17T09:23:31Z |
| _version_ |
1850411447960469504 |
| fulltext |
Методи та засоби програмної інженерії
УДК 681.03
А.В. Островский
ПОДХОД К ОБЕСПЕЧЕНИЮ ВЗАИМОДЕЙСТВИЯ
ПРОГРАММНЫХ СРЕД JAVA И MS.NET
В работе ставится проблема взаимодействия между компонентами в разнородных средах. Рассматри-
ваются теоретические основы обеспечения взаимодействия с помощью распределенных систем, а так-
же их реализация в технологии CORBA. Полученные результаты применяются для решения практиче-
ской задачи – наладки взаимодействия между платформами Java и Microsoft .NET с использованием
CORBA.
Вступление
В наше время с развитием языков
программирования (ЯП) и сред разработки
программ все большее значение приобре-
тает проблема взаимодействия между ком-
понентами, созданными в этих средах.
Множество готовых программ хранится в
специализированных библиотеках (напри-
мер, Matlab, Mathematica, SAS), в среде
систем общего назначения, в Интернете.
При этом они написаны на разных ЯП и
предназначены для работы в разных сре-
дах, так что задача успешной коммуника-
ции между несколькими такими компо-
нентами носит нетривиальный характер.
Очевидна и практическая ценность данной
задачи: адаптация программы в необходи-
мую среду или написание ее «с нуля» за-
частую экономически невыгодны или по-
просту невозможны.
В данной работе рассматриваются
основные принципы построения модели
взаимодействия компонентов в разнород-
ных средах в контексте модели разработки
программного обеспечения. Вводятся ба-
зовые понятия, связанные с распределен-
ными системами; рассматривается архи-
тектура распределенной системы CORBA
с теоретической и практической точки
зрения. Результаты используются для на-
лаживания взаимосвязи между программ-
ными средами Microsoft .NET и Java для
реализации алгоритма шифрования с от-
крытым ключом RSA. При этом в прило-
жении используются преимущества каж-
дой из сред: поддержка вычислений с про-
извольно большими целыми числами в
Java и простота написания пользователь-
ского интерфейса в MS.NET.
1. Принципы взаимодействия программ
в распределенных системах
Модель взаимодействия компонен-
тов повторного использования (КПИ), а
также модели вариабельности и жизнеспо-
собности обоснованы в рамках фундамен-
тального проекта Института программных
систем НАН Украины «Разработка теоре-
тического фундамента генерирующего
программирования (ГП) и инструменталь-
ных средств его поддержки» (шифр III-01-
07, 2007−2011) и образуют составные час-
ти модели разработки программного обес-
печения и программных систем (ПС) [1−3].
К настоящему времени сформировался
модельный подход к разработке ПС. Поя-
вилось множество разных моделей, среди
которых основными и наиболее часто ис-
пользуемыми в практике разработки ПС
являются следующие:
1) генерирующая (порождающая) мо-
дель GDM (Generative Domain Model);
2) сервисно-ориентированная модель
SOA (Service-Oriented Architecture);
3) архитектурно-ориентированная мо-
дель MDA (Model Driven Architecture);
4) модель OSI (Open Systems Intercon-
nection) и др.
В данной работе рассматриваются
принципы взаимодействия разных компо-
нентов в рамках генерирующей модели
ПС, при которой приложение порождается
из отдельных элементов – компонентов,
сервисов, каркасов и т. п. В основе этой
© Островский А.В., 2011
ISSN 1727-4907. Проблеми програмування. 2011. № 2
34
Методи та засоби програмної інженерії
35
модели лежит объектно-ориентированный
подход, дополненный механизмами поро-
ждения КПИ и средствами их взаимодей-
ствия. К модели взаимодействия (intercon-
nection), дополняющей модель GDM, в
рамках рассматриваемого подхода ГП
предъявляется требование обеспечивать
взаимодействие разнородных компонен-
тов, работающих в разных операционных
средах.
Определяющим аспектом модели
взаимодействия является понятие распре-
деленной системы, в рамках которого вво-
дится несколько принятых вспомогатель-
ных определений.
Определение 1. Хост – компьютер,
на котором выполняются компоненты,
входящие в единую систему.
Для обеспечения взаимодействия
между компонентами, размещенными на
разных хостах, теоретически можно поль-
зоваться примитивами, предоставляемыми
сетевой операционной системой (т. е. ис-
пользуя напрямую транспортные каналы)
либо промежуточным слоем.
Определение 2. Промежуточный
слой (middleware) – слой между сетевой
операционной системой и приложениями,
предназначенный для решения проблем
неоднородности (различия между опера-
ционными системами и средами выполне-
ния по отношению к форматам данных
хоста) и распределения (размещение ком-
понентов на разных хостах).
В разных распределенных системах
используются различные подходы к по-
строению промежуточного слоя. В систе-
мах распределенных баз данных, таких как
IBM CICS и Tuxedo, используется тран-
закционно-ориентированный промежуточ-
ный слой, который обеспечивает одинако-
вый механизм обработки транзакций для
разных БД. Промежуточный слой, ориен-
тированный на сообщения, применяется
для обеспечения надежного обмена сооб-
щениями между компонентами (примером
может служить Java Message Queue). Уда-
ленный вызов процедур (Remote Procedure
Call, RPC), применяемый в операционных
системах MS Windows, позволяет вызы-
вать процедуры за пределами хостов. Та-
кие технологии как CORBA компании
OMG, Microsoft COM, удаленный вызов
методов (Remote Method Invocation, RMI) в
системе Java, используют объектно-
ориентированный промежуточный слой,
считающийся на сегодняшний день более
перспективным.
Определение 3. Распределенная
система – система, состоящая из компо-
нентов, которые расположены на объеди-
ненных в сеть хостах, взаимодействуют
через промежуточный слой, обладают
свойством прозрачности (transparency) и
внешне их механизмы взаимодействия не
отличаются от таковых между компонен-
тами в централизованной системе.
Общая модель взаимодействия
компонентов в распределенной системе
показана на рис. 1.
При реализации распределенной
системы применяется стандартная семи-
уровневая модель ISO/OSI. В этой модели
нижние уровни взаимодействия (физиче-
ский, канальный, сетевой и транспортный)
обеспечиваются сетевой операционной
системой, а самый верхний уровень – при-
кладной – средствами прикладных про-
граммистов. Промежуточный слой реали-
зует уровень представления и уровень сес-
сии. Уровень представления отображает
структуры данных приложения в однород-
ной форме (не зависящей от среды выпол-
нения). Преобразование данных от при-
кладного представления к транспортному
называется маршалингом, а обратное пре-
образование – демаршалингом. Для того
чтобы маршалинг и демаршалинг данных
происходили автоматически и учитыва-
лись на этапе компиляции приложения,
промежуточный слой применяет клиент-
ские и серверные стабы (stub) – специаль-
ные интерфейсы, используемые соответст-
венно компонентом, который осуществля-
ет удаленный вызов, и компонентом, кото-
рый этот вызов обрабатывает. Что касается
уровня сессии, он обеспечивает связь меж-
ду компонентами за счет одного или не-
скольких транспортных каналов, отобра-
жая ссылки на объекты в хосты, которые
эти объекты содержат. В большинстве
распределенных систем с объектно-
ориентированным промежуточным слоем
уровень сессии имеет достаточно сложную
Методи та засоби програмної інженерії
36
Рис. 1. Модель работы распределенной системы
структуру и в данной работе не рассмат-
ривается [4].
2. Распределенная система CORBA
Технология CORBA (Common Re-
quest Broker Architecture, общая архитек-
тура брокера объектных запросов) позво-
ляет организовать взаимодействие между
компонентами с произвольными средами
разработки и выполнения, а также предос-
тавляет возможность удаленного взаимо-
действия. Объектно-ориентированный
промежуточный слой, используемый в
CORBA, предусматривает объединение
программного кода в объекты, интерфейс
доступа к которым описывается на языке
описания интерфейсов IDL (Interface Defi-
nition Language) [5]. В нем определены
атомарные типы: boolean (логическая
переменная), char (символ), short (це-
лое число, 2 байта), long (целое число, 4
байта), float (число с плавающей запя-
той, 4 байта), string (символьная строка)
и другие. С помощью атомарных типов
строятся более сложные: списки (se-
quence), структуры (struct), массивы
(array), объединения (union). Компо-
ненты повторного использования опреде-
ляются с использованием ключевого слова
interface; объектная модель IDL под-
держивает ограничение доступа к полям
объектов и обработку исключительных
ситуаций. Типы данных, поддерживаемые
ЯП, определенным образом отображаются
в типы IDL и обратно. Стандартом уста-
новлены отображения для языков Ada,
C++, C, Lisp, Smalltalk, Java, COBOL, Ob-
ject Pascal, PL/1, Python; созданы отобра-
жения и для других языков и сред разра-
ботки, в том числе для языков среды .NET
[6].
Промежуточный слой в технологии
CORBA обеспечивается брокером объект-
ных заявок (ORB). ORB производит ком-
пиляцию IDL-описаний компонентов, соз-
дание клиентских и серверных стабов
(скелетонов в терминологии CORBA).
Существует большое количество реализа-
ций брокеров, такие как Borland Enterprise
Broker, MICO, omniORB, JacORB; брокер
объектных заявок входит в пакет Java
Development Kit. Помимо этого, сущест-
вуют пакеты, которые расширяют функции
брокера заявок, позволяя компилировать
IDL-описания и стабы для дополнитель-
ных ЯП (например, для языков платформы
Microsoft .NET с помощью пакета
IIOPNet). Схема работы распределенной
системы CORBA изображена на рис. 2.
Рис. 2. Схема работы распределенной системы CORBA
Методи та засоби програмної інженерії
37
3. Практическая реализация взаимодей-
ствия компонентов в распределенной
системе
Фрагменты кода на языках Java [7],
[8] и C# [9], (для платформы .NET), приве-
денные далее, не претендуют на полноту и
используются для демонстрации основных
принципов программирования распреде-
ленной системы.
3.1. Описание практической задачи
В качестве теста для проверки взаи-
модействия сред используется программа
шифрования с открытым ключом RSA. Со-
гласно алгоритму шифрования, случайным
образом выбираются два достаточно боль-
ших простых числа p и q. Затем вычисляет-
ся их произведение и функция Эй-pqN =
лера от него )1)(1()( −−= qpNφ . В качест-
ве открытого ключа используется пара
),( Ne , где e – некоторое небольшое число
(одно из чисел Ферма 17, 257, 65537); в ка-
честве секретного – пара , где число d ),( Nd
взаимно обратно к e по модулю )(Nφ . Ко-
дирование числа M состоит в вычислении
)(mod NMX e= , раскодирование – в вы-
числении . Надежность )(mod NXM d=
шифрования для алгоритма зависит от ве-
личины числа N – в настоящее время на-
дежным считается 1024-битный ключ. Для
эффективной реализации RSA нужно, что-
бы среда программирования поддерживала
операции над большими числами. Одной из
таких сред является Java, в ней большие
числа реализованы в виде класса
BigInteger из модуля java.math, ко-
торый предоставляет всю необходимую
функциональность: арифметические опера-
ции, генерацию случайных простых чисел,
модульную арифметику. Таким образом, в
данном случае использование Java для сер-
верной части приложения вполне естест-
венно.
CORBA реализует объектный подход
к проблеме взаимодействия, поэтому один
из главных вопросов при работе с этой тех-
нологией состоит в определении структуры
объектов. Объект RSAService, имплемен-
тирующий алгоритм шифрования RSA,
содержит следующие методы:
− newKey() – генерирует открытый и
секретный ключи и возвращает открытый
ключ;
− encode(key, message) – кодирует
текстовое сообщение message открытым
ключом key. Поскольку алгоритм предна-
значен для кодирования чисел, сообщение
разбивается на фрагменты, каждый из кото-
рых определенным образом переводится в
число, не превосходящее N, и затем кодиру-
ется согласно вышеописанному методу;
− decode(key, code) – декодирует зако-
дированное сообщение секретным ключом,
соответствующим открытому ключу key;
− checkKey(key) – проверяет откры-
тый ключ key на подлинность. Фактически,
этот метод проверяет, существует ли сек-
ретный ключ с числом N таким же, как и в
открытом ключе. Методы encode и decode
будут выполнять эту проверку перед нача-
лом вычислений.
При такой архитектуре объекта
клиентам передаются только открытые
ключи, а соответствующие им секретные
хранятся на сервере. Это обеспечивает со-
кращение длины открытого ключа (вместо
пары чисел достаточно хранить
только N, поскольку e можно оставлять
фиксированным), следовательно, уменьша-
ется и количество данных, которыми об-
мениваются клиент и сервер.
),( Ne
Так как в клиентской среде .NET
отсутствует аналог больших чисел, в при-
ложении используется текстовое пред-
ставление ключа и закодированных сооб-
щений в системе исчисления с достаточно
большим основанием (чтобы получившие-
ся строки имели меньшую длину). Таким
образом, все данные, которыми обменива-
ются клиент и сервер, имеют строковый
тип. Как в ЯП Java, так и среде .NET стро-
ки являются неизменяемыми (immutable)
экземплярами класса String, причем по-
ля и методы класса определяются по-
разному. Из-за этого прямое преобразова-
ние строк при переходе от одной среды к
другой затруднено. При этом в обеих сре-
дах программирования строки хранятся
Методи та засоби програмної інженерії
внутри объектов String в виде последо-
вательности символов Unicode фиксиро-
ванной длины и поэтому соответствуют
стандартному типу данных CORBA
wstring, т. е. передача данных через
CORBA не вызывает проблем.
3.2. Описание серверной части прило-
жения
Технология CORBA интегрирована
в среду программирования Java. Регистра-
ция объекта в этой распределенной систе-
ме подразумевает создание трех базовых
частей приложения:
1) интерфейс объекта, содержащий
описание всех удаленно доступных полей
и методов объекта. Этот интерфейс насле-
дуется от стандартного интерфейса
Remote из модуля java.rmi; каждый
его метод декларируется как потенциально
вызывающий исключение RemoteEx-
ception, поскольку это исключение воз-
буждается серверным скелетоном при воз-
никновении каких-либо неполадок. С уче-
том описанной в разделе 3.1 архитектуры
объекта, декларация интерфейса будет вы-
глядеть так, как показано на рис. 3. Поми-
мо четырех функций, упомянутых ранее, в
описании интерфейса также объявляется
функция getVersion, возвращающая
версию объекта;
2) класс, являющийся потомком клас-
са PortableRemoteObject из модуля
javax.rmi, который реализует описан-
ный интерфейс. Этот класс определяется с
публичным конструктором без аргументов
(у PortableRemoteObject конструк-
тор имеет область видимости
protected), причем в простейшем слу-
чае никаких действий, помимо вызова ро-
дительского конструктора, внутри него не
производится;
3) сервер, публикующий ссылку на
класс, делая его доступным для других
программ с помощью метода rebind сер-
виса именования Context. Этот метод
связывает имплементацию объекта с его
именем в виде строки; другие приложения,
использующие технологию CORBA, после
этого могут обращаться к этому объекту
по его имени.
Как уже упоминалось в разделе 2, в
комплект разработчика Java Development
Kit встроен брокер объектных заявок. С
помощью приложения rmic из этого пакета
описание интерфейса на языке Java преоб-
разуется в IDL-описание (рис. 4). Метод
getVersion, исходя из его имени, при
этом автоматически превращается в поле
строкового типа с доступом только для
чтения (аналогичным образом преобразу-
ются методы, начинающиеся со слова
set). Это же приложение генерирует ста-
бы, именуемые стандартным образом со-
образно имени интерфейса. В данном слу-
чае клиентский стаб и серверный скелетон
будут называться _RSAService_Stub и
_RSAServiceImpl_Tie соответственно,
при этом фактически приложение будет
использовать только скелетон, так как
клиентская часть приложения написана не
на Java.
Рис. 3. Описание интерфейса доступа к объекту в среде Java
38
Методи та засоби програмної інженерії
39
Рис. 4. Описание объекта на языке IDL
3.3. Описание клиентской части прило-
жения
В отличие от Java, платформа .NET
не располагает встроенными средствами
работы с технологией CORBA. Для их
взаимодействия используются пакеты сто-
ронних разработчиков, одним из которых
является IIOPNet с открытым исходным
кодом. С помощью утилиты из этого паке-
та IDL-описание объекта преобразуется в
CLS-совместимую библиотеку, которая
затем присоединяется к приложению. Для
рассматриваемого приложения библиотека
будет содержать описание интерфейса
RSAService.
Для связи с брокером ORB пакет
IIOPNet предоставляет канал связи
IiopClientChannel и сервис именова-
ния NamingContext, позволяющий по-
лучить ссылку на объект по его имени. Ка-
нал фактически играет роль клиентского
стаба, выполняя маршалинг и демарша-
линг передаваемых через него данных.
Метод resolve сервиса именования воз-
вращает ссылку на объект по его имени,
которое было задано вызовом метода
rebind. В платформе Microsoft .NET
возвращаемое значение имеет тип
MarshalByRefObject, что позволяет
трактовать все обращения к полям и мето-
дам объекта как удаленные вызовы. Ис-
пользование канала и сервиса именования
в клиентской части приложения показано
на рис. 5.
Общая последовательность шагов
построения приложения такая:
1) cкомпилировать серверную часть
приложения;
2) с помощью утилиты rmic создать
серверный скелетон и описание объекта на
языке IDL;
3) пользуясь пакетом IIOPNet, преоб-
разовать полученное IDL-описание в CLS-
совместимую библиотеку;
4) присоединить библиотеку к клиент-
ской части приложения для использования
сервиса.
Рис. 5. Использование объекта в клиентской части приложения
Методи та засоби програмної інженерії
На рис. 6 и рис. 7 показана реализация ин-
терфейса программы: серверная часть яв-
ляется консольным приложением, клиент-
ская использует графический интерфейс.
Рис. 6. Интерфейс серверной части приложения
Рис. 7. Интерфейс клиентской части приложения
40
Методи та засоби програмної інженерії
41
3.4. Обработка исключительных ситуа-
ций
Часто необходимо, чтобы сервер
передавал клиенту отчеты об исключени-
ях, возникающих при обработке запросов.
В случае рассматриваемого в данной рабо-
те сервиса шифрования с открытым клю-
чом исключительные ситуации могут воз-
никать в нескольких ситуациях:
1) используется некорректное строко-
вое представление чисел (т. е. открытого
ключа или закодированного сообщения)
при вызове функций encode и decode;
2) предоставленный для кодирования
или декодирования открытый ключ не яв-
ляется подлинным.
Спецификация CORBA включает в
себя исключения, порождаемые методами
объектов, однако использование стандарт-
ных исключений Java для этих целей не-
возможно, так как они не поддерживают
маршалинг. Чтобы обойти эту проблему, в
серверной части приложения определяется
пользовательский тип исключения
RSAException, имплементирующий ин-
терфейс java.io.Serializable, так
как в Java все объекты, в том числе и ис-
ключения, поддерживающие маршалинг,
реализуют этот интерфейс. Способ преоб-
разования данных к транспортному пред-
ставлению и обратно при этом выбирается
платформой Java автоматически. После
изменения соответствующим образом дек-
лараций методов encode и decode в ин-
терфейсе RSAService при компиляции
IDL-описания объекта будут автоматиче-
ски сгенерированы описания объектного
типа данных (ключевое слово языка IDL
valuetype) RSAException, соответст-
вующего исключению, и его обертки –
CORBA-совместимого исключения (ex-
ception) RSAEx.
Помимо этого, будут сгенерирова-
ны описания некоторых стандартных клас-
сов Java, связанных с пользовательским
исключением, например, Exception и
Throwable из модуля java.lang, яв-
ляющиеся его предками в иерархии клас-
сов. IDL-файлы в процессе компиляции
преобразуются в интерфейсы и помещают-
ся в CLS-совместимую библиотеку, так
что их имплементация обеспечивается
клиентской частью приложения. Исключе-
ние RSAEx после компиляции станет по-
томком класса пользовательского исклю-
чения AbstractUserException, опре-
деленного в пакете IIOPNet; аналогично
IDL-описанию, оно будет содержать в себе
экземпляр объекта RSAException.
Итак, проверка на возникновение
исключительных ситуаций в клиентской
части приложения будет осуществляться
так, как показано на рис. 8.
Написание реализаций интерфейсов
является задачей не программиста, пишу-
щего клиентскую часть приложения, а от-
ветственного за серверную часть. Поэтому
в реальных приложениях имплементации
пользовательских исключений и классов
Java компонуются в отдельную CLS-
совместимую библиотеку, которая постав-
ляется вместе с интерфейсом CORBA-
объекта.
Рис. 8. Обработка исключительных ситуаций клиентом
Методи та засоби програмної інженерії
Заключение
В работе описана реализация задачи
взаимодействия прикладных компонен-
тов, разработанных в программных средах
Microsoft .NET (клиентская часть прило-
жения) и Java (серверная часть) через
CORBA. Приведены общие принципы
взаимодействия в распределенных систе-
мах, в частности в технологии CORBA, а
также принципы написания КПИ в про-
граммных средах MS.NET и Java. Разрабо-
тана структура распределенного приложе-
ния, реализующего алгоритм шифрования
с открытым ключом с возможностью об-
работки исключительных ситуаций. Полу-
ченный результат взаимодействия демон-
стрирует эффективность использования
каждой из названных сред программиро-
вания.
Автор благодарен руководителю
фундаментального проекта Е.М. Лаврище-
вой за постановку задачи исследования и
помощь в подготовке статьи.
1. Лавріщева К.М. Генерувальне програму-
вання програмних систем і сімейств //
Проблеми програмування. – 2009. – № 1. –
С. 3−16.
2. Андон П.І., Лавріщева К.М. Розвиток фаб-
рик програм в інформаційному світі //
Вісник НАН України. – 2010. – № 10. –
C. 15−41.
3. Лаврищева Е.М. Проблемы интеропера-
бельности разнородных объектов, компо-
нентов и систем. Подходы к ее решению.
Спец. выпуск международной конферен-
ции “УКРПрО – 2010”, Проблеми програ-
мування.– 2010. – № 2-3. – С. 28−41.
4. Эммерих В. Конструирование распреде-
ленных объектов. Методы и средства про-
граммирования интероперабельных объек-
тов в архитектурах OMG/CORBA,
Microsoft/COM и Java/RMI.: Пер. с англ. –
М.: Мир, 2002. – 510 с., с ил.
5. Лаврищева Е.М., Петрухин В.А. Методы и
средства инженерии программного обес-
печения. Учебное пособие. – М.: МФТИ,
2007. – 415 с.
6. Троэлсен Э. Язык программирования C#
2005 и платформа .NET 2.0. 3-е издание.:
Пер. с англ. – М.: ООО изд. дом Вильямс,
2007. – 1168 с.
7. Naughton P., Schildt H. Java 2: The Complete
Reference, Third Edition. – Osbourne Pub-
lishing, 1999. – 1108 с.
8. http://download.oracle.com/javase/6/docs/ –
документация Java.
9. C# Language Specification. Version 3.0. –
Microsoft, 2007. – 503 c.
Получено 04.01.2011
Об авторе:
Островский Алексей Викторович,
студент 5 курса Киевского отделения
Московского физико-технического инсти-
тута при ФТННЦ НАН Украины,
факультет управления и прикладной мате-
матики.
Место работы автора:
Институт программных систем
НАН Украины,
инженер-конструктор I кат.
e-mail: ostrovski.alex@gmail.com
42
http://download.oracle.com/javase/6/docs/
mailto:ostrovski.alex@gmail.com
Вступление
1. Принципы взаимодействия программ в распределенных системах
2. Распределенная система CORBA
3. Практическая реализация взаимодействия компонентов в распределенной системе
3.1. Описание практической задачи
3.2. Описание серверной части приложения
Технология CORBA интегрирована в среду программирования Java. Регистрация объекта в этой распределенной системе подразумевает создание трех базовых частей приложения:
3.3. Описание клиентской части приложения
В отличие от Java, платформа .NET не располагает встроенными средствами работы с технологией CORBA. Для их взаимодействия используются пакеты сторонних разработчиков, одним из которых является IIOPNet с открытым исходным кодом. С помощью утилиты из этого пакета IDL-описание объекта преобразуется в CLS-совместимую библиотеку, которая затем присоединяется к приложению. Для рассматриваемого приложения библиотека будет содержать описание интерфейса RSAService.
На рис. 6 и рис. 7 показана реализация интерфейса программы: серверная часть является консольным приложением, клиентская использует графический интерфейс.
3.4. Обработка исключительных ситуаций
|