Интегриране на информационни системи с помощта на корпоративната сервизна шина (ESB)

Сред добрите практики за интегриране на сложни информационни системи е изграждането на логически витрини за данни, както и създаването на централизирани инфраструктури за обмен на данни с помощта на MDM системи и корпоративни сервизни шини (ESB, Enterprise Service Bus). Нашите решения, включително системата ArchiGraph.MDM, са подходящи за използване като част от операционната система със специално предназначение Astra Linux Special Edition, както и Alt Linux.

Защо е необходима интеграционна шина?

Всяка компания, която използва повече от два софтуерни продукта, които работят с припокриващи се набори от информация, знае каква е цената на липсата на комуникация между тях. Несинхронизираните списъци с клиенти или продуктови гами и друга информация между ERP, CRM и други корпоративни приложения водят до постоянна загуба на време, ресурси и репутация на компанията. Единственото правилно решение на този проблем е внедряването на корпоративна сервизна шина (ESB) във връзка със система за управление на основни данни (MDM).

Решенията, базирани на редовно качване и трансформиране на информация (ETL), ориентирана към услуги архитектура (SOA), предоставят само временно решение на подобни проблеми, имат много недостатъци и ограничават растежа на ИТ инфраструктурата.

Внедряване на интеграционната шина

При въвеждането на интеграционна шина възниква задачата за картографиране (сравняване) на структурата на информацията за едни и същи обекти, присъстващи в различни информационни системи. Необходимо е да се реши този проблем чрез създаване на общ, неутрален по отношение на всяко приложение, информационен модел. Такъв модел може да бъде реализиран най-ефективно с помощта на семантични технологии. За оптимални резултати от внедряването е необходим професионален архитект на данни, който да разработи модела.

Важна част от проекта за внедряване е внедряването на конектори (програмни интерфейси) за всички приложения, участващи в обмена на данни. Нашите специалисти имат опит в разработването и свързването на конектори за широка гама софтуер на различни платформи.

Изпълняваме интеграционни проекти заедно с партньори, базирани на IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse и Business Semantics bus решения.

Често проект за внедряване на интеграционна шина се изпълнява като част от общ реинженеринг на корпоративната информационна архитектура.

2005 г

Enterprise Service Bus - "бюджетен" подход за решаване на интеграционни проблеми

Изготвил: по материали от чужди сайтове
Превод: Intersoft Lab

Продължавайки да запознаваме читателя с различни подходи към интеграцията, решихме да се съсредоточим върху сравнително нова и много привлекателна технология - корпоративната сервизна шина (Enterprise Service Bus, съкр. ESB).

Какво е Enterprise Service Bus и как се сравнява с Enterprise Application Integration (EAI), обсъдено в предишни броеве на DWH, OLAP и XML Connoisseurs Club Magazine? По традиция първо ще дадем думата на експерти в тази област.

Анализаторите на Gartner определят ESB като нов тип мидълуер, който се интегрира функционалностдруги вече съществуващи типовемеждинна опора. Enterprise Service Bus поддържа уеб услуги чрез внедряване на протокола SOAP (Simple Object Access Protocol) и използване на езика за описание на уеб услуги (WSDL) и спецификацията за универсално описание, откриване и интегриране (UDDI). Универсално описание, откриване и интегриране). Много автобуси за корпоративни услуги поддържат и други комуникационни стилове, включително гарантирана доставка и публикуване и абониране. Услугите, предоставяни от тези автобуси, осигуряват „добавена стойност“, която лекият мидълуер за съобщения няма – те осигуряват проверка на съобщенията, трансформация, базирано на съдържанието маршрутизиране, сигурност, откриване на услуги за ориентирана към услуги архитектура, балансиране на натоварването и регистрация. Някои услуги са вградени в базата на автобуса, други работят в добавки. В допълнение автобусите поддържат XML и други формати на съобщения.

Защо корпоративният сервизен автобус е толкова привлекателен? На първо място, неговата относителна евтиност. Продуктите на ESB обикновено се позиционират като достъпни или както се казва "бюджетни" решения.

Наистина, днес има нарастване на търсенето на интеграционни технологии. И докато по-рано внедряването на продуктите на EAI беше свързано с постигането на стратегически цели и следователно се изплащаше в дългосрочен план, задачите, които в този моменткомпаниите, с които се сблъскват, са тактически по природа и изискват нови подходи. „Съвременните бизнес реалности“ насочиха вниманието към области, в които доставчиците на EAI традиционно са били слаби – трансформация, ориентирано към разработчиците програмиране (като Java) и интеграция с външни технологии. Всичко това "подготви благодатна почва" за появата на нова категория продукти - ESB.

Говорейки за предимствата на автобуса за корпоративни услуги, струва си да цитираме думите на Рой Шулте, вицепрезидент и член на изследователския отдел в Gartner: „Обичайният софтуерсредният слой вече не може да поддържа нови приложения, които използват ориентирана към услуги (Service Oriented Architecture, съкр. SOA) и управлявана от събития архитектура (Event Driven Architecture, съкр. EDA), уеб услуги и управление на бизнес процеси. Това е основната причина, поради която архитектите и мениджърите на информационни системи трябва да използват своите корпоративни информационни инфраструктури с ESB.“

Водещият анализатор на Gartner подчертава групи от доставчици на ESB. Той се позовава на първата група продукти на ESB, които са позиционирани като "бюджетни" интеграционни решения, които са най-подходящи за поддръжка на композитни приложения и SOA. Втората група са продукти, предназначени за пазара на уеб услуги, и накрая, последните софтуер, предоставяйки поддръжка на EDA. Според Рой Шулте пазарът на ESB ще се уплътни през следващите години, воден от нарастващото търсене на уеб услуги и многопротоколни и управлявани от събития решения.

Интересното е, че в редица компании ESB се третира не като категория продукти, а като архитектура. Например в IBM корпоративната сервизна шина се счита за „архитектурен модел“.

По този начин може да се каже, че все още няма ясна дефиниция какво е ESB. Всъщност дискусията се върти около два въпроса:

  1. Дали ESB е архитектура (и такава, която дори не трябва да бъде стандартизирана), „едностранен подход“ или самостоятелен продукт.

    Въпреки че е от полза за редица доставчици, които в момента нямат готови решения, да говорят за Enterprise Service Bus като архитектура, текущата ситуация е такава, че клиентите се нуждаят от техните продукти, за да предлагат ESB функционалност. Следователно трябва да очакваме увеличаване на броя на доставчиците, предлагащи ESB възможности през следващите две години.

  2. Какво е мястото и бъдещето на продуктите на ESB, а именно корпоративната сервизна шина е по-усъвършенствана система за опашка за съобщения, която осигурява проста XML трансформация, както и маршрутизиране и изпращане на съобщения, или ще позволи използването на адаптери за приложения, автоматизация и моделиране на бизнес процеси ESB ще бъде успешно заменен от EAI.

Към момента няма категорични отговори на тези въпроси.

Струва си обаче да се подчертае, че макар да няма яснота относно Enterprise Service Bus, е ясно, че отвореният стандартен подход на ESB може значително да намали разходите за придобиване и внедряване.

Имайте предвид, че думата "услуга" в термина "корпоративен сервизен автобус" е централна. По този начин анализаторите на Forrester Research разглеждат ESB като "слой от междинен софтуер, с който можете да получите достъп до набор от основни (многократно използвани) бизнес услуги." SOA позволява повечето функционалности да бъдат изложени като "услуга" в корпоративна сервизна шина, която препраща, трансформира и валидира входни и изходни данни в XML форматполучени от тези услуги.

ESB и XML

Би било несправедливо, ако не подчертаем специалната роля на XML - XML ​​е основата за интеграция. Ако някой приеме, че XML е повече "азбука", отколкото просто език, става ясно, че пълната интеграция изисква оркестриране на бизнес процеси, управление на XML трансформация и валидиране и препращане на XML съобщения в цялата организация. Всички тези функционалности формират основата на Enterprise Service Bus.

XML може да предостави цялостно представяне на набор от данни. Популярността на този език може да се дължи на неговата висока гъвкавост и разширяемост. Всъщност XML синтаксисът ви позволява да модернизирате и разработвате специализирани XML схеми за обработка на различни данни.

В същото време бързото нарастване на обема на прехвърляните данни създава сериозни затруднения за функционирането на корпоративната информационна структура. И така, първите интеграционни проекти, които използваха възможностите на XML, бяха "живо" доказателство за обещанието на този език, но сега има определени проблеми с увеличаването на броя, размера и сложността на XML документите. По-долу са основните причини за съществуващите трудности (недостатъчна мащабируемост):

  • Анализ на целия документ: Обикновено искате да анализирате цели документи, дори ако само част от тях трябва да бъде извлечена за маршрутизиране и филтриране. Ако документите станат големи, времето за изчакване се увеличава.
  • Повторно сканиране. Документите често се анализират повторно - на всеки етап от бизнес процеса, с други думи, едни и същи документи могат да бъдат сканирани няколко пъти. Тъй като тази практика е изключително ресурсоемка, производителността и пропускателната способност се влошават.
  • Еднонишково изпълнение. В този случай следващата стъпка на обработка не може да бъде стартирана, докато текущата не бъде завършена; в резултат на това забавянето се увеличава, тъй като целият процес зависи от най-бавната стъпка.

За да се преодолее липсата на мащабируемост, се препоръчва да се използва архитектура за обработка, която поддържа следните функции:

  • Поток на документи - Гарантира, че XML документите се обработват при пристигането на всеки елемент, т.е. осигурява ниска латентност. Този подход дава възможност да се обработват големи съобщения толкова продуктивно, колкото и малките.
  • Селективна обработка, която постига много значително подобрение на производителността чрез обработка само на подходящи фрагменти, а не на целия XML документ.
  • Многонишкова обработка, при която процесорът управлява подравняването на последователни стъпки в канал, паралелното изпълнение на отделни стъпки и балансирането на натоварването на идентични стъпки при обработка на множество XML фрагменти.
  • Единственото сканиране, при което вместо няколко повторни четения на структурата на един и същи документ от самото начало, всички необходими фрагменти се извличат с едно прехвърляне.

Горните функции могат да бъдат реализирани с помощта на Enterprise Service Bus - и без специално кодиране и конфигуриране.

Каква е разликата между корпоративна сервизна шина (ESB) и брокери на съобщения (като RabbitMQ)?

В резултат на това проблемът с незадоволителното представяне може да бъде решен.

Заключение

Съдейки по публикации в чуждестранни интернет издания и оценки на анализатори от водещи изследователски компании, корпоративният сервизен автобус вече не е просто нова технологияс голям потенциал. Всъщност Gartner прогнозира, че през 2005 г. повечето големи компании ще използват ESB. IDC вярва, че автобусът за корпоративни услуги трябва да "революционизира" Информационни технологиии позволяват гъвкава и мащабируема разпределена обработка.

Наистина, поддръжката на отворени стандарти (и особено XML) предоставя евтино, но ефективно решение и гарантира бърза възвръщаемост на инвестицията, т.е. висока оценка ROI. Както отбелязва Стив Крагс, вицепрезидент на консорциума за интеграция, „ESB е основата за интеграция, осигурява гъвкава и адаптивна среда, която позволява ползотворно, успешно и систематично изпълнение на интеграционни проекти.“

И все пак, неяснотата с неяснотата на термина "корпоративен сервизен автобус" все още остава. Днес ESB означава всяка технология, необходима за прилагане на SOA. Точно на тази гледна точка се придържа ZapThink, компания, специализирана в разработката и прилагането на сервизно-ориентирана архитектура. В това отношение анализаторите на ZapThink предупреждават, че ако през 2005 г. не бъде разработена истинска и конкретна дефиниция на корпоративна сервизна шина, терминът ESB "завинаги ще напусне лексикона на SOA". Що се отнася до самата SOA, тя ще бъде обсъдена в следващата статия.

Публикации

  1. Бет Голд-Бърнщайн Критичен ли е ESB за вашето бъдеще?
  2. Найджъл Томас и Уорън Бъкли Възход на ESB.
  3. Материали, публикувани на сайта на Интеграционен консорциум.

Какво е ESB и SOA¶

Отлично описание на мисленето система-на-система
Ник Коглан, основен разработчик на Python

предлага се и в Катала, Deutsch, Английски, френски, Италиано, Холандия, португалци, Турскии 中文 .

Абревиатурата ESB и свързаната с нея SOA могат да бъдат източник на объркване. ESB означава Enterprise Service Bus. SOA - Service Oriented Architecture.

Тези имена означават малко, така че следното е повече пълна информацияна разбираем език, без излишна корпоративна лексика.

Цялата истина¶

Нека си представим какво се случва, когато влезете в предния край на приложението на вашата банка:

  1. Вашето име се показва
  2. Показва се салдото по вашата сметка
  3. Показване на вашите кредитни и дебитни карти
  4. Може да има списък на вашите взаимни фондове
  5. Освен това получавате списък с предварително изчислени заеми, които може да ви заинтересуват

С голяма степен на вероятност можем да кажем, че всички тези части от информацията принадлежат на различни системии приложения, всяко от които предоставя данни чрез някакъв интерфейс (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV или всеки друг):

  1. от CRM, работещ с Linux и Oracle
  2. от система COBOL, работеща на z/OS мейнфрейм
  3. те казват, че тази информация идва от мейнфрейм система, но тези момчета са твърде мълчаливи, за да кажат нещо друго, освен че предпочитат CSV пред всичко останало
  4. от комбинация от PHP и Ruby, работещи на Windows
  5. от PostgreSQL, Python и Java, работещи на Linux и Solaris

Въпросът е как можете да накарате приложението за интерфейс да говори със системи 1-5? Е, няма начин.

Това е фундаментално, за да се гарантира, че такива среди могат да надхвърлят множество системи. Не ги принуждавате да общуват директно един с друг.

В диаграмата по-долу всяко повикване към услуга, която се предоставя от друга система, е представено от линия с различна дебелина и стил:

Забележете, че дори не показахме процеси на високо ниво (App1 извиква App2 и App3 или App5 в зависимост от това дали предишният отговор от App6 е бил успешен, така че App4 по-късно да може да вземе данните, генерирани от App2, но само ако App1 не го забранява и т.н.).

Освен това имайте предвид, че не говорим за сървъри - всяка от системите може да работи на 10 физически сървъра, така че поне 60 физически компонента ще комуникират помежду си.

Някои проблеми обаче стават очевидни.

Как да разделим интерфейсите? Как да планирате изтегляне? Как координирате актуализациите или планирания престой, когато всяко приложение се управлява от различни екипи за разработка, доставчици или отдели и половината от първоначалните разработчици вече са напуснали компанията?

Ако смятате, че можете да управлявате 6 приложения, какво ще кажете за 30?

Можете ли да се справите с 400? А от 2000 г. насам? Всяко приложение може да бъде своя собствена уникална екосистема, изискваща дузина сървъри или други устройства, за да работят, така че това са 20 000 движещи се части, разпръснати по континенти с всякакви технически и културни граници. И всички тези части постоянно и нон-стоп искат да обменят съобщения през цялото време без никакви прекъсвания. (Ще ви спестим схемата.)

Има страхотно име за тази ситуация - бъркотия.

Как можете да поправите ситуацията?¶

Първата стъпка е да осъзнаете, че ситуацията е извън контрол. Това ви позволява да търсите решение, без да изпитвате силно чувство за вина. Е, случи се, не знаехте как да го направите по-добре, но има шанс всичко това да бъде поправено.

Това може да доведе до организационни промени в начина, по който подхождаме към ИТ, но друга стъпка е да запомним, че системите и приложенията не са само за споделяне на данни. Те са предназначени да поддържат бизнес процеси, независимо от самия бизнес, било то банкиране, аудио записи, радарни устройства и каквото и да е.

Когато ясно дефинирате тези две точки за себе си, можете да започнете да проектирате или препроектирате вашите системи около услугите.

Услугата е нещо интересно, многократно използваемо и атомарно, което се предоставя от една система на други приложения, които искат да го използват, но услугата никога не е директно изложена едно към едно. Това е най-краткото и смислено описание от всички възможни.

Ако дадена функционалност на системата отговаря на тези три изисквания:

  • азинтересно (интересно)
  • Рмногократно използваем
  • Атомичен (атомен)

тогава има голям шанс системата да може и трябва да бъде изложена на други системи като услуга, но никога да не се свързва директно.

Нека обсъдим подхода на IRA с няколко примера.

Променлива Бележки
Околен свят Електрическа компания CRM система
Функционалност Върнете списък с клиенти, които са били активни на портала за самообслужване през третото тримесечие на 2012 г.
Интересно е? Да, достатъчно интересно. Това може да се използва за генериране на всякакви полезни отчети и статистики.
Възможно е Не, не толкова. Въпреки че това ви позволява да създавате
многократно конструкции на високо ниво като статистика за цялата година,
използвам? ясно е, че това няма да ни трябва през 2018 г.
Атомно ли е? Вероятно да.

Ако вече има подобни услуги за други тримесечия, тогава можете да видите цялата година.
Как да направите IRA от това?
  • Принудително получаване на произволни начални и крайни дати на периода, вместо да се указва само тримесечието.
  • Принуждавайте да получавате произволни приложения, а не само портала. Дават възможност за указване на приложението да получава информация като входен параметър.
Променлива Бележки
Околен свят сайт за електронна търговия
Функционалност Връща всяка част от информацията, която някога е била събирана за посочения потребител
Интересно е? Като цяло, да. Ако имате достъп до цялото, винаги можете да изберете това, от което се нуждаете.
Възможно е Колкото и да е странно, всъщност не. Ще има само няколко
многократно заявки, ако има, които ще се интересуват
използвам? използвайте абсолютно всяка информация.
Атомно ли е? Определено не. Това чудовище от функционалност е предназначено да бъде логично съставено от десетки по-малки части.
Как да направите IRA от това?
  • Разделете на няколко по-малки части. Помислете какво описва купувача – има адреси, телефонни номера, любими продукти, предпочитани методи за връзка с тях и т.н. Всеки от тези артикули трябва да се превърне в самостоятелна услуга.
  • Използвайте ESB за създаване на съставни услуги от атомарни.
Променлива Бележки
Околен свят Всяка CRM система, навсякъде
Функционалност Актуализирайте колоната CUST_AR_ZN в таблицата C_NAZ_AJ, след като някой е създал акаунт
Интересно е? Абсолютно безинтересно. Това е вътрешна функция на CRM системата. Никой с здрав ум не иска да се занимава с функционалност на такова ниско ниво.
Възможно е Да, вероятно. Сметкаможе да се създаде чрез
многократно множество канали, така че изглежда, че е нещо множество
използвам? използвани.
Атомно ли е? Изглежда да. Това е проста актуализация на една колона в таблица.
Как да направим
тази ИРА? Дори не се опитвайте да правите услуга от това. Не е интересно. Никой не иска да мисли за конкретни колони и таблици в една система. Това е сложна част от CRM система и въпреки че е многократно използваема и атомарна, не си струва да се изгради услуга от нея. Това е ваше и CRM, ваша отговорност е да мислите за това, не принуждавайте другите да го понасят също
Променлива Бележки
Околен свят Мобилен оператор
Функционалност Попълване на предплатена комуникационна карта при таксуване
Интересно е? Изключително. Всеки иска да го използва чрез текстови съобщения, IVR, IM, портали, подаръчни картии т.н.
Възможно е да Може да участва в много високо ниво
многократно процеси.
използвам?
Атомно ли е? Да, от гледна точка на приложението за разговори, картата може да се презарежда или не. Фактът, че таксуването прилага това чрез поредица от стъпки, не е важен. От бизнес гледна точка това е атомно, това е неделима услуга, предоставяна чрез таксуване.
Как да направим Това вече е ИРА.
тази ИРА?

Ако сте правили дори малко програмиране през последните 50 години, ще стане очевидно за вас, че предоставянето на услуга е като предоставяне на API в една част от кода за друга. Единствената разлика е, че не работите с подмодули на една система, работите на ниво цяла среда от отделни системи.

Наличие на услуги в ESB и SOA¶

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

Сега работата на ESB е да предоставя и извиква интегрирани системни услуги. По този начин в повечето случаи трябва да се дефинира само един метод за достъп, един интерфейс между всяка система и ESB.

Така че, ако, както в диаграмата по-горе, имате 8 системи - тогава имате 16 интерфейса (по един във всяка посока) за създаване, поддръжка, управление и предоставяне.

Без ESB бихте имали 56 интерфейса за създаване и управление (ако приемем, че всяка система говори с всяка друга).

Без допълнителни 40 интерфейса означава по-малко загубено време и повече спестени пари. Това е една от причините вашите петъци да са по-малко стресиращи.

Този факт сам по себе си трябва да ви подтикне да обмислите внедряването на ESB.

Ако една от системите бъде пренаписана, прехвърлена на друг собственик, разделена между отдели или доставчици, тогава задачата на момчетата от ESB ще бъде да направят съответните промени. Никоя от другите системи дори няма да забележи това, тъй като техният интерфейс с ESB ще бъде недокоснат.

След като започнете да дишате IRA услуги редовно, можете да започнете да мислите за комбинирани услуги.

Спомняте ли си услугата „дайте-ми-каквото-можете-да-направите-за-този-клиент“ по-горе?

Не беше добра идея да създадете такъв, но понякога ще се сблъскате с клиентски приложения, които трябва да събират информация. Момчетата от ESB ще отговарят за това и тяхната работа ще бъде да изберат най-добрите атомарни услуги за изграждане на съставна услуга за тази конкретна клиентска система, изискваща този конкретен набор от съставни данни.

С течение на времето цялата организация ще започне да осъзнава, че вече не става дума за таблици на бази данни, файлове, пакети, функции, подпрограми или записи. Сега говорим за архитектура, съсредоточена около интересни, многократно използвани и атомарни услуги, предоставяни от ESB приложения.

Хората вече няма да мислят, че приложенията и системите си изпращат съобщения. Те ще гледат на ESB като на едно гише към интересни услуги, които техните собствени системи могат да използват. И дори няма да проверят кой какво предоставя, техните системи ще се занимават само с ESB.

Ще отнеме време, търпение и координирани усилия, но е изпълнимо.

Но внимавайте…¶

Повечето По най-добрия начинунищожете цялата концепция на SOA - внедрите ESB и очаквайте проблемите да се оправят сами. Въпреки че е страхотна идея, за съжаление просто внедряването на ESB няма да е достатъчно.

В най-добрия случай опитът да се скрие нещо под килима, както е показано на диаграмата по-долу, няма да доведе до нищо:

Вашите ИТ момчета ще намразят системата и докато мениджърите първоначално ще толерират ESB като ново решение, в крайна сметка тя ще се превърне в посмешище. „Какво, това същият нов сребърен куршум ли е? Хахаха."

Такива последствия са неизбежни, ако ESB не е част от по-голям план за развитие.

И така, ESB само за банки и други подобни ли е?¶

Въобще не. то добро решениевъв всяка ситуация, която изисква координирана работа на няколко източника на данни и няколко метода за достъп, за да се постигне интересен резултат.

Например, задачата за събиране на най-новите температурни показания и публикуването им в множество канали, като имейл предупреждения и приложения за iPhone, е подходяща за платформа за интеграция.

Периодичната проверка и наблюдение на работата на всички екземпляри на критично приложение и ако не всички от тях работят, стартирането на конфигуриран скрипт и изпращането на текстово съобщение до администраторите също е страхотно.

Всичко, което трябва да бъде интегрирано в ясна, добре дефинирана среда, вероятно е подходящо за ESB услуга. Но, както винаги, решението дали нещо наистина е подходящо за интегриране идва с опита.

корпоративен служебен автобус

Разбира се, екипът на Zato може да помогне.

Но чух, че SOA е XML, SOAP и уеб услуги¶

Да, някои хора биха искали да повярвате в това.

Ако хората или доставчиците, с които сте работили, са изпратили BASE64-кодиран CSV файл в защитено от SAML2 SOAP съобщение, тогава е разбираемо защо сте получили това впечатление.

XML, SOAP и уеб услугите имат своите случаи на употреба, но както всичко останало, те могат да бъдат злоупотребени.

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

Ако един архитект проектира красива сграда, той не може да повлияе много на цвета на интериора.

Така че не, SOA не е XML, SOAP и уеб услуги. Могат да се използват, но са само част, а не основа.

Можете да насочите изгубени колеги към тази статия, за да разберат какво е SOA.

Освен това¶

Тази глава обхваща само самите основи, но въпреки това трябва да осигури солидно разбиране за това как трябва да изглеждат ESB и SOA и какво е необходимо, за да бъдат успешни.

Други теми, които не са обхванати тук, включват (но не се ограничават до):

  • Как да получите подкрепа от мениджърите за въвеждане на ESB
  • Как да съберем SOA архитекти и аналитични екипи
  • Представяне на Canonical Data Model (CDM) в организация
  • Ключови показатели за ефективност (KPI) - сега, когато имате общ и унифициран метод за предоставяне на услуги между системите, трябва да започнете да наблюдавате и анализирате какво всъщност ви се предоставя
  • Управление на бизнес процеси (BPM) – как и кога да изберете BPM платформа за управление на услуги (отговорът не е твърде скоро, първо се научете как да изграждате хубави и полезни услуги)
  • Какво да правим със системи без API? Например, ако ESB получи директен достъп до своите бази данни (отговорът е различен, няма златно правило)

И така, какво е Zato?¶

Zato е ESB и сървър за приложения, написан на Python и може да се използва за изграждане на междинен софтуер и бекенд системи. Този софтуер е отворен програмен кодс търговска и обществена подкрепа. А Python е език за програмиране, известен със своята простота и ефективност.

Използването на Python и Zato ви позволява да увеличите производителността и да губите по-малко време.

Зато беше написано прагматици за прагматици. Това не е поредната набързо изградена система от доставчик в резултат на шума за ESB/SOA.

Всъщност Zato е изграден от практически опит в "гасенето на пожари", причинени от такива системи. Всъщност авторите на Zato са прекарали толкова много време в борба с такива среди, че са станали практически имунизирани срещу всякакви пожари.

Това е ковачницата, от която Zato се появи на света и следователно може да предложи производителност и лекота на използване, които не се срещат в други подобни решения.

Ще се видим в тук!

(Enterprise Service Bus) е предназначен за изграждане на разпределен информационен ландшафт на предприятие. Софтуеросигурява взаимодействието на всички интегрирани приложения в един център, комбинирайки съществуващи източници на информация и осигурявайки централизиран обмен на данни между различни информационни системи.

Enterprise Service Data Bus DATAREON ESBе ефективно средство за осигуряване на стабилност и пълнота на обмена на информация, повишаване на общата производителност на информационната система и намаляване на разходите за труд за нейното администриране.

Enterprise Service Bus

Софтуер DATAREON ESBофициално включен в единния регистър на руските програми за електроника компютрии бази данни, които могат да бъдат закупени от държавни и общински институции (https://reestr.minsvyaz.ru/).

За интегриране на 2-3 информационни системи в малки фирми, DATAREON предлага софтуерен продукт, базиран на DATAREON ESB - DATAREON MQ.

Функционалност на DATAREON ESB

Задачи, решени с помощта на корпоративната сервизна шина за данни

  • Трансфер на даннимежду различни информационни системи (маршрутизирани или от точка до точка)
  • Формиране на единно информационно пространствов разнородни среди
  • Изграждане на разпределена система на базата на събитиен моделв следните опции:
    • изграждане на приложения с бизнес процеси от край до край, базирани на модела на събитията;
    • създаване на система със синхронизация на бизнес приложения в различни информационни системи
  • Касова бележка мащабируема контролна архитектураниво предприятие/холдинг
  • Разгръщане системи за обмен на даннина транспортния слой и на ниво бизнес логика
  • Делегиране на задачата за изграждане на информационни потоцианалитични отдели
  • Намаляване на общата сложност на интеграционната схемаи намаляване на изискването за честотна лентаканали
  • Повишаване на общата стабилностслой за транспортиране на данни
  • Намалени транзакционни разходипри обмен на данни между различни отдели
  • Намалени общи разходиподдръжка и поддръжка на информационната система.

Предимства на DATAREON ESB Enterprise Service Bus

  • Бърза интеграция
  • Висока надеждност
  • Възможност за повторно използване на ресурси

), по-рано известен като Axelot Datareon ESB, е предназначен да изгради разпределена корпоративна информационна среда. Софтуерният продукт осигурява взаимодействието на всички интегрирани приложения в един център, комбинирайки съществуващи източници на информация и осигурявайки централизиран обмен на данни между различните информационни системи.

Datareon ESB Enterprise Data Service Bus е средство за осигуряване на стабилност и пълнота на обмена на информация, повишаване на цялостната производителност на информационната система и намаляване на разходите за труд за нейното администриране.

Програмният продукт Datareon ESB е официално включен в единния регистър на руските програми за електронни компютри и бази данни, които могат да бъдат закупени от държавни и общински институции.

Функционалност

  • Поддръжка на различни стандарти и интеграционни сценарии
  • Централизирано управление на интеграционния пейзаж с екосистемата Eclipse
  • Трансформация на данни (алгоритми за многоетапна трансформация на данни с контрол на различни условия)
  • Прехвърляне на данни от всякакъв размер (вертикално и хоризонтално мащабиране)
  • Лесна интеграция с продукти, базирани на платформата 1C:Enterprise 8
  • Осигуряване на сигурен трансфер на данни
  • Диагностика и мониторинг на състоянието на цялата мрежа за данни

Задачи за решаване

  • Пренос на данни между различни информационни системи (с маршрутизиране или от точка до точка)
  • Формиране на единно информационно пространство в разнородни среди
  • Изграждане на разпределена система на базата на модела на събитието в следните опции:
    • изграждане на приложения с бизнес процеси от край до край, базирани на модела на събитията;
    • създаване на система със синхронизация на бизнес приложения в различни информационни системи
  • Получаване на мащабируема архитектура за управление на ниво предприятие / холдинг
  • Внедряване на система за обмен на данни на ниво транспорт и на ниво бизнес логика
  • Делегиране на задачата за изграждане на информационни потоци на аналитичните отдели
  • Намаляване на общата сложност на интеграционната схема и намаляване на изискването за честотна лента на каналите
  • Повишаване на общата стабилност на слоя за транспортиране на данни
  • Намаляване на транзакционните разходи при обмен на данни между различни отдели

2017

Axelot Datareon ESB 2.1.0.0

Решението AXELOT Datareon ESB беше включено в списъка на компетентностите Gold Application Development – ​​факт, потвърждаващ високото качество на продукта и неговата съвместимост с продуктите на Microsoft.

AXELOT Datareon ESB предоставя редица ключови предимства за бизнеса:

  • Възможност за интеграция;
  • Надеждност и повторно използване на ресурсите;
  • Получаване на мащабируема архитектура за управление на ниво предприятие / холдинг;
  • Делегиране на задачата за изграждане на информационни потоци към аналитичните отдели;
  • Намаляване на общата сложност на интеграционната схема и намаляване на изискването за честотна лента на канала;
  • Повишаване на общата стабилност на транспортния слой на пренос на данни;
  • Намаляване на транзакционните разходи при обмен на данни между различни отдели;
  • Намаляване на общите разходи за поддръжка и поддръжка на информационната система.

Основните характеристики на системата:

  • Голям брой конектори различни системи: 1С:Enterprise 8, SOAP услуги, REST услуги, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter и други;
  • Плъгин механизъм за самостоятелно развитие на конектори;
  • Поддръжка на различни езици и технологии за програмиране при разработване на сценарии за взаимодействие: 1C:Enterprise 8, JavaScript, T-SQL;
  • Създаване на многоетапни сценарии за преобразуване на данни с помощта на механизми за визуално картографиране и произволни XSLT трансформации;
  • Работи с различни форматиданни (XML, JSON, XLS, DBF, CSV, Base64 и други);
  • Статично и динамично маршрутизиране на информационни пакети;
  • Висока скорост на взаимодействие и устойчивост на грешки: намалени изисквания за честотна лента на мрежата, балансиране на натоварването, изолиране на информационни домейни, възможност за наблюдение на състоянието на интеграционните възли;
  • Поддръжка на модел на събития, синхронни и асинхронни повиквания, гарантирана доставка;
  • Промяна на сценарии за интеграция на абонатни системи (механизми за разтоварване/зареждане, трансформация и маршрутизиране) в "горещ" режим без необходимост от спирането им (включително конфигурации на платформата 1C:Enterprise 8);
  • Диагностика и мониторинг на всички интеграционни процеси, отстраняване на грешки и проследяване на информационни пакети.

Особено внимание се обръща на интегрирането на приложения на платформата 1C:Enterprise 8. Доставката включва специална подсистема, която е вградена във всяка стандартна конфигурация на платформата 1C:Enterprise 8 и осигурява всички необходими механизми за бърза и удобна настройка и администриране на интеграция. AXELOT: ESB Service Data Bus взаимодейства с конфигурацията на платформата 1C:Enterprise 8 чрез SOAP и REST услуги.

Сървърните компоненти "AXELOT: ESB Service Data Bus" са разработени на C++. Администрирането и конфигурирането на "AXELOT: ESB Service Data Bus" се извършва в средата за разработка Eclipse и може да се извършва във връзка с разработването на системи на платформата "1C: Enterprise 8" в "1C: Enterprise Development Tools". "AXELOT: ESB Service Data Bus" е мултиплатформен и поддържа Операционна система MS Windows и Linux.

AXELOT Datareon ESB е изцяло руска разработка и е в процес на включване в единния регистър на руските програми за електронни компютри и бази данни, които могат да се закупуват от държавни и общински институции за решаване на определени проблеми.

По мое мнение има два подхода за изграждане на корпоративна интеграционна шина:


  • "от интегрируеми системи";

  • "от реализирани процеси".

Нека разгледаме тези подходи по-подробно.

Подход "от интегрируеми системи"

В този случай интеграционната шина се разглежда като вид транспорт, който извършва маршрутизиране и договаряне на протоколи за съобщения. Всички съобщения преминават през веригата: входен канал на адаптера на изходната система -> рутер -> изходен канал на приемната система. Типът комуникация между тези компоненти и специфичните технологии зависи от това дали съобщенията, идващи от една изходна система, могат да имат множество целеви системи, от очакваното натоварване и подход за гарантиране на целостта на данните (използване на обща транзакция за всички изходни системи или данните се прехвърлят към всяка система източник в нейната транзакция).

  1. Зависимост от системи, а не типове съобщения. Обикновено броят на интегрираните системи е няколко пъти по-малък от броя на предаваните видове съобщения.

  2. Лесно свързване на нови приемни системи: за да свържете нова приемна система, достатъчно е да въведете данните в таблицата за маршрутизиране.

  3. Лесно внедряване на системата за мониторинг на интегрираното решение: данните за системата за мониторинг могат да се генерират на едно място - в рутера (този момент обаче може да се приеме само с резерви, тъй като има данни, които се генерират само в адаптери на интегрирани системи).

  4. Лесно решение за поддръжка. Тъй като всички съобщения преминават през един единствен рутер, цялата логика на предаване на съобщения и проследяване на зависимости между съобщенията може да бъде реализирана на едно място – в този рутер.

  5. Споделяне на системата между разработчици. Тъй като ядрото на системата и всички адаптери са независими един от друг (комуникацията се осигурява само чрез специални и описани интерфейси), задачите за тяхното разработване могат да бъдат разделени между програмисти, което позволява паралелизиране на процеса на създаване и внедряване на интеграционно решение.


  1. Решението е приложимо само за внедряване на унифицирана логика за предаване на съобщения, т.е. ако има правила за проследяване на зависимости и трансформация, които са общи за всички или повечето съобщения. Ако различни видовесъобщенията имат напълно различна логика за проследяване на зависимости и управление на обмена, то или ще трябва да бъде преместено към адаптери, което елиминира предимство 4, или изобщо ще бъде невъзможно да се приложи.

  2. Тази схема е подходяща за реализиране на асинхронен обмен. В случай на синхронен или смесен обмен, сложността на изпълнението този подходсе увеличава значително.

  3. Може да възникне влошаване на производителността на решението. Например, ако съобщение трябва да бъде предадено на всяка от приемните системи в отделна транзакция, се изисква разделяне на системата източник, ядрото и приемните системи чрез опашки. Тези опашки могат да се превърнат в тясно място на системата.

Подход "от внедрени процеси"

В този случай се разглежда отделно всеки бизнес процес, при който е необходим обмен на данни между няколко системи. Приспособления за автобуси тази размяна. Събитието, което стартира процеса на обмен, е получаването на съобщение от системата източник. Съобщението, получено от системата източник, се предава на една или няколко системи получатели, като същевременно се изпълняват не само транспортни функции, но също така се наблюдава резултатът от обработката на съобщението и предаденото съобщение се съпоставя с други.

Този подход има следните предимства:


  1. Гъвкавост. Този подход ви позволява да приложите своя собствена, отделна логика за обмен за всеки тип съобщение. Тази логика може да бъде доста нетривиална.

  2. Сложността на изпълнението както на асинхронния, така и на синхронния обмен е приблизително еднаква.

  3. Независимост на нишките, по-точно в този случай е по-правилно да говорим за процеси. Техническите решения, взети по време на изпълнението на един процес на обмен, не влияят върху сложността на изпълнението на друг.

Този подход има следните недостатъци:


  1. Зависимост от видовете съобщения. Обикновено броят на видовете съобщения е многократно по-голям от броя на интегрираните системи. При свързване на нова система източник към шината е необходимо да се маршрутизират съобщенията по типове и да се реализира отделен процес на обмен за всеки тип съобщение.

  2. Ако трябва да се приложи една и съща логика на обмен за няколко типа съобщения, тогава е възможно дублиране на код и/или настройки на шината.

  3. Процесите на предаване на съобщения зависят от системните адаптери и могат да зависят един от друг, както и от обслужващи процеси. Наличието на такива зависимости намалява степента на паралелност на процеса на разработване и внедряване на интеграционно решение. Разработчиците на някои компоненти зависят от резултатите от работата на разработчиците на други компоненти на интеграционното решение.

Изборът на подход се извършва съгласно следния алгоритъм:


  1. Получете списък и описание на интегрирани системи и типове съобщения от анализатори.

  2. Получете от анализатори списък и описание на бизнес процеси, които включват системи, изискващи интеграция.

  3. Ако процесите са тривиални и има много по-малко системи от видовете съобщения, обменът е предимно асинхронен и също така се изисква прехвърляне на едно съобщение към няколко системи, ние избираме първия подход. Вземете решение относно политиката за управление на транзакциите.

  4. Ако процесите предполагат предимно синхронен обмен, докато процесите са сложни, т.е. преминаването на едно съобщение зависи от резултатите от обработката му в приемни системи, тогава избираме втория подход. Друг аргумент в полза на този подход е фактът, че броят на видовете съобщения е сравним с броя на интегрираните системи.

Трябва ясно да се разбере, че тези методи за прилагане не са догма, не е необходимо да се избира само първият подход или само вторият. Те винаги могат да се комбинират, модерни корпоративни сервизни гуми ( ESB) ви позволяват да го направите.

Хареса публикацията -

С тази статия бих искал да отворя цикъл, посветен на IBM WebSphere ESB (наричан по-долу ESB) в контекста на разработката за този продукт. И на първо място ще трябва да се запознаете с технологии от този вид.
Корпоративна сервизна шина (корпоративна сервизна шина) е междинен софтуер, който осигурява централизирано и унифицирано ориентирано към събития изпращане на съобщения между различни информационни системи, базирано на принципите на ориентирана към услугата архитектура.
Разбира се, възможно е, дори и без специален софтуер (може би все пак ще трябва да се разработи нещо общо), да се изгради корпоративна система, базирана на този подход, и това, което се случва в резултат, може да се нарече сервизна шина. Но в продукта на IBM има не само готов апарат за централизирано изпращане на съобщения и контрол на този процес, но и пълен комплектвъзможности за разработване на гъвкави сервизно-ориентирани приложения специално за ESB. В обобщение могат да бъдат подчертани следните характеристики и предимства на IBM WebSphere ESB:

  • Ред и еднородност на архитектурните връзки
  • Централизирано управление
  • Конфигурация на приложението от страна на сървъра
  • Внедряване на технологията Service Component Architecture (SCA) в духа на принципите на сервизно-ориентираната архитектура
  • Протоколна независимост на разработения програмен код
  • Обширни опции за конфигуриране на шини и приложения
В същото време ESB осигурява транзакционен контрол, трансформация на данни, безопасност и гарантирана доставка на съобщения. Достъпът до всички услуги през една точка ви позволява да конфигурирате комуникацията на услугата централно. Можете също така централизирано да управлявате събития на неуспех за групова обработка на грешки.
Класическата топология на асемблиране на ESB е клъстер, който осигурява хоризонтална мащабируемост и толерантност към грешки. Според официалните препоръки увеличаването на броя на членовете на клъстера повишава производителността по-ефективно от увеличаването на капацитета на сървъра в самостоятелна топология. В допълнение, клъстерът може да бъде рестартиран (или част от него може да се повреди), без да спира услугата.
ESB обикновено се използва като сервизен слой в IBM BPM, но може да играе водеща роля в изграждането на модел на взаимодействие. корпоративни системикато мощно устройство за интеграция (което означава ESB като добавка към IBM WebSphere Application Server).
Това всъщност се изисква от ESB, тъй като това е „точка за събиране на услуги“ - ако имате нужда от услуга, която ще работи с други услуги (може би външни), тогава интеграцията между тези услуги е най-логично направена на ESB . За външни или разнородни услуги можете да направите "обвивката" ESB услуга. Нека да илюстрираме малко удобството от използването на "единично жилище" за услуги:

Поръчка
Колкото по-голяма е системата, толкова по-важен е редът и еднообразието в нея. Ако говорим за комплекс от системи на голямо предприятие, то със сигурност може да се нарече система с голям размер. Разбира се, винаги можете да намерите администратор с диаграма на взаимодействието на стотици сървъри в главата си или куп томове несвързана документация за всеки софтуерен модул, който описва с какво и как взаимодейства.


Но е много по-лесно да имате услуга (ESB), която ви позволява да провеждате цялото взаимодействие чрез себе си. С този подход част от архитектурата на взаимодействие във всяка подсистема вече е ясна – няма бъркотия в комуникациите между системи, сървъри и приложения: всичко е свързано с ESB и ESB е свързан с всичко.

Централизирано управление
Винаги е по-удобно да се конфигурират системите централно - независимо дали става въпрос за конфигурация, адаптиране към преместване на сървъра, толерантност към грешки, балансиране на натоварването, обработка на грешки или мониторинг и анализи.


Например, когато премествате сървър на база данни, не е необходимо да влизате в конфигурацията на всички съществуващи сървъри на приложения и по-специално в настройките на конкретни приложения - достатъчно е да имате една променлива на средата в ESB, която определя базата данни адрес и тогава промените ще трябва да се направят само в една точка.
Или ако една от външните системи е била недостъпна за дълго време и нито една заявка към нея не трябва да бъде загубена, можете да използвате услугата за обработка на неуспешни събития, за да „хвърлите“ недоставени съобщения, когато е удобно.
Ако трябва да регулирате броя на едновременните заявки към която и да е система или да наблюдавате тези заявки, анализирайте натоварването, потърсете тесни места - трябва да отидете в центъра за управление на съобщенията - до конзолата на ESB сървъра.

Конфигурация от страна на сървъра
"Едно жилище" за услуги, по отношение на конфигурацията, ви позволява да постигнете няколко полезни цели. Първият е повторното използване на конфигурацията (подобно на повторното използване на код и модул, което е толкова полезно в SOA), защото различни модулии приложенията могат да използват едни и същи параметри за връзка с база данни, ресурси, параметри за удостоверяване, променливи на средата и т.н.


Второ, когато конфигурирате от страна на сървъра, средата на приложението е тази, която може да повлияе до голяма степен, което ви позволява да прехвърляте приложения между различни вериги (тестови и производствени), да настройвате и дори да коригирате грешки, без да правите промени в приложението.

Ако използвате всички тези предимства, приложенията придобиват способността на истински хамелеон – те са толкова гъвкави, че стават част от средата, в която работят, и в същото време носят своята важна функционалност.

Но гъвкавостта на приложенията под IBM WebSphere ESB не се ограничава до средата, в която се изпълняват. Възможностите за развитие имат огромен принос за това. Тъй като системите не само трябва да имат къде да работят, но също така трябва да бъдат разработени и финализирани, тези интересни точки не трябва да се пропускат:

SCA
Тази архитектура се основава на принципа, че даден компонент предоставя своята функционалност като услуга, достъпна за други компоненти. В рамките на един модул компонентите са програмни блокове (java код), които напълно реализират някои функции, описани от съответния интерфейс. Логиката на изпълнение на компонентите се реализира чрез свързването им в структура чрез интерфейси и препратки (Партньорска справка).

Много е удобно да се разработва, проверява, развива, променя и поддържа такава модулна структура. Атомарността на функционалността, внедрена в компонентите, ви позволява да работите с компонентите като цяло, без да слизате до ниво код. От друга страна, това е логично необходимо поради изпълнението на компонентни реализации в транзакционен контекст.
Всеки компонент има интерфейс(и), който осигурява реализация. По този начин, като свържете компонентите заедно, няма нужда да ги познавате вътрешни характеристики– достатъчно е да реализират необходимите интерфейси.
Чрез тази архитектура можете също така да решавате всички задачи, които изискват паралелна работа, без "ръчно" управление на потока (например можете да правите асинхронни извиквания към няколко компонента със забавен отговор).
Компонентите, които не са Java, като типове експортиране и импортиране, ви позволяват да предоставяте услуги за външна употребаили съответно да използвате външни услуги; Компонентът Mediation Flow осигурява достъп на ниско ниво до съобщенията, обменяни от други компоненти, и позволява различни трансформации при работа с разнородни интерфейси.
В допълнение към интерфейсите, IBM бизнес обектната рамка предоставя много полезни функции. Бизнес обектите (BO), представени от xsd схеми, се използват като обекти за трансфер на данни в интерфейси, както между компоненти, така и за комуникация между модули. Те са директно интегрирани, например, в wsdl схемата за описание на уеб услуги. Тоест, например, ако модул "А" предоставя своята функционалност под формата на уеб услуга, за да я използвате, е достатъчно модул "Б" да свърже интерфейса и готовите БО и той ще може да напълно работят с такава услуга, без да създават допълнителни java -обекти за пренос на данни. BO също е удобно да се използва при обмен на данни с базата данни, ако тези данни се използват от други компоненти (това, разбира се, противоречи на модела „DAO“, но елиминира ненужните java обекти и операциите за пренаписване на данни „напред и назад“ ).

Протоколна независимост на програмния код
Както можете да видите, независимостта на кода от протокола се постига чрез използване на компонентите за експортиране и импортиране. Тъй като комуникацията с тези компоненти преминава през интерфейси и препратки, програмен коднапълно независими от протокола, използван за взаимодействие. Същата функционалност може лесно да бъде предоставена на произволен брой поддържани протоколи и на всеки правилните интерфейси. Следващата фигура показва как да добавите експорт със SCA обвързване към bean, който вече излага своя интерфейс като HTTP, JMS и уеб услуга.


Предимствата са очевидни – гъвкавост, многофункционалност, повторно използване на кода, скорост на разработка и модификация.
Между другото, SCA свързването използва специален протокол и е предназначено за комуникация между модули в рамките на един и същи сървър/клъстер. Комуникацията чрез това свързване изисква по-малко ресурси и е по-бърза от другите протоколи.

Конфигурация
Конфигурирането на сървъра и приложението се извършва чрез IBM конзолата на сървъра.
ESB, подобно на IBM WebSphere като цяло, има доста специфични функции и артефакти. Например, когато използвате едно и също импортиране и експортиране, можете да конфигурирате крайните точки на съответните услуги в движение. За извиквания на услуги можете да конфигурирате набори от правила с различни правила (например можете да инсталирате поддръжка за механизма WS-AT, който ви позволява да извиквате уеб услуга в същата транзакция, в която работи клиентът; но транзакционността вече е тема за пълна статия), задаване на параметри за удостоверяване, свързване на сертификати и др.
Чрез конфигурирането можете да настроите някои механизми за автоматична реакция при изключителни ситуации (например автоматично повторение на изпълнението на компонента в случай на грешки). Можете да настроите проследяване на компоненти в движение или да промените нивата на регистриране. Налична е и услуга за управление на събития при повреда, която може съзнателно да се използва за групова обработка на грешки.
И, разбира се, можете да конфигурирате много други неща според спецификацията на Java2EE, която е внедрена, понякога доста стриктно, в IBM Application Server.

Всичко по-горе потвърждава, че ESB е удобен, мощен и гъвкав интеграционен апарат, макар и не винаги лесен за научаване. В бъдеще просто трябва да се научите как да го използвате.

В статията са използвани следните изображения:

Лично съм запознат със SOA от 10 години, през това време разработих ясна асоциативна верига: основата на SOA е шината за данни, добре, тъй като шината за данни, тогава говорим за интеграционни проекти.

Няма да разбърквам историята, всички помним как се разви интеграцията навремето: дълъг и болезнен път от концепцията от точка до точка до шина със специален модел на данни в интеграционния слой. Днес вече говорим за интеграционния продукт Neoflex Integra, който има аналог на руски пазарвсе още няма банкова автоматизация, че началният етап на анализ може да бъде значително намален и в същото време веднага да се оцени резултатът от бъдещ интеграционен проект.

Neoflex Integra се появи след 450-ия или дори 455-ия интеграционен проект, осъществен в банката. Трудно е да се определи точно. Но ние се опитахме да изчислим човекодните, посветени на интеграционната практика от нашите служители, и се оказаха приблизително 137 години. Интеграцията винаги е била една от основните области на работа на Neoflex, така че не бива да се изненадвате от такава цифра. През това време успяхме да разберем две неща. Първо, пейзажите в кредитните институции могат да бъдат класифицирани. Второ, има много общо между интеграционните проекти, поне на етапа на анализ. Ние отделихме основата под формата на общ каноничен модел, съдържащ приложни обекти и връзки между тях, комбинирайки атомарни услуги в бизнес процеси в областите на дейност на финансова организация. Изглежда фантастично, но сега можем да дойдем в банката с набор от готови „детайли“ и да ги използваме, за да формираме бъдещ интеграционен модел. Neoflex Integra е нов продукт, обявихме го в мартенския брой на The Retail Finance. Но днес вече можем да кажем, че това ще позволи да се намали срокът на изпълнение на интеграционния проект с около една четвърт, освен това банката вече не купува „прасе в джоба“, както беше преди, тя плаща за много категоричен резултат. Нека обаче се върнем на SOA и за тези, които се интересуват от темата за интеграционния продукт, ви каня да посетят уебинара „Новият продукт на Neoflex Integra: квинтесенцията на проектния опит“ на 20 ноември.

И така, какво ще се случи по-нататък, как ще се развие SOA, ще остане ли шината за данни и ще заеме ли същото почетно място, както сега в пейзажа на кредита, и ако погледнете по-широко, тогава не само кредитна организация? Ще започна отдалеч, за SOA като цяло, за това каква е съдбата на тази концепция в банковата индустрия. Всъщност правилната ИТ архитектура за една банка е тази, която може да отговори на нейните бизнес нужди. Колкото по-голяма е банката, толкова по-високи са заявките. В Русия, с нейните многоклонови, географски разпределени структури, има достатъчно големи банки, но дори те не винаги могат да си позволят висококачествен SOA ландшафт и не само защото е много скъп, но и защото е огромен риск. SOA проектите не винаги завършват добре. С нашия продукт планираме да намалим рисковете, а в същото време и прага за навлизане в SOA.

Не си мислете, че SOA ландшафтът е луд бизнес. Проектите на Neoflex показват, че неинтегрируеми системи няма. Банките обикновено започват да създават нов пейзаж малко по малко, започвайки с най-важните за тях области, но наскоро се натъкнахме на мащаб, който не сме виждали досега. Това се случи по проект на банка VTB24. Компанията работи там, за да създаде слой за универсални банкови услуги, базиран на Oracle SOA Suite. Решението включва над 600 услуги, които осигуряват работата на банката с всички клиенти по всички комуникационни канали. Такова мащабно и сложно решение, според колегите от Oracle, няма да помнят в Русия. И ако е успял, то други проекти са чисто технически осъществими.

Необходимостта от формиране на единен логически слой и оптимизиране на ИТ пространството е най-изпитана от банките, които управляват голям брой проекти на дребно. Скоростта на обслужване на клиентите е от решаващо значение тук, а техниките, използвани в практиката на SOA, могат значително да я увеличат поради по-бързия поток от данни. Следователно водещи банки като VTB24, Probusinessbank ( Живот група), с които също работим, приеха дългосрочни програми за преход към SOA преди време. Дали по-малките организации ще последват примера им е трудно да се каже: кризата е все пак. Но чисто практически съображения са следните. Ако се опитаме да начертаем условна граница между онези, които се нуждаят от SOA, и тези, които могат да се справят с по-прости решения, тогава тази граница, преди да започне стагнацията на пазара, премина приблизително през първите 400 банки.

В други области на банковата автоматизация, концепцията за максимизиране на използването на готова функционалност, или продуктовата концепция, успешно се вкорени, след като системите бяха компонентизирани. Мисля, че SOA не трябва да бъде изключение. Но това е въпрос на бъдещето. Междувременно много банки живеят в напълно различни реалности и въпросът в дневния им ред не е кой интеграционен продукт да използват, а коя шина да внедрят. Да слезем от небето на земята.

Какво да правя с IBM WebSphere ESB?

Несъмнено IBM WebSphere ESB е лидер на пазара сред интеграционните шини както по отношение на броя на проектите, така и по отношение на броя на внедренията. От 10 интеграционни проекта, 8 са направени на IBM WebSphere ESB. И едва през последните 2 години ситуацията започна малко да се променя и движението на други големи световни доставчици започна да се появява на пазара. Не бих искал да ги сравнявам в рамките на тази статия, тъй като без нея има достатъчно сравнения и аналитични изследвания по тази тема. Статията ми е адресирана до тези, които някога са направили крачка към SOA и са го направили заедно с IBM WebSphere ESB. И те трябваше да се тревожат сериозно: изведнъж, като сняг на главите им, миналогодишната новина, че IBM е променила продуктовата линия на софтуер за интеграция от 2014 г. насам и IBM Web Sphere ESB вече няма да се разработва и поддръжката за това комплексът едва наскоро беше удължен до април 2018 г. Преди това беше планирано да бъде завършен през 2014 г.

В тази връзка все повече наши клиенти, използвали тази интеграционна платформа, започнаха да задават въпроси какво ги очаква.

Чудеса не се случват и аз не съм магьосник, но искам да предложа два начина:

1. Започнете да мислите за използването на друга платформа, на която IBM залагат в бъдеще - Integration Bus (бившият Message Broker).

Той има очевидни предимства пред IBM WebSphere ESB: производителност и надеждност. Има и достатъчно проекти и реализации с тази платформа и някой от самото начало я избра като интеграционна шина.

Неговата основна технологична характеристика е вътрешното използване на опашка за съобщения (MQ) като транспорт, което ни дава гарантирана доставка на съобщения и в резултат на това надеждност.

2. Още сега, когато разработвате интеграционно решение на IBM WebSphere ESB, опитайте се да отделите нивата на внедряване, за да създадете нов кодне на IBM WebSphere ESB, а на други компоненти, чието използване в интеграционното решение съответства на по-нататъшната стратегия за развитие. Няма много подходящи продукти от IBM, само 2-3. Един от тях, според мен, най-обещаващият е IBM WebSphere Data Power, хардуерна и софтуерна система за решаване на интеграционни проблеми, която осигурява висока производителност и сертифицирана сигурност. Предимствата на този продукт са най-високата производителност в своя клас и възможността за решаване на широк спектър от задачи за сигурност, както външни, така и вътрешни.

Към днешна дата имаме повече от впечатляващи резултати от един от пилотните проекти с IBM Data Power, завършен в Ренесанс Кредитна Банка: 40 заявки в секунда се обработват с 5000 едновременни връзки, а времето за обработка на 1 заявка е под 1 ms. Заслужава да се отбележи, че натоварването на процесора по време на тестовете беше на ниво от 5%!

Използването на IBM Data Power ще помогне за разделянето на слоевете на решението за интеграция между IBM WebSphere ESB и IBM DataPower, така че когато замените IBM WebSphere ESB с нова интеграционна шина, например с IBM Integration Bus, не е нужно да преработвате частта за IBM DataPower.

Този подход на хибридна шина може да бъде приложен и въз основа на продукти от други доставчици, т.е. не само IBM. Тъй като развитието на продуктите на много производители често върви в една и съща посока, но това е тема за отделна дискусия.

Как трябва да изглежда интегрираната шина за данни в близко бъдеще?

Тук просто искам да ви насоча към факта, че предложенията, които описах, отговарят много добре на идеята за гумата, която според мен ще се осъществи в бъдеще. Чрез въвеждането на концепцията за "хибриден" автобус и комбинирането на технологии, ние постигаме решение на различни интеграционни проблеми. Освен това говорим както за комбиниране на софтуер, така и за разреждане на „чистия“ софтуер с помощта на софтуерни и хардуерни системи.

В днешно време е много трудно да се покрият всички изисквания на един бизнес с който и да е продукт. Следователно старият, изпитан принцип „най-доброто от породата“ е напълно приложим за интегрираните гуми.

Вземете няколко продукта, комбинирайте ги с една обща задача, разделете компонентите между тях, „засадете“ ги на общ интеграционен модел на данни и не само ще получите многофункционално решение, но и ще се предпазите от „пристрастяване към продукта“.

Така открихме две прости решения, всеки от които има своите предимства:

· IBM WebSphere ESB в комбинация с IBM Integration Bus се използва за изграждане на SOA платформи, интегриране на сложни приложения и ИТ среди;

Висока производителност IBM продукт DataPower, характеризиращ се с лекота на конфигуриране, се използва за обработка на прости заявки и за осигуряване на многофункционална сигурност.

Несъмнено хибридните автобуси са бъдещето, освен ако нямаме шина за данни в облака, дори ако сега изглежда малко вероятно. Ще се върнем към този въпрос след година-две. Съгласен ли си?

Блокът от BPM-системи умишлено не беше разгледан тук, т.к. това е отделна обширна тема.