Arquitetura de Soluções

Uma grande onda está chegando...

Olá pessoal, tudo certo?

Depois do TechReady, vou tirar um tempinho de Férias, para recarregar as baterias.

Em breve, estarei de volta para acompanhar com vocês o que está chegando na plataforma Microsoft.

Veja que teremos uma agenda cheia pela frente, com PDC 2008, Tech.Ed Brasil 2008, SAF 2008, SOA & BP Conference, Microsoft Tracks, entre outros.

Será uma Grande Onda de novidades e tecnologias, preparem-se.

Por enquanto é só!!!

Arigatoo gozaimashita.

Um abraço a todos e até o próximo post, como sempre :)

Waldemir.

Do TCP/IP ao Software+Services, passando pelo REST...

Olá pessoal, tudo certo?

Algumas tecnologias aparecem por movimentos históricos. Outras através de discussões corporativas ou por oportunidades de negócio. Outras no meio acadêmico como frutos de pesquisa. E existem aquelas que aparecem devido a uma mudança de pensamento, de abordagem ou mesmo pela visão de um grupo de pessoas ou de um fenômeno social. A internet surgiu em nossas vidas como uma mescla de todos esses fatores.

Vamos olhar um pouquinho de história. Em plena Guerra Fria, a União Soviética cria o programa espacial Sputnik (que em russo significa "amigo"). Isso foi em 1957 e assim os soviéticos lançavam o primeiro satélite artificial a partir da Terra. Um choque para a humanidade.

Como a Guerra Fria movia a corrida tecnológica e sua principal representação estava no ambiente militar, a DARPA - Defense Advanced Research Projects Agency iniciou o projeto de construção de uma rede de computadores distribuída, descentralizada e que permitisse a segmentação de dados, assim como mecanismos de roteamento dinâmico, garantindo a comunicação entre todas as agências americanas envolvidas em caso de falha (ou ataque) de um de seus nós. Guerra Fria! A partir desse projeto surgiram os protocolos TCP/IP, que garantem esses mecanismos de transporte até os dias de hoje. Em outubro de 1969 o primeiro pacote TCP/IP via ARPANet era transmitido.

Os anos 60 e 70 avançavam e em 1974 o termo "internet" era usado pela primeira vez. Surgiram redes famosas como ARPANET, BITNET, MILNET, DARPANET, entre tantas outras. Em julho de 1980, um relatório da DCA - Defense Communications Agency, que administrava a ARPANET nesse período, já registrava 66 nós e mais de 4500 usuários!!! Hoje, somos mais de 1 bilhão e meio de usuários pela internet!!!

No final dos anos 80 a internet era liberada ao público, envolvendo universidades, agências civis e de pesquisa e assim, o mundo começava a mudar de forma irreversível. Em 1991, Tim Berners-Lee apresentou sua criação : a WWW - World Wide Web, uma interface orientada a links e páginas em hiper-texto (HTML), que seria o modo perfeito de navegação pela crescente massa de dados publicados na rede. O mundo não seria mais o mesmo.

A internet avançou pelos anos 90 mostrando seu valor informativo, obtendo adeptos de forma crescente. Vimos o surgimento de ferramentas e protocolos como Veronica, Gopher, Archie, Mozilla, Netscape, Telnet, FTP e assistimos as primeiras discussões sobre cliente/servidor, sistemas operacionais e a Sandra Bullock no filme "The Net". Algumas tecnologias não sobreviveram com o passar dos anos, mas em 1998 surge um elemento importante para a internet: o protocolo SOAP - Simple Object Acess Protocol. Até então, não existia uma especificação sobre XML e o processo de interoperabilidade entre empresas era muito custoso. A rede já se mostrava de grande valor para os negócios e com um potencial crescente para a integração de diversas indústrias. Por isso, a idéia de um padrão SOAP sobre HTTP que cruzasse as fronteiras de firewalls entre empresas era excepcional.

Entre 1998 e 2000, SOAP tornava-se o mecanismo ideal para a troca de informações e mensagens sobre o protocolo HTTP, que é a base da WWW. Nascia a visão dos Web Services, que permitiram a definição de serviços na web.

Nesses últimos 8 anos vimos diversas tecnologias surgindo ao redor da internet. Não vou me arriscar numa lista, mas gostaria de fazer uma simplificação: digamos que a internet passou por 2 grandes fases: da primeira fase, que eu chamo de web de páginas para a segunda fase, que vou chamar de web de serviços.

Enquanto na primeira fase, SOAP e sua especificação atendia plenamente o modelo rígido de exportação de dados através de API's via Web Services, sendo um veículo perfeito para troca de mensagens entre empresas (com envelopes SOAP), a segunda fase nasceu com o advento da WEB 2.0, com uma abordagem diferente para os portais e presença na web, aplicações de composição, searches e motores de busca sobre dados, etc.

Vamos falar um pouco sobre o fenômeno REST - Representational State Transfer. O termo REST foi definido em 2000, na tese de doutorado do PhD Roy T. Fielding. Entre os principais elementos da arquitetura REST, como definida na tese, temos:

• Todo recurso deve ser representado por um Id ou URI - Uniform Resource Identifier;
• Utilize links para a associação de recursos;
• Utilize métodos padrão, para consulta, alteração, criação ou deleção de recursos;
• Recursos podem ser representados em múltiplos formatos;
• Utilize comunicação stateless, sem estado, etc.;

Apesar de seus 8 anos de fundamentação acadêmica, só recentemente a Web 2.0 trouxe a necessidade pela representação de dados num formato mais dinâmico, permitindo a realização de interfaces ricas via web ou RIA - Rich Internet Application, assim como a flexibilidade e experiência do usuário obtidas com o AJAX - Asynchronous Javascript And XML. Essa necessidade fez crescer a discussão sobre arquiteturas RESTful.

Hoje, estamos presenciando até discussões RESTful-manics, por exemplo: sua arquitetura é LOW-REST ou HI-REST? Digamos que LOW-REST são interfaces menos rígidas e mais pragmáticas, mesclando alguns vevrbos do HTTP (GET, POST, PUT e DELETE) com estruturas AJAX e chamadas em formatos JSON, enquanto HI-REST são mais rígidas ou mesmo "puristas" em relação aos princípios do modelo original.

Seja SOAP ou REST, a web está se tornando cada vez mais uma web de serviços. Formatos e protocolos como JSON, ATOM, RSS, SOAP, REST, POX, etc. estão aparecendo enquanto caminhamos entre software local (on-premise) ou na nuvem (in the cloud). Voltamos ao assunto de sempre, o Software + Services. De fato, uma nova plataforma de serviços está sendo desenvolvida e a internet irá mudar novamente. Mais integração, interoperabilidade, escalabilidade, mas acima de tudo, mais opções para nossas arquiteturas e soluções.

Bom, depois dessa discussão, o que podemos dizer?

SOAP é show!!!
REST é show!!! 
Use WCF 3.5 para implementar os dois e fique de olho no Software + Services!!! 

Por enquanto é só! Até o próximo post :)

Waldemir.

O que é Software + Services?

Olá pessoal, tudo certo?

Em semana de TechReady vamos aproveitar para resgatar alguns assuntos já tratados aqui no Blog. Talvez o mais importante seja o Software + Services.

Quando pensamos nas diversas opções de integração entre sistemas, surge uma lista enorme de tecnologias e arquiteturas que historicamente conectaram nossas organizações nos últimos anos.

Desde os modelos baseados em chamadas RPC – Remote Procedure Call, passando por servidores TCP multi-thread, objetos distribuídos, componentes COM, Web Services, padrões e protocolos para internet, até as mais recentes organizações de software como serviço do SaaS e do SOA.

Envolvendo grande parte dessa evolução encontramos a chamada “computação na nuvem”, que dentro da estratégia Microsoft é conhecida como visão Software + Serviço (S+S). A essência dessa visão está em conceber aplicações que consomem dados locais e serviços locais (on-premise), assim como dados remotos e serviços remotos, publicados em provedores ou datacenters diversos e geograficamente distribuídos (in the cloud).

Como resultado, esse tipo de arquitetura fornece uma solução que é capaz de aproveitar tanto o poder de processamento da estação local ou do equipamento móvel (o “software”), como a capilaridade e a escalabilidade de diversos serviços online distribuídos e oferecidos pelo mercado, a partir da nuvem (o “serviço”). Um dos pontos fortes do S+S é o poder de composição de funcionalidades de diferentes fontes de dados e serviços, criando um mix de recursos com o melhor de cada mundo (por exemplo, os mundos web, mobile, desktop e enterprise).

Atualmente, a Microsoft está desenvolvendo uma série de frameworks, ferramentas e funcionalidades em seu roadmap de produtos para suportar essa visão. Suportar essa visão significa fornecer recursos para construir, executar, consumir e monetizar as soluções baseadas em S+S.

Para saber mais sobre cada uma dessas iniciativas, confira os artigos e material já disponível no link a seguir:

Software + Services (S+S)
Ref.: http://msdn.microsoft.com/en-us/architecture/aa699384.aspx

Por enquanto é só! Até o próximo post :)

Waldemir.

Microsoft TechReady - Seattle, WA

Olá pessoal, tudo certo?

Nos próximos dias estarei em Seattle (USA) para um congresso técnico na Microsoft, o TechReady.

O TechReady é um evento interno, fechado para funcionários da Microsoft de todo mundo, que agora em julho vai reunir perto de 6.000 técnicos em Seattle, em 5 dias de palestras.

O foco é 100% técnico e muitas sessões apresentam o roadmap de produtos e soluções na plataforma Microsoft, com os comentários dos vários times do produtos.

Por se tratar de um evento interno, muitos assuntos são apresentados como confidenciais. Mas para os tópicos públicos e principais anúncios, estarei publicando meus comentários para vocês. Fiquem ligados.

Por enquanto é só! Até o próximo post :)

Waldemir.

patterns & practices: Composite Application Guidance for WPF

Olá pessoal, tudo certo?

Um dos tópicos importantes para o consumo de funcionalidades de uma infra-estrutura organizada a serviços é a composição. As novas aplicações desenvolvidas com essa habilidade são conhecidas como aplicações compostas ou Composite Applications.

Recentemente, o time do patterns & practices publicou o Composite Application Guidance for WPF, que oferece esse poder de composição sobre a infra-estrutura do Windows Presentation Foundation (WPF).

patterns & practices Composite Application Guidance for WPF
Ref.: http://www.codeplex.com/CompositeWPF

Assim, fica a dica para conhecer esse material enquanto evoluímos nossas aplicações no ambiente corporativo.

Por enquanto é só! Até o próximo post :)

Waldemir.

Cenários de implementação de serviços com WCF : Fontes no Codeplex.

Olá pessoal, tudo certo?

Depois de uma série intensa sobre os cenários para serviços WCF, temos uma novidade para vocês : publicamos no Codeplex um projeto para soluções exemplos, implementando as diversas configurações e exemplos aqui estudados. O link é esse abaixo:

Codeplex - Cenários de Implementação de Serviços com WCF
Ref.: http://www.codeplex.com/cenarioswcf

O objetivo será colocar uma solução em C# para cada cenário apresentado nos vários posts da série. Em breve, as primeiras soluções e projetos para Visual Studio 2008 serão publicados. Para lembrar, os cenários foram:

Aproveite para dar suas sugestões e comentários. Essa é a idéia de um projeto no CodePlex.

Acompanhe também o blog do Rogério Cordeiro, que nos apoiou nessa iniciativa e também estará ajudando na evolução do código publicado, com o feedback de vocês.

Por enquanto é só! Até o próximo post :)

Waldemir.

Technorati Tags: SOA,WCF,Services,Codeplex

patterns & practices: Improving Web Services Security (Beta Release).

Olá pessoal, tudo certo?

Recentemente, foram disponibilizados novos livros do pessoal do patterns & practices. Gostaria de destacar um em especial...

patterns & practices Improving Web Services Security (Beta Release)
Ref.: http://www.codeplex.com/WCFSecurityGuide

Esse material é parte do projeto WCF Security Guidance Project do Codeplex, que alguns de vocês já conhecem.

patterns & practices: WCF Security Guidance Project
Ref.: http://www.codeplex.com/WCFSecurity

Muitas empresas estão em plena discussão sobre migração de Web Services para o novo modelo de programação WCF e questões como segurança e configuração de serviços têm sido frequentes.

Entre os assuntos tratados pelo GUIA acima temos:

• Fundamentos sobre segurança em WCF;
• Autenticação, Autorização e Identidades;
• Impersonation e Delegation com WCF;
• Segurança de mensagens e segurança de transportes;
• Fundamentos sobre bindings com WCF;

Ainda é uma versão beta, mas sem dúvida já é uma excelente leitura!!!

Por enquanto é só! Até o próximo post :)

Waldemir.

Technorati Tags: WCF,Services,Codeplex,Web Services

Cenários de implementação de serviços com WCF - Parte 6 : Serviços para Workflow

Serviços para Workflow

Olá pessoal, tudo certo?

Mais um cenário, importante na discussão sobre orquestração, coordenação de processos e fluxos de trabalho: serviços para workflows.

Em arquiteturas orientadas a serviços, é comum o uso de serviços de negócios que encapsulam um série de funcionalidades, disponibilizando esses recursos através de um firewall (em intranets) ou diretamente para clientes na internet. Como benefícios dessa publicação temos um melhor reuso, manutenção, isolação, tolerância a falhas, distribuição e escalabilidade.

Interfaces WCF tornam esse encapsulamento mais fácil, através da definição clara de contratos de mensagens e questões sobre o transporte e segurança. Porém, não temos uma definição sobre a ordem das chamadas ou execução desses serviços dentro da aplicação. Com o .NET 3.0 foi introduzido também o WF - Windows Workflow Foundation, que oferece mecanismos para a construção de workflows e pode ser hosteado em aplicações Windows. Com o uso de workflows ou fluxos de trabalhos, é possível coordenadar as atividades de negócio e requisições de serviços, sendo o método ideal para organizar chamadas para serviços WCF em processos de longa duração.

O .NET 3.5 trouxe novas funcionalidades e entre elas, uma maior facilidade para o consumo de serviços WCF a partir de fluxos de trabalho em WF. Isso tornou a integração WCF + WF muito mais direta e de fácial programação. Também com o .NET 3.5 temos o recurso de serviços duráveis, onde o estado de uma instância de serviço é automaticamente salvo entre chamadas. Isso torna possível a re-hidratação de uma mesma instância de serviço em diferentes máquinas.

A figura a seguir ilustra uma integração WF / WCF, onde um fluxo de trabalho consome uma funcionalidade exportado por um serviços WCF:

Podemos publicar um workflow em qualquer tipo de aplicações Windows. Alguns exemplos de implementação são:

• Uma aplicações cliente Windows que oferece um workflow que coordena chamadas para serviços WCF remotos, publicados no IIS, WAS ou um Windows NT Service;
  
• Uma aplicação ASP.NET que inicia um workflow para coordenar chamadas para serviços WCF remotos publicados em Windows NT Services atrás do firewall de um intranet.

Um video interessante sobre exportação de WF como services WCF é encontrado aqui:

Building WCF Services Using Workflow Foundation
Ref.: http://www.microsoft.com/uk/msdn/nuggets/nugget/285/wf-v35-building-wcf-services-using-workflow-foundation.aspx

Para finalizar, outro cenário típico para a aplicação de workflows é a aprovação e geração de documentos. Um artigo que ilustra bem esse exemplo é dado a seguir:

Crie fluxos de trabalho para obter dados e criar documentos
Ref.: http://msdn.microsoft.com/pt-br/magazine/cc534981.aspx

Nesses últimos dias, passamos pelas principais características de cada cenário, comuns em ambientes corporativos e soluções de negócio.

Aproveito para agradecer ao amigo Rogério Cordeiro, pelas discussões e questões levantadas até aqui. Em breve, vamos ter algumas surpresas como resultado dessas discussões.

Por enquanto é só! Até o próximo post :)

Waldemir.

Technorati Tags: SOA,WCF,Services,Workflow

Cenários de implementação de serviços com WCF - Parte 5 : Serviços com Filas de Mensagens (MSMQ)

Serviços com Filas de Mensagens (MSMQ)

Olá pessoal, tudo certo?

Um novo cenário para nosso estudo destaca os serviços com suporte a filas de mensagens. Comunicação assíncrona, que exige garantia de entrega de mensagens, recuperação ou simplesmente o tracking de mensagens são exemplos de recursos para esse tipo de serviço.

Os patterns de mensagens desconectadas garantem o baixo acoplamento para soluções orientadas a serviços. Como principal benefício, torna-se possível a construção de processos de longa duração, sem a necessidade de espera por respostas on-line, além da garantia de entrega de mensagens, para momentos onde serviços, equipamentos e redes estão off-line ou desconectados.

O Microsoft Message Queuing (MSMQ) é uma plataforma de mensageria que suporta este tipo de cenário, onde WCF amplia o conceito de componentes enfileirados (queued components) suportado pelo Enterprise Services do .NET 2.0. Desse modo, clientes WCF podem enviar mensagens para uma fila e serviços podem receber essas mensagens a partir da fila, usando um modelo de programação familiar aos outros recursos do WCF.

A principal característica desse cenário é que clientes e serviços não interagem diretamente, mas sim, através de uma fila de mensagens. Outros benefícios são:

• Garantia de entrega de mensagens de forma assíncrona;
• Mensageria desconectada;
• Cenários de publicação e subscrição;

A tabela a seguir apresenta as principais características para a configuração de serviços com suporte a mensageria:

Para a configuração de serviços e filas, temos 2 plataformas possíveis com WCF:

• MSMQ 3.0 on Windows Server 2003;
• MSMQ 4.0 on Windows Server 2008;

Para essas plataformas, o WCF oferece o binding de transporte NetMsmqBinding, que garante os detalhes de configuração para o envio de mensagens de forma assíncrona no MSMQ.

O NetMSMQBinding oferece um transporte baseado em encoding binário, permitindo um bom desempenho para o tratamento de mensagens. Oferece também segurança no nível de transporte e de mensagens, além do suporte a transações. Esse binding torna-se uma primeira escolha para cenários assíncronos de alta vazão e que precisem ser confiáveis, duráveis e com suporte ao modelo de mensageria unidirecional (queued One-Way Messaging).

Para cenários onde o serviço deve interagir com soluções MSMQ existentes, o binding indicado será o MsmqIntegrationBinding. O MSMQIntegrationBinding oferece um transporte para integração MSMQ com MSMQ encoding. Fornece a segurança do ambiente MSMQ, assim como o suporte a transação. É uma primeira escolha como binding para cenários de integração com aplicações MSMQ já existentes, além de ser de simples integração com o Host Integration Server e o Biztalk Server, quando existentes na solução.

A figura a seguir apresenta um exemplo de integração de mensagens com serviços WCF:

Um exemplo de aplicação de mensageria para o disparo de serviços é dado na demonstração Demux, disponível para download no link a seguir:

Custom Demux
Ref.: http://msdn.microsoft.com/en-us/library/ms752265.aspx

O exemplo acima apresenta como é possível disparar serviços através do endereçamento do header de mensagens enviadas para a fila MSMQ. Esse cenário é muito interessante para o tratamento de mensagens, criando um roteador de serviços muito comum em aplicações do mercado financeiro, por exemplo.

Outro artigo interessante para esse tipo de cenário é dado a seguir:

Queuing in WCF
Ref.: http://msdn.microsoft.com/en-us/library/ms789048.aspx

No próximo post, vamos falar de nosso último cenário, serviços de workflow... não percam!

Por enquanto é só! Até o próximo post :)

Waldemir.

Technorati Tags: SOA,WCF,Services

Cenários de implementação de serviços com WCF - Parte 4 : Serviços para Intranet

Serviços para Intranet

Olá pessoal, tudo certo?

Vamos falar hoje sobre Serviços de Intranet, um cenário importante para aplicações corporativas. Esse tipo de serviço vive atrás do firewall e por isso não utiliza protocolos de interoperabilidade, como SOAP, HTTP, etc. Cenários utilizando .NET Remoting e Enterprise Services são muito comuns na implementação de serviços para aplicações intranet e estão sendo gradativamente substituídos por serviços com WCF. Nesse contexto, podemos relacionar alguns tipos de implementação de serviços para intranet, como:

• Aplicações cliente/servidor clássicas, onde clientes Windows comunicam com serviços dentro do mesmo domínio Windows;
• Aplicações Web ASP.NET que consomem serviços atrás do firewall, expondo funcionalidades de negócio para as aplicações;
• Serviços distribuídos através de uma infra-estrutura orientada a serviços, consumidos por processos de negócios, camadas diversas, etc.;

A seguir, vamos olhar cada tipo de serviço e suas principais características.

Aplicações Cliente/Servidor

Em um típico cenário cliente/servidor, aplicações cliente acessam serviços instalados em servidores remotos dentro do domínio. Um banco de dados é usualmente parte da configuração, acessado através de serviços, nunca diretamente a partir da aplicação ou da camada de apresentação. Nesse cenário, WCF oferece grande facilidade para a exposição de funcionalidades para clientes remotos dentro da intranet.

A figura a seguir ilustra esse cenário, considerando a autenticação através de um AD ou lista de usuários válidos.

by M. L. Bustamente

A proteção das mensagens durante a comunicação entre cliente e servidor pode ser obtida através de criptografia e assinatura via certificados, criando um transporte com segurança.

A tabela a seguir apresenta as principais características e alternativas de configuração do cenário cliente/servidor:

Note que para alguns cenários, podemos utilizar protocolos de mensagens SOAP + XML, ao invés de SOAP + encoding binário. Devemos avaliar o impacto de performance nessa situação.

Outro ponto importante nessa discussão é que utilizando o Windows Server 2008, podemos configurar nossos serviços como hosted no WAS - Windows Activation Services, permitindo protocolos como TCP, Named Pipes e MSMQ, como vemos na figura a seguir:

Como alternativa ao WAS sobre Windows Server 2008, podemos publicar nossos serviços WCF em serviços NT (Windows NT Service), o que fará nosso transporte ser baseado em protocolo TCP para a entrega de mensagens. Assim, estaremos usando sockets TCP para a comunicação entre cliente e serviço.

Publicar serviços WCF através de Windows NT Service gera alguns contra-tempos, como:

• sempre que o serviço é atualizado, devemos reinicializar nosso Windows NT Service, para que as alterações sejam refletidas na produção;
  
• durante o processo de reinicialização do serviço, requisições feitas para o WCF serão rejeitadas. É importante notar que nesse cenário não existirá um mecanismo de enfileiramento de requisições ou mensagens, como ocorre no hosting baseado no WAS - Windows Activation Services;
  
• Finalmente, Windows NT Service não suporta pooling, monitoração, recycling ou gerenciamento de idle-time (ociosidade) para otimização de recursos;

De fato, para cenários de serviços no ambiente intranet, a utilização de WAS para hosting é a melhor opção por seus vários benefícios. Porém, para cenários de distribuição de serviços em ambientes não controlados, onde não garantimos a presença do WAS, Windows NT Service é a alternativa mais adequada.

Aplicações Web ASP.NET

Vejamos um segundo cenário de serviços na intranet. Em aplicações orientadas a serviços, uma camada de apresentação baseada em ASP.NET pode consumir serviços WCF através do firewall, acesando funcionalidades encapsuladas por esses serviços. Embora seja possível uma aplicação ASP.NET realizar chamadas diretas para os componentes de negócio, o uso de uma camada WCF oferece uma série de benefícios, como:

• Serviços podem encapsular necessidades de negócio recorrentes, permitindo que diversas aplicações reutilizem as mesmas funcionalidades, aumentando o reuso;
  
• A criação de uma fronteira de processos entre as páginas ASP.NET e os componentes de negócio pode aumentar a segurança do ambiente, reduzindo a superfície de ataque para códigos maliciosos ou acessos diretos aos dados da aplicação;
  
• Em muitos ambientes, uma DMZ é exigida entre a lógica de negócio e a camada de apresentação, significando um segundo firewall na infra-estrutura. Serviços WCF podem tornar mais fácil o consumo de funcionalidades através do segundo firewall.

A figura a seguir ilustra o cenário onde páginas ASP.NET e serviços WCF encontram-se na mesma máquina:

by M. L. Bustamente

A tabela a seguir apresenta as principais características de configuração do cenário onde serviços e páginas ASP.NET estão na mesma máquina:

Para cenários onde a camada de serviços encontra-se em outra máquina ou atrás de um firewall (como uma segunda DMZ), nosso protocolo de transporte torna-se o TCP e podemos utilizar certificados X.509 para a comunicação segura durante a troca de mensagens.

A figura a seguir ilustra o cenário onde páginas ASP.NET e serviços WCF encontram-se em máquinas diferentes:

 
by M. L. Bustamente

Assim, vimos que existem diferentes alternativas de configuração de um ambiente ASP.NET com serviços WCF, variando de acordo com as considerações de segurança e infra-estrutura presentes na solução.

Serviços Distribuídos para Arquiteturas Orientadas a Serviços

Um dos grandes benefícios na construção de arquiteturas orientadas a serviços é a composição de funcionalidades, obtida através do consumo de serviços distribuídos ao longo da organização. Um cenário típico de composição oferece uma camada de apresentação em ASP.NET, consumindo camadas de serviços WCF para processos, funcionalidades de negócio, acesso a dados, etc., permitindo uma escalabilidade crescente ao longo de sua utilização.

A figura a seguir apresenta um exemplo desse tipo de cenário:

Vejamos as opções de configuração indicadas para o cenário de serviços distribuídos na intranet.

Foi um longo post, mas conseguimos passar pelos principais cenários presentes no ambiente de intranet, enquanto utilizamos serviços WCF para encapsular nossa lógica de negócios e funcionalidades de aplicações.

No próximo post, vamos falar de um novo cenário, serviços de mensageria e chamadas assíncronas, fiquem ligados!

Por enquanto é só! Até o próximo post :)

Waldemir.

Technorati Tags: SOA,WCF,Services,Web Services,Intranet Services

Cenários de implementação de serviços com WCF - Parte 3 : Serviços para Web 2.0

Serviços para Web 2.0

Olá pessoal, tudo certo?

Vamos continuar nossa discussão sobre cenários de utilização de WCF. Hoje vamos falar sobre serviços para Web 2.0.

O modelo Web 2.0 tornou-se popular devido uma série de recursos como wikis, mashups, a colaboração entre usuários e comunidades, folksonomias, composições de funcionalidades, etc. Além desses recursos, as aplicações RIA - Rich Internet Application, que envolvem mashups, scripts AJAX, Silverlight e outras tecnologias recentes, trouxeram para a Web o poder de interfaces com mídia e conteúdo interativo. Como ponto principal nesse cenário, o cliente Web 2.0 precisa de uma abordagem que diminua o número de interações com o servidor, o que é obtido através de protocolos específicos para a troca de mensagens.

Assim, entre os protocolos de mensagens para clientes Web 2.0 citamos:

De fato, é possível construir serviços em WCF .NET 3.0 que suportam os protocolos acima, em serviços para Web 2.0. Usando o .NET 3.5, o WCF suporta nativamente esses protocolos, o que fornece um ganho adicional de produtividade e configuração para o desenvolvimento de nossos serviços.

A seguir, vamos olhar algumas características de cada combinação de serviços e protocolos de mensagens para a Web 2.0, considerando especificamente POX, REST, JSON, RSS e ATOM.

Características de serviços para Web 2.0 usando POX e REST:

Uma boa discussão com exemplos usando POX e REST é dada no artigo a seguir, veja:

POX and REST
Ref.: http://msdn.microsoft.com/en-us/library/aa395208.aspx

No link acima, você encontra exempos de serviços com interfaces POX e REST, assim como detalhes da interface e comportamentos no WCF. Para esse tipo de implementação, a tabela a seguir apresenta algumas das principais características do cenário.

Assim, quando observamos as interações com serviços POX temos:

Do mesmo modo, quando observamos as interações com serviços REST temos:

Note que para serviços REST, os verbos HTTP (get, post, put e delete) são utilizados, permitindo a construção das chamadas arquiteturas RESTfull, muito interessantes tanto para a exploração de dados via internet, como para a construção de clientes RIA simplificados e de grande flexibilidade no consumo de serviços diversos.

Características de serviços para Web 2.0 usando JSON:

Uma implementação comum para o consumo de serviços JSON, SOAP e XML é o uso do objeto XmlHttpRequest. Ele permite um desenvolvimento flexível para esses vários formatos, facilitando o consumo na ponta cliente. A figura a seguir ilustra o cenário:

Uma boa referência de artigo com exemplos de serviços usando JSON você tem no link abaixo:

Weakly-typed JSON Serialization Sample
Ref.: http://msdn.microsoft.com/en-us/library/bb943471.aspx

Características de serviços para Web 2.0 usando RSS e ATOM:

Uma pergunta frequente para cenários de serviços para Web 2.0 é se podemos usar contratos para POX/REST, JSON e sindicalização (RSS/ATOM) no mesmo serviço WCF. Sim, é possível. Para cada contrato implementado, suportamos um conjunto de operações específicas, ainda que todas elas implementadas pelo mesmo serviço. Vale conferir mais sobre WebHTTPBinding e WebHTTPBehavior. Veja:

WCF Web Programming Object Model
Ref.: http://msdn.microsoft.com/en-us/library/bb412204.aspx

Assim, o objetivo deste post foi apresentar alguns protocolos de mensagens envolvidos com cenários Web 2.0, enquanto utilizamos o WCF para nossas implementações.

No próximo post, vamos falar de um novo cenário: serviços para serviços para intranets. Fiquem ligados!

Por enquanto é só! Até o próximo post :)

Waldemir.

Cenários de implementação de serviços com WCF - Parte 2 : Web Services Corporativos

Web Services Corporativos

Olá pessoal, tudo certo?

Vamos falar hoje sobre um cenário muito comum em ambientes de produção nas empresas, que são os Web Services Corporativos. Nesse cenário, encontramos suporte para web services simples baseados em protocolo SOAP ou implementações avançadas sobre os padrões WS-* (WS-I : Web Services Interoperability Organization).

Desde o final dos anos 90 encontramos Web Services sendo usados em diversas soluções para a interoperabilidade entre sistemas, permitindo a troca de mensagens entre plataformas heterogêneas. Grande parte dessa produtividade é devido o uso dos documentos WSDL - Web Service Description Language, que descrevem as políticas e o metadado do serviço envolvido.

WCF suporta nativamente a tecnologia de Web Services, em diferentes alternativas de implementação, suportando versões consumidas por clientes JAVA ou outras plataformas não Microsoft, assim como clientes .NET 2.0. Também permite o consumo através de clientes Web Services Enhancements (WSE) 3.0 e clientes .NET 3.x.

Em muitos cenários, é possível migrar ASP.NET Web Services (ASMX) e Web Services WSE 3.0 para serviços WCF sem impacto para os clientes envolvidos.

A figura abaixo apresenta uma visão sobre os tipos de clientes envolvidos no cenário de Web Services Corporativos:

Note que é possível combinar diferentes protocolos de acordo com o tipo de cliente envolvido. Além disso, vale lembrar que para compatibilidade histórica, o SOAP 1.1 (ou Basic Profile 1.1) é o transporte indicado para o acesso aos serviços WCF. Assim, para clientes ASMX, usamos o protocolo SOAP 1.1; para clientes ASMX + WSE, usamos o protocolo SOAP 1.2 + WS-Addressing; e para clientes WCF, usamos SOAP 1.2 + WS-Addressing + WS-SecureConversation + WS-ReliableMessaging, para ilustrar.

Sobre os protocolos suportados pelo WCF  temos:

Considerando nossa proposta, vamos dar uma olhada nas principais características e configurações presentes para o cenário de Web Services em WCF. Pensando sobre a segurança aplicada aos Web Services, podemos identificar 3 configurações possíveis:

1. Web Services com passagem de usuário e senha sobre SSL - Secure Sockets Layer
2. Web Services com passagem de usuário e senha sobre segurança de mensagens
3. Web Services com segurança de sessão e mecanismo de sessão confiável ativada

Para cada opção acima, teremos configurações distintas, conforme vemos nas tabelas a seguir:

Web Services com passagem de usuário e senha sobre SSL - Secure Sockets Layer:

A figura abaixo ilustra o cenário acima, onde a segurança é obtida através do canal SSL, veja:

  
by M. L. Bustamente

Web Services com passagem de usuário e senha sobre segurança de mensagens:

Para ilustrar o cenário acima, onde temos a segurança de mensagens com o uso do WS-Security, veja a figura abaixo:

 
by M. L. Bustamante

Web Services com segurança de sessão e mecanismo de sessão confiável ativada:

Como ilustração, a figura abaixo apresenta o modelo de acesso ao serviço WCF, considerando um Web Services avançado, onde aplicamos uma sessão confiável, certificados e um repositório de credenciais externo, veja:

 
by M. L. Bustamante

Fonte: Bustamente, M.L.,Windows Communication Foundation: Application Deployment Scenarios, May 2008.

Qual opção de configuração devemos adotar? De fato, isso irá depender dos recursos disponíveis e aderência do projeto ao modelo de segurança implementado acima.

Note que cada cenário adiciona aspectos de desempenho, complexidade e experiência do usuário em graus diferentes. Por exemplo, para o cenário mais avançado, temos um impacto no tamanho de mensagens, que deve adicionar os padrões WS-Security, WS-SecureConversation e WS-ReliableMessaging (WS-RM). Ao mesmo tempo, WS-RM adiciona um mecanismo de confiabilidade na troca de mensagens, com uma sequência de requests/reponses que aumenta o grau de confiança entre cliente e servidor. Esse mesmo tipo de avaliação deve ser feito para as outras configurações, avaliando seus prós e contras.

Desse modo, passamos por alguns aspectos importantes na definição de arquiteturas com Web Services Corporativos e suas configurações.

No próximo post, vamos olhar um cenário relativamente recente: serviços para Web 2.0. Fiquem ligados.

Por enquanto é só! Até o próximo post :)

Waldemir.

Cenários de implementação de serviços com WCF - Parte 1 : Aspectos de SOA

Olá pessoal, tudo certo?

Vamos dar um tempinho no assunto ADO.NET Entity Framework e voltar para o mundo WCF - Windows Communication Foundation, pode ser?

Recentemente, em conversas com um time de arquitetos, voltamos a falar sobre os vários desafios na construção de arquiteturas orientadas para serviços. E como era de se esperar, WCF apareceu com destaque na reunião, considerando a plataforma Microsoft :)

De fato, o WCF foi construído com os aspectos de SOA (Service Oriented Architecture) em mente. Vamos citar alguns:

• O design e a implementação de serviços são naturalmente desacoplados da lógica de negócios da aplicação. Essa característica é que permite a migração das aplicações atuais para um modelo de serviços;
• Serviços expõem funcionalidades para clientes remotos através de contratos explícitos de serviços e de dados;
• Serviços são executados de forma autônoma, não havendo impacto entre serviços quando da ocorrência de uma falha, ou seja, o isolamento é uma condição obrigatória entre serviços, assim como as fronteiras de segurança;
• Serviços podem ser distribuídos através de diferentes protocolos, o que atende uma série de cenários presentes no ambiente corporativo. A interoperabilidade é uma exigência;
• Serviços são agnósticos ao transporte, ou seja, podem ser expostos diretamente na web, via intranet, ou usado como um backend no enterprise;

Para exemplificar um serviço WCF e seus principais elementos, temos o desenho a seguir:

Resumindo, serviços são orientados a mensagens, possuem contratos de serviços e de dados, são multi-protocolos e multi-hosts, com aspectos de segurança, isolamento, políticas, monitoração, comportamentos, etc. Todos esses aspectos são atendidos pelo modelo de programação do WCF.

Ainda, através do ABC do WCF (onde Endpoint = Addess + Binding + Contract) é possível uma grande flexibilidade na implantação e configuração de serviços em diversos ambientes de TI. Por exemplo, a tabela abaixo mostra a série de Bindings disponíveis para a configuração de nosso Endpoint. Cada combinação com diferentes propriedades para a comunicação entre clientes e serviços:

De fato, nem só de serviços vive uma arquitetura SOA. Precisamos pensar em questões de consumo, composição, orquestração, workflows, interação com o legado, etc. Nesse ponto, surge a necessidade de uma arquitetura de referência, que oriente nossa visão e a posição de cada componente nessa organização de infra-estrutura.

Como já visto aqui no blog, uma arquitetura de referência para SOA é bem representada pelo desenho a seguir, publicado pela Microsoft em outubro de 2007, durante o SOA & BP Conference (confira mais aqui):

Mas quando vamos para a implementação de fato, descobrimos que para nosso mundo de serviços existem diversos cenários possíveis. Cada cenário possui aspectos de configuração e deployment com impacto direto na performance, no versionamento, na administração e na governança do ambiente de produção.

Uma primeira lista de cenários comuns para a implementação de serviços é dada abaixo:

Com certeza, pelo menos 1 dos cenários acima é uma realidade em sua empresa.

Por isso, vamos começar uma nova série aqui no blog: o desafio para os próximos posts será detalhar cada cenário acima, discutindo as diversas configurações e características principais envolvidas. Nosso template de estudo será:

• Tipo de hosting utilizado
• Protocolo de transporte
• Protocolo de mensagens
• Mecanismo de Autenticação
• Mecanismo de Autorização
• Garantia de Confiabilidade
• Proteção no Transporte ou Segurança;

Enquanto avançamos pelos cenários, teremos a oportunidade de entender um pouco mais do modelo de arquitetura WCF. Muito trabalho pela frente, mas será divertido. Fiquem ligados!

Por enquanto é só! Até o próximo post :)

Waldemir.

ADO.NET Data Services : um pouco mais sobre o projeto "Astoria".

Olá pessoal, tudo certo?

O ADO.NET Data Services é um dos componentes da próxima versão do ADO.NET. O projeto "Astoria" como é conhecido, permite a navegação dos dados de um banco publicado na nuvem (web), através de uma interface estilo REST, com dados formatos em JSON e ATOM/APP.

Como principal benefício, é possível consumir as informações de um banco de dados publicado, sendo possível o search pelas informações via http. Além disso, é possível operar sobre esses dados, uma vez que a interface implementa todos os verbos do protocolo HTTP, como GET, POST, PUT e DELETE.

Veja um exemplo simples. Para começar, precisamos instalar alguns pacotes adicionais ao ambiente do Visual Studio 2008. Assim, vamos usar o ASP.NET 3.5 Extensions e o Entity Framework, para trabalhar com o ADO.NET Data Services.

ASP.NET 3.5 Extensions Preview (deve ser instalado)
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=A9C6BC06-B894-4B11-8300-35BD2F8FC908&displaylang=en

ADO.NET Entity Framework Beta 3 (deve ser instalado)
Ref.: http://www.microsoft.com/downloads/details.aspx?FamilyId=15DB9989-1621-444D-9B18-D1A04A21B519&displaylang=en

ADO.Net Entity Framework Tools Dec 07 Community Technology Preview (deve ser instalado)
Ref.: http://www.microsoft.com/downloads/details.aspx?familyid=D8AE4404-8E05-41FC-94C8-C73D9E238F82&displaylang=en

Após a instalação, crie um projeto ASP.NET WEB Application para nosso exercício.

Com o projeto criado, adicione um modelo Entity Data Model, via o template oferecido pelo ADO.NET Entity Framework (Beta 3).

A criação do modelo .EDMX pode ser feita apontando um arquivo .MDF local, ou um SQL Server ou ainda qualquer outro banco para o qual você tenha o provider. Veja a lista de providers disponíveis aqui.

Agora, adicione um novo item ao projeto, um ADO.NET Data Services, através do template disponibilizado pelo ASP.NET Extensions.

Esse template ADO.NET Data Service gera um código exemplo que já pode ser executado, a partir da indicação do modelo Entity Framework utilizado. Em nosso exemplo, veja que o modelo tem o namespace Model e a entidade utilizada é acessada na chamada:

public class WebDataService1 : WebDataService<