Вопрос о дизайне:Как я могу получить прозрачный доступ к механизму IPC?

Question

Я хочу сделать это (без определенного языка):

print(foo.objects.bookdb.books[12].title);

или это:

book = foo.objects.bookdb.book.new();
book.title = 'RPC for Dummies';
book.save();

Где foo на самом деле является службой, подключенной к моей программе через некоторый IPC, и для доступа к ее методам и объектам некоторый уровень фактически отправляет и получает сообщения по сети.

На самом деле я не ищу механизм IPC, поскольку есть из чего выбирать.Скорее всего, он будет основан не на XML, а скорее на s.й.например, буферы протоколов Google, dbus или CORBA.В чем я не уверен, так это в том, как структурировать приложение, чтобы я мог получить доступ к IPC точно так же, как к любому объекту.

Другими словами, как я могу создать ООП, которое прозрачно отображает границы процесса?

Не то чтобы это был вопрос дизайна, и я все еще работаю над довольно высоким уровнем общей архитектуры.Так что я пока не уверен, на каком языке это будет сделано.Однако C #, Java и Python, скорее всего, привыкнут.

Answer 1

Ты не должен этого делать! Для программистов очень важно видеть и чувствовать разницу между IPC / RPC и локальным вызовом метода в коде. Если вы сделаете так, чтобы им не приходилось думать об этом, они не будут думать об этом, и это приведет к очень плохо работающему коду.

Подумайте о:

foreach o, o.isGreen in someList { 
   o.makeBlue; 
}

Программист предполагает, что цикл занимает несколько наносекунд, вместо этого он занимает около секунды, если someList оказывается удаленным.

Answer 2

Я думаю, что способ сделать то, что вы запрашиваете, - это сделать так, чтобы вся объектная коммуникация рассматривалась как передача сообщений.Именно так объектные методы обрабатываются, среди прочего, в ruby и smalltalk.

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

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

Answer 3

Ознакомьтесь с RMI Java - вступительным словом Материал показывает, как вы можете иметь локальное определение удаленного объекта.

Хитрость заключается в том, чтобы иметь два класса с одинаковыми сигнатурами методов. Локальная версия класса - это фасад какого-то сетевого протокола. Удаленная версия получает запросы по сети и выполняет фактическую работу объекта.

Вы можете определить пару классов, чтобы клиент мог иметь

foo= NonLocalFoo( "http://host:port" )
foo.this= "that"
foo.save()

И сервер получает запросы метода set_this () и save () от клиентского соединения. Со стороны сервера (как правило) нетривиально, потому что у вас есть куча проблем с обнаружением и управлением экземплярами.