Беспорядок ESB BizTalk 2009
Я хочу добавить краткую информацию о синтаксисе C # 6.0:
Теперь можно заменить это:
var handler = EventSeven;
if (handler != null)
handler.Invoke(this, EventArgs.Empty);
на это:
handler?.Invoke(this, EventArgs.Empty);
Комбинируя его с членами с выражением выражения , вы можете сократить следующий код:
protected virtual void OnMyEvent()
{
EventHandler handler = MyEvent;
handler?.Invoke(this, EventArgs.Empty);
}
до однострочных :
protected virtual void OnMyEvent() => MyEvent?.Invoke(this, EventArgs.Empty);
См. MSDN для получения дополнительной информации об условно-нулевом операторе
См. этот блог о членах с выражением тела.
4 ответа
Направляющие
На-рампы представляют собой порт приема на основе веб-служб, но они немного отличаются, поскольку они принимают общие сообщения XML. Однако сообщения будут иметь очень специальный заголовок SOAP («конверт», если хотите) со всеми необходимыми свойствами, чтобы сделать возможным, например, маршрут сообщения. Вы найдете все возможные заголовки, заглянув в "EsbEnvGeneric.xsd"
маршруты
Мне нравится, что NealWalter отвечает по этому поводу. Я, однако, просто хотел бы добавить, что маршрут сообщения может потенциально сэкономить много времени и усилий на разработку. Это может сделать организации более гибкими и упростить изменение их процессов. Если мы не Мне нужно разработать и развернуть совершенно новую оркестровку, но только изменить некоторую конфигурацию и использовать наши существующие биты, что, конечно, может сэкономить много времени. И это большая ценность в ESB и маршруте сообщений, как я это вижу.
Окно сообщения
Сообщения в BizTalk всегда должны проходить через окно сообщений. В следующей версии MS намекала о сценарии с низкой задержкой в BizTalk - возможно, тогда мы сможем получить немного больше контроля, но больше, но пока сообщения сохраняются много раз на пути через BizTalk, и в этом нет ничего особенного.
Я отвечу только на ваш второй вопрос:
2) Зачем вам нужны маршруты, может вы не просто создаете то же самое, используя порты и оркестровки? я здесь явно чего-то не хватает.
На последнем месте, где я работал, мы работали над ESB около года. Идея маршрута заключается в том, что когда сообщение поступает в ESB, оно должно волшебным образом попасть в нужной последовательности в соответствующие системы.
В системе, ориентированной на бизнес-процессы (BPM), вы обычно пишете оркестровку, чтобы направлять поток логики. Другими словами, вы кодируете маршрут или путь сообщения в оркестровке. В созданной нами ESB бизнес-правила определяли, куда будет отправляться сообщение. У нас все еще были оркестровки для конечных точек, но обычно они были короткими и обеспечивали только отображение и некоторые очень простые функции. В других местах, где я работал, оркестровки могут быть довольно большими.
Итак, правила того, что делать с сообщением, должны где-то быть. В ESB каждая конечная точка должна быть полностью независимой и не знать о других конечных точках. Лагерь ESB предполагает, что система должна меняться более динамично, без необходимости повторного развертывания программного обеспечения (т. Е. Оркестровок). Таким образом, с помощью нашей ESB вы можете просто изменить бизнес-правила и повторно развернуть их.
Некоторые из сложных проблем с ESB связаны с транзакциями, откатом и обычно создают общий процесс обработки ошибок.
Нил Уолтерс http://BizTalk-Training.com
На общий вопрос: что я помню, да, все сообщения проходят через окно сообщений. Но я использовал BizTalk 2006 R2. Посмотрите на картинку здесь .
Что касается двух других вопросов, я сам так и не понял полностью. У меня сейчас нет времени на расследование, но я, вероятно, сделаю это, если никто нас не просветит :)
Пара дополнительных представлений -
Порты приема / на рампе - полностью согласна с ответом Рири и просто добавила бы - на рампе в контексте BizTalk ESB приложение - это конкретная реализация порта приема; подмножество; частный случай. он использует порт приема для реализации шаблона из мира ESB; так что - они сами по себе не отличаются.
Маршруты - опять же - согласны как с Нилом, так и с Рири и добавили бы, в ответ на ваш вопрос, - BizTalk ESB может использовать маршруты по-разному - «подсказано- up 'клиент может доставить запрошенный маршрут с сообщением запроса; менее осведомленный клиент может просто доставить сообщение, Теоретически их можно также комбинировать, если клиент указывает маршрут, но ESB на рампе заменяет / изменяет его.