Особенности SOAP
Хотя управление Web-сервисом, как компонентом, необходимо предлолагает начало деятельности Web-сервиса, необходимо подчеркнуть тот ключевой аспект, который отличает большинство Web-сервисов от протоколов передачи двоичных данных в моделях программирования таких, как CORBA и DCOM: Web-сервисы – это технология работы с сообщениями, в которой и передача сообщений основана на XML (Simple Object Access Protocol [SOAP]), и они сами описываются на XML (Web Services Description Language [WSDL]).
В моей предыдущей статье я объяснил, как написать хендлер JAX-RPC для аудита и журнализации контента на основе SOAP. Сила такого подхода заключается в возможности манипулировать, перехватить и запросить “сырое” XML-сообщение по дороге к его пункту назначения.
С этим подходом связано несколько проблем, несмотря на очевидную привлекательность полного доступа к передаваемому сообщению. Например, для относительно типичной утилиты журнализации или аудита, этот подход не является слишком уж простым и декларативным —хендлер должен быть написан вручную (custom-written) и сконфигурирован для каждого Web-сервиса. Хотя хендлеры делают возможными сложные вещи, они не позволяют легко делать вещи простые.
Если вы отступите дальше и представите работу с Web-сервисами в разнородной среде, а это, скорей всего, наиболее типичное использование Web-сервисов, поскольку они по сути – технология интеграции, то применение хендлеров становится еще более проблематичным, так как они привязаны к JAX-RPC и не работают, если конечная точка (endpoint) вашего Web-сервиса реализована на C, Visual BASIC или Perl.
Таблица 1: Пример того, как может измениться входное сообщение
| Тело оригинального входящего SOAP-сообщения | SOAP-сообщение с новым параметром |
| ... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> </ns0:getEmpSalaryElement> </env:Body> ... | ... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> <salary_type>Commission</salary_type> </ns0:getEmpSalaryElement> </env:Body> ... |
