Технологии 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.
