Создание приложения для перемещения файлов ... Я ищу служебную шину? - PullRequest
2 голосов
/ 13 ноября 2009

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

Я планирую разработать довольно простое приложение для консолидации этих усилий. По сути, он может быть сконфигурирован с входными данными (т. Е. Папками для просмотра, почтовыми ящиками для проверки и т. Д.), А затем одним или несколькими действиями, которые можно выполнить для каждого входа (т. Е. Скопировать в папку webdav, отправить в веб-службу, отправить по электронной почте и т. Д.) .

Теперь это не очень сложное приложение, которое можно извлечь, но мне любопытно ... Я слышал подкаст или что-то о "Муле", я полагаю, что это ESB. И я не знаю много о сервисных автобусах, но мне кажется, что то, что я собираюсь сделать, по крайней мере похоже. Это так?

Существует ли облегченный фреймворк / библиотека / приложение, которое я могу использовать для выполнения своей задачи без гигантской кривой обучения? Предпочтительно на основе Java, но о C # /. Net не может быть и речи.

(П.С. Я рассмотрел это для ServerFault, но здесь это кажется уместным ...)

Ответы [ 2 ]

2 голосов
/ 13 ноября 2009

Spring Integration немного легче и имеет меньшую кривую обучения. Однако это немного менее гибко. Я бы сказал, что Mule - самый мощный и гибкий из вариантов с открытым исходным кодом на данный момент, но он идет с кривой обучения.

Эта статья представляет собой хорошее введение в Spring Integration и шаблоны проектирования EAI (Enterprise Application Integration) в целом.

Я использовал Mule в подобных ситуациях в прошлом. То, что я скажу о принятии решения, использовать ли это следующим образом:

  • это определенно может быть излишним, в зависимости от того, сколько скриптов вы поддерживаете и сколько людей нужно, чтобы поддерживать их со временем
  • будьте готовы испытать концептуальную кривую обучения - попробуйте много экспериментов!
  • Изучите книгу Корпоративные интеграционные шаблоны для более глубокого понимания того, как использовать любой ESB наиболее разумно
  • как только вы освоите Mule, у вас будет очень гибкий набор инструментов для быстрого и надежного решения практически любой проблемы интеграции

Пока что мой опыт с Мулом определенно был чистой победой. Но это всегда компромисс между:

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

Я, как правило, наслаждаюсь кривой обучения и хорошо разбираюсь в проблемах, когда структура не «взаимодействует» (то есть я еще не до конца ее понимаю). Я также обычно работаю над проектом, который должен пережить мое участие в нем. Таким образом, вовлечение Mule действительно открыло двери и сделало наш код намного более коллективно поддерживаемым.

Другие кодеры, которых я знаю, вообще избегают фреймворков, настаивая на том, что более прагматично не использовать их. Если вы находитесь в последнем лагере, вам определенно НЕ следует заходить в Мул. Вероятно, не Spring Integration, либо!

Надеюсь, это поможет: -)

0 голосов
/ 13 ноября 2009

Я собираюсь предположить, что сценарии, необходимые для работы инструмента, по крайней мере так же сложны, как написание приложения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...