TRABALHO DE SISTEMAS DISTRIBUIDOS

TRABALHO DE SISTEMAS DISTRIBUIDOS

SALVADOR

BA - 2013

MODELOS ARQUITETURAS

Trabalho apresentado ao Professor-Fredy

Da disciplina Sistemas Distribuídos- Do turno-noite

Do curso De Redes de Computadores

FIB

SALVADOR - 30 /09/2013

SUMÁRIO

Importância da definição da Arquitetura

Tipos & Modelos de Arquiteturas

Caracterização das Arquiteturas

Vantagens e Limitações das Arquiteturas

Comentários Finais

1-INTRODUÇÃO

IMPORTÂNCIA DA DEFINIÇÃO DA ARQUITETURA

Quando da definição das estratégias de integração dos

vários sistemas de uma empresa, é essencial que se

conheçam como estes sistemas encontram-se

implantados.

No escopo desta disciplina e do engenheiro de

automação, interessa saber as arquiteturas típicas

existentes e com as quais um dado sistema a ser

integrado deverá ter que lidar para poder interoperar

com os demais (instalados na própria empresa, ou em

outras empresas).

Importante esclarecer que não se trata de

reapresentar conteúdos de redes e de sistemas

distribuídos, mas, na ótica do especificador e

projetista da aplicação de automação, analisar o

impacto que a opção ou imposição de uso de uma

dada arquitetura tem em termos de integração.

Esta definição impacta a qualidade do projeto

global de sistemas, até porque uma mesma

empresa, ou uma mesma ferramenta, pode ter

que conviver e interoperar com sistemas

disponibilizados em mais do que um tipo de

arquitetura.

Essa qualidade geral pode ser vista sob algumas

dimensões – não funcionais – de análise, ...

isto é, de aspectos que não têm a ver diretamente

com o que cada aplicação / sistema faz, mas sim

com o como ele deverá estar integrado e, a partir

disso, com o quão rápido, custoso, seguro, etc. o

sistema integrado executará suas funções.

Neste sentido ...

tanto a estratégia considerada tecnicamente mais

adequada de integração pode esbarrar em custos

financeiros e de segurança, por exemplo, ...;

como a necessidade de se atingir certos requisitos

funcionais e não funcionais de uma dada aplicação

pode incorrer na necessidade de se modificar a

arquitetura (ou parte dela) de sistemas da empresa.

Por exemplo, ...

Qual deverá ser o melhor modelo de licença de software

para o sistema ERP ? Por Licença de Software ou por

Pagamento por Acesso ? Como deve ser concebida a

abordagem de interoperação se parte dos sistemas com

quais o ERP terá que trocar informações está num

computador central, tipo mainframe, e outra parte está

em sistemas Peer-to-Peer (P2P), instalados em múltiplos

servidores ? Qual é o impacto da decisão em termos de

necessidade de grande disponibilidade dos sistemas ?

TIPOS & MODELOS DE ARQUITETURAS

Do ponto de vista de como uma dada aplicação

enxerga as outras com as quais deverá interoperar,

existem quatro modelos básicos:

Centralizado;

Cliente / Servidor “Clássico”;

Provedores de Serviços de Aplicação (ASP);

Software-como-um-Serviço (SaaS) e Nuvem.

Esses quatro modelos diferentes não são

mutuamente exclusivos, podendo coexistir numa

mesma empresa ou arquitetura global de integração.

MODELO CENTRALIZADO

O modelo Centralizado é aqui representado pelo seu

extremo, que é a situação onde os sistemas da empresa

(ou parte deles) estão implantados em mainframes ou

em alguns poucos servidores de grande poder de

processamento.

Os mainframes são computadores

de grande porte que centralizam a

hospedagem e a execução de

aplicações, assim como a

persistência de dados, e são ainda comuns em algumas

empresas de grande porte.

Neste modelo, todo o processamento é central e existe

um repositório de dados também central, tipicamente

chamado de banco de dados corporativo.

Não há processamento no lado dos clientes, que usam

estações ou terminais passivos (“burros”).

O acesso às aplicações e ao banco de dados é feito

através de uma requisição, via rede local ou VPN,

usualmente fazendo uso de uma Intranet ou Portal da

empresa.

Os aspectos de segurança e demais de QoS são

preponderantemente determinados pelo computador

central e pela banda & hardware da rede.

Os sistemas acessados são pagos usualmente na forma

de licença única e multiplicada pelo número de

terminais clientes. O conceito de software livre e

gratuito praticamente não se coloca.

A integração de um sistema heterogêneo com uma

aplicação do mainframe dá-se ou de forma indireta via

Banco de Dados, ou de forma semi-direta, através de

uma requisição (procedimento “batch”) para o

mainframe.

A Computação em Nuvem (Cloud Computing) não deixa

de ser equivalente ao modelo centralizado; porém, na

Nuvem, é logicamente centralizado e com protocolos

de comunicação e ferramentas de acesso diferentes.

MODELO CLIENTE : SERVIDOR “CLÁSSICO”

O modelo Cliente : Servidor é atualmente o mais

comum, embora, do ponto de vista conceitual de redes,

esteja presente em todos os modelos de comunicação

hoje usados.

A perspectiva que aqui se quer enfatizar

é a noção de que o processamento não

é totalmente centralizado em um único

computador central, mas sim

distribuído por vários servidores.

Por consequencia, a hospedagem e a execução de

aplicações, assim como a persistência de dados, é

descentralizada.

ODELO CLIENTE : SERVIDOR “CLÁSSICO”

Neste modelo, o processamento é distribuído e podem

existir um central ou vários repositórios de dados, cada

um devidamente conhecido sobre sua função (servidor

de impressão, servidor de arquivos, servidor de

modelos de produtos, etc.) mas transparente às

aplicações.

Há também processamento no lado das aplicaçõescliente, que usam os serviços do servidor para dar

sequencia às suas execuções / processos de negócios.

O acesso às aplicações e ao banco de dados é também

feito através de uma requisição, via rede local ou VPN,

fazendo uso de Internet, Intranet ou Portal da empresa.

MODELO CLIENTE : SERVIDOR P2P

Uma importante variante atual deste modelo clássico

são os sistemas baseados no modelo P2P (Peer-to-Peer).

Neste modelo, o conceito clássico de cliente:servidor é

estendido no sentido de que todos os nós são, ao

mesmo tempo, clientes e servidores. É muito usado

para uma melhor distribuição de conteúdo e para

compartilhamento de arquivos.

A requisição do serviço é usualmente feita via

plataformas (middlewares) e protocolos especialmente

desenhados para P2P, que abstraem a localização dos

servidores que têm toda ou parte da informação

desejada.

MODELO ASP

O Modelo ASP (Application Service Provider - Provedor

de Serviços de Aplicação) é um modelo mais recente

que se baseia na idéia da disponibilização de aplicações

inteiras via Internet, que ficam fora da empresa, e que

são completamente gerenciadas por uma empresa

terceira.

A empresa cliente não compra a licença do software e

tão pouco o hospeda localmente, mas simplesmente o

“aluga”, pagando pelo seu uso, via rede.

MODELO SAAS

O Modelo SaaS (Software-as-a-Service / Softwarecomo-um-Serviço) é o modelo mais recente. Ele se

baseia na idéia da disponibilização de serviços

especializados de software, relativamente pequenos,

(e não mais de pacotes inteiros, muito grandes) via

Internet, que ficam fora da empresa, e que são também

completamente gerenciados por uma empresa terceira.

A empresa cliente não compra licença alguma de

software e tão pouco o hospeda localmente, mas

simplesmente invoca o serviço, acessando-o on-demand

(apenas quando o requer/usa) e paga pelo seu uso.

Sua arquitetura basicamente contempla um servidor

que provê o acesso aos serviços. Na maior parte dos

casos, são serviços baseados em web, onde basta ao

cliente ter acesso à rede e a um navegador.

Também baseados em SLAs, todo o armazenamento e

acesso aos serviços é terceirizado, assim como o

cumprimento dos aspectos de QoS acordados.

A empresa-gestora (o provedor) fica totalmente

responsável pela segurança, atualização de versões,

manutenção, treinamento, etc., do serviço.

MODELO SaaS : SOA

Um importante uso atual do modelo SaaS é o seu

direcionamento para aplicações SOA (Service Oriented

Architecture / Arquitetura Orientada a Serviços).

Neste modelo, o conceito original de SaaS é alargado,

no sentido de que os serviços de software passam a ser

disponibilizados como funcionalidades de baixa

granularidade, altamente reutilizáveis, para compor

aplicações no lado do cliente.

A integração da aplicação com um serviço SaaS dá-se de

forma direta, através de uma requisição para o servidor.

Caberá ao cliente encontrar e invocar um dado serviço

de dentro da aplicação e gerenciar o resultado.

COMPARATIVO RESUMIDO DE CARACTERÍSTICAS

2-CONCLUSÃO

Pode-se observar que, por não haver uma solução pronta, definitiva, como um sistema operacional distribuído, que várias empresas, organizações ou mesmo pessoas, desenvolvem as suas próprias aplicações com as características de sistemas distribuídos, o que permite identificar que existe uma demanda muito grande a ser atendida por novas aplicações a serem desenvolvidas para essa finalidade, independentemente da área de atuação, seja ela para fins de pesquisas biológicas ou aplicações de banco de dados.

Como recomendações à trabalhos futuros, é sugerido que novas pesquisas possam ser feitas no sentido do desenvolvimento de sistemas nativamente distribuídos, ou seja, que todo o seu projeto fosse pensado, desde o início, para essa finalidade.

3-BIBLIOGRAFIA

DEITEL, Harvey M. Java Como Programar 6ª edição – São Paulo: Editora Pearson Education do Brasil., 2008

FERREIRA, Rubem E. Linux Guia do Administrador do Sistema. São Paulo: Novatec Editora

SALVADOR

BA - 2013

MODELOS ARQUITETURAS

Trabalho apresentado ao Professor-Fredy

Da disciplina Sistemas Distribuídos- Do turno-noite

Do curso De Redes de Computadores

FIB

SALVADOR - 30 /09/2013

SUMÁRIO

Importância da definição da Arquitetura

Tipos & Modelos de Arquiteturas

Caracterização das Arquiteturas

Vantagens e Limitações das Arquiteturas

Comentários Finais

1-INTRODUÇÃO

IMPORTÂNCIA DA DEFINIÇÃO DA ARQUITETURA

Quando da definição das estratégias de integração dos

vários sistemas de uma empresa, é essencial que se

conheçam como estes sistemas encontram-se

implantados.

No escopo desta disciplina e do engenheiro de

automação, interessa saber as arquiteturas típicas

existentes e com as quais um dado sistema a ser

integrado deverá ter que lidar para poder interoperar

com os demais (instalados na própria empresa, ou em

outras empresas).

Importante esclarecer que não se trata de

reapresentar conteúdos de redes e de sistemas

distribuídos, mas, na ótica do especificador e

projetista da aplicação de automação, analisar o

impacto que a opção ou imposição de uso de uma

dada arquitetura tem em termos de integração.

Esta definição impacta a qualidade do projeto

global de sistemas, até porque uma mesma

empresa, ou uma mesma ferramenta, pode ter

que conviver e interoperar com sistemas

disponibilizados em mais do que um tipo de

arquitetura.

Essa qualidade geral pode ser vista sob algumas

dimensões – não funcionais – de análise, ...

isto é, de aspectos que não têm a ver diretamente

com o que cada aplicação / sistema faz, mas sim

com o como ele deverá estar integrado e, a partir

disso, com o quão rápido, custoso, seguro, etc. o

sistema integrado executará suas funções.

Neste sentido ...

tanto a estratégia considerada tecnicamente mais

adequada de integração pode esbarrar em custos

financeiros e de segurança, por exemplo, ...;

como a necessidade de se atingir certos requisitos

funcionais e não funcionais de uma dada aplicação

pode incorrer na necessidade de se modificar a

arquitetura (ou parte dela) de sistemas da empresa.

Por exemplo, ...

Qual deverá ser o melhor modelo de licença de software

para o sistema ERP ? Por Licença de Software ou por

Pagamento por Acesso ? Como deve ser concebida a

abordagem de interoperação se parte dos sistemas com

quais o ERP terá que trocar informações está num

computador central, tipo mainframe, e outra parte está

em sistemas Peer-to-Peer (P2P), instalados em múltiplos

servidores ? Qual é o impacto da decisão em termos de

necessidade de grande disponibilidade dos sistemas ?

TIPOS & MODELOS DE ARQUITETURAS

Do ponto de vista de como uma dada aplicação

enxerga as outras com as quais deverá interoperar,

existem quatro modelos básicos:

Centralizado;

Cliente / Servidor “Clássico”;

Provedores de Serviços de Aplicação (ASP);

Software-como-um-Serviço (SaaS) e Nuvem.

Esses quatro modelos diferentes não são

mutuamente exclusivos, podendo coexistir numa

mesma empresa ou arquitetura global de integração.

MODELO CENTRALIZADO

O modelo Centralizado é aqui representado pelo seu

extremo, que é a situação onde os sistemas da empresa

(ou parte deles) estão implantados em mainframes ou

em alguns poucos servidores de grande poder de

processamento.

Os mainframes são computadores

de grande porte que centralizam a

hospedagem e a execução de

aplicações, assim como a

persistência de dados, e são ainda comuns em algumas

empresas de grande porte.

Neste modelo, todo o processamento é central e existe

um repositório de dados também central, tipicamente

chamado de banco de dados corporativo.

Não há processamento no lado dos clientes, que usam

estações ou terminais passivos (“burros”).

O acesso às aplicações e ao banco de dados é feito

através de uma requisição, via rede local ou VPN,

usualmente fazendo uso de uma Intranet ou Portal da

empresa.

Os aspectos de segurança e demais de QoS são

preponderantemente determinados pelo computador

central e pela banda & hardware da rede.

Os sistemas acessados são pagos usualmente na forma

de licença única e multiplicada pelo número de

terminais clientes. O conceito de software livre e

gratuito praticamente não se coloca.

A integração de um sistema heterogêneo com uma

aplicação do mainframe dá-se ou de forma indireta via

Banco de Dados, ou de forma semi-direta, através de

uma requisição (procedimento “batch”) para o

mainframe.

A Computação em Nuvem (Cloud Computing) não deixa

de ser equivalente ao modelo centralizado; porém, na

Nuvem, é logicamente centralizado e com protocolos

de comunicação e ferramentas de acesso diferentes.

MODELO CLIENTE : SERVIDOR “CLÁSSICO”

O modelo Cliente : Servidor é atualmente o mais

comum, embora, do ponto de vista conceitual de redes,

esteja presente em todos os modelos de comunicação

hoje usados.

A perspectiva que aqui se quer enfatizar

é a noção de que o processamento não

é totalmente centralizado em um único

computador central, mas sim

distribuído por vários servidores.

Por consequencia, a hospedagem e a execução de

aplicações, assim como a persistência de dados, é

descentralizada.

ODELO CLIENTE : SERVIDOR “CLÁSSICO”

Neste modelo, o processamento é distribuído e podem

existir um central ou vários repositórios de dados, cada

um devidamente conhecido sobre sua função (servidor

de impressão, servidor de arquivos, servidor de

modelos de produtos, etc.) mas transparente às

aplicações.

Há também processamento no lado das aplicaçõescliente, que usam os serviços do servidor para dar

sequencia às suas execuções / processos de negócios.

O acesso às aplicações e ao banco de dados é também

feito através de uma requisição, via rede local ou VPN,

fazendo uso de Internet, Intranet ou Portal da empresa.

MODELO CLIENTE : SERVIDOR P2P

Uma importante variante atual deste modelo clássico

são os sistemas baseados no modelo P2P (Peer-to-Peer).

Neste modelo, o conceito clássico de cliente:servidor é

estendido no sentido de que todos os nós são, ao

mesmo tempo, clientes e servidores. É muito usado

para uma melhor distribuição de conteúdo e para

compartilhamento de arquivos.

A requisição do serviço é usualmente feita via

plataformas (middlewares) e protocolos especialmente

desenhados para P2P, que abstraem a localização dos

servidores que têm toda ou parte da informação

desejada.

MODELO ASP

O Modelo ASP (Application Service Provider - Provedor

de Serviços de Aplicação) é um modelo mais recente

que se baseia na idéia da disponibilização de aplicações

inteiras via Internet, que ficam fora da empresa, e que

são completamente gerenciadas por uma empresa

terceira.

A empresa cliente não compra a licença do software e

tão pouco o hospeda localmente, mas simplesmente o

“aluga”, pagando pelo seu uso, via rede.

MODELO SAAS

O Modelo SaaS (Software-as-a-Service / Softwarecomo-um-Serviço) é o modelo mais recente. Ele se

baseia na idéia da disponibilização de serviços

especializados de software, relativamente pequenos,

(e não mais de pacotes inteiros, muito grandes) via

Internet, que ficam fora da empresa, e que são também

completamente gerenciados por uma empresa terceira.

A empresa cliente não compra licença alguma de

software e tão pouco o hospeda localmente, mas

simplesmente invoca o serviço, acessando-o on-demand

(apenas quando o requer/usa) e paga pelo seu uso.

Sua arquitetura basicamente contempla um servidor

que provê o acesso aos serviços. Na maior parte dos

casos, são serviços baseados em web, onde basta ao

cliente ter acesso à rede e a um navegador.

Também baseados em SLAs, todo o armazenamento e

acesso aos serviços é terceirizado, assim como o

cumprimento dos aspectos de QoS acordados.

A empresa-gestora (o provedor) fica totalmente

responsável pela segurança, atualização de versões,

manutenção, treinamento, etc., do serviço.

MODELO SaaS : SOA

Um importante uso atual do modelo SaaS é o seu

direcionamento para aplicações SOA (Service Oriented

Architecture / Arquitetura Orientada a Serviços).

Neste modelo, o conceito original de SaaS é alargado,

no sentido de que os serviços de software passam a ser

disponibilizados como funcionalidades de baixa

granularidade, altamente reutilizáveis, para compor

aplicações no lado do cliente.

A integração da aplicação com um serviço SaaS dá-se de

forma direta, através de uma requisição para o servidor.

Caberá ao cliente encontrar e invocar um dado serviço

de dentro da aplicação e gerenciar o resultado.

COMPARATIVO RESUMIDO DE CARACTERÍSTICAS

2-CONCLUSÃO

Pode-se observar que, por não haver uma solução pronta, definitiva, como um sistema operacional distribuído, que várias empresas, organizações ou mesmo pessoas, desenvolvem as suas próprias aplicações com as características de sistemas distribuídos, o que permite identificar que existe uma demanda muito grande a ser atendida por novas aplicações a serem desenvolvidas para essa finalidade, independentemente da área de atuação, seja ela para fins de pesquisas biológicas ou aplicações de banco de dados.

Como recomendações à trabalhos futuros, é sugerido que novas pesquisas possam ser feitas no sentido do desenvolvimento de sistemas nativamente distribuídos, ou seja, que todo o seu projeto fosse pensado, desde o início, para essa finalidade.

3-BIBLIOGRAFIA

DEITEL, Harvey M. Java Como Programar 6ª edição – São Paulo: Editora Pearson Education do Brasil., 2008

FERREIRA, Rubem E. Linux Guia do Administrador do Sistema. São Paulo: Novatec Editora