Доступ к удаленным объектам (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.