DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da .net Magazine DIGITAL
ou para quem possui Créditos DevMedia.

Clique aqui para saber como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

Revista MSDN Magazine Edição 09 - Sistemas Distribuídos com .NET Remoting

Este artigo mostra os principais conceitos do .NET Remoting e uma aplicação real utilizando estes conceitos.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo

msdn09_capa.JPG

Clique aqui para ler todos os artigos desta edição

 

Sistemas Distribuídos com .NET Remoting

por Gustavo Nalle Fernandes

 

Atualmente grande parte das aplicações multicamada construídas utilizam o browser para fornecer a interface gráfica com o usuário, sob a justificativa de aproveitar a estrutura que a internet oferece e de que todos os sistemas operacionais modernos já incluem um browser. De certo modo isso faz sentido, mas a medida que a aplicação vai se tornando complexa, fica cada vez mais difícil encarar as limitações do browser, causando um impacto imenso no tempo de desenvolvimento e na qualidade do código.

Não fazer uso do browser não significa que seu sistema não possa fazer uso da internet. Ele pode ter um front-end criado com Windows Forms que além de oferecer uma experiência mais rica para o usuário pode perfeitamente se comunicar através da rede utilizando diversos protocolos, “conversando” com diversos sistemas diferentes executando tanto em plataformas .NET  como plataforma não .NET.

É neste cenário que entra o .NET Remoting, que oferece toda a infra-estrutura necessária para que seu sistema se torne distribuído. Este artigo mostra os principais conceitos do .NET Remoting e uma aplicação real utilizando estes conceitos.

 

Application Domains

Abrindo o gerenciador de tarefas do Windows, você certamente verá uma lista de processos que estão em execução no momento. Um processo permite que uma determinada aplicação possua seu próprio bloco de memória reservado, evitando que um processo mal comportado afete os demais.

Quando você executa uma aplicação gerenciada (um executável C#, por exemplo), o sistema operacional carrega o Common Language Runtime (CLR) em um novo processo e o CLR cria um Application Domain (domínio de aplicação) dentro desse processo, onde a aplicação gerenciada é executada. Um Application Domain é uma segmentação lógica de um processo de modo a permitir isolamento mesmo dentro de um mesmo processo.

Um processo pode ser divido em vários Application Domains, cada um executando uma aplicação diferente. O isolamento oferecido pelos Application Domains permite carregar e descarregar uma aplicação dentro de um processo e definir políticas de segurança diferentes para cara aplicação. Um exemplo desse isolamento é o ASP.NET: dentro de um mesmo processo existem vários sites web. Cada site web possui sua própria configuração de segurança e pode ser criado ou destruído independentemente das demais.

 

Contextos

Objetos que são criados dentro de um Application Domain podem estar ou não associados a um contexto. Um contexto é um agrupamento de objetos que possuem o mesmo comportamento e compartilham os mesmos parâmetros. Contextos são importantes porque permitem que chamadas à objetos dentro dele  sejam interceptadas antes de chegar ao destino. Como exemplo, considere o requisito de gerar uma entrada num arquivo de log cada vez que um método de um objeto é chamado. Uma solução é criar um contexto que agrupará todos os objetos que terão seus métodos logados. A cada chamada realizada por métodos desses objetos, o CLR interceptará essas chamadas, onde você poderá escrever no arquivo de log informações sobre o método e somente depois a chamada alcançará o objeto de destino. Desse modo, nenhum objeto dentro do contexto conterá código de log, o que é extremamente vantajoso. Contextos na plataforma .NET viabilizam o uso de AOP (Aspect Oriented Programming), paradigma no qual é possível isolar código como log, tratamento de erros, verificação de segurança (ou seja, códigos não relacionados diretamente com a função primária do objeto) em um local centralizado, tornando mais fácil a manutenção. Não faz parte do escopo desse artigo o detalhamento sobre contextos, basta saber que os contextos são mecanismos de segmentação de um Application Domain.

 

Definição de .NET Remoting

Um sistema .NET é considerado distribuído e utiliza a infra-estrura do .NET Remoting se ocorrer chamadas entre objetos pertencentes a diferentes contextos ou Application Domains. A Figura 1 mostra diversas situações em que ocorrem chamadas entre objetos de diferentes Application Domains e contextos. Note que mesmo dentro de um mesmo Application Domain ocorrem chamadas que se utilizam da infra-estrutura do .NET Remoting (chamadas remotas). Um dos objetivos do .NET Remoting é permitir que você acesse objetos de outro processo do mesmo modo que objetos locais. Quem está acostumado a trabalhar com computação distribuída usando DCOM, perceberá que o .NET Remoting é mais flexível e poderoso. Ao invés de evoluir a tecnologia DCOM, o .NET remoting optou por uma redefinição completa. No restante desse artigo, chamarei de objeto remoto (ou servidor) o objeto que reside em outro Application Domain, e de cliente o objeto que deseja chamar um método do objeto remoto.

 

image002.gif

Figura 1. Segmentação lógica dos processos e tipos de objeto no .NET Remoting:

 

Trafegando entre processos

Para que dois objetos pertencentes à diferentes Application Domains possam se comunicar, é necessário que ambos sejam do tipo Remotable. Na Figura 1, note que chamadas entre contextos e Application Domains sempre envolvem somente objetos do tipo Remotable. É possível tornar um objeto qualquer em um objeto Remotable de duas maneiras: usando Marshal-By-Value ou Marshal-By-Ref.

 

Marshal-By-Value são objetos capazes de trafegar de um Application Domain para outro. Quando você lida com comunicação com objetos remotos certamente precisará passar objetos como parâmetros de métodos e receber objetos em retorno. Esses parâmetros e objetos de retorno precisam trafegar de um Application Domain para outro, e para que isso seja possível, o .NET utiliza um processo chamado serialização, responsável por transformar um objeto em uma seqüência de bytes para que ele possa ser transportado pela rede. Deserialização é o processo inverso.

O .NET framework serializa e deserializa automaticamente os objetos que direta ou indiretamente participam de uma comunicação remota desde que os mesmos utilizem o atributo Serializable. O atributo NonSerialized pode ser usado para marcar campos dentro da classe que não devem ser serializados. Veja na Listagem 1 um exemplo de um objeto serializável, sendo que um dos campos (curriculum) não será serializado, ou seja, seu valor não estará no conjunto de bytes gerado.

Você deve usar com cautela essa modalidade de Remotable, visto que o .NET irá serializar toda a hierarquia de objetos contidos dentro do objeto marcado como serializável (exceto os campos marcados como não serializável). Dependendo do tamanho dessa hierarquia, a quantidade de dados resultante da serialização pode ser proibitiva. Outro cuidado é que se dentro dessa hierarquia existir um objeto que não possa ser serializável, o processo de serialização é interrompido e uma excessão é gerada.

 

Listagem 1: Objeto serializável com um campo não serializável

[Serializable()]     

public class Pessoa  {

  public int idade;

  public string nome;

  public string endereco;

   

  [NonSerialized()]public string curriculum;

     

  public Pessoa () {

  }

}

 

Marshal-By-Ref são objetos que ao contrário do Marshal-By-Value, não trafegam entre Application Domains. Ao invés disso, o .NET Remoting cria um Proxy para o objeto remoto no mesmo Application Domain do objeto que o chama. Proxy em inglês significa “procurador”, e é exatamente isso que acontece quando você chama um método de um objeto Marshal-By-Ref, pois você não lida diretamente com o objeto remoto, mas sim com um representante. O Proxy atua como intermediário entre o seu objeto e o objeto remoto, de tal forma que tudo se passa como se você tivesse lidando diretamente com o objeto remoto. Para que um objeto seja do tipo Marshal-By-Ref, basta fazê-lo herdeiro da classe MarshalByRefObject do namespace System, conforme mostra a Listagem 2. Perceba que o objeto contém apenas um método que retorna um objeto do tipo pessoa, mostrado na Listagem 1. Todos os parâmetros e valores de retorno desse método devem obrigatoriamente ser Remotable para que a chamada remota funcione, caso contrário uma exceção é gerada.

 

Listagem 2: Objeto Remotable do tipo Marshal-By-Ref

 class MinhaClasse : MarshalByRefObject {

   

  public Pessoa getPessoa(int id) {

    // Implementação...

  }

}

 

Ativando um Objeto remoto

Antes de utilizar um objeto Remotable, é necessário criar uma instância dele, ou em outras palavras, ativá-lo. Os objetos Marshal-By-Ref suportam dois tipos de ativação: cliente e servidor, sendo que a ativação pelo servidor pode ser Singleton ou Single Call. A ativação pelo servidor é feita justamente no Application Domain do objeto remoto, que disponibiliza um URI e um nome para que os objetos clientes possam acessar o objeto remoto. O controle do tempo em que o objeto está ativo e do número de instâncias ativas é feito remotamente.

No modo Singleton, uma única instância do objeto remoto existe para servir todos os clientes. No modo single call, o objeto servidor é criado somente para servir um método chamado pelo cliente. A ativação pelo cliente é feita pelo objeto que chama o objeto remoto. Nessa modalidade, cada cliente que acessa o objeto remoto cria uma instância do mesmo, estabelecendo uma relação uma para um. O objeto remoto somente existe para servir um único cliente e pode criar uma sessão com o cliente, de modo a armazenar variáveis entre chamadas de métodos. A Tabela 1 mostra um comparativo entre os tipos de ativação apresentados.

 

 

 

Tabela 1. Comparativo entre os tipos de ativação

 

Tipo de Ativação

Cliente

Server – Single Call

Server – Singleton

Vantagens

Permite ao cliente controlar o tempo de vida do objeto remoto;

Permite  manter estado entre as chamadas. Útil quando se deseja alto grau de conversação entre cliente e servidor

Um objeto para cada cliente sem manter estado; objeto é destruído ao fim da chamada do método. Útil quando não é preciso manter estado e deseja-se maior economia de recursos no lado servidor

Um único objeto serve todos os clientes, permitindo operações conjuntas envolvendo todos os clientes, como por exemplo callbacks e log de conexões

Controle do tempo de vida

cliente

Servidor

Servidor

Estado entre chamadas

sim

não

sim, o servidor é o mesmo para todos os clientes

Multiplicidade cliente-servidor

Um objeto servidor para cada cliente

Um objeto servidor para cada cliente

Um objeto servidor para todos os clientes

 

 

Publicando um objeto para acesso remoto

"

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



Gustavo Nalle Fernandes (gustavo@summa-tech.com) é engenheiro mecânico de formação e atualmente é consultor sênior da Summa Technologies, empresa especializada em arquitetura, mentoring e treinamento usando tecnologias .NET e J2EE [...]

O que você achou deste post?
Serviços

Mais posts