soa_
SOA
Mitos e verdades sob uma ótica técnica
Veja alguns mitos e verdades que cercam a
arquitetura de software mais famosa
S
OA é uma realidade. É um estilo arquitetural
muito utilizado em empresas dos mais variados
segmentos, como telecomunicações, financeiro, governamental, bancário, e mesmo em empresas de
internet como Google, Twitter e Facebook. No entanto, 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 arquitetura 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 desenvolvedores e até mesmo arquitetos tornem-se “míopes”,
ao enxergar apenas uma pequena porção da empresa, 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 “orientação” significa focar a aplicação no ponto para a
qual é orientada, então, um único serviço exposto
/ 54
não pode tornar uma aplicação orientada a serviços,
certo? Então, quantos serviços a aplicação deve expor? E como?
Neste artigo, desmistificarei alguns dos mitos
mais comuns encontrados em arquiteturas de mercado, assim como apresentarei alguns termos comumente utilizados em SOA e quais abordagens e ferramentas utilizar em casos específicos.
Mito: REST não faz parte de SOA
Comecemos pelo princípio: o que faz um serviço
ser um serviço? Thomas Erl, em seu livro SOA Principles 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 contrato 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 claramente como utilizar o serviço.
Em REST também há um contrato, porém presente de uma maneira mais sutil: o contrato REST
Alexandre Saudate | [email protected] | @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.
Muito se fala sobre SOA e muitos a usam. No entanto, é comum encontrar equívocos, tanto em termos de implementação quanto conceituais. Este artigo tem como proposta oferecer esclarecimentos a
respeito dessas situações. Quando utilizar um ESB? Quando utilizar BPEL? Quando utilizar SOAP e quando utilizar REST? Como
desenvolver serviços eficientes, reutilizáveis, escaláveis? Você obterá essas e outras respostas aqui.
não é regido por organização nenhuma. o modelo
REST surgiu a partir da tese de doutorado do doutor 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 também entre aplicações, e não apenas para tráfego de
páginas web.
Esta tese deu “corpo” a quatro elementos fundamentais para os serviços REST: a definição correta
de URLs para os recursos (como são chamadas as entidades trafegadas pelo protocolo HTTP, num modelo REST); a definição de quando, e porquê, utilizar os
diferentes verbos HTTP existentes para tratar estes
recursos; como utilizar os headers HTTP para controlar 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,
finalmente, a utilização de hipermídia (ou seja, formatos como JSON e XML) para fornecer os caminhos
a serem seguidos pelo cliente a fim de executar operações similares à que ele se encontra (técnica abreviada como HATEOAS − Hypermedia As The Engine
of Application State).
Vamos analisar o formato de resposta de um serviç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.66302:00</creationDate>
<id>1</id>
<updateDate>2012-12-02T20:20:06.66902: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 definição “formal”
quanto ao que deve ser feito, ainda existe uma noção
de como utilizar REST nas aplicações. Isto acaba oferecendo 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 −
55 \
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, havendo tanto aqueles que concordam que deve ser utilizado 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 podem 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 mapeamentos entre protocolos distintos e para monitorar
o tráfego entre aplicações, com todas as suas implicaçõ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, discutirei 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 Service Bus, por exemplo, possui uma funcionalidade
chamada split-join, que é utilizada para realizar tratamentos 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, formando... 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 tratamentos incluem ler o conteúdo desta mensagem e realizar 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-
/ 56
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 entre dois serviços, ele oferece a capacidade de monitorar 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 maneira que o ESB salva as requisições que chegarem
em excesso no disco. Conforme o serviço subsequente 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 diversos fatores:
»» Adoção de ferramentas open-source ou proprietárias.
»» Facilidade de uso dessas ferramentas, assim
como a qualidade destas.
»» Conhecimento da equipe sobre técnicas e padrõ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 espaço para discussão, já que há muitas ferramentas
open-source excelentes e há muitas ferramentas proprietárias também excelentes. No entanto, também
existem as ferramentas medíocres − sendo que, no
mundo Java, somos familiarizados com isso (quantos 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 proporcionado (o famoso ROI − Return on Investment).
Além disso, geralmente existe necessidade de treinamento 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 proprietá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 ferramentas open-source é que, caso você queira obter treina-
mento, deve confiar em escolas que não pertencem à
própria fabricante.
Quanto à facilidade de uso e qualidade, ferramentas com poucos bugs (não existe software sem bugs,
apenas software com bugs que não percebemos!) nutrem um bom andamento do projeto − consequentemente, 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 menores 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 afora 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 usado a favor de REST.
Vamos aos fatos: SOA não é composto de ferramentas ou tecnologia (tem um lado voltado à análise
e modelagem, mas não à metodologia). SOA é composto de técnicas de desenvolvimento que têm o objetivo comum de flexibilizar uma arquitetura corporativa (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 organizational and technical framework that enables an enterprise 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 habilita 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 melhores práticas, mas não te diz como fazer. Há um
fundo de verdade quando dizem que as implementações atuais, em muitos lugares, tendem a encarar
SOA como o simples uso de ESB, BPEL e outras ferramentas correlatas. Esta definição não poderia estar
mais errada.
SOA, por definição, compartilha alguns dos conceitos 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 afirmar é que existe um subconjunto de características
de SOA que também estão presentes em um subconjunto 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 sistemas: não existe a preocupação na reutilização, apenas 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 necessá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 motivações excusas, como a criação de um modelo para,
depois, vender ferramentas que atendam a esse modelo. 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 qualquer ferramenta − ao contrário, promove a agnosticidade 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. Obviamente, BPEL (Business Process Execution Language)
é muito semelhante, na aparência, a ferramentas de
BPM (Business Process Modeling). No entanto, o formato (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 necessidades que advêm disso); sendo que BPM e correlatos são claramente utilizados para modelar serviços
estratégicos.
Façamos uma revisão de BPEL: BPEL apresenta 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
57 \
outra linguagem). Esta linguagem executa processamentos muito semelhantes ao desenvolvimento de
sistemas em linguagens de programação, com escopos, 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 conferir detalhes de como a modelagem é feita com essa
ferramenta na figura 1.
Figura 1. Exemplo de modelagem no Oracle BPEL. Foto: docs.oracle.com
Já o BPM é definido em termos de uma notação
específica, a BPMN (Business Process Modeling Notation). Essa notação é, claramente, utilizada para trabalhar com interações entre humanos (inclusive, descrevendo 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 automatizadas 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 confundem (principalmente depois que a interação com
/ 58
humanos foi absorvida por WS-*, na especificação
WS-HumanTask). No entanto, mesmo que eles possuam 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 ferramenta 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 entanto, quero apresentar um ponto de vista que, segundo 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 aplicações.
»» Busca de dados binários, como fotos, documentos 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 resolvidos em cenários SOAP+WSDL, e outros são mais
facilmente resolvidos em cenários REST. Vamos estabelecer comparações:
O Single-Sign On
Este problema é razoavelmente fácil de compreender: existe uma autoridade, em algum ponto, que
é considerada confiável tanto pelo provedor do serviç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 importante: o mesmo ticket pode ser utilizado em diversos
serviços distintos, caracterizando o Single-Sign On
(conforme visto na figura 3).
Figura 3. Requisição Single-Sign On.
A WS-Security (e especificações correlatas) resolve este problema de maneira nativa, através de
tokens SAML − Security Assertion Markup Language
e tickets Kerberos. As duas especificações resolvem o
problema de maneiras diferentes − fornecendo, portanto, abordagens distintas. Além disso, é possível
trabalhar com tickets customizados e continuar utilizando a especificação.
Um problema com essa abordagem é recorrente
em praticamente todas as especificações WS-*: é difícil resolver este problema. Existem poucas ou nenhuma 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 confiança.
Em REST, existem duas abordagens distintas
para a resolução do problema: uma, através de headers customizados no HTTP, contendo o ticket ou
token a ser utilizado; ou utilizando a especificaçã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 estabelecer 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úmero de aplicações envolvidas e da burocracia envolvida.
OAuth Authentication Flow
Figura 4. Fluxo de autenticação OAuth. Foto: cloudspace.com
59 \
Além disso, é de senso comum que algoritmos desenvolvidos “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 cenários. Ou seja, headers customizados têm grandes
chances de não apresentarem boa segurança.
Outra abordagem é o uso de OAuth. No entanto, esta especificação não é própria para resolução
do problema de Single Sign-On, pois tem como objetivo um problema diferente. O OAuth foi desenvolvido 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á utilizando 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, utilizando seu login e senha, B envia para A um token de
liberação de dados nestes escopos. Você pode visualizar 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 diferente (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.
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=Sau
date&anoNascimentoInicial=1990&...
Note que este é um problema não somente estético, mas também de limitações no próprio método 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, tornando (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 informaçõ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
Cenários complexos de busca de
à modelagem. Explico: tome como exemplo um algoritmo complexo, multiparâmetros, que também deinformações
Outro problema comum em cenários REST é o tra- volva muitas informações. Para exemplificar, usarei
tamento de queries. Pode parecer estranho, tratando 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 agrupar informações de dois ou mais serviços de crédito.
BPEL versus REST (ou orquestração versus
O log, informando que a consulta foi completada, será
coreografia)
utilizado para cobrar o requisitante das informações.
Em REST, isto poderia ser modelado de várias
BPEL, por definição, implementa o conceito de
maneiras
distintas. A primeira destas maneiras seria
orquestração de serviços, ou seja, de realizar coagrupar
essas
requisições em um serviço unificado,
municação com serviços heterogêneos (seja Java,
que faria essas requisições por si só. Mas, por ser um
.NET etc.). Além disso, o próprio conceito de BPEL
serviço de consulta e seguindo os preceitos de REST,
representa uma máquina de estados persistente,
ele deveria usar GET. No entanto, este serviço gera o
capaz de desfazer e refazer sequências de procedilog, que será utilizado para gerar uma cobrança. Pelo
mentos. Existe ao menos uma contrapartida para
fato de GET ser “idempotente” (ou seja, nenhuma
esse conceito em REST; no entanto, ainda não são
requisição pode alterar o estado do servidor), não é
ferramentas amplamente adotadas e testadas − ao
recomendado que se utilize este método. Se ele utimenos, não no Brasil. Ou seja, na prática, REST
lizar POST, fere os conceitos de REST, por não estar
ainda não tem nenhuma ferramenta de orquescriando nenhum recurso (e isso vale para outros métração, apenas de coreografia − que não persiste
todos HTTP).
estados e tende a realizar comunicação em nível
Estas requisições também poderiam ser feitas sede código, resultado em serviços mais simples.
paradamente pelo cliente. Mas ele poderia burlar a
cobrança, fazendo as requisições de consulta aos ser/ 60
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 possível modelar a consulta em si como um recurso e fazer este serviço ser assíncrono (entrarei em detalhes
sobre esse aspecto mais à frente). Neste caso, o cliente 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 gerenciamento 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 encapsular as chamadas ao serviços de log e realizar as chamadas 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-BusinessActivity). 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.). Neste 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 inesperada 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ários
Considere 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 endereç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 passar os dados numa única requisição contendo MIME
Types diferentes para cada parte envolvida. Através
dessa técnica, o MTOM pode referenciar outra parte 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 trafegados 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 recaindo 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 carregar metadados complexos, que é algo que REST não
conseguiria fazer, já que os metadados teriam que
ser trafegados em headers HTTP. Obviamente, existe 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 tomada 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 metadados simples.
Comunicações assíncronas
Quando uma comunicação assíncrona é estabelecida (em qualquer mecanismo, seja ele qual for), um
remetente deve ser enviado em conjunto com a mensagem, 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 chamado Endpoint Reference, que especifica qual portType 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 entanto, 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 envia61 \
Não apenas as grandes empresas não estão fugindo de SOA, como a adoção tem sido incentivada
por empresas como a Amazon. Em um post do site
highscalability.com (especificamente http://highscalability.com/amazon-architecture), é explicitado o
uso de SOA por parte da Amazon em diversos formatos. O site dodgycoder.net (http://www.dodgycoder.
net/2012/04/scalability-lessons-from-google-youtube.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 componentes 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 ecossistema 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 pelos 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 7. Tendências de emprego com BPEL.
Figura 6. Tendências de empregos com ESB.
Figura 8. Tendências de emprego com REST.
do. No entanto, este header não é padronizado, o que
pode gerar conflitos em empresas dependendo do cenário de utilização de cada um. Além disso, também
não há especificação em relação ao formato de retorno − algo que, obviamente, pode ser mais ou menos
trivial de lidar.
Conclusão: os serviços REST possuem um formato mais simplificado de tratar esta questão; no entanto, sem padronização − o que pode ou não ser um
problema.
Resultado geral
Em 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)
/ 62
No Brasil, a impressão que alguns profissionais
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 cenário ainda tende a evoluir. Gráficos do site indeed.
com, vistos nas figuras 5, 6, 7 e 8 mostram ligeira queda, 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ável
SoA, por si só, não tem por objetivo promover
a escalabilidade. No entanto, algumas técnicas envolvidas acabam promovendo a escalabilidade. Por
exemplo, dentre as técnicas que definem um serviço, está a não-manutenção de estado do mesmo (em
outras palavras: serviços não devem ter estado − invocações sequenciais devem ser independentes de
invocações prévias). Esta técnica acaba promovendo
a arquitetura shared- nothing, que, por definiçã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 fique
sempre associada a um mesmo servidor, por exemplo. ou seja, caso um servidor apresente problemas,
todos os clientes associados ao mesmo também terão
problemas − mesmo que outros clientes acessem corretamente o sistema.
Igualmente problemático é ter sistemas com
compartilhamento de sessão habilitado entre os
nós. Tome uma arquitetura JEE que contenha Stateful 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 fim 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 dados 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 escalabilidade 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 colocados 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 tipos de ferramentas associadas a esta arquitetura. No
entanto, SoA não foi inventada para promover estas
ferramentas, é apenas uma evolução natural da computação como a conhecemos. Analise a linha temporal da figura 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 desafios enfrentados. Reúso através de serviços não fazia o menor sentido 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, daqui 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 serviços foram, sim, muito oportunas. Algumas dessas
ferramentas têm seu uso justificado; outras não. Se
o uso de uma ferramenta é ou não justificado dentro 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 sistemas que precisem ser reutilizados. ou talvez seus sistemas já sejam bem integrados com outras técnicas.
ou os sistemas da empresa sejam um único monolito,
63 \
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 aparecem 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 pontos do código, a refatoração do sistema para concentrar 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 concentrada 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, assim 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, assim é 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á sucesso, já que neste tipo de metodologia, não há espaço para testes de nenhuma natureza. Assim como
desenvolvimento de sistemas, o desenvolvimento de
serviços para estes sistemas também passam por testes.
é considerada em grandes empresas. Obviamente,
muitas vezes realmente não há a necessidade de se
adotar essa técnica; no entanto, também muitas vezes 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écnicas, principalmente por motivos de espaço. No entanto, 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.
/para saber mais
> 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.
/referências
> [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.
Considerações finais
Neste artigo, pudemos contemplar alguns dos
mitos e verdades que rondam a Arquitetura Orientada a Serviços (SOA). Foi possível contemplar qual é o
papel de REST em SOA, quando utilizar WS-* em detrimento 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 empresas, sendo que a adoção de SOA muitas vezes só
/ 64
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/