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

Question

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

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

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

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

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

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

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

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

Answer 1

В то время как WCF может не быть как завершенный в Mono Mono 2.6 предоставляет все необходимое для silverlight / moonlight, поэтому реализация на основе WCF должна быть вполне осуществимой.Пока вы не пробуете ничего экзотического (различные транспорты, инспекторы и т.д.), Этого должно быть более чем достаточно для обеспечения надежного стека RPC между Windows / mono / etc.

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

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

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

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

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

Answer 2

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

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