В данной заметке Суровый челябинский программист расскажет о том, как создать простой сервис на Oracle SOA Suite и обеспечить взаимодействие с данным сервисом с помощью сервисной шины предприятия Oracle Service Bus (OSB). При этом, для создания проекта OSB будет использоваться интегрированная среда разработки Eclipse с комплектом расширений под названием Oracle Enterprise Pack for Eclipse (OEPE). Для создания же сервиса будет использоваться основная интегрированная среда разработки от Oracle - JDeveloper.
Предполагается, что у читателя уже установлены WebLogic, Oracle Service Bus, Oracle SOA Suite, JDeveloper и OEPE. Я использовал OSB и SOA Suite версии 11.1.1.5, но, думаю, что работа с ранними версиями в целом аналогична.
Создание echo-сервиса
Для демонстрации использования сервисной шины создадим простой веб-сервис, который возвращает принятую им строку. Т.е. это будет т.н. echo-сервис. Сервис представляет собой композит для SOASuite, логика которого реализована на BPEL.
Сначала создадим новый SOA-проект в JDeveloper.
Зададим в качестве названия проекта - echo-service, в качестве используемых технологий - SOA.
Сразу выберем, что создаваемый композит будет содержать в своем составе BPEL.
После нажатия кнопки Next появится мастер создания BPEL-процесса.
Создадим синхронный BPEL-процесс под названием EchoBPELProcess. Отметим, что данный процесс будет выставлен как веб-сервис. Значения параметров Input и Output оставим без изменений: процесс будет принимать на вход строку и возвращать строку.
После нажатия кнопки OK будет создан композит, содержащий BPEL-процесс EchoBPELProcess и связанный с ним веб-сервсис echobpelprocess_client.
После двойного щелчка по компоненту EchoBPELProcess откроется визуальный редактор BPEL. По-умолчанию, процесс содержит две операции - Receive и Reply. Назначение данных операций понятно из названия: Receive принимает запрос и запускает новый экземпляр процесса, а Reply возвращает ответ инициатору запроса. При этом важно отметить, что в общем случае логика процесса не обязана размещаться исключительно между Receive и Reply, процесс может продолжаться и после уведомления инициатора об успешном запуске.
Логика данного процесса довольно проста - значение переменной input копируется в переменную output. Для этого между операциями Receive и Reply необходимо разместить операцию Assign, перетянув ее с палитры компонентов. После размещения операции Assign в теле процесса необходимо настроить копирование, для чего щелкнуть два раза по ее значку. Откроется окно редактирования операции.
Визуальный редактор операции довольно прост - достаточно соединить связями источник копирования и приемник.
После внесения изменений достаточно нажать кнопку OK. Редактор операции закроется, изменения будут внесены в процесс. Теперь его можно сохранить, а композит развернуть на сервере Oracle SOASuite.
Для разворачивания композита существует операция Deploy.
На первом шаге мастера разворачивания необходимо выбрать куда именно мы собираемся поместить композит - на сервер приложений или в файл. По-умолчанию выбран вариант "на сервер приложений", который нас полностью устраивает.
На следующем шаге необходимо выбрать сервер приложений. Если у вас еще не настроена связь JDeveloper с сервером приложений, то сервер необходимо добавить, нажав кнопку плюс.
Запустится мастер регистрации сервера приложений. Сначала необходимо задать название сервера, которое будет использоваться в JDeveloper. Т.к. мы используем локальный сервер версии 11.1.1.5, то разумно присвоить ему метку localhost5. Тип сервера - WebLogic 10.3. JDeveloper так же может опубликовать проект на OC4J, Tomcat, JBoss и WebSphere.
Затем нужно задать логин и пароль администратора сервера.
После чего - настроить непосредственно соединение с сервером: указать порт, на котором серер работает, порт SSL, указать используется ли SSL и задать название домена.
На предпоследнем шаге мастера можно проверить соединение с сервером. Если все настройки верны, то каждый из девяти тестов завершится успешно.
После этого можно полюбоваться на страницу, уведомляющую об успешной настройке соединения с сервером и нажать Finish.
После нажатия кнопки Finish мы вернемся в мастер разворачивания композита.
Выберем вновь созданный сервер приложений и нажмем Next. Запустится поиск partition'ов, созданных на данном сервере для разворачивания композитов. Если поиск завершится успешно, то появится табличка с сервером приложений, списком partition, статусом сервера и его URL.
После нажатия кнопки Next откроется окно с общей информацией о порядке разворачивания композита.
Если вы согласны с данной информацией, то нужно нажать Finish. Окно мастера закроется и появится вкладка Deployment, содержащая информацию о процессе установки. Если установка завершена успешно, то в данной вкладке появится надпись Deployment finished.
Теперь нужно убедиться в работоспособности созданного сервиса. Для этого нужно воспользоваться Oracle Enterprise Manager. С помощью данного приложения можно управлять композитами, просматривать информацию об их работе, осуществлять мониторинг Oracle SOA Suite и OSB, а так же и других приложений.
Перейдем на страницу SOA -> soa-infra -> default -> echo-service.
Так как с BPEL-процессом связан веб-сервис, то данный процесс можно протестировать, нажав кнопку Test в верхней части открывшейся страницы. Откроется страница с информацией о сервисе echo-service. Нас интересует вкладка Input Arguments, на которой расположена форма ввода тестовых параметров. Данная форма генерируется по WSDL-описанию сервиса. В нашем случае будет всего один параметр - input.
После заполнения данного параметра, например значением test, необходимо нажать на кнопку Test Web Service. Будет создан экземпляр композита, на вход которого передано значение test. Если композит работоспособен, то откроется вкладка Response, значением поля result которой будет значение test, введенное на предыдущем шаге.
Возвратимся к списку экземпляров композита echo-service. Видно, что создан новый экземпляр с некоторым идентификатором, который успешно завершил свою работу, о чем свидетельствует его состояние Complete.
Основные понятия Oracle Service Bus
Сервисная шина предприятия является посредником между сервисами, а так же их клиентами. Она предназначена для реализации таких функций, как гарантированная доставка сообщений, маршрутизация, согласование форматов, управление транзакциями.
Ключевыми для Oracle Service Bus являются такие понятия, как Service Consumer, Service Provider, Business Service и Proxy Service. Стоит рассмотреть их подробнее.
Service Provider - экземпляр сервиса, т.е. нечто, непосредственно реализующее сервис. Сервис-провайдером может быть как веб-сервис, так и некоторый веб-сайт, база данных, файл, внешняя КИС, такая как SAP и т.д.
Business Service является посредником между шиной и сервис-провайдером. Обеспечивает такие возможности, как:
- связь через HTTP/SOCKS Proxy.
- балансировку нагрузки. Может существовать несколько Service Provider'ов, предоставляющих один и тот же сервис, соответственно Business Service может выбирать какому из них направить запрос.
- обеспечение гарантированной доставки. Если при отправке запроса Service Provider'у происходит ошибка, то возможна перепосылка запроса через некоторое время.
- кэширование результата вызова.
- и т.д.
Service Customer - клиент сервиса. Именно он инициирует запрос к сервису, предоставляемому Service Provider'ом, а так же получает и обрабатывает ответ от него.
Proxy Service является посредником между Service Customer'ом и Business Service'ом. Решает такие задачи, как:
- маршрутизация запросов и ответов.
- трансформация данных.
- управление транзакциями.
- создание т.н. составных сервисов - реализацию некоторой логики, в результате работы которой ответ формируется в результате вызова не одного, а нескольких Business Service (например, при взаимодействии с банковской системой, сначала узнается текущий операционный день, затем отправляются запросы с указанием полученного операционного дня).
Так как Service Provider'а мы уже создали - это сервис echo-service, а в качестве Service Customer'а будут выступать средства тестирования OSB, то нам осталось создать Business Service и Proxy Service, а так же развернуть их на OSB. Для решения данных задач воспользуемся средой Oracle Enterprise Pack for Eclipse (OEPE).
Создание подключения к серверу в среде OEPE
Для того, чтобы разворачивать созданные в Eclipse приложения на сервере, необходимо настроить соответствующее подключение. Для этого нужно открыть вид Servers.
Для добавления сервера служит пункт New -> Server из контекстного меню вида Servers.
После вызова данного пункта меню запустится мастер настройки подключения. В данном мастере необходимо выбрать тип сервера приложений - Oracle WebLogic Server 11gR1 PatchSet 4, задать параметры подключения, название сервера и т.н. Server runtime environment.
На втором шаге мастера нам будет предложено определить тип сервера: локальный или удаленный и выбрать директорию с доменом.
После выбора которой, можно будет создать подключение, нажав кнопку Finish.
Созданное подключение отобразится на виде Servers, откуда им можно будет управлять: запускать, останавливать, разворачивать приложения и обновлять опубликованную информацию.
Создание проекта OSB
Для того, чтобы создавать проекты для OSB, необходимо сначала создать т.н. конфигурационный проект, который будет являться корнем дерева проектов OSB. Можно провести следующую аналогию: конфигурационный проект - это EAR, а проекты OSB - WAR, RAR и JAR-архивы.
Для создания конфигурационного проекта необходимо вызвать пункт New -> Oracle Service Bus Configuration Project контекстного меню вида Project Explorer.
Для создания минимальной конфигурации достаточно задать ее название.
Созданная конфигурация отобразится на виде Project Explorer. В подкаталогах каталога Resource Summary будут агрегироваться соответствующие объекты из всех проектов данной конфигурации, например WSDL-файлы, сервисы и т.д.
Теперь можно создать непосредственно проект OSB. Для этого необходимо вызвать пункт New -> Oracle Service Bus Project контекстного меню вида Project Explorer.
В окне создания проекта необходимо указать его название и конфигурацию OSB, в которой тот будет разворачиваться.
Внутри проекта можно создавать ресурсы, такие как WSDL-файлы, Business Service'ы, Proxy Service'ы, адаптеры, файлы трансформации и т.д. Чтобы не сваливать все ресурсы в одну кучу, давайте разделим их по каталогам. Для этого необходимо данные каталоги создать. Создается каталог в проекте OSB точно так же, как и в любом другом: с помощью вызова пункта New -> Folder контекстного меню вида Project Explorer
Необходимо выбрать родительский каталог - EchoService и задать наименование - WSDL.
Каталог WSDL будет создан в выбраном родительском каталоге EchoService.
Аналогично создадим еще два каталога: ProxyService и BusinessService.
Теперь необходимо импортировать WSDL созданного ранее сервиса echo-service. Для этого необходимо вызвать пункт Import -> Oracle Service Bus - Resources from URL контекстного меню вида Project Explorer.
На первом шаге мастера импорта необходимо выбрать каталог для импорта - WSDL, задать URL WSDL'я, наименование и тип ресурса.
Узнать URL WSDL-описания сервиса можно в Enterprise Manager. На странице тестирования сервиса есть поле WSDL.
Необходимо скопировать значение данного поля в поле URL первого шага мастера импорта ресурса.
После нажатия на кнопку Next будут показаны импортируемые ресурсы. В данном случае будет импортирован не только WSDL-файл, но и связанная с ним XSD-схема.
После нажатия кнопки Finish будет осуществлен импорт. Новые ресурсы отобразятся в виде Project Explorer.
Теперь можно создать Business Service. Для этого нужно вызвать пункт New -> Business Service из контекстного меню вида Project Explorer
На первом шаге мастера создания Business Service'а необходимо указать каталог, в котором он будет создан, - BusinessService - и задать название сервиса - EchoBusinessService.
Будет создан файл EchoBusinessService.biz. Данный файл необходимо заполнить, воспользовавшись соответствующим редактором. Редактор многостраничный, основными для нас вкладками являются General и Transport.
На вкладке General необходимо указать тип сервиса. В нашем случае это будет сервис, основанный на WSDL, т.к. через данный бизнес-сервис будет вызываться обычный веб-сервис.
При выборе данного варианта станет доступной кнопка Browse. При нажатии на нее откроется окно выбора WSDL. В нем необходимо выбрать импортированный EchoWSDL.wsdl. После выбора данного файла откроется определенный в нем порт и связывание (binding).
Нужно выбрать порт и нажать кнопку OK.
Появится предупреждение, что в выбранном WSDL определена транспортная конфигурация (сервис), отличная от имеющейся. Т.к. имеющейся конфигурации по сути нет - Business Service только что создан, то и реагировать на предупреждение не нужно.
Выбранный порт и WSDL проставятся в соответствующие графы.
На вкладке Transport задается конфигурация связи Business Service и Service Provider. Здесь можно задать протокол связи, алгоритм балансировки нагрузки и URL'ы Service Provider'ов. Так же можно настроить параметры перепосылки запроса: указать количество попыток и интервал между ними.
На этом создание Business Service можно считать законченным.
Рассмотрим процесс создания Proxy Service. Данный сервис можно создать двумя путями: вручную или сгенерировать по уже созданному Business Service. Рассмотрим оба варианта.
Создание вручную выполняется путем вызова пункта New -> Proxy Service контекстного меню вида Project Explorer.
В окне создания Proxy Service необходимо выбрать каталог, в котором тот будет расположен, и указать его название - EchoProxyService.
В каталоге ProxyService будет создан файл EchoProxyService.proxy. Отредактировать данный файл можно с помощью специального многостраничного редактора.
Важными для нас являются вкладки General, Transport и Message Flow.
На вкладке General необходимо указать тип сервиса. Создаваемый нами Proxy Service будет основан на том же WSDL-файле EchoWSDL.wsdl, что и Business Service.
На вкладке Transport необходимо указать протокол для связи Service Consumer'а и Proxy Service, например, протокол http и задать URL создаваемого Proxy Service.
Наиболее интересная вкладка - Message Flow, на которой необходимо определить поток обработки запроса к Proxy Service, т.е. задать необходимые пути маршрутизации, трансформации форматов, логирование и прочие параметры прохождения информации.
Для рисования потока используются соответствующие компоненты из палитры, расположенной в виде Design Palett. Прежде всего небходимо перетянуть на поле рисования компонент Route Node.
После чего в данную Route Node необходимо переместить компонент Routing. В виде Properties будут отображены свойства данного компонента. Компонент имеет одно свойство - Service, в качестве значения которого необходимо указать сервис, на который будет отправлен запрос.
Для выбора сервиса можно воспользоваться кнопкой Browse. Будем перенаправлять все запросы на созданный нами ранее Business Service - EchoBusinessService.biz.
На виде Properties появится галочка Use inbound operation for outbound. В общем случае для запроса и для ответа можно настроить разные пути обработки. Если же отметить данную галочку, то ответ сервиса EchoBusinessService будет использоваться в качестве ответа сервиса EchoProxyService.
Второй способ создания Proxy Service несколько проще. Для генерации Proxy Service по имеющемуся Business Service необходимо вызвать пункт Oracle Service Bus -> Generate Proxy Service контекстного меню имеюшегося Business Service.
В окне генерации Proxy Service необходимо выбрать каталог для размещения вновь созданного сервиса и указать название самого сервиса.
В результате в выбранном каталоге будет сгенерирован файл с названием, соответствующем названию сервиса. Ключевые поля, такие как тип сервиса, протокол, URI и главное - Message Flow будут уже заполнены.
Публикация проекта на OSB
Для публикации созданного проекта его необходимо добавить в настроенное ранее подключение к серверу приложений. Для этого необходимо вызвать пункт Add and Remove... контекстного меню сервера приложений в виде Servers.
Появится окно выбора публикуемых проектов. Необходимо переместить созданную нами конфигурацию OSB Localhost, содержащую проект EchoService, в правую часть окна, используя соответствующие стрелочки.
Галочка If server is started, publish changes immediately позволяет автоматически синхронизировать изменения, сделанные в Eclipse, и программу, развернутую на сервере. Однако, я предпочитаю публиковать изменения вручную, поэтому данную галочку отключаю.
После нажатия на кнопку Finish конфигурация OSB Localhost добавится в соединение с сервером приложений.
Чтобы опубликовать проекты, которые в ней содержатся, на сервере, необходимо нажать кнопку Publish to the server на виде Servers.
После успешной публикации проектов на сервере, они будут отмечены как Synchronized.
Можно переходить к тестированию созданных сервисов.
Тестирование созданного Proxy Server'а
Для тестирования воспользуемся консолью администрирования OSB. Данная консоль расположена по адресу: http://host:port/sbconsole (в моем случае - http://localhost:7001/sbconsole).
После авторизации необходимо в левом меню консоли выбрать пункт Project Explorer. Должен отобразиться список всех проектов, развернутых на OSB, содержащий и проект EchoService.
Перейдем в каталог EchoService/ProxyService. На странице, отображающей содержимое каталога, присутствует блок Resources, в котором есть и созданный нами сервис EchoProxyService. В колонке Actions таблицы Resources содержится список действий, которые можно производить с сервисом. Среди действий есть и тестирование, которое доступно при нажатии кнопки с жуком. Кстати, изображение жука похоже позаимствовано из Eclipse.
При нажатии на данную кнопку откроется окно тестирования сервиса. В нем нас интересует поле payload, содержащее уже сгенерированный пример запроса. Добавим в этот пример значение для параметра ech:input - test, после чего нажмем на кнопку Execute.
Тестовый запрос будет отправлен на сервер, а о том, что запрос обрабатывается нас уведомят симпатичные часы.
Если все настроено корректно, то появится окно, на котором приведен тестовый запрос и соответствующий ответ от Service Provider'а.
Можно убедиться в том, что запрос действительно был обработан сервисом echo-service. Для этого нужно снова открыть страницу данного сервиса в Oracle Enterprise Manager'е. На странице будет отображен новый экземпляр сервиса, выполнение которого завершено успешно.
Если открыть информацию о BPEL-процессе из данного экземпляра, то можно увидеть, что сообщение test было получено и обработано.
Выводы
Продукты класса Enterprise Service Bus, такие как Oracle Service Bus, прочно входят в IT-инфраструктуру многих предприятий. Я уже писал о некоторых тенденциях развития корпоративной IT-инфраструктуры, связанных с переходом к SOA и процессному управлению. Можно заметить, что тенденции сохраняются: в той же Москве крупные компании либо внедрили, либо внедряют, либо планируют внедрить интеграционные решения, в частности основанные на ESB. Рынок здесь однозначно есть.
Считаю, что выбор в качестве основы для корпоративной шины продуктов компании Oracle оправдан: богатые возможности, о которых я еще буду писать, гибкость в настройках, производительность (для которой, впрочем, нужно довольно хорошее железо) и главное - наличие внятной документации являются достаточными причинами, чтобы обратить внимание на данную линейку продуктов как заказчикам, так и разработчикам.
В комментариях вы как всегда можете задать свои вопросы и высказать замечания. Ну или пожелания, если они у вас есть.
Понравилось сообщение - подпишитесь на блог
7 комментариев:
Спасибо за подробный пример. Одного не совсем понял. С помощью BPEL можно создать бизнес-процесс, к примеру, выполняющий прием заказа, проверку наличия товара на складе, оплату и т.п. Всё это будет оформлено в виде веб-сервиса (точка входа бизнес процесса). Что же тогда является бизнес-сервисом (компонент OSB) и зачем он нужен? Для чего этот второй уровень абстракции, если BPEL в частной задаче полностью покрывает требуемый функционал? Может дело в "плюшках" ESB, таких как пулинг, рапределение нагрузки, обработка исключений и т.п.?
В заметке об этом и написано, что Business Service реализует некий интерфейс к реальному сервису со стороны ESB.
Реализуется такая схема взаимодействия.
Клиент запрашивает сервис, запрос поступает в Proxy Service.
Proxy Service в зависимости от настроек Message Flow запрашивает Business Service.
Business Service запрашивает реальный сервис, реализованный на BPEL или чем-то другом.
Business Service реализует такие плюшки, как балансировка нагрузки, гарантированная доставка и т.д. Но даже без этих плюшек он необходим, т.к. является точкой подключения шины к реальному сервису (в терминах OBS - к Service Provider'у).
... в терминах OSB конечно же.
Ну а , скажем, если нет прямой необходимости использовать OSB (нет требований гарантированной доставки, распределять нагрузку негде и т.п.), можно ли обойтись одним BPEL бизнес-процессом, который свяжет все имеющиеся веб-сервисы и организует их взаимодействие? Он же (бизнес-процесс) будет задеплоен как веб-сервис, значит с ним можно будет работать на уровне веб-сервисов.
Да, конечно же можно. Более того, мы сейчас так делаем на некоторых проектах - реализуем транспорт с блекджеком и прочими поэтессами на SOA Suite без использования OSB. Тем более, если раньше у OSB и SOA Suite (если я правильно помню) адаптеры были разные, то теперь - в 11g - есть единая модель адаптеров.
Если создавать Proxy Service на основании WSDL, почему нельзя использовать абстрактную (без портов и биндинга) WSDL? Визард создания прокси обязательно требует порт. Ведь биндинг неабстрактной WSDL все равно потом заменяется биндингом OSB, в чем смысл?
По-моему, заменен будет не биндинг, а сервис. В частности, значение атрибута location. Биндинг же нужен, чтобы указать OSB какую модель связывания использовать.
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!