Instituto Superior de Engenharia do Porto. Departamento de Engenharia Informática. .Net Remoting

Instituto Superior de Engenharia do Porto Departamento de Engenharia Informática Projecto Licenciatura em Engenharia Informática Ramo de Computadores e Sistemas Julho 2002 Elaborado por: 970311 - António Amaral Orientador: Eng.º Alexandre Bragança

Índice Geral Índice Geral Lista de Figuras Lista de Abreviaturas iii vi vii 1 - Introdução-----------------------------------------------------------------------------------------1 1.1 Projecto 1 1.2 Objectivo 1 1.3 Estrutura do Relatório 1 2 - Envolventes --------------------------------------------------------------------------------------- 3 2.1 Contexto 3 2.2 X Internet 3 2.3 XML 4 2.3.1 Apresentação estruturada dos dados 5 2.3.2 Separação de apresentação e dados Xml vs. HTML 5 2.4 Xml Web Services 6 2.5 SOAP 8 2.6 WSDL e UDDI 10 3 -.Net ------------------------------------------------------------------------------------------------- 13 3.1 Uma pequena revolução 13 3.2 CLR 14 1.3 Biblioteca de Classes e Aplicações 15 1.1.1 Aplicações convencionais (de cliente) 16 1.1.2 Aplicações cliente/servidor 17 iii

1.4 Domínios e Contextos (Domains and Contexts) 18 1.4.1 Processos.NET 18 1.4.2 Application Domains (AppDomains) 18 1.4.3 Application Contexts (Contextos) 22 4 - ---------------------------------------------------------------------------------- 23 4.1 Introdução 23 4.2 Arquitectura 23 4.2.1 Cliente 24 4.2.2 Transparent Proxy 24 4.2.3 Real Proxy 24 4.2.4 Client-Side Sinks 25 4.2.5 Canais 26 4.2.6 Server-Side Sinks 26 4.2.7 Objecto remoto 27 4.3 Objectos activados pelo Servidor 27 4.3.1 Objectos Singleton 28 4.3.2 Objectos SingleCall 29 4.3.3 Exemplo: Classificações de Exames 30 4.3.3.1 O Objecto remoto 30 4.3.3.2 O Cliente 35 4.4 Objectos activados pelo Cliente 37 4.4.1 O exemplo Classificações de Exame 37 4.4.1.1 Objecto e Servidor 37 4.4.1.2 O Cliente 39 4.4.2 Tempo de Vida - Objectos activados pelo Cliente 40 4.4.2.1 Através da Aplicação remota 42 4.4.2.2 Através do objecto remoto 43 4.4.2.3 Controlo do Tempo de Vida do Objecto 43 4.4.2.4 Suporte ao controlo do Tempo de Vida - O Lease Sponsor 44 4.5 Ficheiros de configuração 46 iv

4.5.1 Objectos activados pelo Servidor 46 4.5.2 Objectos activados pelo Cliente 51 4.6 Objectos.NET Remoting no IIS 52 5 - Cenários------------------------------------------------------------------------------------------ 55 5.1 Utilização de Objectos 55 5.1.1 Qualquer Cliente.NET - Usando SOAP-HTTP 55 5.1.2.NET.NET - Usando SOAP-HTTP 56 5.1.3.NET.NET - Usando TCP 56 5.1.4.NET Componente COM.NET 57 5.2, Xml Web Services e a X Internet 58 6 - Conclusões--------------------------------------------------------------------------------------- 61 7 - Bibliografia ------------------------------------------------------------------------------------- 63 v

Lista de Figuras Figura 2.1 Exemplo de um pedido RPC através de SOAP.-------------------------9 Figura 3.1 Relação Entre Processos, AppDomain s e Contextos--------------- 22 Figura 4.1 - Os elementos principais da arquitectura do.net Remoting.---- 25 Figura 4.2 Exemplo de Utilização de um Objecto Singleton --------------------- 29 Figura 4.3 Exemplo de Utilização de Objectos SingleCall ------------------------ 29 Figura 4.4 Esquema de Funcionamento Classificações Server Activated Object - (Singleton) ------------------------------------------------------------------ 37 Figura 4.5 Esquema de Funcionamento Classificações Client Activated Object ------------------------------------------------------------------------------------- 40 vi

Lista de Abreviaturas CAO Client Activated Object CLR Common Language Runtime COM Component Object Model CTS Common Type System DCOM Distributed Component Object Model IIS Internet Information Server MFC Microsoft Foundation Classes SAO Server Activated Object SOAP Simple Object Access Protocol UDDI Universal Discovery Description and Integration WSDL Web Services Description Language WWW World Wide Web XML Extensible Markup Language XWS Xml Web Service vii

1 - Introdução 1.1 Projecto Este trabalho foi realizado no âmbito da cadeira Projecto, do 5º ano do curso de Licenciatura em Engenharia Informática Computadores e Sistemas, do Instituto Superior de Engenharia do Porto no segundo semestre do ano lectivo de 2001/2002. 1.2 Objectivo O objectivo da realização deste projecto é o estudo da plataforma.net na sua vertente de Remoting. Como resultado final, pretende-se obter, para além de um documento de análise ao e tecnologias a ele inerentes, um guia para a sua utilização. Fazer um estudo sobre, obrigou á análise de alguns assuntos envolventes; entre eles posso destacar o conceito de X Internet, e dos Web Services, para além de todos os conceitos de Sistemas Distribuídos, Xml, SOAP, e da generalidade do próprio.net. São estes os assuntos que vão ser abordados inicialmente e posteriormente em paralelo ao estudo do. 1.3 Estrutura do Relatório Este relatório está essencialmente dividido em 4 partes, que deram origem a igual número de capítulos. 1

Para além dos pontos iniciais e do primeiro capítulo, que englobam índices, objectivos, e outras introduções, temos o capítulo 2 onde se fala um pouca das tecnologias inerentes ao tema principal (, Web Services e X Internet), como é o caso do Xml, do SOAP, WSDL e UDDI. Para além disso é introduzido neste capítulo o conceito de X Internet e de Web Services. De seguida temos no capítulo 3 uma breve contextualização sobre o.net na generalidade, sendo que este capítulo não pretende clarificar qualquer vertente em concreto do próprio.net. Neste capítulo começam a surgir, no entanto, alguns conceitos que são importantes para a boa compreensão do Remoting: Domínios e Contextos aplicacionais. No capítulo 4 é abordado o : arquitectura, objectos activados pelo servidor, objectos activados pelo cliente, ficheiros de configuração e objectos remotos no IIS são por esta ordem os sub-temas abordados. Neste capítulo é introduzido um exemplo (classificações de exame obtidas a partir de um objecto remoto), que é utilizado por todo o relatório como forma de auxilio á explicação das tecnologias nele utilizadas. No capítulo 5 é feita uma abordagem no sentido prático de utilização quer do Remoting quer dos Xml Web Services, e a sua integração no conceito de X Internet. Após estes quatro capítulos temos uma breve conclusão e bibliografia. 2

2 - Envolventes 2.1 Contexto Podendo-se, neste momento, considerar o aparecimento e amadurecimento da Internet um sucesso, deve-se também pensar um pouco no futuro, e na inevitável aproximação de novas exigências. É por isso previsível que o inevitável ciclo de vida do produto também se venha a aplicar á Internet tal como ela foi utilizada inicialmente. Sendo assim urge o aparecimento de novas formas de globalização na área da informação. Sendo já bastante comum a empresa que se formou ontem ter a famosa página na WWW onde coloca algo sobre si e sobre os seus produtos e serviços, ou até, o nosso vizinho ter uma página pessoal onde escreve sobre o seu maior ídolo ou até sobre si... cabendo a cada um dos utilizadores tirar partido da muita e variada informação (em qualidade e quantidade), parece começar a ser necessário dar outra utilidade á rede de comunicação e distribuição de informação. A palavra chave pode mesmo ser a distribuição; distribuição não só de texto mas também de serviços, de execução de tarefas comuns e especificas. Tornar a Internet executável pode, e começa, a ser o próximo passo. 2.2 X Internet É neste contexto que surge o conceito de X Internet. A X Internet é uma rede na qual os utilizadores participam mais activamente no processo de comunicação. Na X Internet os computadores em vez de se limitarem a fazer download de ficheiros, fazem download de programas de lhe dizem o que fazer... enquanto que na actual World Wide Web os browsers se limitam a carregar milhares de páginas com texto contendo a mais 3

Envolventes variada informação, na X Internet são carregados apenas os ficheiros necessários para se alcançar um determinado objectivo, que pode variar consoante o destino que se lhe pretender dar. Desde a distribuição de informação até ao arranque de sistemas, o conceito de X Internet pretende revolucionar a Internet a que estamos habituados. Como qualquer outra revolução, esta terá o seu tempo de intervenção, e vai obrigar a grandes mudanças, quer no modo de pensar o mundo da distribuição de informação, quer na forma de o fazer. A forma ideal de minimizar os efeitos de qualquer revolução é estar preparado para ela. Da mesma forma que um ser humano se prepara para a guerra tendo a coragem de acreditar que ela vai acontecer, os intervenientes no actual processo de distribuição e processamento de informação, desde empresas a particulares devem também estar preparados, porque quem se atrasar corre sérios riscos de perder o comboio rumo ao futuro mundo da informação. Existem já algumas implementações deste conceito com algum sucesso, no entanto ainda existem algumas barreiras a ultrapassar: Por questões de segurança criam-se apenas pequenas X Internet s ou seja X Intranet s. Ainda não estão definidos standards. Questão económicas inerentes a mudanças no mundo das tecnologias. Mais á frente neste relatório vamos ver de que forma é que o e os Xml Web Services se podem enquadrar neste conceito. De seguida vamos ver algumas tecnologias base associadas a esta forma de implementar a computação distribuída. 2.3 XML Extensible Markup Language (XML) é um formato de documento que descreve os dados de forma estruturada. Isso torna os resultados de busca mais rápidos e 4

Envolventes significativos através dos múltiplos níveis. Além disso, o XML permitirá uma geração nova de aplicações Web-based da visão e da manipulação de dados. Em XML pode-se definir um número ilimitado de nós; um elemento em XML pode declarar os dados a ele associados para ser qualquer coisa: um preço de artigo, um imposto de vendas, o título de um livro, a quantidade de qualquer coisa, ou qualquer outro tipo de dados desejado. Sendo o XML adoptado numa organização, haverá uma capacidade correspondente de procurar e manipular dados independentemente das aplicações em que se encontra; estes podem ser apresentados num browser em variados formatos, ou encaminhados para uma qualquer outra aplicação. 2.3.1 Apresentação estruturada dos dados XML é um subconjunto do SGML que está optimizado para entrega e utilização sobre a World Wide Web; é definido pela (W3C), assegurando-se que os dados estruturados sejam uniformes e independentes das aplicações ou dos autores. XML, que fornece um padrão de dados que permite codificar o conteúdo, a semântica, e o formato ( schema ) para uma larga variedade de casos; As aplicações podem ser construídas mais rapidamente, são mais fáceis de gerir, e podem facilmente fornecer múltiplas vistas dos dados estruturados. 2.3.2 Separação de apresentação e dados Xml vs. HTML As capacidades do XML permitem separar a apresentação e o conteúdo. O HTML especifica como apresentar os dados num browser; por sua vez o XML define o conteúdo. Por exemplo, no HTML usa-se uma Tag para dizer ao browser para apresentar dados em bold (realce), ou em itálico; em XML usa-se somente um nó para descrever dados. 5

Envolventes Juntamente com XML, usam-se stylesheets, XSL, etc., para apresentar os dados num browser; assim sendo separam-se os dados da apresentação, permitindo indicar e processar os dados como se desejar aplicando visões diferentes e aplicações adequadas. Esta separação dos dados da apresentação permite a integração sem restrições de dados de diversas fontes. A informação do cliente, as ordens de compra, os resultados de pesquisas, os pagamentos, os registos médicos, os catálogos, e outra informação pode ser convertida em XML, permitindo que esses dados sejam trocados e manipulados. Os documentos XML são fáceis de criar; quem estiver familiarizado com o HTML, pode rapidamente criar um; neste exemplo, o XML é usado para descrever uma determinada biblioteca: <biblioteca> <seccao id_seccao= 1 tipo = dramas > <livro id_livro= 11 > <titulo>os Maias</titulo> <autor>eça de Queiroz</autor> <data_edicao>13-04-1920</data_edicao> </livro> <livro id_livro= 12 > <titulo>os Lusíadas</titulo> <autor>luis Vaz de Camões</autor> <data_edicao>13-04-1520</data_edicao> </livro> </seccao> </biblioteca> 2.4 Xml Web Services 6

Envolventes É neste contexto, que surge o conceito de Web Service. Tal como as palavras indicam, uma forma de disponibilizar serviços que podem ser acedido de diversas formas inclusive através da WWW (Web). O Xml é um formato que, devido á sua simplicidade possibilita a estandardização de uma forma bastante compreensível e humana, devido á estrutura hierárquica que possui, ser de fácil percepção. È baseado nestes contextos, que surge o conceito de Xml Web Service, uma vez que possibilita a tal forma standard de distribuir informação. Xml Web Services, estão a começar a ser usados como uma forma de integração de aplicações. Sendo o Xml um standard, permite que várias aplicações possam ser construídas das mais variadas formas, desde que no momento de serem disponibilizadas o façam de forma standard. Os Xml Web Services permitem assim que várias fontes de processamento trabalhem em conjunto independentemente de como e onde o façam. Existem actualmente diversas definições de XML Web Service, porque neste momento são várias as entidades que os estão a utilizar e disponibilizar, no entanto todas elas têm algo em comum: Expõem funcionalidades bastante úteis aos utilizadores e consumidores da WWW através de protocolos standard, na maior parte dos casos esse protocolo é o SOAP. Disponibilizam uma forma de descrever os seus interfaces que permitem aos seus utilizadores construir um cliente para os utilizar. Essa descrição é feita normalmente em XML num documento WSDL. São registados, para que possam ser facilmente encontrados, através de UDDI (Universal Discovery Description and Integration). Estas três tecnologias irão ser abordadas de seguida. 7

Envolventes De uma forma resumida pode-se então dizer que a utilização de Xml Web Services têm bastantes vantagens em comparação com outras formas de computação distribuída, como por exemplo o DCOM ou o CORBA, uma vez que não necessitam de profissionais dedicados e preocupados com o facto de terem de abrir mil e uma portas para comunicações binarias; isto porque, na comunicação é possível a utilização de HTTP, um protocolo fiável e de acesso normal para qualquer utilizador de leitura de texto na Internet. Para além disso a utilização de Xml reduz as despesas na formação, investigação e definição de protocolos uma vez que a sua utilização é bastante intuitiva, para além de ser um standard. Estando num universo carente de fontes e formas de informação, é importante também que qualquer nova forma que se queira implementar seja também de fácil inserção, permitindo de preferência a reutilização de aplicações já existentes. Supondo por exemplo uma companhia que disponibiliza aos seus clientes a informação A através de um protocolo qualquer, que tem que ser conhecido por ambos, essas aplicações podem migrar para Web Services facilmente independentemente da forma como funcionam e da plataforma onde funcionam. Imagina-se agora que se trata do seu dentista que disponibiliza através de um serviço deste tipo a sua agenda aos seus colegas de consultório... porque não entrar o cliente na jogada e através dessa mesma aplicação agora disponibilizada por um Xml Web Service poder marcar consultas. Afinal, um Web Service disponibiliza texto, através do qual se pode fazer tudo... o que se quiser disponibilizar para ser feito. 2.5 SOAP Como já foi dito SOAP é o protocolo de comunicação standard utilizado pelos Xml Web Services. É inevitável a sua comparação com outros protocolos de comunicação para aplicações distribuídas, como é o caso do DCOM, CORBA, RMI, etc. Existem alguns pormenores no SOAP, como por exemplo a activação dos objectos 8

Envolventes invocados, que apesar de serem implementados, não fazem parte da especificação SOAP. A especificação preocupa-se apenas com a definição do formato Xml que devem ter as mensagens. Sendo o SOAP um protocolo de comunicação baseado num documento Xml, estão nesse Xml todos os dados necessário para fazer um pedido (Remote Procedure Call), como por exemplo o nome do método, os seus parâmetros, etc. O cliente SOAP faz um pedido através do envio de uma mensagem XML com esse formato e recebe do servidor a resposta também num documento Xml, tal como ilustra a figura 2.1. FIGURA 2.1 EXEMPLO DE UM PEDIDO RPC ATRAVÉS DE SOAP. Uma outra parte da especificação, define como deve ser uma mensagem HTTP que contém uma mensagem/pedido SOAP. Essa definição apesar de ser opcional é importante porque o HTTP é suportado por quase todos os Sistemas Operativos e como tal é o único protocolo standard para SOAP. Por este facto, surge por vezes a confusão que o SOAP é obrigatoriamente utilizado sobre HTTP, o que não é verdade. Algumas implementações suportam MQ Series, SMTP, etc. Apesar disso o HTTP é realmente o mais utilizado, porque quase todas as redes e sistemas informáticos implementados hoje em dia suportam HTTP, ao contrário dos outros protocolos, nomeadamente dos já descritos atrás. 9

Envolventes No entanto nem tudo são vantagens; por vezes existe alguma confusão relativamente a uma distinção que deve ser tida em conta: a especificação SOAP e as implementações da especificação SOAP. A maior parte dos utilizadores de SOAP não têm o trabalho de escrever as mensagens SOAP. Fazem esse trabalho através da utilização de toolkits que a partir de objectos ou programas gerados a partir de diferentes linguagens, geram a mensagem SOAP onde descrevem como devem ser chamados esses objectos ou programas. Por exemplo o Microsoft SOAP Toolkit gera mensagens SOAP a partir de funções disponibilizadas pelo COM e o Apache Toolkit faz o mesmo a partir de funções Java. Obviamente alguns tipos de dados entre estas duas linguagens são diferentes, por isso algumas RPC que poderiam ser feitas com um toolkit não o podem ser com o outro. Esta, não é no entanto uma limitação do SOAP, mas da implementação que está a ser usada. O SOAP é no entanto uma excelente forma de ligar plataformas diferentes. Apesar dos esforços que têm sido feitos para encontrar uma forma de fazer essa ligação até hoje têm normalmente sido em vão. O CORBA por exemplo demorou muito tempo a ser implementado e muito poucas releases foram lançadas. O SOAP tem a vantagem de ser bastante simples, de rápida implementação e de não obrigar um administrador de rede a ter que abrir mais umas portas para comunicação devido ás exigências de alguns protocolos. Basta que tenham suporte para HTTP o que hoje em dia é regra quase geral. Apesar de todas estas vantagens o SOAP não consegue fazer tudo o que o CORBA consegue fazer... mas é mesmo essa característica que faz com que seja um protocolo muito mais acessível. Esta combinação de HTTP com SOAP faz com que os Xml Web Services sejam de fácil implementação e utilização. 2.6 WSDL e UDDI 10

Envolventes WSDL (Web Services Description Language) é o tal documento Xml que foi falado atrás quando se descrevia o SOAP. O WSDL está para o SOAP assim como o IDL está para o COM ou CORBA. Um ficheiro WSDL é normalmente gerado por toolkits apesar de ser um documento de texto facilmente editável. É através da criação de um ficheiro WSDL que se evitam confusões na chamada de um método por SOAP porque é lá que se definem as características dessa chamada. Por exemplo distinguir 2378 que num parâmetro poderia ser um inteiro mas é neste método uma string. A notação usada neste documento é regulada por um Xml Schema tornando-se assim universal e fazendo com que dois Web Services possam ser chamados em locais diferentes usando o mesmo formato de mensagem. O Microsoft Visual Studio.Net tem já embutido, neste aspecto todo o trabalho de geração de código necessário para que uma invocação seja possível. Há no entanto uma aspecto importante a ter em conta: apesar de vários toolkits disponibilizarem a criação automática de um WSDL, não existe nenhuma ferramenta que o faça de raiz, ou seja se alguém fizer uma aplicação e quiser disponibilizá-la por SOAP ou usa um toolkit que gere o WSDL ou então é um conhecedor do seu formato e elaborao manualmente. Tendo uma definição de um Xml Web Service disponibilizada a partir de um documento WSDL, faltava saber onde publicá-la, ou seja, tal como quando se cria uma empresa é necessário fazer saber que ela existe. UDDI - Universal Discovery Description and Integration é a forma de disponibilizar um XWS, surgindo assim como as páginas amarelas dos Web Services. Mais informação sobre a UDDI em: http://www.uddi.org/about.html 11

Envolventes 12

3 -.Net 3.1 Uma pequena revolução A plataforma.net, que foi construída á volta do conceito dos XML Web Services, é a primeira a suportar de raiz XML Web Services na integração de negócio e software. A arquitectura.net vem simplificar o desenvolvimento no ambiente distribuído que a Internet proporciona respondendo aos seguintes objectivos: Fornecer um ambiente de programação coerente e orientado por objectos, com o código armazenado e executado a nível local, ou a nível local mas distribuído pela Internet ou então a nível remoto. Fornecer um ambiente de execução de código que minimiza a implementação de software e conflitos entre versões. Fornecer um ambiente de execução de código que garante a execução segura do código criado por uma entidade não conhecida ou semi conhecida. Fornecer um ambiente de execução de código que elimina os problemas de desempenho de ambiente scripted ou interpretado. A arquitectura.net possui dois componentes principais: o Common Language Runtime (CLR), e a biblioteca de classes da arquitectura.net Framework. O CLR é a base da arquitectura.net. É o componente que gere o código no decurso da sua execução, fornecendo serviços essenciais como por exemplo a gestão de memória, threads, e Remoting, para além da implementação de segurança estrita de tipos e outras formas de 13

.Net certificação de código. A biblioteca de classes é uma colecção abrangente de tipos reutilizáveis que se pode utilizar para desenvolver aplicações que variam desde as convencionais da linha de comando ou de interface gráfica (GUI) até ás baseadas nas mais recentes apostas da computação distribuída, como são os Web Services e a implementação Microsoft incorporada no.net -. Esta arquitectura pode ser disponibilizada por componentes não geridos que carregam o CLR nos seus processos e iniciam a execução de código gerido com funcionalidades geridas e não geridas. O Internet Explorer é um exemplo duma aplicação não gerida que disponibiliza o Runtime (em forma de uma extensão do tipo MIME). É possível incorporar componentes geridos ou controlos Windows Forms em documentos HTML. 3.2 CLR O Common Language Runtime é o componente responsável pela execução de threads, gestão de memória, execução do código, verificação de segurança do código, compilação e outros serviços de sistema. Relativamente á segurança os componentes geridos recebem diversos níveis de confiança, consoante uma série de factores entre os quais a sua origem (por exemplo, a Internet, a Intranet da empresa ou um computador local). O Runtime implementa o acesso á segurança do código. Por exemplo os utilizadores podem ter a confiança de um executável incorporado numa página Web consegue executar uma animação no ecrã sem aceder aos sues dados pessoais, de sistema ou da rede interna. O Runtime implementa também a robustez do código através duma infra-estrutura escrita de verificação de tipos e código, designada por Common Type System (CTS). O CTS assegura que todo o código gerido se descreva a si próprio. Os vários compiladores da Microsoft geram código compatível com o CTS. O Runtime aumenta também a produtividade de programação, uma vez que o programador pode desenvolver na sua linguagem preferida, tirando ao mesmo tempo partido integral do 14

.Net Runtime, da biblioteca de classes e de componentes escritos em outras linguagens. Apesar de ter sido desenvolvido a pensar nesta nova forma de trabalhar, o Runtime também suporta o software actual, permitindo que no desenvolvimento se continuem a utilizar COM e DLL s necessárias. O Runtime foi desenvolvido para aumentar o desempenho. Embora o CLR forneça muitos serviços de Runtime habituais, o código gerido nunca é interpretado. Uma funcionalidade designada por compilação just-in-time (JIT) permite que todo o código gerido seja executado na linguagem de máquina nativa do respectivo sistema. Por fim o Runtime pode ser alojado em aplicações do lado servidor como por exemplo o Microsoft SQL Server ou o Internet Information Services (IIS). 3.3 Biblioteca de Classes e Aplicações A biblioteca de classes da arquitectura.net Framework é uma colecção de tipos reutilizáveis que se integram com o CLR. A biblioteca de classes é OO e proporciona tipos que podem ser utilizados no desenvolvimento para fornecer funcionalidade ao código gerido. Tal como seria de esperar de uma biblioteca de classes orientada por objectos, os tipos da arquitectura.net permite realizar uma variedade de tarefas de programação comuns, incluindo tarefas como a gestão de strings, recolha de dados, conexão a bases de dados e acesso a ficheiros. A biblioteca de classes inclui tipos que suportam uma variedade de cenários de desenvolvimento especializados, como por exemplo, para desenvolver os seguintes tipos de aplicações e serviços: Aplicações de consola. Aplicações scripted ou alojadas. Aplicações Windows com interface gráfica (Windows Forms). Aplicações ASP.NET 15

.Net XML Web Services Serviços para Windows As classes Windows Forms são um conjunto de tipos reutilizáveis que simplificam o desenvolvimento de interfaces gráficas para Windows. Vamos agora ver alguns desenvolvimentos que o.net tem em relação ao seu antecessor o Microsoft Visual Studio 6. Para tal vamos fazer uma divisão típica do mundo aplicacional: Aplicações convencionais (de cliente) Aplicações Cliente/Servidor 3.3.1 Aplicações convencionais (de cliente) Entre as aplicações convencionais ou de cliente, contam-se aplicações como por exemplo processadores de texto e folhas de calculo, bem como aplicações de negócio especializadas como por exemplo ferramentas para relatórios. Nos ambientes de desenvolvimento que antecederam o.net, tais aplicações eram criadas em C/C++, em conjunto com as Microsoft Foundation Classes (MFC) ou com um ambiente RAD (Rapid Application Development) como o VB. A arquitectura.net incorpora aspectos destes produtos num ambiente de desenvolvimento único que simplifica drasticamente o desenvolvimento de aplicações convencionais. As classes Windows Forms contidas na arquitectura.net destinam-se ao desenvolvimento de interfaces gráficas, permitindo a criação fácil de elementos de écran com a flexibilidade necessária para corresponder a constantes mudanças nas necessidades das empresas. 16

.Net Por exemplo, a arquitectura.net fornece propriedades simples para ajustar atributos visuais associados a formulários. Em alguns casos, o sistema operativo subjacente não suporta a alteração directa destes atributos, e nestes casos o.net recria os formulários automaticamente. Ao contrário dos controlos ActiveX, os controlos Windows Forms têm acesso semi confiado ao computador do utilizador. Isto significa que o código binário ou executado de forma nativa consegue aceder a alguns recursos do sistema do utilizador mas não consegue comprometer nem aceder a outros recursos. 3.3.2 Aplicações cliente/servidor Resumindo alguns melhoramentos que o.net traz, pode-se falar do ASP.NET e dos Web Forms, que trazem bastante melhoramentos em relação á tecnologia ASP. Por exemplo pode desenvolver páginas de Web Forms em qualquer linguagem que suporte a arquitectura.net Framework. Existem no entanto bastantes pormenores que não são objectivo deste trabalho e por isso não vão ser abordados. Há no entanto a realçar no.net, relativamente ao desenvolvimento sob o paradigma cliente/servidor, seja qual for a arquitectura aplicacional envolvida (sistema paralelo, tempo real, distribuído, etc.), os já falados Xml Web Services. São componentes que não têm interface gráfica e não foram desenvolvidos para browsers. Consistem em pedaços de software reutilizáveis que se destinam á utilização por outras aplicações, quer sejam convencionais (o típico.exe), quer sejam outros Xml Web Services ou até qualquer outro tipo de serviços. A arquitectura.net fornece uma colecção de classes (que irão ser faladas mais em pormenor nos próximos dois capítulos) e ferramentas que ajudam no desenvolvimento e utilização de XML Web Services. Para além disso, e sendo um dos objectivos deste projecto, o suporte de comunicações do.net: o.net Remoting. 17

.Net 3.4 Domínios e Contextos (Domains and Contexts) A computação distribuída, é sem qualquer dúvida uma peça fundamental na arquitectura aplicacional actual. Isto acontece porque da distribuição leva a que objectivos como a escalabilidade, performance de disponibilidade sejam mais facilmente alcançados. Para tal todos os modelos baseados em componentes já implementados têm vindo a contribuir com bastante sucesso; COM (via DCOM), CORBA, Java RMI, entre outros são disso exemplo. Um dos princípios do.net assenta nessa mesma ideia, principalmente com o Remoting, que permite que se ultrapassem barreiras como são os processos, máquinas e até redes diferentes. Como tal importa que se explique um pouco da filosofia técnica de funcionamento do.net, porque algumas das características do.net são fundamentais e sem elas é muito difícil o entendimento do Remoting; senão vejamos: 3.4.1 Processos.NET Um processo.net é composto por um ou mais domínios de aplicação (Application Domains) que por sua vez são também compostos por um ou mais contextos (Application Contexts). 3.4.2 Application Domains (AppDomains) Um AppDomain é para o.net o que um processo é para um sistema operativo, providenciando segurança, isolamento, etc. Um AppDomain pode ser visto como mini processo dentro de um processo do Sistema Operativo. Todos os objectos.net são criados dentro de um AppDomain. Um AppDomain pode conter não só objectos 18

.Net individuais, mas também aplicações inteiras. Assim sendo em vez de termos uma aplicação por processo, temos n aplicações por AppDomain. Este facto favorece, sem dúvida a performance, e a racionalização de recursos, porque teoricamente um AppDomain é mais fácil de criar do que um processo. O acesso a um AppDomain é encapsulado na classe com o mesmo nome que disponibiliza as seguintes operações: Criar um novo. Terminar. Carregar assemblies e tipos. Enumerar as assemblies e threads. Definir assemblies dinâmicos. O exemplo seguinte mostra, em C#, como usar a respectiva classe. Primeiro diz qual o nome da AppDomain e de seguida mostra informação acerca de cada assembly lá contida: using System; using System.Reflection; using System.Runtime.Remoting; namespace Exemplo1 class Class1 static void Main(string[] args) AppDomain domain = AppDomain.CurrentDomain; Console.WriteLine(domain.FriendlyName); Assembly[] loadedassemblies = domain.getassemblies(); Console.WriteLine("Assemblies: "); foreach(assembly a in loadedassemblies) Console.WriteLine(a.FullName); 19

.Net Um objecto contido numa AppDomain não está directamente acessível a outras AppDomains... senão vejamos a seguinte assembly: using System; namespace Exemplo2A class Class1 static void Main(string[] args) Console.WriteLine("Executei!!"); Agora criamos uma nova AppDomain e carregamos a assembly Exemplo2A.exe e tentamos aceder á classe Exemplo2A.Class1: using System; using System.Reflection; using System.Runtime.Remoting; namespace Exemplo2B class Class1 static void Main(string[] args) AppDomain domain = AppDomain.CurrentDomain; AppDomain newdomain = AppDomain.CreateDomain("NewDomain"); newdomain.executeassembly("exemplo2a.exe", null,args); ObjectHandle o = newdomain.createinstance("exemplo2a", "Exemplo2A.Class1"); o.unwrap(); Quando se tenta correr o Exemplo2B.exe, recebemos a excepção I can t let you access the Exemplo2A.Class1 instance because it s not in the same AppDomain as your object.. Para isso ser possível a Exemplo2A.Class1 teria que ser acedida de forma 20

.Net remota por valor ou por referência... para o conseguir por valor teríamos que a tornar serializável como se mostra de seguida: using System; namespace Exemplo2A [Serializable] class Class1 static void Main(string[] args) Console.WriteLine("Executei!!"); Acerca de serialização, pode-se dizer que consiste em fazer uma cópia exacta do objecto original na AppDomain que tentar usar o objecto. Mais informação acerca de serialização em: http://www.msdn.microsoft.com/library/en-us/dndotnet/html/objserializ.asp Por referência, temos que fazer a classe derivar de System.MarshalByRefObject: using System; namespace Exemplo2A class Class1 : System.MarshalByRefObject static void Main(string[] args) Console.WriteLine("Executei!!"); Neste exemplo já não existe o atributo [Serializable]. Quando um objecto é passado por referência não existe cópia... em vez disso a AppDomain que o pretender 21

.Net usar recebe um proxy para o objecto. Como consequência qualquer alteração que se efectue ao objecto é reflectida no original. É, no entanto, de referir que os utilizadores do.net não vão ter que criar AppDomains, porque esse pormenor é gerido pelo CLR, apesar de o poder fazer, caso pretenda. 3.4.3 Application Contexts (Contextos) Como já foi dito, cada AppDomain contém um ou mais contextos. Quando um AppDomain é criado e associado um contexto. Se forem necessários novos contexto são criados pelo Runtime. Cada contexto faz parte de um e um só AppDomain e pode conter n objectos; cada objecto está contido num só contexto, sendo que todos os objectos contidos no mesmo contexto têm requisitos de execução semelhantes. Já foi falado que os objectos contidos num AppDomain não podem ser acedidos por outros AppDomain s e mesmo se pode passar de contexto para contexto... um objecto num contexto pode ser de dois tipos: context-agile ou context-bound. Os primeiros não estão disponíveis para todos os contextos dentro da AppDomain. Os segundos são o oposto: para serem acedidos de outros contextos têm de o ser via proxy. Para serem context_bound têm que derivar da classe System.ContextBoundObject que por sua vez deriva da System.MarshalByRefObject e como tal herda todas as suas características já faladas. Qualquer objecto que derive directamente da classe System.MarshalByRefObject é context-agile. Para além disso os objectos que não derivem de nenhuma destas classes podem ser acedidos de qualquer contexto dentro da AppDomain mas nunca de outras AppDomain s. FIGURA 3.1 RELAÇÃO ENTRE PROCESSOS, APPDOMAIN S E CONTEXTOS 22

4-4.1 Introdução O.NET Remoting, como componente de comunicações do.net, tem por objectivo disponibilizar formas de comunicação entre objectos fisicamente colocados em locais diferentes ou não. Estamos a falar de comunicar entre aplicações no mesmo sistema, ou entre aplicações colocadas em sistemas diferentes. Para tal o.net Remoting disponibiliza um conjunto de serviços, que inclui a forma de activação dos objectos e consequente suporte durante a sua existência (instanciação), inclui também os canais de comunicação usados para o transporte de mensagens de e para as aplicações remotas. Para além disso existe a inerente codificação e descodificação das mensagens a trocar, que pode ser binária se pretendermos uma maior flexibilidade e fiabilidade, ou XML se pretendemos uma maior interoperabilidade. A codificação XML usa SOAP para o transporte que por sua vez é normalmente, mas não obrigatoriamente transportado sobre HTTP. O Remoting foi pensado tendo em conta a segurança, e como tal é possível ao Canal obter informação acerca da mensagem e do pacote codificado antes deste ser transportado. 4.2 Arquitectura São bastante diferentes os adjectivos que podem ser usados para descrever a arquitectura do.net Remoting: desde fácil utilização, flexível, até complexo... apesar de serem contraditórios todos estes adjectivos são aplicáveis. Vamos começar por ver a 23

extensibilidade da arquitectura, no que diz respeito a objectos passados por referência. Objectos serializados e passados por valor não se aplicam nesta arquitectura. 4.2.1 Cliente O cliente pode ser definido como o objecto ou aplicação que pretende o uso de serviços de um objecto remoto. Dependendo da forma como estiver configurado, pode ou não saber se o objecto que está a utilizar é remoto. 4.2.2 Transparent Proxy Quando um cliente usa um objecto remoto, não possui uma referência directa para esse objecto; em vez disso o cliente faz invocações num proxy que está contido no seu AppDomain. Esse proxy é chamado Transparent Proxy, e tem exactamente a mesma definição do objecto real. Este proxy é criado a partir da meta data (informação sobre a informação) do objecto remoto. O Transparent Proxy é uma classe interna que não pode ser extendida ou substituída. 4.2.3 Real Proxy Para além do cliente do objecto remoto e do Tansparent Proxy, falta ainda fazer referência ao Real Proxy, que como o nome indica é também um proxy, que se situa entre o Transparent Proxy e o objecto remoto. O Real Proxy expõe um método que é invocado pelo Transparent Proxy tantas vezes quantas as invocações feitas pelo cliente ao mesmo método do Transparent Proxy. Contrariamente ao Transparent Proxy, o Real Proxy pode ser extendido ou totalmente substituído, que ao ser feito serve para a criação de novas 24

funcionalidades, não disponibilizadas por um Real Proxy normal, como por exemplo balanceamento de carga (load balancing), operações de segurança e de diagnóstico. 4.2.4 Client-Side Sinks O Real Proxy passa a mensagem para um conjunto de client-side sinks (processos internos do lado do cliente) que são responsáveis por verificar características especificas do contexto corrente. FIGURA 4.1 - OS ELEMENTOS PRINCIPAIS DA ARQUITECTURA DO.NET REMOTING. 25

4.2.5 Canais Os canais são usados para fazer o transporte de mensagens de e para os objectos remotos. Essas mensagens representam as invocações dos métodos remotos via proxy s e o respectivo retorno ou excepções. Existem dois tipos de canais: TCP e HTTP. Os objectos remotos têm que registar pelo menos um desses canais no.net Remoting Framework. Se um objecto registar múltiplos canais, o cliente pode escolher o canal a utilizar para fazer uma comunicação. O.NET Remoting Framework suporta a personalização dos canais existentes e a criação de novos. Cada canal tem associado um objecto responsável pela formatação (serialização) da informação, quer das chamadas dos métodos quer dos respectivos retornos. Por exemplo por defeito o canal HTTP tem por defeito associado o SOAP como objecto responsável por essas tarefas, que serão feitas de acordo com a especificação SOAP. Já o TCP tem associado por defeito um formatador binário. Para além de ser possível a criação de novos canais é também possível configurar os canais para utilizarem outros objectos de formatação de mensagens. Por exemplo o TCP pode ser configurado para utilizar o SOAP, e o HTTP para utilizar um formatador binário. Poder-se-ia por exemplo criar um objecto de formatação XML-RPC para utilizar em vez do SOAP... Uma questão interessante é qual o canal utilizado pelo.net Remoting para comunicar entre contextos dentro do mesmo AppDomain. Não é o TCP nem o HTTP; é um canal especial baseado numa instância da classe CrossContextChannel que está optimizado para o remoting dentro do mesmo processo. Neste caso não é preciso nenhum objecto de formatação. 4.2.6 Server-Side Sinks As mensagens que são encaminhadas por um canal são do outro lado recebidas por um conjunto de server-side sinks que são o paralelo aos client-side sinks. O último deles encaminha a mensagem para o objecto remoto. 26

4.2.7 Objecto remoto Um objecto remoto é um objecto que extende a classe System.MarshalByRefObject ou a classe System.ContextBoundObject. Esse objecto é também responsável por algumas tarefas como registar-se com pelo menos um canal; no entanto os ficheiros de configuração de servidor podem-se encarregar de todos estes pormenores. Um objecto no.net Remoting pode ser classificado como Server-Activated Object (objecto activado no servidor) ou Client-Activated Object (objecto activado no cliente). 4.3 Objectos activados pelo Servidor Quando activado no servidor, um objecto terá todo o seu ciclo de vida (instanciação) gerido pelo servidor que ostenta o objecto. Esse ciclo de vida é completamente independente do ciclo de vida do cliente. Tudo isto resulta de um modelo onde os objectos não são criados no momento em que o cliente faz o pedido de criação. Em vez disso o cliente recebe uma referência para o Transparent Proxy. O objecto remoto só é criado quando o cliente faz a invocação do primeiro método do objecto remoto. Com esta técnica é poupada uma viagem pela rede de duas mensagens (a de invocação da criação e a respectiva resposta), o que pode ser importante se estivermos a falar de redes bastante lentas ou sujeitas a muito tráfego. Teremos no entanto no momento da primeira invocação de um método um tempo de resposta sensivelmente mais lento dependendo no entanto do tempo se inicialização do objecto. Existem dois tipos de objecto activados no servidor: Singleton e SingleCall. 27

4.3.1 Objectos Singleton Um objecto Singleton é um objecto que terá apenas uma instância, e disponibiliza um ponto de acesso global. Este facto não é no entanto muito fácil de garantir principalmente num ambiente distribuído. Por exemplo, criar um objecto Singleton com DCOM. O DCOM não define nem disponibiliza um forma bem definida de procurar objectos já existentes num sistema distribuído. Um cliente DCOM chama o CoCreateInstance (ou um método que o encapsule) para criar e obter um apontador para uma nova instância do objecto. Para que objecto obtido seja sempre o mesmo, é necessário fazer algo mais. Por exemplo, o objecto pode enviar uma mensagem em broadcast/multicast á procura de outras instâncias da sua classe. Se o objecto (emissor) recebe uma resposta positiva dentro de um determinado tempo pré definido então ao cliente é passada a referência do objecto existente. O problema é que o DCOM só tem uma forma de controlar o tempo de vida de um objecto, que é através dos seus clientes. Ou seja, um cliente que instancie um objecto DCOM tem que manter a sua instância enquanto que se desejar ter um singleton, obrigando a que exista sempre um cliente pré definido a instanciar o objecto... e isto nem sempre funciona como se pretende. Felizmente o.net resolve este problema, criando um verdadeiro Server- Activated Singleton. Quando o cliente faz o primeiro pedido via proxy, a um objecto definido como singleton, uma nova instância será criada apenas se não existir nenhuma no servidor. Uma vez que um singleton poderá ser usado simultaneamente por n clientes, tem que ser existe a necessidade de suportarem execução multithread. O runtime do.net, garante que apenas uma instância de um objecto (quando este é singleton) existe num determinado ponto. Como já foi dito, a cada objecto remoto, é sempre associado um ou mais canais, sendo que é por esses canais que os objecto serão invocados. Sendo assim, um singleton existe sempre num determinado canal; isto é o mesmo que rescrever a frase acima - O Runtime do.net, garante que apenas uma instância de um objecto (quando este é singleton) existe num determinado canal. Mesmo 28

os singletons têm um tempo de vida associado. Isto porque não existe interesse num objecto consumir recursos por tempo indeterminado e constante, se por exemplo este não é utilizado durante um largo espaço de tempo. Existe apenas a necessidade de garantir que o ponto de acesso ao objecto é o mesmo apesar do objecto poder ser substituído várias vezes. Isto faz com que seja garantido que num determinado momento o objecto usado seja sempre o mesmo, mas o mesmo objecto não durará eternamente. FIGURA 4.2 EXEMPLO DE UTILIZAÇÃO DE UM OBJECTO SINGLETON 4.3.2 Objectos SingleCall FIGURA 4.3 EXEMPLO DE UTILIZAÇÃO DE OBJECTOS SINGLECALL 29

Os SingleCall são exactamente o oposto aos objectos falados até agora: por cada pedido de cliente é criado um novo objecto como tal não existe do lado do objecto nenhuma persistência de estado. Isto pode-se tornar bastante dispendioso a nível de gasto de recursos do sistema, principalmente se a instanciação dos referidos objectos for também bastante dispendiosa. 4.3.3 Exemplo: Classificações de Exames Vamos agora ver um exemplo de um objecto remoto que vai ajudar as instituições de ensino a disponibilizar as classificações de exame dos alunos. Este objecto remoto obtém as classificações de exames dos alunos do Servidor Web da Instituição em causa. Para tal passamos ao objecto uma string com os números dos alunos a retornar classificações separados por espaços, e recebemos a mesma string mas com os números seguidos do sinal = e da respectiva classificação. Por exemplo a seguinte string: 970311 954999 000567 obteria como resposta: 970311=09 954999=12 000567=10 4.3.3.1 O Objecto remoto Como já foi falado, para ser remoto e ser passado por referência o objecto tem que derivar da classe System.MarshalByRefObject ou indirectamente de uma outra que por sua vez já derive dela (P.e.: System.ContextBoundObject): namespace Classificacoes public class Server : MarshalByRefObject 30

public Server() Console.WriteLine("Construtor!"); ~Server() Console.WriteLine("Servidor foi Garbage Collected!"); public string GetClassificacoes(string Indices) // implementação Indices = Indices.Trim(); string url = "http://www.instituicao.pt/classificacoes.csv?var="; //.NET Regular expressions MatchCollection indicescoll = Regex.Matches(Indices,@"\s\S"); bool first=true; int lastindex = 0; string ind; foreach(match indice in indicescoll) ind = Indices.Substring(lastIndex, indice.index-lastindex).trim(); lastindex = indice.index; if(first) url += ind; first=false; else url += ("+" + ind); if(lastindex!= Indices.Length) urlstring += ("+" + Indices.Substring(lastIndex, Indices.Length-lastIndex).Trim()); //************* //CONTINUA 1 //************* Foram utilizadas expressões regulares disponibilizadas pelo.net, mais propriamente pelo C# para tratar a string com os números a obter valores. Estas expressões são bastante úteis no tratamento de strings. 31

Vamos agora criar um pedido HTTP e enviá-lo: //************* //CONTINUAÇÃO 1 //************* HttpWebRequest Pedido = (HttpWebRequest)WebRequest.Create(url); HttpWebResponse Resposta = (HttpWebResponse)Pedido.GetResponse(); Stream resp = Resposta.GetResponseStream(); byte[] bytes = new byte[1024]; int len = 0; StringBuilder strresp = new StringBuilder(); while(true) len = resp.read(bytes,0,1024); if(len == 0) break; for(int i=0; i<len; i++) strresp.append((char)bytes[i]); Resposta.Close(); //************* //CONTINUA 2 //************* Neste momento temos na variável strresp a resposta obtida. Vamos tratá-la e devolvê-la: //************* //CONTINUAÇÃO 2 //************* string notas = strresp.tostring(); indicescoll = Regex.Matches(notas,"\n"); lastindex = 0; string val = ""; string Retorno = ""; foreach(match indice in indicescoll) string s = notas.substring(lastindex, indice.index-lastindex).trim(); lastindex = inice.index; 32

val = s.substring(1,s.indexof("\"",1)-1); int x = s.indexof(",")+1; int y = s.indexof(",\"",x); cla = s.substring(x,y-x); Retorno += (val + "=" + cla + " "); return Retorno; Mais uma vez foram utilizadas expressões regulares para tratar as strings, neste caso a obtida do Servidor Web da Instituição de Ensino em causa. Repare-se neste inicio de exemplificação, que a única coisa necessária para tornar esta classe remota foi derivá-la da classe System.MarshalByRefObject directa ou indirectamente. Apesar de termos já um objecto remoto ainda não é possível ser usado por eventuais clientes porque ainda não foi registado na.net Remoting Framework. Para tal o nosso objecto pode ser encapsulado em várias formas: um Service do Windows, uma console application, ou até uma aplicação gráfica (GUI). Neste exemplo, e para ser o mais simples possível vamos criar uma console application. O servidor que vai ser criado vai ser responsável por fazer o registo. Esse registo pode também ser feito através de ficheiros de configuração como vai ser visto mais á frente; por enquanto vai ser feito programaticamente. Para começar, temos que atribuir á nossa aplicação servidora pelo menos um canal em que ela possa ser comunicada. Isso é feito através da utilização do método RegisterChannel disponível na classe ChannelServices: ChannelServices.RegisterChannel( new HttpChannel(8888) ); De seguida, é necessário fazer o registo do objecto atribuindo-lhe um tipo de activação. Neste caso vamos ter um Server Activated Object, e como tal usamos o método RegisterWellKnownServiceType disponível na classe RemotingConfigfuration: 33

RemotingConfiguration.RegisterWellKnownServiceType(typeof(Classificacoes.Server),"Classificacoes", WellKnownObjectMode.Singleton ); Como se pode ver, o registo necessita de três parâmetros: o tipo do objecto remoto, o seu URI e o modo de activação que poderia ser WellKnownObjectMode.SingleCall no caso de ser um objecto activado no cliente (CAO Client Activated Object ). WellKnownObjectMode é uma enumeração definida no System.Runtime.Remoting namespace. Para terminar temos de garantir que que a aplicação servidora fica disponível pelo tempo necessário para ser possível o acesso ao objecto remoto: Console.WriteLine("ENTER para terminar"); String keystate = Console.ReadLine(); O código completo, já com os namespaces necessários: using System; using System.Runtime.Remoting; using System.Runtime.Remoting.Channels; using System.Runtime.Remoting.Channels.Http; using System.Runtime.Remoting.Channels.Tcp; using Classificacoes; namespace IniciarClassificacoes class Host static void Main(string[] args) ChannelServices.RegisterChannel(new HttpChannel(8888)); RemotingConfiguration.RegisterWellKnownServiceType(typeof(Classificacoes.Server),"Classi ficacoes, WellKnownObjectMode.Singleton ); Console.WriteLine("Classificações disponíveis!"); Console.WriteLine("ENTER para terminar"); String keystate = Console.ReadLine(); 34