Uso criativo de marshalbyRefobject

Question

Eu estive batendo a cabeça tentando descobrir algumas coisas. Então, estou procurando conselhos e material de pesquisa (via links). Aqui está o cenário:

Temos uma biblioteca (digamos, Commonlib) que contém recursos necessários para vários outros aplicativos (digamos, APPA, APPB, APPC e assim por diante ...). Agora, a maneira como isso está funcionando atualmente são instâncias do Appa, verifica se a porta específica está disponível. Caso contrário, chuta o Commonlib ("Ei, acorde") e o serviço é iniciado. Então Appa está feliz e vamos lá.

Agora, fiz muitas pesquisas sobre os canais remotos. E cheguei à conclusão de que estou iniciando um aplicativo construído sobre uma tecnologia considerada 'legado'. Bem ... eu não gosto disso. Honestamente, o WCF é muito mais sobrecarga do que exigimos e não está totalmente implementado em Mono. Estamos direcionando a compatibilidade com várias plataformas (Windows, Mono, Linux), por isso estamos pesquisando todas as opções.

A idéia de remoção começou, em primeiro lugar, porque queríamos que o Commonlib fosse uma instância única garantida (como eu o entendo, um singleton é praticamente garantido apenas como um singleton dentro de um determinado appdomain - fique à vontade para me corrigir se eu 'Estou errado). De qualquer forma, percebi o poder do remoto e decidi iniciar alguma implementação experimental. Tive sucesso no meu uso inicial do MarshalbyRefobject. Mas estou preocupado com a implementação contínua dessa tecnologia herdada.

Então, com tudo isso ... estou considerando como posso implementar o Commonlib (como um aplicativo host) e, sem remoção, implementar o MarshalbyRefobject através do fluxo, soquete TCP padrão ou de outra maneira. O que estou pensando é que, em vez de instalar a Appa para que o Commonlib em execução, basta implementar o Commonlib como o aplicativo base. Em seguida, você seleciona qual aplicativo (realmente apenas um 'hospedado' .dll) que deseja instança no Commonlib. Commonlib, então carregaria isso .dll na estrutura Commonlib, juntamente com quaisquer controles personalizados que o aplicativo hospedado use. Junto com essa idéia, eu abandonaria o requisito (por enquanto) que o Commonlib deve ser um singleton genuíno.

Então ... isso é um detalhe do nosso cenário. Novamente, minha pergunta são realmente 2 partes: (a) Que tecnologia (s) devo pesquisar e (b) preciso me preocupar com o status herdado da tecnologia remota?

Qualquer outro conselho, comentários ou perguntas são mais do que bem -vindos.

Atualização 1: estou começando com Este trecho. Isso me permitirá carregar um arquivo (ou script) com uma lista de aplicativos (ou plug-ins) que foram instalados. Eu posso criar esse arquivo como XML ou formatado binário. Quando um novo aplicativo é instalado, o arquivo e o caminho podem ser adicionados. Hmmm ... eu não preciso necessariamente usar o MarshalbyRefobject.

Answer 1

Enquanto o WCF pode não ser como completo Em Mono, o Mono 2.6 fornece tudo o que é necessário para a Silverlight / Moonlight; portanto, uma implementação baseada no WCF deve ser perfeitamente viável. Desde que você não tente nada exótico (transportes diferentes, inspetores etc.), deve ser mais do que suficiente para fornecer uma pilha de RPC que seja confiável entre o Windows / Mono / etc.

A principal diferença entre o WCF e a remoção está em uso - A remoção é baseada em um objeto que finge estar em uma extremidade diferente, onde o WCF é baseado em um serviço; O ponto é que você deve basear suas interações em torno de métodos discretos (em vez de acessar propriedades etc.) - isso também tem a vantagem de ajudar a torná -lo explícito quando você está cruzando o limite.

Outra opção seria escrever um servidor de soquete muito básico; muito leve, e você pode usar algo como o Protobuf-Net para fornecer uma implementação portátil (plataforma cruzada) (você realmente não deve confiar BinaryFormatter entre os dois - é ... Flakey).

Em suma - eu não iria construir por aí MarshalByRefObject de forma alguma; Eu escreveria uma camada de serviço, algo como:

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

e abstrair esses detalhes longe do chamador. Se você acabar usando o WCF, isso é tudo você precisa; e para o suporte remoto existente, eu escreveria um IMyService implementação isso encapsula (particular) o todo MarshalByRefObject história. Idem se eu escrevi um servidor de soquete.

Answer 2

Não tenho certeza se o .NET remoto é obsoleto pelo WCF. Eu acho que eles têm casos de uso um pouco diferentes; O WCF (deliberadamente) não possui conceito de "marechal por referência" porque foi projetado para aplicativos distribuídos e (relativamente) acoplados frouxamente que podem precisar evitar protocolos de falador devido à latência etc. Se seus componentes forem naturalmente bem acoplados, a latência será baixa, mas O desempenho precisa ser alto, preservar os tipos ricos .NET é importante, etc. O remoto ainda pode ser um bom ajuste. De qualquer forma, eu não me preocuparia em ser "Tecnologias Legacy", "Legacy", pelo menos no Windows/.Net, têm uma maneira de ficar por perto por algum tempo, se conseguirem uma quantidade decente de uso. O remoto ainda existe na versão mais recente (4.0) do .NET.

Nada disso se entende como uma alegação de que remota necessariamente é O melhor ajuste para a sua situação ...