Introdução à SOA

Todos os desenvolvedores com certeza já se depararam com esta sigla: SOA. O objetivo deste post é explicar brevemente e em poucas palavras o que é este paradigma.

Definição

Service Oriented Architeture ou Arquitetura Orientada a Serviço surgiu com o seguinte princípio: Concentrar os esforços de TI de uma organização para melhor atender ao negócio. Ou seja, o desafio é utilizar a tecnologia de forma que esta possa agregar valores à todo e qualquer tipo de negócio dentro da organização, transformando processos em serviços que possam estar disponíveis e acessíveis à qualquer momento. SOA portanto, tem o objetivo de promover a interoperabilidade entre sistemas que são executados e desenvolvidos nas mais diferentes plataformas, podendo as mesmas ser totalmente distintas.

Imagine uma empresa que possua vários departamentos, aonde cada um possui sistemas que foram desenvolvidos em diferentes tecnologias.






No modelo tradicional, caso um sistema necessite acessar informações em outro, o mesmo só poderá fazê-lo acessando a base de dados diretamente (caso possível), o que impactaria no desenvolvimento de módulos adicionais, regras de acesso e validação para cada caso.




No modelo SOA, existe um serviço em cada sistema responsável por disponibilizar as informações para cada um dos outros sistemas.


Web Services


O mercado padronizou a implementação de SOA através de Web Services, por serem robustos e flexíveis, mas em nenhum momento, em sua definição, é dita a regra que a comunicação entre sistemas deve ser realizada através de Web Services. Imagine como seria o transtorno a comunicação entre dois sistemas através de um simples arquivo texto, levando em consideração um grande volume de dados e estes contendo, ainda, dados diversificados e distintos.

O que é um Web Service

É uma camada de uma aplicação desenvolvida utilizando a mesma tecnologia/arquitetura, capaz de acessar objetos e diretrizes de negócio da aplicação, é hospedado em um servidor de aplicações disponível em uma determinada rede sendo capaz de responder a requisições de qualquer outro sistema, desde que este siga um mesmo padrão de comunicação.
O padrão adotado é o da especificação WSDL (Web Services Definition Language). O padrão dita as regras de como um Web Service deve receber e enviar as requisições de um determinado cliente e também como deve informar quais serviços estão disponíveis através de um contrato de software.

Como é feita a comunicação

SOAP (Padrão WSDL)

Um dos protocolos utilizados para a comunicação é o SOAP, que é executado através de uma requisição HTTP. A mensagem SOAP é criada por um cliente, que informa o serviço e seus parâmetros (se houverem), o servidor então recebe a mensagem, realiza o processamento e devolve a mensagem com o retorno.

Prós:
Mantém o estado da mensagem, possibilitando a troca de uma mesma mensagem durante várias requisições.

Contras:
Trafega apenas XML, que em sua característica é bastante verboso, consumindo muito processamento.
Cada tecnologia deve interpretar o XML, transformar o mesmo em um objeto nativo de sua linguagem, para então executar o processamento, transformar novamente em XML e devolver a resposta.

REST

Prós:
É veloz, pois a comunicação é realizada diretamente através de um método POST ou GET do HTTP.
É capaz de enviar e receber respostas através de JSON, Texto além do XML.

Contras:
Não mantém estado, tornando cada requisição única.
Não permite a utilização de tipos compostos, apenas primitivos.

Espero que este post tenha servido para apresentar um pouco sobre este assunto tão abrangente. Abraços e até a próxima ;)

Google Web Toolkit - Impressões

O que é

Framework para desenvolvimento de aplicações RIA (Rich Internet Applications) baseado em Java desenvolvido pelo Google.

Vantagens

Confiabilidade

Framework Open Source, maduro e amplamente aceito pelo mercado, a primeira versão foi lançada em 2005.

Garantia

Dificilmente a tecnologia vai ser descontinuada, já que o Google é o criador do mesmo.

Chega de Plug-Ins

Não é necessário instalar nenhum Plug-In no navegador do cliente.

Widgets

O GWT oferece uma vasta gama de componentes prontos chamados de Widgets e ainda existem empresas terceiras que desenvolvem gratuitamente mais Widgets para o GWT.

Cases

Várias aplicações de sucesso da Web 2.0 utilizam o GWT:

Drools

Gmail

Google Docs

Desvantagens

Produtividade

Não possui interface de Design como o Dreamweaver ou o Visual Studio, por exemplo, portanto não é possível visualizar a tela até iniciar o processo de Debug. Ou seja, o desenvolvedor constrói a tela no escuro, visualizando o resultado apenas em RunTime.

Maior tempo de Análise

Por possuir uma estrutura mais complexa na geração da interface, visando garantir reaproveitamento e padronização de código, é necessária uma análise mais complexa antes do desenvolvimento de cada classe, adotando padrões e convenções que devem ser respeitados por toda a equipe de desenvolvimento, já que alguns desenvolvedores da equipe devem se preocupar com a User Interface em si, e outros com o comportamento destes objetos, que por sua vez devem respeitar as regras de negócio estabelecidas por um terceiro grupo de desenvolvedores, os da Regra de Negócio.

Como funciona

Client Side

Desenvolvimento da UI

O GWT oferece várias APIs aonde o desenvolvedor escreve código Java para a criação da interface visual da aplicação, não escrevendo código HTML ou JavaScript. Ou seja, o desenvolvedor codifica em Java e faz o Deploy de JavaScript.

Após a criação dos objetos Java (POJOs), o compilador do GWT traduz o código em JavaScript e HTML, criando uma versão do código para cada um dos navegadores mais utilizados, entre eles o Chrome, IE, Firefox e Safari, resolvendo assim o problema do navegador cruzado. Ou seja, não há o risco de a aplicação funcionar de um jeito ou não funcionar dependendo do Browser.

Figura 1: Fluxo de Trabalho. Fonte: Global Code

CSS

É possível utilizar arquivos CSS para definir todo o tema visual da aplicação, como se estes arquivos CSS fossem ser utilizados por uma página Web comum. Isso garante transparência no desenvolvimento, pois o Web Designer não precisa ter ligação alguma com o escopo da aplicação.

Internacionalização

É possível definir um arquivo de constantes para cada idioma desejado que a aplicação suporte, sendo assim, dependendo do idioma do navegador do cliente, todos os textos da aplicação serão exibidos naquele idioma. Portanto, durante o desenvolvimento, não há a necessidade de se preocupar com este fator.

Server Side

O GWT realiza chamadas assíncronas (AJAX) aos componentes da camada de Negócio, tais chamadas podem ser realizadas via RPC ou HTTP.

RPC

O GWT realiza uma chamada a um serviço (Servlet *) de forma assíncrona, após o retorno desta chamada realiza alguma ação (callback).

Figura 2: Chamada RPC. Fonte: Global Code

* Classe Java capaz de responder a reaquisições de protocolos Web.

HTTP

Solução utilizada quando a regra negócio ou algum outro tipo de informação que será consumida pela aplicação não está nela mesmo. Tal solução é aplicada então quando se trabalha com WebService (Arquitetura SOA).

Figura 3: Arquitetura SOA. Fonte: Google Images

Conclusões

Realizei um Estudo de caso aonde criei uma aplicação GWT com o Eclipse.

Processo de instalação

Totalmente fácil, automatizado, apenas inseri a URL do servidor e o Eclipse realizou o download do Plug-IN e o instalou automaticamente na IDE, gerando assim o template e a barra de ferramentas do GWT.

Terminada a instalação eu gerei o projeto de exemplo.

Desenvolvimento do lado Cliente

Criei uma tabela através dos Widgets: Label, TextBox e DatePicker. Através desta tabela é possível inserir e excluir linhas dinamicamente através de dois botões de ação.

Agrupei os componentes da tabela utilizando um Widget do tipo Panel, que além de agrupador serve para melhor distribuir os componentes na tela.

Encontrei dificuldade apenas em saber exatamente como estava ficando a interface, o que me forçou a ir ver a aplicação em RunTime inúmeras vezes. Creio que este tipo de problema seja sanado à medida que eu for me habituando com a ferramenta.

O resultado pode ser visto abaixo:

Foram criadas 3 classes de interface para montar e controlar o Widget. O que resultou em aproximadamente 4 horas de desenvolvimento, número bastante elevado, porém mantendo-se a rigor o padrão de orientação a objetos e consultando-se diversas vezes a documentação do GWT visando utilizá-lo da melhor e mais correta maneira possível.

Desenvolvimento do lado Servidor

Não desenvolvi nenhuma chamada ao Servidor, apenas utilizei a chamada pronta que veio com a aplicação de exemplo e a modifiquei. Tal chamada foi do tipo RPC, aonde o servidor capturava alguns dados, transformava em String e devolvia para o cliente.

Não encontrei nenhuma dificuldade em entender o processo de requisição. Como estou em um ambiente JAVA EE, posso plugar qualquer Framework para me auxiliar no lado servidor, como o JPA (para dados) e o Spring (para inversão de controle e metodologia MVC), desfrutando assim de toda a robustez do EJB.

Considerações Finais

Acredito que o GWT é uma excelente aposta para o desenvolvimento de aplicações RIA aonde a preocupação do Gerente é manter um alto grau de escalabilidade e robustez sem esquecer de lado uma interface extremamente rica, leve e amigável para o usuário, não importando qual seja o perfil do mesmo.

Referências

Site Oficial: Google Web Toolkit. Disponível em: http://code.google.com/webtoolkit/

Global Code: Introdução a Google Web Toolkit. Disponível em http://www.globalcode.com.br/download/minicursos/mc56-gwt.pdf