Описание способов которыми компьютерная программа взаимодействует с другой программой
Для начала следует понять, что подразумевается под внешними программами и с чем именно им придётся взаимодействовать.
Для этого дадим несколько определений:
Компьютерная программа — последовательность инструкций, определяющих процедуру решения конкретной задачи компьютером.
Внешняя программа – это программа, которая находится вне другой программы или даже вне операционной системы.
Написанием программ занимается программист, а если речь идёт о программировании, то взаимодействие с внешними программами можно трактовать, как взаимодействие создаваемой программы с внешними программами (сторонними программами).
Существует достаточно большое количество способов организации взаимодействия между программами. Однако многие из них требуют детального понимания работы операционной системы, поэтому перечислим всего несколько основных способов посредством различных технологий.
Стандарт и технология COM
COM (англ. Component Object Model – объектная модель компонентов) – это технологический стандарт от компании Microsoft для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Microsoft Windows. На основе COM были реализованы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, DirectX, а также XPCOM.
Стандарт COM был разработан в 1993 году корпорацией Microsoft как основа для развития технологии OLE.
Технология COM описывает методологию реализации компонентов программного обеспечения: объектов, которые могут повторно использоваться, могут быть неоднократно подключены к разным приложениям.
Объект COM – конкретный экземпляр COM-класса, завершенный объект с собственными членами данных и методами, который может легко встраиваться в программы или распространяться как отдельный программный продукт. COM-объект представляет собой или DLL-библиотеку или ЕХЕ-программу для Wіndows, которые можно создавать в любой среде программирования, способной поддерживать нужный формат представления. COM-объект может иметь много функций, доступ к которым происходит через его интерфейсы. Любой COM-объект должен иметь по крайней мере одни интерфейс ІUnknown, хотя на самом деле имеет их значительно больше.
Предположим, что пользователю в каком-нибудь отчете нужно поместить электронную таблицу с расчетами, которые ссылаются на определенные параметры в тексте. Чтобы выполнить любые вычисления без использования технологии СОМ, пришлось бы постоянно переключаться между двумя программами (Word и Excel), а информацию копировать (вырезать и вставлять). При помощи технологии COM можно применять функции электронной таблицы прямо в текстовом редакторе и автоматически форматировать полученный результат. Возможность реализовать операции такого рода называется автоматизацией.
Цель автоматизации состоит в том, чтобы дать возможность программе предоставлять в использование сервисы, которые в ней присутствуют. Основной особенностью автоматизации является возможность комбинировать функции различных специализированных приложений в одном модуле. СОМ дает возможность программам передавать свою информацию в другие приложения и модули.
Некоторые широко-известные технологии, основанные на стандарте COM
Технология DCOM
Выпущенная в 1996 году технология DCOM (англ. Distributed COM – распределённая COM) является расширением для COM для поддержания связи между объектами на различных компьютерах по сети. Технология DCOM обеспечивает базовые установки безопасности, позволяя задавать, кто и из каких машин может создавать экземпляры объекта и вызывать его методы.
Технология OLE
OLE (англ. Object Linking and Embedding) – технология связывания и внедрения объектов в другие документы и объекты, разработанная корпорацией Майкрософт. В 1996 году Microsoft переименовала технологию в ActiveX.
OLE позволяет передавать часть работы от одной программы редактирования к другой и возвращать результаты назад.
Основное преимущество использования OLE в том, что она позволяет создать главный файл, картотеку функций, к которой обращается программа. Этот файл может оперировать данными из исходной программы, которые после обработки возвращаются в исходный документ.
OLE используется при обработке составных документов, может быть использована при передаче данных между различными несвязанными между собой системами посредством интерфейса переноса, а также при выполнении операций с буфером обмена. Идея внедрения широко используется при работе с мультимедийным содержанием на веб-страницах, где используется передача изображения, звука, видео, анимации в страницах HTML либо в других файлах, также использующих текстовую разметку. Однако технология OLE использует архитектуру «толстого клиента», то есть сетевой ПК с избыточными вычислительными ресурсами: тип файла либо программа, которую пытаются внедрить, должна присутствовать на машине клиента.
OLE-сервера взаимодействуют с системными библиотеками при помощи таблиц виртуальных функций. Эти таблицы содержат указатели на функции, которые системная библиотека может использовать для взаимодействия с сервером или клиентом.
OLE версии 1.1 позднее развился в архитектуру COM для работы с компонентами программного обеспечения. Позднее архитектура COM была преобразована и стала называться DCOM.
Когда объект OLE помещен в буфер обмена информацией, он сохраняется в оригинальных форматах Windows (bitmap или metafile), а также сохраняется в своём собственном формате. Собственный формат позволяет поддерживающей OLE-программе внедрить порцию другого документа, скопированного в буфер, и сохранить её в документе пользователя.
В 1996 году Microsoft переименовала технологию OLE версии 2.0 в ActiveX. Эта версия OLE в основном используется веб-дизайнерами для вставки в страницы мультимедийных данных.
Технология ActiveX
ActiveX – программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта для определения компонентов, пригодных к использованию из программ, написанных на разных языках программирования.
Множество приложений для Microsoft Windows, включая приложения самой компании Microsoft, такие, как Internet Explorer, Microsoft Office, Microsoft Visual Studio,Windows Media Player, используют управляющие элементы ActiveX, чтобы реализовать набор функциональных возможностей и в дополнение инкапсулировать их собственный функционал в управляющие элементы ActiveX, чтобы предоставить возможность встраивать их в другие приложения.
Технология ActiveX — средство, при помощи которого Internet Explorer (IE) использует другие приложения внутри себя. С помощью ActiveX IE загружает Windows Media Player, Quicktime и другие приложения, которые могут воспроизводить файлы, внедрённые в веб-страницы.
ActiveX официально обрабатываются только Microsoft Internet Explorer и операционной системой Microsoft Windows.
Вредоносное ПО, такое, как компьютерные вирусы и шпионящее ПО, можно случайно установить с вебсайтов злоумышленников, используя технологию управляющих элементов ActiveX.
Заключение
Производственная практика является одним из основных условий закрепления полученных в колледже теоретических знаний, приобретения практических навыков по их применению, а также выявления пробелов в знаниях теории. Практика дает возможность получить практическую подготовку, оценить свои возможности.
На протяжении всего периода производственной практики я ознакомилась с деятельностью, нормативно-правовыми документами, организационной структурой предприятия ИП Гайчук Ольга Игоревна «Тульский Макетный Двор», а также получила практический опыт в создании разного рода программного обеспечения и в составлении документации к программному обеспечению. Небольшой коллектив специалистов организации ИП Гайчук Ольга Игоревна «Тульский Макетный Двор» отличается отзывчивостью и дружелюбностью. Работа на предприятии не останавливается ни на минуту. То и дело поступают новые заказы на изготовление макетов разного вида. Многие заказчики остаются довольными и обращаются неоднократно. Особенно деятельность макетной мастерской привлекает рекламные агентства с целью маркетинга нового объекта техники или архитектурного объекта.
Анализируя деятельность организации ИП Гайчук Ольга Игоревна «Тульский Макетный Двор», я пришла к выводу, что в целом работа организации проходит положительно, но были выявлены такие недостатки:
· Высокий уровень шума, что может плохо сказаться на здоровье работников, в связи с расположением фрезерных станков в одном помещении с рабочими местами разработчиков чертежей, покрасочного цеха, цеха сборки макета, а также к местам работы директора макетного производства и директора фрезерного производства и наружной рекламы;
· Запыленность помещения также плохо влияет на здоровье человека;
· При наличии добросовестных работников есть всего лишь небольшое количество настоящих специалистов своего дела.
Предлагаю провести следующие мероприятия по устранению выявленных недостатков:
1. Взять в аренду второе помещение для фрезерных станков или соорудить перегородку из шумоизоляционных материалов.
2. Взять на работу уборщицу или организовать график дежурств работников организации по уборке помещения.
3. Назначать квалификационных работников на обучение начинающих специалистов, рекламировать курсы повышения квалификации, поощрять стремление работников к повышению квалификации.
Первым и важнейшим этапом создания макета является разработка чертежей. Сейчас доступно большое количество программ для работы с графикой. Но, как известно, в любой программе есть свои недочёты, поэтому разработчикам чертежей для разных макетов приходится пользоваться разным программным обеспечением. Программ для обработки графики появляется всё больше и больше. Это можно назвать «вечной гонкой» среди программистов c желанием создать лучший программный продукт, который будет максимально удовлетворять потребности пользователей. Исходя из этого, можно сделать вывод, что для современного мира важны специалисты программисты, тем более, если учитывать большую скорость развития информационных технологий.
API – описание способов, которыми одна компьютерная программа/cайт/скрипт может взаимодействовать с другой программой/сайтом/скриптом. Иными словами, мы предоставляем вам свои данные о вилках и инструкции по их настройке и использованию. Вы же, в свою очередь, можете использовать эти данные, например, при написании скрипта/программы для автоматизации процесса ставок.
Как выполнить настройку и получить REST API данные
1. Для того, чтобы воспользоваться API – вам необходимо подать заявку со списком необходимых вам букмекеров (до 10 БК) и типом вилок/valuebets (прематч, лайв) на странице с тарифами.
После подачи заявки вы получите расчет стоимости доступа к API с учетом выбранных вами параметров и сможете оплатить эту заявку в Личном Кабинете, когда она будет одобрена. Там же, в личном кабинете, всегда можно посмотреть и статус ваших заявок.
[!] Запомните ID своего фильтра, он понадобится вам в дальнейшей работе с нашим API.
3. Следующий этап – проверка правильности выдаваемых данных. Для этого перейдите на выдачу с API («API Прематч», «API Лайв»), выберите тип API (вилки/valuebets) и примените ранее созданный фильтр. Такая визуализация данных позволит вам наглядно убедиться в том, что вы все настроили правильно.
4. Далее вам нужно перейти на вкладку API в Личном кабинете и скопировать там свой уникальный токен. Токен – буквенно-цифровой ключ, который используется для доступа к API данным конкретно взятым пользователем.
5. Вышеупомянутый токен, а также ID ранее созданного фильтра необходимо вставить в Swagger документацию (arb-controller - для вилок, valuebet-controller - для valuebets). Как результат – вы получите ссылку на данные под указанные вами параметры.
Для этого в Swagger документации нажмите «POST» => «Try it out», далее в появившемся списке заполните все необходимые поля и нажмите «Execute».
access_token: Ваш уникальный токен.
search_filter: ID созданного вами фильтра.
На этом все, результат получен! Он полностью аналогичен отображаемому результату на страницах выдачи «API Прематч» или «API Лайв».
Далее, если вы хотите использовать получаемые данные для автоматизации процесса проставления вилок – вам необходимо реализовать на своей стороне соответствующий скрипт/программу и подключить его к нашему API при помощи сгенерированного Curl.
API - описание способов, в которых одна компьютерная программа может взаимодействовать с другой программой. обычно включены в описание любой из Интернет-протокол, программа рамки. часто реализуется отдельная библиотека или сервис операционной системы. используется программистами для написания приложений.
1. API в качестве средства интеграции приложений. (API as a means of integrating applications)
API определяет функциональные возможности, предоставляемые модулем программы, библиотека, с API позволяет абстрагироваться от того, как именно эта функциональность реализована.
Если программный модуль, библиотека рассматривается как "черный ящик", API набор "ручек", которые будут доступны пользователю из коробки и он может повернуть и вытащить.
Программные компоненты взаимодействуют друг с другом через API. в этом случае компоненты обычно образуют иерархию - более высокого уровня, использовать компоненты API низкоуровневые компоненты, а те, в свою очередь, использовать API даже компонентов более низкого уровня.
На этом принципе построены протоколов передачи данных в Интернете. стандартный стек протоколов сетевой модели OSI содержит 7 уровнях, от физического уровня передачи бит до уровня протоколов приложений, таких протоколов HTTP и IMAP (ИМАП). каждый уровень предыдущей функции "нижележащего" передачи данных и, в свою очередь, предоставляет необходимую функциональность следующим образом "вышележащему" уровня.
Важно отметить, что понятие протокола близко по смыслу к понятию API. Как является абстракцией функциональности, только в первом случае мы говорим о данных, а второй по взаимодействию приложений.
API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.
1.1. API в качестве средства интеграции приложений. Сигнатура функции. (The signature of the function)
Сигнатура функции часть объявления функции, позволяя вещательных СМИ, чтобы определить функцию в частности. Разные языки программирования имеют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функций в этих языках.
Иногда различают вызова подпись, а также подпись функции реализации. призыв подписи обычно пишут в синтаксис вызова функции с учетом сигнатуры области функции, имя функции, фактическая последовательность типы аргументов в вызове и тип результата. В подписи реализация, как правило, включает в себя некоторые элементы синтаксис объявления функции: описатель-функции-объем и последовательность формальных аргументов.
Например, в языке программирования С, простая функция однозначно определяется компилятором по ее имени и последовательности типов ее аргументов, что составляет сигнатуру функции в этом языке. если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.
В языке программирования Java (Ява) сигнатуру метода составляет его имя и последовательность типов параметров, тип возвращаемого значения в сигнатуре не участвует.
1.2. API в качестве средства интеграции приложений. Семантика функции. (The semantics of the function)
Семантика функции-это описание того, что делает эта функция. семантика функции включает в себя описание того, что является результатом вычисления функции, как и от чего этот результат зависит. как правило, результат выполнения зависит только от значений аргументов функции, но в некоторых модулях есть понятие состояния. затем результат функции может зависеть от этого состояния, и, кроме того, результатом может быть изменение в состоянии. логика этих зависимостей и применяет изменения к семантике функции. полное описание семантики функции исполняемый код функции или определение математической функции.
2. Эксплуатации API системы. вопросы, связанные с разнообразием API. (Operating system API. the issues associated with variety of API)
Почти все операционные системы API, с помощью которого программисты могут создавать приложения для этой операционной системы. API операционные системы - это набор системных вызовов.
В индустрии программного обеспечения общие стандартные API для стандартные функциональные возможности играют важную роль, поскольку они гарантируют, что все программы, использующие общий API, будут работать одинаково хорошо или, по крайней мере типичном в обычном порядке. В случае API графических интерфейсов это означает, что программы будут иметь схожий пользовательский интерфейс, что облегчает процесс освоения новых программных продуктов.
С другой стороны, различия в API различных операционных систем делают его очень трудным для переноса приложений между платформами. существуют различные методы, чтобы обойти эту трудность - писать "промежуточных" API графические интерфейсы пользователя wxWidgets, GTK (ГТК) и т. п., написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой операционной системы, внедрение стандартов кодирования на языках программирования, например, стандартная библиотека языка C, писать на интерпретируемых языках, реализованных на различных платформах.
Следует также отметить, что программист часто имеет несколько различных API, позволяющие достичь того же результата. каждый API обычно реализуется с помощью API программный компонент на более низком уровне абстракции.
Например: для того, чтобы увидеть в строке браузера "Привет, мир!", просто создайте HTML-документ с минимальным заголовок и простые тела, что содержит заданную строку. когда браузер откроет этот документ, браузер передаст имя файла или уже открытый дескриптор файла библиотеки, который обрабатывает HTML-документов, что, в свою очередь, API операционная система будет читать этот файл и понимать его структуру, а затем последовательно вызвать через API библиотеки стандартных графических примитивов операции "очистить окошко", "написать "всем привет!" выбранный шрифт". во время этих операций, библиотеку графических примитивов вернется к библиотеке оконного интерфейса с соответствующими запросами, эта библиотека будет обратиться к API операционной системы для записи данных в буфер.
Тем не менее, почти на каждом из уровней на самом деле есть несколько возможных альтернативных API. например: мы могли бы написать исходный документ не на HTML, на LaTeX (Латекс), дисплей можно использовать любой браузер. Кроме того, разные браузеры используют различные HTML-библиотеки, и, кроме того, он может быть составлен с использованием различных библиотек примитивов, на разных операционных системах.
Основные трудности, существующие многоуровневые системы API, таким образом, являются:
- Потеря функциональности при переходе от низшей к высшей. грубо говоря, каждый "слой" API является содействие реализации стандартного набора операций. но это действительно сложно или это принципиально невозможно выполнить некоторые другие операции, которые предложили нижний уровень API.
- Сложность портирования программного кода с одной системы API в другом примере, при смене ОС.
3. Наиболее известные API. (The most famous API)
Операционных систем Графических интерфейсов Звуковых интерфейсов Аутентификационных системWeb API. (Веб-API)
Web API (Веб-API) является практически синонимом для веб-службы, хотя в последние годы из-за тенденции Web 2.0 (Веб 2.0) переход от SOAP (Мыло) в REST тип веб-интерфейсы связи, которые объединяют несколько услуг в новые приложения, известные как гибридные.
В данной лекции рассматриваются базовые понятия программной инженерии - интерфейсы, средства их представления, взаимодействие разноязыковых программ и преобразование типов данных . Представлены подходы к обеспечению интерфейсов программ, записанных в разных языках программирования (ЯП), методы преобразования неэквивалентных типов данных при взаимодействии модулей и программ.
Определены общие задачи неоднородности ЯП, платформ и сред, влияющих на установление связей между разноязыковыми программами, сформулированы пути их решения. Рассмотрены рекомендации стандарта ISO/IEC 11404-1996 по обеспечению независимых от современных ЯП типов данных.
Рассмотрены подходы к преобразованию форматов данных и данных в БД , а также методы изменения (эволюции) программ.
8.1. Задачи интерфейса при разработке программ
Общее определение. Интерфейс - это связь двух отдельных сущностей. Виды интерфейсов: языковые, программные, аппаратные, пользовательские, цифровые и т. п. Программный ( API ) и/или аппаратный интерфейс (port) - это способы преобразования входных/выходных данных во время объединения компьютера с периферийным оборудованием. В ЯП - это программа или часть программы, в которой определяются константы , переменные, параметры и структуры данных для передачи другим.
В программировании термин интерфейс олицетворяет собой набор операций, обеспечивающих определение видов услуг и способов их получения от программного объекта, предоставляющего эти услуги. На начальном этапе программирования в роли интерфейса выступают операторы обращения к ее процедурам и функциям программ через формальные параметры. Программы, процедуры и функции записывались в одном ЯП. Операторы обращения включали имена вызываемых объектов (процедур и функций) и список фактических параметров, задающих значения формальным параметрам и получаемым результатам. Последовательность и число формальных параметров соответствовало фактическим параметрам. Выполнение функции в среде программы на одном ЯП не вызывало проблем, так как типы данных параметров совпадали.
В случае, когда один из элементов ( программа , процедура или функция ) записаны на разных ЯП и, кроме того, если они располагаются на разных компьютерах, то возникают проблемы неоднородности типов данных в этих ЯП, структур памяти платформ компьютеров и операционных сред, где они выполняются. Понятие интерфейса, как самостоятельного объекта, сформировалось в связи со сборкой или объединением разноязыковых программ и модулей в монолитную систему на больших ЭВМ ( mainframes ) [8.1, 8.2].
Рис. 8.1. Схема вызова модулей А и В из С через интерфейсы А'и B'
Интерфейс играл роль посредника между вызываемым и вызывающим модулями. В нем давалось описание формальных и фактических параметров, производилась проверка соответствия передаваемых параметров (количества и порядка расположения), а также их типов данных. Если типы данных параметров оказывались не релевантными (например, передается целое, а результат функции - вещественное или наоборот), то производилось прямое и обратное их преобразование с учетом структуры памяти компьютеров. На рис. 8.1 приведена схема программы , в которой содержатся два вызова - и с параметрами, которые через интерфейсные модули-посредники и производят преобразование данных и их передачу модулям и . После выполнения и результаты преобразуются обратно к виду программы .
8.1.1. Интерфейс в ООП и в современных средах
Интерфейс в ООП.В ООП главным элементом является класс, включающий множество объектов с одинаковыми свойствами, операциями и отношениями. Класс имеет внутреннее (реализацию) и внешнее представление - интерфейс (табл. 8.1).
- публичные, доступные всем клиентам:
- защищенные, доступные классу п подклассу:
- приватные, доступные классу.
Интерфейс содержит множество операций, описывающих его поведение. Класс может поддерживать несколько интерфейсов, каждый из которых содержит операции и сигналы, используются для задания услуг класса или программного компонента. Интерфейс именует множество операций или определяет их сигнатуру и результирующие действия. Если интерфейс реализуется с помощью класса, то он наследует все его операции. Одни и те же операции могут появляться в различных интерфейсах. Если их сигнатуры совпадают, то они задают одну и ту же операцию, соответствующую поведению системы. Класс может реализовывать другой класс через интерфейс.
Операции и сигналы могут быть связаны отношениями обобщения. Интерфейс-потомок включает в себя все операции и сигналы своих предков и может добавлять собственные путем наследования всех операций прямого предка, т.е. его реализацию можно рассматривать как наследование поведения.
увеличить изображение
Рис. 8.3. Интерфейс взаимодействия через операции интерфейса (по Вегнеру)
Вегнер рассматривает модель взаимодействия, как обобщение машины Тьюринга - распределенной интерактивной модели взаимодействия объектов с входными (input) и выходными (output) действиями и возможностью продвижения в ней потенциально бесконечного входного потока (запросов, пакетов) в заданном интервале времени.
Дальнейшим развитием идеи взаимодействия, основанного на действиях, является язык AL (Action language), обеспечиывющий вызовов процедур (локальных или распределенных) с разверткой каждого вызова в программу [8.4], состоящую из операторов действий. Программа из вызовов процедур рассматривается в AL как ограниченное множество конечных программ, взаимодействующих со средой, в которую они погружаются.
Сети строятся на основе стандартной семиуровневой модели открытых систем OSI (Open Systems Interconnection) [8.5]. Объекты уровней в этой модели связываются между собой по горизонтали и вертикали. Запросы от приложений поступают на уровень представления данных для их кодирования (перекодирования) к виду используемой в приложении платформы. Открытые системы предоставляют любым приложениям разного рода услуги: управление удаленными объектами, обслуживание очередей и запросов, обработка интерфейсов и т. п.
Доступ к услугам осуществляется с помощью разных механизмов:
- вызова удаленных процедур RPC (Remote Procedure Call) в системах ОNС SUN, OSF DSE [8.5, 8.6];
- связывания распределенных объектов и документов в системе DCOM [8.7];
- языка описания интерфейса IDL ( Interface Definition Language) и брокера объектных запросов - ORB ( Object Request Broker ) в системе CОRBA [8.8];
- вызова RMI (Remote Methods Invocation) в системе JAVA [8.9, 8.10] и др.
Взаимосвязь процесса с удаленно расположенным от него другим процессом (например, сервером) на другом компьютере выполняет протокол UDP или TCP/IP, который передает параметры в stub - интерфейсе клиента stub -серверу для выполнения удаленной процедуры.
Механизм посылки запроса в системе CORBA базируется на описании запроса в языке IDL для доступа к удаленному методу/функции через протокол IIOP или GIOP . Брокер ORB передает запрос генератору, затем посылает stub / skeleton серверу, выполняющему интерфейс средствами объектного сервиса (Common Object Services) или общими средствами (Common Facilities). Так как брокер реализован в разных распределенных системах: CORBA, COM, SOM , Nextstep и др. [8.2], то он обеспечивает взаимодействие объектов в разных сетевых средах.
Вызов метода RMI в системе JAVA выполняет виртуальная машина (virtual machine), которая интерпретирует byte-коды вызванной программы, созданные разными системами программирования ЯП (JAVA, Pascal, С++) на разных компьютерах и средах. Функции RMI аналогичны брокеру ORB .
8.1.2. Интерфейс в среде клиента и сервера
В распределенной среде реализуется два способа связывания: на уровне ЯП через интерфейсы прикладного программирования и компиляторов IDL, генерирующих клиентские и серверные Stab. Интерфейсы определяются в языках IDL или APL , динамический интерфейс от объектаклиента к объектусервера и обратно выполняет брокер ORB . Интерфейсы имеют отдельную реализацию на ЯП и доступны разноязыковым программам. Компиляторы с IDL как часть промежуточного слоя сами реализуют связывание с ЯП через интерфейс клиента и сервера, заданного в том же ЯП [8.8, 8.11-8.13].
Интерфейс в IDL или в API включает описание формальных и фактических параметров программ, их типов и порядка задания операций передачи параметров и результатов при их взаимодействии. Это описание есть не что иное, как спецификация интерфейсного посредника двух разноязыковых программ (аналогично, как на рис. 8.1), которые взаимодействуют друг с другом через механизм вызова интерфейсных функций или посредников двух типов программ (клиент и сервер), выполняемых на разных процессах.
В функции интерфейсного посредника клиента входят:
- подготовка внешних параметров клиента для обращения к сервису сервера,
- посылка параметров серверу и его запуск в целях получения результата или сведений об ошибке.
Общие функции интерфейсного посредника сервера состоят в следующем:
Описание интерфейсного посредника не зависит от ЯП взаимодействующих объектов и в целом одинаково для всех вызывающих и вызываемых объектов. Посредник описывается в языке спецификации интерфейса IDL.
Интерфейсные посредники задают связь между клиентом и сервером ( stub для клиента и skeleton для сервера). Их описания отображаются в те ЯП, в которых представлены соответствующие им объекты или компоненты. Эти интерфейсы используются в системах CORBA, DCOM, LAVA и др. Они предоставляют всевозможные сервисы разработки и выполнения приложений в распределенной среде. Системные сервисы подключаются к приложению с помощью брокера. Брокер обеспечивает интероперабельность компонентов и объектов при переходе из одной среды другую.
Под интероперабельностью понимается способность совместного, согласованного взаимодействия разнородных компонентов системы для решения определенной задачи.
К средствам обеспечения интероперабельности и передачи данных между разными средами и платформами относится, например, стандартный механизм связи между JAVA и C/C++ компонентами, основанный на применении концепции Java Native Interface ( JNI ), реализованной как средство обращения к функциям из JAVA- классов и библиотек, разработанных на других языках.
Эти средства включает в себя анализ JAVA-классов в целях поиска прототипов обращений к функциям, реализованных на языках C/C++, и генерацию заголовочных файлов для использования их при компиляции C/C++ программ. В средстве JAVA классу известно, что в нем содержится обращение не к JAVA-методу (он называется и для загрузки необходимых C/C++ библиотек добавляется вызов функции), ориентируется именно на такую связь. Данная схема действует в одном направлении - от JAVA к C/C++ и только для такой комбинации ЯП.
Еще вариант реализации аналогичной задачи предлагает технология Bridge2Java,которая обеспечивает обращение из JAVA- классов к COM-компонентам. В этих целях генерируется оболочка для COM-компонента, который включает прокси-класс, обеспечивает необходимое преобразование данных средствами стандартной библиотеки преобразований типов. Данная схема не требует изменений в исходном Java-классе и COM-компоненты могут быть написаны в разных языках.
Такой подход позволяет реализовать доступ к компонентам, которые были разработаны раньше без ориентации на платформу . Net, например к COM-компонентам. Для этого используются стандартные средства генерации оболочки для COM-компонента, с помощью которой он представляется как . Net-компонент. При такой схеме реализуются все виды связей и для любых ЯП данной среды.
Читайте также: