O Desenvolvimento Sistemas Distribuídos

UNIVERSIDADE PAULISTA – UNIP

Rayane Alves Santana – B9141J-7

Modelos de Sistema; Cliente-Servidor; Java RMI; Corba; COM; DCOM

Compensação de faltas

Turma: CC7P30

Brasília – 2016

UNIVERSIDADE PAULISTA – UNIP

Ciência da Computação

Compensação de Faltas

Aluna: Rayane Alves Santana

Matrícula: B9141J-7

Desenvolvimento Sistemas Distribuídos

Brasília – DF / 2016

7º Semestre

Índice

1. Introdução.................................................................................................4
2. Cliente – Servidor......................................................................................5
3. Java / RMI.................................................................................................6
4. CORBA.....................................................................................................8
5. COM..........................................................................................................9
6. DCOM.....................................................................................................10
7. Conclusão...................... ........................................................................12
8. Bibliografia..............................................................................................13

---

Modelos de Sistema

1. Introdução

A divisão de responsabilidades entre componentes do sistema (aplicações, servidor e se outros processos) e a colocação desses componentes em computadores em rede é, talvez, o aspecto mais evidente do desenho de sistemas distribuídos. Esta divisão de responsabilidades tem maiores implicações para a desempenho, confiabilidade e segurança do sistema. Neste ponto, mostram-se os principais modelos de arquitetura, nos quais esta distribuição de responsabilidades é baseada. Em sistemas distribuídos, processos com responsabilidades bem definidas integralmente eles, para realizar uma atividade. 

Em linguagens orientadas a objetos tais como Java e C++, com suporte adicional apropriado, processos distribuídos podem ser construídos em mais formas de orientação a objetos. Muitos objetos podem ser encapsulados num processo servidor ou peer e suas referências são passadas a outros objetos de forma que possam ser acedidas pela invocação remota. Esta abordagem é adoptada por CORBA, Java, … com o seu mecanismo de invocação remota (RMI).

São critérios para a escolha de modelo: desempenho o tempo de resposta: carga do servidor e da rede, delay em atravessar camadas de software, volume de dados a capacidade de processamento cliente, servidor, rede (throughput) o balanceamento de carga (divisão de trabalho, eg. applets, DNS, etc.); qualidade de serviço; uso de cache e replicação; dependabilidade: garantia (confiança) que um sistema oferece no provimento de um serviço ou tarefa o correção, confiabilidade e segurança; aspectos: o tolerância a falhas uso de múltiplos componentes (replicação) para permitir a disponibilidade o serviço o segurança localizar (pôr) dados e recursos sensíveis em locais que ofereçam os níveis adequados de segurança e de controle o disponibilizar recursos de forma parcial (baseado na autorização do usuário).

1. Cliente - Servidor

Esta arquitetura é a frequentemente mais citada quando se aborda sistemas distribuídos. É historicamente a mais importante e continua a mais largamente aplicada. A fig. 6 ilustra uma simples arquitetura, na qual processos clientes interagem com os processos de servidores independentes em máquinas separadas, deforma a aceder o canal partilhado por eles.

[pic 1]

Fig. 6: Clientes invocam servidor individual

Em algum momento os servidores podem ser clientes de outros servidores, como ilustra a fig. 6. Por exemplo, um servidor Web é frequentemente um cliente para um servidor local de ficheiros, que faz a gestão das páginas Web em si armazenadas. Servidores Web e muitos outros serviços de Internet são clientes dos serviços DNS (Domain Name System), que traduz os nomes dos domínios da Internet para endereços de rede. Outro exemplo, também relacionado com a Web, são os motores de busca que permitem aos usuários pesquisar resumos de páginas Web em sites da Internet. Estes resumos são feitos, por programas chamados Web crawler1 (vide fig. 7), que correm por detrás do site do motor de busca usando requisições http2 para aceder servidores Web através da Internet.

[pic 2]

Fig. 7: Web crawler.

Um motor de busca é ao mesmo tempo um servidor e um cliente: ele responde a solicitações de navegadores cliente e ele executa Web crawlers que age como cliente para outros servidores Web. Neste exemplo, as tarefas do servidor (respondendo as requisições dos usuários) e as tarefas do crawler (fazendo requisições a outros servidores Web são totalmente independentes); existe uma pequena necessidade dessincronizá-los e eles podem correr de forma concorrente. De fato, um motor de busca típico incluiria muitas threads de execução concorrentes, alguns servindo seus clientes e outros executando Web crawlers.

1. Java / RMI

Java RMI é um mecanismo para permitir a invocação de métodos que residem em diferentes máquinas virtuais Java (JVM). O JVM pode estar em diferentes máquinas ou podem estar na mesma máquina. Em ambos os casos, o método pode ser executado em um endereço diferente do processo de chamada. Java RMI é um mecanismo de chamada de procedimento remoto orientada a objetos. 

Java RMI é um sistema de linguagem individual, a programação de aplicação distribuída em RMI é bastante simples. Todas as interfaces e classes para o sistema de RMI são definidos no pacote java.rmi. A classe de objeto remoto implementa a interface remota, enquanto as outras classes estendem RemoteObject. 

Uma interface remota é definida pela extensão da interface Remote que está no pacote java.rmi. A interface que declara os métodos que os clientes podem invocar a partir de uma máquina virtual remoto é conhecido como interface remota. A interface remota deve satisfazer as seguintes condições:

• Deve estender-se a interface Remote.
• Cada declaração de método na interface remota deve incluir a exceção RemoteException (ou uma de suas superclasses), em sua cláusula lançada.

Funções do servidor RMI são fornecidos pela classe RemoteObject e suas subclasses Remote Server, Activatable e UnicastRemoteObject. Aqui está uma breve descrição de como lidar com as diferentes classes:

• RemoteObject fornece implementações dos métodos toString, equals e hashCode na classe java.lang.Object.
• As classes UnicastRemoteObject e Activatable cria objetos remotos e os exporta, ou seja, essas classes fazem os objetos remotos usados por clientes remotos.

A classe RemoteException é uma super-classe das exceções que o sistema RMI joga durante uma invocação de método remoto. Cada método remoto que é declarado em uma interface remota deve especificar RemoteException (ou uma de suas superclasses), em sua cláusula throws para garantir a robustez das aplicações no sistema RMI.