Проектирование контракта сервиса

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

Контракт сервиса должен однозначно описывать его интерфейс и семантику. В идеальном случае контракт должен быть самодокументируемым, т.е. по контракту должно быть понятно что это за сервис, какие у него есть методы, какие параметры принимают данные методы и какие результаты они возвращают. Если контракт по настоящему самодокументируемый, то по нему возможна автоматическая генерация кода. Другим преимуществом самодокументируемого контракта является возможность автоматической валидации запросов к сервису. Причем помимо валидации синтаксиса запроса (пример - валидация XML-документа по XSchema) возможна валидация семантики запроса (пример - использование Schematron). В настоящее время стандартом для представления контрактов сервисов является язык Web Services Description Language (WSDL). В данной заметке мы рассмотрим основные решения, которые должен принять архитектор при разработке WSDL-описания контракта сервиса, а так же приведем некоторые практические советы.

Варианты запуска WebLogic Server'а с использованием WLST

Существует несколько способов запуска серверов участников домена сервера приложений WebLogic. Один из них - это использовать скрипты DOMAIN_HOME/bin/startWebLogic.sh для AdminServer'а и DOMAIN_HOME/bin/startManagedWebLogic.sh для управляемых серверов. Другой - использовать утилиту WebLogic Scripting Tool (WLST). В данной заметке мы подробно рассмотрим второй способ.

Пример использования Spring Framework совместно с SCA-контейнером Oracle WebLogic

В одной из предыдущих заметок я привел теоретическое описание компонентной архитектуры сервисов (SCA). Однако любая теория требует практического подкрепления, поэтому в данной заметке мы рассмотрим использование SCA-контейнера сервера приложений Oracle WebLogic и Spring Framework для реализации некоторых из довольно часто используемых паттернов интеграции корпоративных приложений (EIP) - Обогатитель данных (Data Enricher) и основанный на нем паттерн Квитанция (Claim Check).

Паттерн Обогатитель данных

Если есть две интегрируемые системы, одна из которых возвращает меньше данных, нежели нужно другой, то такие данные требуется обогащать - добавлять недостающие, получая их из некоторого хранилища. Например, по почтовому индексу, передаваемому системой-источником, можно получить во внешнем хранилище, например в БД КЛАДР, населенный пункт абонента и передать его в систему-приемник. В данном случае Обогатитель данных выступает специальным трансформатором преобразующим сообщение с неполным набором данных в итоговое сообщение. Важным компонентом данного паттерна является внешнее хранилище данных, которое может представлять собой СУБД, некоторое предустановленное корпоративное приложение или публичную службу.

Паттерн Квитанция

Данный паттерн решает следующую проблему: передаваемое через интеграционный слой, например через очередь, сообщение слишком большое, а его обработка осуществляется в несколько шагов. Чтобы не передавать большое сообщение на каждый шаг обработки, что может повлечь снижение производительности системы, можно поступить следующим образом: сохранить сообщение во внешнем хранилище, например в СУБД, а передавать некоторую квитанцию - сообщение, содержащее лишь указатель на сохраненные данные. При этом в том узле, в котором необходимо получить доступ к содержимому сообщения, оно извлекается из хранилища с помощью паттерна Обогатитель данных.

Асинхронный веб-сервис на Oracle Service Bus

Обеспечить асинхронное взаимодействие с веб-сервисом по протоколу HTTP можно не только с помощью Oracle SOA Suite, но и с помощью Oracle Service Bus. Основная сложность при этом заключается в том, что Oracle Service Bus не содержит встроенных средств сохранения состояния, поэтому необходимо будет каким-то образом сохранить во внешней памяти URL сервиса обратного вызова и идентификатор сообщения, на которое мы отвечаем. Так же нам нужно будет самостоятельно сформировать заголовок ответного SOAP-сообщения, соответствующий спецификации WS-Addressing. Давайте посмотрим как это можно сделать.

Модель потоков Oracle Service Bus

Чтобы разрабатывать эффективные с точки зрения производительности сервисы на Oracle Service Bus, необходимо понимать как данная шина использует потоки.

Общая модель потоков

Общая модель потоков OSB, т.е. модель потоков при использовании маршрутизации, следующая: ветвь обработки запроса выполняется в одном потоке, потоке для WorkManager'а прокси-сервиса, ветвь обработки ответа - в другом потоке - потоке для WorkManager'а бизнес-сервиса. После отправки запроса вызываемому сервису поток прокси-сервиса возвращается в пул потоков. Существует специальный мультиплексор, muxer, который используется для ожидания ответа от вызванного сервиса. После получения ответа тот передает его на обработку новому потоку, который используется для исполнения ветви обработки ответа (Response Pipeline). Данная архитектура подразумевает, что пока осуществляется ожидание ответа от бизнес-сервиса, никакие потоки не используются, что существенно улучшает масштабируемость в терминах использования потоков.

Интеграция Spring Framework и консоли администрирования сервера приложений WebLogic

При эксплуатации программ, разработанных с использованием Spring Framework, под управлением сервера приложений WebLogic, их сопровождение можно облегчить с помощью предоставляемых компанией Oracle расширений для консоли администрирования. В данной заметке мы рассмотрим как включить данные расширения и обеспечить их использование для управления приложениями.

Знакомимся: Компонентная архитектура сервисов - Service Component Architecture (SCA)

Компонентная архитектура сервисов (SCA) - это множество спецификаций, описывающих модель построения приложений и систем с использованием сервис-ориентированной архитектуры (SOA). SCA расширяет и дополняет предыдущие методы реализации сервисов и основывается на открытых стандартах, таких как веб-сервисы.

По-сути, SCA обеспечивает программную модель для реализации SOA.

Спецификация состоит из двух основных частей, описывающих методы

1. Реализации компонентов, предоставляющих одни и использующих другие сервисы.
   
   
2. Объединения множества компонентов для построения бизнес-приложений путем связывания сервисов и сервисных ссылок (service references).
   
   

Разработчиком спецификации является консорциум Open SOA Collaboration (www.osoa.org). Текущая версия спецификации - 1.0 от 21 марта 2007 г. Некоторые части спецификации приняты позднее, например SCA Assembly Extensions for Event Processing and Pub/Sub V1.00 - 30 апреля 2009 г. Существует черновик версии 1.1, выпущенный 31 мая 2011. Несмотря на то, что это - черновик, он уже поддерживается Oracle.

SCA подчеркивает независимость способа реализации и объединения сервисов от возможностей инфраструктуры и используемых методов доступа. Компоненты SCA обслуживают бизнес-уровень и используют минимум API промежуточного слоя.