Взаимодействие между объектами
COM предназначен для прозрачного взаимодействия клиентов с объектами независимо от того, где выполняются эти объекты, в одном процессе, на одном компьютере или на другом компьютере. Это обеспечивает единую модель программирования для всех типов объектов, а также для клиентов объектов и серверов объектов.
С точки зрения клиента все объекты обращаются через указатели интерфейса. Указатель должен быть внутрипроцессным. На самом деле любой вызов функции интерфейса всегда достигает некоторого фрагмента кода в процессе. Если объект находится в процессе, вызов достигает его напрямую, без взаимодействия с кодом инфраструктуры системы. Если объект не является процессом, вызов сначала достигает того, что называется прокси-объектом, предоставленным COM или объектом (если требуется реализующий объект). Параметры вызова прокси-пакетов (включая любые указатели интерфейса) и создайте соответствующий вызов удаленной процедуры (или другой механизм связи в случае пользовательских созданных прокси-серверов) к другому процессу или другому компьютеру, на котором находится реализация объекта. Этот процесс упаковки указателей для передачи через границы процесса называется маршалингом.
С точки зрения сервера все вызовы функций интерфейса объекта выполняются с помощью указателя на этот интерфейс. Опять же, указатель имеет контекст только в одном процессе, и вызывающий объект всегда должен быть частью внутрипроцессного кода. Если объект находится в процессе, вызывающий объект является клиентом. В противном случае вызывающий объект является объектом заглушки, предоставляемым com или самим объектом. Заглушка получает вызов удаленной процедуры (или другой механизм связи в случае пользовательских созданных прокси-серверов) из прокси-сервера в клиентском процессе, отменяет параметров и вызывает соответствующий интерфейс на объекте сервера. С точки зрения как клиентов, так и серверов, они всегда взаимодействуют напрямую с другим встроенным кодом.
COM предоставляет реализацию маршалинга, называемую стандартным маршалингом. Эта реализация работает очень хорошо для большинства объектов и значительно сокращает требования к программированию, что делает процесс маршалинг эффективно прозрачным.
Четкое разделение интерфейса от реализации прозрачности процесса COM может, однако, в некоторых ситуациях. Дизайн интерфейса, который фокусируется на его функции с точки зрения клиента, иногда может привести к принятию решений, которые конфликтуют с эффективной реализацией этого интерфейса в сети. В таких случаях требуется не чистая прозрачность процесса, а "прозрачность процесса, если вам не нужно заботиться". COM предоставляет эту возможность, позволяя объекту реализовать поддержку пользовательского маршалинга (также называемого маршалингом IMarshal). Стандартный маршалинг— это, на самом деле, экземпляр пользовательского маршалинга; это реализация по умолчанию, используемая, если объект не требует пользовательского маршалинга.
Вы можете реализовать пользовательский маршалинг, чтобы разрешить объекту выполнять различные действия при использовании из сети, чем при локальном доступе, и он полностью прозрачный для клиента. Эта архитектура позволяет разрабатывать клиентские и объектные интерфейсы без учета проблем с производительностью сети, а затем устранять проблемы с производительностью сети, не нарушая установленный дизайн.
COM не указывает, как структурированы компоненты; он указывает, как они взаимодействуют. COM оставляет озабоченность по поводу внутренней структуры компонента для языков программирования и сред разработки. И наоборот, среды программирования не имеют стандартных стандартов для работы с объектами за пределами немедленного приложения. Например, Microsoft Visual C++работает очень хорошо для управления объектами внутри приложения, но не поддерживает работу с объектами за пределами приложения. Как правило, все остальные языки программирования одинаковы в этом отношении. Таким образом, чтобы обеспечить сетевое взаимодействие, COM через независимые от языка интерфейсы, выбирает, где языки программирования оставляются.
Двойное косвенное значение структуры вложенности означает, что указатели в таблице указателей функций не должны указывать непосредственно на реальную реализацию в реальном объекте. Это сердце прозрачности процесса.
Для внутрипроцессных серверов, где объект загружается непосредственно в клиентский процесс, указатели функции в таблице указываются непосредственно на фактическую реализацию. В этом случае вызов функции от клиента к методу интерфейса напрямую передает управление выполнением методу. Однако это не может работать для локальных, не говоря уже о удаленных, объектах, так как указатели на память нельзя совместно использовать между процессами. Тем не менее, клиент должен иметь возможность вызывать методы интерфейса, как если бы он вызывал фактическую реализацию. Таким образом, клиент равномерно передает управление методу в определенном объекте путем вызова.
Клиент всегда вызывает методы интерфейса в некоторых внутрипроцессных объектах. Если фактический объект является локальным или удаленным, вызов выполняется к прокси-объекту, который затем вызывает удаленный вызов процедуры к фактическому объекту.
Итак, какой метод выполняется на самом деле? Ответ заключается в том, что всякий раз при вызове внепроцессного интерфейса каждый метод интерфейса реализуется прокси-объектом. Прокси-объект всегда является внутрипроцессным объектом, который действует от имени вызываемого объекта. Этот прокси-объект знает, что фактический объект выполняется на локальном или удаленном сервере.
Прокси-объект упаковает параметры функции в некоторых пакетах данных и создает вызов RPC к локальному или удаленному объекту. Этот пакет выбирается объектом заглушки в процессе сервера на локальном или удаленном компьютере, который распаковывает параметры и вызывает реальную реализацию метода. Когда эта функция возвращается, заглушка упаковывает все вне параметры и возвращаемое значение и отправляет его обратно в прокси-сервер, который распаковывает их и возвращает их исходному клиенту.
Таким образом, клиент и сервер всегда разговаривают друг с другом, как если бы все было в процессе. Все вызовы от клиента и всех вызовов к серверу находятся в какой-то момент в процессе. Но так как структура зависимостей позволяет некоторым агенту, например COM, перехватывать все вызовы функций и все возвращаемые из функций, этот агент может перенаправить эти вызовы на вызов RPC по мере необходимости. Хотя вызовы внутри процесса быстрее, чем вызовы вне процесса, различия процесса полностью прозрачны для клиента и сервера.
Дополнительные сведения см. в следующих разделах:
См. также