(Aproveitando para tirar a poeira :) ) 

Para quem quiser saber um pouco sobre software factories, foi publicado um artigo meu no Linha de Código.  O link é http://www.linhadecodigo.com.br/artigos.asp?id_ac=1360&pag=1 .

Neste artigo, é feita uma breve introdução ao conceito e é mostrada uma fábrica real: a Web Client Software Factory - voltada para desenvolvimento Web.  Ao final, há uma lista de referências para quem tiver maior interesse no assunto.

Estou me aprofundando no conceito de software factories, muito difundido pelas novas ferramentas da Microsoft, a saber o DSL toolkit e algumas software factories que já foram lançadas: para smart clients, aplicações móveis, serviços, jogos, etc.  Até inclui no meu hub uma enquete para ter uma idéia da utilização desse conceito em aplicações de médio ou grande porte.  Quem estiver utilizando, fique à vontade para postar comentários, mensagens, etc.

Ainda com relação a logoff no ASP.NET, um complemento ao post anterior: antes de qualquer redirecionamento, esqueci de citar que deve ser chamado o método FormsAuthentication.SignOut().  Esse sim remove o ticket de autenticação do usuário.  Recomendo ainda para quem for usar esse método que dê uma olhada em http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication.signout.aspx.  Tem algumas questões de segurança que devem ser tratadas, para prevenir ataques de replay, como por exemplo salver o status do usuário em storage persistente.

Eis algumas dicas bem interessantes de um colega (Cleviton Monteiro) sobre ASP.NET e AJAX: 

 

O IE não seta para cinza a cor de um campo que está desabilitado (enable = false). Portanto, para garantir que o usuário não vai ter problemas com usabilidade, devemos utilizar um estilo css para deixar o campo cinza.  Isto é feito da seguinte forma:

 - Criação de um estilo css no arquivo .css do projeto (ou verificar se já existe um);

 - Quando desejar deixar o campo desabilitado, setar a propriedade "CssClass" do TextBox com uma string com o nome do estilo.     Por exemplo: textBox1.CssClass = "disabled"; (onde disabled é o nome do estilo css).

 

Agora sobre AJAX:

- Problemas com componentes validators quando utilizados com ajax

Os componented de validação do ASP.NET 2.0 não funcionam com o AJAX RC. Segundo [1]:

"Microsoft is a bit behind in releasing a patch, via Windows Update, for ASP.NET 2.0.  This patch would solve the UpdatePanel/Validator control issues that have cropped up in previous versions of ASP.NET AJAX (b1, b2, RC1)."

Para resolver o problema sem ser pelo windows update, os passos seguines devem ser seguidos:

 - Copiar uma Validators.dll contida no bin do arquivo baixado em [3] para o bin do viewer;

 - Colocar esse mapeamento no web.config:

   <tagMapping>

        <add tagType="System.Web.UI.WebControls.CompareValidator"           mappedTagType="Sample.Web.UI.Compatibility.CompareValidator, Validators, Version=1.0.0.0"/>

        <add tagType="System.Web.UI.WebControls.CustomValidator"            mappedTagType="Sample.Web.UI.Compatibility.CustomValidator, Validators, Version=1.0.0.0"/>

        <add tagType="System.Web.UI.WebControls.RangeValidator"             mappedTagType="Sample.Web.UI.Compatibility.RangeValidator, Validators, Version=1.0.0.0"/>

        <add tagType="System.Web.UI.WebControls.RegularExpressionValidator" mappedTagType="Sample.Web.UI.Compatibility.RegularExpressionValidator, Validators, Version=1.0.0.0"/>

        <add tagType="System.Web.UI.WebControls.RequiredFieldValidator"     mappedTagType="Sample.Web.UI.Compatibility.RequiredFieldValidator, Validators, Version=1.0.0.0"/>

        <add tagType="System.Web.UI.WebControls.ValidationSummary"          mappedTagType="Sample.Web.UI.Compatibility.ValidationSummary, Validators, Version=1.0.0.0"/>

      </tagMapping>

Referencias interessantes sobre AJAX.

 [1] http://209.85.165.104/search?q=cache:1IEMd4dhsssJ:devjunky.wordpress.com/2007/01/25/aspnet-ajax-rtm-validator-problems-anyone/+asp.net+ajax+validator&hl=pt-BR&ct=clnk&cd=9&gl=br

[2] http://weblogs.asp.net/scottgu/archive/2007/01/25/links-to-asp-net-ajax-1-0-resources-and-answers-to-some-common-questions.aspx

[3] http://blogs.msdn.com/mattgi/attachment/1516974.ashx

[4] http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx

 

 

Ao utilizar o método FormsAuthentication.RedirectToLoginPage() após uma operação de logoff, ao logar novamente é retornada a página em que o usuário estava anteriormente à ação de logoff, e não a página principal da aplicação, como é o comportamento esperado.  Isso ocorre porque esse método inclui um parâmetro ReturnUrl na query string, que contém o endereço da página em que foi feito o logoff. Para corrigir esse problema, deve-se utilizar ao invés o método Response.Redirect(FormsAuthentication.LoginUrl), que se limita a redirecionar para a tela de login configurada, sem incluir parâmetros adicionais na query string.

Lá vão algumas descobertas com relação aos table adapters, uma novidade do ADO.NET 2.0 que permite utilizar adapters fortemente tipados:

- Ao criar queries em table adapters, percebi que sempre era necessário retornar sempre todas as colunas da query.  Quando isso não era feito, era lançada uma exceção de integridade do banco.  Vi isso em algum fórum, mas não encontrei uma explicação lógica.

- O Query Builder do Visual Studio pelo jeito não permite que se utilize a construção “in” do SQL. 

- Ao fazer qualquer alteração no banco (criação de colunas, modificação do tamanho máxima das colunas), é necessário refeti-la no dataset tipado correspondente, ou recriar o dataset.  Isso vale mesmo em situações onde o tamanho das colunas aparentemente não é relevante.  Deve ser devido a checagens de integridade que são feitas pelo dataset.

 

Devido aos problemas citadaos acima, pessoalmente cheguei à conclusão que muitas vezes é mais produtivo usar ADO .NET diretamente, ao invés dos table adapters.  Vamos aguardar o LINQ pra ver se será lançada uma solução adequada para mapeamento objeto-relacional.

Estou tirando a poeira do blog com algumas dicas resultantes de experiências que tive após o contato com o WCF em um projeto real (mais precisamente uma prova de conceito que deve evoluir para um sistema real).  Foi um trabalho interessante, que envolvia um sistema amplamente distribuído, onde um requisito importante era justamente a independência de protocolo de comunicação.

Com relação às dicas, ou melhor, lições aprendidas, aí vão elas:

- Ao criar no Visual Studio um projeto que exponha serviços WCF que devam ser hospedados no IIS, utilizar o template Website à WCF Service.  Esse template, por tratar-se de um projeto Web, evita problemas tais como criação de strings de conexão no próprio código compilado da aplicação, uma vez que o arquivo Web.config passa a ser usado para armazenar strings de conexão.  Além disso, referências para outros serviços WCF também são acrescentadas ao Web.config, sempre que o proxy para algum serviço WCF seja criado/atualizado.  Caso seja utilizado um template não-Web, essas referências são acrescentadas ao arquivo app.config, que não é reconhecido pelo IIS.

- Essa é bem útil: sempre que um serviço WCF retornar uma instância de ICollection, esta será representada no proxy para o serviço como um array.  Sendo assim, no cliente, esse array deve ser tratado como array, e não como ICollection.  Se continuar sendo tratada como ICollection, será gerado um erro de serialização.

- Ao lançar exceções em serviços WCF, não utilizar objetos que herdem de Exception, uma vez que o WCF não é capaz de serializar corretamente esses objetos.  Ao invés disso, utilizar classes comuns para encapsular os dados do erro e lançar FaultException<classe do erro>, onde <classe do erro> é a classe criada.  O construtor de FaultException recebe como parâmetro uma instância dessa classe.  O serviço, por sua vez, deve declarar que lança tal erro através do atributo [FaultContract(typeof(<classe do erro>)]

- Existem situações em que se deseja gerar um proxy dinamicamente para um dado serviço, cujo contrato não é conhecido em tempo de desenvolvimento.  Nesse caso, ao invés de usar o svcutil para gerar o proxy, pode-se usar uma ferramenta que a MS desenvolveu para esse cenário: o WCF Dynamic Proxy (http://wcf.netfx3.com/files/folders/development_tools/entry6148.aspx).  Avaliei essa ferramenta e ela atende perfeitamente esse requisito, porém com algumas limitações: não é suportada chamada assíncrona ao serviço, e é gerada uma exceção ao invocar operações que recebam como parâmetro um array.

Por enquanto, é isso.  Devo continuar me aprofundando em WCF e .NET 3.0 em geral e, qualquer descoberta interessante, vou postando por aqui :)

Ainda que com um pouco de atraso (afinal, faz um certo tempo que eu não posto...), desejo a todos um feliz 2007!  Esse ano que entra, pretendo me aprofundar em mais algumas tecnologias Microsoft (.NET 3.0, em especial WCF e WPF) e, sempre que possível, estarei postando descobertas técnicas e outras novidades!

Abraços a todos!

Monique

Há quase dois meses tive a oportunidade de assistir a uma palestra sobre gerenciamento de projetos ágeis, com o Márcio Tierno, da Compuware. Um dos aspectos mais interessantes da metodologia diz respeito a estabelecer prazo e custo fixo, e ir priorizando as funcionalidades do projeto de acordo com as preferências do cliente.  Ou seja, a cada nova interação (detalhe: cada interação deve durar no máximo 2 semanas), é gerado um release funcional, para que o próprio cliente possa avaliá-lo (e se for o caso, propor mudanças) e decidir quais são as features a serem entregues na próxima iteração.  Obviamente, se houver mudanças, features de menor prioridade serão substituídas pelas mudanças.  O que ocorre de fato é que a lista original de funcionalidades projetada no início do projeto dificilmente é implementada, uma vez que várias funcionalidades foram sendo substituídas à medida que o cliente ia amadurecendo o entendimento do escopo.  Resultado: projeto entregue no prazo, no custo combuinado e com o escopo o mais próximo possível do desejado pelo cliente.

Eu estava validando a arquitetura para uma prova de conceito que envolve o uso de Web Services utilizando um canal seguro de comunicação.  Existem soluções antigas para esse problema, como a habilitação do uso de SSL na configuração do serviço no IIS, além de soluções in-house para criptografia de mensagens e passagem de tokens de autenticação (ex.: login/senha) no cabeçalho das mensagens SOAP.  Essas soluções, apesar de funcionarem, apresentam algumas limitações:

- SSL é um protocolo que atua ponto a ponto, e não fim a fim. Isso significa que, havendo intermediários na comunicação cliente-servidor, a mensagem criptografada tem que ser descriptografada no intermediário, uma vez que uma nova seção SSL deve ser aberta a cada par de máquinas que se comuniquem.  Essa nova seção exigirá uma nova criptografia da mensagem, todo um processo de handshaking, etc.  Chamamos essa abordagem de "segurança a nível de transporte".  Nela, a segurança é totalmente delegada para o sistema operacional, havendo aí uma dependência de plataforma (apesar de que várias plataformas hoje em dia suportam SSL)

- o uso de soluções in-house claramente apresenta problemas de interoperabilidade, uma vez que cada organização estará adicionando seus próprios headers, implementando suas próprias políticas "from scratch".

Para solucionar os problemas acima, foi definido um conjunto de padrões: WS-*.  São vários padrões que se unem aos padrões já existentes para web services (SOAP, UDDI, etc.) para solucionar não apenas questões de segurança (autenticação, autorização, confidencialidade e integridade) mas também transações distribuídas, roteamento, envio de anexos binários, entre outros.  O WS-Security trata especificamente da parte de segurança, e implementa a chamada "segurança a nível de mensagem", o que significa que mensagem XML original é criptografada, com a flexibilidade de apenas partes dela poderem ser criptografadas, e tokens de autenticação são automaticamente anexados e criptografados, de forma transparente para o desenvolvedor.  Com isso não há nenhuma dependência em relação a plataforma.

A implementação MS para esses padrões é o Web Services Enhancements, ou WSE, que já está na sua versão 3.0. Esse não é um produto novo, mas só agora tive a oportunidade de avaliá-lo em um cenário real.  O legal é que ele interopera com o Windows Communication Foundation. 

A explicação abaixo está desatualizada em relação às maiores facilidades que o Windows Communication Foundation (WCF) fornece para segurança de Web Services, mas são úteis caso você precise rapidamente implementar segurança em seus web services e ainda não tiver um domínio a cerca das novas features do .NET 3.0, ou mesmo se não estiver planejando migrar código já existente para usar o WCF.

A título de exemplo da implementação de uma política de segurança para um web service, em geral são necessários poucos passos:

Após instalar o WSE 3.0, automaticamente o plug-in para o Visual Studio é instalado. Dessa forma, para habilitar o WSE em um web service, basta selecionar com o botão direito do mouse o projeto onde está o web service e clicar em WSE 3.0 Settings.  A seguinte janela aparecerá:

Os check boxes exibidos devem ser marcados para que o WSE seja habilitado no projeto em questão.

Vamos passar agora à definição de uma política de segurança.  Embora seja possível implementar políticas customizadas, o WSE já vem com um suporte pré-configurado a cenários comuns, a saber: autenticação com login/senha, certificado X.509, segurança integrada do Windows (autenticação via Kerberos), etc.  Vamor ver, por exemplo, o passo-a-passo para definir uma política com autenticação baseada em login/senha, com criptografia e assinatura digital das mensagens trafegadas.

Na aba Security, escolha as opções "Enable Policy" e "Add" em "Edit Application Policy":

O wizard de definição de política entra em cena, após ser solicitado que se digite um nome para a política.  Na primeira tela de configuração, é possível escolher se a política que está sendo definida é para um serviço ou para um cliente.  No nosso exemplo, estamos configurando a segurança de um serviço.  Ao mesmo tempo, podemos escolher o modo de autenticação desejado.

Também é possível definir já as políticas de autorização.  Basicamente, nomes de papéis e usuários são gerados no arquivo de polítca que será criado ao fim da execução do wizard (embora essa não seja uma opção muito segura - o ideal é que a sua aplicação faça uso de uma base de usuários e papéis). 

Um passo bem importante é a definição do nível de proteção que se deseja.  Particularmente, quando estamos trabalhando com autenticação do tipo UsernameToken (login/senha), ao escolhermos  a opção None, o WSE assume que a mensagem será protegida por SSL.  Observação: o uso do SSL não é forçado pelo WSE.  Nesse caso, você precisa configurar seu web service para usar a segurança a nível de transporte.

Finalmente, é solicitado que se especifique qual certificado será utilizado para a parte de criptografia e assinatura digital.  Certificados digitais em geral contém duas chaves: uma pública, usada para criptografar a chave simétrica que será utilizada na criptografia e descriptografia das mensagens, e uma chave privada, conhecida apenas por aquele que receberá a mesagem, e que será responsável por descriptografar a chave simétrica.  Essa é a base de funcionamento dos certiciados X.509, por exemplo.  Essa é na realidade uma descrição auto-nível: a criptografia e assinatura digital de mensagens envolve um processo um pouco mais complicado de intercâmbio de chaves derivadas, quando utilizamos autenticação com login/senha. Chaves derivadas são, como o próprio nome diz, "derivadas" a partir da senha do cliente, e são elas as chaves simétricas a serem utilizadas nos mecanismos de criptografia e assinatura digital (no caso de assinaturas digitais, o hash da mensagem é que é criptografado).

Ao fim do processo, uma tela de confirmação é exibida com as opçoes que você escolheu, e o wizard pode ser finalizado. Para usar a política, base usar o atributo [Policy("nome da política")] na classe do web service, depois de adicionar a referência à DLL Microsoft.Web.Services3. Caso os seus clientes também estejam utilizando WSE, eles também em geral seguirão um processo análogo para a habilitação do WSE (quando um proxy WSE será gerado) e definição da política de segurança. Para usar a política, é só chamar SetPolicy("nome da política") no proxy. Adicionalmente, pode ser necessário chamar métodos para anexar tokens de autenticação, dependendo de como a política foi configurada. Todo esse processo está bem documentado nos manuais e demos que vêm com o WSE. No caso dos clientes, é necessário que eles adquiram previamente uma cópia da parte pública do certificado do servidor. O WSE não suporta a obtenção dinâmica do certificado, tal qual ocorre no SSL. Um detalhe importante: o WSE vem com certificados digitais de teste, cujas instruções de instalação são incluídas na própria documentação. Mas para que esses certificados possam ser usados, é necessário que a opção "Allow test roots" tanto no servidor como no cliente. Também é importante lembrar que esses certificados não devem ser usados em ambiente de produção, tanto por questões de segurança como de performance.

Antes de finalizar este post, uma dica: o guia que está disponível para download em http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/wssp.asp.

Para que quiser conferir: https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=109340

Segue uma notícia importante sobre o Centro de Inovação MS Recife...

Fonte: http://www2.portodigital.org/portodigital/imprensa/ultimasnoticias/38966;42313;0805;1653;8463.asp

Centro XML transforma-se em Centro de Inovação Microsoft

Os Centros de Inovação Microsot foram criados em 2001 - na época, ainda sob a denominação "Centros de Tecnologia XML" - para atuarem como elo de integração entre as instituições educacionais, governo, mercado privado e empresas de desenvolvimento e integração de tecnologia, com o objetivo de acelerar a adoção das novas tecnologias Microsoft.

O Centro de Inovação Microsoft de Recife é a ramificação pernambucana desta iniciativa. Localizado noPorto Digital, ele conta com profissionais certificados e infra-estrutura composta de laboratórios, salas de reunião, salas de treinamento, servidores e estações de trabalho para atividades de capacitação profissional e transferência de tecnologia.

O Centro de Inovação Microsoft de Recife é um centro de excelência em Tecnologia Microsoft. Seu propósito é difundir tecnologias Microsoft, como a Plataforma .NET, e orientar empresas, instituições acadêmicas e desenvolvedores em geral na adoção e melhor utilização dessas tecnologias com:

      · Provas de Conceito (PoCs): projetos de software de menor escopo e duração, com média cinco semanas. O cliente, juntamente com o Centro de Inovação, define o problema a ser resolvido, que tipicamente consiste na validação de uma ou mais tecnologias Microsoft em um contexto específico. Uma semana para o treinamento desses colaboradores nas tecnologias a serem utilizadas também está incluida.
      · Adoption Labs: treinamento prático sobre a migração de certas plataformas para tecnologias Microsoft, como por exemplo, VB 6.0 para VB .NET, PHP para ASP.NET, Java para C#, Delphi para C#, Oracle para SQL 2005, etc.
      · Palestras e Workshops: eventos que visam promover a capacitação em tecnologias Microsoft. 
      · Acordos de Cooperação: representam parcerias entre o Centro de Inovação com instituições acadêmicas ou ISVs (Independent Software Vendors). Através desses acordos, parceiros usufruem do apoio do Centro de Inovação Recife para a aplicação de tecnologias e ferramentas Microsoft a suas necessidades.

O Centro de Inovação Microsoft de Recife utiliza e incentiva o uso de metodologia Pro.NET, que reúne as melhores práticas de RUP, Microsoft Solutions Framework e metodologia ágeis, a exemplo do XP.

O Centro de Inovação Microsoft de Recife já desenvolveu projetos de prova de conceito com as seguintes instituições:  Banco BGN, WHITec, Qualiti Software Processes, Centro de Informática - UFPE, MidiaVox, Ação Informática, WPD, CIEE, Inteligência Informática, ATI e Strive.

Centro de Inovação Microsoft de Recife.
Endereço: Rua do Apolo, 181, 1º. andar.
Fones: 81 34198137/8134.
Contato: Monique Monteiro - Gerente de Projetos. 
E-mail: monique@qualiti.com.br