(c) feec/unicamp1 plataformas distribuÍdas eleri cardozo feec/unicamp eleri julho de 2002

(c) FEEC/UNICAMP 1

PLATAFORMAS DISTRIBUÍDAS

Eleri CardozoFEEC/UNICAMP

http://www.fee.unicamp.br/~eleri

Julho de 2002

(c) FEEC/UNICAMP 2

Introdução aos Sistemas Distribuídos

(c) FEEC/UNICAMP 3

Sistemas Distribuídos: Definição

Um sistema distribuído é um sistema computacionalcom 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 20021982 2007

1

10

1000

100

10000

100000

20 BIPS

Pentium

486Mips

286

DEC Alpha

HP PA

386

(c) FEEC/UNICAMP 6

Evolução em Redes

Mbits/s

1987 1992 1997 20021982 2007

1

10

1000

100

10000 10 Gbits/s

Fast Ethernet

ISDNEthernet

FDDIT. 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

CORBA especifica o Object Request Broker do modelo OMA. Interoperabilidade entre implementações CORBA é garantida pela linguagem IDL e pelo protocolo IIOP.

O modelo de referência OMA.

Object Request Broker (ORB)

Objetos deAplicação

CORBAFacilities(vertical)

CORBAFacilities

(horizontal)

Serviços CORBA(CORBAservices)

(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 deMiddleware

(c) FEEC/UNICAMP 20

O Conceito de MiddlewareVisã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çõesFinanças

(c) FEEC/UNICAMP 22


APLICAÇÃO

APRESENTAÇÃO

SESSÃO

TRANSPORTE

REDE

ENLACE

FÍSICO

Ex: funções típicas detelecomunicações } Domínio de aplicação

Agente AgenteCliente } Gerenciamento de Rede

Um novo Modelo OSI: camada nível 8 contendo funções típicas dos váriosdomínios de aplicação:Medicina, Finanças, Telecomunicações, etc.

(c) FEEC/UNICAMP 23


APLICAÇÃO

APRESENTAÇÃO

SESSÃO

TRANSPORTE

REDE

ENLACE

FÍSICO

Domínio da aplicação

Contexto daAplicação

Contexto dasComunicações

A Camada de Transporteé um divisor entre o mundo das aplicações e o mundo das comunicações

(c) FEEC/UNICAMP 24


APLICAÇÃO

APRESENTAÇÃO

SESSÃO

TRANSPORTE

REDE

ENLACE

FÍSICO


MIDDLEWARE

(c) FEEC/UNICAMP 25


APLICAÇÃO

APRESENTAÇÃO

SESSÃO


Sistema Operacional

+Hardware

} Sistemas Heterogêneos!

Necessidade dePadronização do

Middleware

(c) FEEC/UNICAMP 26

Evolução em Middleware

1987 1992 1997 2002 200719821977

troca demensagens

chamada deprocedimentoremoto (RPC)

objetosdistribuídos

agentes

componentes

(c) FEEC/UNICAMP 27

Evolução do Conceito de Middleware Troca de Mensagens (primitivas SEND/RECEIVE)

Receive

Aplicação Aplicação

TLI CPC-I Socket Named Pipes

SNA TCP/IP NetBIOSIPX/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)

tarefa 1 tarefa 2

bloqueio

send(M1)

receive(M2)

send(M2)

receive(M1)

(c) FEEC/UNICAMP 29

Troca de Mensagens: Implementação

sistema detransporte(TCP/IP)

API(socket)

sistema detransporte(TCP/IP)

API(socket)

port (endpoint)

buffer

espaço do usuário

espaço do núcleo

LAN / WAN

(c) FEEC/UNICAMP 30

Evolução do Conceito de MiddlewareChamada Remota de Procedimento (RPC)

TLI CPC-I Socket Named Pipes

SNA TCP/IP NetBIOSIPX/SPX

NDIS ODI

Token-ring Ethernet

Aplicação Aplicação

ISDN

Remote Procedure Call (RPC)

2- Call (…) 1- Register (…) 3- Call (…)

(c) FEEC/UNICAMP 31

RPC: Semântica

cliente servidorcall P2(a1,a2)

retorno

cliente servidor

bloqueio

call P2(a1,a2)

P2 executa

P1

P2

P3

retorno

(c) FEEC/UNICAMP 32

RPC: Implementação

API(socket)

empacotaparâmetros

desempacotaresultado

cliente

R = call P2(a1,a2)

desempacotaparâmetros

empacotaresultado

servidor

dispatcher

P1 P2 P3

API(socket)

P2(a1,a2)1

2 3

45

67

8

bibliotecasRPC

P2a1a2

resultado

(c) FEEC/UNICAMP 33

Evolução do Conceito de MiddlewareObjetos 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 deprotó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


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


identidade

instanciação

classe

classe

herança (especialização)

classerelação

interfaceinvocação de métodosM1 M3

M2

estado

métodos

polimorfismo

encapsulamento

M2

(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

ORB (biblioteca)Descrição da(s)Interface(s)

Compilador deInterfaces

Stubs / SkeletonsImplementaçãodos Servants

(C++, Java, ...)

Compilador(C++, Java, ...)

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

interfaceremota

objetodistribuídoupcall

M1M2M3

M1

M1M2M3

M1

protocolode 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//143.106.50.188/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

servidor de nomes

clienteobjeto

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

SkeletonStub

Object Request Broker

servant objetodistribuído

Nomes Eventos SegurançaServiços

servidor

cliente

(c) FEEC/UNICAMP 50

Middleware: Padrões

1987 1992 1997 200219821977

TCP/IP sockets RPC WWW

OSI ODP

DCE(OSF)

CORBA(OMG)

Consórcios

ISO/ITU-T

Internet

SOAP (W3C)

Indústria

DCOM(Microsoft)

RMI(SUN)

EJB(Sun)

.NET(Microsoft)

(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

Adaptador

Browser

S.O.

Hardware

Adaptador

S.O.

Hardware

S.O. Java

Java Chip

Interface dePortabilidade

Máquina Virtual Java bytecodes

Classes Java Básicas

Classes Java Estendidas

PlataformaJava Básica

Applets, Pacotes, Frameworks Suporte àsAplicações

APIs

(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)

Cliente

Servidor EJB

Container EJB

EJB BeanEJB HomeInterface

EJB RemoteInterface Database

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.

(c) FEEC/UNICAMP 56


• JNDI (Java Naming and Directory Interface)

Cliente

JNDI API

JNDI NamingManager

OMG COSNaming

RMI Registry

Internet LDAP

Novell NDS

JNDI SPI

service providers

Provê acesso unificado a serviços de nomes e de diretório para as aplicações Java.

(c) FEEC/UNICAMP 57


• JBDC (Java Database Connectivity)

Provê uma interface uniforme para acesso a bases de dados.

Cliente JDBC

JDBC API

JDBC Driver

API

JDBC Driver A

JDBC Driver B

JDBC Driver C

Database A

Database B

Database C

(c) FEEC/UNICAMP 58


• JTA (Java Transaction API) e JTS (Java Transaction Service)

Definem APIs para um serviço de transação em Java (baseados no Serviço de Transações do OMG - CORBA OTS). JTA é utilizada no EJB.

Cliente JTS

JTA APIJTS API

TransactionCoordinator

TransactionManager(s)

ResourceManager(s)Datastores

(c) FEEC/UNICAMP 59


• 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.

Java 2 ORB Orbix

AppletJava

ServidorEJB

ClienteCORBA(C++)

ServidorCORBA(C++)

IIOP

(c) FEEC/UNICAMP 60


• 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.

IIOP

RMI ORB CORBA ORB

ClienteRMI

ServidorRMI

ClienteCORBA

ServidorCORBA

RMI-IIOPAPI

(c) FEEC/UNICAMP 61


• Outras Tecnologias:

� Java Server Pages (JPS) e Servlets: APIs que permitem estender as funcionalidades de um servidor WWW;

� Java Message Service (JMS): API para serviços de mensagens;

� JavaMail: API para serviços de E-mail;

� J2EE Connector: arquitetura para conectar a plataforma Java 2 com outros serviços de informação da empresa.

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

Naming.bindrmi://host:port/NameObjRef

stub

socket

Naming.lookuprmi://host:port/Name rmiregistry

host

skel.

socket

servidor RMI

cliente RMI

TCP/IP

JRMP

TCP/IP

IIOP

Servant

M2M1 M3

s.M1(...)

ObjRef

M2M1 M3

rmicNaming

Naming

(c) FEEC/UNICAMP 65

Java RMI

O ciclo de desenvolvimento de objetos distribuídos em RMI possui os seguintes passos:

1. definição da interface remota;2. compilação da interface remota (javac); 3. desenvolvimento do servant;4. geração de stubs e skeletons a partir do servant via compilador RMI (rmic);5. desenvolvimento do servidor.

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

<<interface>>Account

deposit()withdraw() balance()

AccountServant


<<interface>>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 *.classAccount.classAccountServant.classC:\ rmic AccountServantC:\ dir *.classAccount.classAccountServant.classAccountServant_Stub.classAccountServant_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/AccountServerO 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.deposit( 300 ); accountRef.deposit( 100 ); accountRef.withdraw( 240 ); accountRef.withdraw( 10 ); System.out.println("Balance is " + accountRef.balance()); accountRef.withdraw( 10000 ); } catch (Exception e) { System.err.println("AccountClient exception: " + e.getMessage()); } } }

(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.

clienteRMI

StubproxyHTTP

servidorRMI

Firewall script CGI(java-rmi.cgi)

sockets especiais

Skeleton

HTTP POST

Serv. HTTP

(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 DistributedProcessing)

(c) FEEC/UNICAMP 83

Modelo OSI

O Modelo OSI possui algumas funcionalidades nacamada 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

Modelo OSI

Problemas no desenvolvimento de Sistemas Distribuídosdiretamente 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ãosão especificados) que vem influenciando outrasatividades de padronização (exemplo: CORBA).

Seu desenvolvimento foi fortemente influenciado peloprojeto ANSA (Universidade de Lancaster, UK).

(c) FEEC/UNICAMP 86

ODP: Pontos de Vista

Empresa

Informação Computação

Engenharia Tecnologia

SDespecificação

implementação

(c) FEEC/UNICAMP 87


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


Empresa

Informação Computação

Engenharia

SD

espe

cific

ação

impl

emen

taçã

o

TecnologiaORB

(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.

T1 T2

BCOinterface computacional

tipo da interface

(c) FEEC/UNICAMP 95

ODP: Interfaces Computacionais

stream

sinal

produtor consumidor

sinal

evocação

terminação

operação

fluxo

cliente servidor

iniciador respondedor

(c) FEEC/UNICAMP 96

ODP: Ligação (Binding) Primitiva

BCOT’T

BCO

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’: 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).

BO

interfacede controle

T T’ T’TBCO BCO

(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 engenharia

BEO

interface degerenciamento

(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.

GCL

CLUSTER

BEO




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

GCL

CLUSTER



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ÁPSULA

CÁPSULA

núcleo

NÓ



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.

canal

stub

rede

protocol adapters

stub

contr.de canal

binders

BEO1 BEO2interface

de controle


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.


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.


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.


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.


ODP: Mapeamento Computação/Engenharia

canal

stub

rede

protocol adapters

stub

contr.de canal

binders

BEO2BEO1 BCO1

BO

BCO2

transparência


ODP: Transparência

Transparência é um conceito chave que permite a visão de engenharia (associada à implementação do sistema) se aproximar da visão de computação (associada ao modelamento do sistema).

Transparência deve ser provida pelo núcleo, canal e demais infra-estruturas de suporte à implementação (ORBs, repositórios, etc.).


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.


DCE (Distributed ComputingEnvironment)


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 detecnologias 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 OMGe ISO, a OSF supre os implementadores com um código fonte base.


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 deplataforma sobre os quais aplicações distribuídassã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).


DCE: Arquitetura

HARDWARE

SISTEMA OPERACIONAL REDE

DCE Threads

DCE Remote Procedure Call

SegurançaTime Diretório

Sistema de Arquivos

APLICAÇÕES DISTRIBUÍDAS


DCE: Threads

OBJETIVO: uniformizar a programação multithreaded.

Utiliza o padrão POSIX 1003.4a (IEEE).

Provê três esquemas de escalonamento de threads:• FIFO (First In First Out)• RR (Round Robin)• Default (RR com prioridades)


DCE: Threads

espaço de endere-çamento comum

THREAD

THREAD

THREAD

THREAD

espaço de en-dereçamento

processomonothreaded processo multithreaded

escalonamento

tempo


DCE: Threads

A programação multithreaded permite que servidoresprocessem uma requisição enquanto outra estiverpendente (bloqueada por I/O, por exemplo).

servidor multi-threaded

cliente

cliente

req #1

req #2


DCE: Threads

Formas de Escalonamento:

Pb > Pa, Pc

A B C

CC ABA C

AA CCC BB

FIFO

RR

DEF.

BBB B


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 !)


DCE: RPC

SERVIÇO DEDIRETÓRIO

servidor

2. registra serviço

RPCdaemon

tabela de endpoints

1. registra endpoint

cliente5. RPC

3. server ?

4. endpoint ?


DCE: RPC

uuidgen

Editor

compilador IDL

arquivo IDL

gera ID único

contém a definiçãoda interface do serviço

stub docliente cabeçalho

stub doservidor código C


DCE: RPC

stub docliente cabeçalho

stub doservidor

Compilador C

CLIENTE SERVIDOR

Compilador C

código docliente

código doservidor

runtime lib(cliente)

runtime lib(servidor)


DCE: Serviço de Relógio Distribuído (DTS)

Objetivo: garantir que os relógios das máquinascom 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 eventosnuma aplicação distribuída.

No DCE, tempo é armazenado num contador de64 bits cujo valor zero corresponde a 00:00 Hs de15/10/1582 !


DCE: DTS

UTC

timeserver

timeserver

timeclerk

timeclerk

timeclerk

redetime ?

fonte de tempo(não requerida)


DCE: DTS

Forma de operação:

UTC server #1

UTC server #2

UTC server #3

UTC server #4

TIME CLERK


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).


DCE: Serviço de Diretório

Arquitetura:

servidor DNS X.500 DA

CDS GDA CDS GDA CDS GDA

CDS: Cell Directory AgentGDA: Global Direcory Agent

célula

outros servidores


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.



AUTENTICAÇÃO

Utiliza a tecnologia Kerberos (MIT).

Um servidor de segurança (security server) gerencia adistribuição de tickets (informação criptografada contendoas identidade de pares cliente-servidor).

Tickets são usados para o estabelecimento deRPC Autenticada (segura).



AUTORIZAÇÃO

Utiliza listas de controle de acesso (ACL: Access ControlList). ACL é um padrão POSIX 1003.6.

Cada recurso possui uma ACL que discrimina osprivilégios para usuários e grupos de usuários.Exemplos de privilégios: read, write, execute.

ACLs são armazenadas num servidor (ACL server).



PROTEÇÃO

Utiliza checksum criptografado como proteção contraalteração da informação em trânsito.

checksuminformação (ex: parâmetro RPC)

computado por criptografia

OBS: O DCE não provê mecanismos paracriptografar a informação.



Visão Geral:

servidor deautenticação

obtém tickets

ferramentas deadministraçãochaves

criptográficas

permissões

login(lib)

clienteACL

server

RPC

recursos

servidorobtémpermissão


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.


DCE: DFS (cliente)

subsistema dearquivo local

clientechamada de sistema(open, read, write, …)

chamadas locais chamadas DFS

DFS cache

RPC para osservidores DFS


DCE: DFS (servidor)

chamadas locais chamadas DFS

Token Manager

Episodesubsistema dearquivo local(+ extensões)

File Exporter

filesetserver

replicationserver

BOSserver

backupserver


DCE: o conceito de CÉLULA

servidores DFS

servidores desegurança,diretório e time

clientes


CORBA (Common ObjectRequest Broker

Architecture)


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.


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.).


OMG: Estrutura

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).


OMG: Processo de Padronização

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


OMG: Padrões Alternativos

As principais tecnologias que competem com as padronizadas pelo OMG são:

• Microsoft DCOM (Distributed Component Object Model). Problema: uma empresa, uma tecnologia (Windows).

• Sun Java (linguagem, APIs, toolkits, frameworks, etc.).

Problema: uma linguagem de programação.

• W3C (WWW Consortium): introdução de objetos na Web (XML, HTTP, SOAP, etc.).

Problema: soluções centradas na Web.


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.


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).


OMA: Componentes

ApplicationInterfaces

Domain Interfaces

CommonFacilities

Object Request Broker (ORB)

ObjectServices


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.).


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 ...


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).


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


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).


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).


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).


CORBA: Arquitetura

A Arquitetura CORBA é composta dos seguintescomponentes 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.


CORBA: Arquitetura

cliente

ORB

POAIDL

skeletonIDL stub DII

servidor

ORBinterface

Repositóriode Interfaces

Repositório deImplementação


CORBA: Object Request Broker (ORB)

É o componente básico de interconexão daArquitetura CORBA, sendo responsável peloencaminhamento de requisições de métodospara objetos remotos.

O ORB provê independência de plataforma,localização e linguagem de implementação dosobjetos comunicantes.

Usualmente é implementado como um daemonque executa em todas as máquinas da rede.


CORBA: ORB

cliente (Java) servidor (C++)

Windows NT Solaris

ORB


CORBA: Internet Inter-ORB Protocol (IIOP)

Objetivo: Prover interoperabilidade entre ORBs dediferentes fornecedores.

ORB (IBM)

INTERNET(TCP/IP)

cliente

ORB (IONA)

IIOPservidor


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 deIDL para linguagens orientadas e não orientadasa objetos (C, C++, Java, etc.).


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.


IDL: Estrutura de uma Interface

Módulo

Definições (tipos complexos, exceções)

Operações

Atributos

Interface

Operações

Atributos

Interface


IDL: Tipos Básicos

Ponto Flutuante: • float (IEEE 32 bits)• double (IEEE 32 bits)

Inteiros:• long: -231 ... +231 -1• unsigned long: 0 ... +232 -1• long long: -263 ... +263 -1• unsigned long long: 0 ... +264

• short: -215 ... +215 -1• unsigned short: 0 ... +216 -1

Nota: IDL não define inteiros !

Outros Tipos:• boolean: TRUE ou FALSE• char: 8 bits (usualmente ASCII)• octet: 8 bits (opaco)• any: armazena qualquer tipo IDL


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".

Exemplo:struct cliente { string nome; long idade;};


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; };



Strings:• armazenam uma sequência de caracteres ASCII com tamanho máximo especificado (bounded) ou não (unbounded).

Exemplos:string<30> cliente; // maximo 30 caracteresstring cliente; // tamanho ilimitado



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 elementossequence<string> nomes;sequence<DataStruct> vencimentos;



Arrays:• armazenam um mesmo tipo IDL em uma estrutura multi-dimensional.

Exemplos:DataStruct vencimentos[16];float Z[50][50];



Tipo Fixo:• permite representar um número em duas partes: valor e escala (posição do ponto decimal).

Exemplos:fixed<6,2> preco; // (-/+)9999.99 fixed<4,3> taxaDolar; // (-/+)9.999



Constantes:• permite associar valores a um identificador.

Exemplos:const float pi = 3.1415926535;const string palmeiras = "alviverde imponente";



Typedefs:• permitem definir nomes para tipos complexos.

Exemplos:typedef sequence<DataStruct> Datas;Datas vencimentos;typedef long integer;integer dataDigital;



Tipo Any:• permite armazenar um valor pertencente a qualquer tipo IDL (simples ou complexo), inclusive outro tipo any.

O mapeamento de IDL para linguagens alvo deve prover mecanismos para:• inserção de valores em tipos any;• extração de valores armazenados em tipos any;• inspeção do tipo armazenado.

Nota: Tipos any são um remédio à imposibilidade de sobregarregar operações (métodos) em IDL.


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 {};


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();};


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.


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.


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 !


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();


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.


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, ...); ...};


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();};


Mapeamento IDL-Java

IDL Javamodule 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


Mapeamento IDL-Java

IDL Javaenum, 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


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.


Parâmetros out e inout em Java (cont.)

Exemplo:

// IDLinterface Account { ... void withdraw(inout long amount);};

// Java public interface AccountOperations { ... void withdraw(intHolder amount);};

// JavaintHolder amt = new IntHolder();amt.value = 10000;acc.withdraw(amt);System.out.println("Amount: " + amt.value);


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);


Mapeamento IDL-Java: Exemplo

Account.idl

Compilador IDL

InterfaceAccount

InterfaceAccountOperations

classAccountHolder

classAccountHelper

class_AccountStub

classAccountPOA


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( ); };


Exemplo: AccountOpeations.java

public interface AccountOperations { void deposit (long arg0); void withdraw (long arg0) throws AccountPackage.LimitExceeded; long balance ();} // interface AccountOperations


Exemplo: Account.java

public interface Account extends AccountOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity {}


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; }...}


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;}}


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) { super(LimitExceededHelper.id()); reason = _reason; } // ctor


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.


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.


IDL: OBV (cont.)

Compilador IDL

classesHelper,Holder

ObjetoJava

Implementaçãodo Objeto

DefaultFactory

ValueFactory

estadométodos

construtor

valuetype


IDL: Valuetypes

// "objeto" a ser passado por valorvaluetype 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);};


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);};


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

}


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);

}}


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 !!


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 hashtablethe_factory = new EmpregadoDefaultFactory();empregados = new Hashtable();

}


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 ! }}


CORBA: Basic Object Adapter (BOA)

Objetivo: instanciar (criar) servidores e controlar aexecução de métodos.

O BOA identifica o código dos objetos servidoresinteragindo com o Repositório de Implementação.

Usualmente, o BOA provê três tipos de instanciaçãode servidores:

• compartilhada;• não compartilhada;• por método.


CORBA: BOA

compartilhada não compartilhada por método

método processo

M1

M2

M3

M1

M2

M1

M2

M3

M1

M2

M3


CORBA: BOA

A tendência é utilizar a instanciação por processoe servidores multitheaded (para cada evocaçãoo servidor cria uma thread para processá-la).

O BOA implementa também funções elementaresde segurança (Ex: verificação se um cliente possuipermissão para instanciar um servidor) via atributos do sistema de arquivos.

Pode-se implementar diferentes adaptadores de objetos em prejuizo da portabilidade.


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.


POA: Stubs e Skeletons Portáveis

stuboutin

IIOP

get n m

result = get(n, m)

ORB ORB

skeletonout in

result

in = invoke(out)

invoke

out = invoke(”get”,in)

invoke

cliente servant

result = get(n, m)value = gridRef.get(x,y)

(_ImplBase)

(_Stub)


POA: Arquitetura

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 Raiz é obtido através do método resolve_initial_references("RootPOA") disponibilizado pelo ORB.

POA Raiz

POA P1 POA P2

POA P3


POA: Arquitetura

Mapa de Objetos Ativos

Object ID

Object ID

Object ID

Object ID

Servant Manager

Ser

van

ts(i

mp

lem

enta

ções

)

Servant Manager(default)

Po

lític

as

POA ManagerServidor CORBA

códigosuprido pelodesenvolvedor

Definidas pelodesenvolvedor


POA: Operação Típica

_invoke

OID

skeleton

parâmetros

_invoke(M, ...)

servant

upcall

POA

M(...)mapa objs.ativos

_invoke

OID

skeleton

parâmetros

_invoke(M, ...)

servant

upcall

POA

M(...)mapa objs.ativos


POA: Políticas

POA define 7 políticas:

1. Atribuição de OIDs: USER_ID; SYSTEM_ID (default)

2. Retenção de Servants: RETAIN (servants são retidos no mapa de objetos ativos); NON_RETAIN (não existe mapa de objetos ativos).

3. Processamento de Requisição: USE_ACTIVE_OBJECT_MAP_ONLY (default); USE_DEFAULT_SERVANT; USE_SERVANT_MANAGER.

4. 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.


POA: Políticas (cont.)

5. Unicidade de OIDs: UNIQUE_ID (default) - cada servant possui um único ID; MULTIPLE_ID - um servant pode possui mais de um ID.

6. 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).


POA: Políticas (cont.)

7. 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".

POA

ORB

POA

ORB

POA

ORB

POA

ORBORB

POA

ORBORB

POA

ORBORB


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.


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).


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.


CORBA: Static Invocation Interface (SII)

SII é a forma mais simples do cliente invocarum método num servidor.

SII requer que todas as interfaces de servidoressejam conhecidas em tempo de compilação(portanto, SII é type-safe).


CORBA: SII

cliente

ORB

POAIDL skeletonIDL stub

servidor

proxy


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.


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.


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.


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 !


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.

servantCORBA

interfaces IDLdo serviço

servidor de nomesdiretório de nomes(persistente ou transiente)


CORBAServices: Ciclo de Vida

O serviço de propriedades proporciona operações que permitem criar, destruir, copiar objetos.

GenericFactory

FactoryFinder

find_factories

create_object

servantCORBA

servantCORBA

servantCORBA

copymove

remove

LifeCycleObject

CORBA.Object obj = GenericFactory.CreateObject(pars);

encontra

cria


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.

PropertySet

PropertySetFactory

create_propertysetcreate_initial_propertyset

create_constrained_propertyset

define_propertyget_property

delete_property

......

servantCORBA

servantCORBA

servidor de propriedades


CORBAServices: Eventos

O serviço de eventos prove um mecanismo de notificação segundo os modelos push e pull.

obtain_push_consumerobtain_push_supplier

connect_push_consumerconnect_push_supplier

canal de eventos

push

push supplier

push consumersservidor de eventos

pushevento

disconnect_push_supplier


CORBAServices: Object Transaction Service

OTS (Object Transaction Service) implementa um serviço de transações aberto baseado no protocolo 2-phase commit.

servantCORBA

interfaces IDLdo serviço- begin - commit - abort, ...

servidor OTS

base de dados(Oracle, Sybase, etc.)interface XA

(X/Open)

permite a integração comprodutos que implementamesta interface


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.

1. exporta capacidades do servidor (desempenho, custo, etc.)2. importa requisitos (desempenho mínimo, custo máximo, etc.)3. retorna IOR do servidor4. interage com o servidor (provavelmente via DII)

ORB

Trader servidorCORBA

clienteCORBA

2 34 1


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++).


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.


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.


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.


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.


geradorde código

ORBIX: Compilador IDL

utilitários

parserIDL

árvore deparsingarquivo IDL

stubs, skeletons,server templatecompilador IDL

aplicação-exemploconversão IDL - HTMLetc.

Code Generation Toolkit


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.


ORBIX: ORB

código da aplicação (cliente)

código do stub(gerado pelo

compilador IDL)

código da aplicação (servidor)

código do skeleton(gerado pelo

compilador IDL)requisição IIOP

API API

ORBIX daemon(orbixd)

ORB (lib)

ORB (lib)

instancia servidor

Rep.Impl.

busca de servidor


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.


ORBIX: Repositórios

Orbix dispõe de repositórios de interface e de

implementação com a seguinte arquitetura:

sistema de arquivosnativo da máquina

utilitários demanutenção

e gerência

registros

repositório

putitcatitlstitrmit...


ORBIX: Integração com MS-COM

ORBIX permite que servidores CORBA se apresentem a clientes

como objetos COM (Component Object Model - padrão Microsoft).

OBS: MIDL (Microsoft IDL) define tipos COM

cliente COM COM IIOP servidorCORBA

Bridge

provê mapeamentobidirecional entreMIDL e OMG IDL

repositóriode tipos(COM)

repositóriode interfaces

(CORBA)


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.


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.


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.


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).


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.


VisiBroker: SmartAgent & OAD

SmartAgent

SmartAgent

SmartAgent

Serviço Distribuído de Nomes + Diretório

Algoritmos deBal. de cargaTol. a Falhas

OAD

Rep. Impl.

OAD

Rep. Impl.

cliente

1. consulta2. encontra servidor

3. retorna ref. OAD

4. bind5. acessa impl.

6. inst. servidor


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.


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).


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.


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).


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.


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.


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.).


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).


Integração via CORBA

Exemplo:

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 #3ORB #1IIOP IIOP


Hooks 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)

ORB internoao produto

Produto Extensãoao Produto

IDL “exportada”pelo produto

IIOPORB Comercial

Hook CORBA deInteroperabilidade


Gateways de Interoperabilidade

Gateways permitem sistemas baseados em CORBA interoperarem com sistemas baseados em outras arquiteturas e protocolos. Exemplo:

GerenteCORBA

IDL “exportada”pelo gateway

IIOPORB Comercial

AgenteSNMP

Domínio deGerência SNMP

Domínio deGerência

CORBA

ORB

GatewayIDL - SNMP

SNMP


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.


Microsoft DCOM

servidor COM

cliente COM

servidor DCOM

cliente DCOM

rede

cliente e servidor em diferentes (processos) mas no mesmo processador

cliente e servidor emdiferentes processadores

RPCIPC


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.


DCOM: Arquitetura

SCM segurança DCE RPC

protocolos de rede (TCP/IP)

hardware

SCM segurança DCE RPC

protocolos de rede (TCP/IP)

hardware

rede

instancia

proxy stubcliente DCOM servidor DCOM

cria instância(de servidor)

SCM: Service Control Manager (parte do Windows)


DCOM: Objetos COM/DCOM

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.

classe(coclass)

interface

classe(coclass)

interface

classe(coclass)

interfacelib


DCOM: MIDLimport "oaidl.idl";import "ocidl.idl";

[object, uuid(3C6E0346-479C-11D4-96B9-0090272BDBDA), dual helpstring("IAccountComObject Interface"), pointer_default(unique)]interface IAccountComObject : IDispatch { HRESULT deposit([in] unsigned long amount); HRESULT withdraw([in] unsigned long amount); HRESULT balance([out, retval] long *amount);};

[uuid(3C6E0339-479C-11D4-96B9-0090272BDBDA), version(1.0), helpstring("Account 1.0 Type Library")]library ACCOUNTLib { importlib("stdole32.tlb"); importlib("stdole2.tlb"); [uuid(3C6E0347-479C-11D4-96B9-0090272BDBDA), helpstring("AccountComObject Class")]coclass AccountComObject { [default] interface IAccountComObject; };};


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).


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).


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.


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/unicamp1 plataformas distribuÍdas eleri cardozo feec/unicamp eleri julho de 2002

Documents