Вход в личный кабинет:

Забыли пароль? | Регистрация

Адреса компании:

Санкт-Петербург

196158, Санкт-Петербург,
Пулковское шоссе, д. 30,
корп. 4, Лит. А, офис 203

Тел: +7 812 414 95 41

Москва

129085, г. Москва, проезд Ольминского, д. 3а, стр. 3, офис 706

Тел: +7 495 616 00 53

Блог

26.08.2015

Progress OpenEdge: промышленные средства репликации данных в Oracle и MS-SQL

Progress OpenEdge Pro2 Replication

Читать далее →




Десять причин перехода на новые версии OpenEdge (Progress)


Плюсы и минусы самописного интеграционного ПО по сравнению с Sonic ESB

Вернуться к списку постов

06.04.2012

Определение требований к интеграционной системе.

Возьмем типовую интеграционную задачу – надежная, скоростная, критичная для бизнеса интеграция двух и более прикладных систем. Исходя из этого определим, что интеграционное ПО – это сложная, многофункциональная система.

Пример требований к ней может быть таковым:

  • Гарантированная и однократная доставка сообщений
  • Отказоустойчивость работы при сетевых, программных и аппаратных сбоях
  • Высокая производительность
  • Короткий цикл разработки интеграционного проекта
  • Легкое увеличение кол-ва подключенных прикладных систем
  • Централизованное управление и мониторинг состояния самой интеграционной системы и состояния обмена данными
  • Возможность использования контентной маршрутизации
  • Возможность использования преобразования данных
  • Оповещение об интересуемых ситуациях
  • Открытое API для увеличения функциональности
  • Низкая стоимость владения и обслуживания системы

Сразу скажу, что всем этим требованиям, а также другим, удовлетворяет Sonic ESB.

Минусы создания собственного интеграционного ПО, удовлетворяющего таким требованиям.

Sonic – готовое, основанное на стандартах (JMS, XML и пр.), поддерживаемое и развиваемое решение.
А вот чтобы довести самописное ПО до такого же состояния, как Sonic, придется потратить много и времени и денег. Больше, чем стоимость Sonic.

Первый минус вытекает из сложности создания любого ПО вообще:

  • Требуется наличие профессиональной команды – менеджера проекта, аналитиков, программистов, тестировщиков. А для них потребуются рабочие места, инструментарий, тестовые полигоны. А потребность в команде – только на период создания ПО. Не профессиональная команда сделает либо не то, либо за более долгий срок. Экономически иметь команду разработчиков для написания такой сложной системы не выгодно по сравнению с покупкой готового ПО такой же сложности. К примеру, команда из одного руководителя проекта – аналитика и трех программистов с усредненной зарплатой в 25 000 рублей это 100 000 рублей в месяц. Sonic ESB с максимальной функциональностью и на 1 процессор это примерно 520 000 рублей. Получается равносильно 5 месяцам работы вашей команды. Тот, кто когда-либо был связан с написанием ПО подобной сложности, понимает, что через 5 календарных месяцев идеальной работы не будет сделана конкурирующая альтернатива готовой интеграционной системе, над созданием которой работали десятки человек не один год.
  • Пусть вы потратили деньги и время и сформировали команду соответствующего уровня компетентности. Теперь команде предстоит реализовать достаточно сложный функционал, в процессе реализации вы можете наталкиваться на неопределенности с выбором способов реализации нужных механизмов будущего ПО. Для адекватного выбора нужно будет проводить грамотные тесты. Можно попасть в ситуацию, когда будет сделано то, что не окажется подходящим для использования, например, из-за низкой производительности, которую довольно сложно предсказать. Всё это приведет к тому, что реализация займет достаточно много времени, в отличие от времени, потраченного на покупку Sonic.
  • После внедрения самописного ПО, особенно в начале опытной эксплуатации, как правило, появляются такие ситуации, которые не были учтены в тестах и в которых система ведет себя не должным образом. Хотя бы потому, что такая ситуация не была учтена при проектировании. Соответственно, самописная система на данном этапе использования будет частично работоспособна. Для полной работоспособности нужно будет исправлять ошибки и дорабатывать её, что займет еще дополнительное время. В отличие, опять же, от времени на покупку Sonic. Что и кем будет делаться при наступлении нештатных, необрабатываемых ситуаций? Это еще один, скрытый минус самописного решения.
  • К примеру, вы готовы урезать функциональность самописной системы, чтобы уменьшить её сложность и, как следствие, сроки разработки. Тогда появляется тема удобства использования такой системы. Например, отсутствие централизованного управления или самовосстановления после сбоя усложнит работу обслуживающего персонала и приведет к увеличению времени поиска ошибки в обмене данными и увеличению времени восстановления работоспособности. В случае с Sonic на такую жертву не придется идти, т.к. Sonic – готовый продукт, «заточенный» под различные ситуации применения и под удобство его использования, и всё необходимое для интеграции в нём уже есть.
  • Для того чтобы самописное решение оставалось поддерживаемым и развиваемым, после создания придется содержать соответствующих специалистов. И, как правило, уход такого специалиста делает самописную систему мертвой. В отличие от использования Sonic – его создания не надо ждать, а поддержкой и развитием занимается всемирно известная компания Progress. И уход из вашей фирмы специалиста по Sonic не приведет к вымиранию системы, т.к. знания о Sonic не являются сакральными, система хорошо документирована, её можно изучить самостоятельно или с помощью готовых специалистов со стороны.

Обработка узкоспециализированных ситуаций.

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

По поводу API Sonic хочется перечислить:

  • XML, XSLT, XPath, Javascript для программирования и конфигурирования готовых ESB-сервисов;
  • Java для написания собственных ESB-сервисов обработки сообщений;
  • Java, C, C++, C#, COM для написания собственных Sonic-клиентов;
  • JMS для обмена сообщениями с клиентами, поддерживающими открытый стандарт JMS;
  • JDBC для доступа к базам данных через JDBC-драйвера.

Обоснованность появления систем интеграции приложений.

Интеграционное ПО – это такой же отдельный и нужный класс служебных систем, как, например, СУБД. Так же, как и СУБД, системы интеграции приложений появились в результате развития информационных технологий и увеличения требований к ИТ. И появились для облегчения построения ИТ-инфраструктуры, как и СУБД. Сейчас обоснованность существования СУБД никому не надо доказывать. Но и системы интеграции приложений появились в ходе аналогичной эволюции. Изначально появилась задача создать взаимодействие разнородных прикладных систем. Для решения этой задачи стали писать специальные заказные решения, сильно зависимые от конкретных прикладных систем. Далее стало ясно, что каждое из таких специализированных заказных решений обладает некими общими функциями, несмотря на различие в прикладных системах, форматах данных, регламентах обмена. Такие функции были определены и унифицированы. С тех пор системы интеграции приложений появились как отдельный класс ПО. Для использования такой системы вместо написания её с нуля нужно взять готовую и написать адаптеры к прикладным системам. Интеграционная система стала независимой от прикладных и стала еще одним централизованным набором функций. Можно предложить проследить тенденцию в развитии любой ИТ-инфрастуктуры – тяготение к централизации функций. Поясню. Одну систему легче обслуживать, чем много таких же. Поэтому сейчас распространены звездообразные топологии сетей (например, Ethernet с их коммутаторами и хабами, DSL с их мультиплексорами доступа), распространены клиент-серверные технологии (те же СУБД, Web-сервера, терминальные службы, доменные контролеры Windows и пр.) Также логично было вынести функцию передачи сообщений (асинхронного обмена данными в реальном времени) в одну централизованную систему. Систему интеграции приложений, ESB, коей является Sonic ESB. В случае централизации функций обмена данными появляется экономия количества нужных для реализации связей между прикладными системами.

Например, для организации взаимодействия 4-х систем напрямую каждая с каждой понадобится 6 двусторонних связей. А при использовании отдельного интеграционного ПО – 4 двусторонних связи (см. рисунок).

И чем больше прикладных систем, тем разница в количестве связей будет увеличиваться, т.к. кол-во связей при прямом взаимодействии растет квадратично (n*(n-1)/2), а при централизованном – растет линейно (n) (разность равна n*(n-1)/2 – n = n*(n-3)/2, где n – кол-во прикладных систем).

Альтернатива готовым ESB.

Сейчас мало кому в голову придет писать собственную СУБД – либо вы возьмете готовую, промышленную СУБД, либо для ваших потребностей подойдет простое хранение данных в файлах.

Учитывая всё вышесказанное, сделаем логичный вывод для интеграционных систем: либо вам стоит использовать готовую промышленную систему, либо вам будет достаточно совершенно простого (технически) механизма — файлового импорта-экспорта данных.

Теперь давайте рассмотрим интеграцию с помощью файлового импорта-экспорта данных. Одна из обычных схем работы: из одной прикладной системы вручную или автоматически по расписанию данные выгружаются в файлы; далее файлы переносятся ближе к получателю вручную или автоматически, переносятся, например, либо копированием, либо по электронной почте; далее опять же вручную или автоматически происходит загрузка файлов в другую прикладную систему. Необходимость выполнять выгрузку или загрузку вручную может происходить, например, из-за возможности сделать это только через GUI прикладной системы. Преимущество такой интеграции перед ESB – стоимость её создания и сроки внедрения. Минусы – практически нулевая надежность и отказоустойчивость, что приводит к необходимости уделять много времени контролю над таким процессом взаимодействия. Т.е. обслуживание такого механизма является трудоемким, и трудоемкость сильно возрастает с увеличением кол-ва прикладных систем, участвующих в обмене данными.

Сравнение готовой интеграционной системы и файлового импорта-экспорта по определенным в начале требованиям.

Требования к интеграционной системе Готовая ESB
(Sonic ESB)
Файловый импорт-экспорт
Гарантированная и однократная доставка сообщений Есть Скорее нет
Отказоустойчивость работы при сетевых, программных и аппаратных сбоях Да Нет
Высокая производительность Да Нет (в случае ручных операций)
Короткий цикл разработки интеграционного проекта Да Да
Легкое увеличение кол-ва подключенных прикладных систем Да Нет
Централизованное управление и мониторинг состояния самой интеграционной системы и состояния обмена данным Да Нет
Возможность использования контентной маршрутизации Да Нет (без специальной доработки)
Возможность использования преобразования данных Да Нет (без специальной доработки)
Оповещение об интересуемых ситуациях Да Нет (без специальной доработки)
Открытое API для увеличения функциональности Да Оно может быть
Cтоимость владения и обслуживания системы Стоимость владения выше Стоимость владения ниже
Стоимость обслуживания импорта-экспорта ниже, если прикладных систем мало и ручные операции редки

Итог

Итог данного анализа – условия выбора готового интеграционного решения и условия выбора создания и использования самописного ПО:

  • Самописное ПО: интеграция 2-3 прикладных систем, в крайнем случае – нескольких экземпляров 2-3 прикладных систем, или более простая конфигурация, при условии НЕ увеличения кол-ва прикладных систем, которые должны быть включены в интеграцию.
  • Готовое интеграционное ПО: интеграция 2 и более прикладных систем, в особенности — в условиях планируемого добавления прикладных систем к взаимодействию.

Что является неизбежным при выборе любого из двух вариантов системы:

  • Написание преобразователей форматов данных (воспринимаемые форматы разных прикладных систем вероятнее всего не совпадут, особенно если разработчики – разные, поэтому для того, чтобы системы понимали друг друга, надо написать преобразователи форматов)
  • Написание обработчиков данных внутри прикладной системы в случае создания нового взаимодействия.
  • Документирование инфраструктуры и конфигурации интеграционного решения

(Источник: http://www.hostco.ru)



Добавить свой комментарий

Ваше имя*:
Ваш E-mail*:
Ваш комментарий*:

Компьютерные системы для бизнеса
© 2010 - 2017 Все права на материалы, находящиеся на этом сайте, охраняются в соответствии с законодательством РФ, в том числе, об авторском праве и смежных правах. При любом использовании материалов сайта ссылка на источник обязательна.