×

Поиск коллег в области интеграции приложений

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

У меня сложилось впечатление, что настоящей интеграцией корпоративных приложений (т.н. Enterprise Application Integration) в Украине практически никто не занимается. Есть информация о нескольких успешных проектах в России (к примеру, в Билайне по интеграции биллинга). Продолжительные поиски людей в этой области, а также компаний предоставляющих такие услуги почти ничего не дал. То небольшое количество русскоязычных статей по тематике, которые отыскиваются, пахнут рекламными менеджерскими презентациями, оторванными от реальности. Много голой игры слов, не подкрепленной практическими реализациями.

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

Хотелось бы найти коллег, которые участвуют в таких проектах.

Цель — услышать и поделится опытом внедрения подобных решений, практическом применению SOA при интеграции, обсудить архитектуры и платформы.

По долгу службы занимаюсь интеграцией большого количества приложений (ERP и др) в рамках компании c использованием платформы IBM WebSphere Business Integration Server.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
В виде сервисов реализуются приложения, которые занимаются обработкой финансовых транзакций.
Сервисы, как я уже написал, управляются BPM машиной.
Я работаю в большом банке. Здесь много приложений и их нужно интегрировать.

Каких справочников?

Если так, то к примеру, что реализуется в виде сервисов? Кем эти сервисы управляются? От кого исходила инициатива по интеграции? От бизнеса или IT? Кто «заказывает» сервисы? Как решается вопрос синхронизации справочников?

В этой итеграции, которой я сейчас кстати активно занимаюсь на платформе JBoss SOA: ESB, BPM, BRMS, ничего особенного нету.

Ну — каких то таких особых тайн у нас как раз нет, то есть могу рассказать подробно:
Есть точки взаимодействия биллинга с окружающим миром, к примеру — Платежи — Call-Center — Система мониторинга — Прием данных — Управление аппаратурой... итд
В каждой из этой точки взаимодействия более или менее фиксированная семантика, но может быть разное ПО подключения (к примеру, для платежей — мы поддерживаем семь платежных систем оплаты по интернету и есть еще форматы реестров банков)
Вот для каждой такой точки взаимодействия делается коннектор — это нечто вроде «настраиваемой прокладки» между биллингом и внешним миров, в которой определен — API с помощью которого конкретные реализации интерфейса могут быть встроенны в биллинг (или с помощью которого можно обращзаться к биллингу) — форматы данных (бизнес-объекты) при необходимости — действия по их конфигурированию
Что касается стратегии — тут я наверное, неправильно выразился. Правильней вместо стратегии будет говорить «архитектура коннектора [/слоя коннектора/] и способ интеграции».
... слой коненктора — еще одно дополнительное понятие.
Эволюция идет, какие-то веши устаревают, какие-то нет, какие=то устаревшие вещи мы выносим из коннекторов, какие-то приживаются и остаются.
Скажем для Self-Care интерфейсов у нас есть API доступа к функциональности биллинга
из
1) PL/SQL (со множеством оговорок)
2) Tcl в нашем контейнере выполнения
3) XWiki плагин (и в принципе — API доступное из JDK)

Это как-бы разнве реализации одного и того-же (как слои коры в дереве). Неиспользуемое мы со временем убираем или переквалифицируем в «приватное API»

К сожалению такова специфика задач, что приходиться оперировать множеством конфиденциальной информации о IT-инфраструктуре компании. Это и есть одна из причин небольшого количества доступных данных о интеграционных проектах.
Большинство подобных задач решаются «на коленках» между парой систем. Яркий пример — обмен файлами, самописные конвертеры. Либо используются уже встроенные средства «больших» систем. К примеру для тех же MES-систем есть стандарт облегчающий их интеграцию в IT-инфраструктуру (википедия говорит о ISA S95). В ряду ERP — производители предлагают собственные решения, чтобы облегчить внедрение.
Но когда у компании больше 5-и масштабных систем от которых невозможно отказаться, найти замену «все в одном», для сохранения уже вложенных инвестиций — вынужденно приходиться задумываться о эффективном решении заставить работать все это между собой. Да еще и быстро, безотказно и с минимум ручной работы.
Поэтому критериями настоящей, взрослой интеграции может служить отказ от создания «зоопарка» отдельных решений для интеграции каждой системы с каждой, унифицированный подход. Повторюсь — это вынужденное решение. Потому как наилучшая интеграция — это отсутствие интеграции:)
2rssh
что у вас понимаете под коннектором к внешней системе? стратегией? этим всем же что-то управляет? или задача кому что отправить, по какому пути, через какой коннектор лежит на биллинге? т.е. все внешние системы «крутятся» вокруг него и интегрируются непосредственно с ним?
Чтобы это не выглядело просто как любопытство, расскажу пару слов (не конфиденциальных:)) о том, как устроено в миру той платформы, которую я использую.
Коннектор к каждой внешней системе оперирует своим набором объектов, специфичных для него. Он их создает во внешней системе и вытягивает чтобы отдать внутрь интеграционной платформы (при событии). Сам коннектор может на прикладном уровне делать изменения в БД, в файлах, отправлять пакеты на хост: порт, вызвать удаленно процедуру, etc.

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

А что такое «настоящая интеграция бизнес-приложений»?
//Мы свой биллинг почти при каждом внедрении интегрируем с разными программами, железками и внешними сервисами (телекоммуникационными или платежными системами) — вроде работает;)
Но именно отдельную платформу интеграции и так что бы ’чисто SOA’ — наверное нет. У нас обычто свой коннектор и своя стратешия интеграции чуть ли не для каждого типа задач.

[более того, тут вобще какая-то странность: выясняется что в реальном мире Rest, CORBA и что-то свое поверх http или radius, встречается чаще чем то, что есть в стандартных коннекторах]

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

Підписатись на коментарі