Programação com Objetos Distribuídos e Componentes

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

Download "Programação com Objetos Distribuídos e Componentes"

Transcrição

1 Programação com Objetos Distribuídos e Componentes Cláudio F. R. Geyer, Luciano Cavalheiro da Silva, Patrícia Kayser Vargas, Juliano Malacarne Resumo Universidade Federal do Rio Grande do Sul Instituto de Informática Av. Bento Gonçalves, 9500 Bloco IV Cx. Postal Porto Alegre {geyer, lucc, Este texto é uma introdução à programação com objetos distribuídos (POD). A abordagem dessa introdução pode ser caracterizada por dois aspectos: conceitos e técnicas básicas de POD e alguns dos ambientes de POD mais importantes nos dias atuais. Inicialmente, os principais conceitos e questões da programação com objetos distribuídos são descritos. O primeiro ambiente apresentado é a linguagem Java via a plataforma JDK da Sun, abordando-se somente os principais recursos para POD, como threads e RMI. A seguir descreve-se o modelo CORBA para POD e a tecnologia DCOM da Microsoft. Por último, introduz-se a tecnologia JavaBeans da Sun, proposta para o desenvolvimento padrão de componentes. 1. Introdução É inegável a crescente importância dos ambientes paralelos e distribuídos tanto no meio acadêmico quanto comercial. O uso de redes locais e da Internet está amplamente difundido mesmo para uso doméstico. Mas para que tais recursos físicos sejam aproveitados da melhor forma possível é preciso fornecer suporte adequado de software. Existem diversos aspectos relacionados ao controle em ambientes distribuídos. Por ambiente distribuído entende-se um conjunto de processadores interligados por uma rede de interconexão e sem memória compartilhada. Enquanto em um ambiente centralizado a comunicação entre processos ocorre através de variáveis ou arquivos compartilhados, a ausência de memória compartilhada exige que a interação entre processos em processadores distintos seja feita através de troca de mensagens. Segundo Tanenbaum, um sistema distribuído é "uma coleção de computadores independentes que parecem ao usuário como um único computador". Essa definição implica hardware formado por máquinas autônomas e software fornecendo a abstração de uma máquina única. O uso de sistemas distribuídos possui uma série de vantagens em relação ao processamento seqüencial, dentre as quais destaca-se: (a) aproveitamento de máquinas potencialmente ociosas, além de ser mais barato interconectar vários processadores do que adquirir um supercomputador; (b) algumas aplicações são distribuídas por natureza e portanto mais facilmente implementadas nesse tipo de ambiente; (c) em caso de falha de uma máquina, o sistema como um todo pode sobreviver, apresentando apenas uma degradação de desempenho; (d) é possível ter um crescimento incremental, pois o poder computacional pode ser aumentado através da inclusão de novos equipamentos; (e) sistemas distribuídos são mais flexíveis do que máquinas isoladas, por isso muitas vezes são utilizados até mesmo que não se esteja buscando desempenho. Porém, também existem algumas desvantagens ainda segundo Tanenbaum: (a) pouco software de alto nível disponível para sistemas distribuídos; (b) dificuldades para evitar acesso indevido (segurança); (c) a rede de interconexão pode causar problemas de não conexão ou não dar vazão à demanda.

2 2 Uma vez que a programação distribuída é mais complexa que a programação seqüencial, diversos trabalhos são desenvolvidos tanto com o objetivo de explorar o paralelismo e a distribuição de forma implícita ou automática, quanto com o intuito de tornar a expressão do paralelismo mais simples. Dentre os diversos tópicos relacionados aos sistemas distribuídos, esse texto irá se deter em aspectos relacionados ao programação com o uso de objetos distribuídos. O uso de objetos distribuídos tem crescido com a popularização da linguagem orientada a objetos Java que possui uma série de facilidades para a programação distribuída. A computação com objetos distribuídos é um paradigma que permite que objetos sejam distribuídos através de uma rede heterogênea e permite que os componentes interajam como se estivessem unificados. Os objetos podem estar distribuídos em diferentes computadores através de uma rede, embora parecendo como se eles estivessem locais dentro de uma aplicação. Uma das preocupações nesse tipo de ambiente é simplificar a programação facilitando ao programador a expressão da concorrência entre objetos e da distribuição dos mesmos. Outros aspectos importantes estão relacionados às diferentes formas de otimizar a execução do sistema buscando aumento de desempenho. O restante desse texto é composto de diversas partes independentes (cada uma tem uma numeração de seção própria): - Conceitos Básicos de Programação com Objetos Distribuídos; - Java Threads - concorrência e sincronização; - Java RMI - comunicação por chamada remota de método; - Introdução a CORBA; - Introdução a DCOM; - Introdução a JavaBeans.

3 3 Índice Programação com Objetos Distribuídos e Componentes...1 Resumo Introdução Conceitos Básicos de Programação com Objetos Distribuídos Programação Distribuída Objetos Distribuição Concorrência Sincronização Java Threads - concorrência e sincronização Introdução Java Thread Criação de threads Sincronização Controle de threads Endereços News Groups Java RMI - comunicação por chamada de método remoto Introdução Conceitos básicos Recursos básicos Comunicação entre os componentes Diferenças entre RMI e chamada local de método Camadas de software do sistema RMI (exemplo Hello) Passos do uso de RMI Segurança do RMI Outros aspectos Pacote java.rmi Pacote java.rmi.registry Introdução a CORBA Introdução O que é CORBA Histórico CORBA...24

4 Arquitetura CORBA IDL ORB ID s Globais e Protocolos Serviços CORBA Facilidades CORBA Objetos de Negócio Endereços Introdução a DCOM Introdução Visão geral de DCOM Características do DCOM Exemplo Counter em DCOM/Java Obtenção de DCOM DCOM X CORBA X RMI Resumo Introdução a JavaBeans Introdução Conceitos Básicos de JavaBeans Principais Recursos de Programação (Classes JavaBeans) Enterprise JavaBeans Bibliografia

5 5 2. Conceitos Básicos de Programação com Objetos Distribuídos Programação Distribuída A programação distribuída está presente em muitos problemas resolvidos através do computador. Para esses problemas as soluções são mais naturalmente representadas na forma de atividades paralelas, atuando de forma cooperativa ou competitiva, que colaboram cada uma com uma parcela da solução final. Um programa concorrente é composto de dois ou mais programas seqüenciais, que são executados de forma concorrente, e denominados processos paralelos distribuídos. Essa execução concorrente pode ser feita através do compartilhamento de um único processador por todos os processos (multiprogramação), ou através da execução de cada processo em elementos processadores exclusivos (multiprocessamento ou processamento distribuído, se esses processadores compartilham ou não memória, respectivamente). Processos que cooperam para atingir os resultados desejados interferem, mutuamente, na sua execução, através da troca de informações necessária para a cooperação. Além disso, há situações em que os processos devem se sincronizar, para respeitar as dependências entre resultados a serem produzidos e consumidos, acomodando assim diferentes velocidades relativas de execução. Tanto a comunicação como a sincronização de processos são efetuadas por mecanismos baseados em compartilhamento de memória ou troca de mensagens. A programação distribuída reduz a complexidade das aplicações. No contexto da programação distribuída, algumas questões são de grande importância, tais como: distribuição, concorrência e sincronização. O modelo para programação distribuída baseado em objetos oferece basicamente: - paralelismo de alta granularidade: permitindo (desde que exista mais de um processador) que mais de uma parte da aplicação esteja executando em um mesmo instante de tempo; - cooperação entre processos: possibilitando comunicação e sincronização entre partes da aplicação Objetos A exploração de paralelismo depende da divisão de um problema em um conjunto de partes que podem ser executadas em paralelo visando o máximo de proveito dos recursos. Normalmente, essa tarefa não é simples, se não existirem mecanismos adequados, nas linguagens de programação, para expressar essa solução. A programação concorrente orientada a objetos estuda como tais mecanismos podem ser implementados aproveitando-se das vantagens de programar no paradigma de objetos, e dessa forma implementar tais programas como uma coleção de objetos. Objetos podem representar naturalmente essas entidades paralelas já que, por definição, apresentam propriedades de encapsulamento e autonomia. Entretanto, é preciso analisar alguns aspectos dessa integração de concorrência com objetos, já que isso implica a incorporação de 1 Essa seção foi inicialmente desenvolvida por alunos da disciplina Programação com Objetos Distribuídos, ministrada no 1 o semestre de 2000 no curso PPGCC da UFRGS, a partir das notas de aula e outras referências.

6 6 conceitos bastante estabelecidos (como processos, sincronização, exclusão mútua, etc) dentro das técnicas embutidas nas linguagens orientadas a objetos. Um objeto remoto é uma unidade de processamento e distribuição criada e executada fora do contexto do objeto que o criou. Um objeto desse tipo é visível fora do objeto que o criou, podendo ser compartilhado por outros objetos. Assim, objetos podem, dinamicamente, tornar-se clientes de objetos que foram criados por outros Distribuição Sistemas de computação distribuída podem ser utilizados por muitos tipos de aplicações. As razões que levam a distribuir uma aplicação se enquadram em quatro categorias: decremento do tempo do processamento total, tolerância a falhas, especializações funcionais de um sistema, e aplicação inerentemente distribuída. Existem basicamente duas características que distinguem a programação distribuída da programação seqüencial: o uso de múltiplos processadores e a cooperação entre os processadores. Um dos requisitos para programação distribuída é a habilidade de distribuir a execução de diferentes partes de um programa em diferentes processadores. Objetos Passivos Em alguns modelos, dados compartilhados são encapsulados em objetos passivos, ou seja, objetos que atendem a requisições de serviço e não possuem fluxo de controle próprio. Os dados armazenados pelo objeto são acessíveis apenas através do conjunto de operações definidas pela classe de objeto, o qual é uma instância de tipos abstratos de dados Concorrência Em se tratando de concorrência, objetos são unidades autônomas de execução e distribuição, interagindo periodicamente com outros objetos através de chamadas de métodos. Os objetos podem apresentar concorrência internamente, para possibilitar a execução de várias tarefas simultaneamente. Objetos que não são remotos, i.e., que são criados e executados dentro do contexto de algum objeto, podem ser de natureza passiva ou ativa. Objetos Passivos Os objetos do tipo passivo têm seu código incorporado ao objeto que os criou, e executam apenas chamadas de métodos; nos intervalos entre chamadas, permanecem sem executar nenhuma tarefa. Objetos Ativos Os objetos ativos, depois de criados, passam a executar uma seqüência de comandos particulares, ao mesmo tempo em que continuam atendendo chamadas de métodos, quando solicitados. Esses comandos particulares são, basicamente, tarefas necessárias à manutenção do estado interno do objeto, que distinguem objetos ativos dos passivos. Outra forma de concorrência é a execução concorrente de métodos. Como objetos remotos podem ser compartilhados por vários clientes, pode ser que, num determinado momento, pedidos para a execução de métodos sejam atendidos enquanto um (ou mais métodos) está sendo executado. Cada pedido de execução de método causa a ativação de uma Thread para atender esse pedido,

7 7 utilizando como dados locais os parâmetros da chamada e as variáveis locais ao método (e de demais funções chamadas em sequência). Essa Thread começa a executar o método e é destruída quando o resultado da execução do método é devolvido ao objeto cliente. Linguagens orientadas a objetos concorrentes trazem os benefícios da orientação a objeto, pois permitem modularizar um problema em pequenos problemas, baseando-se em dados antes de funções, para ambientes multiprocessadores. Abaixo serão apresentadas algumas considerações sobre concorrência. Objetos Concorrentes Objetos, na maioria das linguagens e sistemas existentes, são estáticos ou passivos, isto é, somente um objeto é executado a cada instante. Diante desta limitação, surge o conceito de objetos concorrentes que consistem de operações (métodos), armazenamento local de dados e de um processador. Este conceito é simples, pois a alocação do processador é função da implementação e não da linguagem de programação. Um objeto concorrente torna-se ativo quando recebe uma mensagem invocando um método. Três elementos em objetos concorrentes merecem atenção especial: mensagens, classes e metaobjeto. Mensagens Objetos concorrentes interagem entre si trocando mensagens. Em objetos seqüenciais, mensagens são restritas a simples chamadas síncronas de procedimentos. Em objetos concorrentes, o mecanismo de passagem de mensagens assíncronas deve ser incluído a fim de permitir a exploração da concorrência. Classes Classes em linguagens orientadas a objetos seqüenciais servem para a criação de instâncias e compartilhamento de código. Em uma implementação distribuída, o que é natural para objetos concorrentes, o compartilhamento de código em tempo de execução através da hierarquia de classes deve ser reconsiderado. Em objetos concorrentes, é mais efetivo para cada objeto ter seu próprio código. Isto permite que uma instância migre para diferentes nodos do sistema distribuído, tornando fácil a implementação. Meta-objetos Em objetos seqüenciais existe apenas um objeto controlador para todo o sistema. Assim, o nível meta pode ser acessado e alterado por um objeto, suspendendo a execução dos demais. Além disso, a utilização de um controlador único diminui o grau de paralelismo do sistema. Em objetos concorrentes, um objeto não pode suspender a execução de outros objetos, devendo se constituir em uma entidade independente do sistema. Deste modo cada objeto deve possuir seu próprio controlador. Em multiprocessadores convencionais, objetos se comunicam ou por compartilhamento de memória ou por troca de mensagens. Mas em ambientes orientados a objeto, a comunicação é

8 8 sempre através de troca de mensagens, pois compartilhar dados entre objetos violaria o princípio do encapsulamento. Existe um questionamento sobre a validade de violar o paradigma de objeto em nível físico a fim de maximizar a performance. No entanto, o programador não poderia ter acesso a este nível. Tipos de mensagens As linguagens orientadas a objeto utilizam três tipos de comunicação: - Síncrona: a comunicação síncrona usa chamadas remotas a procedimentos. Isto é muito fácil de implementar, mas algumas vezes causa desperdício de tempo por causa do requerimento de um send e um receive para fazer o rendezvous. Sistemas síncronos são mais previsíveis e fáceis de testar. - Assíncrona: a comunicação assíncrona elimina a espera por sincronização e pode aumentar o volume de atividades concorrentes. No entanto, é menos previsível, conseqüentemente difícil de programar e testar. Um programa pode usar comunicação assíncrona se seus objetos podem permanecer processando sem esperar por alguma resposta para suas mensagens. - Invocação (chamada com resposta no futuro): invocação, ou método futuro, é uma variação da comunicação assíncrona, pois o chamador também continua executando, enquanto uma variável futura aloca um local para o resultado. O sender processa até acessar a variável futura. Se o resultado tiver retornado, o sender continua; se não, ele bloqueia e fica esperando o resultado. Aceitação de mensagens Objetos recebem mensagens implicitamente ou explicitamente. Aceitação implícita significa que o sistema aceita mensagens automaticamente, e os usuários não podem controlar o seu recebimento. Em um sistema implícito, uma tarefa de baixa prioridade pode interromper uma tarefa de alta prioridade. Para controlar isto, o programador pode atribuir propriedades às mensagens, mas isto torna o programa mais complexo. A aceitação explícita permite que os objetos controlem o momento em que receberão e processarão as mensagens. Isto é mais flexível, pois esquemas de prioridade são definidos em uma lista de mensagens e o objeto pode respondê-las. No entanto, isto aumenta o overhead em tempo de execução, pois o sistema precisa priorizar a fila de mensagens e, em função disto, o programador assume maior responsabilidade sobre o controle do processamento de mensagens Sincronização Uma sincronização correta coordena as atividades paralelas para que executem eficientemente, consistentemente e previsivelmente. Muita coordenação reduz a concorrência, pouca conduz a um indeterminismo indesejável. O esquema de herança complica a sincronização, pois quando uma subclasse herda de uma classe base, o programa precisa, algumas vezes, redefinir a sincronização do método herdado. Este é o aspecto mais complicado na integração de concorrência em linguagens orientadas a objeto. Se uma única classe centralizada controlar explicitamente a recepção de mensagens, todas as subclasses precisarão reescrevê-la cada vez que um novo método for adicionado a classe. A

9 9 subclasse não poderá simplesmente herdar o código de sincronização, pois a classe de mais alto nível não consegue invocar o novo método.

10 10 3. Java Threads - concorrência e sincronização 3.1. Introdução Este texto aborda dois grandes tópicos da programação concorrente em Java: - expressão da concorrência em Java através dos objetos Thread; - sincronização dos objetos Thread Java Thread Uma thread Java é um fluxo de controle, ou processo leve, dentro de um programa. Um objeto do tipo Thread equivale a um bloco de controle de processo contendo dados, métodos e prioridades. Um objeto Thread oferece métodos especiais como: - public final void setpriority(int newpriority): altera a prioridade da thread; - public void start(): inicia a execução de uma thread; - public void interrupt(): interrompe a execução de uma thread. As threads Java são escalonadas pelo escalonador da máquina virtual de Java, conforme esquema de escalonamento preemptivo, baseado em prioridades. As aplicações de threads são várias como: - entrada e saída assíncrona; - tratamento assíncrono de requisições assíncronas em sistemas cliente/servidor; - processos de serviço em retaguarda (background); por exemplo, coletores de lixo (garbage collectors); - sistemas reativos que precisam tratar certos eventos rapidamente usando escalonamento baseado em prioridades; - servidores de tempo; - processamento paralelo: uso do poder de computação das máquinas multiprocessadoras Criação de threads As threads Java (ou somente threads a seguir) podem ser criadas por dois métodos. - método A: -- estender a classe Thread definindo uma nova subclasse; -- reescrever o método run(); -- criar um objeto da nova subclasse; -- iniciar a execução da thread via o método start().

11 11 - método B: -- definir uma classe C que implementa a interface Runnable; -- criar um objeto O da classe C; -- criar um objeto do tipo Thread (classe) passando o objeto O como parâmetro; --iniciar a execução da thread via o método start(). Um exemplo de criação pelo método A é dado a seguir: public class MyThread extends Thread { private String whoami; private int delay; public MyThread(String name, int d) { whoami = name; delay = d; public void run() { try { sleep(delay); catch(interruptedexcetion e) { System.out.println( Hello, this is +whoami+! ); public class TestThreads { public static void main(string[] args) { MyThread t1, t2, t3; t1 = new MyThread( First, 1000); t2 = new MyThread( Second, 500); t3 = new MyThread( Third, 2000); t1.start(); t2.start(); t3.start();

12 12 Uma provável saída (impressão) da execução do programa acima seria: Hello, this is second! Hello, this is First! Hello, this is Thirst! No caso de criação de thread com interface Runnable, usa-se o fato de que a classe Thread também é implementada como Runnable. Runnable é uma interface do ambiente Java. O esqueleto do código de uma classe que implementa Runnable está abaixo: class ThreadBody implements Runnable {... public void run() { // código do corpo da thread Um exemplo de criação de thread usando a interface Runnable é dado a seguir. No mesmo, se passa o objeto Runnable (ThreadBody) como argumento da criação de um objeto Thread: Thread t = new Thread (new ThreadBody()); t.start(); Uma vantagem significativa desse método é o que com o mesmo a classe thread do usuário (ThreadBody no caso acima) pode estender uma outra superclasse diferente da classe Thread do ambiente Java Sincronização O conceito geral de sincronização de threads Java segue o modelo clássico de monitores. Um monitor consiste de estruturas de dados e de uma coleção de procedimentos que operam sobre as estruturas do monitor. No modelo clássico, somente uma thread (ou processo) pode executar um procedimento do monitor em um momento, o que oferece exclusão mútua automática no acessos aos dados do monitor. O mesmo modelo ainda oferece as variáveis condicionais, sobre as quais pode-se executar as primitivas wait e signal. A primitiva wait bloqueia um processo de forma incondicional e libera um outro processo para executar um procedimento do monitor. A primitiva signal acorda um processo bloqueado pela primitiva wait. Cada variável condicional possui uma lista (eventualmente uma fila FIFO) de processos bloqueados. O modelo acima é aplicado em Java com algumas diferenças importantes. Qualquer objeto Java pode ser visto como um monitor. Os processos do modelo clássico são implementados pelas threads Java, as quais chamam (executam) os métodos do objeto monitor. Entretanto, a exclusão mútua automática deve ser explicitada pelo programador. Na sua forma básica, um objeto Java permite que várias threads possam estar executando seus métodos ao mesmo tempo. A implementação da exclusão mútua pode ser obtida com o uso do modificador de método

13 13 synchronized. Blocos (trechos de comandos) de exclusão mútua, dentro de um método, com granularidade mais fina que o objeto, podem ser implementados com semântica similar via o comando synchronized. As primitivas clássicas wait e signal são implementadas via os métodos wait e notify/notifyall. Entretanto variáveis de condição propriamente ditas não existem. Elas podem ser emuladas através de objetos de qualquer tipo, os quais devem obrigatoriamente ser referenciados na especificação dos blocos de exclusão mútua (comando synchronized). O modificador de método synchronized torna o mesmo parte do monitor. Não é necessário que todos os métodos de uma classe sejam modificados com synchronized. Os eventuais métodos sem synchronized não respeitam a exclusão mútua, isto é, uma thread pode estar executando um método synchronized enquanto várias outras podem estar executando métodos não synchronized do mesmo objeto. O método wait() inclui a thread em execução na lista de espera do monitor e permite a execução de outra thread dentro do monitor. A thread deve estar de posse do monitor, o que no caso básico (objeto monitor) significa que a thread está executando um método synchronized do objeto. O método notify() acorda uma thread da lista de espera do monitor. A escolha de qual thread a acordar é não determinística, ou em outras palavras, dependente de implementação do ambiente de execução Java. Observe-se que a condição de somente uma thread no monitor continua válida. A escolha de qual thread continua em execução, devido à exclusão mútua, é também não determinística. O método notifyall() acorda todas as threads da lista de espera do monitor. Como no caso do método notify(), a escolha de qual thread continua a execução é não determinística. A seguir é dado um exemplo simples do uso de sincronização. O problema é a codificação de uma classe que implementa uma fila no conceito de ordem FIFO: First In, First Out. A fila deve oferecer dois métodos públicos: - inclusão (append): inclui um elemento no fim (tail) da fila; - retirada (get): retira um elemento do início (head) da fila. Em caso de fila usada em programas monothreads as situações de exceção podem ser tratadas da seguinte forma: - se a fila está vazia em retirada: retorna um aviso; - se a fila está cheia em inclusão: idem. No caso de uso em programas multithread, pode-se oferecer soluções mais interessantes como fazer o usuário ou cliente (processo, thread) esperar em caso de exceção. Na situação de fila vazia em retirada, a thread cliente espera até haver alguma inclusão. Para simplificação do exemplo abaixo, para o caso de fila cheia considera-se que o buffer usado para armazenar os elementos da fila é ilimitado. Deve-se prever a concorrência possível entre diversas threads no acesso à fila. Essa concorrência permite que várias threads estejam inserindo e excluindo elementos ao mesmo tempo. Isto pode levar o objeto fila a um estado inconsistente, como ponteiros apontando para elementos

14 14 inexistentes. Esse problema, de exclusão mútua, pode ser resolvido de modo simples com o uso do modificador synchronized nos métodos append e get. Um segundo problema a ser resolvido é o de bloquear o cliente que chama o método get() quando a fila está vazia. Isto pode ser resolvido com o uso da primitiva wait() sobre o próprio objeto servidor (implicitamente no código abaixo). O terceiro problema, relacionado ao segundo, é o acordar o mesmo cliente quando algum elemento for incluído na fila. O uso da primitiva notify() resolve o mesmo. Uma extensão do problema geral é a de, considerando que o buffer é limitado, por exemplo a N elementos, bloquear o cliente que tenta incluir um elemento quando a fila está cheia. A solução da extensão é deixada a cargo dos leitores. Um esqueleto de código do problema básico, considerando somente a exclusão bloqueio em caso de fila vazia, está abaixo: classe Queue { Element head, tail; // first and last element of the queue // structure: element and pointer (next) // inserts element at the end of the queue public synchronized void append(element p) { if (tail == null) else head = p; tail.next = p; p.next = null; tail = p; notify(); // if queue is empty: simple case // first element is the new element // last elem. points to new element // next of last element is null // last element is the new element // notify someone that 1 element arrived mútua e o public synchronized Element get() { try { while (head = null) // if queue is empty? wait(); // wait for an element catch (InterruptedException e) { return null; Element p = head; // save first element head = head.next; // take out of queue if (head == null) // queue is empty?

15 15 tail = null; // last element null return p; 3.5. Controle de threads O ambiente Java ainda oferece um conjunto de métodos para controle de threads. Esses métodos são em geral chamados por outra thread (objeto) fazendo referência a uma segunda thread (objeto). Por exemplo, em thread a sobre thread b: b.stop(); Alguns desses métodos, em princípio os mais importantes, são brevemente descritos a seguir: Método start() stop() isalive() suspend() resume() sleep(long ml) Descrição inicia execução da thread principal (run) do objeto; JVM chama o método run() força a própria thread a terminar sua execução testa se a thread foi iniciada e ainda não terminou suspende a thread até ser reativada (resume()) reativa thread suspensa anteriormente a thread é colocada em espera ( dormindo ) por ml milisegundos; a thread não abandona o monitor (synchronized) Tabela 1 - Métodos de controle de threads 3.6. Endereços Alguns endereços de sites relacionados com Java estão indicados a seguir: Descrição site da Sun sobre Java notas técnicas tutorial Java tutor Java Java ensina Java Endereço dex.html html

16 16 outro tutorial Java Tabela 2 - Sites sobre Java 3.7. News Groups Alguns nomes de news groups relacionados a Java estão indicados a seguir: comp.lang.java.announce comp.lang.java.api comp.lang.java.beans comp.lang.java.databases comp.lang.java.gui comp.lang.java.help comp.lang.java.machine comp.lang.java.programmer comp.lang.java.security comp.lang.java.softwaretools comp.lang.java.tech

17 17 4. Java RMI - comunicação por chamada de método remoto 4.1. Introdução Este texto introduz os conceitos do pacote RMI, um tópico importante da programação distribuída com Java. Alguns dos principais tópicos abordados nesse texto são: - conceitos básicos de RMI: lado servidor e lado cliente; - exemplo Hello; - roteiro de desenvolvimento; - segurança; - pacote RMI Conceitos básicos RMI, ou "Remote Method Invocation" (Invocação Remota de Método) é um mecanismo que permite a chamada de métodos de objetos remotos (distribuídos). O nome ou sigla RMI é bastante associado ao mecanismo proprietário do ambiente Java. Entretanto, ele pode ser usado para outros mecanismos em geral, como CORBA e DCOM (apesar de, nesses ambientes, serem empregados outros termos), ou mesmo como o termo genérico para chamada remota de método. O objetivo principal é o de oferecer comunicação entre objetos distribuídos de forma similar à comunicação entre objetos locais. Isto simplifica a programação de sistemas distribuídos. RMI apresenta características similares às de RPC (chamada remota de procedimento), um conceito mais antigo de comunicação, mas também introduz diferenças importantes. Outras características do RMI são: - tratamento automático/implícito da heterogeneidade entre máquinas; - modelo cliente/servidor; - comunicação bidirecional; - argumentos de entrada; - valor de retorno. As duas últimas características têm sintaxe idêntica e semântica similar às de chamada local de método. Existem entretanto diferenças sensíveis entre RPC e RMI. Em RPC é realizada a chamada de um procedimento de um módulo servidor (e não de um objeto). A identificação do módulo é freqüentemente implícita na chamada. Só há um procedimento com determinado nome no módulo. O procedimento usa os dados (contexto) do módulo e não de um objeto. O cliente não pode acessar diferentes instâncias do mesmo tipo de servidor, como é possível no modelo OO (orientação a objetos), em especial com RMI, sendo que cada instância tem um estado (dados, contexto) próprio.

18 18 Em RMI, é realizada a chamada de um método de um objeto específico, o qual é sempre explicitado na chamada. Vários objetos podem ter o mesmo método (nome, argumentos e valor de retorno). Os objetos têm dados (contexto) locais ou próprios. Os objetos (e não os métodos) são registrados no sistema de RMI Recursos básicos As principais características do uso de RMI são descritas nessa seção. O objeto servidor deve ser registrado com nomes dados pelo usuário (programador), em um servidor de nomes próprio do RMI, denominado rmiregistry. Opcionalmente pode-se usar outros servidores de nomes via a API JNDI. O cliente precisa localizar os objetos remotos (servidores), obtendo como resultado referências a esses objetos. Para isto o cliente deve acessar o mesmo rmiregistry, via o nome associado ao objeto servidor, para obter a referência. Em outras palavras, no caso básico, o programador do objeto cliente precisa conhecer esses nomes dados pelo programador do objeto servidor. A comunicação entre objetos é deixada totalmente a cargo do RMI, ou seja, é transparente ao programador e similar à comunicação local. Eventualmente, em uma aplicação pode ser necessária a carga de classes de objetos que foram passados pela rede. Isto é implementado via o uso de servidores WEB e protocolos como HTTP, FTP, Comunicação entre os componentes Um aspecto importante da comunicação entre os componentes do sistema RMI é a passagem de parâmetros e resultados entre duas máquinas, principalmente se as duas são heterogêneas. Os tipos primitivos (por exemplo, int, boolean, double,...) são passados por valor na sua forma normal (lembrar que a forma normal dos tipos primitivos Java é única para qualquer ambiente - hardware e SO). Os objetos remotos (isto é, objetos que implementam a interface remota) são passados como referências remotas, apenas para permitir que o receptor possa chamar os métodos dos objetos remotos. Isto nada mais é do que dizer que o objeto servidor não é (implicitamente) passado (ou copiado) para a máquina do objeto cliente. A transferência da referência é realizada implicitamente no momento da busca do servidor pelo cliente. Todos os outros objetos são serializados e então passados por valor (isto é, uma cópia do objeto é transferida). Serialização é um mecanismo de transformação de um objeto Java em uma seqüência de bytes, de modo que o mesmo possa ser transferido pela rede ou gravado em um arquivo Diferenças entre RMI e chamada local de método Diferentes tipos de falhas podem ocorrer em um sistema distribuído, afetando a programação. Por exemplo, a falha pode atingir somente o servidor e não o cliente, o qual continua sua execução, podendo ficar bloqueado à espera de uma resposta do servidor. Alguns métodos, como hashcode, equals, e tostring, são sensíveis a contextos distribuídos, podendo apresentar comportamento diferente.

19 Camadas de software do sistema RMI (exemplo Hello) No lado do servidor os métodos remotos devem ser especificados em uma interface remota que estende a classe java.rmi.remote do pacote RMI. Os objetos remotos são instâncias de classes que implementam a interface remota; essas classes devem ser definidas como subclasses de java.rmi.server.unicastremoteobject, uma classe do pacote RMI. Opcionalmente, pode-se estender qualquer classe e chamar o método estático UnicastRemoteObject.exportObject(objeto). O programa servidor (pode ser o main) deve criar um objeto remoto da classe acima, associar esse objeto a um nome simbólico e incluir essa associação no rmiregistry. Métodos remotos e construtores de objetos remotos podem disparar exceções do tipo RemoteExceptions; elas devem ser declaradas e tratadas. Para ilustrar esses conceitos, será usado o clássico e simples exemplo do Hello World. O mesmo será desenvolvido de forma gradativa. Uma implementação desse problema no paradigma clienteservidor pode ser: o cliente faz uma chamada ao servidor que imprime o string Hello World. A interface do servidor é a seguinte: // todos os arqs em um pacote package hello; // importa pacote de classes RMI import java.rmi.*; // interface do objeto servidor public interface Hello extends Remote { // um único método sayhello public String sayhello() throws java.rmi.remoteexception; A implementação da classe do servidor é simples, pois o mesmo tem um único método que imprime o string Hello World. Conforme dito acima, a complexidade adicional vem dos requisitos de uso do rmiregistry e do tratamento obrigatório de eventuais exceções. O código da classe servidor é: package hello; import java.rmi.*; import java.rmi.server.*; // herda a UnicastRemoteObject e implementa a interface Hello public class HelloImpl extends UnicastRemoteObject implements Hello{ // implementa o construtor public HelloImpl() throws RemoteException{

20 20 super(); // implementa o método sayhello public String sayhello() throws RemoteException { return Hello, World! ; // método main da classe servidora public static void main (String args[]) { try { // cria objeto HelloImpl HelloImpl h = new HelloImpl(); //registra o objeto Naming.rebind( hello, h); catch (Exception e) { System.out.println( HelloImpl.main: + e); O lado do cliente é diferente da versão seqüencial em 3 aspectos: questões de segurança, busca do servidor e tratamento das eventuais exceções. Em geral, um cliente que queira utilizar classes de um servidor remoto deve estabelecer um gerenciador de segurança, por exemplo, o RMISecurityManager, fornecido pelo ambiente Java (por exemplo, o JDK da Sun). O cliente referencia o objeto remoto usando seu nome simbólico para procurá-lo no rmiregistry. A partir desse momento, o cliente pode chamar métodos de um objeto remoto da mesma maneira que ele chama métodos de objetos locais. Deve entretanto tratar as exceções do tipo RemoteException dos métodos remotos. O código da classe cliente é: package hello; import java.rmi.*; public class HelloClient { public static void main (String args[]) { System.setSecurityManager (new RMISecurityManager());

21 21 try { Hello h = (Hello) Naming.lookup( rmi://ijui.inf.ufrgs.br/hello ); //chama um método remoto String message = h.sayhello(); System.out.println(message); catch (Exception e) { System.out.println( Exception in main : + e); 4.7. Passos do uso de RMI Os passos necessários ao desenvolvimento e execução de clientes e servidores remotos com comunicação por RMI são: 1) Escrever arquivos Java para: interface remota; classe que implementa a interface remota (servidor); classe que chama o método remoto (cliente). 2) Compilar os arquivos.java com javac (ou outra ferramenta de desenvolvimento Java) 3) Gerar arquivos stubs e skeletons com o compilador RMI rmic rmic < classe que implementa a interface remota> Alguns cuidados devem ser tomados com relação a diretórios e caminhos (paths) em caso de uso da opção de pacote (package: agrupar todos os fontes de uma aplicação). 4) Iniciar o registry daemon na máquina remota Se o sistema for de tipo Unix (Solaris da Sun, por exemplo) executa-se: rmiregistry & Se for Windows 95/97/Me/NT/2000: start rmiregistry 5 ) Iniciar o servidor na máquina remota Se o RMISecurityManager foi criado, é preciso indicar a política de controle, normalmente através de um arquivo especial (policy). Um exemplo de política totalmente aberta (cuidado!) para testes é gerar um arquivo policy com conteúdo: grant { // Allow everything for now permission

22 22 java.security.allpermission; ; 5 ) Iniciar o servidor na máquina remota Um exemplo de chamada é: java -Djava.security.manager=myHome\mySources\policy hello.helloimpl O arquivo \myhome\mysources\policy contém a política. 6) Iniciar o programa cliente na máquina cliente java hello.helloapp 4.8. Segurança do RMI Um programa (normalmente o cliente) que queira utilizar classes de uma máquina remota deve estabelecer um gerenciador de segurança, por exemplo: System.setSecurityManager (new RMISecurityManager()); O RMISecurityManager não permite que classes remotas (entre outras): - utilizem novas classes; - manipulem threads; - saiam da Máquina Virtual Java. Outros gerenciadores de segurança podem ser obtidos por construção estendendo-se o RMISecurityManager. Um exemplo seria a implementação da autenticação de chaves públicas Outros aspectos Um aspecto importante da programação com RMI é a chamada Integridade Referencial. Quando duas (ou mais) referências ao mesmo objeto são passadas em uma mesma chamada remota, na máquina receptora elas apontarão para a mesma (única) cópia do objeto. Entretanto, se o mesmo for feito em duas chamadas, haverá duas cópias do objeto na máquina receptora. Um outro aspecto importante é a clássica semântica de chamada RPC em caso de falhas. O programador de RMI pode ter certeza de que cada chamada é executada somente uma vez em caso de sucesso. Em caso de falhas (rede, servidor), há certeza de que a chamada foi executada ou uma única vez ou nenhuma Pacote java.rmi O pacote java.rmi deve ser usado por programas clientes e servidores. Ele contém diversas classes. A interface Remote deve ser usada na implementação das interfaces dos servidores. A classe Naming é usada para associação, desassociação e procura de objetos remotos. A classe RMISecurityManager é encarregada de testes de segurança em classes carregadas de

23 23 máquinas remotas, por exemplo, os stubs para os clientes. A classe RemoteException estende a java.lang.exception tendo subclasses, como por exemplo: - ConnectException - AccessException - NoSuchObjectException Elas devem ser pegas num bloco catch ou declaradas em uma cláusula throws. O pacote java.rmi.server é necessário somente para uso em servidores. Entre as classes mais importantes encontra-se a RemoteObject que estende java.lang.object e implementa métodos com semântica especial remota, como equals(), tostring(), hashcode(). A classe RemoteServer oferece métodos para controle da máquina cliente e do stream de saída para log das chamadas. Ela possui a subclasse UnicastRemoteObject, a qual usa sockets TCP para comunicação. Nessa classe, as referências remotas não permanecem válidas após reinícios (falha - start) do servidor e oferece uma única cópia do objeto (sem replicação). A classe java.rmi.activation.activatable é uma classe abstrata que oferece suporte para objetos persistentes e que são ativados pelo sistema (automaticamente) Pacote java.rmi.registry O pacote java.rmi.registry oferece basicamente as interfaces e classes da implementação do servidor de nomes usado em programação RMI. Ele entretanto pode ser usado para outras finalidades, em especial para o desenvolvimento de servidores de nomes mais evoluídos do que o atual oferecido pelo ambiente JDK (Sun). Um registro (servidor de nomes do RMI) é um objeto remoto que mapeia nomes para objetos remotos. Um registro pode ser usado em uma máquina virtual com outras classes de servidores ou sozinho. O pacote oferece duas interfaces para recuperação e registro de objetos através de um simples nome: - interface java.rmi.registry.registry; - interface java.rmi.registry.registryhandler: abandonado em novas versões. A interface java.rmi.registry.registry oferece métodos para procura, associação, reassociação, desassociação e listagem do conteúdo de um registro. A classe java.rmi.naming (faz parte do pacote java.rmi) usa a interface remota Registry para o uso de nomes baseados em URL.

24 24 5. Introdução a CORBA 5.1. Introdução Este texto contém uma introdução aos principais conceitos do padrão CORBA. Os principais tópicos a serem abordados são: - conceitos básicos de CORBA: definição, histórico, arquitetura,... - IDL: linguagem para declaração de interfaces; - arquitetura do ORB: barramento de comunicação entre objetos; - serviços CORBA; - facilidades e objetos de negócio O que é CORBA CORBA, ou Common Object Request Broker Architecture, é um padrão proposto pelo OMG (Object Management Group). CORBA pode ser visto como um conjunto de middlewares: - independentes de plataforma; - que permitem tratamento de sistemas e aplicações heterogêneas; - que usam a orientação a objetos Histórico CORBA Em abril de 1989 a OMG foi criada por 11 companhias, como 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems e Unisys Corporation. Em 1990 a OMG publica o Object Management Architecture Guide (OMA Guide), e em outubro de 1991 publica a especificação do CORBA 1.0, que contém: - IDL (linguagem de declaração de interfaces); - mapeamento para linguagem C; - uma API de serviços. Em fevereiro de 1992, a versão CORBA 1.1 é publicada, a qual foi muito difundida, eliminando ambiguidades da anterior e propondo novas interfaces. Em 1992 saiu uma revisão do OMA, e em dezembro de 1993 a CORBA 1.2, novamente eliminando ambiguidades. Em 1995 são adicionadas as Common Facilities. A versão CORBA 2.0 é anunciada em agosto de 1996, apresentando diversos protocolos para interoperabilidade entre diferentes ORBs, como GIOP, IIOP, DCE CIOP, além dos mapeamentos para Smalltalk e C++. Os mapeamentos para COBOL e Ada são introduzidos com a versão CORBA 2.1 em agosto de 1997, e em fevereiro de 1998 os para Java, junto com a interconexão para o padrão DCOM da Microsoft.

25 25 A versão CORBA 3.0 está em desenvolvimento há vários anos, e pode ser caracterizada como uma série de especificações mais ou menos independentes. As principais entre elas se referem a: - integração com Java e Internet; - qualidade da gerência de serviços; - componentes distribuídos Arquitetura CORBA A arquitetura CORBA, OMA, é organizada em diversos módulos: - application objects: -- desenvolvidos pelos usuários CORBA; - ORB: -- CORBA TM barramento que interliga todos os elementos; - common object services: -- coleção de serviços em nível de sistema; -- empacotados em interfaces especificadas em IDL; -- aumentam e complementam a funcionalidade do ORB; -- OMG: define mais de 15 padrões de serviços; CORBA common facilities: -- coleção de serviços para uso direto pelos objetos de aplicações; - domain interfaces: 5.5. IDL -- serviços para uso direto pelos objetos de aplicações de certos domínios; -- podem combinar facilities e services. A IDL é uma linguagem neutra de especificação de interfaces, usada no desenvolvimento de objetos servidores para a declaração dos métodos ou serviços. A descrição IDL de um componente/objeto CORBA estabelece uma relação contratual entre este e seus cliente e servidor, definindo a interface pela qual estes poderão interagir, no entanto sem fixar detalhes de implementação dos objetos. Ela é independente de linguagem de programação (C++, Java, Smalltalk,...). Atualmente oferece uma série de mapeamentos como C, C++, Ada, Smalltalk, COBOL e Java. Em particular, a IDL é usada para especificação de: - atributos de componentes; - classes pais (herança); - exceções; - eventos tipados (sinais).

26 26 A sintaxe da IDL pode ser caracterizada como um subset de C++ mais diversas palavras chaves para programação distribuída. A estrutura geral de um arquivo IDL é ilustrada a seguir: module <identificador> // define um escopo de nomes, equivalente a { <declarações de tipos de dados>; <declarações de constantes>; <declarações de exceções>; // namespaces em C++ ou packages em Java interface <identificador> [:<herança opcional>] { <declarações de tipos de dados>; <declarações de constantes>; <declarações de exceções>; [<tipo>] <identificador de método> (<parâmetros>).. [raises <exception>] [context]; [<tipo>] <identificador de método> (<parâmetros>).. [raises <exception>] [context]; interface <identificador> [:<herança opcional>] ORB O ORB (Object Request Broker), barramento que faz a ligação entre todos os módulos da OMA, possui diversas vantagens e características, das quais as mais importantes são introduzidas a seguir. O ORB permite chamadas estáticas e dinâmicas: - estáticas: ligações em tempo de compilação; - dinâmicas: ligações em tempo de execução.

27 27 Outros middlewares, em geral, oferecem somente chamadas estáticas. No ORB, as ligações para definição de serviços e chamadas são especificadas ou codificadas em linguagem de alto nível, como C++ mais IDL. Outros middlewares em geral permitem somente uma API de baixo nível como sockets, sem distinção entre especificação e implementação da interface. O sistema tem recursos para ser auto descritivo, via metadados para descrição de serviços (interfaces), usáveis em tempo de execução, e gerados automaticamente por precompiladores. Outros middlwares, em geral, não oferecem metadados. O ORB oferece transparência entre o local e o remoto, quanto a diversos itens como: - transporte, localização e ativação de objetos; - ordenação de bytes (arquitetura); - SO; - concorrência: processo único, multiprocessos em uma máquina, multiprocessos em rede. O ORB também suporta segurança e transações, via informações de segurança e de transações embutidas nas mensagens. As mensagens do ORB podem ser polimórficas, onde o efeito da chamada depende do objeto que atende. Ele é consistente com a tendência de especificação dos sistemas atuais, onde há separação entre especificação e implementação. Também permite tornar aplicações desenvolvidas em linguagens de outro paradigma, como COBOL, em objetos. Os mecanismos de chamada do ORB são similares aos de RPC (chamada remota de procedimento), mas entre os dois existem diferenças sensíveis como: - RPC: 1 único serviço (função); os dados são únicos; - ORB: 1 chamada: 1 função de 1 objeto que possui várias funções; cada objeto possui dados próprios (permitindo múltiplos dados ou estados). A estrutura interna do ORB é bastante complexa, podendo inicialmente ser dividida em duas grandes partes: o ORB cliente e o ORB servidor. A estrutura do ORB oferece independência sobre o servidor, pois esse pode ser implementado em outra linguagem, SO, máquina,... Um objeto pode ser servidor e cliente ao mesmo tempo. No lado do cliente, os principais componentes são: - stubs IDL para o cliente: implementam as chamadas estáticas do cliente para o servidor; - DII: é interface de chamada dinâmica, com a qual o cliente pode determinar métodos a chamar durante a execução; - repositório de interfaces: suporta obtenção e modificação de interfaces de componentes registrados; - interface ORBI: possui algumas API s para serviços locais; - recursos para chamadas estáticas e dinâmicas. As chamadas estáticas são mais fáceis de programar, mais rápidas e autodocumentáveis. As dinâmicas oferecem mais flexibilidade e são mais difíceis de programar. O servidor não distingue entre chamada estâtica e dinâmica.

28 28 No lado do servidor, os principais componentes são: - stubs IDL do servidor (skletons pela OMG): são as interfaces estáticas, havendo um stub para cada serviço; - interface de skeleton dinâmica (DSI): suporte ao mecanismo de ligação dinâmica, para servidores sem IDL skeletons compilados; - adaptador de objetos (Basic Object Adaptor - BOA): situado no topo dos serviços de comunicação do ORB, aceita requisições para objetos; é responsável (dinâmico) por instanciação de objetos, requisição de serviços, atribuição de ID s aos objetos (referências), registro de classes e objetos no RI,...; BOA: é o adaptador mínimo, padrão, definido no CORBA 2.0; os servidores podem suportar mais de um adpatador; - repositório de implementações: é um BD de informações sobre classes, objetos e ID s, e também informações associadas às implementações de ORB s ID s Globais e Protocolos Os ID's globais foram introduzidos no CORBA 2.0. São ID s únicos para todos os ORB s. O formato básico é composto de strings, em 3 níveis de nomes, gerados a partir de pragmas IDL ou outros métodos. Existem diversos protocolos de interconexão entre diferentes ORB s. O IIOP é um dos mais práticos, pois é um Internet Inter-ORB Protocol, especificado no CORBA 2.0 e baseado em TCP/IP. Todo ORB CORBA deve implementar o IIOP. Existem diversos protocolos inter-orb s específicos, chamados ESIOPS (Environment Specific Inter-ORB Protocols), para redes específicas. O GIOP (General Inter-ORB Protocol) é descrito por um conjunto de 7 mensagens e representações comuns de dados, ou CDR: Common Data Representation. Ele mapeia dados OMG-IDL em representação plana para uso em mensagens de redes, tratando: diferentes representações de hardware. O IIOP é a implementação do GIOP sobre TCP/IP. O IOR (Interoperable Object Reference) permite transmissão de referências de objetos entre ORB s distintos Serviços CORBA Os serviços CORBA são uma coleção de serviços empacotados com IDL, aumentando a funcionalidade do ORB. Por exemplo, serviços para criar um componente, nomeá-lo e introduzí-lo no ambiente. Os serviços são agrupados em diversos grupos (mais de 15). Alguns desses grupos de serviços (ou somente serviços) são: - serviço de vida (life cycle): operações de criação, cópia, movimento, exclusão de componentes; - serviços de persistência: operações (e serviços) para armazenamento persistente em diversos servidores de armazenamento como BD de objetos, BD relacionais, arquivos simples; - serviço de nomeação: operações para busca de componentes; permite uso de nomes de outros serviços de nomes como: ISO X.500, OSF DCE, Sun NIS, Novell NDS, Internet LDAP; - serviço de eventos: registro de interesse em evento por componente;

Invocação de Métodos Remotos

Invocação de Métodos Remotos Invocação de Métodos Remotos Java RMI (Remote Method Invocation) Tópicos Tecnologia RMI Introdução Modelo de camadas do RMI Arquitetura Fluxo de operação do RMI Passos para implementação Estudo de caso

Leia mais

Java RMI - Remote Method Invocation. Programação com Objetos Distribuídos (C. Geyer) Java-RMI 1

Java RMI - Remote Method Invocation. Programação com Objetos Distribuídos (C. Geyer) Java-RMI 1 Java RMI - Remote Method Invocation Programação com Objetos Distribuídos (C. Geyer) Java-RMI 1 Autores Autoria Cláudio Geyer Marcelo Castiglia Pereira Local Instituto de Informática UFRGS disciplinas:

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS CUP Disk Memoey CUP Memoey Disk Network CUP Memoey Disk Remote Method Invocation (RMI) Introdução Solução JAVA para Objetos Distribuídos Um objeto existe em uma máquina É possível

Leia mais

Chamadas Remotas de Procedimentos (RPC) O Conceito de Procedimentos. RPC: Programa Distribuído. RPC: Modelo de Execução

Chamadas Remotas de Procedimentos (RPC) O Conceito de Procedimentos. RPC: Programa Distribuído. RPC: Modelo de Execução Chamadas Remotas de Chamada Remota de Procedimento (RPC) ou Chamada de Função ou Chamada de Subrotina Método de transferência de controle de parte de um processo para outra parte Procedimentos => permite

Leia mais

Objetos Distribuídos - Programação Distribuída Orientado a Objetos. Luiz Affonso Guedes

Objetos Distribuídos - Programação Distribuída Orientado a Objetos. Luiz Affonso Guedes Objetos Distribuídos - Programação Distribuída Orientado a Objetos Luiz Affonso Guedes Introdução Conceitos básicos programação distribuída + programação orientada a objetos = Objetos distribuídos Motivação

Leia mais

Java 2 Standard Edition. Fundamentos de. Objetos Remotos. Helder da Rocha www.argonavis.com.br

Java 2 Standard Edition. Fundamentos de. Objetos Remotos. Helder da Rocha www.argonavis.com.br Java 2 Standard Edition Fundamentos de Objetos Remotos Helder da Rocha www.argonavis.com.br 1 Sobre este módulo Este módulo tem como objetivo dar uma visão geral, porém prática, da criação e uso de objetos

Leia mais

Invocação de Métodos Remotos RMI (Remote Method Invocation)

Invocação de Métodos Remotos RMI (Remote Method Invocation) Invocação de Métodos Remotos RMI (Remote Method Invocation) Programação com Objetos Distribuídos Um sistema de objetos distribuídos permite a operação com objetos remotos A partir de uma aplicação cliente

Leia mais

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB)

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB) Uma Introdução à Arquitetura Francisco C. R. Reverbel 1 Copyright 1998-2006 Francisco Reverbel O Object Request Broker (ORB) Via de comunicação entre objetos (object bus), na arquitetura do OMG Definido

Leia mais

MIDDLEWARE Aplicativos RMI, RPC e eventos Camadas Protocolo Requesição-Respostal Middleware Representação Externa dos Dados Sistemas Operacionais

MIDDLEWARE Aplicativos RMI, RPC e eventos Camadas Protocolo Requesição-Respostal Middleware Representação Externa dos Dados Sistemas Operacionais RMI JAVA MIDDLEWARE Aplicativos RMI, RPC e eventos Protocolo Requesição-Respostal Camadas Middleware Representação Externa dos Dados Sistemas Operacionais RMI REMOTE METHOD INVOCATION Invocação remota

Leia mais

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008.

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. Common Object Request Broker Architecture [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. From: Fintan Bolton Pure CORBA SAMS, 2001 From: Coulouris, Dollimore and

Leia mais

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br CORBA Common Object Request Broker Architecture Unicamp Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br Objetivos Apresentação Tecnologia CORBA Conceitos Básicos e Terminologia Considerações

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Marcelo Lobosco DCC/UFJF Comunicação em Sistemas Distribuídos Aula 06 Agenda Modelo Cliente-Servidor (cont.) Invocação Remota de Método (Remote Method Invocation RMI) Visão Geral

Leia mais

Laboratório de Computação VI JAVA IDL. Fabricio Aparecido Breve - 981648-9

Laboratório de Computação VI JAVA IDL. Fabricio Aparecido Breve - 981648-9 Laboratório de Computação VI JAVA IDL Fabricio Aparecido Breve - 981648-9 O que é Java IDL? Java IDL é uma tecnologia para objetos distribuídos, ou seja, objetos em diferentes plataformas interagindo através

Leia mais

Como foi exposto anteriormente, os processos podem ter mais de um fluxo de execução. Cada fluxo de execução é chamado de thread.

Como foi exposto anteriormente, os processos podem ter mais de um fluxo de execução. Cada fluxo de execução é chamado de thread. 5 THREADS Como foi exposto anteriormente, os processos podem ter mais de um fluxo de execução. Cada fluxo de execução é chamado de thread. 5.1 VISÃO GERAL Uma definição mais abrangente para threads é considerá-lo

Leia mais

THREADS EM JAVA. George Gomes Cabral

THREADS EM JAVA. George Gomes Cabral THREADS EM JAVA George Gomes Cabral THREADS Fluxo seqüencial de controle dentro de um processo. Suporte a múltiplas linhas de execução permite que múltiplos processamentos ocorram em "paralelo" (em computadores

Leia mais

INE5380 - Sistemas Distribuídos

INE5380 - Sistemas Distribuídos INE5380 - Sistemas Distribuídos Object Request Broker e CORBA Por: Léo Willian Kölln - 0513227-4 Novembro de 2006 ORB Object Request Broker ORB aqui será tratado como um Middleware que permite a construção

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com Relembrando... Mecanismos de Comunicação Middleware Cenário em uma rede Local

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Faculdades SENAC Análise e Desenvolvimento de Sistemas 28 de abril de 2010 Principais suportes de Java RMI (Remote Method Invocation), da Sun Microsystems DCOM (Distributed Component Object Model), da

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

Sistemas Distribuídos RPC x RMI. Edeyson Andrade Gomes www.edeyson.com.br

Sistemas Distribuídos RPC x RMI. Edeyson Andrade Gomes www.edeyson.com.br Sistemas Distribuídos RPC x RMI Edeyson Andrade Gomes www.edeyson.com.br Roteiro da Aula Chamada Remota a Procedimento Definição Passagem de Parâmetros STUBS Semântica de Falhas 2 RPC Chamada Remota a

Leia mais

Sistemas Paralelos e Distribuídos - 2003/2004 Curso: Matemática /Informática Sistemas Distribuídos - 2003/2004 Curso: Ensino da Informática

Sistemas Paralelos e Distribuídos - 2003/2004 Curso: Matemática /Informática Sistemas Distribuídos - 2003/2004 Curso: Ensino da Informática Java RMI - Remote Method Invocation Folha 5-1 No modelo de programação orientada a objectos, vimos que um programa consiste numa colecção de objectos que comunicam entre si através da invocação dos seus

Leia mais

OBJETOS DISTRIBUÍDOS E INVOCAÇÃO REMOTA

OBJETOS DISTRIBUÍDOS E INVOCAÇÃO REMOTA OBJETOS DISTRIBUÍDOS E INVOCAÇÃO REMOTA SUMÁRIO Introdução Comunicação entre objetos distribuídos Eventos e Notificações 1.INTRODUÇÃO Middleware oferece: Transparência de localização Independência de protocolos

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Tutorial RMI (Remote Method Invocation) por Alabê Duarte

Tutorial RMI (Remote Method Invocation) por Alabê Duarte Tutorial RMI (Remote Method Invocation) por Alabê Duarte Este tutorial explica basicamente como se implementa a API chamada RMI (Remote Method Invocation). O RMI nada mais é que a Invocação de Métodos

Leia mais

CORBA Common Object Request Broker Architecture. Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos

CORBA Common Object Request Broker Architecture. Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos CORBA Common Object Request Broker Architecture Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos Introdução OMG (Object Management Group): uma organização formada por empresas

Leia mais

Num sistema de objectos distribuídos, dois conceitos são fundamentais.

Num sistema de objectos distribuídos, dois conceitos são fundamentais. Folha 10-1 Java RMI - Remote Method Invocation No modelo de programação orientada a objectos, vimos que um programa consiste numa colecção de objectos que comunicam entre si através da invocação dos seus

Leia mais

Programação Orientada a Objetos em Java. Threads Threads Threads. Threads

Programação Orientada a Objetos em Java. Threads Threads Threads. Threads Universidade Federal do Amazonas Departamento de Ciência da Computação IEC481 Projeto de Programas Programação Orientada a Objetos em Java Threads Threads Threads Threads Professor: César Melo Slides baseados

Leia mais

Remote Procedure Call. Programação distribuída e paralela (C. Geyer) RPC 1

Remote Procedure Call. Programação distribuída e paralela (C. Geyer) RPC 1 Remote Procedure Call Programação distribuída e paralela (C. Geyer) RPC 1 Autoria Autores C. Geyer Local II-UFRGS Versão V11.4 2014-2 Disciplinas SOII Programação distribuída e paralela (C. Geyer) RPC

Leia mais

Adriano Reine Bueno Rafael Barros Silva

Adriano Reine Bueno Rafael Barros Silva Adriano Reine Bueno Rafael Barros Silva Introdução RMI Tecnologias Semelhantes Arquitetura RMI Funcionamento Serialização dos dados Criando Aplicações Distribuídas com RMI Segurança Exemplo prático Referências

Leia mais

Programação distribuída e paralela (C. Geyer) RPC 1

Programação distribuída e paralela (C. Geyer) RPC 1 Programação distribuída e paralela (C. Geyer) RPC 1 Autores C. Geyer Local II-UFRGS Versão v6 2008-2 Disciplinas SOII Programação distribuída e paralela (C. Geyer) RPC 2 Bibliografia base original dos

Leia mais

Programação Concorrente em java - Exercícios Práticos Abril 2004

Programação Concorrente em java - Exercícios Práticos Abril 2004 Programação Concorrente em java - Exercícios Práticos Abril 2004 1. Introdução As threads correspondem a linhas de controlo independentes no âmbito de um mesmo processo. No caso da linguagem JAVA, é precisamente

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

3. Comunicação em Sistemas Distribuídos

3. Comunicação em Sistemas Distribuídos 3. Comunicação em 3.1.Troca de mensagens As mensagens são objetos de dados cuja estrutura e aplicação são definidas pelas próprias aplicações que a usarão. Sendo a troca de mensagens feita através de primitivas

Leia mais

Middleware de Aplicações Paralelas/Distribuídas

Middleware de Aplicações Paralelas/Distribuídas Computação Paralela Middleware de Aplicações Paralelas/Distribuídas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho Outubro 2005 Principais aspectos a gerir pelo Middleware

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services Web Services Existem diferentes tipos de comunicação em um sistema distribuído: Sockets Invocação

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Soquetes Um soquete é formado por um endereço IP concatenado com um número de porta. Em geral, os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Comunicação Inter-Processos Sockets e Portas Introdução Sistemas distribuídos consistem da comunicação entre processos

Leia mais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

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 3 Invocação de Objetos

Leia mais

COMUNICAÇÃO INTER-PROCESSOS JAVA RMI e RPC. Prof. Cesar Augusto Tacla http://www.dainf.ct.utfpr.edu.br/~tacla

COMUNICAÇÃO INTER-PROCESSOS JAVA RMI e RPC. Prof. Cesar Augusto Tacla http://www.dainf.ct.utfpr.edu.br/~tacla PR UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ COMUNICAÇÃO INTER-PROCESSOS JAVA RMI e RPC Prof. Cesar Augusto Tacla http://www.dainf.ct.utfpr.edu.br/~tacla 1 1. Conceitos Básicos a. Invocação remota (RPC/RMI)

Leia mais

1 a. Sumário. 1. Conceitos Básicos a. Invocação remota (RPC/RMI) b. Semântica de invocação remota c. Invocação remota de métodos (RMI)

1 a. Sumário. 1. Conceitos Básicos a. Invocação remota (RPC/RMI) b. Semântica de invocação remota c. Invocação remota de métodos (RMI) PR UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ COMUNICAÇÃO INTER-PROCESSOS JAVA RMI e RPC Prof. Cesar Augusto Tacla http://www.dainf.ct.utfpr.edu.br/~tacla 1. Conceitos Básicos a. Invocação remota (RPC/RMI)

Leia mais

Exemplos práticos do uso de RMI em sistemas distribuídos

Exemplos práticos do uso de RMI em sistemas distribuídos Exemplos práticos do uso de RMI em sistemas distribuídos Elder de Macedo Rodrigues, Guilherme Montez Guindani, Leonardo Albernaz Amaral 1 Fábio Delamare 2 Pontifícia Universidade Católica do Rio Grande

Leia mais

1.6. Tratamento de Exceções

1.6. Tratamento de Exceções Paradigmas de Linguagens I 1 1.6. Tratamento de Exceções Uma exceção denota um comportamento anormal, indesejado, que ocorre raramente e requer alguma ação imediata em uma parte do programa [GHE 97, DER

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

Fundamentos de Programaçã. ção Concorrente

Fundamentos de Programaçã. ção Concorrente Java 2 Standard Edition Fundamentos de Programaçã ção Concorrente Helder da Rocha www.argonavis.com.br 1 Programação concorrente O objetivo deste módulo é oferecer uma introdução a Threads que permita

Leia mais

Sistemas Distribuídos Comunicação entre Processos em Sistemas Distribuídos: Middleware de comunicação Aula II Prof. Rosemary Silveira F. Melo Comunicação em sistemas distribuídos é um ponto fundamental

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

Princípios de Sistemas Distribuídos. Tecnologias utilizadas em sistemas distribuídos Aula 5

Princípios de Sistemas Distribuídos. Tecnologias utilizadas em sistemas distribuídos Aula 5 Princípios de Sistemas Distribuídos Tecnologias utilizadas em sistemas distribuídos Aula 5 Conceitos de comunicação entre processos Interprocess Communication (IPC) Sistemas distribuídos são construídos

Leia mais

Programação Concorrente em Java. Profa Andréa Schwertner Charão DLSC/CT/UFSM

Programação Concorrente em Java. Profa Andréa Schwertner Charão DLSC/CT/UFSM Programação Concorrente em Java Profa Andréa Schwertner Charão DLSC/CT/UFSM O que é programação concorrente? Um programa, múltiplos fluxos de execução Quando usar programação concorrente? Desempenho Ex.:

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Java Threads. Introdução

Java Threads. Introdução Java Threads mleal@inf.puc-rio.br 1 Introdução O único mecanismo de concorrência suportado explicitamente pela linguagem Java é multi-threading. threading. Os mecanismos de gerenciamento e sicronização

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Sistemas Distribuídos 59. Sistemas Distribuídos 61. "Receive não-bloqueante:

Sistemas Distribuídos 59. Sistemas Distribuídos 61. Receive não-bloqueante: Comunicação entre processos! Memória Compartilhada: " os processo compartilham variáveis e trocam informações através do uso dessas variáveis compartilhadas COMUNICAÇÃO ENTRE PROCESSOS P1 Área Compartilhda!

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Comunicação Remota Gustavo Reis gustavo.reis@ifsudestemg.edu.br 1 Comunicação entre processos está no coração de todo sistema distribuído. Não tem sentido estudar sistemas distribuídos

Leia mais

Programação Concorrente Processos e Threads

Programação Concorrente Processos e Threads Programação Concorrente Processos e Threads Prof. Eduardo Alchieri Processos O conceito mais central em qualquer sistema operacional é o processo Uma abstração de um programa em execução Um programa por

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 Comunicação- Protocolos, Tipos, RPC Capítulo 4 Agenda Protocolos em Camadas Pilhas de Protocolos em Sistemas Distribuídos Tipos de Comunicação

Leia mais

Middleware. Camada Intermediária de Suporte a Sistemas Distribuídos

Middleware. Camada Intermediária de Suporte a Sistemas Distribuídos Middleware Camada Intermediária de Suporte a Sistemas Distribuídos Alternativas de comunicação entre processos (IPC) Mecanismos de IPC tradicionais (ou de baixo nível) Memória compartilhada, filas de mensagens,

Leia mais

Threads e Concorrência em Java (Material de Apoio)

Threads e Concorrência em Java (Material de Apoio) Introdução Threads e Concorrência em Java (Material de Apoio) Professor Lau Cheuk Lung http//www.inf.ufsc.br/~lau.lung INE-CTC-UFSC A maioria dos programas são escritos de modo seqüencial com um ponto

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Processos I: Threads, virtualização e comunicação via protocolos Prof. MSc. Hugo Souza Nesta primeira parte sobre os Processos Distribuídos iremos abordar: Processos e a comunicação

Leia mais

RMI: Uma Visão Conceitual

RMI: Uma Visão Conceitual RMI: Uma Visão Conceitual Márcio Castro, Mateus Raeder e Thiago Nunes 11 de abril de 2007 Resumo Invocação de Método Remoto (Remote Method Invocation - RMI) trata-se de uma abordagem Java para disponibilizar

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

APÊNDICE A EXEMPLO DE APLICAÇÃO

APÊNDICE A EXEMPLO DE APLICAÇÃO APÊNDICE A EXEMPLO DE APLICAÇÃO Para ilustrar os três métodos de distribuição de objetos apresentados nesta dissertação iremos, a seguir, mostrar um exemplo de implementação de uma aplicação. São apresentadas

Leia mais

(Aula 17) Threads em Java

(Aula 17) Threads em Java (Aula 17) Threads em Java Difícil As Threads thread threads de emjava classificar sãogerenciadaspelajvm. podemser com user criadasdas thread ou kernel Profa. Patrícia A seguintesmaneiras: Fazendo extend

Leia mais

RMI/JNDI - Fundamentos

RMI/JNDI - Fundamentos c o l u n a Professor J RMI/JNDI - Fundamentos Um exemplo prático do que são e de como funcionam RMI e JNDI Roberto Vezzoni (roberto.vezzoni@gmail.com): SCJP, faz Ciência da Computação na Faesa e atua

Leia mais

Comunicação. Parte II

Comunicação. Parte II Comunicação Parte II Carlos Ferraz 2002 Tópicos Comunicação Cliente-Servidor RPC Comunicação de objetos distribuídos Comunicação em Grupo Transações Atômicas Comunicação Stream 2 Comunicação cliente-servidor

Leia mais

Introdução a Java. Hélder Nunes

Introdução a Java. Hélder Nunes Introdução a Java Hélder Nunes 2 Exercício de Fixação Os 4 elementos básicos da OO são os objetos, as classes, os atributos e os métodos. A orientação a objetos consiste em considerar os sistemas computacionais

Leia mais

A ) O cliente terá que implementar uma interface remota. . Definir a interface remota com os métodos que poderão ser acedidos remotamente

A ) O cliente terá que implementar uma interface remota. . Definir a interface remota com os métodos que poderão ser acedidos remotamente Java RMI - Remote Method Invocation Callbacks Folha 9-1 Vimos, na folha prática anterior, um exemplo muito simples de uma aplicação cliente/ servidor em que o cliente acede à referência remota de um objecto

Leia mais

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Aula passada Threads Threads em SDs Processos Clientes Processos Servidores Aula de hoje Clusters de Servidores Migração de Código Comunicação (Cap. 4) Fundamentos

Leia mais

Sistemas Operacionais

Sistemas Operacionais UNIVERSIDADE BANDEIRANTE DE SÃO PAULO INSTITUTO POLITÉCNICO CURSO DE SISTEMAS DE INFORMAÇÃO Sistemas Operacionais Notas de Aulas: Tópicos 7 e 8 Estrutura do Sistema Operacional São Paulo 2009 1 Sumário

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Modelo Cliente-Servidor: Introdução aos tipos de servidores e clientes Prof. MSc. Hugo Souza Iniciando o módulo 03 da primeira unidade, iremos abordar sobre o Modelo Cliente-Servidor

Leia mais

Usando Borland DELPHI para implementar aplicações CORBA

Usando Borland DELPHI para implementar aplicações CORBA Página 1 de 10 USANDO BORLAND DELPHI PARA IMPLEMENTAR APLICAÇÕES CORBA por Simone Vey Dutra e César Bridi Introdução A Arquitetura CORBA Criando uma Aplicação CORBA em Delphi Criando um Servidor CORBA

Leia mais

Linguagens de. Aula 02. Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br

Linguagens de. Aula 02. Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br Linguagens de Programação III Aula 02 Profa Cristiane Koehler cristiane.koehler@canoas.ifrs.edu.br Linguagens de Programação Técnica de comunicação padronizada para enviar instruções a um computador. Assim

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

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br Java Marcio de Carvalho Victorino www.dominandoti.eng.br 3. Considere as instruções Java abaixo: int cont1 = 3; int cont2 = 2; int cont3 = 1; cont1 += cont3++; cont1 -= --cont2; cont3 = cont2++; Após a

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Java 2 Standard Edition Como criar classes e objetos

Java 2 Standard Edition Como criar classes e objetos Java 2 Standard Edition Como criar classes e objetos Helder da Rocha www.argonavis.com.br 1 Assuntos abordados Este módulo explora detalhes da construção de classes e objetos Construtores Implicações da

Leia mais

FBV - Linguagem de Programação II. Um pouco sobre Java

FBV - Linguagem de Programação II. Um pouco sobre Java FBV - Linguagem de Programação II Um pouco sobre Java História 1992: um grupo de engenheiros da Sun Microsystems desenvolve uma linguagem para pequenos dispositivos, batizada de Oak Desenvolvida com base

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

Invocação de Métodos em Objectos Remotos

Invocação de Métodos em Objectos Remotos Invocação de Métodos em Objectos Remotos Invocações de métodos remotas e locais A remote invocation B local C invocation local E invocation local invocation D remote invocation F Page 1 1 Invocação de

Leia mais

Curso de Java. Orientação a objetos e a Linguagem JAVA. TodososdireitosreservadosKlais

Curso de Java. Orientação a objetos e a Linguagem JAVA. TodososdireitosreservadosKlais Curso de Java Orientação a objetos e a Linguagem JAVA Roteiro A linguagem Java e a máquina virtual Objetos e Classes Encapsulamento, Herança e Polimorfismo Primeiro Exemplo A Linguagem JAVA Principais

Leia mais

Sobre o Professor Dr. Sylvio Barbon Junior

Sobre o Professor Dr. Sylvio Barbon Junior 5COP088 Laboratório de Programação Aula 1 Java Prof. Dr. Sylvio Barbon Junior Sylvio Barbon Jr barbon@uel.br 1 Sobre o Professor Dr. Sylvio Barbon Junior Formação: Ciência e Engenharia da Computação (2005

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Modelo Cliente-Servidor: comunicação orientada por mensagem e comunicação orientada por fluxo Prof. MSc. Hugo Souza Continuando o módulo 03 da primeira unidade, iremos abordar sobre

Leia mais

Introdução a Threads Java

Introdução a Threads Java Introdução a Threads Java Prof. Gerson Geraldo Homrich Cavalheiro Universidade Federal de Pelotas Departamento de Informática Instituto de Física e Matemática Pelotas RS Brasil http://gersonc.anahy.org

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

Java RMI. Alcides Calsavara

Java RMI. Alcides Calsavara Java RMI Alcides Calsavara Objetivos Permitir que um método de uma classe Java em execução em uma máquina virtual JVM chame um método de um objeto (instância de uma classe Java) situado em outra máquina

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

Linguagem de Programação Orientada a Objeto. Introdução a Orientação a Objetos Professora Sheila Cáceres

Linguagem de Programação Orientada a Objeto. Introdução a Orientação a Objetos Professora Sheila Cáceres Linguagem de Programação Orientada a Objeto Introdução a Orientação a Objetos Professora Sheila Cáceres Introdução a Orientação a Objetos No mundo real, tudo é objeto!; Os objetos se relacionam entre si

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

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira neto Aula 17-18: Middleware: Implementação de RMI (cont.), RPC, Modelo de Eventos, Exemplo com Java RMI Chamadas dinâmicas

Leia mais

Threads em Java. Sistemas Operacionais - Laboratório Professor Machado

Threads em Java. Sistemas Operacionais - Laboratório Professor Machado Threads em Java Sistemas Operacionais - Laboratório Professor Machado 1 Conceitos de Programação Concorrente Uma unidade concorrente é um componente de um programa que não exige a execução seqüencial,

Leia mais

JavaScript 2.0X 1.0 3.0X 1.1 4.0 4.05 1.2 4.06 4.61 1.3 5.0 1.4 6.0 1.5

JavaScript 2.0X 1.0 3.0X 1.1 4.0 4.05 1.2 4.06 4.61 1.3 5.0 1.4 6.0 1.5 JavaScript Diego R. Frank, Leonardo Seibt FIT Faculdades de Informática de Taquara Fundação Educacional Encosta Inferior do Nordeste Av. Oscar Martins Rangel, 4500 Taquara RS Brasil difrank@terra.com.br,

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN

SISTEMAS OPERACIONAIS. Apostila 03 Estrutura do Sistema Operacional UNIBAN SISTEMAS OPERACIONAIS Apostila 03 Estrutura do Sistema Operacional UNIBAN 1.0 O Sistema Operacional como uma Máquina Virtual A arquitetura (conjunto de instruções, organização de memória, E/S e estrutura

Leia mais

Capítulo V Sistemas de Objectos Distribuídos

Capítulo V Sistemas de Objectos Distribuídos From: Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, Addison-Wesley 2001 From: Wolfgang Emmerich Engineering Distributed Objects John Wiley & Sons, Ltd 2000 1 O modelo

Leia mais

EMENTA DO CURSO. Tópicos:

EMENTA DO CURSO. Tópicos: EMENTA DO CURSO O Curso Preparatório para a Certificação Oracle Certified Professional, Java SE 6 Programmer (Java Básico) será dividido em 2 módulos e deverá ter os seguintes objetivos e conter os seguintes

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Descrição. Implementação. Departamento de Informática e Estatística Universidade Federal de Santa Catarina LAB 4 Transferência de Arquivos

Descrição. Implementação. Departamento de Informática e Estatística Universidade Federal de Santa Catarina LAB 4 Transferência de Arquivos Departamento de Informática e Estatística Universidade Federal de Santa Catarina LAB 4 Transferência de Arquivos Descrição Implemente nesta atividade de laboratório um programa em Java utilizando threads

Leia mais