СМ-Консалт
 

Работа с Web-сервисами в корпоративных SOA: Часть 2. Максимизация функциональной совместимости с внешними Web-сервисами

Статьи Технологии разработки ПО SOA и Web-сервисы

Введение

В моем первом пособии из этой серии по корпоративной SOA, «Заполнение системных пробелов предприятия с помощью множественных SOA» (смотрите Resources) я говорила о различных способах заполнения системных пробелов предприятия с помощью многочисленных SOA и показала, как можно повторно использовать Web-сервисы—центральные данные и бизнес-логику—из одной или более SOA и объединить их в составное приложение под контролем организации.

Когда организация не контролирует Web-сервисы, следует убедиться, что они могут внешне взаимодействовать друг с другом по отношению к совместно используемым семантике и контрактным обязательствам. Семантические несостыковки (например, в связи с патентом) или лазейки в контракте (например, многоплатформные различия) способствуют появлению проблем во взаимодействии между внешними Web-сервисами предприятия.

В этом пособии я покажу вам следующие четыре примера реализации сервисов Manufacturing Resource Planning (MRP) и Customer Relationship Management (CRM):

  1. Наследованное бизнес-приложение
  2. Динамическое соединение с внешними Web-сервисами
  3. Совместимость запросов REpresentational State Transfer/Simple Object Access Protocol (REST/SOAP) с внешним Web-сервисом
  4. Функциональная совместимость Web-сервисов при использовании IBM® WebSphere® Application Server и Microsoft® Visual Studio. Net 

Обдумывая различные компромиссные рещения, важно определить максимальное число совместимых SOA, которые есть в системе, чтобы избежать перезагрузок SOA.


Наследованное бизнес-приложение

Предположим, что унаследованное бизнес-приложение (смотрите Рисунок 1) разделено на модульные компоненты бизнес-процессов. Два наиболее важных компонента приложения-- MRP и CRM—требуют частых изменений и перекомпиляции долго работающего приложения.


Рисунок 1. Наследованное бизнес-приложение
Наследованное бизнес-приложение

Динамическое соединение сервисов

Чтобы повысить эффективность эксплуатации, следует вынести эти компоненты из данного приложения и перестроить их во внешние Web-сервисы. Таким образом, вы сможете поменять код в обоих Web-сервисах и не перекомпилировать большое, сложное, долго работающее приложение.

Доработанное приложение, как более компактная форма в первой SOA (смотрите Рисунок 2), предоставляет возможность динамической связи в внешним корпоративным Web-сервисом MRP во второй SOA, которая, в свою очередь, указывает на внешний корпоративный Web-сервис CRM в третьей SOA. При получении запроса Web-сервис CRM посылает запросы и информацию в приложение для дальнейшей обработки.


Рисунок 2. Динамическая связь с Web-сервисами
Динамическая связь с Web-сервисами

Каждый механизм соединения работает по схеме посыла запроса или сообщения, получения ответа или произведения операции SQL или HTTP. Вы также можете закрыть приложение без компонента MRP, чтобы послать запрос на Web-сервис MRP.


Среды разработки ПО

Вы должны помнить, что вопросы функциональной совместимости между платформами могут возникнуть при переключении от одного протокола к другому или одной среды разработки ПО к другой. Например, SOAP, REST,. Net Framework, Enterprise Java Beans (EJB) и Java Messaging Service (JMS).

Web-сервисы. Net, выходящие за рамки HTTP, можно назвать по-разному: операция HTTP GET, операция HTTP POST, и SOAP. Операции GET и POST необходимы, если срочно нужен Web-сервис, а клиент SOAP недоступен. Вы можете использовать REST, чтобы выполнить операции GET, POST, PUT и DELETE через HTTP в скрипте Perl. В этом скрипте вы можете послать запросы SQL и простые очереди сообщений.

Если клиент SOAP доступен, то сделать простой выбор между REST и SOAP можно следующим образом. Если приложение основано на ресурсе, выберите REST. Если приложение основано на деятельности, выберите SOAP. При работе с REST клиент может запросить выполнение нескольких операций на нескольких источниках через HTTP. Для запросов на SOAP нужна только одна операция запуска для каждой ориентированной на деятельность функции, которую может запросить клиент.


Среда разработки вызова

Чтобы сделать запрос SOAP, используйте Web Services Language Description (WSDL), язык, который описывает, как получить доступ к Web-сервису и то, какую операцию он произведет. Вы можете определить тип сервиса без кода настройки для Web-сервисов и без перекомпилирования унаследованного приложения.

Чтобы убедиться в том, что WSDL будет работать с различными средами разработки ПО, можете воспользоваться средой разработки IBM Web Services Invocation Framework (WSIF), которая позволяет использовать WSDL как стандартное описание несовместимого (disparate) ПО. То есть Вы можете получить доступ к WSDL, независящий от протокола или места нахождения, через язык описания API. Вы также сможете соединить Web-сервисы как комбинированное приложение, используя один WSDL, в котором вы можете переключать протоколы и места нахождения при разных условиях и исключениях.

Для построения WSIF Вы должны соблюдать минимальные требования, общие у любого провайдера. Опции:

  • анализатор JAXP XML 
  • WSDL для Java API 
  • Apache SOAP
  • Apache Axis.

Совместимость REST и SOAP

Так как запросы REST не зависят от WSDL, как запросы SOAP, для проверки операций REST вам нужны XML-схемы. Так как WSDL поддерживает технические характеристики схемы, REST и SOAP могут быть совместимы как запросы от комбинированного приложения Web-сервиса по отношению к внешнему Web-сервису.

Например, приложение в SOA #1 (смотрите Рисунок 3) сначала повылает запрос SOAP для активизации ориентированного на деятельность сервиса из Web-сервиса MRP в SOA #2 и затем посылает запрос REST для работы с серией сервисом, онованном на ресурсе, по отношению к тому же Web-сервису MRP Web. Все запросы SOAP основаны на IBM WSIF.


Рисунок 3. Совместимость REST и SOAP
Совместимость REST и SOAP

Как видите, приложение в первой SOA поступает на сервер Unix или Linux, а Web-сервис MRP во второй SOA поступает на сервер приложения IBM WebSphere (Application Server). Вы можете использовать WSIF, чтобы изменить тип сервиса или место нахождения в стандартной версии WSDL для запросов SOAP.


Функциональная совместимость продуктов WebSphere и. Net

Если вы хотите разработать более сложные Web-сервисы как часть проекта разработки расширенной корпоративной системы на платформе Linux или Windows, рассмотрите вариант IBM Rational® Application Developer для ПО Websphere. Он предоставляется с Universal Modeling Language (UML) Visual Editor для Java™ и EJB и функционирует на прлатформе открытого ПО Eclipse, позволяя вам расширить среду разработки. Вы также можете использовать Microsoft Visual Studio.Net.

Вы можете использовать также ПО для деления логики приложения на модульные компоненты Web-сервиса различных бизнес-процессов. IBM предлагает новейшую разработку Web Services Navigator, подключаемую программу Rational Application Developer, которая позволяет вам воздействовать на транзакции Web-сервисов.

Если вы используете Visual Studio.Net для разработки Web-сервисов на платформе Microsoft. Net platform, можете запустить их на Application Server. То есть, Вы можете сжать функциональную совместимость Web-сервисов между двумя платформами (смотрите Resources), и все, что необходимо, это разработать единый для обеих платформ WSDL.

Например, приложение, запущенное на сервере Unix или Linux (смотрите Рисунок 4) сначала посылает запрос SOAP для активизации сервиса, ориентированного на деятельность, из Web-сервиса MRP на Application Server. Приложение затем посылает запрос REST,чтобы работать на нескольких сервисах, ориентированных на ресурс, на том же Web-сервисе MRP. При получении запроса Web-сервис CRM в SOA #3 посылает запрос или информацию на исходное приложение.


Рисунок 4. Многоплатформные внешние Web-сервисы
Многоплатформные внешние Web-сервисы

Как видите, Web-сервис CRM в третьей SOA запускается на платформе. Net и имеет доступ к серверу приложений Application Server. Web-сервис CRM посылает запрос или информацию на приложение в первой SOA. Вы можете добавить подключаемую программу Visual Perl для Visual Studio.NET. Вы также можете использовать командный уровень Perl для миграции скрипта Perl, основанного на REST, от Unix к Windows и адаптировать его к среде Visual Perl, в зависимости от сложности скрипта.


Visual Studio

Чтобы герметизировать приложения Unix как компоненты COM, лучше выбрать Visual Studio. Net, чем Visual Basic, C++, Java, или Kornshell. С ним также проще работать, если Вы разрабатываете приложение для запуска приложений Windows с основным сценарием Unix, или если Вы переносите приложения Unix на платформу Windows, чтобы связаться с внешними Web-сервисами.

Вот что еще следует знать. Во-первых, вы должны опубликовать свой WSDL в общедоступном месте, чтобы устранить некоторые функциональные несоответствия. Вы можете пропустить автоматически создающийся файл WSDL в Bottom Up-подходе Rational Application Developer или WSDL First-подходе Visual Studio. Net. Вы можете использовать скелет Rational Application Developer или подход Top Down для запуска файла WSDL и внедрить Java Class. Или же Вы можете остановить автоматическое создание файла WSDL в WDSL First-подходе Visual Studio или опубликовать свой.

Во-вторых, чтобы получить шаблон WSDL, используйте метод Bottom Up в ПО Rational Application Developer (из Java Bean), Rational XDE (чтобы генерировать код шаблона, основанный на моделях классов) или метод Implementation First из ПО Visual Studio (чтобы генерировать код шаблона после того, как вы начали писать код для Web-сервиса). Rational Application Developer предоставляет редактор WSDL, а Visual Studio.Net этого не гарантирует.


Сколько SOA?

Количество SOA, которое вы можете использовать для связи с приложениями EAI, зависит от тех компромиссов для состыкования ПО, которые вы используете в связи со сложностью проекта, вопросами функциональной совместимости, бизнес-процессами и проблемами загрузки. Чтобы избежать издержек SOAP, вам нужно убедиться, что в течение всей разработки не произойдет перегрузка SOA. Необходимо протестировать возможные перегрузки на каждом витке цикла.


Заключение

Максимизация функциональной совместимости внешних Web-сервисов между многоплатформными SOA требует заблаговременного планирования, чтобы установить необходимое количество разрабатываемых SOA. Вы должны работать совместно с группой бизнес-аналитиков и со специалистами отдела информационных технологий. Решение вопросов функциональной совместимости сильно облегчит процесс разработк приложений. Вы можете разработать внешние Web-сервисы, каждый из которых может использовать разные платформы и протоколы запроса. Работа аналитиков по созданию и анализированию системы многоплатформных SOA также пойдет легче. Они смогут определить те платформы Web-сервисов, на которых SOA будет работать без перегрузок.

23.02.2008

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Бесплатный вебинар 14 декабря в 14 00 по Мск - «Секреты управления ИТ-командой: 10 важных практик, которые сделают команду эффективной»

Новые статьи в библиотеке

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Отчет, презентация и видео доклада для Октябрьской встречи Петербургского клуба менеджеров проектов в IT - SPM Meetup #36

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2016.
Карта сайта