FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 1
FACULDADE DE INFORMÁTICA LEMOS DE CASTRO
Autorizada pelo Parecer no. 423/99 de 18/05/1999 e homologado pela Portaria Ministerial no. 947 de 22/06/1999
Nome da Disciplina Período Carga Horária
(CD) COMPUTAÇÃO DISTRIBUÍDA 7o 120
Notas de Aula – v4
Janeiro de 2012
Professor M. França
http://www.franca.pro.br/prof
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 2
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 3
O Autor
Marcelo França é técnico em Processamento de Dados, tecnólogo em Processamento de Dados,
analista de sistemas pós-graduado pela PUC-Rio, bacharel em Administração de Sistemas de Informação,
licenciado em Informática pelo Instituto Superior de Educação do Rio de Janeiro – ISERJ,
mestre em Informática pela Universidade Federal do Estado do Rio de Janeiro – UNIRIO,
aluno do MBA em gerenciamento de projetos da Fundação Getúlio Vargas,
certificado MCAD pela Microsoft, certificado SCJA pela Sun,
certificado RAD Associate pela IBM, certificado OCJP 6 (SCJP) pela Oracle,
professor de Informática da FAETEC e da Faculdade de Informática Lemos de Castro,
e especialista de sistemas da IBM Brasil.
Estuda Informática desde 1990 e trabalha com Informática desde 1994.
Dedicatória
Dedico este trabalho a todos os meus alunos e ex-alunos.
Desejo a todos vocês muito sucesso profissional.
Que seus objetivos sejam alcançados e que vocês sempre perseverem, mantendo o foco!
Agradecimentos
Agradeço ao Professor Walter Henrique pelo voto de confiança, e por ter me aberto as portas da FILC.
Obrigado, professor!
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 4
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 5
Índice
Aula 1 – Aspectos Estratégicos da Computação Distribuída ....................................... 9
Introdução ....................................................................................................... 9
Sistema Distribuído........................................................................................... 9
Histórico .......................................................................................................... 9
Tecnologias ................................................................................................... 10
Padrões para Aplicações .................................................................................. 11
EAI – Enterprise Application Integration ou Integração de Aplicações Corporativas . 12
Enterprise Architecture .................................................................................... 12
A Profissão de Arquiteto .................................................................................. 13
Outras Questões ............................................................................................. 14
Exercícios ...................................................................................................... 14
Aula 2 – Middlewares ......................................................................................... 15
Introdução ..................................................................................................... 15
Middleware .................................................................................................... 15
Taxonomia..................................................................................................... 16
Stubs vs. Skeletons ........................................................................................ 16
Queue VS. Topic ............................................................................................. 18
Servidores de Aplicação................................................................................... 19
Outras Questões ............................................................................................. 19
Exercícios ...................................................................................................... 19
Aula 3 – Objetos Distribuídos (Java IDL) [ESTUDO DIRIGIDO] ................................ 21
Introdução ..................................................................................................... 21
Serialização e RMI ............................................................................................. 26
Serialização e Persistência ............................................................................... 26
Introdução ao RMI .......................................................................................... 27
Outras Questões ............................................................................................. 29
Exercícios ...................................................................................................... 29
Aula 4 – Balanceamento de Carga ....................................................................... 31
Introdução ..................................................................................................... 31
Recursos ....................................................................................................... 31
Taxonomia..................................................................................................... 32
Políticas de Escalonamento .............................................................................. 33
Outras Questões ............................................................................................. 34
Exercícios ...................................................................................................... 35
Aula 5 – Algoritmos Distribuídos .......................................................................... 37
Introdução ..................................................................................................... 37
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 6
Breve Histórico .............................................................................................. 37
Características dos Sistemas Distribuídos .......................................................... 38
Computação Concorrente ................................................................................ 39
Comunicação ................................................................................................. 39
Taxonomia .................................................................................................... 40
Características ............................................................................................... 41
Outras Questões ............................................................................................ 41
Exercícios ...................................................................................................... 42
Aula 6 – Banco de Dados Distribuídos .................................................................. 45
Introdução .................................................................................................... 45
Considerações Importantes ............................................................................. 45
Vantagens de bancos de dados distribuídos ....................................................... 45
Desvantagens de banco de dados distribuídos ................................................... 46
Arquitetura de um banco de dados distribuídos em Oracle ................................... 47
Transações Distribuídas .................................................................................. 49
Outras Questões ............................................................................................ 52
Exercícios ...................................................................................................... 52
Aula 7 – Tolerância a Falhas em Ambiente Distribuído ........................................... 55
Introdução .................................................................................................... 55
Mitigar Riscos ................................................................................................ 55
Solução ........................................................................................................ 56
Outras Questões ............................................................................................ 57
Exercícios ...................................................................................................... 58
Aula 8 – Segurança em Ambientes Distribuídos ..................................................... 59
Cenário-Exemplo ............................................................................................ 59
Sub-net Masking ............................................................................................ 59
Motivação ..................................................................................................... 59
Desafios ........................................................................................................ 59
Conceitos Básicos ........................................................................................... 60
Cuidados ....................................................................................................... 60
Ataque (Taxonomia): ...................................................................................... 61
Políticas de Segurança .................................................................................... 61
Criptografia ................................................................................................... 62
Conclusão ..................................................................................................... 64
Outras Questões ............................................................................................ 64
Exercícios ...................................................................................................... 65
Aula 9 – Computação em Grade .......................................................................... 67
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 7
Histórico ........................................................................................................ 67
Internet/Web Como Plataforma ........................................................................ 68
Tecnologias ................................................................................................... 68
Conclusão ...................................................................................................... 69
Outras Questões ............................................................................................. 70
Exercícios ...................................................................................................... 71
Aula 10 – Análise de Desempenho de SD [ESTUDO DIRIGIDO] ............................... 73
Introdução ..................................................................................................... 73
Benchmark .................................................................................................... 75
Outras Questões ............................................................................................. 76
Exercícios ...................................................................................................... 76
Aula 11 – Componentes para Computação Distribuída ............................................ 77
Introdução ..................................................................................................... 77
Componentes Distribuídos ............................................................................... 77
Desenvolvimento Orientado a Componentes ...................................................... 78
Padrões para Empacotamento e Distribuição ...................................................... 78
Outras Questões ............................................................................................. 79
Exercícios ...................................................................................................... 79
Aula 12 – Microsoft .NET Remoting ...................................................................... 81
Introdução ..................................................................................................... 81
DCOM ........................................................................................................... 81
.NET Remoting ............................................................................................... 81
.NET Framework ............................................................................................. 81
Diferenças entre o Microsoft .NET Remoting e o DCOM ........................................ 82
Outras Questões ............................................................................................. 83
Exercícios ...................................................................................................... 83
Bibliografia/Créditos .......................................................................................... 85
Apêndice A – Questionário de Avaliação do Curso .................................................. 87
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 8
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 9
Aula 1 – Aspectos Estratégicos da Computação Distribuída
Introdução
Estratégia competitiva é o conjunto de planos, políticas, programas e ações
desenvolvidos por uma empresa ou unidade de negócios para ampliar ou manter, de modo
sustentável, suas vantagens competitivas (inclui oferecer valor agregado) frente aos
concorrentes. Para Ohmae (1983), “... Sem competidores não haveria necessidade de
estratégia, pois o único propósito do planejamento estratégico é tornar a empresa apta a
ganhar, tão eficientemente quanto possível, uma vantagem sustentável sobre seus
concorrentes. ...”. Para Porter (1985), “A estratégia competitiva visa estabelecer uma posição
lucrativa e sustentável contra as forças que determinam a competição industrial.”
A informática (TI) é suporte para a estratégia corporativa (sistemas de informação
versus ciência da computação). Implementar sistemas distribuídos (SD) é uma forma de se
operacionalizar este suporte.
Sistema Distribuído
Definição de um SD: vários computadores, interconectados por uma rede,
compartilhando um estado. Comunicação por mensagem (síncronas ou assíncronas) entre os
componentes. Exemplos de SD: Internet, Web, DNS, Multiprocessador, Cluster, Grid.
Cenários favoráveis à distribuição (motivação): problema distribuído (groupware),
escalabilidade (horizontal) e confiabilidade (dependability) são características desejáveis.
Características de um SD: [heterogeneidade,] modularidade, escalabilidade,
compartilhamento de recursos, degradação paulatina, mais sujeito a ataques (maior área),
“custo menor” (ao longo do tempo)[, controle distribuído].
Valores agregados com a distribuição: redundância (suporte a falhas, disponibilidade),
flexibilidade, manutenibilidade (crescimento modular), integração de serviços. Entretanto, o
custo com gerência tende a aumentar - TCO.
Histórico
Histórico dos sistemas distribuídos:
1. acesso remoto (terminais/mainframes)
2. distribuição de arquivos e memória (workstations)
3. servidores de arquivo (fator custo)
4. arquitetura cliente-servidor (downsizing)
5. cliente servidor em três camadas (thin client/www)
6. arquitetura peer-to-peer (P2P)
7. computação ubíqua (pervasive computing) – faculdade, trabalho, praia, etc..
Impulsionadores da evolução das arquiteturas: avanços tecnológicos e mudanças nos
requisitos definidos pelos usuários.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 10
Processos de Negócio: Representam as atividades relacionadas a negócios do dia-a-dia
de uma empresa. Centralizados ou distribuídos em múltiplos sites (carros são projetados em
um lugar, montados em muitos lugares e comercializados em diversos outros lugares).
Anos 60, 70 e 80: Processos de Negócios Centralizados. Sistemas de Informação
centralizados (CPD). Processamento centralizado. Poder dos negócios centralizado. Aplicações
centralizadas. Indústria dos computadores guiada mais pela tecnologia do que pelas
necessidades dos usuários. Vendedores são controladores do mercado. Mercado de massa.
Tempo longo para firmar presença no mercado. Tempo longo entre concepção e entrega.
Anos 90: Novo Ambiente de Negócios. Demanda cada vez mais sofisticada. Maior
número de concorrentes. Concorrência acirrada. Necessidades de respostas rápidas (on-
demand): novos produtos e novos serviços. Os vendedores já não mais controlam o mercado.
Clientes é que mandam: tratamento individualizado (Amazon.com); Informam o que
desejam, como desejam e quanto pagarão (eBay, MercadoLivre); Produtos configurados
(personalizados, customizados – Fiat.com.br); Cronogramas de entrega; Prazos de
pagamentos mais convenientes. Organizações novatas não obedecem às regras, elas
definem as regras (copyright & Internet).
Dispersão dos Sistemas de Informações. Dispersão dos negócios (Internet). Dispersão
do poder de processamento. Dispersão das aplicações. Diminuição dos sistemas proprietários
(crescimento do Open Source e Padrões Abertos – xml, webservices). Departamentos
adquirem recursos computacionais (“fim” do CPD). Globalização.
Para atender a estas exigências: Interação e cooperação crescentes entre grupos de
trabalhos e departamentos nas empresas (Intranet), assim como entre empresas (Extranet).
Mudanças organizacionais (culturais) drásticas. Groupware.
Reengenharia Empresarial: Mudanças maiores nas próprias estruturas organizacionais:
Reengenharia Empresarial: “O repensar fundamental e a reestruturação radical dos processos
empresariais, objetivando alcançar drásticas melhorias em indicadores críticos e
contemporâneos de níveis de desempenho: custos, qualidade, atendimento e rapidez.”
Para satisfazer a estes e outros desafios competitivos, empresas estão crescendo
contando com as Tecnologias da Informação (TI). Negócios estão sendo fundamentalmente
transformados através das Tecnologias da Informação.
Tecnologias
RPC, Middleware (integrar a empresa, programa de computador que faz a mediação
entre outros softwares) Orientados a Mensagem, OSF DCE (industry-standard, vendor-neutral
set of distributed computing technologies), Middleware de Dados Distribuídos (gateways SQL,
ODBC, JDBC), Middleware de Processamento de Transações, Cliente/Servidor, Serviços de
rede (sockets TCP/IP), Servidores de Replicação, Groupware, Multimídia, WWW (gateways,
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 11
servidores e browsers), Objetos Distribuídos (CORBA, OLE, OpenDoc, Microsoft .NET
Remoting), Middleware para Computação Móvel.
Tecnologia da Informação, com as funcionalidades oferecidas pela Computação
Distribuída, adequa-se perfeitamente como fornecedora de soluções para as organizações que
buscam os modelos adotados pela Reengenharia.
Sistemas Proprietários (Hardware + Software): Muitas empresas fornecedoras de
sistemas de computadores consideravam seu diferencial de competitividade baseado em
tecnologias proprietárias. Portabilidade de aplicações era quase impossível. Preços
exagerados, gerando grandes lucros para os fornecedores.
Sistemas Abertos: Com o advento de microprocessador (Anos 80), os fabricantes viram
seu poder começar a ser contestado. Grupos de interesse: Grupo de Desenvolvedores de
Software, Grupos de Usuários, Grupo dos Fabricantes de Hardware. Exigência: padrões para
os produtos de Tecnologia da Informação.
Os sistemas abertos formam um conjunto compreensivo de padrões internacionais para
a Tecnologia da Informação, que especificam interfaces, serviços e suporte a formatos que
possam atender à interoperabilidade e portabilidade de aplicações, dados (xml) e pessoas.
Uma metodologia para a integração de tecnologias divergentes, permitindo que se crie um
ambiente flexível para resolver os problemas de negócios de uma organização, através do uso
de software e hardware abertos, isto é não proprietários. A força de sustentação dos sistemas
abertos é a independência de fornecedores.
Órgãos de Padronização: OMG, W3C, ANSI (American National Standards Institute),
ISO (International Organization for Standardization), IEEE (Institute of Eletrical and Eletronic
Engineers), JIS (Japanese Institute for Standards), ABNT (Brasil).
Padrões para Aplicações
API (Interface de Programação de Aplicações). O que posso fazer com essa aplicação?
Estensibilidade. Permitir que um mesmo sistema operacional suporte diversos conjuntos de
interfaces, no sentido de que as aplicações possam ser executadas em qualquer sistema
operacional que suporte esse conjunto de interfaces. Aplicações escritas para um ambiente de
sistema operacional podem rodar em outros sistemas operacionais, porque existe uma API
para o desenvolvedor comum aos dois sistemas operacionais (c/c++, Java).
A Computação Distribuída fornece toda a infraestrutura necessária para a construção e
operação efetiva de aplicações distribuídas e engloba todos os produtos necessários para
permitir que essas aplicações sejam construídas e possam ser executadas em um ambiente
de rede heterogêneo, ou em um ambiente centralizado.
A infra-estrutura para a Computação Distribuída (CD) não precisa basear-se,
obrigatoriamente, em sistemas abertos. Podem ser suportados elementos abertos ou
proprietários. Porém, à medida que a complexidade e o número de aplicações construídas em
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 12
uma plataforma de CD forem crescendo, então diferentes ambientes operacionais e
plataformas de HW vão estar presentes. Nestas circunstâncias, é prudente o uso de interfaces
o mais “abertas” possíveis.
EAI – Enterprise Application Integration ou Integração de Aplicações Corporativas
Com o objetivo de conter custos durante as mudanças de negócios, as indústrias de
tecnologia freqüentemente necessitam integrar suas aplicações com sistemas legados sob
diferentes plataformas. Esta necessidade tem criado uma área de atuação atualmente
conhecida como mercado de integração de aplicações.
O termo EAI ou Enterprise Application Integration é novo, mas sugere toda essa
integração. É, ainda, o termo formal que contempla a integração de aplicações corporativas e
de um conjunto de ferramentas e tecnologias. A dependência das corporações em relação à
tecnologia tem crescido e se tornado mais complexa. Por isso, a integração de aplicações em
um único arsenal de processos de negócios tem se tornado prioridade para o sucesso de uma
empresa.
No contexto de EAI, uma figura de destaque é o “broker”, núcleo das integrações. O
Broker fica no centro das integrações fazendo o roteamento das mensagens para os seus
destinatários. Também faz a verificação das regras de negócio e transformações necessárias.
O objetivo é substituir integrações ponto a ponto, principalmente reutilizando mensagens. A
saída é única, indo para o broker, que transforma e roteia a mensagem.
Enterprise Architecture
An enterprise architecture (EA) is a rigorous description of the structure of an
enterprise, which comprises enterprise components (business entities), the externally visible
properties of those components, and the relationships (e.g. the behavior) between them.
"Enterprise" as used in enterprise architecture generally means more than the
information systems employed by an organization.
The popular TOGAF framework divides the practice into three domains: "Business
Architecture", "Information Systems Architecture" and "Technology Architecture" and then
subdivides the information systems architecture into "Information Architecture and
"Applications Architecture".
Describing the architecture of an enterprise aims primarily to improve the effectiveness
or efficiency of the business itself. This includes innovations in the structure of an
organization, the centralization or federation of business processes, the quality and timeliness
of business information, or ensuring that money spent on information technology (IT) can be
justified.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 13
A Profissão de Arquiteto
Arquitetos definem – “arquitetam” – soluções para problemas de negócios de clientes
através da aplicação fundamentada da Tecnologia; Essas soluções podem incluir sistemas
e/ou processos e geralmente envolvem a aplicação ou integração de uma variedade de
produtos, tecnologias e serviços;
Características gerais de um arquiteto incluem: Experiência no ciclo de vida completo
de soluções; Amplo conhecimento de tecnologia; Experiência em diversos casos; Bom
comunicador; Liderança técnica; Usa metodologias formais; Produz arquiteturas de valor;
A demanda por arquitetos está aumentando.
Mais detalhes em http://www.slideshare.net/msavio/slideshows
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 14
Outras Questões
• Carreira (Punto VS. MBA)
• Não ser um profissional bit/byte (estar antenado ao negócio da empresa).
• Que tal R$ 5.000 (CLT) em uma grande empresa? “Pô, não dá...” Que perfil é
esse? (Especialista em Middleware/Integração)
• Visão estratégica de TI (maximizar lucros, reduzir custos, sempre estamos
empregados).
• Engenharia de Produção (Analista de Negócios)
• Clusterização versus Virtualização (Mainframes Z10/ZOS) – custo Oracle por
processador.
Exercícios
1. O que são sistemas distribuídos, e como eles podem ajudar na estratégia
competitiva de uma empresa?
2. Cite características encontradas em sistemas distribuídos.
3. O que é dependability?
4. O que é Groupware?
5. Relacione Sistemas Proprietário e Sistemas Abertos com o histórico da tecnologia
da informação.
6. O que é uma API? Qual a relação desse conceito com o sucesso (aceitação) da
tecnologia Java?
7. Quais os dois entendimentos mais comuns para o termo EAI?
8. No contexto de EAI, defina Broker.
9. Relacione padrões de mercado, soluções de TI e TCO.
10.O que faz um arquiteto (de integração)?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 15
Aula 2 – Middlewares
Introdução
Sistema distribuído (SD): coleção de componentes, distribuídos entre vários
computadores conectados via uma rede. Esses componentes interagem a fim de trocar dados
ou acessar os serviços uns dos outros. Essa interação pode ser construída diretamente
através das APIs do sistema operacional � extremamente complexo para muitos
desenvolvedores. Em vez disso � suporte de Sistemas de Middleware: localizados entre
componentes do SD e componentes do sistema operacional; sua tarefa é facilitar as
interações entre esses componentes.
Middleware
Camada de software que permite a comunicação entre aplicações (distribuídas); Um
conjunto de serviços que fornece comunicação e distribuição de forma transparente à
aplicação: Middleware permite que processos em diferentes espaços de endereçamento
consigam se comunicar.
Objetivo: Facilitar o desenvolvimento de aplicações e a integração de sistemas legados
(adaptadores) ou desenvolvidos de forma não integrada (transparência).
Ajudam a gerenciar a complexidade e a heterogeneidade inerentes ao desenvolvimento
de aplicações e sistemas distribuídos; Mascara a heterogeneidade com que os programadores
de aplicações distribuídas têm que lidar: Rede & hardware; Sistemas operacionais &
linguagem de programação; Localização, acesso, falhas, concorrência; Diferentes plataformas
de middleware.
Middleware deve fornecer: Facilidade de Uso - Middleware deve ser mais fácil de usar
do que escrever uma interface de comunicação de baixo nível usando sockets; Transparência
de Localização - Deve ser possível mover uma aplicação para um endereço de rede diferente
sem a necessidade de recompilar qualquer software (diminuir o acoplamento/DNS);
Transparência de Linguagem (e plataforma) - Um processo usando o middleware deve ser
capaz de se comunicar com um processo que foi escrito em uma linguagem diferente.
Serviços Oferecidos:
• Infra-estrutura: Encapsulam e melhoram os mecanismos de concorrência e
comunicação nativos do sistema operacional. Ex. estabelecimento de conexão,
sincronização, (un) marshalling (serialização). Ex.: RPC, ACE (Adaptive
Communication Environment) – abstraem as peculiaridades dos SOs.
• Distribuição, remotabilidade: Permitem a integração de aplicações remotas de
forma transparente. Exemplo: Brokers CORBA, RMI, SOAP. Definem modelos de
programação que permitem a construção de aplicações distribuídas, onde a
comunicação é abstraída.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 16
• Comuns: Serviços independentes do domínio de aplicação que fazem uso da
infra-estrutura de distribuição/comunicação. Ex. segurança, transação.
• Específicos, outros: Diretamente relacionados a domínios específicos. Exemplo
de domínios: telecomunicações (URAs, CTI), comércio eletrônico, automação,
saúde, computação móvel.
Principais Plataformas de Middleware Existentes: CORBA da OMG, JEE da Sun/Oracle,
COM, COM+, DCOM da Microsoft, .NET Remoting da Microsoft (hoje, WCF), Web
Services/SOA. Denominações Equivalentes: Modelos de Integração de Objetos, Plataformas
de Distribuição de Objetos.
Taxonomia
Procedure Oriented Middleware (RPC – Remote Procedure Call): Chamadas Remotas de
Procedimentos. É uma chamada de procedimento que cruza as fronteiras dos componentes
locais (hosts). Idéia básica: no que concerne ao processo cliente, não há diferença lógica
entre chamar um procedimento local ou um remoto. Uma chamada remota de procedimento
usa comunicação direta, orientada a conexão e síncrona para permitir a um processo cliente
chamar um procedimento remoto. Paradigma criado pela Sun como parte de sua plataforma
Open Network Computing (ONC). Serviços: comunicação síncrona (request/wait-for-reply).
Vários problemas devem ser tratados pelo programador. Exemplo: Falhas na comunicação.
Stubs vs. Skeletons
In the distributed computing environment, stub stands for client side object
participating in the distributed object communication. The stub acts as a gateway (design
pattern PROXY) for client side objects and all outgoing requests to server side objects that are
routed through it. The stub wraps client object functionality and by adding the network logic
ensures the reliable communication channel between client and server.
In the distributed computing environment skeleton stands for server side object
participating in the distributed object communication. Skeleton acts as gateway for server
Dado (marshalling) � “.--...” � (unmarshalling) Dado
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 17
side objects and all incoming clients requests are routed through it. The skeleton wraps
server object functionality and exposes it to the clients, moreover by adding the network logic
ensures the reliable communication channel between clients and server.
Para fazer uma RPC: O processo cliente chama o stub do cliente como se fosse um
procedimento local. O stub do cliente converte os parâmetros em uma string de bits
(marshalling) e envia os bits na rede para o skeleton do servidor. O skeleton do servidor
converte os bits de volta para parâmetros (unmarshalling) e chama o procedimento no
servidor. O skeleton do servidor converte a resposta do procedimento em uma string de bits e
envia pela rede para o stub do cliente. O stub do cliente converte os bits para a resposta e a
retorna para o procedimento chamador.
Middleware Orientado a Transação: Conhecidos como Monitores de Processamento de
Transações (transaction-processing - TP). Chamada de procedimento remoto + controle de
transações. Principais Serviços: Comunicação síncrona/assíncrona, Transação, Outros
Serviços: Segurança e integridade de dados, Tuning, Balanceamento de carga, Entrega
confiável dos dados, Serviços de nomes - facilitam a descoberta de recursos distribuídos.
Usado em aplicações que demandam rapidez na execução de transações remotas.
Frequentemente usado com aplicações de bancos de dados distribuídos. Tipicamente, os
monitores de TP não são usados para comunicação aplicação-aplicação. Mas, fornecem um
ambiente completo para aplicações de transações que acessam bancos relacionais.
Exemplo: BEA Tuxedo. Construído sobre uma arquitetura orientada a serviços (Service
Oriented Architecture - SOA). Sua plataforma para processamento de transações fornece a
infra-estrutura necessária para: aumentar a acessibilidade de aplicações existentes;
consolidar soluções para transações e passagem de mensagens; garantir a maior
disponibilidade e o maior throughput possível de aplicações; aumentar a eficiência de
processamento e melhorar a gerência de recursos.
Middleware Orientado a Mensagem (Message Oriented Middleware – MOM): É o mais
usado, mais comum. Comunicação através de passagem de mensagens; Tecnologia
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 18
inerentemente assíncrona, e com fraco acoplamento; Filas de mensagens implementam um
link de comunicação indireto, sem conexão e assíncrono entre dois ou mais processos; Um
gerente de filas rodando em um servidor separado gerencia as filas e garante que não
importa o que ocorra na rede, apenas uma cópia da mensagem eventualmente chega ao seu
destino; Deve-se notar que embora a comunicação de processo para processo seja
assíncrona, a comunicação entre um processo e o gerente de fila é em geral implementada
usando um link de comunicação direto e síncrono; Isso significa que se a rede cair ou se o
gerente cair, um processo não pode incluir mensagens em uma fila ou obter mensagens da
mesma.
Filas (queue) são independentes de um processo. Então, muitos processos podem
incluir, ou obter (retirando ou não as mensagens da fila) mensagens de uma mesma fila. Um
processo pode também acessar múltiplas filas; Se a rede ou um destino cair, as mensagens
podem esperar na fila até a falha se resolver; Filas podem ser armazenadas em disco de
forma que se o gerente de filas cair, a fila não é perdida; O gerente de filas pode cooperar
com um gerente de transações; se uma transação é iniciada e uma mensagem é colocada em
uma fila durante a transação a qual é mais tarde abortada, então não somente o BD tem que
sofrer roll back, mas a mensagem também é removida da fila e não enviada.
Queue VS. Topic
-On-line, “multi-cast”.
Principais Serviços: comunicação assíncrona, priorização de mensagens, segurança,
suporte a Multicasting (delivery of information to a group of destinations simultaneously using
the most efficient strategy to deliver the messages over each link of the network only once,
creating copies only when the links to the multiple destinations split), MOM é usado quando
comunicação assíncrona e confiável é a forma dominante de interação do sistema distribuído:
não assume um transporte confiável. Exemplo de Produtos: MQSeries da IBM (hoje, IBM
WebSphere MQ), MSMQ da Microsoft, Tuxedo/Q (WebLogic) da BEA Systems, Java Message
Service - JMS (Sun), WebMethods Broker (costumava vir com o SAP).
Middleware Baseado em Objetos (Object Oriented Middleware): evoluiu mais ou menos
diretamente da idéia de RPC. Usado para chamar uma operação (implementada por um
método) em uma instância de objeto (instanciada a partir de uma classe) que reside em outro
processo.
A idéia aqui é tornar os princípios orientados a objetos disponíveis para o
desenvolvimento de sistemas distribuídos, ou seja, distribuição + OO = Objetos Distribuídos.
O primeiro desses sistemas foi o OMG Common Object Request Broker Architecture
(CORBA). Microsoft adicionou capacidades de distribuição a seu Component Object Model
(COM � DCOM). Sun forneceu mecanismos para Invocação Remota de Métodos – Remote
Method Invocation (RMI).
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 19
Servidores de Aplicação
GlassFish, MS IIS, JBoss, IBM WAS.
Principais Vantagens do middleware OO sobre o middleware RPC: Mais flexível,
Naturalmente integrado com linguagens OO. Exemplos de Tecnologias: Java Remote Method
Invokation (RMI) e EJB (Sun), Common Object Request Broker (CORBA), Distributed
Component Object Model (DCOM), Microsoft .NET Remoting (usado com o Microsoft COM+).
Middleware para Web: WebServices, HTTP (padrão), ubiqüidade (até videogame acessa
http), XML (padrão), codificação dos dados, SOAP (padrão), comunicação (RPC), executa
sobre o http, WSDL – Web Service Definition Language (padrão): o que, onde, como, UDDI –
Universal Description Discovery and Integration (padrão): Descoberta e negociação.
WebServices agem como uma “interface” para acessar os serviços providos por outros
middleware.
Outras Questões
• Arquitetura SOA: In computing, service-oriented architecture (SOA) provides
methods for systems development and integration where systems group
functionality around business processes and package these as interoperable
services. An SOA infrastructure allows different applications to exchange data
with one another as they participate in business processes. Service-orientation
aims at a loose coupling of services with operating systems, programming
languages and other technologies which underlie applications.
• Arquitetura Enterprise Service Bus: In computing, an enterprise service bus
(ESB) refers to a software architecture construct. This construct is typically
implemented by technologies found in a category of middleware infrastructure
products, usually based on recognized standards, which provide fundamental
services for complex architectures via an event-driven and standards-based
messaging engine (the bus).
• Software Microsoft BizTalk Server: often referred to as simply "BizTalk", is a
business process management (BPM) server. Through the use of "adapters"
which are tailored to communicate with different software systems used in a
large enterprise, it enables companies to automate and integrate business
processes. Offered by Microsoft, it provides the following functions: Business
Process Automation, Business Process Modeling, Business-to-business
Communication, Enterprise Application Integration and Message broker.
• JBoss Enterprise Middleware - http://www.jboss.com/products
Exercícios
1. O que são Middlewares, e quais seus objetivos?
2. Explique o conceito de “transparência” no contexto de middlewares.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 20
3. Explique a arquitetura de um MOM?
4. O que é Cloud Computing?
5. O que é SOA?
6. O que é ESB?
7. Relacione stub e skeleton.
8. Precisa-se integrar uma aplicação legada que usa um banco proprietário (ZIM).
Como proceder?
9. Ao tentar implementar RMI, detectou-se um problema de conexão (socket) por
conta de um firewall. Como proceder?
10.Justifique por que filas promovem o baixo acoplamento entre aplicações?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 21
Aula 3 – Objetos Distribuídos (Java IDL) [ESTUDO DIRIGIDO]
Introdução
RPC – Remote procedure call: Este termo é utilizado para aplicativos clientes que fazem
normalmente chamadas a procedimentos remotos que estão em outro processo e hosts. RPC
objetiva permitir chamada de procedimento remoto como se fosse local, ocultando
entrada/saída de mensagens.
RMI – Remote method invocation: O modelo baseado orientado a objeto utiliza este
termo para definir uma chamada local a um método em um objeto remoto.
Interface Definition Languages – IDL (padrão/interoperabilidade): Permite criar uma
notação universal para interface de métodos e variáveis para serem utilizados entre diversas
linguagens de programação.
Marshalling: Linearização (serialização) de uma coleção de itens de dados estruturados
(com exceção dos atributos transientes/java). Tradução dos dados em formato externo (bits).
Unmarshalling: Tradução do formato externo para o local. Restauração dos itens de dados de
acordo com sua estrutura.
Programação distribuída em Java: Entre os atrativos de Java está a facilidade que essa
linguagem oferece para desenvolver aplicações para execução em sistemas distribuídos. Já
em sua primeira versão, Java oferecia facilidades para o desenvolvimento de aplicações
cliente-servidor usando os mecanismos da Internet, tais como os protocolos TCP/IP e UDP.
Se o cliente na aplicação distribuída precisa acessar um servidor de banco de dados
relacional, Java oferece uma API específica para tal fim, JDBC. Através das classes e
interfaces desse pacote é possível realizar consultas expressas em SQL a um servidor de
banco de dados e manipular as tabelas obtidas como resultado dessas consultas.
Em termos de desenvolvimento voltado para a World-Wide Web, Java oferece o já
clássico mecanismo de applets, código Java que executa em uma máquina virtual no lado do
cliente (tipicamente um navegador) Web. O mecanismo de servlets permite associar o
potencial de processamento da plataforma Java a servidores Web, permitindo construir assim
aplicações com arquitetura de distribuição de três camadas baseadas no protocolo HTTP e em
serviços implementados em Java.
Aplicações distribuídas mais elaboradas podem ser desenvolvidas usando uma
arquitetura de objetos distribuídos, onde aplicações orientadas a objetos lidam diretamente
com referências (variáveis) a objetos em processos remotos (servidores de aplicação). Java
oferece duas alternativas nessa direção, RMI (Remote Method Invocation), uma solução
100% Java, e Java IDL, esta uma solução integrada à arquitetura padrão CORBA. Um passo
adiante na evolução desse tipo de sistema é a utilização do conceito de agentes móveis, onde
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 22
não apenas referências a objetos são manipuladas remotamente mas os próprios objetos
(código e estado) movem-se pela rede. � Outras (Java): EJB, Spring Framework
Objetos Distribuídos: Na programação distribuída usando a arquitetura cliente-servidor,
clientes e servidores podem ser implementados usando qualquer paradigma de programação.
Assim, é possível que um serviço específico seja executado por um método de algum objeto.
No entanto, mesmo que o cliente também tenha sido desenvolvido orientação a objetos, na
comunicação entre o cliente e o servidor esse paradigma deve ser esquecido, devendo ser
utilizado algum protocolo pré-estabelecido de troca de mensagens para a solicitação e
resposta ao serviço.
Um sistema de objetos distribuídos é aquele que permite a operação com objetos
remotos. Dessa forma é possível, a partir de uma aplicação cliente orientada a objetos, obter
uma referência para um objeto que oferece o serviço desejado e, através dessa referência,
invocar métodos desse objeto – mesmo que a instância desse objeto esteja em uma máquina
diferente daquela do objeto cliente.
O conceito básico que suporta plataformas de objetos distribuídos é o conceito de
arquiteturas de objetos. Essencialmente, uma arquitetura orientada a objetos estabelece as
regras, diretrizes e convenções definindo como as aplicações podem se comunicar e
interoperar. Dessa forma, o foco da arquitetura não é em como a implementação é realizada,
mas sim na infra-estrutura e na interface entre os componentes da arquitetura.
Na plataforma Java, dois mecanismos são oferecidos para o desenvolvimento de
aplicações usando o conceito de objetos distribuídos: Java RMI e Java IDL. RMI (invocação
remota de métodos) é um mecanismo para desenvolver aplicações com objetos distribuídos
que opera exclusivamente com objetos Java. Java IDL utiliza a arquitetura padrão CORBA
para integração de aplicações Java a aplicações desenvolvidas em outras linguagens.
Java IDL: A API Java IDL, presente na plataforma Java 2, permite a integração entre
objetos Java e outros objetos remotos (caixa preta), eventualmente desenvolvidos em outras
linguagens de programação, através da arquitetura CORBA. Os principais pacotes que
compõem essa API são org.omg.CORBA e org.omg.CosNaming.
A partir da versão 1.3 da plataforma Java 2, é possível gerar interfaces IDL para
classes Java usando o compilador rmic com a opção "-idl". Outra opção, "-iiop", indica que o
protocolo de comunicação de CORBA, IIOP, será utilizado em stubs e ties (correspondentes
aos skeletons) de RMI.
Uma vez obtida a interface IDL para um serviço, as classes auxiliares para acessar o
objeto remoto que implementa o serviço são obtidas pela compilação da interface, usando o
aplicativo idlj (ou idltojava ou ainda idl2java em versões anteriores ao Java 1.3). Além de
classes para stubs e skeletons, são geradas classes auxiliares (helpers e holders) para
permitir a comunicação entre objetos Java e outras linguagens.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 23
Na plataforma Java há uma implementação para o serviço de nomes de CORBA,
oferecida pelo aplicativo tnameserv. Esse serviço está mapeado por default para a porta 900,
podendo esta ser modificada pela opção "-ORBInitialPort".
ORB é o Object Request Broker, o núcleo da arquitetura CORBA. É um programa que
deve estar sendo executado em cada máquina envolvida em uma aplicação CORBA, sendo o
responsável pela conexão entre clientes e serviços através dos correspondentes stubs e
skeletons.
A interação entre um ORB e um programa Java dá-se através de métodos da classe
ORB. Para inicializar a referência ao ORB, utiliza-se o método estático init() dessa classe. Para
obter uma referência para o serviço de nomes utiliza-se o método resolve_initial_references()
tendo a NameService como argumento.
Exemplo de Java IDL: Este exemplo, obtido da documentação da Sun, é uma
implementação em Java IDL do tradicional "hello world", composto por três arquivos:
Interface IDL: uma interface para um serviço com um único método definido usando as
construções da linguagem IDL. Usando o aplicativo idl2j gera-se a interface Java
correspondente, com a tradução das construções IDL para as primitivas Java segundo o
padrão estabelecido em CORBA, e outros arquivos auxiliares (stub, skeleton, helper, holder),
não apresentados aqui. Exemplo: module HelloApp {
interface Hello {
string sayHello();
}
}
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 24
Exemplo de cliente que ativa o ORB, obtém uma referência para o serviço de nomes e,
a partir deste serviço, obtém uma referência remota para o objeto com o serviço Hello.
Obtida a referência, o método é invocado normalmente. import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CORBA.*;
public class HelloClient {
public static void main (String args[]) {
try {
// Create ORB object
ORB meuOrb = ORB.init(args,null);
// Find hello server
org.omg.CORBA.Object objRef = meuOrb.resolve_initial_references("NameService");
// Narrow the reference from generic object
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// Find service in Naming (req. array of NameComp)
NameComponent nc = new NameComponent("Hello","");
NameComponent path[] = {nc};
Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));
// Invoke remote service
String hi = helloRef.sayHello();
System.out.println(hi);
}
catch(Exception e) {
System.out.println(e);
e.printStackTrace(System.out);
}
}
}
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 25
Exemplo de servidor/serviço: nesse arquivo são criadas duas classes. A classe
HelloServer é um servidor que ativa o ORB, cria o objeto que implementa o serviço, obtém
uma referência para o serviço de nomes e registra o objeto neste diretório associado ao nome
Hello. A classe HelloServant é uma implementação do serviço especificado; observe que essa
classe é uma extensão de _HelloImplBase, o skeleton definido pelo aplicativo idltojava. import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class HelloServer {
public static void main(string args[]) {
try {
// Create the ORB
ORB orb = ORB.init(args,null);
// Instantiate the servant object
HelloServant helloRef = new HelloServant();
// Connect servant to the ORB
orb.connect(helloRef);
//Registering the servant
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("Hello","");
NameComponent path[] = {nc};
ncRef.rebind(path, helloRef);
// Wait for invocation
java.lang.Object sync = new java.Lang.Object();
synchronized(sync) {
sync.wait();
}
}
catch(Exception e) {
System.out.println(e);
e.printStackTrace(System.out);
}
}
}
class HelloServant extends _HelloImplBase {
public String sayHello() {
return "\nHelloWorld!\n";
}
}
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 26
Serialização e RMI
Serialização e Persistência
• Serializando e Persistindo Objetos o Como transferir os dados da aplicação servidora para as aplicações clientes? o Objetos Java “vivem” dentro de uma JVM; É necessário que a classe desses
objetos esteja carregada (Onde? Basta ser homônima?). o O processo de criar uma cópia em formato binário dos dados de um objeto é
chamado serialização. o Podemos armazenar este conteúdo (binário) em um arquivo (file system) ou até
mesmo em um banco de dados; Os dados desse objeto são persistidos.
• Definindo uma classe “Serializable”. o Exemplo (package java.io):
package br.com.caelum;
public class Livro implements Serializable {
private static final long serialVersionUID = 1L;
private String nome;
//…
} o “Interface de Marcação” – não requer, de fato, a implementação de método
algum - annotations. o ObjectOutputStream é o responsável por serializar os objetos. o Exemplo:
Livro effectiveJava = new Livro();
FileOutputStream saidaArquivo = new
FileOutputStream(“effectiveJava.txt”); // qualquer extensão
ObjectOutputStream serializador = new
ObjectOutputStream(saidaArquivo);
serializador.writeObject(effectiveJava);
o Exemplo (inverso): FileInputStream entradaArquivo = new
FileInputStream(“effectiveJava.txt”);
ObjectInputStream ois = new ObjectInputStream(entradaArquivo);
Livro livro = (Livro) ois.readObject();
• Compatibilidade (serialVersionUID) o Distribuir o arquivo .class (JARs).
• Serialização em Cascata o Em relacionamento do tipo has-a ambas as classes precisam implementar
Serializable, senão o processo irá falhar. o Serialization lets you simply say “save this object and all of its instance
variables.” Unless I’ve explicitly marked a variable as transient.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 27
• Atributos Transientes o Oposto de persistente. o Você não deseja que todos os atributos participem do processo de serialização. o Exemplo:
public class Pessoa implements Serializable {
private Calendar dataDeNascimento;
private transient int idade;
} o Quando for desserializado o Java coloca o valor default para esse atributo (no
exemplo, 0). o private void writeObject (ObjectOutputStream os){ o private void readObject(ObjectInputStream is){
� defaultWriteObject() � defaultReadObject() � obs.: The constructor does not run – mas o da super classe não
serializável, sim.
Introdução ao RMI
Conceitos:
- transparência;
- contrato (buscará no catálogo);
- “objeto de mentira” (stub) � retornado pelo “catálogo”/padrão de projeto PROXY:
implementa a comunicação/gerado automaticamente (Proxy dinâmico);
- serialização (com RMI)
Atenção: RMI não é Java EE, é Java SE.
• Invocação Remota de Método o Como disponibilizar este serviço? o Não quero ser o responsável por código de infra (sockets). o aplicação cliente apenas tendo uma referência utilizada para invocar métodos em
um objeto que está na aplicação servidora, em outra JVM. o Objeto remoto/remotabilidade.
• Java RMI – Remote Method Invocation o Se o objeto deve aceitar invocações remotas então ele funciona como se fosse
um “mini servidor”. o O “objeto de mentira” (stub) do lado do cliente invoca o objeto remoto. o Para o cliente ter a impressão de estar conversando com o objeto de verdade
(transparência), o objeto de mentira tem que ter as mesmas assinaturas de
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 28
métodos – basta criar uma interface que é implementada pelas classes dos dois objetos.
o Exemplo (Interface): public interface ProcuraLivro extends Remote {
Livro procura (String isbn) throws RemoteException;
}
o Exemplo (Classe que implementa o Serviço) public class ProcuraLivroService extends UnicastRemoteObject
implements ProcuraLivro {
//...
public Livro procura (String isbn) throws RemoteException {
return this.repositorio.get(isbn);
}
}
o Quem vai criar a classe do objeto de mentira? Deixamos a máquina virtual criar a classe dinamicamente (proxy dinâmico) em tempo de execução a partir da interface remota.
• Colocando o Objeto no Servidor o Registrando (bind) um objeto remoto (utilizando um “catálogo de objetos
remotos”) utilizando um “apelido”. o Os clientes fazem uma busca (lookup) pelo apelido do objeto desejado. O
catálogo devolve as informações necessárias para a própria máquina virtual da aplicação cliente construir um stub que possa se conectar com o objeto remoto.
o Exemplo (subindo o catálogo/na máquina Servidora): LocateRegistry.createRegistry(1099); //porta listener do catálogo
o Exemplo (registrando um objeto remoto/na máquina Servidora): ProcuraLivroService buscadorDeLivro = new ProcuraLivroService(); Naming.rebind(“loja/procura”, buscadorDeLivro);
o Exemplo (buscando um objeto remoto/na máquina Cliente): ProcuraLivro biblioteca = (ProcuraLivro) Naming.lookup(“rmi://localhost:1099/loja/procura”);
o O serviço de nomes básico do Java é chamado rmiregistry. “Em produção” é mais comum o uso do JNDI – Java Naming and Directory Interface.
• Quem são os servidores? o RMI é uma tecnologia realmente distribuída. O serviço de nomes centraliza as
informações de onde está cada objeto. Servidor de Nomes (catálogo) e Aplicação.
• O Cliente o Exemplo:
import Java.rmi.Naming; public class ClienteLoja { public static void main (String[] args) throws Exception { ProcuraLivro biblioteca = (ProcuraLivro) Naming.lookup(“rmi://localhost:1099/loja/procura”); Livro livro = biblioteca.procura(“1111”); System.out.println(“Livro: ” + livro.getNome()); } }
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 29
Outras Questões
• Design Patterns do ponto de vista do arquiteto (EJB, VO, TO) • Uso de Stored Procedures (Velocidade, Camada de Indireção Adicional) -
Exemplo arquitetura para um sistema de cartão de crédito.
• Outras tecnologias: Silverlight (MS), Flash/Flex, Java FX.
• Posso usar (outra) aplicação Java para instanciar os objetos (no servidor) e
registrá-los no catálogo, e me preocupar com a gestão do “pool” ou... Servidor
de Aplicação/Middleware (IBM WAS, JBoss, etc..)
Exercícios
1. Compare Java IDL com Java RMI.
2. Compare Marshaling e Unmarshaling.
3. Relacione ORB com a arquitetura CORBA.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 30
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 31
Aula 4 – Balanceamento de Carga
Introdução
Um sistema distribuído constitui-se de um conjunto de processadores autônomos
conectados através de um subsistema de comunicação, que cooperam entre si através da
troca de mensagens. Esse tipo de sistema deve apresentar duas características inerentes: 1)
a transparência na sua utilização, ou seja, a capacidade de apresentar-se aos seus usuários
como uma entidade única, e 2) o alto grau de tolerância a faltas (falhas). Uma das formas de
se implementar tolerância a falhas é através do balanceamento de carga.
Balanceamento de carga: Todo o hardware tem o seu limite, e muitas vezes o mesmo
serviço tem que ser repartido por várias máquinas, sob pena de se tornar congestionado.
Estas soluções podem-se especializar em pequenos grupos sobre os quais se faz um
balanceamento de carga.
Recursos
Utilização do CPU, de armazenamento, ou de rede. Qualquer uma delas introduz o
conceito de clustering, ou server farm, já que o balanceamento será, provavelmente, feito
para vários servidores.
Balanceamento de CPU: Este tipo de balanceamento é efetuado pelos sistemas de
processamento distribuído e consiste, basicamente, em dividir a carga total de processamento
pelos vários processadores no sistema (sejam eles locais ou remotos). Soluções (software):
Beowulf, openMosix, openSSI, OSCAR.
Balanceamento de Carga em SD de Propósito Geral: Um sistema distribuído consiste
numa coleção de computadores autônomos conectados por uma rede de comunicação. Devido
a flutuações na taxa de chegada e no tempo de serviço das tarefas submetidas pelos usuários
durante um certo intervalo de tempo, algumas máquinas poderão estar ociosas enquanto
outras estarão pesadamente carregadas. Os algoritmos de compartilhamento ou distribuição
de carga tentam melhorar o desempenho deste tipo de sistema compartilhando a carga de
trabalho do sistema entre as máquinas que o compõem. Os algoritmos de balanceamento de
carga vão além, visando equilibrar a carga de todas as máquinas.
O problema do balanceamento de carga é um problema de escalonamento, que
consiste em determinar qual máquina da rede irá executar uma determinada tarefa de
maneira a “otimizar” o desempenho do sistema. Encontrar a solução ótima para este tipo de
problema é em geral um problema NP-Completo (os problemas tratáveis também são
comumente denominados "P"/Polinomiais, enquanto os intratáveis são denominados
"NP"/Não-Polinomiais).
Algoritmos de balanceamento de carga podem ter sua atividade de distribuição de
carga disparada pelas máquinas com pouca carga (receptoras) que tentam obter tarefas a
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 32
partir de outras mais carregadas (remetentes), ou disparada pelas máquinas sobrecarregadas
que tentam enviar tarefas àquelas menos carregadas. Algoritmos que utilizam a primeira
estratégia são chamados receiver-initiated e os algoritmos que utilizam a segunda estratégia
sender-initiated. Nos algoritmos symmetrically-initiated, tanto as máquinas receptoras quanto
as remetentes podem disparar a atividade de distribuição de carga.
Estudos mostram que, em sistemas com baixa carga de trabalho, algoritmos sender-
initiated têm mais sucesso em encontrar máquinas subcarregadas e em sistemas com alta
carga de trabalho, algoritmos receiver-initiated têm mais sucesso em encontrar máquinas
sobrecarregadas.
Taxonomia
Classes de algoritmos de balanceamento de carga:
• estático versus dinâmico: estas classes se diferem quanto ao momento em que
as decisões de escalonamento são tomadas. Nos algoritmos estáticos assume-se
que o número de tarefas e comportamento de cada tarefa é conhecido quando o
sistema ainda está sendo compilado; cada tarefa é atribuída a um processador
fixo e toda vez que uma imagem desta tarefa for instanciada, ela será atribuída a
este processador. Nos algoritmos dinâmicos assume-se que se tem pouquíssimo
conhecimento a priori sobre as necessidades de recursos das tarefas que
compõem o sistema; portanto, as decisões de escalonamento são tomadas
somente quando o sistema está em execução.
• fisicamente distribuído versus fisicamente não-distribuído: quando a
responsabilidade de tomar decisões sobre o escalonamento de tarefas reside em
um único processador dizemos que este algoritmo é fisicamente não-distribuído.
Caso contrário o algoritmo é dito fisicamente distribuído.
• cooperativo versus não-cooperativo: os algoritmos onde um processador
individual toma decisões independentemente das ações tomadas por outros
processadores são denominados não-cooperativos. Os algoritmos onde há
cooperação entre os componentes distribuídos são chamados cooperativos.
• adaptável versus não-adaptável: numa solução adaptável os algoritmos e os
parâmetros utilizados para implementar o escalonador podem mudar
dinamicamente de acordo com o comportamento anterior e atual do sistema em
resposta às decisões anteriores feitas pelo escalonador (otimização).
Além de poderem ser divididos nestas classes, os algoritmos de balanceamento de
carga podem ser síncronos ou assíncronos, e preemptivos ou não-preemptivos. Algoritmos
síncronos exigem que todas as máquinas do sistema estejam sincronizadas para que possam
iniciar a atividade de distribuição num mesmo instante no tempo. Uma vez distribuída a
carga, as máquinas sincronizam-se novamente e voltam a executar as tarefas ainda
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 33
pendentes. Algoritmos assíncronos são mais flexíveis. Grupos de máquinas do sistemas
podem iniciar a atividade de distribuição em momentos diferentes, não existindo a
necessidade de sincronização. Nas soluções preemptivas a execução de uma tarefa pode ser
interrompida para que esta tarefa seja migrada de uma máquina para outra; em soluções não
preemptivas somente as tarefas que não estejam sendo executadas podem ser movidas.
Algoritmos preemptivos geralmente têm um custo muito alto, uma vez que guardar o estado
de uma tarefa, que pode ser muito grande ou complexo, é na maior parte das vezes uma
tarefa difícil.
Políticas de Escalonamento
Os algoritmos de balanceamento de carga podem ser divididos em 4 componentes:
política de transferência, política de seleção, política de localização, e política de informação.
A política de transferência determina qual máquina deve iniciar a transferência de tarefas. A
política de localização deve encontrar uma outra máquina que possa receber ou enviar tarefas
para máquina selecionada pela política de transferência. A política de seleção seleciona a
tarefa ser transferida. A política de informação decide quando, a partir de onde, e quais as
informações sobre as máquinas do sistema devem ser coletadas.
Uma das maneiras de se implementar estas políticas é baseá-las em um limiar
(threshold/Ferramentas Administrativas – Performance Counters): toda vez que o índice que
caracteriza a carga do sistema ultrapassar este limite, uma decisão deverá ser tomada de
maneira a alterar o estado do sistema. A dificuldade está em encontrar o limiar que otimize o
desempenho do sistema. Entretanto, existem diferentes maneiras para se implementar cada
uma destas políticas e portanto, uma grande variedade de algoritmos de balanceamento de
carga.
Políticas adaptáveis possuem maior habilidade em evitar estados de baixo
desempenho. Entretanto, como estas políticas devem coletar e reagir às informações sobre o
estado do sistema, elas são necessariamente mais complexas que políticas estáticas. Uma
das perguntas a serem feitas sobre estas políticas e talvez a mais importante é: qual é o nível
apropriado de complexidade para tais políticas? Políticas adaptáveis extremamente simples,
que coletam pouca informação sobre o estado do sistema e que utilizam esta informação de
uma maneira simplificada, são capazes de melhorar dramaticamente o desempenho de um
sistema. Além disso, o resultado obtido com estas políticas extremamente simples são
próximos àqueles alcançados por políticas muito complexas e que exigem muita informação
sobre o estado do sistema.
Exemplo: Requisitos de um Algoritmo de Balanceamento de Carga para Sistemas de
Realidade Virtual Distribuídos (Second Life), WOW (MMORPG).
É necessário que o algoritmo de balanceamento de carga seja fisicamente distribuído,
para que não insiramos um novo gargalo no sistema de realidade virtual, e assíncrono, pois
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 34
as sincronizações dos servidores exigidas por um algoritmo síncrono impossibilitam seu uso
em um sistema de tempo real como este que estudamos. O algoritmo a ser proposto também
deve ser adaptável, uma vez que o número de clientes no sistema varia com o tempo, isto é,
clientes podem entrar e sair do ambiente virtual a qualquer instante. Supondo um algoritmo
que seja ativado quando o número de clientes em um servidor ultrapassar um determinado
limiar (threshold), este limiar não poderá ser o mesmo quando no sistema existirem 100 ou
1000 clientes. O sistema de balanceamento de carga deve ser cooperativo, para evitar que
decisões tomadas por um único servidor atrapalhe o desempenho dos demais servidores.
Acima de tudo, o sistema de balanceamento de carga deve possuir políticas bem
simples que necessitem de informações que possam ser facilmente colhidas, para que o
balanceamento possa ser realizado de forma dinâmica e em tempo real, inserindo o mínimo
de sobrecarga no sistema de realidade virtual.
Outras Questões
• Web Farm versus Web Garden (servidor multiprocessado).
• Cluster (Web): Sessões no Banco versus Middleware (ip fixo).
o Microsoft Sharepoint / NLB (Windows Server 2003, cluster NLB)
o Conceito de “afinidade” (sticky session)
o Espelhamento
o Evita erros intermitentes, já que a sessão fica sempre na mesma máquina
servidora. Senão “funciona, não-funciona” (problema no cliente).
o Criação de um novo IP para o “cluster”.
o Tabela NAT
o Cookies/Expiração – timeout da sessão
o Sessão:
� In-proc (sticky)
� Out-proc
� DB
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 35
Exercícios
1. Nos sistemas que visam atender a milhares de usuários simultaneamente, os
servidores podem facilmente se tornar gargalos do sistema. Além disso, se o
sistema não for cuidadosamente planejado, ele poderá ter sua escalabilidade
reduzida. Uma técnica utilizada para melhorar a escalabilidade de sistemas
distribuídos é o balanceamento de carga entre os servidores do sistema.
o Se, na sua equipe de trabalho, você fosse o arquiteto responsável pelo
projeto/configuração do algoritmo de balanceamento de carga a ser
utilizado em conjunto com o sistema de informação, quais seriam os
requisitos que você consideraria indispensáveis ao algoritmo? Justifique
sua resposta.
o Quais problemas poderiam surgir se você escolhesse utilizar uma política
de transferência baseada num limiar (threshold) fixo? Durante o projeto
de um algoritmo de balanceamento de carga, é natural pensarmos que
utilização de políticas de escalonamentos complexas e baseadas em
informações detalhadas é mais vantajosa que a utilização de políticas de
escalonamento mais simples e baseadas em pouquíssimas informações.
Qual sua opinião sobre esta questão?
2. Defina Balanceamento de Carga e o que motiva sua implementação.
3. Compare Web Farm com Web Garden.
4. Que recursos podem ser compartilhados através do balanceamento de carga?
5. Que considerações precisamos ter ao escalar horizontalmente uma web
application?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 36
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 37
Aula 5 – Algoritmos Distribuídos
Introdução
Escalabilidade: Um sistema distribuído deve permitir a expansão em termos do número
de usuários e recursos e, mesmo assim, manter a performance relativa de atendimento a
serviços do usuário.
A maioria dos sistemas distribuídos atuais é projetada para trabalhar com poucas
centenas de processadores. Atualmente soluções que funcionam com 200 máquinas falham
miseravelmente se aplicadas a 200.000 máquinas.
Exemplo de um sistema que deve possuir escalabilidade: a PTT (Post Telephone and
Telegraph Administration) francesa pretendia instalar um terminal em cada residência e ponto
comercial da França por volta de 1995. Estes terminais seriam utilizados para acesso a base
de dados de telefone (lista telefônica) e também como correio eletrônico, por cerca de 50
milhões de habitantes.
Para implementação de um sistema distribuído deste porte deve-se evitar:
Centralização de Componentes (arquitetura monolítica, gargalo) – ter um único servidor de
correio para 50 milhões de usuário não é uma boa idéia; Centralização de tabelas (orkut.com)
– uma única tabela possui uma imensa vulnerabilidade a falhas; Centralização de Algoritmos
(redundância) – a falha em uma máquina arruína o algoritmo. Todas as máquinas têm que ter
informação completa sobre o estado do sistema.
Breve Histórico
Apareceu na década de 60 dentro do contexto de Sistemas Operacionais. A motivação
foi a criação de unidades de hardware denominadas canais ou dispositivos de controle. Estes
dispositivos funcionam independente de um processador de controle e podem fazer operações
de E/S concorrentemente com a execução de um programa.
Um canal (hardware) comunica-se com o processador central através de uma
interrupção (≠ exceção). Com a introdução dos canais, partes de um programa poderiam
funcionar de forma imprevisível. Logo após o aparecimento dos canais, foram desenvolvidas
as máquinas multiprocessadas. Estas máquinas permitem que aplicações diferentes sejam
executadas em processadores diferentes ao mesmo tempo. Permite também que uma
aplicação possa ser executada mais rapidamente se puder ser reescrita de forma a utilizar
múltiplos processadores.
Perguntas: Como sincronizar as atividades de processos concorrentes? Como utilizar
múltiplos processadores para que uma aplicação seja executada mais rapidamente?
Resposta... Algoritmos Distribuídos: Algoritmos que foram desenvolvidos para serem
executados em muitos processadores “distribuídos” em uma grande área geográfica.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 38
Atualmente, o termo cobre algoritmos que são executados em redes locais e em
multiprocessadores de memória compartilhada.
Características dos Sistemas Distribuídos
• compartilhamento de recursos: um sistema distribuído deve permitir o
compartilhamento eficiente de recursos físicos e lógicos;
• abertura: um sistema distribuído deve pertencer à classe de sistemas abertos
(OPENNESS), permitindo sua “estensibilidade” (é fácil estender e alterar o
sistema?);
• concorrência: um sistema distribuído deve possuir algoritmos e técnicas eficientes
para o escalonamento de processos concorrentes (balanceamento de carga);
• escalabilidade: um sistema distribuído deve permitir a expansão em termos do
número de usuários e recursos e, mesmo assim, manter a performance relativa de
atendimento a serviços do usuário;
• tolerância a falhas: um sistema distribuído deve possuir estratégias para tolerar
falhas em algum(uns) de seu(s) componente(s) e manter o provimento de serviços
ao usuário final;
• transparência: um sistema distribuído deve ser transparente ao usuário final, ou
seja, o usuário deve executar operações remotas como se estive executando-as na
sua máquina (local).
Dentre estas características, iremos falar mais especificamente da concorrência –
obtida através de algoritmos distribuídos.
Cenário-Exemplo: Vários carros desejam ir de um ponto A a um ponto B.
• Eles podem competir por espaços em uma mesma estrada (A) ou acabam
seguindo uns aos outros ou competindo por posições.
• Ou poderiam andar em vias paralelas (B), desta forma chegando quase que ao
mesmo tempo sem invadir a via do outro.
• Ou poderiam trafegar em rotas diferentes (C) usando estradas separadas.
Ou seja: (A) 1 processador (time slice), ou (B) múltiplos processadores, ou (C)
processadores distribuídos (clusters ou grids).
A B C
Recursos independentes
(acostamento).
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 39
Computação Concorrente
Existem múltiplas tarefas a serem feitas. (carros em movimento). Cada tarefa pode ser
executada: uma de cada vez em um único processador (uma única estrada); em paralelo em
múltiplos processadores (pistas em uma estrada); ou, em processadores distribuídos
(estradas separadas). Como elas serão executadas?
Características: Um programa concorrente contém dois ou mais processos que
trabalham juntos para executar uma tarefa. Cada processo é um programa seqüencial.
Programa seqüencial � único thread de controle. Programa concorrente � múltiplos threads
de controle – onde thread é um “fio” de execução.
Comunicação
Os processos em um programa concorrente trabalham juntos comunicando-se entre si.
A comunicação pode ser feita através de: variáveis compartilhadas, troca de mensagens
(loopback). Independente da forma de comunicação, os processos precisam sincronizar-se:
exclusão mútua (seções críticas), sincronização condicional.
Interprocess Synchronization (Windows): Multiple processes can have handles to the
same event, mutex, semaphore, or timer object, so these objects can be used to accomplish
interprocess synchronization. The process that creates an object can use the handle returned
by the creation function (CreateEvent, CreateMutex, CreateSemaphore, or
CreateWaitableTimer). Other processes can open a handle to the object by using its name, or
through inheritance or duplication.
Mutex: 1 or 0 (in use, available) = usually one resource.
Semaphore: available counters (pools) = a set of resources.
Synchronized Methods: in JAVA, to make a method synchronized, simply add the
synchronized keyword to its declaration:
public class SynchronizedCounter {
private int c = 0;
// synchronized = mutex
public synchronized void increment() {
c++;
}
public synchronized void decrement() {
c--;
}
public synchronized int getContador() {
return c;
}
}
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 40
Or in (Microsoft) C#.net
using System;
using System.Runtime.CompilerServices;
using System.Threading;
class Program
{
public static void Main()
{
Sync s = new Sync();
for (int i = 1; i <= 2; i++)
new Thread(new ParameterizedThreadStart(s.Do)).Start(i);
Console.ReadLine();
}
}
class Sync
{
[MethodImpl(MethodImplOptions.Synchronized)]
public void Do(object state)
{
int j = (int)state;
for (int i = 1; i <= 10; i++)
Console.WriteLine("{0} - {1}", j, i);
}
}
It is not possible for two invocations of synchronized methods on the same object to
interleave. When one thread is executing a synchronized method for an object, all other
threads that invoke synchronized methods for the same object block (suspend execution)
until the first thread is done with the object.
Aplicações: processamento de informações distribuídas; computação científica; controle
de processos de tempo real.
Taxonomia
• Método de comunicação entre processos: memória compartilhada, mensagens
ponto-a-ponto, difusão de mensagens (broadcast) e chamadas remotas a
procedimentos (RPC).
• Modelo de Execução (timing model): completamente síncronos, completamente
assíncronos, parcialmente síncronos.
• Modelo de falha: hardware completamente confiável ou pode-se admitir alguma
falha. Na presença de falha: o processo pode parar com ou sem aviso; pode
falhar brevemente; ou pode apresentar falhas graves e o sistema funcionar de
forma arbitrária. Também podem ocorrer falhas na comunicação: perda ou
duplicação de mensagens.
• Problemas abordados: alocação de recursos, comunicação, consenso entre
processadores distribuídos, controle de concorrência em bancos de dados,
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 41
detecção de deadlock, instantâneos globais (global snapshots), sincronização, e
implementação de vários tipos de objetos.
Características
Apresentam um alto grau de incerteza e mais independência de atividades, entre elas:
número de processadores desconhecido; topologia de rede desconhecida; entradas
independentes em diferentes locais; vários programas sendo executados de uma só vez,
começando em tempos diferentes, e operando a velocidades diferentes; não-determinismo
dos processadores; tempos de envio de mensagens incertos; desconhecimento da ordenação
das mensagens; falhas de processadores e comunicação.
Motivação: permitir iteração entre usuários; compartilhamento de recursos/dados e
serviços; em potencial: desempenho melhor, disponibilidade maior. Software tem que estar
distribuído, controle deve estar distribuído.
Requer nova forma de programação/projeto de algoritmos que levam em conta:
paralelismo e não-determinismo; controle descentralizado; atomicidade de ações; tomada de
decisão baseada em informação (parcial) sobre os dados do sistema; otimização do número
de mensagens a serem trocadas; levar em conta a possibilidade de falhas.
Outras Questões
• Recomendação as Sun: Não criar threads “manualmente” dentro do container.
Case IFV.
• Sintaxe Java: fio = new Thread(<objeto>);
• Arquitetura “desconectada”: Quantas licenças para 47 usuários?
• Java/Threads:
o There is one thread per call stack.
o In some JVMs, the Java threads are actually mapped to native OS threads.
o public void run(){} // the new call stack always begin by invoking run();
o Extend the java.lang.Thread class (or)
o Implement the Runnable interface.
o Every thread of execution begins as an instance of class Thread.
o myThread t = new MyThread();
o myRunnable r = new MyRunnable(); Thread t = new Thread (r);
o Once the start() method is called, the thread is considered to be alive. A
thread is considered dead after the run() method completes.
o Example: t.start(); (from new state to runnable state)
o For any group of started threads, order is not guaranteed by the
scheduler.
o There is a way to start a thread but tell it not to run until some other
thread has finished – join() method.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 42
Exemplo:
No exemplo SimplesThread2 a classe Escrita implementa a interface Runnable.
Qualquer classe que implementar a interface Runnable deve ter a descrição do método run().
class Escrita implements Runnable {
private int i;
public void run() {
while(true)
System.out.println(“Número: ”+ i++);
}
}
public class SimplesThread2 {
public static void main(String[] args) {
Escrita e = new Escrita(); //Cria o contexto de execução
Thread t = new Thread(e); //Cria a linha de execução
t.start(); //Ativa a thread
}
}
A classe SimplesThread2 cria o contexto de execução da thread no momento que cria uma instância de um objeto Runnable, que no caso é o objeto Escrita. Escrita e = new Escrita(); //Poderia ser Runnable e = new Escrita();
Para criar uma linha de execução, basta criar a thread, fornecendo o contexto (o local onde há o método run da thread). Thread t = new Thread(e);
O início da thread propriamente dito ocorrerá com o método start().
Exercícios
1. Relacione Escalabilidade com a arquitetura monolítica.
2. Qual a diferença entre escalabilidade vertical e escalabilidade horizontal?
3. O que é interprocess synchronization?
4. Qual a diferença entre mutex e semaphore?
5. O que faz a palavra-chave “synchronized” em um método Java?
6. Qual a diferença entre “exceção” e “interrupção”.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 43
7. Como sincronizar as atividades de processos concorrentes? Como utilizar
múltiplos processadores para que uma aplicação seja executada mais
rapidamente?
8. Quais as principais motivações para a utilização de algoritmos distribuídos?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 44
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 45
Aula 6 – Banco de Dados Distribuídos
Introdução
Banco de dados distribuído (BDD) é uma coleção de várias Base de Dados logicamente
inter-relacionadas, distribuídas por uma rede de computadores. Existem dois tipos de banco
de dados distribuídos, os homogêneos e os heterogêneos. Os homogêneos são compostos
pelos mesmos bancos de dados, já os Heterogêneos são aqueles que são compostos por mais
de um tipo de banco de dados.
Num banco de dados distribuído os arquivos podem estar replicados (cópia) ou
fragmentados, esses dois tipos podem ser encontrados ao longo dos nós do sistema de
BDD's. Quando os dados se encontram replicados, existe uma cópia de cada um dos dados
em cada nó, tornando as bases iguais (ex: tabela de produtos de uma grande loja). Já na
fragmentação, os dados se encontram divididos ao longo do sistema, ou seja a cada nó existe
uma base de dados diferentes se olharmos de uma forma local, mas se analisarmos de uma
forma global os dados são vistos de uma forma única, pois cada nó possui um catálogo que
contém cada informação dos dados dos bancos adjacentes.
A replicação dos dados pode se dar de maneira síncrona ou assíncrona. No caso de
replicação síncrona, cada transação é dada como concluída quando todos os nós confirmam
que a transação local foi bem sucedida. Na replicação assíncrona, o nó principal executa a
transação enviando confirmação ao solicitante e então encaminha a transação aos demais
nós.
Exemplo: Cenário de uma rede lojista, catálogo de produtos replicado, pedidos
fragmentado.
Considerações Importantes
Cuidados com banco de dados distribuídos devem ser tomados para assegurar o
seguinte:
• A distribuição é transparente — usuários devem poder interagir com o sistema
como se ele fosse um único sistema lógico. Isso se aplica ao desempenho do
sistema, métodos de acesso, entre outras coisas.
• Transações são transparentes — cada transação deve manter a integridade do
banco de dados dentre os múltiplos bancos de dados. Transações devem
também ser divididas em subtransações, cada subtransação afetando um
sistema de banco de dados...
Vantagens de bancos de dados distribuídos
• Reflete a estrutura organizacional — fragmentos do banco de dados estão
localizados nos departamentos que se relacionam com os dados que estes
persistem.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 46
• Autonomia Local — um departamento pode controlar seus dados (já que é o
mais familiarizado com estes).
• Maior disponibilidade — uma falha em um banco de dados afetará somente um
fragmento, ao invés do banco de dados inteiro.
• Melhor performance — os dados estão localizados próximo do local de maior
demanda e os sistemas de banco de dados por si só são paralelizáveis,
permitindo carregar no banco de dados para o balanceamento entre servidores
(a elevada carga em um módulo do banco de dados não irá afetar os outros
módulos de banco de dados em um banco de dados distribuído).
• Econômico — custa menos criar uma rede de pequenos computadores com o
mesmo poder que um único computador maior.
• Modularidade — sistemas podem ser modificados, adicionados ou removidos do
banco de dados distribuído sem afetar os outros módulos (sistemas).
• Escalabilidade
Desvantagens de banco de dados distribuídos
• Complexidade — trabalho extra deve ser feito pelos DBAs para garantir que a
natureza da distribuição do sistema seja transparente. Trabalho extra deve ser
feito para manter sistemas múltiplos diferentes, ao invés de um único grande.
Design de banco de dados extra deve também ser feito para levar em conta a
natureza desconectada do banco de dados - por exemplo, joins tornam-se
proibitivamente caros quando são rodados entre múltiplas plataformas.
• Implantação mais cara — o aumento da complexidade e uma infraestrura mais
extensa significa custo extra de trabalho
• Segurança — fragmentos de banco de dados remotos devem ser seguros e,
como eles não são centralizados então os lugares remotos também devem ser
seguros. A infraestrutura também deve ser segura (por exemplo, pela
encriptação dos links de rede entre os lugares remotos).
• Difícil de manter a integridade — em sistemas distribuídos, reforçar a integridade
ao longo de uma rede pode exigir demais dos recursos da rede para ser viável
(consistência).
• “Inexperiência” — pode ser difícil trabalhar com banco de dados distribuídos e
como é uma área relativamente nova ainda não há tantos casos (ou
experiências) práticos de seu uso disponíveis como exemplo.
• Falta de padrões – ainda não há metodologias e ferramentas para ajudar
usuários a converter um SGBD centralizado para um SGBD distribuído.
• Design do banco de dados mais complexo – além das dificuldades normais, o
design de um banco de dados distribuídos tem que considerar a fragmentação
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 47
dos dados, alocação dos fragmentos em lugares específicos e a replicação de
dados.
Arquitetura de um banco de dados distribuídos em Oracle
Um banco de dados distribuídos é um conjunto de banco de dados armazenados em
vários computadores que tipicamente aparecem para uma aplicação como um simples banco
de dados. Consequentemente uma aplicação pode simultaneamente acessar e modificar os
dados nos vários banco de dados da rede. Cada banco de dados no sistema é controlado pelo
seu próprio servidor de Oracle local mas coopera para manter a consistência do banco de
dados global.
1. Clientes e Servidores
Um servidor de banco de dados é um software Oracle que gerencia um banco de dados,
e um cliente é uma aplicação que solicita informação para um servidor. Cada computador no
sistema é um nó. Um nó em um sistema de banco de dados distribuídos age como um cliente,
um servidor, ou ambos dependendo da situação.
2. A Rede
Para criar um link entre banco de dados individuais de um sistema de banco de dados
distribuídos, um rede é necessária.
2.1 Net8
Todo banco de dados Oracle em um sistema de banco de dados distribuídos usa um
software de rede da Oracle, o Net8, para facilitar a comunicação através da rede. Além de o
Net8 conectar clientes e servidores que operem em diferentes computadores de uma rede,
ele também permite servidores de banco de dados que comunicarem através da rede a
suportar transações remotas e distribuídas através de um banco de dados.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 48
Net8 deixa transparente a conectividade que é necessária para transmitir requisições
SQL e receber dados de aplicações que usem o sistema.
3. Nome de um Banco de dados.
Cada banco de dados em um banco de dados distribuídos é distinto dos outros bancos
de dados em um sistema e tem o seu próprio nome do banco de dados global dentro da rede.
4. Links entre Banco de dados Oracle.
Para facilitar uma requisição de uma aplicação em um sistema de banco de dados
distribuídos, Oracle usa database links. Um database link define um caminho de comunicação
de uma mão de uma banco de dados Oracle para outro.
Database link são essencialmente transparentes para os usuários de um sistema de
banco de dados distribuídos, porque o nome de um database link é o mesmo que o nome
global de uma banco de dados que une os dois pontos.
5. Transparência em um sistema de banco de dados distribuído.
Com um mínimo de esforço, você pode fazer a funcionalidade de seu sistema de banco
de dados distribuídos transparente para usuários que trabalham com o sistema. O objetivo da
transparência é fazer um sistema de banco de dados distribuídos aparecer como um simples
banco de dados.
5.1 Transparência local:
Um sistema de banco de dados distribuídos Oracle tem características que permitem
desenvolvedores de aplicações e administradores esconderem a localização física de objetos
de um banco de dados para aplicações e usuários. Transparência local existe quando um
usuário pode universalmente referir-se a um objeto no banco de dados, tal como uma tabela,
sem se preocupar com o nó ao qual uma aplicação conecta-se. Mais tipicamente,
administradores e desenvolvedores usam sinônimos para estabelecer transparência de
localização para tabelas e objetos suportados no esquema da aplicação. Por exemplo, a
seguinte sentença cria sinônimos em um banco de dados para tabelas em outros bancos de
dados (remoto).
CREATE PUBLIC SYNONYM emp FOR [email protected]_auto.com
CREATE PUBLIC SYNONYM dept FOR [email protected]_auto.com
Agora, ao invés de acessar as tabelas remotas como a query abaixo:
SELECT ename, dname FROM [email protected]_auto.com e,
[email protected]_auto.com d,
WHERE e.deptno = d.deptno;
Uma aplicação pode emitir uma query muito mais simples que não precisar saber a
localização das tabelas remotas.
SELECT ename, dname FROM emp e, dept d WHERE e.deptno = d.deptno;
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 49
Transações Distribuídas
Transações (begin, commit, rollback) são serviços que têm como objetivo permitir
integridade dos dados e consistência. O programador vê sua transação como um programa
seqüencial, mesmo que ele possa executar concorrentemente com outros programas ou que
ocorram falhas durante sua execução. Normalmente uma transação deve atender às quatro
propriedades ACID: Atomicidade, Consistência, Isolamento (for Update), Durabilidade.
O uso de transações em sistemas distribuídos servirá para endereçar dois problemas:
concorrência (evitar condições de corrida), falhas (garantir consistência dos dados).
Modelo de Transações Distribuídas: Transações podem acessar dados em vários nós.
Cada nó tem um gerente local de transações, responsável por: Manter log para recuperação;
Coordenar a execução concorrente das transações executando no nó.
Cada nó tem um coordenador de transações, responsável por: Iniciar a execução de
transações que são originadas no nó. Distribuir subtransações para nós apropriados.
Coordenar a terminação de transações originadas no nó, o que resulta na transação ser
validada em todos os nós ou desfeita em todos os nós.
Exemplo da falta de transações: Transferência bancária on-line. Operação feita em 2
passos: saque/depósito. Se a conexão cair após o saque, ocorre o débito na primeira, não
ocorre o crédito na segunda (dinheiro some).
Transações Distribuídas: Uma transação é dita distribuída quando múltiplos servidores
estão envolvidos em uma transação tanto pela requisição
direta do cliente, quanto indiretamente via servidor. Cada
transação distribuída pode ser construída de duas formas
diferentes: transação distribuída simples, transação
distribuída aninhada.
Transações Distribuídas Simples: O cliente invoca
todos os servidores necessários para completar a
transação requisitada...
Transações Distribuídas Aninhadas: O cliente
requisita uma transação ao servidor que por sua vez invoca outros servidores e assim
sucessivamente... Melhor desempenho...
Implementação: Como as transações são
implementadas, de modo a garantirem a
consistência? Dois métodos são apresentados:
Shadow Versions: uma cópia dos dados a
serem alterados é feita. Nessa cópia que as
alterações são efetuadas. Ao fim da transação essa
Requisições são
feitas
seqüencialmente
Podem executar
simultaneamente
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 50
cópia substitui os dados antigos.
Writeahead Log (intention list): antes de um dado ser modificado, são gravadas
informações em um log (qual a transação está efetuando alterações, os dados que estão
sendo alterados, os valores antigos e novos). Após o log ter sido gravado as alterações são
feitas.
Protocolos Atômicos de Confirmação: Objetiva garantir atomicidade a uma transação
distribuída. Ou todas as operações são efetuadas ou todas são abortadas; Dois protocolos
apresentados: one-phase atomic commit protocol, two-phase atomic commit protocol.
One-Phase Protocol: Coordenador comunica os participantes quando confirmar ou
abortar. Desvantagem: não permite que servidores abortem uma transação, por exemplo, no
caso de ocorrência de uma falha ou deadlock.
Two-Phase Protocol: Garante que todos os participantes da transação distribuída
possam confirmar ou abortar sua transação. Usado quando o cliente envia um
closeTransaction(). Se o cliente envia um abortTransaction(): o coordenador informa todos os
participantes que eles devem abortar a transação. Duas fases: Fase de Votação, Fase de
Decisão.
Fase de Votação: O coordenador abre a votação. Cada servidor (coordenador ou
participante) “vota” se a transação será confirmada ou abortada. Fase de Decisão: O
coordenador informa a todos os participantes sobre a decisão. Se todos os participantes
aceitam: transação pode ser confirmada; caso contrário é abortada.
Problemas: Se o coordenador cair os dados ficarão bloqueados até que o coordenador
esteja novamente disponível. “presumed abort”: se o coordenador cair antes de um
participante estar preparado, o participante pode abortar sem esperar pela sua volta.
Esperas Longas: Coordenador a espera dos votos dos participantes. Participante
aguardando o canCommit?(T) do coordenador. Participante aguardando o doCommit(T) or
abortCommit(T) do coordenador. Participante envia um getDecision(T) para o coordenador.
••canCommit?(transcanCommit?(trans))--> Yes / No> Yes / No
••doCommit(transdoCommit(trans))
••doAbort(transdoAbort(trans))
••haveCommitted(transhaveCommitted(trans, participant), participant)
••getDecision(transgetDecision(trans) ) --> Yes / No> Yes / No
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 51
Complexidade do Algoritmo: exige no mínimo 3(N-1) mensagens para completar a
transação.
Controle de Concorrência: Objetivo é garantir a propriedade de isolamento (locks).
Garantir que os dados continuem consistentes depois de acessados por transações
concorrentes. Normalmente, implementado como um algoritmo de duas fases: bloqueio de
duas fases (two-phase locking). A aquisição dos locks sobre os dados é feita de modo que
operações de diferentes transações ativas possam se intercalar. Pode ser feito por outras
maneiras: Timestamps, Controle de Concorrência Otimista.
Um lock (bloqueio) é um mecanismo para controle de acessos concorrentes a um
mesmo item de dados. Dados podem ser bloqueados em dois modos: Exclusivo (E). Dado
pode ser escrito ou lido; Compartilhado (C). Dado pode ser apenas lido. Requisições de locks
(lock-E ou lock-C) são feitas ao gerente de controle de concorrência. Transação fica suspensa
até que lock seja concedido. Granularidade: campo, tupla, tabela, banco, página.
Two-phase locking: O algoritmo two-phase locking possui as seguintes fases: 1ª fase:
obtenção de locks, 2ª fase: liberação de locks. Uma vez que uma transação tiver liberado um
lock qualquer, a transação não poderá adquirir nenhum novo lock pois a primeira liberação
indica o término da primeira fase
Strict two-phase locking: locks adquiridos são mantidos até que a transação seja
cancelada ou confirmada. Vantagem: impede os “cascading aborts”. Desvantagem:
deadlocks.
Deadlock:
Dependendo da ordem dos bloqueios podem ocorrer referências cíclicas e deadlocks.
Há a necessidade de utilizar algoritmos para detectar e eliminar deadlocks. Construção de
grafos wait-for globais.
Exemplo de deadlock distribuído:
Write(B) at Y locks B
Read(A) at X waits for T
Write(A) at X locks A
Read(B) at Y waits for U
UT
Write(B) at Y locks B
Read(A) at X waits for T
Write(A) at X locks A
Read(B) at Y waits for U
UT
X, Y: Servidores
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 52
Grafo Wait-for (WFG): Se uma transação Ti espera por outra transação Tj para liberar
um lock em uma entidade, então Ti -> Tj está no WFG.
Recuperação de deadlocks: Quando deadlock é detectado deve-se procurar uma vítima
(transação que será desfeita). Procurar selecionar a vítima que causará menor custo; para
evitar starvation, incluir número de rollbacks no custo. Extensão do rollback: Total (aborta a
transação e a reinicia); Parcial (efetuar rollback somente até o ponto onde deadlock é
quebrado).
Conclusão: Transações garantem integridade dos dados e consistência. Atomicidade:
garantida pelos protocolos atômicos. Consistência: shadow versions, writeahead log.
Isolamento: Controle de Concorrência. Problemas a serem tratados: Deadlocks, Falha nos
servidores.
Outras Questões
• Transações distribuídas através de “middleware” ou banco de dados distribuídos.
• You could use the Java Transaction API (JTA) to access the Java Transaction
Service (JTS) programmatically, but that’a a heck of alot of work.
• Transação é um serviço de infra-estrutura e, como tal, deveria ficar a cargo do
servidor de aplicação/container JEE (princípio da inversão de controle).
• Estratégia (performance) para inclusão/atualização:
• UPDATE...
• Se falhou por erro “100”...
• INSERT (postura “otimista”)... Ao invés de Select/Exists
Insert/Update (postura “pessimista”).
Exercícios
1. O que são transações distribuídas?
2. Defina as propriedades ACID de uma transação.
3. Como podem ser implementadas transações distribuídas?
4. Como funciona o protocolo atômico de confirmação de duas fases?
5. Compare lock e deadlock.
6. Como um sistema se recupera de um deadlock? Como é feita a escolha da
transação a ser cancelada?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 53
7. O que são Database links e Sinônimos? Como estes recursos podem ajudar em
uma solução de Banco de Dados distribuídos?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 54
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 55
Aula 7 – Tolerância a Falhas em Ambiente Distribuído
Introdução
O contínuo crescimento da utilização de Redes de Computadores levou alguns
pesquisadores deste campo da informática a desenvolverem aplicações que possuíssem
módulos capazes de interagir entre si, mesmo estando em diferentes computadores. Estas
aplicações foram chamadas de Sistemas Distribuídos. A principal finalidade destes sistemas
era de que estes módulos distribuídos fossem executados pelos usuários de forma
transparente, ou seja, não interessava qual o módulo estava respondendo às suas requisições
e muito menos onde ele estava localizado.
A partir deste conceito de transparência, começaram a surgir padronizações de
middlewares que dessem suporte à gerência de sistemas distribuídos. Mas, levando em
consideração que estes módulos estão localizados em meios físicos susceptíveis a falhas, não
há garantia que a execução de um determinado processo chega ao fim.
Diante deste fato de grande relevância para o gerenciamento de sistemas distribuídos,
começaram a surgir técnicas de tolerância a falhas que começaram a fazer parte de alguns
dos padrões de middlewares hoje existentes no mercado.
Tolerância a Falhas: Popularização de serviços Web gera dependências no cotidiano.
Falhas são inevitáveis, mas suas conseqüências devem ser minimizadas. O domínio da área
de tolerância a falhas (TF) auxilia administradores e desenvolvedores de sistemas a avaliar a
relação custo benefício para o seu caso específico e determinar a melhor técnica para seu
orçamento.
Mitigar Riscos
Exemplo: backup consome espaço e tempo enquanto redundância de equipamentos
(hotswap/$$$) e espelhamento de discos exige investimentos (praticamente) sem afetar o
desempenho.
O que é um Sistema Tolerante a Falhas? É um sistema que continua provendo
corretamente os seus serviços mesmo na presença de falhas (de hardware ou de software).
Defeitos não são visíveis para o usuário, pois o sistema detecta e mascara (ou se recupera)
defeitos antes que eles alcancem os limites do sistema (ponto de fuga da especificação).
O que é Tolerância a Falhas? É um atributo que habilita o sistema para ser tolerante a
falhas. É o conjunto de técnicas utilizadas para detectar, mascarar e tolerar falhas no
sistema.
Observação: A indústria não aceita bem o termo TF, preferindo os termos: Sistemas
redundantes (visa confiabilidade), alta disponibilidade (visa disponibilidade – 99.999%).
Tentativa de unificação com “segurança de funcionamento” confundiu com aspectos de
segurança. Atualmente um termo mas amplo, dependabilidade, está se tornando popular.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 56
Definição de Dependabilidade: Uma propriedade de um sistema computacional, tal
como funcionalidade, usabilidade, desempenho e custo. Dependabilidade diz respeito à
habilidade para entregar um serviço comprovadamente confiável (trust), ou seja, habilidade
do sistema para evitar defeitos inaceitáveis para seus usuários.
Possíveis Causas de Falhas: descuidos na especificação (especificação incorreta de
algoritmos, arquiteturas ou projetos de HW e SW), descuidos na implementação (codificação
equivocada ou utilização de componentes de baixa qualidade), defeitos de componentes
(imperfeições na fabricação, ou defeitos randômicos), distúrbios externos (radiações,
interferência eletromagnética), lógica maliciosa (falhas causadas por cavalos de tróia,
programas ativados por tempo ou lógica – bombas lógicas, falhas causadas por vírus ou
worms/backdoor), intrusão (exploração de falhas internas ou externas/hackers), projeto de
software mal estruturado (podem levar ao envelhecimento do software/entropia – inchaço ou
esvaziamento da memória, bloqueio de arquivos, fragmentação, etc.).
Atributos da Dependabilidade: Disponibilidade – diz respeito à média de tempo
disponível para acesso, Confiabilidade – diz respeito à continuidade da entrega de serviço
correto, Integridade – impedimento de alterações de estado impróprias, Segurança (safety) –
diz respeito a garantias de não haver defeitos catastróficos ao usuário ou ambiente,
Confidencialidade – impedimento de acesso indevido, Mantenabilidade – habilidade para
reparo e modificações eficientes, Segurança (security) – proteção contra acessos, ou controle,
não autorizados ao estado do sistema, Testabilidade – facilidade para testar o sistema (ponto
de teste, testes automatizados).
Tolerância a Falhas em SD: SD deveriam ser tolerantes a falhas e sistemas tolerantes a
falhas deveriam ser distribuídos. SD têm redundância intrínseca que pode ser utilizada para
TF. Incluem múltiplos processadores independentes que podem incrementar o desempenho
do sistema através de paralelismo, reduzindo custos da TF. Contém múltiplos componentes, o
que incrementa o risco de defeitos, requerendo o uso de técnicas de TF.
Implementar SDTF é difícil por muitas razões: Sincronização (Deve evitar conflitos e
deadlocks), Detecção de Falhas/Defeitos (Deve ter uma visão consistente de quais
componentes falham e em que ordem), Recuperação (Deve prover mecanismos de
recuperação para atuarem após defeitos e/ou recuperações), Consistência (Deve manter uma
visão consistente do sistema independente das falhas e recuperações).
Solução
Como estruturar um sistema para suportar TF? Diferentes paradigmas de estruturação:
Redundância de hardware (hot swap), Redundância de informação (backup online realtime),
Redundância temporal (refazer computações/aviação civil, mísseis), Redundância de software
(clusters).
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 57
Síntese da TF em SD ou SDTF: Redundância é o requisito chave para implementar
qualquer Sistema Tolerante a Falhas. Nós necessitamos de técnicas de gerenciamento de
replicação para facilitar a implementação de Sistemas Tolerantes a Falhas. As características
de Tolerância a Falhas devem ser transparentes aos programadores e usuários do Sistema
Tolerante a Falhas. Tolerância a Falhas incrementa a complexidade do sistema. Implementar
sistemas paralelos e/ou distribuídos como Tolerante a Falhas é uma tarefa difícil. Há
necessidade por ferramentas de suporte à implementação de sistemas distribuídos TF.
Outras Questões
• Estudo de Caso: eBay – “Staying Online Always” (disponível no endereço:
http://www.icmrindia.org/free%20resources/casestudies/EBAY%20IT1.htm)
o In January 2001, eBay, the largest online auctioneer (leiloeiro) in the
world, saw a major outage (interrupção) of its website, which lasted 11
hours. Company sources blamed the mishap (contra-tempo) on some
problems with the storage hardware and database software. eBay CEO,
Meg Whitman, blamed both the primary and backup infrastructure of the
website. To add to the company's problems, it had to delay replacing
some of its hardware due to the busy holiday season.
o (...) In September 2001, eBay went on a major software revamp
(“remendo”) to improve its site availability and make it more dynamic and
interconnected. After reviewing more than 20 vendors, the company
finally opted for IBM and its WebSphere application server and began to
put in place its 'V3' application architecture. eBay also revamped its
server-side application development architecture to support the Java 2
Enterprise Edition (J2EE)13 and Enterprise JavaBeans14.
o The company replaced a C++ 15 object framework that required a lot of
structural programming. Though the C++ environment was more flexible
than Cobol, it couldn't compete with J2EE, which was becoming the de
facto application development framework. J2EE's objects could handle a
much higher level of abstraction than C++. The new applications were
more widely distributed, running across multiple machines (both Windows
and Solaris) and relied on data-dependent routing, which utilized server
cache16 more efficiently. The V3 deployment was phased in slowly. It
began during the fourth quarter of 2001 and was to be completed over the
next 18 months. By December 2001, eBay's IT infrastructure had not only
become flexible enough to handle instant recoding but also sturdy enough
to process more than 800,000 transactions every minute.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 58
• Como implementar TF em aplicações Web? R: Com Web Gardens (único servidor,
com múltiplos processadores), Web Farms (múltiplos servidores).
o A Web farm takes the concept of a Web garden and extends it to multiple
computers.
o Ambos aumentam a escalabilidade e a confiabilidade de aplicações Web.
o Problema: E o Session state (Session Management)? R: They typically
share a common front-end dispatcher to perform load control and
distribute customer requests.
o Soluções: Banco de Dados, Processo em Separado, Middleware
(dispatcher).
• Backup onsite – torres gêmeas.
• Disponibilidade 99.999% - 5 minutos de paradas não previstas ao ano.
Exercícios
1. Explique por que sistemas de informação tendem a ser entrópicos.
2. O que é um sistema tolerante a falhas?
3. Como você definiria “alta disponibilidade”?
4. O que pode causar a falha (por exemplo, indisponibilidade) de um sistema?
5. No contexto de aplicações Web, como fazer a gestão da sessão em um ambiente
clusterizado?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 59
Aula 8 – Segurança em Ambientes Distribuídos
Cenário-Exemplo
Algumas ameaças à segurança dos sistemas distribuídos são óbvias. Por exemplo, na
maioria das redes locais é fácil instalar um programa que obtenha cópias de mensagens
transmitidas entre processos (você pode ser demitido por instalar um programa desses). Um
programa desse tipo pode ser executado em um computador que já está conectado à rede ou
em um que está infiltrado nela, através de um ponto de conexão sobressalente. Outras
ameaças são mais sutis. Um programa pode se instalar como um servidor de arquivos e obter
cópias de informações confidenciais contidas nos dados que os clientes encaminham para
armazenamento.
Sub-net Masking
A subnetwork, or subnet, is a logically visible subdivision of an IP network. The practice
of dividing a single network into two or more networks is called subnetting and the networks
created are called subnetworks or subnets.
All computers that belong to a subnet are addressed with a common, identical, most-
significant bit-group in their IP address. This results in the logical division of an IP address
into two fields, a network or routing prefix and the rest field or host identifier. The rest field is
an identifier for a specific "host" — either a computer, or a device, or specific network
interface on a computer or device.
Motivação
A maioria das falhas de segurança é causada pelo ser humano, e intencionalmente.
Inicialmente os hackers eram adolescentes ou estudantes que participavam de um “jogo”.
Atualmente as falhas de segurança podem representar grandes prejuízos para as empresas.
Os hackers tornaram-se profissionais. Proteger os dados corporativos torna-se questão de
sobrevivência para as empresas.
Desafios
• Transmissão/Armazenamento seguro de informação
o Uso de Criptografia (via hardware/mainframe ou software)
• Outros (Mais Recentes)
o Impedimento de acesso (denial of service - DOS attack)
� Ataque massivo sobre servidores (time-bomb)
o Segurança em Código Móvel
� Como confiar em código vindo do exterior (Internet no
celular/Android Market)?
• Afetar consistência, desempenho, disponibilidade (PSN 2011), etc.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 60
Conceitos Básicos
Os princípios básicos de segurança em sistemas de comunicação compreendem:
• Confidencialidade (criptografia/https) - tem por objetivo proteger a informação
intercambiada prevenindo-a de acessos não autorizados;
• Integridade (checksum) – deve garantir a veracidade da informação protegendo-
a de modificações não autorizadas;
• Autenticidade (certificados) – visa garantir a identidade dos parceiros do
intercâmbio através da autenticação dos usuários;
• Disponibilidade (redundância) – objetiva prevenir interrupções na operação da
rede garantindo a disponibilidade do uso da informação.
Os usuários podem estar interconectados (com as suas aplicações distribuídas) através
de redes abertas, não-confiáveis, que podem ser compartilhadas por outros usuários - os
quais não estão autorizados a acessar determinados sistemas. Assim sendo, é necessário
identificar e autenticar o usuário que solicitar conexão ao sistema, bem como verificar se ele
possui autorização para acessar os recursos solicitados.
A identificação é o processo inicial para verificar se o usuário está cadastrado no
sistema; normalmente essa identificação é realizada através de um user-id (sugestão
email/mensagem de erro “usuário ou senha”). A autenticação é a etapa seguinte na qual o
usuário deverá provar sua identidade. Antigamente este processo era sinônimo de password
(senha), porém atualmente podemos classificar os métodos de autenticação do usuário em
três categorias:
• Algo que o usuário conheça - o sistema indaga por uma informação que o
usuário tenha conhecimento, sendo o caso típico da password;
• Algo que o usuário possua - o sistema solicita a apresentação de algo físico que o
usuário tenha, podendo ser desde um simples cartão magnético, até sofisticados
dispositivos eletrônicos (bancos: iToken, cartões);
• Algo que o usuário seja - esta categoria está relacionada como os sistemas
biométricos que são métodos automatizados para verificar a identidade de uma
pessoa, baseando-se em alguma característica fisiológica ou comportamental.
Cuidados
Processos de onboard/offboard – 900 funcionários, 2.000 contas ativas.
Vulnerabilidade: São erros no projeto ou configuração dos Sistemas Computacionais
que podem ser exploradas para se produzir falhas intencionais ou não.
Ataque: São investidas contra os Sistemas Computacionais para explorar as suas
vulnerabilidades e causar falhas intencionais. Podem assumir varias formas: destruição,
modificação, roubo, revelação da informação ou interrupção de serviços.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 61
Ataque (Taxonomia):
• Personificação: uma entidade faz-se passar por outra.
• Replay: uma mensagem, ou parte dela, é capturada, armazenada e
posteriormente retransmitida.
• Modificação: o conteúdo de uma mensagem é alterado (Query String).
• Recusa ou Impedimento de Serviço (DOS): interrupção de algum serviço
(geração de mensagens em grande quantidade).
• Ataques Internos: um usuário executa uma operação não autorizada para o
mesmo.
• Armadilhas (trapdoor): uma entidade legitima é substituída por outra alterada.
• Cavalos de Tróia: entidade falsa produz o mesmo serviço que a legitima com o
intuito de se camuflar e executa uma operação adicional não autorizada
(“moedas verdes” - Orkut 2010).
• Spoofing: interceptação da comunicação entre dois hosts por um host não
autorizado (arquivo “hosts” = spoofer).
• Sniffing: usa o principio da propagação da mensagem através do meio físico para
“ouvir” todos as mensagens que nele trafegar. Normalmente este tipo de ataque
é usado na preparação de outros ataques.
Intrusão: é o resultado de um ataque bem sucedido. Ameaça: probabilidade potencial
de um Sistema Computacional ser alvo de um ataque. Risco: probabilidade potencial de um
Sistema Computacional ser invadido (Vulnerabilidade X Ameaça).
Políticas de Segurança
Regras e práticas para proteger informações e recursos: Nível (D1 – D4: classificação
de documentos) de sensibilidade da informação; Identidade do usuário.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 62
Política dos 4P: Paranóica: tudo é negado; Prudente: tudo é proibido exceto o que for
explicitamente permitido; Permissiva: tudo é permitido exceto o que for explicitamente
proibido; Promiscua: tudo é permitido.
Propriedades de Segurança de Sistemas: Autenticidade: garantir-se que um usuário é
realmente quem se diz ser e as ações a ele atribuídas tenham sido realmente de sua autoria;
Confidencialidade: usuários autorizados tenham acesso às informações devidas e ninguém
mais; Integridade: garante que um documento autêntico não foi alterando acidentalmente ou
intencionalmente ou que esteja sendo reutilizado sem que seja percebido; Disponibilidade:
continuidade dos seus serviços acessíveis aos usuários autorizados.
Mecanismos de Segurança - Autenticação:
Controle de Acesso: Access Control List - lista com a identificação do usuário ou
processo e suas permissões para cada objeto; Capabilities - lista para cada usuário ou
processo com a identificação do objeto e suas permissões; Access Control Matriz - é uma
matriz onde as linhas são compostas pelos usuários, as colunas por objetos e os elementos
são listas de permissões (Capability X ACL).
Criptografia
Transformar um texto em claro em um texto codificado através de um algoritmo de
criptografia. O método de criptografia é confiável e seguro quando ele é de domínio público:
Criptografia Simétrica: a chave utilizada para criptografar um texto é a mesma para
descriptografá-lo - DES (Data Encryption Standard); Criptografia Assimétrica: a chave para
criptografar uma mensagem é diferente da chave para descriptografá-la - RSA (Rivest,
Shamir e Adleman).
Outros métodos e padrões (Assinatura digital, Messages Digests - MD5, etc.)
Topologias dos Sistemas Seguros - Segurança na Arquitetura TCP/IP: IPv4 não possui
nenhum mecanismo de segurança. Normalmente adicionamos uma camada de segurança,
como o Secure Sockets Layer (SSL): Desenvolvida pela Netscape (RFC 2246), possui
autenticação e criptografia simétrica, fica entre as camadas de Transporte e Aplicação. Já o
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 63
Internet Protocol Version 6 (IPv6) possui segurança – IPSec, espaço de endereçamento IP,
Qualidade de serviço (QoS) – VoIP por exemplo.
O IPv6 é a versão 6 do protocolo IP. O IPv6 tem como objetivo substituir o padrão
anterior, o IPv4, que só suporta cerca de 4 bilhões (4 x 109) de endereços, enquanto que o
IPv6 suporta 3.4 x 1038 endereços. A previsão atual para a exaustão de todos os endereços
IPv4 livres para atribuição a operadores é de Janeiro de 2014, o que significa que a transição
da versão do IPv4 para o IPv6 é inevitável num futuro próximo. O governo dos Estados
Unidos da América determinou que todas as suas agências federais devem suportar o
protocolo IPv6 até 2008.
Circuitos de criptografia: hardware ou software: Physical Circuit Encryption: camadas
Física ou de Enlace, Virtual Circuit Encryption: camada de Aplicação.
Seleção de Trafego: Switches - Melhoram a performance, Anulam ataques tipo Sniffing;
Roteadores ou Switches com suporte a VLANs - Isolam o trafego até o nível de rede, Política
de Segurança especifica para cada subrede. Hub vs. Switch – barramento vs. estrela.
Firewalls, Filtros e Proxies: são softwares que operam em hosts conectados em mais
uma rede. O trafego de entrada e saída deve fluir através do firewall. Apenas o trafego
autorizado deve fluir através do firewall. O firewall deve operar num host que é um Trusted
Computing Bases (TCB). Os firewalls podem ser classificados em filtros e proxies. Nos filtros o
trafego flui através do firewall. Os proxies atuam como intermediários no trafego. Os proxies
possuem sintaxe mais detalhada e
performance inferior.
Zona Desmilitarizada – DMZ. Uma
DMZ ou ainda "Zona Neutra" corresponde
ao segmento ou segmentos de rede,
parcialmente protegido, que se localiza
entre redes protegidas (interna/da
empresa) e redes desprotegidas (Internet)
e que contém todos os serviços e
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 64
informações para clientes ou públicos (por exemplo, servidor de banco de dados do Website).
A DMZ pode também incluir regras de acesso específico e sistemas de defesa de perímetro
para que simule uma rede protegida e induzindo os possíveis invasores para armadilhas
virtuais de modo a se tentar localizar a origem do ataque.
Proteção dos Dados e Serviços - Ações para tornarem os sistemas mais seguros:
Prevenção a ataques, detecção e reação a invasões, tolerância a invasões. Circuitos de
Criptografia; Uso de certificados de autenticidade - Certification Authority (CA);
Gerenciamento de chaves para criptografia simétrica - Key Distribution Center (KDC).
Conclusão
Para construir um sistema distribuído seguro, nós devemos projetar seus componentes
partindo do princípio de que os agentes do sistema (pessoas e programas) não são confiáveis,
até que provem o contrário. No entanto, é impossível produzir um sistema útil considerando
que não há nenhum componente confiável. Assim sendo, o objetivo passa a ser produzir um
sistema no qual um número mínimo de componentes sejam considerados confiáveis. Os
mecanismos de segurança para sistemas distribuídos baseiam-se no uso de três técnicas:
criptografia, autenticação e controle de acesso.
Outras Questões
• Arquitetura Física em Estrela (Hub) vs. Lógica em Barramento - sniffing.
• Hacker (pichador) vs. Cracker.
• Problema dos endereços IP – até videogame tem IP.
• Geralmente as empresas colocam os bancos de dados dos servidores que ficam
publicados na Internet, na DMZ. Por exemplo, o banco de dados da “Intranet”.
• Segurança da Informação:
o Engenharia Social (cuidado com o orkut/comunidades) - enganação,
exploração da confiança das pessoas.
o Phishing (pescaria). Tentativa de obter informações se passando por outra
pessoa (Bradesco, Norton, Paypal).
• Exemplos de Phishing Scam:
o Cobranças de empresas de telefonia celular;
o Inclusão de nome no SERASA; Entrega FEDEX, DHL.
o Assuntos pessoais (mensagens românticas);
o Cancelamento de CPF ou título de eleitor, IR;
o Um novo vírus avassalador descoberto;
o Fotos da sua mulher;
o Fotos minhas, mas não ria;
o Fotos da festa/escola;
o Software para capturar senha (vírus), etc..
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 65
• Chaves Públicas e Privadas
o Criptografia assimétrica ou de chave pública.
o Passo 1: Alice envia sua chave pública para Bob.
o Passo 2: Bob cifra a mensagem com a chave pública de Alice e envia para
Alice.
o Passo 3: Alice recebe e decifra o texto utilizando sua chave privada.
• SQL Injection
o Select *
o From USUARIO
o Where logon = & txtLogon &
o And senha = & txtSenha � caixa de texto � “xpto OR true”
Exercícios
1. Como a arquitetura da rede pode influenciar em um possível ataque por um
sniffer.
2. Explique os conceitos de: confidencialidade, integridade, autenticidade e
disponibilidade.
3. Relacione identificação e autenticação.
4. Qual a diferença entre os tipos de ataques spoofing e sniffing.
5. Qual a principal motivação para a implementação do IPv6?
6. Qual a diferença entre um proxy e um firewall?
7. O que é uma DMZ?
8. O que é phishing scam?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 66
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 67
Aula 9 – Computação em Grade
Histórico
Em 50 anos de inovações, a velocidade dos computadores cresceu em torno e um
milhão de vezes, mas mesmo assim ainda são lentos para poder resolver muitos problemas
científicos.
Para se conseguir resolver problemas complicados eram necessários
supercomputadores, que custavam “rios de dinheiro”. A evolução do hardware chegou a tal
ponto que um computador pessoal tem mais capacidade computacional que alguns
supercomputadores. Com o advento da Internet, o acesso a dados e computadores ficou
muito mais fácil.
A ideia de clusters de computadores foi desenvolvida no começo da década de 80. A
um custo muito menor, poderia se ter o poder de um supercomputador. Apesar do custo
reduzido, toda a infra-estrutura necessária para se montar um cluster grande é cara.
O que é Computação em Grade? Por todo o mundo, muitos recursos computacionais
são desperdiçados. Enquanto uma pessoa deixa seu computador ligado e vai pegar um café,
milhares de ciclos de CPU que poderiam estar sendo usados são perdidos (estado IDLE).
Computação em Grade é compartilhar recursos computacionais com outros usuários.
Os recursos compartilhados não se resumem a ciclos de CPU, podem ser recursos de
armazenagem, utilização de sensores e recursos de rede.
Para que Computação em Grade? Existe realmente um problema específico para
grades, que faça ser necessária a existência de uma tecnologia de grades? O problema existe,
é a coordenação de compartilhamento de recursos e solução de problemas de organizações
virtuais.
O que é uma Organização Virtual (IBM World Community Grid
http://www.worldcommunitygrid.org/)? Chamamos de Organização Virtual quando temos
participantes que desejam compartilhar recursos para poder concluir uma tarefa. Além disso,
o compartilhamento esta além de
apenas troca de documentos, isto pode
envolver acesso direto a software
remoto, computadores, dados,
sensores e outros recursos.
Descrição da Arquitetura de
Grades: O objetivo na definição dessa
arquitetura não é definir todos os
protocolos, serviços e APIs requeridos,
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 68
mas ao contrário identificar requisitos para classes genéricas de componentes. A arquitetura
foi divida nas seguintes camadas: Base, Conectividade, Recursos, Coletiva e de Aplicações.
Internet/Web Como Plataforma
A variedade da tecnologia da Web faz com seja um ambiente atrativo para a
construção de sistemas e aplicações. Faltam a eles características necessárias para ocorrer
um modelo mais rico de iteração. Os navegadores “atuais” normalmente utilizam TLS
(Transport Layer Security – sucessor do SSL) para fazer autenticação, mas não suportam
login único e delegação.
Tecnologias
Relação com Sistemas de computação distribuída: CORBA, Java Beans, J2EE (J2E) e
DCOM (WCF). A forma principal de interação é do tipo cliente-servidor, e não de uso
coordenado de recursos múltiplos. Tornam mais fácil compartilhar recursos com uma única
organização. No entanto, esses mecanismos não resolvem os requisitos específicos listados
anteriormente.
As tecnologias de desenvolvimento de aplicações distribuídas teriam que ser adaptadas
aos requisitos da Grade. Uma opção seria construir um serviço de Nomes que utiliza o serviço
de informação da Grade para procurar fontes distribuídas de informação através de grandes
organizações virtuais.
Relação com Internet e Computação Ponto a Ponto: eMule (eDonkey), BitTorrent,
Kazaa, Gnutella compartilham arquivos. SETI@home e ProteinFolding@Home compartilham
ciclos de cpu. Não inter-operam entre si. Compartilham arquivos, por exemplo, mas sem
nenhum controle de acesso.
Com a evolução dessas aplicações elas acabaram por inter-operar e haverá uma
convergência de interesses entre computação ponto a ponto, Internet e computação em
Grade.
Outras perspectivas sobre Grades: “Computação em Grade é próxima geração da
Internet” – são protocolos adicionais que são construídos sobre a tecnologia da Internet.
Qualquer recurso que esteja na Grade, também está na Rede.
“A Grade é uma fonte de ciclos grátis.” – computação em Grade é controle de
compartilhamento. Os donos dos recursos terão políticas de restrição ao acesso a eles,
dependendo do usuário.
“A Grade torna supercomputadores desnecessários” – muitos problemas precisam de
supercomputadores para serem resolvidos, com baixa latência e comunicação rápida. Com a
grade o acesso a esses supercomputadores fica muito mais fácil, fazendo com que aumente a
demanda por eles aumente.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 69
Resumindo: "Computational Grids are systems that support parallel execution of
applications in distributed heterogeneous resources, offering consistent and inexpensive
access to those resources independently of physical location." [Ian Foster]
Grid Computing: Assim como os Clusters, os Grids de computadores estão se tornando
algo popular. A idéia por trás tanto dos clusters quanto dos grids é basicamente a mesma:
combinar o poder de processamento de vários computadores ligados em rede para conseguir
executar tarefas que não seria possível (ou pelo menos não com um desempenho satisfatório)
executar utilizando um único computador e ao mesmo tempo fazê-lo a um custo mais baixo
que o de um supercomputador de potência semelhante.
Os clusters e grids podem ser compostos tanto permanentes, quanto temporários,
formados para executar uma tarefa específica e depois desfeitos. Presumindo que todos os
computadores estejam previamente ligados em rede, a criação e dissolução é apenas questão
de ativar e depois desativar o software responsável em cada computador.
A principal diferença entre um cluster e um grid é que um cluster possui um
controlador central, um único ponto de onde é possível utilizar todo o poder de
processamento do cluster. Os demais nós são apenas escravos que servem a este nó central.
Os clusters são mais usados em atividades de pesquisa, resolvendo problemas complicados e
na renderização de gráficos 3D. Clusters também são homogêneos, enquanto grids são
heterogêneos.
Os grids por sua vez são uma arquitetura mais "democrática" onde embora possa
existir algum tipo de controle central, temos um ambiente fundamentalmente cooperativo,
onde empresas, universidades ou mesmo grupos de usuários compartilham os ciclos ociosos
de processamento em seus sistemas em troca de poder utilizar parte do tempo de
processamento do grid.
Por exemplo, duas empresas sediadas em países com fusos-horário diferentes
poderiam formar um grid, combinando seus servidores web, de modo que uma possa utilizar
os ciclos de processamento ociosos da outra em seus horários de pico, já que com horários
diferentes os picos de acessos aos servidores de cada empresa ocorrerão em horários
diferentes.
Conclusão
Podemos traduzir então que, um Grid Computacional resume-se em: Computadores em
diferentes localidades; Rede de grande área; Apropriados para computação intensiva, alto-
desempenho; Ambiente colaborativo; Grande quantidade de dados; Diferentes organizações;
Permitem compartilhar, agregar e escolher recursos computacionais dos mais variados
tipos: supercomputadores, dispositivos especiais - telescópios, radares, etc., sistemas de
armazenamento, bancos de dados, computadores comuns.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 70
As dificuldades encontradas são muitas, e os estudos são incessantes nessas áreas,
destacando-se: Localização dos recursos; Reserva de recursos; Capacidade para adaptar-se a
mudanças no ambiente; Criação e escalonamento das tarefas; Autonomia de cada grupo
participante para definir suas próprias políticas de segurança; Recursos requisitados podem
estar em diferentes localidades; Qualidade de serviço exigida por cada aplicação.
No futuro bem próximo as aplicações baseadas na web vão usufruir os benefícios das
grades computacionais, teremos então uma evolução natural dos sistemas localizados sendo
acessíveis mundialmente e o aluguel de recursos computacionais ociosos, principalmente
aqueles relacionados a processamento massivo.
Outras Questões
• Clusterização versus Virtualização.
o Muito se fala em virtualização. O que é isso?
� “A IBM é líder em virtualização, serviço que permite ao cliente
compartilhar atividades, rodando várias aplicações em um mesmo
servidor. Num exemplo prático, se um serviço de email estiver em
uso num horário do dia, o servidor direciona capacidade para isso.
Depois, quando o email já não estiver sendo usado, o servidor
muda essa capacidade computacional para outro serviço.”
o Mainframe
� Quanto custa?
� Usar um mainframe para trocar 100 máquinas (ecologia,
manutenção, backup, energia)
• Cluster/Grid � Sistema operacional de rede/Aplicação.
• Supercomputador (cálculos complexos, performance) versus Computador de
Grande porte (mainframe/vazão, suportar um grande número de usuários
simultâneos).
• Cloud computing: a expressão do momento em tecnologia. Nomes de peso como
Amazon, AT&T, Dell (tentou patentear), HP, IBM (US$300 milhões), Intel,
Microsoft e Yahoo já anunciaram planos e investimentos na área e o Gartner
acaba de liberar um relatório que aponta o cloud computing como uma das três
mais importantes tendências emergentes nos próximo três a cinco anos.
o Tecnicamente falando o Cloud Computing está fundamentado
principalmente na Virtualizaçao de aplicaçoes de forma que a configuraçao
da capacidade dos servicos (IaaS, PaaS, SaasS) seja dinamicamente
alterada em vôo de acordo com a necessidade do cliente; (Ex. O cliente
solicita que o total de memoria do serviço de banco de dados DB2 que ele
aluga como serviço (PaaS - Plataforma como Serviço) fosse aumentado de
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 71
1 para 2GB) para o cliente ele nao se preocupa em contratar uma nova
instalaçao do banco de dados em um servidor de 2 GB pois fornecedor
'virtualizou' essa instalaçao em um computador servidor de maior
capacidade, de forma que em um apertar de botoes ele compartilhe mais
1 GB para essa instalacao (maquina virtual), logo grande parte da
viabilizacao do conceito e viabilizado via Virtualizacao atraves da criacao
de Maquinas Virtuais (ex. VMWare, VirtualBox). Ai voce pergunta onde
esta a nuvem ? Bem, eu posso montar um sistema Web rodando os
softwares em diferentes fornecedores sem saber exatamente em qual
servidor ele roda mas sabendo o que eu contratei de capacidade desses
servicos, e é isso o que importa, nao o fabricante do hardware e etc...
o Pode ser definido como um modelo no qual a computação
(processamento, armazenamento e softwares) está em algum lugar da
rede e é acessada remotamente (obviamente através de um middleware),
via internet. “O que realmente significa é que alguém vai assumir a
responsabilidade de entregar algumas funções de TI como serviços para
alguns clientes e eles não precisam saber como funciona, eles
simplesmente usarão”, esclarece Daryl C. Plummer, vice-presidente do
Gartner.
• Protocolos Internet (TCP/IP)
o CAMADA � PROTOCOLO
o 5 – Aplicação � http, smtp, ftp, ssh, rtp, telnet, sip, rdp, irc, snmp, nntp,
pop3, imap, BitTorrent, dns, ping, etc..
o 4 – Transporte � TCP, UDP, SCTP, DCCP, SSL, TLS, etc..
o 3 – Rede � IP (IPv4, IPv6, ARP, RARP, ICMP, IPSec, etc..
o 2 – Enlace � Ethernet, 802.11, Wi-Fi, IEEE 802.1Q, 802.11g, HDLC,
Token Ring, FDDI, PPP, Switch, Frame Relay.
o 1 – Física � Modem, RDIS, RS-232, EIA-422, RS-449, Bluetooth, USB.
Exercícios
1. Qual a diferença entre um supercomputador e um computador de grande porte?
2. Qual a diferença entre um cluster e um grid?
3. Como funciona o World Community Grid? Ele é um exemplo de cluster ou grid?
Justifique sua resposta.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 72
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 73
Aula 10 – Análise de Desempenho de SD [ESTUDO DIRIGIDO]
Introdução
Considere o problema de avaliar o desempenho de um SD sendo executado sobre uma
rede homogênea de estações de trabalho. Você terá que interagir com a equipe de
desenvolvimento desse sistema com o intuito de propor algoritmos que melhorarem seu
desempenho.
A seguir, apresentamos uma metodologia segundo a qual analisamos o desempenho de
diferentes soluções propostas para algoritmos de balanceamento de carga em sistema de
realidade virtual distribuído, essa metodologia consiste em seguir os alguns passos básicos
que são: definição do escopo do sistema analisado, definição dos serviços oferecidos pelo
sistema em estudo, definição das métricas utilizadas na análise de desempenho, definição dos
parâmetros que influenciam o desempenho do sistema e que alteram a carga de trabalho que
o sistema atende, definição das técnicas de avaliação e da carga de trabalho utilizadas em
experimentos, projeto dos experimentos realizados, e descrição de como são apresentados e
analisados os resultados obtidos a partir dos experimentos.
Definição do Sistema: O primeiro passo é definir o escopo do sistema analisado, deve-
se determinar quais equipamentos e componentes de software fazem do sistema de
computação sendo analisado. Somente os equipamentos e componentes de software
presentes na definição do sistema deverão ser considerados ou analisados durante os
experimentos para a avaliação de desempenho.
Identificação dos Serviços: Neste passo, serão identificados os serviços oferecidos pelo
sistema em estudo e será determinado para quais desses serviços será realizada análise de
desempenho.
Escolha das Métricas de Desempenho: Esta etapa consiste na definição das métricas
utilizadas na análise de desempenho. Também é importante dizer se as métricas utilizadas
considerarão a ocorrência de possíveis falhas no sistema. Geralmente três classes diferentes
de métricas são utilizadas para avaliar o desempenho de algum recurso ou sistema:
1. throughput ou taxa de saída - o throught mede o número de serviços que o sistema
ou recurso consegue realizar por unidade de tempo. Suponha que o recurso sendo analisado é
um processador e cujo principal serviço é a execução de processos, então o throughput do
sistema será o número de processos completados por segundo.
2. utilização - a utilização de um recurso ou sistema é a relação entre o intervalo de
tempo em que o sistema esteve ocupado servindo os serviços requisitados e o intervalo de
tempo total em que o recurso ou sistema esteve executando ou disponível para uso. Se um
processador fosse ativado por uma hora e passasse 18 minutos ocioso e os outros 42 minutos
ocupado, sua utilização seria igual a 70%.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 74
3. tempo de resposta - o tempo de resposta é o intervalo de tempo decorrido entre o
momento que serviço é requisitado e o momento em que este serviço acaba de ser atendido.
Num sistema distribuído que segue a arquitetura cliente-servidor, o tempo de resposta
compreende o tempo que a requisição do cliente leva para trafegar pela rede até o servidor
(atraso de rede = tempo de transmissão da mensagem + tempo de propagação do sinal no
meio físico), mais o tempo no qual a requisição espera na fila do servidor para chegar sua vez
de ser atendida (tempo de espera), mais o tempo que o servidor leva para processar a
requisição (tempo de serviço), mais o tempo que o resultado do processamento da requisição
leva para ir do servidor ao cliente (atraso de rede).
A métrica mais utilizada na literatura é a média do tempo de resposta dos serviços.
Identificação dos Requisitos de Desempenho do Sistema: Os sistemas de computação
geralmente possuem requisitos de desempenho os quais eles devem satisfazer para que ele
possa ser utilizado eficientemente pelos seus usuários. Este requisitos devem ser identificados
e considerados durante os experimentos. Uma técnica que melhore de alguma maneira o
desempenho de parte do sistema, mas que leve o sistema como um todo a não satisfazer um
determinado requisito não deverá ser utilizada na implementação do sistema.
Identificação dos Parâmetros que Influenciam o Experimento: Todos do experimento
que influenciam o desempenho do sistema ou que alteram a carga de trabalho que o sistema
atende devem ser identificados. Alguns parâmetros dizem respeito ao sistema sendo avaliado,
como por exemplo, o poder de processamento dos processadores ou a banda passante
sustentada pela rede, outros parâmetros são relativos à carga de trabalho atendida pelo
sistema, com por exemplo, o número de processos na fila de espera na CPU ou o número de
hosts ligados à rede.
Identificação dos Fatores que Influenciam o Experimento: Como dezenas de
parâmetros do sistema ou da carga de trabalho podem afetar o experimento a ser realizado,
um único experimento poderá consumir um longo período de tempo para ser realizado.
Entretanto, a influência de alguns parâmetros pode ser considerada menos importante que a
influência de outros parâmetros. Portanto, nem todos os parâmetros precisam variar durante
os experimentos e podem ser considerados constantes. Os parâmetros que irão mudar de
valor durante o experimento são chamados fatores. Para cada fator devem ser determinados
os valores que ele poderá assumir durante o experimento.
Definição da Técnica de Avaliação a ser Utilizada: Para se avaliar o desempenho de um
sistema, geralmente, utiliza-se uma das três técnicas a seguir:
Medição - quando o sistema sendo avaliado já foi implementado são inseridas
instruções especiais no código do sistema. Estas instruções calculam e anotam, ao longo de
todo o experimento, os valores das métricas de desempenho escolhidas . Depois, é realiza
análises estatísticas sobre estes dados.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 75
Simulação - é construído um modelo matemático que representa adequadamente o
sistema sendo avaliado e este modelo é simulado. Durante a simulação as métricas de
desempenho são anotadas e depois é realiza análises estatísticas sobre estes dados.
Modelagem Analítica - é construído um modelo matemático que representa
adequadamente o sistema sendo avaliado, geralmente este modelo baseia na Teoria das
Filas. Então, este modelo é resolvido analiticamente e tenta-se encontrar fórmulas
matemáticas fechadas com quais é possível calcular as métricas escolhidas em função dos
fatores do experimento.
Caracterização e Geração da carga de Trabalho: Nesta etapa, serão escolhidos critérios
para caracterizar a carga de trabalho e será escolhida na qual a carga de trabalho utilizada
nos experimentos será gerada. Veja “balanceamento de carga em sistema distribuídos” para
saber mais sobre caracterização da carga de trabalhos de sistemas de computação.
Existem três formas básicas para se gerar a carga de trabalho de sistemas de
computação:
Benchmark
Comparações entre sistemas.
Benchmarks são programas sintéticos e por vezes padronizados que geram requisições
ao sistema sendo avaliado. O problema encontrado na utilização de benchmark é a dificuldade
em garantir que a carga de trabalho gerado por ele realmente reflete a carga de trabalho ao
qual o sistema sendo avaliado será submetido.
- trace - trace são arquivos que registram as requisições atendidas por um sistema de
computação durante um determinado intervalo de tempo. Estes arquivos podem servir de
entrada para um programa que o percorre do início ao fim gerando para o sistema sendo
avaliado as mesmas requisições ali contidas. A vantagem de se usar traces é que a carga de
trabalho utilizada no experimento será semelhante à carga de trabalho suportada pelo
sistema no mundo real. Entretanto, se o intervalo de tempo no qual o trace foi obtido for
muito pequeno ou se este intervalo de tempo for mal escolhido, esta semelhança poderá ser
perdida. Além disso, é muito difícil conseguir um trace de um sistema devido ao interesse
econômico sobre as informações nele contidas.
- uso real - outra maneira de se gerar a carga de trabalho é colocando o sistema em
funcionamento e solicitar a usuários previamente selecionados que o utilizem de forma
intensiva. O problema com esta técnica é que o sistema deve estar implementado, o perfil
dos usuários pode influenciar na carga de trabalho gerada e que devem existir usuários
disponíveis para realizar o experimento. Se você deseja testar o desempenho de um sistema
com milhares de usuários simultâneos esta técnica pode se tornar impraticável.
Projeto dos Experimentos Realizados: Deve ser descrito em que condições os
experimentos serão realizados e como os experimentos serão realizados, por exemplo:
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 76
Os experimentos serão realizados quando nenhum externo ao sistema estiver presente
na rede; Todas as médias serão calculadas considerando-se 10 amostras.
Análise e Apresentação dos Resultados: Esta é a última etapa da metodologia que
estamos apresentando. Nela, deve ser descrita a maneira segundo a qual os resultados serão
analisados e como os resultados serão apresentados às pessoas interessadas. É aconselhado
o uso de gráficos. Tente evitar fornecer a média das métricas sem dizer para qual intervalo de
confiança a métrica foi calculada. Evite usar desvio padrão ou variância para descrever a
variabilidade dos resultados em relação à média, dê preferência ao coeficiente de variação.
Outras Questões
• O desempenho como um requisito não funcional.
Exercícios
1. O que é throughput?
2. Como se calcula o tempo de resposta?
3. O que é benchmark?
4. Como funciona um trace?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 77
Aula 11 – Componentes para Computação Distribuída
Introdução
Sistema de software é um artefato evolutivo e requer constantes modificações, seja
para corrigir erros, melhorar desempenho, adicionar novas funcionalidades ou para adaptá-los
para novas plataformas de hardware e de software. A dificuldade em atualizar os softwares
para a utilização de novas tecnologias, tem motivado os pesquisadores a investigar soluções
que diminuam os custos de desenvolvimento, garantam um tempo de vida maior para o
sistema e facilitem a manutenção.
As técnicas atuais utilizam basicamente a Orientação a Objetos e a Computação
Distribuída como principais alicerces. Os componentes de software devem ser reutilizados em
todos os níveis de abstração do processo de desenvolvimento e não simplesmente no nível de
código.
O que é um Componente? Definição de Componente - ECOOP’96: “A software
component is a unit of composition with contractually specified interfaces and explicity
context dependencies only. A software component can be deployed independently and is
subject to composition by third parties.”
Componentes Distribuídos
A utilização de componentes distribuídos teve um grande impacto na engenharia de
software. O desenvolvimento orientado a componentes, o uso de componentes distribuídos
(remotos) nos modelos arquiteturais (N Camadas) e o uso da arquitetura MDA (Model Driven
Architecture) são muito citados na engenharia de software.
Tecnologias mais utilizadas para a implementação de componentes distribuídos:
CORBA, WebServices, EJB, DCOM .NET Remoting / Windows Communication Foundation
(WCF) e Internet Communications Engine (Ice).
Visão Geral de Componentes de Software: O ciclo clássico de desenvolvimento de
software composto de quatro fases (análise, projeto, implementação e teste) tem sido
empregado desde os primórdios da engenharia de software, sendo genérico o suficiente para
ser aplicado a qualquer processo de desenvolvimento de software. Atualmente, as técnicas de
desenvolvimento de software devem contemplar também a qualidade, capacidade de
integração, especialização e manutenção de sistemas de software de natureza distribuída.
Um ponto crucial para o software de natureza distribuída é a incorporação ao modelo
do sistema de fatores pertinentes à distribuição. No ciclo clássico de desenvolvimento, a
natureza distribuída do sistema é modelada na fase de projeto (design) onde a arquitetura do
software é concebida. Comumente, uma arquitetura cliente/servidor é adotada e
posteriormente sintetizada na fase de implementação com o auxílio de uma plataforma de
middleware tal como CORBA, DCOM ou Java RMI. É importante observar que mesmo os
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 78
modernos processos de desenvolvimento são deficientes para o desenvolvimento de tais
sistemas. Esta deficiência se deve à ausência de estratégias que permitam construir sistemas
com alto índice de reuso, evolução e geração automática de código (code generators).
Recentemente, devido aos avanços da tecnologia e introdução de padrões (design
patterns) de desenvolvimento de software, associados a ferramentas de apoio, surge um
novo paradigma que visa aprimorar os processos de desenvolvimento de software: o
paradigma de componentes. Na realidade, não se pode considerar uma inovação o conceito
de componentes como blocos de construção para o desenvolvimento de sistemas. Os
desenvolvedores de software sempre tiveram a convicção de que sistemas de grande porte e
complexos podiam ser construídos pela interconexão de blocos de construção menores, pré-
definidos e oriundos de desenvolvimentos anteriores ou adquiridos no mercado. Entretanto,
somente agora as tecnologias envolvidas têm evoluído no sentido de atingir este objetivo.
Desenvolvimento Orientado a Componentes
Os benefícios, com a utilização deste novo paradigma, incluem produção de software
de forma rápida, com menor custo de desenvolvimento, de alta qualidade
(certificação/processo) e de fácil manutenção. Esses objetivos são atingidos principalmente
pelo reuso de componentes, interligação explícita entre os componentes (resultando em baixo
acoplamento), alta coesão (componentes são altamente especializados) e geração automática
de código. Este novo paradigma, ao combinar as vantagens oferecidas pelas tecnologias
tradicionais de middleware e as novas tecnologias orientadas a componentes, provê um
melhor suporte à interoperabilidade (interação entre componentes de diferentes
fornecedores), portabilidade (componentes distribuídos em diferentes plataformas),
estensibilidade (adição de novas funcionalidades aos componentes) e coexistência com
sistemas legados.
Padrões para Empacotamento e Distribuição
Um modelo de componentes precisa descrever a forma como os componentes são
empacotados e distribuídos, tal que possam ser instalados independentemente. O processo de
distribuição utiliza componentes empacotados em arquivos de formatos tais como ZIP, JAR
(Java Archive), EAR, WAR ou DLL (Dynamic Linking Library), MSI, contendo as
implementações e informações necessárias para instalar e personalizar as implementações de
componentes, criar instâncias de componentes e interconectá-las de modo a proporcionar
aplicações na forma executável. É importante enfatizar que todos os recursos necessários
para a execução de um componente, incluindo a especificação das dependências de contexto,
precisam ser instalados junto com o componente. Deste modo, o componente executará
apropriadamente as suas funções somente quando tais recursos forem disponibilizados ao
componente.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 79
Um componente é distribuído em uma plataforma de componentes. No modelo de
componentes, o padrão de distribuição especifica a estrutura e as semânticas para as
descrições de distribuição e pode definir, também, o formato dos pacotes. Uma descrição de
distribuição deve fornecer informações necessárias para o processo de distribuição, tais como
os recursos necessários na máquina em que os componentes serão instalados, outros
componentes, bem como os aspectos de configuração e especialização. Esta descrição é
analisada pela infraestrutura de componentes da máquina destino para a apropriada
instalação e configuração dos componentes.
Um componente para ser instalado independentemente precisa ser completamente
separado de seu ambiente de execução e de outros componentes. Conseqüentemente, o
componente encapsula a sua implementação, ou seja, os dados e algoritmos imprescindíveis
para executar as suas tarefas. O processo de distribuição tipicamente envolve três fases:
instalação, instanciação e configuração de componentes.
Outras Questões
• Robert Martin 2002: “A unidade de reuso é o pacote.”
o Java: package.
o .NET: namespace.
• Metadados: (Banco/Annotations) � Atributos (Reflection)
o Criação automatizada de telas.
o Geração automática de SQL.
• JEE
o EJB 3.0
Exercícios
1. O que é um componente de software?
2. O que é um design pattern?
3. Explique o fato de que é desejável que os componentes tenham baixo
acoplamento e alta coesão.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 80
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 81
Aula 12 – Microsoft .NET Remoting
Introdução
COM: Microsoft® Component Object Model: é modelo de componentes orientado a
objetos, independente de plataforma, destinado à criação de componentes de software
binários que podem interagir entre si. É um conjunto de serviços (APIs) que são fornecidos
por uma biblioteca (biblioteca COM). Componentes podem estar num mesmo processo,
processos diferentes ou máquinas diferentes (DCOM).
DCOM
Microsoft® Distributed Component Object Model é a extensão do COM para ambientes
distribuídos. DCOM substitui a comunicação local entre processos por um protocolo de rede
(transparente para o cliente). Trata detalhes de baixo nível de protocolos de rede enquanto o
desenvolvedor foca no negócio. Oferece mecanismo de segurança: autenticação e encriptação
de dados.
.NET Remoting
É um mecanismo de interoperabilidade que pode ser usado para fazer chamadas de
código .NET em máquinas remotas. Pode-se dizer que o .NET Remoting é o equivalente ao
DCOM no mundo .NET. O .NET Remoting é uma alternativa ao DCOM ou aos Web Services, e
sua utilização em aplicações que rodem em redes internas (LANs) é muito interessante.
O .NET Remoting oferece algumas vantagens, tais como:
• Possibilidade de configurar o canal de comunicação (TCP ou HTTP);
• Configuração da porta (TCP 80);
• Uso de arquivo de configuração para cliente e servidor, evitando a necessidade
de recompilação dos códigos no evento de alteração de configuração.
Esquema da arquitetura do .NET Remoting:
.NET Framework
O .NET Framework é um modelo de programação de código gerenciado da Microsoft
para criar aplicativos em clientes (console/GUI), servidores (serviços/Web) e dispositivos
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 82
móveis ou incorporados do Windows. Os desenvolvedores podem usar o .NET para criar
aplicativos de vários tipos: aplicativos Web, aplicativos para servidores, aplicativos de cliente
inteligente, aplicativos de console, aplicativos de banco de dados e muito mais.
O .NET Remoting é a tecnologia, baseada no .NET Framework, que substitui o
COM/DCOM, levando consigo os conceitos e os princípios de projeto que tornaram o COM tão
poderoso. O .NET é totalmente integrado com o mundo Windows e COM. COM e DCOM ainda
podem ser usados no .NET. A Microsoft afirma que apesar de podermos utilizar COM e .NET
juntos, para novas aplicações distribuídas, é recomendável utilizar preferencialmente .NET
(código gerenciado).
Diferenças entre o Microsoft .NET Remoting e o DCOM
DCOM é baseado no protocolo RPC e o .NET usa SOAP. DCOM não trabalha com firewall
amigavelmente, já .NET sim, pois suporta HTTP. A utilização maior do DCOM é para
plataformas Windows, já .NET suporta várias plataformas. Manutenibilidade - complexa no
DCOM (registrar), .NET usa XML. No DCOM, a ativação do servidor é feita pelo SCM (Service
Control Manager) através da requisição do cliente, no .NET ocorre falha se o servidor não
estiver inicializado. Segurança, no DCOM depende do Sistema Operacional, .NET não.
Concluindo: A diversidade de cenários em que uma aplicação distribuída pode ser
executada é considerável, incluindo ambientes heterogêneos, constituídos por computadores
que apresentam arquiteturas e sistemas operacionais diferentes, e aplicações implementadas
em diferentes linguagens de programação. Isso torna o desenvolvimento de aplicações
distribuídas consideravelmente mais complexo do que o desenvolvimento de aplicações
centralizadas.
Com o objetivo de amenizar os problemas oriundos desse ambiente heterogêneo, foi
proposta a introdução de uma camada de software, chamada middleware, entre as aplicações
e seus sistemas operacionais subjacentes, fornecendo aos desenvolvedores de aplicações
distribuídas, uma interface de programação de alto nível, a qual objetiva ocultar as
dificuldades inerentes a esse ambiente (transparência). Com o sucesso da tecnologia,
diversas plataformas de middleware foram desenvolvidas para apoiar a implementação de
sistemas distribuídos. Dentre elas, destacam-se as plataformas Java RMI, CORBA, .NET
Remoting, JAX-RPC e Apache Axis.
Assim, plataformas de middleware são largamente empregadas por engenheiros de
software para simplificar e tornar mais produtivo o desenvolvimento de aplicações
distribuídas. Basicamente, estes sistemas encapsulam diversos detalhes inerentes à
programação em ambientes de rede, incluindo protocolos de comunicação, heterogeneidade
de arquiteturas, marshalling e unmarshalling de dados, sincronização, localização de serviços,
etc.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 83
Outras Questões
• WCF.
Exercícios
1. É possível trabalhar com WCF (ou .NET Remoting) através de um firewall?
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 84
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 85
Bibliografia/Créditos
• Sistemas Distribuídos - Walfredo Cirne, Fubica Brasileiro
• Aspectos Estratégicos da Computação Distribuída - João Sobral, Daniela Claro
• EAI - Leonardo Chaves
• Estratégia Competitiva - Alceu Alves
• O que é o Middleware – Prof. Michael Stanton
• Objetos Distribuídos com Java - Ivan Marques DCA/FEEC/UNICAMP
• Balanceamento de Carga em Sistemas Distribuídos de Propósito Geral – Prof.
Tiago Carneiro
• Programação Distribuída - Prof. Henrique Mongelli
• Sistemas Distribuídos (Introdução e Conceitos) - Prof. Rodrigo de Grazia –
FACECA
• Transações Distribuídas - Guilherme Galante - PPGC - II UFRGS
• Transações Distribuídas - Ricardo Anido
• TOLERÂNCIA A FALHAS EM SISTEMAS DISTRIBUÍDOS: A ABORDAGEM DO
CORBA/FT – Fábio Mendonça.
• Tolerância a Falhas em Sistemas Distribuídos - Prof. Raul Ceretta Nunes.
• Segurança em Sistemas Distribuídos - Guilherme Machado - Faculdades SENAC
• Segurança em Sistemas Distribuídos - Vidal Martins – GPT.
• Computação em Grade - Uma proposta de Arquitetura para protocolos entre
grades. (Autor Desconhecido)
• Análise de Desempenho de Sistemas Distribuídos – Prof. Tiago Carneiro (UFOP)
• Introdução aos Sistemas Distribuídos e Componentes de Software - Eliane
Gomes Guimarães e CTI Renato Archer
• Manual .NET do Desenvolvedor - Microsoft Consulting Services.
• Allyn Lima - Tópicos em Sistemas Distribuídos – UNICAMP.
• Aspectos para Construção de Aplicações Distribuídas - Cristiano Amaral Maffort –
Dissertação de Mestrado – PUC MG.
• Artigo “Aplicando EAI Patterns” – Revista MUNDO JAVA fev/2009.
• Aposilas da Caelum – www.caelum.com.br
• http://www.inf.ufpr.br/sunye/mapeamento/arquitetura.htm
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 86
Esta página foi deixada propositadamente em branco.
FILC 2012.1 - Notas de Aula de Computação Distribuída – Prof. M. França – Página: 87
Apêndice A – Questionário de Avaliação do Curso
FACULDADE DE INFORMÁTICA LEMOS DE CASTRO – Rio de Janeiro Professor M. França
Disciplina: CD Data: ________ Aluno: _______________________________________________ Período: _____
Observação: O nome é opcional, sinta-se livre para omiti-lo! Atenção: Procure dar respostas completas, evitando monossílabos: “sim”, “não”, “é”, “fui” etc.. E não se esqueça de perguntar ao professor sobre o 0,5 ponto relativo ao preenchimento deste.
1) O curso: O curso Bacharel em Sistemas de Informação da Faculdade de Informática Lemos de Castro possui um bom nível? As matérias são atuais e relevantes? Ele proporciona um ambiente para que alunos interessados possam adquirir conhecimentos aplicáveis profissionalmente?
2) A disciplina: A disciplina em questão (CD) possui um conteúdo atual? O programa foi totalmente coberto? A carga horária semanal foi suficiente para explanação e resolução de exercícios? As aulas práticas (se for o caso) foram suficientes e em condições adequadas (máquinas)?
3) O professor: O professor possuía domínio da disciplina (conhecimento)? Ele explica bem (didático)? Ele é cordial e atencioso para com os alunos? Ele estava sempre disposto a explicar novamente algum conceito mal compreendido? Existe algum ponto positivo e/ou negativo no professor?
4) O aluno: Você freqüenta as aulas assiduamente? Você faz os exercícios/estuda em casa? Você presta atenção na explicação do professor? Você se considera um aluno agitado/disperso? Você conseguiu aprender os principais conceitos da disciplina? Você tentou tirar suas dúvidas com o professor?
5) Livre: Que sugestões, ou críticas, você gostaria de fornecer para a melhoria do processo?
6) Nota: Dê uma nota para a disciplina (CD), de 0 (muito insatisfeito) a 10 (muito satisfeito): _____ Muito obrigado. Desejo a todos muito sucesso profissional e boas férias; Sem radicalismos!
“Teu coração é livre.
Tenha coragem para segui-lo!”
Brave Heart
r e v i s t a
Artigo publicado na edição 33
w w w . m u n d o j a v a . c o m . b r
j a n e i r o / f e v e r e i r o d e 2 0 0 9
6 www.mundojava.com.br
Aplicando EAI Patterns sobre Transformação de Mensagens
Mergulhando nos detalhes conceituais e de implementação sobre padrões de transformação de mensagens
c o l u n a
Estudo de Caso: Automação da Ativação de um Plano de Internet
SO
A n
a P
ráti
ca
Iremos, neste artigo, discorrer diversos padrões de integração sobre transformação de mensagens catalogados no EAI Patterns. Por meio da simulação de um cenário de integração entre sistemas, iremos mostrar no JBoss ESB como implementar alguns desses padrões voltados à transformação de mensagens, bem como outros padrões de EAI que auxiliam soluções de integração.
Ricardo Ferreira([email protected])É arquiteto de software na Squadra Tecnologia em Belo Horizonte. Na Squadra, atua principalmente em projetos cujo foco é integração de sistemas, soluções baseadas em BPM, soluções de modernização de aplicações e projetos baseados em J2EE. Com mais de 10 anos de experiência, já atuou em soluções para bancos, telecom, centrais de energia elétrica, montagem de máquinas, construtoras e universidades. Possui as certificações SCEA, SCBCD, SCWCD, SCJP, IBM Certified RUP v.7.0 Solution Designer e IBM Certified SOA Solution Designer. Nas horas vagas, escreve em seu blog http://architecture-journal.blogspot.com
uando lidamos com soluções de integra-ção em ambientes corporativos, grande parte do esforço desse tipo de solução
gira em torno de como lidar com os mais variados tipos de dados e formatos nos quais esses dados são armazenados. Se fraco acoplamento é a primeira premissa básica de qualquer solução de mensageria, acomodar vários formatos sem fazer com que as aplicações de origem e destino sejam alteradas, sem dúvida alguma será a segunda premissa básica.
Por exemplo, um sistema de processamento de cartões de crédito pode ter uma representação de um cliente diferente da de um sistema de gerência de conta bancária de um determinado banco. Uma solução de CRM também pode ter outro tipo de visão sobre o que é um cliente ou qual é seu formato. Mas se um dado processo de negócio
Q precisa cruzar informações destes três sistemas, como uma solução de integração irá lidar com estas diferentes visões sobre um cliente, e por conseqüência como ela irá lidar com os diferentes formatos em que este cliente estará em cada um destes sistemas? Para este tipo de cenário, o catálogo de EAI Patterns propõe uma seção especial de padrões conhecidos como padrões de transformação de mensagens.
Neste artigo, veremos por meio de um cenário de negócio de uma empresa fictícia, como criar uma so-lução de integração corporativa usando o JBoss ESB como solução de EAI, e iremos aplicar nesta solução alguns dos mais importantes padrões de transformação de mensagens do EAI Patterns.
A empresa FastNet é líder de mercado na prestação de serviços de internet banda larga e hospeda-gem de sites brasileiros. Há quase seis anos, ela é referência no mercado brasileiro sobre internet empresarial e internet domiciliar. Nos últimos meses, a empresa tem observado vários problemas sobre a qualidade no atendimento ao cliente, no seu setor de call center.
Preocupado com o número de reclamações de clientes sobre atendimento, bem com o número
7
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
Posicionando a estratégia da solução de EAI a ser criada
Simulando o atendimento de um cliente para ativação de um plano de internet
grande de cancelamentos do serviço devido ao nível inferior de atendimento, o diretor de ope-rações estratégicas da empresa convoca uma reunião para atacar essa situação. Nesta reunião, estão presentes pessoas de todos os setores da empresa e algumas das atendentes do setor de call center para explanar o problema em mais detalhes. A seguir, um trecho da reunião que houve entre os participantes:
“Fernanda, você pode nos explicar que tipo de problemas acontece para que o atendimento seja tão prejudicado?” − indaga o diretor de operações estratégicas a uma das atendentes do call cen-ter.
“Sim senhor. Grande parte dos nossos problemas gira em torno do excesso de trabalho ao realizar a ativação de um plano de internet de um cliente. Deixe-me explicar melhor. Acontece que quando temos em mãos um cliente requisitando um plano de internet, temos que segurá-lo na linha até que possamos completar a digitação de todos os dados no nosso sistema de atendimento e, depois disso, redigitar os mesmos dados em outros sistemas da empresa.”
“O problema ocorre pois quando terminamos de digitar todos os dados neste sistema, temos que esperar o sistema gerar o identificador único do cliente, processo este que demora bastante. Feito isso, temos que redigitar os mesmos dados em vários sistemas diferentes, para completar o pedido de ativação de ponto do cliente para um determinado plano de internet. Se ele já fizesse isso pra gente, não teríamos metade dos problemas de atendimento que temos hoje. Como não damos conta do número de atendimentos a serem feitos, estamos tendo um acúmulo de quase 2 mil pedidos de ativação, fora aqueles que todos os dias entram. Estamos estafadas de trabalho, pois temos que ficar todos os dias fora do horário para dar conta de diminuir este número de ativações pendentes, e ainda temos que ouvir reclamação de clientes esperando pela sua ativação atrasada todos os dias.” – relata Fernanda.
“Por que estes sistemas não se comunicam diretamente? Por que não automatizar este processo para evitar esta redigitação?” − questiona o diretor de operações para o diretor de TI.
“É que o sistema do call center foi feito há quase dez anos em COBOL, e ele não suporta integra-ção com as tecnologias dos outros sistemas” – relata o diretor de TI. “Não vou admitir este tipo de afirmação, eu aprovo anualmente uma verba absurda para a TI resolver esse tipo de problema. Talvez seja a maior verba aprovada em todos os departamentos da empresa, e vocês me falam que a tecnologia não dá suporte a isso? Troquem a tecnologia, troquem os analistas, mudem os pro-cessos, mas eu quero isso resolvido até o final deste mês” – diz o diretor de operações, já bastante nervoso.
“Não é tão simples assim, você há de concordar comigo que a algum tempo atrás lhe propusemos refazer todo o sistema de call center na plataforma baixa, até porque manter analistas COBOL dentro da empresa está ficando caro demais. A tecnologia de mainframe não suporta integração com outras plataformas, principalmente das plataformas dos outros sistemas em questão.” – diz o diretor de TI.
“De que outras plataformas estamos falando? Semana passada estive lendo um excelente artigo na revista MundoJava no qual se mostrava umas soluções de ESBs e SOA que faziam tudo se conectar com tudo. Por que que eles conseguem e nós não?” – diz o diretor de operações.
“As plataformas em questão são nossa solução de CRM baseada no Oracle Siebel, uma aplicação feita em C++ Builder para o gerenciamento da nossa central de rede, o módulo financeiro do nosso SAP e um sistema web externo feito em Java que pertence aos nossos parceiros de instalação de pontos nos clientes.” – diz o diretor de TI.
“Não acredito que nosso mainframe não possa falar com outros sistemas, isso está me cheirando a corpo mole da TI. A IBM sempre cria produtos cujo foco é integração.” – diz o diretor de operações. “Está correto senhor, existem sim tecnologias capazes de fazer isso funcionar, mas não as possuí-mos hoje em nosso parque de ativos TI. Existe, por exemplo, a solução CICS Transaction Gateway da IBM, que possui conectores JCA, motores de Sockets e TCP-IP que podem falar com o CICS via CommArea ou até mesmo sem ele. O senhor aprova a compra desta solução?” − pergunta o diretor de TI.
“O orçamento da TI para este ano já estourou e não irei aprovar mais orçamento algum para resolver este problema que pensei nem existir. No máximo, posso aprovar algumas horas de um consultor de integração para estudar nosso cenário e propor uma solução que será imple-mentada pelos nossos rapazes de TI. Assim que o consultor realizar o trabalho, quero ser infor-mado de todos os passos. Entre em contato com a Squadra Tecnologia em Belo Horizonte, ouvi dizer que eles são muito bons nesta área.” – diz o diretor de operações, finalizando a reu-nião com os demais.
Depois de realizada a reunião com a direção operacional da empresa FastNet, o diretor de TI da empresa convoca um consultor de inte-gração para auxilliar na criação da solução. O consultor, ao chegar na empresa, é posicionado sobre o problema sob a ótica do pessoal de TI. Neste caso, os problemas apresentados são de comunicação entre sistemas legados diferen-tes para resolver um problema emergencial do call center. “Fernanda, boa tarde! Esse aqui é o nosso consultor de integração de sistemas que irá nos ajudar a resolver aquele problema dis-cutido em nossa reunião. Você poderia auxiliá-lo no entedimento do problema?” – pergunta o analista de TI para a atendente. “Claro! Por favor, sente-se aqui e veja como fazemos uma ativação de plano de internet, estou com um cliente em espera prestes a começar um novo atendimento.” – diz Fernanda para o consultor de integração.
O consultor de integração solicita à Fernanda para agir normalmente no atendimento, como se ele não estivesse presente. O consultor ano-ta todos os procedimentos à medida que ela os executa junto ao cliente. Ele solicita que ela ponha o seu telefone no viva-voz para acom-panhar também o cliente. A figura 1 mostra o detalhamento do atendimento da atendente com o cliente.
8 www.mundojava.com.br
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
Figura 1. Cenário de atendimento da empresa FastNet.
“Pronto! Agora que coletei todos os dados, irei dar prosseguimento na ativação do plano de inter-
net para este cliente.” – diz Fernanda.
“Ok Fernanda, entendi até aqui. Quais são os próximos passos?” – pergunta o consultor.
“Agora eu vou ligar no ramal do financeiro, e pedir a pessoa que me atender neste número para
cadastrar os dados do cliente no nosso sistema financeiro.” − responde Fernanda.
“Então daqui em diante, o processo é por conta dessa pessoa?”
“Não, apenas a parte referente a cobrança. Precisamos cadastrar estes dados no sistema financeiro
para que a FastNet possa enviar boletos de cobrança ao cliente. Depois disso, eu ligo para o pessoal
da central de rede, e peço pra eles cadastrarem também o cliente na central, para que possamos
prover canal de internet ao ponto de sua residência. Estes dois departamentos têm o mesmo aces-
so que eu aos dados referentes aos pedidos de ativação de planos. Feito isso, eu entro no sistema
web para requisição de instalação de ponto no cliente. Temos uma empresa parceira que faz este
serviço pra gente, mas temos que solicitar a instalação por meio deste sistema web que eles nos
oferecem.”
“Deixe-me ver se entendi. Então, depois de cadastrar todos os dados junto com o cliente, operação
esta que demorou quase meia hora, você liga em três setores diferentes, que cuidam de visões
diferentes do serviço, para que eles cadastrem as informações que lhe interessam. É isso?”
“Hum, três departamentos? Na verdade são quatro. Eu esqueci de um. Tenho que antes de ligar pro
departamento financeiro, ligar pro departamento de atendimento ao cliente para que eles regis-
trem os dados do cliente no sistema de gestão deles. Desculpe, eu sempre esqueço deste passo.”
“Fernanda, e o que acontece quando você ou qualquer uma destas quatro pessoas que estão en-
volvidas na ativação do plano esquecem de algum passo, ou atrasam por algum motivo?”
“Aí vai chegar uma hora que o cliente vai ligar reclamando que até agora ninguém instalou a
internet na casa dele, ou que a fatura não lhe foi enviada, ou que o sinal ainda não existe na sua
residência e iremos providenciar todo este processo novamente. Mas normalmente quando chega
neste ponto, o cliente desiste do plano.”
Iniciando a solução de EAIVamos agora conceber como será o fluxo de processamento da solução. O fluxo de pro-cessamento diz respeito a como os sistemas dos legados serão enlaçados. O evento que irá disparar este fluxo de processamento será a geração de um arquivo XML que conterá todos os dados que são de interesse dos sis-temas envolvidos. Neste caso, será criado um programa COBOL que lerá todas as requisições de plano de internet da base de dados do CICS, e para cada requisição lida, gerar um arquivo XML num diretório estratégico da solução. Um agendador da plataforma CICS irá ser usado para que toda madrugada este programa CO-BOL seja executado.
Assim que o arquivo XML for criado, ele será gravado num diretório compartilhado da rede, onde uma solução de EAI lerá este diretório continuamente, na espera pela gravação do arquivo. Quando identificado que este arquivo fora gravado, será iniciado então o processo de ativação de plano de internet, executado pela solução de EAI escolhida para a FastNet. A partir deste ponto, o arquivo XML será verifi-cado, terá seus dados extraídos do arquivo, os dados serão transformados, e cada informação será entregue aos sistemas legados. Um ponto importante desta solução é que ela também resolve o problema de eliminar o backlog de ativações a serem feitas da empresa que esta-vam atrasados. Em parceria com os analistas COBOL do sistema de call center da FastNet, foi gerado um arquivo XML para cada atendimen-to feito cuja natureza era solicitação de plano de internet. Desta forma, com todos os pedidos feitos na forma de arquivos XML, a solução po-deria executar todos os pedidos, bastando para isso gravar tais arquivos no diretório escaneado pela solução de EAI. Para cada arquivo lido, a solução de EAI irá criar um contexto transacio-nal para processamento do arquivo, bem como um thread particular para isolar os processos em nível de aplicação.
Futuramente, cada novo atendimento feito pela equipe de call center irá gerar um arquivo XML respectivo ao atendimento, e será copiado para o diretório escaneado. Isso possibilita que as atendentes não tenham que se preocupar mais com o backlog de atendimento, não ficando, portanto, até altas horas da noite para tentar diminuir a lista de pendências, bem como escalar bem mais atendimentos por dia, garantindo que a instalação do ponto de internet no cliente será feita na data negociada durante a aquisição do plano.
9
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
Construindo uma solução de EAI para a FastNet
Configurando o endpoint do serviço de ativação de ponto
Vamos dar início agora à construção da solução de EAI proposta para a empresa FastNet. Iremos considerar, nesta construção, o servidor JBoss ESB como solução de EAI escolhido para o projeto. É importante que você esteja familiarizado com o JBoss ESB para criar esta solução. Se você não se sente à vontade com este servidor, consulte a edição 32 da revista MundoJava, e visite o artigo Usando EAI Patterns no JBoss ESB, onde você encontrará um bom tutorial sobre o mesmo, bem como uma boa introdução sobre EAI Patterns.
Para esta solução, iremos nos basear no servidor JBoss ESB versão 4.4 GA. Ele pode ser baixado gratuitamente do site da JBoss. Consulte as referên-cias para mais informações sobre como baixar o servidor. Depois de ter instalado seu JBoss ESB (se ele ainda não estiver), crie um módulo ESB na sua ferramenta de desenvolvimento Java preferida, conforme mostrado na figura 2.
Figura 2. Estrutura do módulo ESB para ativação de ponto de internet.
Na figura 2 podemos ver a estrutura do nosso projeto de ativação de ponto de internet. Repare que na raiz do módulo, estão três pacotes. Crie dentro destes pacotes as classes Java mostradas na figura 2. Ainda na raiz do projeto, existe a pasta META-INF que contém alguns arquivos XML de configuração do módulo ESB. Crie estes arquivos dentro desta pasta também. Na raiz do módulo, está também o arquivo queue-service.xml, responsável pela definição das filas JMS que serão usadas no módulo ESB. Finalmente, crie dentro da raiz do projeto, uma pasta chamada Resources, e dentro desta pasta, crie um arquivo XML chamado de pa_123456789.xml.
Agora que temos a estrutura de nosso módulo pronta, podemos dar início às atividades de implementação do projeto. A primeira coisa que faremos então é definir no arquivo queue-service.xml a nossa fila JMS que será nosso canal de processamento para as mensagens. Abra então o arquivo queue-service.xml e edite-o para declarar a fila JMS conforme mostrado na Listagem 1.
<?xml version=”1.0” encoding=”UTF-8”?><server> <mbean code=”org.jboss.jms.server.destination.QueueService” name=”mundojava.eaipatterns.destination: service=Queue,name=ativacaoPontoQueue” xmbean-dd=”xmdesc/Queue-xmbean.xml”> <depends optional-attribute-name=”ServerPeer”> jboss.messaging:service=ServerPeer </depends> </mbean></server>
Listagem 1. Definição da fila JMS que será usada para processamento do serviço de ativação de ponto.
O JBoss ESB usa filas JMS para canalizar o processamento das mensagens. Este canal de execução é, na verdade, uma realização do padrão de integração Point-to-Point Channel. Quando usamos soluções baseadas em RPC, temos a certeza que a mensagem enviada, a chamada de método propriamente dita, irá ser entregue ao objeto do servidor. Em sistemas de mensageria, uma mensagem é enviada a um canal, e esta em seguida será entregue ao seu respectivo receptor. Por isso, todo serviço no JBoss ESB precisa da sua própria fila JMS. Consulte nas referências mais informações sobre o padrão Point-to-Point Channel.
Na solução proposta, um arquivo XML será criado pelo programa COBOL da plataforma CICS e será escrito num diretório que será lido continu-amente pela nossa solução de EAI. Neste caso, temos que definir um tipo de endpoint que tenha esta capacidade de escanear diretórios por arquivos de certo tipo para iniciar o processamento da mensagem. A mensagem neste caso é o próprio arquivo XML que será lido do diretório, e seu conteúdo será automaticamente considerado como a mensagem a ser enviada para o serviço.
No JBoss ESB, este tipo de endpoint é suportado por meio de provedores do tipo File System. Iremos configurar o endpoint de forma que um de-terminado diretório do sistema operacional seja escaneado, em espera por um determinado tipo de arquivo. Para isso, abra o arquivo META-INF/jboss-esb.xml e edite-o conforme mostrado na Listagem 2.
Conforme mostrado na Listagem 4, dois tipos de providers foram defi-nidos no arquivo de configuração do módulo ESB. O primeiro, chamado de FileSystemProvider, é o tipo de provider que suporta leitura de dire-tórios. Por meio da tag <fs-provider>, você pode iniciar a declaração de um provider do tipo File System, que conterá a definição de um ou mais elementos do tipo <fs-bus>, que representa um endpoint do tipo File System. A Listagem 3 especifica as propriedades inerentes ao endpoint do tipo FileSystem usado no exemplo.
10 www.mundojava.com.br
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
<?xml version=”1.0” encoding=”UTF-8”?><jbossesb xmlns=”http://anonsvn.labs.jboss.com/labs/jbossesb/ trunk/product/etc/schemas/xml/jbossesb-1.0.1.xsd” parameterReloadSecs=”5” > <providers> <fs-provider name=”FileSystemProvider”> <fs-bus busid=”fsAtivacaoPonto”> <fs-message-filter directory=”C:\\Temp\\Input” post-directory=”C:\\Temp\\Output” post-delete=”false” input-suffix=”.xml” work-suffix=”.esb” post-suffix=”.processed” /> </fs-bus> </fs-provider> <jms-provider name=”MessagingProvider” connection-factory=”ConnectionFactory”> <jms-bus busid=”jmsAtivacaoPonto”> <jms-message-filter dest-type=”QUEUE” dest-name=”queue/ativacaoPontoQueue” /> </jms-bus> </jms-provider> </providers></jbossesb>
<services> <service category=”MundoJava” name=”AtivacaoPontoESB” description=”Ativacao ponto de Internet”> <listeners> <fs-listener name=”ativacaoPontoListener” busidref=”fsAtivacaoPonto” schedule-frequency=”5” is-gateway=”true” /> <jms-listener name=”ativacaoPontoListener” busidref=”jmsAtivacaoPonto” /> </listeners> <actions mep=”OneWay”> <action name=”Println” class=”org.jboss.soa.esb.actions.SystemPrintln” /> </actions> </service></services>
Listagem 2. Configuração do módulo ESB para suporte a endpoints do tipo File System.
Listagem 4. Definição parcial do nosso serviço de ativação de ponto de internet.
Listagem 3. Descrição das propriedades de configuração dos endpoints File System.
Propriedade Descrição
directory Especifica qual será o diretório que deverá ser lido continuamente pelo ESB
post-directory Especifica qual será o diretório usado para arma-zenar o arquivo depois do processamento
post-delete Determina se o arquivo deverá ou não ser apa-gado depois do processamento
input-suffix Especifica que tipo de arquivo será monitorado pelo ESB no diretório especificado
work-suffix Especifica qual extensão será aplicada no arquivo quando ele estiver sendo processado pelo ESB
post-suffix Especifica qual extensão será aplicada no arqui-vo depois que ele for processado pelo ESB
Neste artigo, iremos assumir que você irá configurar os diretórios do exemplo compatíveis com seu sistema operacional usado. Na configuração do endpoint do tipo File System, usamos diretórios que são compatíveis com o sistema operacional Windows. Caso você esteja usando Linux ou outro sistema operacional baseado em Unix, lembre-se que o separador de diretórios nativo do sistema será ‘/’ e não ‘\’. Atente também que no Unix não se usa o conceito de drives lógicos, como ‘C:\’, e sim, pontos de montagem.
Na Listagem 4 também é mostrada a definição de um provedor JMS. Esta definição é necessária para acomodar a configuração do módulo ESB sobre a fila JMS que será usada para o processamento das mensagens enviadas a um determinado serviço. Nosso serviço de ativação de ponto de internet estará, portanto, usando o jms-bus chamado de ‘jmsAtiva-caoPonto’ que usa internamente a fila JMS chamada de ‘ativacaoPonto-Queue’, configurada anteriormente no arquivo queue-service.xml.
Criando o serviço que fará o processamento do arquivo XML
Vamos agora configurar em nosso módulo ESB o serviço de ativação de ponto de internet. Para isso, abra novamente o arquivo META-INF/jboss-esb.xml, e altere-o acrescentando uma seção de <services> dentro da declaração do módulo, conforme mostrado na Listagem 4. Lembre-se que o arquivo terá seu conteúdo modificado para acomodar as novas declarações, as declarações feitas na Listagem 4 permanecem.
Na Listagem 6, declaramos um serviço chamado de ‘AtivacaoPontoESB’ que será nosso serviço de processamento da ativação do ponto de in-ternet. A este serviço, declaramos dois listeners: um para definir que o endpoint de File System irá invocar este serviço, notadamente o listener do tipo <fs-listener>, e outro que especifica qual bus JMS será usado para o processamento das mensagens. Na declaração do ouvinte do tipo File System, repare que além dos atributos tradicionais, usamos um atributo especial chamado de ‘schedule-frequency’. Este atributo especifica de quantos em quantos segundos, o diretório especificado no endpoint será lido pelo ESB. Note que o listener do tipo File Sytem foi definido como gateway (is-gateway=true), portanto, ele será nosso endpoint para o mundo externo.
Até este ponto você já poderá testar o funcionamento básico da solução usando um arquivo XML de testes. Faça um arquivo Jar do projeto criado, usando algum mecanismo de geração de arquivos Jars, cujo nome do arquivo gerado seja ativacaoPonto.esb. Este será nosso módulo ESB para
11
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
<?xml version=”1.0” encoding=”UTF-8”?><pedido-ativacao> <dados-cliente> <identificador>123456789</identificador> <nome>Vivian L. T. Ferreira</nome> <rg>MG3488189</rg> <cpf>45612300856</cpf> <dataNasc>16/08/1980</dataNasc> </dados-cliente> <enderecos> <endereco-residencial> <logradouro>Avenida Castelo Branco</logradouro> <numero>500</numero> <complemento>Apt 207</complemento> <cep>30852-110</cep> <bairro>São Francisco</bairro> <cidade>São Luis</cidade> <uf>MA</uf> </endereco-residencial> <endereco-cobranca> <logradouro>Rua das Cegonhas</logradouro> <numero>5</numero> <complemento>Apt 107</complemento> <cep>66345-789</cep> <bairro>Praia do Calhau</bairro> <cidade>São Luis</cidade> <uf>MA</uf> </endereco-cobranca> </enderecos> <detalhes-plano> <tipo-plano>BAND_LARG_2MB</tipo-plano> <suporte-tecnico>true</suporte-tecnico> </detalhes-plano> <detalhes-instalacao> <tipo-computador>NOTEBOOK</tipo-computador> <sistema-operacional>WIN_VISTA</sistema-operacional> <responsavel>Vivian L. T. Ferreira</responsavel> <data-instalacao>17/11/2008</data-instalacao> </detalhes-instalacao></pedido-ativacao>
Listagem 5. Arquivo XML de exemplo que será gerado pelo programa COBOL.
Em qualquer solução de integração, uma das práticas mais comuns encontradas durante a criação da solução é particionar o processamento da mensagem em estágios diferentes dentro de um canal de processamento. A esta prática damos o nome da Pipes and Filters. Em verdade, não se trata apenas de uma prática, trata-se de um dos padrões catalogados no EAI Patterns, só que relativo ao assunto sistemas de mensageria. Todos os padrões de de-senho relacionados a mensagens, seja sobre roteamento, transformação ou criação, são fundamentados na solução Pipes and Filters. Consulte as referências do artigo para mais informações.
Definindo o arquivo XML que será enviado pelo programa COBOL
Criando o fluxo de processamento do serviço
testes do mecanismo de leitura de arquivos. Copie o arquivo gerado (ati-
vacaoPonto.esb) para o diretório de implantação do JBoss ESB (<JBOS-
SESB_HOME>/server/default/deploy) e, em seguida, inicie seu servidor.
Após ter iniciado seu servidor JBoss ESB, faça o seguinte teste: pegue
qualquer arquivo XML que esteja em seu computador (pode ser um dos
arquivos XML do projeto) e copie-o para o diretório especificado no atri-
buto ‘directory’ do módulo ESB. Você verá que depois de cinco segundos,
o JBoss ESB vai identificar o arquivo dentro do diretório, irá retirá-lo de
lá, mostrar o conteúdo do arquivo no console do servidor (indicando a
execução da ação org.jboss.soa.esb.actions.SystemPrintln) e depois mo-
ver este arquivo para o diretório especificado no atributo ‘post-directory’.
Nosso módulo ESB está então pronto para que possamos implementar a
lógica do processamento da ativação do ponto de internet.
Vamos definir agora um arquivo XML que servirá de exemplo para
que possamos realizar nossos testes no cenário da FastNet. Conforme
explicado anteriormente, um formato de dados foi negociado entre o
consultor de integração e os analistas COBOL da FastNet, responsáveis
pelo programa que gera o arquivo. Normalmente, essa é uma etapa que
antecede a criação de uma solução de EAI, pois quem gera os arquivos
é quem define o formato do mesmo, baseado em algumas restrições
da sua plataforma de desenvolvimento de software, ou restrições sobre
conhecimento daquele formato de arquivo.
É importante que seja negociado um formato de ampla aceitação, para
que você não tenha problemas de aquisições de conectores especiais
para trabalhar com determinado formato de arquivo ou interface de
sistema. Assim que for possível, prefira trabalhar com arquivos XML, pois
este é um formato universal para transferência de dados, que acomoda
os dados que serão entregues à solução de EAI, bem como os metadados
que definem informações sobre os dados.
Abra o arquivo Resources/pa_123456789.xml e edite-o conforme mos-
trado na Listagem 5. Este é o formato que foi negociado com os analistas
COBOL da FastNet. O nome do arquivo sugere um pedido de ativação
(PA) do cliente cujo identificador único é 123456789.
A partir do recebimento do arquivo XML por parte do JBoss ESB, o
restante do processamento se dá por conta da criação do fluxo de pro-
cessamento da mensagem. No JBoss ESB, todo fluxo de processamento
é representado por um conjunto de ações que são configuradas seqüen-
cialmente, para um dado serviço. Estas ações representam os filtros de
processamento de um determinado duto de execução. Quando uma
mensagem é recebida por um serviço, o conjunto de ações que é confi-
gurado para aquele serviço será disparado pelo motor do ESB na ordem
em que for definido, e este fluxo de processamento será executado na fila
JMS especificada para o serviço.
12 www.mundojava.com.br
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
Desta forma, a primeira coisa a se fazer é desenhar como será o fluxo de processamento da mensagem para posterior implementação na solução de EAI. Quais serão as etapas a serem executadas? Como a mensagem será entregue aos sistemas? Todo serviço possui uma estratégia de pro-cessamento na forma de fluxo. Na figura 3, temos a definição do fluxo de processamento do processo de ativação de ponto de internet.
Figura 3. Fluxo de processamento da mensagem enviada para o serviço.
Aplicando o padrão Message Translator para transformação de XML para Java
Conforme mostrado na figura 3, a primeira ação a ser executada quando uma mensagem for enviada para o serviço de ativação de ponto será de transformar a mensagem enviada do formato XML para o formato Java. Isso se faz necessário para que possamos, dentro do ESB, manipular os dados mais facilmente usando a linguagem Java. Neste caso, iremos aplicar nesta etapa do fluxo, o padrão de integração Message Translator, padrão responsável por troca de formatos em ambientes de integração.
O padrão Message Translator é o “pai” de todos os padrões de trans-formação de mensagens. Ele é usado quando temos que adaptar uma mensagem que se encontra num determinado formato para outro, a fim de possibilitar o processamento da mensagem. Ele é baseado no con-ceito de filtro do padrão Pipes and Filters, ou seja, ele é realizado como um estágio de processamento particular na cadeia, com foco particular em conversão ou adaptação de formatos. Consulte nas referências mais informações sobre este padrão.
Para facilitar as coisas para os arquitetos de integração, o JBoss ESB acom-panha um mecanismo muito poderoso de transformação de mensagens. Por meio de uma ação previamente implementada dentro do JBoss ESB, você pode realizar vários tipos de transformações complexas na mensa-gem enviada para um serviço, usando apenas configuração de arquivos, ao invés de implementação de código. Este mecanismo é chamado de Smooks, pois é baseado no framework Smooks. Veja nas referências mais informações sobre este framework.
Por meio do mecanismo de Smooks, você pode fazer várias transfor-mações entre formatos numa mensagem do ESB, como transformar mensagens XML via XSLT, formatar mensagens XML usando Groovy ou XSLT, transformar um documento XML em objetos Java, transformar um documento XML para objetos Groovy, transformar arquivos CSV para XML, transformar EDI em XML, bem como aplicar CSS em um documento HTML enviado como mensagem. Para o nosso exemplo, iremos usar a
transformação do documento XML enviado para o serviço em objetos Java. Para começar, você deverá configurar a lógica de transformação num arquivo especial de configuração do Smooks. Abra o arquivo META-INF/ativacaoPonto-smooks.xml e edite-o conforme mostrado na Listagem 6.
<?xml version='1.0' encoding='UTF-8'?><smooks-resource-list xmlns=”http://www.milyn.org/xsd/smooks-1.0.xsd”>
<resource-config selector=”decoder:dataDecoder”> <resource>org.milyn.javabean.decoders.DateDecoder</resource> <param name=”format”>dd/MM/yyyy</param> </resource-config>
<resource-config selector=”pedido-ativacao/dados-cliente”> <resource>org.milyn.javabean.BeanPopulator</resource> <param name=”beanId”>cliente</param> <param name=”beanClass”> br.com.mundojava.eaipatterns.pojo.Cliente</param> <param name=”bindings”> <binding property=”identificador” selector=”pedido-ativacao/dados-cliente/identificador” type=”Long” /> <binding property=”nome” selector=”pedido-ativacao/dados-cliente/nome” type=”String” /> <binding property=”cpf” selector=”pedido-ativacao/dados-cliente/cpf” type=”String” /> <binding property=”rg” selector=”pedido-ativacao/dados-cliente/rg” type=”String” /> <binding property=”dataNasc” selector=”pedido-ativacao/dados-cliente/dataNasc” type=”dataDecoder” /> </param> </resource-config>
<resource-config selector=”pedido-ativacao/enderecos/endereco-residencial”> <resource>org.milyn.javabean.BeanPopulator</resource> <param name=”beanId”>enderecoResidencial</param> <param name=”beanClass”> br.com.mundojava.eaipatterns.pojo.Endereco</param> <param name=”bindings”> <binding property=”logradouro” selector= “pedido-ativacao/enderecos/endereco-residencial/logradouro” type=”String” /> <binding property=”numero” selector=
Listagem 6. Configuração da lógica de transformação da mensagem de XML para Java.
Vamos entender como funciona a transfor-mação de mensagens via Smooks. No arquivo apresentado na Listagem 6, temos várias entra-das do tipo <resource-config>. Estas entradas indicam os mecanismos de transformação que serão aplicados numa mensagem. A primeira entrada, chamada de ‘dataDecoder’, é a configu-ração padrão sobre como ler dados referentes a datas. A tag <resource> indica qual implemen-tação será usada para realizar a transformação, e dentro da seção <resource-config>, você pode declarar zero ou mais elementos do tipo <param>, que serão parâmetros enviados para a classe indicada na tag <resource>. A API do Smooks lhe possibilita estender os transfor-
Transforma XML para Java
Cadastra Cliente no Siebel
Adequar Mensagem para Entrega
Registrar Fatura no SAP
Inserir Centro de Custo na Mensagem
Registrar Ponto na Central
Requisitar Instalação de Ponto no Cliente
13
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
<actions mep=”OneWay”> <action name=”MessageTranslator-Xml2Pojo” class=”org.jboss.soa.esb.smooks.SmooksAction”> <property name=”smooksConfig” value=”/META-INF/ativacaoPonto-smooks.xml” /> <property name=”resultType” value=”JAVA” /> </action></actions>
“pedido-ativacao/enderecos/endereco-residencial/numero” type=”Integer” /> <binding property=”complemento” selector= “pedido-ativacao/enderecos/endereco-residencial/complemento” type=”String” /> <binding property=”cep” selector= “pedido-ativacao/enderecos/endereco-residencial/cep” type=”String” /> <binding property=”cidade” selector= “pedido-ativacao/enderecos/endereco-residencial/cidade” type=”String” /> <binding property=”uf” selector= “pedido-ativacao/enderecos/endereco-residencial/uf” type=”String” /> <binding property=”bairro” selector= “pedido-ativacao/enderecos/endereco-residencial/bairro” type=”String” /> </param> </resource-config>
<resource-config selector= “pedido-ativacao/enderecos/endereco-cobranca”> <resource>org.milyn.javabean.BeanPopulator</resource> <param name=”beanId”>enderecoCobranca</param> <param name=”beanClass”> br.com.mundojava.eaipatterns.pojo.Endereco</param> <param name=”bindings”> <binding property=”logradouro” selector= “pedido-ativacao/enderecos/endereco-cobranca/logradouro” type=”String” /> <binding property=”numero” selector= “pedido-ativacao/enderecos/endereco-cobranca/numero” type=”Integer” /> <binding property=”complemento” selector= “pedido-ativacao/enderecos/endereco-cobranca/complemento” type=”String” /> <binding property=”cep” selector= “pedido-ativacao/enderecos/endereco-cobranca/cep” type=”String” /> <binding property=”cidade” selector= “pedido-ativacao/enderecos/endereco-cobranca/cidade” type=”String” /> <binding property=”uf” selector= “pedido-ativacao/enderecos/endereco-cobranca/uf” type=”String” /> <binding property=”bairro” selector= “pedido-ativacao/enderecos/endereco-cobranca/bairro” type=”String” /> </param> </resource-config>
<resource-config selector=”pedido-ativacao/detalhes-plano”> <resource>org.milyn.javabean.BeanPopulator</resource> <param name=”beanId”>detalhesPlano</param> <param name=”beanClass”> br.com.mundojava.eaipatterns.pojo.DetalhesPlano</param> <param name=”bindings”> <binding property=”tipoPlano” selector= “pedido-ativacao/detalhes-plano/tipo-plano” type=”String” /> <binding property=”suporteTecnico” selector= “pedido-ativacao/detalhes-plano/suporte-tecnico” type=”Boolean” /> </param> </resource-config>
<resource-config selector=”pedido-ativacao/detalhes-instalacao”> <resource>org.milyn.javabean.BeanPopulator</resource> <param name=”beanId”>detalhesInstalacao</param> <param name=”beanClass”> br.com.mundojava.eaipatterns.pojo.DetalhesInstalacao</param> <param name=”bindings”>
<binding property=”tipoComputador” selector= “pedido-ativacao/detalhes-instalacao/tipo-computador” type=”String” /> <binding property=”sistemaOperacional” selector= “pedido-ativacao/detalhes-instalacao/sistema-operacional” type=”String” /> <binding property=”responsavel” selector= “pedido-ativacao/detalhes-instalacao/responsavel” type=”String” /> <binding property=”dataInstalacao” selector= “pedido-ativacao/detalhes-instalacao/data-instalacao” type=”dataDecoder” /> </param> </resource-config>
</smooks-resource-list>
Listagem 7. Declarando a transformação via Smooks no serviço de ativação de ponto.
madores padrões que ele oferece, assim como criar os seus próprios transformadores. Depois da declaração do transformador de datas no início do arquivo de configuração, temos várias declarações do tipo org.milyn.javabean.BeanPopulator. Este tipo de transformador é usado quando queremos instanciar uma classe Java do nosso projeto, e popular as propriedades do objeto criado, com as informações de um documento XML. Repare então que, depois da declaração do transformador de datas, temos a declaração do transformador das informações do cliente. Na en-trada do <resource-config>, indicamos que a classe que será instanciada será a br.com.mundojava.eaipatterns.pojo.Cliente. Demos também um apelido para esta transformação, chamando-a de ‘cliente’. Por meio deste apelido, a instância deste bean poderá ser recuperada dentro do corpo da mensagem. Repare que no caso da transformação dos dados do cliente, existe uma propriedade especial configurada chamada de <bindings>. É nesta propriedade que informamos a lógica de quais propriedades do bean serão populadas, e qual será o valor do documento XML que será atribuito à propriedade. Por exemplo, repare que informamos que a propriedade ‘identificador’ da classe do cliente, será populada pelo valor armazenado em pedido-ativacao/dados-cliente/identificador. Esta no-tação usada no atributo ‘selector’ indica uma navegação no documento XML. Lembre-se que um documento XML possui a representação de uma árvore de nós. Portanto, ao mencionar uma informação do documento, você deverá indicar onde aquela informação se situa, tomando como referência o nó raiz do documento. No caso do arquivo XML enviado pelo programa COBOL, o nó raiz será o <pedido-ativacao>.
Salve as alterações feitas no arquivo META-INF/ativacaoPonto-smooks.xml. Para que este mecanismo funcione, você deverá declarar uma ação do Smooks dentro da cadeia de ações do serviço de ativação de ponto. Para isso, abra novamente o arquivo META-INF/jboss-esb.xml e altere a declaração das ações do serviço conforme mostrado na Listagem 7.
14 www.mundojava.com.br
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
Agora que nosso mecanismo de transformação de mensagens está apropriadamente configurando, temos que implementar as classes java que serão instanciadas pelo engine do Smooks. Implemente as classes mecionadas no arquivo de configuração do mecanismo Smooks (em especial, todas as classes do pacote br.com.mundojava.eaipatterns.pojo) conforme mostrado na Listagem 8. Não esqueça de implementar em cada uma das classes os métodos get() e set() (omitidos nas listagens) para compor as propriedades dos objetos Java.
import java.io.Serializable;import java.util.Date;
@SuppressWarnings(“serial”)public class Cliente implements Serializable { private long identificador; private String nome; private String rg; private String cpf; private Date dataNasc; }
//////////////////////////////////////////
package br.com.mundojava.eaipatterns.pojo;
import java.io.Serializable;import java.util.Date;
@SuppressWarnings(“serial”)public class DetalhesInstalacao implements Serializable { private String tipoComputador; private String sistemaOperacional; private String responsavel; private Date dataInstalacao; }
//////////////////////////////////////////
package br.com.mundojava.eaipatterns.pojo;
import java.io.Serializable;
@SuppressWarnings(“serial”)public class DetalhesPlano implements Serializable { private String tipoPlano; private boolean suporteTecnico; }
//////////////////////////////////////////
package br.com.mundojava.eaipatterns.pojo;
import java.io.Serializable;
@SuppressWarnings(“serial”)public class Endereco implements Serializable { private String logradouro; private int numero; private String complemento; private String cep; private String bairro; private String cidade; private String uf; }
package br.com.mundojava.eaipatterns.types;
import java.io.Serializable;
import br.com.mundojava.eaipatterns.pojo.Cliente;import br.com.mundojava.eaipatterns.pojo.Endereco;
@SuppressWarnings(“serial”)public class PedidoCadastroClienteNoSiebel implements Serializable { private long identificador; private Cliente dadosCliente; private Endereco enderecoResidencial; }
//////////////////////////////////////////
package br.com.mundojava.eaipatterns.types;
import java.io.Serializable;
import br.com.mundojava.eaipatterns.pojo.DetalhesInstalacao;import br.com.mundojava.eaipatterns.pojo.Endereco;
@SuppressWarnings(“serial”)public class PedidoInstalacaoPontoNoCliente implements Serializable { private long identificador; private Endereco enderecoResidencial; private DetalhesInstalacao detalhesInstalacao; private String centroCusto; }
//////////////////////////////////////////
package br.com.mundojava.eaipatterns.types;
import java.io.Serializable;
import br.com.mundojava.eaipatterns.pojo.DetalhesPlano;import br.com.mundojava.eaipatterns.pojo.Endereco;
@SuppressWarnings(“serial”)public class PedidoRegistroFaturaNoSAP implements Serializable { private long identificador; private DetalhesPlano detalhesPlano; private Endereco enderecoCobranca; }
//////////////////////////////////////////
Listagem 8. Implementação das classes Java usadas durante a transfor-mação da mensagem.
Listagem 9. Implementação dos tipos complexos que representam os dados esperados pelos sistemas legados.
Aplicando o padrão Message Translator para alteração do formato da mensagem
Após transformar os dados do arquivo XML para objetos Java, é hora de transformar novamente o formato da mensagem, agora para o formato esperado pelos serviços que efetuarão o processamento de cada trecho do processo. Em especial, cada sistema envolvido tem interesse em parte dos dados enviados no documento XML. Neste caso, cada serviço que representa um sistema legado possui uma estrutura de dados que aco-moda as informações de interesse do sistema legado. Essas estruturas de dados estão implementadas na forma de tipos complexos, como mostrados na Listagem 9. Implemente estes tipos de dados antes de passarmos para a implementação da conversão do formato. Lembre-se de implementar os métodos get() e set() (omitidos na listagem) para cada atributo declarado nas classes.
15
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
package br.com.mundojava.eaipatterns.impl;
import java.util.HashMap;import java.util.Map;
import org.jboss.soa.esb.actions.AbstractActionPipelineProcessor;import org.jboss.soa.esb.actions.ActionProcessingException;import org.jboss.soa.esb.helpers.ConfigTree;import org.jboss.soa.esb.message.Message;
import br.com.mundojava.eaipatterns.pojo.Cliente;import br.com.mundojava.eaipatterns.pojo.DetalhesInstalacao;import br.com.mundojava.eaipatterns.pojo.DetalhesPlano;import br.com.mundojava.eaipatterns.pojo.Endereco;import br.com.mundojava.eaipatterns.types.PedidoCadastroClienteNoSiebel;import br.com.mundojava.eaipatterns.types.PedidoInstalacaoPontoNoCliente;import br.com.mundojava.eaipatterns.types.PedidoRegistroFaturaNoSAP;import br.com.mundojava.eaipatterns.types.PedidoRegistroPontoNaCentral;
public class MessageTranslator extends AbstractActionPipelineProcessor { @SuppressWarnings(“unused”) private ConfigTree configTree; public MessageTranslator(ConfigTree configTree) { this.configTree = configTree;
} @SuppressWarnings(“unchecked”) public Message process(Message message) throws ActionProcessingException { Map<String, Object> smooksJavaResult = null; Map<String, Object> messageData = null; Cliente cliente = null; Endereco enderecoResidencial = null; Endereco enderecoCobranca = null; DetalhesPlano detalhesPlano = null; DetalhesInstalacao detalhesInstalacao = null; PedidoCadastroClienteNoSiebel pedCadCliSiebel = null; PedidoRegistroFaturaNoSAP pedRegFatSAP = null; PedidoRegistroPontoNaCentral pedRegPtCentral = null; PedidoInstalacaoPontoNoCliente pedInstPtCliente = null; try { // Recupera o objeto resultado do processamento XML2Java smooksJavaResult = (Map<String, Object>) message.getBody().get(); // Recupera cada objeto da mensagem gerado via Smooks cliente = (Cliente) smooksJavaResult.get(“cliente”); enderecoResidencial = (Endereco)smooksJavaResult.get(“enderecoResidencial”); enderecoCobranca = (Endereco)smooksJavaResult.get(“enderecoCobranca”); detalhesPlano = (DetalhesPlano)smooksJavaResult.get(“detalhesPlano”); detalhesInstalacao = (DetalhesInstalacao)smooksJavaResult.get(“detalhesInstalacao”); // Cria o pedido de cadastro do cliente no Siebel pedCadCliSiebel = new PedidoCadastroClienteNoSiebel(); pedCadCliSiebel.setIdentificador(cliente.getIdentificador()); pedCadCliSiebel.setDadosCliente(cliente); pedCadCliSiebel.setEnderecoResidencial(enderecoResidencial); // Cria o pedido de registro fatura no SAP pedRegFatSAP = new PedidoRegistroFaturaNoSAP(); pedRegFatSAP.setIdentificador(cliente.getIdentificador()); pedRegFatSAP.setEnderecoCobranca(enderecoCobranca); pedRegFatSAP.setDetalhesPlano(detalhesPlano); // Cria o pedido de registro de ponto na Central pedRegPtCentral = new PedidoRegistroPontoNaCentral(); pedRegPtCentral.setIdentificador(cliente.getIdentificador()); pedRegPtCentral.setEnderecoResidencial(enderecoResidencial); pedRegPtCentral.setDetalhesPlano(detalhesPlano); // Cria o pedido de instalação de ponto no Cliente pedInstPtCliente = new PedidoInstalacaoPontoNoCliente(); pedInstPtCliente.setIdentificador(cliente.getIdentificador()); pedInstPtCliente.setEnderecoResidencial(enderecoResidencial); pedInstPtCliente.setDetalhesInstalacao(detalhesInstalacao); // Atualiza a mensagem com os dados em novo formato messageData = new HashMap<String, Object>(); messageData.put(“pedidoCadastroClienteNoSiebel”, pedCadCliSiebel); messageData.put(“pedidoRegistroFaturaNoSAP”, pedRegFatSAP); messageData.put(“pedidoRegistroPontoNaCentral”, pedRegPtCentral); messageData.put(“pedidoInstalacaoPontoNoCliente”, pedInstPtCliente); message.getBody().add(messageData); } catch (Exception ex) { throw new ActionProcessingException(ex); } return message; } }
package br.com.mundojava.eaipatterns.types;
import java.io.Serializable;
import br.com.mundojava.eaipatterns.pojo.DetalhesPlano;import br.com.mundojava.eaipatterns.pojo.Endereco;
@SuppressWarnings(“serial”)public class PedidoRegistroPontoNaCentral implements Serializable { private long identificador; private Endereco enderecoResidencial; private DetalhesPlano detalhesPlano; }
Listagem 10. Nova transformação da mensagem, agora decompondo os dados nos tipos complexos.
Para facilitar os testes da solução no final do exemplo, im-plemente para cada tipo complexo da solução o método toString(), para que o console do JBoss ESB possa mostrar os dados de uma forma mais clara. Se você não fizer isso, o console mostrará apenas uma cadeia de caracteres que representa a referência do objeto do tipo complexo, tornando mais difícil saber se o exemplo realmente fun-cionou.
As classes implementadas na Listagem 9 representam os tipos com-plexos esperados por cada sistema que será enlaçado pela estratégia de integração. Uma vez que os dados enviados no arquivo XML foram transformados para objetos Java, precisamos agora transformar o forma-to dos dados mais uma vez, agora para organizar os dados nas estruturas esperadas pelos sistemas. Vamos então aplicar novamente o padrão Message Translator no nosso fluxo de processamento do serviço de ativação de ponto. Implemente a classe br.com.mundojava.eaipatterns.impl.MessageTranslator conforme mostrado na Listagem 10.
A Listagem 10 mostra como faremos para transformar o formato dos objetos gerados via Smooks para os tipos complexos esperados pelos sistemas legados. Para que esta transformação da mensagem faça parte do fluxo de processamento, precisamos declará-la dentro da lista de ações a serem executadas do serviço de ativação de ponto. Abra nova-
16 www.mundojava.com.br
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
mente o arquivo META-INF/jboss-esb.xml e edite-o conforme mostrado na Listagem 11.
<actions mep=”OneWay”> <action name=”MessageTranslator-Xml2Pojo” class=”org.jboss.soa.esb.smooks.SmooksAction”> <property name=”smooksConfig” value=”/META-INF/ativacaoPonto-smooks.xml” /> <property name=”resultType” value=”JAVA” /> </action> <action name=”MessageTranslator-Pojo2Types” class=”br.com.mundojava.eaipatterns.impl.MessageTranslator” /></actions>
package br.com.mundojava.eaipatterns.impl;
import java.util.Map;
import org.jboss.soa.esb.actions.AbstractActionPipelineProcessor;import org.jboss.soa.esb.actions.ActionProcessingException;import org.jboss.soa.esb.helpers.ConfigTree;import org.jboss.soa.esb.message.Message;
import br.com.mundojava.eaipatterns.types.PedidoInstalacaoPontoNoCliente;
public class ContentEnricher extends AbstractActionPipelineProcessor { private ConfigTree configTree; public ContentEnricher(ConfigTree configTree) { this.configTree = configTree; } @SuppressWarnings(“unchecked”) public Message process(Message message) throws ActionProcessingException { String centroCusto = null; Map<String, Object> messageData = null; PedidoInstalacaoPontoNoCliente pedInstPtCliente = null; try { centroCusto = (String) configTree.getAttribute(“centroCusto”); messageData = (Map<String, Object>) message.getBody().get(); pedInstPtCliente = (PedidoInstalacaoPontoNoCliente) messageData.get(“pedidoInstalacaoPontoNoCliente”); pedInstPtCliente.setCentroCusto(centroCusto); } catch (Exception ex) { throw new ActionProcessingException(ex); } return message; } }
<actions mep=”OneWay”> <action name=”MessageTranslator-Xml2Pojo” class=”org.jboss.soa.esb.smooks.SmooksAction”> <property name=”smooksConfig” value=”/META-INF/ativacaoPonto-smooks.xml” /> <property name=”resultType” value=”JAVA” /> </action> <action name=”MessageTranslator-Pojo2Types” class=”br.com.mundojava.eaipatterns.impl.MessageTranslator” /> <action name=”ContentEnricher” class=”br.com.mundojava.eaipatterns.impl.ContentEnricher “> <property name=”centroCusto” value=”CC00126532” /> </action></actions>
Listagem 11. Configuração da transformação da mensagem de POJO para tipos complexos.
Listagem 12. Inserção do centro de custo na mensagem por meio do padrão Content Enricher.
Listagem 13. Configuração da ação que insere o centro de custo na mensagem para processamento.
Uma boa prática de integração recomendada em cenários de transformação de mensagens por meio do Message Translator, é criar uma cadeia de transformação em está-gios. De fato, o padrão Pipes and Filters estimula a quebra do processamento de uma mensagem em estágios diversos, mas esta quebra pode reunir filtros correlatos, por exemplo, filtros voltados somente à transformação de mensagens. A esta prática, damos o nome de Chainning Transformations, conforme explicado no livro Enterprise Integration Patterns (Gregor Hohpe e Bobby Wolf ) página 89. Consulte nas referências informações sobre o livro.
Aplicando o padrão Content Enricher para inserção do Centro de Custo
O sistema que receberá a solicitação de instalação de ponto no cliente espera com parte dos dados o centro de custo que será usado para efe-tuar a cobrança entre a empresa e a FastNet. Este dado não é enviado no arquivo XML que é gerado pelo programa COBOL e deve ser inserido na mensagem separadamente. Para resolver este problema, iremos aplicar o padrão Content Enricher no fluxo de processamento da mensagem. Implemente a classe br.com.mundojava.eaipatterns.impl.ContentEnri-cher conforme mostrado na Listagem 12.
O padrão Content Enricher é usado quando temos que entregar uma mensagem a um determinado sistema para processamento, mas a mensagem não apresenta todos os dados que o sistema requer para execução da mesma. Neste caso, criamos um filtro na cadeia de proces-samento que insere um valor adicional na mensagem para efeitos de adaptação. Este valor inserido pode ser recuperado de qualquer fonte de dados externa, como um banco de dados, um serviço web ou até mesmo outro sistema de mensageria. Consulte nas referências mais informações sobre este padrão.
Agora que temos todos os tipos complexos criados na mensagem, iremos inserir o dado do centro de custo no tipo complexo br.com.mundojava.eaipatterns.types.PedidoInstalacaoPontoNoCliente. Na Listagem 12, é mostrado como a classe da ação irá recuperar de sua lista de proprieda-des o valor do centro de custo e atualizar o objeto da mensagem. Esta
nova ação deverá ser configurada no arquivo de configuração do mó-dulo ESB, portanto, abra o arquivo META-INF/jboss-esb.xml e edite-o conforme mostrado na Listagem 13.
17
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
package br.com.mundojava.eaipatterns.impl;
import java.util.Collections;import java.util.HashMap;import java.util.Map;
import org.jboss.soa.esb.actions.AbstractActionPipelineProcessor;import org.jboss.soa.esb.actions.ActionProcessingException;import org.jboss.soa.esb.client.ServiceInvoker;import org.jboss.soa.esb.helpers.ConfigTree;import org.jboss.soa.esb.message.Message;import org.jboss.soa.esb.message.format.MessageFactory;import org.jboss.soa.esb.message.format.MessageType;
import br.com.mundojava.eaipatterns.types.PedidoCadastroClienteNoSiebel;import br.com.mundojava.eaipatterns.types.PedidoInstalacaoPontoNoCliente;import br.com.mundojava.eaipatterns.types.PedidoRegistroFaturaNoSAP;import br.com.mundojava.eaipatterns.types.PedidoRegistroPontoNaCentral;
public class Splitter extends AbstractActionPipelineProcessor { @SuppressWarnings(“unchecked”) private Map<Class, ServiceInfo> services; @SuppressWarnings(“unchecked”) public Splitter(ConfigTree configTree) { services = Collections.synchronizedMap(new HashMap<Class, ServiceInfo>()); // Registra os dados do serviço de cadastro de cliente no Siebel String serviceCategory = configTree.getAttribute( “ctg_CadastroClienteSiebel”); String serviceName = configTree.getAttribute( “srv_CadastroClienteSiebel”); ServiceInfo srvCadCliSiebel = new ServiceInfo(serviceCategory, serviceName); services.put(PedidoCadastroClienteNoSiebel.class, srvCadCliSiebel); // Registra os dados do serviço de registro de fatura no SAP serviceCategory = configTree.getAttribute(“ctg_RegistroFaturaSAP”); serviceName = configTree.getAttribute(“srv_RegistroFaturaSAP”); ServiceInfo srvRegFatSAP = new ServiceInfo(serviceCategory, serviceName); services.put(PedidoRegistroFaturaNoSAP.class, srvRegFatSAP); // Registra os dados do serviço de ponto da Central serviceCategory = configTree.getAttribute(“ctg_RegistroPontoCentral”); serviceName = configTree.getAttribute(“srv_RegistroPontoCentral”); ServiceInfo srvRegPtCentral = new ServiceInfo(serviceCategory, serviceName); services.put(PedidoRegistroPontoNaCentral.class, srvRegPtCentral); // Registra os dados do serviço de Instalação de ponto no Cliente
serviceCategory = configTree.getAttribute( “ctg_InstalacaoPontoCliente”); serviceName = configTree.getAttribute(“srv_InstalacaoPontoCliente”); ServiceInfo srvInstPtCliente = new ServiceInfo(serviceCategory, serviceName); services.put(PedidoInstalacaoPontoNoCliente.class, srvInstPtCliente); } @SuppressWarnings(“unchecked”) public Message process(Message message) throws ActionProcessingException { Map<String, Object> messageData = null; PedidoCadastroClienteNoSiebel pedCadCliSiebel = null; PedidoRegistroFaturaNoSAP pedRegFatSAP = null; PedidoRegistroPontoNaCentral pedRegPtCentral = null; PedidoInstalacaoPontoNoCliente pedInstPtCliente = null; ServiceInvoker serviceInvoker = null; MessageFactory messageFactory = null; Message esbMessage = null; ServiceInfo srvInfo = null; try { messageData = (Map<String, Object>) message.getBody().get(); messageFactory = MessageFactory.getInstance(); // Entrega a mensagem de cadastro de clientes no Siebel pedCadCliSiebel = (PedidoCadastroClienteNoSiebel) messageData.get(“pedidoCadastroClienteNoSiebel”); srvInfo = services.get(PedidoCadastroClienteNoSiebel.class); serviceInvoker = new ServiceInvoker(srvInfo.getServiceCategory(), srvInfo.getServiceName()); esbMessage = messageFactory.getMessage(MessageType.JAVA_SERIALIZED); esbMessage.getBody().add(pedCadCliSiebel); serviceInvoker.deliverAsync(esbMessage); // Entrega a mensagem de registro de fatura no SAP pedRegFatSAP = (PedidoRegistroFaturaNoSAP) messageData.get(“pedidoRegistroFaturaNoSAP”); srvInfo = services.get(PedidoRegistroFaturaNoSAP.class); serviceInvoker = new ServiceInvoker(srvInfo.getServiceCategory(), srvInfo.getServiceName()); esbMessage = messageFactory.getMessage(MessageType.JAVA_SERIALIZED); esbMessage.getBody().add(pedRegFatSAP); serviceInvoker.deliverAsync(esbMessage); // Entrega a mensagem de registro de ponto na Central pedRegPtCentral = (PedidoRegistroPontoNaCentral) messageData.get(“pedidoRegistroPontoNaCentral”); srvInfo = services.get(PedidoRegistroPontoNaCentral.class); serviceInvoker = new ServiceInvoker(srvInfo.getServiceCategory(), srvInfo.getServiceName()); esbMessage = messageFactory.getMessage(MessageType.JAVA_SERIALIZED); esbMessage.getBody().add(pedRegPtCentral); serviceInvoker.deliverAsync(esbMessage); // Entrega a mensagem de instalação de ponto no Cliente pedInstPtCliente = (PedidoInstalacaoPontoNoCliente) messageData.get(“pedidoInstalacaoPontoNoCliente”); srvInfo = services.get(PedidoInstalacaoPontoNoCliente.class); serviceInvoker = new ServiceInvoker(srvInfo.getServiceCategory(), srvInfo.getServiceName()); esbMessage = messageFactory.getMessage(MessageType.JAVA_SERIALIZED); esbMessage.getBody().add(pedInstPtCliente); serviceInvoker.deliverAsync(esbMessage); } catch (Exception ex) { throw new ActionProcessingException(ex); } return message; } private final class ServiceInfo { private String serviceCategory; private String serviceName; public ServiceInfo(String serviceCategory, String serviceName) { this.serviceCategory = serviceCategory; this.serviceName = serviceName; } public String getServiceCategory() { return serviceCategory; } public String getServiceName() { return serviceName; } } }
Listagem 14. Implementação do padrão Splitter, responsável por sepa-rar a mensagem e entregar aos interessados.
Aplicando o padrão Splitter para realizar o roteamento dos tipos complexos
Agora que temos a mensagem com todas as informações necessárias para entrega e no formato adequado, podemos finalmente realizar o processo de entrega dos dados para os sistemas legados que aguardam pelo processamento. No estágio atual do processamento da mensagem, temos uma instância do tipo java.util.Map dentro da mensagem que contém todos os tipos complexos de interesse de cada sistema legado. O processo que faremos agora é de separar cada tipo complexo e realizar uma entrega de tal objeto sob uma mensagem do ESB para um serviço particular que faça o processamento deste no sistema legado.
A este processo de separação dos dados e entrega no correto serviço para processamento, iremos aplicar o padrão de integração Splitter. Esse padrão é usado quando queremos quebrar a mensagem do canal de processamento em partes diferentes, para que cada parte possa ser pro-cessada separadamente. Na verdade, cada parte é transformada em uma mensagem independente, e esta mensagem é enviada a um destinatário (um sistema interessado nela) por meio de um novo canal (Point-to-Point Channel) de processamento. Implemente a classe br.com.mundojava.eaipatterns.impl.Splitter conforme é mostrado na Listagem 14. Repare que é criada uma estrutura de dados interna na classe que acomoda as informações dos serviços que serão invocados pelo nosso Splitter.
18 www.mundojava.com.br
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
Para executar a entrega das mensagens para os respectivos serviços dos legados, foi criada a ação de splitter mostrado na Listagem 14. Em sua implementação, foi criada uma classe interna chamada de ServiceInfo para guardar as informações dos serviços de cada sistema legado. Duran-te a inicialização da classe, ou seja, na execução do construtor da mesma, foi criado um mecanismo de registro dos serviços a serem invocados, em particular, os serviços de cadastro de cliente no Siebel, o serviço de registro de fatura no SAP, o serviço de registro de ponto na central e o serviço de requisição de instalação de ponto no cliente.
Para cada um desses serviços, uma instância da classe ServiceInfo foi criada para armazenar as informações de categoria e nome do serviço a ser invocado. Todas as instâncias da classe ServiceInfo, depois de popu-ladas com os dados recuperados do objeto ConfigTree (que representa as propriedades que são configuradas no arquivo jboss-esb.xml para aquela ação), as instâncias foram armazenadas num objeto do tipo java.util.Map, para futura recuperação e consulta, por meio da referência da classe de cada tipo complexo.
Na execução da ação, notadamente durante a execução do método process() da classe da ação, é feita a recuperação de cada tipo complexo que será enviado para os serviços, bem como a montagem de uma men-sagem ESB particular, cujo corpo será formado pelos tipos complexos. Assim que a mensagem é criada, por meio do objeto singleton org.jboss.soa.esb.message.format.MessageFactory, é feita uma solicitação de envio de mensagem para o serviço respectivo daquele tipo complexo. Usando uma instância da classe org.jboss.soa.esb.client.ServiceInvoker, é enviada uma mensagem particular contendo somente o tipo complexo de cada serviço do legado.
Para finalizar a implementação do nosso fluxo de integração para o serviço de ativação de ponto de internet, temos que configurar a classe br.com.mundojava.eaipatterns.impl.Splitter dentro do nosso arquivo jboss-esb.xml. Abra então este arquivo e edite-o conforme mostrado na Listagem 15.
<actions mep=”OneWay”> <action name=”MessageTranslator-Xml2Pojo” class=”org.jboss.soa.esb.smooks.SmooksAction”> <property name=”smooksConfig” value=”/META-INF/ativacaoPonto-smooks.xml” /> <property name=”resultType” value=”JAVA” /> </action> <action name=”MessageTranslator-Pojo2Types” class=”br.com.mundojava.eaipatterns.impl.MessageTranslator” /> <action name=”ContentEnricher” class=”br.com.mundojava.eaipatterns.impl.ContentEnricher”> <property name=”centroCusto” value=”CC00126532” /> </action> <action name=”Splitter” class=”br.com.mundojava.eaipatterns.impl.Splitter”> <property name=”ctg_CadastroClienteSiebel” value=”MundoJava” /> <property name=”srv_CadastroClienteSiebel” value=”CadastroClienteSiebel” /> <property name=”ctg_RegistroFaturaSAP” value=”MundoJava” /> <property name=”srv_RegistroFaturaSAP” value=”RegistroFaturaSAP” /> <property name=”ctg_RegistroPontoCentral” value=”MundoJava” /> <property name=”srv_RegistroPontoCentral” value=”RegistroPontoCentral” /> <property name=”ctg_InstalacaoPontoCliente” value=”MundoJava” /> <property name=”srv_InstalacaoPontoCliente” value=”InstalacaoPontoCliente” /> </action></actions>
Listagem 15. Configuração da ação de Splitter dentro da cadeia de ações do serviço.
Repare na Listagem 15 que várias propriedades são declaradas no corpo da ação. Essas propriedades declaradas determinam as informações de todos os serviços que serão invocados a partir da classe br.com.mundojava.eai-patterns.impl.Splitter durante o processamento do método process(). Em particular, foram definidas as informações de categoria dos serviços, e os nomes dos serviços. Essas informações são recuperadas pela classe no mo-mento da execução do construtor, conforme mostrado na Listagem 16.
Configurando os serviços dos legados e testando a solução de EAI
Agora que temos definido, implementado e configurado todo o fluxo de processamento da mensagem para o serviço de ativação de ponto de internet, podemos dar início aos testes de execução. Mas, antes, temos que realizar a configuração dos serviços que serão usados no exemplo para simular o recebimento das mensagens enviadas pelo padrão Split-ter. Repare na Listagem 15 que nas propriedades da ação Splitter foram mencionados vários serviços. Esses serviços, durante a execução do Splitter, serão invocados em seqüência. Caso eles não estejam configu-randos em seu módulo ESB (ou em geral, no JBoss ESB em si por meio de outros módulos) algumas mensagens de aviso irão aparecer no console do JBoss ESB sobre a não-entrega das mensagens.
Não iremos, neste artigo, realizar a implementação de todos os serviços que representam os sistemas legados, a fim de manter o foco original sobre os padrões de transfor-mação. Mas, a esta altura, acreditamos que está claro que o acesso a sistemas legados por parte do JBoss ESB se dá pelo simples uso de ações personalizadas que por meio da mensagem enviada cria os dados a serem enviados para uma aplicação através de alguma tecnologia de acesso a dados. O JBoss ESB oferece várias ações pré-configuradas para acesso a sistemas legados nos mais diversos estilos de integração. Por exemplo, caso você deseje acessar um EJB para realizar uma operação, você pode usar a classe org.jboss.soa.esb.actions.EJBProcessor. Caso você deseje enviar a mensagem do ESB para uma Queue qualquer (até mesmo de outro servidor J2EE) via JMS, use a classe org.jboss.soa.esb.actions.routing.JMSRouter. Caso seu in-teresse seja acessar um sistema legado por meio de Web Services dado apenas o recurso WSDL do mesmo, você pode usar a classe org.jboss.soa.esb.actions.soap.wise.SOAPClient. Finalmente, o JBoss ESB possibilita o acesso a sistemas legados por meio de notificadores, usando a classe org.jboss.soa.esb.actions.Notifier. Através deste componente, você pode entregar mensagens via SQL, FTP, File System, Queues, Topics e SMTP. Opcionalmente, você pode criar um conector JCA para seu sistema legado, e acessar este conector do JBoss ESB por meio do meca-nismo de Message Inflow, usando gateways do tipo JCA.
19
SOA na Prática • Aplicando EAI Patterns sobre Transformação de Mensagens
<service category=”MundoJava” name=”CadastroClienteSiebel” description=”Cadastro de Clientes no Siebel”> <listeners> <jms-listener name=”cadastroClienteSiebelListener” busidref=”jmsCadastroClienteSiebel” /> </listeners> <actions mep=”OneWay”> <action name=”Default” class=”org.jboss.soa.esb.actions.SystemPrintln”> <property name=”message” value=”--> Executando o Cadastro do Cliente no Siebel” /> </action> </actions></service>
Listagem 16. Exemplo de configuração de serviço para o cadastro de clientes no Siebel. Considerações finais
Atente que ao configurar os serviços dos legados, você deverá realizar a configuração do <jms-bus> de cada ser-viço no arquivo jboss-esb.xml, assim como a configuração das filas JMS que serão usadas dentro do arquivo queue-service.xml. Cada serviço deverá possuir sua própria fila JMS para processamento da mensagem, comportamento necessário para garantir os canais de processamento de cada serviço. Isso é feito por meio da configuração dos elementos <jms-listener> dentro de cada serviço, e os elementos <jms-bus> na seção de providers, no início do arquivo jboss-esb.xml. As filas JMS são declaradas na forma de MBeans no arquivo queue-service.xml, e cada fila deverá ter um nome exclusivo dentro do JBoss ESB.
Neste caso, faça a configuração destes serviços dentro do arquivo META-INF/jboss-esb.xml. A Listagem 16 mostra um exemplo de configuração para o serviço de cadastro de clientes no Siebel. Faça a configuração dos demais serviços seguindo o padrão de configuração mostrado na Listagem 16, e atente que cada serviço deverá ter o nome da categoria e do serviço baseado nos nomes mostrados nas propriedades da ação Splitter.
Depois de configurar todos os serviços do exemplo, gere uma nova ver-são do módulo ESB (arquivo ativacaoPonto.esb) usando uma ferramenta de geração de arquivos Jars de sua preferência, como feito anteriormente no primeiro teste do módulo. Copie o arquivo criado (ativacaoPonto.esb) para o diretório <JBOSSESB_HOME>/server/default/deploy e espere até que o JBoss ESB reconheça a nova versão do módulo e faça a atualização do mesmo em tempo de execução. Assim que o JBoss ESB terminar a atualização, copie o arquivo Resources/pa_123456789.xml para o diretó-rio de leitura, definido no arquivo jboss-esb.xml na seção de endpoints do tipo FileSystemProvider. Depois de cinco segundos, o arquivo será lido pelo ESB, e você poderá ver pelas mensagens no console que cada serviço do legado recebeu seu tipo complexo esperado.
O comportamento esperado neste teste é que os serviços que represen-tam os sistemas legados recebam mensagens contendo apenas os tipos
complexos que lhe interessa, indicando que houve um processamento de separação da mensagem por interesse (padrão Splitter) e que houve os estágios de processamento de transformação da mensagem, como de transformar a mensagem de XML para Java (Message Translator), transformar os objetos Java gerados em tipos complexos dos sistemas legados (Message Translator) e, finalmente, enriquecer a mensagem com o valor do centro de custo (padrão Content Enricher) para entrar em con-formidade com o sistema legado de requisição de instalação de ponto.
Neste artigo, discorremos um cenário de negócio de uma empresa fictícia de serviços de internet, que apresentou um problema típico de integra-ção entre sistemas. Por meio de práticas de projetos de EAI, e o uso do servidor JBoss ESB, criamos um projeto passo a passo que se utiliza de padrões de integração voltados a transformação de mensagens. Vimos também como configurar endpoints do tipo File System dentro do JBoss ESB, bem como usar os recursos do servidor para realizar o processamen-to de mensagens com ênfase em transformação de formatos•
Referências
• EAIPatterns,Point-to-PointChannelPattern:http://www.eaipatterns.com/PointTo-PointChannel.html
• EAIPatterns,PipesandFiltersPattern:http://www.eaipatterns.com/PipesAndFilters.html
• EAI Patterns, Message Translator Pattern: http://www.eaipatterns.com/Message-Translator.html
• EAI Patterns,Content Enricher Pattern:http://www.eaipatterns.com/DataEnricher.html
• EAIPatterns,SplitterPattern:http://www.eaipatterns.com/Sequencer.html• Livro Enterprise Integration Patterns: http://www.amazon.com/exec/obidos/tg/
detail/-/0321200683• DownloaddoservidorJBossESB:http://www.jboss.org/jbossesb/downloads/• JBoss ESB, ProgrGuide: http://www.jboss.org/jbossesb/docs/4.4.GA/manuals/html/
ProgrammersGuide.html• JBoss ESB,AdmiGuide: http://www.jboss.org/jbossesb/docs/4.4.GA/manuals/html/
AdministrationGuide.html• FrameworkCodeHausSmooks:http://milyn.codehaus.org/Smooks
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
1
Windows Vista Technical Articles Windows Communication Foundation Architecture Overview
Microsoft Corporation
March 2006
Summary: Get a high-level view of the Windows Communication Foundation (WCF) architecture and its key concepts. Code examples demonstrate WCF contracts, endpoints, and behaviors. (17 printed pages)
Contents
Introduction WCF Fundamentals Code Examples Summary
Introduction
This document provides a high-level view of the Windows Communication Foundation (WCF) architecture. It is intended to explain key concepts in WCF and how they fit together. There are a few code examples to further illustrate the concepts, but code is not the emphasis of this document.
The rest of this document is organized in two main sections:
• WCF Fundamentals: Covers key concepts in WCF, terms, and architectural components. • Code Examples: Provides a few short code examples intended to illustrate and reify the concepts covered in WCF
Fundamentals.
WCF Fundamentals
A WCF Service is a program that exposes a collection of Endpoints. Each Endpoint is a portal for communicating with the world.
A Client is a program that exchanges messages with one or more Endpoints. A Client may also expose an Endpoint to receive Messages from a Service in a duplex message exchange pattern.
The following sections describe these fundamentals in more detail.
Endpoints
A Service Endpoint has an Address, a Binding, and a Contract.
The Endpoint's Address is a network address where the Endpoint resides. The EndpointAddress class represents a WCF Endpoint Address.
The Endpoint's Binding specifies how the Endpoint communicates with the world including things like transport protocol (e.g., TCP, HTTP), encoding (e.g., text, binary), and security requirements (e.g., SSL, SOAP message security). The Binding class represents a WCF Binding.
The Endpoint's Contract specifies what the Endpoint communicates and is essentially a collection of messages organized in operations that have basic Message Exchange Patterns (MEPs) such as one-way, duplex, and request/reply. The ContractDescription class represents a WCF Contract.
The ServiceEndpoint class represents an Endpoint and has an EndpointAddress, a Binding, and a ContractDescription corresponding to the Endpoint's Address, Binding, and Contract, respectively (see Figure 1).
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
2
Figure 1. Each Service's Endpoint contains an EndpointAddress, a Binding and a Contract represented by ContractDescription.
EndpointAddress
An EndpointAddress is basically a URI, an Identity, and a collection of optional headers as shown in Figure 2.
An Endpoint's security identity is normally its URI; however, in advanced scenarios the identity can be explicitly set independent of the URI using the Identity address property.
The optional headers are used to provide additional addressing information beyond the Endpoint's URI. For example, address headers are useful for differentiating between multiple Endpoints that share the same address URI.
Figure 2. EndpointAddress contains a URI and AddressProperties contains an Identity and a collection of AddressHeaders.
Bindings
A Binding has a name, a namespace, and a collection of composable binding elements (Figure 3). The Binding's name and namespace uniquely identify it in the service's metadata. Each binding element describes an aspect of how the Endpoint communicates with the world.
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
3
Figure 3. Binding class and its members
For example, Figure 4 shows a binding element collection containing three binding elements. The presence of each binding element describes part of the how of communicating with the Endpoint. The TcpTransportBindingElement indicates that the Endpoint will communicate with the world using TCP as the transport protocol. ReliableSessionBindingElement indicates that the Endpoint uses reliable messaging to provide message delivery assurances. SecurityBindingElement indicates that the Endpoint uses SOAP message security. Each binding element usually has properties that further describe the specifics of the how of communicating with the Endpoint. For example, the ReliableSessionBindingElement has an Assurances property that specifies the required message delivery assurances, such as none, at least once, at most once, or exactly once.
Figure 4. An example Binding with three binding elements
The order and types of binding elements in Bindings are significant: The collection of binding elements is used to build a communications stack ordered according to the order of binding elements in the binding elements collection. The last binding element to be added to the collection corresponds to the bottom component of the communications stack, while the first one corresponds to the top component. Incoming messages flow through the stack from the bottom upwards, while outgoing messages flow from the top downwards. Therefore the order of binding elements in the collection directly affects the order in which communications stack components process messages. Note that WCF provides a set of pre-defined bindings that can be used in the majority of scenarios instead of defining custom bindings.
Contracts
A WCF Contract is a collection of Operations that specifies what the Endpoint communicates to the outside world. Each operation is a simple message exchange, for example one-way or request/reply message exchange.
The ContractDescription class is used to describe WCF Contracts and their operations. Within a ContractDescription, each Contract operation has a corresponding OperationDescription that describes aspects of the operation such as whether the operation is one-way or request/reply. Each OperationDescription also describes the messages that make up the operation using a collection of MessageDescriptions.
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
4
A ContractDescription is usually created from an interface or class that defines the Contract using the WCF programming model. This type is annotated with ServiceContractAttribute and its methods that correspond to Endpoint Operations are annotated with OperationContractAttribute. You can also build a ContractDescription by hand without starting with a CLR type annotated with attributes.
A duplex Contract defines two logical sets of operations: A set that the Service exposes for the Client to call and a set that the Client exposes for the Service to call. The programming model for defining a duplex Contract is to split each set in a separate type (each type must be a class or an interface) and annotate the contract that represents the service's operations with ServiceContractAttribute, referencing the contract that defines the client (or callback) operations. In addition, ContractDescription contains a reference to each of the types thereby grouping them into one duplex Contract.
Similar to Bindings, each Contract has a Name and Namespace that uniquely identify it in the Service's metadata.
Each Contract also has a collection of ContractBehaviors that are modules that modify or extend the contract's behavior. The next section covers behaviors in more detail.
Figure 5. ContractDescription class describes a WCF contract
Behaviors
Behaviors are types that modify or extend Service or Client functionality. For example, the metadata behavior that ServiceMetadataBehavior implemented controls whether the Service publishes metadata. Similarly, the security behavior controls impersonation and authorization, while the transactions behavior controls enlisting in and auto-completing transactions.
Behaviors also participate in the process of building the channel and can modify that channel based on user-specified settings and/or other aspects of the Service or Channel.
A Service Behavior is a type that implements IServiceBehavior and applies to Services. Similarly, a Channel Behavior is a type that implements IChannelBehavior and applies to Client Channels.
Service and Channel Descriptions
The ServiceDescription class is an in-memory structure that describes a WCF Service including the Endpoints exposed by the Service, the Behaviors applied to the Service, and the type (a class) that implements the Service (see Figure 6). ServiceDescription is used to create metadata, code/config, and channels.
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
5
You can build this ServiceDescription object by hand. You can also create it from a type annotated with certain WCF attributes, which is the more common scenario. The code for this type can be written by hand or generated from a WSDL document using a WCF tool called svcutil.exe.
Although ServiceDescription objects can be created and populated explicitly, they are often created behind the scenes as part of running the Service.
Figure 6. ServiceDescription object model
Similarly on the client side, a ChannelDescription describes a WCF Client's Channel to a specific Endpoint (Figure 7). The ChannelDescription class has a collection of IchannelBehaviors, which are Behaviors applied to the Channel. It also has a ServiceEndpoint that describes the Endpoint with which the Channel will communicate.
Note that, unlike ServiceDescription, ChannelDescription contains only one ServiceEndpoint that represents the target Endpoint with which the Channel will communicate.
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
6
Figure 7. ChannelDescription object model
WCF Runtime
The WCF Runtime is the set of objects responsible for sending and receiving messages. For example, things like formatting messages, applying security, and transmitting and receiving messages using various transport protocols, as well as dispatching received messages to the appropriate operation, all fall within the WCF runtime. The following sections explain the key concepts of the WCF runtime.
Message
The WCF Message is the unit of data exchange between a Client and an Endpoint. A Message is essentially an in-memory representation of a SOAP message InfoSet. Note that Message is not tied to text XML. Rather, depending on which encoding mechanism is used, a Message can be serialized using the WCF binary format, text XML, or any other custom format.
Channels
Channels are the core abstraction for sending Messages to and receiving Messages from an Endpoint. Broadly speaking, there are two categories of Channels: Transport Channels handle sending or receiving opaque octet streams using some form of transport protocol such as TCP, UDP, or MSMQ. Protocol Channels, on the other hand, implement a SOAP-based protocol by processing and possibly modifying messages. For example, the security Channel adds and processes SOAP message headers and may modify the body of the message by encrypting it. Channels are composable such that a Channel may be layered on top of another Channel that is in turn layered on top of a third Channel.
EndpointListener
An EndpointListener is the runtime equivalent of a ServiceEndpoint. The EndpointAddress, Contract, and Binding of ServiceEndpoint (representing where, what and how), correspond to the EndpointListener's listening address, message filtering and dispatch, and channel stack, respectively. The EndpointListener contains the Channel stack that is responsible for sending and receiving messages.
ServiceHost and ChannelFactory
The WCF Service runtime is usually created behind the scenes by calling ServiceHost.Open. ServiceHost (Figure 6) drives the creation of a ServiceDescription from on the Service type and populates the ServiceDescription's ServiceEndpoint collection with
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
7
Endpoints defined in config or code, or both. ServiceHost then uses the ServiceDescription to create the channel stack in the form of an EndpointListener object for each ServiceEndpoint in the ServiceDescription.
Figure 8. ServiceHost object model
Similarly, on the client side, the Client runtime is created by a ChannelFactory, which is the Client's equivalent of ServiceHost.
ChannelFactory drives the creation of a ChannelDescription based on a Contract type, a Binding, and an EndpointAddress. It then uses this ChannelDescription to create the Client's channel stack.
Unlike the Service runtime, the Client runtime does not contain EndpointListeners because a Client always initiates connection to the Service, so there is no need to "listen" for incoming connections.
Code Examples
This section provides code examples that show how Services and Clients are built. These examples are intended to reify the above concepts and not to teach WCF programming.
Defining and Implementing a Contract
As mentioned above, the easiest way to define a contract is creating an interface or a class and annotating it with ServiceContractAttribute, allowing the system to easily create from it a ContractDescription.
When using interfaces or classes to define contracts, each interface or class method that is a member of the contract must be annotated with OperationContractAttribute. For example:
Copy using System.ServiceModel; //a WCF contract defined using an interface [ServiceContract] public interface IMath { [OperationContract] int Add(int x, int y); }
Implementing the contract in this case is simply a matter of creating a class that implements IMath. That class becomes the WCF Service class. For example:
Copy //the service class implements the interface public class MathService : IMath { public int Add(int x, int y) { return x + y; } }
Defining Endpoints and Starting the Service
Endpoints can be defined in code or in config. In the example below, the DefineEndpointImperatively method shows the easiest way to define Endpoints in code and start the service.
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
8
DefineEndpointInConfig method shows the equivalent endpoint defined in config (config example follows the code below).
Copy public class WCFServiceApp { public void DefineEndpointImperatively() { //create a service host for MathService ServiceHost sh = new ServiceHost(typeof(MathService)); //use the AddEndpoint helper method to //create the ServiceEndpoint and add it //to the ServiceDescription sh.AddServiceEndpoint( typeof(IMath), //contract type new WSHttpBinding(), //one of the built-in bindings "http://localhost/MathService/Ep1"); //the endpoint's address //create and open the service runtime sh.Open(); } public void DefineEndpointInConfig() { //create a service host for MathService ServiceHost sh = new ServiceHost (typeof(MathService)); //create and open the service runtime sh.Open(); } } <!-- configuration file used by above code --> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.serviceModel> <services> <!-- service element references the service type --> <service type="MathService"> <!-- endpoint element defines the ABC's of the endpoint --> <endpoint address="http://localhost/MathService/Ep1" binding="wsHttpBinding" contract="IMath"/> </service> </services> </system.serviceModel> </configuration>
Sending Messages to an Endpoint
The code below shows two ways to send a message to the IMath endpoint. SendMessageToEndpoint hides the Channel creation, which happens behind the scenes while the SendMessageToEndpointUsingChannel example does it explicitly.
The first example in SendMessageToEndpoint uses a tool named svcutil.exe and the Service's metadata to generate a Contract (IMath in this example), a proxy class (MathProxy in this example) that implements the Contract, and associated config (not shown here). Again, the Contract defined by IMath specifies the what (i.e., the operations that can be performed), while the generated config contains a Binding (the how) and an address (the where).
Using this proxy class is simply a matter of instantiating it and calling the Add method. Behind the scenes, the proxy class will create a Channel and use that to communicate with the Endpoint.
The second example in SendMessageToEndpointsUsingChannel below shows communicating with an Endpoint using ChannelFactory directly. In this example, instead of using a proxy class and config, a Channel is created directly using ChannelFactory<IMath>.CreateChannel. Also, instead of using config to define the Endpoint's address and Binding, the ChannelFactory<IMath> constructor takes those two pieces of information as parameters. The third piece of information required to define an Endpoint, namely the Contract, is passed in as the type T.
Copy using System.ServiceModel; //this contract is generated by svcutil.exe //from the service's metadata public interface IMath { [OperationContract] public int Add(int x, int y) { return x + y; } }
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
9
//this class is generated by svcutil.exe //from the service's metadata //generated config is not shown here public class MathProxy : IMath { ... } public class WCFClientApp { public void SendMessageToEndpoint() { //this uses a proxy class that was //created by svcutil.exe from the service's metadata MathProxy proxy = new MathProxy(); int result = proxy.Add(35, 7); } public void SendMessageToEndpointUsingChannel() { //this uses ChannelFactory to create the channel //you must specify the address, the binding and //the contract type (IMath) ChannelFactory<IMath> factory=new ChannelFactory<IMath>( new WSHttpBinding(), new EndpointAddress("http://localhost/MathService/Ep1")); IMath channel=factory.CreateChannel(); int result=channel.Add(35,7); factory.Close(); } }
Defining a Custom Behavior
Defining a custom Behavior is a matter of implementing IServiceBehavior (or IChannelBehavior for client-side behaviors). The code below shows an example behavior that implements IServiceBehavior. In IServiceBehavior.ApplyBehavior, the code inspects the ServiceDescription and writes out the Address, Binding, and Contract of each ServiceEndpoint, as well as the name of each Behavior in the ServiceDescription.
This particular behavior is also an attribute (inherits from System.Attribute), making it possible to apply declaratively as will be shown below. However, behaviors are not required to be attributes.
Copy [AttributeUsageAttribute( AttributeTargets.Class, AllowMultiple=false, Inherited=false)] public class InspectorBehavior : System.Attribute, System.ServiceModel.IServiceBehavior { public void ApplyBehavior( ServiceDescription description, Collection<DispatchBehavior> behaviors) { Console.WriteLine("-------- Endpoints ---------"); foreach (ServiceEndpoint endpoint in description.Endpoints) { Console.WriteLine("--> Endpoint"); Console.WriteLine("Endpoint Address: {0}", endpoint.Address); Console.WriteLine("Endpoint Binding: {0}", endpoint.Binding.GetType().Name); Console.WriteLine("Endpoint Contract: {0}", endpoint.Contract.ContractType.Name); Console.WriteLine(); } Console.WriteLine("-------- Service Behaviors --------"); foreach (IServiceBehavior behavior in description.Behaviors) { Console.WriteLine("--> Behavior"); Console.WriteLine("Behavior: {0}", behavior.GetType().Name); Console.WriteLine(); } } }
Applying a Custom Behavior
All behaviors can be applied imperatively by adding an instance of the behavior to the ServiceDescription (or the ChannelDescription on the client side). For example, to apply the InspectorBehavior imperatively you would write:
Windows Communication Foundation Architecture Overview http://msdn.microsoft.com/en-us/library/aa480210.aspx
10
Copy ServiceHost sh = new ServiceHost(typeof(MathService)); sh.AddServiceEndpoint( typeof(IMath), new WSHttpBinding(), "http://localhost/MathService/Ep1"); //Add the behavior imperatively InspectorBehavior behavior = new InspectorBehavior(); sh.Description.Behaviors.Add(behavior); sh.Open();
Additionally, behaviors that inherit from System.Attribute may be applied declaratively to the service. For example, because InspectorBehavior inherits from System.Attribute, it can be applied declaratively like this:
Copy [InspectorBehavior] public class MathService : IMath { public int Add(int x, int y) { return x + y; } }
Summary
WCF Services expose a collection of Endpoints where each Endpoint is a portal for communicating with the world. Each Endpoint has an Address, a Binding, and a Contract (ABC). The Address is where the Endpoint resides, the Binding is how the Endpoint communicates, and the Contract is what the Endpoint communicates.
On the Service, a ServiceDescription holds the collection of ServiceEndpoints each describing an Endpoint that the Service exposes. From this description, ServiceHost creates a runtime that contains an EndpointListener for each ServiceEndpoint in the ServiceDescription. The Endpoint's address, Binding, and Contract (representing the where, what, and how) correspond to the EndpointListener's listening address, message filtering and dispatch, and channel stack, respectively.
Similarly, on the Client, a ChannelDescription holds the one ServiceEndpoint with which the Client communicates. From this ChannelDescription, ChannelFactory creates the channel stack that can communicate with the Service's Endpoint.