Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«

A Dominação
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 





Por Dennes Torres
dennes@bufaloinfo.com.br
Dennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com

Criando sistemas distribuidos com o Visual Studio 2005

Pesquisa personalizada
Pesquisar Dicas:






A criação de sistemas distribuidos, aplicações que utilizem diversos servidores inclusive através da internet, é um grande desafio para desenvolvedores e profissionais de infraestrutura.

Desenvolvedores frequentemente conhecem pouco sobre a infraestrutura dos servidores. Profissionais de TI conhecem pouco sobre a área de desenvolvimento. Integrar as duas áreas para que as aplicações façam uso adequado dos servidores é um grande desafio para ambos os profissionais e o Visual Studio 2005 se propõe a simplificar este desafio.

Vamos então ver o passo-a-passo de criação de um pequeno sistema distribuido e desta forma entender melhor de que forma o Visual Studio irá nos auxiliar nesta tarefa.

No Visual Studio, selecione File->New Project e em Distributed System Solutions selecione um Logical DataCenter.

O Logical DataCenter é o diagrama que utilizamos para fazer o desenho da infraestrutura de rede da empresa e as conexões que existirão entre os servidores da empresa. Em geral este diagrama será criado por profissionais de infraestrutura. Porém a criação do diagrama envolve conhecimentos em desenvolvimento de software que os profissionais de TI hoje não possuem. Será um desafio aos profissionais de TI adquirirem este conhecimento.

Na Toolbox, vemos elementos específicos para o desenho de uma infraestrutura de rede.

Vamos começar definindo as zonas da rede. As zonas da rede são áreas de rede dentro das quais os servidores tem facilidade de se comunicarem, mas que são protegidas por firewalls, separando uma zona da outra.

As zonas de rede mais comuns em um desenho de infraestrutura são a intranet de uma empresa, a rede interna da empresa, e a DMZ, área onde são localizados os servidores que ficam visíveis na web. Em uma grande empresa haverão muitas outras zonas, tal como zonas isoladas por filiais, por exemplo.

Para definir as zonas de rede basta inserir o objeto Zone e definir o nome da zona pela janela de propriedades. Vamos fazer isso para a intranet e a DMZ.

O objetivo da criação do desenho de infraestrutura é que a equipe de TI especifique o que é e o que não é permitido no uso da infraestrutura disponível. Isso é feito através da especificação de constraints em cada objeto do diagrama de infraestrutura.

Para ver as constraints, basta clicar com o botão direito sobre um objeto e selecionar a opção "Settings and constraints".

Nas zonas, as constraints referem-se a quais servidores podem ser inseridos dentro de cada zona. Na intranet qualquer tipo de servidor pode ser inserido, mas na DMZ permitiremos a inserção apenas se servidores web, a inserção de outros servidores seria uma falha de segurança.

Cada zona tem 2 endPoints, um de entrada, outro de saida. Os endPoints são usados para comunicações de entrada e saida da zona, justamente no sentido de que as zonas são protegidas por firewalls e portanto toda a comunicação de entrada e saida das zonas passa através dos firewalls.

As constraints dos endpoints determinam que tipo de comunicação de entrada e saida pode existir em uma zona. Vejamos alguns exemplos especificando as constraints destes endPoints :

Entrada na DMZ

Apenas devemos permitir o uso de WebSiteEndPoint, nenhum outro. Assim estamos especificando que apenas serão permitidas comunicações com sites web nesta zona. Marcando a opção User Defined podemos também limitar a URL do site web com o qual será feita a comunicação, mas não faremos isso.

Quando marcamos a opção User Defined é aberta a opção WebSite, logo abaixo. Essa opção nos permite definir características de comunicação com o site web. São várias características de infraestrutura do servidor web. Não irei entrar em detalhes disso neste artigo, vamos deixar a opção "User defined" desmarcada.

Saida da DMZ

Neste endPoint vamos limitar a comunicação com banco de dados, mantendo apenas a opção DatabaseClientEndpoint selecionada.

Eventualmente, em uma comunicação entre empresas, o HTTPClientEndpoint precisaria se manter selecionado para permitir que o servidor web consulte servidores de outras empresas. Mas não utilizaremos esse recurso neste exemplo.

Entrada da intranet

Vamos permitir apenas o contato com servidores de banco de dados contidos na intranet.

Saida da Intranet

Vamos permitir apenas a saida de clients HTTP, que em geral farão consultas a webServices ou sites web.

Inserindo servidores

Vamos inserir um servidor de banco na Intranet, vamos chama-lo de srvBanco.

Vamos inserir um servidor web na DMZ. O servidor web já é criado com dois endPoints, um WebSiteEndPoint e um HTTPClientEndPoint, assim sendo por default permite tanto a entrada de requisições (consulta a sites e webServiceS) como a saida de requisições (aplicações consultando sites e webServices remotos).

Existe uma característica muito importante na especificação do servidor web : A autenticação. Por default a autenticação do servidor web é definida como NTLM. Isso é bom para servidores web que estiverem atendendo uma intranet, mas para servidores expostos na web na maioria das vezes desejaremos que a autenticação seja anônima.

Assim sendo, para definirmos que a autenticação utilizada pelo servidor web deverá ser autenticação anônima devemos abrir a pasta "Logical Server Settings", "InternetInformationServices","WebSites", "Authentication", então alteramos o item "AuthFlags" para Anonymous.

Já na pasta um pouco mais acima, "Application Constraints", vemos que o administrador de rede pode criar limitações para os itens de configuração mais críticos em um site ASP.NET, exatamente aqueles que envolvem infraestrutura : Membership, definindo qual será o banco de membership, a segurança, etc., segurança, definindo a forma de autenticação que as aplicações deverão utilizar e Session State, definindo a forma de armazenagem do ambiente de sessão.

Quando os itens estão desmarcados isso indica que não existem restrições. Quando marcamos um dos itens estamos criando uma restrição. Vamos criar uma restrição para a configuração de segurança.

A segurança deverá ser Forms ou None, não utilizaremos segurança windows nas aplicações contidas neste servidor.

Vamos alterar também as constraints do HTTPClientEndPoint. Por default ele pode ser client de sites web ou de serviços web. Vamos limitar isso : Aplicações contidas neste servidor apenas podem ser clients de webServices, não de sites.

Vamos inserir agora um windows client, fora das duas zonas, como se estivesse em qualquer local na web. Vamos chama-lo de winClient.

Vamos então começar a realizar as conexões entre os servidores. As conexões desenhadas no diagrama de infraestrutura são conexões possíveis de serem realizadas por quaisquer aplicações que sejam inseridas nesses servidores. Assim sendo o profissional de TI desenha as conexões como possibilidades, o arquiteto de soluções irá utiliza-las ou não.

Vamos começar ligando o winClient ao srvWeb. Uma ligação feita entre zonas (o winclient está fora das zonas, o srvWeb na DMZ) precisa passar pelos pontos de conexão nas zonas, indicando a passagem por um firewall e sofrendo as restrições aplicadas nessa passagem.

Vamos inserir um HTTPClientEndPoint no WinClient e então utilizar o Connection para fazer a conexão do WinClient até o srvWeb, passando pelo endPoint da DMZ.

Precisamos também conetar o servidor web ao servidor de banco de dados, então vamos inserir um DataBaseClientEndPoint no srvWeb e usar o Connection para fazer a ligação.

Application Designer

Agora que fizemos o desenho da infraestrutura, vamos fazer o desenho da aplicação. Para isso vamos adicionar um novo Application Diagram, clicando com o botão direito sobre a solution, no solution explorer.

Neste application Diagram vamos adicionar as partes de nossa aplicação. Vamos adicionar o seguinte :

Vamos configurar cada uma das aplicações, em especial as aplicações web. Agora não estaremos simplesmente inserindo restrições, estaremos realmente configurando o funcionamento da aplicação, criando visualmente o web.config que será utilizado nestas aplicações.

Vamos começar pelo site Web. Entrando na janela "Settings and Constraints", abaixo da pasta "Application Settings" devemos começar a configuração de nossa aplicação web. Clicando com o botão direito sobre o item "Configuration", podemos utilizar o item "Add Resource" para adicionar uma sessão System.web (SystemWebSectionGroup).

Dentro da sessão System.Web deveremos fazer o mesmo para adicionar uma sessão authentication na qual definiremos a propriedade Mode como "Forms". O diagrama nos obrigará a adicionar a chave credentials. Não falará nada agora, mas quando validarmos a aplicação reclamará da falta desta chave. Isso porque definimos, no servidor, a forma de criptografia de senha das credenciais.

De fato não usaremos a chave credentials para nada, mas essa configuração precisa estar ai para ser validada.

Vamos então repetir a mesma configuração para o webService, srvProdutos.

Feitas as configurações, vamos começar a conectar as aplicações. Vamos começar a conectar o WebService com a base de dados. No momento em que criarmos esta conexão será aberta uma tela para configurarmos as características de conexão com a base de dados. A string de conexão configurada será armazenada no web.config do WebService, isso já é feito automaticamente.

Vamos ligar também a aplicação web com o webService e a aplicação Windows com o webService. Ambas utilizarão os recursos oferecidos pelo serviço. O serviço irá oferecer métodos para nossas aplicações. Clicando com o botão direito sobre o endPoint do webService encontramos a opção Define Operations, pela qual podemos definir os métodos que o serviço irá oferecer para nossas aplicações.

Imaginemos, porém que desejamos que um dos métodos do serviço faça a devolução de um dataSet. O ideal seria que este dataSet fosse tipado. Porém na definição gráfica da aplicação não temos como definir um dataset tipado diretamente no diagrama (o que é uma pena - seria ótimo se fosse possível a partir do banco fazer especificação de datasets direto no diagrama da aplicação). Pior que isso, a aplicação por default não tem references para System.Data, o que nos impede de definir até mesmo métodos retornando dataSets não tipados.

Para resolver este problema precisaremos, neste momento, implementar o webService. Devemos clicar com o botão direito no webService e selecionar a instrução Implement Application.

Com isso o Visual Studio irá criar um projeto para nosso WebService com as características que já determinamos que ele deve ter. Feito isso aproveitamos para adicionar um references para system.Data e adicionamos um novo DataSet. Para simplificar podemos arrastar a tabela Products do Server Explorer para o dataSet. Observe neste ponto uma novidade : é criado um TableAdapter junto com a dataTable. Além de fazer o papel do antigo dataAdapter o tableAdapter também pode conter instruções para atualização direta da base de dados, conforme solicitado durante o Wizard de criação deste objeto.

Retornando ao diagrama da aplicação observamos que já conseguimos visualizar tanto as classes de System.Data como nosso novo DataSet através da definição de operações. O diagrama da aplicação é mantido sempre em sincronia com o projeto.

Vamos então criar 3 métodos nas operations de nosso WebService :

Test Driven Development

TDD é uma técnica que faz parte da metodologia XP para desenvolvimento de software. A idéia do TDD é que os testes dos softwares sejam criados antes dos próprios softwares e só depois seja criado o software para atender ao requisito do teste. Seria extremamente trabalhoso se não fosse uma grande novidade no Visual Studio 2005 : O VS já é capaz de fazer a criação dos testes automaticamente.

Porém estamos iniciando o exemplo pelo caso mais difícil, um webService. Um webService precisa estar hospedado em um servidor. Para execuções individuais o VS coloca no ar o servidor dele, mas para criar o teste precisamos de uma integração entre dois projetos distintos.

A primeira questão é a porta de comunicação. Quando rodamos o webService a porta de comunicação escolhida pelo serviço é aleatória. Para que a aplicação de testes que iremos criar consiga localizar o serviço precisamos fazer com que a porta de comunicações se torne fixa. Basta uma alteraçào nas propriedades do projeto do serviço.

Outra questão é a forma de autenticação ao servidor que hospedará o serviço. Por default ele exige autenticação windows. Porém configurando as start option do projeto do serviço podemos facilmente alterar esta configuração para que ele passe a aceitar conexões anônimas.

Feitas essas configurações poderemos então criar o novo projeto de teste, bastando clicar com o botão direito sobre a classe do serviço. O VS criará um novo projeto, adicionará a webReference para nosso webService e criará, dentro de uma classe de teste, um método de teste para cada um dos métodos de nosso serviço.

Como chamar os métodos do serviço o VS já sabe, o que ele não sabe é quais valores de retorno demonstram o sucesso do serviço. Sendo assim precisaremos fazer pequenas alterações nos métodos de teste para indicar isso ao VS.

Veja como fica o código :

   48     <TestMethod()> _

   49     Public Sub AlterarProdutoTest()

   50 

   51         Dim srv As New localhost.epSrvVendas

   52         Dim ds As localhost.dsProdutos

   53 

   54         srv.AlterarProduto(1, "Chai", 150, 7)

   55 

   56         ds = srv.ListarProdutos

   57 

   58         Assert.AreEqual(CType(150, Decimal), ds.Products.Rows.Find(1)("unitprice"), "Os dados não foram alterados")

   59 

   60 

   61 

   62     End Sub

   63 

   64     <TestMethod()> _

   65     Public Sub AumentarPrecoTest()

   66 

   67         Dim srv As New localhost.epSrvVendas

   68         Dim ds As localhost.dsProdutos

   69         Dim patual As Decimal

   70 

   71         ds = srv.ListarProdutos

   72 

   73         patual = ds.Products.Rows.Find(1)("unitprice")

   74 

   75         srv.AumentarPreco(1, 0.1)

   76 

   77         ds = srv.ListarProdutos

   78 

   79         Assert.AreEqual(CType(patual * 1.1, Decimal), ds.Products.Rows.Find(1)("unitprice"), "O preço não foi aumentado")

   80 

   81 

   82     End Sub

   83 

   84 

   85     <TestMethod()> _

   86     Public Sub ListarProdutosTest()

   87 

   88         Dim srv As New localhost.epSrvVendas

   89         Dim dados As localhost.dsProdutos

   90 

   91         dados = srv.ListarProdutos()

   92 

   93         Assert.IsNotNull(dados, "O conjunto de dados não foi retornado")

   94 

   95 

   96         Assert.IsTrue(dados.Products.Rows.Count > 0, "Não foram trazidos produtos")

   97 

   98 

   99     End Sub

Observe o uso do atributo TestMethod para indicar que tratam-se de métodos de teste. Observe também a forma como é utilizado o Assert para indicar o resultado do teste, sucesso ou não. Coube a nós montar a lógica que determina se o teste teve ou não sucesso.

Tendo construido os métodos de teste, vamos executa-los e constatar o óbvio : Todos eles irão falhar. Isso é realmente óbvio, já que ainda não produzimos os métodos de nosso serviço.

Vamos então produzir os métodos de nosso serviço e novamente executar o teste. Desta vez os testes indicarão sucesso. Assim sendo, antes de passar para as etapas seguintes nós garantimos que nosso serviço encontra-se funcionando, e não só isso : Deixamos a disposição uma aplicação de teste para o serviço de forma que, sempre que for necessário alterar o serviço, poderemos rapidamente identificar se a alteração funcionou ou se causou um problema.


System Diagram

Agora que fizemos a montagem do serviço, vamos completar o diagrama, indicando dentro de qual servidor as aplicações serão inseridas.

Dentro do application diagram clicamos com o botão direito e selecionamos a instrução Define Deployment. Ao escolhermos esta opção o Visual Studio cria um novo diagrama chamado de System Diagram. O System Diagram é como um intermediário entre o logical datacenter e o application diagram. Com o System Diagram iremos definir qual aplicação será inserida em cada servidor.

Ao ser exibido o System Diagram veremos inicialmente os servidores, conforme desenhados no Logical dataCenter. Mas observando no lado esquerdo da tela encontraremos uma tela de visualização das aplicações. Poderemos então arrastar as aplicações para dentro dos servidores em que elas ficarão.

Feito isso, estando cada aplicação em seu devido local, podemos clicar com o botão direito no System Diagram e selecionar a opção Validate Diagram. O Visual Studio irá validar as restrições definidas pela equipe de infraestrutura com as características das aplicações definidas pelos arquitetos da aplicação.

Neste caso deixei propositalmente um erro para vermos a reação do diagrama. Ele irá reclamar pois a aplicação web está conectada ao webService, mas nos servidores não existe uma linha de conexão que possibilite isso.

É simples : Os dois estão no mesmo servidor, então para que isso seja realmente possível devemos definir no logical datacenter uma linha de conexão do servidor para ele mesmo,assim essa conexão não será mais um erro.

Implementando as aplicações

Podemos agora clicar com o botão direito sobre o application diagram e selecionar a opção "Implement all applications". Ele irá implementar todas as aplicações que não tenham sido implementadas até o momento, criando o relacionamento entre as aplicações que, no nosso exemplo, trata-se da webReference da aplicação Windows e da aplicação Web para o WebService.



Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : lorena biazatti E-Mail : lorenabiazatti@hotmail.com
estou precisando de um exemplo de calendario que valide um resultado, ou seja crio um textbox com o nome: dia e mes, coloco o dia e mes la, e depois crio um button, como o nome resultado, sendo assim mecho la meu codigo e o resultado tem que ser datas comemorativas, como 12/10 dia das criancas, e outras datas, porem eu tenho que colocar tambem as datas moveis, tipo assim dia das criancas 12/11 caiu em uma quarta feira, mas ano q vem nao ira cair em uma 4 feira, so q nao estou conseguindo fazer essas datas moveis..se vc poder me ajudar..meu email e lorenabiazatti@hotmail.com mas porem preciso disso para dia 04/09