Технология построения распределенных информационных систем (Основные понятия технологии CORBA)
Содержание:
Введение
Актуальность данной работы заключается в том, что разработанные программы – зачастую состоят из отдельных компонентов — самостоятельные блоки программного кода, которые реализуют определенную логику, распределены по сети и могут быть использованы многократно. Они используются в качестве строительных блоков для создания сложных распределенных приложений.
В данной работе рассматривается одна из ведущих технологий создания распределённых систем - 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].
Список литературы
- Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2 4 изд. Пер. с англ. М.: Изд-во Бином, СПб.: Невский диалект, 2016.
- Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015.
- Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов. [Электронный ресурс] URL: http://www.4stud.info/networking/lecture5.html (дата доступа 28.11.2017)
- Механизм вызова удаленных процедур – RPC [Электронный ресурс] URL: http://delphiworld.narod.ru/base/rpc_protocol.html (дата доступа 28.11.2017)
- Понятие клиент-серверных систем [Электронный ресурс] URL: http://bourabai.kz/dbt/client1.htm (дата доступа 28.11.2017)
- Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.11.2017)
- Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015.
- Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. 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)
- Шевцов А.Н., Смайлова У.М., Шырынханова Д.Ж. Некоторые алгоритмы предварительной обработки теста. 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)
- Цимбал А. Технология CORBA для профессионалов. СПб.: Питер, 2015.
- Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015.
- Object Management Group. Object Services Architecture. Revision 8.0. December 2014.
- Object Management Group. Common Facilities Architecture. Revision 2.0. September 2015.
- Object Management Group. Common Facilities Architecture. Revision 3.0. November 2016.
- Object Management Group. Common Facilities Roadmap. Revision 3.1. January 2015.
- Object Management Group. Common Object Services Specification Volumel (COSS1). March 1994.
- Object Management Group. Object Management Architecture Guide. OMG Document Number 92.11.1. September 1. 2015.
- Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.1.2017)
- СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html (дата доступа 28.04.2014)
- PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm (дата доступа 28.11.2017)
-
Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015. ↑
-
Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2 4 изд. Пер. с англ. М.: Изд-во Бином, СПб.: Невский диалект, 2016. ↑
-
Цимбал А. Технология CORBA для профессионалов. СПб.: Питер, 2015. ↑
-
Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.04.2014) ↑
-
Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015. ↑
-
Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015. ↑
-
Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.11.2017)
Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑
-
PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm (дата доступа 28.11.2017) ↑
-
Шевцов А.Н., Смайлова У.М., Шырынханова Д.Ж. Некоторые алгоритмы предварительной обработки теста. 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) ↑
-
Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.04.2017) ↑
-
Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015. ↑
-
Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов. [Электронный ресурс] URL: http://www.4stud.info/networking/lecture5.html (дата доступа 28.04.2016) ↑
-
Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. 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) ↑
-
Понятие клиент-серверных систем [Электронный ресурс] URL: http://bourabai.kz/dbt/client1.htm (дата доступа 28.11.2017) ↑
-
Object Management Group. Common Facilities Roadmap. Revision 3.1. January 2015. ↑
-
Object Management Group. Object Management Architecture Guide. OMG Document Number 92.11.1. September 1. 2015. ↑
-
Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.11.2017) ↑
-
СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html (дата доступа 28.11.2017) ↑
-
Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. 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) ↑
-
Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑
-
Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑
- История возникновения и развития языка программирования Си (С++) и Java (Сравнительная характеристика)
- Разработка годового финансового плана предприятия (на примере ООО «Омега»)
- Определение, основные задачи, функции бухгалтерского учета.
- Цели и задачи налогового учета .
- Организационная культура и ее роль в современных организациях
- Бренд как конкурентное преимущество компании (Анализ использования бренда в качестве конкурентного преимущества)
- Разработка регламента выполнения процесса «Расчет заработной платы» (Анализ специфики процессов по расчету заработной платы предприятия по оказанию услуг)
- Организационная кудьтура организации, процесс формирования и качественные характеристики последствий внедрения
- Теоретические основы разработки маркетинговой стратегии на предприятии
- Интернет-маркетинговые решения для автосалона "Ралли-Сервис"
- Шрифты. Классификация шрифтов (История появления, развития и классификация шрифта)
- Практические основы принятия управленческих решений на примере деятельности компании МУП КП «Школьник»