Итак, может быть, это тот случай, когда я должен пойти на SOA?

Question

Сценарий: у меня есть система CRM и мое приложение.Когда в системе CRM создается новый заказ, myApp должен что-то сделать (создать комнату проекта для заказа) и написать что-то (URL комнаты проекта) обратно в систему CRM.

Так что я мог бы легкоРеализуя это, используя двухточечную интеграцию, myApp размещает сервис, который, по окончании чего-либо, вызывает сервис в CRM.

Вопрос: стоит ли мне прилагать дополнительные усилия для добавления некоторой служебной шины (дополнительный код, дополнительное сопровождение) или это не подходящий случай?У компании сегодня нет сервисной шины и вообще нет стратегии интеграции.

В случае «да» на поставленный выше вопрос (я ожидаю, что это), какое дополнительное время я должен оценить длявключая, скажем, nServiceBus или rhino-service-bus ((никогда не пробовал ни один из них), в сферу? Есть ли у вас какие-либо рекомендации по другим esb или пример, который я мог бы прочитать?

Спасибо за любую помощь

С уважением

Ларси

Answer 1

Если вы думаете о переходе на архитектуру SOA, прежде чем принимать решения о связи, прежде всего стоит ограничиться границами обслуживания. Если ваше приложение владеет реализацией определенной бизнес-возможности, то есть оно определяет бизнес-логику и является авторитетным источником данных для этой возможности, тогда оно должно быть собственной службой. Однако если ваше приложение просто предоставляет вспомогательные функции для системы CRM, то с точки зрения SOA ваше приложение и CRM будут частью одной и той же службы.

Начните с прочтения этого короткого поста: http://fafach.wordpress.com/2011/04/20/soa-what-is-a-service/

Тогда посмотрите это превосходное вводное видео SOA: http://www.nservicebus.com/ArchitecturalPrinciples.aspx

Answer 2

Вы должны различать основные аспекты SOA

у каждого есть услуги, что в основном является проблемой дизайна. Короче говоря, это означает, что услуга должна быть товарной, а не сделанной на заказ для конкретного клиента, которого вы планируете ..

вторым аспектом является инфраструктура - которая может включать и ESB

Если у вас есть один сервис или небольшое количество сервисов, вы можете использовать простые веб-сервисы (без ESB или другой инфраструктуры) и при этом пользоваться всеми преимуществами SOA. Когда проект расширится, добавить ESB будет не сложнее, чем добавить его сейчас.

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

Answer 3

Вопрос в том, может ли это быть деловым событием, которое может волновать другие системы.Если я возьму случай с новым клиентом, возможно, маркетинговая система отправит им электронное письмо, и система заказов начнет обрабатывать заказ.

Если вы видите, что это происходит, я бы тогда использовал модель push pub / sub (http://www.eaipatterns.com/ObserverJmsExample.html) с использованием nservicebus. Все, что вам нужно сделать, - это создать обработчик для прослушивания нового сообщения клиента для каждогоПриложение, которое заботится, а затем в этом методе, делайте свое дело.

Кроме того ... то, что вы делаете, - это переход на SOA, но вам нужно еще несколько вещей, чтобы стать SOA. SOA - это философия архитектуры./ sub, о котором мы говорим, больше использует MoM.