Os 7 hábitos dos desenvolvedores de WebServices altamente eficazes
Por Paulo Silveira em 18/02/08Esta semana tive o prazer de palestrar no Café Com Tapioca, evento do CeJUG realizado em Fortaleza. Estavam presentes dois conhecidos evangelistas da Sun: Reggie Hutcherson e Simon Ritter.
O agradecimento fica ao Rafael Carneiro, do PortalJava e do CeJUG, pela organização geral do evento. Agradeço também à equipe do grupo Fortes pela minha vinda ao Ceará: ao Clavius Tales, Igo Coelho, Antônio Israel, Ronaldo Moreira, Tiago Moraes, Rodrigo Maia e tantos outros. Vale reparar como a comunidade java cearense é ativa nos blogs! Nesse sábado também ministrei umworkshop sobre Arquitetura e Design Java aqui em Fortaleza.
Durante esses dias aqui, muitas pessoas perguntaram bastante sobre webservices: em especial JSON e Rest. Compilei alguns dos pontos que foram recorrentes nas discussões e considerados como boas práticas:
Cuidado com a granularidade - a granularidade do seu serviço não pode ser muito fina, caso contrário seus seviços sofrerão dos mesmos problemas que o EntityBean do EJB2 exposto remotamente: uma enorme quantidade de requisições serão disparadas para executar pequenas tarefas, como getters! Seus serviços devem realizar uma quantidade significativa de tarefas, para evitar um número alto de roundtrips!
Exponha serviços, não dados - é comum ouvir a frase “Vou criar webservices para expor os meus dados“. O grande perigo aqui é deixar toda a lógica de negócio na mão do cliente, o que descentralizará seu serviço e forçará o cliente a realizar muitas requisições ao servidor. Devemos expor serviços, e não dados em sua forma mais crua.
Nunca parsear WSDL/SOAP manualmente - antes das ferramentas que trabalham com webservices terem atingido sua maturidade, era muito comum ver por aí as pessoas gerando o SOAP manualmente, através de bibliotecas XML ou às vezes até mesmo concatenando String com o uso de StringBuffer! O SOAP é o protocolo de comunicação, e assim como quando você usa RMI/CORBA e você não enxerga absolutamente nada do JRMP/IIOP, você nunca deveria ter contato direto com o protocolo de comunicação! O SOAP e o WSDL devem ser utilizados por ferramentas, e não pela sua própria aplicação. Hoje em dia qualquer ferramenta como o Apache Axis, Apache CXF, ou mesmo o wsimport, que já vem no JDK 6, auxilia nossa tarefa de gerar Stubs que sabem trabalhar com o SOAP, sem que você nem mesmo precise ve-lo um dia. Se você está usando um servidor de aplicação, esta tarefa é ainda mais fácil, até mesmo para fazer o deploy do serviço.
Não enviar XML dentro de XML - outra prática comumente encontrada em aplicações antigas que usam Webservices: dentro do SOAP é enviado um outro XML como um dos parâmetros, então mesmo usando ferramentas para gerar os stubs você fica com uma String que dentro dela há um XML e este precisa ser parseado por sua própria aplicação. Isto é uma má interpretação do conceito que “Webservices é comunicação via XML“. Concordo que em alguns raros casos isso possa fazer sentido, como por exemplo se o valor do que você quer realmente é um outro XML, mas no geral isto é feito sem necessidade nenhuma, como é o famoso caso do WebService MS Office dos Correios do Brasil.
Considerar protocolo binário - são muitas as reclamações de que o SOAP acaba sendo um XML grande e pesado para ser transportado. Hoje em dia há muitas formas de contornar isso, como o uso do padrão Fast InfoSet para compressão do XML. Uma outra forma seria o uso de protocolos proprietários, como o AMF da Adobe, que é uma opção comum no uso do Flex.
Considerar não usar WSDL/SOAP - pelas diversas críticas a burocracia exagerada do WSDL/SOAP, muitas pessoas estão optando por usar algo mais simples, como o bom e velho XML (POX), JSON ou até mesmo uma forma qualquer de estruturar dados. Caso você precise de simplicidade e velocidade no desenvolvimento com outras plataformas, essa é uma boa opção. Cuidado: muita gente está considerando qualquer webservice que não use WSDL/SOAP como sendo REST. Os webservices do flickr e da Amazon são um bom exemplo: tudo é via GET (as vezes POST) e não há recurso identificado pela URI. Na verdade ele usa apenas um esquema HTTP+XML (POX), considerado apenas em parte como RESTful. Você pode ver que esses webservices são muito diferentes do modelo RESTful do Atom Publishing Protocol. Criar um protocolo realmente REST como este não é fácil: porém teremos esse trabalho bastante simplificado com a JAX-RS (JSR 311), e já podemos ver isso através do Glassfish Jersey.
Considerar usar JSON - JSON é um formato que tem ganho muita popularidade. Não é a toa: além de ser um simples para debugar, parsear e gerar, com javascript basta fazer um eval em um resultado JSON que ele já estará pronto para usar. É uma excelente opção para o consumo via AJAX e criação de mashups. JSON tem ganho bastante força na comunidade Flex, tornando-o uma ótima opção como ponte entre Flex e Java. A escolha por JSON abre portas para muitos tipos diferentes de clientes, e em especial o browser, que é nossa plataforma global.
Oi Paulo. O evento parece ter sido legal, eh importante disseminar essas mensagens.
Eu so fiquei com o pe(1) atras com relacao ao “Nunca parsear WSDL/SOAP manualmente”. Usar bibliotecas para marshalling (ou data binding) objeto/xml tem varios riscos, pode aumentar o acoplamento entre cliente e servidor e atrapalha a evolucao independente dos servicos. Por exemplo, em .net se vc mapear um enumerated type do xsd para um enum do C#, teu servico vai quebrar quando o xsd for modificado para incluir um caso novo. Um paper meio antigo que toca nesses assuntos eh o do Alpine. (o link pro paper parece quebrado agora).
(1) Ainda tenho que configurar a acentuacao no solaris aqui, foi mal…
Comment by Rafael de F. Ferreira — February 18, 2008 @ 7:10 am
Já conhecia o Paulo através de comunidades como o GUJ e PortalJava, tive a honra de conhecê-lo pessoalmente através deste evento. Sabia da sua competência, mas não sabia que essa sua competência ia além do que eu esperava.
A sua palestra foi excepcional, deixando os participantes vidrados no conteúdo.
Paulo, meus parabéns pela sua competência e espero que você venha mais vezes a Fortaleza.
Um abraço,
Comment by Rafael Carneiro — February 18, 2008 @ 9:41 am
Ponto negativo: induz os novatos a enxergarem o REST e o JSON como o santo graal
Fora isso, as dicas sao boas.
Quanto ao marshalling entre xsd e tipos, em cotnract-first isto é mandatório. Os problemas acontecem quando você usa code-first, e fica modificando os dois modelos: o WSDL e o código que originou o primeiro wsdl
O acoplamento entre cilente e serviço eh o contrato (WSDL), e este deve ser o master mind da coisa toda… parsear wsdl na mão é suicídio..
Comment by Felipe Gaúcho — February 18, 2008 @ 10:19 am
Esse post caiu como uma luva! rsrsrs
Tem uns malukinhos aqui no trabalho que “precisam” lê-lo urgentemente…
Valeu!
Comment by Leandro Silva — February 18, 2008 @ 11:56 am
Oi Rafael. Acho que ai o problema é da sua ferramenta que nao foi boa o suficiente para ja pensar em pequenas modificacoes futuras. E uma alteracao no WSDL é uma quebra de contrato, o que é normal ter de regerar stubs (mas veja que empresas como a amazon lançam um NOVO wsdl, justo pra esse tipo de coisa acontecer).
Felipe, repare que disse apenas para considerar JSON, Rest e o não uso do WSDL/SOAP. Eu também gosto bastante do contrato forte do WSDL, em vez do contrato “boca a boca” dos webservices que não possuem uma interface. Mas é fato que muita das empresas web tem tido melhores experiências e maior adoção com os webservices não-SOAP/WSDL.
Obrigado pelos comentários…
Comment by Paulo Silveira — February 18, 2008 @ 4:23 pm
Nao quero parecer que so estou criticando, Paulo, eu realmente acho que eh super importante passar para o pessoal estes conceitos sobre granularidade e servicos. Falando nisso, um link legal para uma boa descricao desse tipo de coisa, na linha do que vc esta falando.
Agora, voltando a carga :), contract-first nao resolve todos os problemas de acoplamento, nao. Versionamento de servicos eh sempre um problema dificil. Publicar o contrato e nunca mais tocar nele por toda a eternidade eh uma alternativa viavel. Nesse caso, qq evolucao do sistema se dah publicando outra endpoint com outro contrato e esperando que os clientes migrem para ele. Esse tipo de coisa eh o mesmo que se faria com IDLs CORBA e sistemas analogos. Dependendo do alcance do servico vc pode acabar tendo que rodar um monte de versoes paralelamente para nao atrapalhar os clientes legados. A grande vantagem de document-orientation com XML eh que o formato permite a evolucao independente de clientes e servidores (ou seja, acoplamento mais baixo). Nao eh simples, mas eh perfeitamente possivel, veja por exemplo as extensoes do Atom (RFC-4685 eh uma). Os artigos do David Orchard sugerem umas tecnicas para evolucao de schemas.
Agora, nao vejo nenhum impedimento a-priori para que ferramentas de marshalling XML lidem com versionamento de maneira mais sofisticada. Mas, que eu fico com um peh atras, eu fico.
Comment by Rafael de F. Ferreira — February 18, 2008 @ 6:47 pm
Prefiro a liberdade e leveza do JSON… Não gosto de elefantes.
Comment by Tiago Albineli Motta — February 19, 2008 @ 2:20 pm
Não esquecendo do YAML e do HAML, na linha do JSON.
Comment by Fabio Kung — February 20, 2008 @ 12:07 am
Olá Paulo,
Acho que aqui não é o local ideal para falar sobre isso,
mas o VRaptor hoje trabalha só com JSON? ou já tem a possibilidade de utilizar WSDL/SOAP ou outros?
Muito bom o post!! obrigado.
Comment by Germano Fronza — February 20, 2008 @ 6:36 pm
Mate o pequeno XML que existe dentro de voce.
Comment by Antonio Kantek — February 20, 2008 @ 7:25 pm
@Felipe Gaucho
“Ponto negativo: induz os novatos a enxergarem o REST e o JSON como o santo graal”
Apesar que ele não induziu, isso seria o correto, REST já matou o WS-* faz tempo. Poucos player da WEB2.0 se dá ao luxo de não ter seus serviços como REST apesar de que não é apenas JSON.
WS-* é para empresas “Enterprisey” chatas e burocráticas.
REST é para startups jovens e bacanas.
Que lado você está?
Comment by Christiano Milfont — February 21, 2008 @ 8:42 am
[...] blog.caelum.com.br » Os 7 hábitos dos desenvolvedores de WebServices altamente eficazes (tags: blog.caelum.com.br 2008 mes9 dia2 SOA SOAP webservices REST JSON) [...]
Pingback by rascunho » Blog Archive » links for 2008-10-02 — October 2, 2008 @ 7:24 am