Introdução aos Sistemas Distribuídos

INTRODUÇÃO ÀS PLATAFORMAS DISTRIBUÍDAS Eleri Cardozo FEEC/UNICAMP http://www.fee.unicamp.br/~eleri Introdução aos Sistemas Distribuídos Julho de 2002 (c) FEEC/UNICAMP 1 (c) FEEC/UNICAMP 2 Sistemas Distribuídos: Definição Sistemas Abertos 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. 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 3 (c) FEEC/UNICAMP 4 Sistemas Abertos: Uma Classificação Modelos de Referência 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. 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 5 (c) FEEC/UNICAMP 6

Arquiteturas de Referência Arquiteturas 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. Uma arquitetura é similar a um modelo ou arquitetura de referência, mas prescreve protocolos de interoperabilidade 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 7 (c) FEEC/UNICAMP 8 Implementações de Referência Exemplo de Padrão Aberto: CORBA 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 implementações de sistemas abertos. O modelo de referência OMA. Objetos de Aplicação CORBA Facilities (vertical) Object Request Broker (ORB) Serviços CORBA (CORBAservices) CORBA Facilities (horizontal) 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 9 (c) FEEC/UNICAMP 10 Exemplo de Padrão Aberto: CORBA Sistemas Abertos: Conclusão 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. 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 11 (c) FEEC/UNICAMP 12

O Conceito de Middleware Visão a Partir do Modelo OSI O Conceito de Middleware OPA! Isto eu conheço!!! APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO (c) FEEC/UNICAMP 13 (c) FEEC/UNICAMP 14 Conceito de Middleware e o Modelo OSI Telecomunicações Finanças Medicina APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO (c) FEEC/UNICAMP 15 Agente Conceito de Middleware e o Modelo OSI Cliente Ex: funções típicas de telecomunicações APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO Agente Gerenciamento de Rede Domínio de aplicação 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 16 Conceito de Middleware e o Modelo OSI Conceito de Middleware e o Modelo OSI Domínio da aplicação APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO 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 Domínio da aplicação APLICAÇÃO APRESENTAÇÃO SESSÃO TRANSPORTE REDE ENLACE FÍSICO MIDDLEWARE (c) FEEC/UNICAMP 17 (c) FEEC/UNICAMP 18

Conceito de Middleware e o Modelo OSI Evolução em Middleware Domínio da aplicação APLICAÇÃO APRESENTAÇÃO SESSÃO Sistema Operacional + Hardware Sistemas Necessidade de Padronização do Middleware Heterogêneos! troca de mensagens 1977 1982 chamada de procedimento remoto (RPC) objetos distribuídos agentes componentes 1987 1992 1997 2002 2007 (c) FEEC/UNICAMP 19 (c) FEEC/UNICAMP 20 Evolução do Conceito de Middleware Troca de Mensagens (primitivas SEND/RECEIVE) Troca de Mensagens: Semântica Aplicação Aplicação Send Receive TLI CPC-I Socket Named Pipes SNA TCP/IP IPX/SPX NetBIOS API independente do transporte Pilhas de Transporte send(m1) tarefa 1 tarefa 2 receive(m2) tarefa 1 tarefa 2 send(m1) receive(m1) receive(m2) NDIS... ODI Drivers de Rede Placas de Rede bloqueio send(m2) Token-ring Ethernet ISDN (c) FEEC/UNICAMP 21 (c) FEEC/UNICAMP 22 Troca de Mensagens: Implementação Evolução do Conceito de Middleware Chamada Remota de Procedimento (RPC) Aplicação Aplicação 2- Call ( ) 1- Register ( ) 3- Call ( ) API (socket) espaço do usuário espaço do núcleo port (endpoint) buffer API (socket) Remote Procedure Call (RPC) TLI CPC-I Socket Named Pipes SNA TCP/IP IPX/SPX NetBIOS sistema de transporte (TCP/IP) LAN / WAN sistema de transporte (TCP/IP) NDIS ODI (c) FEEC/UNICAMP 23 Token-ring Ethernet ISDN (c) FEEC/UNICAMP 24

RPC: Semântica RPC: Implementação cliente call P2(a1,a2) retorno servidor P1 P2 P3 cliente servidor call P2(a1,a2) bloqueio P2 executa retorno cliente R = call P2(a1,a2) 8 1 empacota parâmetros desempacota resultado bibliotecas RPC desempacota parâmetros 2 7 3 servidor P1 P2 P3 P2(a1,a2) 4 5 dispatcher empacota resultado 6 API (socket) a2 a1 P2 resultado API (socket) (c) FEEC/UNICAMP 25 (c) FEEC/UNICAMP 26 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 Objetos: Constituição estado: define um conjunto de variáveis internas que armazenam o estado corrente do objeto interface: define, em termos de protótipo, um conjunto de operações (ou métodos) Barramento de Software Interface Padrão (c) FEEC/UNICAMP 27 implementação: código dos métodos definidos tanto pelas interfaces quantos internos ao objeto (c) FEEC/UNICAMP 28 Objetos: Regras de Interação Objetos: Conceitos Básicos 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). 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 29 (c) FEEC/UNICAMP 30

Objetos: Conceitos Básicos Objetos: Conceitos Básicos Instanciação: objetos são criados através de uma operação (denominada de instanciação) sobre uma classe. classe relação 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. encapsulamento estado métodos M1 M3 M2 instanciação interface identidade polimorfismo herança (especialização) classe invocação de métodos M2 (c) FEEC/UNICAMP 31 (c) FEEC/UNICAMP 32 Objetos Distribuídos Objetos Distribuídos: Vantagens 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. 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 autocontidas 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 33 (c) FEEC/UNICAMP 34 Objetos Distribuídos: Interação Interfaces Remotas 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 35 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 36

Objetos Distribuídos: Implementação Referência de Objetos Descrição da(s) Interface(s) Compilador de Interfaces ORB (biblioteca) Compilador (C++, Java,...) 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. Stubs / Skeletons Implementação dos Servants (C++, Java,...) RMI utiliza as próprias instâncias das classes Java que implementam interfaces remotas para identificar objetos distribuídos. servant OBS: Uma referência pode ser persistente ou transiente. (c) FEEC/UNICAMP 37 (c) FEEC/UNICAMP 38 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. interface cliente remota M1 Stub Rede Skeleton M1 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 invocação local M1 M2 M3 protocolo de RPC upcall M1 M2 M3 objeto distribuído (c) FEEC/UNICAMP 39 (c) FEEC/UNICAMP 40 Binding Invocação Remota de Métodos 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 2. lookup de nomes 1. bind/rebind 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. cliente 3. invoke objeto distribuído 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 41 (c) FEEC/UNICAMP 42

Arquitetura de Distribuição Middleware: Padrões servidor cliente servant Stub Skeleton Object Request Broker objeto distribuído OSI Indústria Consórcios DCE (OSF) TCP/IP sockets RPC WWW DCOM (Microsoft) RMI (SUN) ODP CORBA (OMG) ISO/ITU-T Internet EJB (Sun).NET (Microsoft) SOAP (W3C) Serviços Nomes Eventos Segurança 1977 1982 1987 1992 1997 2002 (c) FEEC/UNICAMP 43 (c) FEEC/UNICAMP 44 Plataforma Java 2 Plataforma Java 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 45 (c) FEEC/UNICAMP 46 Plataforma Java 2: Arquitetura Plataformas Java 2 Classes Java Estendidas Adaptador Browser S.O. Hardware Applets, Pacotes, Frameworks Máquina Virtual Java Adaptador S.O. Hardware Classes Java Básicas bytecodes S.O. Java Java Chip APIs Suporte às Aplicações Plataforma Java Básica Interface de Portabilidade 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 entradasaí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 47 (c) FEEC/UNICAMP 48

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. Cliente Servidor EJB EJB Home Interface EJB Remote Interface Container EJB EJB Bean Database 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. Cliente JNDI API JNDI Naming Manager JNDI SPI service providers OMG COSNaming RMI Registry Internet LDAP Novell NDS (c) FEEC/UNICAMP 49 (c) FEEC/UNICAMP 50 Plataforma Java 2EE: Tecnologias Cliente JBDC (Java Database Connectivity) Provê uma interface uniforme para acesso a bases de dados. JDBC API JDBC JDBC Driver API JDBC Driver A JDBC Driver B Database A Database B 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. Cliente JTA API JTS JTS API Transaction Coordinator Transaction Manager(s) JDBC Driver C Database C Datastores Resource Manager(s) (c) FEEC/UNICAMP 51 (c) FEEC/UNICAMP 52 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. 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. Applet Java Servidor EJB IIOP Cliente CORBA (C++) Servidor CORBA (C++) Cliente RMI Servidor RMI RMI-IIOP API Cliente CORBA Servidor CORBA Java 2 ORB Orbix RMI ORB CORBA ORB IIOP (c) FEEC/UNICAMP 53 (c) FEEC/UNICAMP 54

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. 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 55 (c) FEEC/UNICAMP 56 Java Remote Method Invocation (RMI) RMI: Visão Geral 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 57 cliente RMI Naming s.m1(...) M1 M2 M3 stub socket Naming.lookup rmi://host:port/name ObjRef rmic JRMP TCP/IP IIOP rmiregistry Naming host Naming.bind rmi://host:port/name ObjRef servidor RMI Servant skel. socket (c) TCP/IP FEEC/UNICAMP 58 M1 M2 M3 Java RMI RMI: Interfaces Remotas O ciclo de desenvolvimento de objetos distribuídos em RMI possui os seguintes passos: 1. definição da interface remota; 2. compilação da interface remota (javac); 3. desenvolvimento do servant; 4. geração de stubs e skeletons a partir do servant via compilador RMI (rmic); 5. desenvolvimento do servidor. (c) FEEC/UNICAMP 59 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 60

RMI: Passagem de Parâmetros em Métodos de Interfaces Remotas RMI: Servants 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 61 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 62 RMI: Servants (cont.) RMI: Classes 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 63 <<interface>> Remote <<interface>> Account deposit() withdraw() balance() extends implements AccountClient AccountServant deposit() withdraw() balance() AccountServant_Stub deposit() withdraw() balance() geradas por rmic AccountServant_Skel deposit() withdraw() balance() (c) FEEC/UNICAMP 64 RMI: rmic (Compilador RMI) RMI: Serviço de Nomes 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 C:\ dir *.class Account.class AccountServant.class AccountServant_Stub.class AccountServant_Skel.class (c) FEEC/UNICAMP 65 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 66

RMI: A Classe Naming RMI: Servidores 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. 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 67 (c) FEEC/UNICAMP 68 RMI: Servidores (cont.) RMI: Clientes 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 69 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 70 RMI: Clientes (cont.) RMI: Aspectos de Segurança accountref.deposit( 100 ); accountref.deposit( 300 ); 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()); 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 71 (c) FEEC/UNICAMP 72

RMI Sobre HTTP RMI: Propriedades 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 Stub HTTP POST sockets especiais Firewall proxy HTTP Serv. HTTP script CGI (java-rmi.cgi) servidor RMI Skeleton (c) FEEC/UNICAMP 73 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 74 Modelo OSI ODP (Open Distributed Processing) 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 75 (c) FEEC/UNICAMP 76 Modelo OSI ODP: Open Distributed Processing 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. 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 77 (c) FEEC/UNICAMP 78

ODP: Pontos de Vista ODP: Pontos de Vista Empresa Pontos de vista não são hierarquizados, mas sim diferentes visões de um mesmo sistema. Informação Computação especificação implementação SD SD Engenharia Tecnologia ponto de vista (c) FEEC/UNICAMP 79 (c) FEEC/UNICAMP 80 ODP: Pontos de Vista ODP: Ponto de Vista de Empresa especificação implementação Empresa Informação SD ORB Engenharia Computação Tecnologia 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 81 (c) FEEC/UNICAMP 82 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,...). 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 83 (c) FEEC/UNICAMP 84

ODP: Ponto de Vista de Informação ODP: Ponto de Vista de Computaçã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, principalmente). 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, principalmente). (c) FEEC/UNICAMP 85 (c) FEEC/UNICAMP 86 ODP: Ponto de Vista de Computação ODP: Interfaces Computacionais 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. sinal iniciador sinal respondedor BCO interface computacional operação cliente evocação terminação servidor T1 T2 tipo da interface stream produtor fluxo consumidor (c) FEEC/UNICAMP 87 (c) FEEC/UNICAMP 88 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. BCO T T BCO 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). Exemplo: ligação tipo publicador-consumidor. interface de controle T : tipo complementar a T BCO BO T T T T BCO (c) FEEC/UNICAMP 89 (c) FEEC/UNICAMP 90

ODP: Ponto de Vista de Engenharia 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 UML de colaboração, de sequência, de atividade de distribuição, etc. 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 denominadas interfaces de engenharia. BEO checkpoint, recover, delete,... interface de gerenciamento interface de engenharia (c) FEEC/UNICAMP 91 (c) FEEC/UNICAMP 92 ODP: Regras de Estruturação 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 (exemplo: pacote Java, agente móvel). checkpoint, recover, delete,... GCL BEO CLUSTER Cápsula Cápsula é um agregado de clusters. Um BEO especial na cápsula (Gerente de Cápsula) provê uma interface de gerenciamento para a cápsula. É a unidade de alocação de recursos do ODP (exemplo: processo UNIX). checkpoint, recover, delete,... GCP GCL GCL CLUSTER CLUSTER CÁPSULA (c) FEEC/UNICAMP 93 (c) FEEC/UNICAMP 94 ODP: Regras de Estruturação ODP: Regras de Estruturação 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: computador conectado à rede. NÓ núcleo CÁPSULA CÁPSULA 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 95 (c) FEEC/UNICAMP 96

ODP: Canal 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. Binder Binder é responsável pelo gerenciamento fim-afim 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 97 (c) FEEC/UNICAMP 98 ODP: Canal 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. 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 99 (c) FEEC/UNICAMP 100 ODP: Canal (exemplo) ODP: Mapeamento Computação/Engenharia cliente servant BCO1 BEO1 BEO2 Stub RMI STUB BINDER Skeleton RMI BO stub contr. de canal binders stub TCP/IP ADAP. PROTOCOLO TCP/IP BCO2 transparência protocol adapters canal rede (c) FEEC/UNICAMP 101 (c) FEEC/UNICAMP 102

ODP: Transparência 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.). 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 103 (c) FEEC/UNICAMP 104 Object Management Group (OMG) CORBA (Common Object Request Broker Architecture) 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 105 (c) FEEC/UNICAMP 106 OMG: Missão OMG: Estrutura A missão do OMG é prover a indústria com especificaçõ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.). 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 107 (c) FEEC/UNICAMP 108

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). 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 109 (c) FEEC/UNICAMP 110 A Arquitetura OMA OMA: Componentes 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. 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 111 (c) FEEC/UNICAMP 112 OMA: Componentes OMA: Object Request Broker Application Interfaces Domain Interfaces Common Facilities O Object Request Broker (ORB) é um facilitador de comunicação entre objetos distribuídos. Funções típicas desempenhadas pelo ORB: Object Request Broker (ORB) Object Services 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 113 (c) FEEC/UNICAMP 114

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. 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). dentre muitos outros... (c) FEEC/UNICAMP 115 (c) FEEC/UNICAMP 116 OMA: Interfaces Específicas do Domínio OMA: Interfaces de Aplicação 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 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 117 (c) FEEC/UNICAMP 118 A Arquitetura CORBA CORBA: Características 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). 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 119 (c) FEEC/UNICAMP 120

CORBA: Arquitetura CORBA: Arquitetura A Arquitetura CORBA é composta dos seguintes componentes básicos: cliente servidor 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. IDL stub DII ORB interface ORB IDL skeleton POA Repositório de Interfaces Repositório de Implementação (c) FEEC/UNICAMP 121 (c) FEEC/UNICAMP 122 CORBA: Object Request Broker (ORB) CORBA: 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. cliente (Java) Windows NT ORB servidor (C++) Solaris (c) FEEC/UNICAMP 123 (c) FEEC/UNICAMP 124 CORBA: Internet Inter-ORB Protocol (IIOP) Objetivo: Prover interoperabilidade entre ORBs de diferentes fornecedores. cliente CORBA: Interface Definition Language (OMG IDL) Objetivo: especificar interfaces (métodos e atributos) de objetos. OMG IDL não é linguagem de programação; INTERNET (TCP/IP) IIOP ORB (IONA) servidor A especificação CORBA provê mapeamentos de IDL para linguagens orientadas e não orientadas a objetos (C, C++, Java, etc.). ORB (IBM) (c) FEEC/UNICAMP 125 (c) FEEC/UNICAMP 126

OMG IDL: Compiladores IDL: Estrutura de uma Interface 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. Módulo Definições (tipos complexos, exceções) Interface Atributos Operações Interface Atributos Operações (c) FEEC/UNICAMP 127 (c) FEEC/UNICAMP 128 IDL: Tipos Básicos IDL: Tipos Complexos Ponto Flutuante: float (IEEE 32 bits) double (IEEE 32 bits) Inteiros: long: -2 31... +2 31-1 unsigned long: 0... +2 32-1 long long: -2 63... +2 63-1 unsigned long long: 0... +2 64 short: -2 15... +2 15-1 unsigned short: 0... +2 16-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 129 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". Exemplo: struct cliente { string nome; long idade; ; (c) FEEC/UNICAMP 130 IDL: Tipos Complexos (cont.) 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 131 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 132

IDL: Tipos Complexos (cont.) 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; Arrays: armazenam um mesmo tipo IDL em uma estrutura multidimensional. Exemplos: DataStruct vencimentos[16]; float Z[50][50]; (c) FEEC/UNICAMP 133 (c) FEEC/UNICAMP 134 IDL: Tipos Complexos (cont.) 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 Constantes: permite associar valores a um identificador. Exemplos: const float pi = 3.1415926535; const string palmeiras = "alviverde imponente"; (c) FEEC/UNICAMP 135 (c) FEEC/UNICAMP 136 IDL: Tipos Complexos (cont.) IDL: Tipos Complexos (cont.) Typedefs: permitem definir nomes para tipos complexos. Exemplos: typedef sequence<datastruct> Datas; Datas vencimentos; typedef long integer; integer datadigital; 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 137 (c) FEEC/UNICAMP 138

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 139 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 140 IDL: Atributos de Interfaces IDL: Operações 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;... ; Operações são definidas no escopo de uma interface IDL da seguinte forma: <tipo> <nome> (<indireção> <tipo> parâmetro,...) raises {E 1,... E n ; 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. Nota: o compilador IDL gera métodos get e set para operação com atributos. (c) FEEC/UNICAMP 141 (c) FEEC/UNICAMP 142 IDL: Parâmetros de Operações IDL: Retorno 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. 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(); Nota: parâmetros com valor NULL são proibidos! (c) FEEC/UNICAMP 143 (c) FEEC/UNICAMP 144

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: 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 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 145 interface A; interface B { void op1 (in A p1,...);... ; interface A { void op2 (in B p1,...);... ; (c) FEEC/UNICAMP 146 IDL: Herança de Interfaces Mapeamento IDL-Java 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(); ; IDL module boolean char octet string short, unsigned short long, unsigned long long long, unsigned long long float double fixed Java package boolean char byte java.lang.string short int long float double java.math.bigdecimal (c) FEEC/UNICAMP 147 (c) FEEC/UNICAMP 148 Mapeamento IDL-Java Parâmetros out e inout em Java IDL enum, struct, union sequence, array interface constant (fora de uma interface) constant (em uma interface) exception any typedef readonly attribute readwrite attribute operação Java class array interface, helper & holder classes public interface fields na interface Java class org.omg.corba.any helper classes accessor method accessor and modifer methods método 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 149 (c) FEEC/UNICAMP 150