Apresentando o .NET Framework 3.0

David Chappell - Chappell & Associates

Aplicável a:

• .NET Framework 3.0 (anteriormente WinFX)

• Desenvolvimento no Windows

Resumo:

A versão 3.0 do Microsoft .NET Framework fornece um conjunto diverso de tecnologias, cada uma abordando um desafio significativo do desenvolvimento de aplicativos atual. (29 páginas impressas)

Nesta página

Descrevendo o .NET Framework 3.0
Aplicando o .NET Framework 3.0: um cenário
Compreendendo o .NET Framework 3.0: as tecnologias
Obtendo o .NET Framework 3.0: opções de distribuição
Conclusão
Para leitura adicional

Descrevendo o .NET Framework 3.0

O objetivo do desenvolvimento de aplicativos é sempre o mesmo: criar o melhor software possível no menor período de tempo. Todavia, a dificuldade é cada vez maior à medida que as plataformas nas quais os desenvolvedores trabalham se tornam cada vez melhores. No Windows, por exemplo, a interface Win32 original foi incorporada pelo .NET Framework, que é muito mais funcional. A versão 1.0, lançada em 2002, e a versão 2.0, lançada em 2005, do Framework fornecem um ambiente significativamente melhor e mais produtivo para as pessoas que desenvolvem e escrevem software para Windows.

O .NET Framework 3.0 (anteriormente conhecido como WinFX) é a próxima etapa desse processo. Aplicativos baseados nessa nova versão do Framework podem ser criados com o Visual Studio 2005, o que o torna familiar para a maioria dos desenvolvedores do Windows. Mas o .NET Framework 3.0 também é uma evolução que oferece mais do que a versão 2.0 do Framework. Planejado para lançamento no final de 2006, o .NET Framework 3.0 estará disponível para o Windows Vista, o Windows Server 2003 e o Windows XP.

Este documento fornece uma visão abrangente do .NET Framework 3.0 e de seus componentes. O objetivo é esclarecer o que é esta nova versão, examinar como suas tecnologias podem ser usadas e fornecer explicações breves dessas tecnologias.

Criando aplicativos modernos: os desafios

Atualmente, a criação de um aplicativo típico não é uma tarefa fácil. Os requisitos são substanciais. As preocupações tradicionais, como a capacidade de trabalhar com dados armazenados e permitir acesso por meio de um navegador da Web, ainda são importantes, mas não são mais suficientes. Os aplicativos modernos também apresentam uma série de novos desafios, incluindo os seguintes:

• As organizações estão cada vez mais adotando uma visão orientada a processos. Como a maioria dos aplicativos automatiza alguma parte de um processo comercial, pode ser útil tornar as etapas desse processo explícitas no código. Uma maneira eficiente de se fazer isso é usar tecnologia de fluxo de trabalho, uma abordagem que requer suporte para aplicativos baseados em fluxo de trabalho.

• Normalmente, os aplicativos se comunicam com outros aplicativos, dentro e fora da organização. Os aplicativos modernos também devem sempre se adequar a uma arquitetura orientada por serviços (SOA), expondo um pouco de sua funcionalidade, como serviços interoperáveis que podem ser acessados por outros softwares. A obtenção desses objetivos requer suporte para aplicativos orientados por serviços.

• As pessoas que usam um aplicativo normalmente precisam de uma forma de se identificar. Muitas tecnologias diferentes para definir e usar uma identidade digital estão em uso, e problemas como o do phishing são comuns. Por isso, um aplicativo moderno e as pessoas que o usam podem se beneficiar de um controle consistente de identidades digitais de usuários.

• Os requisitos de uma interface de usuário moderna aumentaram significativamente. Normalmente, o fornecimento de um real valor comercial pode exigir o trabalho com vários tipos de documentos, a utilização de gráficos de duas e três dimensões, a exibição de vídeos e muito mais. Tudo isso também precisa estar disponível para clientes nativos do Windows e navegadores da Web. O atendimento dessas necessidades requer uma abordagem unificada para várias interfaces de usuário.

Como os aplicativos de hoje em dia normalmente precisam lidar com alguns desses desafios ou com todos eles, a plataforma na qual esses aplicativos são baseados também deve resolver todos eles de uma maneira coerente e prática. O objetivo do .NET Framework 3.0 é fazer exatamente isso, para aplicativos do Windows.

Resolvendo os desafios: o que o .NET Framework 3.0 oferece

Conforme mostrado na Figura 1, a versão 3.0 do .NET Framework é baseada na versão anterior. Na verdade, nada da versão 2.0 do .NET Framework foi alterado; portanto, os aplicativos existentes criados nessa versão continuarão a funcionar como sempre. No entanto, quatro novos componentes foram adicionados ao .NET Framework 3.0: Windows Workflow Foundation, Windows Communication Foundation, Windows CardSpace e Windows Presentation Foundation. Esta seção descreve brevemente o que o .NET Framework 2.0 e cada um desses novos componentes oferecem.

Figura 1

O .NET Framework 2.0: uma base com finalidade geral para aplicativos do Windows

Embora ainda seja possível escrever software que use a interface Win32 diretamente, o .NET Framework se tornou o principal ambiente para novos aplicativos do Windows. Entre suas partes mais importantes estão as seguintes:

• O ASP.NET, que suporta a criação de aplicativos acessíveis pela Web.

• O ADO.NET, que permite que os aplicativos acessem dados relacionais e outros tipos de dados.

• O Windows Forms, que dá suporte à criação de interfaces gráficas do usuário para aplicativos do Windows.

• O System.XML, que permite que os aplicativos funcionem com dados definidos por XML, incluindo XSLT e XPath.

A versão 2.0 do Framework adicionou várias funcionalidades úteis em relação ao seu predecessor, incluindo tecnologia substancialmente melhorada para criar aplicativos da Web do ASP.NET, suporte para aplicativos de 64 bits que executam em versões de 64 bits do Windows e uma nova abordagem para manipular transações. Embora algumas partes do .NET Framework 2.0 tenham sido amplamente substituídas pelos novos componentes adicionados à versão 3.0, conforme descrito posteriormente, as tecnologias da versão 2.0 continuam sendo uma parte fundamental dessa nova versão.

Windows Workflow Foundation: suporte para aplicativos baseados em fluxo de trabalho

Um fluxo de trabalho é uma idéia simples: é apenas uma série de etapas executadas na mesma ordem. Pode-se até argumentar que qualquer aplicativo implementa um fluxo de trabalho, já que todo aplicativo executa algum processo. Mas a abordagem tradicional da criação de um aplicativo usando C# ou Visual Basic ou qualquer outra linguagem de programação é tornar as etapas desse processo implícitas no código. Isso certamente funciona, mas também incorpora o próprio processo profundamente na lógica de um programa, tornando o processo mais difícil de ser implementado e alterado.

O uso da tecnologia de fluxo de trabalho para implementar a lógica do processo pode ser uma maneira efetiva de resolver o problema. Em vez de entrelaçar a lógica em código comum, cada etapa do processo é definida explicitamente e executada por um mecanismo de fluxo de trabalho. O resultado é uma implementação limpa do próprio processo.

Os mecanismos de fluxo de trabalho não são uma idéia nova; existem vários disponíveis atualmente para Windows e outros sistemas. A Microsoft até fornece mecanismos de fluxo de trabalho incorporados em alguns de seus produtos. No entanto, como o fluxo de trabalho está se tornando uma abordagem principal para a criação de aplicativos, o fornecimento de uma única tecnologia de fluxo de trabalho para o Windows faz todo sentido. Isso é exatamente o que o Windows Workflow Foundation faz (cujo acrônimo oficial é WF). Ao fornecer uma tecnologia comum de fluxo de trabalho para o Windows, o WF dá a qualquer aplicativo baseado em fluxo de trabalho uma mesma base para construção. Os softwares fornecidos pela Microsoft usarão o WF, incluindo o Microsoft Office 2007 System e o Windows SharePoint Services, assim como aplicativos criados por terceiros.

No entanto, o fornecimento de uma tecnologia comum de fluxo de trabalho apresenta alguns desafios. Por exemplo, como uma abordagem única pode atender ao conjunto variado de requisitos apresentados por diferentes aplicativos de fluxo de trabalho? A resposta adotada pelo WF é usar uma visão bastante geral de fluxo de trabalho. Conforme mostrado na Figura 2, o fluxo de trabalho do WF é apenas um grupo de atividades que são executadas pelo mecanismo do WF. Cada atividade é realmente uma classe e pode conter qualquer trabalho que o criador do fluxo de trabalho considere necessário. As atividades podem potencialmente ser reutilizadas entre diferentes fluxos de trabalho, facilitando a criação de soluções automatizadas para novos problemas.

Figura 2

Outro desafio ao fornecimento de uma tecnologia comum de fluxo de trabalho é derivado da divisão tradicional entre fluxos de trabalho orientados por pessoas e fluxos de trabalho orientados por sistemas. Os aplicativos de fluxo de trabalho que são usados principalmente por pessoas precisam ser flexíveis, permitindo ações como alterações dinâmicas no processo. Os aplicativos usados principalmente por sistemas, isto é, por software, tendem a ser mais estáticos, mas precisam ser o mais eficiente possível. O WF é destinado aos dois tipos de uso e, portanto, inclui recursos orientados por pessoas, como a capacidade de fazer alterações em um fluxo de trabalho em execução, juntamente com o suporte a comportamentos orientados por sistemas.

Fornecendo uma tecnologia comum de fluxo de trabalho para Windows no WF, o .NET Framework 3.0 torna amplamente disponível para os desenvolvedores esse útil paradigma para a criação de softwares. Como a visão de software orientada por processos continua a ganhar popularidade, o uso de fluxo de trabalho provavelmente também crescerá.

Windows Communication Foundation: suporte para aplicativos orientados por serviços

Quer sejam criados usando fluxo de trabalho ou qualquer outra abordagem, a maioria dos aplicativos precisa se comunicar com outros aplicativos. A maneira como essa comunicação é feita avançou muito nos últimos anos. Após décadas de desentendimentos, todos os principais fornecedores concordaram em oferecer suporte aos mesmos protocolos de comunicação de aplicativos. Baseado no SOAP, esse acordo global sobre serviços da Web torna a interoperabilidade entre aplicativos baseados em diferentes plataformas de tecnologia, como o J2EE e o .NET Framework, significativamente mais simples do que no passado. Ele também torna a idéia de arquitetura orientada por serviços muito mais plausível para a maioria das organizações.

É claro que já existem abordagens suficientes para comunicação. No .NET Framework 2.0, por exemplo, as opções incluem as seguintes:

• ASP.NET Web Services, que fornece comunicação interoperável baseada em SOAP.

• .NET Remoting, que focaliza a comunicação entre aplicativos .NET.

• Enterprise Services, que oferece suporte para aplicativos transacionais e escalonáveis.

• System.Messaging, que oferece suporte a mensagens em fila por meio do Serviço de Enfileiramento de Mensagens da Microsoft (MSMQ).

• Web Services Enhancements (WSE), uma extensão do ASP.NET Web Services que fornece suporte a especificações mais recentes, como o WS-Security.

Todas essas tecnologias têm valor e todas têm uma função a desempenhar. Por que existem tantas soluções diferentes para resolver o que é essencialmente o mesmo problema? Em vez disso, por que não criar uma única base para a comunicação entre aplicativos baseada em serviços interoperáveis?

Isso é exatamente o que o Windows Communication Foundation (WCF) faz. Em vez de exigir que os desenvolvedores usem uma tecnologia diferente com uma interface de programação de aplicativo diferente para cada tipo de comunicação, o WCF (codinome original "Indigo") fornece uma abordagem que usa uma API comum. No ambiente do .NET Framework 3.0, a maioria dos aplicativos que usava uma das tecnologias que acabamos de listar usará o WCF para comunicação.

O WCF fornece suporte forte para comunicação interoperável por meio do SOAP, uma parte essencial da computação moderna. Isso inclui suporte para várias das especificações de WS-*, incluindo WS-Security, WS-ReliableMessaging e WS-AtomicTransaction. No entanto, o WCF não exige o SOAP e, portanto, outras abordagens também podem ser usadas, incluindo um protocolo binário otimizado, o enfileiramento de mensagens usando o MSMQ e a comunicação simples baseada em REST. O WCF também usa uma abordagem explicitamente orientada por serviços para comunicação. Em vez de tentar fornecer comunicação transparente entre objetos, o WCF interpõe a abstração levemente diferente de um serviço entre as partes da comunicação. Um dos objetivos dessa abordagem é soltar alguns dos acoplamentos rígidos que podem existir em sistemas de objetos distribuídos, tornando a interação menos sujeita a erros e mais fácil de alterar.

A comunicação entre aplicativos, seja dentro de uma organização ou entre organizações, é uma parte fundamental do software moderno. O .NET Framework 3.0 resolve esse desafio usando a abordagem orientada por serviços do WCF.

Windows CardSpace: controle consistente de identidades digitais do usuário

Considere como as pessoas se identificam atualmente na Internet. Na maioria dos casos, a identidade digital de uma pessoa é expressa como um nome de usuário simples. Combinada com uma senha, essa identidade é usada para acessar contas de email, comerciantes na Internet e até mesmo bancos e outras instituições financeiras online. Ainda assim, apesar de sua simplicidade (e ubiqüidade), nomes de usuários e senhas têm várias desvantagens. Aqui estão as duas mais importantes:

• As pessoas têm dificuldade para lembrar todos os nomes de usuários e senhas que escolheram para diferentes sites. Muitas pessoas usam os mesmos valores para diferentes sites, facilitando o problema de memorização, mas aumentando o risco de segurança.

• Nomes de usuários, senhas e outras informações pessoais podem ser roubadas por phishers. Com o envio de emails enganosos, os phishers convencem as pessoas a fazer logon em um site que é muito parecido com o site do banco da vítima, por exemplo. Mas, na verdade, o site é controlado pelo phisher e, assim que a vítima insere seu nome de usuário e sua senha, o phisher pode usar essas informações para se mascarar como o próprio usuário no site real.

A redução da severidade desses problemas exige uma nova abordagem para gerenciar identidades digitais. O Windows CardSpace, codinome original "InfoCard", é uma parte importante dessa abordagem. Para ajudar as pessoas a controlarem suas identidades digitais, o CardSpace representa cada identidade como um cartão de informações distinto. Se um site aceitar logons do CardSpace, os usuários que tentarem fazer logon naquele site verão uma tela de seleção do CardSpace semelhante à mostrada na Figura 3. Escolhendo um cartão, os usuários também escolhem uma identidade digital que será usada para acessar o site. Em vez de memorizar uma grande quantidade de nomes de usuários e senhas, os usuários precisam apenas reconhecer o cartão que desejam usar. Cartões diferentes também podem conter informações diferentes, permitindo que os usuários controlem exatamente o que cada site sabe sobre eles.

Figura 3

As identidades representadas por esses cartões são criadas por um ou mais provedores de identidade. Qualquer organização pode oferecer um provedor de identidade e, em vez de contar com nomes de usuários e senhas simples, normalmente cada identidade fornecida usará mecanismos de criptografia mais fortes para permitir que os usuários comprovem sua identidade. O próprio CardSpace também inclui um provedor de identidade auto-emitida que é executado em máquinas cliente. Com esse provedor, os usuários podem criar suas próprias identidades que não contam com senhas para autenticação. Os sites podem aceitar essas identidades auto-emitidas do CardSpace em vez de contar com a abordagem comum baseada em senha, reduzindo os problemas causados por senhas.

Se senhas não forem usadas para fazer logon em um site, os phishers não poderão roubá-las. Ainda assim, se os phishers puderem fazer com que um usuário faça logon em um site falso, eles poderão adquirir outras informações do usuário, como informações médicas confidenciais. A prevenção desse problema exige que os usuários consigam distinguir sites reais de sites falsos semelhantes criados por phishers. Para permitir isso, a organização que é proprietária de um site pode obter um certificado de alta garantia. Ao contrário dos certificados SSL simples de hoje em dia, a aquisição desse novo tipo de certificado envolve um processo muito mais rigoroso, incluindo uma prova mais sólida de que a organização que solicita um certificado é realmente quem afirma ser. Um certificado de alta garantia também pode ter um logotipo da empresa e outras informações para ajudar o usuário a determinar corretamente se um site que está usando o certificado é legítimo. Quando um usuário acessa um novo site, o CardSpace sempre exibe as informações no certificado daquele site usando uma tela padrão. Com base na força do certificado recebido, essa tela indicará níveis diferentes de garantia da identidade do site. O objetivo é forçar os usuários a tomar uma decisão explícita para confiar em um site e ajudá-los a identificar os sites nos quais podem confiar.

O Windows CardSpace é realmente parte de um meta-sistema de identidades. Baseado inteiramente em protocolos públicos abertos, esse meta-sistema define uma forma de usar diferentes tecnologias de identidade digital consistentemente em várias plataformas (incluindo sistemas operacionais diferentes do Windows) e diversos aplicativos (incluindo navegadores da Web diferentes do Internet Explorer). Ao oferecer uma maneira comum de selecionar identidades e outros dados no Windows, o CardSpace desempenha uma função essencial no meta-sistema. E por resolver o problema fundamental de identidades, o CardSpace também desempenha um papel importante no .NET Framework 3.0.

Windows Presentation Foundation: uma abordagem unificada para várias interfaces de usuário

A interface do usuário é uma parte importante de praticamente qualquer aplicativo. Mesmo assim, a expectativa dos usuários em relação a essas interfaces aumentou significativamente. As GUIs tradicionais orientadas por menus ainda são necessárias, naturalmente, mas os aplicativos podem precisar também exibir vídeo, executar animações, usar gráficos de duas ou três dimensões e trabalhar com vários tipos de documentos. E tudo isso deve ser possível, quer o aplicativo seja acessado em um cliente de desktop instalado ou por meio de um navegador da Web.

Tradicionalmente, todos esses aspectos da interface do usuário eram fornecidos de diferentes maneiras no Windows. Por exemplo, um desenvolvedor pode usar o Windows Forms, que faz parte do .NET Framework, para criar uma GUI do Windows. A criação de uma interface de navegador da Web requer o uso de HTML e talvez de applets Java ou código JavaScript. A exibição de vídeo pode contar com o Windows Media Player ou com software como o Flash Player da Adobe, enquanto formatos de documentos podem ser definidos pelo Microsoft Word, pelo formato PDF da Adobe, entre outros. O desafio dos desenvolvedores é claro: a criação de uma interface coerente do usuário para diferentes tipos de clientes usando tecnologias diversas não é simples.

Um dos objetivos principais do Windows Presentation Foundation (WPF), cujo codinome original é "Avalon", é resolver esse problema. Oferecendo uma base técnica consistente para todos esses aspectos da interface do usuário, o WPF facilita a vida dos desenvolvedores. Usando uma abordagem mais moderna, incluindo suporte para vídeo, animação, gráficos de duas e três dimensões e vários tipos de documentos, o WPF pode permitir que os usuários trabalhem com informações de novas maneiras. E, ao fornecer uma base comum para clientes de desktop e clientes de navegador, o WPF facilita a criação de aplicativos que trabalham com ambos.

A interface de exemplo mostrada na Figura 4, contendo imagens, gráficos ao vivo, exibições tridimensionais e outros itens, ilustra alguns dos recursos fornecidos pelo WPF. Em vez de exigir desenvolvedores com habilidades em várias tecnologias, interfaces de usuário como essa agora podem ser criadas de maneira mais consistente.

Figura 4

Um dos desafios enfrentados pelos criadores de interfaces de usuário são as diferentes funções necessárias para a criação de interfaces eficientes. Os desenvolvedores de software são necessários para criar a lógica por trás da interface, mas normalmente não são as pessoas mais adequadas para definir sua aparência. Designers e especialistas em interação entre o homem e a máquina normalmente são mais adequados para essa função. Ainda assim, tecnologias mais antigas, como o Windows Forms, são totalmente voltadas para o desenvolvedor. Não existe uma maneira realmente efetiva de colaboração entre desenvolvedores e designers. Para resolver esse problema, o WPF conta com a linguagem XAML. Uma linguagem baseada em XML, o XAML permite especificar uma interface do usuário de maneira declarativa em vez de especificá-la no código. Isso facilita muito a geração e o trabalho das ferramentas com uma especificação de interface baseada na representação visual criada por um designer. Na verdade, a Microsoft está fornecendo um novo produto, o Expression Interactive Designer, para fazer exatamente isso. Os designers poderão usar essa ferramenta (e outras fornecidas por terceiros) para criar a aparência de uma interface e, em seguida, fazer com que uma definição XAML dessa interface seja gerada. O desenvolvedor importa essa definição no Visual Studio e cria a lógica necessária para a interface.

Quando os desenvolvedores criam um aplicativo WPF instalado e que seja executado diretamente no Windows, eles têm acesso a tudo o que o WPF fornece. No entanto, para criar um cliente que seja executado dentro de um navegador da Web, os desenvolvedores podem criar um aplicativo de navegador XAML, normalmente chamado de XBAP. Fundamentado na mesma base que um aplicativo WPF instalado, um XBAP permite apresentar o mesmo estilo de interface de usuário dentro de um aplicativo de navegador que pode ser baixado. Potencialmente, o mesmo código pode ser usado para os dois tipos de aplicativo, o que significa que os desenvolvedores não precisam mais ter diferentes tipos de habilidades para clientes de desktop e de navegador. Como é normal nesse tipo de aplicativo sofisticado de Internet, um XBAP baixado da Internet é executado em uma área de segurança que limita o que o aplicativo pode fazer. Além disso, um grande subconjunto da funcionalidade da interface do usuário disponível para um aplicativo WPF instalado também pode ser usado em um XBAP.

Tanto aplicativos WPF instalados quanto XBAPs podem aproveitar o suporte gráfico moderno do WPF, incluindo a capacidade de usar aceleração de hardware, suporte para gráficos vetoriais e muito mais. Fornecendo suporte para gráficos mais avançados, o WPF possibilita uma série de opções de visualização de dados que não são possíveis com o Windows Forms ou outras tecnologias anteriores. O WPF também fornece a base para o XML Paper Specification (XPS), que define um formato padrão para exibição, distribuição e impressão de documentos de formato fixo.

As interfaces do usuário são uma parte complexa e importante dos aplicativos modernos. Por meio do WPF, o .NET Framework 3.0 apresenta uma solução mais completa e consistente aos desafios que essas interfaces apresentam. O objetivo é permitir que as pessoas que criam interfaces de usuário, tanto desenvolvedores quanto designers, façam seu trabalho de maneira mais eficiente.

Aplicando o .NET Framework 3.0: um cenário

Uma maneira de entender como um grupo de tecnologias funciona em conjunto é examinar um exemplo de como elas podem ser usadas. Imagine, por exemplo, um aplicativo que permite que os clientes e agentes enviem solicitações de seguro. Se esse aplicativo for implementado usando o .NET Framework 3.0, ele será semelhante ao mostrado na Figura 5.

Figura 5

A lógica comercial do aplicativo, mostrada na parte superior esquerda do diagrama, é implementada usando um fluxo de trabalho do WF. A manipulação de uma solicitação de seguro é um processo em várias etapas, incluindo a avaliação da solicitação em relação às regras de emissão de seguros da organização, talvez incluindo uma verificação do crédito do solicitante e a obtenção de uma aprovação da gerência. O fluxo de trabalho implementa cada uma dessas etapas como uma atividade, contando com outro software, se necessário. Para acessar dados armazenados, por exemplo, as atividades desse fluxo de trabalho usam o ADO.NET.

Essa seguradora fornece uma central de atendimento, permitindo que seus clientes solicitem seguro por telefone. O software cliente usado pelas pessoas que trabalham naquela central de atendimento, mostrado na parte superior direita do diagrama, é implementado como um aplicativo WPF instalado. Esse cliente comunica-se com a lógica comercial do aplicativo usando o WCF, usando um protocolo binário otimizado para comunicação WCF-WCF. Conforme mostrado na figura, os funcionários da central de atendimento contam com o Windows CardSpace para selecionar a identidade que usarão ao fazer logon no aplicativo.

Os clientes também podem solicitar seguro pela Web, e os agentes de seguro também podem enviar solicitações. Para permitir isso, o aplicativo usa o ASP.NET para comunicar-se com navegadores da Web. Como mostrado no canto inferior esquerdo do diagrama, os clientes que usam o Internet Explorer para acessar o aplicativo por meio de uma interface HTML comum ainda podem usar o CardSpace para selecionar a identidade que desejam apresentar. Terceiros também podem implementar um mecanismo de seleção de identidades para outros sistemas operacionais de cliente e navegadores, permitindo que o meta-sistema de identidades seja estendido para navegadores da Web e clientes não-Windows.

Agentes de seguro que acessam esse aplicativo pela Internet podem muito bem precisar de uma interface mais funcional. Conseqüentemente, eles podem contar com um XBAP, em vez de uma interface HTML simples. Conforme mostrado na parte central inferior do diagrama, isso dá aos clientes uma grande parte da funcionalidade de interface do usuário fornecida pelo aplicativo de desktop do WPF usado na central de atendimento. Os dois são criados sobre a mesma base e, portanto, os desenvolvedores de aplicativos podem reutilizar o mesmo código nos dois tipos de clientes. E, como com os outros tipos de clientes, os agentes podem usar o CardSpace para selecionar a identidade que desejam apresentar ao aplicativo.

Finalmente, é provável que esse aplicativo precise acessar e ser acessado por outros aplicativos. Se a aprovação de um cliente exigir uma verificação de crédito, por exemplo, isso provavelmente será feito por meio de um telefonema para um serviço externo. Ou talvez o aplicativo aceite solicitações diretamente de outro software, expondo os serviços que esses aplicativos externos podem invocar. Para casos como esse, mostrado na parte inferior direita da figura, o aplicativo conta com o WCF para comunicar-se usando serviços da Web padrão. Seja qual for a tecnologia na qual esses aplicativos são baseados, o suporte do WCF ao SOAP simplifica a interação com eles.

Esse cenário ilustra como alguns dos componentes mais importantes do .NET Framework 3.0 podem ser usados em um aplicativo típico. Várias opções foram omitidas e, por isso, esse exemplo simples não deve ser visto como uma ilustração completa do que essa família de tecnologias oferece. Ao contrário, o objetivo é fornecer uma idéia clara de como as várias partes do .NET Framework 3.0 podem ser usadas em conjunto para resolver problemas comerciais reais.

Compreendendo o .NET Framework 3.0: as tecnologias

Para obter uma noção real do que o .NET Framework 3.0 oferece, é importante explorar mais profundamente cada uma das tecnologias que o constituem. Esta seção fornece um breve tutorial sobre cada uma das cinco partes do .NET Framework 3.0. Para obter uma explicação mais detalhada de cada uma, consulte Para leitura adicional no final deste documento.

O .NET Framework 2.0

Figura 6

Atualmente, o .NET Framework 2.0 é uma parte fundamental do desenvolvimento do Windows e também é a base do .NET Framework 3.0. A Figura 6 ilustra as duas partes do Framework: o Common Language Runtime (CLR) e a biblioteca de classes do .NET Framework. Alguns componentes do .NET Framework 3.0, incluindo o WF, WCF e WPF, são implementados amplamente como extensões à biblioteca de classes do .NET Framework. No entanto, conforme descrito anteriormente, embora muitas partes da biblioteca de classes continuem a ser uma parte importante do mundo dos desenvolvedores, outras são incorporadas por novas tecnologias fornecidas pelo .NET Framework 3.0. O ASP.NET, por exemplo, ainda é a base para a criação de aplicativos que podem ser acessados por navegadores, e o ADO.NET ainda é usado para trabalhar com dados armazenados. Os desenvolvedores do .NET Framework 3.0 podem usar o WPF em vez do Windows Forms para criar uma GUI nativa do Windows e, normalmente, preferem o WCF ao ASP.NET Web Services, ao .NET Remoting ou ao Enterprise Services. Apesar dessas alterações, é importante entender que, até no mundo do .NET Framework 3.0, a versão anterior do Framework continua a ser uma parte central da vida de um desenvolvedor.

Windows Workflow Foundation

Um design orientado por processos, dirigido por um fluxo de trabalho, pode ser a abordagem certa para uma fração significativa de softwares para Windows. O objetivo do WF é permitir que os desenvolvedores criem e executem esses aplicativos baseados em fluxo de trabalho. A Figura 7 mostra os componentes fornecidos pelo WF para fazer isso.

Figura 7

Conforme descrito anteriormente, todo fluxo de trabalho é criado a partir de várias atividades. Os fluxos de trabalho e as atividades são apenas classes; portanto, os dois podem ser criados diretamente no código. O WF também fornece o Workflow Designer, uma ferramenta gráfica hospedada pelo Visual Studio para a criação de fluxos de trabalho. Não importa como um fluxo de trabalho é criado, suas atividades podem ser extraídas da BAL (biblioteca de atividades básica) fornecida com o WF ou de qualquer outra origem.

Depois de definido um fluxo de trabalho, ele é finalmente executado pelo mecanismo de tempo de execução do WF. Esse mecanismo conta com um grupo de serviços de tempo de execução para fazer a persistência do estado do fluxo de trabalho, controlar sua execução e muito mais. Todos esses itens — os serviços de tempo de execução, o mecanismo de tempo de execução e o próprio fluxo de trabalho — estão contidos dentro de algum processo do host. Esse processo pode ser qualquer processo do Windows, desde um simples console ou aplicativo WPF em execução em um desktop até um processo escalonável de servidor.

O entendimento do WF exige, ao menos, algum conhecimento de todos os seus componentes. As seções a seguir fornecem uma breve visão geral de cada um.

Fluxos de trabalho

Em sua essência, um fluxo de trabalho não é nada mais do que um grupo de atividades. O WF fornece suporte interno para dois estilos de fluxo de trabalho:

• Fluxos de trabalho seqüenciais que executam atividades em uma ordem definida. Como um fluxograma tradicional, um fluxo de trabalho seqüencial pode conter ramificações, loops e outras estruturas de controle. No entanto, por padrão, as atividades são executadas em seqüência, uma após a outra.

• Fluxos de trabalho de máquina de estado que implementam uma máquina de estado finita tradicional. Como qualquer máquina de estado, a atividade que é executada em uma hora específica é determinada pela combinação do estado atual e de qualquer evento recebido.

A opção seqüencial é útil para fluxos de trabalho bem-definidos, como os usados em processos puramente baseados em software. Eles são relativamente simples de criar e de entender e normalmente parecem mais naturais para a maioria dos desenvolvedores. Fluxos de trabalho de máquina de estado são uma opção melhor quando o caminho de execução é menos previsível. Um bom exemplo disso é um fluxo de trabalho que envolve interações com pessoas, em que qualquer pessoa pode cancelar o fluxo de trabalho em um determinado ponto. Resolver essa situação com um fluxo de trabalho seqüencial é possível, mas cada etapa pode ser uma ramificação: faça isso se o fluxo de trabalho não for cancelado, faça alguma outra coisa se ele for cancelado. A modelagem desse tipo de comportamento usando uma máquina de estado é significativamente mais simples, pois uma solicitação de cancelamento do fluxo de trabalho é apenas outro evento que pode ser recebido e manipulado em algum ponto.

O suporte para fluxos de trabalho de máquina de estado é um exemplo de como o WF tenta fornecer suporte a fluxos de trabalho de pessoas bem como de sistemas. Outro exemplo disso é o suporte oferecido pelo WF para alterar um fluxo de trabalho em execução. As pessoas podem ser imprevisíveis, e não é raro que alguém envolvido em um fluxo de trabalho queira adicionar uma etapa, cancelar uma etapa ou fazer alguma alteração no processo enquanto ele está sendo executado. Para que isso seja acomodado de uma forma controlada, o WF permite que o desenvolvedor crie um fluxo de trabalho para especificar se e como esse fluxo pode ser modificado enquanto está em execução.

A biblioteca de atividades básica

Os desenvolvedores são livres para criar atividades personalizadas. Na verdade, o objetivo da Microsoft é estimular o crescimento de um ecossistema do WF cheio de atividades reutilizáveis. Mesmo assim, começar com um conjunto comum de atividades básicas facilita a vida de todo mundo. O fornecimento desse conjunto comum é a função da BAL.

Um fluxo de trabalho não precisa usar nada da BAL. Mas muitos desenvolvedores descobrirão que a BAL facilita suas vidas, especialmente no início. Entre as atividades contidas na BAL estão as seguintes:

• IfElse: executa as atividades contidas em dois ou mais caminhos possíveis baseados no atendimento ou não de uma condição.

• While: executa repetidamente uma ou mais atividades desde que uma condição seja verdadeira.

• Sequence: executa um grupo de atividades uma de cada vez em uma ordem definida.

• Parallel: executa dois ou mais grupos de atividades em paralelo.

• Code: executa um bloco de código definido.

• Listen: aguarda um evento específico e executa uma ou mais atividades quando o evento é recebido.

• InvokeWebService: chama um serviço da Web.

• State: representa um estado em uma máquina de estado de fluxo de trabalho.

• EventDriven: define uma transição que contém uma ou mais atividades que devem ser executadas quando um evento específico é recebido enquanto estiver em um estado em particular.

• Policy: permite definir e executar regras comerciais usando um mecanismo de regras fornecido pelo WF.

Em vez de definir uma linguagem particular para especificar fluxos de trabalho, o WF adota a abordagem mais geral de uso das atividades. A BAL fornece uma "linguagem", mas quem usa o WF também tem liberdade para definir sua própria.

Ferramentas do Windows Workflow Foundation: o Workflow Designer

Uma das vantagens de criar aplicativos usando fluxos de trabalho é a capacidade de definir o fluxo de trabalho graficamente. O Workflow Designer do WF permite isso, conforme mostrado na Figura 8. Por padrão, as atividades na BAL aparecem na caixa de ferramentas, permitindo que um desenvolvedor as arraste e solte na superfície de design da ferramenta para criar um fluxo de trabalho.

Figura 8

Alguns desenvolvedores preferem escrever código. Eles não gostam de designers gráficos. O WF também permite essa abordagem (e algumas vezes a exige: geralmente as atividades são criadas diretamente no código). Também é possível combinar as duas abordagens, criando um fluxo de trabalho que usa tanto o Workflow Designer quanto a codificação direta. O objetivo é permitir que os desenvolvedores usem a abordagem mais produtiva para eles. E para oferecer suporte mais abrangente à ferramenta, os fluxos de trabalho também podem ser expressos em XAML, a mesma linguagem usada pelo WPF. Na verdade, os fluxos de trabalho criados com o Workflow Designer assumem como padrão uma definição XAML.

O mecanismo de tempo de execução e os serviços de tempo de execução

Conforme descrito anteriormente, o mecanismo de tempo de execução do WF tem a função de executar as atividades em um fluxo de trabalho. Como parte disso, ele conta com um grupo de serviços de tempo de execução. O WF inclui implementações padrão desses serviços, mas os desenvolvedores ambiciosos podem substituí-las conforme desejarem. Esses serviços oferecem suporte a alguns recursos diferentes, mas dois itens de maior interesse se destacam:

• Persistência: um fluxo de trabalho que está bloqueado aguardando por algum evento pode usar esse serviço para ter seu estado em memória automaticamente persistido no disco. Quando o evento ocorre, o serviço recarregará automaticamente o estado do fluxo de trabalho e reiniciará a execução. Isso é útil principalmente para fluxos de trabalho que envolvem pessoas, pois horas, dias ou mais tempo podem decorrer até que uma resposta seja recebida.

• Controle: as atividades em um fluxo de trabalho demarcam claramente a execução do processo que implementam. O serviço de controle do WF permite que um desenvolvedor faça com que as informações sobre a execução do fluxo de trabalho sejam automaticamente gravadas em um banco de dados. Por exemplo, um desenvolvedor pode desejar controlar quando um fluxo de trabalho é iniciado e quando é terminado, quando cada uma de suas atividades inicia e termina, entre outras informações.

Windows Workflow Foundation e outras tecnologias da Microsoft

A introdução de novas abordagens inevitavelmente influencia as já existentes. As novas tecnologias do .NET Framework 3.0 não são exceção e cada uma tem um impacto em outras tecnologias da Microsoft. Com o WF, o impacto inicial é sentido mais fortemente pelo Windows SharePoint Services, pelo Microsoft Office 2007 System e pelo BizTalk Server.

A introdução de novas abordagens inevitavelmente influencia as já existentes. As novas tecnologias do .NET Framework 3.0 não são exceção e cada uma tem um impacto em outras tecnologias da Microsoft. Com o WF, o impacto inicial é sentido mais fortemente pelo Windows SharePoint Services, pelo Microsoft Office 2007 System e pelo BizTalk Server.

Qualquer pessoa familiarizada com o BizTalk Server com certeza já notou a semelhança entre os recursos de orquestração desse produto e o que o WF oferece. Na verdade, a versão seguinte ao BizTalk Server 2006 substituirá a função de orquestração existente do produto pelo WF, fornecendo ferramentas para ajudar a migrar orquestrações existentes para fluxos de trabalho do WF. No entanto, é importante compreender que o WF e o BizTalk Server 2006 resolvem problemas totalmente distintos:

• O WF fornece uma estrutura geral para a criação de aplicativos do Windows baseados em fluxo de trabalho. Ele pode ser hospedado em qualquer processo, usar qualquer tipo de atividade e resolver qualquer tipo de problema comercial, incluindo fluxos de trabalho de pessoas e de sistemas.

• O BizTalk Server é um produto licenciado focalizado na integração de aplicativos empresariais, na integração entre empresas e no gerenciamento de processos comerciais. Ele oferece um amplo conjunto de adaptadores para conexão com vários sistemas e softwares, aceleradores para implementação de padrões, como RosettaNet e SWIFT, e suporte à monitoração de atividades comerciais. O BizTalk Server também oferece uma infra-estrutura e ferramentas de gerenciamento, juntamente com suporte para escalabilidade.

Como ele é a tecnologia padrão de fluxo de trabalho para Windows, o WF também pode aparecer em outros produtos e tecnologias da Microsoft no futuro. Seja qual for a opção da Microsoft, o WF certamente encontrará espaço em vários aplicativos criados por seus clientes.

Windows Communication Foundation

A alteração na comunicação orientada por serviços marca uma mudança na maneira como os aplicativos interagem. Explicitamente desenvolvido para oferecer suporte a aplicativos orientados por serviços, o WCF reflete essa mudança. Esta seção descreve os aspectos mais importantes do WCF, incluindo serviços e clientes, opções de comunicação e suporte para segurança, comunicação confiável e transações.

Serviços e clientes

Figura 9

Como mostrado na Figura 9, a idéia básica do WCF é simples: um serviço expõe uma interface que pode ser acessada por um cliente. Essa interface pode ser definida usando o Web Services Description Language (WSDL) e, em seguida, transformada em código, ou pode ser definida diretamente em uma linguagem como C# ou Visual Basic. Para uma interface simples que expõe um serviço de solicitação de seguro, a última abordagem pode ser semelhante ao seguinte:

[ServiceContract]
interface IInsuranceApplication
{
 [OperationContract]
 int Submit(int policyType, string ApplicantName);

 [OperationContract]
 bool CheckStatus(int applicationNumber);

 [OperationContract]
 bool Cancel(int applicationNumber);
}

A definição desta interface com C# é marcada pelo atributo ServiceContract. Esse atributo indica que o WCF pode expor métodos nesta interface como operações que podem ser chamadas remotamente. Os métodos da interface que estão expostos dependem de quais estão marcados com o atributo OperationContract. Neste exemplo simples, cada método está marcado com esse atributo e, portanto, todos eles estarão expostos a chamadores remotos. No entanto, isso não é necessário. É válido aplicar OperationContract a apenas alguns dos métodos de uma interface. Seja qual for a opção feita, alguma classe no aplicativo deve implementar essa interface, fornecendo código real para os métodos definidos pela interface. Quando isso é feito, o WCF torna os métodos marcados com OperationContract acessíveis aos clientes desse serviço automaticamente.

A Figura 10 fornece uma visão um pouco mais detalhada de como um serviço é realmente exposto a seus clientes. Em vez de acessar uma interface diretamente, um cliente conecta-se a um ponto de extremidade específico. Um serviço pode expor vários pontos de extremidade, potencialmente permitindo que diferentes clientes os acessem de diferentes maneiras.

Figura 10

Conforme mostrado na figura, cada ponto de extremidade especifica três itens:

• Um contrato, que descreve as operações que podem ser invocadas usando o ponto de extremidade. O contrato pode ser identificado usando apenas o nome da interface que define essas operações, que aqui é IInsuranceApplication.

• Uma ligação, que define como as operações do ponto de extremidade podem ser invocadas. Cada ligação define várias coisas, incluindo qual protocolo deve ser usado para invocar as operações, o tipo de segurança que deve ser usado e muito mais. O WCF inclui um conjunto de ligações predefinidas, como a BasicHttpBinding mostrada aqui, para a maioria dos casos, e também é possível definir ligações personalizadas. Como um único serviço pode expor vários pontos de extremidade, ele pode permitir acesso simultâneo a diferentes tipos de clientes através de diferentes protocolos e com opções de segurança distintas.

• Um endereço, que indica onde esse ponto de extremidade pode ser encontrado. Conforme mostrado na figura, o endereço é representado como uma URL.

Os fundamentos do WCF são simples. Como com a maioria das tecnologias de comunicação, os detalhes podem se tornar complexos, já que há muitas opções, mas a criação de aplicativos comuns do WCF não é difícil.

Opções de comunicação

Tipos diferentes de aplicativos criados por diferentes tipos de desenvolvedores precisam de formas de comunicação distintas. A abordagem mais simples para a maioria dos desenvolvedores é a RPC (chamada de procedimento remoto), que permite que um cliente invoque operações remotas da mesma forma como operações locais. Na interface mostrada anteriormente, por exemplo, um cliente pode invocar qualquer operação da maneira síncrona usual, esperando pacientemente até que uma resposta seja recebida. Essa opção é fácil para os desenvolvedores, e é a opção correta em algumas circunstâncias.

No entanto, o WCF também fornece várias outras opções. As seguintes opções estão incluídas:

• Chamadas que não têm resposta. Marcadas com o atributo OneWay, esse tipo de comunicação pode ser útil para enviar eventos ou outras interações unidirecionais.

• Comunicação assíncrona baseada em mensagens, usando envios e recebimentos diretos com mensagens XML.

• Manipulação explícita de mensagens SOAP, incluindo a capacidade de inserir elementos diretamente no cabeçalho do SOAP.

O WCF também permite que os desenvolvedores controlem vários aspectos locais de como um serviço se comporta. Usando o atributo ServiceBehavior, por exemplo, eles podem configurar se o serviço tem um thread simples ou vários threads, se uma nova instância do serviço é criada para cada chamada e outras opções.

Segurança, confiabilidade e transações

A comunicação básica — a habilidade de mover dados entre sistemas — é útil, mas raramente é suficiente. A maioria dos aplicativos precisa de mais do que isso. Por exemplo, a grande maioria dos aplicativos distribuídos precisa de algum tipo de segurança. O fornecimento de segurança pode ser complexo devido à variedade de abordagens e à diversidade de tecnologias em uso atualmente. Para permitir que os desenvolvedores criem aplicativos distribuídos seguros, sem forçá-los a entender todos os detalhes, o WCF conta principalmente com ligações de segurança. Por exemplo, o BasicHttpBinding mostrado anteriormente pode ser configurado para usar HTTPS em vez de HTTP simples, e outras ligações fornecem mais opções de segurança. O WsHttpBinding, por exemplo, oferece suporte ao WS-Security, permitindo autenticação interoperável baseada em SOAP, integridade e confiabilidade dos dados. Os desenvolvedores também podem criar uma ligação personalizada que forneça os serviços exatos de segurança de que seus aplicativos precisam.

Garantir a confiabilidade das comunicações também é essencial para muitos aplicativos. A abordagem tradicional dos serviços da Web, enviando SOAP sobre HTTP, é suficiente em alguns casos e isso é o que é feito quando BasicHttpBinding é usado. No entanto, existem muitas situações em que essa opção largamente usada não é suficiente. As mensagens que são transmitidas por um ou mais intermediários do SOAP, por exemplo, não podem contar com essa abordagem simples para a confiabilidade de ponta a ponta. Nesses casos, o WCF implementa o WS-ReliableMessaging. Ao escolher uma ligação que oferece suporte a essa opção, como a WsHttpBinding, um desenvolvedor pode obter transferência confiável de mensagens automaticamente.

Transações distribuídas também podem ser importantes em alguns aplicativos. O WCF baseia-se no System.Transactions, parte do .NET Framework 2.0, para permitir a criação de software transacional. Um método pode usar o atributo OperationBehavior para indicar que ele precisa de uma transação e para definir como essa transação se comporta. Para permitir transações distribuídas que sejam interoperáveis entre fornecedores, o WCF conta com a especificação WS-AtomicTransaction. Usando a tecnologia definida nesse acordo entre vários fornecedores, os aplicativos do WCF podem participar de transações que abrangem várias tecnologias, incluindo J2EE e outras.

Windows Communication Foundation e outras tecnologias da Microsoft

Conforme mencionado anteriormente, o WCF substitui várias tecnologias anteriores da Microsoft para criar aplicativos distribuídos. A maioria dos aplicativos que seriam criados usando o ASP .NET Web Services, .NET Remoting, Enterprise Services, System.Messaging ou WSE serão baseados no WCF. Os aplicativos do WCF podem interoperar com aplicativos do ASP.NET Web Services — os dois oferecem suporte ao SOAP padrão — bem como com aplicativos baseados no Enterprise Services, no MSMQ e na versão 3.0 do WSE. O WCF também pode ser usado pelo BizTalk Server 2006, e uma futura versão do BizTalk Server será baseada ainda mais diretamente no que o WCF oferece.

É importante compreender que, embora não sejam comumente usadas pelos novos aplicativos do .NET Framework 3.0, todas as tecnologias que o WCF substitui continuam fazendo parte desta versão do Framework, e todas terão o mesmo suporte de sempre. Os aplicativos criados com versões anteriores dessas tecnologias também continuarão a ser executados normalmente. A instalação e o uso do .NET Framework 3.0 não danificará o código existente.

Windows CardSpace

Seja por meio de um navegador da Web ou algum outro tipo de cliente, os usuários acessam aplicativos com freqüência pela rede. Como esses aplicativos normalmente exigem que os usuários se identifiquem de alguma maneira, a conseqüência inevitável disso é que as pessoas são normalmente forçadas a adquirir e apresentar informações de identidade para softwares remotos. O acesso a aplicativos da Internet por meio de um navegador fornece um exemplo muito comum disso, e os usuários de intranets normalmente também enfrentam o mesmo problema.

Conforme descrito anteriormente, hoje em dia as pessoas normalmente dependem de nomes de usuário e de senhas para identidades digitais, com todos os problemas que eles representam. O Windows CardSpace, parte do meta-sistema mais amplo de identidades, oferece uma abordagem alternativa para resolver esses problemas. Para obter um entendimento mais profundo de como o CardSpace funciona, é necessário conhecer os conceitos básicos do meta-sistema de identidades.

` O Windows CardSpace e o meta-sistema de identidades

Ao acessar um aplicativo (a partir de um navegador da Web, de um cliente específico ao aplicativo ou de alguma outra origem), normalmente os usuários apresentam algum tipo de identidade digital. Existem muitas variedades de identidades digitais, mas praticamente todas elas são representadas na rede por um token de segurança. Embora um simples token de segurança possa ser apenas um nome de usuário, um token mais complexo pode incluir um certificado X.509 ou um documento XML. Seja qual a forma como são representados, os tokens de segurança são o mecanismo típico para representar identidades digitais na rede.

Embora seja tentador acreditar que um dia todos nós adotaremos um formato de token de segurança comum, a realidade é que abordagens diversas continuam a ser usadas. Assim como carregamos vários documentos de identidade em nossas carteiras — carteira de motorista, cartão de crédito, cartão de milhas, etc. — sempre teremos várias identidades digitais representadas por diferentes tipos de tokens de segurança. Nenhum sistema de identidades único pode fornecer uma resposta universal e, portanto, vários tokens de segurança sempre serão necessários.

Todavia, os usuários ainda precisam de uma maneira para trabalhar consistentemente com suas várias identidades digitais. Embora nenhum sistema único de identidades seja suficiente, é possível criar um sistema de sistemas de identidade — ou um meta-sistema de identidades — que permita usar uma série de identidades digitais de maneira consistente. Trabalhando com terceiros, a Microsoft liderou o processo de definição desse meta-sistema. Baseado em tecnologias abertas de serviços da Web, como o WS-Security e o WS-Trust, esse meta-sistema define como identidades digitais podem ser adquiridas e usadas, independentemente do tipo de token de segurança do qual dependem.

Você pode considerar que o processo de emissão, aquisição e uso de identidades digitais exige três funções distintas. Essas funções são as seguintes:

• Usuário: algumas vezes chamado de sujeito, o usuário é a entidade que tem uma identidade digital.

• Provedor de identidade: um provedor de identidade fornece uma identidade digital para um usuário. Para a identidade digital atribuída a você pelo seu empregador, por exemplo, o provedor de identidade é normalmente um sistema, como o Active Directory. Para a identidade digital que você usa para acessar o site Amazon, o provedor de identidade é você, uma vez que você define seu próprio nome de usuário e sua senha. Identidades digitais criadas por diferentes provedores de identidade podem transmitir informações diversas e fornecer diferentes níveis de garantia de que os usuários realmente são quem dizem ser.

• Terceira parte confiável: uma terceira parte confiável é um aplicativo que de alguma maneira confia em uma identidade digital. Freqüentemente, uma terceira parte confiável usa uma identidade (isto é, as informações contidas no token de segurança dessa identidade) para autenticar um usuário e, em seguida, tomar uma decisão de autorização, como permitir que esse usuário acesse determinadas informações. Uma terceira parte confiável também pode usar a identidade para obter um número de cartão de crédito, para verificar se o mesmo usuário o está acessando em momentos diferentes ou para outros fins. Exemplos típicos de terceira parte confiável incluem sites da Internet, como bancos, comerciantes online e sites de leilão, além de qualquer aplicativo que aceite solicitações por meio de serviços da Web.

Esses três tipos de entidades interagem no meta-sistema de identidades. A Figura 11 ilustra essas interações e mostra onde o CardSpace se encaixa.

Figura 11

O processo começa quando um usuário acessa uma terceira parte confiável por meio de um aplicativo que reconheça o CardSpace. Para saber qual tipo de token de segurança essa terceira parte confiável solicitará, o aplicativo deve obter a diretiva da terceira parte confiável (etapa 1). Para um navegador que acessa um site, que é provavelmente o caso mais comum, a diretiva do site é expressa em HTML e enviada de volta como parte de uma página da Web. No entanto, para aplicativos acessados por meio de serviços da Web, o aplicativo usa o protocolo padrão da indústria definido pelo WS-MetadataExchange para pedir a diretiva à terceira parte confiável. Nesse caso, a diretiva é expressa usando WS-SecurityPolicy, outro padrão da indústria. Seja qual for a maneira pela qual as informações de diretiva são obtidas, ela sempre indica quais tipos de token de segurança serão aceitos por essa terceira parte confiável e quais informações esses tokens devem conter.

Assim que o CardSpace sabe de qual tipo de token de segurança a terceira parte confiável precisa, ele exibe a tela de identidade mostrada anteriormente. Cada identidade digital disponível para esse usuário é representada como um cartão de informações nessa tela. Os cartões emitidos por uma terceira parte confiável externa são conhecidos como cartões gerenciados, enquanto os emitidos pelo próprio provedor de identidade auto-emitida do CardSpace são conhecidos como cartões auto-emitidos. Os dois tipos de cartões podem ser mostrados nessa tela, e o usuário pode potencialmente selecionar um deles. Para facilitar essa decisão, a tela indica quais identidades atendem aos requisitos da terceira parte confiável, tornando cinza os cartões que não se qualificam. Em seguida, o usuário seleciona uma das identidades digitais que deseja usar (etapa 2).

No entanto, um cartão não contém um token de segurança real. Em vez disso, ele contém as informações necessárias para localizar um provedor de identidade específico e solicitar um token de segurança para este usuário. (Na verdade, cada cartão é criado originalmente por algum provedor de identidade.) O CardSpace usa o conteúdo do cartão selecionado pelo usuário para solicitar um token de segurança do provedor de identidade que emitiu o cartão (etapa 3). Essa solicitação é feita usando o WS-Trust, outro protocolo padrão da indústria, e os usuários se autenticam no provedor de identidade usando Kerberos, um certificado X.509 e uma assinatura digital ou outro mecanismo. O token é retornado em um formulário criptografado, que também contém um carimbo de data/hora para evitar que esse token seja roubado durante a transmissão e reutilizado no futuro.

Assim que o token de segurança solicitado é retornado, ele é enviado para a terceira parte confiável (etapa 4). A maneira como a terceira parte confiável usa as informações do token pode variar. Se o token contiver um certificado X.509, por exemplo, e estiver acompanhado por uma assinatura digital, a terceira parte confiável provavelmente usará o token para autenticar o usuário. No entanto, não há nenhuma exigência de que os tokens sejam usados para autenticação ou para qualquer outro objetivo de segurança. (Na verdade, o termo "token de segurança" é um nome inapropriado.) Um token pode conter informações, como uma prova da idade de um usuário, qualificação para um desconto em um site de compras na Internet ou qualquer outra coisa. A autenticação é um uso importante para tokens de segurança, mas não é a única opção.

É importante observar que nem o CardSpace nem o meta-sistema de identidades como um todo reconhece o formato ou a tecnologia usada para o token de segurança. Em vez de tentar criar uma nova origem única para identidades digitais ou um formato padrão para tokens de segurança, o objetivo do meta-sistema é fornecer uma maneira coerente de usar qualquer identidade digital baseada em qualquer tipo de token de segurança. Ao fornecer uma implementação do Windows de partes-chave do meta-sistema, o CardSpace desempenha uma função importante para tornar realidade essa abordagem geral para identidade digital.

Combatendo o phishing

Os provedores de identidade normalmente são diferentes do usuário, como quando uma identidade é atribuída por um empregador. Ainda assim há muitas situações em que, na verdade, os próprios usuários são o provedor de identidade. Se o CardSpace não for usado, por exemplo, o acesso a muitos sites exigirá o fornecimento de um nome de usuário e uma senha que são definidos pelos usuários. Depois de criarem essa identidade, os usuários podem fornecer o nome de usuário e a senha mais tarde e verificar seu saldo no banco, comprar um livro ou fazer qualquer outra coisa que o site permita.

No entanto, como dependem de senhas, esse tipo de identidades auto-emitidas é alvo de invasores, conforme descrito anteriormente. Para ajudar a reduzir esses ataques, o CardSpace fornece uma forma alternativa de criar uma identidade auto-emitida. Esse provedor de identidade auto-emitida é executado localmente no sistema Windows do usuário. Em vez de confiar em um nome de usuário e uma senha, os tokens de segurança criados pelo provedor de identidade auto-emitida são definidos usando a linguagem SAML, um padrão definido pela OASIS. Esses tokens contam com uma tecnologia de chave pública em vez de senhas para comprovar a identidade do usuário e, se uma terceira parte confiável os aceitar, eles podem desempenhar a mesma função que o nome de usuário e a senha tradicionais. A vantagem é que não existem mais senhas para os phishers roubarem. A redução do uso de senhas, juntamente com a comprovação mais rígida da identidade de um site fornecida por certificados de alta garantia descritos anteriormente, pode tornar o problema de phishing muito menos grave.

Windows CardSpace e outras tecnologias da Microsoft

O CardSpace está relacionado a várias outras tecnologias da Microsoft, incluindo as seguintes:

• WCF: como ele conta com padrões de serviços da Web, como o WS-Security e o WS-Trust, o CardSpace usa o WCF para comunicação. Na verdade, o criador de um aplicativo WCF pode fazer com que esse aplicativo use o CardSpace simplesmente especificando uma ligação específica.

• Active Directory: embora não seja possível atualmente, em algum momento o Active Directory passará a atuar como um provedor de identidade no meta-sistema.

• Windows Live ID (anteriormente chamado de Passport): como com o Active Directory, a Microsoft anunciou que seu sistema de autenticação Live ID também será modificado para atuar como um provedor de identidade. Observe que o CardSpace não é uma substituição do Live ID, pois os dois abordam problemas completamente diferentes. Ao contrário, o Live ID se tornará parte do meta-sistema de identidades como qualquer outro provedor de identidade.

A Microsoft também fornece outras tecnologias relacionadas a identidades que abordam problemas um pouco diferentes do CardSpace. Os Serviços de Federação do Active Directory (ADFS), por exemplo, se concentram em identidades externas entre organizações. Esse é um desafio importante e é enfrentado por muitas empresas que precisam trabalhar com outras organizações. No entanto, esse problema é completamente distinto dos problemas mais amplos abordados pelo CardSpace e o meta-sistema de identidades.

Windows Presentation Foundation

A lógica baseada em fluxo de trabalho, a comunicação orientada por serviços e as identidades são muito importantes para os aplicativos modernos. Ainda assim, os usuários normalmente se preocupam mais com o que vêem: a interface do usuário. O objetivo do WPF é resolver os desafios de criar interfaces do usuário para aplicativos modernos. Conforme descrito a seguir, o WPF fornece uma série de recursos para fazer isso.

Os recursos do Windows Presentation Foundation

Um desenvolvedor é livre para criar uma interface de aplicativo WPF inteiramente no C#, Visual Basic ou qualquer outra linguagem baseada em CLR. No entanto, conforme descrito anteriormente, o WPF também permite especificar uma interface usando o XAML baseado em XML. Os elementos e atributos do XAML são mapeados diretamente para as classes e propriedades fornecidas pelo WPF. Por exemplo, aqui está um botão simples definido em XAML:

<Button Background="Red">
 No
</Button>

Esse exemplo cria um botão vermelho que contém o texto "No" (Não). Exatamente o mesmo resultado também pode ser produzido com o seguinte código:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

Não importa como ele é definido; praticamente qualquer aplicativo WPF segue o mesmo modelo básico. O aplicativo herda o objeto Application padrão do WPF que fornece métodos, eventos e propriedades básicas. Um aplicativo WPF pode ter uma interface tradicional orientada por caixas de diálogo ou uma interface de navegação, permitindo que ele funcione de maneira muito semelhante a um aplicativo de navegador. Um aplicativo criado no estilo de navegador é normalmente implementado como um grupo de páginas, cada uma consistindo em uma interface de usuário definida em XAML juntamente com alguma lógica definida no código. Para vincular essas páginas, o XAML fornece um elemento Hyperlink, muito semelhante ao HTML. O aplicativo exibe uma página de cada vez, permite que um usuário avance e retorne pelas páginas, mantém uma lista de histórico e muito mais. Embora um aplicativo de navegação possa ser executado dentro de um navegador da Web como um XBAP, isso não é necessário. O desenvolvedor também é livre para usar esse estilo de interface em aplicativos WPF instalados. O objetivo é criar software que combine os melhores aspectos de uma interface de navegador e uma interface nativa do Windows.

Seja qual for o estilo usado por sua interface, um aplicativo WPF pode contar com painéis para o layout básico. Cada painel normalmente contém controles, e os controles fornecidos pelo WPF incluem Button, TextBox, ComboBox, Menu, entre outros. A maneira como esses controles são posicionados depende to tipo de painel escolhido. Por exemplo, um Grid permite posicionar controles em uma grade especificada, enquanto Canvas permite que o desenvolvedor coloque controles em qualquer lugar dentro de seus limites. E como sempre em uma GUI, os eventos gerados pelo usuário são capturados e manipulados por vários controles e outras classes no aplicativo. Também é possível aplicar estilos e modelos a grupos de controles, o que contribui para que os aplicativos tenham uma aparência uniforme.

O WPF oferece suporte a muito mais do que essas funções básicas da interface do usuário, incluindo o seguinte:

• Documentos: um aplicativo WPF pode exibir documentos XPS usando a marca FixedDocument do XAML. Um aplicativo também pode exibir documentos dinâmicos usando a marca FlowDocument. Um documento dinâmico pode se comportar como um documento tradicional na tela, permitindo que o usuário role por seu conteúdo. No entanto, com a definição de vários atributos nessa marca, um desenvolvedor pode tornar um documento mais adaptável ao seu ambiente. Um documento pode exibir uma página de cada vez, por exemplo, sem que o leitor precise rolar para a frente e para trás. O WPF também pode determinar automaticamente em quantas colunas um documento deve ser dividido com base no tamanho da janela na qual ele é exibido. O objetivo é permitir que os documentos na tela sejam o mais legíveis possível.

• Gráficos: o WPF inclui suporte para a criação de gráficos vetoriais de duas e três dimensões. Para trabalhos 2D, o WPF fornece abstrações padrão, como formas, pincéis e canetas, enquanto permite que gráficos 3D definam um modelo que pode receber informações de luminosidade e de posicionamento da câmera. Ao contrário de tecnologias anteriores, como o Windows Forms que conta com o GDI+ para gráficos, os gráficos do WPF não são particionados usando um conjunto separado de conceitos que os desenvolvedores precisam entender. Em vez disso, os elementos XAML usados para gráficos podem ser combinados naturalmente com os usados para qualquer outra finalidade em uma interface do usuário. Botões podem ter conteúdo gráfico, texto e gráficos podem ser combinados, e muito mais.

• Imagens: usando a marca Image do XAML, um aplicativo WPF pode exibir imagens em vários formatos, incluindo JPEG, GIF e outros. O WPF conta com o Windows Imaging Component (WIC) para fornecer uma estrutura padrão para codecs, software que exibe e armazena imagens. Como sempre no WPF, um elemento Image pode ser combinado com outros, permitindo objetos como um botão que exibe uma imagem em vez de um simples rótulo de texto.

• Mídia: um aplicativo WPF pode usar a marca MediaElement para exibir vídeo e áudio em vários formatos, incluindo WMV, AVI e MPEG. Mais uma vez, esse elemento pode ser combinado com outros elementos XAML, permitindo, por exemplo, um cubo 3D que exibe vídeo em suas laterais.

• Animação: o WPF fornece suporte interno para a animação da maioria das partes de uma interface do usuário. Um círculo pode aumentar ou encolher, por exemplo, ou um botão pode alterar de tamanho suavemente. Os aplicativos também podem definir storyboards contendo linhas do tempo, permitindo que seqüências coordenadas de animações ocorram.

• Ligação de dados: como muitos aplicativos WPF exibem dados, é útil contar com o suporte automático para mapear dados para elementos da interface do usuário. O WPF fornece esse tipo de ligação de dados para informações contidas em objetos e outras origens. A ligação de dados do WPF também permite classificar e filtrar os dados antes de exibi-los.

Aplicando o Windows Presentation Foundation

O WPF fornece um grande conjunto de funcionalidades da interface do usuário, permitindo que os desenvolvedores e os designers criem interfaces de usuário muito mais atraentes. Todavia, não importa quão atraente um aplicativo cliente pareça, algumas organizações podem evitar usá-lo devido a problemas de implantação. Se a implementação de uma nova versão do cliente exigir a modificação de cada máquina de desktop na qual esse aplicativo está instalado, o custo de atualização poderá ser significativo. Uma maneira comum de evitar esse problema atualmente é criar clientes baseados em navegador em vez de clientes nativos do Windows. No entanto, clientes nativos do Windows normalmente podem ter interfaces de usuário melhores e mais responsivas do que navegadores. Para resolver o desafio de implantar esses clientes, os aplicativos WPF instalados podem ser implantados com o uso do ClickOnce. Uma tecnologia que apareceu primeiro no .NET Framework 2.0, o ClickOnce permite que usuários do Internet Explorer selecionem um aplicativo na Web e, em seguida, o instalem automaticamente em sua máquina local. Depois de instalado, o aplicativo pode ser atualizado automaticamente quando uma nova versão é disponibilizada. O objetivo é combinar a simplicidade e a implantação acessível de um cliente da Web com a potência e a funcionalidade de um aplicativo WPF instalado.

Especialmente quando são implantados usando o ClickOnce, os aplicativos WPF instalados são uma boa opção de cliente em muitas situações. Todavia, há casos em que esse tipo de aplicativo não é apropriado, mesmo quando seus usuários poderiam se beneficiar do tipo de interface permitido pelo WPF. Pense nos agentes remotos de seguros do cenário descrito anteriormente, por exemplo, ou em um comerciante na Internet que queira fornecer gráficos 3D, vídeo e outros recursos modernos que são suportados pelo WPF. Normalmente, não é razoável esperar que os usuários desse aplicativo instalem um aplicativo WPF nativo para acessar o site. Uma solução melhor é dar aos usuários uma interface no estilo WPF dentro de seu navegador da Web.

Os aplicativos de navegador XAML — os XBAPs — são desenvolvidos para fazer isso. Em vez de implantar um aplicativo WPF instalado, um usuário do Internet Explorer pode baixar um XBAP diretamente no navegador. Executado dentro do Internet Explorer, esse aplicativo pode apresentar ao usuário uma interface baseada no WPF. Mas o download e a execução de código em sites da Internet podem ser perigosos. Para proteger o usuário contra desenvolvedores mal-intencionados, todos os XBAPs baixados da Internet são executados em uma área de segurança parcialmente confiável. Com base na segurança de acesso a código fornecida pelo .NET Framework, essa área de segurança limita o que os XBAPs podem fazer. Por exemplo, um XBAP baixado da Internet não pode criar janelas autônomas ou iniciar novas janelas, não pode exibir uma caixa de diálogo Salvar iniciada pelo próprio XBAP nem acessar o sistema de arquivos, exceto em uma área de armazenamento isolada. Mas, apesar das restrições impostas pela área de segurança, um XBAP ainda pode usar uma grande parte da funcionalidade do WPF, incluindo gráficos 2D e 3D, animações, documentos na tela, imagens, vídeo e muito mais.

Como descrito anteriormente, o WPF permite que os aplicativos exibam documentos adaptáveis usando o elemento FlowDocument do XAML. Mas documentos cuja aparência é alterada com base em como eles são exibidos não são sempre a melhor solução. Documentos de formato fixo que sempre aparecem da mesma forma em uma tela e em uma impressora, algumas vezes, são uma opção melhor. Os documentos XPS do WPF resolvem esse problema. Definidos com um subconjunto do XAML, os documentos XPS podem ser lidos em qualquer sistema que forneça um leitor de XPS. Eles também fornecem um novo formato de impressão para Windows, permitindo que gráficos complexos sejam impressos com mais fidelidade. E, para tornar o trabalho com diferentes tipos de documentos mais consistente, os documentos XPS e os documentos do Office 2007 usam as Open Packaging Conventions da Microsoft, que definem maneiras comuns de armazenar o conteúdo de documentos, assinar documentos digitalmente e muito mais.

Ferramentas do Windows Presentation Foundation

É possível criar qualquer interface do usuário do WPF diretamente no código e/ou no XAML usando um editor de texto básico. No entanto, a maioria das pessoas prefere trabalhar com ferramentas melhores e, portanto, a Microsoft fornece extensões do Visual Studio 2005 que permitem que os desenvolvedores criem aplicativos WPF. A próxima versão do Visual Studio, de codinome "Orcas", fornecerá ainda mais recursos com o Visual Designer para Windows Presentation Foundation. Usando essa ferramenta, os desenvolvedores poderão criar graficamente a interface do usuário que desejam ver e deixar que a ferramenta gere o código para essa interface.

Mas os desenvolvedores normalmente não são as pessoas mais indicadas para definir interfaces do usuário. Os designers normalmente são muito mais indicados para esse tipo de trabalho, pois são especializados em comunicação com as pessoas. No entanto, a maioria dos designers não escreve código. Por isso, o Visual Designer para Windows Presentation Foundation, hospedado no Visual Studio, não é uma ferramenta eficaz para os designers. Para permitir que os designers trabalhem com eficiência no mundo do WPF, a Microsoft criou o Expression Interactive Designer. Um designer pode usar essa ferramenta para definir a aparência de uma interface, especificar animações e muito mais e, em seguida, deixar que a ferramenta gere uma versão XAML do que é criado. Um desenvolvedor pode importar esse XAML no Visual Studio e adicionar código para tarefas como a manipulação de eventos. Como o Visual Studio e o Expression Interactive Designer usam o mesmo sistema de compilação, é possível que os desenvolvedores e os designers trabalhem em um projeto interativamente, cada um usando a ferramenta com a qual se sente mais confortável. O objetivo é ajudar as pessoas de disciplinas divergentes de design e de engenharia de software a trabalhar em conjunto com eficiência.

Windows Presentation Foundation e outras tecnologias da Microsoft

Como outros componentes do .NET Framework 3.0, o WPF tem impacto sobre as tecnologias existentes da Microsoft. As mais importantes são as seguintes:

• Windows Forms: a abordagem original do .NET Framework para criação de GUIs de aplicativos, o Windows Forms é usado em muitos aplicativos atualmente. Reconhecendo isso, o WPF permite que os controles do Windows Forms sejam hospedados em aplicativos WPF e que controles do WPF sejam hospedados em aplicativos do Windows Forms. Por exemplo, um aplicativo do Windows Forms pode hospedar um controle do WPF que fornece visualização de dados tridimensional. Embora existam algumas limitações, a criação de aplicativos que usam as duas tecnologias é certamente possível. Observe também que aplicativos existentes do Windows Forms continuarão a funcionar sem a necessidade de modificações no mundo do .NET Framework 3.0.

• Win32 e MCF (Microsoft Foundation Classes): como no Windows Forms, é possível hospedar controles do WPF em aplicativos existentes construídos usando essas tecnologias existentes e vice-versa. No entanto, a interoperabilidade é um pouco mais complexa do que no Windows Forms porque, ao contrário do Windows Forms, os aplicativos baseados no Win32 e no MFC não são baseados no CLR. Conseqüentemente, a interoperabilidade com o WPF também requer o mapeamento entre o código baseado em CLR e o código nativo do Win32.

• Direct3D: parte da família DirectX de APIs, o Direct3D permite que aplicativos criem e exibam gráficos 3D. Com o advento do .NET Framework 3.0, os principais aplicativos baseados no Windows podem usar os recursos de 3D no WPF em vez da abordagem mais especializada fornecida pelo Direct3D. Apesar disso, alguns aplicativos que precisam de um desempenho superior, como os jogos 3D, continuarão a usar o Direct3D. Na verdade, no fundo, o WPF conta com o Direct3D para todo o processamento.

• Windows Communication Foundation: conforme mostrado no cenário anterior, os aplicativos WPF podem usar WCF. No entanto, XBAPs normalmente não podem usar WCF, porque o WCF exige confiança total. Todo XBAP baixado da Internet é executado em uma área de segurança de confiança parcial, o que o proíbe de acessar o WCF. No entanto, os XBAPs podem usar o ASP .NET Web Services permitindo que eles façam chamadas de SOAP que interoperam com o WCF e com outras implementações de serviços da Web.

• "WPF/E": há mais um aspecto do WPF que precisa ser mencionado aqui, embora ele não faça parte do .NET Framework 3.0. Com codinome "WPF/E", seu objetivo é oferecer suporte a interfaces no estilo do WPF em sistemas que não oferecem suporte ao próprio WPF. Como o "E" em seu nome sugere, essa tecnologia tem o objetivo de estar disponível em todos os lugares ("everywhere"), inclusive em Macintoshes, pequenos dispositivos e outros sistemas. Agendado para lançamento algum momento depois do próprio WPF, o WPF/E fornecerá um subconjunto de toda a funcionalidade do WPF, inclusive gráficos 2D, animação e vídeo.

Obtendo o .NET Framework 3.0: opções de distribuição

Para que um aplicativo use o .NET Framework 3.0, essa versão do Framework deve estar instalada nas máquinas nas quais o aplicativo é executado. No Windows Vista, isso é muito simples: o .NET Framework 3.0 é instalado por padrão. Isso significa que novas máquinas com o Windows Vista instalado ou máquinas existentes atualizadas para o Vista poderão executar aplicativos do .NET Framework 3.0 automaticamente. No entanto, o .NET Framework 3.0 também pode ser executado no Windows XP e no Windows Server 2003. Para disponibilizar os novos componentes do .NET Framework 3.0 para os usuários existentes desses sistemas, a Microsoft disponibilizará esse software por meio de download gratuito.

Conclusão

O .NET Framework 3.0 é a evolução do modelo de programação do Windows. Baseado no .NET Framework 2.0 e como uma extensão dele, seu objetivo é oferecer suporte à criação de aplicativos modernos. Para isso, a versão 3.0 do Framework fornece um conjunto variado de tecnologias, cada uma abordando um desafio significativo do desenvolvimento atual de aplicativos. Baseando essa diversidade em uma fundação comum, a Microsoft está tentando tornar o todo maior do que a soma de suas partes, permitindo que os desenvolvedores criem aplicativos que usam as várias partes do .NET Framework 3.0 de maneira coerente.

Quaisquer que sejam os aspectos dessa nova versão adotados por uma organização, a tecnologia certamente terá um impacto substancial no mundo do software para Windows. Este é o momento de entender os benefícios do .NET Framework 3.0 para todos os que trabalham nesse mundo — desenvolvedores, arquitetos ou tomadores de decisões.

Para leitura adicional

• Understanding .NET, Second Edition. David Chappell, Addison-Wesley, 2006

• Introducing Windows Workflow Foundation (em inglês)

• Introducing Windows Communication Foundation (em inglês)

• Introducing InfoCard (Windows CardSpace) (em inglês)

David Chappell é diretor da Chappell & Associates (www.davidchappell.com) em São Francisco, Califórnia. Por meio de palestras, artigos e consultoria, ele ajuda os profissionais de tecnologia do mundo inteiro a entender, usar e tomar decisões melhores sobre software empresarial.