19.08.2016, 15:37:31
Войти Зарегистрироваться
Авторизация на сайте

Ваш логин:

Ваш пароль:

Забыли пароль?

Навигация
Новости
Бизнес план кредитного потребительского
Финансовый рынок нашей страны довольно развит, что в общем-то характерно для государств всего мира с развитыми или развивающимися экономики. Но потребности в финансовых услугах все равно, в значительной

Бизнес онлайн от сбербанка
Услуга Сбербанк бизнес онлайн от Сбербанка России – это новая, уникальная и, несомненно удобная возможность для предпринимателей и юридических лиц управлять своими счетами в банке, а также проводить необходимые

Архив новостей
Реклама
Календарь событий
Right Left

Брокер інтеграції додатків

  1. Типова обчислювальна інфраструктура підприємств характеризується фактичної ізольованістю складових...
  2. Компоненти і топологія інтеграції
  3. Транспортний базис інтеграційного рішення
  4. інтеграційні адаптери
  5. інтеграційний брокер
  6. Перетворення форматів даних
  7. Маршрутизація інформації і даних
  8. Взаємодія з базами даних і іншими системами
  9. Засоби розробки, продуктивність і масштабованість
  10. Архітектура WebSphere MQ Integrator
  11. Потік обробки повідомлення і його візуальне конструювання
  12. Домени повідомлень
  13. Мова роботи з повідомленнями
  14. адміністрування брокера
  15. розширення функціональності
  16. Взаємодія з системами workflow
  17. Висновок
  18. література
Типова обчислювальна інфраструктура підприємств характеризується фактичної ізольованістю складових її додатків, що з точки зору бізнесу веде до затримок виконання ділових процесів, порушення взаємодії між підрозділами, перешкоджає управлінню і контролю, що призводить до зниження ефективності роботи організації в цілому. У загальному випадку, відсутність інтегрованості ставить під сумнів корисність ІТ для бізнесу. Стаття присвячена розбору пропонованих компанією IBM технологій інтеграції додатків, покликаних вирішити проблему ізольованості.

Технічних підходів до вирішення завдання інтеграції чимало, проте не можна забувати, що завдання цю доводиться вирішувати на унікальному організмі обчислювального середовища конкретного підприємства. Різні підходи можна розділити на кілька груп.

Перш за все, відзначимо кардинальний підхід, що вимагає повної заміни існуючих систем. Це дозволяє заздалегідь передбачити і закласти взаємозв'язку між окремими компонентами вже на етапі проектування. Однак за переваги нової технології доведеться розплачуватися втратою вже зроблених напрацювань, людських і матеріальних інвестицій. Типові приклади такого підходу - інтеграція на базі комплексної системи ERP або на базі «домашньої» розробки з використанням об'єктної технології. Крім неминучих втрат і труднощів перехідного періоду принцип повної заміни не вирішує проблем інтеграції для майбутніх удосконалень: нова система, як правило, не покриває всю прикладну функціональність, яка може знадобитися підприємству, - отже, проблема інтеграції залишається.

Другий підхід, пов'язаний з переробкою механізмів доступу до старих систем за допомогою нових інтерфейсів, передбачає написання різного роду обгортають і представляють програм. Підхід цей економічніший, оскільки дозволяє зберегти існуючі системи. Але в той же час він дозволяє реалізовувати досить обмежені сценарії взаємодії між системами.

Нарешті, більш глибокий інтеграційний підхід повинен забезпечити взаємодію систем для різних сценаріїв, вибудовування складних процесів передачі даних і управління між учасниками із забезпеченням реакції на різні типи подій. Гнучке інтеграційне рішення повинно бути відкритим для майбутніх змін.

Типові інтеграційні завдання

Інтеграційні проекти завжди є унікальними, однак можна вказати типові завдання: синхронізація даних, робота складових додатків і наскрізні бізнес-процеси.

Більшість сучасних корпоративних додатків використовують реляційні бази, як основу для зберігання і доступу до прикладних і системних даними. Тому не дивно, що часто під інтеграцією розуміють обмін даними між базами, і метою інтеграції ставиться синхронізація джерел даних, з якими працюють різні додатки. Cинхронизация даних означає відсутність взаємодії прикладних процесів і компонентів різних систем, замість нього має місце взаємодія компонентів зберігання даних.

Робота складеного додатка має на увазі взаємодію процесів, що виконуються в різних системах, що дозволяє з додатком реагувати на події, що відбулися в іншій системі. Сценарій такого взаємодії може варіюватися від досить простого до вельми складного. Для цілісної реалізації розподіленого ділового процесу, що охоплює кілька систем, вже недостатньо простої «сполучної» функціональності. Інтеграційне рішення повинно також відстежувати складну логіку взаємодії систем, використовувати певні виконавчі та контролюючі правила. У той же час інтеграційні завдання можуть дуже сильно відрізнятися за своїми характеристиками: тимчасовим, транзакційних, об'ємним. Скажімо, пакетне переміщення даних, що відбувається рідко, накладає інші вимоги, ніж переміщення, виконувані в режимі близького до реального часу. Транзакційні переміщення і взаємодії вимагають, в свою чергу, підтримки додаткових інтеграційних механізмів.

Різноманітність умов призвело до значного різноманітності в реалізаціях програмних рішень інтеграції, проте з часом виробилася типова функціональність і архітектура.

Компоненти і топологія інтеграції

Серед основних компонентів реалізації топології інтеграції можна виділити: транспортну інфраструктуру, прокладену між додатками; адаптери та конектори, які прив'язують прикладні системи до транспортної інфраструктури; інтеграційний сервер, що бере на себе різноманітну обробку і виконання обчислювальних процедур і процесів, пов'язаних з інтеграцією.

Транспортна середовище повинне забезпечувати більш високу надійність передачі даних між додатками і велику гнучкість для різних сценаріїв взаємодії в порівнянні зі стандартними мережевими службами. Для деяких інтеграційних завдань транспортне середовище повинна забезпечувати транзакційний режим передачі. Крім того, для інтеграційної транспортної середовища необхідний ще цілий ряд функцій, наприклад, система підтверджень доставки інформації, передача відповідно до пріоритетів і ін.

Топологія інтеграційного рішення відображає різні способи з'єднання взаємодіючих додатків і інтеграційних компонентів. Серед основних топологій виділяються сполуки типу «точка-точка», шлюзи і шини (рис. 1).

З'єднання «точка-точка» означає, що інтегруються додатки встановлюють прямі з'єднання один з одним. Простота методу ускладнюється необхідністю для взаємодіючих додатків, по-перше, знати точну адресну інформацію про партнера і, по-друге, вміти здійснювати перетворення між форматами даних використовуваних партнерами. Інтеграція даного типу часто означає розробку додаткового і зміна існуючого програмного коду як мінімум для одного, а частіше для обох взаємодіючих додатків.

Використання адаптерів і коннекторов забезпечує перетворення специфічних інтерфейсів і даних конкретного додатка в інтерфейси і дані стандартної інтеграційного середовища (наприклад, дані з таблиць реляційної бази даних в повідомлення транспортної інфраструктури). Прикладні програмні інтерфейси API дозволяють вбудувати в додатку код, що дозволяє працювати з транспортною інфраструктурою. Налаштування інтерфейсів, адресної інформації і процедур трансформації, що застосовуються в адаптерах замість написання коду, дозволяє прискорити впровадження інтеграційного рішення. Типові приклади - адаптери для під'єднання відомих прикладних систем, таких як SAP R / 3 і Siebel, технологічні адаптери, що дозволяють працювати з базами даних DB2, Oracle, Microsoft SQL Server, плоскими файлами, системами електронної пошти, нарешті, адаптери для спеціалізованих мереж передачі ділової інформації EDIFACT, ACORD, SWIFT, RosettaNet.

Наступний важливий компонент інтеграційного середовища - інтеграційний сервер, шлюз або інтеграційний брокер, що виникає як центральний вузол звернення інтегрованих систем і додатків. Через нього направляються потоки повідомлень і даних з цих систем; він перерозподіляє, обробляє і направляє ці потоки. Використання інтеграційного сервера дозволяє покласти на нього функції адресації і трансформації переданих даних, причому набагато більш складні, ніж в разі прямого з'єднання або використання адаптерів. Централізоване виконання функцій обробки інформації, що передається і даних також означає використання загального сховища для корпоративних інтеграційних правил. Правила із загального сховища доступні для огляду і прозорі для розробників і системних адміністраторів, можуть доповнюватися і змінюватися при зміні ділових процесів і складу обчислювальної середовища, що дозволяє ефективно поєднувати і динамічно управляти інтеграційним рішенням.

Стандартне інтеграційне рішення від IBM базується на транспортному шарі системи черг повідомлень WebSphere MQ, численних адаптери WebSphere BusinessIntegration Adapters і інтеграційному брокера WebSphere MQ Integrator [1].

Транспортний базис інтеграційного рішення

Завдяки простоті, надійності і універсальності програмне забезпечення систем черг повідомлень є однією з найбільш перспективних технологій інтеграції. Системи черг повідомлень надають асинхронний метод взаємодії для прикладних програм. Додатки обмінюються даними, посилаючи і приймаючи їх у вигляді повідомлень. При цьому додатки не взаємодіють один з одним безпосередньо, а звертаються до служби черг повідомлень і за допомогою API отримують доступ до черг і повідомленнями. Черги є проміжне місце зберігання повідомлень, свого роду спеціалізовану базу даних з механізмами, що гарантують збереження даних: журнал, відновлення після збоїв, обробка транзакцій.

У розподіленої середовищі за передачу повідомлень між системами відповідають мережеві компоненти системи черг повідомлень. Так, WebSphere MQ використовує канали передачі повідомлень, що забезпечують гарантовану передачу повідомлень поверх різноманітних мережевих з'єднань. При використанні протоколу гарантованої передачі посилається повідомлення не буде видалене з черги на сервері посилки до тих пір, поки воно не буде повністю прийнято на сервері-адресата - при передачі повідомлень реалізується мережева транзакція.

Протягом цілого ряду років розвиваються і удосконалюються різні компонентні прикладні архітектури CORBA, J2ЕE, .Net. Можна вказати на два моменти, що стосуються відносин подібних архітектур і рішень на базі систем передачі повідомлень. З одного боку, вони не є взаємовиключними: системи передачі повідомлень можуть ефективно поєднуватися з компонентними архітектурою, привносячи функції гарантованої доставки і асинхронного взаємодії для взаємодії розподілених компонентів. З іншого боку, в реальному житті постійно сусідять численні системи, побудовані на різних архітектурах, що не адаптуються під специфікації і стандарти конкретної компонентою архітектури. Практика показує: для взаємодії між подібними слабо зв'язаної системами найбільш придатні прості інтеграційні рішення на принципах обміну повідомленнями.

Серед переваг системи черг повідомлень можна відзначити різноманіття сценаріїв взаємодії програм - від простої розсилки інформації адресатам до підтримки тематичної адресації в моделі «публікація-підписка» та складних розподілених і розпаралелених обчислювальних процесів. Крім того, існування додаткової ланки у вигляді черг повідомлень дозволяє вставляти проміжну обробку інформації, що передається для вирішення різних завдань: забезпечення безпеки і сумісності форматів, динамічної маршрутизації, аналізу контенту і т.д.

інтеграційні адаптери

Адаптери грають роль сполучних містків між прикладними системами, з одного боку, і транспортної середовищем разом з брокером інтеграції, з іншого ( Мал. 3 ). Зазвичай адаптер виступає як постійно діючий процес, що відслідковує настання різних подій в прикладної системі і транспортному середовищі. Адаптер підтримує два основні сценарії:

  • відстеження подій, що відбуваються в прикладної системі, і відсилання інформації про них зацікавленим додатків через транспортну середу;
  • прийом і обробку запитів, які прийшли з боку інших додатків через транспортну середу на адресу прикладної системи, з можливого зворотного відправкою результатів і сповіщень.

Адаптери також можуть підтримувати функції трансформації і перетворення даних, що посилаються між системами (правда, зазвичай простіші, ніж інтеграційний брокер). Залежно від реалізації поведінку адаптера може бути статичним або дозволяти динамічні зміни, керовані подіями.

інтеграційний брокер

Інтеграційні брокери (рис.4) забезпечують взаємодію додатків через центральний проміжний шлюз, що підтримує інтелектуальну обробку і розподіл даних між додатками. Роль брокера в інтеграційній середовищі, заснованої на передачі повідомлень, - це роль поштамту, сортують і реєструючого поштові відправлення, який перевіряє адресну інформацію і розподіляє їх для подальшої відправки адресатам.

Брокер виникає як проміжний сервер в інтеграційній транспортному середовищі і займається обробкою потоків повідомлень і даних, що передаються, а також виконанням викликів і звернення по різних інтерфейсах. Брокер перерозподіляє, обробляє і направляє потоки інформації, даних і повідомлень між інтегрованими системами.

Перетворення форматів даних

Передавання даних між системами дані можуть мати різну структуру, оформлену в самих різних форматах. На практиці зустрічаються відкриті стандартизовані формати (наприклад, XML), специфічні для конкретної галузі формати (EDI або SWIFT), що відносяться до конкретної прикладної системі (SAP R / 3) або унікальні формати, розроблені для конкретного додатка. Брокер повинен забезпечити сумісність форматів для всіх що беруть участь в обміні сторін і вміти оперувати даними в форматах самих різних типів.

Маршрутизація інформації і даних

Передача інформації від одного додатка до іншого може базуватися на методі прямої адресації, коли посилає додаток явно знає і вказує свого кореспондента. Однак додаток в кінцевій точці цього може і не знати: реальна адресна інформація може змінюватися, коли системи стають активними або вибувають з експлуатації або адресна інформація відсутня з причин забезпечення безпеки. Можуть бути також випадки, коли адресна інформація повинна бути визначена зі змісту переданого повідомлення або отримана з зовнішніх даних в момент обробки. У таких ситуаціях брокер може виступати інтелектуальним маршрутизатором, аналізуючи адресну, контекстну і прикладну частину інформації і використовуючи бізнес-правила зі сховищ, він розподіляє дані по адресатам.

Підхід, протилежний прямої адресації, - розподіл інформації на підставі динамічних запитів від додатків-користувачів інформації. Технологія повідомлень дозволяє ефективно реалізувати модель публікація-підписка. Інтеграційний брокер приймає заявки-підписки на інформацію за темами від додатків-передплатників та тематичні повідомлення-публікації від додатків-публікаторів. Брокер розподіляє публікації по передплатникам на підставі збігу тематик і змісту, що є гнучким динамічним механізмом адресації інформації.

Взаємодія з базами даних і іншими системами

Обмін даними, узагальнено кажучи, між зовнішньою динамічної транспортною системою і середовищем внутрішніх даних прикладних систем є найбільш часто повторюється дією. Подібний обмін повинен бути реалізований на загальних для обох середовищ мовних і інтерфейсних засобах; необхідна підтримка стандартів SQL, ODBC, XML. Правда, треба зауважити, що сервери баз даних мають власні спеціальні засоби для збору, передачі і завантаження даних, а також кошти реплікації даних. На відміну від інтеграційних брокерів інструменти СУБД орієнтовані на роботу тільки з базами даних. Якщо порівнювати можливості засобів інтеграційного брокера і засобів сервера баз даних, то брокери часто мають більш обмежені можливості у використанні всіх механізмів СУБД, зокрема, у використанні групових операцій і в підтримці цілісності моделі даних. У той же час брокери повідомлень надають більш надійні транспортні механізми, гнучку маршрутизацію і систему обробки і реакції на події.

Засоби розробки, продуктивність і масштабованість

Універсальний інтеграційний брокер повинен дозволяти створювати і виконувати довільні процедури обробки. Засоби розробки таких процедур повинні бути природні та ефективні в освоєнні і використанні, надавати можливості групової роботи, підтримувати відкритість і прозорість коду процедур для повторного використання і внесення змін.

Масштаби інтеграційної завдання можуть зажадати від брокера високої пропускної здатності, особливо якщо припустити, що потоки даних з декількох інтенсивно працюють систем повинні перетинатися на брокера. Брокер повинен володіти високопродуктивним обробляють ядром з можливістю масштабування на різному устаткуванні.

Архітектура WebSphere MQ Integrator

За свою Історію цею програмний продукт МАВ Версії з різнімі іменамі: MQSeries Integrator [2], MQ Integrator, MQ Integation Broker, MQ Message Broker. Основні компоненти WebSphere MQ Integrator: система виконавчих брокерів, сервер конфігурації Configuration Manager и універсальна графічна середовище розробки и адміністрування ControlCenter ( Мал. 5 ). Брокери, які відповідають за виконання потоків обробки, є виконавчої середовищем. Кожен брокер має власну базу даних, що зберігає частину даних головного сховища. Многопроцессность і багатопотокова архітектура ядра брокера забезпечує масштабованість. Служба форматування повідомлень дозволяє брокеру розбирати повідомлення на окремі поля і оперувати з повідомленнями як з складно структурованими документами.

Сервер конфігурації - центральний компонент, керуючий веденням сховища форматів і бізнес-правил, а також поточною роботою брокерів. Взаємодія між окремими компонентами WebSphere MQ Integrator базується на чергах WebSphere MQ. Всі команди і запити, що йдуть від ControlCenter на сервер конфігурації, реалізуються у вигляді повідомлень. Сам сервер конфігурації і брокери зв'язані за допомогою черг повідомлень WebSphere MQ, через які передаються внутрішні керуючі і звітні повідомлення WebSphere MQ Integrator в форматі XML.

Потік обробки повідомлення і його візуальне конструювання

Обробка повідомлення, що потрапив в брокер, визначається потоком обробки повідомлення (message flow), що представляє собою спрямований граф. Його вузли - це окремі кроки або процедури обробки, а ребра - шляхи сполучень в потоці між окремими стадіями обробки (рис. 6). Фактично логічне уявлення процесу обробки даних і переходу контролю між стадіями обробки співпаде з фізичним процесом внутрішньої трансформації повідомлення на стадіях обробки. Потік обробки складається з послідовності операцій над повідомленням і конструюється за допомогою набору існуючих стандартних обробників. Обробники WebSphere MQ Integrator - це параметрически настроюються процедури, що реалізують окремий крок або спеціалізовану функцію процесу обробки. У властивостях процедур-обробників визначаються параметри, необхідні для виконання даного потоку. Скажімо, якщо обробник читає повідомлення з черги WebSphere MQ, то в якості параметра визначається ім'я черги. Якщо інший обробник призначений для звернення до зовнішньої базі даних, то серед його параметрів будуть назви бази, таблиць і полів. Обробники мають точки входу і виходу - так звані «термінали». Вхідні і вихідні термінали оброблювачів зв'язуються сполуками, утворюючи спрямований граф, який реалізує покрокову послідовність обробки повідомлення.

Потік обробки стандартно починається з отримання повідомлення з черги через вхідний обробник (Input) і закінчується розсилкою повідомлень іншим системам через один або кілька вихідних оброблювачів (Output), записом в базу даних, або публікацією повідомлення для групи передплатників за випадковим збігом теми або просто знищенням надісланого повідомлення . Найчастіше для зв'язку з зовнішніми системами використовується транспорт WebSphere MQ, а вхідні чергу є збірним ящиком для прийому інформації у вигляді повідомлень, що надходять ззовні. В інших випадках процедура обробки може стартувати при отриманні даних з телеметричних пристроїв через протокол SCADA, з мобільних пристроїв за допомогою MQSeries Everyplace або починатися з виконання довільного вхідного обробника власного написання. Важливим завданням на стадії прийому повідомлення через вхідний обробник Input, крім читання прийшов повідомлення з черги, є правильна інтерпретація його вмісту, віднесення до відповідного домену, розбір повідомлення відповідно до типу і форматом на окремі поля. При цьому, для різних доменів повідомлень (наприклад, XML або SAP Idoc) існують різні компоненти аналізу і розбирання структури повідомлення - парсери, які використовуються вхідним оброблювачем. Серед параметрів, що визначають поведінку потоку обробки і окремих оброблювачів, містяться найважливіші ухвали про транзакційності даного потоку обробки, про сталість або непостійність створюваного повідомлення, способі передачі контексту і ідентифікаційної інформації з вихідного повідомлення в нові повідомлення, що створюються в процесі обробки.

Ціла група оброблювачів служить для маршрутизації і розгалуження процесу обробки. Інші обробники призначені для реалізації різних синтаксичних і семантичних перевірок. Наприклад, обробник фільтра розділяє потік на окремі гілки в залежності від умови фільтрації. Умовні переходи з динамічними і статичними призначеннями всередині потоку забезпечуються обработчиками RouteToLabel і Label. Для реакції на виникаючі помилки і обробку виняткових станів існують обробники TryCatch і Throw. Трасування і перевірка коректності потоку і структури проходять повідомлень здійснюються відповідно обработчиками Trace і Check, а обробник FlowOrder визначає порядок проходження окремих гілок потоку обробки. Для взаємодії з базами даних існують спеціалізовані обробники, що дозволяють візуально призначати зв'язку і перетворення між полями бази даних і полями повідомлення. Найбільш часто використовуваним і універсальним за можливостями є обробник Compute, що дозволяє писати різноманітні програми-скрипти на мові ESQL, розширенні SQL3 [3].

Домени повідомлень

На стадії первинної обробки будь-якого повідомлення, що потрапив в WebSphere MQ Integrator, відбувається його віднесення потрібного домену (XML, JMS, MRM, NEON, BLOB) і розбір на окремі поля. Деякі типи повідомлень WebSphere MQ Integrator вміє розпізнавати і обробляти динамічно без використання попередньо занесених в репозиторій метаданих, наприклад, динамічно відбувається обробка так званих «добре визначених» XML-документів. Для інших типів XML-документів потрібно попереднє занесення структури в репозиторій, наприклад, шляхом експорту DTD документа. Серед доменів особливо виділяється MRM (Message Repository Manager), що є основним репозиторієм. MRM-повідомлення можуть мати довільну і дуже складну структуру; інструментальні засоби брокера дозволяють розробляти нові MRM-формати.

Повідомлення, створені додатками за допомогою інтерфейсу JMS, можуть відноситися до декількох типів мови Java: текст, потоки, карти і об'єкти Java. Опціонально WebSphere MQ Integrator включає технологію розбору і обробки повідомлень, ліцензовану у компанії NEON. Нарешті, зміст неструктурованих повідомлень і повідомлень з невідомої структурою трактуються як великі бінарні об'єкти і відносяться до домену BLOB.

Зупинимося на тому, як WebSphere MQ Integrator визначає, до якого домену відноситься прийшло повідомлення. Інформація про домен повідомлення і супутніх параметрах формату може міститися в самому повідомленні або визначатися інформацією, що зберігається в репозиторії MQ Integrator. У першому випадку для визначення формату повідомлення використовуються поля стандартного заголовка і спеціалізовані підзаголовки повідомлень WebSphere MQ (наприклад, підзаголовок MQRFH2, що має поля для визначення набору, типу і формату повідомлення). При використанні другого підходу в репозиторії зберігаються настройки потоку обробки, параметри вхідного обробника Input, що дозволяють призначати домен, формат і тип для повідомлень, які будуть потрапляти до вхідної черги.

На етапі обробки брокер використовує власне внутрішнє повідомлення, створене шляхом доповнення змісту оригінального службовою інформацією, що містить дані про виняткові станах, змінних оточення і адресатів призначення. Це повідомлення використовується процедурами-обработчиками і дозволяє гнучко управляти виконанням потоку обробки на кожному його етапі.

Мова роботи з повідомленнями

Мова скриптів ESQL, що розвиває широко використовуваний процедурний мову SQL3, доповнений засобами маніпулювання повідомленнями різноманітних форматів. ESQL використовується в трьох основних обробниках - Compute, Filter, Database - і дозволяє змінювати зміст і службові дані вхідного повідомлення, створювати нові повідомлення і оновлювати зовнішні бази даних. Важливою особливістю ESQL, що відрізняє його від SQL3, є довідкові конструкції, що дозволяють адресувати окремі поля і елементи в структурованому дереві повідомлення, використовувати різні методи для виділення окремі групи елементів і методи навігації по дереву повідомлення.

адміністрування брокера

Для підтримки життєдіяльності брокера потрібні різноманітні інструменти, починаючи з коштів розробки нових форматів і процедур обробки (в тому числі, засобів тестування і налагодження) і закінчуючи засобами адміністрування та моніторингу повсякденної роботи брокера і діагностики проблем. У WebSphere MQ Integrator використовується інтегроване середовище управління, що є універсальним інструментарієм і для розробника, і для адміністратора. У середу управління входять компоненти, об'єднані спільною графічною оболонкою і підтримують весь цикл роботи брокера: визначення форматів повідомлень; розробка процедур обробки; режим тестування; призначення розроблених процедур на виконання конкретного брокеру; динамічне поширення змін на вже працюють процедури; визначення загальної топології середовища розподілених брокерів; моніторинг стану діючих брокерів і потоків обробки; журнал роботи адміністративних операцій.

розширення функціональності

WebSphere MQ Integrator можна розширити шляхом додавання нових обробників для програмування типових функцій. При цьому передбачений стандартний інструментарій, що дозволяє створювати нові розробники на мовах Сі та Java. Крім того, доступні численні додаткові обробники, розроблені партнерами, замовниками та фахівцями IBM, наприклад, обробники для посилки електронної пошти, або посилки-прийому файлів по FTP, виконання XSLT перетворень та ін. Внутрішня функціональність брокера може бути доповнена шляхом вбудовування парсеров для роботи зі спеціалізованими форматами повідомлень. Репозиторій брокера дозволяє працювати з повідомленнями практично будь-якої складності, однак використання спеціалізованого парсеру може виявитися більш ефективним. Прикладом спеціалізованого парсеру можуть служити компоненти для роботи з документами SAP Idoc системи R / 3.

Взаємодія з системами workflow

Системи workflow дозволяють відокремлювати середу моделювання, середу управління і контролю за виконанням ділових процесів від внутрішньої закодованої логіки прикладних систем, що дозволяє гнучко змінювати ділові процеси відповідно до змін і розвитком бізнесу. Такі системи розраховані на виконання процесів з довгим часом життя, зупинками і відновленням процесу, участю людей-користувачів і додатків-автоматів. Інтеграційні брокери більше орієнтовані на автоматичну обробку повідомлень і документів з коротким часом виконання.

Системи workflow і брокери повідомлень доповнюють один одного, поєднуючи функції управління бізнес-процесами з функціями трансформації і розподілу даних. Наприклад, для будь-якого бізнес-процесу необхідно зробити запит до будь-якої зовнішньої системі або виконати зовнішню функцію. Подібний зовнішній виклик в WebSphere MQWorkflow реалізується у вигляді XML-повідомлення, яке потім може бути перетворено інтеграційним брокером в повідомлення формату зовнішньої системи або оброблено на самому брокера. Результат повертається в систему управління бізнес-процесами WebSphere MQWorkflow і буде сприйнятий, як закінчення чергової стадії бізнес процесу. В іншому випадку повідомлення від прикладної системи, що пройшло через брокер, може викликати старт бізнес-процесу під контролем WebSphere MQWorkflow. При цьому система управління бізнес-процесами може реалізувати в інтересах інтеграційного брокера складну логіку обробки, що міститься в моделі бізнес-процесу.

Висновок

Неінтегрованість прикладних систем є спільною і гострою проблемою застосування ІТ з точки зору бізнесу. Одночасно, в інформаційній індустрії спостерігається швидкий розвиток технологій, що представляють нові функції, і це швидкий розвиток породжує дорогий і ризикований спокуса повної заміни існуючих систем і технологій новими. Розумною альтернативою таких радикальних підходів є інтеграція існуючих і нових додатків в єдину середу обміну.

В основі інтеграційного рішення від IBM рішення лежить базисна технологія черг повідомлень WebSphere MQ [4] - асинхронна система передачі даних з механізмами гарантованої доставки. Поверх базової структури WebSphere MQ можуть бути розміщені інші програмні компоненти для обробки інформації, що передається та управління складними бізнес-процесами.

література
  1. WebSphere MQ Integrator. Programming Guide.
  2. MQSeries Integrator Version 2 Technical White Paper.
  3. WebSphere MQ Integrator. ESQL Reference.
  4. Микола Ігнатович, "IBM MQSeries: архітектура системи черг повідомлень" . // Відкриті системи, 1999, № 9-10.

Микола Ігнатович ( [email protected] ) - фахівець компанії IBM EastEuropeAsia (Москва).