Posts Tagged ‘HTTP’

Palestra: Guerrilla SOA – Falando em Java 2009

maio 25, 2009

Guerrilla SOA

palestra de Dr. Jim Webber da ThoughtWorks

Foi uma palestra muito bacana, abordando de forma direta e engraçada um assunto que normalmente traz mais perguntas do que respostas.

Muitas vezes ele encontra muitos sistemas complexos e nestes casos eles utilizam middlewares. Mas ele vai mostrar uma outra opção que utiliza:

  • Agile: pode ser usado em aplicacoes grandes.
  • Web:  Não da forma que conhecemos.

Podemos trazer agile e web juntos

No começo da computação

No começo da computação era comum e normal ter “silos” de aplicações.  Algumas pessoas inteligentes, presenciando esse panorama, enxergaram a possibilidade de dividir e comunicar estes silos de aplicação. Estes caras fizeram muito “encanamento” para juntar estas aplicações.  E isto funcionava, porque de alguma forma os silos estavam ligados entre si. Não era bonito mas funcionava.

Através dos anos, com o desenvolvimento da computação, a competição surgiu e os especialistas de integração se tornaram muito fortes. Eles exercerciam muita influência e se tornaram muito grandes no mercado.

Eles absorveram muita coisa: BPM, Regras de negócio, adapters, GUI tools, segurança, transformations, confiabilidade…. Com isso, mais silos foram integrados e, mesmo assim, não se tornaram muito melhores.

Neste cenário, SOA veio ao resgate destes problemas. Veio para aumentar o nível de abstração, para pensarmos em nosso sistema com uma mente voltada ao negócio. Mas não é para ser implementado da forma que os livros pregam, não focam em processos de negócio, mas em uma visão de TI.

ESB poderia ser uma boa opção, mas ele é ingovernável, porque para ser efetivo todos os sistemas da empresa deveriam estar funcionando no mesmo bus. E se tivéssemos este bus, estaríamos replicando o problema que atualmente temos com os DBAs.  Além disso, esta solução não escala.

Pensando em agilidade

Ninguém pode negar a beleza do modelo tradicional. É mais confortável, parece que podemos prever tudo. Mas, sabendo que não podemos prever tudo, aprendemos ao longo do projeto. Por isso muitos projetos waterfall falharam.

Foi abordada a criação do manifesto ágil, e que os valores ágeis são bem diferentes do tradicional. E que para eles funcionarem tivemos que aprender sobre BDD, restrospectiva, TDD, review e outras técnicas. Aprendemos também a crescer de forma incremental. E temos que fazer isto para desenvolvimento de sistemas complexos e não só para uma única aplicação.

A WEB

A web quebrou regras. Não foi só uma plataforma de publicação, mas de coordenação de tarefas. Quando navegamos em um site como o Amazon, vamos tela a tela… sendo guiados no processo de compras.

A web é protocol-centric, fazendo com que não seja necessário nenhum middleware. É uma rede “burra”, mas que é uma boa idéia.

A rede telefônica é boa em comprar e prover serviços de voz. Quando tentamos utilizar para serviços de dados, chegamos a um limite. A internet é a rede mais burra possível, ela roteia os pacotes independente do que esteja sendo executado.

Tem uma arquitetura que permite o surgimento de inovação, sem que haja previsão do quão grande isso será.

SOA Tradicional

Formada por pessoas de gabinete e programadores no front.

A guerrilha SOA propõe a idéia de quebrar em diversos pequenos passos, como parte de um grande programa de mudança. Devemos dividir os serviços de acordo com os serviços de negócio, deixando com que os responsaveis do negócio definam e sejam responsáveis  por ele.

Devemos priorizar e entregar incrementalmente os serviços, assim damos valor ao trabalho daqueles que estão no gabinete e os que estão no front.

Web e Serviços

A web é um middleware. Ele gastou muito tempo trabalhando em soluções de middleware. E só depois percebeu que a web já fazia quase tudo. E além disso, a Web já está em todos os lugares.

Além disso, a web é incremental, porque podemos fazer deploy de coisas novas sem quebrar o que já existe. Fazendo com que o risco de usar a web seja muito baixo.

O middleware, neste cenário, é opcional. A web pode ser o seu ESB. Se precisar escalar, coloque um servidor proxy para sua aplicação. A Web é projetada para crescer.

As vantagens da tecnologias Web-Centric em comparação da abordagem tradicional:

  • evolutionary design (ao contrario do BDUF)
  • entrega constante (grandes projetos)
  • Mais barato (caro)
  • Incremental (arriscado)
  • Escala da internet (escala da empresa)
  • Tem em todos os lugares (especializada)
  • integração por produto, entregando valor para o produto

Blog:  http://jim.webber.name

Alexandre Gomes, da Sea, fez uma palestra sobre este assunto no lançamento do InfoQ Brasil.

Perguntas que foram feitas

Se SOA é ruim, porque falamos dela tanto?

– Muita gente faz dinheiro com ela.

– Queremos que SOA funcione.

Como usar HTTP para nossos serviços?

– Fornecer os serviços no lado do servidor.

– Implementar melhor máquina de estados no lado do cliente, aprendendo novas técnicas ou reaprendendo técnicas tradicionais.

Quando eu utilizaria SOA dentro de uma empresa?

– Nas mesmas situações que você utilizaria lits distribuídos hoje. usar distribuído por default, REST.

– No ano passado estava trabalhando para uma empresa no Canadá e perceberam que podiam cachear uma boa parte do catálogo utilizando REST. Desde então, ele usa como REST por default. Só não utilizaria em situações onde o tempo de latência deve ser inferior a 1 segundo. neste caso, ele pagaria por isso.

E a TV Digital?

Ele acha que está convergindo com a web, será um aliado natural da Web.

Palestra: WebServices RESTful – Falando em Java 2009

maio 25, 2009

WebServices RESTful

Palestra apresentada por Jim Webber (ThoughtWorks)

Introdução

Jim, que na minha opinião, foi o melhor palestrante do evento, fechou o evento falando do mesmo assunto que seria destinado a Bill Burke, WebServices RESTful. Após apresentar sua MiniBio ele apresentou os tópicos da apresentação:

  • The Richardson Maturity Model;
  • Web Architecture;
  • Tunneling and POX;
  • URI templates and CRUD Services;
  • Hypermedia Formats;
  • RESTful Services.

The Richardson Maturity Model

O modelo de maturidade Richardson é definido em quatro níveis:

  • Level 0: SOAP, XML, RPC, POX (single URI);
  • Level 1: URI tunneling (muitas URI’s, único verbo);
  • Level 2: Muitas URI’s, muitos verbos (CRUD Services – Modelo Amazon S3);
  • Level 3: Level 2 + Hypermedia (RESTful Services).

Web Architecture

  • Conceito Web: baseada em recursos, acessada por URI’s (nunca diga URL’s: Deus mata crianças e gatos se você fizer isso, de acordo com Jim), arquivada em meios físicos, acessada por meios lógicos (WebServices) e distribuída para aplicações finais (usuários). Tudo é baseado em verbos HTTP;
  • Tudo é acessado via URI’s. URI é um endereço de acesso a recurso(s) de sistema(s);
  • A Web é muito poderosa: é escalável, tolerante a falhas, recuperável, tem baixo acoplamento, interface uniforme, modelo stateless e fail-over fácil;
  • HTTPS é uma tecnologia madura (baseada em SSL) e deve ser aplicada na Web;
  • Web != REST  (não abuse da Web).

Tunneling and POX

  • URI tunneling Pattern: URI’s com assinatura padrão e facilidade de manutenção, acesso e mapeamento;
  • URI tunneling Strengths: muito fácil entendimento e usabilidade em outras linguagens;
  • POX Pattern: como “parsear” padrões de texto, processá-los e disponibilizar as informações de envio;
  • POX Strenghts: simples, apenas usa HTTP POST e XML, facilidade de reuso, sem suporte a metadados;

URI templates and CRUD Services

  • Web já detém a maioria dos recursos. Deve-se usar o CRUD e pensar nele como base (Jim apresentou exemplos de sinalização de mensagens usando GET, POST, PUT, DELETE);
  • CRUD é bom? Sim, mas CRUD não é REST. Modelo CRUD ainda é muito implementado para armazenar dados somente.

Hypermedia Formats & RESTful Services

  • Microformatos na semântica W3C;
  • RESTful services é o level 3 (media type rules!). Logo é preciso implementar formatos hypermedia e XML (e/ou Application XML) não pode conter links. Do contrário não é nível 3;
  • Application /vnd.restbucks + XML: é o formato XML para hypermedia; não é padrão para a IANA;
  • Links descrevem protocolos, fluxo, regra de negócio. Logo podemos pensar em “Link as API” e tudo como framework;
  • Se você não tem hypermidia você não tem o RESTful;
  • Use a Web para escalabilidade massiva, mas com tolerância;
  • HTTP tem estados e header para todas as situações. Queremos ter baixo acoplamento e isso pode ser auxiliado por meio dos links hypermidia.

Para finalizar Jim Webber deixou um link de um artigo seu escrito para o InfoQ, contendo os mesmos exemplos da apresentação. Agradeceu a recepção e o interesse do público brasileiro. Da minha parte fica a impressão de quão incrível são os palestrantes internacionais e a desenvoltura para fazer apresentação e explanação de idéias sem igual.