Instituto de Gesto em Tecnologia da Informao

Ps Graduao em Estratgias de Arquitetura de Software

Hugo de Sousa Marques

Aumento da escalabilidade com o uso de Service Oriented

Architecture (SOA)

BELO HORIZONTE, MG
2012

Hugo de Sousa Marques

Aumentando escalabilidade com o uso de Service Oriented

Architecture (SOA)

Artigo apresentado ao curso de

Estratgias em Arquitetura de Software do
Instituto de Gesto em Tecnologia da
Informao como como requisito parcial
para obteno do ttulo de Especialista.

BELO HORIZONTE, MG
2012

Aumentando escalabilidade com o uso de Service Oriented

Architecture (SOA)

Hugo de Sousa Marques

Aprovado em: ___/___/___

BANCA EXAMINADORA

_________________________________________________

_________________________________________________

_________________________________________________

Conceito final: ____

Aumentando a escalabilidade com Service Oriented Architecture

(SOA)

Hugo de Sousa Marques

Orientador: Prof. Diovani Merlo

Resumo
Este trabalho apresenta uma introduo aos conceitos de Service Oriented
Archictecture (SOA), entre eles: servios, orientao a servios e princpios de
design de servios. Adicionalmente, so definidos os conceitos de escalabilidade de
software e os principais problemas enfrentados ao se tentar construir sistemas mais
escalveis. Em seguida, realizada uma anlise em cima de diversas tecnologias e
estratgias, entre elas: Shared Nothing Architecture, Event Driven Architecture,
Enterprise Service Bus, SOA Patterns e Cloud Computing, sobre quais os ganhos
que elas trazem para o aumento de escalabilidade e o porqu de SOA se relacionar
com tais mtodos.
Palavras chave: Service Oriented Architecture, SOA Patterns, Infraestrutura
SOA, Escalabilidade.

Abstract
This paper presents an introduction to the concepts of Service Oriented
Archictecture (SOA), including: services, service-orientation and principles of service
design. Additionally, its defined the concepts of software scalability and the main
problems faced when trying to build more scalable systems. Then an analysis is
performed on various technologies and strategies, including: Shared Nothing
Architecture, Event Driven Architecture, Enterprise Service Bus, SOA Patterns and
Cloud Computing, on which gains they bring for increasing scalability and why SOA
relates to such methods.
1

Ps graduando do curso de estratgias em Arquitetura de Software do Instituto de Gesto

em Tecnologia da Informao, turma 2012.1 e aluno da formao Consultor SOA da SOAExpert.
2
Professor do Instituto de Gesto em Tecnologia da Informao da disciplina de Service
Oriented Architecture.

Keywords: Service Oriented Architecture, Scalability, SOA Patterns, SOA

Infrastructure
1 INTRODUO

Com o surgimento da internet, as empresas esto tentando, cada dia mais,

disponibilizar seus negcios aos clientes atravs da rede. Nos ltimos anos, houve
um imenso crescimento desse novo paradigma e, como consequncia, um pesado
investimento para atingi-lo.Uma das estratgias adotadas pelo setor de Tecnologia
da Informao (TI) para auxiliar as companhias no seu crescimento a
decomposio dos sistemas em servios e sua utilizao para viabilizar a integrao
dos diferentes softwares isolados desenvolvidos no incio da computao. Essa
decomposio e interligao permite que diferentes setores utilizem softwares uns
dos outros, evitando assim, a reescrita e duplicao de sistemas.
A flexibilidade o principal combustvel para o crescimento dos negcios
no cenrio atual e ela proporcionada no setor de tecnologia da informao
com a decomposio e interligao dos sistemas (Carter, 2007, p299).

Service Oriented Architecture (SOA) uma srie de princpios e metodologias

para o projeto e desenvolvimento de software na forma de servios interoperveis.
Entre os principais benefcios do uso de SOA, temos: (i) encapsular a complexidade
tecnolgica de integraes entre as mais diferentes plataformas da organizao; (ii)
permitir que a equipe de TI desenvolva servios em alinhamento s expectativas dos
negcios; (iii) oferecer uma melhor produtividade, tanto para a rea de negcios
como para a rea de TI; (iv) segurana e controle de Service Level Agreement
(SLA), e (v) excelente tempo de resposta, melhorando a experincia do usurio final
sobre o software.(SOAExperta, 2012)
Para obter estes benefcios, um bom design de servios se torna essencial.
No entanto, atingir a excelncia no design exige que desenvolvedores e arquitetos
envolvidos em projetos SOA sejam guiados por uma srie de princpios conhecidos
como Princpios de Design de Servios. Segundo Thomas Erl (ERL, 2005), os
princpios so: (i) Contrato de servios padronizado; (ii) Baixo Acoplamento; (iii)
Abstrao; (iv) Reutilizao; (v) Autonomia; (vi) No manter estado; (vii) Habilidade
de poder ser descoberto; (viii) Habilidade de poder ser composto (SAUDATE, 2012,
p15).
Paralelo aos benefcios de SOA, com as redes sociais e softwares utilizados a
nveis globais como eBay, Amazon e Google, h uma preocupao cada vez maior

em como tais sistemas podem dar vazo s requisies e suportar o enorme

crescimento de usurios, por exemplo, a Amazon em 2007 possua cerca de 55
milhes de usurios ativos (HOFFa, 2013). Na engenharia de software, a
capacidade de um sistema se adequar um grande nmero de usurios chamada
de escalabilidade.
Portanto, dado que um dos objetivos de SOA encapsular a complexidade
tecnolgica de TI, este trabalho pretende verificar quais as melhores prticas para
aumentar a escalabilidade de sistemas com o uso de SOA.
Nas sees de 1 a 3 sero apresentados o contexto histrico que culminou no
surgimento de SOA, seus conceitos e os princpios de orientao a servios. A
seguir, na seo 4 ser discutido sobre escalabilidade e os principais problemas
encontrados ao tentar atingi-la. No captulo 5 ser analisada como SOA pode
agregar na resoluo dos problemas descritos anteriormente. Por fim, sero
discutidas as concluses que podem ser obtidas a partir desse estudo.

1 SOA - CONTEXTO HISTRICO

Com a evoluo da economia mundial para um conceito globalizado, as
organizaes comearam a sentir a necessidade de se comunicarem umas com as
outras atravs de seus sistemas de software. Essa necessidade fez com que, no
final da dcada de 90, um paradigma de integrao fosse criado; no entanto, se
mostrou ineficiente, visto que adicionava uma complexidade tecnolgica muito alta e
um grande acoplamento entre os sistemas integrados, gerando um custo que o
tornaria invivel de ser mantido.
Diante de tal cenrio, solues como Eletronic Data Interchange (EDI), que se
baseia na integrao atravs da troca de arquivos e/ou compartilhamento de
tabelas; foram concebidas. Ainda assim, tais solues continuavam agregando um
alto custo e acoplamento aos sistemas, medida que um software conhecia
detalhes tcnicos de outro sem necessidade. A consequncia desses fatores foi o
questionamento dos valores de TI, os cortes de custos e uma presso cada vez
maior por solues de integrao.
Nesta mesma poca surgiu o Enterprise Service Bus (ESB), que viabilizaria
um novo modelo de integrao. O ESB um middleware que implementa os
Enterprise Application Integration (EAI Patterns): uma srie de padres para

integrao de aplicaes, que permite o ESB integrar sistemas construdos em

diferentes linguagens e arquiteturas, provendo uma camada homognea entre esses
sistemas.
Por fim, em meados dos anos 2000, o World Wide Web Consortium (W3C)
recebeu a submisso do protocolo Simple Object Protocol (SOAP) e da Web Service
Description Language (WSDL). Essas especificaes, aliadas ao uso do XML,
viabilizaram o surgimento da gerao de Web Services, compondo os servios que
dariam origem s primeiras implementaes de uma Service Oriented Architecture
(SOA). Junto a estas implementaes comearam a surgir as bases do que seria
futuramente a infraestrutura SOA que viria a facilitar a construo, entrega e
disponibilizao desses servios.[MELO, 2012][SOAEXPERTa, 2012]

2 SOA - CONCEITOS
Segundo Carl August Simon(SIMON, 2005), "Arquitetura Orientada a Servios
(SOA) um framework organizacional e tcnico que permite uma empresa distribuir
suas funcionalidades de negcio, independente de plataforma tecnolgica, como
peas para construo de aplicaes". Alm desse conceito, SOA possui as
seguintes definies, de acordo com grandes nomes existentes no mercado:
"Service Oriented Architecture (SOA) uma arquitetura para construo de
aplicaes de negcio a partir de um conjunto de servios com baixo
acoplamento armazenados em uma 'caixa preta' e orquestrados de forma a
entregar resultados alinhados com os objetivos de negcio de uma
empresa. (IBM, citado por MELO, 2012, p. 8)
um estilo de arquitetura de software cujo princpio fundamental prega que
as funcionalidades implementadas pelas aplicaes devem ser
disponibilizadas na forma de servios. Frequentemente, estes servios so
conectados atravs de um "Barramento de Servios" (Enterprise Service
Bus, em ingls), que disponibiliza interfaces ou contratos, acessveis
atravs de webservices ou outra forma de comunicao entre aplicaes.
(Wikipdia, citado por MELO, 2012, p. 8)
SOA uma forma de tecnologia arquitetural que adere aos princpios de
orientao de servios. Quando realizada atravs do uso de Web Services,
SOA atinge o potencial para suporta e promover estes princpios atravs
dos processos de negcio e automao dos domnios corporativo. (ERL,
2005)

Deve-se salientar, referente citao de Thomas Erl, que o uso de Web

Services no implica uma estratgia SOA. Para que isso ocorra, necessrio seguir
princpios e prticas de orientao a servios, alinhados s expectativas de negcio.

Caso contrrio, o produto final ser apenas uma integrao entre sistemas legados
que no expem o negcio atravs de contratos e servios.
Antes de mencionar sobre esses princpios e prticas, ser feita uma breve
definio sobre servios e orientao a servios nas prximas sees.

3 SERVIOS
Um servio em SOA um componente de software que possui uma forte
relao com o processo de negcio, segundo a Mulesoft (MULESOFT, 2013)
Servios so unidades lgicas auto suficientes que realizam atividades especficas.
Possui uma maior importncia a partir do conceito de orientao a servios, citado a
seguir. Graas a esse conceito, o servio contm uma srie de caractersticas que o
diferenciam de componentes criados com outras abordagens. Algumas dessas
caractersticas so: (i) possuir uma ou mais operaes e ser descrito atravs de um
contrato e (ii) ter a capacidade de utilizar outros servios que se completam na
execuo de uma atividade, se tornando reutilizvel. (ERL, 2005)
O contrato mencionado na primeira caracterstica composto de um ou mais
documentos que descrevem metainformaes sobre o servio. Desses documentos,
o mais importante o que descreve sua interface tcnica, ou seja, sua API e quais
operaes o servio pode prover. Adicionalmente, este contrato pode ser resumido
em uma linguagem mais legvel para o usurio, no formato de SLAs3.

3.1 ORIENTAO A SERVIOS

A orientao a servios tem suas razes na engenharia de software, em uma
teoria conhecida como "Separao de Conceitos" (Separation of Concerns - SoC).
Essa teoria se baseia na vantagem de se separar um problema maior em um
conjunto de problemas menores, permitindo que a lgica necessria para o todo seja
decomposta em solues menores, cada uma especializada em resolver uma parte
do problema. (ERL, 2005)
"A orientao a servios uma abordagem para organizar recursos de TI
distribudos em uma soluo integrada que desmembre silos de informao
e maximize a agilidade dos negcios. A orientao a servios separa os
recursos de TI em mdulos, criando processos de negcios do tipo "loosely
coupled" e que integram informaes entre sistemas de negcios".
(Microsoft, citado por MELO, 2012, p. 8)
3 Service Level Agreement ou acordo de nvel de servio, um acordo firmado entre a rea
de TI e seu cliente interno, que descreve o servio de TI, suas metas de nvel de servio, alm dos
papis e responsabilidades das partes envolvidas no acordo. [WIKIPEDIAb, 2013]

Assim, a orientao a servios pode ser vista como uma implementao da

SoC. O que difere uma da outra, como por exemplo, a Orientao a Objetos, uma
srie de princpios que permitem que as caractersticas de SOA sejam atingidas,
conhecidas como "Princpios do Design de Servios".
Segundo Thomas Erl (ERL, 2005), existem oito princpios de design de
servios, descritos a seguir:

Contrato de servios padronizado: expe a capacidade e o propsito

dos servios atravs de um contrato;

Baixo acomplamento: servios devem ser projetados para interagir sem

a necessidade de acoplamento e dependncia entre eles;

Abstrao: a nica parte exposta do servio deve ser o seu contrato,

ou seja, toda a complexidade deve ser omitida dos seus consumidores;

Reusabilidade: independente de existir oportunidades imediatas para

reuso, os servios devem ser projetados para suportar potenciais
reusos futuros;

Autonomia: a lgica governada por um servio reside em uma fronteira

explcita, onde ele deve ter controle dessa fronteira e no depender de
outros servios;

No manter estados: servios no devem gerenciar estados, devem

ser projetados para se manter sem os mesmos, ainda que deleguem
essa gerncia para outro componente;

Habilidade de poder ser descoberto: servios devem permitir que suas

descries

sejam

descobertas

entendidas

por

humanos

consumidores, de forma que esses possam utiliz-los;

Habilidade de poder ser composto: servios podem ser compostos por

outros servios; essa prtica promove a reusabilidade e a criao de
diferentes camadas de abstrao.

4 ESCALABILIDADE
A escalabilidade a capacidade de um sistema crescer e continuar
atendendo requisies, dado que a carga de acesso ao mesmo aumenta. Um
sistema pode ser escalvel horizontalmente ou verticalmente.

Na escalabilidade horizontal, so adicionados recursos do mesmo tipo, como

por exemplo, servidores. J na vertical, se adiciona recursos no mesmo n ou
mquina, aumentando sua memria ou trocando o servidor, por exemplo.
Existem vantagens e desvantagens em se escolher um modelo. Enquanto na
escalabilidade horizontal se ganha muito mais poder, especialmente com as novas
tecnologias de virtualizao e distribuio, tem-se tambm um modelo de
desenvolvimento mais complexo. J na escalabilidade vertical, o modelo bem mais
simples, porm o alcance se torna mais limitado.
Com o crescimento das tcnicas de sistemas distribudos e com o
surgimentos dos servidores nas nuvens, tem-se adotado amplamente o modelo
horizontal. Essas tcnicas abstraem a complexidade e os custos desse modelo,
tornando-o uma opo mais vivel e escalvel (WIKI, 2013).

4.1 PRINCIPAIS PROBLEMAS

Quando um sistema comea a crescer, podem surgir alguns problemas caso
esse crescimento no seja planejado da melhor forma. A lista abaixo um resumo
da lista original publicada no portal highscalability e traz problemas recorrentes de
escalabilidade de sistemas (HOFF, 2013):

Grande nmero de objetos: quanto mais um sistema cresce, mais

objetos ele tende a carregar em memria, desonerando recursos de
todos os tipos utilizados por eles;

Grande nmero de requisies prioritrias: em um sistema de larga

escala, as requisies prioritrias podem utilizar todos os recursos
disponveis apenas para trat-las, paralisando o restante do sistema;

Grande fluxo de dados: com o aumento do nmero de requisies, h

um acrscimo no tempo de carregamento do sistema. Esse cenrio
tende a piorar medida em que o fluxo cresce;

Aumento do nmero de clientes: com o crescimento do sistema, h um

aumento do nmero de clientes e, consequentemente, da utilizao
dos recursos disponveis. Por exemplo: aumenta o nmero de threads
inicializadas para que eventos possam ser tratados; cresce a memria
alocada para o processamento de filas; mais largura de banda
utilizada para a comunicao entre servidores e consumidores e, por
fim, uma maior quantidade de dados armazenada.

Falta de poder de memria e processamento: com mais objetos,

clientes e dados, a memria e a capacidade de processamento dos
servidores pode no ser suficiente. Alm disso, pequenas perdas de
memria, que em sistemas menores degradam gradativamente a
performance, podem aumentar rapidamente. Isso ocasiona erros por
falta de recursos das mquinas.

Incapacidade de testar grandes configuraes: devido dificuldade de

configurar grandes ambientes, o tempo dedicado a testes mnimo. A
incapacidade de testar o sistema em desenvolvimento produz erros de
design que iro impactar diretamente o escalonamento do sistema.

5 ANLISE DE SOA X ESCALABILIDADE

Diante de tantos problemas com escalabilidade, percebe-se a dificuldade para
se atingir tais objetivos. Conforme visto em sees anteriores SOA possui uma srie
de princpios e uma infraestrutura de apoio que quando bem alocada podem
solucionar vrios desses problemas.
Nesta seo, ser apresentado como a infraestrutura SOA pode oferecer para
a resoluo dos problemas de escalabilidade e por fim um conjunto de design
patterns que visam resolver alguns problemas conhecidos de escalabilidade
seguindo uma estratgia SOA. Associado a estes conceitos esto os princpios de
orientao a servios que viabilizam a utilizao da infraestrutura e aplicao do
patterns SOA.

5.1 INFRAESTRUTURA SOA

SOA no inerente tecnologia ou produtos, mas uma boa infraestrutura
SOA se torna essencial a fim de aumentar sua eficcia e produtividade. Nesta
seo, sero encontrados alguns componentes relacionados essa infraestrutura,
bem como seus conceitos e aplicaes na obteno de escalabidade de software.

5.1.1 Shared Nothing Architecture

Shared Nothing Archictecture (SNA) uma arquitetura de sistemas
distribudos, onde cada nodo independente e auto-suficiente, ou seja, no h
compartilhamento de recursos, como memria e disco, entre diferentes ns.

Um sistema projetado para escalar utilizando esse tipo de arquitetura

normalmente particiona seus dados entre diferentes servidores. Assim, cada n fica
responsvel por interagir com os dados de determinada parte do sistema. Por
exemplo, todas as funcionalidades referentes ao usurio ficariam armazenados em
um nico n, logo no haveria compartilhamento entre os dados de usurio para
outros ns do sistema. A grande vantagem dessa abordagem que o no
compartilhamento de recursos evita a dependncia entre ns, eliminando os pontos
de falha da aplicao. A Figura exemplifica esse estilo arquitetural.

Figura 1 - Exemplo conceitual de arquitetura Shared Nothing (STOPFORD, 2013)

Mas, onde SOA se relaciona com SNA? SNA trata de uma abordagem que
utiliza o baixo acoplamento entre os componentes e, conforme visto na seo 8, um
dos princpios que guia a orientao a servios e, consequentemente, SOA, o
Loose Coupling Services. Dessa forma, utilizando SNA com SOA, tem-se uma
arquitetura onde cada servio seria responsvel por lidar com seus prprios
recursos, sem compartilh-los, minimizando os pontos de falha. Esta estratgia torna
o uso de SNA com SOA uma soluo altamente escalvel horizontalmente.
(OLIVEIRA, 2013)
Uma desvantagem desta abordagem que eventualmente os dados tero
que ser compartilhados. Ento, como tratar um cruzamento de funcionalidades
entre, por exemplo, usurio e conta bancria? Seria necessrio acessar os dados do
usurio e, em seguida, envi-los para os servios responsveis pela conta bancria
para ter o retorno do processamento. Essa comunicao entre diferentes ns
causaria um aumento no trfego da rede.
Por fim, possvel utilizar SNA sem SOA. Porm, o que difere SOA de outros
tipos de aplicao so seus princpios, que prezam pela no manuteno de estado,
evitando sua gerncia e propagao entre os diferentes ns da arquitetura. Essa
abordagem facilita a utilizao de SNA a partir dos princpios de design de servios.

5.1.2 Enterprise Service Bus

O Enterprise Service Bus (ESB) um middleware que age como um canal de
integrao e comunicao entre diferentes plataformas computacionais, conforme
demonstrado na Figura 2. Entre as suas principais responsabilidades, esto
(SOAEXPERTb, 2012):

Monitorar e controlar o roteamento e a troca de mensagens entre

servios;

Realizar transformaes de dados de um formato para outro;

Fazer a traduo entre diferentes protocolos;

Padronizar a camada de segurana e o acesso aos servios.

Figura 2 - ESB como camada de integrao entre diferentes plataformas (SOAEXPERTb, 2012)

Para realizar essa atividades, o ESB implementa os Enterprise Application

Integration (EAI) Patterns, atuando como uma realizao das melhores prticas de
integrao.
Conforme discutido na seo 4.1, quando a demanda pelo sistema comea a
aumentar, o nmero de requisies cresce exigindo maiores recursos da mquina.
Em um cenrio onde o ESB concentra todo o fluxo de entrada e sada do sistema, a
vazo pode ser alta demais, de forma que o barramento no consiga atender todas
as requisies, se tornando um ponto nico de falha (ABEYSINGHE, 2009).
Uma funo essencial para que o ESB evite este problema a capacidade
dele se conectar em um cluster de ESBs. De maneira generalizada, um cluster
uma coleo de mquinas que se comporta como uma nica mquina. Os

integrantes se conectam uns com os outros atravs de redes de alta velocidade e

replicam os recursos de hardware e/ou software entre si. A grande vantagem dessa
tcnica que a falha de uma mquina permite que outro integrante do cluster
assuma o seu trabalho sem que haja impacto perceptvel para o cliente.
Alm do aumento da tolerncia a falha, o cluster permite um crescimento
significativo da performance, pois quando uma requisio chega ao barramento,
algoritmos de load-balacing realizados via software ou hardware distribuem as
requisies para ns mais ociosos, dividindo a carga entre diferentes servidores e
aumentando o tempo de resposta dos ESBs. Adicionalmente, possvel escalar o
cluster simplesmente adicionando novos ns a ele.
Outra opo para ganho de performance e escalabilidade utilizar o ESB
para realizar load-balacing e represamento de requisies. Na primeira tcnica,
possvel disponibilizar um mesmo servio em diversas mquinas; registra-se as
mquinas no ESB e, ao receber uma requisio, o mesmo decide para qual delas
ser enviada. Na segunda abordagem, o ESB age como uma represa, impedindo
que os servidores sejam inundados por requisies; o barramento encaminha aos
servios apenas o nmero mximo permitido para no sobrecarreg-los,
armazenando o fluxo adicional para envio posterior (SOAEXPERTb, 2012).

5.2 EVENT DRIVEN ARCHITECTURE (EDA)

Event Driven Architecture (EDA) um estilo arquitetural para construo de
softwares que produzem, detectam, consomem e reagem a eventos. O evento
uma mudana de estado que ocorre quando algum processo de negcio acionado.
Por exemplo, ao efetuar uma compra gerado um evento que pode ser detectado
por outros sistemas interessados, como o sistema de logstica, de anti-fraude, de
pagamentos, entre outros.
O processamento de eventos simples j era comumente utilizado h alguns
anos com tecnologias como IBM ou Tibco Inc. No entanto, em meados de 2007, a
necessidade de analistas de negcio e arquitetos de lidar com negcios em tempo
real fez o Complex Event Processing (CEP) ganhar bastante notoriedade (SLIWA,
2003, citado por MALEKZADEH, 2010, p. 44). CEP trata do processamento de

mltiplos eventos em grandes volumes para dar a eles significado e ajuda a buscar
padres em eventos aparentemente sem relacionamentos, tomando decises
inteligentes (MALEKZADEH, 2010, p. 44).

O relacionamento entre SOA e EDA ocorre medida que ambos os estilos

arquiteturais promovem o baixo acoplamento. Quando utilizadas em conjunto, SOA
contribui com a incluso dos servios aliados aos objetivos de negcio, enquanto
EDA desacopla tais servios a ponto de um consumidor no saber da existncia de
um produtor. Tal relacionamento entre servios e eventos pode ser visto na Figura 3.

Figura 3 - Relacionamento entre servios e eventos (MALEKZADEH, 2010, p. 54)

A capacidade de escalar sistemas com EDA atingida devido ao total

desacoplamento entre seus componentes. Atravs dos eventos, consumidores e
produtores no conhecem a existncia uns dos outros. Essa estratgia permite que
o sistema permanea funcionando mesmo quando um consumidor ou produtor para
de funcionar.
Essa capacidade de desacoplamento total torna possvel escalar a aplicao
horizontalmente com a simples adio de novos consumidores para dar vazo ao
aumento do fluxo de eventos dos produtores. Toda a garantia de concorrncia e
entrega dessas mensagens pode ser feita atravs de filas de mensageria que
utilizam uma estratgia FIFO4 . O grande problema dessa estratgia que uma
mensagem que j tenha sido obtida pelo consumidor e sinalizada fila pode ser
perdida caso o servidor que o hospede saia do ar, gerando assim um problema de
confiabilidade (FERREIRA, 2013).
Quando alm da escalabilidade for necessrio garantir que mensagens no
sejam perdidas, dois padres podem ser utilizados em conjunto: o padro publishsubscribe permitir que diversos consumidores conheam a mesma mensagem, ou
seja, caso um consumidor interrompa o processamento da mensagem sem finalizlo, ela no ser perdida; j o padro content message routing permite que, baseado
em seus contedos, os eventos sejam distribudos para diferentes filas de
4 Em Cincia da Computao, FIFO (acrnimo para First In, First Out, que em portugus
significa primeiro a entrar, primeiro a sair) refere-se a estruturas de dados do tipo fila. Tem uma
estrutura diferente da estrutura de uma LIFO (que significa Last In, First Out, as pilhas). (WIKIPEDIA,
2013)

mensageria. Assim, poderiam ser criados grupos que ficariam responsveis por
tratar somente eventos de determinado tipo, evitando que a memria dos servidores
seja utilizada com todos os eventos recebidos (FERREIRA, 2013).

5.3 SOA Patterns

Ao decidir utilizar uma estratgia SOA, abre-se um leque de novas
possibilidades e tcnicas para tratar de problemas j conhecidos, como por exemplo,
tornar o software altamente escalvel. SOA possui uma srie de design patterns,
solues recorrentes para problemas igualmente recorrentes, que tratam de resolver
situaes que envolvem o aumento de escalabilidade. Os patterns descrito nesta
seo demonstram como SOA pode ser utilizada como soluo para essas
situaes.

5.3.1 Service Grid Pattern

Uma boa estratgia para lidar com o aumento do volume de trfego
armazenar dados idempotentes em memria, minimizando o nmero de acesso ao
banco de dados e, consequentemente, aumentando a performance da aplicao.
Porm, caso o servidor de cache pare, os dados em memria so perdidos,
tornando-o um ponto nico de falha.
O Service Grid Pattern prov uma soluo elegante para esse problema,
armazenando o cache da aplicao em um grid distribudo que o replica entre todos
os seus ns. Caso um desses falhe e no possa atender a requisio, outro
integrante do grid toma seu lugar, aumentando a disponibilidade da aplicao
medida que ela se torna mais resistente a falhas (Figura 4).

Figura 4 Service grid replicando dados entre diferentes servidores (ERL, 2009).

O princpio de Service Stateless se relaciona diretamente com esse padro: o

servio atende diversas requisies e consulta o grid para obter dados
armazenados, independente do cliente que fez a requisio, aumentando assim a
vazo dos dados.

5.3.2 Decoupled Invocation Pattern

Um servio recebe determinado nmero de requisies e consegue atendlas. Porm, em determinados momentos, como uma promoo relmpago, por
exemplo, o servio sobrecarregado com uma taxa muita alta de requests e no
consegue processar as requisies a tempo de respond-las.
O Decoupled Invocation Pattern se prope a resolver esse problema,
separando a lgica de request e response: um handler recebe a requisio e sinaliza
para o sender que a mesma foi recebida com sucesso; uma vez recebida, faz os
primeiros tratamentos e cadastra a requisio em uma fila de entrada. O servio
responsvel pela lgica de negcio vai consumindo essa fila em sua prpria vazo,
fazendo com que a fila aja como uma represa, segurando o fluxo e impedindo que o
servio se afogue com um nmero excessivo de requisies (Figura 5) (ROTEM
GAL-OZ, 2012).

Figura 5 - Arquitetura conceitual do Decoupled Invocation Pattern (ROTEM GAL-OZ, 2012).

O processo de insero nas filas tem um custo baixo e a leitura das mesmas
pode ser feita utilizando load-balacing com diversos leitores distribuindo a carga
entre si. Esse padro se relaciona com os princpios de Service Abstraction e
Service Autonomy, pois alm de lidar com seus prprios recursos, os consumidores
no precisam ter conhecimento da arquitetura encapsulada pelo servio.

O Decoupled Invocation Pattern apropriado para picos de trfego. Porm,

se esses picos se mantiverem durante longos perodos de tempo, ser necessrio
viabilizar outras estratgias, como as abordadas nos itens a seguir.

5.3.3 Parallel Pipelines Pattern

Um determinado processo de negcio tem um fluxo que passa por diversas
fases como validao, deteco de fraude, autorizao e finalizao. Alguns
problemas so a quantidade de passos do fluxo e possveis chamadas a
componentes externos. Como garantir que o fluxo d vazo a quantidades cada vez
mais crescentes de requisies e que ele ainda seja testvel e escalvel?
Uma abordagem seria utilizar o Parallel Pipelines Pattern, que se baseia no
estilo de arquitetura Pipe and Filters. Esse princpio divide o problema em pedaos
que se conectam formando um fluxo; logo a requisio enviada para cada
componente que faz um processamento e, aps termin-lo, passa para o seguinte;
ao final do fluxo, a requisio retornada. Esse processo descrito na Figura 6.

Figura 6 - Fluxo do Parallel Pipelines Pattern (ROTEM GAL-OZ, 2012)

O padro descrito anteriormente possui as seguintes vantagens: (i)

relativamente fcil de implementar; (ii) cada componente se torna muito fcil de
testar, pois age independente dos demais e (iii) para escalar a soluo, se distribui o
pipeline em diferentes servidores e, preferencialmente, cada componente em seu
prprio servidor. Por fim, o desafio est em conseguir dividir o problema de forma
que os componentes fiquem independentes (ROTEM GAL-OZ, 2012).
O princpio de Loose Coupling est fortemente relacionado a esse padro,
pois cada componente dever ser independente dos demais. Alm desse, o princpio

de Service Composition tem papel fundamental, pois embora independentes, os

servios devem ser orquestrados de forma que consigam processar o fluxo, ou seja,
devem se compor para formar novos servios.

5.3.4 Service Instance Pattern

Em uma grande promoo, por exemplo, uma grande carga de requisies
feita ao mdulo de validaes e fraudes. Como escalar o sistema para atender s
requisies?
O Service Instance Pattern define a estratgia de criar novas instncias do
servio. Por seguirem o princpio de Service Stateless, mais servios conseguem dar
vazo a novas requisies. Aliando essa estratgia ao uso do ESB (item 5.1.2),
possvel que ele faa o papel de dispatcher, realizando o load-balacing entre as
novas instncias dos servios (Figura 7) (ROTEM GAL-OZ, 2012).

Figura 7 - Arquitetura conceitual do Service Instance Pattern (ROTEM GAL-OZ, 2012).

5.4 CLOUD COMPUTING

Cloud computing o uso dos recursos de computao que so
disponibilizados como servios atravs de uma rede, usualmente a internet. Nos
ltimos anos, essa tcnica tem crescido muito em adoo pelas grandes
companhias, devido uma srie de vantagens (BOWEN, 2013):

Reduo de custos de investimentos: no mais necessrio investir

em datacenters ou na infraestrutura de TI, j que os servios nas

nuvens disponibilizam todo esse aparato pronto e a um custo

competitivo;

Aumento

de

disponibilidade

confiabilidade:

infraestrutura

disponibilizada nas nuvens tende a ser mais robusta, pois os

provedores de cloud computing possuem servidores de redundncia e
mecanismo para recuperao automtica de falha;

Aumento de escalabilidade: alm de toda a infraestrutura citada

anteriormente,

os

provedores

de

cloud

ainda

trabalham

com

datacenters imensos, utilizando-se de tecnologia de grids e com

crescimento elstico, ou seja, medida que a aplicao demanda por
recursos, o provedor os fornece para ela. Todo esse conjunto de
funcionalidades faz aplicaes disponibilizadas na nuvem altamente
escalveis.
Dessa forma, percebe-se a relao direta entre cloud computing e
escalabilidade de software. Mas, qual a relao entre cloud computing e SOA?
Segundo Jerry Cuomo (BOWEN, 2013), CTO da IBM's Websphere Business, SOA
um estilo arquitetural para construir aplicaes desacopladas e que permitam
composio. possvel construir uma infraestrutura de um datacenter utilizando os
princpios SOA, e isto seria cloud computing, ou seja, infraestrutura orientada a
servios.
Portanto, embora ambas partam de conceitos diferentes, sendo cloud computing
infraestrutura, e SOA estratgia para construo de aplicaes atravs de servios,
ainda assim, cloud computing entrega suas funcionalidades por meio desses
servios. Ou seja, o uso dos princpios de orientao a servios facilita a
disponibilizao das funcionalidades entregues pela cloud computing.

6 ANLISE DOS RESULTADOS

A partir das tcnicas apresentadas nas sees anteriores podemos sintetizar
os resultados classificando-os acordo com os seguintes critrios: (i) Relacionamento
com SOA; (ii) Princpios de SOA que viabilizam o uso da tcnica; (iii) Vantagens de
sua adoo; (iv) Tipo de escalabilidade permitida pela tcnica.
A sntese dessa anlise est descrita na tabela 1.

Relao com SOA

Princpios de SOA

Vantagens

Baixo Acoplamento,

Baixssimo

Abstrao,

acoplamento

produtores.

Habilidade de poder

permite escalar o

Servios proveem o

ser composto

sistema.

Os

servios

se

tornam
consumidores

EDA

Escalabilidade

Horizontal

valor de negcio.
Shared-Nothing

Cada

servio

Architecture

torna

responsvel

por

se

determinadas

Autonomia,

Baixo

No

Horizontal

acoplamento,

compartilhamento

Abstrao.

de

recursos

funcionalidades,

aumenta o poder

dessa forma, no

de

aplicao.

escalar

compartilhamento
de recursos entre
diferentes servios.
Enterprise

Service

Bus

Pilar

da

Baixo acoplamento,

Cluster de ESBs,

Vertical

infraestrutura SOA,

Abstrao, Contrato

Load

Horizontal

facilita a integrao

de

Represamento

entre

padronizado.

diferentes

servios

Balacing,

protocolos
promovendo
tambm um baixo
acoplamento

entre

clientes e servios.
Service

Grid

Pattern

Padro

de

Abstrao

Reduz

ponto

escalabilidade

nico

de

falha

SOA.

mantendo

um

cache

em

diferentes

ns

Horizontal

aumentando
disponibilidade.
Decoupled

Padro

de

Abstrao

Permite

atender

Invocation Pattern

escalabilidade

uma

alta

SOA.

demanda

em

Horizontal

picos de acesso.
Parallel
Pattern

Pipeline

Padro

de

Baixo Acoplamento,

Fraciona

escalabilidade

Habilidade de poder

demanda

SOA.

ser composto.

manter

processamento

Horizontal

mesmo

quando

um

sistema

externo no est
disponvel.
Service

Instance

Pattern

Padro

de

Abstrao

Aumenta a vazo

escalabilidade

com

que

as

SOA.

requisies

so

Horizontal

processadas.
Cloud Computing

SOA

facilita

Baixo Acoplamento,

Maior

Horizontal

distribuio

dos

Abstrao,

infraestrutura dos

servios

nas

Autonomia,

ambientes

Habilidade de poder

nuvens que vai

ser descoberto.

permitir

nuvens.

nas
uma

maior
disponibilidade e
escalabilidade.
Tabela 1 Tabela de sintaxe dos resultados

7 CONCLUSO
Diante do estudo apresentado, percebe-se que SOA possui um arcabouo de
princpios e tecnologias que promovem uma facilidade na busca por sistemas mais
escalveis. Estilos arquiteturais como EDA tem uma forte relao com SOA e so
altamente escalveis por trabalharem com um altssimo desacoplamento entre seus
componentes. Tecnologias e padres de infraestrutura como Cloud Computing e
Shared Nothing Architecture so utilizados por diversos tipos de aplicao, mas
conforme foi analisado, possuem uma srie de sinergias com SOA que facilitam a
sua implantao e utilizao. Alm disso, SOA possui diversos patterns que
resolvem problemas comuns de escalabilidade, alm do Enterprise Service Bus, que
abstrai a complexidade tcnica das solues mencionadas acima.
Todo esse estudo pode ser validado pelo relato da Amazon conforme descrito
no Apendice I (HOFFa, 2013), que demonstra como o uso de SOA pode escalar
uma aplicao a nveis de uso mundial. Conclui-se, dessa forma, que SOA pode
auxiliar o aumento de escalabilidade de software, no sendo a nica estratgia que
aborda o problema, mas certamente uma abordagem vlida e til, que se preocupa
em manter o valor de negcio.

8 REFERNCIAS
8.1 LIVROS E APOSTILAS
CARTER, Sandy. The new language of business: SOA and WEB 2.0
Crawfordsville: Pearson Education, Inc, 2007, p299.
ERL, Thomas. Service Oriented Architecture: Concepts, Technology and
Design. CrawsfordVille: Prentice Hall, 2005.
ERL, Thomas. SOA Design Patterns. Prentice Hall, 2009.
MELO, Diovani. Service Oriented Architecture. Instituto de Gesto em
Tecnologia da Informao. 2012. p6-60
ROTEM GAL-OZ, Arnon. SOA Patterns. Manning Publications Co. 2012. ISBN
9781933988269
SAUDATE, Alexandre. SOA Aplicado: Integrando com Web Services e alm.
Casa do Cdigo, 2012.
SOAEXPERTa, SOA Foundation: Classic and Next Generation, SOA|Expert.
2012.
SOAEXPERTb, Enterprise Service Bus: Integration Specialist, SOA|Expert,
2012.

8.2 DISSERTAES E TESES

MALEKZADEH, Behrooz. Event-Driven Architecture and SOA in collaboration:
A study of how Event-Driven Architecture (EDA) interacts and functions within
Service-Oriented Architecture (SOA). University of Gothenburg. 2010. p. 44-50

MATOS, Jonathan. Distribuio de carga flexvel e dinmica para provedores

de Web Services. USP, So Carlos, Maro de 2009.

8.3 ARTIGOS DA INTERNET

ABEYSINGHE,

Samisa.

Scalable

SOA

[Projeo

visual].

2009.

62

diapositivos: color. Acessvel em: http://www.slideshare.net/wso2.org/scalable-soa

AMAZON, Inside Amazon, Disponvel em: <http://www.amazon.com/InsideCareers-Homepage/b?ie=UTF8&node=239367011> Acesso em 14 Out. 2012
ARCITURA EDUCATION INC, Service Orientation Principles. Acessado em:
02

de

Maro

de

2013.

Disponvel

em:

http://serviceorientation.com/serviceorientation/index
BOWEN, Filmore. How SOA can ease your move to cloud computing.
Acessado

em

24

de

Maro

de

2013.

Disponvel

em:

http://www-

01.ibm.com/software/solutions/soa/newsletter/nov09/article_soaandcloud.html
FERREIRA, Ricardo. Creating Scalable Fast Data Applications using Oracle
Event Processing Platform (Setting Up an Active-Active Oracle CEP Domain).
Acessado

em

28

de

Maro

de

2013.

Disponvel

em:

https://blogs.oracle.com/middlewareplace/entry/implementing_distributed_processing
_of_events
HOFF, Todd. Amazon Architecture. Acessado em 24 de Maro de 2013.
Disponvel em: http://highscalability.com/amazon-architecture
HOFF, Todd. 42 Monster Problems That Attack As Loads Increase. Acessado
em:

17

de

Maro

de

2013.

Disponvel

em:

http://highscalability.com/blog/2013/2/27/42-monster-problems-that-attack-as-loadsincrease.html

MULESOFT, Services in SOA. Acessado em 28 de Maro de 2013.

Disponvel em: http://www.mulesoft.com/resources/esb/services-in-soa
OLIVEIRAa, Felipe. Think Decoupled [Projeo visual]. 2011. 58 diapositivos:
Color. Acessvel em: http://www.slideshare.net/netarchitects/04-felipe-oliveira-thinkdecoupled-soa
OLIVEIRAb, Felipe. Escalabilidade com Arquiteturas SOA. Acessado em 7 de
Janeiro

de

2013.

Disponvel

em:

http://soacloud.com.br/discussion/comment/171/#Comment_171
SIMON, Carl August. Killer SOA Definition. 2005. Acessado em 28 de Maro
de 2013. Disponvel em http://carlaugustsimon.blogspot.com.br/2005/09/killer-soadefinition.html
STOPFORD, Benjamin. Shared Nothing v.s. Shared Disk Architectures: An
Independent View. Acessado em 17 de Maro de 2013. Disponvel em:
http://www.benstopford.com/2009/11/24/understanding-the-shared-nothingarchitecture/
WIKI, Phillip. Scaling Service Oriented Architecture: A look at how Oracle
solutions fit into a scalable Service Oriented Architecture. Acessado em: 10 de Maro
de 2013. Disponvel em: http://www.oracle.com/technetwork/articles/soa/wik-soascaling-1738196.html
WIKIPEDIA, Service-oriented Architecture. Acessado em: 02 de Maro de
2013. Disponvel em: http://en.wikipedia.org/wiki/Service-oriented_architecture
Wikipediab, Acordo de nvel de servio. Acessado em 28 de Maro de 2013.
Disponvel

em:

http://pt.wikipedia.org/wiki/Acordo_de_n%C3%ADvel_de_servio

APENDICE I: ESTUDO DE CASO: AMAZON

A Amazon cresceu de uma pequena loja de livros para uma das maiores lojas
do mundo. Segundo o artigo Amazon Architecture, ela possua 55 milhes de
usurios com conta ativa e mais de 1 milho de parceiros, alm de cerca de 100 a
150 servios utilizados para acessar uma pgina.
O grande passo para tal crescimento foi sair de uma aplicao cliente-servidor
para uma totalmente descentralizada, construda em cima de servios que atendem
diversas aplicaes diferentes. Inicialmente, o sistema era composto de um nico
cliente se comunicando com um backend escrito em C++. A aplicao cresceu e,
durante muito tempo, os esforos dos engenheiros foram em escalar o backend e a
base de dados para suportar mais clientes, mais vendas, mais fornecedores, at o
momento em que a aplicao no podia mais escalar.
Uma nova abordagem foi tomada e o banco de dados dividido em um
conjunto de bancos menores. Porm, por esses recursos serem compartilhados
entre diferentes tempos e processos, a evoluo do sistema ficou restrita. Em um
dado momento, o sistema foi dividido em centenas de servios com alguns
servidores de aplicao mediando a comunicao entre eles.
Os servios so unidades independentes que entregam funcionalidades na
Amazon, e atravs deles que a empresa organizada. Sempre que surge uma
nova necessidade de negcio, um time de 8 a 10 pessoas formado, ficando
responsvel por criar um novo servio que atenda quela necessidade.
Diante de todas essas mudanas, houve uma srie de lies aprendidas ao
sair de uma aplicao pequena e monoltica para um sistema amplamente escalvel
e mundialmente acessada.
You must change your mentality to build really scalable systems.
Approach chaos in a probabilistic sense that things will work well. In
traditional systems we present a perfect world where nothing goes down and
then we build complex algorithms (agreement technologies) on this perfect
world. Instead, take it for granted stuff fails, that's reality, embrace it. For
example, go more with a fast reboot and fast recover approach. With a
decent spread of data and services you might get close to 100%. Create
self-healing, self-organizing lights out operations. Greg Linden, Amazon
Engineer

Uma das tcnicas adotadas foi o uso de uma Shared Nothing Architecture,
pois recursos compartilhados podem causar deadlocks. O uso de uma arquitetura
orientada a servios aliada SNA permite a criao de servios isolados que

escalam de maneira que comportem a demanda necessria ao negcio. Outras

lies da arquitetura da Amazon incluem: (i) exponha suas APIs e um ecossistema
ser criado ao redor de sua aplicao; (ii) torne as coisas to simples quanto
possveis, evitando requisitos e dependncias desnecessrias no seu design; (iii)
evite utilizar camadas de complexidade desnecessria para resolver o problema e,
por fim, (iv) organizar o negcio ao redor dos servios oferece agilidade.