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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB

Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB Alt-N Technologies, Ltd 1179 Corporate Drive West, #103 Arlington, TX 76006 Tel: (817) 652-0204 2002 Alt-N

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

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

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

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

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

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

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

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

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

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

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

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

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

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 Virtualização - motivação Consolidação de servidores. Consolidação de aplicações. Sandboxing. Múltiplos ambientes de execução. Hardware virtual. Executar múltiplos

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

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

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

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

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

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

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

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

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

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

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 5 Servidores de Aplicação

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

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

Modelos de Arquiteturas. Prof. Andrêza Leite andreza.lba@gmail.com

Modelos de Arquiteturas. Prof. Andrêza Leite andreza.lba@gmail.com Modelos de Arquiteturas Prof. Andrêza Leite andreza.lba@gmail.com Agenda Introdução Arquitetura de Sistemas Distribuídos Clientes e Servidores Peer-to-Peer Variações Vários Servidores Proxy Código Móvel

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

APOSTILA DE REDES DE COMPUTADORES PARTE - III

APOSTILA DE REDES DE COMPUTADORES PARTE - III APOSTILA DE REDES DE COMPUTADORES PARTE - III 1 REDE DE COMPUTADORES III 1. Introdução MODELO OSI ISO (International Organization for Standardization) foi uma das primeiras organizações a definir formalmente

Leia mais

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com Sistemas Operacionais Aula 03: Estruturas dos SOs Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com OBJETIVOS Descrever os serviços que um sistema operacional oferece aos usuários e outros sistemas

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

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

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

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

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

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

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

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

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

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

ESTUDO DE CASO WINDOWS VISTA

ESTUDO DE CASO WINDOWS VISTA ESTUDO DE CASO WINDOWS VISTA História Os sistemas operacionais da Microsoft para PCs desktop e portáteis e para servidores podem ser divididos em 3 famílias: MS-DOS Windows baseado em MS-DOS Windows baseado

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

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

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

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

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

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

LEIA ISTO PRIMEIRO. IBM Tivoli Configuration Manager, Versão 4.2.1

LEIA ISTO PRIMEIRO. IBM Tivoli Configuration Manager, Versão 4.2.1 LEIA ISTO PRIMEIRO IBM Tivoli, Versão 4.2.1 O IBM Tivoli, Versão 4.2.1, é uma solução para controlar a distribuição de software e o inventário de gerenciamento de recursos em um ambiente multiplataformas.

Leia mais

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação

FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação FACULDADE DE ADMINISTRAÇÃO E NEGÓCIOS DE SERGIPE - FANESE CURSO SUPERIOR DE TECNOLOGIA em Gestão da Tecnologia da Informação 1 Ruironaldi dos Santos Cruz ARTIGO ARQUITETURA ORIENTADA A SERVIÇO SOA SERVICE

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

4 Estrutura do Sistema Operacional. 4.1 - Kernel

4 Estrutura do Sistema Operacional. 4.1 - Kernel 1 4 Estrutura do Sistema Operacional 4.1 - Kernel O kernel é o núcleo do sistema operacional, sendo responsável direto por controlar tudo ao seu redor. Desde os dispositivos usuais, como unidades de disco,

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

Distributed Systems Principles and Paradigms

Distributed Systems Principles and Paradigms Distributed Systems Principles and Paradigms Maarten van Steen VU Amsterdam, Dept. Computer Science (Tradução e Adaptação Ricardo Anido - IC/Unicamp) Capítulo 04: Comunicação Versão: 20 de março de 2014

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 Processos- Clientes, Servidores, Migração Capítulo 3 Agenda Clientes Interfaces de usuário em rede Sistema X Window Software do lado cliente para

Leia mais

JXTA. Alessandro Vasconcelos Ferreira de Lima. avfl@cin.ufpe.br

JXTA. Alessandro Vasconcelos Ferreira de Lima. avfl@cin.ufpe.br JXTA Alessandro Vasconcelos Ferreira de Lima Roteiro Motivação Introdução Arquitetura de JXTA Elementos de JXTA Os Protocolos Comparações e Desvantagens Conclusão Motivação Limitações do Modelo Cliente

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

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

Comunicando através da rede

Comunicando através da rede Comunicando através da rede Fundamentos de Rede Capítulo 2 1 Estrutura de Rede Elementos de comunicação Três elementos comuns de comunicação origem da mensagem o canal destino da mensagem Podemos definir

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

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

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Sobre entidades externas ao sistema Quais sistemas externos devem ser acessados? Como serão acessados? Há integração com o legado a ser feita?

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

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Este capítulo apresenta trabalhos relacionados ao problema da travessia de firewalls/nat por aplicações CORBA, alguns dos quais tiveram grande influência no desenvolvimento desta

Leia mais