DAVID LOJUDICE SOBRINHO

Tamanho: px
Começar a partir da página:

Download "DAVID LOJUDICE SOBRINHO"

Transcrição

1 DAVID LOJUDICE SOBRINHO AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE FACULDADE DE TECNOLOGIA DE SÃO PAULO Pós-graduação em Tecnologia em Análise e Projeto de Sistemas São Paulo 2009

2 DAVID LOJUDICE SOBRINHO AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE Monografia apresentada à Fatec SP, como requisito para obtenção do título de especialista em Tecnologia de Análise e Projeto de Sistemas. Orientador: prof. Eduardo Endo FACULDADE DE TECNOLOGIA DE SÃO PAULO Pós-graduação em Tecnologia em Análise e Projeto de Sistemas São Paulo 2009

3 i DEDICATÓRIA Aos meus pais que sempre me apoiaram incondicionalmente...

4 ii AGRADECIMENTO Agradeço ao meu orientador, prof. Eduardo Endo, a profa. dra. Marcia Ito, e meus professores do curso de pós-graduação da FATEC, pelo conhecimento que eles transmitiram e direcionamento neste trabalho. Ao meu grande amigo prof. Fernando Paes Campos pelo apoio neste trabalho. À minha família e meus amigos que me apóiam agora e sempre.

5 iii BANCA EXAMINADORA Prof. Eduardo Endo - Orientador FATEC Faculdade de Tecnologia de São Paulo Prof a. Dr a. Marcia Ito FATEC Faculdade de Tecnologia de São Paulo Prof. Dr. Kazuo Watanabe FATEC Faculdade de Tecnologia de São Paulo

6 iv SUMÁRIO 1. INTRODUÇÃO FONTE DE INFORMAÇÃO SITES ESTUDADOS APLICAÇÃO WEB ARQUITETURA DE SOFTWARE ESCALABILIDADE ESTRATÉGIAS CAMADAS REUTILIZAÇÃO COMPUTACIONAL PARTICIONAMENTO DE DADOS COMPARATIVO DAS ESTRATÉGIAS EVOLUÇÃO DA ARQUITETURA CONCLUSÃO REFERÊNCIA APÊNDICE... ix

7 v LISTAS EXPRESSÕES Exp.1 - Escalabilidade Linear FIGURAS Fig.1 Shared Nothing Fig.2 - Shared Nothing com Banco de Dados separado Fig.3 - Por Camada Fig.4 - SOA Fig.5 - Arquitetura Mista Fig.6 - Processo Síncrono Fig.7 - Mensagem Assíncrona Fig.8 - Nuvem de Tags do Flickr Fig.9 - Modelo com valor desnormalizado Fig.10 - Cache Local Fig.11 - Cache distribuído Fig.12 - Cache menor que o repositório final Fig.13 - CDN Fig.14 - Modelo ER Lógico Fig.15 - Modelo ER distribuído usando Sharding Vertical Fig.16 - Modelo ER distribuído usando Sharding Horizontal GRÁFICOS Graf.1 Escalabilidade Vertical x Escalabilidade Horizontal... 11

8 vi TABELAS Tab.1 - Sites Estudados... 3 Tab.2 Referências às estratégias de Camadas Tab.3 - Referências às estratégias de Reutilização Computacional Tab.4 - Referências às estratégias de Particionamento de Dados... 46

9 vii GLOSSÁRIO ACID - Atomicity, Consistency, Isolation, Durability API - Application Programming Interface BASE - Basically Available, Soft State, Eventually Consistent CAP - Consistent, Available E Partition-Tolerant CDN - Content Delivery Network CPU - Central Processing Unit CTO - Chief Technology Officer FK - Foreign Key HTML - Hypertext Mark-Up Language HTTP - Hypertext Transfer Protocol I/O - Input/Output Joins - Uma cláusula SQL Join combina registros de duas ou mais tabelas em um banco de dados. JSon - Javascript Object Notation LRU - Least Recently Used MVC - Model View Controller ORDBMS - Object-Relational Database Management System PK - Primary Key RAM - Random Access Memory RDBMS - Relational Database Management System RPC - Remote Procedure Call SOA - Service-Oriented Architecture SOAP - Simple Object Access Protocol SQL - Structured Query Language SSI - Server Side Includes XML - Extensible Markup LanguageServer Side Includes

10 viii RESUMO Com o número cada vez maior de usuários conectados a internet, alguns web sites tem a desafiadora tarefa de atender milhões de usuários simultâneos, e ainda estar sempre disponível, sem comprometer a performance. Esses usuários podem chegar ao web site sem previsão e em grande número, sendo que atender todos eles é fator crucial para o sucesso do site. Os web sites mais visitados no mundo foram bem sucedido e alguns deles disponibilizaram informações sobre como foi possível escalar para atender este volume de trafego. Este trabalho identifica e estuda quais estratégias e métodos de arquitetura de software que foram empregados em alguns dos maiores web sites da internet para escalar, assim atendendo o crescente número de acessos e usuários. Alguns aspectos se mostraram relevantes para a escalabilidade de uma aplicação web, como a comunicação e distribuição das camadas, as formas de reutilização computacional e o impacto do particionamento dos dados. Ainda foi examinado a evolução da arquitetura dos web sites estudados. Palavras chaves: Escalabilidade, Aplicação Web, Arquitetura de Software

11 ix ABSTRACT With the increasing number of users connected to the Internet, some web sites have the challenging task of answering millions of simultaneous users, and be always available, without compromising performance. These users can reach the web site without forecasting and in a large number, which meet all factor is crucial to the success of the site. The most visited websites in the world have been successful in this scenario and provided some information about how it was possible to scale to meet the volume of traffic. This work identifies and examines which strategies and methods of software architecture that were employed in some of the major internet web sites to scale, so acting in response to the increasing number of hits and users. Some aspects were relevant to the scalability of a web application, such as layers communication and distribution, forms of computing reuse and the impact of partitioning the data. Was examined the evolution of the architecture of web sites studied. Keywords: Scalability, Web Application, Software Architecture

12 1 1. INTRODUÇÃO Com o número cada vez maior de usuários conectados a internet, alguns web sites tem a desafiadora tarefa de atender milhões de usuários simultâneos, e ainda estar sempre disponível, sem comprometer a performance. Esses usuários podem chegar ao web site sem previsão e em grande número, sendo que atender todos eles é fator crucial para o sucesso do site. O web site deve lançar mão de várias estratégias na sua arquitetura de software e infra-estrutura para atender todos esses requisitos e ainda continuar a crescer e, em alguns casos, ser flexível o bastante para poder encolher, dependendo do tráfego. Os web sites mais visitados no mundo foram bem sucedidos nesta tarefa, atendendo até bilhões de pageviews por dia e, alguns deles, disponibilizaram informações sobre como foi possível escalar para atender este volume de trafego. Porém, parte das informações disponibilizadas pelos web sites sobre suas arquiteturas foram feitas de forma informal, através de páginas na web ou blogs de funcionários. OBJETIVO O objetivo deste trabalho é investigar quais estratégias e evoluções nas arquiteturas de software foram empregadas em alguns dos maiores web sites da internet para escalar, e assim, atender o crescente número de acessos e usuários. Ficam fora do escopo deste trabalho outras partes importantes para a escalabilidade de uma aplicação web, como arquitetura de infra-estrutura e técnicas empregadas no software Client-side (Navegador Web). Também ficam fora outros requisitos não funcionais, como a alta-disponibilidade e performance, mesmo que em alguns casos esses requisitos possam ser satisfeitos ao se satisfazer o requisito de escalabilidade.

13 2 HIPÓSTESE Algumas hipóteses são levantadas neste trabalho. A primeira é de que exista um conjunto de propriedades das arquiteturas de softwares que são comuns entre os sites dos sites estudados. Isto permitiria uma classificação conforme estas propriedades. Dado essas propriedades comuns, a segunda hipótese é que o estudo transversal (não individual) entre os sites, permita um melhor entendimento dos métodos empregados e como esses métodos podem ser reutilizados em outros projetos. JUSTIFICATIVA O número de usuários que podem chegar a um web site impõe alguns desafios as tradicionais arquiteturas utilizadas para a construção de uma aplicação web. O intuito deste trabalho é auxiliar arquitetos de software na tomada de decisão sobre qual caminho devem escolher no momento de escalar uma aplicação web FONTE DE INFORMAÇÃO Como este trabalho tem a intenção de mostrar técnicas e modelos empregados por web sites comerciais, é importante ressaltar que algumas das fontes não são oficiais ou mesmo de pessoas ou empresas relacionadas ao web site. Na tentativa de garantir a precisão da informação, este trabalho segue as seguintes regras: Evidências: Algumas técnicas podem ser verificadas por evidencias e não é necessário que a empresa proprietária do web site divulgue sua utilização. Funcionários: Algumas empresas permitem que seus funcionários ou exfuncionários escrevam sobre seus trabalhos em blogs ou sites especializados. Ainda assim, muita dessas informações não é dada como oficial pela empresa proprietária do web site. Porém o blog ou web site é reconhecido por pertencer ao funcionário ou ex-funcionário da empresa e, logo, considerado uma fonte confiável para este trabalho.

14 3 No entanto, algumas empresas divulgam em seus blogs oficiais, sites especializados ou livros, informações sobre sua arquitetura e sua evolução. Essa informação será usada aqui neste trabalho com maior prioridade. Outra fonte importante utilizado neste trabalho é o site highscalability.com (Highscalability, 2009), especializado em compilar e divulgar informações sobre técnicas de escalabilidade e arquiteturas de web sites de alta escalabilidade SITES ESTUDADOS A maioria dos sites estudados são sites com um alto tráfego, sendo que a maioria está entre os principais sites da internet (Tab.1), com milhões de visualizações de páginas por dia. Outros são sites menos conhecidos, sites de nicho, mas com grande volume de acesso. Nessa lista ainda encontra-se sites menores, com médio volume de acesso, porém enfrentaram problemas de escalabilidade e disponibilizaram a documentação de sua arquitetura. Atuação Alexa Ranking Page Views per User (via Alexa) Amazon ecommerce Digg Social News ebay Social ecommerce FaceStats Fotos - - Flickr Fotos Google Busca LinkedIn Social Network LiveJournal Blog MySpace Social Network PlentyOfFish Relacionamento Slashdot Notícia 11, Twitter Micro Blog Wikipedia Conteúdo Social Tab.1 - Sites Estudados

15 4 A Tab.1 apresenta a lista dos sites estudados e seu respectivo ranking no Alexa (Alexa, 2009). O site Alexa é um serviço especializado em medir a audiência dos 100 mil principais sites da internet.

16 5 2. APLICAÇÃO WEB Segundo Henderson(2006), uma aplicação web é a junção da idéia de um web site (estático) e uma aplicação desktop, porém não é nenhum dos dois. Ou seja, tem características de web site e funcionalidades de uma aplicação desktop mas não pode ser enquadrado em nenhuma dessas características, pois um web site estático é formado por páginas estáticas, com nenhuma ou pouca interação com o usuário. As informações ali mostradas não são processadas, mas simplesmente entregues do servidor web no formato original ao cliente, geralmente um navegador web. Uma aplicação web tem a mesma idéia de entregar uma página ao cliente, porém essa página passa por um processamento para cada requisição feita ao servidor web. Já uma aplicação desktop tem a possibilidade de interação ampla com o usuário. Para isso utiliza do poder computacional (CPU, memória, etc.) local, do computador do usuário, para processar o que o usuário deseja fazer. Já a aplicação web tenta oferecer a mesma flexibilidade usando um misto de processamento local e processamento remoto, onde o processamento remoto é geralmente responsável por gravar e manipular os dados. O resumo feito por Henderson (2006) é que aplicações web são sistemas com um conjunto de dados central que pode ser acessado e modificado usando-se páginas web, com a possibilidade de outras interfaces (p.2). Tanto web sites estáticos e aplicações desktop ainda tem sua importância em diversos cenários, porém a utilização de aplicações web tem crescido muito como opção para cenários que antes eram exclusivos dessas outras tecnologias, principalmente porque amplia os limites que as duas tecnologias tem: iteratividade, personalização de um lado e poder de processamento e quantidade de informação do outro. Isso é importante ao sites que dependem de audiência ou empresas que querem vender seus produtos, pois segundo Arlitt(2001), personalization is desirable to boost repeat visits and increase revenue.

17 6 PADRÃO DE UTILIZAÇÃO Um dos fatores mais importantes para entender onde escalar uma aplicação web é entender como ela é utilizada pelos seus usuários e sistemas clientes. Conhecendo qual ação (leitura, gravação, etc.) e o conteúdo (página, web API, etc.) recebe mais requisições ou consome mais recursos do lado do servidor é possível tomar uma ação de escalonamento adequada. Normalmente, as aplicações web tem 80% de leitura e 20% de gravação, sendo que esse número varia dependendo principalmente do tipo da aplicação web. Os acessos também se concentram em poucas páginas, normalmente seguindo a distribuição parecida com a distribuição Zipf (Breslau, 1999, Padmanabhan 2000). Um exemplo de como o entendimento desse padrão é importante é o web site Digg.com (DiggA, 2009), onde a grande maioria dos usuário apenas acessam a página principal, lêem o conteúdo e deixam o site logo após. Assim, seu cache tem um "cache hit" (probabilidade de um item estar no cache) muito alto. Além disso, em seu banco de dados, 98% das ações são de leitura, fazendo o trabalho de escalabilidade muito mais fácil. Porém, o padrão de utilização de uma aplicação web pode variar drasticamente. Um desses motivos de variação são os robôs de busca, que varrem todo o site em busca de texto e outros links. Como a intenção desses robôs é varrer o maior número de página possível, isso invalida qualquer estratégia de escalabilidade baseada no padrão de utilização. Mas como não são freqüentes, é possível criar uma estratégia especifica para os robôs de busca. Um exemplo é desabilitar os caches e ler diretamente do banco de dados, deixando o cache válido para o padrão de utilização dos usuários e não do robô. Outro motivo que pode fazer uma aplicação web ter seu padrão de acesso alterado é quando um link do site é colocado em um web site que recebe muito acesso, geralmente um portal, fazendo com que parte desses usuários naveguem para aquela página especifica em um curto espaço de tempo. Esse efeito é conhecido na internet como "Slashdot effect" (Pilgrim, 2005). Isso se dá pois o site Slashdot.com costuma colocar links em sua página principal de sites menores.

18 7 Esses por sua vez recebem uma quantidade de usuários que não estavam acostumados e muitos não consegue escalar a tempo de atender a essa quantidade de usuários. Um exemplo do "Slashdot effect" aconteceu com o site FaceStat.com (FaceStat, 2009), que recebeu quase 650 mil visualizações de páginas simultâneas. O link de sua página principal foi para a página principal do portal Yahoo.com, com um volume de acesso muitas vezes maior do que o seu, o que levou ao site ficar fora do ar por um tempo considerável. Outros fatores podem alterar o padrão de uso da aplicação, como uma promoção de um produto ou personalizações de uma página para o usuário (Arlitt, 2001). Entender o padrão de utilização da aplicação web é extremamente importante para planejar o melhor modelo de escalabilidade.

19 8 3. ARQUITETURA DE SOFTWARE A arquitetura de software é extremamente importante para a escalabilidade de uma aplicação web, primeiro porque pode alterar o modo como a aplicação escala (Ebay, 2009), tornando mais eficaz o uso de recursos e porque pode ser o limitador da capacidade da aplicação escalar (DiggA, 2009). Segundo Fowler(2002), arquitetura de software é definido por dois aspectos: Arquitetura de software é a quebra de um sistema em partes menores, porém ainda com uma visão abstrata. A segunda definição é que arquitetura de software é onde mora as "decisões difíceis de serem alteradas". Quando se trata de escalabilidade de aplicações web esses dois pontos são muito importantes. Um sinal de que a arquitetura de uma aplicação tem qualidade, é quando as pequenas abstrações, as pequenas partes, têm responsabilidades bem definidas. Esse aspecto é importante pois quando chega o momento de refatorar a aplicação web para que ela se torne mais escalável (por ser um limitador ou melhorar o uso dos recursos), conhecer essas responsabilidades é fundamental, pois isso ajuda a atacar apenas aquelas partes que estão impedindo a escalabilidade. O segundo ponto, o da tomada de decisões difíceis de alteração, também é importante, pois as decisões de escalabilidade geralmente estão na base da arquitetura da aplicação. Escolher qual vai ser a arquitetura ou alterá-la implica em tomar decisões que levam em conta muitos fatores (técnicos, organizacionais e de negócios, por exemplo) e que se espera que seja robusta o suficiente de forma que não precise ser alterada. Assim, quando escalabilidade é um pré requisito para uma aplicação, é desejável que essas decisões levem a uma arquitetura que tenham o menor impacto possível nas futuras modificações do sistema. Este trabalho tenta focar exclusivamente em software. Porém algumas vezes, a plataforma de hardware pode influenciar na arquitetura de software (Henderson, 2006, p.16) e será abordado, mas apenas os pontos relevantes à arquitetura de software.

20 9 4. ESCALABILIDADE Existem algumas definições para escalabilidade. Segundo Hill(1990), um sistema é escalável quando sua performance melhora depois da adição de hardware, sendo essa melhora proporcional ao poder computacional do hardware adicionado. Uma definição parecida é dada em Amazon(2009). Porém, segundo (Henderson, 2006, p.204), escalabilidade não tem relação com performance e sim com a capacidade de acomodar o aumento do uso do sistema e da quantidade de dados adicionando hardware, sem perder a manutenibilidade. Uma definição mais ampla é dada por (Schlossnagle, 2006, p.5): Escalar significa quão bem uma solução particular se encaixa em um problema enquanto o escopo do problema aumenta. Neste trabalho, o problema estudado é o aumento de utilização de recursos computacionais causado pelo aumento de acessos e/ou aumento de personalização da aplicação web. Por isso, para este trabalho, escalar não implica necessariamente adição de mais hardware, pois a melhor utilização dos recursos computacionais existentes através da arquitetura de software pode também ser uma possível solução ao problema proposto. Isso vai de encontro com o problema enfrentando pelos web sites (Schlossnagle, 2006, p.9), que tendem a manter o custo baixo no começo de suas operações, minimizando os riscos. Sejam esses custos vindos da necessidade de mais hardware e por isso precisam maximizar a utilização dos recursos existentes, ou da complexidade em manutenção e por isso precisam manter as soluções arquiteturais simples. Assim, uma arquitetura escalável tem que ser também flexível para mudar conforme a necessidade do web site. O fato de um sistema ser escalável é uma característica momentânea. Ou seja, um sistema pode suportar cada vez mais acessos apenas adicionando mais hardware ou melhorando os algoritmos de cache, por exemplo. Mas a partir de um determinado número de acessos, a solução começa a não ter mais ganhos. Seja por

21 10 um problema de hardware ou software, o sistema encontra seu limite de escalabilidade e deixa de ser escalável para aquele novo cenário. Para continuar escalando, é necessário encontrar o limitador e substituí-lo por uma nova solução. ESCALABILIDADE VERTICAL Chama-se de escalabilidade vertical quando um sistema aumenta sua capacidade trocando o servidor que o hospeda por um servidor mais potente (mais memória RAM, harddisk ou CPU). Uma vantagem deste modelo de escalabilidade é que normalmente se ganha maior capacidade sem alteração no sistema. Ou seja, quanto maior a capacidade do hardware, maior será a capacidade do sistema. Para algumas partes do sistema, essa abordagem pode ser a mais apropriada como, por exemplo, o banco de dados (Plentyoffish, 2009), onde é possível escalar apenas colocando mais memória RAM. Porém, essa estratégia tem seus limites. Primeiro, o custo deste modelo não escala linearmente (Henderson, 2006, p.204): um servidor com 4 CPUs custa aproximadamente o mesmo que 4 servidores com apenas uma CPU, porém um servidor com 72 CPUs custa aproximadamente 3.5 vezes mais do que o 72 servidores com apenas uma CPU (Graf.1).

22 Custo 11 Múltiplos Servidores Único Servidor CPUs Graf.1 Escalabilidade Vertical x Escalabilidade Horizontal Fonte: Henderson, 2006 E mesmo que o custo não seja um limitador (o que é raro para um web site), se alcançaria o limite imposto pelo fabricante, seja no número de CPUs ou quantidade de memória, que um único servidor pode suportar. Um limite, este mais comum, é que nem todos os recursos deste novo hardware podem estar sendo usados se a arquitetura de software deste sistema não for eficiente. Um exemplo comum é o uso de CPU. Isso acontece quando o novo hardware cresce em número de CPUs, porém o sistema tem poucos processos paralelos (Threads), o que geralmente leva a baixa utilização das múltiplas CPUs. Sem alteração do sistema, alterar o hardware tem pouco impacto na escalabilidade do mesmo. ESCALABILIDADE HORIZONTAL A escalabilidade horizontal se difere da escalabilidade vertical, pois ao invés de substituir os hardwares atuais utilizado pela aplicação, apenas adiciona-se mais servidores, sem substituição.

23 12 O principal motivador para escalar horizontalmente é custo. Como apresentado anteriormente, quando é necessário muito poder computacional, adição de novos servidores comuns é muitas vezes mais barato que a substituição por servidores mais potentes. Além disso, não se perde o investimento feito no hardware atual quando se escala horizontalmente. Porém, fazer o escalonamento horizontal pode ser bem desafiador e até mais caro que o escalonamento vertical. O primeiro desafio começa na administração, que deve gerenciar muitos servidores (alguns casos chega-se até milhares) (Michael, 2007). Administrar a rede, configuração e deploy desses servidores não escalam nas mesmas proporções que os servidores (Henderson, 2006, p.206). A escolha do hardware também deve ser estudado com cuidado para não desperdiçar recursos. Por exemplo, pode-se comprar maquinas com uma boa quantidade de memória RAM, e com CPU e disco mais baratos, pois o servidor vai ser usado apenas para cache, intensivo em uso de memória, mas utiliza pouco processamento ou persiste quase nada em disco. É importante também escolher um hardware onde o custo de manutenção seja balanceado com o custo de troca (Henderson, 2006, p.206). Outro ponto que dificulta e pode custar mais caro para este tipo de escalonamento é a arquitetura de software, o ponto que é objeto de estudo deste trabalho. Se a arquitetura de software não estiver preparada para escalar de forma horizontal, adicionar mais servidores será em vão. ESCALABILIDADE, ALTA DISPONIBILIDADE E PERFORMANCE Alta disponibilidade e performance são algumas das características não funcionais que podem acompanhar um sistema quando este é escalável. Porém é importante ressaltar que são características distintas e podem não aparecer simultaneamente. A alta disponibilidade é dada quando uma requisição feita a um sistema sempre retorne um resultado. Para a alta disponibilidade é necessário que o sistema

24 13 tenha algum tipo de redundância, seja para processar informações ou armazenar dados. Para isso, adicionam-se hardwares e mecanismos para distribuir o trabalho entre os servidores. Para acomodar esse requisito, pode ser que o sistema venha também a ficar escalável, ou ao contrário, sendo que para escalar o sistema ganhe alta disponibilidade. Adicionando hardware ou alterando a arquitetura de um sistema para que este fique escalável, pode trazer também mais performance, mas novamente são características distintas, pois ao mesmo tempo que adicionar hardware acarreta em mais poder computacional, também traz maior número de conexões entre eles, o que pode prejudicar a performance. Assim, mesmo que escalabilidade, alta disponibilidade e performance sejam características de um sistema que podem proposital ou acidentalmente virem juntas, tem propriedades e atendem a requisitos distintos.

25 14 5. ESTRATÉGIAS Durante a construção e evolução de suas aplicações web, os web sites aqui estudados encontraram, de alguma forma, problemas de escalabilidade. Quando isto aconteceu, a primeira coisa a fazer foi encontrar o problema e, uma vez identificado, trazer uma estratégia para atacá-lo. Este trabalho propões evidenciar os problemas de escalabilidade enfrentados pelos web sites e as estratégias escolhidas para tentar solucionar estes problemas. Os tópicos estão divididos em três grandes grupos: Camadas: Como a divisão das camadas, seja lógica ou fisicamente, influencia na escalabilidade e na arquitetura de uma aplicação web. Reutilização Computacional: Quais formas de reutilização computacional foram empregadas pelos web sites estudados e como isso possibilitou receber maior tráfego. Particionamento de Dados: Quais as formas de particionamento de dado empregadas pelos web sites estudados e porque particionar é importante para escalar uma aplicação.

26 CAMADAS Quando se trata de arquitetura de software, a separação das responsabilidades é peça chave (talvez a mais importante) no processo de pensar um sistema. A intenção é sempre quebrar um problema maior em partes menores (Fowler, 2002), com responsabilidades bem definidas. Uma maneira de quebrar esses problemas e distribuir a responsabilidade entre elas é usando o que chama-se de camadas. Segundo Fowler(2002):... the hardest part of a layered architecture is deciding what layers to have and what the responsibility of each layer should be. Inicialmente estudada para sistemas operacionais (Dijkstra, 1968) e depois estudada de forma mais ampla (Parnas, 1972, Parnas, 1974, Parnas, 1976, Parnas, 1979), a idéia de camadas e suas responsabilidades é fundamental para a qualidade de um sistema, influenciando em vários de seus aspectos, principalmente a manutenibilidade e flexibilidade. No caso de uma aplicação web, a distribuição das responsabilidades das camadas e como elas se comunicam influencia também na sua escalabilidade Flexibilidade, Manutenibilidade e Escalabilidade Encontrar o balanceamento entre manutenibilidade e flexibilidade, e ainda assim manter o sistema escalável, é o motivo pelo qual o estudo das camadas e sua arquitetura é importante para uma aplicação web. Quanto mais camadas uma aplicação tem, maior será a sua manutenibilidade, porém com menor flexibilidade (Henderson, 2006, p.13). Ou seja, uma aplicação pode ter poucas camadas e assim terá maior flexibilidade ao se comunicar diretamente com as abstrações das camadas abaixo, sem precisar passar por abstrações intermediárias. Porém terá pouca manutenibilidade, pois provavelmente terá dificuldade em substituir essas camadas inferiores, caso necessário.

27 16 No entanto, uma aplicação com muitas camadas tem maior facilidade de manutenção, mas terá pouca flexibilidade em utilizar funcionalidades que as camadas abaixo não expõem. Uma distribuição de camadas bastante difundida e usada, principalmente por aplicações web, é a chamada "Arquitetura de Três Camadas" (Fowler, 2002), que contêm as camadas de apresentação, domínio (ou aplicação) e dados (ou persistência). O web site Flickr (Henderson, 2006, p.13), por exemplo, utiliza apenas uma arquitetura MVC na sua camada de apresentação e poucos frameworks, mas tende a criação de novas camadas conforme sua complexidade aumenta. Já o ebay (Ebay, 2009) tem suas camadas muito bem definidas: dados, aplicação, busca, operações, etc. É importante notar aqui que essa arquitetura vai além das três camadas mais conhecidas. A camada de persistência de dados é um ponto onde os web sites dão grande atenção. Por ser de difícil escalabilidade (ver outros tópicos: CAP, Sharding, Desnormalização), os bancos de dados tendem a ser o principal gargalo para estas aplicações (DiggA, 2009). Para evitar este gargalo, o ebay (Ebay, 2009) faz em algumas partes do sistema apenas operações simples na camada de persistência (no banco de dados) e deixa a responsabilidade de integridade referencial, joins e ordenações na camada de aplicação (ou de domínio). Apesar dessas operações serem normalmente feitas pelo banco de dados, neste caso é melhor ter menos utilização de CPU e I/O nos servidores de banco de dados e assim liberá-los para mais acessos. A razão para isto é que, segundo ebay, os servidores para a camada de aplicação são mais baratos, enquanto os de bancos de dados são o gargalo, difíceis de escalar. Outras formas de eliminar acesso ao banco de dados é vista no tópico Reutilização Computacional e Particionamento. O importante aqui é enfatizar a responsabilidade de cada camada, que dependendo da necessidade de escalabilidade, pode tomar responsabilidades que normalmente não lhe seriam atribuídas. Além disso, no caso do ebay, a manutenibilidade teve menos prioridade comparado com a capacidade que a aplicação tem de escalar.

28 Distribuição entre os servidores Outro ponto importante é a distribuição dessas camadas entre os servidores. O importante aqui não é, novamente, discutir a arquitetura de hardware, mas sim verificar como a distribuição física das camadas pode influenciar a arquitetura de software. Basicamente tem-se dois tipos de distribuição: servidores com todas as camadas em cada um deles (conhecido como Shared Nothing) ou servidores dedicados a uma camada ou responsabilidade (por exemplo, Applicantion Servers e SOA) Shared Nothing Uma maneira de se transformar uma solução de um problema em uma solução escalável é através da remoção dos recursos compartilhados. Assim, cada elemento da solução é autônomo e não interfere no trabalho do elemento ao seu lado, já que nada compartilham. Logo, podem-se acrescentar quantos elementos se quer, escalando linearmente. Isso se aplica para uma aplicação web (Flickr, 2009), uma CPU (Stonebraker, 1986) ou qualquer outra solução escalável. Aplicando essa lógica ao extremo às camadas de uma aplicação web, cada servidor teria tudo o que é preciso para rodar a aplicação web, da camada de apresentação a camada de persistência, incluindo o banco de dados. Assim, quando uma requisição fosse feita, ela iria ser executada do começo ao fim por um dos servidores. Se houverem 100 usuários simultâneos e cada servidor suportar 20 usuários cada, tem-se que ter 5 servidores para atende-los (Exp.1). Máximo Usuários Simultâneos Desejado Quantidade Usuários por Servidor = Servidores Exp.1 - Escalabilidade Linear Além disso, se obtém confiabilidade e performance. Confiabilidade pois, caso um dos servidores deixe de responder, isso não irá penalizar o trabalho de nenhum dos outros servidores, a não ser pela maior quantidade de requisições que eles tem

29 18 que atender. Todos os outros continuam a responder, pois não dependem um do outro. E performance, pois operações de I/O feitas em uma mesma máquina são normalmente mais rápidas do que se feitos através de um I/O de rede. A Fig.1 ilustra uma distribuição Shared Nothing. Cluster Load Balance ServerN Web Aplication Cache Server1 Server2 Server3 ServerN Database Fig.1 Shared Nothing Do ponto de vista da arquitetura de software e objetos distribuídos, a complexidade de ter camadas no mesmo servidor tende a ser muitas vezes menor do que camadas distribuídas. Fowler(2002) discute os benefícios de ter uma arquitetura não distribuída e chega a proclamar: First Law of Distributed Object Design: Don't distribute your objects. Porém, as aplicações web nem sempre tem o privilégio de poderem ter todas as camadas e suas dependências em apenas um servidor. Alguns dos motivos mais comuns são bancos de dados compartilhados, comunicação com sistemas ou serviços externos e dificuldade de deploy em múltiplos servidores, conforme ilustra a Fig.2. Ainda assim, quanto menor a dependência entre os servidores, maior a possibilidade de escalabilidade.

30 19 Cluster Load Balance ServerN Web Aplication Cache Server1 Server2 Server3 ServerN Cluster Load Balance ServerN Database Server1 Server2 Server3 ServerN Fig.2 - Shared Nothing com Banco de Dados separado Por Camada Uma forma bastante usada para escalar uma aplicação foi a distribuição das três camadas em servidores distintos, um para cada camada, conforme mostra a Fig.3. Web Aplicação Cache Database Fig.3 - Por Camada

31 20 Assim, cada camada (apresentação, aplicação e persistência) tem seu conjunto de servidores dedicados. Quando há a necessidade de atender um número maior de usuários, escalase apenas a camada que se tornou o gargalo de escalabilidade. Normalmente essa distribuição é prejudicada em sua escalabilidade por tentar compartilhar estado, ou seja, os servidores de uma determinada camada compartilham, por exemplo, dados de um usuário, sessão ou uma determinada transação. Manter o gerenciamento de estado do lado do servidor e transações distribuídas, estudados nos tópicos CAP e Sharding, são um problema para escalabilidade. Mas é possível construir aplicações onde algumas camadas utilizam o princípio discutido acima, Shared Nothing, para evitar esses problemas (Ebay, 2009). Ou seja, os servidores de uma mesma camada não têm conhecimento sobre seus pares. Como descrito antes, outro problema deste tipo de distribuição é que a complexidade do software aumenta, pois é necessário criar uma camada para abstrair as chamadas remotas (RPC, SOAP, etc.). Além disso, qualquer chamada feita através da rede é mais custosa em termos de I/O que uma chamada local, no mesmo servidor. Foi observado entre os sites estudados que este tipo de distribuição não é a mais usada, porém algumas camadas ainda hoje são mais fáceis de escalar se isoladas, como é o caso de banco de dados. Como o SQL já é uma linguagem pensada de modo distribuído (Fowler, 2002), ter o banco de dados em servidores separados não aumenta a complexidade da arquitetura da aplicação SOA - Service-oriented architecture Outra forma de escalar uma aplicação é usando SOA (Service Oriented Architecture). A idéia de utilizar SOA para escalabilidade de uma aplicação web é separar responsabilidades, e não camadas, da aplicação e escalar individualmente essas partes. Cada uma dessas responsabilidades teria sua própria arquitetura interna, com suas camadas, e diferentes problemas de escalabilidade.

32 21 SOA tem algumas definições distintas, mas usaremos a seguinte: segundo (Barry, 2003, p.19), duas ideais básicas estão por trás dessa arquitetura: Serviço e Conexão. Um serviço é uma função bem definida, autônoma e não depende do contexto e do estado de outros serviços. Para fazer a conexão, utiliza-se o protocolo de transferência HTTP para fazer a comunicação entre os sistemas. Para a formatação dos dados, apesar de não ser um padrão, é normalmente feito via XML ou, mais recentemente, JSon. Por exemplo, imaginando uma aplicação web que tivesse um módulo de autenticação, publicação de conteúdo e publicação de comentários, poderia-se ter um serviço para cada uma dessas responsabilidades, conforme ilustrado na Fig.4. Serviços Internos Serviços Externos Publicador Search Comentários Produtos Fig.4 - SOA A Amazon (Amazon, 2009), por exemplo, tinha inicialmente uma arquitetura monolítica e, para poder escalar, mudou para uma arquitetura totalmente descentralizada, voltada a serviço. Hoje, tanto seus sistemas internos como suas APIs publicas usam serviço. Segundo o seu CTO, Werner Vogels, para construir uma página da Amazon, pode se necessário chamar mais de cem serviços. Outro

33 22 exemplo é o Digg (DiggA, 2009), que utiliza extensivamente serviços, tanto internamente como para suas APIs. Comparada com a distribuição de servidores por camada, SOA tem algumas vantagens para a escalabilidade de uma aplicação. A primeira é o fato de ser independente de estado (stateless), logo, não existe transações distribuídas ou gerenciamento de estado entre os serviços. Outra vantagem é a comunicação padronizada, utilizando HTTP e XML, ou seja, independente de uma tecnologia ou fornecedor. Ainda assim, os dois tipos de arquitetura compartilham o custo das chamadas remotas. Independente de qual seja a distribuição de camadas entre os servidores, todos eles provavelmente acabam com uma arquitetura mista, onde Shared Nothing, distribuição por camada e SOA se misturam (Fig.5). Publicador Cluster1 Cluster DB Web Aplication Database Cache Search Fig.5 - Arquitetura Mista

34 Mensagens Assíncronas Normalmente, quando uma funcionalidade de uma das camadas é chamada, espera-se um resultado o mais rápido possível. Por exemplo, uma pesquisa no banco de dados (Fig.6). User Interface Aplicação Repositório Obter Comentários Obter Lista Comentários Lista Comentários Lista Comentários Fig.6 - Processo Síncrono Porém, em alguns cenários, nem sempre é preciso ter um retorno rápido ou mesmo ter um retorno em si. Um exemplo é o envio de um recado aos amigos em uma rede social. Ao mesmo tempo em que é importante que essa mensagem apareça o mais rápido possível aos amigos, não é mandatório que seja em tempo real (Twitter, 2009). São nesses cenários que, ao invés de chamar uma funcionalidade de uma camada de forma síncrona, simplesmente envia-se uma mensagem e a camada é responsável por ler essa mensagem, de forma assíncrona (Fig.7).

35 24 Usuário 2 Usuário 1 UI Aplicação Repositório Mandar Recado Mandar Recado Recado Enviado Gravar Recado Mensagem Assíncrona Recado Enviado Obter Recados Obter Recado Obter Lista Recado Efetivação da Operação Lista Vazia (Repositório ainda não processou) Lista Recados Vazia Lista Recados Vazia Gravar Recado Obter Recados Obter Recado Obter Lista Recado Lista com recados do Usuário 1 Lista Recados Lista Recados Fig.7 - Mensagem Assíncrona Quando falamos de um ambiente extremamente distribuído, mensagens assíncronas tem um papel importante. Segundo Hohpe(2003), asynchronous messaging is fundamentally a pragmatic reaction to the problems of distributed systems. Ainda segundo Hohpe(2003), mensagens assíncronas tem algumas vantagens. A primeira é que a camada consumidora da mensagem tem flexibilidade para consumir essas mensagens conforme sua capacidade e não corre o risco de sofre uma parada por excesso de requisições. Para a escalabilidade de uma aplicação web isto é importante, pois o que vai determinar se é necessário ou não escalar esta camada consumidora é o tempo ao qual a mensagem deve ser consumida. Assim, a necessidade de escalabilidade é proporcional ao tempo de consumo das mensagens. Em outras palavras: para cenários onde o consumo da mensagem deve ser rápido, talvez seja necessário muito poder computacional. Já para cenários onde a velocidade não é importante, estes ganham menos peso no momento de escalar.

36 25 Além disso, como o produtor da mensagem não espera a finalização da requisição, liberam-se recursos para atender novas requisições do lado do produtor. Por exemplo: um pedido de uma página que deve salvar um comentário, que será persistido em um banco de dados. Caso a requisição ao banco de dados demore a finalizar, o recurso computacional que poderia atender outro usuário está agora preso até que a requisição termine. A melhor forma de liberar este recurso é fazê-lo de forma assíncrona. Dessa forma o comentário é salvo quando a camada de banco de dados estiver livre e o processo que recebe requisições de páginas está livre para atender novos pedidos. Outra vantagem na utilização de mensagens assíncronas é que as mensagens podem ser gravadas assim que enviadas e, se caso um dos sistemas não estiver disponível no momento, as mensagens podem ser consumidas posteriormente, melhorando assim outro aspecto do sistema: a confiabilidade. Ao mesmo tempo em que esta técnica resolve alguns problemas de escalabilidade, traz consigo complexidades que não existiam na forma síncrona. As principais são: ordenação das mensagens, quando é necessário manter a ordem das mensagens para se ter consistência da operação; padronização do formato e do protocolo da mensagem, para que a camada consumidora entenda a camada produtora da mensagem; repositório de mensagem, que é o local onde as mensagens vão ser gravadas e lidas; e dificuldade para obter o resultado da operação efetuada pela mensagem, já que uma vez envidada, a mensagem perde o contato com a camada produtora. Porém, quando se tem um ambiente distribuído, com alto volume de tráfego, a complexidade é um preço a ser pago, não restando outra opção. Tanto é assim que esta técnica é empregada em vários cenários pelos web sites: - Atualizar e manter consistência de dados particionados (DiggB, 2009, Linkedin, 2009): Ao invés de se fazer várias chamadas síncronas entre os bancos de dados, é possível enviar uma mensagem para cada camada responsável por aquele dado e deixar a responsabilidade atualizá-los para esta camada. O problema aqui é a consistência dos dados. Mais sobre as vantagens e desvantagens dessa solução serão vistas nos tópicos CAP e Sharding.

37 26 - Invalidar caches (Twitter, 2009): Mesmo quando os dados já estão salvos no repositório, invalidar as várias camadas de cache ou lugares onde aquele dado está no cache, pode ser uma tarefa custosa se feita de forma síncrona. Uma estratégia é enviar uma mensagem de forma assíncrona para que um sistema invalide o dado nos caches. - Realizar trabalhos paralelo em geral (DiggB, 2009, Livejournal, 2009): Para montar uma página com várias informações, pode-se fazer uma requisição para cada recurso de forma assíncrona, paralela, e no final esperar até que todas as requisições terminem. Assim, o máximo de tempo que se espera para construir uma página é o tempo da requisição que mais tempo levou para retornar e não a soma de todos os tempos das requisições, caso fosse feito de forma serial. Quanto menos tempo para construir a página, mais recursos são liberados para atender novas requisições.

38 REUTILIZAÇÃO COMPUTACIONAL Um dos pontos mais críticos na escalabilidade de uma aplicação web é o banco de dados. Seja qual for a tecnologia usada ou o tipo de banco de dados (RDBMS, ORDBMS, Document-oriented, etc.), o banco de dados tem que persistir e ler os dados da aplicação web da forma mais consistente possível e ainda assim atender e processar o máximo de requisições possíveis. Manter a consistência dos dados é uma tarefa árdua em um ambiente distribuído, pois para isso é necessário, em algum momento, um ponto de sincronização (detalhes no tópico CAP). Compartilhar um estado, como constatado no tópico Shared Nothing, neste caso o ponto de sincronização, é um característica que dificulta (e pode impedir) a escalabilidade dessa camada. Não é tarefa complicada sincronizar os dados entre dois ou três servidores de banco de dados. Porém a complexidade de manter a consistência entre os servidores cresce exponencialmente conforme a quantidade de servidores aumenta. Por sua dificuldade de escalabilidade, tenta-se evitar o acesso a esta camada (Plentyoffish, 2009), usando-a apenas quando estritamente necessário. Um dos modos de fazer isso é através de reutilização computacional (Schlossnagle, 2006, p.109), ou seja, guarda-se um valor que foi previamente calculado para futuro reuso. Porém, a reutilização computacional pode ir além do banco de dados. É possível guardas os dados vindos da camada de aplicação ou mesmo da camada de apresentação, poupando essas camadas, evitando reprocessamento e, assim, atendendo mais usuários. A seguir serão apresentados como as estratégias de desnormalização dos dados, utilização de cache e criação de conteúdo estático foram usadas pelos web sites e ajudaram a atender mais requisições, evitando escalar as camadas com recursos compartilhados.

39 Desnormalização Manter dados em um único lugar, sem duplicá-los, tem seus benefícios. Entre os principais está o ganho de integridade e a facilidade de manipulação desses dados. Essas são as idéias centrais por trás dos bancos de dados relacionais e a normalização de dados (Codd, 1970). Porém, para agrupar esses dados é necessário gastar processamento e I/O. Dependendo da complexidade do agrupamento ("Join" ou "Group By", por exemplo), processá-lo pode ser bem custoso. Agrupar muitas tabelas ou tabelas com muitos dados em um banco de dados relacional exige muito uso de CPU, memória e disco. Para evitar o custo de agrupar esses dados, e assim não gastar recursos do banco de dados, é possível manter uma cópia desnormalizada dos dados. Ao invés de pedir ao banco de dados para agrupar esses dados a cada requisição, com consultas (SQL) complexas, acessa-se a tabela que contém os dados já agrupados (PlentyoffIsh, 2009, Twitter, 2009) com simples consultas. A desnormalização é uma estratégia comum (Henderson, 2006, p.200) e muito usada entre os sites estudados. Um exemplo para ilustrar este problema é a nuvem de tags. Uma nuvem de tags é a representação gráfica da utilização das tags em um determinado objeto. O web site Flickr (Flickr, 2009), por exemplo, permite que os usuários coloquem tags nas fotos enviadas e mostra em uma de suas páginas as tags mais utilizadas (Fig.8).

40 29 Fig.8 - Nuvem de Tags do Flickr Este problema envolve agrupar os dados únicos, as tags de cada foto dos usuários, em um único lugar, a página de nuvem de tags. Obviamente, não faz sentido calcular a nuvem de tags para cada requisição da página que contém a nuvem, pois o custo para processá-la é muito alto. Uma das soluções é manter as tabelas normalizadas com os dados de cada foto e suas tags e manter uma tabela desnormalizada, já com os valores agregados (Fig.9). PK Foto FotoID Campo que mantém o valor desnormalizado SELECT COUNT(*) FROM FotoTag WHERE TagID = [Tag.TagID] FotoTag Tag PK,FK1 PK,FK2 FotoID TagID PK TagID Count Fig.9 - Modelo com valor desnormalizado O problema em desnormalizar os dados é justamente manter a consistência entre eles. Neste exemplo de nuvem de tags, por exemplo, agora temos a mesma informação em dois lugares (as tabelas normalizadas e a tabela desnormalizada).

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais

23/05/12. Computação em Nuvem. Computação em nuvem: gerenciamento de dados. Computação em Nuvem - Características principais Computação em Nuvem Computação em nuvem: gerenciamento de dados Computação em nuvem (Cloud Computing) é uma tendência recente de tecnologia cujo objetivo é proporcionar serviços de Tecnologia da Informação

Leia mais

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE

CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE CENTRO UNIVERSITÁRIO UNA DIRETORIA DE EDUCAÇÃO CONTINUADA, PESQUISA E EXTENSÃO CURSO DE PÓS GRADUAÇÃO ENGENHARIA DE SOFTWARE NoSQL Banco de Dados Não Relacional ALUNO: Heitor Oliveira Silva PROFESSOR ORIENTADOR:

Leia mais

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

Leia mais

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa.

Um cluster de servidores de email pode ser usado para servir os emails de uma empresa. CLUSTERS Pode-se pegar uma certa quantidade de servidores e juntá-los para formar um cluster. O serviço então é distribuído entre esses servidores como se eles fossem uma máquina só. Um cluster de servidores

Leia mais

Arquiteturas escaláveis utilizando ferramentas Shared Nothing. Victor Canô

Arquiteturas escaláveis utilizando ferramentas Shared Nothing. Victor Canô Arquiteturas escaláveis utilizando ferramentas Shared Nothing Victor Canô Victor Canô - Founder / CTO @ Cazamba - Founder @ Troz.io /victoracano Conteúdo O que esperamos de uma aplicação? Cloud, benefícios

Leia mais

Banco de Dados Distribuídos

Banco de Dados Distribuídos A imagem não pode ser exibida. Talvez o computador não tenha memória suficiente para abrir a imagem ou talvez ela esteja corrompida. Reinicie o computador e abra o arquivo novamente. Se ainda assim aparecer

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

Engenharia de Software Aplicações de Internet

Engenharia de Software Aplicações de Internet Engenharia de Software Aplicações de Internet Eduardo Santos eduardo.edusantos@gmail.com eduardo.santos@planejamento.gov.br www.softwarepublico.gov.br Histórico Por que existe a Internet? Por que existe

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

ARQUITETURA TRADICIONAL

ARQUITETURA TRADICIONAL INTRODUÇÃO Atualmente no universo corporativo, a necessidade constante de gestores de tomar decisões cruciais para os bons negócios das empresas, faz da informação seu bem mais precioso. Nos dias de hoje,

Leia mais

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS

MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS MÓDULO 8 ARQUITETURA DOS SISTEMAS DE BANCO DE DADOS Quando falamos em arquitetura, normalmente utilizamos esse termo para referenciar a forma como os aplicativos computacionais são estruturados e os hardwares

Leia mais

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos Sistemas Distribuídos Sistemas de Arquivos Distribuídos Roteiro Sistema de arquivos distribuídos Requisitos Arquivos e diretórios Compartilhamento Cache Replicação Estudo de caso: NFS e AFS Sistemas Distribuídos

Leia mais

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc. Implementar servidores de Web/FTP e DFS Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.br Conteúdo programático Introdução ao protocolo HTTP Serviço web

Leia mais

Engenharia de software 2011A. Trabalho sobre

Engenharia de software 2011A. Trabalho sobre Engenharia de software 2011A Trabalho sobre NOSQL Not only SQL NoSQL Not only SQL GRUPO - 9 Cléverton Heming Jardel Palagi Jonatam Gebing Marcos Wassem NOSQL O Termo NoSQL, foi utilizado pela primeira

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

Modelos e Arquiteturas de Sistemas Computacionais

Modelos e Arquiteturas de Sistemas Computacionais Modelos e Arquiteturas de Sistemas Computacionais Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas SUMÁRIO Importância da definição da Arquitetura

Leia mais

Uma solução de desempenho para a distribuição de documentos: Habilitando a distribuição de documentos em tempo real para corporações globais

Uma solução de desempenho para a distribuição de documentos: Habilitando a distribuição de documentos em tempo real para corporações globais Uma solução de desempenho para a distribuição de documentos: Habilitando a distribuição de documentos em tempo real para corporações globais Visão Geral Desafio Hoje, os aplicativos da web são um tremendo

Leia mais

Pollyanna Gonçalves. Seminário da disciplina Banco de Dados II

Pollyanna Gonçalves. Seminário da disciplina Banco de Dados II Pollyanna Gonçalves Seminário da disciplina Banco de Dados II Web 2.0 vem gerando grande volume de dados Conteúdo gerado por redes sociais, sensores inteligentes, tecnologias de colaboração, etc. Novas

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

Introdução ao Modelos de Duas Camadas Cliente Servidor Introdução ao Modelos de Duas Camadas Cliente Servidor Desenvolvimento de Sistemas Cliente Servidor Prof. Esp. MBA Heuber G. F. Lima Aula 1 Ciclo de Vida Clássico Aonde estamos? Page 2 Análise O que fizemos

Leia mais

Desenvolvendo para WEB

Desenvolvendo para WEB Nível - Básico Desenvolvendo para WEB Por: Evandro Silva Neste nosso primeiro artigo vamos revisar alguns conceitos que envolvem a programação de aplicativos WEB. A ideia aqui é explicarmos a arquitetura

Leia mais

Sistema de Arquivos Distribuídos

Sistema de Arquivos Distribuídos Sistema de Arquivos Distribuídos Sistema de Arquivos Distribuídos A interface cliente para um sistema de arquivos é composta por um conjunto de primitivas e operações em arquivos (criar, apagar, ler, escrever)

Leia mais

Arquitetura dos Sistemas de Informação Distribuídos

Arquitetura dos Sistemas de Informação Distribuídos Arquitetura dos Sistemas de Informação Distribuídos Quando se projeta um sistema cuja utilização é destinada a ser feita em ambientes do mundo real, projeções devem ser feitas para que o sistema possa

Leia mais

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados

Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Tópicos de Ambiente Web Conceitos Fundamentais Redes de Dados Professora: Sheila Cáceres Computador Dispositivo eletrônico usado para processar guardar e tornar acessível informação. Tópicos de Ambiente

Leia mais

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados SISTEMA DE BANCO DE DADOS Banco e Modelagem de dados Sumário Conceitos/Autores chave... 3 1. Introdução... 4 2. Arquiteturas de um Sistema Gerenciador... 5 3. Componentes de um Sistema... 8 4. Vantagens

Leia mais

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios?

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? RESUMO DA SOLUÇÃO CA ERwin Modeling Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? O CA ERwin Modeling fornece uma visão centralizada das principais definições de

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

The Eucalyptus Open- source Cloud-computing System. Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva

The Eucalyptus Open- source Cloud-computing System. Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva The Eucalyptus Open- source Cloud-computing System Janaina Siqueira Lara Wilpert Marcelo Scheidt Renata Silva Sumário Introdução Trabalhos Correlatos Eucalyptus Design Conclusões Visão Geral Introdução:

Leia mais

Apresentação do Artigo

Apresentação do Artigo Apresentação do Artigo Web Search for a Planet: The Google Cluster Architecture Publicado em IEEE Micro Março 2003, pg.22-28 Luiz A.Barroso, Jeffrey Dean, Urs Hölze Frank Juergen Knaesel fknaesel@inf.ufsc.br

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais

Leia mais

Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01

Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01 Treinamento PostgreSQL Cluster de Banco de Dados - Aula 01 Eduardo Ferreira dos Santos SparkGroup Treinamento e Capacitação em Tecnologia eduardo.edusantos@gmail.com eduardosan.com 13 de Junho de 2013

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Criação de um Ambiente Web de Alto Desempenho para o Portal do CEULP/ULBRA

Criação de um Ambiente Web de Alto Desempenho para o Portal do CEULP/ULBRA Criação de um Ambiente Web de Alto Desempenho para o Portal do CEULP/ULBRA Valdirene da Cruz Neves Júnior, Jackson Gomes de Souza Curso de Sistemas de Informação Centro Universitário Luterano de Palmas

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Bancos de Dados Distribuídos Conceitos e Arquitetura Vantagens das Arquiteturas C/S (em relação

Leia mais

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos

Capítulo 8. Sistemas com Múltiplos Processadores. 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos Capítulo 8 Sistemas com Múltiplos Processadores 8.1 Multiprocessadores 8.2 Multicomputadores 8.3 Sistemas distribuídos 1 Sistemas Multiprocessadores Necessidade contínua de computadores mais rápidos modelo

Leia mais

Torne seu site mais rápido e venda mais

Torne seu site mais rápido e venda mais Torne seu site mais rápido e venda mais Descubra como criar uma estratégia de aceleração de sites que deixe seu site mais rápido e aumente sua conversão UAIZO A Uaizo ajuda a sua empresa a definir a estratégia

Leia mais

Capítulo 8 Arquitetura de Computadores Paralelos

Capítulo 8 Arquitetura de Computadores Paralelos Capítulo 8 Arquitetura de Computadores Paralelos Necessidade de máquinas com alta capacidade de computação Aumento do clock => alta dissipação de calor Velocidade limitada dos circuitos => velocidade da

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas Criação de uma Serviço de Geração de Relatórios Goiânia 12/2011 Versionamento 12/12/2011 Hugo Marciano... 1.0

Leia mais

ATIVIDADES PRÁTICAS SUPERVISIONADAS

ATIVIDADES PRÁTICAS SUPERVISIONADAS ATIVIDADES PRÁTICAS SUPERVISIONADAS Ciência da Computação 5ª série Sistemas Operacionais A atividade prática supervisionada (ATPS) é um método de ensinoaprendizagem desenvolvido por meio de um conjunto

Leia mais

A Estrutura da Web. Redes Sociais e Econômicas. Prof. André Vignatti

A Estrutura da Web. Redes Sociais e Econômicas. Prof. André Vignatti A Estrutura da Web Redes Sociais e Econômicas Prof. André Vignatti A Estrutura da Web Até agora: redes onde unidades eram pessoas ou entidades sociais, como empresas e organizações Agora (Cap 13, 14 e

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 04 SGBD Sistemas Gerenciadores de Bancos de Dados Prof. MSc. Edilberto Silva edilms@yahoo.com Conceitos Básicos DADOS: são fatos em sua forma primária. Ex: nome do funcionário,

Leia mais

Foglight A solução ideal para o gerenciamento de aplicações e serviços SAP

Foglight A solução ideal para o gerenciamento de aplicações e serviços SAP Parceria: Foglight A solução ideal para o gerenciamento de aplicações e serviços SAP Uma nova visão no Gerenciamento da Aplicação INDICE 1. Parceria Union e Quest Software... 3 2. Foglight Gerenciando

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Cluster, Grid e computação em nuvem Slide 8 Nielsen C. Damasceno Introdução Inicialmente, os ambientes distribuídos eram formados através de um cluster. Com o avanço das tecnologias

Leia mais

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS -ARQUITETURAS DE APLICAÇÃO MÓVEL. Prof. Angelo Augusto Frozza, M.Sc. http://about.

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS -ARQUITETURAS DE APLICAÇÃO MÓVEL. Prof. Angelo Augusto Frozza, M.Sc. http://about. PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS -ARQUITETURAS DE APLICAÇÃO MÓVEL Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza ROTEIRO Introdução Cliente-Servidor Cliente Servidor Tipos de conexão

Leia mais

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes

Leia mais

Autoria Web Apresentação e Visão Geral sobre a Web

Autoria Web Apresentação e Visão Geral sobre a Web Apresentação e Visão Geral sobre a Web Apresentação Thiago Miranda Email: mirandathiago@gmail.com Site: www.thiagomiranda.net Objetivos da Disciplina Conhecer os limites de atuação profissional em Web

Leia mais

Uma Breve Introdução. Andréa Bordin

Uma Breve Introdução. Andréa Bordin Uma Breve Introdução Andréa Bordin O que significa? NoSQL é um termo genérico que define bancos de dados não-relacionais. A tecnologia NoSQL foi iniciada por companhias líderes da Internet - incluindo

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Softwares de Sistemas e de Aplicação

Softwares de Sistemas e de Aplicação Fundamentos dos Sistemas de Informação Softwares de Sistemas e de Aplicação Profª. Esp. Milena Resende - milenaresende@fimes.edu.br Visão Geral de Software O que é um software? Qual a função do software?

Leia mais

Bancos de Dados Distribuídos. Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte

Bancos de Dados Distribuídos. Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte Bancos de Dados Distribuídos Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte Conceitos Sistema distribuído. Banco de dados distribuído (BDD). Coleção de multiplos

Leia mais

CAPÍTULO 2. Este capítulo tratará :

CAPÍTULO 2. Este capítulo tratará : 1ª PARTE CAPÍTULO 2 Este capítulo tratará : 1. O que é necessário para se criar páginas para a Web. 2. A diferença entre páginas Web, Home Page e apresentação Web 3. Navegadores 4. O que é site, Host,

Leia mais

Aluno: Paulo Roberto Alves de Oliveira Trabalho da disciplina Segurança em Windows 2010. Comparativo entre Apache e IIS.

Aluno: Paulo Roberto Alves de Oliveira Trabalho da disciplina Segurança em Windows 2010. Comparativo entre Apache e IIS. Aluno: Paulo Roberto Alves de Oliveira Trabalho da disciplina Segurança em Windows 2010 Comparativo entre Apache e IIS. Apache versus IIS 1. Resumo Os programas de computador Apache, da fundação Apache

Leia mais

COMPUTAÇÃO EM GRID COM BANCO DE DADOS ORACLE 10g

COMPUTAÇÃO EM GRID COM BANCO DE DADOS ORACLE 10g COMPUTAÇÃO EM GRID COM BANCO DE DADOS ORACLE 10g Daniel Murara Barcia Especialista em Sistemas de Informação Universidade Federal do Rio Grande do Sul daniel@guaiba.ulbra.tche.br Resumo. Esse artigo aborda

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática /

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços

Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Alinhando a infra-estrutura de aplicações com os negócios através de Application Delivery orientado a serviços Visão Geral Desafio Solução Uma implementação SOA (Service Oriented Architecture) bem-sucedida

Leia mais

BANCO DE DADOS CONTEÚDO INFORMÁTICA. Prof.: MARCIO HOLLWEG mhollweg@terra.com.br BANCO DE DADOS SGBD TABELA CONCEITOS BÁSICOS

BANCO DE DADOS CONTEÚDO INFORMÁTICA. Prof.: MARCIO HOLLWEG mhollweg@terra.com.br BANCO DE DADOS SGBD TABELA CONCEITOS BÁSICOS CONTEÚDO HARDWARE - 2 AULAS SISTEMA OPERACIONAL - 2 AULAS INFORMÁTICA Prof.: MARCIO HOLLWEG mhollweg@terra.com.br APLICATIVOS OFFICE - 3 AULAS INTERNET - 1 AULA REDE - 2 AULA SEGURANÇA - 1 AULA BANCO DE

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Basedos na Web Capítulo 12 Agenda Arquitetura Processos Comunicação Nomeação Sincronização Consistência e Replicação Introdução

Leia mais

Sistema BuildParty para montagem e gerenciamento de eventos. Plano de Testes. Versão <1.1> DeltaInfo. Soluções para web Soluções para o mundo

Sistema BuildParty para montagem e gerenciamento de eventos. Plano de Testes. Versão <1.1> DeltaInfo. Soluções para web Soluções para o mundo Sistema BuildParty para montagem e gerenciamento de eventos Plano de Testes Versão DeltaInfo Soluções para web Soluções para o mundo DeltaInfo 2 Histórico de Revisões Data Versão Descrição Autores

Leia mais

08/04/2013. Agenda. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ

08/04/2013. Agenda. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ Agenda Caché Server Pages Uma Aplicação Banco de Dados Fernando Fonseca Ana Carolina Salgado Mestrado Profissional 2 SGBD de alto desempenho e escalabilidade Servidor de dados multidimensional Arquitetura

Leia mais

O que são sistemas supervisórios?

O que são sistemas supervisórios? O que são sistemas supervisórios? Ana Paula Gonçalves da Silva, Marcelo Salvador ana-paula@elipse.com.br, marcelo@elipse.com.br RT 025.04 Criado: 10/09/2004 Atualizado: 20/12/2005 Palavras-chave: sistemas

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

Service Oriented Architecture SOA

Service Oriented Architecture SOA Service Oriented Architecture SOA Arquitetura orientada aos serviços Definição: Arquitetura de sistemas distribuídos em que a funcionalidade é disponibilizada sob a forma de serviços (bem definidos e independentes)

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Questões Em uma rede de sobreposição (overlay), mensagens são roteadas de acordo com a topologia da sobreposição. Qual uma importante desvantagem

Leia mais

LISTA DE EXERCÍCIOS. Mede a capacidade de comunicação de computadores e dispositivos. Operam em diferentes plataformas de hardware

LISTA DE EXERCÍCIOS. Mede a capacidade de comunicação de computadores e dispositivos. Operam em diferentes plataformas de hardware 1. A nova infra-estrutura de tecnologia de informação Conectividade Mede a capacidade de comunicação de computadores e dispositivos Sistemas abertos Sistemas de software Operam em diferentes plataformas

Leia mais

Administração de Banco de Dados

Administração de Banco de Dados Administração de Banco de Dados Professora conteudista: Cida Atum Sumário Administração de Banco de Dados Unidade I 1 INTRODUÇÃO A BANCO DE DADOS...1 1.1 Histórico...1 1.2 Definições...2 1.3 Importância

Leia mais

Definição de Padrões. Padrões Arquiteturais. Padrões Arquiteturais. Arquiteturas de Referência. Da arquitetura a implementação. Elementos de um Padrão

Definição de Padrões. Padrões Arquiteturais. Padrões Arquiteturais. Arquiteturas de Referência. Da arquitetura a implementação. Elementos de um Padrão DCC / ICEx / UFMG Definição de Padrões Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Um padrão é uma descrição do problema e a essência da sua solução Documenta boas soluções para problemas recorrentes

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

ATIVIDADE 1. Redes Windows. 1.1 Histórico do SMB

ATIVIDADE 1. Redes Windows. 1.1 Histórico do SMB ATIVIDADE 1 Redes Windows Falar sobre Samba e redes mistas Windows / Linux, sem antes explicar o conceito básico de uma rede não parece correto e ao mesmo tempo, perder páginas e mais páginas explicando

Leia mais

Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina

Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina Programação para Internet Rica 1 Aula 2: RIA - Aplicações Ricas para Internet Fonte: Plano de Aula Oficial da Disciplina Objetivo: Identificar as principais características de uma Aplicação Internet Rica.

Leia mais

Desenvolvendo aplicações Web escaláveis. Elton Luís Minetto

Desenvolvendo aplicações Web escaláveis. Elton Luís Minetto Desenvolvendo aplicações Web escaláveis Elton Luís Minetto Quem? Graduado e pós-graduado em Ciência da Computação. Cursando MBA em Gerenciamento de Projetos Trabalha com PHP desde 2000 Autor do livro

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

1º Seminário de Software Livre Tchelinux Software Livre: leve adiante esta idéia. Soluções de Web Caching e Web Acceleration

1º Seminário de Software Livre Tchelinux Software Livre: leve adiante esta idéia. Soluções de Web Caching e Web Acceleration 1º Seminário de Software Livre Tchelinux Software Livre: leve adiante esta idéia Soluções de Web Caching e Web Acceleration Domingos Parra Novo domingosnovo@terra.com.br Tópicos Introdução O que são web

Leia mais

1 Introdução. O sistema permite:

1 Introdução. O sistema permite: A intenção deste documento é demonstrar as possibilidades de aplicação da solução INCA Insite Controle de Acesso - para controle de conexões dia-up ou banda larga à Internet e redes corporativas de forma

Leia mais

GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC

GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC GERENCIAMENTO CENTRALIZADO DELL POWERVAULT DL 2000 BASEADO EM TECNOLOGIA SYMANTEC RESUMO EXECUTIVO O PowerVault DL2000, baseado na tecnologia Symantec Backup Exec, oferece a única solução de backup em

Leia mais

Thin Clients : aumentando o potencial dos sistemas SCADA

Thin Clients : aumentando o potencial dos sistemas SCADA Artigos Técnicos Thin Clients : aumentando o potencial dos sistemas SCADA Tarcísio Romero de Oliveira, Engenheiro de Vendas e Aplicações da Intellution/Aquarius Automação Industrial Ltda. Um diagnóstico

Leia mais

Single-Chip Cloud Computer

Single-Chip Cloud Computer IME-USP Departamento de Ciência da Computação Single-Chip Cloud Computer Diogo de Jesus Pina 6798294 (diogojpina@gmail.com) Everton Topan da Silva 6514219 (everton.topan.silva@usp.br) Disciplina: Organização

Leia mais

Arquiteturas de Software Problemas e soluções

Arquiteturas de Software Problemas e soluções Arquiteturas de Software Problemas e soluções Marcos Monteiro, MBA, ITIL V3 http://www.marcosmonteiro.com.br contato@marcosmonteiro.com.br Cliente - Servidor Cada instância de um cliente pode enviar requisições

Leia mais

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013 MC714 Sistemas Distribuídos 2 semestre, 2013 Virtualização - motivação Consolidação de servidores. Consolidação de aplicações. Sandboxing. Múltiplos ambientes de execução. Hardware virtual. Executar múltiplos

Leia mais

UM ESTUDO SOBRE TIPOS DE ALGORITMOS DE DISPATCHER PARA WEB CLUSTERS

UM ESTUDO SOBRE TIPOS DE ALGORITMOS DE DISPATCHER PARA WEB CLUSTERS REVISTA CIENTÍFICA ELETRÔNICA DE SISTEMAS DE INFORMAÇÃO - ISSN 1807-1872 P UBLICAÇÃO C IENTÍFICA DA F ACULDADE DE C IÊNCIAS J URÍDICAS E G ERENCIAIS DE G ARÇA/FAEG A NO II, NÚMERO, 04, FEVEREIRO DE 2006.

Leia mais

Serviços Web: Introdução

Serviços Web: Introdução Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

Arquitetura de BDs Distribuídos. Victor Amorim - vhca Pedro Melo pam2

Arquitetura de BDs Distribuídos. Victor Amorim - vhca Pedro Melo pam2 Victor Amorim - vhca Pedro Melo pam2 Arquitetura de BDs Distribuídos Sistemas de bds distribuídos permitem que aplicações acessem dados de bds locais ou remotos. Podem ser Homogêneos ou Heterogêneos: Homogêneos

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

as cinco principais batalhas do monitoramento e como você pode vencê-las

as cinco principais batalhas do monitoramento e como você pode vencê-las DOCUMENTAÇÃO TÉCNICA Setembro de 2012 as cinco principais batalhas do monitoramento e como você pode vencê-las agility made possible sumário resumo executivo 3 efetivo do servidor: 3 difícil e piorando

Leia mais

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

Leia mais

Arquitetura de Software e Atributos de Qualidade

Arquitetura de Software e Atributos de Qualidade Arquitetura de Software e Atributos de Qualidade Jair C Leite Requisitos e atributos de qualidade Requisitos Características, atributos, propriedades e restrições associadas ao software. Requisitos funcionais

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

5 motivos para gerenciar sua frota na nuvem

5 motivos para gerenciar sua frota na nuvem 5 motivos para gerenciar sua frota na nuvem 2 ÍNDICE >> Introdução... 3 >> O que é software na nuvem... 6 >> Vantagens do software na nuvem... 8 >> Conclusão... 13 >> Sobre a Frota Control... 15 3 Introdução

Leia mais

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br

CLOUD COMPUTING. Andrêza Leite. andreza.leite@univasf.edu.br CLOUD COMPUTING Andrêza Leite andreza.leite@univasf.edu.br Roteiro O que é cloud computing? Classificação O que está 'por traz' da cloud? Exemplos Como montar a sua? O que é cloud computing? Cloud Computing

Leia mais

Potenciais de Aplicação da Metodologia AJAX

Potenciais de Aplicação da Metodologia AJAX SEGeT Simpósio de Excelência em Gestão e Tecnologia 1 Potenciais de Aplicação da Metodologia AJAX Bruno Simões Kleverson Pereira Marcos Santos Eduardo Barrere Associação Educacional Dom Bosco - AEDB RESUMO

Leia mais

CAPÍTULO 2 ARQUITETURAS CLIENTE-SERVIDOR PARA DISSEMINAÇÃO DE DADOS GEOGRÁFICOS: UMA REVISÃO

CAPÍTULO 2 ARQUITETURAS CLIENTE-SERVIDOR PARA DISSEMINAÇÃO DE DADOS GEOGRÁFICOS: UMA REVISÃO CAPÍTULO 2 ARQUITETURAS CLIENTE-SERVIDOR PARA DISSEMINAÇÃO DE DADOS GEOGRÁFICOS: UMA REVISÃO Existem várias maneiras com as quais dados geográficos podem ser distribuídos pela Internet, todas fundamentadas

Leia mais

Abordagem NoSQL uma real alternativa

Abordagem NoSQL uma real alternativa 1 Abordagem NoSQL uma real alternativa Renato Molina Toth Universidade Federal de São Carlos Campus Sorocaba Sorocaba, São Paulo email: renatomolinat@gmail.com Abstract Nas grandes aplicações web, desktop

Leia mais