Waldemir Cambiucci - Solutions Architect - Microsoft Brasil : Cenários de serviços WCF

Interoperabilidade e Comunicação na plataforma Microsoft.

wcamb — Mon, 09 Feb 2009 15:55:00 GMT

Olá pessoal, tudo certo?

A semana passada foi bem corrida, com uma série de reuniões de projetos em diferentes empresas. Um dos tópicos interessantes que vi foi um mapa sobre os diferentes níveis de interoperabilidade na plataforma Microsoft.

Podemos pensar em 3 níveis básicos de complexidade:

Interop in the Framework
Interop in the Box
Interop in the Cloud

A figura abaixo faz um resumo desse mapa de interoperabilidades:

O chamado "Interop in the Framework" envolve a integração customizada, através de sua principal ferramenta, o WCF - Windows Communication Foundation. Através do WCF podemos construir arquiteturas de serviços com interfaces específicas para cada necessidade de negócio envolvida. Veja que a customização possível do WCF envolve a escolha dos melhores bindings, protocolos de entrega, formatação de dados, etc. Assim, suportamos de forma especializada padrões como ASMX, WSE, .NET Remoting, MSMQ, formatos como POX, REST, JSON, ATOM, além de mecanismos de roteamento, transação, coordenação, entre outros padrões do WS-I. Veja sobre cenários de WCF aqui.

Porém, existem cenários onde podemos aproveitar recursos de EAI - Enterprise Application Intergation ou mensageria, que envolvem tipicamente a transformação de mensagens, roteamento e principalmente atividades de tradução entre diferentes ambientes e tecnologias. Nesse caso, o chamado "Interop in the Box" apresenta uma caixa pronta, através do BizTalk Server na plataforma Microsoft. Na verdade, o BizTalk Server oferece um conjunto de recursos que podem ser configurados ou extendidos, permitindo a integração direta entre diferentes sistemas através de adaptadores, para SAP, Siebel, JD Edwards, etc, além do atendimento de protocolos de troca de dados como XML, EDI, EDIFACT, AS2, SWIFT, etc. Finalmente, é muito comum a integração de cenários "in the Framework" com cenários "in the Box", pois nossa TI sempre possui características mistas de composição de negócios e serviços.

Por último e mais recentemente, podemos pensar na composição de cenários entre múltiplas empresas, que implementam internamente suas integrações nos níveis "in the Box" e "in the Framework" através da nuvem. Usando elementos de escalabilidade e processamento massivo de um datacenter externo, fazemos a integração de diferentes cenários de negócio e suas necessidades, usando um ambiente de hardware provisionável por demandad. Temos assim o chamado "Interop in the Cloud". Nesse tipo de ambiente, identidade, conectividade e workflow ou orquestração de negócios na nuvem são elementos básicos para o projeto. Seu maior representando no Windows Azure é o .NET Services, sendo o principal mecanismo para a construção de uma integração "in the cloud". Como exemplo, a Microsoft está desenvolvendo um projeto conhecido como MEBA - Multi-Enterprise Business Application, usando a nuvem como ponto de integração entre empresas. Veja um pouco mais sobre MEBA aqui.

MEBA - Multi-Enterprise Business Application

Interoperabilidade é um dos temas principais de arquitetura, assim como a Comunicação entre diferentes ambientes. Na plataforma Microsoft, quando pensamos em comunicação citamos 4 caixas específicas:

Microsoft® BizTalk® Server (BTS)
Microsoft Host Integration Server (HIS)
Microsoft Message Queuing (MSMQ)
Microsoft Enterprise Service Bus (ESB) Guidance

Vamos falar um pouco mais dessas soluções em posts futuros.

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

Waldemir.

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

wcamb — Mon, 21 Jul 2008 14:35:00 GMT

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:

Cenários comuns de serviços WCF	Descrição do cenário
Web Services Corporativos	Cenários com suporte para web services simples, baseados em protocolo SOAP ou implementações avançadas sobre os padrões WS-* (WS-I)
Serviços para Web 2.0	Cenários contemplando o modelo de programação web, que suporta protocolos POX, REST, JSON, RSS e ATOM.
Aplicações Intranet	Aplicações cliente/servidor clássicas, distribuição de serviços através de firewall e aplicações web.
Serviços com suporte a mensageria	Implementações com chamadas assíncronas, chamadas desconectadas e suporte a publicação e subscrição.
Serviços para workflow	Cenários com coordenação de chamadas através de workflows, exposição de workflows como serviços e serviços duráveis.

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

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

wcamb — Thu, 17 Jul 2008 23:57:00 GMT

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)

wcamb — Tue, 15 Jul 2008 03:03:00 GMT

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:

Característica	Descrição
Hosting	Windows NT Services sobre Windows Server 2003 ou Windows Activation Service (WAS) sobre Windows Server 2008
Protocolo de Transporte	MSMQ (nativo, SRMP ou SRMPS)
Protocolo de Mensagens	SOAP + Binário
Autenticação	Certificados X.509 usados para autenticar o originador da mensagem (sender).
Autorização	Certificados X.509 usados para autorizar o originador da mensagem (sender).
Segurança	Certificados X.509 usados para proteger as mensagens colocadas na fila.
Autenticação para a fila	Certificados X.509 usados para autenticar o chamador da fila.
Autorização para a fila	Certificados X.509 usados para autorizar o chamador da fila.
Segurança na fila	O certificado X.509 do chamador é usado para assinar a mensagem enviada para a fila. Criptografia é normalmente tratada no nível da mensagem.

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

wcamb — Fri, 11 Jul 2008 06:03:00 GMT

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:

Característica	Descrição
Hosting	Windows NT Services sobre Windows Server 2003 ou Windows Activation Service (WAS) sobre Windows Server 2008
Protocolo de Transporte	TCP
Protocolo de Mensagens	SOAP + Binário ou SOAP + XML
Autenticação	Credenciais Windows autenticadas contra o domínio Windows.
Autorização	Credenciais Windows autorizadas contra o domínio Windows.
Segurança	As credenciais Windows são utilizadas para a geração de chaves para a comunicação segura. Certificados X.509 podem ser utilizados.

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:

Característica	Descrição
Hosting	Windows NT Services sobre Windows Server 2003 ou Windows Activation Service (WAS) sobre Windows Server 2008
Protocolo de Transporte	Named Pipes
Protocolo de Mensagens	SOAP + Binário
Autenticação	Credenciais Windows usadas para autenticar a aplicação chamadora.
Autorização	Credenciais Windows usadas para autorizar a aplicação chamadora.
Segurança	Credenciais Windows são usadas para a geração de chaves para a comunicação segura.

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.

Característica	Descrição
Hosting	IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008
Protocolo de Transporte	TCP
Protocolo de Mensagens	SOAP + Binário
Autenticação	Certificado X.509 usado para autenticar a aplicação ou serviço chamador.
Autorização	Certificado X.509 usado para autorizar a aplicação ou serviço chamador.
Segurança	Certificado X.509 usado para assinatura e criptografia na segurança de mensagens.

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

wcamb — Thu, 03 Jul 2008 13:12:00 GMT

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:

Protocolo	Descrição
POX	Um protocolo de mensagens XML simplificado, sem o formalismo do protocolo SOAP.
REST	Uma alternativa ao protocolo SOAP, baseado em POX - Plain Old XML. Fornece um estilo de arquitetua que permite o acesso de a recursos através da internet.
JSON	JavaScript Object Notation é um formato de mensagens leve, que é uma alternativa ao XML. É muito útil em combinação com clientes JavaScript, para a troca de dados com serviços com um overhead de processamento e um custo de transferência menor quando comparado com o XML.
RSS/ATOM	Really Simple Syndication e ATOM são formatos de sindicalização baseados em XML. São especialmente interessantes para o compartilhamento de dados atualizados em feeds ou blogs.

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.

Característica	Descrição
Hosting	IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008
Protocolo de Transporte	HTTP ou HTTPS (SSL)
Protocolo de Mensagens	XML
Autenticação	Basic Authentication (com usuário e senha) é uma escolha típica. Porém, segurança sobre certificados e integração Windows são também suportados.
Autorização	Um armazenamento de credenciais é normalmente indicado, desde que credenciais Windows sejam necessárias.
Segurança	Se necessário, SSL é suportado.

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:

Característica	Descrição
Hosting	IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008
Protocolo de Transporte	HTTP ou HTTPS (SSL)
Protocolo de Mensagens	JSON
Autenticação	Basic Authentication (com usuário e senha) é uma escolha típica. Porém, segurança sobre certificados e integração Windows são também suportados.
Autorização	Um armazenamento de credenciais é normalmente indicado, desde que credenciais Windows sejam necessárias.
Segurança	Se necessário, SSL é suportado.

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:

Característica	Descrição
Hosting	IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008
Protocolo de Transporte	HTTP ou HTTPS (SSL)
Protocolo de Mensagens	XML ou JSON
Autenticação	Basic Authentication (com usuário e senha) é uma escolha típica. Porém, segurança sobre certificados e integração Windows são também suportados.
Autorização	Um armazenamento de credenciais é normalmente indicado, desde que credenciais Windows sejam necessárias.
Segurança	Se necessário, SSL é suportado.

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

wcamb — Mon, 30 Jun 2008 23:34:00 GMT

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:

Categoria	Protocolo Suportado
Messaging	SOAP, WS-Addressing, MTOM
Metadada	WSDL, WS-MetadataExchange, WS-Policy
Security	WS-Security, WS-SecureConversation, WS-Trust
Reliability	WS-ReliableMessaging
Transactions	WS-Coordination, WS-AtomicTransaction

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:

Web Services com passagem de usuário e senha sobre SSL - Secure Sockets Layer
Web Services com passagem de usuário e senha sobre segurança de mensagens
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:

Característica	Descrição
Hosting	IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008
Protocolo de Transporte	HTTPS (SSL)
Protocolo de Mensagens	SOAP + WS-Addressing
Autenticação	Usuário e Senha são fornecidos como parte da mensagem SOAP, baseada em WS-Security e UsernameToken Profile.
Autorização	Um armazenamento de credenciais é normalmente indicado, desde que os usuários não façam parte de um domínio Windows.
Segurança	Um certificado SSL é fornecido para segurança de mensagens.

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:

Característica	Descrição
Hosting	IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008
Protocolo de Transporte	HTTP
Protocolo de Mensagens	SOAP + WS-Addressing
Autenticação	Usuário e Senha são fornecidos como parte da mensagem SOAP, baseada em WS-Security e UsernameToken Profile.
Autorização	Um armazenamento de credenciais é normalmente indicado, desde que os usuários não façam parte de um domínio Windows.
Segurança	Uso de protocolo WS-Security sobre certificados X.509 para a 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:

Característica	Descrição
Hosting	IIS 6 sobre Windows Server 2003, IIS 7 sobre Windows Server 2008
Protocolo de Transporte	HTTP
Protocolo de Mensagens	SOAP + WS-Addressing
Autenticação	Usuário e Senha são fornecidos como parte da mensagem SOAP, baseada em WS-Security e UsernameToken Profile. WS-SecureConversation é ativado para otimizar a autenticação.
Autorização	Um armazenamento de credenciais é normalmente indicado, desde que os usuários não façam parte de um domínio Windows.
Segurança	Uso de protocolo WS-Security sobre certificados X.509 para a segurança de mensagens.
Reliability (Confiabilidade)	Protocolo WS-ReliableMessaging é utilizado.

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

wcamb — Wed, 25 Jun 2008 13:41:00 GMT

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.

Porém, quando vamos para a implementação de projeto SOA 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.