Творческое использование MarshalByRefObject

Question

Я билась головой, пытаясь понять некоторые вещи. Итак, я ищу советы и материалы исследования (по ссылкам). Вот сценарий:

У нас есть библиотека (скажем, CommonLib), которая содержит ресурсы, необходимые для нескольких других приложений (например, AppA, AppB, AppC и т. Д.). Теперь, способ, которым это в настоящее время работает, является экземплярами AppA, проверяет, доступен ли определенный порт. Если это не так, то он запускает CommonLib («Эй, проснись») и служба запускается. Тогда AppA счастлив, и мы идем.

Итак, я провел много исследований по Remoting.Channels и пришел к выводу, что запускаю приложение, основанное на технологии, которая считается «устаревшей». Ну ... мне это не нравится. Честно говоря, WCF намного больше затрат, чем нам требуется, и не полностью реализован в Mono. Мы ориентируемся на мультиплатформенную совместимость (Windows, Mono, Linux), поэтому изучаем все варианты.

Идея удаленного взаимодействия возникла, во-первых, потому что мы хотели, чтобы CommonLib был гарантированно единичным экземпляром (насколько я понимаю, синглтон в значительной степени гарантированно является одиночным в пределах данного AppDomain - не стесняйтесь исправлять мне, если я ошибаюсь). Во всяком случае, я осознал силу удаленного взаимодействия и решил начать экспериментальную реализацию. Я был успешным в моем первоначальном использовании MarshalByRefObject. Но я обеспокоен дальнейшим внедрением этой устаревшей технологии.

Итак, со всем этим ... я рассматриваю, как я могу реализовать CommonLib (как хост-приложение) и, без удаленного взаимодействия, реализовать MarshalByRefObject через Stream, стандартный TCP-сокет или каким-либо другим способом. Я думаю, что вместо того, чтобы создавать AppA для запуска CommonLib, просто внедрите CommonLib в качестве базового приложения. Затем вы выбираете, какое приложение (на самом деле просто «размещенный» .dll) вы хотите использовать в CommonLib. Затем CommonLib загрузит этот .dll в платформу CommonLib вместе со всеми пользовательскими элементами управления, которые использует размещаемое приложение. Наряду с этой идеей, я бы отказался от требования (на данный момент), что CommonLib должен быть подлинным синглтоном.

Итак ... это деталь нашего сценария. Опять же, мой вопрос на самом деле состоит из 2 частей: (a) Какие технологии (ы) я должен исследовать, и (b) Нужно ли мне интересоваться унаследованным статусом технологии удаленного взаимодействия?

Любые другие советы, комментарии или вопросы приветствуются.

ОБНОВЛЕНИЕ 1: я начинаю с этого фрагмента . Это позволит мне загрузить файл (или скрипт) со списком установленных приложений (или плагинов). Я могу создать этот файл в формате XML или Binary. Когда новое приложение установлено, файл и путь могут быть добавлены. Хммм ... Мне не обязательно использовать MarshalByRefObject.

Answer 1

Хотя WCF может не быть как завершенный в Mono, Mono 2.6 предоставляет все необходимое для Silverlight / Moonlight, поэтому реализация на основе WCF должна быть вполне осуществимой. До тех пор, пока вы не попробуете ничего экзотического (разные транспорты, инспекторы и т. Д.), Этого будет более чем достаточно, чтобы обеспечить стек RPC, надежный между windows / mono / и т. Д.

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

Другой вариант - написать очень простой сокет-сервер; очень легкий, и вы могли бы использовать что-то вроде protobuf-net для обеспечения переносимой (кроссплатформенной) реализации сериализатора (вам не следует доверять BinaryFormatter между этими двумя - это ... бред).

Короче - я бы не стал строить вокруг MarshalByRefObject вообще ; Я бы написал служебный слой, что-то вроде:

interface IMyService {
    void Method1();
    int Method2(string s);
}

и абстрагируйте эти детали от абонента. Если вы в конечном итоге используете WCF, то это все , что вам нужно; и для существующей поддержки удаленного взаимодействия я написал бы реализацию IMyService, которая инкапсулирует (в частном порядке) всю историю MarshalByRefObject. То же самое, если я написал сокет-сервер.

Answer 2

Я не уверен, что .NET Remoting устарела WCF. Я думаю, что у них несколько разные варианты использования; WCF (намеренно) не имеет понятия «маршал по ссылке», потому что он предназначен для распределенных и (относительно) слабосвязанных приложений, которым может потребоваться избегать болтливых протоколов из-за задержки и т. Д. Если ваши компоненты естественно тесно связаны, задержка будет низкой, но производительность должна быть высокой, важно сохранять богатые типы .NET и т. д., тогда удаленное взаимодействие все еще может быть подходящим. В любом случае, я бы не беспокоился о том, чтобы быть «устаревшими», «унаследованными» технологиями, по крайней мере, в Windows / .NET, которые могли бы оставаться в течение достаточно долгого времени, если бы они получили приличное использование. Удаленное взаимодействие по-прежнему существует в последней (4.0) версии .NET.

Ничто из этого не означает, что удаленное взаимодействие обязательно является наилучшим образом подходящим для вашей ситуации ...