Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Revista MSDN Magazine Edição 09 - Sistemas Distribuídos com .NET Remoting
Artigo Originalmente Publicado na MSDN Magazine Edição 09
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
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.
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. Este é um post disponível para assinantes MVP
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Gustavo Nalle Fernandes
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. Gustavo é Microsoft Certified Professional (ASP.NET/C#) , além de po...
