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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Вкратце - я бы не строил вокруг MarshalByRefObjectвообще; Я бы написал сервисный слой, например:

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

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

Answer 2

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

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