Распределенные системы обработки информации (Анализ тестов и технология Сorba)

Содержание:

ВВЕДЕНИЕ

Технология CORBA(Common Object Request Broker Architecture) – это стандарт написания распределенных приложений, предложенный консорциумом OMG (Open Management Group). Создавая CORBA-объекты, мы можем ,например, существенно уменьшить время решения задач, требующих выполнения большого объема вычислений.

Это возможно благодаря размещению CORBA-объектов на разных машинах. Каждый удаленный объект решает определенную подзадачу, тем самым разгружает клиент от выполнения лишней работы.

Основу CORBA составляет объектный брокер запросов (Object Request Broker).

ORB управляет взаимодействием объектов в распределенной сетевой среде. IIOP (Internet Inter-ORB Protocol) — это специальный протокол взаимодействия между ORB.

В адресном пространстве клиента функционирует специальный объект, называемый заглушкой (stub). Поучив запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его серверу, а точнее скелету.

Скелет (skeleton) — объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает серверу. Также скелет преобразует ответы сервера и передает их клиенту (заглушке).

Для того, чтобы написать любое приложение CORBA используя технологию Java, необходимо иметь две вещи — это установленный пакет JDK1.5 и компилятор idlj (…\jdk1.5.0\bin\idlj.exe). JDK предоставляет набор классов для работы с CORBA объектами, а idlj производит отображение языка IDL в Java.

Цель данной работы – изучить технологию CORBA.

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

1. АНАЛИЗ ТЕСТОВ И ТЕХНОЛОГИЯ CORBA

1.1 Основные архитектурные принципы и задачи

Основное назначение CORBA – поддержка разработки и развертывания сложных объектно-ориентированных прикладных систем. Любого отдельно взятого объектно-ориентированного языка недостаточно для написания распределенных вычислительных систем. Очень часто различные компоненты программной системы требуют реализации на разных языках и, возможно, разных аппаратных платформах. С помощью объектных моделей множество объектов приложения, в том числе и на различных платформах, взаимодействуют друг с другом и реализуют процессы, создавая видимость единого целого^[1].

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

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

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

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

CORBA – это -серверные , в функциональность предоставляется посредством к интерфейсам.

Интерфейс набор , которые функции, данному объектов. Интерфейс клиенту только тот иной , скрывая него детали реализации.

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

В обеих взаимодействие клиентским и объекта, есть , который и экземпляры , использует объектный вызова процедуры (RPC, procedure ). Структура RPC – старейшей из промежуточного обеспечения. Механизм RPC схему сообщений, соответствии которой распределенном -серверном процедураклиент специальное с вызова сети удаленную процедуру, результаты выполнения в сообщении процессу^[2].

Для чтобы эту , на клиента на сервера специальные , носящие клиентский серверный (client и stub). Для чтобы ту иную , клиент к суррогату, упаковывает в -запрос передает на уровень . Серверный суррогат полученное и соответствии переданными вызывает функцию, нужный объекта, речь об варианте RPC. В CORBA суррогат имеет названия, серверный термином .

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

2. Брокер Объектных Заявок

Брокер Объектных Заявок (Object Request Broker – ORB) - промежуточное ПО, устанавливает -серверные между в компьютерной . ORB обеспечивает , позволяющие посылать принимать , отвечать них получать , не о других в среде способе реализации. ORB за реализации -сервера выполнения , подготовку этого к заявки за данных, результатом заявки.

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

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

Интероперабельность брокеров OMG как объекта-, управляемого -1, определенные IDL- операции -сервера, брокером-, при , что -1 брокер- были независимо от . Иначе говоря, вызовы быть от , одним тем или (возможно, ) брокерами взаимодействующие .

CORBA определяет для реализаций ORB, общие и (рис. ). Это обеспечивает клиентов реализаций по к реализациям ORB. ORB интероперабельность глобального пространства. Определения объектов быть в Репозитарий Интерфейсов (Interface Repository) способами: - в спецификации IDL, или . Репозитарий представляет интерфейса объекты обеспечивает к в выполнения.

Рис. . Структура интерфейсов Брокера Объектных Заявок

При заявки может интерфейс вызова генерируемый IDL стаб () - локальную вызова операции обращении ней.

Клиент непосредственно с ORB. В случае ORB соответствующий реализации , пересылает параметры и управление. Реализация принимает заявки сгенерированный IDL скелетон (Skeleton) при может к Объектному Адаптеру (Object Adaptor) ORB. Основная функция адаптера, для CORBA-объекта, - доступа сервисам объектных . Объектный адаптер все средства связи с клиентами. В этих входят:

) генерация на объекты,

) вызов , определенных IDL,

3) безопасности ,

4) и объектов,

) установление между на объекты реальными объектов,

) регистрация .

Спецификация OMG CORBA определяет объектный , который быть во брокерах . Basic Object Adapter (BOA) - это интерфейсов создания на объекты, объектов, запросов активизации . Базовый объектный является первоочередной обеспечения между объекта брокером . Для организации между ORB , например, управления данных быть свой адаптер.

Скелетон – программа, связывает с адаптером, объектному перенаправлять к серванту. При методах скелетон при IDL кода. При – не .

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

Языковое отображение определение для IDL данных интерфейсов к средствами языка . Отображение определяет интерфейса клиента, динамического , скелетона объекта, адаптеров прямые ORB.

Для определенного отображения программный к для типа . Стабы осуществляют к ORB, скрытые , возможно, для ядра ORB . Для определенного отображения , возможно, зависимости используемого Объектного Адаптера обеспечиваться к , реализующим объектный . Вызов этих осуществляется скелетон.

Наличие не существование стаба . Возможно, и . Можно написать Объектный Адаптер, не скелетоны вызова реализации .

Доступно широкое способов конкретных ORB-. Далее будут примеры реализаций. Следует ввиду, конкретный ORB быть сразу способами.

1. ORB, в и приложение.

Если подходящий коммуникаций, возможна ORB-а виде подпрограмм со клиента, и стороны объекта. Вызовы могут в со взаимодействия (Inter Process Communication - IPC).

1. ORB, выполненный виде .

С целью централизованного и всевозможной , ORB может реализован виде приложения.

Взаимодействующие устанавливают с ORB- посредством механизмов IPC.

1. ORB часть .

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

1. ORB, основанный библиотеках.

Если объекта небольшой и требует дополнительных , то может выполнен виде . При этом заглушки самом будут настоящими . При этом , что, доступ данным , клиент разрушит данные.

3. Язык интерфейсов

Один ключевых архитектуры CORBA, интероперабельность , заключается независимости интерфейсов от реализации. Именно решения задачи комплексе CORBA предусматривается язык определения - OMG IDL (Interface Definition Language).

Определение интерфейса средствами OMG IDL характеризует операции, могут данным по клиентов. Это служит информации разработки -клиентов, к с на операций, определениями интерфейсов. Поскольку используемого интерфейса быть его , необходимо отображение , заданных языке OMG IDL, язык клиента.

Для синтаксиса в стандарта CORBA нотация, EBNF (Extended Backus-Naur Format - Расширенный формат Бэкуса-Наура).

::= - по

| - или

< > - символ, заключенным скобки «текст» -

* - возможность предшествующей конструкции или раз

+ - повторения синтаксической один более

{ } - заключенные скобки конструкции как конструкция

[ ] - в синтаксическая является .

При отображении IDL различные программирования CORBA , чтобы IDL были отображены: базовые конструируемые , ссылки объекты константы, в IDL, операций, ситуации, к , сигнатуры в , определенном ORB ( динамического ). Реализация отображения возможность иметь ко функциям ORB виде, для языка . Все реализации ORB следовать OMG отображения конкретного программирования.

Основные , вызывающие при стандартов IDL, включают представления ORB в языке (следует , как представляется программе, он в параметра, осуществляется операций его ); представление ситуаций конкретном ; представление ORB.

К настоящему OMG определены IDL в C, C++ и Smalltalk. Завершается стандарта IDL в Ada. Эта работа проста. Так, обсуждение принятие IDL в С++ более лет работы, важность принятия , используемой OMG.

4. Сетевая объектная CORBA

Интероперабельность брокеров Универсальным Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP универсальным, он зависит конкретной транспортной и быть в транспортный , поддерживающий соединения. Одно таких - отображение GIOP протокол TCP/IP - CORBA 2. в Межброкерного Протокола Internet (Internet Inter-ORB Protocol, сокращенно IIOP). Назначение GIOP/IIOP заключается том, поддержать брокеров рамках Internet за пределами.

Согласно GIOP, архитектура предполагается . Подход, который быть конкретным для GIOP/IIOP, не . Все, что для включения в сеть, - существование с компонентов, посылать принимать IIOP.

Спецификация GIOP включает:

) определение Общего данных (Common Data Representation - CDR), , по , коммуникационным , отображающим типов OMG IDL в передачи между и мостами ();

2) передаваемых агентами GIOP, которые для объектных , установления реализаций и транспортными ;

3) ограничений допустимый транспорт GIOP.

Протокол IIOP, можно специализацией GIOP, дополнительно, агенты соединения TCP/IP используют для сообщений GIOP. GIOP транспортное как . Определяются две роли соединения: клиента роль . Клиент образует и объектные , сервер заявки посылает . Сервер не посылать заявок. Соединение использоваться многочисленными в брокере посылки заявок объектам определенном или . Допускается асинхронная заявок их чередовании соединении.

В сообщениях произвольный байтов ( от процессора), отправителем . Получатель сообщения изменить порядок для образом. Установлены значений типов IDL (, octet, , unsigned , long, long, , double, , enum) границе для полей. Установлено конструируемых IDL (struct, , array, , string), накладывающее требований по к , которые для типов.

Объектная OMG определяет объектную для базовых объектов , независимым реализации .

Объектная модель OMG в объектной - ядра (Core Object Model – COM) совокупности . Объектная модель - - специфицирует набор понятий. Примерами COM являются , операции, , отношение /подтип, , интерфейс . Каждое расширение дополнительный понятий. Расширяться либо COM, уже и расширения. При вводится профиля, некоторой COM, и или расширений, поддерживающих целевую .

Объектная модель CORBA взаимодействие клиентами серверами. Клиенты - приложения, запрашивают , предоставляемые . Объекты-серверы набор , разделяемых многими . Операция указывает сервис. Интерфейсы описывают операций, могут вызваны определенного . Реализации объектов - приложения, сервисы, клиентами.

5. Основные службы универсальные CORBA

Трехуровневая архитектура систем, спецификациям OMG, в системы данными, взаимодействующих CORBA- и интерфейсы представления .

Однако очевидно, в ИС требуется множество объектных , которые зависят предметной и базовую для распределенными . С целью создания приложений OMG стандартизовал часто сервисы ( CORBAservices 1.).

Сервис Жизненнго Цикла (Life Cycle Service) определяет создания, , перемещения удаления на .

Сервис Именования (Naming service) для и ссылок CORBA-объекты. Его задача в , чтобы образом соединение друг другом. Служба представляет хранилище ссылок. Обращение этому выполняется получения объектной , идентифицируемой читаемому ( разработчику) объекта.

Сервис Событий (Event ) обеспечивает асинхронного приложений.

Сервис Долговременного Хранения (Persistence ) предоставляет универсальных для экземпляров в памяти. Сервис таким , что его на объектной данных.

Сервис Транзакций (Transaction ) поддерживает моделей , включая транзакции. Сервис необходим корректной приложений многопользовательском .

Сервис Отношений (Relationship service) логические между CORBA-. Сервис определяет дополнительных объектов: и . Роль представляет CORBA-объект, характер , а характеризует объектов области.

Сервис Контроля Совместного Доступа (Concurrency service) клиентам свои при разделяемых . Управление разделяемыми осуществляется помощью . Каждая блокировка с ресурсом единственным . Сервис определяет несколько блокировок, соответствуют способам .

Сервис Внешнего Представления (Externalization service) копию CORBA- в некоторого представления - , элемента данных т. .

Сервис Запросов (Query Sevice) обеспечивает запросов объектов. Он собой SQL и на спецификациях SQL3 языке запросов (Object Query Language - OQL).

Сервис Лицензирования (Licensing Service) операции отслеживания компонентов, обеспечить компенсацию использования.

Данный поддерживает модель компонента любой его цикла.

Сервис Свойств (Properties Service) операции, позволяют ассоциировать величины ( свойства) любым .

Сервис Времени (Time Service) предоставляет для времени среде объектов. Кроме , предусматривает для и событиями, на время.

Сервис Безопасности (Security Sercice) полную для безопасности объектов. Он аутентификацию, контроля , конфиденциальность, и прав между .

Сервис Коммерции (Trade Service) обеспечивает «Желтые » для ; это возможность оповещать своих и заявки себе «рынок ».

Сервис Контейнеров (Collection Service) предоставляет CORBA для и общедоступных .

Известно, что OMG не независимыми от . Часть из может создана базе служб. Согласно OMG, существует на . 1 зависимостей службы другой.

Универсальные предоставляют интерфейсов уровня делятся два : горизонтальные вертикальные.

Рис. . Граф зависимостей , специфицированных OMG

Горизонтальные средства интерфейсы, зависящие предметной . В настоящее существует спецификация универсальных , состоящая следующих :

1) Средств интерфейса. Они аспекты, представления , и инструменты разработки , средства автоматизации работы, на стол () пользователя т. .

Средств управления . Они предоставляют , с которых моделировать, , сохранять, , перемещать и ею. Предполагается, данный должен из спецификаций:

• моделирование ( правила, которым структуризация доступ информации),
• и информации ( использование данных систем ),
• информационный ,
• стандарты и , поддерживающие информацией разделяемые , сетевые или интерфейсы.

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

4) Средств задачами. Предполагается, данный будет четырьмя : службы потоками (workflow ), службы агентов ( facility), управления (rule facility), автоматизации ( facility).

Вертикальные предназначены поддержки областей : финансовой , промышленного , медицины т. .

Разрабатываются спецификации средств:

) Средств обработки . Специфицируют доступ обмен данными. Роль службы в приложений пользователя проверке, , визуализации сохранению данных.

) Средств поддержки супермагистрали ( facility). Специфицируется сетей, и их , а множество информации набор , обеспечивающих и доступ этой .

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

4) Средств распределенных . Службы этой должны базис, основе возможно построение функционирование модели.

) Средств информатизации газовой нефтяной . Эта предметная характеризуется количеством и сложностью .

6) Средств коммуникаций ( facility). Включают формы транзакций: валюты, платежами, и .п.

) Средств поддержки приложений. Обслуживают , разработку, и приложений, корпоративную систему. Данные включают анализа, , реализации, и системы.

6. СОЗДАНИЕ CORBA ПРИЛОЖЕНИЯ В J++BUILDER

2. Написание интерфейса

Создание CORBA на Java с интерфейса объекта, язык интерфейсов (Interface Definition Language, IDL).

Создадим hello.

module HelloApp

{

Hello

{

string sayHello();

void ();

};

};

Данный интерфейс лишь метода и sayHello. Причем, не , что эти , главное определяем, они и какие них и параметры.

Далее запустить IDL-to-Java :

idlj - Hello.idl

В директории новая HelloApp, в содержаться java-. Каждый из имеет назначение.

• HelloPOA. java — класс, представляет ни иное, скелет (skeleton) обеспечивает сервера.

• _HelloStub. — класс, заглушку () клиента. Обеспечивает клиента.

• HelloHelper. и HelloHolder. — классы, вспомогательные для CORBA .

• HelloOperations.java — , содержащий интерфейса на Java.

• Hello.java — -наследник HelloOperations, интерфейс .omg.CORBA.Object.

2. Создание

Теперь наша — написать , реализующий hello. В случае будет HelloImpl. Обратите , на , что является класса HelloPOA. В HelloImpl методы, в Hello..

Для упрощения объявление можно из HelloOperations.java, jdlj.

HelloImpl extends HelloPOA {

ORB orb;

void setORB(ORB _val) {

= orb_;

}

// implement sayHello()

public String sayHello() {

"\nHello world !!\";

}

// implement () method

void () {

orb.(false);

}

}

Следующим будет собственно части . Это будет HelloServer.

В нем всего метод – функция .

Первое что делаем, ORB. Затем создаем класса объекта (HelloImpl) регистрируем в ORB. Дальше специальную имен (NameService) регистрируем ней удаленного , чтобы смог найти.

Рассмотрим эти .

1. Создание инициализация ORB. Производится статического init ORB

ORB orb = ORB.(args, );

2. Создание класса объекта регистрация в ORB

HelloImpl helloImpl = HelloImpl();

helloImpl.setORB(orb);

. Получение контекста (NamingContext)

org..CORBA.Object objRef = orb._initial_("NameService");

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

В строчке получаем ссылку службу (NameService). Но фактически обыкновенный CORBA- и того, использовать как имен (NamingContext), вызвать narrow NamingContextHelper, который бы данный CORBA-.

4. Регистрация удаленного (HelloImpl)

String name = "Hello";

NameComponent [] = ncRef.to_( name );

ncRef.(path, );

Регистрация имени для , чтобы смог удаленный . Этой цели функция (NameComponent[] nc, Object ) интерфейса NamingContext.

. Ожидание запросов клиента

.run();

Теперь готов работе.

// HelloServer.

import HelloApp.*;

org..CosNaming.*;

import .omg.CosNaming.NamingContextPackage.*;

org..CORBA.*;

import .omg.PortableServer.*;

org..PortableServer.POA;

import .util.Properties;

HelloImpl extends HelloPOA {

ORB orb;

void setORB(ORB _val) {

= orb_;

}

// implement sayHello()

public String sayHello() {

"\nHello world !!\";

}

// implement () method

void () {

orb.(false);

}

}

class HelloServer {

static main(String []) {

try{

// and the ORB

ORB = ORB.init(, null);

// reference rootpoa & the POAManager

POA =

POAHelper.narrow(.resolve__references("RootPOA"));

.the_POAManager().();

// create and it the ORB

HelloImpl helloImpl = HelloImpl();

helloImpl.setORB(orb);

// object from servant

.omg.CORBA.Object = rootpoa._to_(helloImpl);

Hello href = HelloHelper.(ref);

// the naming

// NameService invokes name

org..CORBA.Object objRef =

orb._initial_("NameService");

// Use NamingContextExt which part the Interoperable

// Naming Service (INS) .

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

// the Object Reference Naming

String name = "Hello";

NameComponent [] = ncRef.to_( name );

ncRef.(path, );

System.out.("HelloServer ready waiting ...");

// for from

orb.();

}

catch (Exception ) {

System.err.("ERROR: " + e);

.printStackTrace(System.out);

}

System..println("HelloServer Exiting ...");

}

}

3. Создание

Перейдем к кода клиента.

Основные написания приложения

1. Создание инициализация ORB
2. Получение службы (NamingContext)
3. Нахождение удаленного
4. Вызов метода sayHello.
5. Вызов shutdown.

Как , первые пункта с создания приложения, рассматривать не .

Третий пункт тоже просто. Создается NameComponent. Вызывается метод (NameComponent[] path), отыскивает имени объект ( CORBA-объект). При метода (org..CORBA.Object obj) helloHelper (сгенерированного компилятором) объектную на hello.

String = "Hello";

helloImpl = HelloHelper.narrow(ncRef._str());

Теперь можно метод sayHello:

System..println(helloImpl.sayHello());

Метод завершает сервера.

helloImpl.();

//testClient.java HelloApp.*;

import .omg.CosNaming.*;

org..CosNaming.NamingContextPackage.*;

import .omg.CORBA.*;

class HelloClient

{

Hello helloImpl;

public void (String args[])

{

{

// create initialize ORB

ORB orb = ORB.(args, );

// get root context

.omg.CORBA.Object objRef =

.resolve__references("NameService");

// Use NamingContextExt of NamingContext. This

// part the Interoperable Service.

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

// the Object Reference Naming

String name = "Hello";

helloImpl = HelloHelper.(ncRef.resolve_(name));

System..println("Obtained handle server : " +

helloImpl);

System.out.(helloImpl.sayHello());

helloImpl.shutdown();

} (Exception e) {

System..println("ERROR : " + ) ;

e.printStackTrace(System.);

}

}

}

2. Компиляция и приложения

Файлы HelloServer. and HelloClient., Hello.idl папка HelloApp, idkj. должны в папке.

Для клиента сервера в строке

javac *. HelloApp/*.java

.exe в …\.5.\bin.

Среда Eclipse позволяет CORBA-приложения. Для

1. Запустить orbd - Object Request Broker Daemon (…\.5.\bin\.exe). Это , чтобы смогли ссылку службу .

start -ORBInitialPort 1050

Параметр -ORBInitialPort– порта, котором работать имен.

. Запуск сервера

java HelloServer -ORBInitialPort -ORBInitialHost localhost

Указывается , на работает имен. Параметр -ORBInitialHost хост, котором сервер .

3. Запуск

java HelloClient -ORBInitialPort -ORBInitialHost localhost

Указывается , на работает имен. Параметр -ORBInitialHost хост, котором сервер .

Для удобства и можно bat-:

idlj - Hello.idl

*.java HelloApp/*.

start HelloServer -ORBInitialPort 1050 -ORBInitialHost

java HelloClient -ORBInitialPort -ORBInitialHost localhost

ЗАКЛЮЧЕНИЕ

Нужно , что CORBA нацелена достижение - разработки систем:

• систем , находящихся условиях и неоднородности, также и информационных ;
• интеграция;
• ;
• миграция ;
• повторное неоднородных ресурсов;
• жизненного систем.

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

СПИСОК ЛИТЕРАТУРЫ

1. Белоусов В.Е., Дехтенко В.О., Белоусов А.В. Применение технологии CORBA задачах систем // сборник трудов XX Международной -практической . 2016
2. Калиниченко Л.А., Когаловский М.Р. Интероперабельность в CORBA 2.//СУБД. -2013. -№ .
3. Кен Арнольд, Джеймс Гослинг, Дэвид Холмс. Язык программирования Java™.
4. Кирьянов С.К. Применение CORBA для машины запросов // Вестник Нижегородского Университета . Н.И. Лобачевского. Серия: Математическое моделирование оптимальное . – 2014. - № . – С. 258-
5. Маслобоев А.В., Шишаев М.Г. Распределенные системы компьютерные обработки : учеб. . – Апатиты: Изд-во КФ ПетрГУ,
6. Омельченко А.И. Особенности построения информационных на технологии CORBA // Материалы VIII Международной -практической . 2015
7. Сравнение COM CORBA [Электронный ресурс] URL: ://kunegin./ref3//12.
8. СОМ или CORBA [Электронный ] URL: http://.narod./base/_or_.html
9. Механизм удаленных – RPC [Электронный ресурс] URL: ://delphiworld..ru//rpc_.html
10. PowerBuilder .0 - инструментарий создания распределенных -серверных [Электронный ресурс] URL: ://www..ru//www2//1996//97.
11. Разработка распределённого Web- [Электронный ресурс] URL: ://www..ru//webdevelopment/-57-.xml
12. Понятие -серверных [Электронный ресурс] URL: ://bourabai./dbt/.htm
13. Компоненты приложения. Клиент- взаимодействие роли . [Электронный ресурс] URL: ://www..info//lecture5.
14. Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов приложения модели анализа исправления экзаменационного . Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, .05., Taraz, Kazakhstan. - №5, . -p.-83. [Электронный ] URL: http://.ru/.asp?=20357857

1. СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html ↑

2. PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm; Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml ↑