Еще немного мыслей об архитектуре ЮЗДО
Статья Алексея Корепанова "Архитектура обмена юридически значимыми электронными документами" как раз относится к такого рода информационным материалам, ибо разбудила от зимней спячки некоторых активных авторов и читателей ecm-journal. Не удержусь от соблазна еще раз высказать несколько своих мыслей, возникших в ходе чтения статьи.
На мой взгляд, хороший материал (статьи, блоги) - это тот, что вызывает желание думать, спорить, обсуждать. Статья Алексея Корепанова "Архитектура обмена юридически значимыми электронными документами" как раз относится к такого рода информационным материалам, ибо разбудила от зимней спячки некоторых активных авторов и читателей ecm-journal. Не удержусь от соблазна еще раз высказать несколько своих мыслей, возникших в ходе чтения статьи.
Мысль первая. Интересно, но при обсуждении архитектуры обмена электронными документами между несколькими информационными системами ни разу не всплыли популярные когда-то аббревиатуры SOA (Service Oriented Architecture) и ESB (Enterprise Service Bus). Да и BPM-функционал рассматривался как безусловный аттрибут ECM-системы, а не отдельное решение. А ведь в ряде моментов надо говорить уже не только о human workglow, но и о межсистемном взаимодействии. В чем, как считалось пять или чуть более лет назад, и есть весь цимес SOA. Сразу всплывают из памяти Microsoft Biztallk или IBM WebSphere. Думаю, если бы не цена решения, способная отпугнуть недостаточно крупный бизнес, отличная бы получилась архитектурка. Да... Быстротечна ИТ-мода и круты петли гартнеровской hype-кривой. Впрочем, наличие в ECM-системе workflow просто нашептывает использовать его и в интеграционных целях. Тенденция? Или речь идет об интеграции систем, находящихся в нескольких юрисдикциях (Конрагент 1, Спецоператор, Контрагент 2)? Каждый сам автоматизирует свой кусок, как может. Думаю, как-то так.
Мысль вторая. Говоря об информационных системах, будь то ECM или ERP, мы по привычке "думаем за" on-premise системы. А ведь совсем скоро облачные решения отвоюют еще больше ИТ-бюджетов, и интегрировать надо будет разнообразные облачные решения. По крайней мере, если мы говорим о SaaS (Software as a Service) и отчасти PaaS (Platform as a Service). И это уже в ряде случаев будет головная боль провайдеров услуг. Или такие решения, разработанные ISV (Independent Software Vendors ), будут продаваться в он-лайн магазинчиках тех же поставщиков сервисов. Или это будут отдельные сервисы, что-то вроде популярных когда-то mushup'ов. Опять, забытый или редко используемый термин?
Похожие статьи
Комментарии 5
Данные и API с которыми они работают
Тот же BizTalk имеет просто огромное число механизмов для преобразования разных форматов сообщений в другие. Вся его основа - преобразование данных. На сколько я занаю, большая часть их кода нативная только для того, чтобы максимально выиграть на операциях преобразования.
Сюда же можно отнести огромное число адаптеров (и средств их разработки) - для того чтобы можно было легко подключиться к любой системе.
Workflow работает с внутренним API системы, в которую встроена. Ее задача - предоставление удобного интерфейса программисту для автоматизации рутинных задач или систематизации регламентов. Она оперирует ограниченным набором объектов, которое это самое API и предоставляет.
Масштабирование и устойчивость.
Задача ESB - прокачивать тонны сообщений между системами. Например, процессинг заказо средний фирмы или операции в неблоьшом банке, это сотни тысяч сообщений в час. Например, BizTalk имеет средства для хостинга на нескольких серверах "одним щелчком" (причем по разным серверам можно раскидывать разные части - на одной оркестровка, на другой входящие адаптеры, на третьей - исходящие, ...). Более того, из него можно строить целые деревья для систем обработки (когда каждый каскад решает свою задачу и конечный узел просто консолидирует все).
При этом на ESB стараются не вешать дополнительную сложную логику, а также они работают асинхронно. Т.е. обработал одно сообщение, отбросил его в нужную систему и забыл о нем.
Workflow - обеспечивает работу людей и сложные длинные процессы, которые могут течь годами. Обычно этих процессов не много (если, конечно, программисты не используют workflow для затыкания абсолютно всех задач - от подписания документов, до выполнения резервного копирования) - несколько десятков тысяч на всю систему. Но (!) как я уже говорил, т.к. Workflow по сути управляет системой, в которую встроена - нагрузки на нее весьма приличные.
Другое дело, что масштабировать и обеспечивать отказоустойчивость для Workflow-системы из-за самого характера системы очень сложно.
Мониторинг и аналитика.
ESB прокачивает кучу данных. Почему бы сразу эти данные не консолидировать, не строить по ним аналитику? Не по количеству прошедших сообщений, а по данным в них!
Workflow данные не передает, она управляет тем, что есть в системе, где она работает. Поэтому для нее аналитика это выборки из самой системы.
В свете вышесказанного, мне кажется это ошибка.
Тема, которую поднял Алексей, достаточно обширна и многогранна. Я "отвел ветку", в которой хотел поговорить об интеграционных аспектах, термин "ЮЗДО" в данном случае - просто ссылка на исходную статью.
Миша, спасибо за подробный анализ! Теперь и в моей голове что-то проснилось и немного устаканилось.
Я, скорее всего, очень многословно и неявно выразил свой посыл. Меня как раз несколько удивило, что в обсуждении не говорилось о SOA, ESB, BPM (в более широком понимании, чем human workflow), только о wokflow. У меня два предположения: 1) термин SOA окончательно вышел из моды 2) на wokflow пытаются взвалить задачи межсистемной интеграции.
Ну тут претензии к Алексею - он всячески продвигал идею "ECM - как центр вселенной", чем и задал тему обсуждения.
Более того, Алексей говорил о документах, содержащих неструктурированный контент, т.е. тех, которые в обязательном порядке требуют ручной работы с ними. Это нормально в случае уникального контента (типа нетиповые договоров) и, скорее всего, мало пригодится при потоковом обмене документами - заказами, счетами (их, кстати, скорее всего вообще не будет), счетами-фактурами. Вот тут и потребуются системы класса ESB.
Понятно, что схемы могут быть разными. Хотя сама постановка вопроса меня смущает: СЭД в качестве ESB в целях экономии... Имхо, при наличии огромного рынка open source решений в этой области как-то даже смысла не видно в таком варианте.