Embed Size (px)
DESCRIPTION
Trabalho de conclusão de curso apresentado ao IGTI-BH, o objetivo é explorar conceitos e técnicas relacionadas ao uso de SOA que irão permitir um aumento de escalabilidade na aplicação.
Citation preview
Instituto de Gestão em Tecnologia da Informação
Pós Graduação em Estratégias 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
Estratégias em Arquitetura de Software do
Instituto de Gestão em Tecnologia da
Informação como como requisito parcial
para obtenção do título 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 Marques1
Orientador: Prof. Diovani Merlo2
Resumo Este trabalho apresenta uma introdução aos conceitos de Service Oriented
Archictecture (SOA), entre eles: serviços, orientação a serviços e princípios de
design de serviços. Adicionalmente, são definidos os conceitos de escalabilidade de
software e os principais problemas enfrentados ao se tentar construir sistemas mais
escaláveis. Em seguida, é realizada uma análise em cima de diversas tecnologias e
estratégias, 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 métodos.
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, it’s 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 Pós graduando do curso de estratégias em Arquitetura de Software do Instituto de Gestão
em Tecnologia da Informação, turma 2012.1 e aluno da formação Consultor SOA da SOAExpert. 2 Professor do Instituto de Gestão em Tecnologia da Informação da disciplina de Service
Oriented Architecture.
Keywords: Service Oriented Architecture, Scalability, SOA Patterns, SOA
Infrastructure
1 INTRODUÇÃO
Com o surgimento da internet, as empresas estão tentando, cada dia mais,
disponibilizar seus negócios aos clientes através da rede. Nos últimos anos, houve
um imenso crescimento desse novo paradigma e, como consequência, um pesado
investimento para atingi-lo.Uma das estratégias adotadas pelo setor de Tecnologia
da Informação (TI) para auxiliar as companhias no seu crescimento é a
decomposição dos sistemas em serviços e sua utilização para viabilizar a integração
dos diferentes softwares isolados desenvolvidos no início da computação. Essa
decomposição e interligação permite que diferentes setores utilizem softwares uns
dos outros, evitando assim, a reescrita e duplicação de sistemas. “A flexibilidade é o principal combustível para o crescimento dos negócios no cenário atual e ela é proporcionada no setor de tecnologia da informação com a decomposição e interligação dos sistemas” (Carter, 2007, p299).
Service Oriented Architecture (SOA) é uma série de princípios e metodologias
para o projeto e desenvolvimento de software na forma de serviços interoperáveis.
Entre os principais benefícios do uso de SOA, temos: (i) encapsular a complexidade
tecnológica de integrações entre as mais diferentes plataformas da organização; (ii)
permitir que a equipe de TI desenvolva serviços em alinhamento às expectativas dos
negócios; (iii) oferecer uma melhor produtividade, tanto para a área de negócios
como para a área de TI; (iv) segurança e controle de Service Level Agreement
(SLA), e (v) excelente tempo de resposta, melhorando a experiência do usuário final
sobre o software.(SOAExperta, 2012)
Para obter estes benefícios, um bom design de serviços se torna essencial.
No entanto, atingir a excelência no design exige que desenvolvedores e arquitetos
envolvidos em projetos SOA sejam guiados por uma série de princípios conhecidos
como Princípios de Design de Serviços. Segundo Thomas Erl (ERL, 2005), os
princípios são: (i) Contrato de serviços padronizado; (ii) Baixo Acoplamento; (iii)
Abstração; (iv) Reutilização; (v) Autonomia; (vi) Não manter estado; (vii) Habilidade
de poder ser descoberto; (viii) Habilidade de poder ser composto (SAUDATE, 2012,
p15).
Paralelo aos benefícios de SOA, com as redes sociais e softwares utilizados a
níveis globais como eBay, Amazon e Google, há uma preocupação cada vez maior
em como tais sistemas podem dar vazão às requisições e suportar o enorme
crescimento de usuários, por exemplo, a Amazon em 2007 possuía cerca de 55
milhões de usuários ativos (HOFFa, 2013). Na engenharia de software, a
capacidade de um sistema se adequar à um grande número de usuários é chamada
de escalabilidade.
Portanto, dado que um dos objetivos de SOA é encapsular a complexidade
tecnológica de TI, este trabalho pretende verificar quais as melhores práticas para
aumentar a escalabilidade de sistemas com o uso de SOA.
Nas seções de 1 a 3 serão apresentados o contexto histórico que culminou no
surgimento de SOA, seus conceitos e os princípios de orientação a serviços. A
seguir, na seção 4 será discutido sobre escalabilidade e os principais problemas
encontrados ao tentar atingi-la. No capítulo 5 será analisada como SOA pode
agregar na resolução dos problemas descritos anteriormente. Por fim, serão
discutidas as conclusões que podem ser obtidas a partir desse estudo.
1 SOA - CONTEXTO HISTÓRICO Com a evolução da economia mundial para um conceito globalizado, as
organizações começaram a sentir a necessidade de se comunicarem umas com as
outras através de seus sistemas de software. Essa necessidade fez com que, no
final da década de 90, um paradigma de integração fosse criado; no entanto, se
mostrou ineficiente, visto que adicionava uma complexidade tecnológica muito alta e
um grande acoplamento entre os sistemas integrados, gerando um custo que o
tornaria inviável de ser mantido.
Diante de tal cenário, soluções como Eletronic Data Interchange (EDI), que se
baseia na integração através da troca de arquivos e/ou compartilhamento de
tabelas; foram concebidas. Ainda assim, tais soluções continuavam agregando um
alto custo e acoplamento aos sistemas, à medida que um software conhecia
detalhes técnicos de outro sem necessidade. A consequência desses fatores foi o
questionamento dos valores de TI, os cortes de custos e uma pressão cada vez
maior por soluções de integração.
Nesta mesma época surgiu o Enterprise Service Bus (ESB), que viabilizaria
um novo modelo de integração. O ESB é um middleware que implementa os
Enterprise Application Integration (EAI Patterns): uma série de padrões para
integração de aplicações, que permite o ESB integrar sistemas construídos em
diferentes linguagens e arquiteturas, provendo uma camada homogênea entre esses
sistemas.
Por fim, em meados dos anos 2000, o World Wide Web Consortium (W3C)
recebeu a submissão do protocolo Simple Object Protocol (SOAP) e da Web Service
Description Language (WSDL). Essas especificações, aliadas ao uso do XML,
viabilizaram o surgimento da geração de Web Services, compondo os serviços que
dariam origem às primeiras implementações de uma Service Oriented Architecture
(SOA). Junto a estas implementações começaram a surgir as bases do que seria
futuramente a infraestrutura SOA que viria a facilitar a construção, entrega e
disponibilização desses serviços.[MELO, 2012][SOAEXPERTa, 2012]
2 SOA - CONCEITOS Segundo Carl August Simon(SIMON, 2005), "Arquitetura Orientada a Serviços
(SOA) é um framework organizacional e técnico que permite uma empresa distribuir
suas funcionalidades de negócio, independente de plataforma tecnológica, como
peças para construção de aplicações". Além desse conceito, SOA possui as
seguintes definições, de acordo com grandes nomes existentes no mercado: "Service Oriented Architecture (SOA) é uma arquitetura para construção de aplicações de negócio a partir de um conjunto de serviços com baixo acoplamento armazenados em uma 'caixa preta' e orquestrados de forma a entregar resultados alinhados com os objetivos de negócio de uma empresa.” (IBM, citado por MELO, 2012, p. 8) “É um estilo de arquitetura de software cujo princípio fundamental prega que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços. Frequentemente, estes serviços são conectados através de um "Barramento de Serviços" (Enterprise Service Bus, em inglês), que disponibiliza interfaces ou contratos, acessíveis através de webservices ou outra forma de comunicação entre aplicações”. (Wikipédia, citado por MELO, 2012, p. 8) “SOA é uma forma de tecnologia arquitetural que adere aos princípios de orientação de serviços. Quando realizada através do uso de Web Services, SOA atinge o potencial para suporta e promover estes princípios através dos processos de negócio e automação dos domínios corporativo”. (ERL, 2005)
Deve-se salientar, referente à citação de Thomas Erl, que o uso de Web
Services não implica uma estratégia SOA. Para que isso ocorra, é necessário seguir
princípios e práticas de orientação a serviços, alinhados às expectativas de negócio.
Caso contrário, o produto final será apenas uma integração entre sistemas legados
que não expõem o negócio através de contratos e serviços.
Antes de mencionar sobre esses princípios e práticas, será feita uma breve
definição sobre serviços e orientação a serviços nas próximas seções.
3 SERVIÇOS Um serviço em SOA é um componente de software que possui uma forte
relação com o processo de negócio, segundo a Mulesoft (MULESOFT, 2013)
“Serviços são unidades lógicas auto suficientes que realizam atividades específicas.
Possui uma maior importância a partir do conceito de orientação a serviços, citado a
seguir. Graças a esse conceito, o serviço contém uma série de características que o
diferenciam de componentes criados com outras abordagens. Algumas dessas
características são: (i) possuir uma ou mais operações e ser descrito através de um
contrato e (ii) ter a capacidade de utilizar outros serviços que se completam na
execução de uma atividade, se tornando reutilizável. (ERL, 2005)
O contrato mencionado na primeira característica é composto de um ou mais
documentos que descrevem metainformações sobre o serviço. Desses documentos,
o mais importante é o que descreve sua interface técnica, ou seja, sua API e quais
operações o serviço pode prover. Adicionalmente, este contrato pode ser resumido
em uma linguagem mais legível para o usuário, no formato de SLAs3.
3.1 ORIENTAÇÃO A SERVIÇOS A orientação a serviços tem suas raízes na engenharia de software, em uma
teoria conhecida como "Separação 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 lógica necessária para o todo seja
decomposta em soluções menores, cada uma especializada em resolver uma parte
do problema. (ERL, 2005) "A orientação a serviços é uma abordagem para organizar recursos de TI distribuídos em uma solução integrada que desmembre silos de informação e maximize a agilidade dos negócios. A orientação a serviços separa os recursos de TI em módulos, criando processos de negócios do tipo "loosely coupled" e que integram informações entre sistemas de negócios". (Microsoft, citado por MELO, 2012, p. 8)
3 Service Level Agreement ou acordo de nível de serviço, é um acordo firmado entre a área
de TI e seu cliente interno, que descreve o serviço de TI, suas metas de nível de serviço, além dos papéis e responsabilidades das partes envolvidas no acordo. [WIKIPEDIAb, 2013]
Assim, a orientação a serviços pode ser vista como uma implementação da
SoC. O que difere uma da outra, como por exemplo, a Orientação a Objetos, é uma
série de princípios que permitem que as características de SOA sejam atingidas,
conhecidas como "Princípios do Design de Serviços".
Segundo Thomas Erl (ERL, 2005), existem oito princípios de design de
serviços, descritos a seguir:
• Contrato de serviços padronizado: expõe a capacidade e o propósito
dos serviços através de um contrato;
• Baixo acomplamento: serviços devem ser projetados para interagir sem
a necessidade de acoplamento e dependência entre eles;
• Abstração: a única parte exposta do serviço 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 serviços devem ser projetados para suportar potenciais
reusos futuros;
• Autonomia: a lógica governada por um serviço reside em uma fronteira
explícita, onde ele deve ter controle dessa fronteira e não depender de
outros serviços;
• Não manter estados: serviços não devem gerenciar estados, devem
ser projetados para se manter sem os mesmos, ainda que deleguem
essa gerência para outro componente;
• Habilidade de poder ser descoberto: serviços devem permitir que suas
descrições sejam descobertas e entendidas por humanos e
consumidores, de forma que esses possam utilizá-los;
• Habilidade de poder ser composto: serviços podem ser compostos por
outros serviços; essa prática promove a reusabilidade e a criação de
diferentes camadas de abstração.
4 ESCALABILIDADE A escalabilidade é a capacidade de um sistema crescer e continuar
atendendo requisições, dado que a carga de acesso ao mesmo aumenta. Um
sistema pode ser escalável horizontalmente ou verticalmente.
Na escalabilidade horizontal, são adicionados recursos do mesmo tipo, como
por exemplo, servidores. Já na vertical, se adiciona recursos no mesmo nó ou
máquina, aumentando sua memória 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 virtualização e distribuição, tem-se também um modelo de
desenvolvimento mais complexo. Já na escalabilidade vertical, o modelo é bem mais
simples, porém o alcance se torna mais limitado.
Com o crescimento das técnicas de sistemas distribuídos e com o
surgimentos dos servidores nas nuvens, tem-se adotado amplamente o modelo
horizontal. Essas técnicas abstraem a complexidade e os custos desse modelo,
tornando-o uma opção mais viável e escalável (WIKI, 2013).
4.1 PRINCIPAIS PROBLEMAS Quando um sistema começa a crescer, podem surgir alguns problemas caso
esse crescimento não 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 número de objetos: quanto mais um sistema cresce, mais
objetos ele tende a carregar em memória, desonerando recursos de
todos os tipos utilizados por eles;
• Grande número de requisições prioritárias: em um sistema de larga
escala, as requisições prioritárias podem utilizar todos os recursos
disponíveis apenas para tratá-las, paralisando o restante do sistema;
• Grande fluxo de dados: com o aumento do número de requisições, há
um acréscimo no tempo de carregamento do sistema. Esse cenário
tende a piorar à medida em que o fluxo cresce;
• Aumento do número de clientes: com o crescimento do sistema, há um
aumento do número de clientes e, consequentemente, da utilização
dos recursos disponíveis. Por exemplo: aumenta o número de threads
inicializadas para que eventos possam ser tratados; cresce a memória
alocada para o processamento de filas; mais largura de banda é
utilizada para a comunicação entre servidores e consumidores e, por
fim, uma maior quantidade de dados é armazenada.
• Falta de poder de memória e processamento: com mais objetos,
clientes e dados, a memória e a capacidade de processamento dos
servidores pode não ser suficiente. Além disso, pequenas perdas de
memória, que em sistemas menores degradam gradativamente a
performance, podem aumentar rapidamente. Isso ocasiona erros por
falta de recursos das máquinas.
• Incapacidade de testar grandes configurações: devido à dificuldade de
configurar grandes ambientes, o tempo dedicado a testes é mínimo. A
incapacidade de testar o sistema em desenvolvimento produz erros de
design que irão impactar diretamente o escalonamento do sistema.
5 ANÁLISE DE SOA X ESCALABILIDADE Diante de tantos problemas com escalabilidade, percebe-se a dificuldade para
se atingir tais objetivos. Conforme visto em seções anteriores SOA possui uma série
de princípios e uma infraestrutura de apoio que quando bem alocada podem
solucionar vários desses problemas.
Nesta seção, será apresentado como a infraestrutura SOA pode oferecer para
a resolução dos problemas de escalabilidade e por fim um conjunto de design
patterns que visam resolver alguns problemas conhecidos de escalabilidade
seguindo uma estratégia SOA. Associado a estes conceitos estão os princípios de
orientação a serviços que viabilizam a utilização da infraestrutura e aplicação do
patterns SOA.
5.1 INFRAESTRUTURA SOA SOA não é inerente à tecnologia ou produtos, mas uma boa infraestrutura
SOA se torna essencial a fim de aumentar sua eficácia e produtividade. Nesta
seção, serão encontrados alguns componentes relacionados à essa infraestrutura,
bem como seus conceitos e aplicações na obtenção de escalabidade de software.
5.1.1 Shared Nothing Architecture
Shared Nothing Archictecture (SNA) é uma arquitetura de sistemas
distribuídos, onde cada nodo é independente e auto-suficiente, ou seja, não há
compartilhamento de recursos, como memória e disco, entre diferentes nós.
Um sistema projetado para escalar utilizando esse tipo de arquitetura
normalmente particiona seus dados entre diferentes servidores. Assim, cada nó fica
responsável por interagir com os dados de determinada parte do sistema. Por
exemplo, todas as funcionalidades referentes ao usuário ficariam armazenados em
um único nó, logo não haveria compartilhamento entre os dados de usuário para
outros nós do sistema. A grande vantagem dessa abordagem é que o não
compartilhamento de recursos evita a dependência entre nós, eliminando os pontos
de falha da aplicação. 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 seção 8, um
dos princípios que guia a orientação a serviços e, consequentemente, SOA, é o
Loose Coupling Services. Dessa forma, utilizando SNA com SOA, tem-se uma
arquitetura onde cada serviço seria responsável por lidar com seus próprios
recursos, sem compartilhá-los, minimizando os pontos de falha. Esta estratégia torna
o uso de SNA com SOA uma solução altamente escalável horizontalmente.
(OLIVEIRA, 2013)
Uma desvantagem desta abordagem é que eventualmente os dados terão
que ser compartilhados. Então, como tratar um cruzamento de funcionalidades
entre, por exemplo, usuário e conta bancária? Seria necessário acessar os dados do
usuário e, em seguida, enviá-los para os serviços responsáveis pela conta bancária
para ter o retorno do processamento. Essa comunicação entre diferentes nós
causaria um aumento no tráfego da rede.
Por fim, é possível utilizar SNA sem SOA. Porém, o que difere SOA de outros
tipos de aplicação são seus princípios, que prezam pela não manutenção de estado,
evitando sua gerência e propagação entre os diferentes nós da arquitetura. Essa
abordagem facilita a utilização de SNA a partir dos princípios de design de serviços.
5.1.2 Enterprise Service Bus
O Enterprise Service Bus (ESB) é um middleware que age como um canal de
integração e comunicação entre diferentes plataformas computacionais, conforme
demonstrado na Figura 2. Entre as suas principais responsabilidades, estão
(SOAEXPERTb, 2012):
• Monitorar e controlar o roteamento e a troca de mensagens entre
serviços;
• Realizar transformações de dados de um formato para outro;
• Fazer a tradução entre diferentes protocolos;
• Padronizar a camada de segurança e o acesso aos serviços.
Figura 2 - ESB como camada de integração entre diferentes plataformas (SOAEXPERTb, 2012)
Para realizar essa atividades, o ESB implementa os Enterprise Application
Integration (EAI) Patterns, atuando como uma realização das melhores práticas de
integração.
Conforme discutido na seção 4.1, quando a demanda pelo sistema começa a
aumentar, o número de requisições cresce exigindo maiores recursos da máquina.
Em um cenário onde o ESB concentra todo o fluxo de entrada e saída do sistema, a
vazão pode ser alta demais, de forma que o barramento não consiga atender todas
as requisições, se tornando um ponto único de falha (ABEYSINGHE, 2009).
Uma função essencial para que o ESB evite este problema é a capacidade
dele se conectar em um cluster de ESBs. De maneira generalizada, um cluster é
uma coleção de máquinas que se comporta como uma única máquina. Os
integrantes se conectam uns com os outros através de redes de alta velocidade e
replicam os recursos de hardware e/ou software entre si. A grande vantagem dessa
técnica é que a falha de uma máquina permite que outro integrante do cluster
assuma o seu trabalho sem que haja impacto perceptível para o cliente.
Além do aumento da tolerância a falha, o cluster permite um crescimento
significativo da performance, pois quando uma requisição chega ao barramento,
algoritmos de load-balacing realizados via software ou hardware distribuem as
requisições para nós mais ociosos, dividindo a carga entre diferentes servidores e
aumentando o tempo de resposta dos ESBs. Adicionalmente, é possível escalar o
cluster simplesmente adicionando novos nós a ele.
Outra opção para ganho de performance e escalabilidade é utilizar o ESB
para realizar load-balacing e represamento de requisições. Na primeira técnica, é
possível disponibilizar um mesmo serviço em diversas máquinas; registra-se as
máquinas no ESB e, ao receber uma requisição, o mesmo decide para qual delas
será enviada. Na segunda abordagem, o ESB age como uma represa, impedindo
que os servidores sejam inundados por requisições; o barramento encaminha aos
serviços apenas o número máximo permitido para não 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 construção de
softwares que produzem, detectam, consomem e reagem a eventos. O evento é
uma mudança de estado que ocorre quando algum processo de negócio é acionado.
Por exemplo, ao efetuar uma compra é gerado um evento que pode ser detectado
por outros sistemas interessados, como o sistema de logística, 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 negócio e arquitetos de lidar com negócios 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
múltiplos eventos em grandes volumes para dar a eles significado e ajuda a buscar
padrões em eventos aparentemente sem relacionamentos, tomando decisões
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 inclusão dos serviços aliados aos objetivos de negócio, enquanto
EDA desacopla tais serviços a ponto de um consumidor não saber da existência de
um produtor. Tal relacionamento entre serviços e eventos pode ser visto na Figura 3.
Figura 3 - Relacionamento entre serviços e eventos (MALEKZADEH, 2010, p. 54)
A capacidade de escalar sistemas com EDA é atingida devido ao total
desacoplamento entre seus componentes. Através dos eventos, consumidores e
produtores não conhecem a existência uns dos outros. Essa estratégia permite que
o sistema permaneça funcionando mesmo quando um consumidor ou produtor para
de funcionar.
Essa capacidade de desacoplamento total torna possível escalar a aplicação
horizontalmente com a simples adição de novos consumidores para dar vazão ao
aumento do fluxo de eventos dos produtores. Toda a garantia de concorrência e
entrega dessas mensagens pode ser feita através de filas de mensageria que
utilizam uma estratégia FIFO4. O grande problema dessa estratégia é 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 além da escalabilidade for necessário garantir que mensagens não
sejam perdidas, dois padrões podem ser utilizados em conjunto: o padrão publish-
subscribe permitirá que diversos consumidores conheçam a mesma mensagem, ou
seja, caso um consumidor interrompa o processamento da mensagem sem finalizá-
lo, ela não será perdida; já o padrão content message routing permite que, baseado
em seus conteúdos, os eventos sejam distribuídos para diferentes filas de
4 Em Ciência da Computação, FIFO (acrônimo para First In, First Out, que em português
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 responsáveis por
tratar somente eventos de determinado tipo, evitando que a memória dos servidores
seja utilizada com todos os eventos recebidos (FERREIRA, 2013).
5.3 SOA Patterns Ao decidir utilizar uma estratégia SOA, abre-se um leque de novas
possibilidades e técnicas para tratar de problemas já conhecidos, como por exemplo,
tornar o software altamente escalável. SOA possui uma série de design patterns,
soluções recorrentes para problemas igualmente recorrentes, que tratam de resolver
situações que envolvem o aumento de escalabilidade. Os patterns descrito nesta
seção demonstram como SOA pode ser utilizada como solução para essas
situações.
5.3.1 Service Grid Pattern
Uma boa estratégia para lidar com o aumento do volume de tráfego é
armazenar dados idempotentes em memória, minimizando o número de acesso ao
banco de dados e, consequentemente, aumentando a performance da aplicação.
Porém, caso o servidor de cache pare, os dados em memória são perdidos,
tornando-o um ponto único de falha.
O Service Grid Pattern provê uma solução elegante para esse problema,
armazenando o cache da aplicação em um grid distribuído que o replica entre todos
os seus nós. Caso um desses falhe e não possa atender a requisição, outro
integrante do grid toma seu lugar, aumentando a disponibilidade da aplicação à
medida que ela se torna mais resistente a falhas (Figura 4).
Figura 4 – Service grid replicando dados entre diferentes servidores (ERL, 2009).
O princípio de Service Stateless se relaciona diretamente com esse padrão: o
serviço atende diversas requisições e consulta o grid para obter dados
armazenados, independente do cliente que fez a requisição, aumentando assim a
vazão dos dados.
5.3.2 Decoupled Invocation Pattern
Um serviço recebe determinado número de requisições e consegue atendê-
las. Porém, em determinados momentos, como uma promoção relâmpago, por
exemplo, o serviço é sobrecarregado com uma taxa muita alta de requests e não
consegue processar as requisições a tempo de respondê-las.
O Decoupled Invocation Pattern se propõe a resolver esse problema,
separando a lógica de request e response: um handler recebe a requisição e sinaliza
para o sender que a mesma foi recebida com sucesso; uma vez recebida, faz os
primeiros tratamentos e cadastra a requisição em uma fila de entrada. O serviço
responsável pela lógica de negócio vai consumindo essa fila em sua própria vazão,
fazendo com que a fila aja como uma represa, segurando o fluxo e impedindo que o
serviço se afogue com um número excessivo de requisições (Figura 5) (ROTEM
GAL-OZ, 2012).
Figura 5 - Arquitetura conceitual do Decoupled Invocation Pattern (ROTEM GAL-OZ, 2012).
O processo de inserção 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 padrão se relaciona com os princípios de Service Abstraction e
Service Autonomy, pois além de lidar com seus próprios recursos, os consumidores
não precisam ter conhecimento da arquitetura encapsulada pelo serviço.
O Decoupled Invocation Pattern é apropriado para picos de tráfego. Porém,
se esses picos se mantiverem durante longos períodos de tempo, será necessário
viabilizar outras estratégias, como as abordadas nos itens a seguir.
5.3.3 Parallel Pipelines Pattern
Um determinado processo de negócio tem um fluxo que passa por diversas
fases como validação, detecção de fraude, autorização e finalização. Alguns
problemas são a quantidade de passos do fluxo e possíveis chamadas a
componentes externos. Como garantir que o fluxo dê vazão a quantidades cada vez
mais crescentes de requisições e que ele ainda seja testável e escalável?
Uma abordagem seria utilizar o Parallel Pipelines Pattern, que se baseia no
estilo de arquitetura “Pipe and Filters”. Esse princípio divide o problema em pedaços
que se conectam formando um fluxo; logo a requisição é enviada para cada
componente que faz um processamento e, após terminá-lo, passa para o seguinte;
ao final do fluxo, a requisição é retornada. Esse processo é descrito na Figura 6.
Figura 6 - Fluxo do Parallel Pipelines Pattern (ROTEM GAL-OZ, 2012)
O padrão descrito anteriormente possui as seguintes vantagens: (i) é
relativamente fácil de implementar; (ii) cada componente se torna muito fácil de
testar, pois age independente dos demais e (iii) para escalar a solução, se distribui o
pipeline em diferentes servidores e, preferencialmente, cada componente em seu
próprio servidor. Por fim, o desafio está em conseguir dividir o problema de forma
que os componentes fiquem independentes (ROTEM GAL-OZ, 2012).
O princípio de Loose Coupling está fortemente relacionado a esse padrão,
pois cada componente deverá ser independente dos demais. Além desse, o princípio
de Service Composition tem papel fundamental, pois embora independentes, os
serviços devem ser orquestrados de forma que consigam processar o fluxo, ou seja,
devem se compor para formar novos serviços.
5.3.4 Service Instance Pattern
Em uma grande promoção, por exemplo, uma grande carga de requisições é
feita ao módulo de validações e fraudes. Como escalar o sistema para atender às
requisições?
O Service Instance Pattern define a estratégia de criar novas instâncias do
serviço. Por seguirem o princípio de Service Stateless, mais serviços conseguem dar
vazão a novas requisições. Aliando essa estratégia ao uso do ESB (item 5.1.2), é
possível que ele faça o papel de dispatcher, realizando o load-balacing entre as
novas instâncias dos serviços (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 computação que são
disponibilizados como serviços através de uma rede, usualmente a internet. Nos
últimos anos, essa técnica tem crescido muito em adoção pelas grandes
companhias, devido à uma série de vantagens (BOWEN, 2013):
• Redução de custos de investimentos: não é mais necessário investir
em datacenters ou na infraestrutura de TI, já que os serviços nas
nuvens disponibilizam todo esse aparato pronto e a um custo
competitivo;
• Aumento de disponibilidade e confiabilidade: a infraestrutura
disponibilizada nas nuvens tende a ser mais robusta, pois os
provedores de cloud computing possuem servidores de redundância e
mecanismo para recuperação automática de falha;
• Aumento de escalabilidade: além de toda a infraestrutura citada
anteriormente, os provedores de cloud ainda trabalham com
datacenters imensos, utilizando-se de tecnologia de grids e com
crescimento elástico, ou seja, à medida que a aplicação demanda por
recursos, o provedor os fornece para ela. Todo esse conjunto de
funcionalidades faz aplicações disponibilizadas na nuvem altamente
escaláveis.
Dessa forma, percebe-se a relação direta entre cloud computing e
escalabilidade de software. Mas, qual a relação entre cloud computing e SOA?
Segundo Jerry Cuomo (BOWEN, 2013), CTO da IBM's Websphere Business, “SOA
é um estilo arquitetural para construir aplicações desacopladas e que permitam
composição. É possível construir uma infraestrutura de um datacenter utilizando os
princípios SOA, e isto seria cloud computing, ou seja, infraestrutura orientada a
serviços”.
Portanto, embora ambas partam de conceitos diferentes, sendo cloud computing
infraestrutura, e SOA estratégia para construção de aplicações através de serviços,
ainda assim, cloud computing entrega suas funcionalidades por meio desses
serviços. Ou seja, o uso dos princípios de orientação a serviços facilita a
disponibilização das funcionalidades entregues pela cloud computing.
6 ANÁLISE DOS RESULTADOS A partir das técnicas apresentadas nas seções anteriores podemos sintetizar
os resultados classificando-os acordo com os seguintes critérios: (i) Relacionamento
com SOA; (ii) Princípios de SOA que viabilizam o uso da técnica; (iii) Vantagens de
sua adoção; (iv) Tipo de escalabilidade permitida pela técnica.
A síntese dessa análise está descrita na tabela 1.
Relação com SOA Princípios de SOA Vantagens Escalabilidade
EDA
Os serviços se
tornam
consumidores e
produtores.
Serviços proveem o
valor de negócio.
Baixo Acoplamento,
Abstração,
Habilidade de poder
ser composto
Baixíssimo
acoplamento
permite escalar o
sistema.
Horizontal
Shared-Nothing
Architecture
Cada serviço se
torna responsável
por determinadas
funcionalidades,
dessa forma, não
há
compartilhamento
de recursos entre
diferentes serviços.
Autonomia, Baixo
acoplamento,
Abstração.
Não
compartilhamento
de recursos
aumenta o poder
de escalar a
aplicação.
Horizontal
Enterprise Service Bus
Pilar da
infraestrutura SOA,
facilita a integração
entre diferentes
protocolos
promovendo
também um baixo
acoplamento entre
clientes e serviços.
Baixo acoplamento,
Abstração, Contrato
de serviços
padronizado.
Cluster de ESBs,
Load Balacing,
Represamento
Vertical e
Horizontal
Service Grid Pattern
Padrão de
escalabilidade
SOA.
Abstração Reduz ponto
único de falha
mantendo um
cache em
diferentes nós
aumentando
disponibilidade.
Horizontal
Decoupled
Invocation Pattern
Padrão de
escalabilidade
SOA.
Abstração Permite atender
uma alta
demanda em
picos de acesso.
Horizontal
Parallel Pipeline
Pattern
Padrão de
escalabilidade
SOA.
Baixo Acoplamento,
Habilidade de poder
ser composto.
Fraciona a
demanda e
manter o
processamento
Horizontal
mesmo quando
um sistema
externo não está
disponível.
Service Instance
Pattern
Padrão de
escalabilidade
SOA.
Abstração Aumenta a vazão
com que as
requisições são
processadas.
Horizontal
Cloud Computing SOA facilita a
distribuição dos
serviços nas
nuvens.
Baixo Acoplamento,
Abstração,
Autonomia,
Habilidade de poder
ser descoberto.
Maior
infraestrutura dos
ambientes nas
nuvens que vai
permitir uma
maior
disponibilidade e
escalabilidade.
Horizontal
Tabela 1 – Tabela de sintaxe dos resultados
7 CONCLUSÃO Diante do estudo apresentado, percebe-se que SOA possui um arcabouço de
princípios e tecnologias que promovem uma facilidade na busca por sistemas mais
escaláveis. Estilos arquiteturais como EDA tem uma forte relação com SOA e são
altamente escaláveis por trabalharem com um altíssimo desacoplamento entre seus
componentes. Tecnologias e padrões de infraestrutura como Cloud Computing e
Shared Nothing Architecture são utilizados por diversos tipos de aplicação, mas
conforme foi analisado, possuem uma série de sinergias com SOA que facilitam a
sua implantação e utilização. Além disso, SOA possui diversos patterns que
resolvem problemas comuns de escalabilidade, além do Enterprise Service Bus, que
abstrai a complexidade técnica das soluções 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 aplicação a níveis de uso mundial. Conclui-se, dessa forma, que SOA pode
auxiliar o aumento de escalabilidade de software, não sendo a única estratégia que
aborda o problema, mas certamente uma abordagem válida e útil, que se preocupa
em manter o valor de negócio.
8 REFERÊNCIAS
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 Gestão em
Tecnologia da Informação. 2012. p6-60
ROTEM GAL-OZ, Arnon. SOA Patterns. Manning Publications Co. 2012. ISBN
9781933988269
SAUDATE, Alexandre. SOA Aplicado: Integrando com Web Services e além.
Casa do Código, 2012.
SOAEXPERTa, SOA Foundation: Classic and Next Generation, SOA|Expert.
2012.
SOAEXPERTb, Enterprise Service Bus: Integration Specialist, SOA|Expert,
2012.
8.2 DISSERTAÇÕES 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. Distribuição de carga flexível e dinâmica para provedores
de Web Services. USP, São Carlos, Março de 2009.
8.3 ARTIGOS DA INTERNET ABEYSINGHE, Samisa. Scalable SOA [Projeção visual]. 2009. 62
diapositivos: color. Acessível em: http://www.slideshare.net/wso2.org/scalable-soa
AMAZON, Inside Amazon, Disponível em: <http://www.amazon.com/Inside-
Careers-Homepage/b?ie=UTF8&node=239367011> Acesso em 14 Out. 2012
ARCITURA EDUCATION INC, Service Orientation Principles. Acessado em:
02 de Março de 2013. Disponível em:
http://serviceorientation.com/serviceorientation/index
BOWEN, Filmore. How SOA can ease your move to cloud computing.
Acessado em 24 de Março de 2013. Disponível 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 Março de 2013. Disponível em:
https://blogs.oracle.com/middlewareplace/entry/implementing_distributed_processing
_of_events
HOFF, Todd. Amazon Architecture. Acessado em 24 de Março de 2013.
Disponível em: http://highscalability.com/amazon-architecture
HOFF, Todd. 42 Monster Problems That Attack As Loads Increase. Acessado
em: 17 de Março de 2013. Disponível em:
http://highscalability.com/blog/2013/2/27/42-monster-problems-that-attack-as-loads-
increase.html
MULESOFT, Services in SOA. Acessado em 28 de Março de 2013.
Disponível em: http://www.mulesoft.com/resources/esb/services-in-soa
OLIVEIRAa, Felipe. Think Decoupled [Projeção visual]. 2011. 58 diapositivos:
Color. Acessível em: http://www.slideshare.net/netarchitects/04-felipe-oliveira-think-
decoupled-soa
OLIVEIRAb, Felipe. Escalabilidade com Arquiteturas SOA. Acessado em 7 de
Janeiro de 2013. Disponível em:
http://soacloud.com.br/discussion/comment/171/#Comment_171
SIMON, Carl August. Killer SOA Definition. 2005. Acessado em 28 de Março
de 2013. Disponível em http://carlaugustsimon.blogspot.com.br/2005/09/killer-soa-
definition.html
STOPFORD, Benjamin. Shared Nothing v.s. Shared Disk Architectures: An
Independent View. Acessado em 17 de Março de 2013. Disponível em:
http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-
architecture/
WIKI, Phillip. Scaling Service Oriented Architecture: A look at how Oracle
solutions fit into a scalable Service Oriented Architecture. Acessado em: 10 de Março
de 2013. Disponível em: http://www.oracle.com/technetwork/articles/soa/wik-soa-
scaling-1738196.html
WIKIPEDIA, Service-oriented Architecture. Acessado em: 02 de Março de
2013. Disponível em: http://en.wikipedia.org/wiki/Service-oriented_architecture
Wikipediab, Acordo de nível de serviço. Acessado em 28 de Março de 2013.
Disponível em: http://pt.wikipedia.org/wiki/Acordo_de_n%C3%ADvel_de_serviço
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 possuía 55 milhões de
usuários com conta ativa e mais de 1 milhão de parceiros, além de cerca de 100 a
150 serviços utilizados para acessar uma página.
O grande passo para tal crescimento foi sair de uma aplicação cliente-servidor
para uma totalmente descentralizada, construída em cima de serviços que atendem
diversas aplicações diferentes. Inicialmente, o sistema era composto de um único
cliente se comunicando com um backend escrito em C++. A aplicação cresceu e,
durante muito tempo, os esforços 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 aplicação não podia mais escalar.
Uma nova abordagem foi tomada e o banco de dados dividido em um
conjunto de bancos menores. Porém, por esses recursos serem compartilhados
entre diferentes tempos e processos, a evolução do sistema ficou restrita. Em um
dado momento, o sistema foi dividido em centenas de serviços com alguns
servidores de aplicação mediando a comunicação entre eles.
Os serviços são unidades independentes que entregam funcionalidades na
Amazon, e é através deles que a empresa é organizada. Sempre que surge uma
nova necessidade de negócio, um time de 8 a 10 pessoas é formado, ficando
responsável por criar um novo serviço que atenda àquela necessidade.
Diante de todas essas mudanças, houve uma série de lições aprendidas ao
sair de uma aplicação pequena e monolítica para um sistema amplamente escalável
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 técnicas adotadas foi o uso de uma Shared Nothing Architecture,
pois recursos compartilhados podem causar deadlocks. O uso de uma arquitetura
orientada a serviços aliada à SNA permite a criação de serviços isolados que
escalam de maneira que comportem a demanda necessária ao negócio. Outras
lições da arquitetura da Amazon incluem: (i) exponha suas APIs e um ecossistema
será criado ao redor de sua aplicação; (ii) torne as coisas tão simples quanto
possíveis, evitando requisitos e dependências desnecessárias no seu design; (iii)
evite utilizar camadas de complexidade desnecessária para resolver o problema e,
por fim, (iv) organizar o negócio ao redor dos serviços oferece agilidade.
