Анти-шаблон SOA или WCF

Ответ 1

Я думаю, что ты прав. В моем текущем задании (веб-разработка) каждый доступ к базе данных реализуется как служба. Мы - "ЧИСТАЯ СОА", как сказал ведущий архитектор... Вау!

В фактах это добавляет много сложности ко всему. Когда я хочу прочитать содержимое простой таблицы, я должен сгенерировать что-то вроде 8 проектов, 42 файлов, 8 сборок и, возможно, 9 конфигурационных файлов!

Много сложностей, как я уже сказал. Скорее всего, кто-то где-то забудет один файл... Разоблачение простого процесса как службы глупо.

В моих книгах вы должны подвергать свои процессы службе, когда:

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

Также обратите внимание, что сервис должен быть DESIGNED для обслуживания, а проектирование службы по меньшей мере сложнее, чем проектирование библиотеки: улавливание ошибок должно быть тщательно обработано, регистрация должна быть достаточно гибкой, документация должна быть полной, и др.

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

Ну, очень интересный вопрос. 1 балл: o)

Ответ 2

SOA как концепция - отличная идея.

SOA, реализованная с использованием HTTP-WS/BPEL и др., - это шутка, которая заслуживает смерти в моем не очень скромном виде. Я прекратил принимать систему серьезно вскоре после изучения их единственной концепции распределенных транзакций - транзакции компенсации... bzzt NEXT!!

Ответ 3

Есть два основных анти-шаблона, о которых я знаю:

• Непосредственная экспозиция объектов с вашего бизнес-уровня через уровень обслуживания
• Предоставление определенных тонкодисперсных методов, например, в вашем бизнес-уровне.

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

Вот отличный совет на высоком уровне: http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines

Вот конкретный пример типа классов сообщений, о которых идет речь, и о том, как реализовать его в WCF: http://dotnet.org.za/hiltong/pages/windows-communication-foundation-tutorial-part-3-messaging-messagecontracts.aspx

Ответ 4

Я опубликовал несколько анти-шаблонов SOA

• Анти-паттерн транзакционной интеграции
• Узел анти-шаблона
• Наносервис анти-шаблон

Дело в том, что многие люди рассматривают SOA как установку переднего конца веб-сервиса перед логикой и забывают о последствиях полученного RPC (также известного как Ошибки распределенных вычислений)

Ответ 5

SOA - одна из худших представленных концепций. SOA является архитектурным стилем и не имеет ничего общего с веб-сервисами или любой технологией. Я согласен с тем, что объяснение SOA через веб-сервисы и BPEL является обманчивым, BPEL обычно не имеет ничего общего с SOA, но вместо этого является способом реализации WS-оркестровки. Продавцы сделали ужасный беспорядок.

Я предлагаю очень красивую загружаемую книгу, которая действительно объясняет, что такое SOA:

http://www.infoq.com/minibooks/enterprise-soa

Затем вы можете прочитать эту интересную запись в блоге

Привет