SOA: причины, по которым эмуляция поведения ESB в коде, безусловно, является худшим вариантом - PullRequest
Новая
       50

SOA: причины, по которым эмуляция поведения ESB в коде, безусловно, является худшим вариантом

2 голосов
/ 26 февраля 2012

У нас есть проект на основе SOA, который с самого начала был создан как слой веб-сервиса для хорошо зарекомендовавшего себя приложения.

ClientA -->                       
ClientB -->    ESB   -->   Atomic Services  -->   Established App (DB/NAS etc)
ClientC -->

У нас есть несколько сценариев, в которых услуга, предоставляемая ESB, состоит из нескольких атомарных вызовов, вызываемых последовательно с взаимодействиями, так что логически они делают что-то вроде этого: 

def composing_service(xmlrequest):
    output_of_decision_service = decision_service(xmlrequest)
    if (output_of_decision_service.matches("foo")):
        xmlresult = foo_service(xmlrequest)
    if (output_of_decision_service.matches("bar")):
        xmlresult = bar_service(xmlrequest)
    return xmlresult

Фактически эта логика была реализована с использованием XSLT-преобразований и запросов XPath, встроенных в реализацию ESB, которую мы купили.Это кажется проблематичным для меня по нескольким причинам:

  • Разработчики не могут тестировать составляющие сервисы (простая функциональность с точки зрения бизнеса) локально, поскольку реализация ESB слишком «тяжелая» для локального развертывания.Общее тестирование - это процесс интеграции.
  • Синтаксис XSLT, используемый для формирования этих и подобных блоков управления, не так удобен для чтения и недоступен, как код на общем языке программирования.(если ... тогда, еще, наконец, и т. д.) XSLT стал очень длинным и пугающим.
  • В некоторых сложных сценариях было бы полезно более тонкое управление, то есть компенсация неудачных вызовов путем вызова компенсирующей атомарной службы.чтобы откатить предыдущее действие.

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

Полагаю, это выглядело бы так: 

ClientA -->    ComposingServiceA     -->                   
ClientB -->    ComposingServiceB     -->   Atomic Services  -->   App
ClientC -->    ComposingServiceC     -->

Однако, читая здесь, я нашел следующее выражение без ссылки:

, эмулирующее поведение ESB в коде, дляКонечно, это худший вариант

К сожалению, это было оставлено как слепое изложение фактов (мнений) без каких-либо оснований.Однако это заставило меня вздрогнуть.Почему вышесказанное может быть правдой?Я был готов написать электронное письмо нашему архитектору, озвучив все вышеперечисленные проблемы, но этот комментарий заставляет меня задуматься, стоит ли мне это делать?

Почему эмуляция поведения ESB в коде, безусловно, худший вариант?

1 Ответ

1 голос
/ 28 февраля 2012

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

С точки зрения архитектуры, вы вправе хотеть разложить на «составные» сервисы.Это называется многоуровневое обслуживание и обычно приводит к трем слоям .Ваши атомарные сервисы соответствуют сервисам уровня сущности или сервисам более поздних сервисов , которые не зависят от бизнес-процессов и, как правило, достаточно многократно используются.Ваши сервисы создания обычно соответствуют сервисам уровня задач , которые составляют другие сервисы, относятся к определенному бизнес-процессу и, как правило, не используются повторно.

...