Как распределенные службы лучше распределенных объектов?

Меня не интересует технология, например. CORBA vs Web Services, меня интересуют принципы. Когда мы делаем ООП, почему мы должны иметь что-то такое процедурное на более высоком уровне? Разве это не то же самое, что с ООП и реляционными базами данных? Часто службы поддерживаются с помощью генерации кода, помимо шаблона, я думаю, что это потому, что мы новый SOM-сервисный объект mapper. Итак, каковы причины для вербовщиков, а не объектов?Как распределенные службы лучше распределенных объектов?

источник

2010-04-06 Gabriel Ščerbák

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

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

Итак, проблема заключается не в технологии или протоколе (двоичный, а в XML), а в сценариях использования. Вы можете создавать «сервисы» в CORBA и программировать распределенные объекты старой школы в WCF, но первые, кажется, более склонны к объектам, а последние - к услугам ...

источник

2010-04-07 02:39:43

Это похоже на реальный момент, но он по-прежнему не является реальным аргументом, потому что существует много концепций, которые более грубоваты и могут использоваться, а также сервисы, смоделированные с использованием объектов. –

ИМХО, есть небольшая разница на высоком уровне. Но на уровне реализации распределенные объекты, CORBA, Java RMI и т. Д. Оставляют желать лучшего. Я пытался работать с CORBA и позже RMI в реальных производственных системах, а синхронизация версий была кошмаром.

В эти дни я отправляю сообщения и получаю ответы.

источник

2010-04-06 22:18:05 fishtoprecords

Ок, отдельно забыть о технических трудностях, я спросил в этом вопросе и сказать мне, как различные отправляют сообщения на пути WS от передачи сообщений в распределенных объектах? –

Передача распределенного объекта означает, что вы передаете код и данные объекта. Когда я писал о передаче сообщения, я имел в виду передачу некоторых текстовых/строковых данных, которые можно разобрать/прочитать в Object на принимающей стороне. Его так же, как с помощью пакета RDBMS, а не с помощью собственного файла IO, с СУБД, кто-то еще может добавлять столбцы, индексы и т. Д., И ваш код не волнует. Когда вы передаете объекты, вы должны синхронизировать их определения. – fishtoprecords

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

Перемещение объекта по сети из местоположения в другое? В этом случае вы должны быть уверены, что «право собственности» правильно отказано. Как один хозяин знает, что другой изменил состояние объекта? Это должно быть - что - скопировано обратно?

Модель «распределенного объекта» быстро становится сложной.

Служба - в ее самом простом смысле - означает, что именно один хост предлагает обслуживание и поддерживает состояние. Реляционные базы данных на протяжении десятилетий демонстрируют эту модель услуг. Как и другие традиционные услуги (т. Е. Электронная почта, NIS и т. Д.)

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

«почему мы должны иметь что-то такое процедурное на более высоком уровне»

Вы не имеете что-то процедурную на более высоком уровне.

У вас есть объект (хост, предлагающий услуги) несколькими способами. Это совершенно объектно-ориентированный подход.

Это - вообще - a Singleton, что делает жизнь очень простой.

источник

2010-04-06 22:33:48

Согласен, реализация распределенных объектов может быть более сложной, но картографические швы для ее взвешивания. Кроме того, аргументами сервисов могут быть только чистые данные, нет объектов, поэтому он по-прежнему не будет выглядеть более непрозрачным для меня, даже с идеей singleton. Я не говорю, что службы и процессы неестественны, они лучше для многих случаев, как вы упомянули, но ООП заменил процедурное программирование на более низком уровне в основном использовании, поэтому я думаю, что разработчикам проще думать с точки зрения ООП так же, как и это для меня. –

@Gabriel Ščerbák: «Также аргументы для сервисов могут быть только чистыми данными, без объектов»: False. Аргументы могут быть сериализованными объектами. Услуги ** - это объекты **. Легко применять дизайн OO к услугам. Почему вы продолжаете повторять, что услуги - это просто процедуры? Это ** методы ** одноэлементного ** Объекта **. –

Иногда это может быть допустимый прецедент для использования объекта в качестве аргумента, но не из-за его данных, а его поведения. Как бы вы моделировали это с помощью сервисов? Каким образом поведение может передаваться в данные, переданные в качестве аргументов для служебных вызовов? Не могли бы вы передать в качестве аргумента какой-то URL-адрес другому синглтону? –

Распределенные объекты и удаленные вызовы процедур вроде как разделяемое состояние между процессами, в то время как службы самодостаточны.

Его можно сравнить с отношением между обычным ООП на общедоступном государственном языке и языком, использующим модель Актера, и не иметь общего состояния (например, в Эрланге, где у вас много легких процессов, которые не делят ничего, но только через сообщения). Модельный подход Actor намного менее сложный и может дать вам преимущества по сравнению с параллелизмом и т. Д.

источник

2010-04-07 05:30:49

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

Я просто попытался рассказать о предмете, рассматривая параллель с различием между «ванильным ООП» и моделью Актера. –

Vanilla OOP Я имею в виду основной OOP в C#/Java/что-то еще. OO - идея - больше, и согласно ppl, например, Alan Key, все должно было быть связано с сообщениями: «Мне жаль, что я придумал термин« объекты », это все о сообщениях». Erlang также является OO - идея - даже если нет классов или объектов. http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html –

Почему противопоставление? Понятия распределенных служб и распределенных объектов накладываются значительно, если не полностью (и SOAP - это объект протокол доступа, в конце концов). WCF является одним из примеров переключения между «веб-службой» и «удаленным объектом» с помощью одной строки конфигурации.

Разница в основном терминологическая, объясняется историческими областями применения.

(Шимона писал по существу того же eariler)

источник

2010-04-07 06:26:01 ima

Веб-сервисы были представлены мне как лучший способ распространения предыдущих технологий CORBA. Когда я попросил аргументы, были представлены только технические детали. ООП является ИМХО в настоящее время преобладающим (над процедурной оценкой), поэтому я смущен, почему вернуться на концептуальный уровень? SOAP давно потерял свое первоначальное значение.У меня нет опыта, но я буду вам верить в WCF, но разве он не отличается от микширования процедурного (стиль C) в C++ (OOP)? Мне кажется концептуально неправильным. Если бы объекты-участники (как упоминалось) были веб-службами, это имело бы смысл для меня. –

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

Как распределенные службы лучше распределенных объектов?

ответ

Смежные вопросы