PLATAFORMAS DISTRIBUÍDAS Eleri Cardozo FEEC/UNICAMP http://www.fee.unicamp.br/~eleri Julho de 2002 (c) FEEC/UNICAMP

Sistemas Distribuídos Introdução aos Sistemas Distribuídos (c) FEEC/UNICAMP

Sistemas Distribuídos: Definição Um sistema distribuído é um sistema computacional com as seguintes propriedades: 1. distribuição: um subconjunto de seus componentes encontram-se geograficamente dispersos; 2. concorrência: um subconjunto de seus componentes executam concorrentemente (em paralelo); 3. ausência de estado global: é impossível determinar-se precisamente o estado global do sistema; 4. falhas parciais: qualquer componente do sistema pode falhar independente dos demais; 5. assincronismo: as atividades do sistema não são regidas por um relógio global. (c) FEEC/UNICAMP

Sistemas Distribuídos: Motivação Evolução em microprocessadores: constante incremento da capacidade de processamento com decréscimo de custo. Evolução em redes de comunicação: velocidades de Gigabits/s já disponíveis a custo atrativo. Portanto, a utilização de uma rede rápida de processadores poderosos é atrativa para abrigar sistemas complexos de software. (c) FEEC/UNICAMP

Evolução em Microprocessadores MIPS 1987 1992 1997 2002 1982 2007 1 10 1000 100 10000 100000 20 BIPS Pentium 486 Mips 286 DEC Alpha HP PA 386 (c) FEEC/UNICAMP

Evolução em Redes Mbits/s 10000 10 Gbits/s 1000 100 10 1 1982 1987 1992 1997 2002 1982 2007 1 10 1000 100 10000 10 Gbits/s Fast Ethernet ISDN Ethernet FDDI T. Ring X.25 Frame Relay ATM Gigabit Ethernet (c) FEEC/UNICAMP

Downsizing $$$ $$$ (c) FEEC/UNICAMP

Downsizing: Benefícios liberdade de escolha (fornecedores, produtos, etc.); confiabilidade (múltiplos pontos de falha); processamento espacial da informação; aumento incremental da capacidade de processamento; atualização tecnológica constante. (c) FEEC/UNICAMP

Internet (c) FEEC/UNICAMP

Sistemas Abertos Sistemas Abertos são sistemas implementados segundo padrões abertos. Padrão aberto: documento estabelecido por consenso e publicado por organismo de padronização acreditado para uso comum e repetitivo. NOTA: esta definição exclui muitos padrões de-facto tais como Java, Windows e MATLAB. (c) FEEC/UNICAMP

Sistemas Abertos: Uma Classificação Podemos classificar Sistemas Abertos em quatro categorias: 1. Modelos de Referência; 2. Arquiteturas de Referência; 3. Arquiteturas Abertas; 4. Implementações de Referência. (c) FEEC/UNICAMP

Modelos de Referência Um modelo de referência é uma descrição de todos os possíveis componentes do sistema, bem como suas funções, relações, e formas de interação [SEI]. Exemplos: OSI, RM-ODP, OMA. Por não imporem restrições para a realização de seus componentes, modelos de referência não garantem interoperabilidade entre diferentes implementações. Entretanto, modelos de referência são úteis para a concepção de arquiteturas para sistemas abertos. (c) FEEC/UNICAMP

Arquiteturas de Referência Uma arquitetura de referência é similar a um modelo de referência, mas prescreve interfaces entre seus componentes. Exemplos: TINA, CORBAservices. Arquiteturas de referência possuem lacunas na especificação que levam a diferentes interpretações e possibilidades de extensões. Estas lacunas tendem a comprometer a interoperabilidade entre diferentes implementações da arquitetura. (c) FEEC/UNICAMP

Arquiteturas Uma arquitetura é similar a um modelo ou arquitetura de referência, mas prescreve protocolos de interopera-bilidade para todos os seus componentes. Exemplos: CORBA, H.323, TCP/IP, ISDN. Arquiteturas provêem interoperabilidade mínima entre suas implementações. (c) FEEC/UNICAMP

Implementações de Referência Uma implementação de referência provê código fonte aberto (não necessariamente gratuito) para os componentes de uma arquitetura que são fundamentais para a interoperabilidade entre diferentes implementações desta arquitetura. Exemplos: FreeDCE, TMN API, HTTPd. Implementações de referência garantem o maior nível possível de interoperabilidade para implemen-tações de sistemas abertos. (c) FEEC/UNICAMP

Exemplo de Padrão Aberto: CORBA Object Request Broker (ORB) Objetos de Aplicação CORBA Facilities (vertical) (horizontal) Serviços CORBA (CORBAservices) O modelo de referência OMA. CORBA especifica o Object Request Broker do modelo OMA. Interoperabilidade entre implementações CORBA é garantida pela linguagem IDL e pelo protocolo IIOP. (c) FEEC/UNICAMP

Exemplo de Padrão Aberto: CORBA IDL e IIOP garantem que duas implementações CORBA sempre irão interoperar no tocante a invocação remota de métodos. Serviços CORBA (CORBAservices) nem sempre interoperam pois apenas suas interfaces são especificadas (faltam implementações de referência e/ou melhor especificação de comportamento). Gerência, configuração e recursos avançados de diferentes implementações CORBA não interoperam. (c) FEEC/UNICAMP

Sistemas Abertos: Conclusão Sistemas abertos são fundamentais para: tornar as implementações menos dependentes de fornecedor individual; incentivar a competição entre diferentes fornecedores por melhores produtos; desenvolver aplicações portáveis, confiáveis, com alto grau de interoperabilidade e capazes de evoluir de forma ordenada; incentivar a inserção de novas tecnologias. (c) FEEC/UNICAMP

O Conceito de Middleware (c) FEEC/UNICAMP

O Conceito de Middleware Visão a Partir do Modelo OSI APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO OPA! Isto eu conheço!!! (c) FEEC/UNICAMP

Conceito de Middleware e o Modelo OSI APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO Medicina Telecomunicações Finanças (c) FEEC/UNICAMP

Conceito de Middleware e o Modelo OSI APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO Ex: funções típicas de telecomunicações } Domínio de aplicação Agente Cliente } Gerenciamento de Rede Um novo Modelo OSI: camada nível 8 contendo funções típicas dos vários domínios de aplicação:Medicina, Finanças, Telecomunicações, etc. (c) FEEC/UNICAMP

Conceito de Middleware e o Modelo OSI APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO Domínio da aplicação Contexto da Aplicação Contexto das Comunicações A Camada de Transporte é um divisor entre o mundo das aplicações e o mundo das comunicações (c) FEEC/UNICAMP

Conceito de Middleware e o Modelo OSI APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO Domínio da aplicação MIDDLEWARE (c) FEEC/UNICAMP

Conceito de Middleware e o Modelo OSI APLICAÇÃO APRESENTAÇÃO SESSÃO Domínio da aplicação Sistema Operacional + Hardware } Sistemas Heterogêneos! Necessidade de Padronização do Middleware (c) FEEC/UNICAMP

Evolução em Middleware 1987 1992 1997 2002 2007 1982 1977 troca de mensagens chamada de procedimento remoto (RPC) objetos distribuídos agentes componentes (c) FEEC/UNICAMP

Evolução do Conceito de Middleware Troca de Mensagens (primitivas SEND/RECEIVE) Aplicação TLI CPC-I Socket Named Pipes SNA TCP/IP NetBIOS IPX/SPX NDIS ODI Token-ring Ethernet ISDN API independente do transporte Pilhas de Transporte Drivers de Rede Placas de Rede ... Send (c) FEEC/UNICAMP

Troca de Mensagens: Semântica tarefa 1 tarefa 2 send(M1) receive(M2) bloqueio send(M2) receive(M1) (c) FEEC/UNICAMP

Troca de Mensagens: Implementação sistema de transporte (TCP/IP) API (socket) port (endpoint) buffer espaço do usuário espaço do núcleo LAN / WAN (c) FEEC/UNICAMP

Remote Procedure Call (RPC) Evolução do Conceito de Middleware Chamada Remota de Procedimento (RPC) TLI CPC-I Socket Named Pipes SNA TCP/IP NetBIOS IPX/SPX NDIS ODI Token-ring Ethernet Aplicação ISDN Remote Procedure Call (RPC) 2- Call (…) 1- Register (…) 3- Call (…) (c) FEEC/UNICAMP

RPC: Semântica call P2(a1,a2) cliente servidor P1 P2 retorno P3 bloqueio P2 executa P1 P2 P3 (c) FEEC/UNICAMP

RPC: Implementação cliente R = call P2(a1,a2) servidor P1 P2 P3 1 2 3 API (socket) empacota parâmetros desempacota resultado cliente R = call P2(a1,a2) servidor dispatcher P1 P2 P3 P2(a1,a2) 1 2 3 4 5 6 7 8 bibliotecas RPC a1 a2 (c) FEEC/UNICAMP

Evolução do Conceito de Middleware Objetos Distribuídos O conceito de objetos surgiu para atender os requisitos relacionados ao aumento na complexidade do desenvolvimento de software Reusabilidade Objeto Barramento de Software Interface Padrão (c) FEEC/UNICAMP

Objetos: Constituição interface: define, em termos de protótipo, um conjunto de operações (ou métodos) estado: define um conjunto de variáveis internas que armazenam o estado corrente do objeto implementação: código dos métodos definidos tanto pelas interfaces quantos internos ao objeto (c) FEEC/UNICAMP

Objetos: Regras de Interação toda a interação com um objeto se dá através da invocação de seus métodos declarados como públicos; métodos declarados como privados só podem ser invocados pelos demais métodos definidos pelo objeto; as variáveis de estado são manipuladas apenas pelos métodos (públicos ou privados) definidos pelo objeto (isto é, são invisíveis externamente ao objeto). (c) FEEC/UNICAMP

Objetos: Conceitos Básicos Classificação: objetos são organizados em classes. Uma classe define o comportamento dos objetos dela derivados. Relacionamento: classes podem apresentar relações de interdependência, por exemplo herança (relação tipo é-um/é-uma); composição (relação tipo parte-de); colaboração (relações tipo usa, delega, autoriza, etc). (c) FEEC/UNICAMP

Objetos: Conceitos Básicos Instanciação: objetos são criados através de uma operação (denominada de instanciação) sobre uma classe. Encapsulamento: objetos “escondem” detalhes de sua implementação interna, expondo apenas suas interfaces para o meio externo. Identidade: objetos possuem identidade única capaz de diferenciar um objeto dos demais. Polimorfismo: métodos de mesmo nome podem apresentar diferentes comportamentos, dependendo do objeto que o implementa. (c) FEEC/UNICAMP

Objetos: Conceitos Básicos identidade instanciação classe herança (especialização) relação interface invocação de métodos M1 M3 M2 estado métodos polimorfismo encapsulamento (c) FEEC/UNICAMP

Objetos Distribuídos Deve-se notar que as tecnologias de middleware procuram acompanhar as tecnologias de desenvolvimento de software: troca de mensagens: estende o paradigma de programação não estruturada à programação de sistemas distribuídos (programação distribuída); RPC: estende o paradigma de programação estruturada à programação distribuída; objetos distribuídos: estende o paradigma de programação orientada a objetos à programação distribuída. (c) FEEC/UNICAMP

Objetos Distribuídos: Vantagens Objetos distribuídos apresentam as seguintes vantagens sobre troca de mensagens e RPC: flexibilidade: qualquer entidade de software pode ser transformada em um objeto distribuído; granularidade: objetos distribuídos podem apresentar diferentes níveis de granularidade; confiabilidade: objetos distribuídos são entidades auto-contidas o que facilita a identificação, isolação e correção de falhas; custo: o desenvolvimento de objetos distribuídos é mais econômico graças ao reuso de software propiciado pela programação orientada a objetos. (c) FEEC/UNICAMP

Objetos Distribuídos: Interação Objetos distribuídos são capazes de interagir através de uma rede de comunicação (LAN, Intranet, Internet) de forma semelhante à interação entre objetos locais. Para tanto, padrões são necessários para prover: definição de interfaces remotas; identificação de objetos (referências); "nomeação" de objetos (naming); associação nome-referência (binding); suporte à invocação remota de métodos (RPC). Estes padrões são oferecidos por uma infra-estrutura denominada ORB (Object Request Broker). Por exemplo, RMI é o ORB nativo da linguagem Java. (c) FEEC/UNICAMP

Interfaces Remotas Objetos distribuídos devem definir pelo menos uma interface remota capaz de processar invocações através da rede. Em padrões neutros (independentes de linguagem de programação) como CORBA e DCOM, uma linguagem de definição de interface (IDL) é especificada. ORBs provêem compiladores IDL para cada linguagem alvo. RMI, por ser uma solução puramente Java, utiliza interfaces Java derivadas da interface Remote para definir interfaces remotas. Um servant (ou implementação) é um objeto que implementa uma interface remota (i.e., supre código para os métodos da interface). Um objeto distribuído é constituído por um ou mais servants. (c) FEEC/UNICAMP

Objetos Distribuídos: Implementação Descrição da(s) Interface(s) ORB (biblioteca) Compilador (C++, Java, ...) Compilador de Interfaces Implementação dos Servants (C++, Java, ...) Stubs / Skeletons servant (c) FEEC/UNICAMP

Referência de Objetos Objetos distribuídos devem possuir uma identificação (referência) capaz de localizá-lo na rede. Esta identificação é dependente do ORB. Por exemplo, CORBA utiliza um identificador denominado IOR (Interoperable Object Reference) que agrega o endereço de rede do objeto (host e port do servidor), sua classe, seu identificador no servidor, etc. IOR é armazenado em uma cadeia de bytes. RMI utiliza as próprias instâncias das classes Java que implementam interfaces remotas para identificar objetos distribuídos. OBS: Uma referência pode ser persistente ou transiente. (c) FEEC/UNICAMP

Stubs e Skeletons Para interagir com um objeto remoto, um objeto cliente deve obter a referência do objeto remoto e converte-la em um objeto local denomindo proxy ou stub. Stubs definem os mesmos métodos da interface remota do objeto. Ao invocar um método no stub, o stub encaminha a requisição para o objeto remoto, recebe o retorno e o devolve como resultado da interação. Skeletons fazem o papel inverso do stub no lado do objeto remoto. invocação local Stub Rede Skeleton interface remota objeto distribuído upcall M1 M2 M3 protocolo de RPC cliente (c) FEEC/UNICAMP

Atribuição de Nomes ORBs convencionam esquemas de nomes para os objetos distribuídos. Por exemplo, CORBA utiliza um espaço hierárquico e arbitrário de nomes definido em um contexto. RMI utiliza uma notação padrão URL: rmi://ferrugem.dca.fee.unicamp.br:8088/Servers/AccountServer //143.106.50.188/AccountServer (c) FEEC/UNICAMP

Binding ORBs provêem serviços de nomes para armazenar e recuperar associações nome-referência de objeto. No caso do RMI, um servidor de nomes denominado rmiregistry é fornecido com a plataforma Java. servidor de nomes cliente objeto distribuído 2. lookup 1. bind/rebind 3. invoke (c) FEEC/UNICAMP

Invocação Remota de Métodos A invocação de métodos remotos exige protocolos de RPC (Remote Procedure Call). Tais protocolos especificam: como parâmetros são codificados (número de parâmetros, tipos, valores e indireções); como invocações e retornos são estruturados; que protocolo de transporte é utilizado (TCP ou UDP); como exceções são propagadas de volta para o cliente. CORBA especifica o protocolo IIOP (Internet Inter-ORB Protocol), enquanto RMI especifica JRMP (Java Remote Method Protocol). Opcionalmente, para fins de interoperabilidade com CORBA, RMI pode utilizar IIOP. (c) FEEC/UNICAMP

Arquitetura de Distribuição Skeleton Stub Object Request Broker servant objeto distribuído Nomes Eventos Segurança Serviços servidor cliente (c) FEEC/UNICAMP

Middleware: Padrões Indústria Consórcios ISO/ITU-T Internet 1977 1982 DCOM (Microsoft) EJB (Sun) Indústria RMI (SUN) .NET (Microsoft) DCE (OSF) CORBA (OMG) SOAP (W3C) Consórcios OSI ISO/ITU-T ODP Internet TCP/IP sockets RPC WWW 1977 1982 1987 1992 1997 2002 (c) FEEC/UNICAMP

Plataforma Java (c) FEEC/UNICAMP

Plataforma Java 2 A Plataforma Java 2 consiste de uma linguagem (Java), um ambiente de runtime (máquina virtual) e um conjunto de serviços de middleware disponibilizados através de interfaces de programação (APIs). Linguagem Java Máquina Virtual APIs (c) FEEC/UNICAMP

Plataforma Java 2: Arquitetura APIs Suporte às Aplicações Applets, Pacotes, Frameworks Classes Java Estendidas Classes Java Básicas Plataforma Java Básica Máquina Virtual Java bytecodes Interface de Portabilidade Adaptador Adaptador S.O. Java Browser S.O. S.O. Java Chip Hardware Hardware (c) FEEC/UNICAMP

Plataformas Java 2 A SUN Microsystems fornece três tipos de plataformas Java 2: Java 2 Platform, Micro Edition (J2ME): plataforma de desenvolvimento para dispositivos pequenos, tais como Palm Pilots, Pagers, etc. Contém uma forma bem restrita da linguagem Java; Java 2 Platform, Standard Edition (J2SE): contém serviços Java para Applets e Aplicações. Contém funcionalidades para entrada-saída, interfaces gráficas de usuários, entre outras; Java 2 Platform, Enterprise Edition (J2EE): plataforma de desenvolvimento completa para empresa fornecendo um ambiente seguro, multi-usuário, portável, neutro (Sistema Operacional e Hardware) para o desenvolvimento de aplicações distribuídas escritas em Java (com ënfase no lado servidor). (c) FEEC/UNICAMP

Plataforma Java 2EE: Tecnologias Enterprise JavaBeans (EJB) Define uma API que facilita a criação, instalação e gerência de aplicações baseadas em componentes. Utiliza RMI para comunicação cliente-servidor. Servidor EJB Container EJB EJB Home Interface EJB Bean Cliente EJB Remote Interface Database (c) FEEC/UNICAMP

Plataforma Java 2EE: Tecnologias JNDI (Java Naming and Directory Interface) Provê acesso unificado a serviços de nomes e de diretório para as aplicações Java. service providers OMG COSNaming JNDI SPI JNDI API RMI Registry JNDI Naming Manager Cliente Internet LDAP Novell NDS (c) FEEC/UNICAMP

Plataforma Java 2EE: Tecnologias JBDC (Java Database Connectivity) Provê uma interface uniforme para acesso a bases de dados. JDBC Driver API JDBC Driver A Database A JDBC API JDBC Driver B Cliente JDBC Database B JDBC Driver C Database C (c) FEEC/UNICAMP

Plataforma Java 2EE: Tecnologias JTA (Java Transaction API) e JTS (Java Transaction Service) Definem APIs para um serviço de transação em Java (baseados no Serviço de Transações do OMG - CORBA OTS). JTA é utilizada no EJB. Transaction Coordinator JTS API JTA API Cliente Transaction Manager(s) JTS Resource Manager(s) Datastores (c) FEEC/UNICAMP

Plataforma Java 2EE: Tecnologias Java IDL (Interface Definition Language) Permite aplicações Java interoperarem com outras plataformas CORBA (ex. Orbix). Prove compilador IDL e ORB simples que suporta IIOP. Cliente CORBA (C++) Servidor CORBA (C++) Applet Java Servidor EJB IIOP Java 2 ORB Orbix (c) FEEC/UNICAMP

Plataforma Java 2EE: Tecnologias RMI-IIOP (Java Remote Method Invocation - CORBA Internet Inter-ORB Protocol) Permite clientes Java acessarem, via RMI, serviços disponibilizados em CORBA (e vice-versa). RMI-IIOP utiliza JNDI. Cliente RMI Servidor RMI Cliente CORBA Servidor CORBA RMI-IIOP API RMI ORB CORBA ORB IIOP (c) FEEC/UNICAMP

Plataforma Java 2EE: Tecnologias Outras Tecnologias: Java Server Pages (JPS) e Servlets: APIs que permitem estender as funcionalidades de um servidor WWW; Java Message Service (JMS): API para serviços de mensagens; JavaMail: API para serviços de E-mail; J2EE Connector: arquitetura para conectar a plataforma Java 2 com outros serviços de informação da empresa. (c) FEEC/UNICAMP

Plataforma Java 2EE: API Específicas, Extensões, Pacotes e Produtos Java Media Framework (JMF): API para manipulação (local e através da rede) de áudio e vídeo; Java TV API: API para serviços interativos em TV digital (ex: vídeo sob demanda); Java Phone API: API para serviços de telefonia (ex: click-to-dial); Java Commerce Toolkit: pacote para desenvolvimento de aplicações de comércio eletrönico; Java Cryptography Extension e Java Authentication and Authorization Service: extensões de segurança; Java 2D, Java 3D, Java Advanced Imaging: APIs para computação gráfica; Jini: serviços de suporte à redes com topologia variável; .......... Dentre muitos outros !!! (c) FEEC/UNICAMP

Java Remote Method Invocation (RMI) RMI é um ORB nativo da linguagem Java que provê uma infra-estrutura para invocação de métodos remotos, um compilador para geração de stubs e skeletons (rmic) e um servidor de nomes (rmiregistry). RMI utiliza o mecanismo de segurança nativo da linguagem Java através de security managers e class loaders. RMI tem como vantagens simplicidade e plena integração com Java (segurança, carregamento dinâmico de classes, passagem de objetos por valor, etc.). Entretanto, é uma solução 100% Java (mas capaz de interoperar com outras linguagens de programação através de CORBA). (c) FEEC/UNICAMP

RMI: Visão Geral host rmiregistry Naming Naming rmic stub skel. Naming.lookup rmi://host:port/Name rmiregistry Naming.bind rmi://host:port/Name ObjRef cliente RMI ObjRef Naming s.M1(...) servidor RMI Naming rmic Servant M1 M2 M3 M1 M2 M3 TCP/IP JRMP stub skel. socket socket TCP/IP IIOP (c) FEEC/UNICAMP

Java RMI O ciclo de desenvolvimento de objetos distribuídos em RMI possui os seguintes passos: definição da interface remota; compilação da interface remota (javac); desenvolvimento do servant; geração de stubs e skeletons a partir do servant via compilador RMI (rmic); desenvolvimento do servidor. (c) FEEC/UNICAMP

RMI: Interfaces Remotas Interfaces remotas em RMI são declaradas como interfaces Java que estendem a interface Remote. Cada método da interface remota deve lançar uma exceção do tipo RemoteException (que será propagada ao cliente). import java.rmi.Remote; import java.rmi.RemoteException; public interface Account extends Remote { void deposit( long amount ) throws RemoteException; void withdraw( long amount ) throws RemoteException; long balance() throws RemoteException; } (c) FEEC/UNICAMP

RMI: Passagem de Parâmetros em Métodos de Interfaces Remotas Parâmetros e retornos em invocações remotas são sempre passados por valor (isto e, uma cópia é passada). Objetos Java passado como parâmetros devem ser "serializáveis" (todos os tipos nativos são). Referências de objetos remotos podem ser passados como parâmetros ou retorno (no caso, uma cópia de seu stub é passada). Tais objetos devem possuir apenas interfaces remotas. Caso a classe de um objeto passado ou retornado não se encontra presente na JVM, a mesma pode ser carregada dinamicamente via HTTP (detalhes a seguir). (c) FEEC/UNICAMP

RMI: Servants import java.rmi.*; import java.rmi.server.*; public class AccountServant implements Account { long balance; long limit; public AccountServant(long lim) throws RemoteException { super(); balance = 0; limit = lim; } (c) FEEC/UNICAMP

RMI: Servants (cont.) public void deposit( long amount ) throws RemoteException { balance = balance + amount; } public void withdraw( long amount ) throws RemoteException { if((limit + balance - amount) < 0) throw new RemoteException("Limit Exceeded"); balance = balance - amount; public long balance() throws RemoteException { return balance; (c) FEEC/UNICAMP

RMI: Classes AccountClient Remote AccountServant_Stub AccountServant <<interface>> Account deposit() withdraw() balance() AccountServant Remote extends implements AccountServant_Stub AccountServant_Skel geradas por rmic AccountClient (c) FEEC/UNICAMP

RMI: rmic (Compilador RMI) A plataforma Java provê um compilador capaz de gerar stubs e skeletons para suporte à distribuição de objetos com RMI. O compilador recebe como argumento a classe compilada do servant e gera dois arquivos compilados: um contendo o stub (utilizado pelo cliente) e outro o skeleton (utilizado pelo servidor). Exemplo: C:\ dir *.class Account.class AccountServant.class C:\ rmic AccountServant AccountServant_Stub.class AccountServant_Skel.class (c) FEEC/UNICAMP

RMI: Serviço de Nomes A plataforma Java provê um serviço de nomes para registro de servants RMI. O serviço de nomes é suportado por um servidor transiente, rmiregistry, que armazena as referências de objetos localizados em seu próprio nó. A referência de objeto no formato URL estipula o seu endereço de host e, opcionalmente, port do servidor de nomes. Exemplo: seja um objeto registrado como: rmi://ferrugem.dca.fee.unicamp.br/Servers/AccountServer O acesso à referência do objeto deve se dar no endereço de host "ferrugem.dca.fee.unicamp.br" e port default do servidor de nomes (1099). (c) FEEC/UNICAMP

RMI: A Classe Naming O servidor de nomes rmiregistry é acessível através da classe Naming que provê os seguintes métodos estáticos: void bind(String name, Remote ref): associa um nome a uma referência de objeto; void rebind(String name, Remote ref): re-associa um nome a uma referência de objeto; Remote loopkup(String name): busca uma referência associada ao nome; void unbind(String name): desassocia a referência do nome; String[] list(String registry): lista todos os nomes mantidos por um servidor rmiregistry. (c) FEEC/UNICAMP

RMI: Servidores import java.rmi.*; import java.rmi.server.*; import java.net.*; public class AccountServer { public static void main(String[] args) { // if no security manager was set, set the RMI´s one if(System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } (c) FEEC/UNICAMP

RMI: Servidores (cont.) try { String host = (InetAddress.getLocalHost()).getCanonicalHostName(); String name = "rmi://" + host + "/Account"; Account objRef = new AccountServant((long)1000); Naming.rebind(name, objRef); // bind System.out.println("AccountServant registered"); } catch (Exception e) { System.err.println("AccountServant exception: " + e.getMessage()); e.printStackTrace(); } (c) FEEC/UNICAMP

RMI: Clientes import java.rmi.*; import java.net.*; public class AccountClient { public static void main(String args[]) { if(args.length != 1) { System.out.println("I need the server's host name as argument"); System.exit(0);} // if no security manager was set, set the RMI´s one if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager());} try { // get reference of the remote object String host = (InetAddress.getByName(args[0])).getCanonicalHostName(); String name = "rmi://" + host + "/Account"; Account accountRef = (Account) Naming.lookup(name); (c) FEEC/UNICAMP

RMI: Clientes (cont.) accountRef.deposit( 100 ); accountRef.withdraw( 240 ); accountRef.withdraw( 10 ); System.out.println("Balance is " + accountRef.balance()); accountRef.withdraw( 10000 ); } catch (Exception e) { System.err.println("AccountClient exception: " + e.getMessage()); } (c) FEEC/UNICAMP

RMI: Aspectos de Segurança No lado servidor, RMI exige que todas as permissões de socket sejam habilitadas para os domínios onde os clientes se localizam. Adicionalmente, permissão para conexão local ao port 1099 (rmiregistry) deve ser habilitada. Por exemplo, o trecho do arquivo .java.policy abaixo libera interações com clientes localizados em qualquer host do domínio "dca.fee.unicamp.br" grant { permission java.net.SocketPermission "*.dca.fee.unicamp.br", "listen,accept,connect"; permission java.net.SocketPermission "localhost:1099", "connect"; }; (c) FEEC/UNICAMP

RMI Sobre HTTP Devido a presença de firewalls, uma requisição RMI pode ser impedida de atingir o objeto remoto. Nestes casos, é possível tunelar-se a requisição RMI sobre o protocolo HTTP. cliente RMI Serv. HTTP Firewall script CGI (java-rmi.cgi) servidor RMI HTTP POST proxy HTTP Stub Skeleton sockets especiais (c) FEEC/UNICAMP

RMI: Propriedades O comportamento de clientes e servidores RMI pode ser configurado através de propriedades da máquina virtual. As mais comuns são: java.rmi.server.codebase: localização (URL) das classes que devem ser carregadas dinamicamente (skeletons, parâmetros, etc.); java.rmi.server.logCalls: gera um log em System.err; java.rmi.activation.port: define um port de ativação para o daemom RMI (default 1098); java.rmi.server.disableHttp: desabilita tunelamento através de HTTP. (c) FEEC/UNICAMP

Como Distribuir um Objeto ? Os métodos públicos têm que ser definidos de forma precisa através de uma sintaxe neutra. Para tal emprega-se uma Linguagem de Descrição de Interfaces (IDL). Deve-se prover uma infra-estrutura que permita a invocação remota (através da rede) de métodos. Esta infra-estrutura é denominada Object Request Broker (ORB). Deve-se conectar os métodos públicos ao ORB para permitir sua invocação remota. Os componentes de conexão, denominados stubs e skeletons, são gerados integralmente por um Compilador IDL. (c) FEEC/UNICAMP

ODP (Open Distributed Processing) (c) FEEC/UNICAMP

O Modelo OSI possui algumas funcionalidades na camada 7 para o desenvolvimento de sistemas distribuídos: ROSE (Remote Operation Service Element); CCR (Concurrency, Commitment, Recovery); TP (Transaction Processing); DS (Directory Service); MHS (Message Handling System). (c) FEEC/UNICAMP

Problemas no desenvolvimento de Sistemas Distribuídos Modelo OSI Problemas no desenvolvimento de Sistemas Distribuídos diretamente sobre o OSI: baixa disponibilidade de implementações completas; padrão “estacionado”; ausência de serviços importantes (segurança, principalmente); ASN.1/BER pouco flexível; eficiência dos protocolos. (c) FEEC/UNICAMP

ODP: Open Distributed Processing Padrão OSI/ITU-T para processamento distribuído aberto (ITU-T X.901,902,903,904). É um modelo de referência apenas (protocolos não são especificados) que vem influenciando outras atividades de padronização (exemplo: CORBA). Seu desenvolvimento foi fortemente influenciado pelo projeto ANSA (Universidade de Lancaster, UK). (c) FEEC/UNICAMP

ODP: Pontos de Vista Empresa Informação Computação SD Engenharia especificação SD implementação Engenharia Tecnologia (c) FEEC/UNICAMP

ODP: Pontos de Vista Pontos de vista não são hierarquizados, mas sim diferentes visões de um mesmo sistema. SD ponto de vista (c) FEEC/UNICAMP

ODP: Pontos de Vista Empresa SD Informação Computação Tecnologia especificação SD Informação Computação ORB implementação Tecnologia Engenharia (c) FEEC/UNICAMP

ODP: Ponto de Vista de Empresa O ponto de vista de empresa modela o sistema em termos de grandezas relevantes para a organização onde o sistema será empregado. Em linhas gerais, pode ser considerada um “resumo executivo” do sistema, onde suas principais características são levantadas. Este ponto de vista estabelece as principais restrições impostas ao projeto do sistema. Não existe uma linguagem formal para descrever o sistema neste ponto de vista. Textos, gráficos, diagramas, esquemas podem ser livremente utilizados. (c) FEEC/UNICAMP

ODP: Ponto de Vista de Empresa Grandezas relevantes para este ponto de vista: requisitos (QoS, custos, ...); objetivos (mercados, público-alvo, …); benefícios (lucro, produtividade, …); políticas (segurança, acesso, taxação, ...); domínios administrativos/federações; restrições/privilégios de uso do sistema; pontos de referência (protocolos, acordos, ...); funcionalidades (agentes, relações, contratos, ...). (c) FEEC/UNICAMP

ODP: Ponto de Vista de Informação O ponto de vista de informação tem por objetivo modelar o sistema enfocando a informação produzida e consumida pelo sistema. Neste ponto de vista são levantados os principais componentes manipuladores de informação, componentes estes denominados objetos de informação. (c) FEEC/UNICAMP

ODP: Ponto de Vista de Informação Objetos de informação identificam as principais entidades do domínio, suas relações (especialização, decomposição, etc.) e principais variáveis e operações. Este ponto de vista pode ser descrito através de notação gráfica introduzidas por metodologias de desenvolvimento orientado a objeto (UML, OMT, …). (c) FEEC/UNICAMP

ODP: Ponto de Vista de Computação O ponto de vista de computação modela o sistema em termos de entidades de processamento de informação. Estas entidades, denominadas objetos computacionais, são os blocos fundamentais a partir dos quais o sistema distribuído é contruido. Este ponto de vista pode ser descrito através de notação gráfica introduzidas por metodologias de desenvolvimento orientado a objeto (UML, OMT, …). (c) FEEC/UNICAMP

ODP: Ponto de Vista de Computação No ODP, objetos computacionais básicos (BCO: basic computacional object) possuem múltiplas interfaces computacionais, cada uma associada a determinado tipo. O tipo define as características da interface. interface computacional BCO T1 T2 tipo da interface (c) FEEC/UNICAMP

ODP: Interfaces Computacionais iniciador respondedor sinal sinal cliente evocação servidor operação terminação produtor consumidor fluxo stream (c) FEEC/UNICAMP

ODP: Ligação (Binding) Primitiva Na ligação primitiva dois objetos computacionais básicos têm suas interfaces conectadas sem o auxílio de um artefato específico de interconexão. Exemplo: objetos C++ num mesmo programa. T T’ BCO BCO T’: tipo complementar a T (c) FEEC/UNICAMP

ODP: Ligação (Binding) Composta Na ligação composta dois objetos computacionais básicos têm suas interfaces conectadas com o auxílio de um artefato específico de interconexão. Na visão de computação este artefato é representado por um objeto de ligação (BO: binding object). interface de controle BCO BO BCO T T’ T T’ (c) FEEC/UNICAMP

ODP: Ponto de Vista de Engenharia O ponto de vista de engenharia fornece a visão “espacial” (distribuída) do sistema. Nesta visão os objetos computacionais (BCO e BO) da visão de computação são realizados através de objetos básicos de engenharia (BEO: Basic Engineering Object). Regras de estruturação que estabelecem agrupamentos e ligações entre BEOs. Este ponto de vista pode ser descrito através de diagramas de distribuição (deployment) da notação UML. (c) FEEC/UNICAMP

ODP: Ponto de Vista de Engenharia Objetos Básicos de Engenharia (BEO) São as unidades de processamento no ponto de vista de engenharia. Possuem uma interface de gerenciamento e uma ou mais interfaces de serviço, interfaces estas denomi-nadas interfaces de engenharia. checkpoint, recover, delete, ... interface de gerenciamento BEO interface de engenharia (c) FEEC/UNICAMP

ODP: Regras de Estruturação Cluster Cluster é um agregado de BEOs compartilhando um mesmo espaço de endereçamento. Um BEO especial no cluster (Gerente de Cluster - GCL) provê uma interface de gerenciamento para o cluster. É a unidade de migração do ODP. checkpoint, recover, delete, ... GCL BEO CLUSTER (c) FEEC/UNICAMP

ODP: Regras de Estruturação checkpoint, recover, delete, ... Cápsula Cápsula é um agregado de clusters. Um BEO especial na cápsula (Gerente de Cápsula) provê uma interface de geren-ciamento para a cápsula. É a unidade de alocação de recursos do ODP (exemplo: processo UNIX). GCP CÁPSULA GCL CLUSTER (c) FEEC/UNICAMP

ODP: Regras de Estruturação CÁPSULA núcleo NÓ Nó Um nó é composto de um conjunto de cápsulas e um núcleo. No ODP o nó representa uma unidade de processamento, armazenamento e comunicação. Exemplo: estação UNIX. (c) FEEC/UNICAMP

ODP: Regras de Estruturação Canal Canal é a realização do objeto de ligação na visão de engenharia. É composto de três objetos básicos de engenharia de cada lado: stub, binder e protocol adapter. Adicionalmente, um controlador de canal expõe uma interface única de controle para o canal. BEO1 BEO2 interface de controle stub stub contr. de canal binders protocol adapters canal rede (c) FEEC/UNICAMP

ODP: Canal Stub Stub é responsável pelos serviços de apresentação (conversão/compactação de dados, criptografia, etc) do canal. Apresenta uma interface de dados para o objeto de engenharia no extremo do canal e uma interface de controle utilizada pelo controlador de canal. (c) FEEC/UNICAMP

ODP: Canal Binder Binder é responsável pelo gerenciamento fim-a-fim do canal. Funções típicas do binder: monitoramento do fluxo de informação através do canal, gerência de qualidade de serviço e destruição de seu extremo do canal. Possui interfaces de dados para o stub e protocol adapter, além de uma interface de controle utilizadada pelo controlador de canal. (c) FEEC/UNICAMP

ODP: Canal Protocol Adapter Protocol Adapter é responsável pela comunicação fim-a-fim no canal. Funções típicas: estabelecimento e encerramento de conexões de transporte através da rede. Apresenta uma interface de dados para o binder e uma interface de controle utilizada pelo controlador de canal. (c) FEEC/UNICAMP

ODP: Canal Controlador de Canal Controlador de canal apresenta uma interface única de controle para o canal. Esta interface realiza na visão de engenharia a interface computacional do objeto de ligação (BO) presente na visão de computação. Controlador de canal interage com os demais objetos do canal para realizar a ação de controle solicitada em sua interface. (c) FEEC/UNICAMP

ODP: Mapeamento Computação/Engenharia BCO1 BEO1 BEO2 stub stub contr. de canal BO binders BCO2 protocol adapters canal transparência rede (c) FEEC/UNICAMP

ODP: Transparência Transparência é um conceito chave que permite a visão de engenharia (associada à implementação do sistema) se aproximar da visão de computação (associada ao modelamento do sistema). Transparência deve ser provida pelo núcleo, canal e demais infra-estruturas de suporte à implementação (ORBs, repositórios, etc.). (c) FEEC/UNICAMP

ODP: Transparência Tipos de transparência: acesso; localização; migração; concorrência (transação); relocação; falha; replicação; persistência. As transparências de acesso e localização são as mais comumente encontradas nos sistemas distribuídos. (c) FEEC/UNICAMP

DCE (Distributed Computing Environment) (c) FEEC/UNICAMP

DCE: Distributed Computing Environment Padrão da antiga Open Software Foundation (OSF), hoje Open Group. OSF é um consórcio sem fins lucrativos de empresas (IBM, DEC, HP,…) destinado a padronização de tecnologias de software para sistemas abertos. Exemplo: OSF/1 (UNIX “não AT&T”) OSF/Motif (similar ao X Window) Diferentemente de organizações como a OMG e ISO, a OSF supre os implementadores com um código fonte base. (c) FEEC/UNICAMP

DCE: Objetivos Oferecer um conjunto de serviços distribuídos (RPC, sistema de arquivos, serviços de segurança, diretório e relógio distribuído) independentes de plataforma sobre os quais aplicações distribuídas são construídas. Estes serviços são baseados em padrões já consagrados tais como X.500 (ISO/ITU-T), DNS (IETF) e POSIX (IEEE). (c) FEEC/UNICAMP

DCE: Arquitetura HARDWARE SISTEMA OPERACIONAL REDE DCE Threads DCE Remote Procedure Call Segurança Time Diretório Sistema de Arquivos APLICAÇÕES DISTRIBUÍDAS (c) FEEC/UNICAMP

DCE: Threads OBJETIVO: uniformizar a programação multithreaded. Utiliza o padrão POSIX 1003.4a (IEEE). Provê três esquemas de escalonamento de threads: FIFO (First In First Out) RR (Round Robin) Default (RR com prioridades) (c) FEEC/UNICAMP

DCE: Threads tempo espaço de en- dereçamento espaço de endere- çamento comum escalonamento T H R E A D T H R E A D T H R E A D T H R E A D tempo processo monothreaded processo multithreaded (c) FEEC/UNICAMP

DCE: Threads A programação multithreaded permite que servidores processem uma requisição enquanto outra estiver pendente (bloqueada por I/O, por exemplo). cliente req #1 servidor multi- threaded cliente req #2 (c) FEEC/UNICAMP

DCE: Threads Formas de Escalonamento: A B C FIFO RR A B C A B C B C B DEF. A B C A B C C Pb > Pa, Pc (c) FEEC/UNICAMP

DCE: Remote Procedure Call Integrado com os serviços de thread, segurança e diretório; Independente da pilha de protocolos de rede; Permite a passagem de argumentos de tamanho ilimitado e de ponteiros; Utiliza uma linguagem de definição de interfaces: IDL - Interface Definition Language (diferente da IDL do CORBA !) (c) FEEC/UNICAMP

DCE: RPC cliente servidor SERVIÇO DE DIRETÓRIO 3. server ? 2. registra serviço 5. RPC cliente servidor RPC daemon 4. endpoint ? 1. registra endpoint tabela de endpoints (c) FEEC/UNICAMP

DCE: RPC uuidgen gera ID único contém a definição da interface do serviço Editor arquivo IDL compilador IDL stub do cliente stub do servidor cabeçalho código C (c) FEEC/UNICAMP

DCE: RPC stub do cliente stub do servidor cabeçalho runtime lib código do cliente código do servidor runtime lib (servidor) Compilador C Compilador C CLIENTE SERVIDOR (c) FEEC/UNICAMP

DCE: Serviço de Relógio Distribuído (DTS) Objetivo: garantir que os relógios das máquinas com DCE instalado: são consistentes (marcam o mesmo tempo); são corretos (seguem a mesma referência). DTS é necessário para a ordenação de eventos numa aplicação distribuída. No DCE, tempo é armazenado num contador de 64 bits cujo valor zero corresponde a 00:00 Hs de 15/10/1582 ! (c) FEEC/UNICAMP

DCE: DTS fonte de tempo (não requerida) time server time server time ? rede time clerk time clerk time clerk UTC (c) FEEC/UNICAMP

DCE: DTS Forma de operação: UTC server #1 UTC server #2 UTC server #3 TIME CLERK (c) FEEC/UNICAMP

DCE: Serviço de Diretório Objetivo: manter a localização (host) de servidores. O serviço de diretório é estruturado em dois níveis: Nível local (de célula): registra os recursos locais (CDS: Cell Directory Service) Nível Global: permite acesso a recursos remotos (GDS: Global Directory Service) GDS é baseado nos padrões X.500 (ISO/ITU-T) e DNS (Internet Domain Name System). (c) FEEC/UNICAMP

DCE: Serviço de Diretório Arquitetura: servidor DNS X.500 DA CDS GDA CDS: Cell Directory Agent GDA: Global Direcory Agent célula outros servidores (c) FEEC/UNICAMP

DCE: Serviço de Segurança Objetivo: prover acesso seguro aos recursos. No DCE, segurança compreende três atividades: Autenticação: comprovação da identidade de clientes e servidores; Autorização: quem está autorizado a manipular determinado recurso; Proteção: garantir que a informação não se alterou em trânsito. (c) FEEC/UNICAMP

DCE: Serviço de Segurança AUTENTICAÇÃO Utiliza a tecnologia Kerberos (MIT). Um servidor de segurança (security server) gerencia a distribuição de tickets (informação criptografada contendo as identidade de pares cliente-servidor). Tickets são usados para o estabelecimento de RPC Autenticada (segura). (c) FEEC/UNICAMP

DCE: Serviço de Segurança AUTORIZAÇÃO Utiliza listas de controle de acesso (ACL: Access Control List). ACL é um padrão POSIX 1003.6. Cada recurso possui uma ACL que discrimina os privilégios para usuários e grupos de usuários. Exemplos de privilégios: read, write, execute. ACLs são armazenadas num servidor (ACL server). (c) FEEC/UNICAMP

DCE: Serviço de Segurança PROTEÇÃO Utiliza checksum criptografado como proteção contra alteração da informação em trânsito. informação (ex: parâmetro RPC) checksum computado por criptografia OBS: O DCE não provê mecanismos para criptografar a informação. (c) FEEC/UNICAMP

DCE: Serviço de Segurança Visão Geral: servidor de autenticação obtém tickets ferramentas de administração chaves criptográficas permissões login (lib) cliente ACL server RPC recursos servidor obtém permissão (c) FEEC/UNICAMP

DCE: Sistema de Arquivos DCE provê um sistema de arquivos distribuído (DFS: Distributed File System) composto de: Um subsistema de arquivo local similar ao do UNIX denominado Episode (acesso compativel com o padrão POSIX 1003); Um conjunto de servidores para tornar distribuído o subsistema de arquivos local. (c) FEEC/UNICAMP

DCE: DFS (cliente) cliente DFS cache RPC para os servidores DFS subsistema de arquivo local cliente chamada de sistema (open, read, write, …) chamadas locais chamadas DFS DFS cache RPC para os servidores DFS (c) FEEC/UNICAMP

DCE: DFS (servidor) File Exporter Token Manager chamadas locais chamadas DFS Token Manager Episode subsistema de arquivo local (+ extensões) File Exporter fileset server replication BOS backup (c) FEEC/UNICAMP

DCE: o conceito de CÉLULA clientes servidores DFS servidores de segurança, diretório e time (c) FEEC/UNICAMP

CORBA (Common Object Request Broker Architecture) (c) FEEC/UNICAMP

Object Management Group (OMG) O OMG foi fundado em 1989 por 11 empresas (dentre elas 3Com, HP, Data General, Unisys, Sun e Philips) como uma empresa sem fins lucrativos. Hoje possui 800 membros, dentre eles todos os “peso-pesados” das indústrias de informática e de telecomunicações. (c) FEEC/UNICAMP

OMG: Missão A missão do OMG é prover a indústria com especifi-cações detalhadas na área de gerência de objetos distribuídos visando estabelecer uma base comum para o desenvolvimento de aplicações. Estas especificações incluem: uma arquitetura de referência (OMA) e sua implementação (CORBA); uma linguagem de especificação (IDL); protocolos de interoperabilidade (GIOP, IIOP); aplicações específicas (TMN, IN, etc.). (c) FEEC/UNICAMP

O OMG é estruturado em três comitês: 1. Platform Technology Committee (PTC); 2. Domain Technology Committee (DTC); 3. Architecture Board. Cada comitê é subdividido em Task Forces, Special Interest Groups (SIGs) e Working Groups (WGs). (c) FEEC/UNICAMP

OMG: Processo de Padronização Membros do OMG possuem um dos três níveis de influência: voto no nível de Task Forces (universidades, governos, pequenas empresas); voto no nível de Platform TC, Domain TC ou ambos (grandes usuários de tecnologia); submissão de padrões para adoção nos TCs (gigantes da informática e telecomunicações). (c) FEEC/UNICAMP

OMG: Padrões Alternativos As principais tecnologias que competem com as padronizadas pelo OMG são: Microsoft DCOM (Distributed Component Object Model). Problema: uma empresa, uma tecnologia (Windows). Sun Java (linguagem, APIs, toolkits, frameworks, etc.). Problema: uma linguagem de programação. W3C (WWW Consortium): introdução de objetos na Web (XML, HTTP, SOAP, etc.). Problema: soluções centradas na Web. (c) FEEC/UNICAMP

A Arquitetura OMA OMA (Object Management Architecture) é uma arquitetura de referência para gerência de objetos distribuídos. A arquitetura identifica componentes, interfaces e protocolos necessários para o desenvolvimento de sistemas de software interoperáveis entre os principais sistemas de hardware, sistemas operacionais e linguagens de programação. (c) FEEC/UNICAMP

OMA: Componentes OMA possui um componente central, o Object Request Broker (ORB), e 4 categorias de interfaces: Serviços de Objetos (Object Services); Facilidades Comuns (Common Facilities); Interfaces Específicas do Domínio (Domain Interfaces); Interfaces Específicas da Aplicação (Application Interfaces). (c) FEEC/UNICAMP

OMA: Componentes Application Domain Common Interfaces Interfaces Facilities Object Request Broker (ORB) Object Services (c) FEEC/UNICAMP

OMA: Object Request Broker O Object Request Broker (ORB) é um facilitador de comunicação entre objetos distribuídos. Funções típicas desempenhadas pelo ORB: transparência de comunicação (localização, conversão de dados, referência de objetos, etc.); gerência da execução de objetos servidores; manutenção de repositórios de servidores e suas interfaces; gerência de tipos específicos de dados (Any, NVList, etc.). (c) FEEC/UNICAMP

OMA: Serviços de Objetos São arquiteturas e interfaces para serviços de propósito geral tais como: nomes; eventos; propriedades; ciclo de vida; transações; persistência; externalização/ internalização; segurança; coleções. dentre muitos outros ... (c) FEEC/UNICAMP

OMA: Facilidades Comuns São interfaces (denominadas horizontais) para serviços orientados para aplicações-fim. Exemplos: agentes móveis; data interchange; interfaceamento com o usuário; gerenciamento da informação; gerenciamento de sistemas; gerenciamento de tarefas (workflow). (c) FEEC/UNICAMP

OMA: Interfaces Específicas do Domínio São interfaces (denominadas verticais) para serviços em domínios específicos. Exemplo: CORBA/TMN and CORBA/SNMP Interworking CORBA/Intelligent Networks Interworking Notification Service Control and Management of A/V Streams Telecom Log Service Wireless Access & Control (c) FEEC/UNICAMP

OMA: Interfaces de Aplicação São interfaces para os serviços específicos da aplicação. Estes serviços em geral utilizam os serviços de objetos, as facilidades comuns ou serviços específicos do domínio. Exemplo: uma aplicação de gerência de redes pode utilizar o serviço de eventos (serviço de objetos) e o Telecom Log Service (serviço específico do domínio). (c) FEEC/UNICAMP

A Arquitetura CORBA A Arquitetura CORBA (Common Object Request Broker Architecture) especifica um ORB para a Arquitetura de Referência OMA. Os demais elementos da OMA, quando implementados sobre CORBA são denominados CORBAservices (serviço de objetos) e CORBAfacilities (facilidades comuns). (c) FEEC/UNICAMP

CORBA: Características Estabelece uma arquitetura orientada a objetos; Separa a interface do serviço de sua implementação; Prevê uma vasta gama se serviços e funcionalidades; Permite a utilização de múltiplas linguagens de programação (C++, Java, Smalltalk, etc.); Previsão de vir embutido nos sistemas operacionais e linguagens de programação (Java 1.2). (c) FEEC/UNICAMP

CORBA: Arquitetura A Arquitetura CORBA é composta dos seguintes componentes básicos: ORB (Object Request Broker); Compilador IDL (Interface Definition Language); SII (Static Invocation Interface); DII (Dynamic Invocation Interface); BOA/POA (Basic/Portable Object Adaptor); Repositórios de Interfaces e de Implementação. (c) FEEC/UNICAMP

CORBA: Arquitetura servidor cliente DII ORB IDL skeleton ORB POA interface POA IDL stub DII ORB Repositório de Interfaces Repositório de Implementação (c) FEEC/UNICAMP

CORBA: Object Request Broker (ORB) É o componente básico de interconexão da Arquitetura CORBA, sendo responsável pelo encaminhamento de requisições de métodos para objetos remotos. O ORB provê independência de plataforma, localização e linguagem de implementação dos objetos comunicantes. Usualmente é implementado como um daemon que executa em todas as máquinas da rede. (c) FEEC/UNICAMP

CORBA: ORB cliente (Java) servidor (C++) ORB Windows NT Solaris (c) FEEC/UNICAMP

CORBA: Internet Inter-ORB Protocol (IIOP) Objetivo: Prover interoperabilidade entre ORBs de diferentes fornecedores. cliente ORB (IONA) servidor INTERNET (TCP/IP) IIOP ORB (IBM) (c) FEEC/UNICAMP

CORBA: Interface Definition Language (OMG IDL) Objetivo: especificar interfaces (métodos e atributos) de objetos. OMG IDL não é linguagem de programação; A especificação CORBA provê mapeamentos de IDL para linguagens orientadas e não orientadas a objetos (C, C++, Java, etc.). (c) FEEC/UNICAMP

OMG IDL: Compiladores Compiladores IDL traduzem as interfaces IDL em construções de uma linguagem alvo (Java, C++, etc.), bem como geram stubs e skeletons para clientes e servidores que utilizam e disponibilizam a interface. Dependendo da linguagem alvo, compiladores IDL podem gerar tambem código auxiliar para a manipulação de tipos e passagem de parâmetros. (c) FEEC/UNICAMP

IDL: Estrutura de uma Interface Módulo Definições (tipos complexos, exceções) Interface Atributos Operações Interface Atributos Operações (c) FEEC/UNICAMP

IDL: Tipos Básicos Ponto Flutuante: Outros Tipos: float (IEEE 32 bits) double (IEEE 32 bits) Inteiros: long: -231 ... +231 -1 unsigned long: 0 ... +232 -1 long long: -263 ... +263 -1 unsigned long long: 0 ... +264 short: -215 ... +215 -1 unsigned short: 0 ... +216 -1 Nota: IDL não define inteiros ! Outros Tipos: boolean: TRUE ou FALSE char: 8 bits (usualmente ASCII) octet: 8 bits (opaco) any: armazena qualquer tipo IDL (c) FEEC/UNICAMP

IDL: Tipos Complexos Enumerações: um conjunto de possíveis valores Exemplo: enum moeda {real, dolar, euro, peso}; moeda.real, moeda.dolar, moeda.iene Estruturas: um conjunto de tipos (básicos ou complexos) "empacotados". struct cliente { string nome; long idade; }; (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Uniões: contruções capazes de armazenar um tipo IDL dentre um conjunto de tipos declarados. Exemplo: enum formato {formatoString, formatoDigital}; struct DataStruct {    short dia;    short mes;    short ano; }; union Data switch (formato) {   case formatoString: string dataString;    case formatoDigital: long dataDigital;   default: DataStruct dataStruct; (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Strings: armazenam uma sequência de caracteres ASCII com tamanho máximo especificado (bounded) ou não (unbounded). Exemplos: string<30> cliente; // maximo 30 caracteres string cliente; // tamanho ilimitado (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Seqüências: armazenam uma seqüência de um mesmo tipo IDL com tamanho máximo especificado (bounded) ou não (unbounded). Exemplos: sequence<string, 10> nomes; // máximo 10 elementos sequence<string> nomes; sequence<DataStruct> vencimentos; (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Arrays: armazenam um mesmo tipo IDL em uma estrutura multi-dimensional. Exemplos: DataStruct vencimentos[16]; float Z[50][50]; (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Tipo Fixo: permite representar um número em duas partes: valor e escala (posição do ponto decimal). Exemplos: fixed<6,2> preco; // (-/+)9999.99 fixed<4,3> taxaDolar; // (-/+)9.999 (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Constantes: permite associar valores a um identificador. Exemplos: const float pi = 3.1415926535; const string palmeiras = "alviverde imponente"; (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Typedefs: permitem definir nomes para tipos complexos. Exemplos: typedef sequence<DataStruct> Datas; Datas vencimentos; typedef long integer; integer dataDigital; (c) FEEC/UNICAMP

IDL: Tipos Complexos (cont.) Tipo Any: permite armazenar um valor pertencente a qualquer tipo IDL (simples ou complexo), inclusive outro tipo any. O mapeamento de IDL para linguagens alvo deve prover mecanismos para: inserção de valores em tipos any; extração de valores armazenados em tipos any; inspeção do tipo armazenado. Nota: Tipos any são um remédio à imposibilidade de sobregarregar operações (métodos) em IDL. (c) FEEC/UNICAMP

IDL: Exceções Operações nas interfaces IDL podem lançar exceções. Exceções são declaradas em IDL da seguinte forma: exception <nome> { parâmetros }; Exemplos: exception operationFailed {        string reason; short errorCode;      exception noFunds {}; (c) FEEC/UNICAMP

IDL: Interfaces Interfaces são comumente definidas no escopo de um módulo (podem também estar desassociadas de um módulo). Interfaces são definidas em IDL da seguinte forma: interface <nome> { atributos operações }; Exemplo: interface Account { void deposit (in long amount); void withdraw(in long amount) raises {noFunds, operationFailed}; long balance(); (c) FEEC/UNICAMP

IDL: Atributos de Interfaces Atributos são variáveis associadas às interfaces (similares a atributos públicos de classes em OO). Atributos podem ser "readonly" ou "read-write", sendo definidos em IDL da seguinte forma: <readonly> attribute <nome>; Exemplo: interface Account { readonly attribute string customerName; readonly attribute sequence<octet> number; ... }; Nota: o compilador IDL gera métodos get e set para operação com atributos. (c) FEEC/UNICAMP

IDL: Operações Operações são definidas no escopo de uma interface IDL da seguinte forma: <tipo> <nome> (<indireção> <tipo> parâmetro, ...) raises {E1, ... En}; Exemplos: void withdraw(in long amount) raises {noFunds, operationFailed}; long balance(); Nota: IDL não permite a sobrecarga de operações (mesmo nome com diferentes assinaturas) ou operações com número de parâmetros variável. (c) FEEC/UNICAMP

IDL: Parâmetros de Operações Parâmetros de operações podem assumir qualquer tipo (básico ou complexo). A indireção do parâmetro é obrigatória e possui três modos: in: o parâmetro é de entrada, isto é, passado do cliente para o servidor. Seu valor permanece inalterado após o retorno da operação. out: o parâmetro é de saída, isto é, passado do servidor para o cliente. Seu valor comumente se altera após o retorno da operação. inout: o parâmetro é de entrada/saída, isto é, passado nos dois sentidos. Seu valor comumente se altera após o retorno da operação. Nota: parâmetros com valor NULL são proibidos ! (c) FEEC/UNICAMP

IDL: Retorno de Operações Operações podem retornar o tipo void ou qualquer tipo IDL (básico ou complexo). Operações em CORBA são sempre síncronas (mesmo retornando void). Operações assíncronas podem ser definidas com a palavra-chave oneway. Neste caso, devem retornar void e não definir exceções. Exemplo: oneway void deposit(); (c) FEEC/UNICAMP

IDL: Interfaces e Tipos Complexos Ao declarar uma interface em IDL, está-se declarando também um novo tipo complexo. Este tipo pode ser utilizado em parâmetros e retornos de operações. Exemplo: interface Account { ... }; interface AccountFactory { Account makeAccount(in string customerName, in sequence<octet> accountNumber); Nota: makeAccount retorna uma referência para um objeto distribuído que implementa a interface Account. (c) FEEC/UNICAMP

IDL: Definições Postergadas É comum referenciar uma interface antes da mesma ser definida. IDL permite postergar a definição de interface declarando-se apenas o seu nome. Exemplo: interface A; interface B { void op1 (in A p1, ...); ... }; interface A { void op2 (in B p1, ...); (c) FEEC/UNICAMP

IDL: Herança de Interfaces IDL permite herança simples e múltipla de interfaces. interface D : A,B,C { ... }; Exemplo: interface SavingAccount : Account { readonly attribute float interestRate; float computeInterest(); (c) FEEC/UNICAMP

Mapeamento IDL-Java IDL Java module package boolean boolean char char octet byte string java.lang.String short, unsigned short short long, unsigned long int long long, unsigned long long long float float double double fixed java.math.BigDecimal (c) FEEC/UNICAMP

Mapeamento IDL-Java IDL Java enum, struct, union class sequence, array array interface interface, helper & holder classes constant (fora de uma interface) public interface constant (em uma interface) fields na interface Java exception class any org.omg.CORBA.Any typedef helper classes readonly attribute accessor method readwrite attribute accessor and modifer methods operação método (c) FEEC/UNICAMP

Parâmetros out e inout em Java Em linguagens que suportam ponteiros (como C++), parâmetros out e inout são passados por referência quando mapeados para a linguagem alvo. Em Java, todo parâmetro possui uma classe Holder associada. O pacote org.omg.CORBA define as classes holder para os tipos básicos, enquanto o compilador IDL gera as classes holder para os tipos complexos. Portanto: para um tipo qualquer X existe a classe XHolder; a classes XHolder possui um atributo público do tipo X denominado value; este atributo contém o valor a ser passado para o servidor (inout), bem como tem o seu valor alterado no retorno da operação. (c) FEEC/UNICAMP

Parâmetros out e inout em Java (cont.) Exemplo: // IDL interface Account { ... void withdraw(inout long amount); }; // Java public interface AccountOperations { void withdraw(intHolder amount); // Java intHolder amt = new IntHolder(); amt.value = 10000; acc.withdraw(amt); System.out.println("Amount: " + amt.value); (c) FEEC/UNICAMP

Classes Helper Tal como classes holder, cada tipo IDL X possui uma classe XHelper associada quando mapeado para Java. Classes helper oferecem três funcionalidades (via métodos estáticos): inserção do tipo em um tipo any: void insert(org.omg.CORBA.Any a, X that); extração do tipo armazenado em um tipo any: X extract(org.omg.CORBA.Any a); criação de stubs a partir da referência do objeto remoto: X narrow(org.omg.CORBA.Object obj); (c) FEEC/UNICAMP

Mapeamento IDL-Java: Exemplo Account.idl Compilador IDL Interface AccountOperations class AccountHolder class _AccountStub Interface Account class AccountHelper class AccountPOA (c) FEEC/UNICAMP

Exemplo: Account.idl interface Account { exception LimitExceeded{string reason;}; void deposit( in long long arg0 ); void withdraw( in long long arg0 ) raises (LimitExceeded); long long balance( ); }; (c) FEEC/UNICAMP

Exemplo: AccountOpeations.java public interface AccountOperations { void deposit (long arg0); void withdraw (long arg0) throws AccountPackage.LimitExceeded; long balance (); } // interface AccountOperations (c) FEEC/UNICAMP

Exemplo: Account.java public interface Account extends AccountOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { } (c) FEEC/UNICAMP

Exemplo: AccountHolder.java public final class AccountHolder implements org.omg.CORBA.portable.Streamable { public Account value = null; public AccountHolder () {} public AccountHolder (Account initialValue) value = initialValue; } ... (c) FEEC/UNICAMP

Exemplo: AccountHelper.java abstract public class AccountHelper { private static String _id = "IDL:Account:1.0" public static void insert (org.omg.CORBA.Any a, Account that) { ... } public static Account extract (org.omg.CORBA.Any a) public static Account narrow (org.omg.CORBA.Object obj) { .... } public static String id () { return _id;} } (c) FEEC/UNICAMP

Exemplo LimitExceeded.java package AccountPackage; public final class LimitExceeded extends org.omg.CORBA.UserException { public String reason = null; public LimitExceeded () super(LimitExceededHelper.id()); } // ctor public LimitExceeded (String _reason) reason = _reason; (c) FEEC/UNICAMP

IDL: Passagem de Objetos por Valor CORBA, por ser um padrão neutro, não suporta passagem de objetos nas invocações de métodos remotos. Recentemente, o OMG introduziu o padrão denominado "Objeto por Valor" (Object by Value - OBV). OBV permite: definir um objeto em IDL (estado + métodos); utilizar este objeto como parâmetro ou retorno de invocações, passando-o por valor. (c) FEEC/UNICAMP

IDL: OBV Mas: e se o cliente e servidor forem escritos em diferentes linguagens de programação (que eventualmente não suportam o conceito de objeto, como C, Fortran, etc.) ? como objetos são serializados / de-serializados ? Resposta: O padrão OBV permite apenas transferir o estado do objeto (similar a uma IDL struct) em uma invocação. Os métodos devem ser implementados localmente, tanto no lado cliente quanto no lado servidor, em suas respectivas linguagens de programação. (c) FEEC/UNICAMP

IDL: OBV (cont.) valuetype Compilador IDL classes Helper, Holder estado métodos construtor Objeto Java Compilador IDL Value Factory Default Factory Implementação do Objeto (c) FEEC/UNICAMP

IDL: Valuetypes // "objeto" a ser passado por valor valuetype Empregado { // definicao do estado public string nome; public string cargo; public float idade; public long salario; // metodos - pode haver varios long computaSalario(); // construtor factory init(in string n, in string c, in float i); }; (c) FEEC/UNICAMP

IDL: Uso de Valuetypes // interface que utiliza o "objeto" interface RH Empregado obtemEmpregado(in string nome); void adicionaEmpregado(in Empregado emp); void removeEmpregado(in Empregado emp); }; (c) FEEC/UNICAMP

IDL: Implementação de Valuetypes import org.omg.CORBA.*; public class EmpregadoImpl extends Empregado { // construtores // conforme definido na IDL (facory init) public EmpregadoImpl(String n, String c, float i) { this.nome = new String(n); this.cargo = new String(c); this.idade = i; this.salario = computaSalario(); // <<< operacao local } (c) FEEC/UNICAMP

IDL: Implementação de Valuetypes (cont.) // construtor vazio tambem é necessario public EmpregadoImpl() { this.nome = new String(""); this.cargo = new String(""); this.idade = 0; this.salario = 0; } public int computaSalario () { if(cargo.equals("gerente")) return(8000); return(3000); (c) FEEC/UNICAMP

IDL: Valuetypes - lado cliente // creia fabrica de Empregados (local) EmpregadoDefaultFactory fact = new EmpregadoDefaultFactory(); Empregado e = fact.init("Jose", "gerente", (float)43.0); rh.adicionaEmpregado(e); Empregado e1 = rh.obtemEmpregado("Joao"); System.out.println("Empregado obtido: " + e1.nome + " - cargo: " + e1.cargo + " - idade: " + e1.idade); System.out.println("O salario de " + e1.nome + " e' " + e1.computaSalario()); // <<< chamada local !! (c) FEEC/UNICAMP

IDL: Valutypes - lado servidor import org.omg.CORBA.*; import java.util.*; public class RHServant extends RHPOA implements RHOperations { EmpregadoDefaultFactory the_factory = null; Hashtable empregados = null; float massaSalarial = 0; public RHServant() { // cria fabrica e hashtable the_factory = new EmpregadoDefaultFactory(); empregados = new Hashtable(); } (c) FEEC/UNICAMP

IDL: Valutypes - lado servidor (cont.) public Empregado obtemEmpregado (String nome) { Empregado e = (Empregado)empregados.get(nome); if(e == null) e = the_factory.init("", "", (float)0.0); return e; } public void adicionaEmpregado (Empregado emp) { Empregado e = the_factory.init(emp.nome, emp.cargo, emp.idade); massaSalarial += emp.computaSalario(); // <<< chamada local ! empregados.put(emp.nome, e); public void removeEmpregado (Empregado emp) { if(empregados.remove(emp.nome) != null) massaSalarial -= emp.computaSalario(); // <<< chamada local ! (c) FEEC/UNICAMP

CORBA: Basic Object Adapter (BOA) Objetivo: instanciar (criar) servidores e controlar a execução de métodos. O BOA identifica o código dos objetos servidores interagindo com o Repositório de Implementação. Usualmente, o BOA provê três tipos de instanciação de servidores: compartilhada; não compartilhada; por método. (c) FEEC/UNICAMP

CORBA: BOA M1 M2 M3 método processo compartilhada não compartilhada por método método processo M1 M2 M3 (c) FEEC/UNICAMP

CORBA: BOA A tendência é utilizar a instanciação por processo e servidores multitheaded (para cada evocação o servidor cria uma thread para processá-la). O BOA implementa também funções elementares de segurança (Ex: verificação se um cliente possui permissão para instanciar um servidor) via atributos do sistema de arquivos. Pode-se implementar diferentes adaptadores de objetos em prejuizo da portabilidade. (c) FEEC/UNICAMP

Adaptador de Objeto Portável (POA) POA (Portable Object Adapter) é uma parte importante da arquitetura CORBA que trata do controle dos objetos que implementam interfaces remotas (objetos servants). POA vem eliminar muitas das deficiências do BOA (Basic Object Adapter), principalmente sua dependência de implemen-tação. POA permite esquemas flexíveis de controle através da combinação de políticas de controle do POA com diferentes modos de ativação de objetos servants. (c) FEEC/UNICAMP

POA: Stubs e Skeletons Portáveis cliente servant value = gridRef.get(x,y) result = get(n, m) result = get(n, m) skeleton in out (_ImplBase) stub in (_Stub) out invoke in = invoke(out) out = invoke(”get”,in) get n m invoke IIOP result ORB ORB (c) FEEC/UNICAMP

POA: Arquitetura POA Raiz POA P1 POA P2 POA P3 POA Raiz é obtido através do método resolve_initial_references("RootPOA") disponibilizado pelo ORB. POA P1 POA P2 Um POA é sempre criado a partir de um POA pai (exceto o Root POA) através do método create_POA invocado no POA pai. POA P3 (c) FEEC/UNICAMP

POA: Arquitetura Servidor CORBA POA Manager (default) Servant Manager Mapa de Objetos Ativos Object ID Servant Manager (implementações) Servants (default) Políticas POA Manager Servidor CORBA código suprido pelo desenvolvedor Definidas pelo desenvolvedor (c) FEEC/UNICAMP

POA: Operação Típica (c) FEEC/UNICAMP

POA: Políticas POA define 7 políticas: Atribuição de OIDs: USER_ID; SYSTEM_ID (default) Retenção de Servants: RETAIN (servants são retidos no mapa de objetos ativos); NON_RETAIN (não existe mapa de objetos ativos). Processamento de Requisição: USE_ACTIVE_OBJECT_MAP_ONLY (default); USE_DEFAULT_SERVANT; USE_SERVANT_MANAGER. Ativação Implícita: IMPLICIT_ACTIVATION (default) - atribui um OID e o adiciona no mapa de objetos ativos quando necessário (não ativa o servant !); NO_IMPLICIT_ACTIVATION. (c) FEEC/UNICAMP

POA: Políticas (cont.) Unicidade de OIDs: UNIQUE_ID (default) - cada servant possui um único ID; MULTIPLE_ID - um servant pode possui mais de um ID. Tempo de Vida: TRANSIENT (default) - referências atribuidas por um POA se tornam inválidas quando o POA que as atribuiu é desativado; PERSISTENT - referências sobrevivem à desativação do POA (neste caso, a referência de objeto (IOR) que abriga o OID deve "apontar" para o daemon de ativação do ORB e não para o POA que a criou). (c) FEEC/UNICAMP

POA: Políticas (cont.) Política de Thread: ORB_CTRL_THREAD (default) - o POA mantém um pool de threads para atender as requisições; SINGLE_THREAD_MODEL - o pool possui apenas 1 thread; MAIN_THREAD_MODEL - não há threads, exceto a thread "main". (c) FEEC/UNICAMP

POA: Gerenciador de Servants Existem dois tipos de gerenciador de servants (servant manager) cuja utilização pelo POA se dá através da política USE_SERVANT_MANAGER: Ativador de Servants (Servant Activator): utilizado em conjunto com a política RETAIN, disponibiliza ao POA um método que retorna um servant ativado dado um OID. O POA invoca esta operação quando o OID não está presente no mapa de objetos ativos; Localizador de Servants (Servant Locator): utilizado em conjunto com a política NON_RETAIN, disponibiliza ao POA um método que retorna um servant ativado dado um OID. O POA invoca esta operação para cada requisição que recebe do ORB. (c) FEEC/UNICAMP

POA: Gerenciador de POA O Gerenciador de POA (POA Manager) disponibiliza um conjunto de métodos que permite colocar o POA um um dos quatro estados abaixo: espera: suspende temporariamente o processamento das requisições, enfileirando-as; ativo: processa normalmente as requisições; descarte: descarta requisições; inativo: estado pré-destruição (completa processamento das requisições pendentes e descarta novas requisições). (c) FEEC/UNICAMP

POA: Indentificadores de Objeto (OID) OIDs podem ser atribuidos pelo POA (mais comum) ou pela aplicação. OIDs é uma sequência de bytes presente no IOR que identifica o servant. IORs são criados pelo POA via métodos create_reference (POA atribui OID) ou create_reference_with_id (aplicação atribui OID). Quando atribuído pela aplicação, em geral o OID é uma chave de acesso para o estado do servant armazenado em uma base de dados. Isto permite a criação de servidores persistentes. (c) FEEC/UNICAMP

CORBA: Static Invocation Interface (SII) SII é a forma mais simples do cliente invocar um método num servidor. SII requer que todas as interfaces de servidores sejam conhecidas em tempo de compilação (portanto, SII é type-safe). (c) FEEC/UNICAMP

CORBA: SII cliente servidor proxy POA ORB IDL stub IDL skeleton (c) FEEC/UNICAMP

CORBA: Dynamic Invocation Interface (DII) DII é um conjunto de serviços que permitem a clientes: Verificar a existência de interfaces no Repositório de Interfaces; Descobrir os parâmetros (tipos) e métodos (protótipos) de determinada interface; Preparar passo-a-passo uma evocação para um servidor que implementa esta interface. (c) FEEC/UNICAMP

CORBA: DSI DSI (Dynamic Skeleton Interface) é equivalente ao DII para o lado servidor. DSI permite a um servidor inspecionar uma invocação antes de seu processamento, obtendo o nome do método e respectivos parâmetros. DSI permite também ao servidor retornar um valor para o cliente. Nota: O uso de DII no lado cliente não implica no uso de DSI no lado servidor e vice-versa. (c) FEEC/UNICAMP

CORBA: Repositórios de Interfaces e Implementação Objetivo: armazenar de forma persistente as interfaces IDL e as implementações de servidores. Estes repositórios podem ser implementados diretamente no sistema de arquivo nativo do sistema operacional ou através de uma base de dados (relacional ou OO). As implementações CORBA provêem aplicativos para a manutenção destes repositórios. (c) FEEC/UNICAMP

CORBA: CORBAservices CORBAservices define arquiteturas e interfaces (não implementações !) para os seguintes serviços: nomes (diretório); eventos; ciclo de vida; segurança; transações; time; persistência; dentre muitos outros ! (c) FEEC/UNICAMP

CORBAservices: Nomes O serviço de nomes especifica interfaces IDL para: criar contextos para definições de nomes; associar (bind) um nome a um objeto (usualmente um servant); pesquisar um nome (e obter o objeto associado); navegar pelo diretório de nomes. servant CORBA interfaces IDL do serviço servidor de nomes diretório de nomes (persistente ou transiente) (c) FEEC/UNICAMP

CORBAServices: Ciclo de Vida O serviço de propriedades proporciona operações que permitem criar, destruir, copiar objetos. GenericFactory FactoryFinder find_factories create_object servant CORBA copy move remove LifeCycleObject encontra CORBA.Object obj = GenericFactory.CreateObject(pars); cria (c) FEEC/UNICAMP

CORBAServices: Propriedades O serviço de propriedades proporciona operações que permitem definir pares atributo-valor (propriedades) e associa-los a qualquer entidade da aplicação. create_propertyset create_initial_propertyset create_constrained_propertyset servant CORBA PropertySetFactory define_property get_property delete_property ...... servant CORBA PropertySet servidor de propriedades (c) FEEC/UNICAMP

CORBAServices: Eventos O serviço de eventos prove um mecanismo de notificação segundo os modelos push e pull. obtain_push_consumer obtain_push_supplier connect_push_consumer connect_push_supplier disconnect_push_supplier push push evento push supplier canal de eventos push consumers servidor de eventos (c) FEEC/UNICAMP

CORBAServices: Object Transaction Service OTS (Object Transaction Service) implementa um serviço de transações aberto baseado no protocolo 2-phase commit. interfaces IDL do serviço - begin - commit - abort, ... base de dados (Oracle, Sybase, etc.) servant CORBA interface XA (X/Open) servidor OTS permite a integração com produtos que implementam esta interface (c) FEEC/UNICAMP

CORBAservices: Trader Trader, conceito introduzido no modelo ODP, foi padronizado pelo OMG. Trader é um serviço de nomes mais sofisticado que permite clientes encontrar servidores que melhor atendam suas necessidades. Cenário típico de utilização do trader é dado abaixo. cliente CORBA servidor CORBA Trader 4 2 3 1 ORB 1. exporta capacidades do servidor (desempenho, custo, etc.) 2. importa requisitos (desempenho mínimo, custo máximo, etc.) 3. retorna IOR do servidor 4. interage com o servidor (provavelmente via DII) (c) FEEC/UNICAMP

CORBA: Produtos ORBIX (IONA Technologies Ltd.) VisiBroker (Borland) ORBacus (Object Oriented Concepts / IONA) CORBAplus (Expersoft) Nouveau (Rogue Wave) vários outros ... Implementações robustas de domínio público: Java IDL (parte da plataforma Java 2), MICO (C++), JacORB (Java), TAO (C++). (c) FEEC/UNICAMP

CORBA: Produtos Muitos produtos em diferentes domínios possuem implementações CORBA embutidas para fins de interoperabilidade com outros produtos compatível com CORBA. Exemplos: Plataforma Jambala (Ericsson): utilizada em telefonia celular; OpenView (HP): produto para gerência de redes e TMN; Jaguar (Sybase): middleware para OLTP. (c) FEEC/UNICAMP

CORBA: Produtos Produtos CORBA tradicionais como ORBIX e VisiBroker foram incorporados em Plataformas de Desenvolvimento (Application Server Platforms). Estas plataformas, além de permitirem desenvolvimento em CORBA, suportam ainda desenvolvimento em J2EE/EJB, .NET, XML/SOAP, etc., bem como alguma interoperabilidade entre estas tecnologias. (c) FEEC/UNICAMP

ORBIX Orbix, da Iona Technologies, é uma família de produtos CORBA. Orbix possui compiladores IDL para várias linguagens de programação, bem como ORBs para uma grande variedade de plataformas. Por exemplo, é possível desenvolver um servidor CORBA em COBOL e executá-lo em mainframe IBM OS/390. (c) FEEC/UNICAMP

ORBIX: Disponibilidade Orbix possui versões para desenvolvimento em C, C++, Java, COBOL, PL/1, VB para as seguintes plataformas: Microsoft Windows NT/2000/XP; Sun Solaris; Linux; HP-UX Silicon Graphics IRIX; IBM AIX; IBM OS/390 Mainframe; Digital/Compaq OpenVMS. (c) FEEC/UNICAMP

ORBIX: Compilador IDL parser IDL gerador de código utilitários stubs, skeletons, server template compilador IDL parser IDL gerador de código árvore de parsing arquivo IDL utilitários Code Generation Toolkit aplicação-exemplo conversão IDL - HTML etc. (c) FEEC/UNICAMP

ORBIX: ORB No Orbix o Object Request Broker (ORB) consiste de dois componentes: 1. Uma interface de programação (API) que provê funções relativas ao ORB para clientes e servidores tais como binding, DII (cliente); iniciação de servidores, DSI (servidor); 2. Um daemon (orbixd) que executa em cada máquina da rede e gerencia o repositório de implementação e ativação de servidores. (c) FEEC/UNICAMP

ORBIX: ORB ORB ORB (lib) (lib) ORBIX daemon (orbixd) busca de servidor ORBIX daemon (orbixd) Rep. Impl. instancia servidor código da aplicação (cliente) código da aplicação (servidor) API API código do stub (gerado pelo compilador IDL) código do skeleton (gerado pelo compilador IDL) ORB (lib) ORB (lib) requisição IIOP (c) FEEC/UNICAMP

ORBIX: ORB Orbix ORB possui as seguintes características básicas: suporte para DII (Dynamic Invocation Interface); suporte para BOA e POA (Basic/Portable Object Adapter); suporte para DSI (Dynamic Skeleton Interface). Orbix ORB provê ainda uma interface para operações de manipulação de typos (Any, NVList, ...), disponibilização de servidores, busca de serviços disponíveis (nomes, eventos, ...), dentre muitas outras. (c) FEEC/UNICAMP

ORBIX: Repositórios Orbix dispõe de repositórios de interface e de implementação com a seguinte arquitetura: repositório registros putit catit lstit rmit ... utilitários de manutenção e gerência sistema de arquivos nativo da máquina (c) FEEC/UNICAMP

ORBIX: Integração com MS-COM ORBIX permite que servidores CORBA se apresentem a clientes como objetos COM (Component Object Model - padrão Microsoft). COM Bridge servidor CORBA cliente COM IIOP provê mapeamento bidirecional entre MIDL e OMG IDL repositório de tipos (COM) repositório de interfaces (CORBA) OBS: MIDL (Microsoft IDL) define tipos COM (c) FEEC/UNICAMP

ORBIX: Serviços CORBA Orbix implementa os seguintes serviços CORBA: serviço de nomes; serviço de transações; serviço de trading; serviço de eventos; serviço de notificação. (c) FEEC/UNICAMP

VisiBroker VisiBroker tem sua origem no ORBeline, produto da PostModern que em 1996 fundiu-se com a Visigenic, mudando o nome do produto para VisiBroker. A Visigenic foi adquirida pela Borland que manteve o nome do produto, hoje na versão 4. VisiBroker foi o primeiro ORB a ter uma versão total-mente escrita em Java. Atualmente, VisiBroker está incorporado no produto Borland Enterprise Server. (c) FEEC/UNICAMP

VisiBroker: Disponibilidade VisiBroker possui versões para desenvolvimento em C++ e Java para as seguintes plataformas: Microsoft Windows ; Sun Solaris; Linux; HP-UX; IBM AIX; Digital/Compaq UNIX; Silicon Graphics IRIX; IBM OS/390 Mainframe. (c) FEEC/UNICAMP

VisiBroker: Características VisiBroker possui as seguintes características básicas: repositórios de interface e implementação; suporte para DII (Dynamic Invocation Interface); suporte para BOA e POA (Basic/Portable Object Adapter); suporte para DSI (Dynamic Skeleton Interface); suporte a multithreading (vários modelos de threading); suporte a Object-by-Value (OBV); Filtros (Interceptors). (c) FEEC/UNICAMP

VisiBroker X Orbix VisiBroker é muito similar ao Orbix, sendo talvez o seu maior concorrente. Algumas diferenças: possui dois daemons: SmartAgent e OAD (Object Activation Daemon): SmartAgent: provê serviços de nome e diretório que permite localizar OADs. A localização pode levar em conta balanceamento de carga e tolerância a falhas; OAD: utilizado para instanciar servidores (similar ao orbixd). serviço de nomes e eventos (OMG) incorporados. (c) FEEC/UNICAMP

VisiBroker: SmartAgent & OAD Serviço Distribuído de Nomes + Diretório SmartAgent SmartAgent SmartAgent Algoritmos de Bal. de carga Tol. a Falhas 1. consulta 2. encontra servidor 3. retorna ref. OAD OAD 6. inst. servidor OAD cliente 4. bind 5. acessa impl. Rep. Impl. Rep. Impl. (c) FEEC/UNICAMP

VisiBroker: Componentes Adicionais A Imprise oferece os seguintes componentes adicionais para o VisiBroker: VisiSecure: serviço de segurança do OMG; VisiTransact: serviço de transação do OMG; VisiNotify: serviço de notoficação do OMG. adicionalmente, os seguintes CORBAservices são oferecidos pela Prism Technologies para o VisiBroker: Trading, Notification, LifeCycle, Property, Collection, Concurrency, Relationship, e Time Services. (c) FEEC/UNICAMP

Java IDL A plataforma Java dispõe de uma implementação CORBA denominada Java IDL. Esta implementação, compatível com a versão CORBA 2.3, vem sendo aprimorada desde a sua introdução na versão 1.2 e dispõe atualmente de: um compilador idl (idlj); um conjunto de pacotes (org.omg.CORBA, ...); um daemon de ativação / servidor de nomes (orbd); um aplicativo para registro de servidores no repositório de implementação (servertool). (c) FEEC/UNICAMP

Java IDL Java IDL suporta: Adaptador de Objeto Portável (POA); servidores persistentes; passagem de objeto por valor (Object by Value); Intercerceptadores Portáveis (suporte parcial). Java IDL não suporta: segurança (IIOP/SSL, por exemplo); repositório de interfaces; passagem de contexto nas invocações (Current); outros serviços CORBA. (c) FEEC/UNICAMP

CORBA x DCE A favor do DCE: Os padrão DCE está estacionado, enquanto CORBA está em constante evolução; Implementações DCE interoperam por princípio; DCE trata segurança em todos os níveis; DCE IDL suporta ponteiros e parâmetros de tamanho arbitrário (pipes); DCE suporta o conceito de versão (de servidores). (c) FEEC/UNICAMP

CORBA x DCE A favor do CORBA: CORBA é orientado a objeto (enquanto DCE é orientado a procedimento); OMG IDL permite herança e tipo any, além de mapear para várias linguagens de programação; CORBA permite late-binding via DII; CORBA especifica uma vasta gama de serviços (poucos destes disponíveis atualmente !); CORBA define repositórios de interfaces e implemenação; CORBA vem despertando mais interesse que o DCE. (c) FEEC/UNICAMP

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 de interoperabilidade. (c) FEEC/UNICAMP

Novos Desenvolvimentos em CORBA A utilização de CORBA em novos desenvolvimentos se justifica devido a: ampla aceitação por parte da indústria; maturidade dos produtos CORBA disponíveis no mercado; neutralidade em termos de plataformas e linguagens de programação; simplicidade de uso quando comparado a outras tecnologias (ex: DCOM e DCE); integração natural com tecnologias relacionadas à Internet (applets, browsers, etc.). (c) FEEC/UNICAMP

Integração via CORBA CORBA é uma tecnologia adequada para a integração de sistemas “legados” (exemplo: controle de estoques desen-volvido em COBOL para IBM OS/390 utilizando DB2). Nestes casos, a interação com o sistema legado pode se dar através de um wrapper dividido em duas partes: 1. parte responsável pela interação com um ORB, por exemplo, através de stub gerado por compilador IDL; 2. parte responsável pela interação com o sistema legado através de, por exemplo, interfaces de programação (APIs). (c) FEEC/UNICAMP

Integração via CORBA Exemplo: ORB #2 ORB #3 ORB #1 Sistema Legado #1 (COBOL / OS/390) Sistema Legado #2 (C++ / UNIX) Sistema Legado #3 (V.Basic / Windows) wrapper #1 wrapper #2 wrapper #3 IDL > COBOL IDL > C++ COM-CORBA bridge ORB #2 ORB #3 ORB #1 IIOP (c) FEEC/UNICAMP

Hooks CORBA de Interoperabilidade ORB interno ao produto Produto Extensão ao Produto IDL “exportada” pelo produto IIOP ORB Comercial Hook CORBA de Interoperabilidade Hooks CORBA de interoperabilidade permitem adicionar funcionalidades externas a produtos. Exemplos: Plataforma Jambala para telefonia celular (Ericsson) Sistema de gerência de redes OpenView (HP) (c) FEEC/UNICAMP

Gateways de Interoperabilidade Gateways permitem sistemas baseados em CORBA interoperarem com sistemas baseados em outras arquiteturas e protocolos. Exemplo: SNMP Gateway IDL - SNMP Gerente CORBA Agente SNMP IIOP ORB ORB Comercial Domínio de Gerência SNMP IDL “exportada” pelo gateway Domínio de Gerência CORBA (c) FEEC/UNICAMP

Microsoft DCOM DCOM (Distributed Component Object Model) é uma generalização da tecnologia COM (ex-OLE) desenvolvida pela Microsoft para o “mundo Windows”. Portanto, OLE/COM/DCOM são soluções “fechadas”. COM permite a comunicação entre aplicativos executando no mesmo processador. Portanto, COM é um mecanismo de comunicação inter-processos (IPC). DCOM estende COM permitindo a comunicação entre aplicativos executando em diferentes processadores. Portanto, DCOM é um middleware. Atualmente, DCOM está integrado nas plataformas COM+ e .NET. (c) FEEC/UNICAMP

Microsoft DCOM servidor DCOM servidor COM IPC RPC rede cliente COM cliente DCOM cliente e servidor em diferentes (processos) mas no mesmo processador cliente e servidor em diferentes processadores (c) FEEC/UNICAMP

Microsoft DCOM COM é neutro em termos de linguagem de programação. Por exemplo, um cliente escrito em Visual Basic pode interagir com um servidor escrito em C++. Para permitir esta neutralidade uma linguagem de definição de interfaces foi definida pela Microsoft: MIDL (Microsoft Interface Definition Language). DCOM procura minimizar as diferenças em relação ao COM (transparência de distribuição), escondendo do desenvolvedor o fato de clientes e servidores estarem em processadores distintos. DCOM utiliza um mecanismo de RPC (derivado do DCE !) para suporte à comunicação cliente/servidor. (c) FEEC/UNICAMP

protocolos de rede (TCP/IP) DCOM: Arquitetura SCM segurança DCE RPC protocolos de rede (TCP/IP) hardware rede instancia proxy stub cliente DCOM servidor DCOM cria instância (de servidor) SCM: Service Control Manager (parte do Windows) (c) FEEC/UNICAMP

DCOM: Objetos COM/DCOM classe (coclass) interface lib Objetos COM/DCOM derivam de uma classe base (coclass), definem uma interface com detrminado número de métodos, e podem ser agregados numa biblioteca (lib). O objeto, sua interface e a lib a qual pertence são individidual- e globalmente identificados por um UUID (ou GUID) (Universally/Globally Unique IDentifier), uma sequência de 128 bits gerada por um aplicativo denominado guidgen. guidgen leva em conta a data, hora, host ID, etc. para gerar um GUID. (c) FEEC/UNICAMP

DCOM: MIDL import "oaidl.idl"; import "ocidl.idl"; [object, uuid(3C6E0346-479C-11D4-96B9-0090272BDBDA), dual helpstring("IAccountComObject Interface"), pointer_default(unique)] interface IAccountComObject : IDispatch { HRESULT deposit([in] unsigned long amount); HRESULT withdraw([in] unsigned long amount); HRESULT balance([out, retval] long *amount);}; [uuid(3C6E0339-479C-11D4-96B9-0090272BDBDA), version(1.0), helpstring("Account 1.0 Type Library")] library ACCOUNTLib { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [uuid(3C6E0347-479C-11D4-96B9-0090272BDBDA), helpstring("AccountComObject Class")] coclass AccountComObject { [default] interface IAccountComObject; }; }; (c) FEEC/UNICAMP

DCOM: Desenvolvimento Desenvolver aplicações distribuídas em DCOM exige: experiência com o “mundo Windows”, principalmente com a tecnologia COM/COM+; um ambiente de desenvolvimento que contenha gerador de GUID (guidgen), compilador MIDL (midl), compilador da linguagem alvo, etc. Os ambientes Microsoft Visual C++, Basic e J++ contém estes aplicativos. Nos ambientes Microsoft, clientes e servidores COM/DCOM são desenvolvidos a partir de um wizard (ATL COM AppWizard). (c) FEEC/UNICAMP

DCOM: Servidores Servidores DCOM podem ser instanciados de duas maneiras: por demanda, quando uma requisição para um objeto for gerada por um cliente; de forma persistente, como um serviço do sistema operacional (Windows-NT apenas); NOTA: o Register do Windows é empregado para mapear classes de objetos e suas interfaces (através de seus GUIDs) em servidores (programas executáveis). Funciona, portanto, como o repositório de implementação do CORBA. NOTA: o SCM do Windows funciona para o DCOM como os daemons de ativação do CORBA (orbixd, OAD). (c) FEEC/UNICAMP

CORBA x DCOM A favor do CORBA: CORBA é uma arquitetura aberta, independente de plataforma ou fornecedor; CORBA é mais aceito por fornecedores de software; desenvolvimento em CORBA é mais simples que em DCOM; CORBA se integra melhor com Java/Internet que DCOM; CORBA é um middleware mais completo que DCOM; CORBA permite late-binding via DII; mercado de produtos CORBA bem superior ao mercado de produtos DCOM; CORBA também opera em ambientes Windows. (c) FEEC/UNICAMP

CORBA x DCOM A favor do DCOM: força de mercado da Microsoft; perfeitamente integrado ao “mundo Windows”; estende COM, uma tecnologia bem conhecida pelos desenvolvedores para Windows; integrado aos ambientes de desenvolvimento Microsoft (Visual xxx); utiliza elementos já disponíveis no Windows (Register, SCM, segurança, etc.). (c) FEEC/UNICAMP