domingo, 28 de junho de 2009

WCF, Parte 1: SOA e WCF

Bom Dia Galera! Depois de algum tempo como gerente, só mexendo em Outlook e Excel, senti falta da área técnica. Peguei uma pilha de material com o Luti pra me atualizar (http://luticm.blogspot.com - o menino é o cara de SQL e até acha que joga futebol), e a primeira leitura está sendo o livro Learning WCF.



Parte 1 da Parte 1 - SOA

Bem, o livro começa falando sobre SOA. Se você ler esta primeira parte, aposto que você irá pensar assim: "Uai, mas isso eu já fiz!". Aposto que você irá reconhecer a arquitetura que você bolou para alguns sistemas. Todo bom arquiteto de software se preocupa com modularização e reuso das funcionalidades que serão implementadas, e SOA é o terceiro degrau na escada de paradigmas para isto.
O primeiro degrau é OOA – Arquitetura Orientada a Objetos. O uso de orientação a objetos em uma aplicação permite que código seja modularizado e reutilizado através do encapsulamento fornecido pelo uso de classes – você cria funcionalidade dentro de uma classe, e reutiliza este código em várias partes da aplicação sendo desenvolvida. Por exemplo, podemos criar uma classe que manipule o Estoque da empresa, para ser chamada sempre que for necessário qualquer operação de consulta ou modificação do estoque.


Fig.1 – Aplicação com arquitetura orientada a objetos.

O segundo degrau é COA – Arquitetura Orientada a Componentes. Nosso time de desenvolvimento do exemplo anterior, ao partir para a próxima aplicação a ser construída, precisou novamente de realizar operações no estoque. “Oras Bolas!”, pensa o arquiteto. “Macacos me mordam!”, fala ele com seus botões. “Com mil demônios!”, grita ele alto J. O que o deixou tão empolgado é que este código já está pronto – só que atualmente faz parte da primeira aplicação desenvolvida. Ele então reestrutura a aplicação para separar a classe de Estoque dentro de um projeto Class Library, o que permite que a classe Estoque compilada seja compartilhada pelas aplicações – em vez de colocar o código da classe dentro da segunda aplicação, o que seria péssimo, e não preciso nem dizer porquê. Ao compartilhar código binário entre aplicações, nosso arquiteto usou uma arquitetura orientada a componentes – agora ambas as aplicações usam um componente dedicado a autenticar usuários.


Fig.2 – Aplicações com arquitetura orientada a componentes.

E agora, naturalmente, todas as aplicações da empresa irão usar este mesmo mecanismo de manipulação do estoque. Só que algumas aplicações Web estão na DMZ, do lado de fora do firewall, e o “povo de infra” disse que não vai abrir a porta 1433 no firewall para o componente conseguir falar com o SQL Server na LAN. Além disso, outras aplicações, em vez de estarem escritas em ASP.NET, estão escritas em Java! E pra completar, a empresa ainda fez um acordo com outra empresa através do qual esta outra empresa poderá fazer solicitações aos sistemas corporativos – o que implicitamente envoverá disponibilizar as operações de manipulação de estoque para sistemas rodando na Internet.


Fig.3 – Aplicações com arquitetura orientada a serviços.

E isto é SOA. Apesar de não ser esta a definição formal, o objetivo de uma aplicação com arquitetura orientada a serviços é permitir que funcionalidade, geralmente da camada de negócio, seja exposta para outras aplicações, independente do local e da plataforma destas aplicações. Estas “aplicações clientes” podem estar na mesma máquina que o serviço (a funcionalidade exposta), em outra máquina dentro da mesma rede, ou até mesmo fora da rede aonde o serviço está; e não necessariamente tem que estar escrita na mesma plataforma de desenvolvimento do serviço.

Parte 2 da Parte 1 – E o WCF?
Windows Communication Foundation é a mais recente tecnologia da Microsoft para facilitar a vida de quem quer desenvolver uma aplicação SOA. Ela é a última em uma “linha de evolução” de tecnologias para suporte a aplicações distribuídas – porque no núcleo da idéia de SOA está o conceito de aplicação distribuída, como fica evidente na figura 3. Estas tecnologias, em ordem (mais ou menos) cronológica, são:
  • DCOM, ou Distributed COM. O Component Object Model (só COM, sem o "D") permitia que lá no Visual Basic 6 você colocasse uma referência a um componente e reutilizasse código entre aplicações (fig.2). Logo depois, apareceu o DCOM, para permitir que isto pudesse ser feito mesmo que o componente estivesse em outra máquina. Legal, não? Só que só funciona para Windows, tem protocolo de comunicação proprietário e é uma programação chata, pois há vários… ahn… cuidados que devem ser tomados, para que programas escritos em uma liguagem possam chamar componentes escritos em outra. Desde o Windows 2000 o DCOM vem “escondido” dentro do Component Services, um pedaço do Windows que se dedica a facilitar a construção de aplicações com arquitetura orientada a componentes.
  • Enterprise Services: um namespace do .NET Framework que expõe o Componet Services para aplicações .NET.
  • .NET Remoting: outro namespace do .NET Framework dedicado à programação distribuída. Ele permite que aplicações clientes ativem objetos remotos – que vivem em outro processo, outra máquina ou até mesmo outra rede.
  • Web Services: o .NET Framework tem um namespace para implementação de Web Services, mas esta tecnologia não é proprietária da Microsoft. Ela visa a ativação de um objeto remoto, como no .NET Remoting, mas utilizando-se de protocolos Web padrão para comunicação, e baseada em um contrato de ativação do objeto, que descreve (em uma linguagem formal chamada WSDL) como o objeto deve ser invocado, e qual é o formato da resposta à cada possível chamada. Isto permite interoperabilidade quase que completamente transparente entre plataformas.

Cada uma destas tem suas vantagens e suas limitações, mas todas com o objetivo de fornecer uma forma o mais transparente possível de implementar programação distribuída, independente do local e da plataforma das aplicações envolvidas. Cada uma procurava aumentar esta independência, e ao mesmo tempo facilitar o seu uso pelo desenvolvedor, desta forma melhorando a produtividade. WCF é o mais recente passo nesta direção, e o objetivo da Microsoft com ela é fornecer uma tecnologia de proramação distribuída que possa substituir todas as anteriores, e desta forma fornecer um único modelo de programação orientada a serviços. É esta tecnologia que iremos explorar nesta série de artigos.

Update: Apesar de esta postagem ser antiga (aliás, a postagem mais antiga do meu blog), notei que recentemente o acesso a ela tem aumentado. Infelizmente, o envolvimento em outros projetos parou meu estudo de WCF. Por isto, não escrevi a sequência de artigos sobre WCF que iria se iniciar com este post. Espero que quando entrarmos em um projeto que use WCF eu volte para esta série.

Atenciosamente,

GB