Métodos em Objectos Remotos · • Desvantagens – As integrações assumem uma ligação forte ... • Efectua a conversão dos parâmetros de entrada e de ... – Comunicação

1

8/28/2003 José Alves Marques

Departamento de Engenharia Informática

Métodos em Objectos Remotos



Orientado aos Métodos

• Partilha de componentes ou módulos entre aplicações• Vantagens

– Fácil de utilizar nas linguagens baseadas em procedimentos, objectos e/ou componentes

– Ofertas dos maiores fabricantes, ex.: Corba, J2EE, .NET

• Desvantagens– As integrações assumem uma ligação forte quando há mudanças

no servidor os clientes têm de ser modificados – Baseia-se normalmente numa comunicação síncrona – Dificuldade de partilhar componentes devido a detalhes funcionais,

tecnologia, segurança, ausência de arquitectura

2



Visão Corporativa

EmpresaVirtual

Sistema de Suporte ao Negócio

Processos de NegócioAplicações de Negócio

Componentes das Aplicações



m4

m5

m6

Interface Remota

m1m2m3

Código dos

métodos

Dados

Objecto remoto

Invocação de Objectos Remotos

3



Diferenças Relevantes

• Granularidade– Mais fina do que em servidores que tipicamente disponibilizam

interfaces para programas com alguma complexidade

• Invocação dinâmica – Sistemas cliente-servidor ligação é forte (tightly coupled):

• Clientes não podem invocar serviços para os quais não tenham os stubs (estabelecidos quando IDL foi compilada)

– Sistemas de objectos desenvolvimento incremental / looselycoupled

• Permitem um objecto invocar dinamicamente outros de que obtém a interface em tempo de execução



Principais Sistemas de Objectos Remotos

• Corba• RMI (Java / J2EE)• Remoting (C# / .NET)

4



CORBA

• Tem origem no Object Management Group (OMG) criado em 1989

• Modelo Conceptual é uma síntese entre o modelo cliente –servidor e as arquitecturas de objectos

• A proposta original do Corba - Object ManagementArchitecture foi publicada em 1990 e continha:– Object Request Broker (ORB)

• Novo paradigma: consiste num serviço que auxilia a invocação de objectos remotos

• O papel do ORB é localizar o objecto, activá-lo se necessário, enviar o pedido do cliente ao objecto

– Serviços de suporte ao ciclo de vida dos objectos• Serviços básicos como nomes, acontecimentos assíncronos,

persistência, etc.



CORBA

• CORBA 2.0 publicado em 1996• Os principais elementos da plataforma são:

– IDL – linguagem object oriented com suporte para herança– Arquitectura – define o ambiente de suporte aos objectos, à invocação, ao

ciclo de vida– GIOP – General Inter Orb Protocol – protocolo de invocação remota entre

Orb de fabricantes diferentes– IIOP - Internet Inter Orb Protocol – implementação do GIOP sobre

protocolos TCP/IP• Actualmente

– Actividade de normalização reduzida– Vários produtos disponíveis

• Visigenic/Visibroker• IONA• Menos utilizado vs. plataformas J2EE / .net

5



Modelo de Objectos

• Um objecto CORBA implementa uma interface descrita na IDL CORBA

• Um objecto CORBA pode ser invocado remotamente através de uma referência remota

• Os objectos CORBA residem no servidor, • os clientes podem ser objectos ou programas que enviam

as mensagens correctas para os objectos • Os objectos remotos são transferidos por referência.

– Ou seja permanecem no servidor e apenas é enviada uma referência que permite invocá-los

• Os objectos não têm de ser implementados numa linguagem Object Oriented podem ser em Cobol, C, etc.



Arquitectura

Implementationrepository

interfacerepository

Clientprogram Proxy

for AORBcore

client

or dynamic skeleton

obje

ctad

apte

r

ORBcore

server

skel

eton

ServantA

Request

Reply

Or dynamic invocation

6



Elementos da Arquitectura

• ORB – núcleo – run-time da invocação remota, conjunto de funções residentes quer no cliente quer no servidor

– O ORB tem funções para ser inicializado e parado– Operações para converter as referências remotas em cadeias de caracteres– Operações para fornecer a lista de argumentos em pedidos que usem invocação

dinâmica• Servidor

– Object adapters - rotina de despacho que recebe as mensagens e invoca os stubsapropriado

• O nome do objecto adapter faz parte da referência remota e permite a sua invocação• Cria referências remotas para os objectos Corba• Despacha cada RMI via um skeleton para o método apropriado• Activa o objecto

– Skeletons• Funções de adaptação que fazem a conversão dos parâmetros de entrada e saída e o

tratamento das excepções– Client proxies

• Para as linguagens Object oriented• Efectua a conversão dos parâmetros de entrada e de saída




– Implementation repository• Armazena a tabela que relaciona os object adapters e os

pathnames dos ficheiros que contem a implementação dos objectos

• É responsável por activar servidores a pedido• Localizar servidores que estão em execução• Quando um servidor se inicia regista o nome do object adapter

e da sua implementação.• O nome do object adapter é usado para referenciar os

servidores quando são registados ou quando são activados

7




– Interface repository• Dá informação sobre as interfaces registadas• Para uma interface pode dar a informação dos métodos e dos

respectivos parâmetros• O compilador de IDL atribui um número único a cada tipo IDL

que compila • Esta facilidade permite a reflexão em CORBA. Se um cliente

recebe uma referência remota para um novo objecto CORBA de que não tem um proxy, pode ir buscar esta informação ao Interface repository



CORBA – Invocação Dinâmica

• O CORBA não permite que novas classes sejam carregadas dinamicamente

• Para dinamicamente invocar um objecto em tempo de execução existe a invocação dinâmica

• O cliente não precisa de ter os proxies – As invocações remotas são construídas dinamicamente– Novos servidores podem ser usados por clientes já existentes

• Funcionamento– O Cliente usa o Interface Repository para obter a informação sobre os

métodos e argumentos.– Cria a mensagem de acordo com a especificação da interface– O Cliente selecciona uma interface e envia o pedido para o respectivo

objecto.

8



Arquitectura de Integração da Optimus7.3. Arquitectura de Sistemas de Informa7.3. Arquitectura de Sistemas de Informaçção, EIAão, EIA

Workers

CommandTransformation

Mediator

SecurityValidator

BSCS

LDAP

Repository

StateMachine

ServiceCatalogue

CORBA

JMS

SOCKET

SOAP

EIADatabase

File System

BSCS

Self-Care

UnifiedInterface

SAP R/3

MVPN

Enterprise Integration Architecture - Aplication Components (R 1.1)

XML

Error MsgCatalogue

XML

RQ queue

Workers

DeployedServices

WorkersDatabase

WorkersFile



Java 2 Plataform, Enterprise Edition

9



J2EE

• Plataforma aberta e baseada em standards para:– Desenvolvimento, instalação e gestão de aplicações

distribuídas e multicamada• Aplicações empresariais• Baseadas em tecnologia Web• Centradas no servidor• Compostas por n-camadas• Constituídas por componentes



Plataforma Java 2

Dispositivo Java Desktop Java Servidor Departamental

Servidor Central

10



Páginas HTML dinâmicas

Páginas JSP

Enterprise Beans

Base de Dados

Aplicação J2EE Multi-nível

Cliente

ServidorJ2EE

Servidor deBase de Dados

Camada cliente

Camada Web

Camada de negócio

Camada EIS

Ambiente de trabalho de SD e ES



Arquitectura J2EE

11



Arquitectura J2EE: n-camadas

Multi tier permite que cada camada se execute em dispositivos diferentes



API’s e Tecnologias J2EE

• Java 2 SDK, Standard Edition • Enterprise JavaBeans (EJB)• Java Servlets• JavaServer Pages (JSP)• RMI/ IIOP• JDBC™• Java Transaction (JTA)• Java Transaction Service • Java Connector Architecture• Java Message Service (JMS)• Java Naming and Directory Interface (JNDI)• Java Authentication and Authorization Services (JAAS)• JavaMail

12



Enterprise Java Beans

• Parte fundamental da arquitectura J2EE• Tecnologia básica para a construção de componentes para

execução no servidor• Dirigido para aplicações complexas

– Transaccionais– Distribuídas– N-camadas– Seguras– Robustas– Portáveis



Servlets

• Objectos Java que estendem a a funcionalidade do servidor HTTP

• Geração dinâmica de conteúdos• Alternativa melhor que CGI, NSAPI, ISAPI, etc

– Mais eficiente – classes Java compiladas– Independente da plataforma e do servidor– Gestão de sessões– Baseada em Java

13



JSP’s

• Permite separação entre a apresentação e a lógica da aplicação– Apresentação baseada em HTML e XML/XSLT– Lógica da aplicação implementada com Java Beans ou “custom

tags”– Melhor capacidade de manutenção e reusabilidade

• Extensível• Complementar com a tecnologia de Servlets• JSP modelo focado no documento enquanto o modelo das

servelts é programático



RMI / IIOP

• Remote Method Invocation: mecanismo de chamada remota a métodos Java

• Utilizado para RPCs entre objectos Java distribuídos– Mantém a semântica de uma chamada local, para objectos distantes– Efectua automaticamente o empacotamento e desempacotamento

dos parâmetros– Envia as mensagens de pedido e resposta– Faz o agulhamento para encontrar o objecto e o método pretendido

14



Java RMI

• O RMI Java pressupõe que se utiliza um ambiente Java de linguagem única, pelo que não se colocam alguns dos problemas que o CORBA pretende resolver.

• Apesar do ambiente uniforme um objecto tem conhecimento que invoca um método remoto porque tem de tratar RemoteExceptions

• A interface do objecto remoto por sua vez tem de ser uma extensão da interface Remote



Java RMI

• No Java RMI os parâmetros de um método assumem-se como entradas(input) e o resultado do método como parâmetro de saída (output)

• Quando o parâmetro é um objecto remoto – é sempre passado como uma referência para um objecto remoto

• Quando o parâmetro é um objecto local – é serializado e passado por valor. Quando um objecto é passado por valor uma nova

instância é criada remotamente• Os objectos susceptíveis de serem passados por valor têm de implementar a

interface Serializable. Todos os tipos primitivos e objectos remotos são serializáveis.

• Quando um objecto é serializado a informação sobre a sua classe é registada com a localização da classe (URL) permitindo o seu carregamento dinâmico.

• Quando um objecto é passado por valor se o receptor não tiver a classe respectiva o seu código é descarregado automaticamente.

15



JNDIJava Naming and Directory Interface

• Mecanismo de nomes do J2EE• Utilizado para associar nomes a recursos e

objectos de forma portável– Identificação, localização, partilha

• Mapeia nomes em referências para objectos• Uma instância do registry deve executar-se em

todos servidores que têm objectos remotos.• Os clientes têm de dirigir as suas pesquisas para o

servidor pretendido



JDBC

• Interface standard Java para acesso a bases de dados relacionais– Baseada em SQL

• Fornecedores de bases de dados disponibilizam drivers JDBC para as suas bases de dados

16



Java Message System (JMS)

• API standard Java para acesso a message-orientedmiddleware (MOM)– Comunicação assíncrona, com fraca ligação entre

aplicações– Comunicação fiável, escalável– Interface ponto a ponto ou publish-subscribe

• Drivers para muitos MOM’s– IBM MQSeries, MSMQ, ...



Arquitectura J2EE

17



Entidades Fundamentais do J2EE

• Componentes (components)• Contentores (containers)• Conectores (connectors)




Componentes (components)Contentores (containers)Conectores (connectors)

18



Componentes

Componente J2EE: unidade de software autocontidaIntegrada numa aplicaçãoInstalada com todas as suas classes e ficheirosComunica com outras componentes

Existem 3 tipos de componentesClient ComponentsWeb ComponentsBusiness Components



Componentes Cliente

– Executam-se na máquina cliente• Oferecem a interface utilizador

– Existem 3 tipos de clientes• Clientes Web (Thin Clients)• Applets• Clientes aplicacionais, ou stand-alone

19



Componentes Web

• Implementa o front-end do servidor J2EE– Gera dinamicamente os dados enviados para a interface cliente– Valida os dados dos pedidos



Funções e Benefícios da Camada Web

Funções:Controla a comunicação entre os clientes e a camada aplicacionalGera o conteúdo dinâmicoMantém o estado das sessõesSuporta múltiplos tipos de clientes

BenefíciosSepara a apresentação da lógica aplicacionalSepara as funções de desenvolvimentoOferece um ponto único de acesso à camada aplicacionalIntroduz um nível adicional de segurança

20



Componentes Aplicacionais (EJBs)

• Implementam a lógica aplicacional



Configurações J2EE

21



Configurações J2EE

• Aplicações Web com 4 camadas – Browser: cliente HTML– JSP/Servlets: geração dinâmica de conteúdos– EJB: lógica aplicacional– JDBC/Connector, base de dados: dados persistentes

• Aplicações Web com 3 camadas– Browser: cliente HTML– JSP/Servlets: geração dinâmica de conteúdos– EJB: lógica aplicacional– JDBC/Connector, base de dados: dados persistentes

• Aplicações com 3 camadas– Aplicações EJB stand-alone: cliente– EJB: lógica aplicacional– JDBC/Connector, base de dados: dados persistentes

• Integração de aplicações empresariais– Comunicação entre plataformas J2EE

• JMS• Mensagens XML





22



Containers

A noção de contentor é central na arquitectura. Os componentes podem esperar os mesmos serviços em plataformas disponibilizadas por diferentes vendedoresOs contentores oferecem todo o suporte sistema para a execução dos componentes de forma transparente

Não existe APITrabalham por interposição

Estabelecem a interface com o sistema operativo e as outras entidades J2EEContêm a implementação do J2EE

Interface e serviços standardImplementações diferenciadas com características adicionais dos fornecedores de tecnologia



Containers vs. Components

ContainersContainers• Concorrência• Segurança• Persistência• Transacções• Disponibilidade• Fiabilidade• Gestão do ciclo de vida• Administração

ComponentsComponents• Interface utilizador• Lógica aplicacional

23



Enterprise JavaBeans

• Implementam “APENAS” a lógica aplicacional– Programador não se preocupa com mecanismos de

sistema baixo nível– Reutilizáveis em vários servidores EJB– Usam interfaces Java

• Para acederem a funcionalidade J2EE– Implementam interfaces Java

• Para poderem ser geridos pelos containers



Arquitectura EJB

24



Contratos EJB- Contrato cliente

• Contrato entre um cliente e um container– Estabelece a funcionalidade do EJB acessível aos clientes– Cliente de um EJB pode ser:

• Componentes da camada Web: Servlet e JSP• Applet• Outro EJB no mesmo container ou num container diferente• Uma aplicação Java stand-alone• Um cliente de Web Services

– Composto por:• Home interface

– Métodos para criar e localizar beans– Acessível a clientes locais e remotos

• Remote interface– Interface à lógica aplicacional– Acessível a clientes locais e remotos

• Identidade dos objectos• Interface aos Metadados• Handle



Contratos EJB - Contrato componente

• Contrato entre um EJB e um container– Permite a invocação do EJB pelos clientes– Gere o ciclo de vida das instâncias dos beans EJB– Implementa a interface home e remote– Oferece persistência transparente– Oferece informação do contexto de execução aos beans– Gere transacções, segurança, excepções, …– Implementa os callbacks

25



Chamadas a EJBs

• Os EJBs são isolados e suportados por um container EJB• As chamadas a métodos de um EJB por um cliente são interceptadas

pelo container EJB– Objectos proxy (objecto Home e objecto EJB), gerados automaticamente

• Este mecanismo de intercepção permite ao container mediar todas as interacções entre EJBs

– Instanciação de EJBs– Gestão da segurança– Controlo de concorrência– Suporte de transacções



Arquitectura dos Componentes e Containers

26



Tipos de Beans

SessionSession BeansBeans• Representam um processo

aplicacional• Uma instância por cliente• Curta duração: duração da

sessão• Transientes, não

sobrevivem a falhas no servidor

• Podem ser transaccionais

EntityEntity BeansBeans• Representam dados da

aplicação• Partilhados por múltiplos

clientes• Longa duração: mantidos na

base de dados• Persistentes, sobrevivem a

falhas no servidor• Sempre transaccionais



Session & Entity Beans

27



Session & Entity Beans



EJBs

28







Connectors

• Permite a comunicação entre componentes em containers diferentes

• Oferece funcionalidade para:– Acesso a bases de dados– Comunicação segura– Suporte de transacções

29





.NET Remoting

Equivalente ao RMI para C# / Plataforma.NET

30



Objectos Remotos

• Qualquer objecto pode ser usado remotamente derivando-o de MarshalByRefObject ou de MarshalByValObject

• MarshallByValue– Objectos serializáveis, são copiados para o cliente– Pode ser muito ineficiente

• MarshallByRef– Quando o cliente recebe uma referência de um objecto remoto ele está

efectivamente a receber uma referência a um objecto proxy local criado automaticamente pelo .NET Remoting.

– Esse proxy é encarregue de passar as chamadas dos métodos para o servidor.



Utilização de Objectos Remotos

• Requer a respectiva activação• Dois modos:• Singleton

– Apenas uma instância em cada instante– Criada aquando da primeira invocação– Requer sincronização no acesso a estado partilhado

• SingleCall– Uma nova instância é criada para cada pedido.– Após a execução de uma chamada, a próxima chamada será

servida por outra instância.

31



Tempo de Vida dos Objectos

• Tempo de vida dos objectos Singletondeterminado por sistema de leases. – Ao expirar um lease, este deve ser renovado, caso

contrário a memória ocupada pelo objecto é recuperada pelo garbage collector.

– A utilização de leases é uma alternativa mais simples àcontagem de referência distribuída



Canais

• A comunicação entre dois processos distintos é realizada através de canais, cuja função é:

– Empacotar a informação de acordo com um tipo de protocolo

– Enviar esse pacote a outro computador. • Dois tipos predefinidos:

– TcpChannel (que envia os dados por TCP em formato binário).

– HttpChannel (que utiliza o protocolo HTTP em formato XML).

• Maior flexibilidade do que no RMI na escolha dos mecanismos de serialização e protocolos de transmissão. Permitir tratar redes locais, internet, restrições de firewalls

32



Resumo das Opções

• MarshallByRef vs. MarshallByValue• Canais – TcpChannel vs. HttpChannel vs. Custom• Activação – Singleton vs. Single Call• Tempo de vida – Single Call vs. Leases



Exemplo: Servidorclass ser {static void Main() {TcpChannel chan1 = new TcpChannel(8086);ChannelServices.RegisterChannel(chan1); RemotingConfiguration.RegisterWellKnownServiceType(typeof(c_ola),

“Ola", WellKnownObjectMode.Singleton);System.Console.WriteLine("<enter> para sair...");System.Console.ReadLine();}

}

public class c_ola : MarshalByRefObject {public string MetodoOla() {return “ola!”;

}}

33



Exemplo: Cliente

class cl {static void Main() {

TcpChannel chan = new TcpChannel();ChannelServices.RegisterChannel(chan);c_ola obj = (c_ola) Activator.GetObject(typeof(c_ola),

"tcp://localhost:8086/Ola");if (obj == null)

System.Console.WriteLine("Could not locate server");else

Console.WriteLine(obj.MetodoOla());}

}



Comparação – IDL

package SimpleStocks;import java.rmi.*;import java.util.*;

public interface StockMarketextends java.rmi.Remote{float get_price( String symbol ) throws RemoteException;}

module SimpleStocks{interface StockMarket{float get_price( in string symbol );};};

using System;namespace SimpleStocks{

public interface StockMarket {float get_price(string symbol);

}

Java/RMI - Interface definitionCORBA - IDLC#/Remoting – IDL

34



////// StockMarketClient////import java.rmi.*;import java.rmi.registry.*;import SimpleStocks.*;

public class StockMarketClient{public static void main(String[] args)throws Exception{if(System.getSecurityManager() == null){System.setSecurityManager(newRMISecurityManager());}StockMarket market = (StockMarket)Naming.lookup("rmi://localhost/NASDAQ");System.out.println( "The price of MY COMPANY is "+ market.get_price("MY_COMPANY") );}}

////// StockMarketClient////import org.omg.CORBA.*;import org.omg.CosNaming.*;import SimpleStocks.*;

public class StockMarketClient{public static void main(String[] args){try{ORB orb = ORB.init();NamingContext root = NamingContextHelper.narrow(orb.resolve_initial_references("NameService") );NameComponent[] name = newNameComponent[1] ;name[0] = newNameComponent("NASDAQ","");

StockMarket market = StockMarketHelper.narrow(root.resolve(name));System.out.println("Price of MY COMPANY is " + market.get_price("MY_COMPANY"));}catch( SystemException e ){System.err.println( e );}}}

////// StockMarketClient////

namespace SimpleStocks{public class StockMarketClient{static void Main() {try {

StockMarket market = (StockMarket)Activator.GetObject(

typeof(StockMarket),“tcp://localhost:8086/NASDAQ”);

System.Console.WriteLine("The priceof MY COMPANY is " + market.get_price("MY_COMPANY") );}

}

Java/RMI - Client implementationCORBA - Client implementationC# / Remoting - Client implementation


Departamento de Engenharia Informática////// StockMarketServer////

package SimpleStocks;import java.rmi.*;import java.rmi.server.UnicastRemoteObject;

public class StockMarketImpl extends UnicastRemoteObject implements StockMarket{

public float get_price( String symbol ){float price = 0;for( int i = 0; i < symbol.length(); i++ ){price += (int) symbol.charAt( i );}price /= 5;return price;}

public StockMarketImpl( String name ) throws RemoteException{try{Naming.rebind( name, this );}catch( Exception e ){System.out.println( e );}}

}

////// StockMarketServer////

import org.omg.CORBA.*;import SimpleStocks.*;

public class StockMarketImpl extends _StockMarketImplBase{

public float get_price( String symbol ){float price = 0;for(int i = 0; i < symbol.length(); i++){price += (int) symbol.charAt( i );}price /= 5;return price;}

public StockMarketImpl( String name ) {super( name );}

}

////// StockMarketServer////

using System.Runtime.Remoting;

public class StockMarketImpl : MarshalByRefObject, SimpleStocks.StockMarket{

public float get_price( string symbol ){float price = 0;

for( int i = 0; i < symbol.length(); i++ ){price += (int) symbol.charAt(i);}

price /= 5;return price;}

}

Java/RMI - Server implementationCORBA - Server implementationC# / Remoting - Server implementation

35



////// StockMarketServer Main////

using System.Runtime.Remoting;

class StockMarketServer{static void Main(string[] args){TcpChannel chan1 = new

TcpChannel(8086);

ChannelServices.RegisterChannel(chan1);

RemotingConfiguration.RegisterWellKnownServiceType(typeof(StockMarket),“NASDAQ",WellKnownObjectMode.Singleton);

System.Console.WriteLine("<enter>para sair...");

System.Console.ReadLine();}

}

C# / Remoting - Server Main////// StockMarketServer Main////import java.rmi.*;importjava.rmi.server.UnicastRemoteObject;import SimpleStocks.*;

public class StockMarketServer{

public static void main(String[] args) throws Exception{if(System.getSecurityManager() == null){System.setSecurityManager(newRMISecurityManager());}StockMarketImpl stockMarketImpl = newStockMarketImpl("NASDAQ");}

}

////// StockMarketServer Main////import org.omg.CORBA.*;import org.omg.CosNaming.*;import SimpleStocks.*;

public class StockMarketServer{

public static void main(String[] args){try{ORB orb = ORB.init();BOA boa = orb.BOA_init();StockMarketImpl stockMarketImpl = newStockMarketImpl("NASDAQ");boa.obj_is_ready( stockMarketImpl );

org.omg.CORBA.Object object = orb.resolve_initial_references("NameService");NamingContext root = NamingContextHelper.narrow( object ) ;NameComponent[] name = newNameComponent[1];name[0] = new NameComponent("NASDAQ", "");root.rebind(name, stockMarketImpl);

boa.impl_is_ready();}catch( Exception e ){e.printStackTrace();}}}

Java/RMI - Server MainCORBA - Server Main

Documents

Métodos em Objectos Remotos · • Desvantagens – As integrações assumem uma ligação forte ... • Efectua a conversão dos parâmetros de entrada e de ... – Comunicação