В последнее время в моей компании проявился большой интерес к сервис-ориентированной архитектуре (SOA). Всякий раз, когда я пытаюсь понять, как мы можем это использовать, я всегда сталкиваюсь с ментальным блоком. Грубо:

  • Объектная ориентация гласит: «храните вместе данные и методы, управляющие данными (бизнес-процессами)»;

  • Сервис-ориентированность гласит: «держите бизнес-процесс в сервисе и передавайте ему данные».

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

У меня вопрос: какие шаблоны, архитектуры, стратегии и т. Д. Позволяют SOA и OO работать вместе?


Изменить. Ответы «ОО для внутренних компонентов, SOA для границ системы» прекрасны и полезны, но это не совсем то, что я имел в виду.

Допустим, у вас есть объект Account, в котором есть бизнес-операция Merge, которая объединяет его с другой учетной записью. Типичный объектно-ориентированный подход будет выглядеть так:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

В то время как эквивалент SOA, который я видел, выглядит так:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

В случае объектно-ориентированного подхода бизнес-логика (и осведомленность о сущности благодаря паттерну ActiveRecord) встроены в класс Account. В случае SOA объект Account на самом деле является просто структурой, поскольку все бизнес-правила скрыты в сервисе.

Могу ли я иметь одновременно многофункциональные функциональные классы и многоразовые службы?

41
Dan Vinton 14 Янв 2009 в 15:43
6
Привет, спасибо за отличный пост! В наши дни это меня смущает. Есть ли у вас дальнейшие выводы через 5 лет? На самом деле хочу знать. - Тони
 – 
尤川豪
30 Апр 2015 в 20:19

6 ответов

Лучший ответ

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

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

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

9
Jesse Pepper 14 Янв 2009 в 15:55
5
Спустя 8 лет после публикации этого ответа сервис-ориентированные архитектуры стали очень популярными, многие компании, такие как Netflix, Amazon, Uber, eBay и другие, перевели свои продукты из монолитов в микросервисы. Масштабируемость - причина номер один.
 – 
human
24 Дек 2017 в 14:30
1
Да, за эти 8 лет изменилось то, из чего обычно состоит SOA. Раньше это означало синхронные API-интерфейсы запроса-ответа без гарантированной упорядоченной доставки. Ситуация изменилась, и теперь это означает асинхронные API-интерфейсы, которые позволяют осуществлять потоковую передачу и значительно улучшают пропускную способность и общую производительность.
 – 
Jesse Pepper
25 Дек 2017 в 15:23

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

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

10
Avi 14 Янв 2009 в 16:08

SOA - хорошая архитектура для связи между системами или приложениями.

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

Ключевыми моментами здесь являются четко определенные службы с четко определенным интерфейсом. То, как на самом деле реализуются ваши сервисы, не имеет значения для SOA.

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

10
James Anderson 14 Янв 2009 в 16:14

Я считаю, что это неправильное понимание объектной ориентации. Даже в Java методы обычно не являются частью объектов , а являются их классом (и даже это "членство" не обязательно для объектной ориентации, но это другое тема). Класс - это просто описание типа, поэтому на самом деле это часть программы, а не данные.

SOA и OO не противоречат друг другу. Сервис может принимать данные, организовывать их в объекты внутри, работать с ними и, наконец, возвращать их в любом желаемом формате.

4
Svante 14 Янв 2009 в 16:32

Я слышал, как Джеймс Гослинг говорил, что SOA можно реализовать на COBOL.

Если вы прочитаете собственное описание Алана Кея происхождения ООП, оно описывает кучу маленьких компьютеров, взаимодействующих для выполнения чего-то полезного.

Рассмотрим это описание:

Ваш X должен состоять из Ys. Каждый Y должен отвечать за одну концепцию и должен быть полностью описан в терминах своего интерфейса. Один Y может попросить другого Y сделать что-то посредством обмена сообщениями (в соответствии с их указанными интерфейсами).

В некоторых случаях X может быть реализован Z, которым он управляет в соответствии со своим интерфейсом. Ни одному X не разрешен прямой доступ к Z другого X.

Думаю, возможны следующие замены:

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

Если вы думаете в первую очередь об инкапсуляции, сокрытии информации, слабой связи и интерфейсах «черный ящик», между ними есть немало общего. Если вы увязли в полиморфизме, наследовании и т. Д., Вы думаете о программировании / реализации вместо архитектуры, ИМХО.

4
Community 20 Июн 2020 в 12:12

Если вы позволите своим службам запоминать состояние, то их можно будет рассматривать как большие объекты с возможно медленным временем вызова.

Если им не разрешено сохранять состояние, тогда они просто, как вы сказали, - операторы данных.

Похоже, вы разделяете свою систему на слишком много служб. У вас есть письменные взаимно согласованные критерии разделения?

Внедрение SOA не означает выбросить все ваши объекты , а означает разделение вашей системы на большие многократно используемые блоки.

3
Andy Dent 14 Янв 2009 в 17:01