notas de aula – v4 janeiro de 2012 - frança.pro.br · possam atender à interoperabilidade e...

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

[email protected]

http://www.franca.pro.br/prof


Esta página foi deixada propositadamente em branco.


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!


Í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


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


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


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.


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,


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


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.


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


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)?


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.


• 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


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


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).


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.


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?


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


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.


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();

}

}


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);

}

}

}


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";

}

}


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.


• 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


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()); } }


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.


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


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


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


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


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?


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.


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).


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;

}

}


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,


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.


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”.


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?


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.


• 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


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.


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;


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


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


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


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?


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?


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.


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).


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.


• 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?


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.


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.


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.


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


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


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..


• 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?


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,


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.


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.


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


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.


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%.


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.


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:


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?


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


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.


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.


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


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.


Outras Questões

• WCF.

Exercícios

1. É possível trabalhar com WCF (ou .NET Remoting) através de um firewall?


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


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.



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


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.



<?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


<?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.



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


<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.



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; }

//////////////////////////////////////////


import java.io.Serializable;

@SuppressWarnings(“serial”)public class DetalhesPlano implements Serializable { private String tipoPlano; private boolean suporteTecnico; }

//////////////////////////////////////////



@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 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; }

//////////////////////////////////////////



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; }

//////////////////////////////////////////



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


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; } }



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-



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>


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



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.



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


<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).


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.


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.


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.


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.


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


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.

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 xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.serviceModel> <services>  <service type="MathService">  <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; } }


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:


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.

notas de aula – v4 janeiro de 2012 - frança.pro.br · possam atender à interoperabilidade e...

Documents