Сервисная ориентация или объектная ориентация - могут ли они сосуществовать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Your X should be made up of Ys. Each Y should be responsible for a single concept, and should be describable completely in terms of its interface. One Y can ask another Y to do something via an exchange of messages (per their specified interfaces).

In some cases, an X may be implemented by a Z, which it manages according to its interface. No X is allowed direct access to another X's Z.

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

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

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

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

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

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

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