SOA Архитектура понимания

Question

Мне было предложено работать над проектом, основанным на SOA, используя WCF. Я работал с WCF (создание и потребление), но никогда с SOA. Правильно ли я говорю, что у одной службы будет обычный уровень уровня обслуживания, уровня бизнес-уровня и доступа к данным (если необходимо). Затем сервисный уровень выставляет методы.

Возможна ли услуга A Справочная служба B и служба B справочной службы A?

И тогда пользовательский интерфейс может получить доступ к этим услугам через ссылки - и это по существу SOA? Я борюсь за то, чтобы найти последние, последние уроки (Youtube), и «гиды», которые я вижу в Интернете, кажутся чрезвычайно сложными.

Answer 1

Этот Wikipedia entry довольно ясный, я думаю?

Попробуй простой пример. Скажем, у нас есть приложение Library, которое позволяет вам проверять книги.

Если вы посмотрите на «традиционный» не-SOA подход к решению систем многоуровневых то есть сервис под названием MyService, который имеет методы, называемые что-то вроде CheckOutBook. Это будет уходить и внутренне иметь класс и класс Лицо и будет произносить, скажем, Book.IsAvailable = False и Person.NumberOfBooks.

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

с помощью SOA вы бы книги обслуживания и обслуживания Person. Служба Person будет иметь действие, такое как Person.AssociateWithBook, которое могут использовать как библиотеки, так и BookShop без изменения, поскольку это достаточно просто, чтобы сделать минимум. Затем приложение обращается к правильному сервису (службам), чтобы выполнить требуемую работу. Это означает, что он может использоваться повторно, без необходимости изменять различные сервисы.

Это очень упрощенно, но, надеюсь, отображает архитектурные различия и вы идете?

Answer 2

Я бы пропустил вопрос о SOA, так как каждый из них может назвать SOA, что бы он ни понимал, SOA (Service Oriented Architecture). Я имею в виду, каждая архитектура, с использованием услуг, можно назвать SOA ...

С технической стороны, я бы построить его в следующем виде:

ИМО, услуги сами по себе должны иметь меньше логики, как они могут (например, фасадную схему), вся логика должна быть перенесена на бизнес-логику.

Служба A с использованием ServiceA.BusinessLogic, называет услугу B (прокси-сервер для службы B доступен для ServiceA.BL).

же для Service B, вызов службы А.

Это даст вам двунаправленную связь, без проблем дуплекса (сломанные обратных вызовов, ...).

Пользовательский интерфейс также должен получить доступ к службам - с помощью UI.BusinessLogic (обычно я предпочитаю думать об услуге связи как своего рода уровня доступа к данным передачи данных).