Instituto de Gestão em Tecnologia da InformaçãoPós Graduação em Estratégias de Arquitetura de SoftwareHugo de Sousa Marque...
Hugo de Sousa MarquesAumentando escalabilidade com o uso de Service OrientedArchitecture (SOA)Artigo apresentado ao curso ...
Aumentando escalabilidade com o uso de Service OrientedArchitecture (SOA)Hugo de Sousa MarquesAprovado em: ___/___/___BANC...
Aumentando a escalabilidade com Service Oriented Architecture(SOA)Hugo de Sousa Marques1Orientador: Prof. Diovani Merlo2Re...
Keywords: Service Oriented Architecture, Scalability, SOA Patterns, SOAInfrastructure1	   INTRODUÇÃO	  Com o surgimento da...
em como tais sistemas podem dar vazão às requisições e suportar o enormecrescimento de usuários, por exemplo, a Amazon em ...
integração de aplicações, que permite o ESB integrar sistemas construídos emdiferentes linguagens e arquiteturas, provendo...
Caso contrário, o produto final será apenas uma integração entre sistemas legadosque não expõem o negócio através de contr...
Assim, a orientação a serviços pode ser vista como uma implementação daSoC. O que difere uma da outra, como por exemplo, a...
Na escalabilidade horizontal, são adicionados recursos do mesmo tipo, comopor exemplo, servidores. Já na vertical, se adic...
• Falta de poder de memória e processamento: com mais objetos,clientes e dados, a memória e a capacidade de processamento ...
Um sistema projetado para escalar utilizando esse tipo de arquiteturanormalmente particiona seus dados entre diferentes se...
5.1.2 Enterprise	  Service	  Bus	  O Enterprise Service Bus (ESB) é um middleware que age como um canal deintegração e com...
integrantes se conectam uns com os outros através de redes de alta velocidade ereplicam os recursos de hardware e/ou softw...
O relacionamento entre SOA e EDA ocorre à medida que ambos os estilosarquiteturais promovem o baixo acoplamento. Quando ut...
mensageria. Assim, poderiam ser criados grupos que ficariam responsáveis portratar somente eventos de determinado tipo, ev...
O princípio de Service Stateless se relaciona diretamente com esse padrão: oserviço atende diversas requisições e consulta...
O Decoupled Invocation Pattern é apropriado para picos de tráfego. Porém,se esses picos se mantiverem durante longos perío...
de Service Composition tem papel fundamental, pois embora independentes, osserviços devem ser orquestrados de forma que co...
nuvens disponibilizam todo esse aparato pronto e a um custocompetitivo;• Aumento de disponibilidade e confiabilidade: a in...
Relação com SOA Princípios de SOA Vantagens EscalabilidadeEDAOs serviços setornamconsumidores eprodutores.Serviços proveem...
mesmo quandoum sistemaexterno não estádisponível.Service InstancePatternPadrão deescalabilidadeSOA.Abstração Aumenta a vaz...
8 REFERÊNCIAS8.1 LIVROS E APOSTILASCARTER, Sandy. The new language of business: SOA and WEB 2.0Crawfordsville: Pearson Edu...
MATOS, Jonathan. Distribuição de carga flexível e dinâmica para provedoresde Web Services. USP, São Carlos, Março de 2009....
MULESOFT, Services in SOA. Acessado em 28 de Março de 2013.Disponível em: http://www.mulesoft.com/resources/esb/services-i...
APENDICE I: ESTUDO DE CASO: AMAZONA Amazon cresceu de uma pequena loja de livros para uma das maiores lojasdo mundo. Segun...
escalam de maneira que comportem a demanda necessária ao negócio. Outraslições da arquitetura da Amazon incluem: (i) expon...
Upcoming SlideShare
Loading in...5
×

Aumentando escalabilidade com SOA

2,281

Published on

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.

Published in: Technology
3 Comments
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
2,281
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
147
Comments
3
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "Aumentando escalabilidade com SOA"

  1. 1. Instituto de Gestão em Tecnologia da InformaçãoPós Graduação em Estratégias de Arquitetura de SoftwareHugo de Sousa MarquesAumento da escalabilidade com o uso de Service OrientedArchitecture (SOA)BELO HORIZONTE, MG2012
  2. 2. Hugo de Sousa MarquesAumentando escalabilidade com o uso de Service OrientedArchitecture (SOA)Artigo apresentado ao curso deEstratégias em Arquitetura de Software doInstituto de Gestão em Tecnologia daInformação como como requisito parcialpara obtenção do título de Especialista.BELO HORIZONTE, MG2012
  3. 3. Aumentando escalabilidade com o uso de Service OrientedArchitecture (SOA)Hugo de Sousa MarquesAprovado em: ___/___/___BANCA EXAMINADORA___________________________________________________________________________________________________________________________________________________Conceito final: ____
  4. 4. Aumentando a escalabilidade com Service Oriented Architecture(SOA)Hugo de Sousa Marques1Orientador: Prof. Diovani Merlo2ResumoEste trabalho apresenta uma introdução aos conceitos de Service OrientedArchictecture (SOA), entre eles: serviços, orientação a serviços e princípios dedesign de serviços. Adicionalmente, são definidos os conceitos de escalabilidade desoftware e os principais problemas enfrentados ao se tentar construir sistemas maisescaláveis. Em seguida, é realizada uma análise em cima de diversas tecnologias eestratégias, entre elas: Shared Nothing Architecture, Event Driven Architecture,Enterprise Service Bus, SOA Patterns e Cloud Computing, sobre quais os ganhosque elas trazem para o aumento de escalabilidade e o porquê de SOA se relacionarcom tais métodos.Palavras chave: Service Oriented Architecture, SOA Patterns, InfraestruturaSOA, Escalabilidade.AbstractThis paper presents an introduction to the concepts of Service OrientedArchictecture (SOA), including: services, service-orientation and principles of servicedesign. Additionally, it’s defined the concepts of software scalability and the mainproblems faced when trying to build more scalable systems. Then an analysis isperformed on various technologies and strategies, including: Shared NothingArchitecture, Event Driven Architecture, Enterprise Service Bus, SOA Patterns andCloud Computing, on which gains they bring for increasing scalability and why SOArelates to such methods.1Pós graduando do curso de estratégias em Arquitetura de Software do Instituto de Gestãoem Tecnologia da Informação, turma 2012.1 e aluno da formação Consultor SOA da SOAExpert.2Professor do Instituto de Gestão em Tecnologia da Informação da disciplina de ServiceOriented Architecture.
  5. 5. Keywords: Service Oriented Architecture, Scalability, SOA Patterns, SOAInfrastructure1   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, houveum imenso crescimento desse novo paradigma e, como consequência, um pesadoinvestimento para atingi-lo.Uma das estratégias adotadas pelo setor de Tecnologiada Informação (TI) para auxiliar as companhias no seu crescimento é adecomposição dos sistemas em serviços e sua utilização para viabilizar a integraçãodos diferentes softwares isolados desenvolvidos no início da computação. Essadecomposição e interligação permite que diferentes setores utilizem softwares unsdos outros, evitando assim, a reescrita e duplicação de sistemas.“A flexibilidade é o principal combustível para o crescimento dos negóciosno cenário atual e ela é proporcionada no setor de tecnologia da informaçãocom a decomposição e interligação dos sistemas” (Carter, 2007, p299).Service Oriented Architecture (SOA) é uma série de princípios e metodologiaspara 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 complexidadetecnoló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 dosnegócios; (iii) oferecer uma melhor produtividade, tanto para a área de negócioscomo 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 finalsobre 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 arquitetosenvolvidos em projetos SOA sejam guiados por uma série de princípios conhecidoscomo Princípios de Design de Serviços. Segundo Thomas Erl (ERL, 2005), osprincí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) Habilidadede 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 aníveis globais como eBay, Amazon e Google, há uma preocupação cada vez maior
  6. 6. em como tais sistemas podem dar vazão às requisições e suportar o enormecrescimento de usuários, por exemplo, a Amazon em 2007 possuía cerca de 55milhões de usuários ativos (HOFFa, 2013). Na engenharia de software, acapacidade de um sistema se adequar à um grande número de usuários é chamadade escalabilidade.Portanto, dado que um dos objetivos de SOA é encapsular a complexidadetecnológica de TI, este trabalho pretende verificar quais as melhores práticas paraaumentar 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 nosurgimento de SOA, seus conceitos e os princípios de orientação a serviços. Aseguir, na seção 4 será discutido sobre escalabilidade e os principais problemasencontrados ao tentar atingi-la. No capítulo 5 será analisada como SOA podeagregar na resolução dos problemas descritos anteriormente. Por fim, serãodiscutidas as conclusões que podem ser obtidas a partir desse estudo.1 SOA - CONTEXTO HISTÓRICOCom a evolução da economia mundial para um conceito globalizado, asorganizações começaram a sentir a necessidade de se comunicarem umas com asoutras através de seus sistemas de software. Essa necessidade fez com que, nofinal da década de 90, um paradigma de integração fosse criado; no entanto, semostrou ineficiente, visto que adicionava uma complexidade tecnológica muito alta eum grande acoplamento entre os sistemas integrados, gerando um custo que otornaria inviável de ser mantido.Diante de tal cenário, soluções como Eletronic Data Interchange (EDI), que sebaseia na integração através da troca de arquivos e/ou compartilhamento detabelas; foram concebidas. Ainda assim, tais soluções continuavam agregando umalto custo e acoplamento aos sistemas, à medida que um software conheciadetalhes técnicos de outro sem necessidade. A consequência desses fatores foi oquestionamento dos valores de TI, os cortes de custos e uma pressão cada vezmaior por soluções de integração.Nesta mesma época surgiu o Enterprise Service Bus (ESB), que viabilizariaum novo modelo de integração. O ESB é um middleware que implementa osEnterprise Application Integration (EAI Patterns): uma série de padrões para
  7. 7. integração de aplicações, que permite o ESB integrar sistemas construídos emdiferentes linguagens e arquiteturas, provendo uma camada homogênea entre essessistemas.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 ServiceDescription Language (WSDL). Essas especificações, aliadas ao uso do XML,viabilizaram o surgimento da geração de Web Services, compondo os serviços quedariam origem às primeiras implementações de uma Service Oriented Architecture(SOA). Junto a estas implementações começaram a surgir as bases do que seriafuturamente a infraestrutura SOA que viria a facilitar a construção, entrega edisponibilização desses serviços.[MELO, 2012][SOAEXPERTa, 2012]2 SOA - CONCEITOSSegundo Carl August Simon(SIMON, 2005), "Arquitetura Orientada a Serviços(SOA) é um framework organizacional e técnico que permite uma empresa distribuirsuas funcionalidades de negócio, independente de plataforma tecnológica, comopeças para construção de aplicações". Além desse conceito, SOA possui asseguintes definições, de acordo com grandes nomes existentes no mercado:"Service Oriented Architecture (SOA) é uma arquitetura para construção deaplicações de negócio a partir de um conjunto de serviços com baixoacoplamento armazenados em uma caixa preta e orquestrados de forma aentregar resultados alinhados com os objetivos de negócio de umaempresa.” (IBM, citado por MELO, 2012, p. 8)“É um estilo de arquitetura de software cujo princípio fundamental prega queas funcionalidades implementadas pelas aplicações devem serdisponibilizadas na forma de serviços. Frequentemente, estes serviços sãoconectados através de um "Barramento de Serviços" (Enterprise ServiceBus, em inglês), que disponibiliza interfaces ou contratos, acessíveisatravé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 deorientaçã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ésdos 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 WebServices não implica uma estratégia SOA. Para que isso ocorra, é necessário seguirprincípios e práticas de orientação a serviços, alinhados às expectativas de negócio.
  8. 8. Caso contrário, o produto final será apenas uma integração entre sistemas legadosque 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 brevedefinição sobre serviços e orientação a serviços nas próximas seções.3 SERVIÇOSUm serviço em SOA é um componente de software que possui uma forterelaçã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 aseguir. Graças a esse conceito, o serviço contém uma série de características que odiferenciam de componentes criados com outras abordagens. Algumas dessascaracterísticas são: (i) possuir uma ou mais operações e ser descrito através de umcontrato e (ii) ter a capacidade de utilizar outros serviços que se completam naexecução de uma atividade, se tornando reutilizável. (ERL, 2005)O contrato mencionado na primeira característica é composto de um ou maisdocumentos 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 quaisoperações o serviço pode prover. Adicionalmente, este contrato pode ser resumidoem uma linguagem mais legível para o usuário, no formato de SLAs3.3.1 ORIENTAÇÃO A SERVIÇOSA orientação a serviços tem suas raízes na engenharia de software, em umateoria conhecida como "Separação de Conceitos" (Separation of Concerns - SoC).Essa teoria se baseia na vantagem de se separar um problema maior em umconjunto de problemas menores, permitindo que a lógica necessária para o todo sejadecomposta em soluções menores, cada uma especializada em resolver uma partedo problema. (ERL, 2005)"A orientação a serviços é uma abordagem para organizar recursos de TIdistribuídos em uma solução integrada que desmembre silos de informaçãoe maximize a agilidade dos negócios. A orientação a serviços separa osrecursos de TI em módulos, criando processos de negócios do tipo "looselycoupled" 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 áreade TI e seu cliente interno, que descreve o serviço de TI, suas metas de nível de serviço, além dospapéis e responsabilidades das partes envolvidas no acordo. [WIKIPEDIAb, 2013]
  9. 9. Assim, a orientação a serviços pode ser vista como uma implementação daSoC. O que difere uma da outra, como por exemplo, a Orientação a Objetos, é umasé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 deserviços, descritos a seguir:• Contrato de serviços padronizado: expõe a capacidade e o propósitodos serviços através de um contrato;• Baixo acomplamento: serviços devem ser projetados para interagir sema 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 parareuso, os serviços devem ser projetados para suportar potenciaisreusos futuros;• Autonomia: a lógica governada por um serviço reside em uma fronteiraexplícita, onde ele deve ter controle dessa fronteira e não depender deoutros serviços;• Não manter estados: serviços não devem gerenciar estados, devemser projetados para se manter sem os mesmos, ainda que deleguemessa gerência para outro componente;• Habilidade de poder ser descoberto: serviços devem permitir que suasdescrições sejam descobertas e entendidas por humanos econsumidores, de forma que esses possam utilizá-los;• Habilidade de poder ser composto: serviços podem ser compostos poroutros serviços; essa prática promove a reusabilidade e a criação dediferentes camadas de abstração.4 ESCALABILIDADEA escalabilidade é a capacidade de um sistema crescer e continuaratendendo requisições, dado que a carga de acesso ao mesmo aumenta. Umsistema pode ser escalável horizontalmente ou verticalmente.
  10. 10. Na escalabilidade horizontal, são adicionados recursos do mesmo tipo, comopor exemplo, servidores. Já na vertical, se adiciona recursos no mesmo nó oumáquina, aumentando sua memória ou trocando o servidor, por exemplo.Existem vantagens e desvantagens em se escolher um modelo. Enquanto naescalabilidade horizontal se ganha muito mais poder, especialmente com as novastecnologias de virtualização e distribuição, tem-se também um modelo dedesenvolvimento mais complexo. Já na escalabilidade vertical, o modelo é bem maissimples, porém o alcance se torna mais limitado.Com o crescimento das técnicas de sistemas distribuídos e com osurgimentos dos servidores nas nuvens, tem-se adotado amplamente o modelohorizontal. 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 PROBLEMASQuando um sistema começa a crescer, podem surgir alguns problemas casoesse crescimento não seja planejado da melhor forma. A lista abaixo é um resumoda lista original publicada no portal highscalability e traz problemas recorrentes deescalabilidade de sistemas (HOFF, 2013):• Grande número de objetos: quanto mais um sistema cresce, maisobjetos ele tende a carregar em memória, desonerando recursos detodos os tipos utilizados por eles;• Grande número de requisições prioritárias: em um sistema de largaescala, as requisições prioritárias podem utilizar todos os recursosdisponí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áriotende a piorar à medida em que o fluxo cresce;• Aumento do número de clientes: com o crescimento do sistema, há umaumento do número de clientes e, consequentemente, da utilizaçãodos recursos disponíveis. Por exemplo: aumenta o número de threadsinicializadas para que eventos possam ser tratados; cresce a memóriaalocada para o processamento de filas; mais largura de banda éutilizada para a comunicação entre servidores e consumidores e, porfim, uma maior quantidade de dados é armazenada.
  11. 11. • Falta de poder de memória e processamento: com mais objetos,clientes e dados, a memória e a capacidade de processamento dosservidores pode não ser suficiente. Além disso, pequenas perdas dememória, que em sistemas menores degradam gradativamente aperformance, podem aumentar rapidamente. Isso ocasiona erros porfalta de recursos das máquinas.• Incapacidade de testar grandes configurações: devido à dificuldade deconfigurar grandes ambientes, o tempo dedicado a testes é mínimo. Aincapacidade de testar o sistema em desenvolvimento produz erros dedesign que irão impactar diretamente o escalonamento do sistema.5 ANÁLISE DE SOA X ESCALABILIDADEDiante de tantos problemas com escalabilidade, percebe-se a dificuldade parase atingir tais objetivos. Conforme visto em seções anteriores SOA possui uma sériede princípios e uma infraestrutura de apoio que quando bem alocada podemsolucionar vários desses problemas.Nesta seção, será apresentado como a infraestrutura SOA pode oferecer paraa resolução dos problemas de escalabilidade e por fim um conjunto de designpatterns que visam resolver alguns problemas conhecidos de escalabilidadeseguindo uma estratégia SOA. Associado a estes conceitos estão os princípios deorientação a serviços que viabilizam a utilização da infraestrutura e aplicação dopatterns SOA.5.1 INFRAESTRUTURA SOASOA não é inerente à tecnologia ou produtos, mas uma boa infraestruturaSOA se torna essencial a fim de aumentar sua eficácia e produtividade. Nestaseçã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 sistemasdistribuí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.
  12. 12. Um sistema projetado para escalar utilizando esse tipo de arquiteturanormalmente particiona seus dados entre diferentes servidores. Assim, cada nó ficaresponsável por interagir com os dados de determinada parte do sistema. Porexemplo, todas as funcionalidades referentes ao usuário ficariam armazenados emum único nó, logo não haveria compartilhamento entre os dados de usuário paraoutros nós do sistema. A grande vantagem dessa abordagem é que o nãocompartilhamento de recursos evita a dependência entre nós, eliminando os pontosde 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 queutiliza o baixo acoplamento entre os componentes e, conforme visto na seção 8, umdos princípios que guia a orientação a serviços e, consequentemente, SOA, é oLoose Coupling Services. Dessa forma, utilizando SNA com SOA, tem-se umaarquitetura onde cada serviço seria responsável por lidar com seus própriosrecursos, sem compartilhá-los, minimizando os pontos de falha. Esta estratégia tornao uso de SNA com SOA uma solução altamente escalável horizontalmente.(OLIVEIRA, 2013)Uma desvantagem desta abordagem é que eventualmente os dados terãoque ser compartilhados. Então, como tratar um cruzamento de funcionalidadesentre, por exemplo, usuário e conta bancária? Seria necessário acessar os dados dousuário e, em seguida, enviá-los para os serviços responsáveis pela conta bancáriapara ter o retorno do processamento. Essa comunicação entre diferentes nóscausaria um aumento no tráfego da rede.Por fim, é possível utilizar SNA sem SOA. Porém, o que difere SOA de outrostipos 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. Essaabordagem facilita a utilização de SNA a partir dos princípios de design de serviços.
  13. 13. 5.1.2 Enterprise  Service  Bus  O Enterprise Service Bus (ESB) é um middleware que age como um canal deintegração e comunicação entre diferentes plataformas computacionais, conformedemonstrado na Figura 2. Entre as suas principais responsabilidades, estão(SOAEXPERTb, 2012):• Monitorar e controlar o roteamento e a troca de mensagens entreserviç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 ApplicationIntegration (EAI) Patterns, atuando como uma realização das melhores práticas deintegração.Conforme discutido na seção 4.1, quando a demanda pelo sistema começa aaumentar, 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, avazão pode ser alta demais, de forma que o barramento não consiga atender todasas requisições, se tornando um ponto único de falha (ABEYSINGHE, 2009).Uma função essencial para que o ESB evite este problema é a capacidadedele 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
  14. 14. integrantes se conectam uns com os outros através de redes de alta velocidade ereplicam os recursos de hardware e/ou software entre si. A grande vantagem dessatécnica é que a falha de uma máquina permite que outro integrante do clusterassuma 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 crescimentosignificativo da performance, pois quando uma requisição chega ao barramento,algoritmos de load-balacing realizados via software ou hardware distribuem asrequisições para nós mais ociosos, dividindo a carga entre diferentes servidores eaumentando o tempo de resposta dos ESBs. Adicionalmente, é possível escalar ocluster simplesmente adicionando novos nós a ele.Outra opção para ganho de performance e escalabilidade é utilizar o ESBpara 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 asmáquinas no ESB e, ao receber uma requisição, o mesmo decide para qual delasserá enviada. Na segunda abordagem, o ESB age como uma represa, impedindoque os servidores sejam inundados por requisições; o barramento encaminha aosserviç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 desoftwares 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 detectadopor outros sistemas interessados, como o sistema de logística, de anti-fraude, depagamentos, entre outros.O processamento de eventos simples já era comumente utilizado há algunsanos com tecnologias como IBM ou Tibco Inc. No entanto, em meados de 2007, anecessidade de analistas de negócio e arquitetos de lidar com negócios em temporeal fez o Complex Event Processing (CEP) ganhar bastante notoriedade (SLIWA,2003, citado por MALEKZADEH, 2010, p. 44). CEP trata do processamento demúltiplos eventos em grandes volumes para dar a eles significado e ajuda a buscarpadrões em eventos aparentemente sem relacionamentos, tomando decisõesinteligentes (MALEKZADEH, 2010, p. 44).
  15. 15. O relacionamento entre SOA e EDA ocorre à medida que ambos os estilosarquiteturais promovem o baixo acoplamento. Quando utilizadas em conjunto, SOAcontribui com a inclusão dos serviços aliados aos objetivos de negócio, enquantoEDA desacopla tais serviços a ponto de um consumidor não saber da existência deum 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 totaldesacoplamento entre seus componentes. Através dos eventos, consumidores eprodutores não conhecem a existência uns dos outros. Essa estratégia permite queo sistema permaneça funcionando mesmo quando um consumidor ou produtor parade funcionar.Essa capacidade de desacoplamento total torna possível escalar a aplicaçãohorizontalmente com a simples adição de novos consumidores para dar vazão aoaumento do fluxo de eventos dos produtores. Toda a garantia de concorrência eentrega dessas mensagens pode ser feita através de filas de mensageria queutilizam uma estratégia FIFO4. O grande problema dessa estratégia é que umamensagem que já tenha sido obtida pelo consumidor e sinalizada à fila pode serperdida caso o servidor que o hospede saia do ar, gerando assim um problema deconfiabilidade (FERREIRA, 2013).Quando além da escalabilidade for necessário garantir que mensagens nãosejam perdidas, dois padrões podem ser utilizados em conjunto: o padrão publish-subscribe permitirá que diversos consumidores conheçam a mesma mensagem, ouseja, 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, baseadoem seus conteúdos, os eventos sejam distribuídos para diferentes filas de4 Em Ciência da Computação, FIFO (acrônimo para First In, First Out, que em portuguêssignifica primeiro a entrar, primeiro a sair) refere-se a estruturas de dados do tipo fila. Tem umaestrutura diferente da estrutura de uma LIFO (que significa Last In, First Out, as pilhas). (WIKIPEDIA,2013)
  16. 16. mensageria. Assim, poderiam ser criados grupos que ficariam responsáveis portratar somente eventos de determinado tipo, evitando que a memória dos servidoresseja utilizada com todos os eventos recebidos (FERREIRA, 2013).5.3 SOA PatternsAo decidir utilizar uma estratégia SOA, abre-se um leque de novaspossibilidades 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 resolversituações que envolvem o aumento de escalabilidade. Os patterns descrito nestaseção demonstram como SOA pode ser utilizada como solução para essassituaçõ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 aobanco 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 todosos seus nós. Caso um desses falhe e não possa atender a requisição, outrointegrante 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).
  17. 17. O princípio de Service Stateless se relaciona diretamente com esse padrão: oserviço atende diversas requisições e consulta o grid para obter dadosarmazenados, independente do cliente que fez a requisição, aumentando assim avazã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, porexemplo, o serviço é sobrecarregado com uma taxa muita alta de requests e nãoconsegue 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 sinalizapara o sender que a mesma foi recebida com sucesso; uma vez recebida, faz osprimeiros tratamentos e cadastra a requisição em uma fila de entrada. O serviçoresponsá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 oserviço se afogue com um número excessivo de requisições (Figura 5) (ROTEMGAL-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 mesmaspode ser feita utilizando load-balacing com diversos leitores distribuindo a cargaentre si. Esse padrão se relaciona com os princípios de Service Abstraction eService Autonomy, pois além de lidar com seus próprios recursos, os consumidoresnão precisam ter conhecimento da arquitetura encapsulada pelo serviço.
  18. 18. 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árioviabilizar 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 diversasfases como validação, detecção de fraude, autorização e finalização. Algunsproblemas são a quantidade de passos do fluxo e possíveis chamadas acomponentes externos. Como garantir que o fluxo dê vazão a quantidades cada vezmais 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 noestilo de arquitetura “Pipe and Filters”. Esse princípio divide o problema em pedaçosque se conectam formando um fluxo; logo a requisição é enviada para cadacomponente 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 detestar, pois age independente dos demais e (iii) para escalar a solução, se distribui opipeline em diferentes servidores e, preferencialmente, cada componente em seupróprio servidor. Por fim, o desafio está em conseguir dividir o problema de formaque 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
  19. 19. de Service Composition tem papel fundamental, pois embora independentes, osserviç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 àsrequisições?O Service Instance Pattern define a estratégia de criar novas instâncias doserviço. Por seguirem o princípio de Service Stateless, mais serviços conseguem darvazã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 asnovas 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 COMPUTINGCloud computing é o uso dos recursos de computação que sãodisponibilizados como serviços através de uma rede, usualmente a internet. Nosúltimos anos, essa técnica tem crescido muito em adoção pelas grandescompanhias, devido à uma série de vantagens (BOWEN, 2013):• Redução de custos de investimentos: não é mais necessário investirem datacenters ou na infraestrutura de TI, já que os serviços nas
  20. 20. nuvens disponibilizam todo esse aparato pronto e a um custocompetitivo;• Aumento de disponibilidade e confiabilidade: a infraestruturadisponibilizada nas nuvens tende a ser mais robusta, pois osprovedores de cloud computing possuem servidores de redundância emecanismo para recuperação automática de falha;• Aumento de escalabilidade: além de toda a infraestrutura citadaanteriormente, os provedores de cloud ainda trabalham comdatacenters imensos, utilizando-se de tecnologia de grids e comcrescimento elástico, ou seja, à medida que a aplicação demanda porrecursos, o provedor os fornece para ela. Todo esse conjunto defuncionalidades faz aplicações disponibilizadas na nuvem altamenteescaláveis.Dessa forma, percebe-se a relação direta entre cloud computing eescalabilidade de software. Mas, qual a relação entre cloud computing e SOA?Segundo Jerry Cuomo (BOWEN, 2013), CTO da IBMs Websphere Business, “SOAé um estilo arquitetural para construir aplicações desacopladas e que permitamcomposição. É possível construir uma infraestrutura de um datacenter utilizando osprincípios SOA, e isto seria cloud computing, ou seja, infraestrutura orientada aserviços”.Portanto, embora ambas partam de conceitos diferentes, sendo cloud computinginfraestrutura, e SOA estratégia para construção de aplicações através de serviços,ainda assim, cloud computing entrega suas funcionalidades por meio dessesserviços. Ou seja, o uso dos princípios de orientação a serviços facilita adisponibilização das funcionalidades entregues pela cloud computing.6 ANÁLISE DOS RESULTADOSA partir das técnicas apresentadas nas seções anteriores podemos sintetizaros resultados classificando-os acordo com os seguintes critérios: (i) Relacionamentocom SOA; (ii) Princípios de SOA que viabilizam o uso da técnica; (iii) Vantagens desua adoção; (iv) Tipo de escalabilidade permitida pela técnica.A síntese dessa análise está descrita na tabela 1.
  21. 21. Relação com SOA Princípios de SOA Vantagens EscalabilidadeEDAOs serviços setornamconsumidores eprodutores.Serviços proveem ovalor de negócio.Baixo Acoplamento,Abstração,Habilidade de poderser compostoBaixíssimoacoplamentopermite escalar osistema.HorizontalShared-NothingArchitectureCada serviço setorna responsávelpor determinadasfuncionalidades,dessa forma, nãohácompartilhamentode recursos entrediferentes serviços.Autonomia, Baixoacoplamento,Abstração.Nãocompartilhamentode recursosaumenta o poderde escalar aaplicação.HorizontalEnterprise ServiceBusPilar dainfraestrutura SOA,facilita a integraçãoentre diferentesprotocolospromovendotambém um baixoacoplamento entreclientes e serviços.Baixo acoplamento,Abstração, Contratode serviçospadronizado.Cluster de ESBs,Load Balacing,RepresamentoVertical eHorizontalService GridPatternPadrão deescalabilidadeSOA.Abstração Reduz pontoúnico de falhamantendo umcache emdiferentes nósaumentandodisponibilidade.HorizontalDecoupledInvocation PatternPadrão deescalabilidadeSOA.Abstração Permite atenderuma altademanda empicos de acesso.HorizontalParallel PipelinePatternPadrão deescalabilidadeSOA.Baixo Acoplamento,Habilidade de poderser composto.Fraciona ademanda emanter oprocessamentoHorizontal
  22. 22. mesmo quandoum sistemaexterno não estádisponível.Service InstancePatternPadrão deescalabilidadeSOA.Abstração Aumenta a vazãocom que asrequisições sãoprocessadas.HorizontalCloud Computing SOA facilita adistribuição dosserviços nasnuvens.Baixo Acoplamento,Abstração,Autonomia,Habilidade de poderser descoberto.Maiorinfraestrutura dosambientes nasnuvens que vaipermitir umamaiordisponibilidade eescalabilidade.HorizontalTabela 1 – Tabela de sintaxe dos resultados7 CONCLUSÃODiante do estudo apresentado, percebe-se que SOA possui um arcabouço deprincípios e tecnologias que promovem uma facilidade na busca por sistemas maisescaláveis. Estilos arquiteturais como EDA tem uma forte relação com SOA e sãoaltamente escaláveis por trabalharem com um altíssimo desacoplamento entre seuscomponentes. Tecnologias e padrões de infraestrutura como Cloud Computing eShared Nothing Architecture são utilizados por diversos tipos de aplicação, masconforme foi analisado, possuem uma série de sinergias com SOA que facilitam asua implantação e utilização. Além disso, SOA possui diversos patterns queresolvem problemas comuns de escalabilidade, além do Enterprise Service Bus, queabstrai a complexidade técnica das soluções mencionadas acima.Todo esse estudo pode ser validado pelo relato da Amazon conforme descritono Apendice I (HOFFa, 2013), que demonstra como o uso de SOA pode escalaruma aplicação a níveis de uso mundial. Conclui-se, dessa forma, que SOA podeauxiliar o aumento de escalabilidade de software, não sendo a única estratégia queaborda o problema, mas certamente uma abordagem válida e útil, que se preocupaem manter o valor de negócio.
  23. 23. 8 REFERÊNCIAS8.1 LIVROS E APOSTILASCARTER, Sandy. The new language of business: SOA and WEB 2.0Crawfordsville: Pearson Education, Inc, 2007, p299.ERL, Thomas. Service Oriented Architecture: Concepts, Technology andDesign. CrawsfordVille: Prentice Hall, 2005.ERL, Thomas. SOA Design Patterns. Prentice Hall, 2009.MELO, Diovani. Service Oriented Architecture. Instituto de Gestão emTecnologia da Informação. 2012. p6-60ROTEM GAL-OZ, Arnon. SOA Patterns. Manning Publications Co. 2012. ISBN9781933988269SAUDATE, 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 TESESMALEKZADEH, Behrooz. Event-Driven Architecture and SOA in collaboration:A study of how Event-Driven Architecture (EDA) interacts and functions withinService-Oriented Architecture (SOA). University of Gothenburg. 2010. p. 44-50
  24. 24. MATOS, Jonathan. Distribuição de carga flexível e dinâmica para provedoresde Web Services. USP, São Carlos, Março de 2009.8.3 ARTIGOS DA INTERNETABEYSINGHE, Samisa. Scalable SOA [Projeção visual]. 2009. 62diapositivos: color. Acessível em: http://www.slideshare.net/wso2.org/scalable-soaAMAZON, Inside Amazon, Disponível em: <http://www.amazon.com/Inside-Careers-Homepage/b?ie=UTF8&node=239367011> Acesso em 14 Out. 2012ARCITURA EDUCATION INC, Service Orientation Principles. Acessado em:02 de Março de 2013. Disponível em:http://serviceorientation.com/serviceorientation/indexBOWEN, 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.htmlFERREIRA, Ricardo. Creating Scalable Fast Data Applications using OracleEvent 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_eventsHOFF, Todd. Amazon Architecture. Acessado em 24 de Março de 2013.Disponível em: http://highscalability.com/amazon-architectureHOFF, Todd. 42 Monster Problems That Attack As Loads Increase. Acessadoem: 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
  25. 25. MULESOFT, Services in SOA. Acessado em 28 de Março de 2013.Disponível em: http://www.mulesoft.com/resources/esb/services-in-soaOLIVEIRAa, Felipe. Think Decoupled [Projeção visual]. 2011. 58 diapositivos:Color. Acessível em: http://www.slideshare.net/netarchitects/04-felipe-oliveira-think-decoupled-soaOLIVEIRAb, Felipe. Escalabilidade com Arquiteturas SOA. Acessado em 7 deJaneiro de 2013. Disponível em:http://soacloud.com.br/discussion/comment/171/#Comment_171SIMON, Carl August. Killer SOA Definition. 2005. Acessado em 28 de Marçode 2013. Disponível em http://carlaugustsimon.blogspot.com.br/2005/09/killer-soa-definition.htmlSTOPFORD, Benjamin. Shared Nothing v.s. Shared Disk Architectures: AnIndependent 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 Oraclesolutions fit into a scalable Service Oriented Architecture. Acessado em: 10 de Marçode 2013. Disponível em: http://www.oracle.com/technetwork/articles/soa/wik-soa-scaling-1738196.htmlWIKIPEDIA, Service-oriented Architecture. Acessado em: 02 de Março de2013. Disponível em: http://en.wikipedia.org/wiki/Service-oriented_architectureWikipediab, 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
  26. 26. APENDICE I: ESTUDO DE CASO: AMAZONA Amazon cresceu de uma pequena loja de livros para uma das maiores lojasdo mundo. Segundo o artigo “Amazon Architecture”, ela possuía 55 milhões deusuários com conta ativa e mais de 1 milhão de parceiros, além de cerca de 100 a150 serviços utilizados para acessar uma página.O grande passo para tal crescimento foi sair de uma aplicação cliente-servidorpara uma totalmente descentralizada, construída em cima de serviços que atendemdiversas aplicações diferentes. Inicialmente, o sistema era composto de um únicocliente 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 abase de dados para suportar mais clientes, mais vendas, mais fornecedores, até omomento em que a aplicação não podia mais escalar.Uma nova abordagem foi tomada e o banco de dados dividido em umconjunto de bancos menores. Porém, por esses recursos serem compartilhadosentre diferentes tempos e processos, a evolução do sistema ficou restrita. Em umdado momento, o sistema foi dividido em centenas de serviços com algunsservidores de aplicação mediando a comunicação entre eles.Os serviços são unidades independentes que entregam funcionalidades naAmazon, e é através deles que a empresa é organizada. Sempre que surge umanova necessidade de negócio, um time de 8 a 10 pessoas é formado, ficandoresponsá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 aosair de uma aplicação pequena e monolítica para um sistema amplamente escalávele mundialmente acessada.“You must change your mentality to build really scalable systems.Approach chaos in a probabilistic sense that things will work well. Intraditional systems we present a perfect world where nothing goes down andthen we build complex algorithms (agreement technologies) on this perfectworld. Instead, take it for granted stuff fails, thats reality, embrace it. Forexample, go more with a fast reboot and fast recover approach. With adecent spread of data and services you might get close to 100%. Createself-healing, self-organizing lights out operations.” – Greg Linden, AmazonEngineerUma das técnicas adotadas foi o uso de uma Shared Nothing Architecture,pois recursos compartilhados podem causar deadlocks. O uso de uma arquiteturaorientada a serviços aliada à SNA permite a criação de serviços isolados que
  27. 27. escalam de maneira que comportem a demanda necessária ao negócio. Outraslições da arquitetura da Amazon incluem: (i) exponha suas APIs e um ecossistemaserá criado ao redor de sua aplicação; (ii) torne as coisas tão simples quantopossí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.

×