RESTful Web Services Teoria Prática
•Als PPT, PDF herunterladen•
4 gefällt mir•612 views
O documento discute arquitetura RESTful para web services. Ele explica os principais conceitos de REST como recursos, identidade, interface uniforme e hipermídia. Também discute como REST fornece uma arquitetura simples, escalável e tolerante a falhas em comparação com outras especificações como WS-*.
![RESTful Web Services ,[object Object],[object Object],[object Object],[object Object],[object Object]](https://image.slidesharecdn.com/restteoriaepratica-091118170022-phpapp01/85/rest-teoria-e-pratica-1-320.jpg)
![Integração ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie RESTful Web Services Teoria Prática
Ähnlich wie RESTful Web Services Teoria Prática (20)
Mehr von Luiz Costa
Mehr von Luiz Costa (7)
RESTful Web Services Teoria Prática
- 7. Foco nas operações Serviço Tradicional <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Body> <m: ObterPedidos xmlns:m=“ urn: ServicosPedidos "> < id xsi:Type=‘xsd:integer’>12553</id> </m: ObterPedidos > </env:Body> </env:Envelope>
- 8. Foco nas operações Serviço Tradicional No matter how hard I try, I still think the WS-* stack is bloated, opaque, and insanely complex. I think it's going to be hard to understand, hard to implement, hard to interoperate, and hard to secure. Tim Bray Director of Web Technologies at Sun Microsystems . Fonte: http://qotd.me/q 2004-11-02.html
- 12. Web apenas para humanos ? “ Não existe nenhuma diferença essencial entre a web humana e a web programável ” Leonard Richardson e Sam Ruby
- 15. Architectural Styles and the Design of Network-based Software Architectures Dissertação de Doutorado – Roy Fielding - 2000
- 16. REST
- 20. Link os Recursos Os dados do pedido junto com o cliente <cliente> <id> 23 </id> <nome>Joana Cardoso</nome > <cpf>12345678900</cpf> <pedidos> <pedido> <id>1234</id> <data> 01/10/2009</data> <valor> 100.00 </valor> <items> <produto>33</produto> <quantidade>1</quantidade> <preco>100.00</preco> </items> </pedido> </pedidos> </cliente>
- 23. Interface Uniforme Agora o foco são os Recursos.
- 28. Escolhendo uma Representação GET /pedidos/2009/11 HTTP 1.1 HOST exemplo.com Accept: application/xml 200 OK <pedido … />
- 29. Possíveis representações do recurso: http://exemplo.com/clientes/23 XHTML XML <html> <body> <dt>id</dt> <dd>23</dd> <dt>nome</dt> <dd>Joana Cardoso</dd> <dt>cpf</dt> <dd>12345678901</dd> </body> </html> <cliente> <id> 23 </id> <nome>Joana Cardoso</nome> <cpf>12345678900</cpf> </cliente>
- 30. Falta de Estado
- 38. FIM Luiz Costa [email_address] Sergio Junior [email_address] .br Obrigado.
Hinweis der Redaktion
- Luiz e Sergio : Bom dia, nos somos Luiz e Sergio Luiz O objetivo de nossa apresentação é mostrar REST como uma alternativa a implementação de Web Services tradicionais. Sergio: Vamos falar um pouco da teoria e depois mostrar um demo de uma aplicação aplicando essa teoria.
- Bom, pra começar, vamos contar uma história que já aconteceu com a gente em uma empresa. Ou melhor, com amigos nossos. Rs Se alguém notar alguma semelharnça com a realidade é mera coicidência. Um dos maiores problemas que temos hoje em dia, é o de integrar 2 ou mais aplicações né. Como fazer para compartilhar informações entre estas informações. Em uma empresa qualquer, passamos por um problema desses. O que é bem comum hoje em dia. Tínhamos várias aplicações dentro da empresa e estas precisavam se comunicar. Trocar informaçlões. Tínhamos aí o velho problema. Como integrar isso. A primeira solução que foi utilizado é:
- Banco de dados Vamos compartilhar as Tabelas que são comuns para as aplicações e tá tudo certo. Então as aplicações que utilizavam as tabelas de clientes, produtos, iriam acessar a mesma tabela. Isso durante um tempo funcionou bem. Só que as coisas começaram a ficar mais complicadas. Várias outras aplicações foram aparecendo, precisam de acessar informações de clientes e produtos, ou até mesmo de outras tabelas. Isso começou a gerar um trabalho enorme, manter todas estas tabelas em um estado consistente. Isso era trabalhoso mas de certa forma funcionava. Até o dia que apreceu um parceiro externo. Nós precisávamos trocar informações com um parceiro. Como fazer? Alguém deu a solução, a gente pede pra ele uma tabela, o ip do servidor de banco de dados e construímos a url de conexão e fazemos a conexão direta neste servidor. Brilhante né? É evidente que este parceiro não aceito esta solução, não iria liberar acesso ao servidor de banco de dados deles. Enfim não deu muito certo. O pessoal mais antigo então disse. Vamos fazer troca de arquivos. Isso era muito comum antigamente.
- O pessoal mais antigo então disse. Vamos fazer troca de arquivos. Isso era muito comum antigamente. Os 2 parceiros vão combinar alguma coisa sobre como estes arquivos serão formados e então, nós construímos o nosso parser e conseguimos ler os dados destes arquivos. Muito legal né. Mas e se aparecer um outro parceiro externo? Hoje em dia, não podemos pensar que nossa aplicação é uma ilha, onde somente a gente vai utilizar seus dados. Todo mundo quer trocar informação hoje em dia, se vc for observar, quase tudo é integrado, o serviço de cartão de crédito, a compra de passagens, em uma aplicação de agencia de viagens etc. Começaram a surgir várias opções no mercado, apareceram os famos Objetos Distribuídos, com aquele negócio do CORBA. Era interessante né, eles tinham um discurso que ia resolver estes problemas de integração com objetos distribuídos. Esse negócio não vingou né. Precisavamos de algo mais padronizado. Voltando ao ao problema
- Podemos utilizar web services. Todo mundo hoje utiliza web service. É a forma mais comum de se fazer integração hoje. Já temos um formato padronizado, podemos tirar proveito da interoperabilidade, enfim, várias vantagens né.; Vamos dá uma olhada em como eles funcionam.
- Os Ws são padronizados, tem uma tal de W S * que define um conjun to de padrões Outro coisa interessante, é que agora vc não fica trocando arquivos, vc sabe exatamente o que fazer. Ou seja, vc tem disponivel em algum lugar, algo que te diz Como utilizar este serviço. Isso é oq conhecemos como WSDL. Para vc utilizar o serviço, vc precisa conhecers seu descritor. Vc tem um contrato. Como vcs podem perceber, estes web services são focados em operações. Vc tem que conhecer quais são as operações que vc pode executar sobre o serviço. Isso até parece razoavel né, eu precisa saber oq eu possa fazer para interagir com o serviço.
- Vamos imaginar que eu tenho um cliente que quer trocar informações com um serviço. Este é um serviço de pedidos. Por exemplo, se eu quiser obter todos os pedidos, primeiramente eu tenho que saber qual operação chamar. Para isso eu preciso ir até um EndPoint, que está disponível na web, e fazer uma marcutaia qualquer (as ides normalmente te ajudam nisso) e gerar um conjunto de classes para acessar aquele serviço. Feito isso, eu posso utilizar o serviço. Quando eu envio uma solicitação para o serviço de pedidos, invocando o metodo ObterPedidos, o que na verdade acontece é que, sua solicitação é transformada em um envelope SOAP. Soap é um protoclo que é utilizad para embrulhar os dados de uma solicitação em um webservice. Dentro destes envelope, vão as informações do método a ser executado, os parametros, etc. E o SOAP utiliza o HTTP como protocolo de transporte, para carregar os dados. Depois que isso acontece o servidor, processa os dados, e retorna um envelop SOAP, contendo a resposta. Isso funciona hoje, e é muito utilizado. Acontece que o ws-* não para de crescer. Se vc quiser segurança, vc vai ter utilizar um padrão do ws para prover segurança, se quer transações tem que utilizar um ws qualquer para prover transações. Isso tá se tornando demasiadamente complexo. Teve um dia desses aí, que um rapaz conhecido como Tim Bray, deu uma alfinetada nestes serviços. (mostrar a foto e o texto agora). Interessante isso né.
- Mas será que precisamos disso tudo? Para fazer coisas simples, deveria ser simples né... Será que já não existe algo que faça isso pra gente, será que não temos nada pronto para ajudar a gente?
- Vamos dá uma olhada em algo que já faz parte da nossa vida hoje. A Web. Quando vc quer saber de alguma noticia o que vc faz hoje? Liga a TV? Será que está passando o noticário? Vc utiliza a internet.
- Para acessar o site da Aljazira eu precisei de quê? Somente de uma url né. Então o que acontece é, eu entro no meu browser, digito a url e mando pro servidor. O servidor processa a resposta e devolve. Volta a resposta. Quem comunicou foi o browser com o servidor. Esta imagem não é bem parecida com a dos webservices? Tinhamos 2 aplicações se falando naquele slide, e agora, temos 2 aplicações se falando? Sim, o browser e servidor web. É engraçado como ignoramos o browser né... Ele eh da familia. O browser troca dados com o servidor, da mesma forma que uma aplicação trocaria dados com um serviço. Podemos fazer melhor, podemos trocar de browser. Aí somente para exibir alguns dos browser mais utilizados hoje. Será que falta algum aí? Não né... Ele não pode ser considerado browser..hehehe Ainda temos dispositivos móveis que podem acessar o site da aljazira, por exemplo o iphone, celular. E ainda, para os mais puristas, podemos acessar isso utilizando o utilitário de linha de comando Curl. Para quem não consegue ver, nós tentamos colocar a imagem do curl ali. Acreditem, é aquele borão preto. O que acontece aqui, é a torca de dados entre duas aplicações. O browser o servidor web.
- Falar do Varejo Americanas Submarino Pedidos de um cliente, lista de produtos, comprar televisao Se pararmos para pensar, um site da internet como o das lojas americanas ou submarino, poderia ser classificado como um serviço né? E o que acontece nestes casos é que seres humanos acessam sites na web. E quando falamos em serviços, estamos falando de outras aplicações que irão acessá-los. Só que alguns caras aí disseram que, a web que nós utilizamos, não deveria ser muito diferente da que os programas utilizam O que estamos falando é que poderíamos então ter aplicações que utilizassem a internet para trocar dados de uma forma bem parecida com o que já acontece hoje. Quando eu entro em um site para comprar um produto, eu, ser humano, sei escolher as informações do produto, baseado nas minhas opções. Mas quando um programa for executar esta tarefa, ele não sabe escolher os produtos, da mesma forma que um ser humano. Então existe um pequeno ponto aí: programas de computador são bons ao desenvolverem e analisarem documentos, e estrutura de dados complexas, mas não são tão flexíveis quanto humanos ao interpretarem os documentos. Para aproveitar todo o potencial da web, vamos ver algumas características.
- Rápido Repare bem estas características. Será que não é isso que procuramos nas aplicações que desenvolvemos atualmente?
- Então a maioria dos serviços web que construímos não poderia fazer uso apenas do HTTP? Será que isso seria possível?
- Pensando nisso um rapaz resolveu escrever uma tese de doutrado, que falava de um estilo arquitetural usando o http como base. Neste estilo arquitetura se faz extenso uso dos recurso do protocolo http. Ele não era fraco não, esse cara, Roy Fielding, participou da especiicação do HTTP. Então o menino tem conhecimento de causa. O nome que ele deu para isso foi REST
- Só passar Vamos entender o que é isso então né
- REST significa – REpresentational State Transfer Pontos Chave: É um estilo de arquitetura e É baseado em um conjunto de principios Bom para aproveitar então todas as características da web , o que precisamos em primeiro lugar é tentar ser simples, da mesma forma que a web é. Isto significa que não precisamos de nada além do que já está disponível na web para implementar aplicações que fazem parte da web. REST é simples, mas não é pq ele simples que só é possível implementar serviços simples. Podemos ver o Rest como um conjunto de princípios que definem como os Web Standards , tal como HTTP, URIs são utilizados. A idéia então é que se vc adota estes princípíos enquanto projeta sua aplicação, esta irá conseguir explorar todos os benefícios que a arquitetura web nos trás. Vamos começar a analisar estes princípios
- Diferente da visão tradicional de web services, o que vc expõe em rest são Recursos. Mas o que são estes Recursos? Recursos são coisas importantes que vc tem na sua aplicação. Eles podem ser algo físico como uma foto, ou um conceito abstrato como “Como está o tempo agora?”. Então fotos, relatorios, arquivos e até uma lista de buracos da br 101, podem ser recursos. Inclusive o resultado de um cálculo. Por exemplo, posso ter um recurso Total de Vendas por Região. Isso é um recurso algorítmico. Vale destacar que um recurso identifica alguma coisa. Eu posso ter o recurso Todos os Clientes, mas eu também tenho o Recurso Cliente “José Maria” O primeiro, representa todos os clientes, o segundo apenas o josé maria. Tudo o que vc vai expor em sua aplicação utilizando REST vai se transformar em Recursos.
- Então agora a gente sabe que expomos recursos. Então na minha aplicaçõe eu tenho vários recursos disponíveis para utilização em outras aplicações. Mas como eu utilizo estes recursos? Vamos pensar como é feito nos webServices tradicionais. Vc tem um EndPoint onde vc descobre um WSDL que te dá as informações do Serviço. Tem que ter algo para que eu consiga Identificar os recursos que eu tenho na minha apliucação. Precisamos de um ID. Um identificador. Por exemplo para um recurso Cliente eu poderia utilizar o CPF como um identificador. Acontece que queremos que nossa aplicação faça parte da web, e há um concenso na web sobre IDs. A forma padrão de identificar qualquer coisa na web é através de URIs. Então para eu acessar os recursos eu vou utilizar URIs, da mesma forma que eu faço para acessar o site do google. Se eu estou desenvolvendo uma aplicação para cuidade de clientes eu posso expor alguns recursos: “ Todos os clientes” este vai ser acessado por http://exemplo.com/clientes. Repare que este recurso, representa todos os clientes da minha aplicação. Eu não estou me referindo a um cliente em específico. Se eu quiser fazer isso, então tenho que expor outro recurso. http://exemplo.com/clientes/10 Repare que agora eu acesso apenas o cliente 10. ou http://exemplo.com/clientes/23 Somente o cliente 23. Como utilizamos uris para identificar recursos é comum ver por aí, uris bem legíveis para facilitar sua leitura. Agora, como este recurso é identificável, vc pode chegar no Browser e digitar esta URI e ir diretamente até este recurso, ou até mesmo, copiar esta URI e colar em um e-mail e enviar para o setor de marketing oferecer uma promocao a este cliente. É assim que a web funciona né. Vc sabe as uris dos sites que vc acessa.
- Uma vez que conseguimos encontrar um recurso e solicitar informações sobre ele, é possível que estas informações possam nos levar outros recursos. Ex: Quando solicitamos “Cliente número 23&quot; podemos ter as informações do recurso cliente 23 e alem disso, alguns pedidos podem estar associados a este cliente. Então como poderíamos representar isso? Nós vamos falar de representações com mais detalhes um pouco a frente, mas por enquanto vamos pensar nestes pontos: a) Poderíamos ter uma representação do recurso cliente em XML e incluír os dados dos pedido junto desta representação
- b) Poderíamos ter uma representação do recurso cliente em XML e incluir um Link para o recurso Pedido. Se observamos a Web trabalha atraves de links. Quando vc entra em um site na web, normalmente vc não continua sua navegação digitando novos endereços na barra do se browser. O que vc faz é seguir os links. Se nossa aplicação quer fazer parte da web, temos que incorparar estas características nela. Assim nós utilizamos links para continuar a nevagação pela nossa aplicação, da mesma forma que a web. Esse é o conceito conhecido como Hipermedia: os documentos não são apenas dados, mas links para outros recursos.
- Bom, falamos de URIs e Recursos, e por último falamos de Links. Como podemos utilizar estas URIs e Links em nossa aplicação? Quando vc vê uma URI em alguma propaganda em um Outdoor, ou até mesmo alguém informando isso em um programa de televisão, vc pode pegar esta URI, digitar no seu Browser e esperar um resposta. Mas o que seu Browser faz com esta URI? Como ele sabe o que fazer com ela? O browser sabe o que fazer com esta URI, pq existe uma interface padrão para todo recurso. O seja, todo recurso suporta a mesmo conjunto de instrucoes, ou o mesmo conjunto de operações. Em toda Web, existem apenas algumas coisas básicas que vc pode fazer com recursos. O protocolo HTTP nos fornece quatro métodos básicos para operações mais comuns. Ele chama estes métodos de verbos, são eles (GET, POST,PUT,DELETE ) e alem deles temos (HEAD e OPTIONS). Isto significa que estes métodos estão definidos na especificação do protocolo HTTP. É como se imaginássemos (em OO) que existe uma interface que todo recurso precisasse estender.
- Como temos uma interface padrão definida, eu posso confiar que serei capaz de obter uma representação de um recurso usando um método GET. Eu posso confiar nisso pq a semantica do método GET está definida na especificação do HTTP. Então o que o meu Browser faz quando eu digito uma URI é enviar um solicitação usando o método GET do HTTP. Mas pera aí. Eu tenho 4 métodos disponíveis para realizar todas as operações em um recurso? Esse negócio tá meio esquisito. Acontece que normalmente utilizamos uma abordagem de design diferente quando utilizamos Rest. Vamos tentar ver como modelamos um &quot;Serviço&quot; web hoje. Temos um &quot;Serviço&quot; e vários métodos que atuam sobre este serviço. Se quisermos utilizar este serviço precisamos conhecer antes a sua interface. Não tem como utilizaramos sem conhecer esta interface. Utilizando Rest nós utilizamos uma forma mais genérica para lidar com isso. Lembra que falei que parece que todo o recurso rest estende uma interface padrão? Então nós precisamos utilizar somente os métodos do HTTP. Mas como resolver tudo com estes métodos? Talvez vaão existir situações que não vamos conseguir resolver com apenas estes métodos. A resposta para isto é, vamos criar vários recursos. Na implementação tradicional temos apenas um 1 serviço que tem vários métodos. Na nossa implementação baseada em rest, vamos ter vários recursos, e cada recurso vai ser manipulado pelos métodos default do http.
- representa um pedido em especifico, o template {identificador} informa que será utilizado algo que identifique um pedido em especifico, pode ser um número. As operações são: Agora nós utilizamos os métodos da interface padrão sobre os recursos criados. O método GET sobre um pedido especifico tem o mesmo efeito que o metodo obterDetalhesDeUmPedido(). Com uma abordagem como essa,existe um número fixo de operações, mas podemos representar milhões de pedidos diferentes através de recursos. Então quando eu quero obter a informação de um recurso eu utilizo o método GET. Quando vc faz uma requisição GET em um recurso vc não está fazendo qualquer alteração no estado do Servidor. Qualquer quantidade de requisições GET que eu fizer no mesmo recurso, terá sempre o mesmo efeito. Então uma operação GET é segura, não há mudanças de estado. Para criar um pedido utilizamos o POST ou o PUT. A diferença é que com o POST o servidor decide qual URI vamos utilizar. Por exemplo, se utilizar uma URI deste modo: http://exemplo.com/pedidos/1258, onde o número é um ID que só será conhecido após a criação do recurso, utilizamos post. Se queremos criar um recuro já com uma URI definida, então utilizamos o PUT> E para excluir um recurso utilzamos o DELETE Todas estas iterações podem ter problemas, e para utilizamos o código de erro do HTTP. O clietne deve verificar estes codigos de erro da requisição para saber se deu tudo certo ou não. E a partir daí, qualquer aplicação que saiba conversar com o HTTP pode utilizar nossos Recursos. Inclusive seu Browser!!!
- representa todos os pedidos, ou seja toda a coleção de pedidos disponíveis. Podemos descrever o que as operações padrão fazem para este recurso como:
- Um recurso é apenas uma idéia, algo conceitual. Quando utilizamos uma URI para chegar até um recurso, estamos na verdade pedindo o servidor web exatamente o quê? O Servidor web não pode nos enviar uma idéia. O que um servidor sabe responder para nós, é apenas um conjunto de bytes. Este bytes normalmente, deve estar em formato específico, em uma linguagem específica. Esta linguagem e este formato ó que chamos de representação de um recurso. Um mesmo recurso, pode ter diversas representações. Por exemplo, eu posso querer exibir os dados do meu Recurso Cliente em um Browser, para isso eu podeira utilizar uma representação deste recurso em XHTML. Ou então eu poderia disponibilizar os dados deste recurso para uma outra aplicação. Para isso eu poderia utilizar XML. O fato é que podem haver várias representações para um mesmo recurso. Aqui tem os algumas delas.
- Um mesmo recurso, pode ter diversas representações. E quando solicitamos informações sobre um recurso através da chamada de métodos padrão, nós também podemos informar, qual é a representação que esperamos. Nós temos um recurso que é: &quot;/pedidos/2009/11&quot; (pedidos de novembro de 2009). Ele pode ser acessado por uma URI: http://exemplo.com/pedidos/2009/11. Quando acessamos esta URI através de um browser, o que esperamos como resposta? Uma página web contendo os dados dos pedidos de novembro de 2009. Já quando acessamos por uma aplicação, talvez fosse melhor, receber estes dados em uma outra representação ou formato, por exemplo XML, ou até mesmo em um arquivo texto separado por vírgulas. Se vc fornece os formatos xHTML e XML para representações do seu recurso, ele pode ser consumido não somente pela sua aplicação, mas por qualquer Web Brower ou seja, as informações de sua aplicação podem estar disponível para todos que saibam utilizar a web.
- Como eu disse, seu que quiser exibir os dados do meu recurso em um site por exemplo, eu posso utilizar um representação em XHTML. Agora se for para uma outra aplicação utilizar vamos expor os dados em xml. Aqui alguns exemplos de como isso poderia ser utilizado.
- O último princípio que nós gostaríamos de falar é sobre falta de estado. A falta de estado significa que toda a solicitação HTTP ocorre em um isolamento completo. Quando o cliente faz uma solicitação HTTP, inclui todas as informações necessárias para o servidor processar e responder esta solicitação. O princípio da falta de estado torna as coisas muito mais simples. Um cliente pode fazer solicitações para um mesmo recurso, diversas vezes. Uma servidor pode parar de responder por algum problema técnico e interromper a solicitação no meio do caminho sem maiores problema, visto que o cliente pode reenviar a novamente.
- Mas é evidente que precisamos armazenar os dados de nosso Recurso, pois são estes dados que nos fazem querer utilizá-lo. A falta de estado que estamos falando aqui é a falta de estado da aplicação. Existe uma diferença entre falta de estado da aplicação e falta de estado do recurso. A falta de estado da aplicação significa que o cliente é quem deve ser o responsável por gerenciar seu próprio caminho pela aplicação. O servidor nem sabe que existe um cliente conectado. Agora o estado do recurso é o mesmo para todo o cliente e seu lugar é no servidor. Por exemplo, quando você faz um upload de fotos no Flickr ele cria um novo recurso que tem sua própria URI e pode ser destino de futuras solicitações. Esta foto é parte do estado do Recurso e ficará no servidor até que algum cliente a apague.
- A falta de estado na apliacação nos traz uma vantagem enorme quando falamos em escalabilidade. Imagine que eu tenho um servidor atendendo uma aplicação. Tem um cliente acessando, e o servidor respondendo. De repente começam a aparecer outros clientes acessando sua aplicação. Ela começa a se tornar popular, o número de requisições vai aumentando. Até que chega um ponto que seu servidor abre o bico. E aí o que fazer?
- Podemos escalar a vontade os servidores web. Até que o problema mude de lugar. (BD) Nico vai resolver isso! =)
- Falar rapidamente da arquitetura
- Bom pessoal, já falamos muito sobre a teoria do REST, sobre Web como plataforma, sobre um monte de coisas, então vamos deixar este bla bla bla pra lá e vamos ao que interessa. O que vamos fazer aqui hoje é mostrar apenas um pedaço de código como exemplo de como seria um serviço Rest. Para isso vamos utilizar um exemplo de aplicação do treinamento FJ-16 aqui da Caelum. É uma aplicação que utilizar um conjunto de CandleSticks para traçar gráficos. Nós resolvemos utilizar esta aplicação para desmistificar que serviços Restful são sinônimos de CRUD. Então nosso objetivo com esta aplicaçõe é arrancar a lógica de negócio desta aplicação e expor isso através de serviço web. Quais recusos podemos identificar nesta aplicação?
- JERSEY - JSR-311 Nós encontramos os recursos Negocio, CandleStick e Acao Vamos utilizar o Jersey para implementar estes recurso em java. Temos uma aplicação desktop que consome estes recursos.