Технология построения распределенных информационных систем (Архитектурные принципы реализации приложений)

Содержание:

Введение

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

В данной работе рассматривается одна из ведущих технологий создания распре­делённых систем - CORBA, предложенная крупнейшим в мире консорци­умом разработчиков программного обеспечения Object Management Group (OMG). Представлено описание распределённой программной системы – машины удалённых запросов, разработанной на основе стандарта CORBA, в виде набора взаимодействующих объектных сервисов CORBA (CORBA Object Services).

Рассмотрим один из вариантов сочетания программы для анализа тестов с данной технологией относящейся к базовым объектным архитектурам для создания распределенных объектных программных систем.

Целью работы является — рассмотреть некоторые вопросы разработки программного обеспечения на основе объектных моделей, необходимого для предварительного анализа и исправления ошибок в сочетании с CORBA.

Основными задачами данной работы являются:

• рассмотреть основные понятия и функции технологии CORBA;
• перечислить и охарактеризовать принципы и общую схему технологии CORBA.

ГЛАВА 1. Основные понятия технологии CORBA

1.1. Основные функции и задачи технологии CORBA

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

CORBA - это стандарт создания распределенных систем, предложенный кон­сорциумом разработчиков программного обеспечения Object Management Group (OMG), который затрагивает все вопросы, имеющие отношение к этой пробле­ме^[1].

Слово CORBA, является, аббревиатурой от Common Object Request Broker Architecture (стандартная архитектура брокера объектных запросов), что, по словам самих разработчиков OMG, обозначает «открытую, не зависимую от поставщика ар­хитектуру и инфраструктуру, позволяющую использовать различные приложения для совместной работы в сетях. Используя стандартный протокол IIOP, CORBA - приложения, разработанные любым производителем программного обеспечения, ра­ботающие практически на любой аппаратной платформе, операционной системе или сети, могут взаимодействовать с другими CORBA-приложениями того же или дру­гого поставщика также на практически любой платформе, операционной системе или сети, созданными с использованием самых различных языков программирова­ния».

Стандарт CORBA исчерпывающе описывает взаимодействие между приложени­ями на основе объектных интерфейсов. Основой совместимости CORBA-приложений является ORB (Object Request Broker - брокер объектных запросов). Приложе­ние с помощью ORB может предоставлять во внешний мир объектный интерфейс, структура которого описана с помощью языка описания интерфейса IDL (Interface Definition Language), а также обращаться к другим приложениям, совместимым с CORBA, через предоставленный этими приложениями объектный интерфейс. Таким образом, приложение может служить как сервером (в традиционном смысле этого слова), и как клиентом, как одновременно, так и по отдельности^[2].

CORBA-приложение, обращающееся к другим CORBA-приложениям, обязано лишь знать описание интерфейса этих приложений.

На основе данного описания ин­терфейса, ORB первого приложения, строит необходимую инфраструктуру, позволя­ющую обращаться к объектам других приложений, как будто эти объекты являются объектами данного приложения. При этом, если ORB взаимодействующих приложе­ний стандартны и поддерживают общий протокол обмена, их взаимодействие не зависимо от языка программирования, на котором приложения написаны^[3].

Именно протокол обмена диктует, насколько далеко могут быть разнесены об­щающиеся между собой приложения, совместимые с CORBA. Приложения могут выполняться в одном адресном пространстве (в виде, например, подключаемых би­блиотек), либо на одном компьютере, в многозадачной среде, либо на разных ком­пьютерах, общаясь через сеть^[4].

Стандарт определяет протоколы GIOP (General Inter- ORB Protocol), который описывает пакетный способ общения и является основой других пакетных протоколов, IIOP (Internet Inter-ORB Protocol) -'пакетный про­токол, основывающийся на GIOP и предназначенный для использования в сетях на основе протокола TCP/IP, и другие протоколы. Кроме определения правил взаимо­действия приложений и структуры самого ORB, стандарт' CORBA описывает на­бор стандартных сервисов (Object Services), то есть приложений, предоставляющих стандартный интерфейс, с помощью которого совместимое с CORBA приложение может выполнять те или иные задачи. Стандарт CORBA не требует обязательного наличия всех стандартных сервисов в том или ином воплощении ORB, но однознач­но определяет структуру и способ использования сервиса, если таковой имеется в конкретной реализации ORB^[5].

Для написания приложения, совместимого с CORBA, используется одно из стан­дартных отображений CORBA на язык (mapping). Стандарт определяет отображе­ния CORBA на Java, C++, Smalltalk и другие языки. Различные реализации ORB включают в себя отображения на различные языки, различные наборы сервисов и протоколов. Собственные реализации ORB есть у таких известных производителей, как BorlandT, SybaseT, OracleT и других. Имеются также реализации ORB независи­мых производителей, как коммерческие, так и свободно распространяемые. В число последних входят MICO и ТАО, включающие в себя, среди прочего, отображение CORBA на C++. Ниже более подробно рассмотрены основные элементы стандарта CORBA. Всю документацию по стандарту CORBA можно бесплатно получить в электронном виде на сайте www.omg.org[6].

1.2. Архитектурные принципы реализации приложений

Функции CORBA — это функции промежуточного программного обеспечения объектной среды. Для того чтобы обеспечить взаимодействие объектов и их интеграцию в цельную систему, архитектура промежуточного уровня должна реализовать несколько базовых принципов^[7].

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

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

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

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

В обеих технологиях взаимодействие между клиентским процессом и сервером объекта, то есть процессом, который порождает и обслуживает экземпляры объекта, использует механизм объектный вариант вызова удаленной процедуры (RPC, remote procedure call).

Структура RPC — старейшей механизм из технологий промежуточного программного обеспечения. Механизм RPC реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура - клиент передает специальное сообщение с параметрами вызова по сети в удаленную серверную процедуру, а результаты ее выполнения возвращаются в другом сообщении клиентскому процессу^[9].

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

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

Тем самым достигается возможность взаимодействия клиента и сервера на различных платформах^[10].

ГЛАВА 2. Описание распределённой программной системы

2.1. CORBA – это машина удалённых запросов

В данном разделе представлено описание распределённой программной системы - машины удалённых запросов, реализованной с использованием технологии CORBA. Представленная программная система предназначена для реше­ния следующих задач:

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

Машина удалённых запросов функционально состоит из трёх взаимодействую­щих объектных сервисов CORBA:

• сервис внешнего представления (Externalization Service) - является стандарт­ным сервисом CORBA;
• транспортный сервис (Transport Service) - не является стандартным сервисом CORBA;
• сервис удаленных запросов (Remote Query Service) - не является стандартным сервисом CORBA^[11].

Все упомянутые сервисы предоставляют внешний интерфейс согласно стандарту CORBA и более подробно рассмотрены в соответствующих подразделах, где при­водятся IDL декларации их интерфейсов, описания их взаимодействия и наиболее интересные нюансы их реализации.

Текущие версии машины удалённых запросов используют свободно распростра­няемые реализации ORB независимых производителей - MICO или ТАО. В каче­стве языка программирования, для реализации сервисов использовался Visual C++ 6.0, обе упомянутые выше реализации CORBA поддерживают отображение на язык C++- Стоит заметить, что все приведённые ниже IDL декларации интерфейсов, схемы взаимодействия сервисов и алгоритмы не зависят от конкретной реализации CORBA и языка программирования.

Сервис внешнего представле­ния (Externalization Service) предназначен для построения образа объекта, взаимо­действующего со стандартными потоками ввода-вывода. Важность его связана глав­ным образом с тем, что потоки ввода-вывода используются в современном програм­мировании повсеместно.

’ Сервис внешнего представления является стандартным сервисом CORBA. Его реализация в машине удалённых запросов базируется на стандартизированных IDL декларациях его интерфейсов и принципах его функционирования, представленных на официальном сайте разработчиков www.omg.org. Ниже приведено краткое описа­ние интерфейсов сервиса внешнего представления.

По стандартной спецификации сервис внешнего представления предоставляет внешний интерфейс, позволяющий переводить объекты типа Streamable во внеш­нее представление и обратно. Для успешного выполнения этих операций, для об­рабатываемых объектов должны быть корректно реализованы методы интерфейса Streamable^[12].

Приложение, которое желает перевести объекты во внешнее представление (экс- тернализовать), должно выполнить следующие действия при инициализации:

Получить ссылку на объект типа Stream (объект данного типа может быть со­здан приложением методом createQ объекта StreamFactory, функциональность которого должна поддерживаться сервисом внешнего представления).

Вызвать метод externalize() объекта Stream, передав ему в качестве параметра ссылку на экстернализуемый объект типа Streamable. '

Приложение имеет возможность экстернализовать несколько объектов в один поток, для этого у объекта Stream существуют методы begin_context(), которые необходимо вызывать перед экстернализацией первого объекта и end.context(), вызываемый после экстернализации последнего объекта^[13].

Далее сам объект Stream отвечает за перевод переданных ему по ссылке объектов во внешнее представление. В частности, его функциональность должена включать в себя реализацию интерфейса StreamIO, предоставляющего базовые методы записи и чтения из потока. Именно ссылка на объект типа StreamIO передаётся в качестве ар­гумента в метод externalize_tojstream() каждого из экстернализуемых объектов типа Streamable, и они пользуются методами объекта SytreamIO для записи необходимой информации в поток.

Приложение, которое желает перевести объекты из внешнего представления (ин- тернализовать), должно выполнить следующие действия при инициализации:

Получить ссылку на объект типа Stream - поток, в котором сохранены объек­ты.

Вызвать метод internalize() объекта Stream, передав ему в качестве параметра ссылку на объект типа FactoryFinder - объект с интерфейсом CosLifeCycle::Fac- toryFinder (IDL декларация интерфейса включена в описание стандартного CORBA сервиса Object Lifecycle Service), содержит метод find-factories(), ис­пользуемый для поиска фабрики Streamable объекта по её описанию.

Фабрики Streamable объектов должны поддерживать интерфейс StreamableFactoгу и используются для создания неинициализированных объектов при их чтении из потока. Реализация объекта типа FactoryFinder должна включать в себя механизм поиска нужной фабрики Streamable объектов по некоторому уникальному идентифи­катору key. Значение идентификатора Streamable объекта запаковывается в поток при его экстернализации, извлекается из потока перед его интернализацией, по из­влечённому идентификатору ищется нужная фабрика, с помощью которой и созда­ётся неинициализированный Streamable объект (метод create.uninitialized() объекта типа StreamableFactory). В качестве идентификатора используется значение атри­бута key самого Streamable объекта, получаемое при его экстернализации^[14].

В текущей реализации машины удалённых запросов интерфейс сервиса внешнего представления расширен модулями CosStorage и ExternalizationStorage с интерфей­сами:

• CosStorage::Storage - представляет собой низкоуровневое хранилище байт, с базовыми операциями по работе с ним.
• CosStorage::StorageInput - итератор для доступа к данным, хранимым в объ­екте Storage.
• CosStorage: :StorageFactory - фабрика, используемая для создания объектов ти­па Storage.
• ExternalizationStorage::StorageStream - CosExternalization::Stream с хранением данных в виде CosStorage::Storage.
• ExternalizationStorage::StorageStreamFactory - фабрика, используемая для со­здания объектов типа StorageStream.

Транспортный сервис может быть исполь­зован для передачи объектов адресату или множеству адресатов через различные среды: через прямое соединение, через почтовую систему или даже посредством пе­реноса файлов между не связанными между собой системами.

Транспортный сервис предоставляет внешний интерфейс согласно стандарту CORBA и использует другие сервисы CORBA для выполнения внутренних функций: сервис внешнего представления (Externalization Service) используется для получения внешнего представления передаваемого объекта. Поэтому при запуске транспортно­го сервиса одним из его обязательных входных параметров является IOR объекта ти­па StreamFactory,созданного сервисом внешнего представления.

При инициализации транспортный сервис создаёт объект типа TransportService и вспомогательные объекты, в соответствии со спецификацией сервиса и реализую­щие его функциональность^[15].

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

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

Сервис удаленных запросов предоставляет внешний интерфейс согласно стан­дарту CORBA и использует другие сервисы CORBA для выполнения внутрен­них функций: транспортный сервис (Transport Service) используется для транс­портировки внешнего представления запроса, а сервис внешнего представления (Externalization Service) используется для получения внешнего представления за­проса и результата* с целью дальнейшей передачи через транспортный сервис.

Сервис удалённых запросов при запуске получает в качестве одного из входных параметров IOR объекта типа TransportService, созданного транспортным серви­сом. Далее, используя полученную ссылку,' создаёт и регистрирует в транспортном сервисе объект типа Consumer, тем самым приобретая возможность получать объ­екты через транспортный сервис, и объекты типа StreamableFactory, необходимые для выполнения операций перевода из внешнего во внутреннее представление пе­редаваемых и получаемых объектов. После чего создаёт объект типа RemoteQueryMachine и вспомогательные объекты, в соответствии со спецификаци­ей сервиса и реализующие его функциональность^[16].

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

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

Получить ссылку на объект типа RemoteQueryMachine (ссылка может быть получена через IOR объекта, который сохраняется в файле при запуске серви­са удалённых запросов либо через Сервис Именования Объектов, если сервис удалённых запросов был запущен с опцией регистрации в Сервисе Именова­ния).

Зарегистрировать объекты типа QueryListener, предназначенные для уда­ленного исполнения запросов, посредством метода RemoteQueryMachine::register_listener().

Зарегистрировать объекты типа StreamableFactory, необходимые для выпол­нения операций перевода из внешнего во внутреннее представление, в объекте типа TransportService, ссылка на который может быть получена при помощи метода RemoteQueryMachine::get_transport().

Эти действия требуются для приложения, которое будет получать запросы от сер­виса, выполнять эти запросы, а также получать результаты запросов^[17].

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

2.2. Общая схема системы

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

CORBA определяется с помощью формализованной спецификации, написанной на языке IDL. Появлению очередной версии предшествуют четко организованный процесс адаптации нового стандарта, который обычно завершается быстрее, чем аналогичные процедуры в ISO. В результате CORBA может похвастаться значительным числом реализаций. Первоначальный вариант спецификации появился в 1991 году, и уже в 1992-м был выпущен коммерческий продукт — брокер объектных запросов DEC ObjectBroker^[18].

Спецификация CORBA — это строго организованное описание, не обремененное деталями реализации, которые оставляются на долю разработчиков конкретных продуктов. Обилие реализаций от разных поставщиков с одной стороны стимулирует конкуренцию и, как следствие, совершенствование технологии, но с другой — порождает проблемы несовместимости разнородных продуктов. Так, спецификация CORBA включает определение Basic Object Adapter, который обеспечивает доступ к сервисам брокера объектных запросов со стороны сервера объекта. Эта часть спецификации оказалась слишком общей, так что разработчики получили слишком большую степень свободы в реализации собственных объектных адаптеров. В итоге, часто оказывалось невозможно перенести серверные компоненты архитектуры с одного ORB на другой. В новой спецификации переносимого объектного адаптера (Portable Object Adapter, POA) делается исправить этот недостаток.

Различные брокеры запросов взаимодействуют между собой по протоколу General Inter ORB Protocol (GIOP). В связи с активным переносом в среду Web критически важных корпоративных приложений наибольший интерес представляет реализация протокола GIOP на базе TCP/IP — протокол Internet Inter ORB Protocol (IIOP).

Ниже представлена схема взаимодействия сервисов машины удалённых запросов внутри одного сервера системы и между не­сколькими серверами, разнесёнными в сети (Рис.1).

Ядро CORBA, включающее Брокер Объектных Запросов и Объектные Адапте­ры, обеспечивает механизмы, позволяющие объектам взаимодействовать меж­ду собой, не заботясь о положении в распределенной среде и способе их реали­зации, обеспечивает механизмы управления циклом жизни CORBA-объектов и их реализаций^[19].

Рис. 1. Схема взаимодействия сервисов машины удалённых запросов

Реализация машины удалённых запросов на основе технологии -CORBA в виде набора взаимодействующих сервисов CORBA позволила достигнуть среди прочего:

• Платформенной и языковой независимости. Реализация описанных выше сер­висов на языке C++ легко переносима между операционными системами семей­ства Windows и Unix. Использование для описания интерфейсов сервисов языка IDL позволяет легко отображать их на большинство современных объектно - ориентированных языков программирования, переносимость клиентов и реализаций объектов между ORB различных про­изводителей.
• Возможности создания серверных объектов по запросам клиента с обеспечени­ем оптимального управления ресурсами серверов (оперативная память, сете­вые соединения), возможность построения динамических связей между объек­тами в системе и динамического сопоставления с ними произвольных свойств^[20].

Заключение

Итак, CORBA является ведущей технологией построения распределенных объектных сред. Она имеет базовые принципы и множество различий в деталях реализации. На основе технологии CORBA создан солидный багаж проектов, что наглядно демонстрирует многочисленные «истории успеха» на Web-узле консорциума OMG и домашней страничке CORBA.

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

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

CORBA обеспечивает реальную многоплатформенность. Реализации CORBA многочисленны и принадлежат множеству производителей (с их полным списком и описанием продуктов можно познакомиться в Web по адресу www.corba.org/vendors). Эти продукты поддерживают обширный диапазон аппаратных платформ, в том числе мэйнфреймы, миникомпьютеры и Unix-системы. Однако разнообразие реализаций имеет и свои недостатки, прежде всего потенциальную проблему несовместимости.

Ряд продуктов позволяет сосуществовать объектам СОМ/CORBA. Взаимодействие объектов CORBA с OLE/COM определяется в спецификации CORBA, начиная с версии 2.0. Поддержку смешанной среды СОМ/CORBA обеспечивают в своих системах, например, компании Iona, Visual Edge и NobleNet. Так, Iona получила лицензию от Microsoft на использование технологии СОМ в системе СОМet, которая позволяет организовать «мост» между объектами в разных архитектурах. Непосредственную интеграцию СОМ, CORBA, RPC и Java обеспечивает анонсированная в начале этого года последняя версия системы Nouveau компании NobleNet^[21].

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

1. Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2 4 изд. Пер. с англ. М.: Изд-во Бином, СПб.: Невский диалект, 2016.
2. Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения ин­терфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015.
3. Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов. [Электронный ресурс] URL: http://www.4stud.info/networking/lecture5.html (дата доступа 28.11.2017)
4. Механизм вызова удаленных процедур – RPC [Электронный ресурс] URL: http://delphiworld.narod.ru/base/rpc_protocol.html (дата доступа 28.11.2017)
5. Понятие клиент-серверных систем [Электронный ресурс] URL: http://bourabai.kz/dbt/client1.htm (дата доступа 28.11.2017)
6. Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.11.2017)
7. Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015.
8. Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, 30.11.2017, Taraz, Kazakhstan. - №5, 2016. -p.77-83. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20357857 (дата доступа 28.11.2017)
9. Шевцов А.Н., Смайлова У.М., Шырынханова Д.Ж. Некоторые алгоритмы предварительной обработки теста. Theoretical & Applied Science. «Results & Perspectives», ISPC, 30.09.2016, Florence, Italy. - №9, 2013. -p.51-58. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20362250 (дата доступа 28.11.2017)
10. Цимбал А. Технология CORBA для профессионалов. СПб.: Питер, 2015.
11. Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015.
12. Object Management Group. Object Services Architecture. Revision 8.0. December 2014.
13. Object Management Group. Common Facilities Architecture. Revision 2.0. September 2015.
14. Object Management Group. Common Facilities Architecture. Revision 3.0. November 2016.
15. Object Management Group. Common Facilities Roadmap. Revision 3.1. January 2015.
16. Object Management Group. Common Object Services Specification Volumel (COSS1). March 1994.
17. Object Management Group. Object Management Architecture Guide. OMG Document Number 92.11.1. September 1. 2015.
18. Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.1.2017)
19. СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html (дата доступа 28.04.2014)
20. PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm (дата доступа 28.11.2017)

1. Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения ин­терфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015. ↑

2. Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2 4 изд. Пер. с англ. М.: Изд-во Бином, СПб.: Невский диалект, 2016. ↑

3. Цимбал А. Технология CORBA для профессионалов. СПб.: Питер, 2015. ↑

4. Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.04.2014) ↑

5. Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015. ↑

6. Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015. ↑

7. Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.11.2017)

   Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑

8. PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm (дата доступа 28.11.2017) ↑

9. Шевцов А.Н., Смайлова У.М., Шырынханова Д.Ж. Некоторые алгоритмы предварительной обработки теста. Theoretical & Applied Science. «Results & Perspectives», ISPC, 30.09.2016, Florence, Italy. - №9, 2013. -p.51-58. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20362250 (дата доступа 28.11.2017) ↑

10. Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.04.2017) ↑

11. Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения ин­терфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015. ↑

12. Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов. [Электронный ресурс] URL: http://www.4stud.info/networking/lecture5.html (дата доступа 28.04.2016) ↑

13. Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, 30.05.2013, Taraz, Kazakhstan. - №5, 2016. -p.77-83. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20357857 (дата доступа 28.11.2017) ↑

14. Понятие клиент-серверных систем [Электронный ресурс] URL: http://bourabai.kz/dbt/client1.htm (дата доступа 28.11.2017) ↑

15. Object Management Group. Common Facilities Roadmap. Revision 3.1. January 2015. ↑

16. Object Management Group. Object Management Architecture Guide. OMG Document Number 92.11.1. September 1. 2015. ↑

17. Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.11.2017) ↑

18. СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html (дата доступа 28.11.2017) ↑

19. Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, 30.05.2013, Taraz, Kazakhstan. - №5, 2016. -p.77-83. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20357857 (дата доступа 28.04.2016) ↑

20. Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑

21. Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑