Carregar apresentação
A apresentação está carregando. Por favor, espere
1
PLATAFORMAS DISTRIBUÍDAS
Eleri Cardozo FEEC/UNICAMP Julho de 2002 (c) FEEC/UNICAMP
2
Sistemas Distribuídos
Introdução aos Sistemas Distribuídos (c) FEEC/UNICAMP
3
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
4
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
5
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
6
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
7
Downsizing $$$ $$$ (c) FEEC/UNICAMP
8
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
9
Internet (c) FEEC/UNICAMP
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
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
19
O Conceito de Middleware
(c) FEEC/UNICAMP
20
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
21
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
22
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
23
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
24
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
25
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
26
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
27
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
28
Troca de Mensagens: Semântica
tarefa 1 tarefa 2 send(M1) receive(M2) bloqueio send(M2) receive(M1) (c) FEEC/UNICAMP
29
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
30
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
31
RPC: Semântica call P2(a1,a2) cliente servidor P1 P2 retorno P3
bloqueio P2 executa P1 P2 P3 (c) FEEC/UNICAMP
32
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
33
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
34
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
35
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
36
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
37
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
38
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
39
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
40
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
41
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
42
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
43
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
44
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
45
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
46
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 // /AccountServer (c) FEEC/UNICAMP
47
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
48
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
49
Arquitetura de Distribuição
Skeleton Stub Object Request Broker servant objeto distribuído Nomes Eventos Segurança Serviços servidor cliente (c) FEEC/UNICAMP
50
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
51
Plataforma Java (c) FEEC/UNICAMP
52
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
53
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
54
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
55
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
56
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
57
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
58
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
59
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
60
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
61
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 ; J2EE Connector: arquitetura para conectar a plataforma Java 2 com outros serviços de informação da empresa. (c) FEEC/UNICAMP
62
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
63
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
64
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
65
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
66
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
67
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
68
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
69
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
70
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
71
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
72
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
73
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
74
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
75
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
76
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
77
RMI: Clientes (cont.) accountRef.deposit( 100 );
accountRef.withdraw( 240 ); accountRef.withdraw( 10 ); System.out.println("Balance is " + accountRef.balance()); accountRef.withdraw( ); } catch (Exception e) { System.err.println("AccountClient exception: " + e.getMessage()); } (c) FEEC/UNICAMP
78
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
79
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
80
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
81
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
82
ODP (Open Distributed Processing)
(c) FEEC/UNICAMP
83
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
84
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
85
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
86
ODP: Pontos de Vista Empresa Informação Computação SD Engenharia
especificação SD implementação Engenharia Tecnologia (c) FEEC/UNICAMP
87
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
88
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
89
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
90
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
91
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
92
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
93
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
94
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
95
ODP: Interfaces Computacionais
iniciador respondedor sinal sinal cliente evocação servidor operação terminação produtor consumidor fluxo stream (c) FEEC/UNICAMP
96
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
97
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
98
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
99
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
100
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
101
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
102
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
103
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
104
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
105
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
106
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
107
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
108
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
109
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
110
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
111
DCE (Distributed Computing
Environment) (c) FEEC/UNICAMP
112
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
113
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
114
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
115
DCE: Threads OBJETIVO: uniformizar a programação multithreaded.
Utiliza o padrão POSIX a (IEEE). Provê três esquemas de escalonamento de threads: FIFO (First In First Out) RR (Round Robin) Default (RR com prioridades) (c) FEEC/UNICAMP
116
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
117
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
118
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
119
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
120
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
121
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
122
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
123
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
124
DCE: DTS fonte de tempo (não requerida) time server time server time ?
rede time clerk time clerk time clerk UTC (c) FEEC/UNICAMP
125
DCE: DTS Forma de operação: UTC server #1 UTC server #2 UTC server #3
TIME CLERK (c) FEEC/UNICAMP
126
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
127
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
128
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
129
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
130
DCE: Serviço de Segurança
AUTORIZAÇÃO Utiliza listas de controle de acesso (ACL: Access Control List). ACL é um padrão POSIX 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
131
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
132
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
133
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
134
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
135
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
136
DCE: o conceito de CÉLULA
clientes servidores DFS servidores de segurança, diretório e time (c) FEEC/UNICAMP
137
CORBA (Common Object Request Broker Architecture)
(c) FEEC/UNICAMP
138
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
139
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
140
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
141
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
142
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
143
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
144
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
145
OMA: Componentes Application Domain Common Interfaces Interfaces
Facilities Object Request Broker (ORB) Object Services (c) FEEC/UNICAMP
146
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
147
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
148
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
149
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
150
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
151
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
152
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
153
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
154
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
155
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
156
CORBA: ORB cliente (Java) servidor (C++) ORB Windows NT Solaris
(c) FEEC/UNICAMP
157
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
158
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
159
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
160
IDL: Estrutura de uma Interface
Módulo Definições (tipos complexos, exceções) Interface Atributos Operações Interface Atributos Operações (c) FEEC/UNICAMP
161
IDL: Tipos Básicos Ponto Flutuante: Outros Tipos: float (IEEE 32 bits)
double (IEEE 32 bits) Inteiros: long: unsigned long: long long: unsigned long long: short: unsigned short: 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
162
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
163
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
164
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
165
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
166
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
167
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; // (-/+) fixed<4,3> taxaDolar; // (-/+)9.999 (c) FEEC/UNICAMP
168
IDL: Tipos Complexos (cont.)
Constantes: permite associar valores a um identificador. Exemplos: const float pi = ; const string palmeiras = "alviverde imponente"; (c) FEEC/UNICAMP
169
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
170
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
171
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
172
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
173
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
174
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
175
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
176
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
177
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
178
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
179
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
180
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
181
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
182
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
183
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
184
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
185
Mapeamento IDL-Java: Exemplo
Account.idl Compilador IDL Interface AccountOperations class AccountHolder class _AccountStub Interface Account class AccountHelper class AccountPOA (c) FEEC/UNICAMP
186
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
187
Exemplo: AccountOpeations.java
public interface AccountOperations { void deposit (long arg0); void withdraw (long arg0) throws AccountPackage.LimitExceeded; long balance (); } // interface AccountOperations (c) FEEC/UNICAMP
188
Exemplo: Account.java public interface Account extends AccountOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { } (c) FEEC/UNICAMP
189
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
190
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
191
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
192
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
193
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
194
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
195
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
196
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
197
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
198
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
199
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
200
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
201
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
202
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
203
CORBA: BOA M1 M2 M3 método processo compartilhada não compartilhada
por método método processo M1 M2 M3 (c) FEEC/UNICAMP
204
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
205
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
206
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
207
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
208
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
209
POA: Operação Típica (c) FEEC/UNICAMP
210
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
211
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
212
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
213
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
214
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
215
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
216
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
217
CORBA: SII cliente servidor proxy POA ORB IDL stub IDL skeleton
(c) FEEC/UNICAMP
218
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
219
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
220
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
221
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
222
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
223
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
224
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
225
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
226
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
227
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
228
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
229
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
230
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
231
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
232
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
233
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
234
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
235
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
236
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
237
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
238
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
239
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
240
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
241
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
242
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
243
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
244
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
245
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
246
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
247
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
248
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
249
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
250
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
251
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
252
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
253
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
254
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
255
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
256
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
257
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
258
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
259
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
260
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
261
DCOM: MIDL import "oaidl.idl"; import "ocidl.idl";
[object, uuid(3C6E C-11D4-96B BDBDA), 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(3C6E C-11D4-96B BDBDA), version(1.0), helpstring("Account 1.0 Type Library")] library ACCOUNTLib { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [uuid(3C6E C-11D4-96B BDBDA), helpstring("AccountComObject Class")] coclass AccountComObject { [default] interface IAccountComObject; }; }; (c) FEEC/UNICAMP
262
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
263
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
264
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
265
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
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.