SAAS
Conecte aplicativos empresariais aos Serviços do BizTalk hospedados
Jon Flanders e Aaron Skonnard
Este artigo baseia-se em uma versão de pré-lançamento do BizTalk Services. Todas as informações deste artigo estão sujeitas a alterações.
Este artigo discute:
- Serviços do BizTalk como um serviço ESB
- Aplicativos WCF nos Serviços do BizTalk
- Opções de conectividade retransmitida
- Serviços de identidade e provedores de token
|
O artigo utiliza as seguintes tecnologias:
Serviços do BizTalk, .NET Framework 3.0
|
Sumário
Hoje, mais do antes, as empresas exigem a capacidade de desenvolver, implantar e integrar rapidamente novos aplicativos em ambientes existentes. Essa crescente necessidade de aplicativos menos rígidos e dinâmicos é um dos principais motivos pelos quais as empresas mudaram ou estão mudando para a SOA (Arquitetura orientada ao serviço) como a nova base para seus aplicativos.
Conforme as empresas mudam para a SOA, os sistemas compostos ganham cada vez mais atenção em relação aos diversos aplicativos usados por elas. Neste novo mundo, cabe ao desenvolvedor orquestrar os processos empresariais a partir desses diversos serviços de aplicativos disponibilizados na rede por outras equipes e organizações, que podem estar usando tecnologias de implementação ou aplicativos de linha de negócios diferentes, aumentando assim a complexidade do sistema como um todo. Embora a SOA simplifique cada conexão ponto a ponto, os aplicativos compostos podem se tornar difíceis de gerenciar e até mesmo frágeis, conforme o número total de conexões de serviço exigido pelo aplicativo aumenta com o tempo (consulte a Figura 1).
Figura 1 Gerenciando conexões ponto a ponto em aplicativos compostos (clique na imagem para obter uma exibição ampliada)
Essa realidade levou muitas empresas a adotar um padrão de serviço mais flexível e sustentável, muitas vezes referido como ESB (Barramento de Serviços Corporativos). O modelo ESB cresceu em popularidade porque ajuda as empresas a gerenciar várias conexões de serviço por meio de um barramento central que fornece uma camada de abstração com os detalhes do sistema de mensagens subjacentes. Por exemplo, um ESB reduz as diferenças dos agentes nos serviços em termos de convenção de nomenclatura, gerenciamento de identidade, formatos de mensagem e protocolos de comunicação. Assim que um serviço chega, qualquer coisa que estiver no barramento poderá se conectar a ele, mesmo que normalmente não se comunique com o serviço de forma direta (consulte a Figura 2).
Figura 2 Criando aplicativos compostos com um ESB (clique na imagem para obter uma exibição ampliada)
Esse modelo introduz um nível de indireção entre os diversos serviços no barramento e entre os aplicativos compostos e os serviços que eles consomem. Os ESBs também fornecem vários recursos de sistema de mensagens incluindo a funcionalidade de publicação/assinatura, que apresenta menos rigidez ao sistema inteiro. Com a publicação/assinatura, os consumidores não precisam mais estar diretamente conectados aos serviços (basta ter uma conexão com o barramento) e os nós podem ser adicionados ou removidos à vontade. Os ESBs, com freqüência, também fornecem um mecanismo de fluxo de processo para orquestrar as interações do sistema de mensagens que compõem um processo empresarial (essa camada costuma ser chamada de orquestração ou fluxo de trabalho).
Uma maneira de criar sistemas que empregam o padrão ESB na plataforma Microsoft é usar o BizTalk® Server. O BizTalk Server fornece, prontos para uso, todos os recursos do ESB que discutimos aqui.
Software como um serviço
Embora os ESBs tenham se tornado mais conhecidos dentro das empresas, outra tendência comercial que também tem se difundido na Web, sem dúvida irá afetar os sistemas empresariais nos próximos anos. Essa tendência, chamada de SaaS (Software como um Serviço), diz respeito às empresas que expõem aplicativos ou serviços completos na Web (às vezes referidos como nuvem da Internet) de forma que outras empresas possam simplesmente pagar para usá-los. Isso permite aos consumidores evitar as complexidades e os custos associados à criação ou ao gerenciamento de um software semelhante (custos operacionais, de design, desenvolvimento e manutenção), que muitas vezes exigem um grande investimento inicial.
O modelo SaaS basicamente permite aos consumidores acessar, de maneira remota, o software hospedado por outra empresa com experiência em uma determinada área (como CRM, contabilidade, folha de pagamento, armazenamento de dados, email etc.), conforme ilustrado na Figura 3. Com o Saas, o provedor em geral oferece uma solução completa para uma necessidade de software específica, permitindo ao consumidor terceirizar essa parte do sistema. O provedor de serviços gerencia o software com o tempo e simplesmente cobra do consumidor o seu uso, o que significa que o consumidor não precisa mais gerenciar esses serviços de software localmente.
Figura 3 Terceirizar necessidades de software com o SaaS (clique na imagem para obter uma exibição ampliada)
Os aplicativos ou serviços oferecidos pelos provedores SaaS normalmente adotam formatos de dados e protocolos Web padrão para aumentar a facilidade de uso e o alcance potencial. Atualmente, eles costumam contar basicamente com HTTP e formatos de dados da Web comuns, como XML, RSS e JSON, amplamente usados hoje em dia. Embora o SaaS não restrinja um provedor a essas opções específicas, os requisitos de alcance muitas vezes forçam os provedores a seguir nessa direção.
Alguns arquitetos podem questionar se é uma boa idéia assumir as dependências externas inerentes à arquitetura do sistema SaaS. Embora eles possam levantar questões sobre conectividade e SLAs (contratos de nível de serviço), com a ubiqüidade das conexões da Internet hoje em dia, parece que expor software na Web tornou-se quase totalmente aceitável e até mesmo muito vantajoso tendo em vista as novas portas que isso pode abrir.
Barramento de Serviços de Internet
A Microsoft adotou essas idéias populares, ESB e SaaS, e mesclou suas características mais interessantes em um novo conceito chamado ISB (Barramento de Serviço de Internet). O modelo ISB é semelhante ao ESB em termos de funcionalidade. Entretanto, o ISB é disponibilizado em um escopo da Internet mais amplo, por isso ele é semelhante ao SaaS em termos de padrões, alcance e escalabilidade. O Microsoft® ISB, em poucas palavras, permite que as empresas adotem a infra-estrutura ESB com mais facilidade.
Embora a funcionalidade do ESB seja tentadora para uma vasta gama de empresas, atualmente, parece que apenas as empresas de grande porte estão realmente se beneficiando com ela. Em grande parte, isso acontece por causa do investimento inicial e risco financeiro associados à adoção de uma infra-estrutura importante como um ESB. Em vez disso, muitas empresas acabam criando sua própria infra-estrutura de integração de sistemas personalizada (e geralmente mais dispendiosa). Esse é um dos grandes impedimentos da adoção do BizTalk Server atualmente.
Além disso, as empresas capazes de implementar um ESB ainda são desafiadas a tentar integrar seu ESB ao de seus parceiros. Não existem duas instâncias ESB iguais, o que torna difícil a integração entre empresas, mesmo que se adote o padrão ESB menos rígido.
A plataforma Microsoft ISB enfrenta essas realidades colocando componentes importantes de barramento de serviço na nuvem da Internet para consumo público, independentemente da plataforma que utiliza esses componentes. Basicamente, a Microsoft está disponibilizando o barramento de serviço por meio do modelo SaaS, permitindo assim que empresas de qualquer porte o adotem. O ISB oferece uma arquitetura de publicação/assinatura e a infra-estrutura de sistema de mensagens necessária para atravessar firewalls empresariais e NATs (conversões de endereço de rede). O ISB também oferece gerenciamento de identidade federada e uma camada de serviços de fluxo de trabalho para hospedar processos empresariais personalizados na Web, conforme ilustrado na Figura 4.
Figura 4 Criando o novo barramento de serviços de Internet (clique na imagem para obter uma exibição ampliada)
A Microsoft está trabalhando ativamente para tornar o ISB uma realidade, e você pode acompanhar esse trabalho no site dos Serviços do BizTalk (consulte
labs.biztalk.net). A CTP (visualização de tecnologia da comunidade) oferece vários serviços fundamentais que você pode começar a experimentar hoje. Nos próximos anos, a Microsoft espera que essa iniciativa se torne uma grande rede de comunicação capaz de fornecer uma estrutura poderosa para uma ampla variedade de aplicativos modernos conectados.
Entretanto, é importante lembrar que, por se tratar de uma CTP, o que é disponibilizado atualmente destina-se apenas à experimentação e obtenção de comentários, e não ao uso de produção. A Microsoft não oferece nenhuma garantia de qualidade no momento. Além disso, a empresa ainda não anunciou como irá cobrar pelo uso do ISB quando ele estiver pronto para ser empregado na produção.
Serviços do BizTalk
Os Serviços do BizTalk são a implementação inicial dos componentes do ISB que residem na Web. Atualmente, os Serviços do BizTalk consistem em alguns serviços principais, incluindo os Serviços de Conectividade do BizTalk e os Serviços de Identidade do BizTalk. Outro serviço importante chamado Serviços de Fluxo de Trabalho do BizTalk se tornará disponível em breve. Mais serviços serão adicionados pela Microsoft com o tempo, e serviços adicionais também podem ser colocados no ISB por terceiros.
Vamos examinar cada um desses serviços principais atuais com mais detalhes. Um dos problemas mais desafiantes ao criar aplicativos compostos menos rígidos é gerenciar como os serviços irão se conectar no nível da rede. Por exemplo, você pode ter um serviço que reside no perímetro da rede e outro que reside dentro do firewall, e eles precisam se comunicar. Ou você pode querer expor um serviço aos parceiros comerciais, mas esses serviços de parceiros estão protegidos por seus próprios firewalls ou outros dispositivos de rede, como proxies ou NATs.
Os Serviços de Conectividade do BizTalk simplificam muitos desses desafios de comunicação fornecendo uma convenção de nomenclatura universal para serviços com um mecanismo de comunicação direta/indireta entre dois nós independentes de topologia e configuração de rede. Eles fazem isso fornecendo um mecanismo controlado para retransmitir conexões de maneira segura pelos dispositivos de rede. Dito isso, nos casos em que uma conexão direta pode ser feita, os Serviços de Conectividade do BizTalk também podem não interferir e deixar os nós se conectarem sem retransmitir o tráfego.
Sem dúvida, você pode escrever esse tipo de código sozinho, embora seja desafiador e enfadonho. A principal vantagem de deixar os Serviços do BizTalk fornecerem essa funcionalidade é que não é preciso escrever ou manter esse código, que muitas vezes é personalizado por ponto de extremidade. Isso permite que você se concentre na escrita do código para resolver seu problema empresarial, e não no código para contornar esses problemas de infra-estrutura. Os Serviços de Conectividade do BizTalk também apresentam outros recursos importantes, como uma convenção de nomenclatura global baseada em URIs (identificadores de recursos uniformes), um mecanismo de publicação/assinatura simples e até recursos multicast.
Outra parte importante dos Serviços do BizTalk são os Serviços de Identidade do BizTalk, um STS (Serviço de token de segurança) que se conforma ao padrão WS-Trust. O WS-Trust é um padrão de interoperabilidade para negociar segurança com base em relacionamentos entre partes. Por exemplo, uma parte pode autenticar um cliente e emitir um token contendo um conjunto de declarações sobre o cliente. Esse token pode ser apresentado de maneira segura a outras partes que também confiem na parte original que emitiu o token. Essa abordagem torna possível combinar informações valiosas de identidade entre fronteiras organizacionais.
Assim, os Serviços de Identidade do BizTalk podem ser usados como um serviço de gerenciamento de identidade e autenticação de terceiros, mesmo que você não empregue outros recursos como os Serviços de Conectividade BizTalk. Entretanto, ao usar os outros Serviços do BizTalk, os Serviços de Identidade BizTalk sempre serão usados para autenticar e autorizar usuários.
Ao usar os Serviços de Conectividade do BizTalk, o cliente e o serviço são autenticados nos Serviços de Identidade do BizTalk usando um nome de usuário/senha, certificado de cliente ou cartão gerenciado. Uma vez autenticado, um conjunto de regras de autorização é processado para emitir um novo token que é fornecido aos Serviços de Conectividade do BizTalk. O site dos Serviços do BizTalk fornece uma interface do usuário para gerenciar as regras de autorização com algumas APIs programáticas, incluindo a interface RESTful.
Os Serviços de Fluxo de Trabalho do BizTalk ainda não foram lançados para consumo público. Entretanto, um futuro lançamento dos Serviços do BizTalk é esperado para fornecer o recurso de hospedar serviços de fluxo de trabalho baseado no Windows® Workflow Foundation (WF) no ISB. Os fluxos de trabalho serão ativados com base nas mensagens recebidas pelo ISB em um URI específico. Atualmente, esses são os únicos detalhes disponíveis.
SDK dos Serviços do BizTalk
O SDK dos Serviços do BizTalk é um download gratuito disponível em
biztalk.net que lhe permitirá começar a programar no ISB. Antes de começar, será necessário instalar o SDK dos Serviços do BizTalk e criar uma conta de usuário no site dos Serviços BizTalk. Os Serviços do BizTalk foram criados no WCF (Windows Communication Foundation). O SDK é apenas um conjunto de assemblies criados no Microsoft .NET Framework 3.0 que permite usar o ISB por meio do modelo de programação do WCF.
Boa parte do SDK dos Serviços do BizTalk está no assembly System.ServiceBus. System.ServiceBus usa pontos de extensibilidade do WCF para definir uma nova associação chamada RelayBinding. Para aqueles que não conhecem o WCF, uma associação determina o tipo de comunicação que será exposto ou usado por um ponto de extremidade do serviço. As associações são usadas pelo runtime do WCF ao criar a camada de comunicação, conhecida como pilha de canal, para enviar e receber mensagens. Os objetos na pilha de canal executam a comunicação de rede e determinam como a segurança e outros protocolos são implementados para um ponto de extremidade específico.
No lado da escuta, o RelayBinding permite expor um ponto de extremidade que estará acessível por meio de um URI global ao qual os Serviços de Conectividade do BizTalk oferece suporte. Quando um ponto de extremidade que usa RelayBinding é aberto, o URI é registrado com os Serviços de Conectividade do BizTalk e, a partir daí, qualquer cliente autorizado é capaz de enviar mensagens a esse URI global usando um cliente configurado de maneira semelhante. Os Serviços de Conectividade do BizTalk tornaram-se um meio de comunicação entre esses dois pontos de extremidade.
Um aplicativo WCF típico
Vejamos com mais detalhes um exemplo simples. Imagine que estamos em uma empresa e atualmente expomos um serviço WCF na rede interna que é chamado de um aplicativo cliente avançado. O aplicativo cliente é usado pelos vendedores para processar os pedidos. O aplicativo chama o serviço, e o serviço inicia o processamento de back-end necessário para atender ao pedido.
O serviço está configurado atualmente com um único ponto de extremidade usando NetTcpBinding, que permite conexões de alta velocidade em TCP/IP. NetTcpBinding, em geral, é a melhor opção para serviços que operam com firewall.
Veja o código que configura o ponto de extremidade e inicia o serviço usando o ServiceHost padrão:
ServiceHost sh = new ServiceHost(typeof(SalesService));
sh.AddServiceEndpoint(typeof(ISalesService),
new NetTcpBinding(),
"net.tcp://salesservicehost/SalesService");
sh.Open();
...
Este é o código WCF padrão. A implementação do serviço é o tipo SalesService e o contrato é ISalesServices. O ServiceEndpoint, criado quando AddServiceEndpoint é chamado, usa NetTcpBinding e possui um endereço de net.tcp://salesservicehost/SalesService.
Em vez de codificar o ponto de extremidade dessa maneira, poderíamos também configurá-lo no arquivo de configuração do aplicativo (que é como normalmente se faz isso). Mas este exemplo deve ser mais fácil de seguir mantendo tudo no código. Veja um aplicativo cliente de exemplo que invoca o SalesService para processar uma venda:
static void MakeSale(SaleData sd) {
EndpointAddress ea = new EndpointAddress(
"net.tcp://salesservicehost/SalesService");
ChannelFactory<ISalesService> cf =
new ChannelFactory<ISalesService>(new NetTcpBinding(), ea);
ISalesService service = cf.CreateChannel();
service.EnterSale(sd);
}
Com o tempo, a equipe de vendas passa a sair mais, e começam a aparecer relatórios de vendedores que não conseguem se conectar para processar pedidos quando estão fora do escritório, conectados a redes aleatórias (algumas das quais não permitem conexões de Rede Virtual Privada, ou VPN).
Os serviços do BizTalk podem resolver esse problema. Vejamos o que é necessário para expor SalesService por meio dos Serviços de Conectividade do BizTalk:
ServiceHost sh = new ServiceHost(typeof(SalesService));
sh.AddServiceEndpoint(typeof(ISalesService),
new RelayBinding(),
"sb://connect.biztalk.net/services/contososervices/SalesService");
sh.Open();
...
Como você pode ver, para expor o serviço por meio dos Serviços do BizTalk, basta alterar apenas uma linha de código, a chamada a ServiceHost.AddServiceEndpoint. Em vez de NetTcpBinding, usamos RelayBinding, que por sua vez usa os Serviços de Conectividade do BizTalk para expor esse ponto de extremidade ao mundo no URI especificado. As mensagens enviadas a esse endereço são, então, retransmitidas à instância local SalesService.
Observe o formato do URI. Ele começa com o esquema "sb" e é seguido pelo nome de host dos Serviços do BizTalk, que é seguido por "services". Depois disso, adicionamos a identidade dos Serviços do BizTalk (o nome da conta que configuramos) que, neste caso, é contososervices. Então, podemos adicionar qualquer coisa que desejarmos ao URI para torná-lo exclusivo. Aqui, apenas acrescentamos SalesService.
Quando você chama ServiceHost.Open, RelayBinding faz o WCF se comunicar com os Serviços de Identidade do BizTalk para autenticar a identidade do serviço e autorizá-lo a escutar o URI especificado. O comportamento padrão neste momento é que o seletor do Windows CardSpace™ seja exibido solicitando que alguém selecione um cartão para representar a identidade do serviço.
O fato de que uma interface do usuário é exibida durante a autenticação, sem dúvida, é proibitivo para a maioria dos serviços já que, com freqüência, elas são executadas em ambientes sem periféricos nos quais não há ninguém conectado ao computador. Entretanto, podemos contornar esse problema com um pouco de código, que mostraremos posteriormente, portanto, não fique preocupado. Neste momento, vamos apenas selecionar um cartão que permitirá que SalesService comece a escutar. Você pode gerenciar quais identidades têm permissão para escutar um URI específico com os Serviços de Identidade do BizTalk.
Agora, vejamos o que é necessário para atualizar o cliente de forma que ele possa consumir o ponto de extremidade dos Serviços do BizTalk:
static void MakeSaleISB(SaleData sd) {
string uri =
"sb://connect.biztalk.net/services/contososervices/SalesService";
ChannelFactory<ISalesService> cf = new ChannelFactory<ISalesService>(
new RelayBinding(), new EndpointAddress(uri));
ISalesService service = cf.CreateChannel();
service.EnterSale(sd);
}
Observe que o cliente e o serviço permanecem exatamente os mesmos, exceto pelo uso de RelayBinding e da especificação do URI de barramento de serviço (sb://...). O cliente também verá o seletor do Windows CardSpace por padrão, permitindo ao cliente selecionar uma identidade, que é enviada aos Serviços de Identidade do BizTalk para autenticação e autorização. Se o cliente for autorizado a enviar mensagens ao URI especificado, os Serviços de Identidade do BizTalk retornarão um token indicando esse fato, que então é passado aos Serviços de Conectividade do BizTalk como prova.
Fazer o Windows CardSpace aparecer neste cenário parece bastante aceitável já que é um aplicativo cliente interativo. Aqui também, você pode gerenciar quais identidades-cliente têm permissão para enviar um URI específico usando os Serviços de Identidade do BizTalk.
Quando os Serviços de Conectividade do BizTalk recebem uma mensagem de entrada de um remetente autorizado, eles simplesmente retransmitem a mensagem para uma instância do SalesService executada localmente. Você realmente não precisa se preocupar em saber como eles fazem isso porque é um detalhe da implementação que provavelmente será alterado no futuro. Entretanto, por trás do pano, RelayBinding usa TcpTransport do WCF para se conectar aos Serviços de Conectividade do BizTalk. Ao retransmitir mensagens, os Serviços de Conectividade do BizTalk podem encapsular a conexão TCP existente para a instância do serviço local.
Por que isso foi tão simples? Porque os Serviços de Conectividade do BizTalk usa os pontos de extensibilidade padrão do WCF para encapsular a conectividade e retransmitir lógica para o cliente e o serviço dentro do novo RelayBinding. O fato de que você pode fazer alterações de comunicação fundamentais simplesmente alterando a associação (que pode ser feito inteiramente na configuração) é uma das grandes vantagens de adotar o modelo de programação do WCF.
Opções de conectividade retransmitida
Uma das propriedades importantes no objeto RelayBinding é ConnectionMode. O tipo de propriedade é um enum chamado RelayedConnectionMode. Essa configuração determina como a conexão com os Serviços de Conectividade do BizTalk é feita. Os Serviços de Conectividade do BizTalk permitem vários modos de comunicação entre remetentes e receptores que oferecem bastante flexibilidade para cenários de comunicação específicos (consulte a Figura 5).
Figura 5 Opções de RelayBinding ConnectionMode
| Valor ConnectionMode |
Descrição |
| RelayedOneWay |
A conexão é configurada para aceitar ou enviar somente operações unidirecionais. Para usar esta configuração, todos os métodos no seu contrato de serviço devem ter um OperationContractAttribute com a propriedade IsOneWay definida como verdadeiro. |
| RelayedDuplex |
A conexão é configurada para oferecer suporte a contratos de solicitação-resposta (incluindo contratos duplex). |
| RelayedDuplexSession |
O mesmo que RelayedDuplex mas configurado para usar WS-ReliableMessaging. |
| DirectDuplexSession |
O mesmo que RelayedDuplexSession com uma otimização. A conexão inicial entre remetente e receptor usará os Serviços de Conectividade do BizTalk, mas tentará fazer uma conexão direta entre os dois nós, se possível. Se uma conexão direta puder ser feita, o remetente e o receptor se comunicarão sem o intermédio dos Serviços de Conectividade do BizTalk. Se uma conexão direta não puder ser feita, os Serviços de Conectividade do BizTalk continuarão a fornecer uma retransmissão para a comunicação. |
| RelayedMulticast |
A conexão é configurada para fornecer recursos de publicação/assinatura. Várias escutas podem registrar o mesmo endereço ao usar este modo. Para usar esta configuração, todos os métodos no seu contrato de serviço devem ter um OperationContractAttribute com a propriedade IsOneWay definida como verdadeiro. |
| RelayedHttp |
A conexão é configurada para expor um ponto de extremidade HTTP por meio dos Serviços do BizTalk que retransmite de volta para um serviço executado em um computador na rede local, mesmo que esse serviço normalmente não seja acessível pela Internet. |
RelayedOneWay destina-se a cenários de sistema de mensagens unilateral, portanto, você só pode usá-lo em operações marcadas com IsOneWay=true. RelayedDuplex, por sua vez, é destinado a cenários de solicitação-resposta, incluindo contratos duplex. RelayedDuplexSession é exatamente como RelayedDuplex, mas também permite um sistema de mensagens confiável dentro da pilha de canal. Esse é o modo de conexão padrão, por isso, foi o que realmente usamos nos exemplos anteriores. Além disso, o modo DirectDuplexSession é uma otimização de RelayedDuplexSession, já que tenta fazer uma conexão direta entre o remetente e o receptor. Quando isso não é possível, ele volta a retransmitir o tráfego.
Veremos com mais detalhes os dois últimos modos de conexão. Primeiro, RelayedMulticast permite publicação/assinatura por meio do WCF, um padrão de comunicação que não está disponível em nenhuma das associações do WCF internas. Além disso, RelayedHttp permite expor pontos de extremidade baseados em HTTP de dentro de um firewall corporativo ou protegidos por um NAT, coisa que os desenvolvedores se esforçam para fazer desde o advento do Web Services.
Os Serviços de Conectividade do BizTalk permitem que várias escutas se registrem em um URI quando RelayedMulticast é especificado pela primeira escuta. Cada ServiceHost que possui um ponto de extremidade escutando nesse mesmo URI implicitamente torna-se um assinante. Quando um cliente envia uma mensagem para esse URI, ela é entregue a todos os pontos de extremidade do serviço atualmente inscritos. A única restrição real quanto ao uso de RelayedMulticast é que, como RelayedOneWay, todas as operações devem ser marcadas com IsOneWay=true.
Voltemos ao nosso aplicativo de vendas anterior. Suponha que periodicamente durante o dia, atualizemos o preço de diferentes itens vendidos. Queremos difundir os novos preços a toda a equipe de vendas de forma que ela seja informada instantaneamente. Para que isso aconteça, cada aplicativo cliente pode iniciar um ServiceHost e escutar o mesmo URI usando o RelayBinding com ConnectionMode definido como RelayMulticast:
ServiceHost sh = new ServiceHost(typeof(PriceUpdateService));
sh.AddServiceEndpoint(typeof(IPriceUpdateService),
new RelayBinding(RelayConnectionMode.RelayedMulticast),
"sb://connect.biztalk.net/services/contososervices/priceupdate");
sh.Open();
...
Cada cliente executa seu código quando o aplicativo é iniciado e, portanto, todos os aplicativos-cliente serão assinantes das mensagens enviadas a sb://connect.biztalk.net/services/contososervices/clientupdate. Cada cliente torna-se agora um serviço de assinatura para fins desse contrato e URI. Neste cenário, o sistema de back-end executa a função do cliente WCF e difunde (publica) uma mensagem a todos os assinantes, conforme ilustrado aqui:
static void DoPriceUpdate(PriceUpdate pu) {
EndpointAddress ea = new EndpointAddress(
"sb://connect.biztalk.net/services/contososervices/priceupdate");
ChannelFactory<IPriceUpdateService> cf =
new ChannelFactory<IPriceUpdateService>(
new RelayBinding(RelayConnectionMode.RelayedMulticast), ea);
IPriceUpdateService service = cf.CreateChannel();
service.UpdatePrice(pu);
}
Quando UpdatePrice é chamado, a mensagem PriceUpdate é enviada aos Serviços de Conectividade do BizTalk, que retransmitem a mensagem a todos os serviços atualmente inscritos no mesmo URI.
Atravessando firewalls com RelayedHttp
O modo RelayedHttp permite usar um serviço HTTP executado na rede local e expô-lo por meio dos Serviços de Conectividade do BizTalk via HTTP na Web pública, mesmo que, em geral, esse serviço não seja diretamente acessível de fora da rede. Esse recurso é especialmente útil quando usado com o novo modelo de programação Web do WCF encontrado no .NET Framework 3.5.
Esse novo modelo de programação Web facilita a implementação dos serviços Web RESTful com o WCF. Ele também fornece recursos que tornam mais fácil a integração dos serviços WCF com a infra-estrutura RSS/Atom e AJAX existentes encontradas na Web hoje em dia. Os Serviços do BizTalk não exigem o .NET Framework 3.5, mas dados esses novos recursos do WCF, o modo RelayedHttp possui mais funcionalidade quando o .NET Framework 3.5 está instalado.
Voltando ao aplicativo de vendas, às vezes, os vendedores não estão executando o aplicativo-cliente avançado, mas ainda precisam ser notificados das informações de preços mais recentes. Uma forma interessante de expor dados atualizados com freqüência é por meio de um Web feed, um ponto de extremidade HTTP que retorna formatos XML conhecidos, como RSS ou Atom, a aplicativos que sabem como consumir esses feeds. Os Web feeds podem ser sondados quanto a novo conteúdo em um cronograma definido por um leitor de feeds (o nome comum para um programa que agrega Web feeds em uma interface do usuário de interação humana). Isso permite ao usuário final receber atualizações sem navegar ativamente até o site, mas apenas examinando seu leitor de feeds.
Usando o modelo de programação Web do WCF, é possível criar facilmente um Web feed que exponha os dados de atualização de preços. A primeira coisa de que precisamos é um contrato que use os novos atributos do WCF para habilitar invocações HTTP. Esses atributos informam à camada do sistema de mensagens do WCF como rotear solicitações HTTP de entrada para os métodos no serviço com base no URI, e não no cabeçalho de Ação SOAP. Veja um exemplo:
[ServiceContract]
public interface IPriceUpdateFeed {
[OperationContract()]
[WebGet(UriTemplate = "*")]
Atom10FeedFormatter GetPriceUpdate();
}
Aqui, WebGetAttribute informa ao WCF que este método deve ser chamado sempre que uma solicitação HTTP GET chegar no serviço (diferentemente das solicitações SOAP, que sempre usam HTTP POST).
Observe também a propriedade UriTemplate em WebGetAttribute. Ela informa ao WCF exatamente como rotear as mensagens de entrada para diferentes métodos com base no URI da solicitação de entrada. Este exemplo usa um modelo de caractere curinga ("*") para indicar que desejamos que todas as solicitações GET sejam roteadas para esse método específico. Você pode configurar facilmente vários métodos em um serviço, cada um para manipular um UriTemplate diferente. Também existe um WebInvokeAttribute que você pode usar quando desejar responder a outros verbos HTTP além de GET (incluindo POST, PUT, DELETE e HEAD).
Outra coisa que vale notar nesse contrato é o tipo de retorno do método. O modelo de programação Web do WCF inclui novos tipos criados especificamente para ajudar a produzir os formatos de feed padrão atuais. Os dois principais formatos com suporte hoje em dia são Atom e RSS. Este exemplo usa o formato Atom.
A Figura 6 mostra uma implementação simples da operação GetPriceUpdate que produz um feed de distribuição Atom. Essa implementação usa a nova API SyndicationFeed para produzir um feed lógico, que ela retorna encapsulado em um objeto Atom10FeedFormatter para produzir o formato XML correto.
Figura 6 Produzindo um Web feed
public Atom10FeedFormatter GetPriceUpdate() {
SyndicationFeed feed = new SyndicationFeed("Product Update Feed",
"", null);
List<SyndicationItem> items = new List<SyndicationItem>();
feed.Items = items;
IEnumerable<Product> products = GetUpdatedProducts();
string iText = "Product update for {0}. Old price={1}. New Price={2}";
foreach (var product in products) {
items.Add(new SyndicationItem("Product update for " + product.Name,
String.Format(iText, product.Name, product.OldUnitPrice,
product.UnitPrice),
null,
product.Name,
product.UpdatedTime));
}
return new Atom10FeedFormatter(feed);
}
Agora precisamos configurar um ponto de extremidade para escutar essas solicitações. O WCF 3.5 vem com uma nova classe de associação para facilitar a configuração do ponto de extremidade. A classe WebHttpBinding encapsula os detalhes da criação da pilha de canal RESTful que não espera mensagens SOAP. Ela simplesmente usa o transporte HTTP e o codificador de mensagens baseado em texto do WCF, com a versão de mensagem do codificador definida como None. Este é o código necessário para que o novo ponto de extremidade fique pronto para execução:
ServiceEndpoint se =
sh.AddServiceEndpoint(typeof(IPriceUpdateFeed),
new WebHttpBinding(), "http://localhost:8099/ProductFeed");
se.Behaviors.Add(new WebHttpBehavior());
...
Observe que o ponto de extremidade WebHttpBinding está configurado com uma instância de WebHttpBehavior, que injeta a lógica de expedição baseada em HTTP no runtime. Depois que ServiceHost entrar em operação com seu novo ponto de extremidade configurado, você poderá navegar até o URI HTTP que o serviço está escutando em localhost:8099/ProductFeed para ver o feed Atom.
Agora, suponha que desejemos expor esse feed aos vendedores que não estão na rede interna. Em vez de expor esse computador por meio do firewall, podemos simplesmente usar os Serviços de Conectividade do BizTalk para retransmitir o tráfego HTTP ao serviço local. Para fazer isso, adicionamos outro ponto de extremidade usando RelayBinding, mas especificamos RelayedHttp para ConnectionMode, conforme ilustrado aqui:
ServiceEndpoint se =
sh.AddServiceEndpoint(typeof(IPriceUpdateFeed),
new RelayBinding(RelayConnectionMode.RelayedHTTP),
"http://connect.biztalk.net/services/contososervices/ProductFeed");
se.Behaviors.Add(new WebHttpBehavior());
...
Com isso, agora, nosso serviço está exposto de maneira segura na Web pública, mas a lógica está hospedada em um servidor interno. Na Figura 7, você pode ver esse feed exposto por meio de um URI público, acessível pela Internet. É claro que o feed parece exatamente o mesmo, e agora os vendedores em trânsito podem assiná-lo e obter atualizações sem qualquer complicação causada por VPNs, firewalls ou problemas de rede.
Figura 7 Expondo um Serviço HTTP por meio dos Serviços de Conectividade do BizTalk (clique na imagem para obter uma exibição ampliada)
Configurando os Serviços de Identidade
Independentemente do modo de conexão usado com RelayBinding, o Listener (serviço) e o Sender (cliente) devem ser autenticados e autorizados pelos Serviços de Identidade do BizTalk. A autenticação é o processo de identificar o cliente ou o solicitante ao receber um conjunto inicial de declarações. A autorização é o processo de aplicar regras de autorização definidas pelo usuário a esse conjunto inicial de declarações.
As regras de autorização produzem um novo conjunto de declarações por meio de uma série de transformações de declaração (cada regra mapeia um conjunto de declarações de entrada para um conjunto de declarações de saída). O conjunto inicial de declarações de entrada é aquele apresentado aos Serviços do BizTalk pelo solicitante. Atualmente, os Serviços de Identidade do BizTalk oferece suporte a três tipos de conjuntos declarações iniciais: nome de usuário/senha, certificado cliente e cartões gerenciados. No caso de nome de usuário/senha, o nome de usuário é a declaração inicial e a senha é a prova dessa declaração.
Os Serviços de Identidade do BizTalk começam processando as regras de autorização usando a declaração do nome de usuário como ponto inicial para produzir declarações de saída. Conforme novas declarações são produzidas, elas servem como declarações de entrada para outras regras, permitindo um grau de encadeamento de regras. O conjunto final das declarações de saída é o que está contido no token retornado pelos Serviços de Identidade do BizTalk. Ao tentar acessar os Serviços de Conectividade do BizTalk, algumas declarações de saída devem ser apresentadas.
Também é possível configurar os Serviços de Identidade do BizTalk com um certificado para proteger os tokens que eles produzem. Quando um certificado é configurado, o token fornecido ao solicitante é criptografado com a chave pública do certificado, tornando segura sua viagem pela conexão e também menos suscetível à violação do cliente em trânsito.
Existem algumas maneiras de configurar essas regras de autorização. Uma delas é pela interface do usuário fornecida no site dos Serviços do BizTalk (consulte a Figura 8). A outra é programaticamente, usando a API de Gerenciamento de Identidades encontrada no SDK. Recentemente, uma versão RESTful dessa interface também foi lançada.
Figura 8 Interface do usuário de mapeamento de declarações do site dos Serviços do BizTalk (clique na imagem para obter uma exibição ampliada)
Ao configurar as regras de autorização, você deve pensar sobre a forma como irá usar os Serviços de Identidade do BizTalk. Aqui também, é possível usar os Serviços de Identidade do BizTalk como um STS genérico ou como o mecanismo de controle de acesso dos Serviços de Conectividade do BizTalk.
Ao usar os Serviços de Identidade do BizTalk como STS genérico, você pode mapear declarações de entrada de nome de usuário para qualquer declaração de saída. A declaração de saída será colocada no token resultante que pode então ser apresentado a outras partes. Para usar os serviços dessa forma, é necessário ter pelo menos uma regra na qual a declaração de entrada seja o nome de usuário. Você pode adicionar mais regras em cascata com base nas novas declarações de saída (por exemplo, usar a declaração de saída produzida pela regra do nome de usuário como declaração de entrada para outra declaração de saída), o que lhe permite criar um conjunto arbitrário de declarações de saída. Consulte os exemplos de AccessControl no SDK dos Serviços do BizTalk para obter um exemplo completo.
Para autenticar nos Serviços de Conectividade do BizTalk, é necessário configurar os Serviços de Identidade do BizTalk com algumas regras específicas. Conforme mencionado, você deve ter pelo menos uma regra na qual a declaração de entrada seja o nome de usuário e também pode ter regras em cascata.
Entretanto, quando os Serviços de Conectividade do BizTalk são exclusivos, eles esperam encontrar uma declaração de saída Resource#Operation no token final, no qual o recurso deve ser o URI de escuta do serviço e a operação deve ser Listen ou Send. Por exemplo, {URI}#Listen permite ao usuário iniciar a escuta de um ponto de extremidade do serviço no URI especificado, enquanto que {URI}#Send permite ao usuário enviar uma mensagem ao URI especificado.
Provedores de token personalizados
Anteriormente, mencionamos que não é comum um aplicativo de servidor ter uma tela de logon interativa como a do seletor do Windows CardSpace que aparece quando o servidor começa a escutar. Isso acontece porque cada ponto de extremidade que usa RelayBinding emprega um objeto que implementa a interface ITokenProvider. A implementação padrão dessa interface é CardspaceTokenProvider, que faz o seletor do Windows CardSpace aparecer quando uma conexão é feita com os Serviços de Conectividade do BizTalk.
Além do CardspaceTokenProvider, o SDK contém outras implementações de ITokenProvider. UsernameTokenProvider recupera um token usando um nome de usuário e senha registrados nos Serviços de Identidade do BizTalk. AutomaticRenewalTokenProvider faz o seletor do Windows CardSpace aparecer, mas obtém automaticamente um novo token antes que o atual expire, permitindo que os pontos de extremidade sejam configurados uma vez. Essas duas implementações também são comportamentos de ponto de extremidade que podem ser adicionadas a um ponto de extremidade cliente ou de serviço para substituir o CardspaceTokenProvider padrão.
Nosso serviço agora pode evitar o logon interativo, configurando UsernameTokenProvider no seu ponto de extremidade antes de chamar ServiceHost.Open, conforme mostrado aqui:
ServiceHost sh = new ServiceHost(typeof(SalesService));
ServiceEndpoint se = sh.AddServiceEndpoint(typeof(ISalesService),
new RelayBinding(),
"sb://connect.biztalk.net/services/contososervices/SalesService");
UsernameToken token = new UsernameTokenProvider("someusername",
"somepassword");
se.Behaviors.Add(token);
sh.Open();
...
Agora, sempre que o processo do serviço for iniciado, ele automaticamente será autenticado nos Serviços de Identidade do BizTalk sem qualquer intervenção humana. Implementações alternativas de ITokenProvider também podem ser configuradas no ponto de extremidade RelayBinding simplesmente adicionando a implementação como um comportamento de ponto de extremidade (a classe base TokenProvider encontrada no SDK implementa ITokenProvider e IEndpointBehavior).
Guia de introdução
Se você deseja começar a usar os Serviços do BizTalk, primeiro navegue até
labs.biztalk.net e crie uma conta. Verifique se você tem o .NET Framework 3.0 instalado e depois baixe e instale o SDK dos Serviços do BizTalk. Depois de criar uma conta e instalar o SDK no seu computador, você poderá recriar os exemplos que mostramos neste artigo. É claro que será necessário alterar o nome da conta usado nos URIs de "contoso" para o nome da sua conta. Além disso, o SDK vem com exemplos adicionais para sua apreciação, que podem ajudar a ilustrar melhor alguns dos conceitos abordados aqui. Quando começar, se surgirem outras dúvidas, verifique as perguntas freqüentes no site dos Serviços do BizTalk. Boa sorte!