T. D. S. I. PARA WEB Prof. Emmanuel Nolêto

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 linguagem em que se especificam os objectos distribuídos A arquitectura que materializa o sistema. GIOP (General Inter-ORB Protocol) 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 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 multi- plataforma, 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  Aceita invocações (pedidos) e envia respostas Os clientes não precisam de ser objectos Os objectos CORBA são independentes de qualquer linguagem 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 A1; readonly attribute 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 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 T2; typedef sequence 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.