Essays.club - TCC, Modelos de monografias, Trabalhos de universidades, Ensaios, Bibliografias
Pesquisar

O Desenvolvimento Sistemas Distribuídos

Por:   •  28/6/2018  •  2.229 Palavras (9 Páginas)  •  563 Visualizações

Página 1 de 9

...

[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.

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

Quando uma chamada de método remoto tiver um erro, a exceção RemoteException é lançada. Falha de comunicação, erros de protocolo e falha durante a triagem ou unmarshalling de parâmetros ou valores de retorno são algumas das razões para o fracasso da comunicação RMI. RemoteException é uma exceção que deve ser tratada pelo método chamador. O compilador confirma que o programador de ter lidado com essas exceções.

---------------------------------------------------------------

- CORBA

O padrão CORBA passou a ser concebido pela OMG em 1989 com o intuito de proporcionar interoperabilidade entre aplicações heterogêneas.

Sua arquitetura é baseada no modelo Cliente/Servidor e no paradigma de orientação a objetos distribuídos. Deste modo, clientes fazem requisições aos objetos CORBA. As solicitações dos clientes e a resposta dos objetos CORBA são realizadas de forma transparente através do ambiente de comunicação ORB.

Todos os objetos CORBA que implementam serviços devem ter suas interfaces definidas em IDL, pois, desta forma, estes serviços poderão ser solicitados por clientes desenvolvidos em linguagens de programação distintas da utilizada para implementar o objeto servidor. Após a definição da interface, um compilador IDL gera os stubs e os skeletons, utilizados para a invocação de métodos remotos. Assim, os clientes desta arquitetura requisitam serviços a um objeto CORBA por meio do stub. Depois da chegada da solicitação ao servidor, o skeleton invoca o método do objeto que implementa o serviço e envia ao stub uma mensagem com os resultados gerados pelo objeto CORBA. Por fim, o stub recebe a mensagem, extrai os resultados e os retorna ao cliente solicitante. Este processo é denominado invocação estática.

A invocação dinâmica foi concebida para minimizar o problema da falta de flexibilidade na invocação estática. Deste modo, o padrão CORBA possui duas interfaces responsáveis por este tipo de invocação: a DII(Interface de Invocação Dinâmica) e a DSI(Interface Skeleton Dinâmica). A primeira possui a mesma função do stub, enquanto que a segunda corresponde ao skeleton. Estas interfaces são fornecidas diretamente pelo ORB, portanto, não existe mais a necessidade de cada cliente ou servidor ter uma interface específica.

---------------------------------------------------------------

- COM

A Component Object Model (COM) é um sistema independente de plataforma, distribuído, orientada a objeto para a criação de componentes de software binários que podem interagir. COM é a tecnologia base para OLE da Microsoft (documentos compostos), ActiveX (componentes habilitados para a Internet), bem como outros.

Para entender COM (e, portanto, todas as tecnologias baseadas em COM), é crucial para entender que não é uma linguagem orientada a objeto, mas um padrão. COM também não especifica como um aplicativo deve ser estruturada; linguagem, estrutura e detalhes de implementação são deixados para o desenvolvedor do aplicativo. Em vez disso, COM especifica um modelo de objeto e requisitos de programação que permitem que os objetos COM (também chamada de componentes COM, ou às vezes simplesmente objetos) para interagir com outros objetos. Esses objetos podem estar dentro de um único processo, em outros processos, e pode até ser em computadores remotos. Eles podem ser escritos em linguagens diferentes, e podem estar estruturalmente bastante diferentes, e é por isso COM é referida como um padrão de binário; um padrão que se aplica depois que um programa foi traduzido para código de máquina binário.

A única exigência

...

Baixar como  txt (16.1 Kb)   pdf (62 Kb)   docx (18.4 Kb)  
Continuar por mais 8 páginas »
Disponível apenas no Essays.club