Сравнение COM (ActiveX) объектов и JAVA апплетов

Идентификация COM объектов.

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

Каждый интерфейс COM характеризуется двумя именами: одно из них символьное. По соглашению символьные имена начинаются с «I» «Interface». Различные технологии, основанные на COM, определяют интерфейсы с различными именами. Не исключено совпадение строковых имен у разных объектов. Поэтому для идентификации интерфейса операционной системой используется GUID – глобальный уникальный идентификатор. Для COM объектов его называют идентификатором класса и для его обозначения используют аббревиатуру CLSID, а GUID для интерфейсов обозначают IID. GUID представляет собой 16-байтовую величину, генерируемую автоматически при создании объекта COM или интерфейса.

При генерации идентификатора GUID необходимо обеспечить его глобальную уникальность. Это достигается обеспечением уникальности генерируемой величины во времени и в пространстве. Уникальность во времени обеспечивается за счет того, что GUID содержит метку времени создания, что обеспечивает отличие ото всех GUID, сгенерированных на данной машине. Для обеспечения уникальности в пространстве используется уникальный идентификатор компьютера, например адрес сетевой карты. Если сетевой карты нет, то из различных случайных характеристик данной системы генерируется фиктивный идентификатор машины.

Технологии COM и Java applets схожи в некоторых чертах: обе технологии не предполагают установки на компьютере множества дополнительных приложений. Тем не менее, технология JAVA предполагает наличие интерпретатора Java-кода.

В целом JAVA апплеты выполняются медленнее, чем COM объекты, так как объекты – это скомпилированный текст, а апплеты интерпретируются.

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

Все полученное из Интернет программное обеспечение необходимо проверять на вирусы. Но JAVA предполагает безопасный способ загрузки программ из сети, так как передается текст программы, интерпретируемый Java-машиной (программой), встроенной в браузер.

При поступлении из Интернет COM объекты регистрируются в операционной системе, при использовании объектов, вообще говоря, требуется проверять, не устарел ли он, и при необходимости обновлять. Java апплеты теоретически могут сохраняться во временных каталогах. Но стандартное использование их предполагает после запроса передачу апплета по сети, работу апплета во время показа странички и исчезновение апплета. При таком подходе не надо заботиться об обновлении, но не экономятся передачи по сети.

Доступ к удаленным объектам (DCOM,.Net, CORBA)

COM-объекты дают возможность интегрировать приложения, расположенные на одном компьютере. Для удаленного взаимодействия COM-сервера и COM-клиента требуется решить несколько дополнительных вопросов. Основные из них: как узнать, где расположен COM-сервер; как организовать передачу параметров по сети. Эти проблемы решены в технологии DCOM. Основное ограничение DCOM состоит в одинаковости аппаратно-операционной среды на общающихся компьютерах. Технология DCOM явилась фактически заплаточным решением, тем не менее, она оказалась востребованной.

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

Очень важной представлялась также проблема организации межъязыкового общения клиента и сервера. Программы, написанные на разных языках, непросто интегрировать в единый комплекс в связи с тем, что в разных компиляторах по-разному реализована передача параметров. Поясним это. Пусть мы имеем дело с функцией fff (p1 тип1,p2 тип2,p3 тип3), написанной на одном языке и программой ppp, вызывающей эту функцию, написанной на другом языке. Возможные проблемы при организации такого вызова следующие.

· Вызывающая программа (т.е. ppp) должна расположить в стеке фактические параметры. Беда в том, что компиляторы генерируют код, располагающий параметры в стеке либо в прямом либо в обратном порядке. Таким образом, может получиться, например, следующее - в стеке будут расположены параметры так: p1 p2 p3. А вызванная функция будет их выбирать в порядке p3 p2 p1. Поскольку область стека это просто последовательность битов, то нет никакой возможности распознать, где реально находится, где начинается и где заканчивается тот или иной параметр.

· Еще одна проблема проистекает из-за того, что в разных языках может быть разное представление (реализация) одинаковых с точки зрения программиста типов. Уже упоминавшиеся ранее нами целые числа могут быть представлены как «старший байт – младший байт», а могут байты идти наоборот. Строки символов тоже могут храниться в прямом и в обратном порядке. Массивы могут передаваться либо в порядке «по строкам», либо «по столбцам».

· Еще одна проблема при вызове функции, написанной на другом языке, состоит в том, что в языке вызываемой функции может просто не быть нужного типа данных. Например, в вызываемой программе используется четырехбайтное целое, а в вызываемой такого типа просто нет. В связи с чем расположенное в стеке четырехбайтное число будет воспринято неверно. Строки символов могут реализовываться тоже по-разному. Например, как набор символов, заканчивающийся символом с нулевым кодом. Либо как два (или четыре) байта – длина строки, за которыми следует набор символов.

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

Разработчики стандарта CORBA исходили из того, что система среднего слоя должна решать «на лету» все проблемы взаимодействия вне зависимости от аппаратно-операционной среды за счет преобразования на стороне клиента передаваемых параметров в некоторый стандартный (транспортный) вид и обратного преобразования из транспортного вида в вид, необходимый серверу. Кроме того, проблемы межъязыкового взаимодействия должны решаться на стадии разработки проекта за счет использования набора стандартных типов и предварительного описания CORBA объекта на языке IDL.

Дата добавления: 2014-01-04