Tcc Igti Modelo Hugo Marques 1v4b12

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 Marques

1

Orientador: Prof. Diovani Merlo

2

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 ar 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, í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 a 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 ar 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 o 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 ar 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 o 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 publishsubscribe 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 o 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 a por diversas fases como validação, detecção de fraude, autorização e finalização. Alguns problemas são a quantidade de os 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, a 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

Baixo Acoplamento,

Baixíssimo

Abstração,

acoplamento

produtores.

Habilidade de poder

permite escalar o

Serviços proveem o

ser composto

sistema.

Os

serviços

se

tornam consumidores

EDA

Escalabilidade

e

Horizontal

valor de negócio. Shared-Nothing

Cada

serviço

Architecture

torna

responsável

por

se

determinadas

Autonomia,

Baixo

Não

Horizontal

acoplamento,

compartilhamento

Abstração.

de

recursos

funcionalidades,

aumenta o poder

dessa forma, não

de

há

aplicação.

escalar

a

compartilhamento de recursos entre diferentes serviços. Enterprise

Service

Bus

Pilar

da

Baixo acoplamento,

Cluster de ESBs,

Vertical

infraestrutura SOA,

Abstração, Contrato

Load

Horizontal

facilita a integração

de

Represamento

entre

padronizado.

diferentes

serviços

Balacing,

protocolos promovendo também um baixo acoplamento

entre

clientes e serviços. Service

Grid

Pattern

Padrão

de

Abstração

Reduz

ponto

escalabilidade

único

de

falha

SOA.

mantendo

um

cache

em

diferentes

nós

Horizontal

aumentando disponibilidade. Decoupled

Padrão

de

Abstração

Permite

atender

Invocation Pattern

escalabilidade

uma

alta

SOA.

demanda

em

Horizontal

picos de o. Parallel Pattern

Pipeline

Padrão

de

Baixo Acoplamento,

Fraciona

a

escalabilidade

Habilidade de poder

demanda

e

SOA.

ser composto.

manter

o

processamento

Horizontal

e

mesmo

quando

um

sistema

externo não está disponível. Service

Instance

Pattern

Padrão

de

Abstração

Aumenta a vazão

escalabilidade

com

que

as

SOA.

requisições

são

Horizontal

processadas. Cloud Computing

SOA

facilita

a

Baixo Acoplamento,

Maior

Horizontal

distribuição

dos

Abstração,

infraestrutura dos

serviços

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 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. ível em: http://www.slideshare.net/wso2.org/scalable-soa AMAZON, Inside Amazon, Disponível em: o em 14 Out. 2012 ARCITURA EDUCATION INC, Service Orientation Principles. ado 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. ado

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). ado

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. ado 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. ado em:

17

de

Março

de

2013.

Disponível

em:

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

MULESOFT, Services in SOA. ado 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. ível em: http://www.slideshare.net/netarchitects/04-felipe-oliveira-thinkdecoupled-soa OLIVEIRAb, Felipe. Escalabilidade com Arquiteturas SOA. ado 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. ado em 28 de Março de 2013. Disponível em http://carlaugustsimon.blogspot.com.br/2005/09/killer-soadefinition.html STOPFORD, Benjamin. Shared Nothing v.s. Shared Disk Architectures: An Independent View. ado em 17 de Março de 2013. Disponível 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. ado em: 10 de Março de 2013. Disponível em: http://www.oracle.com/technetwork/articles/soa/wik-soascaling-1738196.html WIKIPEDIA, Service-oriented Architecture. ado 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. ado 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 ar uma página. O grande o 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 ar 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 ada. “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.