Фреймворк WSIF: Универсальный доступ к веб-сервисам через WSDL

Введение

Web Services Invocation Framework (WSIF) поддерживает простой и гибкий Java API для вызова любого сервиса, описанного в языке описания веб-сервисов (WSDL). Используя WSIF, WSDL может стать центральным элементом интеграционной платформы для доступа к программному обеспечению, работающему на различных платформах и использующему различные протоколы. Программное обеспечение должно быть описано с помощью WSDL и содержать привязку (binding) в своем описании, для которой в клиентском WSIF-фреймворке существует соответствующий провайдер. WSIF определяет и поставляется с провайдерами для протоколов локального Java, Enterprise JavaBeans (EJB), Java Message Service (JMS) и Java EE Connector Architecture (JCA), что позволяет клиенту определить сервис EJB или Java Message Service как привязку WSDL и получить к нему прозрачный доступ с помощью WSIF, используя тот же API, который используется для сервиса SOAP или локального Java-класса.

Структура

В WSDL, связывание (binding) определяет способ сопоставления абстрактного PortType с конкретным форматом и протоколом сервиса. Например, связывание SOAP определяет стиль кодирования, заголовок SOAPAction, пространство имен тела сообщения (targetURI) и так далее. WSDL допускает наличие нескольких реализаций для веб-сервиса и несколько портов, использующих один и тот же PortType. Иными словами, WSDL позволяет одному и тому же интерфейсу иметь связывания с сервисами, такими как SOAP и IIOP. WSIF предоставляет API, позволяющий одному и тому же клиентскому коду обращаться к любому доступному связыванию. Поскольку клиентский код может быть написан для PortType, выбор порта и связывания, которые он использует, может определяться развертыванием, настройками конфигурации или кодом.

WSIF использует провайдеры для поддержки множественных связываний WSDL. Провайдер – это программный модуль, поддерживающий расширение WSDL и обеспечивающий вызов сервиса через конкретную реализацию. Провайдеры WSIF используют спецификацию поставщика услуг J2SE JAR, что делает их обнаруживаемыми во время выполнения. Клиенты могут использовать новые реализации и делегировать выбор порта инфраструктуре и среде выполнения, что позволяет выбирать реализацию на основе характеристик качества обслуживания или бизнес-политик.

Обязательства для ЕЖБ, СМС и СКК

WSIF определяет дополнительные обязательные расширения, позволяющие описывать в WSDL Enterprise JavaBean (EJBs), локальные Java-классы, программное обеспечение, доступное через очереди сообщений с использованием API Java Message Service (JMS), и программное обеспечение, которое может быть вызвано с помощью архитектуры Java Connector. WSIF поставляется с провайдерами, обеспечивающими прозрачный вызов на основе соответствующего описания WSDL.

Описание

WSIF позволяет разработчикам взаимодействовать с абстрактными представлениями веб-сервисов через их описания WSDL вместо непосредственной работы с API-интерфейсами протокола простого доступа к объектам (SOAP), который обычно используется в качестве модели программирования. С помощью WSIF разработчики могут использовать единую модель программирования независимо от реализации и способа доступа к веб-сервису. WSIF обеспечивает вызов веб-сервиса без заглушек или полностью динамически, на основе анализа метаданных сервиса во время выполнения. Он также позволяет подключать обновленные реализации привязок к WSIF во время выполнения, позволяя вызывающему сервису отложить выбор привязки до момента выполнения. WSIF тесно интегрирован с WSDL, что позволяет ему вызывать любой сервис, который может быть описан на этом языке. Если сложная корпоративная программная система состоит из различных компонентов, разработанных на протяжении десятилетий – EJB, устаревшие приложения, доступ к которым осуществляется через коннекторную архитектуру Java, SOAP-сервисы, размещенные на внешних серверах, старый код, доступ к которому осуществляется через промежуточное ПО обмена сообщениями – необходимо разрабатывать приложения, использующие все эти компоненты для выполнения полезных задач, где различия в протоколах и мобильность программного обеспечения приводят к конфликтам. При перемещении программного обеспечения на другой сервер код перестает работать. Используемые библиотеки SOAP могут измениться, например, при переходе с Apache SOAP на Apache Axis, поскольку последний использует устаревший API SOAP. То, что ранее было доступно как EJB, теперь может быть доступно через промежуточное ПО обмена сообщениями посредством JMS – в этом случае код, использующий программное обеспечение, необходимо исправить. Или, например, если EJB предлагается как SOAP-сервис для внешних клиентов, использование SOAP приводит к снижению производительности по сравнению с прямым доступом к EJB. WSIF решает эти проблемы, позволяя WSDL служить нормализованным описанием разнородного программного обеспечения и предоставляя пользователям доступ к этому программному обеспечению без привязки к конкретному протоколу или местоположению. Разделение API от фактического протокола обеспечивает гибкость – протоколы, местоположение и т.д. можно изменять без перекомпиляции клиентского кода. Если внешне доступный SOAP-сервис становится доступным как EJB, пользователи могут использовать RMI/IIOP, изменив описание сервиса (WSDL), не внося изменений в приложения, использующие этот сервис. Можно использовать расширяемость WSDL, его способность предлагать несколько привязок для одного и того же сервиса и принимать решение о привязке во время выполнения.

WSIF enables developers to interact with abstract representations of Web services through their WSDL descriptions instead of working directly with the Simple Object Access Protocol (SOAP) APIs, which is the usual programming model. With WSIF, developers can work with the same programming model regardless of how the Web service is implemented and accessed. WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the metadata about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, allowing the calling service to defer choosing a binding until runtime. It is closely based on WSDL enabling it to invoke any service that can be described in the language. If a complicated enterprise software system consists of various pieces of software, developed over a period of decades—EJBs, legacy apps accessed using Java's connector architecture, SOAP services hosted on external servers, old code accessed through messaging middleware—it is necessary to write software applications that use all these pieces to do useful things, where differences in protocols and mobility of software conflict with each other. If the software is moved to a different server, the code breaks. The SOAP libraries used change—for example, when transitioning from using Apache SOAP to Apache Axis, as it employs a now deprecated SOAP API. Something that was previously accessible as an EJB is now available through messaging middleware via JMS—again, the code that uses the software must be fixed, or if one has an EJB which is offered as a SOAP service to external clients. Using SOAP results in a performance penalty compared to accessing the EJB directly. WSIF resolves these issues by enabling WSDL to serve as a normalized description of disparate software and allowing users to access this software without depending on a specific protocol or location. The separation of the API from the actual protocol also means there is flexibility—protocols, location, etc. can be switched without having to recompile client code. If an externally available SOAP service becomes available as an EJB, users can use RMI/IIOP by changing the service description (the WSDL), without making any modification in applications that use the service. WSDL's extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc. can be exploited.

Различия между WSIF и Axis

Axis – это реализация SOAP. Он включает в себя серверную инфраструктуру для развертывания реализаций веб-сервисов и последующей маршрутизации SOAP-сообщений между клиентами и этими реализациями. Он также реализует спецификацию JAX-RPC для вызова SOAP-сервисов. WSIF аналогичен клиентской части Axis, поскольку используется для вызова сервисов. Однако API WSIF ориентирован на WSDL и не зависит от протокола; он позволяет подключать протокольно-специфичный код ("провайдеры"). Для вызова SOAP-сервисов WSIF поставляется с провайдером Axis, который использует API Axis (то есть JAX-RPC) для выполнения вызова. Таким образом, WSIF работает на более высоком, абстрактном уровне, чем Axis.

Различия между WSIF и JAX-RPC

JAX RPC — это API для вызова RPC-сервисов на основе XML, при этом текущий охват ограничен вызовом SOAP-сервисов. WSIF — это API для вызова сервисов, описанных с помощью WSDL, независимо от того, являются ли они SOAP-сервисами или нет (например, WSIF определяет привязки WSDL, позволяющие описывать EJB, корпоративное программное обеспечение, доступное через JMS или архитектуру Java Connector, а также локальные Java-классы как полноценные WSDL-сервисы и затем вызывать их с использованием единого, протокол-независимого WSIF API).