Возник у меня вопрос отчасти теоретического свойства. Есть достаточно сложная информационная система. Ну например ГИС решение или сисиема обработки экспериментальных данных. Поскольку система большая, разные ее модули писались в разное время и разными людьми с использованием разных языков и технологий. То есть совсем разных: один модуль может быть написан на перле, другой на си, а третий вообще на хаскеле. Под модулями в данном случае я понимаю функциональный элемент системы, выполняющий, например, преобразование формата данных, анализ данных, взаимодействие с пользователем. Сотня модулей за несколько лет жизни системы порождают доселе невиданный зоопарк. Сейчас модули оформляются в виде отдельных программ со своими собственными форматами входа и выхода и интегрируются между собой в классическом unix way.
Вопрос: что умные люди советуют использовать для интеграции в современном мире?
Хочется:
1. Поддержки всех возможных языков на уровне библиотек либо простоты имплементации этой поддержки.
2. Поддержки распределенности.
3. Контроля исполняемых в текущий момент времени задач.
4. Фиксации интерфейсов модулей, чтобы можно было заменять модули без риска развалить всю систему.
5. Простоты перекомбинации модулей для расширения функционала системы.
Масштабы примерно такие:
1-10 рабочих станций, на которых выполняются процессы
100-1000 функциональных модулей
10-100 различных юзкейзов к системе
Здравствуйте, gandjustas, Вы писали:
G>Может SOA и веб сервисы?
По моему опыту, у вебсервисов есть один концептуальный недостаток. Они сложны. Мало того, что разработка веб-сервисов в разы более трудоемка, чем разработка CLI, так еще и их поддержка требует специальных знаний. ИМХО, SOA на веб-сервисах технология тяжелая. Она хорошо подходит для ситуаций, когда у нас есть сильные команды админов и разработчиков, а система изменяется централизованно, продуманно и медленно. В моем случае, есть кучка микрокоманд из 1-5 человек, для которых программирование часто не является основным занятием. Я не представляю их за отладкой веб-сервисов. Их приоритет -- решенные задачи, а не архитектурные красивости. Боюсь, что заставить всех написать веб-сервисные обертки к модулям задача нереальная, не говоря уже о том, чтобы все переписать.
Если где-то бывает SOA, не опирающаяся на веб-сервисы, буду рад ссылкам.
Здравствуйте, Miroff, Вы писали:
M>Если где-то бывает SOA, не опирающаяся на веб-сервисы, буду рад ссылкам.
Введите в Google словосочетание написанное в этом сообщении: Re: Интеграция неигтегрируемого
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>ИМХО UNIX-way для _такой_ интеграции лучше всего. Если нужна распределенность — то можно что-то типа SOAP использовать. MSS>Все форматы данных при общении должны быть задокументированы.
Согласен, лучше всего. По сути, к нему только одна претензия: сложность (неоднородность) текстовых форматов данных затрудняет разработку до такой степени, что разобрать входные и сформировать выходные данные становится чуть ли не сложнее чем разработать собственно бизнес логику. Например, географические координаты могут быть представлены чуть ли не в десятке разных форматов. Для даты форматов уже несколько десятков. Никакое документирование тут не избавит от разработки. Кроме затруднений в разработке, это затрудняет и использование. В особо тяжелых случаях, интеграция модулей с несовместимыми форматами требует едва ли не больше "клея" чем сами модули.
Я вижу "серебряную пулю" так (оставим в стороне распределенность):
1. Вместо текстовых форматов модули используют некоторый структурированный формат общения, например, на основе XML или RDF.
2. Создается набор инструментов для конвертирования структурированного формата в текстовые и обратно. Например, с помощью XSLT преобразований.
3. Для каждого модуля определяются типы данных, которые он способен принимать на вход.
Таким образом, поскольку все понимают только один формат, содержащий только информацию, без human-readable разметки, интеграция должна упроститься.
Вопрос: не изобретаю ли очередного велосипеда? Возможно, кто-то в этом направлении уже успешно трудится. ИМХО, такая штука пришлась бы очень кстати в тех же юниксах и существенно бы упростила CLI утилиты. Ее отсутствие меня очень сильно смущает. Может я хочу странного?
Здравствуйте, Miroff, Вы писали:
M>Вопрос: не изобретаю ли очередного велосипеда?
Да, изобретаете. В своих пунктах 1-3 вы описали суть ESB (уж аж в 3 раз говорю вам!), см. описание простой реализации здесь: Re: Как собрать процесс воедино?
Здравствуйте, rsn81, Вы писали:
R>Да, изобретаете. В своих пунктах 1-3 вы описали суть ESB (уж аж в 3 раз говорю вам!), см. описание простой реализации здесь: Re: Как собрать процесс воедино?
Спасибо, посмотрю. Можете ответить на пару вопросов?
Скажите, вы можете представить себе unix, построенный на этой штуке?
Какова трудоемкость декларативного описания процессов в том-же Mule?
Здравствуйте, Miroff, Вы писали:
M>Спасибо, посмотрю. Можете ответить на пару вопросов? M>Скажите, вы можете представить себе unix, построенный на этой штуке?
Не могу и, пожалуй, даже не буду рисковать.
Вопрос не понял.
M>Какова трудоемкость декларативного описания процессов в том-же Mule?
Я не знаю, что вы в данном контексте подразумеваете под процессом. В Mule задаются декларативно узлы и маршрут общей шины; если же определенный узел выполняет специфические действия, то есть которых нет в стандартной поставке Mule, то нужно кодить.
Здравствуйте, rsn81, Вы писали:
R>Не могу и, пожалуй, даже не буду рисковать. R>Вопрос не понял.
R>Я не знаю, что вы в данном контексте подразумеваете под процессом. В Mule задаются декларативно узлы и маршрут общей шины; если же определенный узел выполняет специфические действия, то есть которых нет в стандартной поставке Mule, то нужно кодить.
Поясняю, предметная область такова, что очень часто все происходит в пределах одной машины. Поэтому куча распределенных протоколов из стандартной поставки посвящена изрядная часть документации к Mule мне мало интересна. С другой стороны, разные комбинации модулей создаются довольно часто на один раз. Поэтому я применяю эмпирический критерий сравнимости с unix way. Например, мне нужен список файлов, в которых встречается слово "Ленин", я комбинирую find и grep. Завтра мне может потребоваться конвертировать все эти файлы в html и залить по ftp на сервер. Вот такую операцию, составленную из примитивных команд я называю процессом. В терминах Mule, это, скорее всего, маршрут по общей шине. Отсюда вопрос, насколько медленнее описывать (и отлаживать) процессы в Mule по сравнению с unix way? Если на порядок медленнее, боюсь, что такое решение не подойдет.
Здравствуйте, Miroff, Вы писали:
M>Поясняю, предметная область такова, что очень часто все происходит в пределах одной машины. Поэтому куча распределенных протоколов из стандартной поставки посвящена изрядная часть документации к Mule мне мало интересна.
Есть коннекторы и к файловой системе.
M>С другой стороны, разные комбинации модулей создаются довольно часто на один раз. Поэтому я применяю эмпирический критерий сравнимости с unix way. Например, мне нужен список файлов, в которых встречается слово "Ленин", я комбинирую find и grep. Завтра мне может потребоваться конвертировать все эти файлы в html и залить по ftp на сервер.
Настроить и протестировать такой маршрут не должно отнять и часа. Написание XSL-преобразования и прочее — не учитываю — просто связать все в единый поток.
M>Вот такую операцию, составленную из примитивных команд я называю процессом. В терминах Mule, это, скорее всего, маршрут по общей шине. Отсюда вопрос, насколько медленнее описывать (и отлаживать) процессы в Mule по сравнению с unix way? Если на порядок медленнее, боюсь, что такое решение не подойдет.
А потрогать пытались? Дольше рассуждать...
M>разработать собственно бизнес логику. Например, географические координаты могут быть представлены чуть ли не в десятке разных форматов. Для даты форматов уже несколько десятков.
В вашей системе будет только один формат координат и один формат даты, возможно, с фильтрами для импорта-экспорта (если оно нужно).
M>1. Вместо текстовых форматов модули используют некоторый структурированный формат общения, например, на основе XML или RDF. M>2. Создается набор инструментов для конвертирования структурированного формата в текстовые и обратно. Например, с помощью XSLT преобразований.
А XML не текстовый?
M>3. Для каждого модуля определяются типы данных, которые он способен принимать на вход.
Проще. Для всей системы определяется единый формат координат и даты, все модули переделываются под него. Возможно, что потом для поступающих извне данных пишутся еще фильтры-преобразователи (а возможно, что и не пишутся).
M>Таким образом, поскольку все понимают только один формат, содержащий только информацию, без human-readable разметки, интеграция должна упроститься.
M>1. Поддержки всех возможных языков на уровне библиотек либо простоты имплементации этой поддержки. M>2. Поддержки распределенности. M>3. Контроля исполняемых в текущий момент времени задач. M>4. Фиксации интерфейсов модулей, чтобы можно было заменять модули без риска развалить всю систему. M>5. Простоты перекомбинации модулей для расширения функционала системы.
Все эти задачи можно решить методом обмена сообщениями. Можно почитать здесь. Здесь масса шаблонов описывается
