Подтвердить что ты не робот

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

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

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

  • Сервис-ориентация говорит: "Держите бизнес-процесс в сервисе и передавайте ему данные".

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

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

Изменить: Ответы, в которых говорится: "OO для внутренних компонентов, SOA для системных границ" являются большими и полезными, но это не совсем то, что я получаю.

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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