1
argonavis.com.br
2
Objetos Distribuídos
Plataformas para Aplicações Distribuídas
2
Objetivos
•
Este capítulo aborda os seguintes assuntos
•
Revisão geral: orientação a objetos
•
Objetos distribuídos (Remote Method Invocation)
•
Padrões OMG
•
OMG CORBA
•
Soluções de RMI da Microsoft
•
Soluções de RMI da Sun
•
Messaging assíncrono
3
argonavis.com.br
O que é um objeto?
•
Objetos são
conceitos
que têm
•identidade,
•estado e
•comportamento
•
Características de Smalltalk, resumidas por Allan Kay:
•Tudo(em um programa OO) são objetos
•Um programaé um monte de objetos enviando mensagens uns aos outros
•O espaço(na memória) ocupado por um objeto consiste de outros objetos
•Todo objeto possui um tipo(que descreve seus dados)
•Objetos de um determinado tipo podem receber as mesmas mensagens
4
Objetos (2)
•
Em uma linguagem orientada a objetos pura
•Um número, uma letra, uma palavra, uma valor booleano, uma data, um registro, uma botão da GUI são objetos
•
Em Java, objetos são armazenados na memória de
heap
e manipulados através de uma
referência
(variável), guardada na
pilha
.
•Têm estado(seus atributos)
•Têm comportamento(seus métodos)
•Têm identidade(a referência)
•
Valores
unidimensionais
não são objetos
em Java
•Números, booleanos, caracteres são armazenados na pilha •Têm apenas identidade (nome da variável) e estado (valor
literal armazenado na variável); - dinâmicos; + rápidos Heap 001A 0010 001A 001F ref 23 5 Pilha
5
argonavis.com.br
O que é uma classe?
•Classes são uma especificaçãopara objetos
•Uma classe representa um tipo de dadoscomplexo
•Classes descrevem
•Tipos dos dados que compõem o objeto (o que podem armazenar)
•Procedimentos que o objeto pode executar (o que podem fazer)
Casa boolean abrePorta(){} int numero Color cor
static String arquiteto
12
56
72
Classe
Instâncias da classe Casa (objetos)
Casa c1 = new Casa(); c1.numero = 12; c1.cor = Color.yellow; Casa c2 = new Casa(); c2.numero = 56; c2.cor = Color.red; Casa c3 = new Casa(); c3.numero = 72; c3.cor = Color.white; c3.abrePorta();
6
Ou seja...
•
Classes não são os objetos que representam
•A planta de uma casa é um objeto, mas não é uma casa
•
Classes definem lógica estática
•Relacionamentos entre classes são definidos na programação e não mudamdurante a execução
•Relacionamentos entre objetos são dinâmicos e podem mudar. O funcionamento da aplicação reflete a lógica de relacionamento entre os objetos, e não entre as classes.
•
Classes não existem no contexto da execução
•Uma classe representavários objetos que ocupam espaço na memória, mas ela não existe nesse domínio
•A classe tem papel na criação dos objetos, mas não existe quando os objetos trocam mensagens entre si.
7
argonavis.com.br
Membros: atributos e métodos
•Uma classe define uma estrutura de dados não-ordenada
•Pode conter componentes em qualquer ordem •Os componentes de uma classe são seus membros
•Uma classe pode conter três tipos de componentes
•Membros estáticos ou de classe:não fazem parte do "tipo"
•Membros de instância:definem o tipo de um objeto
•Procedimentos de inicialização •Membros estáticos ou de classe
•Podem ser usados através da classe mesmo quando não há objetos
•Não se replicam quando novos objetos são criados •Membros de instância
•Cada objeto, quando criado, aloca espaço para eles
•Só podem ser usados através de objetos •Procedimentos de inicialização
•Usados para inicializar objetos ou classes
8 (...) CDPlayer cd1; cd1 = new CDPlayer (); cd1.liga(); cd1.selecionaFaixa (3); cd1.executa(); (...)
Objetos possuem uma interface ...
•
Através da
interface*
é possível utilizá-lo
•Não é preciso saber dos detalhes da implementação
•
O
tipo
(Classe) de um objeto determina sua interface
•O tipo determina quais mensagenspodem ser enviadas
CDPlayer liga() desliga() selecionaFaixa(int) avança() retorna() executa() pausa() para() Interface Tipo
Classe Java (tipo)
Envio de mensagem Criação de objeto Referência Em Java Formato das mensagens que se pode enviar para um objeto
9
argonavis.com.br
... e uma implementação (oculta)
•
Implementação não interessa à quem
usa
objetos
•
Papel do usuário de classes
•não precisa sabercomo a classe foi escrita, apenas quais seus métodos, quais os parâmetros (quantidade, ordem e tipo) e valores que são retornados
•usa apenas a interface(pública) da classe
•
Papel do desenvolvedor de classes
•definenovos tiposde dados
•expõe, através de métodos, todas as funções necessárias ao usuário de classes, e ocultao resto da implementação
•tem a liberdadede mudar a implementaçãodas classes que cria sem que isto comprometa as aplicações desenvolvidas pelo usuário de classes
10
•
Separação interface-implementação: maior reuso
•Reuso depende de bom planejamento e design
•
Uma vez criada uma classe, ela deve representar uma
unidade de código útil para que seja reutilizável
•
Formas de uso e reuso
•Uso e reuso de objetoscriados pela classe: mais flexível •Composição: a “é parte essencial de”b
•Agregação: a “é parte de”b •Associação: a “é usado por”b
•Reuso da interface da classe: pouco flexível •Herança: b “é”a(substituição pura)
ou b “é um tipo de”a(substituição útil, extensão)
Reuso de implementação
b a b a b a b a * Notação UML *11
argonavis.com.br
Agregação, composição e associação
•Composição: um tremé formado por locomotiva e vagões
•Agregação: uma locomotiva temum farol (mas não vai deixar de ser uma locomotiva se não o tiver)
•Associação: um tremusauma estrada de ferro (não faz parte do trem, mas ele depende dela)
Trem EstradaDeFerro Trem Locomotiva usa Vagão Locomotiva 1..* 1 Farol 12
Herança (reuso de interface)
•
Um carro
é um
veículo
•
Fuscas e Porsches
são
carros (e também veículos)
Veículo Carro Veículo Carro Fusca Porsche Veículo getVelocidade():float getPassageiros():int acelera() freia() representação UML representação UML detalhada de ‘Veículo’ representação UML simplificada (não mostra os métodos)
13 argonavis.com.br
Extensão e sobreposição
•
Extensão
•
Sobreposição
Carro Fusca Porsche Veículo Carro abastece() fechaPorta() abrePorta() abrePorta() getVelocidade() freia() Redefine os métodos implementadospreviamente (Um objeto do tipo Fusca tem o mesmo númerode métodos de um objeto do tipo Carro
Acrescenta novos
métodos aos já herdados (Um objeto do tipo Carro tem maismétodos que um objeto do tipo Veiculo) Veículo getVelocidade():float getPassageiros():int acelera() freia() 14
Polimorfismo
•
Uso de um objeto no lugar de outro
•pode-se escrever código que não dependa da existência prévia de tipos específicos
Figura
Círculo Quadrado Triângulo desenha()
desenha() desenha() desenha() Desenhista
geraFigura()
«usa»
Conhece apenas interface do tipo genérico (Figura) Chama "desenha()" sem saber qual objeto será desenhado. Objeto real pode ser "plugado"
durante a execução. Cada desenha() sobrepõe funcionamento original com algo diferente
Ligação da interface com o objeto real pode ser feita durante a execução
15
argonavis.com.br
Encapsulamento
•
Simplifica o objeto expondo apenas a sua interface
essencial
•
Código dentro de métodos é naturalmente encapsulado
•Não é possível acessar interior de um método fora do objeto
•
Métodos que não devem ser usados externamente e
atributos podem ter seu nível de acesso controlado em
Java, através de modificadores
•private: apenas acesso dentro da classe
•package-private(default): acesso dentro do pacote*
•protected: acesso em subclasses
•public: acesso global
* não existe um modificador com este nome em Java. A ausência de um modificador de acesso deixa o membro com acesso package-private
16
Resumo de características OO
•Abstração de conceitos
•Classes, definem um tipo separando interface de implementação
•Objetos: instâncias utilizáveis de uma classe •Herança: "é um"
•Aproveitamento do códigona formação de hierarquias de classes
•Fixada na compilação (inflexível) •Associação "tem um"
•Consiste na delegação de operações a outros objetos
•Pode ter comportamento e estrutura alterados durante execução
•Vários níveis de acoplamento: associação, composição, agregação •Encapsulamento
•Separação de interface e implementação que permite que usuários de objetos possam utilizá-los sem conhecer detalhes de seu código •Polimorfismo
17
argonavis.com.br
Componentes
•
Composição de um ou mais objetos com interface
definida, meta-informação, etc. fácil de distribuir,
executar, implantar
•
Em Java, componentes são armazenados em JARs
•Java Archive: extensão de ZIP com meta-informação
•Podem ser formados por classes, arquivos, etc.
•Podem ser executáveis, instaláveis ou bibliotecas
•Ex: JavaBeans, EJB, aplicações Web, etc.
•
.NET oferece componentes similares
•Assemblies: empacotados em DLLs, EXEs, CABs
•Contém arquivo com meta-informação
•Reutilizáveis, e com interface definida
18
Java ARchive
•Para construir, pode-se usar WinZIP
•Estrutura (META-INF e Manifest obrigatórios)
•Exemplo de Manifest.mf para componente executável
•Para executar
> java -jar abc.jar META-INF Manifest.mf pacote subpacote Classe Classe Classe Arquivo Main-class: com.empresa.exec.Executavel ... abc.jar
19
argonavis.com.br
Sistemas distribuídos: RMI e RPC
•RMI e RPC são técnicas usadas para isolar, dos clientes e servidores, os detalhes da comunicação em rede
•Utilizam protocolos padrão, stubs e interfaces
•Lidam com diferentes representação de dados
•RPC: Remote Procedure Call
•Chamada procedural de um processo em uma máquina para um processo em outra máquina.
•Permitem que os procedimentos tradicionais permanecam em múltiplas máquinas, porém consigam se comunicar
•RMI: Remote Method Invocation •É RPC em versão orientada a objetos
•Permite possível chamar métodos em objetos remotos
•Beneficia-se de características do paradigma OO: herança, encapsulamento, polimorfismo
20
Dificuldades em RMI
•Para dar a impressão de comunicação local, implementações de RPC precisam lidar com várias dificuldades, entre elas
•Marshallinge unmarshalling(transformação dos dados em um formato independente de máquina)
•Diferenças na forma de representação de dadosentre máquinas
•Implementações RMI tem ainda que decidir como lidar com particularidades do modelo OO:
•Como implementar e controlar referências dinâmicas remotas (herançae polimorfismo)
•Como garantir a não duplicação dos dados e a integridade do
encapsulamento?
•Como implementar a coleta de lixo distribuída?
•Como implementar a passagem de parâmetrosque são objetos?
•Padrões diversos. Como garantir a interoperabilidade? •OMG - Object Management Group!
21
argonavis.com.br
O que é a OMG
•
Um dos maiores
consórcios
do mundo na área de
tecnologia da informação
•500-800* membros (grandes empresas de TI, empresas de telecom, universidades, governo, etc.)
•
Cria e mantém especificações que visam a
interoperabilidade
entre aplicações distribuídas
orientadas a objetos
•
Não desenvolve produtos: somente
especificações
•Todas as especificações podem ser baixadas de graça
* O número de membros ativos varia
22
Alguns membros da OMG
? ABN AMRO Bank? AT&T ? Attachmate ? Bank of America ? BBV Software Services AG ? BEA Systems ? Boeing
? Borland Software Corporation
? Carnegie Mellon University
? Cisco Systems
? Deutsche Telekom AG
? Ericsson
? Federal Reserve System
? Fujitsu ? GE Aircraft Engines ? Hewlett-Packard ? Hitachi ? IBM ? Lockheed Martin ? Microsoft ? Motorola ? NASA
? National Science Foundation
? NEC ? Nokia ? Oracle ? Rational Software ? Siemens AG ? Sun Microsystems ? Unisys ? US Postal Service ? Visionnaire (Brasil) ? W3 Consortium ... e vários outros.
23
argonavis.com.br
Padrões da OMG
•
MDA
- Model Driven Architecture
•
UML
- Unified Modelling Language
•
MOF
- Meta Object Facility
•
XMI
- XML Metadata Interface
•
CWM
- Common Warehouse Metamodel
•
CORBA
- Common ORB Architecture
24
MDA: Model Driven Architecture
•
Busca
separar
lógica de apresentação e lógica de
negócios da tecnologia da plataforma
•Isola aplicações corporativas da evolução da tecnologia
•Controla todo o ciclo de vida da aplicação: análise, design, implementação, instalação, manutenção, evolução
•
Aplicações independentes de plataforma construidas
usando MDA podem executar em plataformas
abertas ou não
•.NET, J2EE, Web Services, CORBA, ...
•
Padrões relacionados
25
argonavis.com.br
UML: Unified Modeling Language
•
Linguagem gráfica
independente de metodologia que
representa análise e design orientados a objeto
•
Define diversos diferentes tipos de diagramas
•Quatro tipos de diagramas estruturais: classe, objeto, componente, deployment
•Cinco tipos de diagramas comportamentais: casos de uso, atividade, seqüência, colaboração, estado
•Três tipos de diagramas de representação de modelos: pacotes, modelos, subsistemas
26
MOF - Meta Object Facility
•
Padroniza um
meta-modelo
para análise e design
orientados a objetos
•Estruturas similares em linguagens diferentes
•Repositório para modelos e metamodelos
•
Permite que informações possam ser trocadas entre
meta-modelos diferentes
•Modelos UML, que são baseados no meta-modelo MOF, podem ser compartilhados entre ferramentas usando XMI
27
argonavis.com.br
XMI - XML Metadata Interchange
•
Permite que modelos compatíveis com o MOF
possam ser compartilhados como conjuntos de dados
XML
(XML DataSet)
•Informações do UML e MOF são incluídos em tags XML de acordo com esquema padrão
•
Podem ser
mapeados a XML
usando XMI:
•Modelos de dados, expressos em CWM
•Modelos de aplicações, expressos em UML
28
CWM
- Common Warehouse Metamodel
•
Padrão para representação de modelos de dados de
uma corporação
•Engloba diferentes repositórios e armazéns de dados
•
Inclui meta-modelos para
•Dados
•Transformações
•OLAP
•Data mining
•Funções de data-warehousing como processos e operações
29
argonavis.com.br
CORBA - Common ORB Architecture
•
ORB
=
O
bject
R
equest
B
roker: corretor de
requisição de objetos
•
Especificação para
interoperabilidade
de sistemas
•
Independente de
•Plataforma,
•Sistema operacional,
•Linguagem de programação
•Protocolo de rede
•
Composta por várias outras especificações menores
•OMG IDL - Interface Definition Language
•IIOP - Internet Inter-ORB Protocol
•POA - Portable Object Adapter
•CCM - CORBA Component Model
30
Arquitetura CORBA
•Common Object Request Broker Architecture •Especificação da OMG - Object Management Group
•Padrão para interoperabilidade de objetos distribuídos
•Componentes
• IIOP- Internet Inter ORB Protocol
• ORB- Object Request Broker
•OMG IDL- Interface Definition Language
• COS- CORBA Object Services (opcionais)
•Principais características
• Transparência de localidade: não precisa saber onde estão objetos
• Independência de plataforma: objetos podem estar distribuídos em plataformas diferentes
• Neutralidade de linguagem: objetos se comunicam mesmo escritos em linguagens diferentes
31
argonavis.com.br
Comunicação CORBA: ORB
•IDL
•Abstração da interface do objeto remoto
•Usada para gerarstubs e esqueletos
•Stub(lado-cliente)
•Transforma os parâmetros em formato independente de máquina (marshalling) e envia requisições para o objeto remoto através do ORB passando o nome do método e os dados transformados
•ORB: barramento comum
•ORB do cliente passa dados via IIOP para ORB do servidor
•Esqueleto(lado-servidor)
•Recebe a requisição com o nome do método, decodifica (unmarshals) os parâmetros e os utiliza para chama o método no objeto remoto
•Transforma (marshals) os dados retornados e devolve-os para o ORB ORB void m() {...} ObjetoRemoto ORB srv-->m(); stub Cliente IIOP IIOP Internet Comunicação aparente IDL 32
Padrões associados a CORBA
•
OMG
IDL
- Interface Definition Language
•
IIOP
- Internet Inter-ORB Protocol
•
POA
- Portable Object Adapter
•
CCM
- Corba Component Model
33
argonavis.com.br
OMG IDL - Interface Definition Language
•
Linguagem usada para expressar a
interface de
operações
para um objeto
•Usa sintaxe genérica (mas parecida com C++)
•
Isola a
interface
dos detalhes da implementação
(inclusive linguagem, tipos, sistema operacional,
tecnologia, etc.)
•Usuário da interface ignora detalhes da implementação
•
Existem
mapeamentos de IDL
para todas as
principais linguagens de programação
•C, COBOL, Lisp, C++, Ada, Java, Python, Smalltalk têm mapeamento padrão definido na OMG
34
IIOP - Internet Inter ORB Protocol
•
Um cliente acessa os
serviços de um objeto
local ou
remoto através do
ORB
•O cliente não distingue objeto local de objeto remoto
•
IIOP viabiliza a
comunicação entre ORBs
diferentes,
oferecendo
transparência de localidade
•Se o cliente chama um objeto remoto,é o ORB que sabe que ele é remoto(do ponto de vista do cliente, todos os objetos são locais) e usa IIOP para passar as informações de chamada e receber os resultados
•IIOP abstrai as diferenças de plataforma. ORB converte objetos (marshalling) no formato IIOP e de volta para o formato nativo (unmarshalling)
35
argonavis.com.br
POA - Portable Object Adapter
•Permite a criação de implementações de objetos que são portáteis entre diferentes fabricantes de ORBs
•Mapeia abstrações de objetos CORBA às suas implementações verdadeiras
•Podem ser configurados (transparente para cliente)
•Podem ser aninhados
Fonte: http://www.iona.com POA Stub ORB Cliente Objeto Remoto 36
CCM - CORBA Component Model
•Arquitetura para criar aplicações baseadas em componentes reutilizáveis que rodam em ambiente operacional de um servidor de aplicações, utilizando seus serviços
•Arquitetura consiste de
•Containers CCM (ambiente que oferece serviços aos componentes)
•Componentes CORBA (sessão com estado e sem estado, entidade)
•POA, ORB e serviços CORBA
•Implementação padrão: Enterprise JavaBeans
Componente CCM Nomes Transações Segurança Persistência Servidor de Aplicações Container CCM Cliente Interage com
37
argonavis.com.br
OMA - Object Management Architecture
•
Oferece um ambiente comum
contendo serviços e facilidades
disponíveis aos objetos via ORB
•
Classifica os objetos em quatro categorias. São
acessíveis através de interfaces IDL
•CORBA Services: são serviços essenciais como registro de nomes, transações, segurança, persistência, etc.
•CORBA Facilities: serviços não essenciais porém genéricos (impressão, internacionalização)
•CORBA Domain Objects: serviços específicos para um determinado tipo de indústria
•Application Objects: serviços específicos de uma
aplicação. Esta categoria não faz parte da padronização.
38
Arquiteturas Microsoft
•
Apesar de participar ocasionalmente da OMG, a
Microsoft possui seus próprios modelos de
arquitetura para objetos distribuídos
•COM - Component Object Model
•DCOM - Distributed COM
•COM+ / Microsoft Transaction Server
•Plataforma .NET
•
Tecnologias restritas a plataformas Microsoft
•
Dentro da filosofia da OMG, que busca integração,
há capítulos da especificação dedicados à integração
entre CORBA e essas arquiteturas
39
argonavis.com.br
COM - Component Object Model
•
Oferece uma interface e ambiente que opera sobre
essa interface para permitir o reuso de objetos
•Objetos COM podem ser escritos em qualquer linguagem
•Clientes conectam-se apenas através de interfaces
•Interfaces são escritas em Microsoft IDL (MIDL)
•Objetos são registrados em serviços de nomes
•Middleware gera código de adaptação da interface (stubs)
Middleware
void m() {...} Objeto COM srv-->m();
Cliente MIDL
stub Registry stub
Localiza objeto Java C++ 40 Processo Cliente
DCOM - Distributed COM
•
DCOM é uma versão de COM estendida para
funcionar em rede
•Protocolo DCE RPC faz a comunicação
•
Comunicação é transparente a clientes COM
Objeto Local Processo Servidor Objeto Local COM Stub COM Proxy Local Proxy Remoto Aplicação Processo Servidor Objeto Local COM Stub RPC RPC Máquina local Máquina remota Interfaces MIDL
41
argonavis.com.br
COM+
•
COM+
(MTS - Microsoft Transaction Service)oferece
serviços de middleware
para COM e DCOM
•Suporte a transações locais (OLETx) ou distribuídas (XA)
•Segurança declarativa (por papéis) ou programática
•Controle de ciclo de vida, pooling de recursos, etc.
•
Baseado no modelo de componentes e containers
•Container para requisição de objetos (ORB baseado em COM/DCOM)
•Container Web (Internet Information Server)
•
COM+ tem conceitos similares ao CCM
•Promove arquitetura em três camadas (apresentação, negócios e dados) baseada em componentes e serviços
•Não suporta componentes de entidade (apenas de sessão)
42
Java RMI
•
Outra solução popular de comunicação distribuída
através de objetos remotos que não é CORBA é o
Java Remote Method Invocation
•
Consiste de
•Um protocolo RPC: Java Remote Method Protocol •Um registro de objetos: RMI Registry
•Uma APIincluindo uma especificação para definição de interfaces (similar a IDL, mas usando Java)
•
Java RMI tem a vantagem de ser mais simples para
desenvolvedores de sistemas 100% Java
43
argonavis.com.br
Arquitetura Java RMI
•A arquitetura Java RMI pode ser comparada com a arquitetura CORBA
•Usa um protocolo: JRMP- Java Remote Method Protocol
•Possui um serviço de registro de nomes: RMI Registry- que funciona de forma centralizada e não hierárquica
•Possui uma interface descrevendo as operações remotas: uma extensão de java.rmi.Remoteé base para sua interface "IDL"
•Principais características
• Centralizada: cliente tem que saber em que servidor está o objeto remoto (não é transparente quanto à localização)
• Independente de plataforma: por ser 100% Java (não suporta comunicação com objetos escritos em outras linguagens)
• Suporta transferência de bytecode: objetos remotos podem ser transferidos fisicamente para o cliente (por ser 100% Java)
• Suporta coleta de lixo distribuída
• Suporta passagem de parâmetros por valor e por referência
44
Comunicação RMI
•Interface Remote
•Abstração da interface do objeto remoto
•Usada para gerarstubs e esqueletos
•Stub(lado-cliente) •Transforma parâmetros
(serializados) e envia requisição pela rede (sockets)
•Esqueleto(lado-servidor)
•Recebe a requisição, desserializa os parâmetros e chama o método no objeto remoto. Depois serializa objetos retornados.
•RMIRegistry
•Servidor registra o objeto usando java.rmi.Naming.bind()
•Cliente recupera o objeto usando java.rmi.Naming.lookup() RMIRegistry void m(){...} ObjetoRemoto srv.m(); stub Cliente JRMP Comunicação aparente void m(); java.rmi.Remote ObjRemote lookup() bind()
45
argonavis.com.br
Java RMI sobre IIOP
•
Java RMI sobre IIOP
é a solução da Sun para
integração entre o mundo RMI e o mundo CORBA
•Mesmo modelo de desenvolvimento que Java RMI (mais fácil para programadores Java)
•Integração e compatibilidade com o modelo CORBA (pode comunicar-se com serviços e objetos CORBA ou
accessíveis via CORBA)
•
Java RMI suporta os mesmos padrões que CORBA
•Serviço de nomes COS Naming
•Linguagem para definição de interfaces OMG IDL ou Java
•Protocolo RPC: IIOP
46
Arquitetura Java RMI sobre IIOP
•Modelo de programação RMI com comunicação CORBA •Usa protocolo IIOP
•Comunica-se através de ORB e IIOP
•A interface java.rmi.Remoteé base para sua interface remota
•Gera IDLse necessário
•Principais características
• Transparência de localidade: não precisa saber onde estão objetos
• Independência de plataforma: objetos podem estar distribuídos em plataformas diferentes
• Neutralidade de linguagem é possível: pode se comunicar com objetos escritos em linguagens diferentes (gera IDL)
• Suporta passagem de parâmetros por valor e por referência • Sem suporte à transferência de bytecode
• Sem suporte à coleta de lixo distribuída
47 argonavis.com.br
Comunicação RMI-IIOP
•Interface Remote •Abstração da interface do objeto remoto•Usada para gerarstubs e esqueletos
•Stub(lado-cliente) •Transforma parâmetros
(serializados) em formato independente
de máquina e envia requisição pela rede através do ORB
•ORB: barramento comum
•ORB do cliente passa dados via IIOP para ORB do servidor
•Esqueleto(lado-servidor)
•Recebe a requisição do ORB e desserializa os parâmetros
•Chama o método do objeto remoto
•Transforma os dados retornados e devolve-os para o ORB void m() {...} ObjetoRemoto srv.m(); Cliente Comunicação aparente void m(); java.rmi.Remote ObjRemote
ORB stub ORB
IIOP IIOP
Internet
48
Messaging: comunicação assíncrona
•Método de comunicaçãoentre componentes ou aplicações•Arquitetura peer-to-peercom serviço centralizadopara repasse de mensagens recebidas e enviadas
•Clientes e servidores enviam e recebem mensagens para canais administrados por serviço central de mensagens (MOM)
•Comunicação distribuída com acoplamento fraco
•Interface genérica: MOM ignora conteúdo e repassa qualquer coisa. Formato do conteúdo deve ser conhecido pelas partes
•Assíncrona: Comunicação pode ocorrer mesmo que o cliente e servidor não estejam disponíveis ao mesmo tempo
MOM C S S C C C
49
argonavis.com.br
Message-oriented Middleware (MOM)
•
Sistemas de messaging são freqüentemente chamados de
Message-Oriented Middleware
(
MOM
)
•Conceito não é novo: já existiam há algum tempo em implementações proprietárias (e incompatíveis)
•Java Message Service API: solução independente de fabricante para acessar serviços MOM por clientes Java
•
Alguns produtos MOM compatíveis com JMS:
•Open source: JBossMQ, OpenJMS, JORAM
•IBM MQSeries, IPlanet MQ, Bea WebLogic, HP-MS, Progress SoniqMQ
•Mais em: java.sun.com/products/jms/
50
Messaging vs. RMI/RPC
•
Messaging
•Mensagens são representadas como eventos
•Interface genérica(reutilizada em aplicações diferentes)
•Arquitetura centralizada(tudo passa pelo MOM)
•Serviços de nomes localizam canais de comunicação
(destinos)
•
RMI/RPC (Corba, Java RMI, etc.)
•Mensagens são representadas como chamadaspara métodos remotos
•Cada aplicação se comunica através de interface definida
•Pode ser descentralizado(rede de ORBs ligados por IIOP)
51
argonavis.com.br MOM
Messaging vs. RMI/RPC
•Sistema de Messaging com paradigma pub/sub
Protocolo comum:
mensagem
•Sistema RMI/RPC (Java RMI ou CORBA)
Protocolo comum:
interface dos objetos Message Broker ORB srv.metodo(); stub Cliente ORB srv.metodo(); stub Cliente ORB skeleton metodo() { // ... } Objeto Remoto Inter-ORB Protocol mom.publica(); Remetente onMessage(msg) { . . .} Destinatário msg msg inscreve -se notifica 52
Web Services
•
Ambiente de computação distribuída (DCE) que
utiliza
XML
em todas as camadas
•No formato de dados usado na comunicação
•Na interfaceusada para descrever as operações suportadas
•Na aplicação usada para registrar elocalizar serviços
•
Serviços são transportados principalmente via HTTP
•Podem também utilizar outros protocolos populares
•
Web Services visam comunicação entre
máquinas
•Serviços podem ser implementados usando CGI (com C, Perl, etc.), ASP, PHP, servlets, JSP, CFML, etc.
•Acesso é feito via clientes HTTP (ou de outros protocolos)
53
argonavis.com.br
Serviços Web elementares
•
Clientes HTTP usam o método POST para
enviar
dados
•Tipicamente usado por browsers para enviar dados de formulários HTML e fazer upload de arquivos
•
Exemplo
•Formulário HTML
•Requisição POST gerada pelo browser para o servidor
POST /cgi-bin/catalogo.pl HTTP/1.0
Content-type: text/x-www-form-urlencoded
Content-length: 15
isbn=2877142566
<FORM ACTION="/cgi -bin/catalogo.pl" METHOD="POST">
<H3>Consulta preço de livro</H3>
<P>ISBN: <INPUT TYPE="text" NAME=" isbn"> <INPUT TYPE="Submit" VALUE="Enviar"> </FORM> Cabeçalho HTTP Mensagem(corpo da requisição) Linha em branco 54
Enviando XML sobre POST
•
Você pode criar um
servico RPC
simples (um Web Service!)
trocando mensagens XML via HTTP POST!
•Defina esquemaspara as mensagens de chamada e resposta
•Escreva clienteque envie requisições POST para servidor Web
•Escreva uma aplicação Web(JSP, ASP, PHP, servlet, CGI)
POST /ISBNService.jsp HTTP/1.0
Content -type: text/xml Content -length: 90 <chamada>
<funcao>
<nome>getPrice</nome> <param>2877142566</param> </funcao>
</chamada>
HTTP/1.1 200 OK Content -type: text/xml Content -length: 77 <resposta> <funcao> <param>19.50</param> </funcao> </resposta> ISBNService.jsp ISBNClient ISBNQuery getPrice() 2877142566 19.50 BD 1 2 3 4 gera requisição gera resposta
55
argonavis.com.br
XML-RPC
•
Especificação para RPC em XML via HTTP POST
•Projetada para ser a solução mais simples possível
•Várias implementações: veja www.xml-rpc.com
•
Exemplo anterior implementado com XML-RPC
(cabeçalhos HTTP omitidos)<methodCall>
<methodName>getPrice</methodName> <params> <param> <value><string>2877142566</string></value> </param> </param> </methodCall> <methodResponse> <params> <param> <value><double>19.5</double></value> </param> </param> </methodResponse> Resposta Requisição 56
Arquitetura de Web Services: papéis
•Provedor de serviços
•Oferece serviços, alguns dos quais podem ser Web Services
•Registro de serviços
•Catálogo de endereços: repositório central que contém informações sobre web services
•Cliente de serviços
•Aplicação que descobre um web service, implementa sua interface de comunicação e usa o serviço
Provedor de serviços Registro UDDI Cliente 1 2 3 4 5 publica procura mapeia interface usa acha SOAP WSDL
57
argonavis.com.br
Arquitetura de Web Services: camadas
•Serviços oferecidos via plataforma Web (HTTP) ou via SMTP •Protocolo, interface de comunicação e registro são todos definidos em
esquema XML padronizado
•Componentes
• SOAP- Simple Object Access Protocol
• UDDI- Universal Discovery, Description and Integration (registry)
• WSDL- Web Service Description Language
•Principais características
• Interoperabilidade: permite a comunicação entre arquiteturas diferentes (usa um formato de mensagem padrão)
• Transparência de localidade: não precisa saber onde estão objetos
• Independência de plataforma: objetos podem estar distribuídos em plataformas diferentes
• Neutralidade de linguagem: objetos se comunicam mesmo escritos em linguagens diferentes
58
Comunicação SOAP: ORB
•WSDL
•Contém, entre outras informações, descrição da interface do objeto remoto
•Usada para gerarcódigo do cliente e/ou servidor
•Stub(lado-cliente)
•Transforma os tipos e coloca os dados em um envelope SOAP
•Recebe a resposta do servidor, abre o envelope e remove os dados.
•Registro UDDI
•Onde cliente obtém descrição do serviço (ou localização do WSDL)
•Handler(lado-servidor)
•Recebe mensagem em envelope SOAP, extrai parâmetros (unmarshalling), constrói a chamada do método
•Chama o método, obtém resposta, coloca em envelope SOAP (marshalling) e devolve a mensagem.
void m() {...} Serviço J2EE srv.m(); stub Cliente .NET HTTP Registro UDDI WSDL SOAP
59
argonavis.com.br
SOAP
•
S
imple
O
bject
A
ccess
P
rotocol
•
Protocolo padrão baseado em XML para trocar
mensagens
entre aplicações
•SOAP não é um protocolo RPC, mas um par de mensagens SOAP pode ser usado para esse fim
•Transporte pode ser HTTP, SMTP ou outro
•Mensagens podem conter qualquer coisa (texto, bytes)
•É extensível (mecanismo de RPC, por exemplo, é extensão)
Envelope Attachment Attachment XML XML Mensagem SOAP Header Body Envelope Estrutura de uma mensagem SOAP Conteúdo baseado em esquema do usuário ... 60
Simples requisição SOAP-RPC
•
Principal aplicação do SOAP, hoje, é RPC sobre HTTP
•Esquema do corpo da mensagem lida com RPC
POST /xmlrpc -bookstore/bookpoint/BookstoreIF HTTP/1.0 Content -Type: text/xml; charset="utf -8"
Content -Length: 585 SOAPAction: "" <?xml version="1.0" encoding="UTF -8"?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance"
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > <env:Body>
<ans1:getPrice xmlns:ans1="http://mybooks.org/wsdl"> <String_1 xsi:type="xsd:string">2877142566</String_1> </ans1:getPrice>
</env:Body> </env:Envelope>
61
argonavis.com.br
Resposta SOAP-RPC
HTTP/1.1 200 OKContent -Type: text/xml; charset="utf -8" SOAPAction: ""
Date: Thu, 08 Aug 2002 01:48:22 GMT
Server: Apache Coyote HTTP/1.1 Connector [1.0] Connection: close
<?xml version="1.0" encoding="UTF -8"?>
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance"
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns0="http://mybooks.org/types"
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > <env:Body>
<ans1:getPriceResponse xmlns:ans1="http://mybooks.org/wsdl"> <result xsi:type="xsd:decimal">19.50</result>
</ans1:getPriceResponse> </env:Body> </env:Envelope> Resposta (Preço) 62
Descrição de um serviço RPC: WSDL
•
Para saber usar um Web Service, é preciso
•Saber o que um serviço faz (quais as operações?)
•Como chamar suas operações (parâmetros? tipos?)
•Como encontrar o serviço (onde ele está?)
•
W
eb
S
ervices
D
escription
L
anguage
•Documento XML de esquema padrão que contém todas as informações necessárias para que um cliente possa utilizar um Web Service
•Define informações básicas (operações, mapeamentos, tipos, mensagens, serviço) e suporta extensões
•Tem basicamente mesmo papel que linguagens IDL
usadas em outros sistemas RPC
63
argonavis.com.br
.NET
•.NETé a nova arquitetura da Microsoft para aplicações locais e distribuídas
•Comunicação de rede baseada em Web Services(e não mais em protocolos RPC proprietários): ainda é comum usar COM/DCOM mas indiretamente através de wrappers
•Compiladores .NET traduzem código de várias linguagens diferentes para bytecode comum(MSIL: Microsoft Intermediate Language) que é independente de versões do Windows*
•Plataforma .NET é baseada em máquina virtual(CLR: Common Language Runtime) que executa bytecode
•Gerencia aplicações: memória (coleta de lixo), threads, acesso remoto
•Principal linguagem: C# tem sintaxe quase idêntica a Java. Suporta tratamento de exceções, referências, interfaces, etc.
•Framework inclui ferramentas (Visual Studio) e S.O. (Windows)
* MSIL, CLR e CLI são especificações publicadas pelo consórcio ECMA. Uma versão de .NET open-source e multi-plataforma está em desenvolvimento (Mono)
64
Arquitetura
65
argonavis.com.br
.NET: Linguagens suportadas
•Todas as linguagens abaixo podem ser compiladas para bytecode compatível com a máquina virtual CLR
•Aplicações podem ser construídas por desenvolvedores escrevendo código em linguagens diferentes e gerando os mesmos binários
•Linguagem compartilham gerenciamento de memória, recursos (coleta de lixo) e tipos de dados (CTS: Common Type System). Objeto pode usar ou herdar de objeto escrito em outra linguagem
APL Fortran Pascal
C++ Haskell Perl
C# Java 1.4 (J++) Python COBOL Microsoft JScript RPG Component Pascal Mercury Scheme Curriculum Mondrian SmallTalk Eiffel Oberon Standard ML
Forth Oz Microsoft Visual Basic
66
Java vs. .NET
•Independência de plataforma
•Máquina Virtual Java (JVM): roda em todas as plataformas mais populares (Windows, Mac, Unix, palmtops, celulares, cartões inteligentes) e browsers
•Máquina Virtual Microsoft (CLR): roda nas plataformas Microsoft (Windows para desktop, servidor, palmtops, celulares, cartões) e browsers (Internet Explorer)
•Independência de linguagem e tipos de dados
•Plataforma Java: executa bytecode gerado a partir de código Java (outras linguagens, como Python, geram bytecode Java, mas Sun não suporta). Busca integração com outras linguagens via CORBA
•Plataforma .NET: bytecode pode ser gerado a partir de diversas linguagens. Modelo de dados é compartilhado e podem-se misturar objetos escritos em linguagens diferentes.
67
argonavis.com.br
CORBA (J2EE) vs. .NET
•Dependência de fabricante
•CORBA: solução de integração aberta: suportada por cerca de 700 empresas independentes
•.NET: solução da Microsoft para integração entre diferentes linguagens e plataformas Microsoft
•Disponibilidade
•.NET ainda depende muito de integração com sistemas existentes. Serviços prometidos ainda não existem.
•CORBA: implementações em operação de vários fabricantes.
•Performance e produtividade
•Benchmarks imparciais (theserverside.com) apontam vantagens na produtividade e performance nas aplicações .NET. Isto é facilitado pela disponibilidade de ferramentas, múltiplas linguagens .NET, uso de arquiteturanativa e acoplada e capacidade de integração do fabricante com seu próprio sistema operacional
68
Comparação entre soluções de RPC
Registro Descrição de Serviços Transporte
Java RMI
CORBA RMI / IIOP DCOM
RMI Registry
COS Naming JNDI SCM
Java
OMG IDL OMG IDLJava ou MIDL
Java RMI
IIOP IIOP (~DCE RPC)MS RPC
Web Services*
UDDI WSDL SOAP
* Vale também para.NET usando apenas Web Services como solução de comunicação em rede. Na prática, é mais comum, hoje, usar .NET sobre COM/DCOM através de wrappers (Runtime COM Wrapper)
69
argonavis.com.br
Fontes
[1] Helder da Rocha.J100 - Programação Orientada a Objetos usando Java.
2003. http://www.argonavis.com.br/cursos/java/j100
[2] Object Management Group. http://www.omg.org
[3]Helder da Rocha.J433 - Minicurso de Aplicações Distribuídas em Java.
2000. http://www.argonavis.com.br/cursos/java/j433
[4] David Flanagan et al.Java Enterprise in a Nutshell, 2nd. edition. Abril
2002 (O'Reilly).
[5] Microsoft. Understanding the .NET Framework. Microsoft Corporation.
http://msdn.microsoft.com/netframework/using/understanding/netframe work/default.aspx
[6] Wei Huang. Comparison between .NET and CORBA. OGI, 2003.
http://www.cse.ogi.edu/class/cse515/middleware/corba-net.pdf
70
Plataformas para Aplicações Distribuídas
Versão 1.0 © 2003, Helder da Rocha
