Я отвечаю только на ваш второй вопрос:
2) Зачем вам маршруты, можно
вы не просто создаете то же самое, используя
порты и оркестровки? я
очевидно, что-то здесь упущено.
В последнем месте, где я работал, мы работали над нашим ESB около года.
Идея перехода заключается в том, что когда сообщение поступает в ESB, оно должно волшебным образом идти в правильной последовательности к соответствующим системам.
В системе, ориентированной на бизнес-процессы (BPM), вы обычно пишете оркестровку для управления потоком логики. Другими словами, вы кодируете маршрут или путь сообщения в оркестровке. В ESB, который мы создали, бизнес-правила решили, куда будет отправлено сообщение. У нас все еще были оркестровки для конечных точек, но они, как правило, были короткими и выполняли только картографию и некоторые базовые функции. В других местах, где я работал, оркестровки могут быть довольно большими.
Так что правила того, что делать с сообщением, должны быть где-то. В ESB каждая конечная точка должна быть абсолютно независимой и не знать о других конечных точках. Лагерь ESB предполагает, что система должна меняться более динамично, без необходимости повторного развертывания программного обеспечения (то есть оркестровки). Таким образом, с нашим ESB вы можете просто изменить бизнес-правила и повторно развернуть их.
Некоторые сложные проблемы с ESB связаны с транзакциями, откатом и обычно создают общий процесс обработки ошибок.
Нил Уолтерс
http://BizTalk -Training.com