В настоящее время большой популярностью пользуется компонентный подход к разработке программного обеспечения. Этот подход характеризуется тем, что создаваемый программный продукт состоит из взаимодействующих компонентов. При этом различные компоненты могут независимо разрабатываться разными группами программистов, и при создании каждого компонента может применяться наиболее подходящий язык программирования . В качестве примера можно привести Microsoft Visual Studio . NET и Microsoft Office.
К сожалению, проблемы в организации взаимодействия компонентов зачастую перевешивают преимущества компонентного подхода. Действительно, языки программирования используют различные несовместимые между собой модели данных, соглашения о вызове подпрограмм, форматы исполняемых и объектных файлов и т.п. Поэтому взаимодействие компонентов, написанных на разных языках, требует от разработчика дополнительных усилий и, кроме того, может существенно снизить эффективность получаемого кода.
Отсутствие удовлетворительной технологии взаимодействия компонентов приводит к следующим негативным явлениям:
C++. Взаимодействие двух консольных приложений
- Для разработки программной системы используется только один язык программирования, даже если часть системы удобней было бы реализовать на другом языке.
- Программа выглядит как гигантский монолит, из которого трудно выделить отдельные части и, соответственно, невозможно заменить одну часть на другую.
- Появляются чрезмерно универсальные языки программирования, а существующие языки наделяются несвойственными им возможностями. Например, функциональные и логические языки оснащаются библиотеками для разработки графического пользовательского интерфейса.
В компонентной системе можно выделить три вида взаимодействия компонентов:
- взаимодействие внутри адресного пространства одного процесса;
- межпроцессное взаимодействие , при котором компоненты работают в разных процессах;
- взаимодействие в сети, когда компоненты запущены на разных компьютерах.
В этом разделе мы ограничимся рассмотрением первого случая, то есть изучим, как на платформе . NET реализовано взаимодействие компонентов, работающих в рамках одного процесса. Межпроцессное и сетевое взаимодействие используется, главным образом, в распределенных системах, изучение которых выходит за рамки нашего учебника.
Обзор компонентных технологий
Существует множество способов и технологий организации компонентного программирования . Давайте проведем беглый обзор достижений в этой области.
Библиотеки подпрограмм
Наиболее древний способ заключается в использовании библиотек подпрограмм. Такие библиотеки создаются одной группой разработчиков, а затем могут быть использованы другими программистами в других проектах. Исходный код библиотек может быть закрыт, то есть они могут распространяться в откомпилированном виде, защищая тем самым интересы разработчиков. Однако организация компонентного программирования на базе библиотек подпрограмм обладает следующими недостатками:
Что такое API?
- Двоичный код библиотеки жестко привязан к аппаратной платформе, так как содержит инструкции конкретного процессора. Это уменьшает переносимость программы, использующей библиотеку.
- Как правило, библиотека рассчитана на использование конкретного компоновщика и может поддерживать ограниченное количество языков программирования, компиляторы которых генерируют объектные файлы в нужном формате и используют нужные соглашения о вызове подпрограмм.
- Библиотеки подпрограмм плохо подходят для объектно-ориентированных языков, так как не содержат никакой информации о типах. Например, если вы разработаете библиотеку классов на C++, вам придется распространять вместе с ней заголовочные файлы, содержащие объявления классов.
Динамические библиотеки некоторым образом облегчают компонентное программирование . Они поддерживаются операционной системой, и поэтому разработчики компиляторов вынуждены следовать требованиям, налагаемым операционной системой. То есть динамические библиотеки не зависят от причуд компиляторов и компоновщиков и могут использоваться для большего диапазона языков программирования. Однако в остальном они не лучше, чем обычные библиотеки подпрограмм.
Открытые исходные тексты
Еще один интересный путь создания компонентных программ придумали в мире открытых исходников, в котором компоненты распространяются в виде исходных текстов. Тем самым вроде бы решается часть проблем. По крайней мере, можно попытаться переносить эти компоненты с платформы на платформу (перекомпилируя исходники и исправляя возникающие ошибки). Кроме того, исходные тексты в отличие от двоичных файлов содержат информацию о типах, что позволяет использовать объектно-ориентированные возможности. Но и здесь нас подстерегают неприятности:
- Если компоненты написаны на разных языках, то соединить их вместе не так-то просто. Отсюда проистекает тяга фанатов открытых исходников к превращению своих программ в набор маленьких утилит, написанных на C и соединенных посредством корявых и трудночитаемых скриптов.
- Открытые компоненты почти всегда имеют так называемые «заразные» лицензии (например, GNU Public License — GPL). Такие лицензии требуют, чтобы программы, использующие эти компоненты, сами распространялись в виде открытых исходников. Этот печальный факт существенно ограничивает применимость открытых компонентов.
Технологии COM и CORBA
Особого внимания заслуживают технологии COM (Component Object Model) и CORBA (Common Object Request Broker Architecture). Технология COM, разработанная корпорацией Microsoft, поддерживает все три вида взаимодействия компонентов, а именно: взаимодействие внутри адресного пространства процесса , межпроцессное взаимодействие и взаимодействие по сети. Технология CORBA ориентирована исключительно на взаимодействие компонентов по сети.
Первое, с чем сталкивается программист при использовании COM или CORBA, это необходимость описывать метаданные на языке IDL ( Interface Definition Language). В COM и CORBA используются несколько разные варианты языка IDL, но для нас сейчас это несущественно. Подобное неудобство объясняется тем, что эти технологии не подразумевают специальной поддержки в компиляторах языков программирования. Например, мы можем написать COM-объект на языке C++, но ничего не знающий о COM компилятор C++, естественно, не сгенерирует никаких метаданных! Вот поэтому метаданные нужно отдельно описывать на языке IDL.
Технологии COM и CORBA определяют двоичный стандарт для передачи данных между компонентами. Так как компоненты могут быть написаны на разных языках и, соответственно, внутреннее представление данных в них может существенно различаться, то компонент, осуществляющий передачу, вынужден выполнять преобразование передаваемых данных в стандартное представление (маршалинг), а компоненту, принимающему данные, приходится выполнять преобразование данных из стандартного представления к своему внутреннему представлению (демаршалинг). При межпроцессном взаимодействии и взаимодействии по сети затраты на преобразование данных не играют существенной роли, но при взаимодействии внутри адресного пространства одного процесса они могут сильно сказаться на производительности программы.
На рис. 2.11 изображена схема взаимодействия двух объектов при использовании технологии COM или CORBA. Объекты Client и Server находятся в разных компонентах, поэтому объект Client не может непосредственно передать сообщение объекту Server . Вместо этого он обращается к специальному объекту-заглушке ClientStub , который осуществляет упаковку сообщения и затем передает его информационной магистрали
Рис. 2.11. Взаимодействия двух объектов через COM или CORBA
(в терминах CORBA информационная магистраль называется ORB — Object Request Broker ). Информационная магистраль передает сообщение серверному объекту -заглушке ServerStub , который распаковывает сообщение и вызывает соответствующий метод объекта Server . Результат, возвращаемый методом объекта Server , совершает обратный путь к объекту Client аналогичным образом. Данный пример показывает, что использование технологий COM и CORBA связано с большими трудностями. Ситуация, пожалуй, облегчается лишь тем, что объекты-заглушки могут быть сгенерированы автоматически на основе описания объекта Server на языке IDL (для этого существуют специальные компиляторы).
Хотя технологии COM и CORBA продолжают активно применяться, есть все основания утверждать, что в самом ближайшем будущем они будут вытеснены более эффективными и удобными технологиями (например, .NET).
Источник: intuit.ru
Как говорят две программы друг с другом?
Операционной системе возможен =разговор= между двумя програмами?
комментировать
в избранное
Lidoc hka17 [56.5K]
10 лет назад
Технология IPC позволяет процессам передавать друг другу сообщения, то есть «разговаривать» между собой. Все такие переговоры определяются определенными правилами, которые образуют протоколы.
Операционная система Linux/Debian GNU используется для разговора между двумя программами, которые называются interprocess communication (сокращенно-IPC), процессы взаимодействуют с друг другом, так как все программы называются процессами, так же как и люди хотят общаться с друг другом. Вот как-то так.
Источник: www.bolshoyvopros.ru
Взаимодействие программ в информационных системах
Сказанное выше относилось к технологиям разработки отдельных программ. Но в настоящее время программы, как правило, должны являться частью некоторой информационной системы (ИС),т.е. функционировать не сами по себе, а во взаимодействие с большим количеством других программ.
Также программы должны уметь «использовать» другие программы и системы, разработанные сторонними организациями. Например, ваша программа может подготовить некоторый отчетный документ в формате Microsoft Word, и этот документ будет доступен на всех компьютерах, на которых установлен Word (но на которых может не быть вашей программы).
Аналогично, можно из прикладной программы создать итоговые чертежи в формате распространенных графических систем (например, в формате AutoCAD или Corel Draw). В этом случае один из основных вопросов — организация взаимного общения программ друг с другом и с источником данных. В качестве последнего в ИС выступают базы данных (БД), вместе с системой управления базами данных (СУБД).
Программы, работающие в составе ИС, получают информацию из БД, к которым имеют доступ и другие программы. В этом случае естественным образом создается возможность взаимосвязи приложений через данные. Например, одна программа записывает результаты своей работы, а другая использует их как начальные данные для своей работы. Этот простейший уровень взаимосвязи требует одного — унификацию данных и форматов их хранения. Для целей унифицированного доступа к данным используются специальные языки, например SQL (Structured Query Language — язык структурированных запросов).
Но во многих случаях этого простейшего механизма общения недостаточно для современной ИС — например, программа не должна ожидать, когда кем-то будет запущена другая программа — поставщик данных. Необходимо иметь возможность запускать из одной программы другую, передавая при этом ей управляющую информацию. Запуск основного приложения порождает в среде операционной системы процесс, для которого операционная система выделяет необходимые ресурсы компьютера (память и время процессора). Дочерняя программа может выполняться как в адресном пространстве вызвавшей ее программы, так и в собственном адресном пространстве и в другом потоке.
Однако часто требуется обмен информацией между программами, выполняющимися одновременно (параллельно). Желательно, чтобы этот обмен не зависел от языка программирования, на котором написаны разные программы, а в сетевых системах не зависел и от операционных систем, установленных на разных компьютерах. Яркий пример подобной организации взаимосвязи — Интернет, в глобальную сеть соединены компьютеры с различными операционными системами (Windows, Unix, Solaris, сотовые телефоны и др.).
Простейшими средствами параллельного общения вначале были файлы совместного доступа, или разделяемые файлы (файлы, к которым могут иметь одновременный доступ несколько программ), которые появились еще на заре Windows. Также ранним средством является буфер обмена ClipBoard, доступный практически всем приложениям Windows, в котором можно временно хранить для передачи другим программам информацию различного формата — текстовую, графическую и т.п. Несколько позже для межпрограммного взаимодействия использовалась технология DDE — динамический обмен данными. Сегодня актуальность DDE ниже из-за появления новых технологий, а использование БД, буфера обмена и разделяемых файлов как простейшего варианта межпрограммного взаимодействия остается актуальным.
Позднее появилась технология связывания и внедрения объектов OLE1 (Object Linking and Embedding). Благодаря OLE1 появилась возможность создавать составные документы (например, в документ Word вставлять таблицу Exel, при ее редактировании из Word используются возможности Exel). На смену ей пришла технология OLE2, позволяющая различным программам предоставлять друг другу свои функции (сервис). Программа, предоставляющая свои функции, называется сервером, а программа, их использующая — клиентом. В этой технологии одна программа может не просто вызвать другую, но использовать ее отдельные функции.
Следующим шагом на пути совершенствования межпрограммного обмена явилась технология компонентной модели объектов (СОМ — Component Object Model). Эта технология заключается в стандартизированном описании служб программы, к которым она дает доступ другим программам. В технологии СОМ неважно, на каких языках написаны программы и где они выполняются: в одном потоке, в разных потоках, на разных компьютерах. Расширение этих возможностей дает технология DCOM — распределенная модификация СОМ. Отметим, что СОМ подразумевает взаимосвязь на уровне специальных объектов, структура которых во многом схожа с рассмотренными ранее объектами внутри одной программы.
Необходимо сказать о еще одной стремительно развивающейся технологии — Интернет. В Интернете располагаются и базы данных, и серверы, с которыми общаются приложения пользователя.
Дата добавления: 2016-07-18 ; просмотров: 2391 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ
Источник: poznayka.org