T. D. S. I. PARA WEB Prof. Emmanuel Nolêto [email protected] IDL - Corba Introdução • Multicast IP • Otimização do uso do link eliminando redundância; • Múltiplas notificações divididas por grupos. • Facilidade de desenvolvimento; • Permite que a aplicação cresça. Componentes IDL (Interface Definition Language) A arquitectura que materializa o sistema. GIOP (General Inter-ORB Protocol) A linguagem em que se especificam os objectos distribuídos O protocolo de comunicação utilizado nas invocações IIOP (Internet Inter-Orb Protocol) Implementação do GIOP sobre TCP/IP. Origem Norma definida pelo OMG (Object Management Group), uma organização independente formada em 1989. O objectivo principal reside em permitir a implementação de objectos distribuídos em qualquer linguagem e garantir a interoperabilidade, mesmo perante cenários de grande heterogeneidade. Faz parte de um conjunto de especificações introduzidas de forma escalonada: 1992, 1995, ..., 2000 Origem • CORBA (“Common Object Request Broker Architecture”) • Especificação da OMG (“Object Management Group”) para sistemas distribuídos multiplataforma, independente de fornecedor; • Outra especificação bastante conhecida: UML • Possui muitas implementações, para várias linguagem e arquiteturas; • Inclusive para sistemas embarcados e sistemas em tempo real (CORBART); Meta-Modelo de Objectos “Objecto CORBA” é sinónimo de objecto remoto Corresponde ao servidor no paradigma C/S Os clientes não precisam de ser objectos Os objectos CORBA são independentes de qualquer linguagem Aceita invocações (pedidos) e envia respostas Podem-se traduzir para várias linguagens, mesmo que não sejam OO Há mappings standard para: C, C++, Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript. Comporta a noção de herança (múltipla). Meta-Modelo de Objetos Os objectos CORBA são caracterizados por uma interface, um identificador único e são acessíveis através de referências As referências para os objectos remotos são opacas Pode haver múltiplas referências para o mesmo objecto CORBA A localização dos objectos remotos está contida na próprias referências, mas é completamente transparente para os clientes CORBA IDL A linguagem IDL serve para: Especificar a interface dos objectos remotos Definir agrupamentos de objectos em módulos Estabelecer as relações hierárquicas entre tipos de objectos IDL - Módulos Module A { … }; Module B { … Module C { … }; }; São opcionais e permitem limitar a visibilidade (escopo) de conjuntos de definições. Interfases IDL module M { interface I { … }; }; O tipo dos objectos CORBA é definido através de um nome único assinalado com a palavra chave: INTERFASE Podem incluir a definição de operações, tipos, atributos e excepções... Operações IDL module M { interface I { string op1( in long arg1, out short arg2, inout boolean arg3 ) ; oneway void shutdown( ... ) ; }; }; • As operações podem ter (ou não) um resultado e parâmetros de entrada, saída ou entrada e saída. • Podem ser assíncronas e lançar exceções ... Excepções IDL module M { exception E1 { long errorCode; }; ... Interface I { void op(...) raises (E1, E2, ...) ; ... }; }; • Cada operação pode lançar vários tipos de excepções e estas podem conter variáveis... Atributos IDL module M { interface I { attribute <type> A1; readonly attribute <type> A2; ... }; }; Um objecto CORBA pode ter um ou mais atributos Os atributos podem ser marcados como sendo só de leitura. Cada atributo define implicitamente até duas operações (para fazer a consulta e a atualização dos valores se permitido). Tipos básicos do IDL • Os tipos primitivos usuais, com diversas precisões, estão presentes em CORBA IDL. • • • • • • • Short unsigned short long unsigned long long long unsigned long long float Tipos básicos do IDL • • • • • • double long double boolean char wchar string • Estes tipos podem ser usados para construir novos tipos mais complexos Tipos complexos do IDL module M { struct { long l; ....} T1 ; typedef sequence< T1> T2; typedef sequence< T2,, 20> T3; typedef T3 T4[10][20]; }; enum E { e1, e2, e3, ..., en}; • A definição de novos tipos é feita através da palavra chave typedef. Pode-se definir novos tipos à custa de estruturas, sequências, arrays, enumerações e unions. Unions IDL module M { enum E { e1, e2, e3, ..., en}; typedef union U switch( E ) { case e1: string s; case e2: long l ; ... default: float f; } T1 ; ... }; • As unions podem ter a validade dos campos ditada por um atributo de controlo, ao estilo dos registos com variante da linguagem Pascal. Herança IDL module MyServer { interface Service { readonly attribute string name ; oneway void shutdown() ; }; interface MyService : Service { void ping( inout string msg) ; }; }; • Um objecto CORBA pode derivar de um ou mais objectos, desde que não haja colisões de nomes NameService • O espaço dos nomes dos objectos CORBA é hierárquico e relativo a uma dada raiz. • Qualquer caráter pode ser usado na designação de um objecto • Não havendo um separador (“/”), não é (sempre) possível designar o nome completo por uma string. • O código de acesso ao NameService é relativamente complexo. • O nome é sempre relativo à raiz associada a cada ORB. • É possível organizar os NameServices em federações, para particionar o espaço de nomes, por exemplo. Name Services • São oferecidas as operações usuais de interacção com um repositório (registry): • bind(...), unbind(...), rebind(...), resolve(...) e list(...) • A operação de listagem devolve um iterador e evita transferir de uma só vez o conteúdo do repositório... Serialização em Java • Classes • • • • • • • • • • • Tipos primitivos ( Sim ) Tipos básicos que implementam Serializable ( Sim ) Conteiners caso os objetos sejam serializáveis ( Sim ) Classes que herdam tipos serializáveis (Integer herda Number) ( Sim ) Exceções e erros ( Sim ) Conteiners, componentes e eventos AWT e Swing ( Sim ) Classes matemáticas (java.math) ( Sim ) Classes de reflexão (java.lang.reflect) ( Sim ) Adapter, filters e classes filhas ( Não ) Streams, readers, writers e outras classes de I/O ( Não ) Serialização permitida ( Não ) RMI Problemas • Apesar da normalização verificam-se problemas de interoperabilidade entre ORBs distintos. • A melhor maneira de garantir a inter-operabilidade entre clientes e servidores heterogéneos (linguagens diferentes) é usar um ORB e ferramentas da mesma proveniência... • O servidor precisa de uma interface para expor seus métodos para JVMs remotas; • O cliente precisa pensar que está acessando objetos locais; • A passagem de objetos e variáveis por valor e por referência precisa ser resolvida por meio de serialização.