CAPÍTULO 6 CORBA / DCOM

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

Download "CAPÍTULO 6 CORBA / DCOM"

Transcrição

1 CAPÍTULO 6 CORBA / DCOM Após determinar quais objetos precisam ser implementados como locais e quais como distribuídos, é difícil optar por uma arquitetura de distribuição. Por exemplo, num caso hipotético, pode-se ter algumas das seguintes soluções (Schultz, 1997): Hardware CICS e sistema operacional OS/2 usando IBM s Distributed Object Model (DSOM). C usando Distributed Computing Environment (DCE). C++ usando Distributed Component Object Model (DCOM). Implementação baseada em uma solução CORBA usando, por exemplo, Iona s Orbix. Baseado em Web usando Java e HTML. Estas arquiteturas suportam o desenvolvimento de aplicações executando num ambiente heterogêneo e distribuído, e dispõem de serviços comuns às aplicações, tais como, comunicação entre cliente e servidor, isolamento das aplicações em relação às plataformas de hardware, sistemas operacionais, protocolos de rede e linguagens de implementação. Cada uma delas apresentará vantagens e desvantagens, isto é, uma melhor adequação para cada sistema em particular. Através de pesquisa bibliográfica, notou-se que as arquiteturas mais referenciadas são: o CORBA, o DCOM e o Java. Este capítulo enfoca a descrição dos resultados da comparação das arquiteturas de distribuição de objetos utilizadas pelo CORBA e DCOM (já descritas nos capítulos anteriores). 153

2 Posteriormente, é descrito o mecanismo utilizado pela linguagem de programação Java (que também permite a distribuição de objetos), porém, há diferenças entre a abordagem adotada pelo Java e a utilizada pelo CORBA e DCOM. 6.1 CORBA/DCOM Ambos, CORBA e DCOM, auxiliam a resolução de problemas surgidos quando se definem e implementam objetos num ambiente complexo. A meta dos sistemas distribuídos é permitir que códigos de programas e dados, armazenados em diferentes plataformas, trabalhem em conjunto. CORBA e DCOM provêem suporte similar para implementação de objetos acessíveis remotamente por aplicações. Esta capacidade simplifica a construção de sistemas distribuídos PADRONIZAÇÃO As organizações devem utilizar padrões como guias no desenvolvimento de sistemas porque tanto produtos podem ser comprados, como aplicações podem ser desenvolvidas com a confiança de que o hardware e o software trabalharão juntos por muitos anos. Os benefícios da padronização dos sistemas em ambientes distribuídos evidenciam-se na redução da complexidade do gerenciamento, no aumento do grau de interoperabilidade e usabilidade, assim como na redução dos custos de administração e suporte, pois estas se tornam mais especializadas (Nimer, 1998). Ao adotar um padrão, uma organização deve considerar a sua disponibilidade, maturidade, influência, estilo, precisão e propósito das suas especificações, assim como, produtos disponíveis, ferramentas de suporte ao desenvolvimento, 154

3 aceitação pelos desenvolvedores e referências de sucesso de implementações aderentes a esse padrão. Deve-se levar em conta também a plataforma de hardware (estações de trabalho, PCs, etc), o sistema operacional (UNIX, Windows, etc) e a rede disponível na organização, assim como, o nível de preparo da equipe (conhecimento de tecnologia de distribuição, padrões, conceitos de orientação a objeto, linguagens de programação orientadas a objeto, etc). Embora enfoquem diferentes aspectos, tanto o CORBA como o DCOM são padrões cujo propósito é atender a complexidade da distribuição de objetos. CORBA foi especificado para suprir os requisitos necessários à construção de um sistema distribuído. Surgiu como uma solução aos problemas enfrentados pelas organizações ao tentar integrar uma mescla de sistemas, mainframes, UNIX com várias arquiteturas de hardware, sistemas operacionais proprietários de minicomputadores, PCs Macintosh e IBM, etc. A meta foi combinar objetos e tecnologia de sistemas distribuídos dentro de uma arquitetura interoperável que pudesse resolver problemas de integração num empreendimento ( enterprise ). Desta forma, o foco principal do CORBA é definir uma estrutura que melhor solucione problemas de ambientes heterogêneos (Mowbray e Ruh, 1997) (Nicol et al, 1993) (Otte et al, 1996) (Tallman e Bradford, 1998). COM é uma infra-estrutura de integração usada para implementar componentes que interagem dentro de um espaço de endereçamento único ou entre processos num único host, enquanto o DCOM é uma extensão do COM que permite a interação entre objetos executando em hosts separados na rede. Assim, o foco principal do DCOM é suportar componentes executando em diferentes estações de trabalho (Grimes, 1997) (Mowbray e Ruh, 1997) (Tallman e Bradford, 1998). 155

4 6.1.2 MODELO DE OBJETO CORBA e DCOM apresentam nos seus modelos de objeto aspectos fundamentais concordantes. Por modelo de objeto entenda-se, basicamente, a forma com que uma arquitetura de distribuição resolve o problema da forte ligação existente entre a aplicação e os objetos a ela relacionados (Betz, 1994). Para minimizar esta ligação, tanto o CORBA como o DCOM, expressa seus modelos de objeto em termos de interface. O conceito de interface é utilizado para definir as funcionalidades de um objeto visto pelo seu cliente. Os detalhes da implementação do objeto são escondidos dos clientes que acessam o objeto somente pela invocação dos métodos definidos na interface os quais são atendidos somente por referência. As invocações remotas dos clientes são executadas no espaço de endereçamento ocupado pelo objeto. Este ocultamento da implementação ou encapsulamento reduz, a um mínimo, a ligação existente entre o cliente e a implementação de um objeto por ele utilizado, tornando possível suportar transparência de localização, plataforma e linguagem de programação. Também permite que programas selecionem a implementação do objeto a ser utilizada em tempo de execução, ao invés de em tempo de compilação ou link. Esta ligação dinâmica ( dynamic binding ) de código executável torna a atualização ( upgrade ) e o reuso da implementação mais fácil (Tallman e Bradford, 1998). Transparência é a possibilidade de esconder, do usuário, o ambiente distribuído. Ambos, CORBA e DCOM provêem: transparência de localização: clientes invocam serviços de objetos sem a preocupação de localizá-los. No DCOM, uma vez que o cliente adquire o ponteiro para a interface desejada de um objeto, ele pode iniciar o uso dos serviços providos por este objeto simplesmente invocando o método da interface. Para o cliente, invocar um método é 156

5 como invocar um procedimento ou função local. No CORBA, o ORB é que se encarrega de enviar a requisição do cliente aonde ela deva ser atendida, isto é, ele localiza o objeto bem como provê os serviços auxiliares necessários para a execução da requisição do cliente. transparência de plataforma: objetos podem ser executados, em diferentes hardwares ou sistemas operacionais, sem a preocupação de resolver as diferenças de representação dos dados existentes entre eles. No DCOM isto é possível através do protocolo Object RPC (ORPC), descrito no Capítulo 4. No CORBA através dos protocolos General inter-orb Protocol (GIOP) e Internet inter-orb Protocol (IIOP), descritos no Capítulo 5. transparência de linguagem de programação: objetos e clientes interagem entre si, apesar de serem implementados usando diferentes linguagens de programação. Tanto no CORBA como no DCOM isto é obtido através do uso de interfaces e linguagens de definição de interfaces (IDL), que serão melhor detalhadas adiante INTERFACE DE OBJETO Ambos, CORBA e DCOM, definem objetos da maneira convencional, isto é, uma coleção de métodos e dados. Os dois permitem acessar objetos através de interfaces específicas definidas por IDL, onde as particularidades das IDLs do CORBA e DCOM são descritas adiante. No DCOM, cada objeto apresenta duas ou mais interfaces a seu cliente que, comumente, possui múltiplos ponteiros de interfaces para o mesmo objeto COM (Betz, 1994) (Chappell, 1997) (Chung et al, 1998) (Grimes, 1997). Todos os objetos no DCOM suportam uma interface fundamental chamada lunknown. Esta interface suporta três métodos que provêem funcionalidades básicas para todos os objetos COM. Estes métodos são: QueryInterface que 157

6 permite ao cliente perguntar quais interfaces o objeto suporta; AddRef e Release que gerenciam o contador de referências para o objeto. O contador de referência para o objeto é um mecanismo que possibilita ao sistema rastrear quantos clientes possuem um ponteiro para uma ou mais interfaces do objeto. Quando este contador de referência alcançar zero, o sistema pode destruir o objeto. Adicionar funcionalidades em uma versão de um objeto COM é tornar disponível esta funcionalidade através de uma nova interface do objeto. As Interfaces existentes não devem ser alteradas para que seus antigos clientes não sejam afetados. Desta forma, eles nunca irão adquirir ponteiros para as novas interfaces. Apenas os novos clientes conhecerão as interfaces recémcriadas, ou seja, somente eles serão afetados pelas versões atualizadas de um objeto COM (Microsoft, 1998b). Por exemplo, suponha que exista um conjunto de ferramentas matemáticas implementado como um objeto COM suportando uma interface ICalculoTrigonometrico. Para acessar o serviço de cálculo trigonométrico, oferecido pelo objeto, uma determinada aplicação obtém, através do método QueryInterface da interface IUnknown, o ponteiro da interface ICalculoTrigonometrico. Como o objeto suporta essa interface ele retorna um ponteiro válido, caso contrário retornaria um ponteiro igual a NULL. Agora assuma que esse objeto, numa nova versão, suporta além do cálculo trigonométrico (interface ICalculoTrigonometrico) o cálculo logarítmico, onde a adição de uma nova funcionalidade implica na criação de um nova interface, no caso, ICalcLogaritmico. A aplicação que precisa do ponteiro da interface ICalculoTrigonometrico continua obtendo da forma como sempre fez e como desconhece a nova interface ICalcLogaritmico ela não irá buscar esse ponteiro. Agora, se uma nova aplicação utilizar, além de cálculos trigonométricos, cálculos logarítmicos ela poderá obter, através do método QueryInterface, o ponteiro de ambas as interfaces. Assim, atualizações no conjunto de 158

7 ferramentas matemáticas não implicam em atualizações nas aplicações que o utiliza. Essa forma de versionamento é dependente do método QueryInterface da interface IUnknown e da imutabilidade das interfaces suportadas por um objeto. Deve-se notar que não existe no COM nenhuma proteção que garanta esta imutabilidade. Esta é uma regra que deve ser obedecida pelos desenvolvedores. No CORBA, cada objeto apresenta uma única interface a seu cliente, o qual possui uma referência para o objeto como um todo. Clientes comunicam-se com objetos CORBA via ORB. No ORB, a interface do objeto é definida somente uma vez, assim ele não tem a necessidade da definição de uma interface diferente para cada tipo de interação possível com esse objeto. Cada objeto utiliza-se de um Adaptador de Objeto para conectar-se ao ORB. A maioria dos Adaptadores de Objeto são projetados para cobrir uma faixa larga de implementações, objetivando restringir o projeto de um novo adaptador somente quando uma implementação requeira um serviço ou uma interface muito diferente (Queiroz e Madeira, 1998) (Mowbray e Ruh, 1997). Para satisfazer diferentes tipos de requisições de clientes, um servidor de objeto pode utilizar, para conectar-se a um ORB, vários tipos de Adaptadores de Objetos. A OMG, para restringir os tipos de adaptadores, especificou o Adaptador de Objeto Básico ( Basic Object Adapter BOA) (Orfali et al, 1996). A implementação do BOA deve prover as seguintes funcionalidades básicas: gerar e interpretar referências de objetos, invocar métodos, garantir segurança, ativar e desativar objetos, mapear as referências dos objetos às suas correspondentes implementações e registrar implementações. 159

8 Para cobrir uma faixa larga de tipos de aplicações, o CORBA definiu quatro políticas de ativação de objetos que devem ser suportadas pelo BOA, sendo elas (Orfali et al, 1996): Servidor compartilhado: quando num servidor múltiplos objetos residem num mesmo processo (programa) o BOA ativa o servidor no primeiro pedido de requisição feito a qualquer um dos objetos nele implementado. O BOA só ativará outro servidor após o término do atendimento de todas as requisiçôes feitas ao servidor ativado anteriormente. Servidor não compartilhado: quando num servidor cada objeto reside em um processo diferente o BOA ativa o servidor no primeiro pedido de requisição feito ao objeto nele implementado. Caso uma requisição seja enviada a outro servidor o BOA o ativará mesmo que o anterior ainda esteja ativo. Servidor por método: o BOA ativa o servidor a cada pedido de requisição feito ao objeto nele implementado. O servidor executa somente durante o período necessário ao atendimento da requisição (tempo para execução do método). Servidor persistente: os servidores são ativados externamente ao BOA. O BOA envia o pedido de requisição a um scheduler que ativa o servidor correspondente. Após a ativação do servidor o BOA só ativará outro servidor após o término do atendimento de todas as requisiçôes feitas ao servidor ativado anteriormente. Em relação ao tratamente de versões de objetos CORBA encontra-se em estudo um Request for Proposal (RFP) para o desenvolvimento de um serviço de gerenciamento de alterações ( Change Management Service ). Esse serviço suportará a identificação e evolução dos objetos incluindo gerenciamento de configuração e versão (CORBAservices, 1998). 160

9 Novas funcionalidades no DCOM implicam em novas interfaces e no CORBA em um novo adaptador de objeto, assim, no DCOM o número de interfaces entre N objetos pode representar um problema de ordem (NxN) enquanto no CORBA, devido ao ORB, somente N interfaces são necessárias entre N objetos, como mostrado na Figura 6.1 (Queiroz e Madeira, 1998) (Mowbray e Ruh, 1997). A B A B C F C ORB - CORBA E D D E F Ordem (N x N) interfaces Ordem N interfaces Fig. 6.1 Número de interfaces necessárias para integração entre objetos FONTE: Mowbray e Ruh (1997, p.15) IDL Ambos, CORBA e DCOM, provêem IDL, mas elas apresentam diferenças fundamentais entre si. A IDL é considerada, na arquitetura CORBA, um item fundamental utilizado para definição das interfaces, e possui uma notação universalmente aplicável em APIs. A Figura 6.2 mostra o mapeamento entre a IDL CORBA e as linguagens de programação utilizadas para implementar objetos. Por mapeamento entenda-se a forma que possibilita aos desenvolvedores 161

10 acessar as funcionalidades do ORB utilizando a linguagem de programação escolhida para implementar os objetos (CORBA, 1998). Esse mapeamento cria uma definição abstrata adequada a cada linguagem de programação, isto é, cria uma estrutura que define como expressar os tipos de dados, as referências às constantes e objetos, as invocação de métodos (passagem de parâmetros, recebimento de resultados), os tratamentos de exceções e etc. da IDL na linguagem de programação utilizada para implementar o objeto. Este mapeamento é de responsabilidade do fornecedor do ORB (Mowbray e Ruh, 1997). A IDL CORBA possui declarações de tipo sintaticamente semelhantes a um subconjunto da linguagem C++. Ela não possui ponteiros, mas suporta tipos definidos e construídos pelo usuário. Possui exceções ( exception ) e o any pode representar qualquer tipo de dado válido para o IDL, por exemplo, inteiro, caracter, vetor, etc. A IDL CORBA possui uma descrição formal Backus-Naur Form (BNF) para várias linguagens de programação, tais como, Java, C, C++, Smalltalk, Cobol e Ada95. As interfaces para os serviços CORBA ( CORBAservices ) e facilidades CORBA ( CORBAfacilities ) são definidos em IDL (Nybroe e Bajers, 1998) (Mowbray e Ruh, 1997) (Otte et al, 1996) (Tallman e Bradford, 1998). 162

11 Definições IDL Mapeamento em C - Cabeçalho do cliente - Stub - Cabeçalho de implementação - Skeleton Compiladores IDL Mapeamento em C++ - Cabeçalho do cliente - Stub - Cabeçalho de implementação - Skeleton Mapeamento Smalltalk - Template de implementação Repositório de Interfaces Outros mapeamentos - Cobol - Ada83, Ada95 - Common Lisp - Outros Fig. 6.2 Mapeamento do IDL CORBA FONTE: Mowbray e Ruh (1997, p.73) No DCOM, qualquer linguagem de programação que possa criar estruturas de ponteiros e chamadas de funções implícitas ou explícitas, através desses ponteiros, pode ser utilizada para criar objetos COM e suas respectivas interfaces. Uma das maneiras de definir interfaces no DCOM é a utilização da ferramenta Microsoft Interface Definition Language (MIDL). O MIDL é uma extensão do DCE RPC IDL, que é baseado em C. Ela suporta todos os tipos de dados C, incluindo ponteiros e estruturas de dados baseados em ponteiros. O MIDL não define um conjunto comum de tipos de dados acessíveis a todas as linguagens de programação, isto é, nâo provê nenhuma 163

12 forma de mapeamento de linguagens de programação. Podem-se definir interfaces e tipos de dados em MIDL para C, C++ e Java, encontrando-se em desenvolvimento para Visual Basic e Ada (Grimes, 1997) (Tallman e Bradford, 1998) HERANÇA DE INTERFACE Em relação a objetos distribuídos se pode distinguir duas formas de herança, a saber: herança de implementação e herança de interface. Na herança de implementação, o objeto herda código de seu pai, isto é, quando um cliente de um objeto filho chama um dos métodos herdados por este objeto filho, o código realmente executado é o do objeto pai. Na herança de interface, o filho herda somente a definição dos métodos do pai, assim, quando o cliente de um objeto filho chama um destes métodos é o próprio filho que deve prover o código para lidar com a requisição do cliente. Herança de implementação é um mecanismo para reuso de código, enquanto a herança de interface é um mecanismo para reuso de especificação (é a definição dos métodos que o objeto suporta). A herança de interface permite definir uma nova interface herdada de uma já existente, garantindo, assim, que um objeto que suporta a nova interface possa ser tratado como um objeto que suporta a interface anterior (pai). Objetos COM suportam somente herança simples de interface. Não suportam herança de implementação mas, através de mecanismos de contenção e agregação, descritos no Capítulo 4, é possível obter o reuso de código. CORBA permite herança múltipla de interface. No CORBA um objeto possui somente uma interface, mas pode suportar múltiplas interfaces através do mecanismo de herança de interface. 164

13 A Figura 6.3 mostra a herança de interface utilizada pelo CORBA e DCOM. A B C IU IU D A A IU IU IU E F B C D E F Herança de Interface CORBA Herança de Interface DCOM Fig. 6.3 Herança de interface CORBA e DCOM FONTE: CORBA (1998, p.16.27) REPOSITÓRIO DE INTERFACES Tanto o CORBA com o DCOM suportam invocação de métodos de objetos de forma estática e dinâmica. Invocação estática é aquela que, para atender uma requisição, apresenta as definições exatas em tempo de compilação. Quando isso não acontece, deve haver uma maneira que permita descobrir, em tempo de execução, as definições necessárias para atender a requisição, e a este processo dá-se o nome de invocação dinâmica. Para atender a invocação dinâmica, CORBA define um repositório de interfaces ( Interface Repository ) que armazena definições de tipos de dados, informações de interface definidas em IDL, incluindo stubs, skeletons, rotinas para browse de interfaces e informações para depuração. A implementação fica a cargo do fornecedor do produto que implementa o ORB. 165

14 Os programas utilizam o repositório de interfaces, através da invocação dinâmica de interface ( Dynamic Invocation Interface DII), para procurar as interfaces que não foram encontradas em tempo de compilação (Chung et al, 1998) (Mowbray e Ruh, 1997) (Tallman e Bradford, 1998). No DCOM a invocação dinâmica torna-se disponível através da utilização da interface IDispatch e seus respectivos métodos Invoke, GetIDsOfNames, GetTypeInfo e GetTypeInfoCount já descritos anteriormente. Um objeto cujos métodos são dinamicamente invocados deve possuir entre suas interfaces a interface IDispatch. Esta interface consulta a biblioteca Type Library que descreve o objeto e provê dinamicamente suas interfaces e respectivos métodos. Esta biblioteca é acessada através da interface ITypeLib e as definições dos dados nela contidas sâo obtidas pela interface ITypeInfo (Grimes, 1997). Como os clientes não possuem instruções de compilação para invocar métodos de interfaces desconhecidas eles devem recorrer ao uso de interfaces de invocação dinâmica quando necessitarem invocar objetos cujas interfaces devam ser descobertas em tempo de execução. Depuradores ( debbugers ) são exemplos de aplicações que necessitam de invocação dinâmica, pois podem ser invocados, para depurar novos programas, por alguma operação descoberta em tempo de execução. No CORBA, usa-se o DII e no DCOM a interface IDispatch, que são maneiras diferentes de implementar a mesma funcionalidade CICLO DE VIDA DO OBJETO No DCOM, um cliente cria um objeto utilizando-se das funções da biblioteca COM. Além de outros parâmetros, especifica o identificador da classe (CLSID) do objeto que ele quer utilizar. Com isto o cliente obtém seu primeiro ponteiro 166

15 de interface para o novo objeto, como parte do processo de criação, e dele obterá qualquer outro ponteiro de que necessite, bastando perguntar, diretamente, ao objeto através do método QueryInterface da interface IUnknown. Quando o cliente terminar de fazer uso do ponteiro de interface obtido, ele passará esta informação ao objeto, através o método Release da interface IUnknown. Quando o cliente liberar todos os ponteiros de todas as interfaces do objeto, o objeto usualmente se destruirá (Chappell, 1997) (Chung et al, 1998) (Frankel e Guttman, 1998). Se for necessária a criação de vários objetos da mesma classe, o cliente poderá adquirir o ponteiro para a class factory da classe que possui esta função. A class factory, além de prover uma ligação entre o cliente e o objeto, permite que a aplicação do cliente mantenha o objeto na memória, mesmo não existindo contador de referência para qualquer interface do objeto. Sem esta facilidade, o objeto seria destruído assim que o contador de referência fosse zerado. Esta facilidade possibilita ao cliente decidir, por exemplo, manter o objeto na memória, uma vez que esteja motivado por razões de desempenho (Grimes, 1997). No CORBA, um objeto é criado tipicamente por um chamado ao ORB, utilizando para este fim o serviço de ciclo de vida. Este chamado gera uma referência de objeto única (um identificador de objeto) para o objeto recémcriado, sendo utilizada para rastrear o objeto durante todo o seu ciclo de vida. Essa referência de objeto é utilizada pelo serviço de nomeação para localizar o objeto, pelo serviço de persistência para armazenar o estado do objeto e é ela que permite ao cliente invocar seus métodos. A forma de implementação da referência de objeto não é definida pelo CORBA (Orfali et al, 1996). Quando um cliente invoca um método de um objeto ativo, isto é, de um objeto que possui seu dado e o código na memória, o ORB passa a ele a requisição recebida do cliente. Se o objeto alvo não estiver ativo, o ORB carrega os dados 167

16 e o código do objeto na memória e entrega a ele a requisição do cliente. Clientes não precisam informar ao objeto quando eles terminam de usá-lo e não é definido pelo padrão CORBA quando um objeto pára de executar. Produtos diferentes apresentam várias maneiras de tratar a destruição do objeto. No CORBA, diferentemente do DCOM, fazer com que um objeto deixe de ser ativo não é a mesma coisa que destruí-lo. CORBA requer que o cliente, explicitamente, diga ao ORB que um objeto deve ser destruído e, até que isto seja feito, o ORB é capaz de iniciar e parar o objeto quando necessário para atender uma requisição do cliente (Chappell, 1997) (Chung et al, 1998) (Frankel e Guttman, 1998). A Figura 6.4 mostra o ciclo de vida de um objeto CORBA. Objeto executando Objeto criado 3 Objeto destruído Objeto ativo Objeto desativado Fig. 6.4 Ciclo de vida de um objeto CORBA FONTE: Otte et al (1996, p.9-3) DCOM não tem o conceito de referência de objeto, mas através do mecanismo de persistência de nomeação ( moniker ) provê uma referência única aos métodos e dados de uma instância particular do objeto. Monikers encapsulam esquemas de implementação específicos baseados em nomes que passam a possuir a localização do objeto. 168

17 6.1.8 PROTOCOLO Tanto o CORBA como o DCOM provêem um protocolo para suportar a execução do cliente e objeto servidor em diferentes máquinas. CORBA não especifica um protocolo de comunicação interno entre o cliente e um objeto servidor executando num ORB, isto fica determinado pelo fornecedor. Entretanto, é especificado o protocolo General Inter-ORB Protocol (GIOP) de maneira a garantir a interoperabilidade entre diferentes implementações de ORBs. Quando a troca de mensagens é via conecções TCP/IP, utiliza-se o protocolo Internet Inter-ORB Protocol (IIOP). O IIOP especifica um novo padrão para formatação de mensagens conhecido como Common Data Representation (CDR). A principal vantagem deste protocolo é o baixo custo de tempo de execução obtido pelas seguintes características (Watson et al, 1998): ordenamento variável de bytes: não há necessidade de fazer troca de bytes quando o marshaling for em máquinas de mesmo endianess. Marshaling é o processo de empacotar, num formato padrão para transmissão, tanto os parâmetros de chamada de um método (no espaço de endereçamento do cliente) como o retorno do valor da execução deste método (obtido no espaço de endereçamento do objeto). tipos de primitivas alinhadas: permite tratamento eficiente de dados através do alinhamento de dados na memória. No CORBA, existe, também, o protocolo DCE Common InterORB (DCE- CIOP) que utiliza o formato de comunicação definido pelo DCE-RPC, com uma diferença, ao invés de representar os dados como, no DCE-RPC, utilizando o Network Data Representation (NDR) ele substitui esta representação pelo 169

18 Common Data Representation (CDR). O NDR oferece mais funcionalidades em relação ao CDR, mas carece de características relacionadas à minimização de custo de tempo de execução (Nybroe e Bajers, 1998). DCOM tem seu protocolo baseado nas especificações OSF DCE RPC (DCE, 1998) com poucas modificações. O protocolo DCOM estendeu o NDR definindo um novo tipo primitivo de dado que pode ser marshaled. Este tipo é a referência de interface para o objeto descrito como OBJREF que relaciona, de forma única, o objeto à sua interface (Brown e Kindel, 1998). Foi necessária esta extensão porque o RPC é apropriado para aplicações nas quais o cliente faz uma requisição e espera pela resposta antes de continuar seu processamento, assim, não é indicado para aplicações envolvendo objetos distribuídos ou programação orientada a objeto (Vondrak, 1998). DCOM incluiu também, nas suas especificações, um protocolo chamado de pinging que permite a execução de um garbage collect de objetos remotos. Pinging é o mecanismo pelo qual um processo envia um pequeno pacote de dados ( ping ) para outro processo indicando que ele está vivo e o processo receptor responde ao ping mostrando que ele também está vivo ( pong ). O ping é continuamente repetido num intervalo de tempo pré-determinado. A perda de um número pré-determinado de pings indica que o cliente terminou de forma anormal e o ponteiro para interface que o contém deve ser liberado (Grimes,1997). Apesar do ping enviar um pequeno pacote de dados, ele pode ser desligado para reduzir o tráfego na rede (Chung et al, 1998) ERROS E EXCEÇÕES CORBA garante que uma invocação feita por um cliente receba sempre um retorno indicando sucesso ou uma exceção. Isto simplifica, significamente, as complexidades da computação distribuída, pois pode reduzir a quantidade de código no lado cliente. Exceções representam também uma parte importante 170

19 das especificações de uma interface. Exceções definem os valores passados pela interface no caso de acontecer um erro. Os valores de exceções são declarados similarmente a tipos de estruturas na IDL. CORBA especifica uma extensa lista de exceções que se mapeiam naturalmente tanto em linguagens de programação que possuem tratamento de exceção nativo, como C++ e Java, como nas que não o possuem. Existem dois tipos de exceção: as definidas pelo padrão CORBA, estabelecidas no ORB ou na implementação do objeto, e as definidas pelo usuário estabelecidas na implementação do objeto (Chung et al, 1998) (Mowbray e Ruh, 1997) (Otte et al,1996). Para tratamento de exceções o DCOM estabelece padrões para valores de status e erros baseados no sistema de códigos de erros do Win32. Ele possui um tratamento padrão de erros através do retorno de um valor de 32 bits chamado HRESULT. O código de status possui 32 bits dos quais 16 bits são de status, 15 bits de facilidade ( facility ) e 1 bit indicador de sucesso. O bit mais significativo é o indicador de sucesso, ele determina se o código de status representa sucesso ou falha. Esse é o bit utilizado para teste pelas macros SUCCEED( ) e FAILED( ). Os 15 bits de facilidade descrevem onde o erro foi gerado; a combinação destes bits produzem um código de facilidade que pode ser definido pelo usuário ou provido pelo DCOM. Os 16 bits menos significativos são indicativos de status e especificam o erro ocorrido (Chung et al, 1998) (Grimes, 1997) (Mowbray e Ruh, 1997) PERSISTÊNCIA Ambos, DCOM e CORBA, utilizam-se de um armazenamento persistente para salvar o estado de um objeto que poderá vir a ser utilizado numa reativação futura. 171

20 No CORBA, o mecanismo de persistência é completamente transparente ao cliente que não possui meios de determinar onde e como o objeto foi armazenado. O cliente só obtém essa informação, caso exista um outro objeto responsável por conhecer os detalhes de armazenamento do objeto utilizado por ele. A implementação do mecanismo de persistência é de responsabilidade exclusiva do serviço de gerenciamento de persistência do ORB, tornando a ligação com o cliente restrita ao que foi definido nas interfaces do objeto (Otte et al, 1996) (Mowbray e Ruh, 1997) (Tallman e Bradford, 1998). No DCOM, o modelo de persistência requer que os objetos implementem uma interface que suporte persistência. Para essa finalidade, utiliza-se um ou vários meios de armazenamento como arquivos, streams, etc. Para reativar um objeto, o cliente indica, explicitamente, onde o estado do objeto está armazenado (tipicamente um arquivo) e requisita sua ativação. Isto é usualmente feito através de um file moniker. Todos os monikers são gerenciados pelo cliente SERVIÇOS Serviços permitem a interação, através da rede, de múltiplos processos executando em uma ou mais máquinas. DCOM e CORBA utilizam diferentes esquemas de serviços, dificultando, desta forma, algum tipo de comparação. A abordagem da Microsoft para desenvolver aplicativos distribuídos é chamada de Windows Distributed internet Applications (DNA). O Windows DNA não é um produto mas uma estratégia para escrever aplicativos utilizando as tecnologias e os produtos da Microsoft. O objetivo é fornecer, à plataforma (Windows), a tecnologia de componentes (COM/DCOM), a infraestrutura, os serviços de interoperabilidade e as ferramentas que os desenvolvedores necessitam para escrever aplicativos cliente/servidor de três camadas (Kirtland, 1999). 172

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

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

Cliente/Servidor. Objetos Distribuídos. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Objetos Distribuídos. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Objetos Distribuídos Graça Bressan Graça Bressan/LARC 2000 1 Objetos São entidades de software que encapsulam dados, ou atributos, e código e que são acessados através de funções ou métodos.

Leia mais

CAPÍTULO 3 MIDDLEWARE. Para entender-se o aparecimento da tecnologia middleware é descrita a seguir, e, brevemente, a sua evolução.

CAPÍTULO 3 MIDDLEWARE. Para entender-se o aparecimento da tecnologia middleware é descrita a seguir, e, brevemente, a sua evolução. CAPÍTULO 3 MIDDLEWARE Para entender-se o aparecimento da tecnologia middleware é descrita a seguir, e, brevemente, a sua evolução. 3.1 ARQUITETURA CLIENTE/SERVIDOR Primeiramente, surgiu a arquitetura centralizada

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

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

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

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Conceitos Gerais Graça Bressan Graça Bressan/LARC 2000 1 Forças de marketing que conduzem à arquitetura cliente/servidor "Cliente/Servidor é um movimento irresistível que está reformulando

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

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

Componentes para Computação Distribuída

Componentes para Computação Distribuída Componentes para Computação Distribuída Conceitos Foi a partir do fenômeno da Internet (WWW), no início dos anos noventa, que a computação distribuída passou a ter relevância definitiva, a ponto de a Internet

Leia mais

OBJETOS DISTRIBUÍDOS: CONCEITOS E PADRÕES

OBJETOS DISTRIBUÍDOS: CONCEITOS E PADRÕES MINISTÉRIO DA CIÊNCIA E TECNOLOGIA INSTITUTO NACIONAL DE PESQUISAS ESPACIAIS INPE-7939-TDI/744 OBJETOS DISTRIBUÍDOS: CONCEITOS E PADRÕES Samira Rachid da Costa Dissertação de Mestrado em Computação Aplicada,

Leia mais

CAPÍTULO 5 CORBA 5.1 MODELO DE OBJETO

CAPÍTULO 5 CORBA 5.1 MODELO DE OBJETO CAPÍTULO 5 CORBA Um dos grandes problemas das empresas é, utilizando seus recursos de hardware e o software, integrar vários elementos de trabalho diferentes de maneira a resolver problemas de negócios

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

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

CAPÍTULO 7 JAVA 7.1 CARACTERÍSTICAS DA LINGUAGEM

CAPÍTULO 7 JAVA 7.1 CARACTERÍSTICAS DA LINGUAGEM CAPÍTULO 7 JAVA Java é uma linguagem orientada a objeto cujo projeto foi desenvolvido pela Sun Microsystems no início de 1991. Ela foi originalmente concebida para ser utilizada na programação de dispositivos

Leia mais

O modelo de arquitetura CORBA e suas aplicações

O modelo de arquitetura CORBA e suas aplicações ABR. MAI. JUN. 2004 ANO X, N º 37 157-163 INTEGRAÇÃO 157 O modelo de arquitetura CORBA e suas aplicações ANA PAULA GONÇALVES SERRA* Resumo Nos últimos anos, os sistemas de informação nas empresas têm evoluído

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos 11 Objetivos Este capítulo apresenta uma introdução aos sistemas distribuídos em geral Arquiteturas de cliente servidor Características das arquiteturas de 2 e 3 camadas Ambiente

Leia mais

Desenvolvimento em CORBA. Novos Desenvolvimentos em CORBA

Desenvolvimento em CORBA. Novos Desenvolvimentos em CORBA Desenvolvimento em CORBA Onde utilizar CORBA? CORBA é uma arquitetura para sistemas distribuídos, tipicamente utilizada em: novos desenvolvimentos; integração de produtos e sistemas legados ; hooks e gateways

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

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

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

Protocolos de gerenciamento

Protocolos de gerenciamento Protocolos de gerenciamento Os protocolos de gerenciamento têm a função de garantir a comunicação entre os recursos de redes homogêneas ou não. Com esse requisito satisfeito, operações de gerenciamento

Leia mais

1.264 Lição 16. Legado Middleware

1.264 Lição 16. Legado Middleware 1.264 Lição 16 Legado Middleware O que é o legado middleware? Cliente (interface do usuário, aplicativo local). Cliente (interface do usuário, aplicativo local). Como conectamos clientes e servidores?

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

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

3 Propostas de Travessias de Firewalls/NAT

3 Propostas de Travessias de Firewalls/NAT 3 Propostas de Travessias de Firewalls/NAT Este capítulo irá apresentar as propostas deste trabalho para que aplicações que utilizem CORBA como plataforma de comunicação possam atravessar firewalls/nat.

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Arquitetura de um sistema é a especificação de sua estrutura e de seus componentes

Arquitetura de um sistema é a especificação de sua estrutura e de seus componentes Arquiteturas e Modelos de sistemas Arquitetura Arquitetura de um sistema é a especificação de sua estrutura e de seus componentes Localização dos componentes e relação entre eles Objetivo: garantir que

Leia mais

Sistemas Distribuídos Arquiteturas Middlewares

Sistemas Distribuídos Arquiteturas Middlewares Sistemas Distribuídos Arquiteturas s Arquitetura Arquitetura de um sistema é sua estrutura em termos dos componentes e seus relacionamentos Objetivo: garantir que a estrutura satisfará as demandas presentes

Leia mais

Padrões Arquiteturais. Sistemas Distribuídos: Broker

Padrões Arquiteturais. Sistemas Distribuídos: Broker Padrões Arquiteturais Sistemas Distribuídos: Broker Sistemas Distribuídos Tendências: Sistemas Comp. com múltiplas CPUs Redes locais com centenas de hospedeiros Benefícios Economia Desempenho e escalabilidade

Leia mais

Computational viewpoint. Engineering Viewpoint

Computational viewpoint. Engineering Viewpoint Processamento Paralelo RM-ODP Prof. João Paulo A. Almeida (jpalmeida@inf.ufes.br) 2007/0 - INF02799 RM-ODP Reference Model for Open Distributed Processing Contém conceitos para a especificação de sistemas

Leia mais

World Wide Web e Aplicações

World Wide Web e Aplicações World Wide Web e Aplicações Módulo H O que é a WWW Permite a criação, manipulação e recuperação de informações Padrão de fato para navegação, publicação de informações e execução de transações na Internet

Leia mais

A utilização do JSWDP para construção de Web Services

A utilização do JSWDP para construção de Web Services A utilização do JSWDP para construção de Web Services Fabiana Ferreira Cardoso 1, Francisco A. S. Júnior 1, Madianita Bogo 1 1 Centro de Tecnologia da Informação Centro Universitário Luterano de Palmas

Leia mais

Sistemas Distribuídos. Introdução. Edeyson Andrade Gomes. www.edeyson.com.br

Sistemas Distribuídos. Introdução. Edeyson Andrade Gomes. www.edeyson.com.br Sistemas Distribuídos Introdução Edeyson Andrade Gomes www.edeyson.com.br SUMÁRIO Definições Características Desafios Vantagens Desvantagens 2 Definições DEFINIÇÕES Um sistema distribuído é uma coleção

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

Sumário. Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Paradigmas. Objetos Distribuídos. Tecnologias e Motivações

Sumário. Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Paradigmas. Objetos Distribuídos. Tecnologias e Motivações Sumário Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Tecnologias e Motivações Paradigmas e Tecnologias para Desenvolvimento de SDs Sistemas Distribuídos x Tecnologia da Informação

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

Paradigma Cliente/Servidor

Paradigma Cliente/Servidor Paradigma Cliente/Servidor Mário Meireles Teixeira UFMA Departamento de Informática Dezembro, 2012 Comunicação em Sistemas Distribuídos! Os processos em um SD estão lógica e fisicamente separados. Precisam

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO... 27 CAPÍTULO 2 - SISTEMAS DISTRIBUÍDOS BASEADOS EM OBJETOS... 33

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO... 27 CAPÍTULO 2 - SISTEMAS DISTRIBUÍDOS BASEADOS EM OBJETOS... 33 SUMÁRIO Pág. LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SÍMBOLOS CAPÍTULO 1 - INTRODUÇÃO... 27 CAPÍTULO 2 - SISTEMAS DISTRIBUÍDOS BASEADOS EM OBJETOS... 33 CAPÍTULO 3 - SUPORTE PARA A IMPLEMENTAÇÃO DE

Leia mais

Padrões de Projeto Implementados em Infraestrturas de Componentes

Padrões de Projeto Implementados em Infraestrturas de Componentes Padrões de Projeto Implementados em Infraestrturas de Componentes Paulo Pires paulopires@nce.ufrj.br http//genesis.nce.ufrj.br/dataware/hp/pires 1 distribuídas baseadas em componentes Comunicação transparente,

Leia mais

Arquiteturas de Aplicações Distribuídas

Arquiteturas de Aplicações Distribuídas Arquiteturas de Aplicações Distribuídas Fernando Albuquerque 061-2733589 fernando@cic.unb.br www.cic.unb.br/docentes/fernando Tópicos Introdução. HTTP / CGI. API sockets. JDBC. Remote Method Invocation.

Leia mais

Aula 2. Objetivo: Saber qual a funcionalidade de um sistema operacional de rede.

Aula 2. Objetivo: Saber qual a funcionalidade de um sistema operacional de rede. Aula 2 Objetivo: Saber qual a funcionalidade de um sistema operacional de rede. Sistema Operacional de Rede Definição: Conjunto de módulos que ampliam as tarefas dos sistemas operacionais locais, complementando-os

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

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2)

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2) Definição de um Sistema Distribuído (1) Introdução Um sistema distribuído é: Uma coleção de computadores independentes que aparecem para o usuário como um único sistema coerente. Definição de um Sistema

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

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos:

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos: Estruturas de Sistemas Operacionais Podemos analisar um sistema operacional sob diversos aspectos: Os serviços que o sistema operacional oferece. A interface que o sistema operacional torna disponível

Leia mais

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

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

Leia mais

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

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

COMPUTAÇÃO DE OBJETOS DISTRIBUÍDOS NA ERA DA INTERNET

COMPUTAÇÃO DE OBJETOS DISTRIBUÍDOS NA ERA DA INTERNET COMPUTAÇÃO DE OBJETOS DISTRIBUÍDOS NA ERA DA INTERNET DÉSIRÉ NGUESSAN Mestre em Ciências da Computação Universidade Federal de Santa Catarina e Professor do Curso de Ciências da Computação na UNINOVE CARLOS

Leia mais

Desenvolvimento Cliente-Servidor 1

Desenvolvimento Cliente-Servidor 1 Desenvolvimento Cliente- 1 Ambiienttes de Desenvollviimentto Avançados Engenharia Informática Instituto Superior de Engenharia do Porto Alexandre Bragança 1998/99 Ambientes de Desenvolvimento Avançados

Leia mais

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

Prof. Luiz Fernando Bittencourt MC714. Sistemas Distribuídos 2 semestre, 2013 MC714 Sistemas Distribuídos 2 semestre, 2013 Tipos de comunicação Middleware: serviço intermediário na comunicação de nível de aplicação. Fig. 67 Ex.: correio eletrônico Comunicação é persistente. Middleware

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

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

Sistema centralizado O Paradigma Cliente/Servidor

Sistema centralizado O Paradigma Cliente/Servidor centralizado O Paradigma Cliente/Servidor Computador central (mainframe) + conjunto de terminais + recursos centralizados recursos mainframe terminais 2 distribuído Relações entre entidades Grupo de computadores

Leia mais

UFG - Instituto de Informática

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

Leia mais

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

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

Leia mais

CORBA Integração com a Web

CORBA Integração com a Web CORBA Integração com a Web Mário Meireles Teixeira mario@deinf.ufma.br Tópicos Abordados Evolução das aplicações na Web A Object Web Principais Empresas CORBA e XML Estudo de Caso Um Sistema de Informações

Leia mais

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com Projeto de Sistemas Distribuídos Prof. Andrêza Leite andreza.lba@gmail.com Exemplos de SD Quais podem ser? Ex. de SD: Internet Internet é um conjunto de redes de computadores, de muitos tipos diferentes,

Leia mais

INTEROPERABILIDADE EM SISTEMAS UTILIZANDO WEB SERVICES COMO MIDDLEWARES

INTEROPERABILIDADE EM SISTEMAS UTILIZANDO WEB SERVICES COMO MIDDLEWARES INTEROPERABILIDADE EM SISTEMAS UTILIZANDO WEB SERVICES COMO MIDDLEWARES Bruno B. Boniati 1, Agner Q. Olson 1, Ms. Edson Luiz Padoin 2 2 Departamento de Tecnologia - 1 Curso de Informática: Sistemas de

Leia mais

Web Services. Integração de aplicações na Web. Sistemas Distribuídos

Web Services. Integração de aplicações na Web. Sistemas Distribuídos Web Services Integração de aplicações na Web Integração de Aplicações na Web Interoperação entre ambientes heterogêneos desafios diversidade de componentes: EJB, CORBA, DCOM... diversidade de linguagens:

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

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware.

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware. Camadas de Software - o Middleware Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas Modelos de Arquitecturas para sistemas distribuidos Interfaces e Objectos Requerimentos para Arquitecturas Distribuídas

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Computação Aula 01-02: Introdução 2o. Semestre / 2014 Prof. Jesus Agenda da Apresentação Definição e surgimento de Sistemas Distribuídos Principais aspectos de Sistemas Distribuídos

Leia mais

GLOSSÁRIO. ActiveX Controls. É essencialmente uma interface usada para entrada e saída de dados para uma aplicação.

GLOSSÁRIO. ActiveX Controls. É essencialmente uma interface usada para entrada e saída de dados para uma aplicação. GLOSSÁRIO Este glossário contém termos e siglas utilizados para Internet. Este material foi compilado de trabalhos publicados por Plewe (1998), Enzer (2000) e outros manuais e referências localizadas na

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

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

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

CORBA (Common Object Request Broker Architecture)

CORBA (Common Object Request Broker Architecture) CORBA (Common Object Request Broker Architecture) Sistemas Distribuídos Desafios para a realização de sistemas Distribuídos Exemplos de Sistemas Distribuídos CORBA Evolução Histórica OMA (Object Management

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

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

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

Leia mais

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

OMA (Object Management Arquitecture): Application Interfaces. Domain Interfaces. Domain. Interfaces. Object Request Broker (ORB) Object Services

OMA (Object Management Arquitecture): Application Interfaces. Domain Interfaces. Domain. Interfaces. Object Request Broker (ORB) Object Services 1 Copyright 1998, 1999 Francisco Reverbel OMA (Object Management Arquitecture): Application Interfaces Domain Domain Interfaces Interfaces Object Request Broker (ORB) Object Services 2 Copyright 1998,

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

Programação Orientada a Objetos

Programação Orientada a Objetos Programação Orientada a Objetos Universidade Católica de Pernambuco Ciência da Computação Prof. Márcio Bueno poonoite@marciobueno.com Fonte: Material da Profª Karina Oliveira Introdução ao Paradigma OO

Leia mais

SISTEMA DISTRIBUÍDO COM O PADRÃO DE ARQUITETURA CORBA

SISTEMA DISTRIBUÍDO COM O PADRÃO DE ARQUITETURA CORBA LEONARDO LINCOLN BIANCHETTI SISTEMA DISTRIBUÍDO COM O PADRÃO DE ARQUITETURA CORBA Trabalho de conclusão de curso apresentado ao Curso de Ciência da Computação. UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS Orientador:

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

Programação para a Internet. Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala

Programação para a Internet. Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala Programação para a Internet Prof. M.Sc. Sílvio Bacalá Jr sbacala@gmail.com www.facom.ufu.br/~bacala A plataforma WEB Baseada em HTTP (RFC 2068) Protocolo simples de transferência de arquivos Sem estado

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

Computação Distribuída, Web Service - um estudo de caso

Computação Distribuída, Web Service - um estudo de caso CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE CIÊNCIA DA COMPUTAÇÃO Diogo Francisco Sales da Silva Flávio Rodrigo Lovatti Computação Distribuída, Web Service - um estudo de caso VILA VELHA 2009 Diogo Francisco

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS Pág. CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 2.1 A tecnologia de orientação a objetos 25 2.1.1 Projeto de software

Leia mais

Object Brokers. Tecnologias de Middleware 2004/2005 André Santos

Object Brokers. Tecnologias de Middleware 2004/2005 André Santos Object Brokers Tecnologias de Middleware 2004/2005 André Santos Resumo O que são Object Brokers? Como surgiu o conceito? CORBA Exemplos de utilização Comparação com Java RMI Actualidade (J2EE,.NET) O que

Leia mais

UTFPR - Sistemas Distribuídos Prof. Cesar Augusto Tacla. Anotações. Copyright Cesar Augusto Tacla 2008 - 1 -

UTFPR - Sistemas Distribuídos Prof. Cesar Augusto Tacla. Anotações. Copyright Cesar Augusto Tacla 2008 - 1 - - 1 - - 2 - - 3 - Segundo (Garg, 2004), são sistemas compostos por múltiplos processadores conectados por uma rede de comunicação, sendo a rede de comunicação uma LAN (Ethernet) ou WAN (Internet). - 4

Leia mais

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

Distributed Systems Concepts and Design

Distributed Systems Concepts and Design Distributed Systems, Cap 2, Coulouris Pag. 1 de 1 Distributed Systems Concepts and Design 2 Modelos de Sistemas Modelos de arquitetura de sistemas distribuídos, estão relacionado com o local onde estão

Leia mais

IBM Tivoli Directory Server Versão 5.2 Leia-me do Cliente

IBM Tivoli Directory Server Versão 5.2 Leia-me do Cliente IBM Tivoli Directory Server Versão 5.2 Leia-me do Cliente Nota Antes de utilizar estas informações e o produto suportado por elas, leia as informações gerais em Avisos, na página 7. Prefácio Este Leia-me

Leia mais

Rede de Computadores II

Rede de Computadores II Rede de Computadores II Slide 1 SNMPv1 Limitações do SNMPv1 Aspectos que envolvem segurança Ineficiência na recuperação de tabelas Restrito as redes IP Problemas com SMI (Structure Management Information)

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

Arquitetura de Software e Atributos de Qualidade

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

Leia mais

Comunicação em Sistemas Distribuídos

Comunicação em Sistemas Distribuídos Comunicação em Sistemas Distribuídos Sockets Aplicações Protocolo de Aplicação FTP, SMTP, HTTP, Telnet, SNMP, etc. sockets TCP, UDP IP Data Link Ethernet, Token Ring, FDDI, etc Física Conjunto de APIs

Leia mais

Introdução ao Modelos de Duas Camadas Cliente Servidor

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

Leia mais

Metas de um Sistema Distribuído

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

Leia mais

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

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

Figura 01 Kernel de um Sistema Operacional

Figura 01 Kernel de um Sistema Operacional 01 INTRODUÇÃO 1.5 ESTRUTURA DOS SISTEMAS OPERACIONAIS O Sistema Operacional é formado por um Conjunto de rotinas (denominado de núcleo do sistema ou kernel) que oferece serviços aos usuários e suas aplicações

Leia mais

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

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

Leia mais

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

SOA: Service-oriented architecture

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

Leia mais

Sistemas Operacionais Aula 06: Threads. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com

Sistemas Operacionais Aula 06: Threads. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com Sistemas Operacionais Aula 06: Threads Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com Objetivos Introduzir o conceito de thread Discutir as APIs das bibliotecas de threads Pthreads, Win32

Leia mais