IA847 Projeto de Sistemas Distribuídos Abertos143.106.148.168:9080/Cursos/IA847/01-07/ia847.pdf · global (por exemplo, ... convêniência, etc. Exemplo: Windows, Linux, Java, MATLAB

IA847Projeto de Sistemas Distribuídos Abertos

Prof. Eleri CardozoDCA/FEEC/Unicamp

[email protected]://www.dca.fee.unicamp.br/~eleri

mailto:[email protected]

IA847 - Prof. Eleri Cardozo 2

Sistemas Distribuídos

Um sistema distribuído é um sistema computacional com as seguintes propriedades:

1. Distribuição: um subconjunto de seus componentes são controlados por entidades independentes e dispersas (processos, máquinas virtuais, etc.).

2. Concorrência: um subconjunto de seus componentes executam concorrentemente (paralelismo real ou pseudo-paralelismo).

3. Falhas parciais: qualquer componente do sistema pode falhar independentemente dos demais.

4. Assincronismo: as atividades do sistema não são regidas por um relógio global (por exemplo, pode ser impossível estabelecer causa-efeito ou determinar precisamente o estado do sistema).


Sistemas Abertos

Sistemas abertos são sistemas implementados segundo padrões abertos.

Padrão aberto: documento estabelecido por consenso e publicado por organismo de padronização acreditado para uso comum e repetitivo. Exemplo: Protocolos TCP/IP (IETF), RM-ODP (ISO), UML (OMG).

Padrão de-facto: padrões aceitos por razões de disponibilidade, custo, convêniência, etc. Exemplo: Windows, Linux, Java, MATLAB.

OBS: 1. A motivação para uso de padrões aberto é motivado pela independência de fornecedores.

2. Um sistema desenvolvido segundo padrões abertos não necessariamente é um sistema gratuito ou de código aberto.


Sistemas Abertos: Classificação

Podemos classificar sistemas abertos em quatro categorias:

1. Modelos de referência: descrevem os componentes do sistema, suas funções, relações e formas de interação. Exemplo: Modelos OSI e ODP.

2. Arquiteturas de referência: igual aos modelos de referência, mas com especificação mais precisa das interfaces e pontos de referência entre os componentes do sistema. Exemplo: Arquiteturas SOA e OMA.

3. Arquiteturas abertas: igual às arquiteturas de referência, mas com especificação precisa dos protocolos de interação entre os componentes do sistema. Exemplo: Arquiteturas CORBA e TCP/IP.

4. Implementações de referência: provêem código aberto (gratuito ou não) para os componentes fundamentais da arquitetura. Exemplo: Linux kernel e Projetos da Apache.

O grau de interoperabilidade é menor para os modelos de referência e maior para as implementações de referência.


Exemplo: Arquitetura CORBA

Object Request Broker (ORB)

Objetos deAplicação

CORBAServices

CORBAFacilities

Arquitetura OMA

IDL (Interface Description Language)

IIOP (Internet Inter-ORB Protocol)

OMA + IDL + IIOP = CORBA


Desenvolvimento de Sistemas Distribuídos

Infra-estrutura necessária:● Hardware: rede de computadores, multiprocessador, processador multitarefa● Software: ORBs, middlewares, contêineres, ...

A infra-estrutura de hardware é responsável por:● Suportar a distribuição do processamento;● Suportar comunicação entre os elementos do sistema.

A infra-estrutura de software é responsavel por:● Prover transparência (esconder a distribuição) aos componentes do sistema;● Atender a um subconjunto de requisitos não-funcionais do sistema.



Um sistema distribuído é especificado em diferentes níveis de abstração e/ou visões (viewpoints).

A parte mais importante da especificação é sua arquitetura.

Uma arquitetura de software define os elementos (objetos, módulos, componentes, etc.) que compõem o sistema, a estruturação destes elementos (camadas, tiers, clusters, etc.), as relações entre os elementos (cliente/servidor, produtor/consumidor, etc.), e as propriedades visíveis externamente destes elementos e relações (pontos de interação).



Atualmente, a tendência é se concentrar mais na arquitetetura e menos nas tecnologias de implementação:

● favorece o reuso de arquiteturas (em oposição ao reuso de código);● alterar a arquitetura em fase adiantada de desenvolvimento é extremamente custoso;● ferramentas de desenvolvimento de software possuem capacidade crescente de geração de código.

Adotam esta estratégia:

● ODP: Visão de tecnologia; ● MDA (Model-driven Architecture): PIM (Platform Independent Model).


Redes de ComputadoresRede de Telefonia

Redes Locais

CATV

Redes de Acesso(Última Milha)(Cable Modem,

ADSL, Fibra)

Troncos(Fibra ótica)SONET/SDH

Redes ATM

Redes TCP/IP

Ethernet Wireless

VoIP IPTV

Fixa Móvel

2G, 3G

WWW

WiFi/WiMax

Sensores

Veicular

Corporal

...

Chão deFábrica

Tecnologias(camadas 1,2)

Aplicações(camadas 5,6,7)

Fibra Ótica(DWDM)

Comunicação(camadas 3,4)


Redes de Computadores

Modelo OSI (ISO): um modelo de referência para redes de computadores.

Protocolos ISO para o modelo OSI: conjunto de protocolos para os elementos (camadas) do modelo OSI.

Arquitetura TCP/IP (IETF): arquitetura de rede não aderente ao modelo OSI.

Outras arquiteturas de rede: NetWare (Novell), IN (Rede Inteligente) (ITU-T), SNA (IBM).


Modelo OSI

Rede

Física

Enlace

Transporte

Sessão

Apresentação

Aplicação

Transmissão de bits no meio físico

Transferência de quadros entre nós próximos

Transferêrncia de pacotes (store-and-forward)

Transferência de segmentos fim-a-fim

Manutenção de estado da comunicação fim-a-fim

Formatação canônica de dados

Infra-estrutura para o desenvolvimento de aplicações


Modelo OSI: Exemplo

Rede

Física

Enlace

Transporte

Sessão

Apresentação

Aplicação

Par trançado (100BaseT)

Ethernet (IEEE 802.3)

Internet Protocol (IP), Address Resolution Protocol (ARP)

Transfer Control Protocol (TCP)

Secure Socket Layer (SSL)

Hypertext Markup Language (HTML)

Hypertext Transfer Protocol (HTTP, HTTPS)

Navegador Web


Modelo OSI: Visão Geral

4-7

1-3 1-3 1-3

1-3

4-7

1-3

1-3

roteamento

comunicaçãoem broadcast

comunicação fim-a-fim

subrede decomunicação

OBS: Esta visão “OSI” não é mais atual. Exemplo:● meio físico dedicado (switching);● roteamento baseado em restrições;● L2-VPNs (Layer 2 Virtual Private Networks).

comunicaçãoponto-a-ponto


Arquitetura TCP/IP

Interface de Rede

Interconexão de Redes

Transporte

Aplicação

Rede

Física

Enlace

Transporte

Sessão

Apresentação

Aplicação

OBS: Na arquitetura TCP/IP a camada de aplicação é responsável pela representação canônica de dados (apresentação) e por manter o estado da comunicação (sessão).


Protocolos TCP/IPA camada interface de rede não prescreve protocolos específicos.

A camada de rede define os seguintes protocolos:● IP (Internet Protocol): define o formato de um pacote de rede (datagrama);● ARP (Address Resolution Protocol): mapeia endereços de rede em endereços de interface de rede (enlace);● ICMP (Internet Control Message Protocol): define mensagens de controle (p.ex., echo request) e erros (e.g., host unreachable).

A camada de transporte define os seguintes protocolos:● TCP (Transfer Control Protocol): transporte de cadeia de bytes com garantia de entrega fim-a-fim;● UDP (User Datagram Protocol): transporte de mensagens sem garantia de entrega fim-a-fim.

A camada de aplicação define vários protocolos tais como HTTP, SMTP (Simple Mail Transfer Protocol) e SSH (Secure Shell).


Protocolos TCP/IP

Além dos protocolos básicos, a Arquitetura TCP/IP especifica umgrande número de protocolos de rede e aplicação, por exemplo:

Camada de rede:● IPSec (IP Secure): confidencialidade e integridade de pacote IP;

● OSPF (Open Shortest Path First): roteamento de pacotes IP;● RSVP (Resource Reservation Protocol): reserva de recursos

para comunicação;● DiffServ (Serviços Diferenciados): priorização de pacotes;● DHCP (Dynamic Host Configuration Protocol): atribuição de

endereços de rede.

Camada de Aplicação:● SNMP (Simple Network Management Protocol): gerência de

rede;● DNS (Domain Name System): mapeamento nome

hierárquico-endereço de rede;● NAT (Network Address Translation): mapeamento

endereçamento privado-público.


Endereçamento TCP/IP

Endereço físico(distingue a conexão ao meio físico)

Física

Endereço de enlace(distingue a interface de rede no enlace)

Endereço de rede(distingue globalmente a interface)

Enlace

Rede

TransporteEndereço de transporte(distingue um ponto de acesso à rede utilizado por aplicação)

AplicaçãoEndereço de aplicação(distingue um serviço ou aplicação)


Mapeamento de Endereços TCP/IP

Física

Enlace

Rede

Transporte

Aplicação

hardwired

00:11:43:CF:06:53

ARP (Address Resolution Protocol)

143.106.50.145

8080

prainha.dca.fee.unicamp.br

DNS (Domain Name System)

http://prainha.dca.fee.unicamp.br:8080/

RJ-45


Endereços IP

Camada de rede: utiliza endereçamento de 32 bits hierarquizados em dois níveis (subrede - host)● Classe A: 7 bits para subrede e 24 para host;● Classe B: 14 bits para subrede e 16 para host;● Classe C: 21 bits para subrede e 8 para host.

Notação decimal: valor decimal de 8 bits separados por pontoExemplo: 143.106.8.30

Notação classless: notação decimal / tamanho do prefixo (agrega 2N endereços consecutivos)Exemplos: 143.106.8/24 (rede com 256 hosts), 143.106.8/26 (rede com 1024 hosts), 143.106.8.30/32 (host específico)


Por que TCP/IP Prevaleceu ?

Não especificar protocolos de rede e enlace permitiu evoluir as tecnologias de rede e preservar as aplicações (a custa do protocolo ARP).

Camada de rede simples com serviço de melhor-esforço (protocolo IP) barateia os roteadores.

Deixa para os computadores dos usuários o ônus da comunicação confiável e o controle de congestionamento (protocolo TCP) -- escalabilidade.

Fácil de configurar (protocolo DHCP).

Compartilhamento de endereços públicos (NAT).

Portabilidade de aplicações (sockets).

Killing application (WWW).


Requisitos de Rede

Requisitos Funcionais:

Transporte de bytes entre componentes do sistema distribuído.

Requisitos Não Funcionais:

● Confiabilidade (taxa de perdas, probabilidade de falha, ...);● Segurança (privacidade, autenticidade, ...);● Qualidade de serviço (atraso, jitter, ...);● Classes de serviço (priorização de tráfego)● Mobilidade (de terminal, de sessão, ...).

Os requisitos funcionais são atendidos pelas camadas 1-7. Os requisitos não funcionais podem necessitar de infra-estrutura adicional (Gerência baseada em políticas, QoS brokers, etc.).


Requisitos de Rede

Que requisitos de rede TCP/IP é capaz de atender ?

a. Segurança: atende razoavelmente bem com mecanismo de chaves criptográficas (ex: HTTPS);b. QoS (atraso, jitter): não atende (Internet atual);c. CoS: atende em redes privadas com equipamentos adequados (ex: priorização de tráfego VoIP);d. Mobilidade: não tende.

Cenário hoje:

a. sobre-provisionamento de recursos para QoS/CoS;b. mobilidade apenas na camada 2 (ex: WiFi) ou via redes sobrepostas (ex: IP em redes de telefonia celular).


Qualidade de Serviço

Visão OSIQoS nas camadas 1,2,3 garantidos por controle de admissão;QoS nas camadas superiores negociados no estabelecimento de conexões.

Visão TCP/IP (original)Campo TOS (Type of Service) no datagrama IP utilizado para definir o tipo de serviço conferido ao datagrama pelos roteadores.

Visão TCP/IP (Arq. de Serviços Integrados - IntServ)Utiliza-se um protocolo para sinalizar reserva de recursos na camada 3 (RSVP).

Visão TCP/IP (Arq. de Serviços Diferenciados - DiffServ)Redefine-se o campo TOS para identicar classes de serviço.


Conexões

Uma conexão é uma negociação entre duas camadas adjacentes (por meio de seus respectivos protocolos) visando dotar a comunicação de certos atributos relavantes para a camada. Por exemplo, para a camada de rede atributos de taxa de transferência e atraso são importantes; para a camada de transporte ausência de perdas é importante.

Conexões garantem a utilização dos recursos de forma planejada (por exemplo, evitando congestionamento nos roteadores).

Entretanto, a complexidade dos protocolos orientados a conexão é muito maior em relação àqueles que operam sem conexão.


Campo TOS

De acordo com o valor do campo TOS, o roteador confere um tratamento adequado ao pacote:● máxima vazão;● máxima confiabilidade;● mínimo atraso;● máxima segurança.● mínimo custo monetário.

Problema: os roteadores primitivos não tinham como honrar o campo TOS.

Resultado: serviço de melhor esforço independente do campo TOS.


Arquitetura IntServ

Solução orientada a fluxo.

R RRfluxo

● Estabelece reserva de recursos para um fluxo individual.● Define um modelo de reoteador capaz de diferenciar fluxos. ● Define um protocolo para reserva de recursos por fluxo.

A B

estado


Roteadores IntServ

Agente deRoteamento(e.g., OSPF)

Base de Dados

(Tabela) deRoteamento

Agente deReserva

(e.g., RSVP)

Agente deGerência

(e.g., SNMP)

Controle deAdmissão

Controlede Tráfego

Classificador

de Pacotes

Escalonador

de Pacotes

Interfacede Saída

Interfacede

Entrada

Roteadorde Pacotes

Filas


Protocolos IntServA Arquitetura IntServ define o protocolo RSVP (Resource Reservation Protocol). RSVP é um protocolo:

- soft state; - extensível (cabeçalho simples + objetos); - complexo (combinação e compartilhamento de reservas); - exige tráfego modelado por meio de token bucket.

A B

R RR

Path (fluxo, Tspec)

Resv

A mensagen Path instala (e “refresca”) o estado e Resv confirma o estado.


IntServ: Legado

A arquitetura IntServ foi uma proposta muito radical:

● estabele conexão no nível de rede !!!● exige roteadores complexos (e portanto caros);● exige sinalização no host (externa à rede);● não é solução escalável (estado e controle por fluxo).

Pelas razões acima, IntServ nunca foi utilizada pelos provedores de rede. Entretanto ...

● o modelo de roteador IntServ prevalece;● o protocolo RSVP é empregado em outas arquiteturas de rede (ex: MPLS);● a idéia é viável se houver agregação de fluxo (como no MPLS).


Arquitetura DiffServ

Solução orientada a diferenciação de serviços:● define-se N classes de serviço;● para cada classe, define-se um comportamento homogêneo para pacotes pertencentes à classe (per hop behavior - PHB).

Classes de serviço são especificadas separadamente. Cada classe é identificada por um código no campo TOS (DiffServ Code Point - DSCP) e pode possuir mais de uma subclasse. Cada subclasse pode possuir mais de uma “prioridade de descarte”. Atualmente existem 3 classes:● EF (Expedited Forward) - similar a uma “linha privada virtual” - não define subclasses;● AF (Assured Forward) - “melhor que melhor esforço” - define 4 subclasses com 3 prioridades de descarte cada;● BE (Best Effort) - serviço padrão - não define subclasses.


Roteadores DiffServ

Medidorde Tráfego

Classifi-cador dePacotes

Escalo-nador

dePacotes

Interface

deSaída

Interfacede

Entrada

Roteador

de Pacotes

Filas

AF1

BE

EF Condicio-

nador de

Pacotes

Marcador

dePacotes

...

Agente deRoteamento(e.g., OSPF)

Base de Dados(Tabela) deRoteamento

Agente deGerência

(e.g., SNMP)

SLAs (Service Level Agreements)


DiffServ Hoje

● Utilizada em redes privadas e entre provedores de rede;

● Marcação pelo host usualmente ignorada pela rede;

● Apesar de escalar melhor que IntServ, o tratamento de SLAs pode ainda comprometer a escalabilidade;

● Cenário provável:

Provedor de Rede

Provedorde ConteúdoRede de

Acesso

SLA

DiffServAlocaçãode Banda

Usuário


Arquiteturas deSistemas Distribuídos


Arquiteturas de SDs

O termo “arquitetura” refere-se a arquitetura de uma aplicação específica (exemplo: e-Banking). O termo “estilo arquitetural” ou “padrão arquitetural” refere-se a um esboço de arquitetura a partir do qual arquiteturas de aplicações podem ser projetadas (exemplo: estilo cliente/servidor).

Arquiteturas que seguem o mesmo estilo arquitetural compartilham propriedades estrututurais semelhantes.

A partir daqui, os termos “arquitetura” e “estilo arquitetural” serão utilizados como sinônimos.


Arquiteturas de SDs

Arquiteturas usualmente estabelecem:

1. Os elementos que compõem a arquitetura;Exemplo: Uma arquitetura de agentes possui os elementos agência e agentes.

2. A estruturação dos elementos da arquitetura;Exemplo: Agentes são elementos contidos em agências (relaçãocontêiner/contido).

3. As relações entre os elementos da arquitetura;Exemplo: Uma agência controla a execução de agentes.

4. Os pontos de interação da arquitetura.

Exemplo: Agências interagem entre sí segundo um protocolo de gerência deagentes. Agentes oferecem interfaces de callback para controle por parte daagência. Agências oferecem interfaces para os agentes obterem informaçõessobre o seu ambiente de execução.


Arquiteturas de SDsExemplo de modelagem de arquiteturas


Padrões Arquiteturais

● Cliente/Servidor;

● n-Tier;

● Dirigidas a Eventos e a Mensagens;

● Peer-to-Peer (P2P);

● Grades Computacionais;

● Orientadas a Serviço.


Arquitetura Cliente/Servidor

O sistema é decomposto em elementos clientes e servidores. Servidores provêem serviços por meio de uma ou mais interfaces. Clientes utilizam serviços invocando operações nestas interfaces.

Clientes dependem de servidores para desempenhar suas funções.

A relação entre clientes e servidores é a de provedor/consumidor de serviços. Esta relação é estabelecida apenas durante a execução de serviços.

Um ponto de interação entre clientes e servidores deve explicitar protocolos para descrição de interfaces de serviços e para invocação de serviços.


Protocolos de Interação Cliente/Servidor

RPC (Remote Procedure Call) - O servidor suporta um conjunto de subrotinas que podem ser invocadas dinamicamente. ● a passagem de parâmetros e retorno é sempre por valor;● necessita de infra-estrutura para invocação remota.

Infra-estrutura mínima:

bibliotecaRPC

bibliotecaRPC

P1 P2 P3

invocação localcallRPC

protocoloRPC

serializa parâmetrosde-serializa retorno

de-serializa parâmetrosserializa retorno

Cliente

Servidor


Compiladores RPC

Stub

bibliotecaRPC

P2 P3P1

bibliotecaRPC

P1 P2 P3

invocação local

Servidor

Skeleton

protocolo RPC

associação (binding)

Cliente

P1, P2, P3Descrição de interfaces

CompiladorRPC


RPC: Registro de ServidoresServidores devem registrar seus procedimentos para que clientes os encontrem. Registros podem ser locais, centralizados ou distribuídos.

C

Nó

R

S

Nó

R

S

Nó

R

S

Nó

C

Nó

S

Nó

R

S

Nó

S

Nó

C

Nó

S

Nó

S

Nó

S

Nó

R

DistribuídoLocal

Centralizado


RPC: Registro de Servidores

RegistroRegistro:● portmapper● serviço de nomes● negociador (trader)

ServidorCliente

Stub Skeleton

1. registra2. busca

3. invoca


RPC: Registro de Servidores

Portmapper: mapeia procedimentos (programa, versão, procedimento) em um port de servidor local. Exemplo (0x12345678, 1, 2) -> 111

Serviço de nomes: mapeia nomes hierárquico em endereços de servidores. Exemplo: /Servidores/TimeServers/T1/getTime -> (143.106.50.145, 111)

Negociador (Trader): mapeia nomes hierárquicos e atributos em endereços de servidores locais. Exemplo:/Servidores/TimeServers/T1/getTime {Precision = 99.990} ->(143.106.50.145, 111)

Ao buscar um servidor, o cliente define um critério de busca. Exemplo:/Servidores/TimeServers/*/getTime {Precision > 99.0}


RPC: Protocolos

SUN RPC: Utilizada em serviços como NFS e NIS. Possui linguagem de descrição de procedimentos (RPC Language) e compilador (rpcgen). Opera com registro local (portmapper). Stubs possuem assinaturas diferentes dos procedimentos.

/* RPC Language */program DATE_PROG { version DATE_VERS {

long BIN_DATE(void) = 1; /* numero do procedimento */string STR_DATE(long) = 2;

} = 1; /* versao */} = 0x12345678; /* numero do programa */

......

/* codigo do cliente */CLIENT cl = clnt_create(server, DATE_PROG, DATE_VERS, “udp”); /* stub */long ldate = bin_date_1(NULL, cl);


RPC: Protocolos

DCE RPC: Utilizada inicialmente no DCE (Distributed Computing Environment), serviu de base para o Microsoft DCOM/COM+. Possui invocação segura e compilador. Stubs possuem assinaturas diferentes dos procedimentos. Hoje disponível em código aberto.

/* DCE IDL */[uuid(70ff8220-6e1a-11cc-89ee-080002b2a1bca)]interface date {

long bin_date();[string, prt] str_date ([in] long date);

}

........

/* codigo do cliente */rpc_binding_handle_t binding_h; /* stub */unsigned32 dce_status;import_interface(“date”, date_v1.0_c_ifspec, &binding_h, &dce_status);long ldate = time(NULL);char* date = str_date(binding_h, ldate, &dca_status);


Objetos Distribuídos

Comumente arquiteturas cliente/servidor são realizadas com objetos distribuídos. Um objeto distribuído:● possui uma referência que extrapola o seu espaço de endereçamento;● possui uma ou mais interfaces descritas segundo uma linguagem de descrição de interfaces;● é ancorado por uma infra-estrutura que suporta invocação remota dos métodos definidos em sua(s) interface(s).

A infra-estrutura de suporte a objetos distribuídos provê minimamente:● stubs e skeletons gerados para uma dada interface;● mecanismo de ligação stub-skeleton (binding). Adicionalmente a infra-estrutura pode prover:● mecanismo de controle de execução e persistência de objetos distribuídos;● serviços adicionais (segurança, transação, etc.).


Objetos Distribuídos: CORBA

Stub

bibliotecaORB

P2 P3P1

bibliotecaORB

O1 O2 O3

invocaçãolocal

Servidor

Skeleton

protocolo IIOP

associação (binding)

Cliente

I1, I2, I3Descrição de interfaces: CORBA IDL

CompiladorIDL

POA

controle

Objetos serventes


Objetos Distribuídos: CORBA

// CORBA IDLinterface date {

long bin_date();string str_date(in long ldate);

}

......

// clienteorg.omg.CORBA.Object obj = nserver.resolve_str(“TimeServer”);

date dt = dateHelper.narrow(obj); /* stub */long ldate = dt.bin_date();String str = str_date(ldate);


Arquitetura n-Tier

Variante da arquitetura Cliente/Servidor onde os elementos da aplicação distribuída são estruturados em camadas verticais (tiers). Comumente são empregadas 3 camadas (Arquitetura 3-Tier):

- Apresentação: contém os elementos responsáveis pela interação com o usuário.

- Lógica da Aplicação (de negócio): contém os elementos responsáveis pela lógica da aplicação (processamento da informação).

- Dados (Back-End) - contém os elementos responsáveis pela persistência e consistência dos dados.

Elementos de uma camada interagem apenas com elementos de camadas adjacentes.

Pontos de interação entre camadas devem explicitar protocolos para descrição de interfaces de serviços e para invocação de serviços disponíveis em cada camada.


Exemplo de Arquitetura 3-Tier

Apresentação

EJBContainer

(EnterpriseJava Beans)

WebContainer

(JSP/Servlet)

Base deDados

Relacional

Lógica daAplicação

Dados(Back-End)

HTTPRMI

JDBCJava BeansHibernate


Arquitetura Dirigida a Eventos e Mensagens

O sistema é decomposto em elementos produtores e consumidores de eventos (mensagens).

Produtores e consumidores são desacoplados por meio de um canal de difusão de eventos (mensagens).

Produtores e consumidores de eventos (mensagens) dependem do canal de difusão para desempenhar suas funções.

Um ponto de interação entre produtores, consumidores e canal de difusão deve explicitar protocolos e interfaces para subscrição, “de-subscrição”, publicação e consumo de eventos (mensagens).



ProxyConsumidor

ProxyProdutor

Admin

Persistência

Produtor

Produtor

push

subscribeunsubscribe

pull

Consumidor(push)

Consumidor(pull)

push

Canal deDifusão



Exemplo de infra-estruturas de eventos/mensagens:

● Serviço de Notificação e de Mensagens CORBA;

● Java Message Systems (JMS);

● ActiveMQ (Apache);

● WebSphere MQ (IBM).


Arquitetura Peer-to-Peer (P2P)

O sistema é composto de elementos que desempenham funções semelhantes (elementos pares).

Não há uma estruturação definida para os elementos pares, apesar de prevalecer uma estruturação em grafos não orientados.

Não há relação de dependência ou hierarquia entre os elementos pares.

Um ponto de interação entre pares deve ser definido para que estes possam cooperar (tipicamente por meio de troca de mensagens).

Arquiteturas P2P são comumente empregadas em redes de compartilhamento de informação (Gnutella, Napster, etc.) e de processamento cooperativo (SETI@Home, Entropia, etc).


Arquitetura P2P

Rede de suporte (underlay, e.g., Internet)

Rede suportada (overlay, e.g., Gnutella)

peer

Topologia, protocolos de interação e funcionalidade dos nós diferem entre as duas redes.


Exemplo de Arq. P2P: Gnutella

Gnutella é uma arquitetura de propósito geral para compartilhamento de informação (tipicamente arquivos). Gnutella define um protocolo de interação entre os nós que suporta:

● descoberta de pares (mensagens PING e PONG);● busca de informação (mensagens QUERY e QUERY RESPONSE);● transferência de informação (mensagens GET e PUSH).

Em arquiteturas P2P estilo Gnutella um fator fundamental é o roteamento de queries.



Mensagem PING Mensagem PONG



Query (inundação) Query Response

Get/Push


Arquiteturas Grid

Internet

Job

Job

Submissão remota de jobs

Mainframe

Computação em Grid

Do ponto de vista do usuário, o Grid é um processador virtual composto de dezenas/centenas de processadores interconectados.

Analogia: Power Grid (sistema elétrico de potência).


Arquiteturas Grid

Os elementos da arquitetura são recursos computacionais (CPU, armazenamento, hardware especializado, software, etc.).

Os recursos são estruturados em recursos virtuais e organizações virtuais (VOs) -- virtualização.

VOs são regidas por meio de SLAs (Service Level Agreements).

Pontos de interação são definidos entre VOs para fins de submissão de jobs, inquirição e notificação de status e coleta de resultados.


Grid: Recursos Virtuais

Recursos

Serviços

Acesso

Armaze-

namentoSensores Aplicações InformaçãoComputadores

Interfaces dos Recursos

Interfaces Comuns

Classes de Interfaces

(c) Open Grid Forum


Grid: Organizações Virtuais

Organização real

Organização Virtual

SLA

SLA

Recurso


Grid X Conceitos Similares

Processamento Distribuído:● Fraco acoplamento;● Heterogêneo;● Intra-organizacional.

Processamento Paralelo (Cluster):● Forte acoplamento;● Homogêneo;● Intra-organizacional.

Grid:● Fraco acoplamento;● Heterogêneo;● Inter-organizacional, Larga escala.


Grid: Exemplo

Recursos

Virtualizados

Serviços

de Grid

(middleware) Brokering Service

Registry Service

DataService

CPU Resource Equipment

Service

Job-Submit Service

ComputeService

Notify

Ad

vertise

ApplicationService

(c) Open Grid Forum

1

2

3

4

5


Grid: Serviços

● Compartilhamento de dados (Data Grids) - Exemplo: dados astronômicos.

● Processamento (Computational Grids) - Exemplo: simulação.

● Equipamentos especializados (Equipment Grids) - Exemplo: telescópio.

Aplicações desenvolvidas segundo uma arquitetura Grid devem utilizar uma infra-estrutura comum para disponibilização, gerência e uso dos serviços. Esta infra-estrutura pode consistir de um middleware, toolkit, ou ambiente de programação.


Grid: Globus Toolkit

Conjunto de funções de suporte a arquiteturas Grid:

● Gerência de execução (alocação e gerência de recursos, manutenção de workspace);

● Comunicação (mensagem, RPC, estado compartilhado, I/O remoto providos pela Nexus Communication Library);

● Gerência de Informação (publicação, descoberta e acesso a informação sobre serviços disponíveis no Grid);

● Segurança (autenticação, autorização, delegação, gerência de credenciais).

http://www.globus.org


Grid: Globus Toolkit

(c) Globus Aliance


Grid: Open Grid Service Architecture (OGSA)

● Arquitetura aberta orientada a serviço para computação em Grid em padronização pelo Open Grid Forum.

● Classes de serviços similar ao Globus.

● Utiliza padrões XML existentes (WS-Security, WS-Policy, etc.) e padrões específicos para computação em Grid (Configuration Description Language (CDL), Job Submission Description Language (JSDL)).

http://www.ogf.org


Grid: OGSA

Security• Cross-organizational users• Trust nobody• Authorized access only

Information Services

• Registry• Notification• Logging/auditing

Execution Management• Job description &

submission• Scheduling• Resource provisioning

Data Services• Common access facilities• Efficient & reliable transport• Replication services

Self-Management

• Self-configuration• Self-optimization• Self-healingOGSA

OGSA “profiles”

Web services foundation

(c) Global Grid Forum


Arquitetura Orientada a Serviço

Tal como em Grids, arquitetura orientada a serviço (SOA - Service- oriented Architecture) é uma solução de processamento distribuído inter-organizacional. O foco principal está na interoperabilidade e segurança (mesmo comprometendo a eficiência).

Um serviço encapsula uma lógica (de negócio) auto-contida, com interface bem definida e auto-descritiva, cuja execução não depende do contexto ou estado de execução de outros serviços.

Devido aos requisitos de interoperabilidade, implementações de SOA têm se limitado à tecnologia de serviços Web.


Arquitetura Orientada a Serviço

Os elementos da arquitetura são serviços.

Serviços são estruturados em serviços primitivos e compostos (composição de serviços).

Serviços compostos dependem dos serviços primitivos que os suportam.

Pontos de interação são definidos para registro, descoberta e invocação de serviços.


SOA: objetos X componentes X serviços

Objeto Componente Serviço

Granularidade baixa média alta

Acoplamento médio baixo baixo

Aspectos não- providos pelo providos pelo providos pelafuncionais programador container plataforma

Interoperoperabilidade protocolo protocolo protocoloespecífico específico XML

Composiçao embutida descritor de script deno código montagem composição

(ñ recursiva) (recursiva)


SOA: Características Próprias

Provedores e clientes de serviços podem trocar metadados sobre a utilização de serviços, por exemplo, políticas de uso do serviço.

Serviços são “sem estado” (stateless). Entretanto, o efeito da execução do serviço pode refletir em invocações subseqüentes (via alteração em base de dados, por exemplo).

Um serviços usualmente reflete um workflow balizado por regras de negócio.

Um serviço composto é também um serviço.


SOA: Composição de Serviços

Composição é um fluxo de execução de serviços descrito por uma linguagem de composição (script descrevendo um workflow) e processado por uma máquina de composição. Tipicamente, linguagens de composição suportam:● execução sequencial e paralela de serviços;● variáveis (armazenam resultados intermediários);● pontos de decisão;● laços de iteração;● ações de compensação (tratamento de exceções).

Máquina deComposiçãoScript

ServiçoPrimitivo

ServiçoPrimitivo

...

conexão (partner link)Serviço

Composto


SOA: Orquestração X Coreografia

Coreografia descreve contratos inter-organizacionais para a execução de serviços. É um processo não necessariamente automatizado similar a um SLA.

Orquestração é um processo intra-organização, usualmente automatizado por meio de composição de serviços.

Coreografia

Orquestração


Desenvolvimento Orientado a Serviço

Usualmente empregam-se um processo multi-camadas:

Camada de negócio: representada por workflows, regras de negócio, políticas, etc.

Camada de serviço: representa as interfaces e conexões entre os serviços responsáveis pela lógica de negócio. Possui 3 subcamadas:● Serviços de orquestração (serviços criados via composição de serviços);● Serviços de negócio (serviços específicos do negócio);● Serviços de aplicação (serviços de propósito geral).

Camada de aplicação: plataformas de suporte a serviços e máquinas de orquestração.


Desenv. Orientado a Serviço

Camada deAplicação

Camada deServiço

Camada deNegócio

M.C. M.C. M.C

Plataforma


SOA: Camada de Negócio

A camada de negócio utiliza editores dedicados para modelar processos de negócio. Estes editores geram scrips de composição.


SOA: Camada de Serviço

Serviços são descritos por meio de suas interfaces. O ciclo de desenvol-vimento de um serviço segue o modelo clássico: definição de interface, compilação de interface, implementação da lógica de serviço.

Alternativamente, um serviço pode ser desenvolvido por meio de composição de serviços utilizando uma plataforma apropriada capaz de integrar as interfaces dos serviços primitivos, o script de composição, e código executável.

Uma vez desenvolvido, a interface do serviço pode ser registrada em um diretório de serviços.


SOA: Camada de Aplicação

A camada de aplicação utiliza utiliza plataformas e máquinas de composição. Plataformas oferecem facilidades de desenvolvimento de serviços via aplicativos, editores, debuggers, etc., bem como servidores onde os serviços serão instalados e diretórios onde os serviços serão registrados.

Máquinas de composição podem ou não ser integradas às plataformas.

Exemplos (produtos gratuitos):

● Apache Axis: executa como aplicação no Tomcat (não possui editor ou máquina de orquestração, apenas aplicativos). Bom para o desenvolvimento de serviços primitivos.

● Eclipse BPEL Project, Oracle BPEL Process Manager, ActivBPEL: Máquinas de orquestração. Bom para o desenvolvimento de serviços compostos.


SOA: Tecnologias Web

WS-BPELWS-CDL

WSDL, UDDI

SOAP, XML

HTTP, HTTPS

Codificaçãoe

Transporte

Descrição

Processode Negócio

Web Service Business Process Description LanguageWeb Service Choreography Description Language

Web Services Description LanguageUniversal Description, Discovery and Invocation

Simple Object Access ProtocolExtensible Markup Language

Hypertext Transfer Protocol (Secure)

WS-PolicyWS-SecurityWS-Metadata


SOA: Tecnologias & Produtos

WS-BPELWS-CDL

WSDL, UDDI

SOAP, XML

HTTP, HTTPS

WS-PolicyWS-SecurityWS-Metadata

Contêiners(Ex: Tomcat + Axis)

Aplicativos & APIs(Ex: java2wsdl, jUDDI)

Máquinas de composição(Ex: ActivBPEL)


Padrões Arquiteturais: Resumo

Padrão Elementos Estruturação Dependências Ponto de Interação

Cliente/Servidor clientes e arbitrária clientes de prot. RPC entreservidores servidores clientes e servidores

Dirigida a Evento/ produtores e em torno de prods. e cons. prot. de interaçãoMensagem consumidores canais de difusão do canal c/ o canal

n-Tier clientes e camadas tier de tiers prot. de interaçãoservidores verticais (tiers) adjacentes entre tiers

Peer-to-peer pares redes nó dos nós prot. de cooperaçãoconectados entre pares

Grades recursos organizações orgs. de SLAs prot. de uso dosComputacionais virtuais virtuais estabelecidos recursos virtuais

Orientada a serviço composição serviço composto prot. de invocação eServiço de serviços dos primitivos composição de serviços

Multi-Agentes agentes e agentes contidos agentes de prot. de interaçãoagências em agências agências agente-agência e

agente-agente


Unified Modeling LanguageOOAD (Object Oriented Analysis and Design) começou a proliferar no início da década de 90.

James Rumbaugh e outros (General Electric Co) publicam o livro Object-Oriented Modeling and Design, Prentice-Hall, 1991, descrevendo OMT (Obect Modeling Technique).

Ivar Jacobson (Objective Systems) e outros publicam o livro Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992.

Grady Booch (Rational Software Co) publica o livro Object Oriented Analysis and Design with Applications, Pearson, 1993.

Rumbaugh se transferiu para a Rational em 1994. Lá estavam Booch e Jacobsen. UML 0.8 surgiu em 1995 como fusão das três técnicas de modelagem.

OMG (Object Management Group) criou em 1996 uma força tarefa para padronizar OOAD.

Rational submete ao OMG a versão 1.0 da UML. OMG contribui para UML 1.1.

UML 1.2 surge em 1998, 1.3 em 1999; 1.4 em 2001, 1.5 em 2003, 2.0 em 2004, 2.1.1 em 2007.


Modelagem de Arquiteturas com UML

Elementos: diagramas de classes, componentes, pacotes.

Estruturação: diagramas de componentes e de instalação (deployment).

Dependências: relações entre elementos.

Pontos de interação: diagramas de caso de uso, atividade, comunicação, seqüência, transição de estado.

OBS: UML é deficiente para representar certos aspectos de sistemas distribuídos, por exemplo: - requisitos não-funcionais são difíceis de modelar (ex: QoS); - propriedades relativas a distribuição difíceis de estabelecer (ex: ausência de deadlocks, limites de performance); - ausência de mecanismos para modelar restrições organizacionais (ex: políticas), tecnológicas (ex: características do hardware), e de interação com o usuário humano (ex: acessibilidade).


Object Constraint Language

OCL, Object Constraint Language (UML 2.x), é uma linguagem textual para precisar ou restringir certos elementos do modelo, por exemplo:● invariantes, pré e pós condições;● limites em tipos e valores de atributos, cardinalidade, etc;● elemento relacionados;● inter-dependência de atributos;● resultados de operações.

Exemplo:

Pessoa

NomeSexoIdadeEstCivil

conjuge

*

0..1

união


OCLPessoa

NomeSexoIdadeEstCivil

conjuge

*

0..1

Context Pessoa inv:

-- bigamia é proibidoself.conjuge->size() <= 1

-- união somente entre sexo opostoself.conjuge->size() = 1 implies self.Sexo <> self.conjuge.Sexo

-- união significa casamentoself.conjuge->size() = 1 implies self.EstCivil = #casado and self.conjuge.EstCivil = #casado

-- um dos conjuges é sempre maior de idadeif self.EstCivil = #casado then self.Idade >= 18 or self.conjuge.Idade >= 18

união


XML Metadata InterchangeXML Metadata Interchange (XMI) permite representar um diagrama UML de forma neutra e intercambiável entre ferramentas de projeto.Permite ainda processar o modelo UML. Por exemplo:

DocumentoXMI

Modelo UML

ferramentade projeto

Geradorde

Código

Validadorde

Modelo

Transformadorde

Modelo

Ex: Classe UML -> Interface WSDL

Ex: Aderênciaa Perfil UML

Ex: Diagrama de Arividades UML ->Documento BPEL

Save As ...

Import As ...



UML 2.x

Adiçoes à UML 1.5 presentes na UML 2.0 foram motivadas por MDA e SOA.

● Diagrama de atividades: construções para modelagem de workflows. Adição de fluxos, sinais, pré/pós-condições, exceções e agrupamentos de ações.

● Diagrama de classes: mudanças insignificantes (ex: navegação que pode ou não ocorrer). Entretanto, o uso de OCL é cada vez mais presente.

● Diagramas de comunicação (antigo diagrama de colaboração): adição de envio concorrente de mensagens (letra após número de seqüência).

● Diagramas de caso de uso: adição de condições para extensão de casos de uso.

● Diagramas de componentes: adição de ports, interfaces requeridas e conectores de componentes.


Metamodelos

Um metamodelo é uma referência para a contrução de modelos. O OMG define 4 níveis de modelos.

MOF

CWM MM UML MM EDOC Mm

M0 (sistema real)

M2 (metamodelos)

M3 (meta-metamodelo)

M1 (modelos) Modelo UML Perfil UML

Simulador JogoWeb Lab


Perfis UML

Um perfil UML é uma extensão de UML para um domínio de aplicação específico. UML pode ser estendida de duas maneiras:

● Criando novas construções a partir do meta-modelo UML (exemplo: uma nova associação).

● Utilizando os mecanismos nativos de extensão: estereótipos e valores etiquetados (tagged values).

Perfis UML são úteis para geração de código e transformação de modelos (as ferramentas sabem o que procurar no documento XMI).


Exemplo de Perfil UML

CanalDeDifusão

subscribeunsubscribe

push

Consumidor

push

Produtor

logEnabled : Bool

<<CanalDeDifusão>>ChatServer

<<Consumidor>>Apresentador

<<Produtor>>

Editor

* ** *

CanalDeDifusão Classe Reresenta um canal de difuãoProduror Classe Reresenta um produtor de mensagensConsumidor Classe Reresenta um consumidor de mensagens

Estereótipos Elemento Descrição

Valores Etiq. Valores Elemento Descrição

plataforma java, corba Classe Plataforma alvo para geraçãode código

{plataforma=java}

{plataforma=java}{plataforma=java}


UML e Processos de Desenvolvimento de Software

Um processo de desenvolvimento de sofware estabelece quem faz o quê, quando e como.

Involve, portanto, pessoas e organizações (quem); seqüências de ações (o quê, quando); e linguages, ferramentas e tecnologias (como).

UML não é um processo de desenvolvimento de software, mas sim uma linguagem de modelagem de software com ferramentas de suporte.

UML é útil em ações do processo que envolvem a especificação do produto (software), tipicamente, as fases de análise e projeto. Outras fases, como implementação e teste, necessitam linguagens e ferramentas específicas que não UML.


Model Driven Architecture (MDA)

Motivações:

● Sub-utilização de modelos (modelos tem sido entidades de documentação, não de desenvolvimento);

● Proliferação de middlewares e plataformas;

● Reuso de projeto X reuso de código.

OBS:

MDA não é um padrão para o desenvolvimento de aplicações distribuídas como OMA e CORBA, mas uma estratégia de utilização de modelos no desenvolvimento destas aplicações(ou seja, modelos são as entidades centrais em MDA).


MDA: Idéias Básicas

● Especificar um sistema independente de plataforma;

● Especificar plataformas alvo;

● Selecionar uma plataforma para suportar o sistema;

● Transformar a especificação do sistema independente de plataforma em outra compatível com a plataforma selecionada (transformação de modelos).

OBS: a transformação de modelos pode ser plenamente automática (ideal), assistida, ou manual.


MDA: Pontos de Vista

MDA define três pontos de vista:

1. Ponto de vista independente da computação: similar aos pontos de vista de empresa e informação do ODP. Modelos neste ponto de vista são denominados CIM (Computation Independent Model).

2. Ponto de vista independente de plataforma: similar aos pontos de vista de informação e computação do ODP. Modelos neste ponto de vista são denominados PIM (Plataform Independent Model).

3. Ponto de vista dependente de plataforma: similar aos pontos de vista de engenharia e tecnologia do ODP. Modelos neste ponto de vista são denominados PSM (Plataform Specific Model).


MDA: Transformação de Modelos

PSM

PIM

PIM“Marcado”

Marcas

Mapeamento Plataforma

Transformação


MDA: Marcação de Modelos

A marcação de modelos é utilizada para guiar o mapeamento de PIM para PSM. Estas marcas consistem de:

● estereótipos definidos por um perfil UML;

● valores etiquetados (tagged values);

● expressão OCL;

● comentário (anchor text).


MDA: Exemplo de Transformação

PSM(Java/RMI)

PIM(UML)

PIM“Marcado”

(UML)

Marcas

Mapeamento Plataforma

Ex: <<RMI Interface>>

Ex: XMI Class ->RMI Remote Interface

Ex: RMI


MDA: Especificação de Transformação

PSM

PIM MetamodeloPIM

MetamodeloPSM

Especificaçãoda

Transformação

linguagem origem

linguagem alvo


MDA: Métodos de Transformação de Modelos

1. Transformação manual de modelos PIM. Exemplo: UML -> Java -> Java2WSDL

2. Transformação de um modelo PIM que segue um perfil UML. Exemplo: EJB UML Profile -> EJB

3. Transformação de um modelo PIM marcado. Exemplo: <<RMI Interface>>

4. Transformação de modelos PIM “computacionalmente completos” Exemplo: modelo PIM expresso em SDL


MDA: Transformação Automática de Modelos

A transformação automática usualmente requer modelos PIM compatíveis com um perfil UML ou marcados segundo uma especificação de transformação.

DocumentoXMI

PIM


Transformadorde

Modelo

Save As ...

public interface AccessSession extends Remote {

public String start(...) throws RemoteException { ...}...}

PSM


MDA: Exemplo - CMtel

CMtel é um modelo de componentes independente de tecnologia. O desenvolvimento de aplicações CMtel segue as linhas de MDA.

CMtel define um perfil UML para a descrição de componentes e contêineres. Um modelo PIM é obtido especifindo-se componentes e contêineres segundo este perfil.

Máquinas de transformação de código (CMBuilders) processam este modelo PIM e geram modelos PSM para certas tecnologias (CORBA e Web Services).


Componentes CMtel

ComponenteCMtel

Faceta

Receptáculo

Transmissorde Fluxo

Apresentadorde Fluxo

Emissorde Evento

Consumidorde Evento

PortasOperacionais

Portas de Fluxo

Portasde Sinal

Elemento deConfiguração


CMtel: Perfil UML


CMtel: Exemplo de Aplicação


CMtel: CMBuilders

Utilizam XSLT (XML Stylesheet Language Transformation) para transformar um PIM segundo o perfil CMtel (expresso em XMI) em um PSM. A transformação ocorre em dois passos:

XSLT(xalan)XMI XMLXML

XMLXML XSLT

(xalan)CódigoCódigoCódigo

CódigoCódigo

XSLCódigoCódigo

XSLEspecificação daTransformação

PIM PSM

XMLSchema

XML Schemas sãogerados a partir doperfil UML


CMtel: CMBuilders

CMBuilders geram:

● Interfaces das portas dos componentes;● Fábricas de componentes;● Localizadores de fábricas (home finders);● Implementação parcial das facetas;● Implementação integral das demais portas;● Contêineres para componentes;● Arquivos de instalação (sh, bat, build.xml).

CMBuilders podem gerar ainda montadores da aplicação (assemblers) a partir de diagramas UML de comunicação (colaboração).


CCMBuilder (CORBA CMBuilder)

Plataforma alvo:

ORB Corba (Java)

Serviço dePropriedades

(CosProperties)

Serviço deStreaming

(A/V Streams)

Serviço deEventos

(CosEvent)

Suporta portasoperacionais

Suporta elementosde condiguração

Suporta portasde sinal

Suporta portasde fluxo

Serviço deNomes

(CosNaming)

Suporta localizaçãode componentes

No PSM, portas de componentessão especificadas em CORBA IDL


WSCMtel (Web Services CMtel)

Plataforma alvo:

Apache AXIS

jUDDIServiço de

Difusão(Push/Pull)

Suporta portasoperacionais eelementos deconfiguração

Suporta portas desinal e de fluxo

Suporta localizaçãode componentes

No PSM, portas de componentessão especificadas em WSDL


MDA: Exemplo - ACORD

Metamodelo para aplicações sensíveis a contexto (ASC):

● Define um perfil UML para ASC;

● Define marcas adicionais com valores etiquetados;

● Transformação PIM-PSM baseada em XSLT (Linux XML tools);

● Plataforma de suporte ao PSM: Java + JESS.


Serviços Web

Definição do W3C: A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols.

Definição Alternativa: Serviços Web são entidades de composição acessíveis via protocolos centrados em XML cujas mensagens são transportadas por protocolos nativos da Web tais como HTTP, SMTP e TCP.

A maioria dos protocolos relativos a Serviços Web estão ainda em desenvolvimento e possuem pouco suporte para sua utilização (APIs, ferramentas, experiência de uso, etc.).

Os protocolos centrais estão caminhando para a estabilidade e possuem suporte para desenvolvimento e utilização.

Serviços Web são base para o desenvolvimento de arquiteturas orientadas a serviço (SOA).


Serviços Web: Padronização

Serviços Web são padronizados por duas organizações:

● World Wide Web Consortium (W3C) - http://www.w3c.org

● Organization for the Advancement of Structured Information Standards (OASIS) - http://www.oasis-open.org

Os padrões relativos a Web Service são amplamente suportados pela indústria (Microsoft, Sun, IBM, Oracle, ...).

A Apache Software Foundation (http://www.apache.org) desenvolve em comunidade os protocolos mais importantes.

http://www.w3c.org/

http://www.oasis-open.org/


Serviços Web: Protocolos

http://roadmap.cbdiforum.com/reports/protocols/


Serviços Web: Uso Básico

http://roadmap.cbdiforum.com/reports/protocols/


CORBA X Serviços Web

XML

IDL WSDL

SOAP/HTTPIIOP/TCP

UDDICosNaming

WS-*CORBA Services

BPEL, WSIL

Objetos Serviços

RPC, MsgsRPC

IOR URI

CDR

Forte Fraco

Entidades de Distribuição

Acoplamento

Referência Remota

Interação

Descrição de Interfaces

Transporte

Localização

Formatação

Composição/Coreografia

Serviços

CORBA Serviços Web Característica

POA Proc. da Invocação

CORBA DomainServices

BusinessDomain

Specific Exts.

Aplicações p/ DomíniosEspecíficos


Serviços Web: Uso Avançado

Processode negócio

Ferramentade Edição

ScriptBPEL

Serviços (intra-organização)

Serviços (inter-organização)

composiçãocoreografia

ServiçoComposto

Máquina deComposição


Serviços Web: Desenvolvimento

O desenvolvimento de Serviços Web requer plataformas que ofereçam suporte para a criação, instalação e invocação destes serviços.

Exemplos de Plataformas

● Apache SOAP (desenvolvimento “próximo ao fio”)● Apache Axis/Axis2● Sun ONE● Microsoft .NET● Oracle JDeveloper

Exceto a plataforma .NET que privilegia C#, todas as demais plataformas são baseadas em Java.


Serviços Web: Plataforma AxisApache Tomcat

Plataforma Axis(servlet)

Permite estender a plataforma(via pré e pós-processamento demensagens SOAP)

HTTP POST

Dispatcher

WEB-INF/lib

serviços:WS-Policy

WS-Security

Aplicativos:java2wsdl wsdl2javaSoapMonitorAdminClient

Serviços Web

WEB-INF/services



InterfaceWSDL

CompiladorWSDL

(wsdl2java)

GeradorWSDL

(java2wsdl)

InterfaceJava

Stubs doCliente

Skeletondo Servidor

Impl.Vazia

Arquivos deInstalação e

Desinstalação

Estilo “Objetos Distribuídos”

Impl.Completa

Instalador/Desinstalador(ClientAdmin)

Serviço(.jar)

jar

axis2/WEB-INF/lib

URI do serviço



Java Object

<service name="AccessService" scope="application"> <description> GigaBOT Access Service </description> <messageReceivers> <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out" class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/> </messageReceivers> <parameter name="ServiceClass">accessservice.AccessService</parameter></service>

Ant

build.xml

ServiçoInstalável

(.aar)

Descritor do Serviçoaxis2/WEB-INF/services(hot deployment)

Estilo POJO (PlainOld Java Object)


Web Services: Clientes

Invocação Estática: Utiliza stubs como em objetos distribuídos. Stubs possuem a URI do serviço hardcoded.

Invocação Dinâmica: utiliza classes auxilares para construir uma invocação passo-a-passo (similar ao DII do CORBA). Dependendo do estilo de invocação, o cliente pode suprir diretamente a URI do serviço ou seu nome no UDDI (mais a URI do UDDI).

A invocação estática é type-safe, enquanto a dinâmica não é. Entretanto, na invocação dinâmica o cliente pode escolher o serviço em tempo de execução.


Web Services: Exemplo (cliente)package client;import javax.xml.namespace.QName;import org.apache.axis2.AxisFault;import org.apache.axis2.addressing.EndpointReference;import org.apache.axis2.client.Options;import org.apache.axis2.rpc.client.RPCServiceClient;

public class AccessRPCClient {

public static void main(String[] args1) throws AxisFault { try { RPCServiceClient serviceClient = new RPCServiceClient(); Options options = serviceClient.getOptions(); EndpointReference targetEPR = new EndpointReference("http://143.106.50.145:8080/axis2/services/AccessService"); options.setTo(targetEPR); // create session QName opCreateSession = new QName("http://accessservice/xsd", "createSession"); Object[] opArgs = new Object[] {"[email protected]", "cardozo", 1, 3}; Class[] returnTypes = new Class[] { String.class }; Object[] response = serviceClient.invokeBlocking(opCreateSession, opArgs, returnTypes); String sessid = (String) response[0]; // Displaying the result System.out.println("createSession : " + sessid);} catch (Exception exc) {

System.out.println("Exception: " + exc.toString());}

}}


Alternativas a Web Services

Apesar das vantagens claras de Web Services sobre tecnologias de objetos distribuídos como CORBA e RMI, muitos tem criticado esta tecnologia, por exemplo:

● SOAP muito complexo para transportar documentos XML;

● WS-* muito extensos e pouco utilizados;

● Navegadores não suportam diretamente Web Services;

● Data binding estrito dificulta evolução das aplicações.


Alternativas a Web Services

Quais são as alternativas ?

● REST (Representational State Transfer);

● JavaScript + JSON (JavaScript Object Notation);

● AJax (Asynchronous JavaScript and XML).

O que estas alternativas propõem ?

● Simplicar a interação (HTTP + XML);

● Navegador como contêiner da aplicação no lado cliente (JavaScript);

● Data binding menos estrito (DOM/SAX versus XPath/XSLT).


REST

REST é um estilo arquitetural cuja realização depende apenas de HTTP e XML. Idéia:

HTTP(API)

HTTP(API)

POST/DELETEGET

HTTP

XMLParserXML

recurso

Aplicação

estado

Cliente Servidor


REST

Em REST a aplicação é modelada como um conjunto de recursos operados por requisiçoes HTTP (POST/GET/DELETE).

Requisições/resposta carregam documentos XML.

O estado da aplicação é acessado e alterado por meio de requisições HTTP.

Nenhum serviço adicional é especificado (exemplo: transações).

Não existe suporte para orquestração (como BPEL).

Extremo oposto a Web Services em termos de simplicidade.

Ideal para aplicações tipo “browse catalog”.


JavaScript/JSONJavaScript foi inicialmente concebida para computações simples como checagem de consistência em formulários HTML.

JSON é uma representação de dados na forma atributo-valores.

Funções convertem representação textual em “objetos” e vice-versa (similar a JAXB).

Utilizado no GoogleMaps.

JavaScript

JSON Objects

eval() toJSONString()

lógica

JSON Text(pode ser XML)

JSON Text

parseJSON() JSON Objects


JSON: Representação Textual de Objetos

var records = { "data" : [ { "First Name" : "Bob", "Last Name" : "Smith", "Email" : "[email protected]", "Phone" : "(555) 555-1212", }, { "First Name" : "Jan", "Last Name" : "Smith", "Email" : "[email protected]", "Phone" : "(555) 555-3434", }, { "First Name" : "Sue", "Last Name" : "Smith", "Email" : "[email protected]", "Phone" : "(555) 555-5656", } ]};

<data> <item> <FirstName>Bob</FirstName> <LastName>Smith</LastName> <Email>[email protected]</Email> <Phone>(555) 555-1212</Phone> </item> <item> <FirstName>Jan</FirstName> <LastName>Smith</LastName> <Email>[email protected]</Email> <Phone>(555) 555-3434</Phone> </item> <item> <FirstName>Sue</FirstName> <LastName>Smith</LastName> <Email>[email protected]</Email> <Phone>(555) 555-5656</Phone> </item></data>


JavaScript/JSON


Objetos JavaScript

var obj = { a : Object, b : Array, c : false, d : null, init : function() { // set local object vars here this.run(); }, run : function() { // run bulk of behavior here }}function initializer() { obj.init(); // other init() methods go here}addEvent(window,'load',inializer);


JSON: Lado Servidor

O servidor poderá utilizar parsers JSON para conversão de objetos textuais JSON em, por exemplo, Java.

Axis2 suporta JSON:

HTTP

SOAP(XML)

JSONText

HTTP


Ajax

Utiliza JavaScript para processar requisições HTTP transportando documentos XML:

http_request.open('GET', url, true);http_request.send(null)

if(http_request.status == 200) { alert(http_request.responseText);} else {

alert('HTTP request failed');}


Ajax Como Cliente de Serviços Web

<html><head>...<script type="text/javascript" src="scripts/prototype.js"></script><script type="text/javascript" src="scripts/ws.js"></script><script type="text/javascript">function sayHello(name, container) { var call = new WS.Call('/AjaxWS/services/HelloWorld'); var nsuri = 'http://example'; var qn_op = new WS.QName('sayHello',nsuri); var qn_op_resp = new WS.QName('sayHelloResponse',nsuri); call.invoke_rpc(qn_op, new Array( {name:'name',value:name} ),null, function(call,envelope) { var ret = envelope.get_body().get_all_children()[0]. get_all_children()[0].get_value(); container.innerHTML = ret; $('soap').innerHTML = arguments[2].escapeHTML(); } );}</script></head>


Conclusão

HTTP + XML é atrativo pela simplicidade

Cliente Rico (Java + Web Service) versus Cliente Pobre (JavaScript + Ajax/JSON)

Aparentemente é muito difícil disseminar o uso de serviços comuns (WS-* terá o mesmo fim de CORBA Services?)

Grandes provedores de informação oferecem alternativas mais simples a Web Services (Amazon, Google, ...)

O que é de fato a Web 2.0?

Documents

IA847 Projeto de Sistemas Distribuídos Abertos143.106.148.168:9080/Cursos/IA847/01-07/ia847.pdf · global (por exemplo, ... convêniência, etc. Exemplo: Windows, Linux, Java, MATLAB