/ 54

soa_

Veja alguns mitos e verdades que cercam a arquitetura de software mais famosa

Mitos e verdades sob uma ótica técnica

SoA é uma realidade. É um estilo arquitetural muito utilizado em empresas dos mais variados

segmentos, como telecomunicações, financeiro, go-vernamental, bancário, e mesmo em empresas de internet como Google, Twitter e Facebook. No en-tanto, ainda há muita confusão em relação a essas implementações, e até mesmo se o que a empresa está utilizando é SoA ou não.

Não custa lembrar: o que é SOA? SOA significa Arquitetura orientada a Serviços, e como todo termo que utiliza “orientação” coloca algo como centro, SoA coloca serviços como o centro da sua arquitetu-ra de Software. No entanto, a diferença entre SoA e outras arquiteturas é que, na realidade, SoA mira em grandes desafios, ao olhar para a empresa como um todo, e não apenas para um único sistema.

Esse olhar faz com que muitas vezes desenvolve-dores e até mesmo arquitetos tornem-se “míopes”, ao enxergar apenas uma pequena porção da empre-sa, e ignorar o todo. Muitos acabam por considerar que criar um web service e realizar a comunicação desse web service com outros setores da empresa faz com que o sistema seja orientado a serviços − SOA.oras, se um sistema é orientado a serviços, e “orien-tação” significa focar a aplicação no ponto para a qual é orientada, então, um único serviço exposto

não pode tornar uma aplicação orientada a serviços, certo? Então, quantos serviços a aplicação deve ex-por? E como?

Neste artigo, desmistificarei alguns dos mitos mais comuns encontrados em arquiteturas de mer-cado, assim como apresentarei alguns termos comu-mente utilizados em SoA e quais abordagens e ferra-mentas utilizar em casos específicos.

Mito: REST não faz parte de SOAComecemos pelo princípio: o que faz um serviço

ser um serviço? Thomas Erl, em seu livro SoA Princi-ples of Service Design [1], descreve um serviço como algo na qual a orientação a serviços foi aplicada de maneira significativa. A orientação a serviços, por sua vez, é um conjunto de princípios, dentre os quais um dos mais significativos é a presença de um con-trato de serviços padronizado.

Nos modelos mais tradicionais de SoA, o WSDL é, sem sombra de dúvidas, este contrato de serviços. o WSDL é um documento cujo formato é regido pelo World Wide Web Consortium (W3C), e descreve cla-ramente como utilizar o serviço.

Em REST também há um contrato, porém pre-sente de uma maneira mais sutil: o contrato REST

SOASOA

55 \

Muito se fala sobre SOA e muitos a usam. No entanto, é comum en-contrar equívocos, tanto em termos de implementação quanto con-ceituais. Este artigo tem como proposta oferecer esclarecimentos a respeito dessas situações. Quando utilizar um ESB? Quando utili-zar BPEL? Quando utilizar SOAP e quando utilizar REST? Como desenvolver serviços efi cientes, reutilizáveis, escaláveis? Você obte-rá essas e outras respostas aqui.

Alexandre Saudate | alesaudate@gmail.com | @alesaudate Formado em Sistemas de Informação pela USP. Trabalha com SOA e correlatos desde 2008, e é autor do livro “SOA Aplicado:

Integrando com web services e além”, publicado pela Casa do Código.

não é regido por organização nenhuma. o modelo REST surgiu a partir da tese de doutorado do dou-tor Roy Fielding [2], sendo este um dos autores do protocolo HTTP. Como um dos autores do protocolo mais utilizado no mundo, sua ideia claramente era a de promover a utilização correta do protocolo tam-bém entre aplicações, e não apenas para tráfego de páginas web.

Esta tese deu “corpo” a quatro elementos funda-mentais para os serviços REST: a defi nição correta de URLs para os recursos (como são chamadas as en-tidades trafegadas pelo protocolo HTTP, num mode-lo REST); a defi nição de quando, e porquê, utilizar os diferentes verbos HTTP existentes para tratar estes recursos; como utilizar os headers HTTP para con-trolar esta comunicação (por exemplo, os headers Content-Type e Accept para lidar com a tipagem do que está sendo enviado no corpo da requisição); e, fi nalmente, a utilização de hipermídia (ou seja, for-matos como JSON e XML) para fornecer os caminhos a serem seguidos pelo cliente a fi m de executar ope-rações similares à que ele se encontra (técnica abre-viada como HATEOAS − Hypermedia As The Engine of Application State).

Vamos analisar o formato de resposta de um ser-viço REST (utilizando xML):

<people xmlns:ns2=”http://www.w3.org/1999/xlink”> <ns2:link href=”person?page=0” rel=”lastPage”/> <person> <active>true</active> <creationDate>2012-12-02T20:20:05.663- 02:00</creationDate> <id>1</id> <updateDate>2012-12-02T20:20:06.669- 02:00</updateDate> <ns2:link href=”1” rel=”portrait” type=”image/*”/> <ns2:link href=”1” rel=”self”/> <name>Smurf Daddy</name> </person></people>

Note que, apesar de não haver defi nição “formal” quanto ao que deve ser feito, ainda existe uma noção de como utilizar REST nas aplicações. Isto acaba ofe-recendo a chance de descrever clientes dinâmicos, que podem navegar pelos serviços, a partir de uma URL inicial.

ora, este conjunto de informações nada mais é do que um contrato! Muito se especula, ainda, a respeito destas URLs e do formato aceito por elas −

/ 56

e, neste sentido, a resposta que parece convergir é a noção de um WADL [4], ou seja, um contrato gerado dinamicamente para fornecer informações (inclusive xML Schemas) a respeito do que deve ser utilizado como entrada e o que deve ser utilizado como saída dos serviços REST. No entanto, vale notar que o uso do WADL não é consensual entre a comunidade, ha-vendo tanto aqueles que concordam que deve ser uti-lizado quanto aqueles que discordam.

À parte, a discussão sobre usar ou não o WADL, REST ainda possui um contrato, e segue as regras da orientação a serviços − sendo, portanto, um modelo de serviços. Sendo assim, serviços REST também po-dem fazer parte de SoA.

Mito: ESB é a sigla para Enterprise Spaghetti Box

Muito se discute, também, a respeito da utiliza-ção de ESBs, originando inclusive a piada descrita no título deste tópico (tradução: “Caixa de Espaguete Empresarial”). Um fato é que a utilização incorreta, de qualquer ferramenta, leva a verdadeiros pesadelos para qualquer pessoa.

ESB, o Enterprise Service Bus, não foge à regra. No entanto, sua utilização ideal é para realizar mape-amentos entre protocolos distintos e para monitorar o tráfego entre aplicações, com todas as suas impli-cações. Idealmente, o ESB compreende, por si só, um padrão de projeto SoA. Este, por sua vez, compreende diversos padrões de integração (fato que, aliás, discu-tirei no mito “Eu preciso de muitas ferramentas para ter SoA”). Estes padrões podem ser vistos no livro de Gregor Hohpe e Bobby Woolf, Enterprise Integration Patterns [3], ou no site http://eaipatterns.com/.

É fato, muitos usam ESBs para funcionalidades que não lhe compreendem. Situação: o oracle Ser-vice Bus, por exemplo, possui uma funcionalidade chamada split-join, que é utilizada para realizar tra-tamentos complexos de mensagens e para atender, como diz o nome, os padrões Splitter [3] e Aggregator [3]. No entanto, sua utilização remete ao uso de BPEL (visto no mito “BPEL serve para modelar processos de negócio”), o que leva alguns a colocarem as mesmas funções que colocariam em BPEL no próprio ESB, for-mando... bem, um espaguete.

OK, neste caso, para quê serve um ESB?A função do ESB é receber chamadas e realizar

tratamentos em cima das requisições. Estes trata-mentos incluem ler o conteúdo desta mensagem e re-alizar diversas operações, como reescrevê-la (a fim de criar compatibilidade para alguns serviços), realizar roteamentos (uma única invocação a um serviço no ESB pode gerar várias requisições para vários serviços diferentes), realizar tradução entre protocolos (o ESB pode receber uma chamada SoAP e invocar um ser-

viço REST, ou escrever o conteúdo num arquivo CSV) etc.

Além disso, o ESB pode (e deve!) monitorar a saú-de da arquitetura a partir dessas requisições. Se o ESB estiver fazendo o meio de campo na comunicação en-tre dois serviços, ele oferece a capacidade de monito-rar qual tem sido o tempo de resposta das aplicações, qual porcentagem teve falha etc. Dessa maneira, ele elimina (ou reduz) a necessidade de se ter softwares de monitoramento específicos como o Nagios [5].

o ESB também pode atuar preventivamente para impedir que um serviço fique “afogado” em requisi-ções e acabe parando de responder. Essa técnica é conhecida como throttling, e é implementada de ma-neira que o ESB salva as requisições que chegarem em excesso no disco. Conforme o serviço subsequen-te for respondendo, essas requisições são entregues.

Mito: implementar SOA custa muito caro!

Neste caso, existe uma parcela de mito e uma parcela de realidade, variando de acordo com diver-sos fatores:

» Adoção de ferramentas open-source ou pro-prietárias.

» Facilidade de uso dessas ferramentas, assim como a qualidade destas.

» Conhecimento da equipe sobre técnicas e pa-drões SoA.

» Implementação da arquitetura in-house ou terceirizada.

» Conhecimento do negócio. » Burocracias internas da empresa.Quanto à adoção de ferramentas, há muito es-

paço para discussão, já que há muitas ferramentas open-source excelentes e há muitas ferramentas pro-prietárias também excelentes. No entanto, também existem as ferramentas medíocres − sendo que, no mundo Java, somos familiarizados com isso (quan-tos Application Servers você conhece que são bons, e quantos são medíocres?). o diferencial está tanto no custo dessas ferramentas quanto no retorno pro-porcionado (o famoso ROI − Return on Investment). Além disso, geralmente existe necessidade de treina-mento no uso destas e, quanto a isso, existem prós e contras na adoção tanto de ferramentas proprietárias quanto open-source. No caso de ferramentas pro-prietárias, geralmente a própria fabricante oferece treinamentos − que são caros, porém, fáceis de serem agendados e, eventualmente, podem ser oferecidos na própria empresa contratante. Já no caso de open--source, geralmente existem maiores dificuldades em relação a isso. obviamente, existem fabricantes que oferecem cursos (como é o caso da Red Hat, por exemplo) − no entanto, a regra geral para ferramen-tas open-source é que, caso você queira obter treina-

57 \

mento, deve confiar em escolas que não pertencem à própria fabricante.

Quanto à facilidade de uso e qualidade, ferramen-tas com poucos bugs (não existe software sem bugs, apenas software com bugs que não percebemos!) nu-trem um bom andamento do projeto − consequente-mente, menos dinheiro gasto com horas extras. Além disso, ferramentas assim também costumam ser mais fáceis de serem utilizadas − o que se reflete em meno-res custos com treinamento, resolução de problemas etc.

Mito: eu preciso de muitas ferramentas para ter SOA

Esta é, talvez, a maior falácia pregada mundo afo-ra quando falamos de SoA. Muitas pessoas (algumas dessas, inclusive, muito esclarecidas a respeito de tecnologia como um todo) acreditam que, sem ESB, BPEL, BRMS etc., não é possível implementar SoA com sucesso − argumento que, aliás, muitos têm usa-do a favor de REST.

Vamos aos fatos: SoA não é composto de ferra-mentas ou tecnologia (tem um lado voltado à análise e modelagem, mas não à metodologia). SoA é com-posto de técnicas de desenvolvimento que têm o ob-jetivo comum de flexibilizar uma arquitetura corpo-rativa (veja bem: estou falando, aqui, de um conjunto de vários sistemas, e não de apenas um). Segundo Carl August Simon, estudioso do assunto:

“A service-oriented architecture (SOA) is the orga-nizational and technical framework that enables an en-terprise to deliver self-describing, platform-independent business functionality and make it available as building blocks of current and future applications.”

Tradução: uma arquitetura orientada a serviços é um framework organizacional e técnico que habi-lita a empresa a entregar funcionalidades de negó-cio autodescritas e independentes de plataforma, e torná-las disponíveis como blocos de fundação para aplicações correntes e futuras.

Moral da história: SoA apresenta técnicas e me-lhores práticas, mas não te diz como fazer. Há um fundo de verdade quando dizem que as implemen-tações atuais, em muitos lugares, tendem a encarar SoA como o simples uso de ESB, BPEL e outras fer-ramentas correlatas. Esta definição não poderia estar mais errada.

SOA, por definição, compartilha alguns dos con-ceitos de integração pura. No entanto, não cabe dizer que SoA é um modelo de integração, ou que integra-ção contém SOA etc. A única coisa que podemos afir-mar é que existe um subconjunto de características de SoA que também estão presentes em um subcon-junto de características de integração.

Algumas dessas características são, por exemplo, a comunicação entre aplicações distintas, e alguns

Enterprise Integration Patterns bem conhecidos (ver [3]). Estes são, especificamente, adotados pelo ESB, que por si só, representa um design pattern SoA.

No entanto, um ponto em que as duas coisas diferem radicalmente é a abordagem. SoA procura desacoplar ao máximo uma aplicação de outra, para promover APIs que sejam reutilizáveis. Perceba o contraponto em relação à integração pura de siste-mas: não existe a preocupação na reutilização, ape-nas a comunicação pura e simples. onde integração trata de questões com simples comunicação ponto--a-ponto, em SoA existe mais uma preocupação em deixar a API suficientemente flexível. Neste ponto entram, muitas vezes, as ferramentas: nem sempre é possível deixar um sistema compatível com outro sem intervenção externa. ou então, pode ser neces-sário consultar uma sequência de serviços para obter os dados necessários para consumir um determinado serviço.

Por ter essa característica de flexibilização, SOA aborda essas ferramentas externas. Note, no entanto, que essas ferramentas não tiveram origem em moti-vações excusas, como a criação de um modelo para, depois, vender ferramentas que atendam a esse mo-delo. Um exemplo disso é o próprio Thomas Erl, que escreveu um dos catálogos de design patterns SoA, que compreende composição de serviços (BPEL) e disponibilização de serviços (ESB). A empresa que Thomas possui, a SoA Systems, não desenvolve qual-quer ferramenta − ao contrário, promove a agnostici-dade de fornecedor.

As ferramentas tiveram, portanto, fundamenta-ção legítima. Vale lembrar que o uso destas depende, também, de bom senso. Não se usa frameworks em Java (ou qualquer outra linguagem) sem uma motiva-ção legítima − então, por que alguém haveria de usar ferramentas sem sequer ter necessidade de utilizá--las?

Mito: BPEL serve para modelar processos de negócio

Esse é outro erro comumente cometido. obvia-mente, BPEL (Business Process Execution Language) é muito semelhante, na aparência, a ferramentas de BPM (Business Process Modeling). No entanto, o for-mato (e necessidade) difere radicalmente, no sentido de que BPEL é mais adaptado para trabalhar com a pura integração entre serviços (e com todas as neces-sidades que advêm disso); sendo que BPM e correla-tos são claramente utilizados para modelar serviços estratégicos.

Façamos uma revisão de BPEL: BPEL apresen-ta uma linguagem (definida em XML) para que seja possível descrever interações entre serviços através de formatos agnósticos (ou seja, não se comunica apenas com web services Java, ou .NET, ou qualquer

/ 58

outra linguagem). Esta linguagem executa processa-mentos muito semelhantes ao desenvolvimento de sistemas em linguagens de programação, com esco-pos, variáveis, captura e tratamento de falhas etc. ou seja, é uma ferramenta tipicamente adaptada para ser utilizada por desenvolvedores e arquitetos, devendo ser ignorada por áreas de negócios. Você pode con-ferir detalhes de como a modelagem é feita com essa ferramenta na figura 1.

Figura 1. Exemplo de modelagem no Oracle BPEL. Foto: docs.ora-cle.com

Já o BPM é definido em termos de uma notação específica, a BPMN (Business Process Modeling Nota-tion). Essa notação é, claramente, utilizada para tra-balhar com interações entre humanos (inclusive, des-crevendo papéis específicos) e a interação entre eles. Aliás, existem definições específicas para processos descritos utilizando a notação que são automatiza-das e os que não são, sendo chamados de modelos concretos e abstratos, respectivamente. Na figura 2, você confere um exemplo de modelagem feita com o oracle BPM – uma entre várias ferramentas desse segmento.

Figura 2. Modelagem realizada com o Oracle BPM. Foto: docs.oracle.com

Note que o papel do BPM é mais estratégico. Em relação a funcionalidades, efetivamente estas se con-fundem (principalmente depois que a interação com

humanos foi absorvida por WS-*, na especificação WS-HumanTask). No entanto, mesmo que eles pos-suam as mesmas funcionalidades, nota-se (de longe!) que ainda não têm o mesmo propósito. Como quase tudo em TI é uma questão de bom senso: utilize a fer-ramenta certa para a coisa certa.

Mito: Web Services tradicionais são muito difíceis de utilizar. REST é muito melhor.

Neste ponto, existe um fundo de verdade. No en-tanto, quero apresentar um ponto de vista que, se-gundo minha experiência, muitos desenvolvedores não notam.

É fato, WSDLs não são feitos para serem lidos por seres humanos. Sim, são contratos complexos e não há maneiras de facilitar isso no mundo dos web services tradicionais. No entanto, certos desafios são presentes em muitas empresas:

» Utilização de Single-Sign on entre aplicações. » Cenários complexos de busca de informações,

com passagens de vários parâmetros. » Exposição de algoritmos complexos entre apli-

cações. » Busca de dados binários, como fotos, documen-

tos em formatos proprietários etc. » Criação de comunicações assíncronas. Estes desafios certamente não são facilmente

“transponíveis” em qualquer modelo. No entanto, alguns destes problemas são mais facilmente resol-vidos em cenários SoAP+WSDL, e outros são mais facilmente resolvidos em cenários REST. Vamos esta-belecer comparações:

O Single-Sign OnEste problema é razoavelmente fácil de compre-

ender: existe uma autoridade, em algum ponto, que é considerada confiável tanto pelo provedor do ser-viço quanto pelo cliente. Quando o cliente quer fazer uma requisição para o serviço, ele entra em contato primeiro com essa autoridade considerada confiá-vel, para que a mesma emita um token, ou seja, uma informação que identifique aquele cliente perante o serviço, sem revelar, no entanto, usuário/senha, e com tempo de expiração predeterminado. Uma vez obtido esse token, o cliente faz a requisição para o serviço fornecendo o token. o serviço faz, então, a verificação junto à entidade confiável a respeito dos dados que esse token representa − o login do usuário, seu nome, preferências de uso etc. Um ponto impor-tante: o mesmo ticket pode ser utilizado em diversos serviços distintos, caracterizando o Single-Sign on (conforme visto na figura 3).

59 \

Figura 3. Requisição Single-Sign On.

A WS-Security (e especifi cações correlatas) re-solve este problema de maneira nativa, através de tokens SAML − Security Assertion Markup Language e tickets Kerberos. As duas especifi cações resolvem o problema de maneiras diferentes − fornecendo, por-tanto, abordagens distintas. Além disso, é possível

trabalhar com tickets customizados e continuar utili-zando a especifi cação.

Um problema com essa abordagem é recorrente em praticamente todas as especifi cações WS-*: é di-fícil resolver este problema. Existem poucas ou ne-nhuma ferramenta que resolva o problema de forma satisfatória, sendo que a descrição da comunicação deve ser incluída tanto no WSDL quanto nos clientes, serviços e servidor de confi ança.

Em REST, existem duas abordagens distintas para a resolução do problema: uma, através de he-aders customizados no HTTP, contendo o ticket ou token a ser utilizado; ou utilizando a especifi cação oAuth. Problemas existem, no entanto, com ambas as abordagens.

o problema com os headers customizados é que, por eles possuírem essa abordagem customizada, eles não são padronizados. ou seja, deve-se estabele-cer um acordo entre todas as aplicações participantes para que elas possam detectar o header customizado − o que pode ser impraticável, dependendo do núme-ro de aplicações envolvidas e da burocracia envolvida.

Figura 4. Fluxo de autenticação OAuth. Foto: cloudspace.com

OAuth Authentication Flow

/ 60

Além disso, é de senso comum que algoritmos desen-volvidos “em casa” quase sempre não demonstram o mesmo nível de proteção do que algoritmos testados e provados pelo próprio mercado, em diferentes ce-nários. ou seja, headers customizados têm grandes chances de não apresentarem boa segurança.

outra abordagem é o uso de oAuth. No entan-to, esta especificação não é própria para resolução do problema de Single Sign-on, pois tem como ob-jetivo um problema diferente. o oAuth foi desenvol-vido para atender o contexto de aplicações distintas na web − que, portanto, não têm conhecimento umas das outras. A sistematização é distinta: o cliente (ou seja, a pessoa que está operando um browser) deseja autorizar uma aplicação (A) que ele já está utilizan-do para acessar dados de outra aplicação (B) na web. Neste caso, A redireciona este cliente para uma pá-gina de login/senha de B, junto com os escopos que deseja acessar. Se o cliente fizer esta autorização, uti-lizando seu login e senha, B envia para A um token de liberação de dados nestes escopos. Você pode visuali-zar este fluxo na figura 4.

Note que não é um problema de Single Sign-on, já que, para cada aplicação externa que A desejar acessar, deverá ser fornecida uma autenticação dife-rente (ou seja, não é um “único” Sign-on, mas vários).

Conclusão: WS-* fornece mecanismos melhores para trabalhar com cenário de login único em várias aplicações, ainda que seja complexo de ser realizado.

Cenários complexos de busca de informações

outro problema comum em cenários REST é o tra-tamento de queries. Pode parecer estranho, tratando

desta maneira, mas visualize uma simples busca por exemplos em REST. Agora visualize uma busca por exemplos em que o “exemplo” tenha vários campos:

GET /pessoa?nome=Alexandre&sobrenome=Saudate&anoNascimentoInicial=1990&...

Note que este é um problema não somente es-tético, mas também de limitações no próprio méto-do GET. Apesar de não ser um limite oficial, a alguns browsers trabalham com query strings limitadas. Nos tempos de hoje este limite é extremamente alto, tor-nando (talvez) esta preocupação desnecessária. No entanto, vale notar que a mesma limitação também existe em alguns mecanismos de consumo de URLs, de maneira programática. ou seja, este problema pode tanto adicionar um problema estético quanto algo que realmente é motivo de preocupação.

obviamente, outros métodos HTTP podem ser utilizados para consumo de informações − o que, no entanto, descaracterizaria o uso destes métodos HTTP.

Já com SOAP, este problema simplesmente não faz sentido: o método padrão para transporte de in-formações é PoST, que não apresenta estas limita-ções. Ponto para SoAP/WSDL.

Exposição de algoritmos complexos entre aplicações

Costumo comentar com algumas pessoas que REST, apesar de ser simples tecnicamente falando, transfere a complexidade para questões relacionadas à modelagem. Explico: tome como exemplo um algo-ritmo complexo, multiparâmetros, que também de-volva muitas informações. Para exemplificar, usarei um serviço (hipotético) de consulta de informações em órgãos de proteção ao crédito. Esta consulta de informações deve gerar um log de completude, após a solicitação. Além disso, o serviço também deve agru-par informações de dois ou mais serviços de crédito. o log, informando que a consulta foi completada, será utilizado para cobrar o requisitante das informações.

Em REST, isto poderia ser modelado de várias maneiras distintas. A primeira destas maneiras seria agrupar essas requisições em um serviço unificado, que faria essas requisições por si só. Mas, por ser um serviço de consulta e seguindo os preceitos de REST, ele deveria usar GET. No entanto, este serviço gera o log, que será utilizado para gerar uma cobrança. Pelo fato de GET ser “idempotente” (ou seja, nenhuma requisição pode alterar o estado do servidor), não é recomendado que se utilize este método. Se ele uti-lizar PoST, fere os conceitos de REST, por não estar criando nenhum recurso (e isso vale para outros mé-todos HTTP).

Estas requisições também poderiam ser feitas se-paradamente pelo cliente. Mas ele poderia burlar a cobrança, fazendo as requisições de consulta aos ser-

BPEL versus REST (ou orquestração versus coreografia)BPEL, por definição, implementa o conceito de orquestração de serviços, ou seja, de realizar co-municação com serviços heterogêneos (seja Java, .NET etc.). Além disso, o próprio conceito de BPEL representa uma máquina de estados persistente, capaz de desfazer e refazer sequências de procedi-mentos. Existe ao menos uma contrapartida para esse conceito em REST; no entanto, ainda não são ferramentas amplamente adotadas e testadas − ao menos, não no Brasil. ou seja, na prática, REST ainda não tem nenhuma ferramenta de orques-tração, apenas de coreografia − que não persiste estados e tende a realizar comunicação em nível de código, resultado em serviços mais simples.

61 \

viços de proteção e deixando de fazer a criação do log de consultas.

Além disso, note que existe um componente transacional: os dados não podem ser retornados sem a criação do log e, se o log for gerado, o cliente deve obrigatoriamente ter acesso aos dados criados. Para resolver este problema, então, poderia ser pos-sível modelar a consulta em si como um recurso e fa-zer este serviço ser assíncrono (entrarei em detalhes sobre esse aspecto mais à frente). Neste caso, o clien-te criaria uma requisição de consulta em um serviço e receberia o resultado apenas quando tudo estiver concluído. No entanto, ainda corre o risco do geren-ciamento do workflow − tudo deve ser persistido de alguma forma, caso contrário, corre-se o risco de criar o ticket com a requisição do cliente e perder dados. Desta forma, note que foi gerada uma complexidade substancialmente maior para contornar o problema.

No mundo dos web services tradicionais, existem duas formas de resolver o problema: pode-se encap-sular as chamadas ao serviços de log e realizar as cha-madas a essa cápsula, ao invés de ao serviço em si. A questão da geração dos dados poderia ser resolvida, então, utilizando WS-AtomicTransaction (ou WS-Bu-sinessActivity). Assim que a requisição fosse conclu-ída, a transação seria dada como concluída também. Se o cliente não receber os dados, a transação sofre rollback, os logs não são escritos e fim da história.

Neste caso, ainda existe o risco da máquina que estiver executando a operação sofrer algum desastre (falha de hardware, falha da rede elétrica etc.). Nes-te caso, é possível coordenar as atividades utilizando BPEL, que irá salvar todas as operações efetuadas em banco de dados. Neste caso, se qualquer coisa ines-perada acontecer, é possível retomar as atividades do ponto onde elas pararam em um segundo momento, ou mesmo enviar uma requisição para a engine BPEL para refazer a operação.

Tráfego de dados bináriosConsidere um cenário de inclusão de fotos em

um banco de dados. Serviços SoAP endereçam essa questão através da definição de tipos especiais num xML Schema, base64Binary ou hexBinary. Como os nomes indicam, os dados têm que ser codificados em Base64 ou hexadecimal e passados, portanto, como texto. Isso acrescenta um overhead, segundo estudos, de cerca de 33% no tamanho da mensagem.

outras técnicas foram desenvolvidas para en-dereçar essa questão, como Soap with Attachments. No entanto, esta técnica foi preterida em favor de MToM/xoP (Message Transmission optimization Mechanism/xML-binary optmized Packaging). o mecanismo geral dessa técnica consiste em passar os dados binários “separados” da mensagem SoAP (sendo que esta carrega uma referência para os dados

binários). Todos os dados são enviados em uma única requisição HTTP, utilizando uma técnica conhecida como Multipart HTTP. Esta técnica consiste em pas-sar os dados numa única requisição contendo MIME Types diferentes para cada parte envolvida. Através dessa técnica, o MToM pode referenciar outra par-te contida no HTTP sem prejuízos: os dados binários podem ser trafegados em sua forma binária.

Já em REST, os dados sempre podem ser trafega-dos em sua forma “nativa”, ou seja, basta ajustar os MIME Types corretamente e enviar os dados binários, sem envelope.

A escolha entre uma ou outra técnica acaba re-caindo sobre os metadados que podem acompanhar estes dados binários. Utilizar um envelope SoAP pura e simplesmente para trafegar dados binários não compensa, mesmo utilizando MToM. No entanto, ao utilizar esta técnica, o envelope também pode carre-gar metadados complexos, que é algo que REST não conseguiria fazer, já que os metadados teriam que ser trafegados em headers HTTP. obviamente, exis-te sempre a condição de adotar práticas semelhantes ao SOAP, como trafegar os dados binários codificados em XML em um serviço REST − o que não compensa, pelas razões explicitadas acima.

Conclusão: esta é uma decisão que deve ser to-mada com muito cuidado, já que um envelope SoAP pode tornar o tráfego destes dados muito pesado. No entanto, a mensagem SoAP pode carregar tanto os dados binários quanto metadados complexos − em contrapartida ao REST, que pode carregar apenas me-tadados simples.

Comunicações assíncronasQuando uma comunicação assíncrona é estabele-

cida (em qualquer mecanismo, seja ele qual for), um remetente deve ser enviado em conjunto com a men-sagem, para que o destinatário da mensagem saiba para quem responder, quando completar a requisi-ção. Isso é verdade tanto para web services quanto para JMS e outros mecanismos assíncronos.

os web services tradicionais resolvem esta questão através de uma especificação chamada WS--Addressing, que resolve esta questão através da padronização de endereços de web services. Esta padronização envolve a passagem de endereços (em headers SoAP, por exemplo) e um trecho de xML cha-mado Endpoint Reference, que especifica qual port-Type e service (especificados em um WSDL) devem ser invocados no retorno da mensagem. obviamente, um web service deve ser criado para receber o retorno das mensagens.

Em REST, esta questão é mais simples; no en-tanto, não há padronização alguma. Por exemplo, é possível enviar, em um header HTTP, o endereço para o qual o retorno de uma mensagem deve ser envia-

/ 62

do. No entanto, este header não é padronizado, o que pode gerar conflitos em empresas dependendo do ce-nário de utilização de cada um. Além disso, também não há especificação em relação ao formato de retor-no − algo que, obviamente, pode ser mais ou menos trivial de lidar.

Conclusão: os serviços REST possuem um forma-to mais simplificado de tratar esta questão; no en-tanto, sem padronização − o que pode ou não ser um problema.

Resultado geralEm geral, a simplicidade de serviços REST pode

servir para muitos cenários. No entanto, deve-se ter em mente que REST ainda não possui contrapartidas para o que existe em WS-*, devendo ser considerado caso a caso. Há cenários, obviamente, em que REST é melhor do que SoAP, e vice-versa. Há de se ter bom senso em relação à escolha de um em detrimento ao outro.

Mito: grandes empresas estão fugindo de SOA (ou: SOA está morto/morrendo)

Não apenas as grandes empresas não estão fu-gindo de SoA, como a adoção tem sido incentivada por empresas como a Amazon. Em um post do site

highscalability.com (especificamente http://highs-calability.com/amazon-architecture), é explicitado o uso de SoA por parte da Amazon em diversos forma-tos. o site dodgycoder.net (http://www.dodgycoder.net/2012/04/scalability-lessons-from-google-youtu-be.html) resumiu o texto da seguinte forma (tradu-ção livre):

“A arquitetura da Amazon é fracamente acoplada e construída em torno de serviços. SoA deu a eles o isolamento que permitiria construir muitos compo-nentes de software rapidamente e independentes uns dos outros, permitindo lançamento rápido. A aplica-ção que renderiza as páginas web da Amazon.com é um application server. Assim como as aplicações que servem as interfaces de web services, a aplicação de serviço ao consumidor, e a interface de vendas.

Abra seu sistema com APIs e você criará um ecos-sistema em torno da sua aplicação. organização em torno de serviços te dá agilidade − você pode fazer coisas agora em paralelo porque a saída de tudo é um serviço. Proíba acesso direto ao banco de dados pe-los clientes. Isto significa que você pode tornar seu serviço escalável e mais confiável sem envolver seus clientes. Isto é muito parecido com a habilidade do Google de distribuir melhorias independentemente da tecnologia para benefício de todas as aplicações.”

Figura 5. Tendências de empregos com SOA.

Figura 8. Tendências de emprego com REST.

Figura 7. Tendências de emprego com BPEL.

Figura 6. Tendências de empregos com ESB.

63 \

No Brasil, a impressão que alguns profi ssionais têm (este autor incluído) é de que a adoção de SoA ainda é pequena em comparação com países como EUA, Canadá e alguns europeus. No entanto, este ce-nário ainda tende a evoluir. Gráfi cos do site indeed.com, vistos nas fi guras 5, 6, 7 e 8 mostram ligeira que-da, apenas neste ano.

Nota-se que esta queda pode ser atribuída à crise europeia, posto que SoA é um conjunto de técnicas elaborado para “alavancar” negócios − algo que tende a ser mais conservador em tempos de crise. Porém, no geral, nota-se que tem havido uma retomada, ainda que tímida.

Mito: SOA não é escalávelSoA, por si só, não tem por objetivo promover

a escalabilidade. No entanto, algumas técnicas en-volvidas acabam promovendo a escalabilidade. Por exemplo, dentre as técnicas que defi nem um servi-ço, está a não-manutenção de estado do mesmo (em outras palavras: serviços não devem ter estado − in-vocações sequenciais devem ser independentes de invocações prévias). Esta técnica acaba promovendo a arquitetura shared- nothing, que, por defi nição, é uma arquitetura em que nenhum dos nós envolvidos em processamento conversam uns com os outros. Isso faz com que a escalabilidade horizontal (ou seja, através da adição de mais máquinas) seja trivial.

Uma contrapartida a sistemas de arquitetura shared-nothing são alguns Application Servers que, por exemplo, habilitam opções de “sticky sessions”. Isso faz com que uma mesma sessão de usuário fi que sempre associada a um mesmo servidor, por exem-plo. ou seja, caso um servidor apresente problemas, todos os clientes associados ao mesmo também terão problemas − mesmo que outros clientes acessem cor-retamente o sistema.

Igualmente problemático é ter sistemas com compartilhamento de sessão habilitado entre os nós. Tome uma arquitetura JEE que contenha State-ful Session Beans, por exemplo. Nota-se que, a cada cliente novo para um EJB assim, uma nova instância do EJB deve ser criada. Caso ocorra de a requisição do cliente cair em outro nó do sistema, a instância deve ser transferida para o novo nó − onerando a rede.

A intenção de uma arquitetura shared-nothing, portanto, vai evitar estas técnicas a fi m de que uma requisição possa ser atendida por qualquer dos nós do cluster. Note que não é fácil, no entanto, atingir este nível, posto que as instâncias de banco de da-dos também deve ser shared-nothing para que o todo possa ser (sendo que, quando o banco de dados é compartilhado entre os nós, a arquitetura recebe o nome de shared-disk). É mais fácil atingir esse estado com determinados bancos NoSQL, pois alguns (como Cassandra, por exemplo) são independentes de prati-

camente todos os outros nós, fazendo com que a es-calabilidade seja promovida.

Note também que uma arquitetura shared-disk ou shared-nothing também é ideal para uso em cloud computing, razão pela qual temos visto cada vez com mais frequência os dois termos associados. Cloud computing promove a elasticidade no uso de máquinas (mais ou menos máquinas de acordo com a demanda), o que faz com que os sistemas nela colo-cados sejam adequados apenas se tiverem um desses dois tipos de arquitetura, que são ideais para SoA.

Mito: SOA é um termo inventado para “vender”

Um fato: SoA catalisou a venda de diversos ti-pos de ferramentas associadas a esta arquitetura. No entanto, SoA não foi inventada para promover estas ferramentas, é apenas uma evolução natural da com-putação como a conhecemos. Analise a linha tempo-ral da fi gura 9:

Figura 9. Unidades de reúso em software ao longo da história.

Note que o mecanismo de reutilização vai se adaptando conforme o nível dos desafi os enfrenta-dos. Reúso através de serviços não fazia o menor sen-tido nos anos 60. Hoje, não faz o menor sentido ter reúso através de funções (apenas).

o tamanho dos problemas que enfrentamos vai se adaptando conforme o tempo. Provavelmente, da-qui a 40 ou 50 anos teremos algum mecanismo ainda melhor do que serviços para termos reúso de sistemas em nossas empresas. No entanto, hoje, o que temos de mais adequado para isso é o uso de web services (sejam eles WS-* ou REST).

As ferramentas que seguiram a criação dos ser-viços foram, sim, muito oportunas. Algumas dessas ferramentas têm seu uso justifi cado; outras não. Se o uso de uma ferramenta é ou não justifi cado den-tro de uma empresa, cabe à mesma decidir − não ao vendedor.

Verdade: nem todo mundo precisa de SOA

Isso é um fato. SoA é um conjunto de técnicas elaborado para promover reúso de sistemas − e talvez uma empresa seja tão pequena que não tenha siste-mas que precisem ser reutilizados. ou talvez seus sis-temas já sejam bem integrados com outras técnicas. ou os sistemas da empresa sejam um único monolito,

/ 64

que funciona bem e não precisa ser reposto. obviamente, um discurso de vendas não dirá

isso. Mais uma vez, cabe à empresa decidir se precisa de SOA ou não − e, se precisar, também cabe à mesma decidir quais tecnologias utilizar para isso.

Verdade: SOA não dá resultados imediatos

Evidentemente, resultados de reúso não apare-cem imediatamente. Pense num sistema que utilize objetos: se vários módulos de um mesmo sistema orientado a objetos utilizam um mesmo algoritmo, mas este algoritmo está espalhado em diversos pon-tos do código, a refatoração do sistema para con-centrar este algoritmo em um único ponto não dará resultados imediatos, mas o contrário − um ou mais programadores terão necessariamente que perder tempo refatorando os pontos onde este algoritmo é invocado para redirecionar estas chamadas para o ponto em comum. Esta tarefa, mesmo que concen-trada em um único sistema, pode ser extremamente demorada, em termos de dias e até mesmo semanas.

Com SoA não é diferente, sendo que SoA trata de escopos maiores, de integração entre vários sistemas. Obviamente, o resultado visto não será imediato; ao contrário, custará tempo e dinheiro. No entanto, as-sim como refatorações dentro de um mesmo sistema demonstram seus benefícios através da manutenção do mesmo, que se torna mais simples e agradável, as-sim é com empresas que adotam SoA.

Muitos programadores já devem ter visto (assim como você, leitor) empresas que são intolerantes em relação a refatorações em seus sistemas. Para essas empresas, o que importa é apenas a “completude” da tarefa, não importa como (vide “metodologia” Go Horse [6]). Se sua empresa adota esta “metodologia”, não adianta considerar que a adoção de SoA terá su-cesso, já que neste tipo de metodologia, não há es-paço para testes de nenhuma natureza. Assim como desenvolvimento de sistemas, o desenvolvimento de serviços para estes sistemas também passam por tes-tes.

Considerações finais Neste artigo, pudemos contemplar alguns dos

mitos e verdades que rondam a Arquitetura orienta-da a Serviços (SoA). Foi possível contemplar qual é o papel de REST em SoA, quando utilizar WS-* em de-trimento a REST, quando e como utilizar ferramentas como BPEL, BPM e ESB, e assim por diante.

Vimos neste artigo que nem tudo o que parece, em SoA, é. Ainda existem muitos mitos a respeito dessa questão (ver [7]) muitas vezes por pura falta de conhecimento de tomadores de decisões nas em-presas, sendo que a adoção de SoA muitas vezes só

> [1] SOA Principles of Service Design. Thomas Erl. Prentice

Hall, 2007.

> [2] Tese de Roy Fielding sobre REST − http://www.ics.uci.

edu/~fielding/pubs/dissertation/top.htm

> [3] Catálogo de EAI Patterns − http://www.eaipatterns.

com/

> [4] REST em Java: chegou a hora do WADL no JAX-RS? −

http://www.infoq.com/br/news/2012/11/rest-wadl-jaxrs

> [5] Nagios – http://www.nagios.org/

> [6] Go Horse Process − http://www.gohorseprocess.com.

br/

> [7] Os mitos do SOA − http://www.aqueleblogdesoa.com.

br/2009/05/os-mitos-do-soa/

/referências

> Como descrito na minha biografia, eu sou o autor de

um livro chamado “SOA Aplicado: Integrando com web

services e além”, publicado pela Casa do Código. O livro

aborda desde a criação de web services (clássicos e REST)

até temas como BPEL, ESB e Cloud Computing. Tudo de

uma forma prática, onde o leitor tem a exata noção de

como e por que utilizar estas ferramentas.

> O livro pode ser encontrado no site da Casa do Código:

http://www.casadocodigo.com.br/products/livro-soa-web

services.

/para saber mais

é considerada em grandes empresas. obviamente, muitas vezes realmente não há a necessidade de se adotar essa técnica; no entanto, também muitas ve-zes existe a necessidade de adotá-la e isso não é feito por fatores culturais ou mesmo preconceito − não por embasamento técnico.

Este artigo não se propôs a elucidar questões téc-nicas, principalmente por motivos de espaço. No en-tanto, serve para que você, leitor, saiba que muito do que é pregado em conversas com outras pessoas de TI não é verdade. Espero, assim, que possamos diminuir os preconceitos que, infelizmente, ainda circundam SoA no mundo.