Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Серверные компоненты






Не всякий COM-компонент может быть использован для обслуживания SOAP-запросов. В этом разделе будут рассмотрены требования к компонентам, способы их активации, возможности отладки.

Наиболее важное требование к компоненту, рассчитанному на работу с SOAP Toolkit – поддержка интерфейса IDispatch. SOAPServer должен сформировать вызов компонента на основе динамической информации, находящейся в WSML-файле. Чтобы это было возможным, компонент должен поддерживать позднее связывание на основе интерфейса IDispatch.

СОВЕТ Если для создания серверного компонента используется ATL (как наиболее популярная библиотека для создания COM-компонентов), для поддержки интерфейса IDispatch может использоваться шаблон IDispatchImpl. Однако если существует необходимость вызова по SOAP двух различных дуальных интерфейсов компонента, средствами ATL этого будет сложно добиться – так как ATL позволяет компоненту иметь только один дуальный интерфейс, доступный через IDispatch:: Invoke. Пожалуй, наиболее простой в данном случае способ заключается в создании “комбинированного” дуального-интерфейса, который перенаправляет вызовы нужной реализации, и который будет использоваться для SOAP-вызовов, или разделение компонента на два независимых, каждый из которых поддерживает свой дуальный интерфейс.

SOAP Toolkit накладывает ограничение на типы передаваемых параметров. Поскольку интерфейсы серверного компонента должны поддерживать IDispatch, мы ограничены только oleautomation-совместимым типами данных. Но и среди automation-типов есть типы, с которыми могут возникнуть проблемы. Это объектные ссылки (указатели на интерфейсы).

В мире COM/DCOM передача указателя на интерфейс сопровождалась неявным маршалингом, и клиент получал указатель на Proxy, который передавал вызовы серверному компоненту. В случае протокола SOAP передача указателя на интерфейс клиенту должна была бы означать, что клиент сможет делать SOAP-вызовы методов передаваемого объекта, но при этом для такого объекта также должны быть доступны WSDL- и WSML-файлы, и кто-то должен контролировать его время жизни (как это происходит в случае с DCOM).

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

Конечно, все эти проблемы могут быть решены, но в настоящее время SOAP Toolkit не поддерживает передачу объектных ссылок ни от сервера клиенту, ни в обратном направлении.

ПРИМЕЧАНИЕ SOAP нельзя рассматривать как полную замену DCOM, так как DCOM поддерживает специфические технологии, которые сложно или практически невозможно реализовать для SOAP-вызовов – управление временем жизни объектов (DCOM ping), передача объектных ссылок, COM-события. Поэтому в общем случае для перехода с DCOM на SOAP может потребоваться частичное (или даже полное) изменение архитектуры приложения.





© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.