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

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

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

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

, Таким образом, Вы свободны реализовать свои сервисы uing все последнее и самое большое OO tequniques или любой другой methodoligy, который работает на Вас. (Я видел крайние случаи, где "сервис" является implmented фактическими людьми, вводящими данные по экрану - все же все было все еще SOA учебника!).

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

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

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

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

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

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

Это кажется, что можно делить систему на слишком много сервисов. Вы имеете записанными, взаимно согласованные критерии того, как разделиться?

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

Я услышал, что James Gosling говорит, что можно было реализовать SOA в КОБОЛе.

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

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

Ваши 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

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