.
NET Remoting
Um estudo ao suporte de invocações em objectos remotos na plataforma .NET
Milton Moura
Faculdade de Ciências e Tecnologia
Universidade Nova de Lisboa
Pós-Graduação em Enga Informática
miltonmoura@gmail.com
RESUMO
Existe hoje em dia um número considerável de tecnologias
orientadas para a programação de sistemas de objectos dis-
tribuı́dos, como são exemplo disso o CORBA, o Java/RMI, o
DCOM e, mais recentemente, o .NET Remoting. Qualquer
uma delas oferece um agregado de serviços e funcionalidades
que diferem na sua abordagem e implementação, tornando-
as mais ou menos complexas e apropriadas para determina-
dos cenários de utilização.
Este trabalho resulta de uma análise ao suporte de in-
vocações em objectos remotos na plataforma de desenvolvi-
mento .NET, tendo como ambiente de execução a imple-
mentação multi-plataforma da especificação CLI denomi-
nada Mono, e pretende expor os vários aspectos dos serviços
disponbilizados pelo componente .NET Remoting, bem como
a sua arquitectura e funcionamento interno.
Numa vertente práctica, são apresentados alguns exemp-
los de diferentes técnicas normalmente utilizadas em ambi-
entes de sistemas de objectos distribuı́dos, com o objectivo
de oferecer assim uma visão comparativa deste suporte em
relação a outros já estudados.
1. INTRODUÇÃO
As tecnologias de suporte aos sistemas distribuı́dos de ob-
jectos permitem que componentes em execução numa de-
termina máquina sejam acedidos por aplicações ou objectos
em execução noutras máquinas distintas. Tecnologias como
o CORBA, o Java/RMI, o DCOM e o .NET Remoting são
exemplos de sistemas deste tipo e, apesar de estarem imple-
mentados de forma muito diferente e com funcionalidades
distintas, mantêm algumas semelhanças:
• Os objectos têm uma identidade única e podem ter um
estado de execução.
• A utilização de objectos remotos tem a mesma semãntica
dos objectos locais.
• Estão associados a um modelo de componentes, onde
os detalhes de implementação estão escondidos.
• Têm modelos de tolerância a falhas bem definidos.
A implementação de suporte à invocação de objectos re-
motos no .NET Remoting é semelhante à do Java/RMI [7]
em muitos aspectos, pois ambos têm como base a especi-
ficação de Birrel et al [2] para RPC’s (Remote Procedure
Calls), que introduziu os conceitos básicos utilizados nas
1
Ricardo Seabra
Faculdade de Ciências e Tecnologia
Universidade Nova de Lisboa
Licenciatura em Enga Informática
ricardo.seabra@gmail.com
infra-estruturas deste tipo, como os stubs, o processo de
marshaling e a IDL [1].
A restante plataforma .NET é constituı́da por um ambi-
ente controlado de execução de código, designado por CLR
(Common Language Runtime), um gestor de memória, re-
sponsável pela recolha automática de referências não uti-
lizadas, um sistema de tipos unificado (Common Type Sys-
tem) que permite a interoperabilidade entre objectos imple-
mentados em diferentes linguagens de programação, compi-
ladas por uma ferramenta que implemente a CLS (Common
Language Specification), e um conjunto de APIs, separados
em módulos lógicos, que enriquece o modelo de objectos base
fornecido [5].
2. .NET REMOTING
Integrado na especificação da plataforma Microsoft .NET,
o componente .NET Remoting permite o desenvolvimento
de aplicações distribuı́das, onde os objectos participantes
podem ser executados em máquinas e processos diferentes e
em dominios aplicacionais distintos.
Na génese do .NET Remoting está uma implementação
abstracta de comunicação entre processos que separa os ob-
jectos remotos e seus potenciais clientes do mecanismo de
comunicação entre si, tornando-se assim uma plataforma
flexı́vel e extensı́vel, onde os protocolos de comunicação e
formatos de serialização podem ser facilmente alterados. É
também agnóstica ao modelo da aplicação, possibilitando a
interoperabilidade entre aplicações Web, serviços de sistema
ou programas executados na consola.
A plataforma disponibiliza ainda um conjunto de serviços
comuns em ambientes de middleware, como o suporte à ac-
tivação de objectos remotos, gestão do seu ciclo de vida e
segurança nos canais de mensagens.
2.1 Meta-Modelo de Objectos
e Definição de Interfaces
O código executado na plataforma .NET tem vários nı́veis
de isolamento, sendo que num processo da CLR podem estar
em execução vários domı́nios aplicacionais. Em qualquer
domı́nio aplicacional são dadas as seguintes garantias:
1. Uma aplicação pode ser parada de forma indepen-
dente.
2. Uma aplicação não pode aceder directamente a código
e recursos de outra aplicação.
3. Uma falha na aplicação não afecta as restantes aplicações.
 4. A configuração da aplicação determina o local de onde
o código é carregado e a sua versão.
Um domı́nio aplicacional pode ainda ser dividido em con-
textos, que asseguram uma série de restrições e semântica de
segurança no acesso aos objectos que neles se encontrem em
execução. Por omissão, todo o domı́nio aplicacional contém
pelo menos um contexto, onde são criados todos os objec-
tos, excepto aqueles que necessitam de um novo contexto
especializado.
Figura 1: Nı́veis de isolamento da CLR.
2.1.1 Objectos
O .NET Remoting possbilita a invocação de métodos so-
bre objectos remotos, em execução num CLR host. É in-
diferente ao sistema a linguagem em que estão implementa-
dos os objectos servidores e objectos clientes, podendo esta
ser distinta. O sistema unificado de tipos da plataforma gere
a representação interna dos objectos e garante assim a sua
interoperabilidade.
A invocação remota de métodos depende da obtenção de
uma referência para o objecto remoto, referência esta que
contém uma série de meta-dados necessários para que o
cliente efectue a invocação de forma transparente, utilizando
uma semântica de acesso idêntica à dos objectos locais.
A obtenção dessa referência é levado a cabo através de um
canal de comunicações estabelecido com o servidor, desig-
nado por um URI (Universal Resource Identifier ) de acesso
único. Ao iniciar, é da responsabilidade do servidor registar
ambos estas propriedades na plataforma.
2.1.2 Tipos
Com o objectivo de possibilitar a interacção entre objectos
residentes em diferentes nı́veis de isolamento da plataforma,
os tipos de objectos objectos podem ser classificados de re-
motos ou não-remotos. Um tipo é considerado remoto se:
1. As suas instâncias podem atravessar os nı́veis de iso-
lamento da plataforma.
2. Outros objectos podem aceder a instâncias do tipo,
atravessando os nı́veis de isolamento da plataforma.
Qualquer tipo de objecto que não satisfaça estas pro-
priedades, é não-remoto.
2
Os tipos de objectos remotos podem ser classificados de
acordo com três categorias: marshal-by-value, marshal-by-
reference ou context-bound. As instâncias dos tipos marshal-
by-value podem ser enviadas entre domı́nios aplicacionais
através de um processo de serialização, que corresponde à
codificação do estado actual de um objecto numa sequência
de bits. A recepção de um objecto deste tipo resulta na
criação de uma cópia no destino, com o mesmo estado do
objecto original. Os objectos deste tipo são caracteriza-
dos por um atributo especificado na sua definição, o atrib-
uto Serializable. No entanto, é possı́vel que um objecto
definido com este atributo contenha propriedades que não
se destinem a ser transmitidas. Para tal, deve-se colocar o
atributo NonSerializable no campo em causa.
Os objectos do tipo marshal-by-reference são utilizados
quando se pretende manter uma única instância desse tipo
acessı́vel num determinado domı́nio aplicacional, sendo pas-
sada uma referência dessa instância aos seus clientes, em
vez de uma cópia serializada. Assim, para que os objec-
tos possam ser acedidos remotamente, estes têm de derivar
do tipo MarshalByRefObject (ver Figura 2), de forma a su-
portar essa funcionalidade. As referências envolvidas neste
processo são objectos do tipo ObjRef.
[Serializable]
public abstract class MarshalByRefObject
{
protected MarshalByRefObject () { }
internal Identity GetObjectIdentity (
MarshalByRefObject obj,
out bool IsClient
);
[NonSerialized]
internal ServerIdentity ObjectIdentity
{ get; set; }
public virtual ObjRef CreateObjRef (Type type);
public virtual object GetLifetimeService ();
public virtual object InitializeLifetimeService ();
}
Figura 2: Excerto da classe MarshalByRefObject
Por último, os tipos context-bound constituem uma espe-
cialização do objecto remoto tı́pico, passado por referência,
que neste caso está restrito ao contexto de execução em que
é instanciado. Isto significa que o seu acesso, inclusive a par-
tir do mesmo domı́nio aplicacional, envolve sempre o envio
de uma referência remota para os objectos clientes, em vez
da invocação local normal que seria de esperar em situações
deste tipo. Essa funcionalidade é adquirida derivando do
tipo ContextBoundObject.
Os restantes tipos não-remotos definidos para a plataforma
.NET são suportados pela API de Remoting de forma trans-
parente, possibilitando a utilização de qualquer classe, in-
terface, enumeração e objecto, sem quaisquer limitações.
Partindo do princı́pio que tanto os clientes como os ob-
jectos servidor estão contidos em plataformas de execução
idênticas, isto é, em CLRs baseadas numa mesma versão
de implementação, a interoperabilidade a nı́vel de tipos de
dados está solucionada à partida.
2.1.3 Atributos
Um tipo de objecto remoto pode definir atributos, desig-
nados por propriedades na plataforma .NET, e especificar se
estes são só de leitura ou de leitura e escrita. No entanto, a
sua implementação interna, forma de acesso e representação
são em tudo idênticas aos dos métodos.
interface IRemoteObject
{
int MyRemoteMethod();
// propriedade só de leitura
double MyFloatProperty { get; }
// propriedade de leitura-escrita
int MyIntProperty { get; set; }
}
Figura 3: Exemplo de definição de propriedades
2.1.4 Operações
Designados por métodos, as operações em Remoting po-
dem ser invocadas desde que declaradas como públicas na
implementação do tipo de objecto remoto. Caso o objecto
remoto seja uma implementação de um ou mais interfaces,
então todos os métodos implementados, necessários para
satisfazer o contrato, são públicos.
A semântica de invocação das operações remotas é muito
semelhante à dos métodos locais, uma vez que os parâmetros
podem ser passados por referência ou por valor. A pas-
sagem de um parâmetro por referência significa que é pas-
sado um apontador com a informação necessária para que
a operação o manipule, tal como a sua localização e outros
dados necessários. A passagem de objectos por valor resulta
na criação de uma cópia no contexto de execução do método
invocado, idêntica à do objecto submetido.
No entanto, quando estão envolvidos objectos remotos, a
sua passagem como parâmetro de um método remoto de-
pende do seu tipo, mais precisamente, se este é marshal-by-
reference ou marshal-by-value.
2.1.5 Invocações
A semântica de invocações nesta plataforma é do tipo at-
most-once, o que significa que a recepção de uma excepção
resultante de uma invocação remota indica que o método
alvo poderá não ter sido executado. Por outro lado, a inex-
istência de erros constitui uma garantia de que a operação
foi executada com sucesso no objecto remoto.
Podem ser efectuados três tipos diferentes de invocações
sobre objectos remotos: sı́ncronas, assı́ncronas, e assı́ncronas
num só sentido (oneway). O modo sı́ncrono consiste no blo-
queio do cliente, após a invocação, até que alguma resposta
ou excepção seja enviada pelo servidor ou pela plataforma.
Para fazer face ao potencial fraco desempenho das chamadas
sı́ncronas, o .NET Remoting suporta um mecanismo de in-
vocações assı́ncronas, assente na utilização de delegates. Os
delegates fornecem um mecanismo de callback com verificação
de tipos, permitindo a invocação assı́ncrona de operações lo-
cais ou remotas (ver Figura 4).
Assim, a invocação do método é feita em dois passos: em
primeiro lugar despoleta-se a invocação da operação remota
a partir do método BeginInvoke(). Este método retorna
um objecto IAsyncResult que irá permitir obter o valor de
3
delegate string MyDelegate(int myValue);
string DoSomething(int myValue);
MyDelegate md = new MyDelegate(DoSomething);
// invocaç~
ao assı́ncrona
IAsyncResult ar = md.BeginInvoke(
someValue, null, null);
// obtenç~
ao do resultado
string result = md.EndInvoke(ar);
Figura 4: Exemplo de invocação assı́ncrona
retorno da função. É também suportado um modo de in-
vocação assı́ncrona num só sentido, ou seja, os métodos não
podem possuir retorno ou parâmetros de saı́da.
Apesar de existir uma API de reflexão na especificação
da CLI (System.Reflection), esta não está integrada com
o Remoting de forma a possibilitar a invocação dinâmica
de operações. Está portanto limitada à invocação estática
e dependente do acesso à definição dos tipos dos objectos
num assembly local ou registado na GAC (Global Assembly
Cache).
2.1.6 Tratamento de erros
O tratamento de erros, à semelhança do que acontece
na restante plataforma, é efectuada através da propagação
de excepções, objectos do tipo Exception que deverão ser
definidos como serializáveis, de forma a poderem ser trans-
formadas e enviados pelos canais de comunicação definidos
entre os objectos remotos e clientes envolvidos. Em partic-
ular, os erros com origem na infra-estrutura de Remoting,
lançam apenas um tipo de excepção: o RemotingException.
Uma excepção deste tipo pode ser levantada por inúmeras
razões, entre as quais:
• É instanciado um tipo de objecto remoto que não deriva
de MarshalByRefObject.
• Especificação inválida do ponto de acesso de um tipo
de objecto remoto, isto é, o URI está mal formado.
• Protocolos de comunicação diferentes entre os clientes
e os objectos servidor.
• A invocação de operações sobre objectos remotos que
não estão em execução, nem foram activados.
2.1.7 Sub-tipos e herança múltipla
A plataforma .NET não suporta herança de múltiplas im-
plementações, mas suporta a herança de múltiplos inter-
faces. Assim, um tipo de objecto pode extender uma im-
plementação e implementar múltiplos interfaces.
Esta caracterı́stica permite que os objectos remotos sejam
sub-tipos da implementação MarshalByRefObject e que, ao
mesmo tempo, implementem interfaces não remotos.
2.1.8 Polimorfismo
O suporte ao polimorfismo está estaticamente restricto
pela herança de múltiplos interfaces. A qualquer objecto
do sistema está associado um tipo estático, sendo apenas
possı́vel atribuı́r a este instâncias de objectos cujo tipo estático
seja um super-tipo do objecto em questão. É possı́vel então localmente no objecto remoto e o seu resultado encapsulado
redefinir determinadas operações herdadas pelos sub-tipos numa mensagem que percorre o trajecto inverso.
e determinar a execução da operação correcta através de
mecanismos de late-binding.
Esta garantia de consistência da representação dos tipos
distribuı́dos e a coerência do modelo de objectos permite in-
stituir uma noção de polimorfismo distribuı́do, abrindo por-
tas ao suporte de migração de código entre domı́nios aplica-
cionais e contextos de execução distintos.

2.2 Arquitectura
Como a maioria dos sistemas de objectos distribuı́dos, o
.NET Remoting recorre ao modelo tradicional de suporte à
invocação de operações em objectos remotos, que consiste
na implementação dessas operações numa classe, por sua
vez instanciada num processo anfitrião, em execução num
local conhecido e acessı́vel aos clientes. Como o contexto de
execução do objecto remoto está isolado em relação ao do
cliente, a invocação dos métodos remotos tem de ser efectu-
ada através de um stub ou proxy, uma cópia local do objecto
remoto que adere à sua definição de tipo. A invocação destes
métodos expostos pelo proxy resulta no envio de mensagens
serializadas através da rede. As mensagens são transferidas
pelo canal de comunicação estabelecido entre o cliente e o
servidor, sendo efectuado o processo inverso de serialização
após a sua recepção no servidor e submetido (dispatched ) o
método para invocação no objecto remoto. O processo de
envio do resultado da invocação é análogo, mas em sentido
contrário.
Figura 5: Arquitectura das plataformas de suporte
a sistemas de objectos distribuı́dos.
Em particular, na infra-estrutura de Remoting, assim que
um cliente activa um objecto remoto, a plataforma cria uma
instância local da classe TransparentProxy, que contém uma
lista de todas classes e métodos dos interfaces do objecto re-
moto. Assim que esta classe é criada, todas as invocações
sobre ela são interceptados pelo runtime, de forma a de-
terminar a sua validade e a existência de uma instância do
objecto alvo no mesmo domı́nio aplicacional em que o proxy
está em execução. Se existir, então é feito um encamin-
hamento simples para o método invocado no objecto local.
Caso contrário, é criado um objecto do tipo IMessage, onde
são colocados os parâmetros submetidos ao método remoto
(caso existam), e encaminhada a mensagem para um ob-
jecto RealProxy, através do método Invoke(). Esta classe
é responsável pelo encaminhamento das mensagens para o
objecto remoto, através de canais registados no servidor.
Uma vez recebida a mensagem de invocação no domı́nio
aplicacional ou contexto de destino, o método é invocado
Figura 6: Entidades envolvidos na invocação de um
método remoto.
2.2.1 Referências Remotas
As referências para os objectos remotos, envolvidos no
processo descrito anteriormente, são do tipo ObjRef e contêm
toda a informação necessária para a criação dos proxys já
mencionados. A referência contém, entre outros dados, o
URI que constitui o ponto de acesso conhecido para o ob-
jecto em questão, uma série de meta-dados que descrevem o
tipo do objecto remoto, tal como o nome do assembly que
contém a sua implementação, a sua versão e chaves públicas,
entre outros. Dados acerca de todos os tipos da hierarquia
de derivação também são agrupados nesta referência e seri-
alizados de forma a serem enviados ao cliente. Ainda é in-
cluı́da informação relativa ao contexto de execução, domı́nio
aplicacional e processo que contém o objecto associado à re-
ferência, bem como a identificação do tipo de canal, endereço
e porta que deverão ser utilizados nos pedidos de invocação
remota.
2.2.2 Mensagens
Na base do suporte a invocações sobre objectos remo-
tos estão as mensagens, um tipo de objecto que abstrai o
processo de invocação de métodos de uma forma orientada
a objectos. Assim, uma mensagem pode encapsular a in-
vocação de métodos, argumentos de entrada e valores de
retorno, invocações a construtores de objectos, lançamento
de excepções, entre outros. Os objectos de mensagens im-
plementam o tipo IMessage e são serializáveis.
2.2.3 Canais
As mensagens são transmitidas entre os objectos interve-
nientes através de canais de comunicação estabelecidos na
altura de activação dos objectos remotos. Estes objectos
são extremamente extensı́veis e permitem a construção de
mecanismos de transporte suportados por uma variedade de

4
protocolos e formatos na transmissão dos dados. No entanto,
a plataforma disponibiliza apenas dois canais de transporte:
o HttpChannel e o TcpChannel. O HttpChannel, por defeito,
recorre ao SOAP (Simple Object Access Protocol ) para cod-
ificar as mensagens. O SOAP é um protocolo baseado em
XML, desenhado para permitir a invocação de procedimen-
tos remotos sobre HTTP, de forma a superar as restrições
impostas pelas firewalls em redes de larga escala. Em am-
bientes mais controlados, o TcpChannel verifica-se uma al-
ternativa mais eficaz, uma vez que, por defeito, utiliza um
formato binário, minimizando assim o tamanho das men-
sagens transmitidas e aumentando o desempenho da troca
de mensagens entre objectos.
Estes objectos implementam o interface IChannel e, de
modo a suportar tanto o envio como a recepção de da-
dos, também implementam os tipos IChannelReceiver e
IChannelSender.
Os canais têm a particularidade de serem constituı́dos
por uma série de objectos logicamente encadeados, conheci-
dos por sinks, que aceitam mensagens, isto é, objectos do
tipo IMessage, de um elemento anterior, efectuam alguma
operação sobre estas e submetem-nas ao próximo elemento
da cadeia de sinks.
Figura 7: Transformações de uma mensagem através
de um canal e da sua cadeia de sinks.
Um dos elementos mais importantes, e normalmente o
primeiro nesta cadeia de objectos, é o formatter sink, re-
sponsável pela serialização da mensagem propriamente dita,
preparando-a assim para ser transmitida pelo canal. Os ele-
mentos intermédios podem efectuar processamento adicional
sobre esta, sendo que o último elemento da cadeia fica então
encarregado de transportar a mensagem pelo fio, de acordo
com um protocolo de transporte especı́fico.
Nos canais apresentandos anteriormente, cada qual tem
o seu formatter apropriado. O HttpChannel utiliza um ob-
jecto do tipo SoapFormatter, enquanto que o TcpChannel
utiliza um BinaryFormatter.
Como já foi mencionado, todos estes componentes po-
dem ser extendidos. Em particular, podem ser introduzi-
dos novos elementos na cadeia de sinks, substituı́dos ou re-
movidos outros, de forma a manipular o processamento das
5
mensagens através do canal. Entre outros, poderia ser de-
senvolvido um sink para a encriptação de mensagens, outro
que guardasse um log de todas as mensagens trocadas en-
tre os objectos, ou ainda outro que exigisse algum tipo de
autenticação adicional por parte dos clientes envolvidos [4].
O desenvolvimento de novos formatters passa pela im-
plementação do tipo ISerializable, que contém apenas o
método GetObjectData(). Este método é chamado quando
é necessário serializar o objecto. Quando estão envolvi-
dos tipos não suportados por este método (por exemplo,
referências), a plataforma recorre a surrogates e surrogate
selectors.
2.2.4 Activação
A plataforma suporta a activação de objectos remotos a
partir dos cliente ou do próprio servidor. A activação por
parte do servidor é normalmente utilizada quando os objec-
tos envolvidos não têm necessidade de manter o seu estado
entre diferentes operações, enquanto que, por outro lado, a
activação a partir do cliente resulta numa instanciação do
objecto remoto a pedido do cliente, sendo a sua gestão do
tempo de vida feita através de um sistema de leases.
Assim, os objectos activados no servidor são geridos por
este, sendo instanciados apenas quando ocorre a primeira
invocação por parte de um cliente. Este tipo de objectos
apenas suporta construtores sem parâmetros e têm a sua
localização bem definida e conhecida, uma vez que estão
associados a um URI. Podem ser de dois tipos distintos:
Singleton ou SingleCall.
Os objectos do tipo Singleton baseam-se no padrão de
desenho com o mesmo nome e portanto dizem respeito a
tipos de objectos que são instanciados uma única vez e com
um único ponto global de acesso durante o seu perı́odo de
execução [3]. Tal como os restantes tipos de objectos remo-
tos, estes também têm um tempo de vida pré-determinado,
o que significa que os seus clientes não obterão necessari-
amente sempre uma referência para a mesma instância da
classe remota. Este aspecto tem implicações na gestão do
estado destes objectos e pode ser contornado, forçando a
manutenção do objecto em memória, enquanto o domı́nio
aplicacional do servidor estiver em execução, através de uma
lease nula. Assim, é possı́vel que este objecto mantenha um
determinado estado entre invocações e que este seja mod-
ificado ou obtido por diferentes clientes. No entanto, este
tipo de interacção com objectos Singleton deve ser efectu-
ada com alguma precaução, uma vez que o seu acesso não
é sincronizado, podendo servir dois clientes concorrentes em
threads de execução diferentes.
Os tipos remotos SingleCall têm sempre uma instância
por pedido, de modo que cada invocação por parte de um
cliente é servida por uma instância diferente, com um estado
distinto.
Os objectos activados pelos clientes são instanciados a
partir do momento em que este cria um novo objecto do tipo
remoto pretendido, com o operador new ou com o método
Activator.CreateInstance(). Neste cenário, o cliente pode
participar na gestão da vida do objecto remoto, utilizando
as já mencionadas leases. Também possibilita a instan-
ciação parametrizada bem como a manutenção do estado
do objecto por cliente, uma vez que cada cliente tem a sua
instância distinta do objecto remoto em execução no servi-
dor.
2.3 Heterogeneidade
A plataforma em estudo resolve de forma elegante e eficaz
os problemas associados à heterogeneidade, normalmente
discutidos nos sistemas de objectos distribuı́dos.
2.3.1 Linguagens de Programação
A existência de um sistema de tipos comum, que garante
a interoperabilidade e integração dos tipos, através da im-
posição de regras e especificação de um modelo de objectos
comum, resolve o problema da utilização de várias lingua-
gens de programação no processo de desenvolvimento.
Todo o código produzido por uma linguagem que esteja es-
pecificada de acordo com o Common Type System é traduzido
para uma linguagem intermédia comum, que mais tarde é
interpretada pelo runtime e transformada em código nativo.
2.3.2 Representação dos dados
Uma vez que o código nativo é executado em runtimes de-
vidamente condicionados e baseados na mesma implementação,
a heterogeneidade na representação dos dados não é um
problema, desde que o ambiente de execução seja comum,
isto é, tenha como base a mesma versão de uma determinada
implementação da CLI.
A utilização de diferentes implementações e versões de
uma ou mais CLI’s não garante a representação homogénea
dos dados, uma vez que a estrutura interna dos tipos pode
ter sido alterada, tornando-as efectivamente incompatı́veis.
2.4 Localização
A designação de serviços remotos na plataforma consiste
na atribuição de URIs bem conhecidos aos objectos e são
definidos na fase em que estes são registados na plataforma.
O registo de objectos é normalmente realizado pela aplicação
que os instancia, registando os canais de comunicação através
de operações disponibilizadas pela classe ChannelServices e
os objectos remotos através da classe RemotingConfiguration.
O registo de um objecto remoto só é possı́vel mediante a
seguinte informação:
1. o nome do tipo do objecto remoto.
2. o URI que o designa.
3. o tipo de activação.
No caso dos objectos activados pelo servidor, esse URI é
fixo e conhecido, enquanto que nos objectos activados pe-
los clientes, esse URI é gerado e relativo a uma instância
particular do tipo de objecto no servidor.
// registo de um canal de comunicaç~
ao
TcpChannel channel = new TcpChannel(4321);
ChannelServices.RegisterChannel(channel);
// registo do tipo de objecto remoto
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(MyRemoteObject),
"MyRemoteObjectUri",
WellKnownObjectMode.Singleton
);
Figura 8: Registo tı́pico de um objecto remoto.
6
2.5 Gestão do Ciclo de Vida
Nesta plataforma, a problemática relativa à gestão do ciclo
de vida dos objectos é solucionada com recurso à utilização
de leases e sponsorships que, uma vez associadas aos objec-
tos remotos, evitam que estes sejam recolhidos pelo mecan-
ismo local de recolha de lixo. A excepção a este cenário
reside nos objectos single-call activados no servidor, que são
desactivados imediatamente após uma invocação sobre as
suas operações.
2.5.1 Leases e Sponsors
Tal como os restantes sistemas de objectos distribuı́dos,
em .NET Remoting a gestão de ciclo de vida está associada
ao mecanismo de recolha de lixo, que mantém informação
acerca dos objectos em utilização pelos clientes. Quando
um objecto deixa de ser referenciado pelos clientes, é recol-
hido e eventualmente destruı́do, sendo libertada a memória
anteriormente atribuı́da.
Este processo é eficaz num cenário onde as aplicações par-
tilham o mesmo processo de execução (a mesma CLR). Num
cenário distribuı́do, a situação é diferente, uma vez que um
objecto pode não ter clientes locais, mas sim clientes que
estão em execução em processos e máquinas diferentes, onde
a recolha prematura de um objecto resultaria na invalidação
da referência remota possuı́da pelos clientes.
A solução implementada na plataforma .NET envolve a
utilização de leases e funciona da seguinte forma: o acesso
a um objecto no servidor por parte de um cliente resulta
na associação deste a um objecto lease, que mantêm, entre
outras propriedades, um perı́odo de tempo durante o qual
o objecto servidor não deverá ser recolhido. O lease man-
ager, responsável pela gestão das associações entre objectos
e leases, dá inı́cio à contagem decrescente do tempo de lease
a partir do momento em que a primeira referência é envi-
ada para fora do seu domı́nio de execução. Esta entidade
também mantém uma referência para o objecto servidor,
evitando assim a sua recolha para destruição. Uma vez ex-
pirada a lease de um objecto, a CLR assume que não existem
clientes a utilizar referências remotas e descarta também a
sua referência local [6].
No entanto, não são dadas garantias de que não exis-
tam ainda clientes que possuam referências para os objec-
tos remotos. É então necessário providenciar uma forma de
estes poderem extender as leases. Aqueles clientes que pre-
cisam de ser contactados quando o tempo de vida de um
objecto remoto termina devem recorrer a um objecto spon-
sor, registando-o na lease respectiva. Assim, o gestor de
leases percorre a lista de sponsors associada à lease do ob-
jecto em questão e identifica se há ou não necessidade de
extender o seu tempo de vida.
2.5.2 Propriedades das Leases
Uma lease é instanciada com valores atribuı́dos por omissão
às suas propriedades (ver Figura 9), mas que podem ser al-
terados antes de serem registados os objectos no servidor,
quer programaticamente, quer através dos ficheiros de con-
figuração da aplicação.
A propriedade RenewOnCallTime tem um valor de tempo
adicional que é automaticamente acrescentado ao tempo de
vida do objecto caso sejam invocados métodos sobre este,
perto da expiração da sua lease. Esta renovação do tempo
de lease só é efectuada caso o restante tempo de vida do
objecto seja inferior ao valor atribuı́do à propriedade anteri-
public sealed class LifetimeServices
{ designado por ADO.NET.
TimeSpan LeaseManagerPollTime { get; set; }
TimeSpan InitialLeaseTime { get; set; }
TimeSpan RenewOnCallTime { get; set; }
TimeSpan SponsorshipTimeout {get; set; }
static LifetimeServices()
{
LeaseManagerPollTime = TimeSpan.FromSeconds(10);
LeaseTime = TimeSpan.FromMinutes(5);
RenewOnCallTime = TimeSpan.FromMinutes(2);
SponsorshipTimeout = TimeSpan.FromMinutes(2);
} dos de invocações remotas facultado, expressos sob a forma
} de mensagens SOAP. Este protocolo especifica um formato
Figura 9: Classe LifetimeServices
ormente mencionada, evitando assim que um objecto remoto
que seja bastante solicitado pelos seus clientes aumente pro-
gressivamente o seu tempo de vida.
A propriedade LeaseManagerPollTime indica a duração
do intervalo de tempo que deverá decorrer entre a verificação
dos tempos das leases, que por omissão é de 10 segundos,
enquanto que a propriedade SponsorshipTimeout especifica
o tempo que o servidor deverá esperar por respostas dos
clientes remotos quando inquire estes acerca do estado da
sua sponsorship. Esta propriedade é importante pois é a
partir deste valor que são toleradas falhas de comunicação
com os clientes, sendo estes removidos da lista de sponsors
da lease caso não respondam dentro do intervalo de tempo
estabelecido.
Um objecto remoto pode também alterar as propriedades
do seu ciclo de vida após a sua instanciação, fornecendo uma
implementação para o método InitializeLifetimeService
e devolvendo um objecto do tipo ILease.
2.5.3 Sponsors
Como foi referido anteriomente, um sponsor é utilizado
para possibilitar um pedido de renovação do lease por parte
do cliente, quando este está prestes a expirar. Este processo
de renovação envolve a invocação do método Renewal no
objecto sponsor, pelo gestor de leases.
Uma vez que os objectos sponsor estão associados aos
clientes e têm de ser registados no servidor, terão de derivar
da classe MarshalByRefObject e ser enviados por referência,
ou então marcados como Serializable e enviados por valor.
Na primeira hipótese, o cliente deverá garantir a manutenção
de uma referência para este objecto remoto e remover o
seu registo quando já não for necessário, ganhando nesta
situação a vantagem de poder controlar as suas decisões com
base em eventos ou propriedades associadas ao cliente. Por
outro lado, se o objecto sponsor for enviado por valor, é cri-
ada uma cópia no servidor que, apesar de ser transferida de
forma mais eficiente , apenas poderá basear as suas decisões
nas propriedades do servidor.
2.6 Persistência
O suporte ao armazenamento de tipos de objectos num
repositório de dados persistente não constitui um serviço in-
trinsecamente ligado ao .NET Remoting, mas está presente
na plataforma .NET como um componente genérico para o
7
tratamento e persistência de estruturas de dados relacionais,
Esta API em conjunto com o processo de serialização
de objectos já abordado, poderia estar na base da imple-
mentação de um serviço de persistência orientado para o
armazenamento dos objectos remotos, particularmente útil
na salvaguarda a longo-prazo do estado de execução de servi-
dores.
2.7 Interoperabilidade
A interoperabilidade da plataforma .NET Remoting em
relação a outros sistemas de objectos distribuı́dos assenta
sobretudo no protocolo SOAP e no mecanismo de pedi-
XML normalizado, que permite a inclusão de definições de
tipos e dados estruturados, independente da plataforma e
linguagem de programação utilizadas. Esta possibilidade de
oferecer serviços web, baseados em XML, a clientes poten-
cialmente desenvolvidos sobre outras plataformas e arqui-
tecturas, garante que as mensagens podem ser trocadas e
entendidas entre sistemas diferentes, escondendo assim os
detalhes de implementação dos serviços remotos.
2.8 Configurabilidade
De forma a introduzir alguma flexibilidade na configuração
dos serviços oferecidos pelos objectos remotos, a plataforma
suporta o carregamento de determinadas propriedades a par-
tir de ficheiros, sem ser necessário recompilar o código.
É possı́vel então especificar num ficheiro de configuração
a porta e o tipo de canal utilizado no estabelecimento de
ligações ao objecto remoto, o seu modelo de activação, o
URI de acesso, entre outras propriedades importantes (ver
Figura 10).
<configuration>
<system.runtime.remoting>
<application name="MyServer">
<service>
<wellknown mode="Singleton"
type="MyServerImpl, MyServerLib"
objectUri="MyURI" />
</service>
<channels>
<channel ref="tcp" port="8080" />
</channels>
</application>
</system.runtime.remoting>
</configuration>
Figura 10: Exemplo de um ficheiro de configuração
2.9 Ambientes de Execução
Uma vez que os objectos remotos só podem ser activa-
dos após efectuado o seu registo e o dos seus canais de
comunicação, esse processo deverá ser efectuado por uma
aplicação designada para esse fim. Essa aplicação deverá
estar em execução durante todo o ciclo de vida dos objectos
registados.
Em ambientes Microsoft Windows, essa aplicação pode
ser substituı́da por um serviço genérico desenvolvido com
esse objectivo, ou então associada a um de dois serviços
já existentes: o IIS (Internet Information Services) ou aos
serviços COM+.
2.9.1 Integração no IIS
O IIS é um servidor web e normalmente está sempre em
execução num ambiente Windows. Como tal, presta-se a ser
um bom anfitrião aos componentes remotos que se querem
disponibilizar, apesar de estar limitado à utilização de canais
HttpChannel. Por outro lado, possibilita uma configuração
rápida das restrições de segurança impostas aos componentes
e a alteração da sua configuração sem ser necessário re-
iniciar o serviço.
2.9.2 Integração nos serviços COM+
Outra opção passa por tirar partido das funcionalidades
oferecidas pelo ambiente COM+, tais como o suporte a
transacções distribuı́das, segurança baseada em roles, e pool-
ing de objectos. Um componente remoto pode participar
do contexto de execução dos serviços COM+ derivando da
classe ServicedComponent. Esta classe, e o espaço de nomes
System.EnterpriseServices, possibilita a utilização de atrib-
utos particulares ao COM+ num objecto em execução na
CLR e a todos os benefı́cios que daı́ resultam.
3. EXEMPLOS
Procedeu-se ao desenvolvimento de um conjunto de exem-
plos simples, demonstrativos das funcionalidades disponibi-
lizadas pelo infra-estrutura de Remoting, sobre uma imple-
mentação da CLI open source e compatı́vel com sistemas
UNIX, designada por Mono e disponı́vel em http://www.mono-
project.com/.
Esta distribuição implementa toda a funcionalidade da
versão 1.1 da plataforma .NET disponı́vel para sistemas op-
erativos Microsoft Windows e ainda extende a distribuição
base com uma série de módulos adicionais. É composta
por uma máquina virtual, que constitui o ambiente con-
trolado de execução das aplicações, um compilador just-in-
time, para a linguagem intermédia, uma API que reproduz
as Framework Class Libraries da Microsoft e um compilador
de C#.
São apresentadas, no apêndice deste documento, listagens
de alguns dos exemplos desenvolvidos, sendo que os restantes
estarão disponı́veis num ficheiro que deverá acompanhar este
trabalho.
4. CONCLUSÕES
A infra-estrutura de Remoting, integrada na plataforma
.NET, apresenta caracterı́sticas comuns a outros sistemas de
objectos distribuı́dos, não alheio ao facto de esta ter sido a
abordagem mais recente ao suporte de invocações em objec-
tos remotos e toda a problemática em redor.
Tal como o CORBA, DCOM e Java/RMI, em Remoting
é possı́vel solicitar a execução de operações em objectos res-
identes noutros contextos de execução, num ambiente dis-
tribuı́do. À semelhança do Java/RMI, a inclusão no modelo
de objectos de objectos não-remotos exige uma diferenciação
no seu tratamento a nı́vel de tipos, e, como nos sistemas
acima mencionados, todo o objecto remoto é identificado a
partir de uma referência que assegura a transparência de
localização.
A Common Type System estabelece a separação entre a
noção de interfaces e implementações, e define regras para
8
a interoperabilidade entre objectos desenvolvidos em difer-
entes linguagens, possibilitando a execução e comunicação
entre estes num ambiente CLI, onde o tratamento de erros
estabelecido segue um modelo at-most-once.
A utilização de proxys como mecanismo de atingir um
modelo de transparência de acesso é comum a todos os sis-
temas referidos, sendo de realçar que em Remoting, a criação
e manipulação dos objectos deste tipo é completamente in-
visı́vel para o utilizador ou programador.
O mecanismo de leases constitui o modelo de recolha de
objectos para os quais já não existem referências e estão
também implementadas variadas formas de suporte à ac-
tivação dinâmica dos objectos servidores.
Em suma, a infra-estrutura de Remoting tem bastantas
semelhanças com a do Java/RMI, mas oferece de raiz, em
determinados aspectos, mais funcionalidades associadas ao
tratamento dos objectos remotos, e na configuração e ex-
tensão dos canais de comunicação. A interoperabilidade com
outras plataformas através de protocolos como o SOAP e
HTTP evidencia também uma abertura para a integração
entre sistemas com diferentes implementações.
5. REFERÊNCIAS
[1] W. Emmerich. Engineering Distributed Objects. John
Wiley and Sons, Ltd, 2000.
[2] B. et al. Network Objects. DIGITAL, Inc., 1995.
[3] G. et al. Design Patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley, 1995.
[4] M. et al. Microsoft .NET Remoting. Microsoft Press,
2003.
[5] E. International. Standard ECMA-335: Common
Language Infrastructure. ECMA International, 2005.
[6] J. Lowy. Managing the lifetime of remote .net objects
with leasing and sponsorhip. MSDN Magazine,
Dezembro 2003.
[7] SUN. Java RMI Specification. Sun Microsystems, Inc.,
1998.
APÊNDICES
A. LISTAGENS
Apresentamos em seguida implementações de alguns ex-
emplos desenvolvidos no âmbito de uma demonstração das
capacidades da plataforma .NET Remoting, conforme de-
talhadas no texto.
A.1 Hello World - Client Activated
A.1.1 RemoteObject.cs
using System;
using System.Runtime.Remoting;
namespace com.mgcm.net.remoting
{
public class RemoteObject : MarshalByRefObject
{
public RemoteObject()
{
}
public string HelloWorld()
 { using System;
return "Hello World!"; using System.Runtime.Remoting;
} using System.Runtime.Remoting.Channels;
} using System.Runtime.Remoting.Channels.Tcp;
}
namespace com.mgcm.net.remoting
A.1.2 RemoteServer.cs {
public class RemoteClient
using System; {
using System.Runtime.Remoting; public static int Main(string[] args)
using System.Runtime.Remoting.Channels; {
using System.Runtime.Remoting.Channels.Tcp; TcpChannel tcp = new TcpChannel();
ChannelServices.RegisterChannel(tcp);
namespace com.mgcm.net.remoting
{ RemoteObject obj = (RemoteObject)
public class RemoteServer Activator.GetObject(
{ typeof(com.mgcm.net.remoting.RemoteObject),
public static int Main(string[] args) "tcp://localhost:8080/HelloWorld");
{
TcpChannel tcp = new TcpChannel(8080); Console.WriteLine(obj.HelloWorld());
ChannelServices.RegisterChannel(tcp); return 0;
}
RemotingConfiguration.RegisterWellKnownServiceType( }
typeof(RemoteObject), }
"HelloWorld",
WellKnownObjectMode.SingleCall); A.3 Execução de Código Móvel

System.Console.WriteLine("server running..."); A.3.1 Interfaces.cs

System.Console.ReadLine();
return 0; namespace com.mgcm.net.remoting
} {
} public interface ITask
} {
void exec();
A.1.3 RemoteClient.cs }

public interface IAgent

using System;
{
using System.Runtime.Remoting;
void run();
using System.Runtime.Remoting.Channels;
}
using System.Runtime.Remoting.Channels.Tcp;
public interface IAgentHost
namespace com.mgcm.net.remoting
{
{
void accept(IAgent agent);
public class RemoteClient
}
{
}
public static int Main(string[] args)
{ A.3.2 Tasks.cs
TcpChannel tcp = new TcpChannel();
ChannelServices.RegisterChannel(tcp); using System;

RemoteObject obj = (RemoteObject) namespace com.mgcm.net.remoting

Activator.CreateInstance( {
typeof(com.mgcm.net.remoting.RemoteObject)); [Serializable]
public class TaskHello: ITask
Console.WriteLine(obj.HelloWorld()); {
return 0; public TaskHello():base()
} {
} }
}
public void exec()
A.2 Hello World - Server Activated {
System.Console.WriteLine("Hello World");
A.2.1 RemoteClient.cs }

9
 } A.3.4 Agent.cs
[Serializable] using System;
public class TaskDateNow: ITask
{ namespace com.mgcm.net.remoting
public TaskDateNow():base() {
{ [Serializable]
} public class Agent: IAgent
{
public void exec() private ITask task;
{
System.Console.WriteLine(DateTime.Now); public Agent(ITask task)
} {
} this.task = task;
} }
A.3.3 AgentHost.cs public void run()
using System; {
using System.Runtime.Remoting; task.exec();
using System.Runtime.Remoting.Channels; }
using System.Runtime.Remoting.Channels.Tcp; }
using System.Collections; }
using System.Threading; A.3.5 Server.cs
namespace com.mgcm.net.remoting using System;
{ using System.Runtime.Remoting;
public class AgentHost: MarshalByRefObject, using System.Runtime.Remoting.Channels;
IAgentHost using System.Runtime.Remoting.Channels.Tcp;
{
private Stack agents; namespace com.mgcm.net.remoting
{
public AgentHost() public class Server
{ {
agents = new Stack(); public static void Main(string[] args)
{
Thread t = new Thread( int port = 8080;
new ThreadStart(execAgents) TcpChannel channel = new TcpChannel(port)
); ChannelServices.RegisterChannel(channel);
t.Start();
} RemotingConfiguration.RegisterWellKnownServiceType(
typeof(AgentHost),
public void accept(IAgent agent) "AgentHost",
{ WellKnownObjectMode.Singleton
agents.Push(agent); );
}
System.Console.ReadLine();
public void execAgents() }
{ }
while (true) }
{
if (agents.Count > 0) A.3.6 Client.cs
{
IAgent agent = (IAgent) agents.Pop(); using System;
Thread t = new Thread( using System.Runtime.Remoting;
new ThreadStart(agent.run) using System.Runtime.Remoting.Channels;
); using System.Runtime.Remoting.Channels.Tcp;
t.Start();
} namespace com.mgcm.net.remoting
System.Threading.Thread.Sleep(500); {
} public class Client
} {
} public static void Main(string[] args)
} {

10
 TcpChannel channel = new TcpChannel();
ChannelServices.RegisterChannel(channel);

IAgentHost host = (IAgentHost)

Activator.GetObject(
typeof(com.mgcm.net.remoting.IAgentHost),
"tcp://localhost:8080/AgentHost"
);

ITask task1 = new TaskHello();

ITask task2 = new TaskDateNow();
IAgent agent1 = new Agent(task1);
IAgent agent2 = new Agent(task2);

host.accept(agent1);
host.accept(agent2);
}
}
}

11