СМ-Консалт
 

Работа с Web-сервисами в корпоративных SOA: Часть 1. Заполнение пробелов предприятия с помощью нескольких SOA

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

Введение

В моей третьей статье из серии, посвященной соглашениям о сервисном обслуживании (Service-Level Agreements — SLA) ( «Использование SLA с интернет-сервисами,» см. Ресурсы), я рассуждала о том, как можно дополнить приложения Enterprise Application Integration (EAI) (ИПМП — интеграция приложений масштаба предприятия) Web-сервисами и преодолеть, таким образом, ограничения EAI. В этой статье я иду дальше, рассматривая сценарии заполнения системных пробелов предприятия с помощью различных SOA и демонстрируя оформление бизнес-логики Web-сервисов, позволяющее добиться взаимодействия специализированных приложений EAI. Я покажу, как можно многократно применять Web-сервисы—как по предоставлению информации так и по бизнес-логике — в одной и более SOA и комбинировать их в сложное приложение.


Пробелы в EAI

Я сосредоточусь на трех основных ограничениях подхода EAI: специализированность, ограниченная интеграция и недостаток стандартов открытых отраслевых сетей. Все это создает препятствует эффективному взаимодействию компаний и предприятий; например, это такие приложения EAI как:

  • Управление связями с заказчиками (Customer relationship management — CRM)
  • Управление связями с инвесторами (Investor relationship management — IRM)
  • Управление поставками (Supply-chain management — SCM)
  • Планирование ресурсов предприятия (Enterprise resource planning — ERP)

Специализированность приложений EAI определяется видом коммерческих операций, для которых применяются приложения EAI, а также видом бизнеса, которым занимается компания. Подход EAI ограничивает работу по интеграции внешних приложений в системы EAI. Разработка схем преобразования данных бизнес-логики между системами EAI и внешними приложениями — дорогостоящий и долгий процесс.

Стандартов исполнения EAI в сущности нет. Но без таких стандартов очень сложно интегрировать многофункциональные коммерческие приложения EAI через интернет. В отличие от EAI, Web-сервисы предлагают огромное количество стандартных способов связи приложений с внешними сервис-провайдерами. Поскольку EAI безопаснее Web-сервисов, ИТ-компании совместно трудятся над созданием новых и улучшением существующих стандартов безопасности Web-сервисов, чтобы добиться более высокой степени безопасности.


Заполнение пробелов

Для заполнения пробелов в EAI используются различные промежуточные программные средства. Web-сервисы — лучшее промежуточное программное средство, обеспечивающее связь приложений EAI друг с другом. Они предлагают стандарты открытых отраслевых сетей для связи зависящих от платформ систем EAI. Иногда приложения EAI дополняются таким образом, чтобы исполнить роль потребителя или провайдера коммерческих операций в открытой отраслевой сети, что в закрытой среде является для приложений EAI невозможным.

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


Гармоничное сочетание Web-сервисов

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

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


Как избежать проблем

Разрабатывая или комбинируя Web-сервисы, вы можете столкнуться со следующими 4 проблемами:

  1. Издержки (overheads) простого протокола доступа к объектам Simple Object Access Protocol (SOAP)
  2. Проблемы, связанныве с интероперабельностью SOAP
  3. Сильносвязанные бизнес-сервисы
  4. Среды с затрудненными транзакциями.

Не всегда целесообразно создавать Web-сервисы везде и комбинировать их в общее приложение Web-сервисов, даже несмотря на то, что список стандартов открытых отраслевых сетей Web-сервисов постоянно растет, а приложениям EAI этого как раз недостает. Эксплуатация Web-сервисов грозит предприятиям слишком большими издержками SOAP и замедлением непосредственного выполнения коммерческих операций.

Предприятия могут также столкнуться с проблемами интероперабельности SOAP среди Web-сервисов. Несмотря на огромный объем проделанной работы по увеличению интероперабельности, SOAP пока еще не является общеотраслевым и интероперабельным протоколом.

Некоторые специализированные приложения EAI в сильносвязанной среде могут отлично выполнять определенные бизнес-функции, которые в слабосвязанной среде сложные приложения Web-сервисов осуществить не могут. В качестве примера сильносвязанной среды можно привести покупателя, который вводит дебетовую карточку в считывающее устройство, получает информацию о сумме дебета, уточняет получение наличности в торговом предприятии, и получает подтверждение автоматического снятия средств с его счета.

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


Сценарий для единичного SOA 

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

  • Retailer ID (идентификатор дистрибьютора)
  • Retailer Name (имя дистрибьютора)
  • Retailer Address (адрес дистрибьютора)
  • Order Quantity (объем заказа)
  • Pricing (цены)
  • Tax (налоги)

Как показано на Рисунке 1, первые четыре Web-сервиса выполняют только функции баз данных, в то время как в двух последних преимущественно используется бизнес-логика для осуществления доставки счета определенному дистрибьютору. Я объединяю их все в одно сложное приложение для формирования счетов, которое, в свою очередь, преобразуется в приложение для ведения бухгалтерского учета.


Рисунок 1. Сценарий для единичного SOA 
Сценарий для единичного SOA

Вначале Web-сервис Retailer ID запрашивает Web-сервис Retailer Name, чтобы установить соответствие имени и ID дистрибьютора. После подтверждения запроса Web-сервис Retailer Name интегрируется с Web-сервисами Retailer Address, Order Quantity, Pricing и Tax в сложное приложение для формирования счетов дистрибьютора. Затем это сложное приложение преобразуется в приложение для ведения бухучета на основе бизнес-логики этих услуг.


Сценарий для нескольких SOA

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

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


Рисунок 2. Сценарий для множественных SOA
Сценарий для множественных SOA

Один SOA, запрашивающий несколько приложений EAI

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

Будем считать, что SOA — главная промежуточная программная технология для сведения коммерческих функций нескольких приложений EAI как в их границах, так и вне брандмауэра. Чтобы избежать издержек SOAP, ограничьте количество Web-сервисов. Также постарайтесь избежать медленной загрузки запрашиваемых Web-сервисами приложений EAI.

В сценарии, где одна SOA запрашивает несколько приложений EAI, Web-сервис Retail ID сначала запрашивает систему Retail Мanagement System (система управления предприятием) (см. Рисунок 3). После успешной загрузки запрашиваемого приложения данный Web-сервис посылает запрос о связи ID с именем и адресом.


Рисунок 3. Единичный SOA запрашивает множественные приложений EAI
Единичный SOA запрашивает множественные приложений EAI

Затем приложение EAI выполняет поиск запрошенных объектов в базе данных. Когда имя и адрес найдены, информация передается в SOA для включения в сложное приложение Web-сервисов Объем заказа (Order Quantity) и (Цена) Pricing. Между тем система розничных продаж Retail Management System не загружена для запроса других приложений EAI.

Следующим шагом образовавшегося сложного приложения является запрос системы Finance Management System (система управления финансами), которая обслуживает базу данных налогового консультанта. После успешной загрузки этого приложения к нему подключается приложение объема заказа и цен. Таким образом строится сложная функция формирования счетов (расчетная функция). В этот момент система Finance Management System не загружена.


Несколько SOA, запрашивающих приложения EAI

Теперь предположим, что нам необходимы два SOA для связи двух приложений EAI. В данном сценарии я комбинирую Web-сервисы Order Quantity (объем заказа) и Order Description (описание заказа) в сложное приложение в первом SOA. Я повторяю действие из третьего сценария, когда Web-сервис Retail ID (идентификация для розницы) запрашивает, загружает и посылает запрос поиска системы Retail Management System (см Рисунок 4). После успешного поиска это приложение EAI посылает информацию в SOA для включения в сложное приложение. В этот момент система Retail Management System не загружена.


Рисунок 4. Множественные SOA запрашивают несколько приложений EAI
Множественные SOA запрашивают несколько приложений EAI

Затем это сложное приложение посылает системе Order Management System (система управления заказами) запрос о поиске базы данных Pricing Policies (ценовая политика). После успешного поиска система Order Management System подключается к Web-сервису консультанта по налогам во втором SOA. Затем консультант по налогам включается в сложную расчетную функцию (функцию формирования счетов) в первом SOA. Все процессы загрузки и разгрузки, таким образом, успешно проходят без издержек SOAP.


Число SOA

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


Заключение

Заполнение системных пробелов предприятия с помощью SOA требует заблаговременного определения возможного числа SOA. Вы должны рассмотреть различные варианты и проблемы исполнения с группой бизнес-аналитиков и ИТ-специалистов. Вы непременно увидите, что заполнение пробелов в EAI с помощью SOA значительно облегчит ваш труд по разработке приложений. Вы можете комбинировать бизнес-логику Web-сервисов в одном или нескольких SOA в одно или несколько сложных приложений. Аналитикам заполнение пробелов облегчит разработку и анализ систем SOA. Они смогут определить, какие Web-сервисы можно скомбинировать, чтобы обеспечить эффективную работу и избежать перегрузки SOAP.

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.
Карта сайта