Mini Curso - Programação em SD

2
Programao em Sistemas Distribudos

Rmulo de Oliveira1 Resumo: A reduo do preo de computadores e sua grande disseminao vm impulsionando a criao de redes de computadores. Hoje, essas redes esto em todos os lugares, e a Internet pode ser entendida como um grande e disperso sistema distribudo, que permite aos seus usurios o acesso a uma variedade de servios. So mltiplos os desafios enfrentados pelos projetistas desses sistemas frente aos problemas de heterogeneidade, segurana e confiabilidade. Este curso descreve os principais conceitos relacionados ao desenvolvimento de sistemas distribudos, tais como: heterogeneidade de representao de dados e marshaling; transparncias de distribuio e middleware; modelo cliente-servidor; Chamada de Procedimento Remoto (RPC); servios de nome e binding. Tambm sero abordadas duas das principais plataformas utilizadas para esse propsito atualmente: JAVA (com suas tecnologias relacionadas) e CORBA. Joni Fraga1 Carlos Montez1
Laboratrio de Controle e Microinformtica LCMI Depto de Automao e Sistemas DAS Universidade Federal de Santa Catarina UFSC e-mail: {romulo, fraga, montez}@das.ufsc.br
X Escola de Informtica da SBC-Sul - ERI 2002
2.1. Introduo
A reduo do preo dos computadores e sua grande disseminao, a partir do surgimento de microcomputadores na dcada de 80, impulsionaram a criao de redes de computadores. Essas redes foram criadas, principalmente, devido necessidade de compartilhamento de recursos entre os computadores. Inicialmente, pequenas redes locais foram sendo instaladas nas instituies, e, posteriormente, a partir de meados da dcada de 90 no Brasil, elas foram se interligando Internet. Hoje, as redes de computadores esto em todos os lugares e a Internet pode ser entendida como um grande e disperso sistema distribudo que permite aos seus usurios acessarem servios, tais como www, email e transferncia de arquivos, entre muitos outros. Um sistema distribudo pode ser definido como aquele "formado por componentes de hardware e software, situados em redes de computadores, e que se comunicam e coordenam suas aes apenas atravs de trocas de mensagens" [Coulouris 2001]. A separao espacial dos computadores que formam esses sistemas distribudos pode variar desde poucos metros, em uma rede local, at quilmetros de distncia, em uma rede largamente dispersa. Da mesma maneira, podem variar bastante os desafios enfrentados pelos projetistas desses sistemas - frente aos problemas de heterogeneidade, segurana e confiabilidade (tolerncia a faltas). Envios e recepes de mensagens no ocorrem instantaneamente, e a conseqncia imediata do fato da comunicao entre os componentes dos sistemas distribudos se dar apenas por trocas de mensagens, a inexistncia de um relgio global, no qual todos os computadores possam se basear. Essa caracterstica dificulta a obteno de um estado global dos componentes do sistema, importante para a resoluo de uma srie de problemas de sincronizao que surgem nas aplicaes. Questes de coordenao e sincronizao em sistemas distribudos decorrem exatamente da sua caracterstica de concorrncia entre seus componentes e a necessidade de compartilhamento de recursos entre eles. Esses problemas formam uma classe que inclui a necessidade, entre outros, de algoritmos de eleio, deteco de deadlocks (impasses) distribudos, algoritmos de concordncia, etc [Lynch 1996]. O objetivo deste texto no tratar de algoritmos distribudos, mas sim tratar de plataformas de software que suportam a execuo (facilitam a construo) de aplicaes distribudas. As primeiras propostas de plataformas para suportar a construo de aplicaes distribudas, no incio da dcada de oitenta, eram limitadas. Elas tratavam com sistemas homogneos e estavam baseadas em sistemas operacionais ou linguagens especiais para programao distribuda (ARGUS [Liskov 1988], Emerald [Jul 1991], CONIC [Kramer 1989]). Com a expanso dos sistemas tomando propores geogrficas considerveis e envolvendo diferentes tecnologias, a necessidade de padres e plataformas mais flexveis tornou-se evidente. Nesse sentido houve vrios esforos, tais como ODP [ISO 1995], ANSAware [ANSA], DCE [OSF]. Essas propostas serviram para demarcar o
caminho para o conjunto de padres para ambientes operacionais distribudos existentes atualmente. O propsito deste texto apresentar os conceitos fundamentais presentes no desenvolvimento de sistemas distribudos, assim como as principais plataformas utilizadas para esse propsito atualmente. O tema em si vasto, e existem livros inteiros para tratar do assunto, tais como [Tanenbaum 2002], [Coulouris 2001], [Birman 1996], [Lynch 1996]. Em funo da limitao de espao, este texto concentra-se na descrio de duas das tecnologias mais utilizadas atualmente para a construo de sistemas distribudos. A seo 2.2 apresenta os conceitos elementares da rea, presentes em qualquer plataforma que suporte a execuo de sistemas distribudos. Em seguida, a seo 2.3 descreve como aplicaes distribudas podem ser escritas em Java. A seo 2.4 faz o mesmo para o padro CORBA. Finalmente, a seo 2.5 contm as consideraes finais.
2.2. Conceitos bsicos

Toda a comunicao entre processos em um sistema distribudo baseada em trocas de mensagens, pois, conceitualmente, no h memria compartilhada. Quando vrios processos precisam se comunicar, necessria a adoo de protocolos, ou seja, acordos entre as partes que se comunicam, sobre como a comunicao se dar (formatos, contedos e significados de mensagens). Cada sistema final na rede executa protocolos que controlam o envio e recepo de informaes na rede. Atualmente, o conjunto de protocolos da Internet denominado TCP/IP [RFC 1180] se tornou um padro de facto em ambientes de sistemas distribudos. Seus dois protocolos mais importantes so o TCP (Transmition Control Protocol) orientado a conexes , e o IP (Internet Protocol), motivo pelo qual esse conjunto de protocolo conhecido como TCP/IP. A Figura 2.1 mostra a pilha de protocolos TCP/IP, comparando-a com as sete camadas do modelo ISO OSI [Stevens1998, Kurose 2001]. Modelo OSI Protocolos TCP/IP Aplicao Apresentao Sesso Transporte Rede Enlace Fsica TCP IP Device Driver e Hardware UDP Aplicao socket
Figura 2.1. Pilha de protocolos do Modelo OSI e TCP/IP.
As aplicaes usualmente tm acesso aos protocolos de transporte da rede usando sockets. Um socket pode ser concebido como um porto de entrada e de sada de cada processo. Cada processo envia e/ou recebe mensagens atravs de seus sockets. Devido ao fato que, usualmente, os protocolos de transporte da rede so implementados e controlados pelo sistema operacional, um socket tambm pode ser concebido como uma interface entre a aplicao e o substrato de comunicao do sistema operacional (Figura 2.2).
Aplicao Sistema Operacional
Processo socket TCP ou UDP, buffers, etc... Rede
Processo socket TCP ou UDP, buffers, etc...
Figura 2.2. Socket como interface de acesso rede. A programao de sistemas distribudos pode ser feita diretamente em uma linguagem de programao (ex. C, C++ ou Java), usando uma API (Application Program Interface Interface de Programao de Aplicaes) socket. Na seo 2.3.1, este texto apresenta os principais conceitos relacionados programao de aplicaes distribudas usando a API socket do Java [Harold 1997].
2.2.1. Heterogeneidade de representao de dados e marshaling

vivel a construo de grandes sistemas distribudos atravs da API socket. Entretanto, o programador de tais sistemas precisa lidar diretamente com uma srie de questes, tais como heterogeneidade de representao de dados e falta de transparncias de distribuio. Essas questes exacerbam a complexidade do sistema, desviando a ateno dos programadores do problema que deveria ser originalmente resolvido. Suponha, por exemplo, um sistema heterogneo, onde processos clientes e servidores residam em computadores com diferentes tipos de processadores. Ao trocar mensagens entre si, possvel que alguns dos processos representem um valor inteiro, com 2 bytes, usando a representao little-endian, enquanto outros processos usem a representao bigendian. A representao little-endian, usada pela Intel, representa o valor inteiro considerando o byte mais significativo antes do menos significativo. J a representao bigendian, usada, por exemplo, pelos processadores SPARC, o inverso. A Figura 2.3 mostra as duas formas de representao do valor inteiro 256 (100 na base 16).
01 00 00 01
big-endian
little-endian
Figura 2.3. Representao big-endian e little-endian.
Problemas semelhantes surgem com representaes diferentes para nmeros de ponto flutuantes, e at mesmo com representaes de cdigos de caracteres (ASCII ou EBCDIC). Envio de dados pelo suporte de comunicao, implica em empacot-los na forma de mensagens no momento do envio, e desempacot-los no momento de suas recepes. Representaes diferentes de dados podem gerar interpretaes diferentes dos valores dos dados. Para superar essas questes, um sistema distribudo pode adotar duas estratgias. A primeira a de converter todos os dados transmitidos para um formato comum, previamente conhecido por todos os processos. A segunda estratgia a de enviar junto com os dados, informaes de qual tipo de representao est sendo adotada naquela mensagem. Ambas as solues demandam trabalho adicional do programador e aumentam a complexidade do sistema. Com objetivo de facilitar a programao de sistemas distribudos, seria interessante que as questes da heterogeneidade dos dados, e o trabalho adicional gerado por esses problemas, no envio e na recepo das mensagens, no precisassem ser tratados diretamente pelos programadores. Veremos adiante nesse texto que os stubs, implementados em suportes de middleware, so os componentes de sistemas distribudos que buscam ocultar dos programadores toda complexidade envolvida com o empacotamento (marshaling) e desempacotamento de mensagens (unmarshaling), respectivamente, nos envios e recepes de mensagens. (Empacotamento e desempacotamento de mensagens tambm costumam ser chamados de serializao e deserializao de parmetros)
2.2.2. Transparncias de distribuio e middleware

Para complicar ainda mais esse cenrio, suponha que um programador resolva implementar um servio em dois servidores diferentes (replicao) por motivo de tolerncia a faltas. Nesse caso, o programador teria de se preocupar em implementar cada cliente fazendo requisies para os dois servidores. Ou ainda, possvel que vrios processos do sistema distribudo precisem fazer acesso simultneo a um recurso compartilhado (por exemplo, um arquivo). Nesse caso, o programador precisa implementar um cdigo que controle a competio no acesso a esse recurso (por exemplo, garantindo a excluso mtua no acesso ao recurso). Seria interessante que essas questes de replicao e concorrncia fossem transparentes (invisveis) para o programador, ou seja, que este no precisasse se preocupar com esses temas, e se concentrasse no problema principal a ser resolvido. Assim, o ideal que existisse, do ponto de vista do programador do sistema, transparncias de replicao e de concorrncia. Basicamente, costuma-se reconhecer oito tipos de transparncias de distribuio [ISO 1995]: de acesso: quando o acesso aos recursos feito de forma idntica, independentemente se estes se encontram localmente ou remotamente localizados; de localizao: quando os recursos so acessados sem o conhecimento de suas localizaes;
de concorrncia: permite que vrios processos concorrentes compartilhem recursos sem interferncia entre eles; de replicao: quando o acesso s mltiplas instncias de um recurso feito sem o conhecimento explcito do programador; de falha: permite que usurios e as aplicaes completem suas tarefas apesar de falhas em componentes de hardware ou software; de migrao: permite a movimentao de recursos e de clientes sem afetar a operao ([Coulouris 2001] denomina essa transparncia como "de mobilidade", devido importncia crescente da computao mvel nos dias atuais); desempenho: permite que o sistema seja reconfigurado automaticamente quando a carga varia no tempo; de escalabilidade: permite que o sistema se expanda sem a mudana na estrutura do sistema ou nos algoritmos de suas aplicaes. A forma usual de se obter essas transparncias de distribuio atravs do uso de middlewares. Em um sistema distribudo, o software que suporta um modelo de programao atuando sobre servios de sistema operacional e de rede chamado de middleware. Basicamente, middleware uma camada de software, residente acima do sistema operacional e do substrato de comunicao, que oferece abstraes de alto nvel, fornecendo uma viso uniforme na utilizao de recursos heterogneos existentes, com objetivo de facilitar a programao distribuda (Figura 2.4).
Rede Processo Middleware Sistema Operacional (ex. Linux) Sistema Operacional (ex. Windows) Processo
Figura 2.4. Middlewares ocultam a heterogeneidade em sistemas distribudos. A seo 2.3 desse texto apresenta o middleware Java RMI, e a seo 2.4 os padres CORBA, um middleware para programao de sistemas distribudos na forma de objetos distribudos. Ambos buscam ocultar a heterogeneidade de hardware e sistemas operacionais hospedeiros. CORBA vai alm, no sentido que tambm permite que o sistema seja desenvolvido usando linguagens de programao diferentes.
2.2.3. Modelo cliente-servidor

Interaes em um sistema distribudo ocorrem, usualmente, atravs do modelo cliente-servidor. No modelo cliente-servidor, um sistema estruturado em processos cooperantes que assumem papeis de clientes ou de servidores. Um processo assume o papel de servidor quando ele oferece servios aos outros processos clientes. Um mesmo processo pode ora fazer papel de cliente, ora papel de servidor. Por exemplo, um processo servidor de nomes (ex. DNS [RFC 1035]) pode receber uma requisio para resoluo de um nome o qual ele no possa resolver. Nesse caso, o servidor, temporariamente, assume papel de cliente fazendo uma requisio para outro servidor de nomes. Servidores de tempo NTP [Mills 1991] tambm funcionam de forma hierrquica, onde alguns servidores sincronizam seus relgios, periodicamente, fazendo requisies a outros servidores. A maneira mais simples de implementar um modelo cliente-servidor atravs de um protocolo simples do tipo requisio/resposta (request/reply). A Figura 2.5 apresenta um exemplo de implementao de um protocolo requisio/resposta usando trs primitivas fazOperao(), e aguardaPedido() e enviaResposta(). Essas primitivas, por sua vez, podem ser implementadas atravs de operaes de envio e recepo de mensagens existentes, por exemplo, na API socket.
Processo cliente
mensagem de requisio fazOperao () aguardaPedido () mensagem de resposta enviaResposta ()
Processo servidor
Figura 2.5. Modelo cliente-servidor usando um protocolo requisio-resposta. Nessa implementao de protocolo, um processo cliente, envia uma mensagem de requisio para um servidor requisitando algum servio (fazOperao()). Essa operao bloqueia o processo cliente enquanto no retornada uma mensagem de resposta. No outro ponto final da comunicao, o servidor j estava bloqueado aguardando alguma requisio de servio (aguardaPedido()). Ao receber o pedido de requisio, o servidor se desbloqueia, extrai a mensagem, executa a operao pedida pelo cliente, e retorna uma mensagem para o cliente (enviaResposta()). Um exemplo tradicional de implementao de um protocolo requisio/resposta o HTTP, usado em interaes entre navegadores e servidor web. interessante notar que toda a complexidade decorrente do tratamento de possveis perdas de mensagens, da heterogeneidade de representao de dados, e questes de empacotamento (marshaling) e desempacotamento (unmarshaling) de dados em mensagens no representada na Figura 2.5. O conceito de chamada de procedimento remoto (RPC)
apresentado a seguir busca, exatamente, ocultar essa complexidade em sistemas distribudos, fornecendo ao programador um ambiente de programao mais confortvel.
2.2.4. Chamada de Procedimento Remoto

Uma das principais atividades em sistemas distribudos a da busca de paradigmas para programao distribuda que facilitem ao mximo os programadores desses sistemas. Programadores esto acostumados a desenvolver sistemas fazendo chamadas de procedimentos (no paradigma de programao procedural) ou invocaes em operaes em objetos (no paradigma de programao orientada a objetos). O desenvolvimento de sistemas distribudos unicamente atravs de trocas de mensagens, usando, por exemplo, API sockets, torna a programao tediosa e com bastante tendncia a introduo de erros durante sua codificao. A implementao de modelos cliente-servidor, usando protocolos requisio/resposta, representa "um passo a mais" para o programador desses sistemas. Contudo, conforme j foi dito, toda a complexidade com relao ao empacotamento e desempacotamento de mensagens precisa ser tratada pelo programador. Assim, em meados da dcada de 80 foi proposta a idia do RPC (Remote Procedure Call Chamada de Procedimento Remoto). A Figura 2.6 esquematiza como so efetuadas chamadas usando o RPC. A idia bsica , do ponto de vista dos programadores, tornar as interaes entre clientes e servidores semelhantes a uma chamada de procedimento. Para o programador existe uma transparncia de acesso, e toda a complexidade relacionada s tarefas de serializao/deserializao de parmetros tambm so ocultadas do programador. A complexidade dessas tarefas ocultada do programador, e encapsulada dentro dos stubs. Os stubs so gerados durante a compilao dos programas que compem o sistema, e uma descrio mais detalhada desse processo de gerao desses stubs, apresentada mais adiante, nas sees 2.3.3 (Java RMI) e 2.4.9 (CORBA).
chamada
chamada stub do cliente stub do servidor
Cliente
retorno
Servidor
retorno
Sistema receive Operacional
receive send
send
Sistema Operacional
Rede
Figura 2.6. Chamada de Procedimento Remoto.

Basicamente, o cliente executa uma chamada de procedimento. O stub do cliente empacota a requisio e seus parmetros (marshaling) e envia a mensagem (send). Do
outro lado, a mensagem recebida (receive) pelo stub do servidor, que desempacota (unmarshaling) a mensagem, executando uma chamada de procedimento ao servidor. Aps o servidor executar o procedimento, o valor de retorno devolvido ao stub do servidor, o qual empacota a resposta em uma mensagem, que enviada (send) de volta para o cliente. O stub do cliente recebe (receive) a mensagem de retorno, desempacota a resposta e a retorna para o processo cliente. Para o processo cliente, todas essas etapas ocorrem de forma transparente. Ele simplesmente faz uma chamada de procedimento, aguarda que ela seja executada, e recebe a resposta.
2.2.5. Servios de Nome e binding

Aplicaes tradicionais (no distribudas) no tm necessidade de esquemas especiais para identificar e localizar seus provedores de servio. Nesse caso, os servios utilizados usualmente so oferecidos pelos sistemas operacionais, que executam no mesmo computador das aplicaes clientes. A forma de obter acesso a esses servios j conhecida previamente, em tempo de compilao, e normalmente se d atravs de chamadas de procedimentos. Por outro lado, aplicaes distribudas necessitam de esquemas elaborados para localizar os seus fornecedores de servio. Uma forma convencional e imediata o uso de endereos IP e de portas de comunicao. Por exemplo, a porta 80 do endereo IP 200.135.48.81 poderia identificar um determinado servidor web na Internet. Entretanto, essa forma de localizao e identificao inadequada em sistemas distribudos por vrios motivos. Uma delas o fato do par "porta-endereo IP" no identificar de forma inequvoca um servio. Ou seja, apesar da tentativa de padronizao no uso de valores numricos de portas para alguns servios, nada garante que a porta 80, por exemplo, seja usada exclusivamente em servidores web. Outro servio na Internet poderia usar esse valor. Alm disso, possvel, por exemplo, que alguns servidores web possam fazer uso de outras portas tais como a 8080. Contudo, a principal desvantagem do uso dessa abordagem, o fato dela dificultar a obteno das transparncias de distribuio. Nesse sentido, visando resolver esses problemas, atualmente so empregados servios de nomes. Servios de nomes (ou location brokers) permitem que clientes tenham acesso a servios remotos atravs de nomes identificadores de "alto-nvel" , em contraste com a identificao "baixo-nvel" oferecida pelo par "porta-endereo IP". Caso o servio seja replicado, ou migre, o cliente continua a acessar o servio de forma transparente. Na Internet o DNS [RFC 1035] o padro adotado para servio de nomes. Nesse texto, iremos apresentar: na seo 2.3.3, a classe java.rmi.Naming; na seo 2.3.4, as funcionalidades do Servidor de Lookup do Jini; e, na seo 2.4.6, o Servio de Nomes do CORBA. A seguir so apresentadas algumas tecnologias Java usadas para programao de sistemas distribudos: socket, servlet, RMI e Jini.
2.3. Tecnologias Java

Java uma linguagem de programao criada pela Sun Microsystems, anunciada oficialmente em 1995, com o propsito de se tornar a linguagem de programao preferida para a Internet. Essa pretenso est baseada em dois aspectos de Java. Primeiramente, o compilador Java gera cdigo para uma mquina hipottica, chamada Mquina Virtual Java. Este cdigo apresenta a caracterstica de ser interpretado. Dessa forma, o cdigo-objeto gerado pela compilao de um programa Java altamente portvel atravs de diferentes arquiteturas e sistemas operacionais. Basta que exista uma implementao da mquina virtual Java em um computador para que qualquer cdigo Java possa executar nele, sem a necessidade de uma recompilao. No contexto da Internet, onde a heterogeneidade das plataformas a regra, a portabilidade de cdigo-objeto, sem necessidade de recompilaes, uma vantagem importante. Outro aspecto que torna Java atraente e adequada para Internet o da prpria sintaxe da linguagem. Ela orientada a objetos, inclui suporte nativo para programao multithread e tratamento de excees, possui uma imensa biblioteca de classes que ajuda no momento de criar os aplicativos e possui um tratamento de tipos mais rigoroso do que, por exemplo, C++. Este texto no tem a pretenso de ensinar Java, algo capaz de ocupar milhares de pginas. O leitor interessado pode consultar os vrios livros existentes que tratam do assunto, como [Arnold 1997] e [Deitel 2001]. Java no apenas uma linguagem de programao. Ela cercada de diversas tecnologias que atendem a diferentes propsitos. Cada uma dessas tecnologias aparece na forma de bibliotecas e/ou programas auxiliares, criadas com um propsito especfico. Uma viso geral das tecnologias associadas com Java pode ser obtida na pgina http://java.sun.com/products. Das vrias tecnologias associadas com Java, trs delas so especialmente importantes para a programao de sistemas distribudos: Servlets, RMI e Jini. Cada uma delas ser tratada aqui. Porm, inicialmente ser mostrado como a linguagem suporta de maneira simples a construo de programas distribudos, usando um recurso de mais baixo nvel: a comunicao atravs de sockets.
2.3.1. Sockets em Java

O socket uma abstrao que representa um ponto de comunicao em uma rede de computadores [Harold 1997]. Para dois computadores trocarem informaes, cada um utiliza um socket. Tipicamente, um computador atua como servidor, abrindo o socket e ficando na escuta, a espera de mensagens ou pedidos de conexes. O outro computador assume o papel de cliente, enviando mensagens para o socket do servidor. Existem dois modos de operao: orientado a conexo, baseado no protocolo TCP (Transport Control Protocol) e sem conexo, empregando o protocolo UDP (User Datagram Protocol). Para usar sockets orientados a conexo, antes do envio dos dados necessrio o estabelecimento de uma conexo entre o cliente e o servidor. A conexo deve ser terminada ao final da comunicao e os dados chegam na mesma ordem que foram enviados. Quando sockets sem conexo so empregados, a entrega no garantida. Dados
podem chegar em ordem diferente da que foram enviados. O modo usado depende das necessidades da aplicao. Via de regra, o uso de conexo implica em maior confiabilidade, porm com maior overhead. Cada computador em uma rede TCP/IP possui endereo IP nico. Portas representam conexes individuais com esse endereo. Quando o socket criado, ele deve ser associado com uma porta especfica, isto , efetuar o seu binding. Para estabelecer uma conexo o cliente precisa conhecer o endereo IP da mquina onde o servidor executa e o nmero da porta que o servidor est escutando. Existe a tentativa de padronizao de alguns nmeros de portas com relao aos servios oferecidos pelo servidor, tais como: 7-echo, 13-daytime, 21-ftp, 23-telnet, 25-smtp, 79-finger, 80-http, 110-pop3. Estes nmeros de portas so definidos pela IANA (Internet Assigned Numbers Authority). A Figura 2.7 mostra o algoritmo bsico para clientes e servidores quando TCP usado. Em Java, clientes e servidores adotam procedimentos diferentes. Um socket cliente criado e conectado pelo construtor da classe Socket. Por exemplo:
clientSocket = new Socket(merlin.das.ufsc.br, 80);
A comunicao em si feita com o auxlio de classes tipo streams, que so classes do pacote java.io. Os clientes seguem sempre a mesma receita bsica: cria um socket com conexo cliente e utiliza classes que implementam streams para efetuar a comunicao. Existem diversas opes para sockets clientes, tais como definir o timeout usado no protocolo de desconexo, timeout utilizado em operaes de leitura, etc.
Inicia aplicao Cria o socket Cria o socket servidor Aceita conexo
Cria streams Conduz conversa
Cria streams Conduz conversa
Fecha streams e socket
Fecha streams e socket
Termina aplicao
No
mais
Sim
Figura 2.7. Comunicao utilizando sockets orientados conexo.
Servidores no criam conexes, eles esperam pelo pedido de conexo de um cliente. O construtor de ServerSocket usado, como em:
ServerSocket serverSocket = new ServerSocket(80, 5);
Um servidor pode receber vrias requisies de conexo ao mesmo tempo e as requisies so processadas uma a uma. A fila de requisies ainda no atendidas denominada pilha de escuta. O tamanho da fila de escuta indica quantas requisies de conexo simultneas so mantidas. Assim, na construo acima, o primeiro parmetro o nmero da porta a ser escutada e o segundo parmetro o tamanho da pilha de escuta. O valor default 50. O mtodo accept() chamado para retirar requisies da fila. Ele bloqueia o processo at a chegada uma requisio, e aps isso, retorna um socket conectado com o cliente. O objeto socket do servidor no usado, um novo criado para a transferncia dos dados. O socket do servidor continua enfileirando pedidos de conexo. Finalmente, streams so usados para a troca de dados. Um servidor simples processa uma conexo de cada vez. Entretanto, utilizando mltiplas threads, um servidor concorrente vai criar uma nova thread para cada conexo aberta e assim consegue processar vrias conexes simultaneamente. Por exemplo, servidores web comerciais so todos concorrentes. No caso de comunicao baseada em datagramas, a classe DatagramSocket usada tanto por clientes como por servidores. O servidor deve especificar sua porta, e a omisso do parmetro significa use a prxima porta livre. O cliente sempre utiliza a prxima. O algoritmo bsico mostrado na Figura 2.8.
Cria o socket datagrama Envia dados (solicitao) Inicia aplicao Cria o socket datagrama
Recebe dados
Recebe dados
Envia dados (resposta) No Fim?
No Fim? Sim Fecha socket Termina aplicao Sim
Fecha socket
Figura 2.8. Comunicao utilizando sockets orientados a datagrama
A classe DatagramPacket usada para enviar e receber dados. Ela contm informaes para conexo e os prprios dados. Para receber dados de um socket datagrama, o mtodo receive() bloqueia at a recepo dos dados. Para enviar dados para um socket datagrama necessrio um endereo, a classe InetAddress representa endereos na Internet. Por exemplo:
InetAddress addr = InetAddress.getByName(das.ufsc.br).
O envio de um string para um socket destinatrio feito atravs da montagem de um objeto DatagramPacket, o qual conter a mensagem e o endereo destino. Seu envio atravs do mtodo send() de objeto da classe DatagramSocket criado anteriormente pelo cliente.
2.3.2. Servlets
Servlets uma forma de programao distribuda em Java que utiliza abstraes de mais alto nvel do que o emprego direto de sockets. O servlet segue o modelo cliente-servidor e estende a funcionalidade de um servidor. Em particular, estende a funcionalidade de servidores HTTP. Neste caso, so utilizados para interagir com bancos de dados, gerar pginas dinmicas e manter informaes sobre uma sesso web em andamento. A Figura 2.9 ilustra a sua utilizao. Embora tenham sido concebidos com este contexto, possvel utiliz-los em outras situaes. Os pacotes relacionados com esta tecnologia so javax.servlet e javax.servlet.http.
Mquina Cliente Mquina Servidora Servidor HTTP
servlet servlet
Figura 2.9. Esquema bsico dos servlets. Servlets so semelhantes aos applets, mas executam do lado do servidor. So suportados pelos servidores HTTP mais conhecidos, como o servidor web da Netscape, o IIS da Microsoft e o servidor Apache. Na situao tpica, o cliente (provavelmente um navegador web) envia uma requisio HTTP para o servidor HTTP, o servidor recebe a solicitao e a repassa para o servlet apropriado. O servlet processa a requisio, incluindo aqui um possvel acesso a bancos de dados, e retorna os dados para o cliente, os quais envolvem documentos HTML, imagens, ou outros tipos de documentos usados no ambiente web. Todo servlet deve implementar a interface javax.servlet.Servlet. Muitos dos mtodos especificados nessa interface sero chamados pelo servidor que hospeda o servlet.
A interface composta pelos mtodos init() (automaticamente chamado uma vez para permitir a inicializao do servlet), service() (mtodo chamado com a solicitao de um cliente), getServletConfig() (deve retornar uma referncia para o objeto que implementa a interface ServletConfig, o qual fornece informaes de configurao), getServletInfo() (deve retornar um String que contm informaes tais como autor e verso) e destroy() (mtodo responsvel por liberar quaisquer recursos que tenham sido alocados pelo servlet durante sua execuo). O mtodo mais importante o service(), pois ele responsvel por implementar a funcionalidade do servlet. Seus parmetros so dois objetos stream que permitem receber dados do cliente (a requisio) e enviar dados para o cliente (a resposta). Existem duas classes abstratas includas nos pacotes relativos a servlets que fornecem uma implementao padro para facilitar a programao dos servlets. O programador pode partir dessas classes, e criar uma subclasse na qual sobrepe alguns dos mtodos da interface. As classes abstratas so GenericServlet e HttpServlet. A classe HttpServlet sobrescreve o mtodo service para fazer distino entre as operaes mais freqentes do protocolo HTTP. Dessa forma, o mtodo service analisa a requisio recebida e, conforme a operao, chama o mtodo apropriado. Por exemplo, a classe define mtodos como doGet(), doPost(), doDelete(), doOptions(), doPut() e doTrace(). Se o servlet a ser criado vai operar no contexto da web (quase sempre o caso), ento estender a classe HttpServlet mais vantajoso do que estender a classe GenericServlet. A partir do mecanismo geral descrito neste texto, os detalhes de programao incluem as interfaces e classes auxiliares, alm dos mtodos e parmetros utilizados. Por exemplo, vrias classes especficas so utilizadas como parmetros dos mtodos citados antes. Tambm existe suporte ao manuseio de "cookies", atravs da classe javax.servlet.http.Cookie, e suporte ao manuseio de informaes referentes sesso em andamento sem a utilizao de cookies, atravs da classe javax.servlet.http.HttpSession. Observe que o servlet pode utilizar os recursos do pacote JDBC de Java para acessar bancos de dados, quando isso for necessrio para atender as requisies recebidas. Informaes detalhadas de como programar servlets foge do objetivo deste texto. Elas podem ser encontradas, inclusive com exemplos de cdigo completos, em livros como [Deitel 2001].
2.3.3. RMI (Remote Method Invocation)

A invocao remota de mtodos permite que um objeto Java em um computador invoque o mtodo de outro objeto, em outro computador, como se fosse um objeto local. A tecnologia RMI est baseada na Chamada Remota de Procedimento (RPC - Remote Procedure Call), apresentada antes. A princpio, mecanismos para RMI podem ser implementados para qualquer linguagem orientada a objetos. No caso de Java, a grande vantagem est na homogeneidade. Por exemplo, como todas as mquinas virtuais Java representam os dados da mesma maneira, no existe a necessidade de converso de dados.
Alm disso, o mecanismo de serializao de objetos em Java permite que objetos completos sejam passados como parmetros de invocaes remotas. O principal propsito do RMI o mesmo do RPC: facilitar a programao de uma aplicao distribuda na medida que esconde do programador a maioria dos detalhes relacionados com a comunicao em ambiente distribudo. Uma vantagem do RMI-Java sobre outras solues, como CORBA, a construo de interfaces usando a prpria linguagem Java, sem a necessidade de uma linguagem separada para a descrio de interfaces. Em resumo, os passos para construir uma aplicao simples que utiliza RMI so trs. Inicialmente necessrio definir uma interface remota que descreve como o cliente e o servidor se comunicam um com o outro. Em seguida, necessrio criar o cdigo do programa servidor que implementa a interface remota definida antes. Finalmente, deve-se criar o programa cliente que, utilizando uma referncia da interface remota, invoca os mtodos da implementao remota da interface definida antes. Obviamente, uma vez definida a interface remota, os programas cliente e servidor podem ser desenvolvidos em paralelo. A interface remota define os mtodos remotos que o programa cliente poder invocar. Toda interface remota estende a interface java.rmi.Remote e inclui a declarao dos mtodos que sero suportados pelo objeto remoto. Basta um objeto implementar uma interface derivada da interface Remote para tornar-se apto a ter seus mtodos invocados remotamente, a partir de uma outra mquina virtual, com as devidas verificaes de segurana. Mtodos remotos esto sujeitos a problemas na comunicao entre diferentes computadores ou mesmo problemas na mquina que executa o objeto servidor. Em funo disso, todo mtodo remoto pode lanar uma exceo RemoteException e o objeto cliente deve estar preparado para isto. Por exemplo:
import java.rmi.*; public interface ServidorTempo extends Remote{ public java.util.Date getDate( ) throws RemoteException; }
A classe servidora dever implementar a interface remota. Ela deve estender a classe
java.rmi.server.UnicastRemoteObject, a qual serve de modelo para todos os
objetos que atuam como servidores remotos. O construtor dessa classe cuida dos detalhes de baixo nvel para permitir que o objeto receba conexes remotas atravs de sockets, e, portanto deve ser sempre chamado. Como ltima tarefa do lado servidor, necessrio definir o nome do objeto servidor, o qual ser usado pelos clientes para localiz-lo no momento de efetuar as invocaes remotas. O nome tem a forma:
//computador:porta/nome_objeto_remoto
onde computador e porta dizem respeito ao ponto de contato com o rmiregistry responsvel pela sua localizao e o nome_objeto_remoto refere-se ao nome do objeto servidor. O rmiregistry o programa servidor de nomes responsvel por fazer o mapeamento entre "nome_objeto_remoto" de um computador e o respectivo objeto executando sobre a mquina virtual local. O rmiregistry faz parte do pacote Java e est normalmente vinculado porta 1099 de cada computador onde existam objetos remotos executando. O objeto servidor deve fazer o seu registro perante o rmiregistry escolhido fornecendo o seu nome. A classe java.rmi.Naming usada para estabelecer o vnculo (bind) entre o nome escolhido e o objeto servidor propriamente dito, perante o rmiregistry em questo. O utilitrio rmic, parte do pacote Java, responsvel por criar uma classe stub apropriada para o objeto servidor em questo. Esta classe stub dever executar junto com o objeto cliente. Ela receber as invocaes de mtodo locais do objeto cliente e far a comunicao com a mquina servidora, usando o suporte RMI para fazer a invocao chegar ao objeto servidor. A verso 1.2 de Java gera apenas um stub para executar no lado cliente. Verses anteriores de Java utilizavam uma abordagem diferente. Antes de o objeto cliente poder fazer invocaes remotas ao objeto servidor, ele deve contactar o rmiregistry apropriado para localizar o objeto servidor. O rmiregistry apropriado, aquele que contm o registro do objeto servidor, identificado atravs do endereo de mquina (DNS ou IP) e o nmero da porta escutada (normalmente a porta 1099). O objeto servidor identificado por seu nome. A classe java.rmi.Naming fornece suporte para a localizao do objeto servidor. A partir do endereo e porta do rmiregistry e do nome do objeto servidor, ela no s localiza o objeto servidor em questo como tambm cria um proxy local que, deste momento em diante, ser usado pelo objeto cliente para obter os servios do objeto servidor. Todo o processo de envio de parmetros, retorno de resultados, comunicao via sockets, etc implementado pelas classes de suporte e pelo stub, sendo invisvel para o programador da aplicao. O grande poder do RMI reside na simplicidade do mecanismo usado pelo programador de aplicao para criar uma interface de comunicao entre objetos distribudos. A Figura 2.10 resume todo o processo. Uma observao importante deve ser feita. Quando um dos parmetros do mtodo remoto uma referncia para objeto, o que enviado para o mtodo remoto no uma referncia para o objeto na mquina cliente, mas sim uma cpia completa do objeto em questo. Para isto, o objeto passado como parmetro deve ser serializvel.
Escreve interface
Escreve cliente
Escreve servidor
Cliente.java
Servidor.java
javac
rmic
javac
Cliente.class
Servidor_Stub.class
Servidor.class
Servidor_Stub.class
rmiregistry
java Cliente Cliente
java Servidor Servidor
Figura 2.10. Mecanismo geral do RMI.
2.3.4. Jini
A concepo de Jini ([Sun 1999], [Sun 2001], [Edwards 2000]) partiu de uma viso do futuro que est se tornando realidade rapidamente. Esta viso do futuro est baseada na constatao que processadores continuaro a ficar mais rpidos, menores e mais baratos, ao menos pelos prximos anos. Memria tambm continuar a ficar mais rpida e mais barata. Dispositivos para entretenimento continuaro a aumentar a sua parcela digital. Como conseqncia, nos prximos anos, at mesmo os dispositivos mais simples podero conter um processador razoavelmente poderoso. Poderoso o bastante para executar uma verso simples de Java. Ao mesmo tempo, a velocidade das redes locais continuar a aumentar, e elas se faro presentes em todos os lugares, permitindo a conexo em rede de todos os dispositivos com computao embutida. possvel vislumbrar um mundo onde tudo estar conectado em rede. Embora isso j acontea em parte hoje nos escritrios, no futuro pode-se esperar este nvel de
conectividade tambm em hotis, lares, veculos, etc, alm de tornar-se mais intenso em ambientes de escritrio. possvel imaginar uma casa onde o aparelho de som, a televiso, o vdeo-cassete, o aparelho de DVD, o equipamento de segurana, o ar condicionado, os telefones fixo e celular, at mesmo a iluminao, o rdio-relgio e, claro, os microcomputadores e impressoras, formaro uma rede local. Entretanto, usurios buscam solues em rede que sejam simples e confiveis. Atualmente, a configurao de redes locais trabalhosa. Imagine, atualmente, o que necessrio para conectar uma impressora e um microcomputador na rede local do escritrio e fazer a configurao necessria para o computador usar a impressora. Projete agora esse esforo para a variedade de dispositivos citados antes, e sem qualquer ajuda de um especialista em informtica. A soluo atual no apropriada para o consumo em massa. O objetivo da tecnologia Jini simplificar a construo de sistemas distribudos. Os consumidores simplesmente conectam dispositivos fsicos na rede, ou instalam programas em seu computador e os servios que eles oferecem ficam automaticamente disponveis para todos os outros equipamentos e aplicaes da rede. Embora o espectro de utilizao de Jini seja imenso, aparentemente os primeiros segmentos de mercado que sero beneficiados por esta tecnologia so os fabricantes de dispositivos perifricos. Basicamente, Jini uma arquitetura para construo de aplicaes distribudas baseada em Java que, acima de tudo, facilita a integrao entre provedores de servios e consumidores de servios em uma rede local. Servio aqui possui uma conotao ampla. Vai desde um servio de impresso provido por uma impressora , at um algoritmo de traduo de lnguas implementado puramente em software. Assim, Jini pode ser concebido como um mecanismo de "plug-and-play" para servios em geral no ambiente distribudo. Em termos prticos, Jini aparece como um conjunto de classes e interfaces Java, acrescidos de alguns programas utilitrios e protocolos, cujo objetivo criar uma federao (ou comunidade) de mquinas virtuais Java. Pessoas, dispositivos, dados e aplicaes dentro da federao podem ser dinamicamente conectados uns aos outros para o fornecimento de servios (compartilhar informaes ou realizar tarefas). 2.3.4.1. Protocolos Jini A Figura 2.11 ilustra a infraestrutura associada com Jini. Um ambiente com diferentes arquiteturas de computadores e sistemas operacionais tornado homogneo atravs da execuo de mquinas virtuais Java. A tecnologia RMI fornece o mecanismo de comunicao entre programas executando em diferentes mquinas virtuais atravs da rede. Em seguida temos os trs mecanismos fundamentais de Jini, os protocolos para "Discovery", "Join" e "Lookup". Os servios (impresso, etc) so oferecidos acima desses, no nvel de aplicao.
Servio 1
... Lookup Join Discovery RMI
Servio N
MV Java Solaris Sparc
MV Java MAC PPC
MV Java Windows PPC
Figura 2.11. Arquitetura Jini. O elemento que define uma federao Jini o Servio de Lookup. O Servidor de Lookup deve executar em algum computador da federao e ele responsvel por manter a informao de "quais os servios disponveis nesta federao". Qualquer entidade, dispositivo, ou programa, querendo oferecer algum tipo de servio para os demais membros da federao deve se cadastrar no Servidor de Lookup. Esta operao de cadastramento recebe o nome de "join". Os clientes, por sua vez, consultam o Servidor de Lookup a procura de um servidor especfico. Esta consulta pode ser parametrizada de diferentes formas e corresponde a operao "lookup". Para que clientes e servidores possam efetuar respectivamente as operaes de "join" e "lookup", eles devem saber como contactar o Servidor de Lookup. A operao de descoberta do Servidor de Lookup chamada de "discovery". Nas prximas sees, cada uma dessas trs operaes fundamentais ser detalhada. 2.3.4.2. Discovery O propsito de Jini a formao ad-hoc de federaes. Clientes e servidores devem ser colocados em contato sem que exista nenhuma forma prvia de configurao. Por exemplo, ao conectar uma nova impressora ou um novo forno microondas na rede local eles devem automaticamente localizar o Servidor de Lookup dessa rede e fazer o seu cadastramento, oferecendo dessa forma os seus servios para os demais membros da federao. Da mesma forma, quando uma mquina fotogrfica conectada na rede e ela deseja contactar um servidor de impresso para imprimir algumas fotos, ela deve antes localizar um Servidor de Lookup para atravs dele localizar os servios de impresso disponveis naquela federao. A pergunta aqui : como um dispositivo ou um software recm conectado na rede local localiza o Servidor de Lookup ? Existem 3 formas. Quando uma aplicao ou servio ligado, ela pode utilizar o protocolo de difuso de pedido ("Multicast Request Protocol") que utiliza a capacidade de
difuso da rede local para mandar uma mensagem especfica indagando onde naquela rede local esto os Servidores de Lookup. Uma forma alternativa usar o protocolo de difuso de anncio ("Multicast Announcement Protocol"), quando o prprio Servidor de Lookup utiliza a capacidade de difuso da rede local para anunciar sua localizao. Finalmente, o protocolo de discovery direto ("Unicast Discovery Protocol") usado quando uma aplicao ou dispositivo conhece o endereo de rede do Servidor de Lookup a ser contactado. Este tipo de "discovery" especialmente til quando o servidor sendo cadastrado no se encontra na mesma rede local do Servidor de Lookup. O endereo do Servidor de Lookup definido na forma de uma URL, por exemplo:
jini://servlookup.das.ufsc.br
Vrios Servidores de Lookup podem existir simultaneamente na mesma rede, com o propsito de prover redundncia e um certo grau de tolerncia a faltas. importante observar que o Servio de Lookup , por si s, um servio. Logo, o prprio Servio de Lookup aparece como um servio cadastrado no Servidor de Lookup. O mecanismo de "discovery" nada mais que um mtodo simplificado de efetuar a operao "lookup" quando o servio procurado o prprio Servio de Lookup. Como resposta ao pedido de "discovery", o Servidor de Lookup envia uma classe Java que ser executada na mquina da entidade que fez o pedido. Esta classe ser usada pela entidade para acessar os servios do Servidor de Lookup. Em termos prticos, esta classe permitir a entidades do tipo servidor realizar a operao "join" junto ao Servidor de Lookup. Ao mesmo tempo, entidades do tipo cliente usaro esta classe para realizar a operao "lookup". Observe que, o cdigo original das entidades cliente e servidor no precisa conter o cdigo que implementa a comunicao com o Servidor de Lookup, pois este cdigo ser fornecido pelo prprio Servidor de Lookup como resposta ao pedido de "discovery". Este tipo de cdigo chamado na literatura de proxy. Tudo que as entidades cliente e servidor precisam conhecer antecipadamente a interface Java do proxy do Servidor de Lookup, a qual definida em sua forma mais bsica na especificao de Jini. Servidores de Lookup mais sofisticados que o bsico podem ser criados, mas sua interface Java dever sempre estender a interface padro. Dessa maneira, entidades que esperam encontrar apenas a interface bsica no tero problemas em usar uma classe que suporta uma interface mais elaborada, pois a interface bsica tambm ser suportada. A Figura 2.12 ilustra a operao "discovery". Espera-se que um dia a tecnologia Jini seja usada para conectar inclusive dispositivos simples como interruptores de luz. No caso de dispositivos simples demais para executar uma mquina virtual Java, possvel implementar a operao "discovery" e, em seguida, a prpria operao "join" de uma forma mais simples. Por exemplo, um programa escrito em C, gravado em ROM e embutido no dispositivo responsvel por conversar com o Servidor de Lookup e realizar as operaes. Ou ainda, um outro dispositivo com maior capacidade computacional pode fazer o cadastramento em nome de um dispositivo mais simples.
cliente ou servidor
servidor de lookup
pedido de discovery proxy para servidor de lookup new
proxy p/ servidor de lookup
Figura 2.12. Operao "discovery". 2.3.4.3. Join Uma vez concluda a operao de "discovery", uma entidade que deseja oferecer seus servios aos membros da federao pode fazer o seu cadastro no Servidor de Lookup, ou nos Servidores de Lookup, caso a operao de "discovery" tenha descoberto mais de um. A operao "join" consiste em efetuar o cadastro do servio oferecido, o qual ser identificado por um nome, por atributos, por uma interface Java suportada, e ser associado com um endereo de rede e uma ou mais classes Java, as quais funcionaro como um proxy, a ser executado nas mquinas virtuais das futuras entidades clientes. A Figura 2.13 ilustra a operao "discovery" seguida pela operao "join" por parte de um "servidor x" qualquer.
servidor x servidor de lookup
pedido de discovery proxy para servidor de lookup new
proxy p/ servidor de lookup
pedido de join (proxy p/ x) pedido de join (proxy p/ x)
Figura 2.13. Operao "discovery" seguida da operao "join".
2.3.4.4. Lookup Quando um cliente deseja contactar um servidor capaz de realizar determinado servio, ele realiza uma operao "lookup" junto ao Servidor de Lookup. A operao "lookup" basicamente o mapeamento de uma descrio do servio desejado, fornecida pelo cliente, para uma classe proxy, previamente fornecida pelo servidor capaz de realizar aquele servio. A descrio do servio desejado pelo cliente pode ter a forma atributos descritivos, tais como nome do servio e verso, ou ter a forma da interface Java a ser suportada pelo proxy e usada para acessar o servio em questo. Uma vez que o cliente obteve uma classe proxy para o servio desejado, ela instanciada na mquina virtual Java do cliente e a aplicao cliente passa a chamar os mtodos desse objeto local para obter o servio. Existem diversas formas pelas quais o proxy pode atender s requisies do cliente. A Figura 2.14 ilustra a operao "lookup" por parte de um "cliente y", e o subseqente acesso a um "servidor x" qualquer.
cliente y servidor Lookup servidor x
pedido de lookup(x) proxy para servidor x new proxy p/ servidor x
pedido de servio p/ x pedido de servio p/ x
Figura 2.14. Cliente usa "lookup" e proxy para acessar servidor. O proxy pode realizar ele mesmo o servio, quando o servio em questo for uma computao que no depende de dispositivos fsicos especficos e pode ser realizada na mquina cliente. O proxy pode ser um simples stub RMI, fornecendo uma porta para o acesso de mtodos Java que, executando na mquina servidora, so capazes de fornecer o servio solicitado. Esses mtodos podem acessar recursos fsicos especficos presentes na mquina servidora. Por fim, o proxy pode ser uma classe complexa, que executa parte do servio na prpria mquina cliente e solicita parte do servio para mtodos executando na mquina servidora. O protocolo entre o proxy na mquina cliente e o servidor na mquina servidora completamente ignorado pelo cliente, que conhece apenas a interface do
servio, suportada pelo proxy, uma classe local para o cliente. Neste ltimo caso o proxy pode at mesmo ser uma porta para acesso a objetos escritos em outras linguagens de programao, sendo usado CORBA como meio entre o proxy e o servidor que ele representa. As possibilidades so ilimitadas. Como o protocolo entre o proxy e o servidor ignorado pela aplicao cliente, diferentes solues podem ser criadas para um mesmo tipo de servio. Por exemplo, uma interface "Impressora" pode ser criada para definir os servios suportados por uma impressora de rede. A partir disso cada fabricante constri as suas impressoras, completamente diferentes entre si. Cada fabricante tambm escreve um proxy apropriado para cada impressora e cria um protocolo proprietrio para o seu proxy trocar informaes com a sua impressora. Uma ampla variedade de solues ignorada pela aplicao cliente, que se preocupa apenas em obter junto ao Servidor de Lookup um proxy capaz de suportar a interface "Impressora" e depois em chamar os mtodos dessa interface. A garantia de compatibilidade entre o proxy e a impressora obtida pelo fato da prpria impressora ter registrado o proxy (operao "join") junto ao Servidor de Lookup. Alguns proxy podem oferecer, alm de uma interface de programao, uma interface para o usurio. O proxy, ao executar na mquina cliente, pode apresentar uma interface grfica ao usurio e permitir que este usurio acesse diretamente os servios remotos. Neste caso, o programa cliente pode desconhecer completamente a funcionalidade associada com o servio, e simplesmente servir como um hospedeiro para o proxy, que faz todo o trabalho. Nesta configurao, o proxy muito semelhante a um applet, que cumpre o mesmo papel ao executar no navegador (cliente) e comunicar-se diretamente com a sua mquina de origem para suprir sua funcionalidade. A Figura 2.15, a Figura 2.16 e a Figura 2.17 ilustram todo o processo bsico de colocar um cliente e um servidor em contato.
Lookup Service
Servidor Lookup
<< discovery & join >> Mquina cliente

cliente y proxy p/ x interface servidor x
Mquina servidor
Figura 2.15. Situao antes do "discovery" e "join" do servidor.
Lookup Service << discovery & lookup >>

Servidor Lookup proxy p/ x

cliente y proxy p/ x interface servidor x
Mquina servidor
Figura 2.16. Situao aps o "join" e antes do "lookup".

Lookup Service << discovery & lookup >>
Servidor Lookup proxy p/ x

cliente y proxy p/ x interface
Mquina servidor
proxy p/ x
<<protocolo qualquer>>
servidor x
Figura 2.17. Situao aps o "lookup".
2.3.4.5. Outros mecanismos de Jini Alm das operaes de "discovery", "join" e "lookup", a infra-estrutura Jini disponibiliza outros recursos para o desenvolvedor de aplicaes distribudas. Esta seo descreve rapidamente as facilidades para "leasing", "eventos distribudos" e "transaes distribudas", depois conclui com alguns comentrios gerais. Atravs do mecanismo denominado "leasing" um dispositivo ou programa servidor registra-se no Servio de Lookup por tempo limitado, especificado no momento da operao "join". Quando o prazo definido esgota-se, o dispositivo ou programa deve renovar o seu cadastramento. Se, por alguma razo, o dispositivo ou programa torna-se indisponvel, seu registro ser automaticamente removido do sistema aps o prazo especificado. O fato das entradas sem valor do Servio de Lookup serem removidas depois de algum tempo torna o sistema "auto-limpante". O mecanismo tem esse nome pois considerado que o servidor "aluga" espao no Servidor de Lookup para fazer o seu registro por um perodo de tempo. Se ele no renovar o aluguel, ser despejado, ou seja, seu registro ser removido e o espao liberado. Jini tambm inclui uma API para facilitar a construo de aplicaes distribudas baseadas na idia de eventos. O mesmo mecanismo de eventos usado na construo de JavaBeans e presente nas Java Foundation Classes estendido para o ambiente distribudo. Eventos podem ser usados, por exemplo, para permitir que um Servidor de Lookup notifique um dado cliente quando o servidor que aquele cliente estava esperando finalmente executou a operao "join" e ingressou na federao. O pacote Jini tambm inclui uma API para gerenciar transaes distribudas, o qual usa a tcnica clssica de confirmao em duas fases (two-phase commit). Transaes facilitam a construo de aplicaes distribudas com relacionamentos complexos entre vrios objetos distribudos. Jini no inclui nenhuma preocupao com segurana e controle de acesso. A filosofia bsica que qualquer mquina virtual Java que tenha acesso ao Servidor de Lookup pode usufruir os servios registrados nele. claro que esquemas de autenticao e controle de acesso podem ser empregados pelos Servidores de Lookup ou diretamente por servidores especficos, mas esta questo no abordada pelo pacote Jini e deve ser tratada como algo a mais, parte da aplicao. Na verdade, Jini perde muito do seu apelo quando consideraes sobre controle de acesso devem ser feitas. Jini funciona melhor em ambientes onde uma rede local define a federao e todos os servios registrados esto disponveis para todas as aplicaes dentro dos limites da federao, como em um escritrio ou uma residncia. Embora existam crticas sobre a escalabilidade de Jini em termos, por exemplo, da Internet, o seu propsito principal sempre foi facilitar a conexo entre componentes distribudos no contexto de uma rede local, o que feito sem problemas. Na API de Jini existe suporte para o conceito de grupo. Durante a operao "discovery" um servidor ou cliente pode especificar os grupos que ele gostaria de localizar. O resultado da operao "discovery" retornar apenas os Servidores de Lookup que suportam os grupos solicitados. O conceito de grupo pode ser usado para criar uma diviso
interna no caso de federaes muito grandes. Entretanto, no existe nenhum controle de acesso embutido em Jini e na maioria das vezes espera-se que a diviso em grupos seja ignorada e todos os componentes refiram-se ao grupo default (sem nome). Finalmente, Jini uma tecnologia Java, isto , feito para o mundo Java, e no para ser usado em outros ambientes. Jini implementa algo similar a um "plug-and-play" para aplicaes distribudas, onde os elementos conectados podem ser dispositivos fsicos como impressoras e videogames, ou aplicaes como tradutores e compactadores. Todo o mecanismo est baseado na capacidade do cliente obter dinamicamente um proxy que ser executado localmente, fato que enormemente facilitado pelo ambiente confortvel criado por uma nica linguagem de programao e por um conjunto homogneo de mquinas virtuais.
2.4. Especificaes CORBA

2.4.1. Introduo
Nos ltimos anos, a rea de sistemas distribudos tem avanado na direo da padronizao aberta. Esta tendncia vem no sentido de combater solues proprietrias que determinam sempre altos custos em desenvolvimento de sistemas. Sistemas abertos abrangem um significante leque de tecnologias e especificaes que, de forma diversa aos ambientes proprietrios, permitem solues mais adaptadas complexidade e heterogeneidade de sistemas distribudos. As especificaes CORBA (Commom Object Request Broker Architecture) foram criadas com o objetivo de permitir que as dificuldades existentes na programao em ambientes distribudos sejam superadas. Seu conjunto de especificaes abertas padronizadas pela OMG2 (Object Management Group) [OMG 1998] j se consolidou como um padro para sistemas distribudos. A utilizao das especificaes CORBA cobre s necessidades de reduo de custos, portabilidade, interoperabilidade e flexibilidade nos sistemas contemporneos. Esta seo introduz uma reviso geral de objetos distribudos em sistemas abertos, dando nfase s especificaes OMG.
2.4.2. Arquitetura CORBA

As especificaes CORBA definem um conjunto de mecanismos padronizados e de conceitos para construir objetos distribudos. Segundo essa arquitetura, mtodos de objetos remotos podem ser ativados de forma transparente em ambientes distribudos heterogneos atravs de um ORB (Object Request Broker). O ORB, num sentido mais genrico, um canal de comunicao para objetos distribudos que interagem entre si usando o modelo de interaes cliente-servidor. Objetos distribudos encapsulam estados e se fazem acessveis
uma organizao formada por centenas de empresas com o objetivo de especificar um conjunto de padres e conceitos para a programao orientada a objetos em ambientes distribudos abertos.
2
atravs de uma interface bem definida, construda a partir de uma linguagem de definio de interfaces (IDL: Interface Definition Language). Usando CORBA possvel tambm obter interoperabilidade entre objetos desenvolvidos em diferentes linguagens de programao (C, C++, Ada, Cobol, Java, etc.), onde as diferenas entre as mesmas so ocultadas atravs do mapeamento adequado da IDL para a linguagem de programao desejada. A IDL uma linguagem declarativa, sem nenhuma estrutura algortmica, com sintaxes e tipos predefinidos, baseados na linguagem C++. O uso desta linguagem de definio de interface permite tratar das heterogeneidades do ambiente computacional que incluem, alm das diferenas de linguagens de programao, tambm o trato com diferentes tipos de mquinas e sistemas operacionais.
2.4.3. O modelo de objetos

Esta seo apresenta a terminologias e os aspectos conceituais do modelo de objetos definido pela OMG [OMG 1998]. Um sistema de objetos uma coleo de objetos que isola os requerentes do servio (os clientes) dos provedores dos servios (os servidores) atravs de interfaces bem definidas. Um cliente no necessariamente um objeto faz requisies a um objeto servidor. Uma requisio pode ser interpretada como um evento que ocorre em um instante de tempo particular, provocando um processamento no servidor. Esto associadas a uma requisio, as informaes sobre o endereo do objeto alvo, sobre a operao requisitada e sobre os parmetros associados operao. Neste modelo, os objetos s podem ser criados ou destrudos por meio de requisies. Isso se deve ao fato de no existirem mecanismos de construtores e destrutores nas especificaes IDL/CORBA como em algumas linguagens de programao orientadas a objetos. A criao de um objeto por um cliente materializada na forma de uma referncia de objeto que denota o novo objeto. Uma referncia de objeto , basicamente, um identificador associado a um objeto particular. Especificamente, uma referncia de objeto identificar o mesmo objeto cada vez que a mesma usada numa requisio. Contudo, um objeto pode ser identificado por diferentes referncias de objeto. Todo objeto deste modelo disponvel a seus clientes atravs de sua interface, que descreve um conjunto de operaes (mtodos) que podem ser requisitados pelos clientes. Um objeto satisfaz a uma dada interface se especificado de forma que possa atender a cada requisio de execuo de mtodos definidos na sua interface. O uso da interface permite ocultar do cliente os aspectos relacionados implementao do servio (mtodos do objeto servidor). Mudanas na forma de implementar um servio no implicam, necessariamente, na alterao da interface deste servio, no provocando, dessa forma, qualquer nus ao cliente. O conceito de interface est diretamente relacionado ao conceito de classe no modelo tradicional da programao orientada a objetos. De forma similar s classes, no modelo de objetos da OMG permitido aplicar tcnicas de encapsulamento, herana e polimorfismo.
2.4.4. A arquitetura OMA

O objetivo da OMG permitir o crescimento da tecnologia a objetos e influenciar sua direo no sentido de cumprir os requisitos e conceitos estabelecidos na OMA (Object Management Architecture). A arquitetura OMA fornece uma infra-estrutura conceitual para todas as especificaes da OMG. As regras definidas por esta arquitetura de referncia visam auxiliar a construo de componentes de software interoperveis, reutilizveis e portveis. Esta arquitetura composta de quatro principais elementos (Figura 2.18): o ORB, os objetos de servio, as facilidades comuns e os objetos da aplicao.
A p lic a e s D is t r ib u d a s
A u to m a o
CSCW
R e s e rv a d e v o
........
C o n t. d e E s to q u e
S i m u la a o
P r o je t o C A D
........
F a c ilid a d e s C O R B A V e r t ic a l
C o n t a b ilid a d e
D e s e n v o lv i m e n t o d e A p li c a e s
M e d ic in a
S u p e r v ia d a in f o r m a o
s e g u ra n a
T e le c o m u n icaes
T e m po -re a l
S im u la o D is t r ib u d a
M e t a - o b je t o s
M a p e a m e n to
M a n u f a tu r a
I n t e r n a c i o n a liza o
P ro du o e e x p lo r a o d e le o e g s
........
R e p lic a o
F a c ilid a d e s C O R B A H o r iz o n t a l
In te r fa c e d o u s u r io
C o m p o s i o d a a p r e s e n ta o
G e r e n c ia m e n to d e in fo r m a o
M o d e la m e n t o
A r m a z e n a m e n to e re c upe ra o
G e r e n c ia m e n to d e s is te m a
C o n s is t n c ia
G e r e n c ia m e n to d e ta r e fa
A g e n te s
C o le o
C u s t o m iz a o
C o le o d e da do s
P o l t i c a
A u to m a o
G e r e n c ia m e n t o d e d e s k to p
G e r e n c ia m e n t o d e r e n d e r in g
S c r ip t in g
T ro c a de c o m p o s i o
T ro c a de da do s
T ro c a de in f o r m a o
Lanar pro c e s s o s
Q u a lid a d e d e s e r v i o
R e gra s
W o r k f lo w
E v e n to s
I n s t n c ia
In s tr u m e n ta o
E s c a lo n a m e n t o
S u p o rte a o u s u rio
R e p r e s e n ta o e e n c o d if ic a o
O pe ra e s de te m p o
S e gura n a
S e r v i o s d e O b je t o C o m u m ( C O S S )
N omeao
E v e n to s
C ic lo d e v id a
P e r s is t e n t e
T ra ns a o
C o n c o r r n c ia
R e la c io n a m e n t o
E x t e r n a liz a o
C o n s u lt a
S e gura n a
In te r - tr o c a
G e r e n c ia m e n t o
L ic e n c ia m e n t o
T ra d e r
C o le o
R e p lic a o
P r o p r ie d a d e
........
........
T em po
O b je c t R e q u e s t B r o k e r ( O R B )
S is t e m a O p e r a c io n a l e S e r v i o s d e R e d e
Figura 2.18. Arquitetura OMA (Object Management Architecture).
2.4.5. Estrutura do ORB

As especificaes CORBA definem um broker: o ORB que implementa abstraes e semnticas da comunicao entre objetos em um sistema distribudo (Figura 2.19). O ORB fornece os mecanismos de representao de objetos e de comunicao para que seja possvel o processamento das requisies no lado servidor em um ambiente computacional aberto. O ORB, num sentido mais genrico, pode ser entendido como uma via de comunicao para que objetos heterogneos possam interoperar.
Implementao do Objeto Cliente
Repositrio de Interfaces
Repositrio de Implementaes
Stub de Invocao Dinmica
Stubs IDL (esttica)
Interface do ORB
Esqueleto IDL (esttica)
Esqueleto de Adaptador Invocao de Objeto Dinmica
Ncleo do ORB
Figura 2.19. Arquitetura CORBA (Common Object Request Broker Architecture). As interaes no ambiente CORBA, seguindo o modelo cliente/servidor, utilizam primitivas de um mecanismo de RMI (Remote Method Invocation) nas interaes deste modelo. A grande diferena do RMI em relao ao tradicional RPC (Remote Procedure Call) est no fato que mtodos remotos devem dar suporte a passagem de objetos como argumentos e resultados de mtodos. As stubs (stubs e esqueletos IDL no modelo CORBA) necessrias que implementam o RMI so geradas a partir da traduo da interface IDL do servidor. Uma chamada do cliente de um mtodo de um servidor remoto (requisio do cliente) ento transmitida atravs da rede usando estas stubs que executam a serializao/deserializao (marshalling/unmarshalling) de parmetros e objetos, lidando com as transformaes de uma chamada em uma mensagem correspondente e vice-versa. O ORB, em uma chamada de cliente, atravs de seu ncleo, localiza o objeto remoto, transporta os dados e transfere o controle para a Implementao do Objeto servidor atravs do Esqueleto IDL correspondente. Quando o processamento da requisio termina, os resultados so retornados para o ORB, que os entrega ao cliente de forma transparente da localizao do servio. Para executar a requisio, a Implementao de Objeto suportada por alguns servios do ORB, disponveis atravs do Adaptador de Objetos. O Adaptador de Objetos se situando no topo dos servios de comunicao do ncleo de ORB, alm de passar requisies, fornece os servios ORB: gerao e interpretao de referncias de objetos, invocao de mtodos, ativao e desativao de objetos, mapeamento de referncias de
objetos para implementaes de objetos, registros de implementaes, etc. As especificaes definem um Adaptador de Objetos Portvel (POA - Portable Object Adapter), que pode ser usado pela maioria dos objetos que possuem implementaes convencionais. Algumas implementaes de objeto podem ter requisitos especiais, exigindo adaptadores de objeto especficos. Nada impede implementadores de estender o POA ou de desenvolverem adaptadores mais adequados s suas necessidades. A Interface do ORB, segundo as especificaes CORBA, deve ser idntica para as diferentes implementaes CORBA. Devido ao fato que a maioria das funcionalidades necessrias ao funcionamento das interaes da aplicao serem oferecidas atravs dos adaptadores, stubs e dos skeletons, nesta interface oferecida apenas um pequeno nmero de operaes que so comuns tanto a clientes como a implementaes de objetos. Esta interface do ORB acessada diretamente por objetos cliente e servidor. Na requisio de um servio, o cliente pode realizar uma invocao no servidor de duas formas: esttica atravs de Stubs IDL ou dinmica atravs da interface de invocao dinmica (DII). Em ambas abordagens a implementao do objeto (o servidor) desconhece o tipo de invocao utilizada na requisio pelo cliente. Na invocao esttica, o cliente faz a invocao de um mtodo no objeto servidor se utilizando de Stubs IDL apropriados, gerados no processo de compilao do arquivo de definio de interface IDL correspondente. Esta stub pode ser entendida como uma representao local do objeto remoto. Para invocaes dinmicas, as interfaces de objetos disponveis via CORBA devem estar armazenadas no sistema (repositrio de interfaces). Uma invocao dinmica permite ao cliente dinamicamente construir e invocar mtodos no servidor usando interfaces DII. Este tipo de chamada oferece uma grande flexibilidade para sistemas dinmicos: o cliente determina o objeto a ser invocado, o mtodo a ser executado e o conjunto de parmetros desse mtodo, em tempo de execuo, atravs de uma seqncia de chamadas. A Figura 2.20 ilustra esta seqncia de chamadas feitas no repositrio de interfaces e na interface DII.
1 . O b tm o nom e d a inter fa c e d o ob jeto: o b j.g e t_ in te rfa c e () 2 . O b tm a d esc ri o d os m tod o: lo o k u p _ n a m e () d e sc rib e () 3 . C ria a lista d e ar g um e ntos: c re a te _ list() a d d _ a rg ()... a d d _ a rg ()... .........a g g _ a rg ()
R e p o s it r io d e in t e r fa c e s
o b je to
4 . C r ia a re q uisi o: cre a te _ re q u e s t(O b je c t R e fe re n c e , M e th o d s , A rg u m e n ts L is t) 5 . Inv oca o m tod o re m oto in v o k e (...)
Figura 2.20. Construo de uma chamada atravs da DII O Repositrio de Interfaces contm informaes de interfaces IDL em uma forma disponvel em tempo de execuo para as invocaes dinmicas. Usando a informao disponvel no repositrio possvel a um programa encontrar um objeto remoto mesmo desconhecendo sua interface, seus mtodos e parmetros, e sua forma de ativao. J o Repositrio de Implementaes (Figura 2.19) contm informaes que permitem ao ORB localizar e ativar implementaes de objetos.
2.4.6. Objetos de servio COSS

Para o desenvolvimento de aplicaes de objetos distribudos, a OMG oferece um conjunto de servios oferecendo funcionalidades bsicas para compor ou dar suporte aos objetos da aplicao. No padro CORBA, essas funcionalidade adicionais so providas como objetos de servio, isto , objetos CORBA com interfaces IDL bem definidas. Por exemplo, a concorrncia e a persistncia que so necessrias em algumas aplicaes no so includas pela OMG como mecanismos do ncleo do ORB. Esses servios e muitos outros so padronizados pela OMG, dentro da arquitetura OMA (Figura 2.18), na forma de objetos de servio de servios ou COSS (Common Object Services Specifications) [OMG 1997a]. Esta coleo de servios (interfaces de objetos) pode ser entendida como uma extenso ou uma complementao das funcionalidades do ORB. A definio destes servios padronizados foi a forma encontrada pela OMG para no estender o ORB ou
introduzir novos adaptadores de objetos quando da necessidade de aumentar funcionalidades de middleware. Uma especificao de objeto de servio usualmente consiste de um conjunto de interfaces e de uma descrio do comportamento do servio, que podem ser utilizados por objetos de aplicao e outros objetos de servio. A sintaxe usada para especificar as interfaces a OMG IDL. A semntica que especifica o comportamento do servio expressa, em geral, em termos de objetos, operaes e tipos de dados padronizados [OMG 1997a]. A OMG tem definido at agora vrios COSS, tais como: Servio de ciclo de vida, que define servios e convenes para criar, destruir, copiar e mover objetos. Devido aos ambientes baseados no CORBA suportar objetos distribudos, este servio define servios e convenes que permitem ao cliente realizar operaes nesse servio remotamente; Servio de persistncia, que introduz uma interface nica para salvar estados persistentes dos objetos em servidores de armazenamento, incluindo objetos de base de dados. O estado do objeto considerado composto de duas partes: o estado dinmico que est tipicamente na memria e que envolve informaes que no necessariamente devem ser preservadas e o estado persistente que contm as informaes necessrias para reconstruir um estado dinmico. Servio de nomes, que determina as necessidades para a implementao e administrao de nomes e seus contextos em ambientes CORBA. Objetos a partir de um ORB localizam objetos remotos por nomes, mesmo que localizados em outros ORBs. Uma associao entre nome (nome simblico) e uma referncia de objeto chamada de name binding. Neste caso, um name context pode ser visto como um objeto que contm na sua representao um conjunto de name bindings. Em um contexto de nomes cada nome nico. Diferentes nomes podem designar um mesmo objeto no mesmo ou em diferentes contextos simultaneamente. A Figura 2.21 ilustra a organizao de um objeto NamingContext definido na especificao Cosnaming servio de nomes do CORBA.
NamingContext
(Turma, refobj2) (Banco, refobj1) (Banco1, refobj1) (Conta, refobj4) (Aluno, refobj3)
Figura 2.21. NamingContext no CosNaming O servio de nomes no CORBA pode usar contextos federados (federated naming contexts), fornecendo desta maneira, um suporte hierarquizado para gesto de contextos e nomes em sistemas distribudos.
Nas especificaes CORBA uma referncia de objeto definida numa forma padro conhecida como IOR (Interoperable Object Reference). A IOR [OMG 1998] uma seqncia de caracteres que quando convertida para o formato adequado fornece as informaes de endereo IP da mquina, a porta, um ponteiro local para o objeto a ser acessado e algumas informaes de controle relacionadas com a prpria IOR. Cada objeto distribudo deve ter sua prpria IOR registrada em um NamingContext. Com isto o cliente necessitando da IOR de um objeto servidor deve, atravs do envio do nome simblico do mesmo, obt-lo no NamingContext onde este objeto foi registrado. A Figura 2.22 apresenta um diagrama temporal separando em fases os procedimentos no suporte dado pelo servio de nomes s interaes cliente/servidor.
o b jre f re so lv e (b an c o ); C lien te 4 5 6
S e rv id o r H T T P : IO R d o S N 1
N a m in g C o n te xt
S e rv id o r d e a p lic a o
3 b in d (b a n c o ,o b jre f);
Figura 2.22. Interaes para resoluo de nomes no CORBA. Um objeto NamingContext na sua iniciao (passo 1 da Figura 2.22) deve colocar a sua prpria IOR num repositrio (por exemplo, servio de diretrios, servidor http, ou ftp) ), tornando-a disponvel a objetos CORBA em geral para que possam ter acesso ao mesmo. No exemplo da figura, o NamingContext tem a sua IOR disponvel atravs de um servidor http, o que facilitaria o acesso ao mesmo via Internet. Uma vez o NamingContext em execuo, objetos para se tornarem visveis via CORBA registram suas IORs neste servio de nomes. Todo objeto servidor ento, quando de sua iniciao registra a sua IOR em um NamingContext. Para isto necessrio buscar a IOR do NamingContext (passo 2 da figura), o que feito com o mtodo resolve_initial_reference do servios da interface ORB. Aps obter a IOR do NamingContext o servidor de aplicao pode invoc-lo para se registrar (passo 3). Os procedimentos de um cliente para viabilizar a sua comunicao com o servidor de aplicao devem iniciar com a obteno da IOR do NamingContext usando o mtodo resolve_initial_reference (passo 4 da Figura 2.22). Com a posse dessa IOR (disponvel em servidor http), o cliente usando o nome do objeto servidor invoca o NamingContext, pedindo a resoluo do nome (passo 5 da figura). Se nome existir dentro do contexto indicado, o servio de nomes retorna a IOR associada ao nome enviado. A partir da o cliente obtm o binding desejado podendo fazer as invocaes ao servidor de aplicao (passo 6 da figura).
O servio de notificao de eventos (CosEventComm) define uma outra forma de comunicao. O servio define um objeto canal de eventos que coleta e distribui eventos entre os componentes atravs do ORB, que desacopla as comunicaes entre objetos cliente e servidor (comunicao assncrona). O servio define duas funes: a de fornecedor de eventos e a de consumidor de eventos. Os objetos podem registrar dinamicamente seus interesses em termos da recepo de eventos especficos, assumindo ento o papel de consumidores. Os eventos so produzidos pelo fornecedor de eventos. Neste servio so definidas duas abordagens: os modelos Pull e Push. O modelo Push permite ao fornecedor do evento iniciar a transferncia do evento ao consumidor. J o modelo Pull caracteriza as transferncias a partir de requisies dos consumidores. A Figura 2.23 ilustra o modelo Push.
F o rn e c e d o re s d e E v en to s
C o n s u m i d o re s d e E v en to s
S e rv i o de E v en to s
Figura 2.23. Servio de eventos atuando segundo a abordagem Push Servio de tempo: este COSS define as interfaces de um servio de tempo global para ambientes normalmente distribudos e heterogneos. Este servio importante, por exemplo, na ordenao dos eventos que ocorrem no sistema. Pode ser usado tambm para disparar eventos em valores de tempo especificados atravs de mecanismos de temporizao e alarmes ou ainda, para computar intervalos de tempo entre eventos. A representao de tempo deste servio segue o padro UTC (Universal Time Coordinated).
COSS6
Servio de Tol. a Falhas Servio de Tempo Real
COSS1
Servio de Ciclo de vida Servio de Nomes Servio de Persistncia Servio de Eventos
COSS4
Servio de Consulta Servio de Licenciamento Servio de Propriedades
COSS5
Servio de Trader Servio de Colees
COSS2
Servio de Transao Servio de Concorrncia Servio de Relacionamento Servio de Externalizao
COSS3
Servio de Segurana Servio de Tempo
Figura 2.24. A coleo dos COSS definidos at o presente momento pela OMG.
Existem outras especificaes de servios COSS a Figura 2.24 apresenta os grupos destes servios. Algumas destas sero retomados na seqncia deste texto.
2.4.7. Facilidades comuns

As facilidades comuns so uma coleo de servios de propsitos gerais utilizados pelas mais diversas aplicaes. As facilidades comuns so divididas segundo dois aspectos, as facilidades comuns horizontais e as facilidades comuns verticais (Figura 2.18). As facilidades horizontais podem ser utilizadas por diferentes aplicaes, independente da rea da aplicao, so divididas segundo quatro categorias: interface de usurio, gerenciamento de informao, gerenciamento de sistema e gerenciamento de tarefa. As facilidades verticais so utilizadas em reas de aplicao especificas, por exemplo: gerenciamento e controle de imagens, supervias de informao, manufatura integrada por comutador, simulao distribuda, contabilidade, etc.
2.4.8. Interoperabilidade entre ORBs

Nas primeiras especificaes CORBA no estavam claras a forma de como garantir a interoperabilidade entre objetos pertencentes a diferentes implementaes de ORBs. A poltica da OMG a padronizao do CORBA e seus servios, na maioria das vezes, apenas em nvel de interface, deixando em aberto aos programadores de middleware as escolhas referentes a parte da implementao. Este fato tornou difcil garantir a interoperabilidade entre objetos em diferentes implementaes de ORB sem a padronizao de um protocolo de comunicao e da sintaxe de transferncia das mensagens que deveriam circular entre estes ORBs. Para suprir esta necessidade, a OMG publicou o padro CORBA 2.0, nestas especificaes foram introduzidos os seguintes protocolos (Figura 2.25): Protocolo Inter-ORB GERAL (GIOP): que especifica um conjunto de formatos para dados a serem transferidos nas comunicaes entre ORBs; Protocolo Inter-ORB Internet (IIOP): que especifica como mensagens GIOP so transmitidas numa rede TCP/IP (GIOP + TCP/IP = IIOP); Protocolo Inter-ORB para Ambientes Especficos (ESIOPs): que uma especificao feita para permitir a interoperabilidade de um ORB com outros ambientes de middleware (por exemplo, DCE).
D o m n io O R B
D o m n io O R B
IIO P
D C E - G IO P
H a lf B r id g e
IIO P
IIO P
H a lf B rid g e
O u tro s p ro to c o lo s
Figura 2.25. Interoperabilidade entre ORBs Para comunicaes de um objeto em ambientes CORBA com outro ambiente no-CORBA foi introduzida a noo de Half Bridge. Este mecanismo faz o mapeamento que transforma uma requisio expressa em termos do modelo origem para o modelo do domnio destino, permitindo que chamadas atravessem estes domnios. A idia deste mapeamento est centrada na converso do formato de mensagens de um domnio no-CORBA para o GIOP permitindo, ento, que estas possam ser transmitidas atravs do protocolo IIOP (domnio CORBA), e vice-versa. Na verso 2.0 do CORBA tambm foi acrescentada a interface Skeleton dinmica (DSI) que utilizada para a interconexo de ORBs distintos. Quando o POA recebe uma invocao para uma implementao de objeto que no tem um Skeleton pr-compilado (abordagem esttica), esta invocao passada para a interface de Skeleton dinmica que ativa a DII de um outro ORB que possua este Skeleton onde ser feita a invocao; isto caracteriza a interoperabilidade chamada nas especificaes de Bridge Request-Level (Figura 2.26) . A outra forma de interoperabilidade atravs da abordagem Bridge In-Line na qual a ponte implementada dentro do ncleo do ORB (Figura 2.27).
C lie n t e
D II
S e r v id o r
Servios do O RB Ncleo do O RB X
Servios do O RB Ncleo do O RB Y
Figura 2.26. Formas para interoperabilidade entre ORBs: Bridge request-level.
C lie n t e
D II DSI
B r id g e
S e rv id o r
D II
Servios do O RB Ncleo do ORB X
Servios do ORB Ncleo do O RB Y
Figura 2.27. Formas para interoperabilidade entre ORBs: Bridge In-Line.
2.4.9 Programando com CORBA IDL

Como citado anteriormente, a IDL (Interface Definition Language) uma linguagem declarativa, com sintaxes e tipos predefinidos, baseada na linguagem C++. Sendo uma linguagem de descrio de interface a sua funo gerar todo o suporte RMI que permitir a chamada de mtodos remotos. Os principais elementos que compem uma IDL so: mdulos (modules), interfaces, tipos de dados, constantes, atributos, operaes e excees.
module <identificador> { <declaraes de tipos>; <declaraes de constantes>; <declaraes de excees>; interface <identificador> [:<herana>] { <declaraes de tipos>; <declaraes de constantes>; <declaraes de atributos>; <declaraes de excees>;
define um contexto de nome
define uma classe CORBA
define um mtodo
[<tipo operador>] <identificador>(<parmetros>) [raises exceo] [context]; ... } interface <identificador> [:<herana>] ... }
Figura 2.28. Declaraes IDL.
Os tipos de dados da IDL devem ser mapeados nos tipos da linguagem alvo, ou seja, mapear nos tipos da linguagem usada na programao da aplicao. A IDL suporta tipos bsicos (short, long, float, boolean ,...), tipos derivados (array, sequences e string; construdos com o uso da palavra chave typedef), tipos estruturados (enum, struct, union) e tipos variveis (arrays dinmicos, string) e o tipo Any que aporta uma certa flexibilidade. A declarao module descreve os objetos (interfaces) que compem a aplicao. Cada objeto ter suas interfaces descritas, com seus atributos e mtodos sendo declarados segundo a sintaxe apresentada na Figura 2.28. A Figura 2.29 ilustra a obteno dos binrios do cliente e servidor a partir de uma declarao de interface IDL e dos cdigos dos objetos cliente e servidor. A traduo da especificao de interface pelo compilador IDL gera os stubs na linguagem alvo que ligados com os cdigos de aplicao ao serem compilados devem gerar os binrios correspondentes ao cliente e servidor. O compilador IDL gera tambm na linguagem alvo as interfaces dos objetos, cabendo ao programador preencher o corpo dos mtodos.
E s p e c if ic a o d o s e r v id o r
A r q u iv o I D L
E s p e c if ic a o d o c lie n t e
C o m p ila d o r I D L
C d ig o d o c lie n t e
S tu b ID L
S k e le t o n ID L
C d ig o d o s e r v id o r
R e p o s it r io d e in t e r f a c e
C lie n t e 0101000 1010100 0011010
B ib lio t e c a s d o O R B e c o m p ila o
S e r v id o r 0101000 1010100 0011010
Figura 2.29. Gerao dos binrios do cliente e servidor Basicamente, a partir de uma especificao do servidor, o programador escreve as classes de objetos do servidor em IDL [Orfali 1998]. Esses arquivos IDL formam uma espcie de contrato entre os clientes do servio e o provedor do servio, pois descrevem todos os servios (mtodos e atributos) que so exportados e visveis para os potenciais clientes, e descrevem a forma que esses servios podem ser acessados. Esses arquivos IDL precisam ser compilados pelos clientes e servidor antes de serem usados. O compilador IDL ir mapear as descries em IDL para a linguagem usada pelo cliente ou servidor. Por exemplo, o programador do servidor pode usar um compilador IDL-Java, e o programador de um cliente (dentre os vrios que podem existir no sistema) pode usar um compilador
IDL-C++. Os resultados dessas compilaes so os stubs (que no caso do servidor recebem o nome de skeletons) Os stubs ocultam dos programadores a complexidade das tarefas necessrias na serializao/deserializao dos parmetros em/de mensagens da rede. Finalmente, os programadores codificam o resto do cdigo de seus sistemas; ou seja, o programador do servidor ir codificar as classes que ele descreveu no arquivo IDL, e o programador do cliente ir codificar a parte que faz chamadas ao servidor.
2.4.10. Integrando CORBA, HTTP e Java/RMI

A grande disseminao e a portabilidade da linguagem Java adicionada de seus mecanismos que facilitam a programao de aplicaes na Internet levou a OMG a lanar especificaes CORBA tentando unir as duas tecnologias. A primeira iniciativa foi definir o mapeamento IDL para a linguagem Java que permite ento a gerao de stubs e skeletons em Java, e o mapeamento inverso do Java para IDL que permite programadores Java gerarem stubs para atuarem em ambientes CORBA a partir de cdigo Java. A Sun, por sua vez, adotou o protocolo IIOP no Java/RMI. A Netscape em seus navegadores j oferece suporte para IIOP. Considerando que o HTTP abre uma nova conexo para cada requisio no mesmo servidor Web e o IIOP utiliza uma mesma conexo para vrias requisies em um servidor CORBA, a unio destas trs ferramentas cria novas perspectivas na programao de aplicaes na Internet. A Figura 2.30 ilustra as possibilidades da combinao destas ferramentas. Clientes em servidores Web podem ser ativados a partir de um navegador via http. Uma vez ativados podem interagir com servidores CORBA, Java ou mesmo DCOM e DCE. Estas combinaes trazem bem mais alternativas que os usuais comandos CGI em um servidor Web. Um cliente na forma de um applet pode com suporte CORBA a partir de qualquer navegador na Internet pode enviar requisies a servidores CORBA, por exemplo.
iiop://lcmi.ufsc.br
HTTP
Cliente ORB (applet)
Servidor HTTP CGI Cliente ORB A

IIO P
Servidor HTTP CGI Cliente ORB A
IIO P
S e r v id o r ORB A
IIO P
S e r v id o r ORB B
IIO P
S e r v id o r O R B Java
S e r v id o r D CE
S e r v id o r DCOM
Figura 2.30. Integrao CORBA/Java/Web
2.4.11. Suporte para Aplicaes Crticas em CORBA

A OMG, dentro de sua dinmica de manter as especificaes CORBA evoluindo, vem estimulando a criao de muitos grupos de discusso ligados a interesses especficos de aplicaes. Com isto nos ltimos anos tm surgido novos COSS (Common Object Services Specifications) atendendo caractersticas de determinadas reas de aplicaes. neste quadro que se encaixam as especificaes Real-Time CORBA (RT-CORBA) [OMG 1999b], Fault-Tolerant CORBA (FT-CORBA) [OMG 2000a] e CORBA Security (CORBASec) [OMG 2000b] que so COSS voltados para aplicaes crticas. Na seqncia, so apresentadas descries resumidas das especificaes OMG sobre o Real-Time CORBA, o Fault-Tolerant CORBA e o CORBA Security. 4.11.1. As Especificaes Real-Time CORBA A falta de suporte de middleware para aplicaes de tempo real levou o consrcio OMG a criar em 1995 um grupo de trabalho com objetivo de estender os padres CORBA. Um documento RFI (Request for Information) [OMG 1996] foi lanado especificando requisitos que deveriam ser mantidos por um ORB que suporta aplicaes com restries temporais. O documento definiu um conjunto de requisitos para o ambiente operacional, para o ORB e servios. Os requisitos de ambiente operacional podem ser resumidos em: multithreading, filas ordenadas por prioridade, sincronizao de relgios e latncia mxima de comunicao delimitada. J os requisitos de ORB e servios envolvem certas facilidades para expressar e implementar restries temporais, a noo de prioridade global, invocaes com polimorfismo temporal, etc. Em setembro de 1997, um documento RFP (Request for Proposal) [OMG 1997b] foi publicado solicitando propostas de padronizao de um CORBA para aplicaes de tempo real (RT CORBA). Esse primeiro documento RFP, o Real-Time CORBA 1.0 RFP, definiu alguns requisitos para escalonamento baseado em prioridades. Em outubro de 1998, cinco propostas apresentadas previamente foram reunidas em uma nica proposta o RT CORBA 1.0 [OMG 1999b]. Esse documento enfatiza a definio de mecanismos de ORB, permitindo projetistas selecionarem as polticas para escalonamento de tempo real. No existem suposies prvias sobre o ambiente operacional subjacente, mas o documento reconhece que um sistema operacional em conformidade com POSIX adequado para a obteno de previsibilidade. Algumas das caractersticas e abstraes introduzidas nesta especificao so descritas na seqncia. Threads, Pool de Threads e Filas de Requisies: O RT CORBA 1.0 descreve threads como as entidades escalonveis do sistema. Algumas interfaces so especificadas para gerir threads Pool de threads e filas de requisio o que permite uma grande portabilidade s aplicaes. Threads podem ser definidas e controladas de forma uniforme, independentemente se a plataforma de execuo possui threads Solaris, NT, ou POSIX.1c. So introduzidos tambm Pool de threads e filas de requisio como recursos que aplicaes podem manipular diretamente. Um pool de threads pode ser criado para
processar requisies de mtodos recebidas por um servidor. Uma fila de requisio pode ser criada e associada com o pool de threads (Figura 2.31).
Servidor mtodo mtodo mtodo
RT POA Ncleo do RT ORB
pool de threads RT ORB fila de requisies
requisio
Figura 2.31. Exemplo de Uso dos Mecanismos do RT CORBA Prioridade CORBA: A prioridade CORBA um tipo de prioridade global que pode atravessar diferentes ORBs, fazendo uso de mensagens de invocao. Dependendo da abordagem de escalonamento, essa prioridade pode ser usada pelos servidores para ordenar as requisies recebidas. Portanto, o documento RFP introduz dois modos de utilizao: os modelos client-priority propagation e o server-set priority. Em ambas as estratgias, a prioridade CORBA da invocao deve ser mapeada para as prioridades do sistema operacional antes da execuo do mtodo invocado. Binding: A ligao entre cliente e servidor RT-CORBA feita atravs de um binding explcito que contm vrios passos a serem tomados para a interconexo dos objetos, tais como: localizar objetos destino e iniciar estruturas de dados que suportem comunicao entre objetos. No lado do cliente, o binding pode ser usado para garantir que seus requisitos temporais sejam respeitados (por exemplo, atravs da seleo de um protocolo de transporte apropriado e de um valor de timeout para deteco de faltas). No lado do servidor, o binding permite a alocao dos recursos necessrios na execuo das requisies, tais como threads e filas. Interceptadores: O principal mecanismo proposto nas especificaes CORBA, que introduz flexibilidade na programao da aplicao o interceptador. Interceptadores so mecanismos geralmente usados para implementar de maneira transparente as polticas que regulam o comportamento das aplicaes. A especificao RT CORBA 1.0 no trata especificamente de interceptadores, porque estes j foram padronizados nas especificaes CORBA [OMG 1998]. Os mecanismos e recursos definidos nas especificaes RT-CORBA devem permitir a implementao de diferentes abordagens de escalonamento de tempo real sobre as requisies principalmente as baseadas em prioridades fixas.
4.11.2. As Especificaes Fault-Tolerant CORBA Atualmente, muitas aplicaes com requisitos de tolerncia a faltas esto seguindo o paradigma de orientao a objetos e considerando o CORBA como uma alternativa de se adequar a sistemas abertos. Como resultado deste interesse, a OMG apresentou recentemente a especificao Fault-Tolerant CORBA [OMG 2000a]. As especificaes FT CORBA, que ainda devem passar por varias revises (e extenses), definem um conjunto de interfaces de servios e facilidades teis para a implementao de tcnicas de replicao em ambientes distribudos heterogneos. As especificaes atendem apenas aos requisitos bsicos para tolerncia a faltas, definindo algumas interfaces bastante genricas, de fcil entendimento, e aplicveis em praticamente todas aplicaes que requerem tolerncia a faltas. Um padro que tenta atender a todos os requisitos de um largo espectro de aplicaes pode faz-lo de forma insatisfatria ou, pode ser muito complexo para implementar. Portanto, o comit da OMG responsvel pela padronizao do FT CORBA optou, para esse primeiro momento, por assumir apenas alguns compromissos. Nesta primeira especificao foram apresentados um conjunto de interfaces de servios comuns (COSS) e facilidades e ainda protocolos para a interoperabilidade que compem algumas funcionalidades como: gerenciamento de replicaes, gerenciamento de faltas, gerenciamento de recuperao e logging. Na Figura 2.32, apresentada a arquitetura do FT-CORBA. Nela so apresentados os servios comuns de objetos que, no middleware, fornecem funcionalidades bsicas para a construo de servidores tolerantes a faltas. Gerenciamento de Replicaes O gerenciamento de replicao constitudo pelos servios de gerenciamento de propriedades, de grupos de objetos e fbrica genrica. Segundo as especificaes, o gerente de replicaes responsvel pelo gerenciamento de grupo, exercendo um controle dinmico nas entradas e sadas (normal ou por falha) de objetos de um grupo pela manuteno de listas atualizadas de seus membros (membership). Na criao ou remoo de rplicas, o servio de objeto gerente de replicaes usa o objeto fbrica genrica para criar e remover membros do grupo de objetos da aplicao. O objeto fbrica genrica negocia com os objetos fbrica locais para a criao/remoo de rplicas nas diferentes estaes de um sistema distribudo. No processo de criao de rplicas so utilizados mecanismos de logging e checkpoint para o registro e a atualizao de estados, que a partir de uma rplica primria (objeto servidor 1 na figura), fazem transferncias de estados para novas rplicas que se juntam na replicao. O servio de gerenciamento de propriedades define e manipula as propriedades de tolerncia a faltas dos grupos de objetos mantidos pelo servio de gerenciamento de replicaes.
Gerenciamento de Faltas No gerenciamento de faltas, o servio de deteco de falhas dividido em trs nveis, detectores de falhas em nvel de objeto, processo e host. Os detectores de falhas nos diferentes nveis so baseados em mecanismos de timeout (as hipteses de falha assumidas so de crashes de processadores). O detector de falha em nvel de host se utiliza de replicao. O servio notificador de falhas tambm replicado e tem a funo de enviar mensagens de notificao ao gerente de replicaes, a partir dos registros de falhas enviados pelos detectores de falhas dos trs nveis. Esses registros so necessrios ao gerente de replicaes para atualizao das listas de membros de um grupo de objetos.
Gerenciamento de Replicaes Gerenciamento de Gerenciamento de Propriedades Grupo de Objetos Fbrica Genrica
Create_object() Notificao
Notificador de Falha
Detector de Falha de Host

is_alive()
Host 1
H ost 2
Fbrica
Detector de Falha de Processo

is_alive()
Host 3
Fbrica
Detector de Falha de Processo

is_alive()
P4
Processo P1
P2
Objeto Servidor 1
P3
Objeto Servidor 2
Cliente
Detector de Falha de Objeto

is_alive()
Detector de Falha de Objeto

is_alive()
ORB
ORB
Mecanismos de Logging e Checkpoint
ORB
Mecanismos de Logging e Checkpoint
Mecanismo de Recuperao
Mecanismo de Recuperao
Sistema de Comunicao de Grupo Proprietrio
Figura 2.32. Arquitetura de Tolerncia a Faltas do CORBA As entidades e mecanismos descritos nas especificaes foram introduzidos para suportarem as tcnicas de replicao que podem ser suportadas pela arquitetura FTCORBA, (Replicao ativa, Replicao passiva fria e Replicao passiva quente [OMG 2000a]). A OMG, como de sua caracterstica, se limita em definir interfaces genricas de servios, tentando atender diferentes abordagens de tolerncia a faltas. Por exemplo, protocolos de comunicao de grupo confivel, base fundamental para a implementao de tcnicas de replicao, no so padronizados como era de se esperar, pela
complexidade dos mesmos e pela quantidade de algoritmos envolvidos. A OMG enfatiza, neste caso, o uso de solues proprietrias (Figura 2.32). Todavia, para garantir um mnimo grau de interoperabilidade, os sistemas de comunicao de grupo devem adotar a IOGR (Interoperable Object Group Reference), a referncia de grupo de objetos definida em [OMG 1999a]. A IOGR uma extenso da IOR de um simples objeto, formando uma referncia interopervel de grupo de objetos. Uma IOGR permite a um cliente referenciar a um grupo de objetos como a uma entidade nica. De forma genrica, a IOGR contm o conjunto de IORs de cada membros de um grupo de objeto. 4.11.3. As Especificaes CORBA Security A complexidade inerente aos sistemas de objetos distribudos causa vulnerabilidades adicionais que devem ser contidas por uma arquitetura de segurana. Dentre estas vulnerabilidades, o controle de acesso em sistemas de larga escala problemtico, j que sistemas de objetos distribudos podem crescer sem limites, com componentes sendo constantemente adicionados, removidos e modificados nestes ambientes. No sentido de minimizar estes problemas a OMG introduziu o CORBAsec que um modelo de segurana que, quando implementado e administrado corretamente, pode prover um alto nvel de segurana para informaes e aplicaes de objetos distribudos em ambientes de larga escala [OMG 2000b]. O modelo de segurana descrito neste documento estabelece vrios procedimentos envolvendo a autenticao, a verificao da autorizao na invocao de um mtodo remoto, a segurana da comunicao entre os objetos, alm de aspectos relacionados com esquemas de delegao de direitos, no-repudiao, auditoria e administrao da segurana.
C lie n te
O b je to D e s tin o
p e d id o p e d id o
S e rv i o s ORB
O b jetos d e s e r v i o (C O S S ) S e r v i o d e Segurana
S e rv i os ORB
N c le o O R B
te cn o log ia d e s e g u ra n a
P ro te o B s ica e C om u n ica e s
Figura 2.33. O Modelo CORBA de Segurana
O modelo CORBA de segurana relaciona objetos e componentes de quatro nveis (Figura 2.33). Em nvel de aplicao, objetos cliente e servidor; servios COSS, servios ORB e o ncleo do ORB, todos em nvel de middleware; componentes de tecnologia de segurana em nvel de servios de segurana subjacentes e componentes de proteo bsica, fornecida por uma combinao de hardware e sistemas operacionais locais. 4.11.4. Interceptadores No modelo CORBA de segurana, so definidos dois tipos de interceptadores que atuam durante uma invocao de mtodo: o interceptador de controle de acesso (Access Control Interceptor), que em nvel mais alto provoca um desvio para realizar o controle de acesso na chamada, e o interceptador de chamada segura (Secure Invocation Interceptor), que faz uma interceptao de mais baixo nvel no sentido de fornecer propriedades de integridade e de confidencialidade nas transferncias de mensagens correspondentes invocao. Esses interceptadores atuam tanto no lado do cliente como do objeto servidor de aplicao.
Cliente Servidor
ClientAcessDecision Domain Required Access Rights Policy
Servios ORB Controle de acesso Chamada Segura
Servios ORB Controle de acesso Chamada Segura
ServerAcessDecision Domain Required Access Rights Policy
Vault cria SecurityContext
SecurityContext cria Vault
Ncleo ORB Object Request Broker
Figura 2.34. Componentes Internos do Modelo de Segurana do CORBA A Figura 2.34 mostra todos os objetos e mecanismos definidos pelo CORBASec que atuam a nvel de middleware. Observa-se que no interior das setas esto contidos o interceptador de controle de acesso que est representado pelo objeto Controle de Acesso e o interceptador de chamada segura que est representado pelo objeto Chamada Segura. Servios de Objetos Comuns Os servios de objetos comuns que implementam os controles de segurana nas especificaes CORBA so:
o Principal Authenticator que corresponde ao servio de autenticao de principais no CORBA; o Vault que estabelece as associaes seguras entre os clientes e servidores com os respectivos contextos de segurana; o SecurityContext que representa o contexto da associao segura, o Credential que representa as credenciais ou direitos do cliente na sesso; o DomainAccessPolicy que representa a interface de gerenciamento de polticas de autorizao discricionrias e concede a um conjunto de principais direitos especficos para executar operaes sobre todos os objetos do domnio [Karjoth98]; o RequiredRights que armazena as informaes sobre os direitos (rights) necessrios para executar cada mtodo de cada interface do sistema; os objetos AccessDecision responsveis por interagir com os objetos DomainAccessPolicy e RequiredRights para determinar se uma dada operao sobre um objeto destino especfico permitida.
Existem, tambm, outros objetos de servio relacionados com a no-repudiao e auditoria. Os servios de objetos comuns no modelo CORBA de segurana isolam aplicaes e o ORB da tecnologia de segurana (Figura 2.34). Esta ltima consiste em uma camada subjacente que implementa vrias funcionalidades dos servios de objetos comuns relacionados com a segurana. A tecnologia de segurana inclui servios de autenticao, servios de associao segura (distribuio de chaves, certificados, cifragens/decifragens), etc. De acordo com a especificao do CORBASec, as tecnologias que podem ser utilizadas para fornecer esses servios so [OMG 2000b]: SPKM (Simple Public-Key GSS-API Mechanism), Kerberos, CSI-ECMA (baseado no SESAME e no mecanismo ECMA GSS-API) e o SSL.
2.4.12. Consideraes sobre as especificaes CORBA

A OMG, dentro de sua linha de fornecer padres abrangentes que atendam as necessidades de programao de aplicaes distribudas em sistemas cada vez mais caracterizados pela distribuio geogrfica e heterogeneidade, continua a estimular a produo de novas especificaes. Alm das citadas neste texto, existem vrias outras propostas em fase de padronizao ou j padronizadas na OMG. Neste processo, esto as propostas de: UML (Unified Modeling Language); protocolo Meta-objeto; suporte para mdia contnua; comercio eletrnico; agentes mveis e centenas de outras especificaes. O CORBA corresponde a um conjunto de especificaes bastante completo atendendo a um espectro amplo de aplicaes. Por ser completo considerado muito complexo por seus crticos. Mas no sentido de justificar a sua aceitao diramos que a fora destas especificaes est na sua constante evoluo que procura mant-la adaptada sempre s novas tecnologias emergentes. A nossa opinio de que a aceitao destes padres deve continuar ainda por muitos anos.
2.5. Concluso
Este texto descreveu plataformas para a execuo de aplicaes distribudas. Inicialmente a seo 2.2 apresentou os conceitos fundamentais da rea. Em seguida, a seo 2.3 mostrou como aplicaes distribudas podem ser escritas atravs da tecnologia Java. Em particular, foram apresentadas quatro maneiras de usar Java com este propsito: sockets, servlets, RMI e Jini. A seo 2.4 tratou do padro mais importante atualmente para o desenvolvimento de aplicaes distribudas em arquiteturas heterogneas, o padro CORBA. Esta uma rea com enorme quantidade de material publicado. O leitor interessado no assunto poder ampliar os seus conhecimentos atravs da literatura citada ao longo do texto. Os autores esperam que, aps a leitura deste texto, fique mais fcil para algum interessado na rea identificar os tpicos relevantes e localizar o material apropriado a ser estudado. No momento que este texto escrito, surgem diversos novos desafios para a comunidade que trabalha na rea, ao mesmo tempo em que velhos desafios continuam indomados. A necessidade premente atacar os problemas de segurana existentes hoje. Todos ns conhecemos bem os problemas advindos dos vrus de computador e dos acessos no autorizados. A disseminao da computao mvel tambm traz novos problemas para a confiabilidade da operao de aplicaes distribudas. Finalmente, sistemas distribudos com requisitos de tempo real exigem novas consideraes no momento do projeto. A dimenso tempo deixa de ter um papel secundrio, como uma questo de desempenho, e passa a ter um papel central, relacionado com a prpria funcionalidade da aplicao. Com certeza nos prximos anos muitas novidades continuaro a surgir nesta rea.
2.6. Referncias
[ANSA] ANSAware, URL: http://www.ansa.co.uk [Arnold 1997] K. Arnold, J. Gosling, Programando em Java, Makron Books, 1997. [Birman 1996] K. Birman, Building Secure and Reliable Network Applications, Manning Publications, 1996. [Coulouris 2001] G. Coulouris, J. Dollimore, T. Kindberg, Distributed Systems: Concepts and Design, Third Edition, Addison-Wesley, 2001. [Deitel 2001] H. Deitel, P. Deitel, Java Como Programar, 3a edio, Bookman, 2001. [Edwards 2000] W. Keith Edwards, Core Jini, 2nd edition, Prentice Hall, 2000. [Harold 1997] E. Harold, Java Network Programming, O'Reilly, 1997. [ISO 1995] ISO, Reference Model of Open Distributed Processing - Part 1: Overview, Document 10746-1, May 1995.
[Jul 1991] Eric Jul, et. al., Emerald: A General-Purpose Programming Language, Software Practice and Experience, vol. 21, number 1, pages 91-118, Jan. 1991. [Kramer 1989] J. Magee, J. Kramer, M. Sloman, Constructing Distributed Systems in Conic, IEEE Transactions on Software Engineering, vol 15, no 6, 1989. [Kurose 2001] J. Kurose, K. Ross, Computer Network: A Top-Down Approach Featuring the Internet, Addison Wesley, 2001. [Liskov 1988] B. Liskov, Distributed Programming in Argus, Communications of the ACM, Vol. 31, Num. 3, Mar. 1988, pages 300-312. [Lynch 1996] N. Lynch, Distributed Algorithms, Morgan Kaufmann Publishers, 1996. [Mills 1991] D. L. Mills, Internet Time Synchronization: the Network Time Protocol, IEEE Trans. on Communications 39, 10, pp.1482-1493, Oct. 1991. [OMG 1996] OMG Realtime Platform Special Interest Group, Realtime Technologies Request for Information, Object Management Group (OMG), Document realtime/9608-02 96, Aug. 1996. [OMG 1997a] Object Management Group, CORBAservices: Common Object Services Specification, OMG Document. Mar. 1997. [OMG 1997b] OMG Realtime Platform Special Interest Group, Realtime CORBA 1.0 RFP, Object Management Group (OMG), Document realtime/97-09-31, Sep. 1997. [OMG 1998] OMG, The Common Object Request Broker: Architecture e Specification Revision 2.2, Object Management Group (OMG), Feb. 1998. [OMG 1999a] Object Management Group, ORB Interface, OMG Document Number 9907-08, June 1999. [OMG 1999b] OMG, Realtime CORBA - Joint Revised Submission, Object Management Group (OMG), Document orbos/99-02-12, Mar. 1999. [OMG 2000a] Object Management Group, Fault-Tolerant CORBA Specification V1.0, OMG document: ptc/2000-04-04, Apr. 2000. [OMG 2000b] Object Management Group, Security Service:v1.5, OMG Document Number 00-06-25, Jun. 2000. [Orfali 1998] R. Orfali, D. Harkey, Client/Server Programming with JAVA anda CORBA, Second Edition, John Wiley & Sons, Inc., 1998. [OSF] DCE, URL: http://www.opengroup.org/dce/ [RFC 1035] P. Mockapetris, Domain Names Implementation and Specification, Nov. 1987. [RFC 1180] T. Socolofsky, C. Kale, A TCP/IP Tutorial, Jan 1991. [Stevens 1998] W. Stevens, UNIX Network Programming Networking APIs: Socket and XTI, Volume 1, Second Edition, Prentice-Hall Inc., 1998.
[Sun 1999] Sun, Jini Architectural Overview: Technical White Paper, Sun Microsystems, Inc., 1999. [Sun 2001] Sun, Jini Network Technology: An Executive Overview, Sun Microsystems, Inc., 2001. [Tanenbaum 2002] M. Van Steen, A. Tanenbaum, Distributed Systems: Principles and Paradigms, Prentice Hall, 2002.

Mini Curso - Programação em SD

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mini Curso - Programação em SD

Uploaded by

Copyright:

Available Formats

2

Programao em Sistemas Distribudos

X Escola de Informtica da SBC-Sul - ERI 2002

X Escola de Informtica da SBC-Sul - ERI 2002

2.2. Conceitos bsicos

Figura 2.1. Pilha de protocolos do Modelo OSI e TCP/IP.

X Escola de Informtica da SBC-Sul - ERI 2002

Aplicao Sistema Operacional

Processo socket TCP ou UDP, buffers, etc... Rede

Processo socket TCP ou UDP, buffers, etc...

2.2.1. Heterogeneidade de representao de dados e marshaling

Figura 2.3. Representao big-endian e little-endian.

X Escola de Informtica da SBC-Sul - ERI 2002

2.2.2. Transparncias de distribuio e middleware

X Escola de Informtica da SBC-Sul - ERI 2002

X Escola de Informtica da SBC-Sul - ERI 2002

2.2.3. Modelo cliente-servidor

X Escola de Informtica da SBC-Sul - ERI 2002

2.2.4. Chamada de Procedimento Remoto

chamada stub do cliente stub do servidor

Sistema receive Operacional

Figura 2.6. Chamada de Procedimento Remoto.

X Escola de Informtica da SBC-Sul - ERI 2002

2.2.5. Servios de Nome e binding

X Escola de Informtica da SBC-Sul - ERI 2002

2.3. Tecnologias Java

2.3.1. Sockets em Java

X Escola de Informtica da SBC-Sul - ERI 2002

Cria streams Conduz conversa

Cria streams Conduz conversa

Fecha streams e socket

Fecha streams e socket

Figura 2.7. Comunicao utilizando sockets orientados conexo.

X Escola de Informtica da SBC-Sul - ERI 2002

Envia dados (resposta) No Fim?

No Fim? Sim Fecha socket Termina aplicao Sim

Figura 2.8. Comunicao utilizando sockets orientados a datagrama

X Escola de Informtica da SBC-Sul - ERI 2002

X Escola de Informtica da SBC-Sul - ERI 2002

2.3.3. RMI (Remote Method Invocation)

X Escola de Informtica da SBC-Sul - ERI 2002

X Escola de Informtica da SBC-Sul - ERI 2002

X Escola de Informtica da SBC-Sul - ERI 2002

java Cliente Cliente

java Servidor Servidor

Figura 2.10. Mecanismo geral do RMI.

X Escola de Informtica da SBC-Sul - ERI 2002

X Escola de Informtica da SBC-Sul - ERI 2002

... Lookup Join Discovery RMI

MV Java Solaris Sparc

MV Java MAC PPC

MV Java Windows PPC

X Escola de Informtica da SBC-Sul - ERI 2002

X Escola de Informtica da SBC-Sul - ERI 2002

pedido de discovery proxy para servidor de lookup new

proxy p/ servidor de lookup

pedido de discovery proxy para servidor de lookup new

proxy p/ servidor de lookup

pedido de join (proxy p/ x) pedido de join (proxy p/ x)

Figura 2.13. Operao "discovery" seguida da operao "join".

X Escola de Informtica da SBC-Sul - ERI 2002

pedido de lookup(x) proxy para servidor x new proxy p/ servidor x

pedido de servio p/ x pedido de servio p/ x

X Escola de Informtica da SBC-Sul - ERI 2002