sdII - Franca

FACULDADE DE INFORMTICA 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 (CD) COMPUTAO DISTRIBUDA
Perodo 7o
Carga Horria 120
Notas de Aula v4 Janeiro de 2012
Professor M. Frana professor@franca.pro.br http://www.franca.pro.br/prof

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 1
Esta pgina foi deixada propositadamente em branco.
O Autor
Marcelo Frana tcnico em Processamento de Dados, tecnlogo em Processamento de Dados, analista de sistemas ps-graduado pela PUC-Rio, bacharel em Administrao de Sistemas de Informao, licenciado em Informtica pelo Instituto Superior de Educao do Rio de Janeiro ISERJ, mestre em Informtica pela Universidade Federal do Estado do Rio de Janeiro UNIRIO, aluno do MBA em gerenciamento de projetos da Fundao Getlio Vargas, certificado MCAD pela Microsoft, certificado SCJA pela Sun, certificado RAD Associate pela IBM, certificado OCJP 6 (SCJP) pela Oracle, professor de Informtica da FAETEC e da Faculdade de Informtica Lemos de Castro, e especialista de sistemas da IBM Brasil. Estuda Informtica desde 1990 e trabalha com Informtica desde 1994.
Dedicatria
Dedico este trabalho a todos os meus alunos e ex-alunos. Desejo a todos vocs muito sucesso profissional. Que seus objetivos sejam alcanados e que vocs sempre perseverem, mantendo o foco!
Agradecimentos
Agradeo ao Professor Walter Henrique pelo voto de confiana, e por ter me aberto as portas da FILC. Obrigado, professor!
ndice
Aula 1 Aspectos Estratgicos da Computao Distribuda ....................................... 9 Introduo....................................................................................................... 9 Sistema Distribudo........................................................................................... 9 Histrico .......................................................................................................... 9 Tecnologias ................................................................................................... 10 Padres para Aplicaes .................................................................................. 11 EAI Enterprise Application Integration ou Integrao de Aplicaes Corporativas . 12 Enterprise Architecture .................................................................................... 12 A Profisso de Arquiteto .................................................................................. 13 Outras Questes............................................................................................. 14 Exerccios ...................................................................................................... 14 Aula 2 Middlewares ......................................................................................... 15 Introduo..................................................................................................... 15 Middleware .................................................................................................... 15 Taxonomia..................................................................................................... 16 Stubs vs. Skeletons ........................................................................................ 16 Queue VS. Topic ............................................................................................. 18 Servidores de Aplicao................................................................................... 19 Outras Questes............................................................................................. 19 Exerccios ...................................................................................................... 19 Aula 3 Objetos Distribudos (Java IDL) [ESTUDO DIRIGIDO] ................................ 21 Introduo..................................................................................................... 21 Serializao e RMI ............................................................................................. 26 Serializao e Persistncia ............................................................................... 26 Introduo ao RMI .......................................................................................... 27 Outras Questes............................................................................................. 29 Exerccios ...................................................................................................... 29 Aula 4 Balanceamento de Carga ....................................................................... 31 Introduo..................................................................................................... 31 Recursos ....................................................................................................... 31 Taxonomia..................................................................................................... 32 Polticas de Escalonamento .............................................................................. 33 Outras Questes............................................................................................. 34 Exerccios ...................................................................................................... 35 Aula 5 Algoritmos Distribudos .......................................................................... 37 Introduo..................................................................................................... 37
Breve Histrico .............................................................................................. 37 Caractersticas dos Sistemas Distribudos .......................................................... 38 Computao Concorrente ................................................................................ 39 Comunicao ................................................................................................. 39 Taxonomia .................................................................................................... 40 Caractersticas ............................................................................................... 41 Outras Questes ............................................................................................ 41 Exerccios ...................................................................................................... 42 Aula 6 Banco de Dados Distribudos .................................................................. 45 Introduo .................................................................................................... 45 Consideraes Importantes ............................................................................. 45 Vantagens de bancos de dados distribudos ....................................................... 45 Desvantagens de banco de dados distribudos ................................................... 46 Arquitetura de um banco de dados distribudos em Oracle ................................... 47 Transaes Distribudas .................................................................................. 49 Outras Questes ............................................................................................ 52 Exerccios ...................................................................................................... 52 Aula 7 Tolerncia a Falhas em Ambiente Distribudo ........................................... 55 Introduo .................................................................................................... 55 Mitigar Riscos ................................................................................................ 55 Soluo ........................................................................................................ 56 Outras Questes ............................................................................................ 57 Exerccios ...................................................................................................... 58 Aula 8 Segurana em Ambientes Distribudos ..................................................... 59 Cenrio-Exemplo............................................................................................ 59 Sub-net Masking ............................................................................................ 59 Motivao ..................................................................................................... 59 Desafios ........................................................................................................ 59 Conceitos Bsicos........................................................................................... 60 Cuidados ....................................................................................................... 60 Ataque (Taxonomia):...................................................................................... 61 Polticas de Segurana .................................................................................... 61 Criptografia ................................................................................................... 62 Concluso ..................................................................................................... 64 Outras Questes ............................................................................................ 64 Exerccios ...................................................................................................... 65 Aula 9 Computao em Grade .......................................................................... 67
Histrico ........................................................................................................ 67 Internet/Web Como Plataforma ........................................................................ 68 Tecnologias ................................................................................................... 68 Concluso ...................................................................................................... 69 Outras Questes............................................................................................. 70 Exerccios ...................................................................................................... 71 Aula 10 Anlise de Desempenho de SD [ESTUDO DIRIGIDO] ............................... 73 Introduo..................................................................................................... 73 Benchmark .................................................................................................... 75 Outras Questes............................................................................................. 76 Exerccios ...................................................................................................... 76 Aula 11 Componentes para Computao Distribuda ............................................ 77 Introduo..................................................................................................... 77 Componentes Distribudos ............................................................................... 77 Desenvolvimento Orientado a Componentes ...................................................... 78 Padres para Empacotamento e Distribuio ...................................................... 78 Outras Questes............................................................................................. 79 Exerccios ...................................................................................................... 79 Aula 12 Microsoft .NET Remoting ...................................................................... 81 Introduo..................................................................................................... 81 DCOM ........................................................................................................... 81 .NET Remoting ............................................................................................... 81 .NET Framework ............................................................................................. 81 Diferenas entre o Microsoft .NET Remoting e o DCOM ........................................ 82 Outras Questes............................................................................................. 83 Exerccios ...................................................................................................... 83 Bibliografia/Crditos .......................................................................................... 85 Apndice A Questionrio de Avaliao do Curso .................................................. 87
Aula 1 Aspectos Estratgicos da Computao Distribuda

Introduo
Estratgia competitiva o conjunto de planos, polticas, programas e aes desenvolvidos por uma empresa ou unidade de negcios para ampliar ou manter, de modo sustentvel, suas vantagens competitivas (inclui oferecer valor agregado) frente aos concorrentes. Para Ohmae (1983), ... Sem competidores no haveria necessidade de estratgia, pois o nico propsito do planejamento estratgico tornar a empresa apta a ganhar, to eficientemente quanto possvel, uma vantagem sustentvel sobre seus concorrentes. .... Para Porter (1985), A estratgia competitiva visa estabelecer uma posio lucrativa e sustentvel contra as foras que determinam a competio industrial. A informtica (TI) suporte para a estratgia corporativa (sistemas de informao versus cincia da computao). Implementar sistemas distribudos (SD) uma forma de se operacionalizar este suporte.
Sistema Distribudo
Definio de um SD: vrios computadores, interconectados por uma rede, compartilhando um estado. Comunicao por mensagem (sncronas ou assncronas) entre os componentes. Exemplos de SD: Internet, Web, DNS, Multiprocessador, Cluster, Grid. Cenrios favorveis distribuio (motivao): problema distribudo (groupware), escalabilidade (horizontal) e confiabilidade (dependability) so caractersticas desejveis. Caractersticas de um SD: [heterogeneidade,] modularidade, escalabilidade,
compartilhamento de recursos, degradao paulatina, mais sujeito a ataques (maior rea), custo menor (ao longo do tempo)[, controle distribudo]. Valores agregados com a distribuio: redundncia (suporte a falhas, disponibilidade), flexibilidade, manutenibilidade (crescimento modular), integrao de servios. Entretanto, o custo com gerncia tende a aumentar - TCO.
Histrico
Histrico dos sistemas distribudos: 1. acesso remoto (terminais/mainframes) 2. distribuio de arquivos e memria (workstations) 3. servidores de arquivo (fator custo) 4. arquitetura cliente-servidor (downsizing) 5. cliente servidor em trs camadas (thin client/www) 6. arquitetura peer-to-peer (P2P) 7. computao ubqua (pervasive computing) faculdade, trabalho, praia, etc.. Impulsionadores da evoluo das arquiteturas: avanos tecnolgicos e mudanas nos requisitos definidos pelos usurios.
Processos de Negcio: Representam as atividades relacionadas a negcios do dia-a-dia de uma empresa. Centralizados ou distribudos em mltiplos sites (carros so projetados em um lugar, montados em muitos lugares e comercializados em diversos outros lugares). Anos 60, 70 e 80: Processos de Negcios Centralizados. Sistemas de Informao centralizados (CPD). Processamento centralizado. Poder dos negcios centralizado. Aplicaes centralizadas. Indstria dos computadores guiada mais pela tecnologia do que pelas necessidades dos usurios. Vendedores so controladores do mercado. Mercado de massa. Tempo longo para firmar presena no mercado. Tempo longo entre concepo e entrega. Anos 90: Novo Ambiente de Negcios. Demanda cada vez mais sofisticada. Maior nmero de concorrentes. Concorrncia acirrada. Necessidades de respostas rpidas (ondemand): novos produtos e novos servios. Os vendedores j no mais controlam o mercado. Clientes que mandam: tratamento individualizado (Amazon.com); Informam o que desejam, como desejam e quanto pagaro (eBay, MercadoLivre); Produtos configurados (personalizados, customizados Fiat.com.br); Cronogramas de entrega; Prazos de
pagamentos mais convenientes. Organizaes novatas no obedecem s definem as regras (copyright & Internet).
regras, elas
Disperso dos Sistemas de Informaes. Disperso dos negcios (Internet). Disperso do poder de processamento. Disperso das aplicaes. Diminuio dos sistemas proprietrios (crescimento do Open Source e Padres Abertos xml, webservices). Departamentos adquirem recursos computacionais (fim do CPD). Globalizao. Para atender a estas exigncias: Interao e cooperao crescentes entre grupos de trabalhos e departamentos nas empresas (Intranet), assim como entre empresas (Extranet). Mudanas organizacionais (culturais) drsticas. Groupware. Reengenharia Empresarial: Mudanas maiores nas prprias estruturas organizacionais: Reengenharia Empresarial: O repensar fundamental e a reestruturao radical dos processos empresariais, objetivando alcanar drsticas melhorias em indicadores crticos e
contemporneos de nveis de desempenho: custos, qualidade, atendimento e rapidez. Para satisfazer a estes e outros desafios competitivos, empresas esto crescendo contando com as Tecnologias da Informao (TI). Negcios esto sendo fundamentalmente transformados atravs das Tecnologias da Informao.
Tecnologias
RPC, Middleware (integrar a empresa, programa de computador que faz a mediao entre outros softwares) Orientados a Mensagem, OSF DCE (industry-standard, vendor-neutral set of distributed computing technologies), Middleware de Dados Distribudos (gateways SQL, ODBC, JDBC), Middleware de Processamento de Transaes, Cliente/Servidor, Servios de rede (sockets TCP/IP), Servidores de Replicao, Groupware, Multimdia, WWW (gateways,
servidores e browsers), Objetos Distribudos (CORBA, OLE, OpenDoc, Microsoft .NET Remoting), Middleware para Computao Mvel. Tecnologia da Informao, com as funcionalidades oferecidas pela Computao Distribuda, adequa-se perfeitamente como fornecedora de solues para as organizaes que buscam os modelos adotados pela Reengenharia. Sistemas Proprietrios (Hardware + Software): Muitas empresas fornecedoras de sistemas de computadores consideravam seu diferencial de competitividade baseado em tecnologias proprietrias. Portabilidade de aplicaes era quase impossvel. Preos
exagerados, gerando grandes lucros para os fornecedores. Sistemas Abertos: Com o advento de microprocessador (Anos 80), os fabricantes viram seu poder comear a ser contestado. Grupos de interesse: Grupo de Desenvolvedores de Software, Grupos de Usurios, Grupo dos Fabricantes de Hardware. Exigncia: padres para os produtos de Tecnologia da Informao. Os sistemas abertos formam um conjunto compreensivo de padres internacionais para a Tecnologia da Informao, que especificam interfaces, servios e suporte a formatos que possam atender interoperabilidade e portabilidade de aplicaes, dados (xml) e pessoas. Uma metodologia para a integrao de tecnologias divergentes, permitindo que se crie um ambiente flexvel para resolver os problemas de negcios de uma organizao, atravs do uso de software e hardware abertos, isto no proprietrios. A fora de sustentao dos sistemas abertos a independncia de fornecedores. rgos de Padronizao: 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).
Padres para Aplicaes

API (Interface de Programao de Aplicaes). O que posso fazer com essa aplicao? Estensibilidade. Permitir que um mesmo sistema operacional suporte diversos conjuntos de interfaces, no sentido de que as aplicaes possam ser executadas em qualquer sistema operacional que suporte esse conjunto de interfaces. Aplicaes 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 Computao Distribuda fornece toda a infraestrutura necessria para a construo e operao efetiva de aplicaes distribudas e engloba todos os produtos necessrios para permitir que essas aplicaes sejam construdas e possam ser executadas em um ambiente de rede heterogneo, ou em um ambiente centralizado. A infra-estrutura para a Computao Distribuda (CD) no precisa basear-se, obrigatoriamente, em sistemas abertos. Podem ser suportados elementos abertos ou proprietrios. Porm, medida que a complexidade e o nmero de aplicaes construdas em
uma plataforma de CD forem crescendo, ento diferentes ambientes operacionais e plataformas de HW vo estar presentes. Nestas circunstncias, prudente o uso de interfaces o mais abertas possveis.
EAI Enterprise Application Integration ou Integrao de Aplicaes Corporativas

Com o objetivo de conter custos durante as mudanas de negcios, as indstrias de tecnologia freqentemente necessitam integrar suas aplicaes com sistemas legados sob diferentes plataformas. Esta necessidade tem criado uma rea de atuao atualmente conhecida como mercado de integrao de aplicaes. O termo EAI ou Enterprise Application Integration novo, mas sugere toda essa integrao. , ainda, o termo formal que contempla a integrao de aplicaes corporativas e de um conjunto de ferramentas e tecnologias. A dependncia das corporaes em relao tecnologia tem crescido e se tornado mais complexa. Por isso, a integrao de aplicaes em um nico arsenal de processos de negcios tem se tornado prioridade para o sucesso de uma empresa. No contexto de EAI, uma figura de destaque o broker, ncleo das integraes. O Broker fica no centro das integraes fazendo o roteamento das mensagens para os seus destinatrios. Tambm faz a verificao das regras de negcio e transformaes necessrias. O objetivo substituir integraes ponto a ponto, principalmente reutilizando mensagens. A sada 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 Profisso de Arquiteto
Arquitetos definem arquitetam solues para problemas de negcios de clientes atravs da aplicao fundamentada da Tecnologia; Essas solues podem incluir sistemas e/ou processos e geralmente envolvem a aplicao ou integrao de uma variedade de produtos, tecnologias e servios; Caractersticas gerais de um arquiteto incluem: Experincia no ciclo de vida completo de solues; Amplo conhecimento de tecnologia; Experincia em diversos casos; Bom comunicador; Liderana tcnica; Usa metodologias formais; Produz arquiteturas de valor;
A demanda por arquitetos est aumentando. Mais detalhes em http://www.slideshare.net/msavio/slideshows

Outras Questes
Carreira (Punto VS. MBA) No ser um profissional bit/byte (estar antenado ao negcio da empresa). Que tal R$ 5.000 (CLT) em uma grande empresa? P, no d... Que perfil esse? (Especialista em Middleware/Integrao) Viso estratgica de TI (maximizar lucros, reduzir custos, sempre estamos empregados). Engenharia de Produo (Analista de Negcios) Clusterizao versus Virtualizao (Mainframes Z10/ZOS) custo Oracle por processador.
Exerccios
1. O que so sistemas distribudos, e como eles podem ajudar na estratgia competitiva de uma empresa? 2. Cite caractersticas encontradas em sistemas distribudos. 3. O que dependability? 4. O que Groupware? 5. Relacione Sistemas Proprietrio e Sistemas Abertos com o histrico da tecnologia da informao. 6. O que uma API? Qual a relao desse conceito com o sucesso (aceitao) da tecnologia Java? 7. Quais os dois entendimentos mais comuns para o termo EAI? 8. No contexto de EAI, defina Broker. 9. Relacione padres de mercado, solues de TI e TCO. 10.O que faz um arquiteto (de integrao)?
Aula 2 Middlewares
Introduo
Sistema distribudo (SD): coleo de componentes, distribudos entre vrios computadores conectados via uma rede. Esses componentes interagem a fim de trocar dados ou acessar os servios uns dos outros. Essa interao pode ser construda diretamente atravs 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 interaes entre esses componentes.
Middleware
Camada de software que permite a comunicao entre aplicaes (distribudas); Um conjunto de servios que fornece comunicao e distribuio de forma transparente aplicao: Middleware permite que processos em diferentes espaos de endereamento consigam se comunicar. Objetivo: Facilitar o desenvolvimento de aplicaes e a integrao de sistemas legados (adaptadores) ou desenvolvidos de forma no integrada (transparncia). Ajudam a gerenciar a complexidade e a heterogeneidade inerentes ao desenvolvimento de aplicaes e sistemas distribudos; Mascara a heterogeneidade com que os programadores de aplicaes distribudas tm que lidar: Rede & hardware; Sistemas operacionais & linguagem de programao; Localizao, acesso, falhas, concorrncia; Diferentes plataformas de middleware. Middleware deve fornecer: Facilidade de Uso - Middleware deve ser mais fcil de usar do que escrever uma interface de comunicao de baixo nvel usando sockets; Transparncia de Localizao - Deve ser possvel mover uma aplicao para um endereo de rede diferente sem a necessidade de recompilar qualquer software (diminuir o acoplamento/DNS); Transparncia 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. Servios Oferecidos: Infra-estrutura: Encapsulam e melhoram os mecanismos de concorrncia e comunicao nativos do sistema operacional. Ex. estabelecimento de conexo, sincronizao, (un) marshalling (serializao). Ex.: RPC, ACE (Adaptive
Communication Environment) abstraem as peculiaridades dos SOs. Distribuio, remotabilidade: Permitem a integrao de aplicaes remotas de forma transparente. Exemplo: Brokers CORBA, RMI, SOAP. Definem modelos de programao que permitem a construo de aplicaes distribudas, onde a comunicao abstrada.
Comuns: Servios independentes do domnio de aplicao que fazem uso da infra-estrutura de distribuio/comunicao. Ex. segurana, transao.
Especficos, outros: Diretamente relacionados a domnios especficos. Exemplo de domnios: telecomunicaes (URAs, CTI), comrcio eletrnico, automao, sade, computao mvel.
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. Denominaes Equivalentes: Modelos de Integrao de Objetos, Plataformas de Distribuio 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). Idia bsica: no que concerne ao processo cliente, no h diferena lgica entre chamar um procedimento local ou um remoto. Uma chamada remota de procedimento usa comunicao direta, orientada a conexo e sncrona para permitir a um processo cliente chamar um procedimento remoto. Paradigma criado pela Sun como parte de sua plataforma Open Network Computing (ONC). Servios: comunicao sncrona (request/wait-for-reply). Vrios problemas devem ser tratados pelo programador. Exemplo: Falhas na comunicao.
Stubs vs. Skeletons
Dado (marshalling)
.--...
(unmarshalling) Dado
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
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 parmetros 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 parmetros (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 Transao: Conhecidos como Monitores de Processamento de Transaes (transaction-processing - TP). Chamada de procedimento remoto + controle de transaes. Principais Servios: Comunicao sncrona/assncrona, Transao, Outros
Servios: Segurana e integridade de dados, Tuning, Balanceamento de carga, Entrega confivel dos dados, Servios de nomes - facilitam a descoberta de recursos distribudos. Usado em aplicaes que demandam rapidez na execuo de transaes remotas. Frequentemente usado com aplicaes de bancos de dados distribudos. Tipicamente, os monitores de TP no so usados para comunicao aplicao-aplicao. Mas, fornecem um ambiente completo para aplicaes de transaes que acessam bancos relacionais. Exemplo: BEA Tuxedo. Construdo sobre uma arquitetura orientada a servios (Service Oriented Architecture - SOA). Sua plataforma para processamento de transaes fornece a infra-estrutura necessria para: consolidar solues para aumentar a acessibilidade e passagem de de aplicaes existentes; a maior
transaes
mensagens;
garantir
disponibilidade e o maior throughput possvel de aplicaes; aumentar a eficincia de processamento e melhorar a gerncia de recursos. Middleware Orientado a Mensagem (Message Oriented Middleware MOM): o mais usado, mais comum. Comunicao atravs de passagem de mensagens; Tecnologia
inerentemente assncrona, e com fraco acoplamento; Filas de mensagens implementam um link de comunicao indireto, sem conexo e assncrono entre dois ou mais processos; Um gerente de filas rodando em um servidor separado gerencia as filas e garante que no importa o que ocorra na rede, apenas uma cpia da mensagem eventualmente chega ao seu destino; Deve-se notar que embora a comunicao de processo para processo seja assncrona, a comunicao entre um processo e o gerente de fila em geral implementada usando um link de comunicao direto e sncrono; Isso significa que se a rede cair ou se o gerente cair, um processo no pode incluir mensagens em uma fila ou obter mensagens da mesma. Filas (queue) so independentes de um processo. Ento, muitos processos podem incluir, ou obter (retirando ou no as mensagens da fila) mensagens de uma mesma fila. Um processo pode tambm acessar mltiplas 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 no perdida; O gerente de filas pode cooperar com um gerente de transaes; se uma transao iniciada e uma mensagem colocada em uma fila durante a transao a qual mais tarde abortada, ento no somente o BD tem que sofrer roll back, mas a mensagem tambm removida da fila e no enviada.
Queue VS. Topic

-On-line, multi-cast. Principais Servios: comunicao assncrona, priorizao de mensagens, segurana, 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 comunicao assncrona e confivel a forma dominante de interao do sistema distribudo: no assume um transporte confivel. 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 idia de RPC. Usado para chamar uma operao (implementada por um mtodo) em uma instncia de objeto (instanciada a partir de uma classe) que reside em outro processo. A idia aqui tornar os princpios orientados a objetos disponveis para o desenvolvimento de sistemas distribudos, ou seja, distribuio + OO = Objetos Distribudos. O primeiro desses sistemas foi o OMG Common Object Request Broker Architecture (CORBA). Microsoft adicionou capacidades de distribuio a seu Component Object Model (COM DCOM). Sun forneceu mecanismos para Invocao Remota de Mtodos Remote
Method Invocation (RMI).

Servidores de Aplicao
GlassFish, MS IIS, JBoss, IBM WAS. Principais Vantagens do middleware OO sobre o middleware RPC: Mais flexvel, 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 (padro), ubiqidade (at videogame acessa http), XML (padro), codificao dos dados, SOAP (padro), comunicao (RPC), executa sobre o http, WSDL Web Service Definition Language (padro): o que, onde, como, UDDI Universal Description Discovery and Integration (padro): Descoberta e negociao.
WebServices agem como uma interface para acessar os servios providos por outros middleware.
Outras Questes
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
Exerccios
1. O que so Middlewares, e quais seus objetivos? 2. Explique o conceito de transparncia 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 aplicao legada que usa um banco proprietrio (ZIM). Como proceder? 9. Ao tentar implementar RMI, detectou-se um problema de conexo (socket) por conta de um firewall. Como proceder? 10.Justifique por que filas promovem o baixo acoplamento entre aplicaes?
Aula 3 Objetos Distribudos (Java IDL) [ESTUDO DIRIGIDO]

Introduo
RPC Remote procedure call: Este termo utilizado para aplicativos clientes que fazem normalmente chamadas a procedimentos remotos que esto em outro processo e hosts. RPC objetiva permitir chamada de procedimento remoto como se fosse local, ocultando entrada/sada de mensagens. RMI Remote method invocation: O modelo baseado orientado a objeto utiliza este termo para definir uma chamada local a um mtodo em um objeto remoto. Interface Definition Languages IDL (padro/interoperabilidade): Permite criar uma notao universal para interface de mtodos e variveis para serem utilizados entre diversas linguagens de programao. Marshalling: Linearizao (serializao) de uma coleo de itens de dados estruturados (com exceo dos atributos transientes/java). Traduo dos dados em formato externo (bits). Unmarshalling: Traduo do formato externo para o local. Restaurao dos itens de dados de acordo com sua estrutura. Programao distribuda em Java: Entre os atrativos de Java est a facilidade que essa linguagem oferece para desenvolver aplicaes para execuo em sistemas distribudos. J em sua primeira verso, Java oferecia facilidades para o desenvolvimento de aplicaes cliente-servidor usando os mecanismos da Internet, tais como os protocolos TCP/IP e UDP. Se o cliente na aplicao distribuda precisa acessar um servidor de banco de dados relacional, Java oferece uma API especfica para tal fim, JDBC. Atravs das classes e interfaces desse pacote possvel 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 clssico mecanismo de applets, cdigo Java que executa em uma mquina 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 aplicaes com arquitetura de distribuio de trs camadas baseadas no protocolo HTTP e em servios implementados em Java. Aplicaes distribudas mais elaboradas podem ser desenvolvidas usando uma arquitetura de objetos distribudos, onde aplicaes orientadas a objetos lidam diretamente com referncias (variveis) a objetos em processos remotos (servidores de aplicao). Java oferece duas alternativas nessa direo, RMI (Remote Method Invocation), uma soluo 100% Java, e Java IDL, esta uma soluo integrada arquitetura padro CORBA. Um passo adiante na evoluo desse tipo de sistema a utilizao do conceito de agentes mveis, onde
no apenas referncias a objetos so manipuladas remotamente mas os prprios objetos (cdigo e estado) movem-se pela rede. Outras (Java): EJB, Spring Framework
Objetos Distribudos: Na programao distribuda usando a arquitetura cliente-servidor, clientes e servidores podem ser implementados usando qualquer paradigma de programao. Assim, possvel que um servio especfico seja executado por um mtodo de algum objeto. No entanto, mesmo que o cliente tambm tenha sido desenvolvido orientao a objetos, na comunicao entre o cliente e o servidor esse paradigma deve ser esquecido, devendo ser utilizado algum protocolo pr-estabelecido de troca de mensagens para a solicitao e resposta ao servio. Um sistema de objetos distribudos aquele que permite a operao com objetos remotos. Dessa forma possvel, a partir de uma aplicao cliente orientada a objetos, obter uma referncia para um objeto que oferece o servio desejado e, atravs dessa referncia, invocar mtodos desse objeto mesmo que a instncia desse objeto esteja em uma mquina diferente daquela do objeto cliente. O conceito bsico que suporta plataformas de objetos distribudos o conceito de arquiteturas de objetos. Essencialmente, uma arquitetura orientada a objetos estabelece as regras, diretrizes e convenes definindo como as aplicaes podem se comunicar e interoperar. Dessa forma, o foco da arquitetura no em como a implementao realizada, mas sim na infra-estrutura e na interface entre os componentes da arquitetura. Na plataforma Java, dois mecanismos so oferecidos para o desenvolvimento de aplicaes usando o conceito de objetos distribudos: Java RMI e Java IDL. RMI (invocao remota de mtodos) um mecanismo para desenvolver aplicaes com objetos distribudos que opera exclusivamente com objetos Java. Java IDL utiliza a arquitetura padro CORBA para integrao de aplicaes Java a aplicaes desenvolvidas em outras linguagens. Java IDL: A API Java IDL, presente na plataforma Java 2, permite a integrao entre objetos Java e outros objetos remotos (caixa preta), eventualmente desenvolvidos em outras linguagens de programao, atravs da arquitetura CORBA. Os principais pacotes que compem essa API so org.omg.CORBA e org.omg.CosNaming. A partir da verso 1.3 da plataforma Java 2, possvel gerar interfaces IDL para classes Java usando o compilador rmic com a opo "-idl". Outra opo, "-iiop", indica que o protocolo de comunicao de CORBA, IIOP, ser utilizado em stubs e ties (correspondentes aos skeletons) de RMI. Uma vez obtida a interface IDL para um servio, as classes auxiliares para acessar o objeto remoto que implementa o servio so obtidas pela compilao da interface, usando o aplicativo idlj (ou idltojava ou ainda idl2java em verses anteriores ao Java 1.3). Alm de classes para stubs e skeletons, so geradas classes auxiliares (helpers e holders) para permitir a comunicao entre objetos Java e outras linguagens.
Na plataforma Java h uma implementao para o servio de nomes de CORBA, oferecida pelo aplicativo tnameserv. Esse servio est mapeado por default para a porta 900, podendo esta ser modificada pela opo "-ORBInitialPort". ORB o Object Request Broker, o ncleo da arquitetura CORBA. um programa que deve estar sendo executado em cada mquina envolvida em uma aplicao CORBA, sendo o responsvel pela conexo entre clientes e servios atravs dos correspondentes stubs e skeletons. A interao entre um ORB e um programa Java d-se atravs de mtodos da classe ORB. Para inicializar a referncia ao ORB, utiliza-se o mtodo esttico init() dessa classe. Para obter uma referncia para o servio de nomes utiliza-se o mtodo resolve_initial_references() tendo a NameService como argumento. Exemplo de Java IDL: Este exemplo, obtido da documentao da Sun, uma implementao em Java IDL do tradicional "hello world", composto por trs arquivos:
Interface IDL: uma interface para um servio com um nico mtodo definido usando as construes da linguagem IDL. Usando o aplicativo idl2j gera-se a interface Java correspondente, com a traduo das construes IDL para as primitivas Java segundo o padro estabelecido em CORBA, e outros arquivos auxiliares (stub, skeleton, helper, holder), no apresentados aqui. Exemplo:
module HelloApp {
interface Hello { string sayHello(); }
Exemplo de cliente que ativa o ORB, obtm uma referncia para o servio de nomes e, a partir deste servio, obtm uma referncia remota para o objeto com o servio Hello. Obtida a referncia, o mtodo 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/servio: nesse arquivo so criadas duas classes. A classe HelloServer um servidor que ativa o ORB, cria o objeto que implementa o servio, obtm uma referncia para o servio de nomes e registra o objeto neste diretrio associado ao nome Hello. A classe HelloServant uma implementao do servio especificado; observe que essa classe uma extenso 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"; } }
Serializao e RMI
Serializao e Persistncia
Serializando e Persistindo Objetos o Como transferir os dados da aplicao servidora para as aplicaes clientes? o Objetos Java vivem dentro de uma JVM; necessrio que a classe desses objetos esteja carregada (Onde? Basta ser homnima?). o O processo de criar uma cpia em formato binrio dos dados de um objeto chamado serializao. o Podemos armazenar este contedo (binrio) em um arquivo (file system) ou at mesmo em um banco de dados; Os dados desse objeto so 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 Marcao no requer, de fato, a implementao de mtodo algum - annotations. o ObjectOutputStream o responsvel por serializar os objetos. o Exemplo: Livro effectiveJava = new Livro(); FileOutputStream saidaArquivo = new FileOutputStream(effectiveJava.txt); // qualquer extenso 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). Serializao em Cascata o Em relacionamento do tipo has-a ambas as classes precisam implementar Serializable, seno o processo ir falhar. o Serialization lets you simply say save this object and all of its instance variables. Unless Ive explicitly marked a variable as transient.
Atributos Transientes o Oposto de persistente. o Voc no deseja que todos os atributos participem do processo de serializao. 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 no serializvel, sim.
Introduo ao RMI
Conceitos: - transparncia; - contrato (buscar no catlogo); - objeto de mentira (stub) retornado pelo catlogo/padro de projeto PROXY:
implementa a comunicao/gerado automaticamente (Proxy dinmico); - serializao (com RMI) Ateno: RMI no Java EE, Java SE. Invocao Remota de Mtodo o Como disponibilizar este servio? o No quero ser o responsvel por cdigo de infra (sockets). o aplicao cliente apenas tendo uma referncia utilizada para invocar mtodos em um objeto que est na aplicao servidora, em outra JVM. o Objeto remoto/remotabilidade.
Java RMI Remote Method Invocation o Se o objeto deve aceitar invocaes remotas ento 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 impresso de estar conversando com o objeto de verdade (transparncia), o objeto de mentira tem que ter as mesmas assinaturas de
mtodos 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 Servio) 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 mquina virtual criar a classe dinamicamente (proxy dinmico) em tempo de execuo a partir da interface remota. Colocando o Objeto no Servidor o Registrando (bind) um objeto remoto (utilizando um catlogo de objetos remotos) utilizando um apelido. o Os clientes fazem uma busca (lookup) pelo apelido do objeto desejado. O catlogo devolve as informaes necessrias para a prpria mquina virtual da aplicao cliente construir um stub que possa se conectar com o objeto remoto. o Exemplo (subindo o catlogo/na mquina Servidora): LocateRegistry.createRegistry(1099); //porta listener do catlogo o Exemplo (registrando um objeto remoto/na mquina Servidora): ProcuraLivroService buscadorDeLivro = new ProcuraLivroService(); Naming.rebind(loja/procura, buscadorDeLivro); o Exemplo (buscando um objeto remoto/na mquina Cliente): ProcuraLivro biblioteca = (ProcuraLivro) Naming.lookup(rmi://localhost:1099/loja/procura); o O servio de nomes bsico do Java chamado rmiregistry. Em produo mais comum o uso do JNDI Java Naming and Directory Interface. Quem so os servidores? o RMI uma tecnologia realmente distribuda. O servio de nomes centraliza as informaes de onde est cada objeto. Servidor de Nomes (catlogo) e Aplicao. 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 Questes
Design Patterns do ponto de vista do arquiteto (EJB, VO, TO) Uso de Stored Procedures (Velocidade, Camada de Indireo Adicional) Exemplo arquitetura para um sistema de carto de crdito. Outras tecnologias: Silverlight (MS), Flash/Flex, Java FX. Posso usar (outra) aplicao Java para instanciar os objetos (no servidor) e registr-los no catlogo, e me preocupar com a gesto do pool ou... Servidor de Aplicao/Middleware (IBM WAS, JBoss, etc..)
Exerccios
1. Compare Java IDL com Java RMI. 2. Compare Marshaling e Unmarshaling. 3. Relacione ORB com a arquitetura CORBA.
Aula 4 Balanceamento de Carga

Introduo
Um sistema distribudo constitui-se de um conjunto de processadores autnomos conectados atravs de um subsistema de comunicao, que cooperam entre si atravs da troca de mensagens. Esse tipo de sistema deve apresentar duas caractersticas inerentes: 1) a transparncia na sua utilizao, ou seja, a capacidade de apresentar-se aos seus usurios como uma entidade nica, e 2) o alto grau de tolerncia a faltas (falhas). Uma das formas de se implementar tolerncia a falhas atravs do balanceamento de carga. Balanceamento de carga: Todo o hardware tem o seu limite, e muitas vezes o mesmo servio tem que ser repartido por vrias mquinas, sob pena de se tornar congestionado. Estas solues podem-se especializar em pequenos grupos sobre os quais se faz um balanceamento de carga.
Recursos
Utilizao 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 vrios servidores. Balanceamento de CPU: Este tipo de balanceamento efetuado pelos sistemas de processamento distribudo e consiste, basicamente, em dividir a carga total de processamento pelos vrios processadores no sistema (sejam eles locais ou remotos). Solues (software): Beowulf, openMosix, openSSI, OSCAR. Balanceamento de Carga em SD de Propsito Geral: Um sistema distribudo consiste numa coleo de computadores autnomos conectados por uma rede de comunicao. Devido a flutuaes na taxa de chegada e no tempo de servio das tarefas submetidas pelos usurios durante um certo intervalo de tempo, algumas mquinas podero estar ociosas enquanto outras estaro pesadamente carregadas. Os algoritmos de compartilhamento ou distribuio de carga tentam melhorar o desempenho deste tipo de sistema compartilhando a carga de trabalho do sistema entre as mquinas que o compem. Os algoritmos de balanceamento de carga vo alm, visando equilibrar a carga de todas as mquinas. O problema do balanceamento de carga um problema de escalonamento, que consiste em determinar qual mquina da rede ir executar uma determinada tarefa de maneira a otimizar o desempenho do sistema. Encontrar a soluo tima para este tipo de problema em geral um problema NP-Completo (os problemas tratveis tambm so comumente denominados "P"/Polinomiais, enquanto os intratveis so denominados
"NP"/No-Polinomiais). Algoritmos de balanceamento de carga podem ter sua atividade de distribuio de carga disparada pelas mquinas com pouca carga (receptoras) que tentam obter tarefas a
partir de outras mais carregadas (remetentes), ou disparada pelas mquinas sobrecarregadas que tentam enviar tarefas quelas menos carregadas. Algoritmos que utilizam a primeira estratgia so chamados receiver-initiated e os algoritmos que utilizam a segunda estratgia sender-initiated. Nos algoritmos symmetrically-initiated, tanto as mquinas receptoras quanto as remetentes podem disparar a atividade de distribuio de carga. Estudos mostram que, em sistemas com baixa carga de trabalho, algoritmos senderinitiated tm mais sucesso em encontrar mquinas subcarregadas e em sistemas com alta carga de trabalho, algoritmos receiver-initiated tm mais sucesso em encontrar mquinas sobrecarregadas.
Taxonomia
Classes de algoritmos de balanceamento de carga: esttico versus dinmico: estas classes se diferem quanto ao momento em que as decises de escalonamento so tomadas. Nos algoritmos estticos assume-se que o nmero de tarefas e comportamento de cada tarefa conhecido quando o sistema ainda est sendo compilado; cada tarefa atribuda a um processador fixo e toda vez que uma imagem desta tarefa for instanciada, ela ser atribuda a este processador. Nos algoritmos dinmicos assume-se que se tem pouqussimo conhecimento a priori sobre as necessidades de recursos das tarefas que compem o sistema; portanto, as decises de escalonamento so tomadas somente quando o sistema est em execuo. fisicamente distribudo versus fisicamente no-distribudo: quando a
responsabilidade de tomar decises sobre o escalonamento de tarefas reside em um nico processador dizemos que este algoritmo fisicamente no-distribudo. Caso contrrio o algoritmo dito fisicamente distribudo. cooperativo versus no-cooperativo: os algoritmos onde um processador individual toma decises independentemente das aes tomadas por outros processadores so denominados no-cooperativos. Os algoritmos onde h cooperao entre os componentes distribudos so chamados cooperativos. adaptvel versus no-adaptvel: numa soluo adaptvel os algoritmos e os parmetros utilizados para implementar o escalonador podem mudar
dinamicamente de acordo com o comportamento anterior e atual do sistema em resposta s decises anteriores feitas pelo escalonador (otimizao). Alm de poderem ser divididos nestas classes, os algoritmos de balanceamento de carga podem ser sncronos ou assncronos, e preemptivos ou no-preemptivos. Algoritmos sncronos exigem que todas as mquinas do sistema estejam sincronizadas para que possam iniciar a atividade de distribuio num mesmo instante no tempo. Uma vez distribuda a carga, as mquinas sincronizam-se novamente e voltam a executar as tarefas ainda
pendentes. Algoritmos assncronos so mais flexveis. Grupos de mquinas do sistemas podem iniciar a atividade de distribuio em momentos diferentes, no existindo a necessidade de sincronizao. Nas solues preemptivas a execuo de uma tarefa pode ser interrompida para que esta tarefa seja migrada de uma mquina para outra; em solues no preemptivas somente as tarefas que no estejam sendo executadas podem ser movidas. Algoritmos preemptivos geralmente tm 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 difcil.
Polticas de Escalonamento
Os algoritmos de balanceamento de carga podem ser divididos em 4 componentes: poltica de transferncia, poltica de seleo, poltica de localizao, e poltica de informao. A poltica de transferncia determina qual mquina deve iniciar a transferncia de tarefas. A poltica de localizao deve encontrar uma outra mquina que possa receber ou enviar tarefas para mquina selecionada pela poltica de transferncia. A poltica de seleo seleciona a tarefa ser transferida. A poltica de informao decide quando, a partir de onde, e quais as informaes sobre as mquinas do sistema devem ser coletadas. Uma das maneiras de se implementar estas polticas 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 deciso 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 polticas e portanto, uma grande variedade de algoritmos de balanceamento de carga. Polticas adaptveis possuem maior habilidade em evitar estados de baixo
desempenho. Entretanto, como estas polticas devem coletar e reagir s informaes sobre o estado do sistema, elas so necessariamente mais complexas que polticas estticas. Uma das perguntas a serem feitas sobre estas polticas e talvez a mais importante : qual o nvel apropriado de complexidade para tais polticas? Polticas adaptveis extremamente simples, que coletam pouca informao sobre o estado do sistema e que utilizam esta informao de uma maneira simplificada, so capazes de melhorar dramaticamente o desempenho de um sistema. Alm disso, o resultado obtido com estas polticas extremamente simples so prximos queles alcanados por polticas muito complexas e que exigem muita informao sobre o estado do sistema. Exemplo: Requisitos de um Algoritmo de Balanceamento de Carga para Sistemas de Realidade Virtual Distribudos (Second Life), WOW (MMORPG). necessrio que o algoritmo de balanceamento de carga seja fisicamente distribudo, para que no insiramos um novo gargalo no sistema de realidade virtual, e assncrono, pois
as sincronizaes dos servidores exigidas por um algoritmo sncrono impossibilitam seu uso em um sistema de tempo real como este que estudamos. O algoritmo a ser proposto tambm deve ser adaptvel, uma vez que o nmero 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 nmero de clientes em um servidor ultrapassar um determinado limiar (threshold), este limiar no poder ser o mesmo quando no sistema existirem 100 ou 1000 clientes. O sistema de balanceamento de carga deve ser cooperativo, para evitar que decises tomadas por um nico servidor atrapalhe o desempenho dos demais servidores. Acima de tudo, o sistema de balanceamento de carga deve possuir polticas bem simples que necessitem de informaes que possam ser facilmente colhidas, para que o balanceamento possa ser realizado de forma dinmica e em tempo real, inserindo o mnimo de sobrecarga no sistema de realidade virtual.
Outras Questes
Web Farm versus Web Garden (servidor multiprocessado). Cluster (Web): Sesses no Banco versus Middleware (ip fixo). o o o o Microsoft Sharepoint / NLB (Windows Server 2003, cluster NLB) Conceito de afinidade (sticky session) Espelhamento Evita erros intermitentes, j que a sesso fica sempre na mesma mquina servidora. Seno funciona, no-funciona (problema no cliente). o o o o Criao de um novo IP para o cluster. Tabela NAT Cookies/Expirao timeout da sesso Sesso: In-proc (sticky) Out-proc DB
Exerccios
1. Nos sistemas que visam atender a milhares de usurios simultaneamente, os servidores podem facilmente se tornar gargalos do sistema. Alm disso, se o sistema no for cuidadosamente planejado, ele poder ter sua escalabilidade reduzida. Uma tcnica utilizada para melhorar a escalabilidade de sistemas distribudos o balanceamento de carga entre os servidores do sistema. o Se, na sua equipe de trabalho, voc fosse o arquiteto responsvel pelo projeto/configurao do algoritmo de balanceamento de carga a ser utilizado em conjunto com o sistema de informao, quais seriam os requisitos que voc consideraria indispensveis ao algoritmo? Justifique sua resposta. o Quais problemas poderiam surgir se voc escolhesse utilizar uma poltica de transferncia baseada num limiar (threshold) fixo? Durante o projeto de um algoritmo de balanceamento de carga, natural pensarmos que utilizao de polticas de escalonamentos complexas e baseadas em informaes detalhadas mais vantajosa que a utilizao de polticas de escalonamento mais simples e baseadas em pouqussimas informaes. Qual sua opinio sobre esta questo? 2. Defina Balanceamento de Carga e o que motiva sua implementao. 3. Compare Web Farm com Web Garden. 4. Que recursos podem ser compartilhados atravs do balanceamento de carga? 5. Que consideraes precisamos ter ao escalar horizontalmente uma web application?
Aula 5 Algoritmos Distribudos

Introduo
Escalabilidade: Um sistema distribudo deve permitir a expanso em termos do nmero de usurios e recursos e, mesmo assim, manter a performance relativa de atendimento a servios do usurio. A maioria dos sistemas distribudos atuais projetada para trabalhar com poucas centenas de processadores. Atualmente solues que funcionam com 200 mquinas falham miseravelmente se aplicadas a 200.000 mquinas. Exemplo de um sistema que deve possuir escalabilidade: a PTT (Post Telephone and Telegraph Administration) francesa pretendia instalar um terminal em cada residncia e ponto comercial da Frana por volta de 1995. Estes terminais seriam utilizados para acesso a base de dados de telefone (lista telefnica) e tambm como correio eletrnico, por cerca de 50 milhes de habitantes. Para implementao de um sistema distribudo deste porte deve-se evitar:
Centralizao de Componentes (arquitetura monoltica, gargalo) ter um nico servidor de correio para 50 milhes de usurio no uma boa idia; Centralizao de tabelas (orkut.com) uma nica tabela possui uma imensa vulnerabilidade a falhas; Centralizao de Algoritmos (redundncia) a falha em uma mquina arruna o algoritmo. Todas as mquinas tm que ter informao completa sobre o estado do sistema.
Breve Histrico
Apareceu na dcada de 60 dentro do contexto de Sistemas Operacionais. A motivao foi a criao de unidades de hardware denominadas canais ou dispositivos de controle. Estes dispositivos funcionam independente de um processador de controle e podem fazer operaes de E/S concorrentemente com a execuo de um programa. Um canal (hardware) comunica-se com o processador central atravs de uma interrupo ( exceo). Com a introduo dos canais, partes de um programa poderiam funcionar de forma imprevisvel. Logo aps o aparecimento dos canais, foram desenvolvidas as mquinas multiprocessadas. Estas mquinas permitem que aplicaes diferentes sejam executadas em processadores diferentes ao mesmo tempo. Permite tambm que uma aplicao possa ser executada mais rapidamente se puder ser reescrita de forma a utilizar mltiplos processadores. Perguntas: Como sincronizar as atividades de processos concorrentes? Como utilizar mltiplos processadores para que uma aplicao seja executada mais rapidamente? Resposta... Algoritmos Distribudos: Algoritmos que foram desenvolvidos para serem executados em muitos processadores distribudos em uma grande rea geogrfica.
Atualmente, o termo cobre
algoritmos que so executados em redes locais e em
multiprocessadores de memria compartilhada.
Caractersticas dos Sistemas Distribudos

compartilhamento de recursos: um sistema distribudo deve permitir o compartilhamento eficiente de recursos fsicos e lgicos; abertura: um sistema distribudo deve pertencer classe de sistemas abertos (OPENNESS), permitindo sua estensibilidade ( fcil estender e alterar o sistema?); concorrncia: um sistema distribudo deve possuir algoritmos e tcnicas eficientes para o escalonamento de processos concorrentes (balanceamento de carga); escalabilidade: um sistema distribudo deve permitir a expanso em termos do nmero de usurios e recursos e, mesmo assim, manter a performance relativa de atendimento a servios do usurio; tolerncia a falhas: um sistema distribudo deve possuir estratgias para tolerar falhas em algum(uns) de seu(s) componente(s) e manter o provimento de servios ao usurio final; transparncia: um sistema distribudo deve ser transparente ao usurio final, ou seja, o usurio deve executar operaes remotas como se estive executando-as na sua mquina (local). Dentre estas caractersticas, iremos falar mais especificamente da concorrncia obtida atravs de algoritmos distribudos. Cenrio-Exemplo: Vrios carros desejam ir de um ponto A a um ponto B. Eles podem competir por espaos em uma mesma estrada (A) ou acabam seguindo uns aos outros ou competindo por posies. 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) mltiplos processadores, ou (C) processadores distribudos (clusters ou grids).
Recursos independentes (acostamento).

A B C
Computao Concorrente
Existem mltiplas 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 mltiplos processadores (pistas em uma estrada); ou, em processadores distribudos (estradas separadas). Como elas sero executadas? Caractersticas: Um programa concorrente contm dois ou mais processos que trabalham juntos para executar uma tarefa. Cada processo um programa seqencial. Programa seqencial nico thread de controle. Programa concorrente mltiplos threads
de controle onde thread um fio de execuo.
Comunicao
Os processos em um programa concorrente trabalham juntos comunicando-se entre si. A comunicao pode ser feita atravs de: variveis compartilhadas, troca de mensagens (loopback). Independente da forma de comunicao, os processos precisam sincronizar-se: excluso mtua (sees crticas), sincronizao 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. Aplicaes: processamento de informaes distribudas; computao cientfica; controle de processos de tempo real.
Taxonomia
Mtodo de comunicao entre processos: memria compartilhada, mensagens ponto-a-ponto, difuso de mensagens (broadcast) e chamadas remotas a procedimentos (RPC). Modelo de Execuo (timing model): completamente sncronos, completamente assncronos, parcialmente sncronos. Modelo de falha: hardware completamente confivel ou pode-se admitir alguma falha. Na presena de falha: o processo pode parar com ou sem aviso; pode falhar brevemente; ou pode apresentar falhas graves e o sistema funcionar de forma arbitrria. Tambm podem ocorrer falhas na comunicao: perda ou duplicao de mensagens. Problemas abordados: alocao de recursos, comunicao, consenso entre processadores distribudos, controle de concorrncia em bancos de dados,
deteco de deadlock, instantneos globais (global snapshots), sincronizao, e implementao de vrios tipos de objetos.
Caractersticas
Apresentam um alto grau de incerteza e mais independncia de atividades, entre elas: nmero de processadores desconhecido; topologia de rede desconhecida; entradas
independentes em diferentes locais; vrios programas sendo executados de uma s vez, comeando em tempos diferentes, e operando a velocidades diferentes; no-determinismo dos processadores; tempos de envio de mensagens incertos; desconhecimento da ordenao das mensagens; falhas de processadores e comunicao. Motivao: permitir iterao entre usurios; compartilhamento de recursos/dados e servios; em potencial: desempenho melhor, disponibilidade maior. Software tem que estar distribudo, controle deve estar distribudo. Requer nova forma de programao/projeto de algoritmos que levam em conta: paralelismo e no-determinismo; controle descentralizado; atomicidade de aes; tomada de deciso baseada em informao (parcial) sobre os dados do sistema; otimizao do nmero de mensagens a serem trocadas; levar em conta a possibilidade de falhas.
Outras Questes
Recomendao as Sun: No criar threads manualmente dentro do container. Case IFV. Sintaxe Java: fio = new Thread(<objeto>); Arquitetura desconectada: Quantas licenas para 47 usurios? Java/Threads: o o o o o o o o o There is one thread per call stack. In some JVMs, the Java threads are actually mapped to native OS threads. public void run(){} // the new call stack always begin by invoking run(); Extend the java.lang.Thread class (or) Implement the Runnable interface. Every thread of execution begins as an instance of class Thread. myThread t = new MyThread(); myRunnable r = new MyRunnable(); Thread t = new Thread (r); Once the start() method is called, the thread is considered to be alive. A thread is considered dead after the run() method completes. o o Example: t.start(); (from new state to runnable state) 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 descrio do mtodo run().
class Escrita implements Runnable { private int i; public void run() { while(true) System.out.println(Nmero: + i++); } } public class SimplesThread2 { public static void main(String[] args) { Escrita e = new Escrita(); Thread t = new Thread(e); t.start(); } } //Cria o contexto de execuo //Cria a linha de execuo //Ativa a thread
A classe SimplesThread2 cria o contexto de execuo da thread no momento que cria uma instncia 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 execuo, basta criar a thread, fornecendo o contexto (o local onde h o mtodo run da thread).
Thread t = new Thread(e);
O incio da thread propriamente dito ocorrer com o mtodo start().
Exerccios
1. Relacione Escalabilidade com a arquitetura monoltica. 2. Qual a diferena entre escalabilidade vertical e escalabilidade horizontal? 3. O que interprocess synchronization? 4. Qual a diferena entre mutex e semaphore? 5. O que faz a palavra-chave synchronized em um mtodo Java? 6. Qual a diferena entre exceo e interrupo.
7. Como sincronizar as atividades de processos concorrentes? Como utilizar mltiplos processadores para que uma aplicao seja executada mais
rapidamente? 8. Quais as principais motivaes para a utilizao de algoritmos distribudos?
Aula 6 Banco de Dados Distribudos

Introduo
Banco de dados distribudo (BDD) uma coleo de vrias Base de Dados logicamente inter-relacionadas, distribudas por uma rede de computadores. Existem dois tipos de banco de dados distribudos, os homogneos e os heterogneos. Os homogneos so compostos pelos mesmos bancos de dados, j os Heterogneos so aqueles que so compostos por mais de um tipo de banco de dados. Num banco de dados distribudo os arquivos podem estar replicados (cpia) ou fragmentados, esses dois tipos podem ser encontrados ao longo dos ns do sistema de BDD's. Quando os dados se encontram replicados, existe uma cpia de cada um dos dados em cada n, tornando as bases iguais (ex: tabela de produtos de uma grande loja). J na fragmentao, 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 so vistos de uma forma nica, pois cada n possui um catlogo que contm cada informao dos dados dos bancos adjacentes. A replicao dos dados pode se dar de maneira sncrona ou assncrona. No caso de replicao sncrona, cada transao dada como concluda quando todos os ns confirmam que a transao local foi bem sucedida. Na replicao assncrona, o n principal executa a transao enviando confirmao ao solicitante e ento encaminha a transao aos demais ns. Exemplo: Cenrio de uma rede lojista, catlogo de produtos replicado, pedidos fragmentado.
Consideraes Importantes
Cuidados com banco de dados distribudos devem ser tomados para assegurar o seguinte: A distribuio transparente usurios devem poder interagir com o sistema como se ele fosse um nico sistema lgico. Isso se aplica ao desempenho do sistema, mtodos de acesso, entre outras coisas. Transaes so transparentes cada transao deve manter a integridade do banco de dados dentre os mltiplos bancos de dados. Transaes devem tambm ser divididas em subtransaes, cada subtransao afetando um sistema de banco de dados...
Vantagens de bancos de dados distribudos

Reflete a estrutura organizacional fragmentos do banco de dados esto 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 invs do banco de dados inteiro.
Melhor performance os dados esto localizados prximo do local de maior demanda e os sistemas de banco de dados por si s so paralelizveis, permitindo carregar no banco de dados para o balanceamento entre servidores (a elevada carga em um mdulo do banco de dados no ir afetar os outros mdulos de banco de dados em um banco de dados distribudo).
Econmico 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 distribudo sem afetar os outros mdulos (sistemas).
Escalabilidade
Desvantagens de banco de dados distribudos

Complexidade trabalho extra deve ser feito pelos DBAs para garantir que a natureza da distribuio do sistema seja transparente. Trabalho extra deve ser feito para manter sistemas mltiplos diferentes, ao invs de um nico grande. Design de banco de dados extra deve tambm ser feito para levar em conta a natureza desconectada do banco de dados - por exemplo, joins tornam-se proibitivamente caros quando so rodados entre mltiplas plataformas. Implantao mais cara o aumento da complexidade e uma infraestrura mais extensa significa custo extra de trabalho Segurana fragmentos de banco de dados remotos devem ser seguros e, como eles no so centralizados ento os lugares remotos tambm devem ser seguros. A infraestrutura tambm deve ser segura (por exemplo, pela encriptao dos links de rede entre os lugares remotos). Difcil de manter a integridade em sistemas distribudos, reforar a integridade ao longo de uma rede pode exigir demais dos recursos da rede para ser vivel (consistncia). Inexperincia pode ser difcil trabalhar com banco de dados distribudos e como uma rea relativamente nova ainda no h tantos casos (ou experincias) prticos de seu uso disponveis como exemplo. Falta de padres ainda no h metodologias e ferramentas para ajudar usurios a converter um SGBD centralizado para um SGBD distribudo. Design do banco de dados mais complexo alm das dificuldades normais, o design de um banco de dados distribudos tem que considerar a fragmentao
dos dados, alocao dos fragmentos em lugares especficos e a replicao de dados.
Arquitetura de um banco de dados distribudos em Oracle

Um banco de dados distribudos um conjunto de banco de dados armazenados em vrios computadores que tipicamente aparecem para uma aplicao como um simples banco de dados. Consequentemente uma aplicao pode simultaneamente acessar e modificar os dados nos vrios banco de dados da rede. Cada banco de dados no sistema controlado pelo seu prprio servidor de Oracle local mas coopera para manter a consistncia 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 aplicao que solicita informao para um servidor. Cada computador no sistema um n. Um n em um sistema de banco de dados distribudos age como um cliente, um servidor, ou ambos dependendo da situao. 2. A Rede Para criar um link entre banco de dados individuais de um sistema de banco de dados distribudos, um rede necessria. 2.1 Net8 Todo banco de dados Oracle em um sistema de banco de dados distribudos usa um software de rede da Oracle, o Net8, para facilitar a comunicao atravs da rede. Alm de o Net8 conectar clientes e servidores que operem em diferentes computadores de uma rede, ele tambm permite servidores de banco de dados que comunicarem atravs da rede a suportar transaes remotas e distribudas atravs de um banco de dados.
Net8 deixa transparente a conectividade que necessria para transmitir requisies SQL e receber dados de aplicaes que usem o sistema. 3. Nome de um Banco de dados. Cada banco de dados em um banco de dados distribudos distinto dos outros bancos de dados em um sistema e tem o seu prprio nome do banco de dados global dentro da rede. 4. Links entre Banco de dados Oracle. Para facilitar uma requisio de uma aplicao em um sistema de banco de dados distribudos, Oracle usa database links. Um database link define um caminho de comunicao de uma mo de uma banco de dados Oracle para outro. Database link so essencialmente transparentes para os usurios de um sistema de banco de dados distribudos, porque o nome de um database link o mesmo que o nome global de uma banco de dados que une os dois pontos. 5. Transparncia em um sistema de banco de dados distribudo. Com um mnimo de esforo, voc pode fazer a funcionalidade de seu sistema de banco de dados distribudos transparente para usurios que trabalham com o sistema. O objetivo da transparncia fazer um sistema de banco de dados distribudos aparecer como um simples banco de dados. 5.1 Transparncia local: Um sistema de banco de dados distribudos Oracle tem caractersticas que permitem desenvolvedores de aplicaes e administradores esconderem a localizao fsica de objetos de um banco de dados para aplicaes e usurios. Transparncia local existe quando um usurio pode universalmente referir-se a um objeto no banco de dados, tal como uma tabela, sem se preocupar com o n ao qual uma aplicao conecta-se. Mais tipicamente, administradores e desenvolvedores usam sinnimos para estabelecer transparncia de localizao para tabelas e objetos suportados no esquema da aplicao. Por exemplo, a seguinte sentena cria sinnimos em um banco de dados para tabelas em outros bancos de dados (remoto). CREATE PUBLIC SYNONYM emp FOR scott.emp@sales.us.americas.acm_auto.com CREATE PUBLIC SYNONYM dept FOR scott.dept@sales.us.americas.acm_auto.com Agora, ao invs de acessar as tabelas remotas como a query abaixo: SELECT ename, dname FROM scott.emp@sales.us.americas.acm_auto.com e, scott.dept@sales.us.americas.acm_auto.com d, WHERE e.deptno = d.deptno; Uma aplicao pode emitir uma query muito mais simples que no precisar saber a localizao das tabelas remotas. SELECT ename, dname FROM emp e, dept d WHERE e.deptno = d.deptno;
Transaes Distribudas
Transaes (begin, commit, rollback) so servios que tm como objetivo permitir integridade dos dados e consistncia. O programador v sua transao como um programa seqencial, mesmo que ele possa executar concorrentemente com outros programas ou que ocorram falhas durante sua execuo. Normalmente uma transao deve atender s quatro propriedades ACID: Atomicidade, Consistncia, Isolamento (for Update), Durabilidade. O uso de transaes em sistemas distribudos servir para enderear dois problemas: concorrncia (evitar condies de corrida), falhas (garantir consistncia dos dados). Modelo de Transaes Distribudas: Transaes podem acessar dados em vrios ns. Cada n tem um gerente local de transaes, responsvel por: Manter log para recuperao; Coordenar a execuo concorrente das transaes executando no n. Cada n tem um coordenador de transaes, responsvel por: Iniciar a execuo de transaes que so originadas no n. Distribuir subtransaes para ns apropriados. Coordenar a terminao de transaes originadas no n, o que resulta na transao ser validada em todos os ns ou desfeita em todos os ns. Exemplo da falta de transaes: Transferncia bancria on-line. Operao feita em 2 passos: saque/depsito. Se a conexo cair aps o saque, ocorre o dbito na primeira, no ocorre o crdito na segunda (dinheiro some). Transaes Distribudas: Uma transao dita distribuda quando mltiplos servidores esto envolvidos em uma transao tanto pela requisio direta do cliente, quanto indiretamente via servidor. Cada transao distribuda pode ser construda de duas formas diferentes: transao distribuda simples, transao
Requisies so feitas seqencialmente
distribuda aninhada. Transaes Distribudas Simples: O cliente invoca todos os servidores necessrios para completar a
transao requisitada... Transaes Distribudas Aninhadas: O cliente
requisita uma transao ao servidor que por sua vez invoca outros servidores e assim sucessivamente... Melhor desempenho...
Podem executar simultaneamente
Implementao: implementadas, de
Como modo
as a
transaes garantirem
so a
consistncia? Dois mtodos so apresentados: Shadow Versions: uma cpia dos dados a serem alterados feita. Nessa cpia que as
alteraes so efetuadas. Ao fim da transao essa
cpia substitui os dados antigos. Writeahead Log (intention list): antes de um dado ser modificado, so gravadas informaes em um log (qual a transao est efetuando alteraes, os dados que esto sendo alterados, os valores antigos e novos). Aps o log ter sido gravado as alteraes so feitas. Protocolos Atmicos de Confirmao: Objetiva garantir atomicidade a uma transao distribuda. Ou todas as operaes so efetuadas ou todas so 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: no permite que servidores abortem uma transao, por exemplo, no caso de ocorrncia de uma falha ou deadlock.
Two-Phase Protocol: Garante que todos os participantes da transao distribuda possam confirmar ou abortar sua transao. Usado quando o cliente envia um
closeTransaction(). Se o cliente envia um abortTransaction(): o coordenador informa todos os participantes que eles devem abortar a transao. Duas fases: Fase de Votao, Fase de Deciso.
canCommit?(trans)-> Yes / No canCommit?(trans) doCommit(trans) doCommit(trans) doAbort(trans) doAbort(trans) haveCommitted(trans, participant) haveCommitted(trans, getDecision(trans) -> Yes / No getDecision(trans)
Fase de Votao: O coordenador abre a votao. Cada servidor (coordenador ou participante) vota se a transao ser confirmada ou abortada. Fase de Deciso: O coordenador informa a todos os participantes sobre a deciso. Se todos os participantes aceitam: transao pode ser confirmada; caso contrrio abortada. Problemas: Se o coordenador cair os dados ficaro bloqueados at que o coordenador esteja novamente disponvel. 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.
Complexidade do Algoritmo: exige no mnimo 3(N-1) mensagens para completar a transao. Controle de Concorrncia: Objetivo garantir a propriedade de isolamento (locks). Garantir que os dados continuem consistentes depois de acessados por transaes concorrentes. Normalmente, implementado como um algoritmo de duas fases: bloqueio de duas fases (two-phase locking). A aquisio dos locks sobre os dados feita de modo que operaes de diferentes transaes ativas possam se intercalar. Pode ser feito por outras maneiras: Timestamps, Controle de Concorrncia 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. Requisies de locks (lock-E ou lock-C) so feitas ao gerente de controle de concorrncia. Transao fica suspensa at que lock seja concedido. Granularidade: campo, tupla, tabela, banco, pgina. Two-phase locking: O algoritmo two-phase locking possui as seguintes fases: 1 fase: obteno de locks, 2 fase: liberao de locks. Uma vez que uma transao tiver liberado um lock qualquer, a transao no poder adquirir nenhum novo lock pois a primeira liberao indica o trmino da primeira fase Strict two-phase locking: locks adquiridos so mantidos at que a transao seja cancelada ou confirmada. Vantagem: deadlocks. Deadlock: impede os cascading aborts. Desvantagem:
Exemplo de deadlock distribudo:
X, Y: Servidores
T Write(A) Read(B) at X at Y locks A Write(B) waits for U Read(A) at X at Y
U locks B waits for T
Dependendo da ordem dos bloqueios podem ocorrer referncias cclicas e deadlocks. H a necessidade de utilizar algoritmos para detectar e eliminar deadlocks. Construo de grafos wait-for globais.
Grafo Wait-for (WFG): Se uma transao Ti espera por outra transao Tj para liberar um lock em uma entidade, ento Ti -> Tj est no WFG.
Recuperao de deadlocks: Quando deadlock detectado deve-se procurar uma vtima (transao que ser desfeita). Procurar selecionar a vtima que causar menor custo; para evitar starvation, incluir nmero de rollbacks no custo. Extenso do rollback: Total (aborta a transao e a reinicia); Parcial (efetuar rollback somente at o ponto onde deadlock quebrado). Concluso: Transaes garantem integridade dos dados e consistncia. Atomicidade: garantida pelos protocolos atmicos. Consistncia: shadow versions, writeahead log.
Isolamento: Controle de Concorrncia. Problemas a serem tratados: Deadlocks, Falha nos servidores.
Outras Questes
Transaes distribudas atravs de middleware ou banco de dados distribudos. You could use the Java Transaction API (JTA) to access the Java Transaction Service (JTS) programmatically, but thata a heck of alot of work. Transao um servio de infra-estrutura e, como tal, deveria ficar a cargo do servidor de aplicao/container JEE (princpio da inverso de controle). Estratgia (performance) para incluso/atualizao: UPDATE... Se falhou por erro 100... INSERT (postura otimista)... Ao invs de Select/Exists
Insert/Update (postura pessimista).
Exerccios
1. O que so transaes distribudas? 2. Defina as propriedades ACID de uma transao. 3. Como podem ser implementadas transaes distribudas? 4. Como funciona o protocolo atmico de confirmao de duas fases? 5. Compare lock e deadlock. 6. Como um sistema se recupera de um deadlock? Como feita a escolha da transao a ser cancelada?
7. O que so Database links e Sinnimos? Como estes recursos podem ajudar em uma soluo de Banco de Dados distribudos?
Aula 7 Tolerncia a Falhas em Ambiente Distribudo

Introduo
O contnuo crescimento da utilizao de Redes de Computadores levou alguns pesquisadores deste campo da informtica a desenvolverem aplicaes que possussem mdulos capazes de interagir entre si, mesmo estando em diferentes computadores. Estas aplicaes foram chamadas de Sistemas Distribudos. A principal finalidade destes sistemas era de que estes mdulos distribudos fossem executados pelos usurios de forma transparente, ou seja, no interessava qual o mdulo estava respondendo s suas requisies e muito menos onde ele estava localizado. A partir deste conceito de transparncia, comearam a surgir padronizaes de middlewares que dessem suporte gerncia de sistemas distribudos. Mas, levando em considerao que estes mdulos esto localizados em meios fsicos susceptveis a falhas, no h garantia que a execuo de um determinado processo chega ao fim. Diante deste fato de grande relevncia para o gerenciamento de sistemas distribudos, comearam a surgir tcnicas de tolerncia a falhas que comearam a fazer parte de alguns dos padres de middlewares hoje existentes no mercado. Tolerncia a Falhas: Popularizao de servios Web gera dependncias no cotidiano. Falhas so inevitveis, mas suas conseqncias devem ser minimizadas. O domnio da rea de tolerncia a falhas (TF) auxilia administradores e desenvolvedores de sistemas a avaliar a relao custo benefcio para o seu caso especfico e determinar a melhor tcnica para seu oramento.
Mitigar Riscos
Exemplo: backup consome espao e tempo enquanto redundncia 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 servios mesmo na presena de falhas (de hardware ou de software). Defeitos no so visveis para o usurio, pois o sistema detecta e mascara (ou se recupera) defeitos antes que eles alcancem os limites do sistema (ponto de fuga da especificao). O que Tolerncia a Falhas? um atributo que habilita o sistema para ser tolerante a falhas. o conjunto de tcnicas utilizadas para detectar, mascarar e tolerar falhas no sistema. Observao: A indstria no aceita bem o termo TF, preferindo os termos: Sistemas redundantes (visa confiabilidade), alta disponibilidade (visa disponibilidade 99.999%). Tentativa de unificao com segurana de funcionamento confundiu com aspectos de segurana. Atualmente um termo mas amplo, dependabilidade, est se tornando popular.
Definio de Dependabilidade: Uma propriedade de um sistema computacional, tal como funcionalidade, usabilidade, desempenho e custo. Dependabilidade diz respeito habilidade para entregar um servio comprovadamente confivel (trust), ou seja, habilidade do sistema para evitar defeitos inaceitveis para seus usurios. Possveis Causas de Falhas: descuidos na especificao (especificao incorreta de algoritmos, arquiteturas ou projetos de HW e SW), descuidos na implementao (codificao equivocada ou utilizao de componentes de baixa qualidade), defeitos de componentes (imperfeies na fabricao, ou defeitos randmicos), distrbios externos (radiaes, interferncia eletromagntica), lgica maliciosa (falhas causadas por cavalos de tria, programas ativados por tempo ou lgica bombas lgicas, falhas causadas por vrus ou worms/backdoor), intruso (explorao de falhas internas ou externas/hackers), projeto de software mal estruturado (podem levar ao envelhecimento do software/entropia inchao ou esvaziamento da memria, bloqueio de arquivos, fragmentao, etc.). Atributos da Dependabilidade: Disponibilidade diz respeito mdia de tempo disponvel para acesso, Confiabilidade diz respeito continuidade da entrega de servio correto, Integridade impedimento de alteraes de estado imprprias, Segurana (safety) diz respeito a garantias de no haver defeitos catastrficos ao usurio ou ambiente, Confidencialidade impedimento de acesso indevido, Mantenabilidade habilidade para reparo e modificaes eficientes, Segurana (security) proteo contra acessos, ou controle, no autorizados ao estado do sistema, Testabilidade facilidade para testar o sistema (ponto de teste, testes automatizados). Tolerncia a Falhas em SD: SD deveriam ser tolerantes a falhas e sistemas tolerantes a falhas deveriam ser distribudos. SD tm redundncia intrnseca que pode ser utilizada para TF. Incluem mltiplos processadores independentes que podem incrementar o desempenho do sistema atravs de paralelismo, reduzindo custos da TF. Contm mltiplos componentes, o que incrementa o risco de defeitos, requerendo o uso de tcnicas de TF. Implementar SDTF difcil por muitas razes: Sincronizao (Deve evitar conflitos e deadlocks), Deteco de Falhas/Defeitos (Deve ter uma viso consistente de quais componentes falham e em que ordem), Recuperao (Deve prover mecanismos de recuperao para atuarem aps defeitos e/ou recuperaes), Consistncia (Deve manter uma viso consistente do sistema independente das falhas e recuperaes).
Soluo
Como estruturar um sistema para suportar TF? Diferentes paradigmas de estruturao: Redundncia de hardware (hot swap), Redundncia de informao (backup online realtime), Redundncia temporal (refazer computaes/aviao civil, msseis), Redundncia de software (clusters).
Sntese da TF em SD ou SDTF: Redundncia o requisito chave para implementar qualquer Sistema Tolerante a Falhas. Ns necessitamos de tcnicas de gerenciamento de replicao para facilitar a implementao de Sistemas Tolerantes a Falhas. As caractersticas de Tolerncia a Falhas devem ser transparentes aos programadores e usurios do Sistema Tolerante a Falhas. Tolerncia a Falhas incrementa a complexidade do sistema. Implementar sistemas paralelos e/ou distribudos como Tolerante a Falhas uma tarefa difcil. H necessidade por ferramentas de suporte implementao de sistemas distribudos TF.
Outras Questes
Estudo de Caso: eBay Staying Online Always (disponvel no endereo:
http://www.icmrindia.org/free%20resources/casestudies/EBAY%20IT1.htm)
In January 2001, eBay, the largest online auctioneer (leiloeiro) in the world, saw a major outage (interrupo) 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.
(...) 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.
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 aplicaes Web? R: Com Web Gardens (nico servidor, com mltiplos processadores), Web Farms (mltiplos servidores). o A Web farm takes the concept of a Web garden and extends it to multiple computers. o o Ambos aumentam a escalabilidade e a confiabilidade de aplicaes Web. 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 Solues: Banco de Dados, Processo em Separado, Middleware
(dispatcher). Backup onsite torres gmeas. Disponibilidade 99.999% - 5 minutos de paradas no previstas ao ano.
Exerccios
1. Explique por que sistemas de informao tendem a ser entrpicos. 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 aplicaes Web, como fazer a gesto da sesso em um ambiente clusterizado?
Aula 8 Segurana em Ambientes Distribudos

Cenrio-Exemplo
Algumas ameaas segurana dos sistemas distribudos so bvias. Por exemplo, na maioria das redes locais fcil instalar um programa que obtenha cpias 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, atravs de um ponto de conexo sobressalente. Outras ameaas so mais sutis. Um programa pode se instalar como um servidor de arquivos e obter cpias de informaes 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, mostsignificant 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.
Motivao
A maioria das falhas de segurana causada pelo ser humano, e intencionalmente. Inicialmente os hackers eram adolescentes ou estudantes que participavam de um jogo. Atualmente as falhas de segurana podem representar grandes prejuzos para as empresas. Os hackers tornaram-se profissionais. Proteger os dados corporativos torna-se questo de sobrevivncia para as empresas.
Desafios
Transmisso/Armazenamento seguro de informao 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 Segurana em Cdigo Mvel Como confiar em cdigo vindo do exterior (Internet no
celular/Android Market)? Afetar consistncia, desempenho, disponibilidade (PSN 2011), etc.
Conceitos Bsicos
Os princpios bsicos de segurana em sistemas de comunicao compreendem: Confidencialidade (criptografia/https) - tem por objetivo proteger a informao intercambiada prevenindo-a de acessos no autorizados; Integridade (checksum) deve garantir a veracidade da informao protegendoa de modificaes no autorizadas; Autenticidade (certificados) visa garantir a identidade dos parceiros do intercmbio atravs da autenticao dos usurios; Disponibilidade (redundncia) objetiva prevenir interrupes na operao da rede garantindo a disponibilidade do uso da informao. Os usurios podem estar interconectados (com as suas aplicaes distribudas) atravs de redes abertas, no-confiveis, que podem ser compartilhadas por outros usurios - os quais no esto autorizados a acessar determinados sistemas. Assim sendo, necessrio identificar e autenticar o usurio que solicitar conexo ao sistema, bem como verificar se ele possui autorizao para acessar os recursos solicitados. A identificao o processo inicial para verificar se o usurio est cadastrado no sistema; normalmente essa identificao realizada atravs de um user-id (sugesto email/mensagem de erro usurio ou senha). A autenticao a etapa seguinte na qual o usurio dever provar sua identidade. Antigamente este processo era sinnimo de password (senha), porm atualmente podemos classificar os mtodos de autenticao do usurio em trs categorias: Algo que o usurio conhea - o sistema indaga por uma informao que o usurio tenha conhecimento, sendo o caso tpico da password; Algo que o usurio possua - o sistema solicita a apresentao de algo fsico que o usurio tenha, podendo ser desde um simples carto magntico, at sofisticados dispositivos eletrnicos (bancos: iToken, cartes); Algo que o usurio seja - esta categoria est relacionada como os sistemas biomtricos que so mtodos automatizados para verificar a identidade de uma pessoa, baseando-se em alguma caracterstica fisiolgica ou comportamental.
Cuidados
Processos de onboard/offboard 900 funcionrios, 2.000 contas ativas. Vulnerabilidade: So erros no projeto ou configurao dos Sistemas Computacionais que podem ser exploradas para se produzir falhas intencionais ou no. Ataque: So investidas contra os Sistemas Computacionais para explorar as suas vulnerabilidades e causar falhas intencionais. Podem assumir varias formas: destruio, modificao, roubo, revelao da informao ou interrupo de servios.
Ataque (Taxonomia):
Personificao: uma entidade faz-se passar por outra. Replay: uma mensagem, ou parte dela, capturada, armazenada e
posteriormente retransmitida. Modificao: o contedo de uma mensagem alterado (Query String). Recusa ou Impedimento de Servio (DOS): interrupo de algum servio (gerao de mensagens em grande quantidade). Ataques Internos: um usurio executa uma operao no autorizada para o mesmo. Armadilhas (trapdoor): uma entidade legitima substituda por outra alterada. Cavalos de Tria: entidade falsa produz o mesmo servio que a legitima com o intuito de se camuflar e executa uma operao adicional no autorizada (moedas verdes - Orkut 2010). Spoofing: interceptao da comunicao entre dois hosts por um host no autorizado (arquivo hosts = spoofer).
Sniffing: usa o principio da propagao da mensagem atravs do meio fsico para ouvir todos as mensagens que nele trafegar. Normalmente este tipo de ataque usado na preparao de outros ataques.
Intruso: o resultado de um ataque bem sucedido. Ameaa: probabilidade potencial de um Sistema Computacional ser alvo de um ataque. Risco: probabilidade potencial de um Sistema Computacional ser invadido (Vulnerabilidade X Ameaa).
Polticas de Segurana
Regras e prticas para proteger informaes e recursos: Nvel (D1 D4: classificao de documentos) de sensibilidade da informao; Identidade do usurio.
Poltica dos 4P: Paranica: 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 Segurana de Sistemas: Autenticidade: garantir-se que um usurio realmente quem se diz ser e as aes a ele atribudas tenham sido realmente de sua autoria; Confidencialidade: usurios autorizados tenham acesso s informaes devidas e ningum mais; Integridade: garante que um documento autntico no foi alterando acidentalmente ou intencionalmente ou que esteja sendo reutilizado sem que seja percebido; Disponibilidade: continuidade dos seus servios acessveis aos usurios autorizados. Mecanismos de Segurana - Autenticao:
Controle de Acesso: Access Control List - lista com a identificao do usurio ou processo e suas permisses para cada objeto; Capabilities - lista para cada usurio ou processo com a identificao do objeto e suas permisses; Access Control Matriz - uma matriz onde as linhas so compostas pelos usurios, as colunas por objetos e os elementos so listas de permisses (Capability X ACL).
Criptografia
Transformar um texto em claro em um texto codificado atravs de um algoritmo de criptografia. O mtodo de criptografia confivel e seguro quando ele de domnio pblico: Criptografia Simtrica: a chave utilizada para criptografar um texto a mesma para descriptograf-lo - DES (Data Encryption Standard); Criptografia Assimtrica: a chave para criptografar uma mensagem diferente da chave para descriptograf-la - RSA (Rivest, Shamir e Adleman). Outros mtodos e padres (Assinatura digital, Messages Digests - MD5, etc.) Topologias dos Sistemas Seguros - Segurana na Arquitetura TCP/IP: IPv4 no possui nenhum mecanismo de segurana. Normalmente adicionamos uma camada de segurana, como o Secure Sockets Layer (SSL): Desenvolvida pela Netscape (RFC 2246), possui autenticao e criptografia simtrica, fica entre as camadas de Transporte e Aplicao. J o
Internet Protocol Version 6 (IPv6) possui segurana IPSec, espao de endereamento IP, Qualidade de servio (QoS) VoIP por exemplo. O IPv6 a verso 6 do protocolo IP. O IPv6 tem como objetivo substituir o padro anterior, o IPv4, que s suporta cerca de 4 bilhes (4 x 109) de endereos, enquanto que o IPv6 suporta 3.4 x 1038 endereos. A previso atual para a exausto de todos os endereos IPv4 livres para atribuio a operadores de Janeiro de 2014, o que significa que a transio da verso do IPv4 para o IPv6 inevitvel num futuro prximo. O governo dos Estados Unidos da Amrica determinou que todas as suas agncias federais devem suportar o protocolo IPv6 at 2008. Circuitos de criptografia: hardware ou software: Physical Circuit Encryption: camadas Fsica ou de Enlace, Virtual Circuit Encryption: camada de Aplicao.
Seleo de Trafego: Switches - Melhoram a performance, Anulam ataques tipo Sniffing; Roteadores ou Switches com suporte a VLANs - Isolam o trafego at o nvel de rede, Poltica de Segurana especifica para cada subrede. Hub vs. Switch barramento vs. estrela. Firewalls, Filtros e Proxies: so softwares que operam em hosts conectados em mais uma rede. O trafego de entrada e sada deve fluir atravs do firewall. Apenas o trafego autorizado deve fluir atravs 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 atravs do firewall. Os proxies atuam como intermedirios 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 contm todos os servios e
informaes para clientes ou pblicos (por exemplo, servidor de banco de dados do Website). A DMZ pode tambm incluir regras de acesso especfico e sistemas de defesa de permetro para que simule uma rede protegida e induzindo os possveis invasores para armadilhas virtuais de modo a se tentar localizar a origem do ataque. Proteo dos Dados e Servios - Aes para tornarem os sistemas mais seguros: Preveno a ataques, deteco e reao a invases, tolerncia a invases. Circuitos de Criptografia; Uso de certificados de autenticidade Certification Authority (CA);
Gerenciamento de chaves para criptografia simtrica - Key Distribution Center (KDC).
Concluso
Para construir um sistema distribudo seguro, ns devemos projetar seus componentes partindo do princpio de que os agentes do sistema (pessoas e programas) no so confiveis, at que provem o contrrio. No entanto, impossvel produzir um sistema til considerando que no h nenhum componente confivel. Assim sendo, o objetivo passa a ser produzir um sistema no qual um nmero mnimo de componentes sejam considerados confiveis. Os mecanismos de segurana para sistemas distribudos baseiam-se no uso de trs tcnicas: criptografia, autenticao e controle de acesso.
Outras Questes
Arquitetura Fsica em Estrela (Hub) vs. Lgica em Barramento - sniffing. Hacker (pichador) vs. Cracker. Problema dos endereos 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. Segurana da Informao: o Engenharia Social (cuidado com o orkut/comunidades) - enganao, explorao da confiana das pessoas. o Phishing (pescaria). Tentativa de obter informaes se passando por outra pessoa (Bradesco, Norton, Paypal). Exemplos de Phishing Scam: o o o o o o o o o Cobranas de empresas de telefonia celular; Incluso de nome no SERASA; Entrega FEDEX, DHL. Assuntos pessoais (mensagens romnticas); Cancelamento de CPF ou ttulo de eleitor, IR; Um novo vrus avassalador descoberto; Fotos da sua mulher; Fotos minhas, mas no ria; Fotos da festa/escola; Software para capturar senha (vrus), etc..
Chaves Pblicas e Privadas o o o Criptografia assimtrica ou de chave pblica. Passo 1: Alice envia sua chave pblica para Bob. Passo 2: Bob cifra a mensagem com a chave pblica de Alice e envia para Alice. o Passo 3: Alice recebe e decifra o texto utilizando sua chave privada.
SQL Injection o o o o Select * From USUARIO Where logon = & txtLogon & And senha = & txtSenha caixa de texto xpto OR true
Exerccios
1. Como a arquitetura da rede pode influenciar em um possvel ataque por um sniffer. 2. Explique os conceitos de: confidencialidade, integridade, autenticidade e
disponibilidade. 3. Relacione identificao e autenticao. 4. Qual a diferena entre os tipos de ataques spoofing e sniffing. 5. Qual a principal motivao para a implementao do IPv6? 6. Qual a diferena entre um proxy e um firewall? 7. O que uma DMZ? 8. O que phishing scam?
Aula 9 Computao em Grade

Histrico
Em 50 anos de inovaes, a velocidade dos computadores cresceu em torno e um milho de vezes, mas mesmo assim ainda so lentos para poder resolver muitos problemas cientficos. Para se conseguir resolver problemas complicados eram necessrios
supercomputadores, que custavam rios de dinheiro. A evoluo 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 fcil. A ideia de clusters de computadores foi desenvolvida no comeo da dcada de 80. A um custo muito menor, poderia se ter o poder de um supercomputador. Apesar do custo reduzido, toda a infra-estrutura necessria para se montar um cluster grande cara. O que Computao em Grade? Por todo o mundo, muitos recursos computacionais so desperdiados. Enquanto uma pessoa deixa seu computador ligado e vai pegar um caf, milhares de ciclos de CPU que poderiam estar sendo usados so perdidos (estado IDLE). Computao em Grade compartilhar recursos computacionais com outros usurios. Os recursos compartilhados no se resumem a ciclos de CPU, podem ser recursos de armazenagem, utilizao de sensores e recursos de rede. Para que Computao em Grade? Existe realmente um problema especfico para grades, que faa ser necessria a existncia de uma tecnologia de grades? O problema existe, a coordenao de compartilhamento de recursos e soluo de problemas de organizaes virtuais. O que uma Organizao Virtual (IBM World Community Grid
http://www.worldcommunitygrid.org/)? Chamamos de Organizao Virtual quando temos participantes que desejam compartilhar recursos para poder concluir uma tarefa. Alm disso, o compartilhamento esta alm de
apenas troca de documentos, isto pode envolver remoto, acesso direto a software dados,
computadores,
sensores e outros recursos. Descrio da Arquitetura de
Grades: O objetivo na definio dessa arquitetura no definir todos os protocolos, servios e APIs requeridos,
mas ao contrrio identificar requisitos para classes genricas de componentes. A arquitetura foi divida nas seguintes camadas: Base, Conectividade, Recursos, Coletiva e de Aplicaes.
Internet/Web Como Plataforma

A variedade da tecnologia da Web faz com seja um ambiente atrativo para a construo de sistemas e aplicaes. Faltam a eles caractersticas necessrias para ocorrer um modelo mais rico de iterao. Os navegadores atuais normalmente utilizam TLS (Transport Layer Security sucessor do SSL) para fazer autenticao, mas no suportam login nico e delegao.
Tecnologias
Relao com Sistemas de computao distribuda: CORBA, Java Beans, J2EE (J2E) e DCOM (WCF). A forma principal de interao do tipo cliente-servidor, e no de uso coordenado de recursos mltiplos. Tornam mais fcil compartilhar recursos com uma nica organizao. No entanto, esses mecanismos no resolvem os requisitos especficos listados anteriormente. As tecnologias de desenvolvimento de aplicaes distribudas teriam que ser adaptadas aos requisitos da Grade. Uma opo seria construir um servio de Nomes que utiliza o servio de informao da Grade para procurar fontes distribudas de informao atravs de grandes organizaes virtuais. Relao com Internet e Computao Ponto a Ponto: eMule (eDonkey), BitTorrent, Kazaa, Gnutella compartilham arquivos. SETI@home e ProteinFolding@Home compartilham ciclos de cpu. No inter-operam entre si. Compartilham arquivos, por exemplo, mas sem nenhum controle de acesso. Com a evoluo dessas aplicaes elas acabaram por inter-operar e haver uma convergncia de interesses entre computao ponto a ponto, Internet e computao em Grade. Outras perspectivas sobre Grades: Computao em Grade prxima gerao da Internet so protocolos adicionais que so construdos sobre a tecnologia da Internet. Qualquer recurso que esteja na Grade, tambm est na Rede. A Grade uma fonte de ciclos grtis. computao em Grade controle de compartilhamento. Os donos dos recursos tero polticas de restrio ao acesso a eles, dependendo do usurio. A Grade torna supercomputadores desnecessrios muitos problemas precisam de supercomputadores para serem resolvidos, com baixa latncia e comunicao rpida. Com a grade o acesso a esses supercomputadores fica muito mais fcil, 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 esto se tornando algo popular. A idia por trs tanto dos clusters quanto dos grids basicamente a mesma: combinar o poder de processamento de vrios computadores ligados em rede para conseguir executar tarefas que no seria possvel (ou pelo menos no com um desempenho satisfatrio) executar utilizando um nico computador e ao mesmo tempo faz-lo a um custo mais baixo que o de um supercomputador de potncia semelhante. Os clusters e grids podem ser compostos tanto permanentes, quanto temporrios, formados para executar uma tarefa especfica e depois desfeitos. Presumindo que todos os computadores estejam previamente ligados em rede, a criao e dissoluo apenas questo de ativar e depois desativar o software responsvel em cada computador. A principal diferena entre um cluster e um grid que um cluster possui um controlador central, um nico ponto de onde possvel utilizar todo o poder de processamento do cluster. Os demais ns so apenas escravos que servem a este n central. Os clusters so mais usados em atividades de pesquisa, resolvendo problemas complicados e na renderizao de grficos 3D. Clusters tambm so homogneos, enquanto grids so heterogneos. Os grids por sua vez so uma arquitetura mais "democrtica" onde embora possa existir algum tipo de controle central, temos um ambiente fundamentalmente cooperativo, onde empresas, universidades ou mesmo grupos de usurios 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 pases com fusos-horrio diferentes poderiam formar um grid, combinando seus servidores web, de modo que uma possa utilizar os ciclos de processamento ociosos da outra em seus horrios de pico, j que com horrios diferentes os picos de acessos aos servidores de cada empresa ocorrero em horrios diferentes.
Concluso
Podemos traduzir ento que, um Grid Computacional resume-se em: Computadores em diferentes localidades; Rede de grande rea; Apropriados para computao intensiva, altodesempenho; Ambiente colaborativo; Grande quantidade de dados; Diferentes organizaes; Permitem compartilhar, agregar e escolher recursos computacionais dos mais variados tipos: supercomputadores, dispositivos especiais - telescpios, radares, etc., sistemas de armazenamento, bancos de dados, computadores comuns.
As dificuldades encontradas so muitas, e os estudos so incessantes nessas reas, destacando-se: Localizao dos recursos; Reserva de recursos; Capacidade para adaptar-se a mudanas no ambiente; Criao e escalonamento das tarefas; Autonomia de cada grupo participante para definir suas prprias polticas de segurana; Recursos requisitados podem estar em diferentes localidades; Qualidade de servio exigida por cada aplicao. No futuro bem prximo as aplicaes baseadas na web vo usufruir os benefcios das grades computacionais, teremos ento uma evoluo natural dos sistemas localizados sendo acessveis mundialmente e o aluguel de recursos computacionais ociosos, principalmente aqueles relacionados a processamento massivo.
Outras Questes
Clusterizao versus Virtualizao. o Muito se fala em virtualizao. O que isso? A IBM lder em virtualizao, servio que permite ao cliente compartilhar atividades, rodando vrias aplicaes em um mesmo servidor. Num exemplo prtico, se um servio de email estiver em uso num horrio do dia, o servidor direciona capacidade para isso. Depois, quando o email j no estiver sendo usado, o servidor muda essa capacidade computacional para outro servio. o Mainframe Quanto custa? Usar um mainframe para trocar 100 mquinas (ecologia,
manuteno, backup, energia) Cluster/Grid Sistema operacional de rede/Aplicao.
Supercomputador (clculos complexos, performance) versus Computador de Grande porte (mainframe/vazo, suportar um grande nmero de usurios simultneos).
Cloud computing: a expresso do momento em tecnologia. Nomes de peso como Amazon, AT&T, Dell (tentou patentear), HP, IBM (US$300 milhes), Intel, Microsoft e Yahoo j anunciaram planos e investimentos na rea e o Gartner acaba de liberar um relatrio que aponta o cloud computing como uma das trs mais importantes tendncias emergentes nos prximo trs a cinco anos. o Tecnicamente falando o Cloud Computing est fundamentado
principalmente na Virtualizaao de aplicaoes de forma que a configuraao da capacidade dos servicos (IaaS, PaaS, SaasS) seja dinamicamente alterada em vo de acordo com a necessidade do cliente; (Ex. O cliente solicita que o total de memoria do servio de banco de dados DB2 que ele aluga como servio (PaaS - Plataforma como Servio) fosse aumentado de
1 para 2GB) para o cliente ele nao se preocupa em contratar uma nova instalaao do banco de dados em um servidor de 2 GB pois fornecedor 'virtualizou' essa instalaao 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 computao
(processamento, armazenamento e softwares) est em algum lugar da rede e acessada remotamente (obviamente atravs de um middleware), via internet. O que realmente significa que algum vai assumir a responsabilidade de entregar algumas funes de TI como servios para alguns clientes e eles no precisam saber como funciona, eles
simplesmente usaro, esclarece Daryl C. Plummer, vice-presidente do Gartner. Protocolos Internet (TCP/IP) o o CAMADA PROTOCOLO http, smtp, ftp, ssh, rtp, telnet, sip, rdp, irc, snmp, nntp,
5 Aplicao
pop3, imap, BitTorrent, dns, ping, etc.. o o o 4 Transporte 3 Rede 2 Enlace TCP, UDP, SCTP, DCCP, SSL, TLS, etc..
IP (IPv4, IPv6, ARP, RARP, ICMP, IPSec, etc.. Ethernet, 802.11, Wi-Fi, IEEE 802.1Q, 802.11g, HDLC,
Token Ring, FDDI, PPP, Switch, Frame Relay. o 1 Fsica Modem, RDIS, RS-232, EIA-422, RS-449, Bluetooth, USB.
Exerccios
1. Qual a diferena entre um supercomputador e um computador de grande porte? 2. Qual a diferena 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 Anlise de Desempenho de SD [ESTUDO DIRIGIDO]

Introduo
Considere o problema de avaliar o desempenho de um SD sendo executado sobre uma rede homognea de estaes 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 solues propostas para algoritmos de balanceamento de carga em sistema de realidade virtual distribudo, essa metodologia consiste em seguir os alguns passos bsicos que so: definio do escopo do sistema analisado, definio dos servios oferecidos pelo sistema em estudo, definio das mtricas utilizadas na anlise de desempenho, definio dos parmetros que influenciam o desempenho do sistema e que alteram a carga de trabalho que o sistema atende, definio das tcnicas de avaliao e da carga de trabalho utilizadas em experimentos, projeto dos experimentos realizados, e descrio de como so apresentados e analisados os resultados obtidos a partir dos experimentos. Definio do Sistema: O primeiro passo definir o escopo do sistema analisado, devese determinar quais equipamentos e componentes de software fazem do sistema de computao sendo analisado. Somente os equipamentos e componentes de software presentes na definio do sistema devero ser considerados ou analisados durante os experimentos para a avaliao de desempenho. Identificao dos Servios: Neste passo, sero identificados os servios oferecidos pelo sistema em estudo e ser determinado para quais desses servios ser realizada anlise de desempenho. Escolha das Mtricas de Desempenho: Esta etapa consiste na definio das mtricas utilizadas na anlise de desempenho. Tambm importante dizer se as mtricas utilizadas consideraro a ocorrncia de possveis falhas no sistema. Geralmente trs classes diferentes de mtricas so utilizadas para avaliar o desempenho de algum recurso ou sistema: 1. throughput ou taxa de sada - o throught mede o nmero de servios que o sistema ou recurso consegue realizar por unidade de tempo. Suponha que o recurso sendo analisado um processador e cujo principal servio a execuo de processos, ento o throughput do sistema ser o nmero de processos completados por segundo. 2. utilizao - a utilizao de um recurso ou sistema a relao entre o intervalo de tempo em que o sistema esteve ocupado servindo os servios requisitados e o intervalo de tempo total em que o recurso ou sistema esteve executando ou disponvel para uso. Se um processador fosse ativado por uma hora e passasse 18 minutos ocioso e os outros 42 minutos ocupado, sua utilizao seria igual a 70%.
3. tempo de resposta - o tempo de resposta o intervalo de tempo decorrido entre o momento que servio requisitado e o momento em que este servio acaba de ser atendido. Num sistema distribudo que segue a arquitetura cliente-servidor, o tempo de resposta compreende o tempo que a requisio do cliente leva para trafegar pela rede at o servidor (atraso de rede = tempo de transmisso da mensagem + tempo de propagao do sinal no meio fsico), mais o tempo no qual a requisio 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 requisio (tempo de servio), mais o tempo que o resultado do processamento da requisio leva para ir do servidor ao cliente (atraso de rede). A mtrica mais utilizada na literatura a mdia do tempo de resposta dos servios. Identificao dos Requisitos de Desempenho do Sistema: Os sistemas de computao geralmente possuem requisitos de desempenho os quais eles devem satisfazer para que ele possa ser utilizado eficientemente pelos seus usurios. Este requisitos devem ser identificados e considerados durante os experimentos. Uma tcnica que melhore de alguma maneira o desempenho de parte do sistema, mas que leve o sistema como um todo a no satisfazer um determinado requisito no dever ser utilizada na implementao do sistema. Identificao dos Parmetros 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 parmetros dizem respeito ao sistema sendo avaliado, como por exemplo, o poder de processamento dos processadores ou a banda passante sustentada pela rede, outros parmetros so relativos carga de trabalho atendida pelo sistema, com por exemplo, o nmero de processos na fila de espera na CPU ou o nmero de hosts ligados rede. Identificao dos Fatores que Influenciam o Experimento: Como dezenas de
parmetros do sistema ou da carga de trabalho podem afetar o experimento a ser realizado, um nico experimento poder consumir um longo perodo de tempo para ser realizado. Entretanto, a influncia de alguns parmetros pode ser considerada menos importante que a influncia de outros parmetros. Portanto, nem todos os parmetros precisam variar durante os experimentos e podem ser considerados constantes. Os parmetros que iro mudar de valor durante o experimento so chamados fatores. Para cada fator devem ser determinados os valores que ele poder assumir durante o experimento. Definio da Tcnica de Avaliao a ser Utilizada: Para se avaliar o desempenho de um sistema, geralmente, utiliza-se uma das trs tcnicas a seguir: Medio - quando o sistema sendo avaliado j foi implementado so inseridas instrues especiais no cdigo do sistema. Estas instrues calculam e anotam, ao longo de todo o experimento, os valores das mtricas de desempenho escolhidas . Depois, realiza anlises estatsticas sobre estes dados.
Simulao - construdo um modelo matemtico que representa adequadamente o sistema sendo avaliado e este modelo simulado. Durante a simulao as mtricas de desempenho so anotadas e depois realiza anlises estatsticas sobre estes dados. Modelagem Analtica construdo um modelo matemtico que representa
adequadamente o sistema sendo avaliado, geralmente este modelo baseia na Teoria das Filas. Ento, este modelo resolvido analiticamente e tenta-se encontrar frmulas matemticas fechadas com quais possvel calcular as mtricas escolhidas em funo dos fatores do experimento. Caracterizao e Gerao da carga de Trabalho: Nesta etapa, sero escolhidos critrios 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 distribudos para saber mais sobre caracterizao da carga de trabalhos de sistemas de computao. Existem trs formas bsicas para se gerar a carga de trabalho de sistemas de computao:
Benchmark
Comparaes entre sistemas. Benchmarks so programas sintticos e por vezes padronizados que geram requisies ao sistema sendo avaliado. O problema encontrado na utilizao 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 so arquivos que registram as requisies atendidas por um sistema de computao durante um determinado intervalo de tempo. Estes arquivos podem servir de entrada para um programa que o percorre do incio ao fim gerando para o sistema sendo avaliado as mesmas requisies 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 semelhana poder ser perdida. Alm disso, muito difcil conseguir um trace de um sistema devido ao interesse econmico sobre as informaes nele contidas. - uso real - outra maneira de se gerar a carga de trabalho colocando o sistema em funcionamento e solicitar a usurios previamente selecionados que o utilizem de forma intensiva. O problema com esta tcnica que o sistema deve estar implementado, o perfil dos usurios pode influenciar na carga de trabalho gerada e que devem existir usurios disponveis para realizar o experimento. Se voc deseja testar o desempenho de um sistema com milhares de usurios simultneos esta tcnica pode se tornar impraticvel. Projeto dos Experimentos Realizados: Deve ser descrito em que condies os experimentos sero realizados e como os experimentos sero realizados, por exemplo:
Os experimentos sero realizados quando nenhum externo ao sistema estiver presente na rede; Todas as mdias sero calculadas considerando-se 10 amostras. Anlise e Apresentao dos Resultados: Esta a ltima etapa da metodologia que estamos apresentando. Nela, deve ser descrita a maneira segundo a qual os resultados sero analisados e como os resultados sero apresentados s pessoas interessadas. aconselhado o uso de grficos. Tente evitar fornecer a mdia das mtricas sem dizer para qual intervalo de confiana a mtrica foi calculada. Evite usar desvio padro ou varincia para descrever a variabilidade dos resultados em relao mdia, d preferncia ao coeficiente de variao.
Outras Questes
O desempenho como um requisito no funcional.
Exerccios
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 Computao Distribuda

Introduo
Sistema de software um artefato evolutivo e requer constantes modificaes, 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 utilizao de novas tecnologias, tem motivado os pesquisadores a investigar solues que diminuam os custos de desenvolvimento, garantam um tempo de vida maior para o sistema e facilitem a manuteno. As tcnicas atuais utilizam basicamente a Orientao a Objetos e a Computao Distribuda como principais alicerces. Os componentes de software devem ser reutilizados em todos os nveis de abstrao do processo de desenvolvimento e no simplesmente no nvel de cdigo. O que um Componente? Definio de Componente - ECOOP96: 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 Distribudos
A utilizao de componentes distribudos teve um grande impacto na engenharia de software. O desenvolvimento orientado a componentes, o uso de componentes distribudos (remotos) nos modelos arquiteturais (N Camadas) e o uso da arquitetura MDA (Model Driven Architecture) so muito citados na engenharia de software. Tecnologias mais utilizadas para a implementao de componentes distribudos: CORBA, WebServices, EJB, DCOM .NET Remoting / Windows Communication Foundation (WCF) e Internet Communications Engine (Ice). Viso Geral de Componentes de Software: O ciclo clssico de desenvolvimento de software composto de quatro fases (anlise, projeto, implementao e teste) tem sido empregado desde os primrdios da engenharia de software, sendo genrico o suficiente para ser aplicado a qualquer processo de desenvolvimento de software. Atualmente, as tcnicas de desenvolvimento de software devem contemplar tambm a qualidade, capacidade de integrao, especializao e manuteno de sistemas de software de natureza distribuda. Um ponto crucial para o software de natureza distribuda a incorporao ao modelo do sistema de fatores pertinentes distribuio. No ciclo clssico de desenvolvimento, a natureza distribuda 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 implementao com o auxlio de uma plataforma de middleware tal como CORBA, DCOM ou Java RMI. importante observar que mesmo os
modernos processos de desenvolvimento so deficientes para o desenvolvimento de tais sistemas. Esta deficincia se deve ausncia de estratgias que permitam construir sistemas com alto ndice de reuso, evoluo e gerao automtica de cdigo (code generators). Recentemente, devido aos avanos da tecnologia e introduo de padres (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, no se pode considerar uma inovao o conceito de componentes como blocos de construo para o desenvolvimento de sistemas. Os desenvolvedores de software sempre tiveram a convico de que sistemas de grande porte e complexos podiam ser construdos pela interconexo de blocos de construo menores, prdefinidos e oriundos de desenvolvimentos anteriores ou adquiridos no mercado. Entretanto, somente agora as tecnologias envolvidas tm evoludo no sentido de atingir este objetivo.
Desenvolvimento Orientado a Componentes

Os benefcios, com a utilizao deste novo paradigma, incluem produo de software de forma rpida, com menor custo de desenvolvimento, de alta qualidade
(certificao/processo) e de fcil manuteno. Esses objetivos so atingidos principalmente pelo reuso de componentes, interligao explcita entre os componentes (resultando em baixo acoplamento), alta coeso (componentes so altamente especializados) e gerao automtica de cdigo. 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 (interao entre componentes em diferentes de diferentes
fornecedores),
portabilidade
(componentes
distribudos
plataformas),
estensibilidade (adio de novas funcionalidades aos componentes) e coexistncia com sistemas legados.
Padres para Empacotamento e Distribuio

Um modelo de componentes precisa descrever a forma como os componentes so empacotados e distribudos, tal que possam ser instalados independentemente. O processo de distribuio utiliza componentes empacotados em arquivos de formatos tais como ZIP, JAR (Java Archive), EAR, WAR ou DLL (Dynamic Linking Library), MSI, contendo as
implementaes e informaes necessrias para instalar e personalizar as implementaes de componentes, criar instncias de componentes e interconect-las de modo a proporcionar aplicaes na forma executvel. importante enfatizar que todos os recursos necessrios para a execuo de um componente, incluindo a especificao das dependncias de contexto, precisam ser instalados junto com o componente. Deste modo, o componente executar apropriadamente as suas funes somente quando tais recursos forem disponibilizados ao componente.
Um componente distribudo em uma plataforma de componentes. No modelo de componentes, o padro de distribuio especifica a estrutura e as semnticas para as descries de distribuio e pode definir, tambm, o formato dos pacotes. Uma descrio de distribuio deve fornecer informaes necessrias para o processo de distribuio, tais como os recursos necessrios na mquina em que os componentes sero instalados, outros componentes, bem como os aspectos de configurao e especializao. Esta descrio analisada pela infraestrutura de componentes da mquina destino para a apropriada instalao e configurao dos componentes. Um componente para ser instalado independentemente precisa ser completamente separado de seu ambiente de execuo e de outros componentes. Conseqentemente, o componente encapsula a sua implementao, ou seja, os dados e algoritmos imprescindveis para executar as suas tarefas. O processo de distribuio tipicamente envolve trs fases: instalao, instanciao e configurao de componentes.
Outras Questes
Robert Martin 2002: A unidade de reuso o pacote. o o Java: package. .NET: namespace. Atributos (Reflection)
Metadados: (Banco/Annotations) o o
Criao automatizada de telas. Gerao automtica de SQL.
JEE o EJB 3.0
Exerccios
1. O que um componente de software? 2. O que um design pattern? 3. Explique o fato de que desejvel que os componentes tenham baixo acoplamento e alta coeso.
Aula 12 Microsoft .NET Remoting

Introduo
COM: Microsoft Component Object Model: modelo de componentes orientado a objetos, independente de plataforma, destinado criao de componentes de software binrios que podem interagir entre si. um conjunto de servios (APIs) que so fornecidos por uma biblioteca (biblioteca COM). Componentes podem estar num mesmo processo, processos diferentes ou mquinas diferentes (DCOM).
DCOM
Microsoft Distributed Component Object Model a extenso do COM para ambientes distribudos. DCOM substitui a comunicao local entre processos por um protocolo de rede (transparente para o cliente). Trata detalhes de baixo nvel de protocolos de rede enquanto o desenvolvedor foca no negcio. Oferece mecanismo de segurana: autenticao e encriptao de dados.
.NET Remoting
um mecanismo de interoperabilidade que pode ser usado para fazer chamadas de cdigo .NET em mquinas 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 utilizao em aplicaes que rodem em redes internas (LANs) muito interessante. O .NET Remoting oferece algumas vantagens, tais como: Possibilidade de configurar o canal de comunicao (TCP ou HTTP); Configurao da porta (TCP 80); Uso de arquivo de configurao para cliente e servidor, evitando a necessidade de recompilao dos cdigos no evento de alterao de configurao. Esquema da arquitetura do .NET Remoting:
.NET Framework
O .NET Framework um modelo de programao de cdigo gerenciado da Microsoft para criar aplicativos em clientes (console/GUI), servidores (servios/Web) e dispositivos
mveis ou incorporados do Windows. Os desenvolvedores podem usar o .NET para criar aplicativos de vrios 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 princpios de projeto que tornaram o COM to 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 aplicaes distribudas, recomendvel utilizar preferencialmente .NET (cdigo gerenciado).
Diferenas entre o Microsoft .NET Remoting e o DCOM

DCOM baseado no protocolo RPC e o .NET usa SOAP. DCOM no trabalha com firewall amigavelmente, j .NET sim, pois suporta HTTP. A utilizao maior do DCOM para plataformas Windows, j .NET suporta vrias plataformas. Manutenibilidade - complexa no DCOM (registrar), .NET usa XML. No DCOM, a ativao do servidor feita pelo SCM (Service Control Manager) atravs da requisio do cliente, no .NET ocorre falha se o servidor no estiver inicializado. Segurana, no DCOM depende do Sistema Operacional, .NET no. Concluindo: A diversidade de cenrios em que uma aplicao distribuda pode ser executada considervel, incluindo ambientes heterogneos, constitudos por computadores que apresentam arquiteturas e sistemas operacionais diferentes, e aplicaes implementadas em diferentes linguagens de programao. Isso torna o desenvolvimento de aplicaes distribudas consideravelmente mais complexo do que o desenvolvimento de aplicaes centralizadas. Com o objetivo de amenizar os problemas oriundos desse ambiente heterogneo, foi proposta a introduo de uma camada de software, chamada middleware, entre as aplicaes e seus sistemas operacionais subjacentes, fornecendo aos desenvolvedores de aplicaes distribudas, uma interface de programao de alto nvel, a qual objetiva ocultar as dificuldades inerentes a esse ambiente (transparncia). Com o sucesso da tecnologia, diversas plataformas de middleware foram desenvolvidas para apoiar a implementao de sistemas distribudos. Dentre elas, destacam-se as plataformas Java RMI, CORBA, .NET Remoting, JAX-RPC e Apache Axis. Assim, plataformas de middleware so largamente empregadas por engenheiros de software para simplificar e tornar mais produtivo o desenvolvimento de aplicaes distribudas. Basicamente, estes sistemas encapsulam diversos detalhes inerentes
programao em ambientes de rede, incluindo protocolos de comunicao, heterogeneidade de arquiteturas, marshalling e unmarshalling de dados, sincronizao, localizao de servios, etc.
Outras Questes
WCF.
Exerccios
1. possvel trabalhar com WCF (ou .NET Remoting) atravs de um firewall?
Bibliografia/Crditos
Sistemas Distribudos - Walfredo Cirne, Fubica Brasileiro Aspectos Estratgicos da Computao Distribuda - Joo Sobral, Daniela Claro EAI - Leonardo Chaves Estratgia Competitiva - Alceu Alves O que o Middleware Prof. Michael Stanton Objetos Distribudos com Java - Ivan Marques DCA/FEEC/UNICAMP Balanceamento de Carga em Sistemas Distribudos de Propsito Geral Prof. Tiago Carneiro Programao Distribuda - Prof. Henrique Mongelli Sistemas Distribudos (Introduo e Conceitos) - Prof. Rodrigo de Grazia FACECA Transaes Distribudas - Guilherme Galante - PPGC - II UFRGS Transaes Distribudas - Ricardo Anido TOLERNCIA A FALHAS EM SISTEMAS DISTRIBUDOS: A ABORDAGEM DO CORBA/FT Fbio Mendona. Tolerncia a Falhas em Sistemas Distribudos - Prof. Raul Ceretta Nunes. Segurana em Sistemas Distribudos - Guilherme Machado - Faculdades SENAC Segurana em Sistemas Distribudos - Vidal Martins GPT. Computao em Grade - Uma proposta de Arquitetura para grades. (Autor Desconhecido) Anlise de Desempenho de Sistemas Distribudos Prof. Tiago Carneiro (UFOP) Introduo aos Sistemas Distribudos e Componentes de Software - Eliane Gomes Guimares e CTI Renato Archer Manual .NET do Desenvolvedor - Microsoft Consulting Services. Allyn Lima - Tpicos em Sistemas Distribudos UNICAMP. Aspectos para Construo de Aplicaes Distribudas - Cristiano Amaral Maffort Dissertao 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 protocolos entre
Apndice A Questionrio de Avaliao do Curso

FACULDADE DE INFORMTICA LEMOS DE CASTRO Rio de Janeiro Professor M. Frana Disciplina: CD Data: Aluno: _______________________________________________ Perodo:
________ _____
Observao: O nome opcional, sinta-se livre para omiti-lo! Ateno: Procure dar respostas completas, evitando monosslabos: sim, no, , fui etc.. E no se esquea de perguntar ao professor sobre o 0,5 ponto relativo ao preenchimento deste.
1) O curso: O curso Bacharel em Sistemas de Informao da Faculdade de Informtica Lemos de Castro possui um bom nvel? As matrias so atuais e relevantes? Ele proporciona um ambiente para que alunos interessados possam adquirir conhecimentos aplicveis profissionalmente?
2) A disciplina: A disciplina em questo (CD) possui um contedo atual? O programa foi totalmente coberto? A carga horria semanal foi suficiente para explanao e resoluo de exerccios? As aulas prticas (se for o caso) foram suficientes e em condies adequadas (mquinas)?
3) O professor: O professor possua domnio da disciplina (conhecimento)? Ele explica bem (didtico)? 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 freqenta as aulas assiduamente? Voc faz os exerccios/estuda em casa? Voc presta ateno na explicao do professor? Voc se considera um aluno agitado/disperso? Voc conseguiu aprender os principais conceitos da disciplina? Voc tentou tirar suas dvidas com o professor?
5) Livre: Que sugestes, ou crticas, 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 frias; Sem radicalismos! Teu corao livre. Tenha coragem para segui-lo! Brave Heart FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 87
Artigo publicado
na edio 33
janeiro/fevereiro de 2009
w w w . m u n d o j a v a . c o m . b r
coluna
Ricardo Ferreira (ricardo.ferreira@squadra.com.br) arquiteto de software na Squadra Tecnologia em Belo Horizonte. Na Squadra, atua principalmente em projetos cujo foco integrao de sistemas, solues baseadas em BPM, solues de modernizao de aplicaes e projetos baseados em J2EE. Com mais de 10 anos de experincia, j atuou em solues para bancos, telecom, centrais de energia eltrica, montagem de mquinas, construtoras e universidades. Possui as certificaes 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://architecturejournal.blogspot.com
Iremos, neste artigo, discorrer diversos padres de integrao sobre transformao de mensagens catalogados no EAI Patterns. Por meio da simulao de um cenrio de integrao entre sistemas, iremos mostrar no JBoss ESB como implementar alguns desses padres voltados transformao de mensagens, bem como outros padres de EAI que auxiliam solues de integrao.
Aplicando EAI Patterns

sobre Transformao de Mensagens
Mergulhando nos detalhes conceituais e de implementao sobre padres de transformao de mensagens
uando lidamos com solues de integrao em ambientes corporativos, grande parte do esforo desse tipo de soluo gira em torno de como lidar com os mais variados tipos de dados e formatos nos quais esses dados so armazenados. Se fraco acoplamento a primeira premissa bsica de qualquer soluo de mensageria, acomodar vrios formatos sem fazer com que as aplicaes de origem e destino sejam alteradas, sem dvida alguma ser a segunda premissa bsica. Por exemplo, um sistema de processamento de cartes de crdito pode ter uma representao de um cliente diferente da de um sistema de gerncia de conta bancria de um determinado banco. Uma soluo de CRM tambm pode ter outro tipo de viso sobre o que um cliente ou qual seu formato. Mas se um dado processo de negcio
precisa cruzar informaes destes trs sistemas, como uma soluo de integrao ir lidar com estas diferentes vises sobre um cliente, e por conseqncia como ela ir lidar com os diferentes formatos em que este cliente estar em cada um destes sistemas? Para este tipo de cenrio, o catlogo de EAI Patterns prope uma seo especial de padres conhecidos como padres de transformao de mensagens. Neste artigo, veremos por meio de um cenrio de negcio de uma empresa fictcia, como criar uma soluo de integrao corporativa usando o JBoss ESB como soluo de EAI, e iremos aplicar nesta soluo alguns dos mais importantes padres de transformao de mensagens do EAI Patterns.
Estudo de Caso: Automao da Ativao de um Plano de Internet

A empresa FastNet lder de mercado na prestao de servios de internet banda larga e hospedagem de sites brasileiros. H quase seis anos, ela referncia no mercado brasileiro sobre internet empresarial e internet domiciliar. Nos ltimos meses, a empresa tem observado vrios problemas sobre a qualidade no atendimento ao cliente, no seu setor de call center. Preocupado com o nmero de reclamaes de clientes sobre atendimento, bem com o nmero
www.mundojava.com.br
SOA na Prtica
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens grande de cancelamentos do servio devido ao nvel inferior de atendimento, o diretor de operaes estratgicas da empresa convoca uma reunio para atacar essa situao. Nesta reunio, esto 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 reunio que houve entre os participantes: Fernanda, voc pode nos explicar que tipo de problemas acontece para que o atendimento seja to prejudicado? indaga o diretor de operaes estratgicas a uma das atendentes do call center. Sim senhor. Grande parte dos nossos problemas gira em torno do excesso de trabalho ao realizar a ativao de um plano de internet de um cliente. Deixe-me explicar melhor. Acontece que quando temos em mos um cliente requisitando um plano de internet, temos que segur-lo na linha at que possamos completar a digitao 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 vrios sistemas diferentes, para completar o pedido de ativao de ponto do cliente para um determinado plano de internet. Se ele j fizesse isso pra gente, no teramos metade dos problemas de atendimento que temos hoje. Como no damos conta do nmero de atendimentos a serem feitos, estamos tendo um acmulo de quase 2 mil pedidos de ativao, fora aqueles que todos os dias entram. Estamos estafadas de trabalho, pois temos que ficar todos os dias fora do horrio para dar conta de diminuir este nmero de ativaes pendentes, e ainda temos que ouvir reclamao de clientes esperando pela sua ativao atrasada todos os dias. relata Fernanda. Por que estes sistemas no se comunicam diretamente? Por que no automatizar este processo para evitar esta redigitao? questiona o diretor de operaes para o diretor de TI. que o sistema do call center foi feito h quase dez anos em COBOL, e ele no suporta integrao com as tecnologias dos outros sistemas relata o diretor de TI. No vou admitir este tipo de afirmao, 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 vocs me falam que a tecnologia no d suporte a isso? Troquem a tecnologia, troquem os analistas, mudem os processos, mas eu quero isso resolvido at o final deste ms diz o diretor de operaes, j bastante nervoso. No to simples assim, voc h de concordar comigo que a algum tempo atrs 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 no suporta integrao com outras plataformas, principalmente das plataformas dos outros sistemas em questo. 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 solues de ESBs e SOA que faziam tudo se conectar com tudo. Por que que eles conseguem e ns no? diz o diretor de operaes. As plataformas em questo so nossa soluo de CRM baseada no Oracle Siebel, uma aplicao feita em C++ Builder para o gerenciamento da nossa central de rede, o mdulo financeiro do nosso SAP e um sistema web externo feito em Java que pertence aos nossos parceiros de instalao de pontos nos clientes. diz o diretor de TI. No acredito que nosso mainframe no possa falar com outros sistemas, isso est me cheirando a corpo mole da TI. A IBM sempre cria produtos cujo foco integrao. diz o diretor de operaes. Est correto senhor, existem sim tecnologias capazes de fazer isso funcionar, mas no as possumos hoje em nosso parque de ativos TI. Existe, por exemplo, a soluo 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 soluo? pergunta o diretor de TI. O oramento da TI para este ano j estourou e no irei aprovar mais oramento algum para resolver este problema que pensei nem existir. No mximo, posso aprovar algumas horas de um consultor de integrao para estudar nosso cenrio e propor uma soluo que ser implementada pelos nossos rapazes de TI. Assim que o consultor realizar o trabalho, quero ser informado de todos os passos. Entre em contato com a Squadra Tecnologia em Belo Horizonte, ouvi dizer que eles so muito bons nesta rea. diz o diretor de operaes, finalizando a reunio com os demais.
Posicionando a estratgia da soluo de EAI a ser criada

Depois de realizada a reunio com a direo operacional da empresa FastNet, o diretor de TI da empresa convoca um consultor de integrao para auxilliar na criao da soluo. O consultor, ao chegar na empresa, posicionado sobre o problema sob a tica do pessoal de TI. Neste caso, os problemas apresentados so de comunicao entre sistemas legados diferentes para resolver um problema emergencial do call center. Fernanda, boa tarde! Esse aqui o nosso consultor de integrao de sistemas que ir nos ajudar a resolver aquele problema discutido em nossa reunio. Voc poderia auxililo no entedimento do problema? pergunta o analista de TI para a atendente. Claro! Por favor, sente-se aqui e veja como fazemos uma ativao de plano de internet, estou com um cliente em espera prestes a comear um novo atendimento. diz Fernanda para o consultor de integrao.
Simulando o atendimento de um cliente para ativao de um plano de internet

O consultor de integrao solicita Fernanda para agir normalmente no atendimento, como se ele no estivesse presente. O consultor anota todos os procedimentos medida que ela os executa junto ao cliente. Ele solicita que ela ponha o seu telefone no viva-voz para acompanhar tambm o cliente. A figura 1 mostra o detalhamento do atendimento da atendente com o cliente.
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens
Iniciando a soluo de EAI

Vamos agora conceber como ser o fluxo de processamento da soluo. O fluxo de processamento diz respeito a como os sistemas dos legados sero enlaados. O evento que ir disparar este fluxo de processamento ser a gerao de um arquivo XML que conter todos os dados que so de interesse dos sistemas envolvidos. Neste caso, ser criado um programa COBOL que ler todas as requisies de plano de internet da base de dados do CICS, e para cada requisio lida, gerar um arquivo XML num diretrio estratgico da soluo. Um agendador da plataforma CICS ir ser usado para que toda madrugada este programa COBOL seja executado. Assim que o arquivo XML for criado, ele ser gravado num diretrio compartilhado da rede, onde uma soluo de EAI ler este diretrio continuamente, na espera pela gravao do arquivo. Quando identificado que este arquivo fora gravado, ser iniciado ento o processo de ativao de plano de internet, executado pela soluo de EAI escolhida para a FastNet. A partir deste ponto, o arquivo XML ser verificado, ter seus dados extrados do arquivo, os dados sero transformados, e cada informao ser entregue aos sistemas legados. Um ponto importante desta soluo que ela tambm resolve o problema de eliminar o backlog de ativaes a serem feitas da empresa que estavam atrasados. Em parceria com os analistas COBOL do sistema de call center da FastNet, foi gerado um arquivo XML para cada atendimento feito cuja natureza era solicitao de plano de internet. Desta forma, com todos os pedidos feitos na forma de arquivos XML, a soluo poderia executar todos os pedidos, bastando para isso gravar tais arquivos no diretrio escaneado pela soluo de EAI. Para cada arquivo lido, a soluo de EAI ir criar um contexto transacional para processamento do arquivo, bem como um thread particular para isolar os processos em nvel de aplicao. Futuramente, cada novo atendimento feito pela equipe de call center ir gerar um arquivo XML respectivo ao atendimento, e ser copiado para o diretrio escaneado. Isso possibilita que as atendentes no tenham que se preocupar mais com o backlog de atendimento, no ficando, portanto, at altas horas da noite para tentar diminuir a lista de pendncias, bem como escalar bem mais atendimentos por dia, garantindo que a instalao do ponto de internet no cliente ser feita na data negociada durante a aquisio do plano.
Figura 1. Cenrio de atendimento da empresa FastNet.
Pronto! Agora que coletei todos os dados, irei dar prosseguimento na ativao do plano de internet para este cliente. diz Fernanda. Ok Fernanda, entendi at aqui. Quais so os prximos passos? pergunta o consultor. Agora eu vou ligar no ramal do financeiro, e pedir a pessoa que me atender neste nmero para cadastrar os dados do cliente no nosso sistema financeiro. responde Fernanda. Ento daqui em diante, o processo por conta dessa pessoa? No, apenas a parte referente a cobrana. Precisamos cadastrar estes dados no sistema financeiro para que a FastNet possa enviar boletos de cobrana ao cliente. Depois disso, eu ligo para o pessoal da central de rede, e peo pra eles cadastrarem tambm o cliente na central, para que possamos prover canal de internet ao ponto de sua residncia. Estes dois departamentos tm o mesmo acesso que eu aos dados referentes aos pedidos de ativao de planos. Feito isso, eu entro no sistema web para requisio de instalao de ponto no cliente. Temos uma empresa parceira que faz este servio pra gente, mas temos que solicitar a instalao por meio deste sistema web que eles nos oferecem. Deixe-me ver se entendi. Ento, depois de cadastrar todos os dados junto com o cliente, operao esta que demorou quase meia hora, voc liga em trs setores diferentes, que cuidam de vises diferentes do servio, para que eles cadastrem as informaes que lhe interessam. isso? Hum, trs departamentos? Na verdade so quatro. Eu esqueci de um. Tenho que antes de ligar pro departamento financeiro, ligar pro departamento de atendimento ao cliente para que eles registrem os dados do cliente no sistema de gesto deles. Desculpe, eu sempre esqueo deste passo. Fernanda, e o que acontece quando voc ou qualquer uma destas quatro pessoas que esto envolvidas na ativao 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 ningum instalou a internet na casa dele, ou que a fatura no lhe foi enviada, ou que o sinal ainda no existe na sua residncia e iremos providenciar todo este processo novamente. Mas normalmente quando chega neste ponto, o cliente desiste do plano.
8
www.mundojava.com.br
Construindo uma soluo de EAI para a FastNet

Vamos dar incio agora construo da soluo de EAI proposta para a empresa FastNet. Iremos considerar, nesta construo, o servidor JBoss ESB como soluo de EAI escolhido para o projeto. importante que voc esteja familiarizado com o JBoss ESB para criar esta soluo. Se voc no se sente vontade com este servidor, consulte a edio 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 introduo sobre EAI Patterns. Para esta soluo, iremos nos basear no servidor JBoss ESB verso 4.4 GA. Ele pode ser baixado gratuitamente do site da JBoss. Consulte as referncias para mais informaes sobre como baixar o servidor. Depois de ter instalado seu JBoss ESB (se ele ainda no estiver), crie um mdulo ESB na sua ferramenta de desenvolvimento Java preferida, conforme mostrado na figura 2.
Listagem 1. Definio da fila JMS que ser usada para processamento do servio de ativao de ponto. <?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>
O JBoss ESB usa filas JMS para canalizar o processamento das mensagens. Este canal de execuo , na verdade, uma realizao do padro de integrao Point-to-Point Channel. Quando usamos solues baseadas em RPC, temos a certeza que a mensagem enviada, a chamada de mtodo 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 servio no JBoss ESB precisa da sua prpria fila JMS. Consulte nas referncias mais informaes sobre o padro Point-to-Point Channel.
Na soluo proposta, um arquivo XML ser criado pelo programa COBOL da plataforma CICS e ser escrito num diretrio que ser lido continuamente pela nossa soluo de EAI. Neste caso, temos que definir um tipo de endpoint que tenha esta capacidade de escanear diretrios por arquivos de certo tipo para iniciar o processamento da mensagem. A mensagem neste caso o prprio arquivo XML que ser lido do diretrio, e seu contedo ser automaticamente considerado como a mensagem a ser enviada para o servio.
Figura 2. Estrutura do mdulo ESB para ativao de ponto de internet.
Na figura 2 podemos ver a estrutura do nosso projeto de ativao de ponto de internet. Repare que na raiz do mdulo, esto trs pacotes. Crie dentro destes pacotes as classes Java mostradas na figura 2. Ainda na raiz do projeto, existe a pasta META-INF que contm alguns arquivos XML de configurao do mdulo ESB. Crie estes arquivos dentro desta pasta tambm. Na raiz do mdulo, est tambm o arquivo queueservice.xml, responsvel pela definio das filas JMS que sero usadas no mdulo 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.
No JBoss ESB, este tipo de endpoint suportado por meio de provedores do tipo File System. Iremos configurar o endpoint de forma que um determinado diretrio 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 definidos no arquivo de configurao do mdulo ESB. O primeiro, chamado de FileSystemProvider, o tipo de provider que suporta leitura de diretrios. Por meio da tag <fs-provider>, voc pode iniciar a declarao de um provider do tipo File System, que conter a definio 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.
Configurando o endpoint do servio de ativao de ponto

Agora que temos a estrutura de nosso mdulo pronta, podemos dar incio s atividades de implementao do projeto. A primeira coisa que faremos ento definir no arquivo queue-service.xml a nossa fila JMS que ser nosso canal de processamento para as mensagens. Abra ento o arquivo queue-service.xml e edite-o para declarar a fila JMS conforme mostrado na Listagem 1.
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens Na Listagem 4 tambm mostrada a definio de um provedor JMS. Esta definio necessria para acomodar a configurao do mdulo ESB sobre a fila JMS que ser usada para o processamento das mensagens enviadas a um determinado servio. Nosso servio de ativao de ponto de internet estar, portanto, usando o jms-bus chamado de jmsAtivacaoPonto que usa internamente a fila JMS chamada de ativacaoPontoQueue, configurada anteriormente no arquivo queue-service.xml.
Listagem 2. Configurao do mdulo ESB para suporte a endpoints do tipo File System. <?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>
Criando o servio que far o processamento do arquivo XML

Vamos agora configurar em nosso mdulo ESB o servio de ativao de ponto de internet. Para isso, abra novamente o arquivo META-INF/jbossesb.xml, e altere-o acrescentando uma seo de <services> dentro da declarao do mdulo, conforme mostrado na Listagem 4. Lembre-se que o arquivo ter seu contedo modificado para acomodar as novas declaraes, as declaraes feitas na Listagem 4 permanecem.
Listagem 4. Definio parcial do nosso servio de ativao de ponto de internet. <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 3. Descrio das propriedades de configurao dos endpoints File System.
Propriedade directory post-directory post-delete input-suffix work-suffix post-suffix
Descrio Especifica qual ser o diretrio que dever ser lido continuamente pelo ESB Especifica qual ser o diretrio usado para armazenar o arquivo depois do processamento Determina se o arquivo dever ou no ser apagado depois do processamento Especifica que tipo de arquivo ser monitorado pelo ESB no diretrio especificado Especifica qual extenso ser aplicada no arquivo quando ele estiver sendo processado pelo ESB Especifica qual extenso ser aplicada no arquivo depois que ele for processado pelo ESB
Neste artigo, iremos assumir que voc ir configurar os diretrios do exemplo compatveis com seu sistema operacional usado. Na configurao do endpoint do tipo File System, usamos diretrios que so compatveis com o sistema operacional Windows. Caso voc esteja usando Linux ou outro sistema operacional baseado em Unix, lembre-se que o separador de diretrios nativo do sistema ser / e no \. Atente tambm que no Unix no se usa o conceito de drives lgicos, como C:\, e sim, pontos de montagem.
Na Listagem 6, declaramos um servio chamado de AtivacaoPontoESB que ser nosso servio de processamento da ativao do ponto de internet. A este servio, declaramos dois listeners: um para definir que o endpoint de File System ir invocar este servio, notadamente o listener do tipo <fs-listener>, e outro que especifica qual bus JMS ser usado para o processamento das mensagens. Na declarao do ouvinte do tipo File System, repare que alm dos atributos tradicionais, usamos um atributo especial chamado de schedule-frequency. Este atributo especifica de quantos em quantos segundos, o diretrio 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 bsico da soluo usando um arquivo XML de testes. Faa um arquivo Jar do projeto criado, usando algum mecanismo de gerao de arquivos Jars, cujo nome do arquivo gerado seja ativacaoPonto.esb. Este ser nosso mdulo ESB para
10 www.mundojava.com.br
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens testes do mecanismo de leitura de arquivos. Copie o arquivo gerado (ativacaoPonto.esb) para o diretrio de implantao do JBoss ESB (<JBOSSESB_HOME>/server/default/deploy) e, em seguida, inicie seu servidor. Aps ter iniciado seu servidor JBoss ESB, faa 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 diretrio especificado no atributo directory do mdulo ESB. Voc ver que depois de cinco segundos, o JBoss ESB vai identificar o arquivo dentro do diretrio, ir retir-lo de l, mostrar o contedo do arquivo no console do servidor (indicando a execuo da ao org.jboss.soa.esb.actions.SystemPrintln) e depois mover este arquivo para o diretrio especificado no atributo post-directory. Nosso mdulo ESB est ento pronto para que possamos implementar a lgica do processamento da ativao do ponto de internet.
Listagem 5. Arquivo XML de exemplo que ser gerado pelo programa COBOL. <?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>So Francisco</bairro> <cidade>So 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>So 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>
Definindo o arquivo XML que ser enviado pelo programa COBOL

Vamos definir agora um arquivo XML que servir de exemplo para que possamos realizar nossos testes no cenrio da FastNet. Conforme explicado anteriormente, um formato de dados foi negociado entre o consultor de integrao e os analistas COBOL da FastNet, responsveis pelo programa que gera o arquivo. Normalmente, essa uma etapa que antecede a criao de uma soluo de EAI, pois quem gera os arquivos quem define o formato do mesmo, baseado em algumas restries da sua plataforma de desenvolvimento de software, ou restries sobre conhecimento daquele formato de arquivo. importante que seja negociado um formato de ampla aceitao, para que voc no tenha problemas de aquisies de conectores especiais para trabalhar com determinado formato de arquivo ou interface de sistema. Assim que for possvel, prefira trabalhar com arquivos XML, pois este um formato universal para transferncia de dados, que acomoda os dados que sero entregues soluo de EAI, bem como os metadados que definem informaes sobre os dados. Abra o arquivo Resources/pa_123456789.xml e edite-o conforme mostrado na Listagem 5. Este o formato que foi negociado com os analistas COBOL da FastNet. O nome do arquivo sugere um pedido de ativao (PA) do cliente cujo identificador nico 123456789.
Criando o fluxo de processamento do servio

A partir do recebimento do arquivo XML por parte do JBoss ESB, o restante do processamento se d por conta da criao do fluxo de processamento da mensagem. No JBoss ESB, todo fluxo de processamento representado por um conjunto de aes que so configuradas seqencialmente, para um dado servio. Estas aes representam os filtros de processamento de um determinado duto de execuo. Quando uma mensagem recebida por um servio, o conjunto de aes que configurado para aquele servio 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 servio.
Em qualquer soluo de integrao, uma das prticas mais comuns encontradas durante a criao da soluo particionar o processamento da mensagem em estgios diferentes dentro de um canal de processamento. A esta prtica damos o nome da Pipes and Filters. Em verdade, no se trata apenas de uma prtica, trata-se de um dos padres catalogados no EAI Patterns, s que relativo ao assunto sistemas de mensageria. Todos os padres de desenho relacionados a mensagens, seja sobre roteamento, transformao ou criao, so fundamentados na soluo Pipes and Filters. Consulte as referncias do artigo para mais informaes.
11
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens Desta forma, a primeira coisa a se fazer desenhar como ser o fluxo de processamento da mensagem para posterior implementao na soluo de EAI. Quais sero as etapas a serem executadas? Como a mensagem ser entregue aos sistemas? Todo servio possui uma estratgia de processamento na forma de fluxo. Na figura 3, temos a definio do fluxo de processamento do processo de ativao de ponto de internet. transformao do documento XML enviado para o servio em objetos Java. Para comear, voc dever configurar a lgica de transformao num arquivo especial de configurao do Smooks. Abra o arquivo META-INF/ativacaoPonto-smooks.xml e edite-o conforme mostrado na Listagem 6. Vamos entender como funciona a transformao de mensagens via Smooks. No arquivo apresentado na Listagem 6, temos vrias entradas do tipo <resource-config>. Estas entradas indicam os mecanismos de transformao que sero aplicados numa mensagem. A primeira entrada, chamada de dataDecoder, a configurao padro sobre como ler dados referentes a datas. A tag <resource> indica qual implementao ser usada para realizar a transformao, e dentro da seo <resource-config>, voc pode declarar zero ou mais elementos do tipo <param>, que sero parmetros enviados para a classe indicada na tag <resource>. A API do Smooks lhe possibilita estender os transfor-
Transforma XML para Java
Adequar Mensagem para Entrega
Inserir Centro de Custo na Mensagem
Cadastra Cliente no Siebel
Registrar Fatura no SAP
Registrar Ponto na Central
Requisitar Instalao de Ponto no Cliente
Figura 3. Fluxo de processamento da mensagem enviada para o servio.
Aplicando o padro Message Translator para transformao de XML para Java

Conforme mostrado na figura 3, a primeira ao a ser executada quando uma mensagem for enviada para o servio de ativao de ponto ser de transformar a mensagem enviada do formato XML para o formato Java. Isso se faz necessrio para que possamos, dentro do ESB, manipular os dados mais facilmente usando a linguagem Java. Neste caso, iremos aplicar nesta etapa do fluxo, o padro de integrao Message Translator, padro responsvel por troca de formatos em ambientes de integrao. O padro Message Translator o pai de todos os padres de transformao 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 conceito de filtro do padro Pipes and Filters, ou seja, ele realizado como um estgio de processamento particular na cadeia, com foco particular em converso ou adaptao de formatos. Consulte nas referncias mais informaes sobre este padro. Para facilitar as coisas para os arquitetos de integrao, o JBoss ESB acompanha um mecanismo muito poderoso de transformao de mensagens. Por meio de uma ao previamente implementada dentro do JBoss ESB, voc pode realizar vrios tipos de transformaes complexas na mensagem enviada para um servio, usando apenas configurao de arquivos, ao invs de implementao de cdigo. Este mecanismo chamado de Smooks, pois baseado no framework Smooks. Veja nas referncias mais informaes sobre este framework. Por meio do mecanismo de Smooks, voc pode fazer vrias transformaes 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
Listagem 6. Configurao da lgica de transformao da mensagem de XML para Java. <?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/enderecoresidencial> <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=
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>
madores padres que ele oferece, assim como criar os seus prprios transformadores. Depois da declarao do transformador de datas no incio do arquivo de configurao, temos vrias declaraes 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 informaes de um documento XML. Repare ento que, depois da declarao do transformador de datas, temos a declarao do transformador das informaes do cliente. Na entrada do <resource-config>, indicamos que a classe que ser instanciada ser a br.com.mundojava.eaipatterns.pojo.Cliente. Demos tambm um apelido para esta transformao, chamando-a de cliente. Por meio deste apelido, a instncia deste bean poder ser recuperada dentro do corpo da mensagem. Repare que no caso da transformao dos dados do cliente, existe uma propriedade especial configurada chamada de <bindings>. nesta propriedade que informamos a lgica de quais propriedades do bean sero 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 notao usada no atributo selector indica uma navegao no documento XML. Lembre-se que um documento XML possui a representao de uma rvore de ns. Portanto, ao mencionar uma informao do documento, voc dever indicar onde aquela informao se situa, tomando como referncia o n raiz do documento. No caso do arquivo XML enviado pelo programa COBOL, o n raiz ser o <pedido-ativacao>. Salve as alteraes feitas no arquivo META-INF/ativacaoPonto-smooks. xml. Para que este mecanismo funcione, voc dever declarar uma ao do Smooks dentro da cadeia de aes do servio de ativao de ponto. Para isso, abra novamente o arquivo META-INF/jboss-esb.xml e altere a declarao das aes do servio conforme mostrado na Listagem 7.
Listagem 7. Declarando a transformao via Smooks no servio de ativao de ponto. <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>
13
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens Agora que nosso mecanismo de transformao de mensagens est apropriadamente configurando, temos que implementar as classes java que sero instanciadas pelo engine do Smooks. Implemente as classes mecionadas no arquivo de configurao do mecanismo Smooks (em especial, todas as classes do pacote br.com.mundojava.eaipatterns.pojo) conforme mostrado na Listagem 8. No esquea de implementar em cada uma das classes os mtodos get() e set() (omitidos nas listagens) para compor as propriedades dos objetos Java.
Listagem 8. Implementao das classes Java usadas durante a transformao da mensagem. import java.io.Serializable; import java.util.Date; @SuppressWarnings(serial) public class Cliente implements Serializable { private long identificador; private String nome; private String rg; private String cpf; private Date dataNasc; } ////////////////////////////////////////// package br.com.mundojava.eaipatterns.pojo; import java.io.Serializable; import java.util.Date; @SuppressWarnings(serial) public class DetalhesInstalacao implements Serializable { private String tipoComputador; private String sistemaOperacional; private String responsavel; private Date dataInstalacao; } ////////////////////////////////////////// package br.com.mundojava.eaipatterns.pojo; import java.io.Serializable; @SuppressWarnings(serial) public class DetalhesPlano implements Serializable { private String tipoPlano; private boolean suporteTecnico; } ////////////////////////////////////////// package br.com.mundojava.eaipatterns.pojo; import java.io.Serializable; @SuppressWarnings(serial) public class Endereco implements Serializable { private String logradouro; private int numero; private String complemento; private String cep; private String bairro; private String cidade; private String uf; } } ////////////////////////////////////////// package br.com.mundojava.eaipatterns.types; import java.io.Serializable; import br.com.mundojava.eaipatterns.pojo.DetalhesInstalacao; import br.com.mundojava.eaipatterns.pojo.Endereco; @SuppressWarnings(serial) public class PedidoInstalacaoPontoNoCliente implements Serializable { private long identificador; private Endereco enderecoResidencial; private DetalhesInstalacao detalhesInstalacao; private String centroCusto; } ////////////////////////////////////////// package br.com.mundojava.eaipatterns.types; import java.io.Serializable; import br.com.mundojava.eaipatterns.pojo.DetalhesPlano; import br.com.mundojava.eaipatterns.pojo.Endereco; @SuppressWarnings(serial) public class PedidoRegistroFaturaNoSAP implements Serializable { private long identificador; private DetalhesPlano detalhesPlano; private Endereco enderecoCobranca; } //////////////////////////////////////////
Aplicando o padro Message Translator para alterao do formato da mensagem

Aps transformar os dados do arquivo XML para objetos Java, hora de transformar novamente o formato da mensagem, agora para o formato esperado pelos servios que efetuaro 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 servio que representa um sistema legado possui uma estrutura de dados que acomoda as informaes de interesse do sistema legado. Essas estruturas de dados esto implementadas na forma de tipos complexos, como mostrados na Listagem 9. Implemente estes tipos de dados antes de passarmos para a implementao da converso do formato. Lembre-se de implementar os mtodos get() e set() (omitidos na listagem) para cada atributo declarado nas classes.
Listagem 9. Implementao dos tipos complexos que representam os dados esperados pelos sistemas legados. package br.com.mundojava.eaipatterns.types; import java.io.Serializable; import br.com.mundojava.eaipatterns.pojo.Cliente; import br.com.mundojava.eaipatterns.pojo.Endereco; @SuppressWarnings(serial) public class PedidoCadastroClienteNoSiebel implements Serializable { private long identificador; private Cliente dadosCliente; private Endereco enderecoResidencial;
package br.com.mundojava.eaipatterns.types; import java.io.Serializable; import br.com.mundojava.eaipatterns.pojo.DetalhesPlano; import br.com.mundojava.eaipatterns.pojo.Endereco; @SuppressWarnings(serial) public class PedidoRegistroPontoNaCentral implements Serializable { private long identificador; private Endereco enderecoResidencial; private DetalhesPlano detalhesPlano; }
} @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 instalao 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; } }
Para facilitar os testes da soluo no final do exemplo, implemente para cada tipo complexo da soluo o mtodo toString(), para que o console do JBoss ESB possa mostrar os dados de uma forma mais clara. Se voc no fizer isso, o console mostrar apenas uma cadeia de caracteres que representa a referncia do objeto do tipo complexo, tornando mais difcil saber se o exemplo realmente funcionou.
As classes implementadas na Listagem 9 representam os tipos complexos esperados por cada sistema que ser enlaado pela estratgia de integrao. Uma vez que os dados enviados no arquivo XML foram transformados para objetos Java, precisamos agora transformar o formato dos dados mais uma vez, agora para organizar os dados nas estruturas esperadas pelos sistemas. Vamos ento aplicar novamente o padro Message Translator no nosso fluxo de processamento do servio de ativao de ponto. Implemente a classe br.com.mundojava.eaipatterns. impl.MessageTranslator conforme mostrado na Listagem 10.
Listagem 10. Nova transformao da mensagem, agora decompondo os dados nos tipos complexos. 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;
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 transformao da mensagem faa parte do fluxo de processamento, precisamos declar-la dentro da lista de aes a serem executadas do servio de ativao de ponto. Abra nova15
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens mente o arquivo META-INF/jboss-esb.xml e edite-o conforme mostrado na Listagem 11.
Listagem 11. Configurao da transformao da mensagem de POJO para tipos complexos. <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>
Listagem 12. Insero do centro de custo na mensagem por meio do padro Content Enricher. package br.com.mundojava.eaipatterns.impl; import java.util.Map; import org.jboss.soa.esb.actions.AbstractActionPipelineProcessor; import org.jboss.soa.esb.actions.ActionProcessingException; import org.jboss.soa.esb.helpers.ConfigTree; import org.jboss.soa.esb.message.Message; import br.com.mundojava.eaipatterns.types.PedidoInstalacaoPontoNoCliente; public class ContentEnricher extends AbstractActionPipelineProcessor { private ConfigTree configTree; public ContentEnricher(ConfigTree configTree) { this.configTree = configTree; } @SuppressWarnings(unchecked) public Message process(Message message) throws ActionProcessingException { String centroCusto = null; Map<String, Object> messageData = null; PedidoInstalacaoPontoNoCliente pedInstPtCliente = null; try { centroCusto = (String) configTree.getAttribute(centroCusto); messageData = (Map<String, Object>) message.getBody().get(); pedInstPtCliente = (PedidoInstalacaoPontoNoCliente) messageData.get(pedidoInstalacaoPontoNoCliente); pedInstPtCliente.setCentroCusto(centroCusto); } catch (Exception ex) { throw new ActionProcessingException(ex); } return message; } }
Uma boa prtica de integrao recomendada em cenrios de transformao de mensagens por meio do Message Translator, criar uma cadeia de transformao em estgios. De fato, o padro Pipes and Filters estimula a quebra do processamento de uma mensagem em estgios diversos, mas esta quebra pode reunir filtros correlatos, por exemplo, filtros voltados somente transformao de mensagens. A esta prtica, damos o nome de Chainning Transformations, conforme explicado no livro Enterprise Integration Patterns (Gregor Hohpe e Bobby Wolf) pgina 89. Consulte nas referncias informaes sobre o livro.
Aplicando o padro Content Enricher para insero do Centro de Custo

O sistema que receber a solicitao de instalao de ponto no cliente espera com parte dos dados o centro de custo que ser usado para efetuar a cobrana entre a empresa e a FastNet. Este dado no enviado no arquivo XML que gerado pelo programa COBOL e deve ser inserido na mensagem separadamente. Para resolver este problema, iremos aplicar o padro Content Enricher no fluxo de processamento da mensagem. Implemente a classe br.com.mundojava.eaipatterns.impl.ContentEnricher conforme mostrado na Listagem 12. O padro Content Enricher usado quando temos que entregar uma mensagem a um determinado sistema para processamento, mas a mensagem no apresenta todos os dados que o sistema requer para execuo da mesma. Neste caso, criamos um filtro na cadeia de processamento que insere um valor adicional na mensagem para efeitos de adaptao. Este valor inserido pode ser recuperado de qualquer fonte de dados externa, como um banco de dados, um servio web ou at mesmo outro sistema de mensageria. Consulte nas referncias mais informaes sobre este padro. 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 ao ir recuperar de sua lista de propriedades o valor do centro de custo e atualizar o objeto da mensagem. Esta
nova ao dever ser configurada no arquivo de configurao do mdulo ESB, portanto, abra o arquivo META-INF/jboss-esb.xml e edite-o conforme mostrado na Listagem 13.
Listagem 13. Configurao da ao que insere o centro de custo na mensagem para processamento. <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>
Aplicando o padro Splitter para realizar o roteamento dos tipos complexos

Agora que temos a mensagem com todas as informaes necessrias para entrega e no formato adequado, podemos finalmente realizar o processo de entrega dos dados para os sistemas legados que aguardam pelo processamento. No estgio atual do processamento da mensagem, temos uma instncia do tipo java.util.Map dentro da mensagem que contm 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 servio particular que faa o processamento deste no sistema legado. A este processo de separao dos dados e entrega no correto servio para processamento, iremos aplicar o padro de integrao Splitter. Esse padro usado quando queremos quebrar a mensagem do canal de processamento em partes diferentes, para que cada parte possa ser processada separadamente. Na verdade, cada parte transformada em uma mensagem independente, e esta mensagem enviada a um destinatrio (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 informaes dos servios que sero invocados pelo nosso Splitter.
Listagem 14. Implementao do padro Splitter, responsvel por separar a mensagem e entregar aos interessados. package br.com.mundojava.eaipatterns.impl; import java.util.Collections; import java.util.HashMap; import java.util.Map; import org.jboss.soa.esb.actions.AbstractActionPipelineProcessor; import org.jboss.soa.esb.actions.ActionProcessingException; import org.jboss.soa.esb.client.ServiceInvoker; import org.jboss.soa.esb.helpers.ConfigTree; import org.jboss.soa.esb.message.Message; import org.jboss.soa.esb.message.format.MessageFactory; import org.jboss.soa.esb.message.format.MessageType; import br.com.mundojava.eaipatterns.types.PedidoCadastroClienteNoSiebel; import br.com.mundojava.eaipatterns.types.PedidoInstalacaoPontoNoCliente; import br.com.mundojava.eaipatterns.types.PedidoRegistroFaturaNoSAP; import br.com.mundojava.eaipatterns.types.PedidoRegistroPontoNaCentral; public class Splitter extends AbstractActionPipelineProcessor { @SuppressWarnings(unchecked) private Map<Class, ServiceInfo> services; @SuppressWarnings(unchecked) public Splitter(ConfigTree configTree) { services = Collections.synchronizedMap(new HashMap<Class, ServiceInfo>()); // Registra os dados do servio 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 servio 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 servio 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 servio de Instalao 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 instalao 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; } } }
17
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens Para executar a entrega das mensagens para os respectivos servios dos legados, foi criada a ao de splitter mostrado na Listagem 14. Em sua implementao, foi criada uma classe interna chamada de ServiceInfo para guardar as informaes dos servios de cada sistema legado. Durante a inicializao da classe, ou seja, na execuo do construtor da mesma, foi criado um mecanismo de registro dos servios a serem invocados, em particular, os servios de cadastro de cliente no Siebel, o servio de registro de fatura no SAP, o servio de registro de ponto na central e o servio de requisio de instalao de ponto no cliente. Para cada um desses servios, uma instncia da classe ServiceInfo foi criada para armazenar as informaes de categoria e nome do servio a ser invocado. Todas as instncias da classe ServiceInfo, depois de populadas com os dados recuperados do objeto ConfigTree (que representa as propriedades que so configuradas no arquivo jboss-esb.xml para aquela ao), as instncias foram armazenadas num objeto do tipo java. util.Map, para futura recuperao e consulta, por meio da referncia da classe de cada tipo complexo. Na execuo da ao, notadamente durante a execuo do mtodo process() da classe da ao, feita a recuperao de cada tipo complexo que ser enviado para os servios, bem como a montagem de uma mensagem 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 solicitao de envio de mensagem para o servio respectivo daquele tipo complexo. Usando uma instncia da classe org.jboss.soa.esb.client.ServiceInvoker, enviada uma mensagem particular contendo somente o tipo complexo de cada servio do legado. Para finalizar a implementao do nosso fluxo de integrao para o servio de ativao de ponto de internet, temos que configurar a classe br.com.mundojava.eaipatterns.impl.Splitter dentro do nosso arquivo jboss-esb.xml. Abra ento este arquivo e edite-o conforme mostrado na Listagem 15. Repare na Listagem 15 que vrias propriedades so declaradas no corpo da ao. Essas propriedades declaradas determinam as informaes de todos os servios que sero invocados a partir da classe br.com.mundojava.eaipatterns.impl.Splitter durante o processamento do mtodo process(). Em particular, foram definidas as informaes de categoria dos servios, e os nomes dos servios. Essas informaes so recuperadas pela classe no momento da execuo do construtor, conforme mostrado na Listagem 16.
Listagem 15. Configurao da ao de Splitter dentro da cadeia de aes do servio. <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>
Configurando os servios dos legados e testando a soluo de EAI

Agora que temos definido, implementado e configurado todo o fluxo de processamento da mensagem para o servio de ativao de ponto de internet, podemos dar incio aos testes de execuo. Mas, antes, temos que realizar a configurao dos servios que sero usados no exemplo para simular o recebimento das mensagens enviadas pelo padro Splitter. Repare na Listagem 15 que nas propriedades da ao Splitter foram mencionados vrios servios. Esses servios, durante a execuo do Splitter, sero invocados em seqncia. Caso eles no estejam configurandos em seu mdulo ESB (ou em geral, no JBoss ESB em si por meio de outros mdulos) algumas mensagens de aviso iro aparecer no console do JBoss ESB sobre a no-entrega das mensagens.
No iremos, neste artigo, realizar a implementao de todos os servios que representam os sistemas legados, a fim de manter o foco original sobre os padres de transformao. 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 aes personalizadas que por meio da mensagem enviada cria os dados a serem enviados para uma aplicao atravs de alguma tecnologia de acesso a dados. O JBoss ESB oferece vrias aes pr-configuradas para acesso a sistemas legados nos mais diversos estilos de integrao. Por exemplo, caso voc deseje acessar um EJB para realizar uma operao, 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 interesse 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. Atravs 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 mecanismo de Message Inflow, usando gateways do tipo JCA.
SOA na Prtica Aplicando EAI Patterns sobre Transformao de Mensagens Neste caso, faa a configurao destes servios dentro do arquivo METAINF/jboss-esb.xml. A Listagem 16 mostra um exemplo de configurao para o servio de cadastro de clientes no Siebel. Faa a configurao dos demais servios seguindo o padro de configurao mostrado na Listagem 16, e atente que cada servio dever ter o nome da categoria e do servio baseado nos nomes mostrados nas propriedades da ao Splitter.
Listagem 16. Exemplo de configurao de servio para o cadastro de clientes no Siebel. <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>
complexos que lhe interessa, indicando que houve um processamento de separao da mensagem por interesse (padro Splitter) e que houve os estgios de processamento de transformao 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 (padro Content Enricher) para entrar em conformidade com o sistema legado de requisio de instalao de ponto.
Consideraes finais
Neste artigo, discorremos um cenrio de negcio de uma empresa fictcia de servios de internet, que apresentou um problema tpico de integrao entre sistemas. Por meio de prticas de projetos de EAI, e o uso do servidor JBoss ESB, criamos um projeto passo a passo que se utiliza de padres de integrao voltados a transformao de mensagens. Vimos tambm como configurar endpoints do tipo File System dentro do JBoss ESB, bem como usar os recursos do servidor para realizar o processamento de mensagens com nfase em transformao de formatos
Atente que ao configurar os servios dos legados, voc dever realizar a configurao do <jms-bus> de cada servio no arquivo jboss-esb.xml, assim como a configurao das filas JMS que sero usadas dentro do arquivo queueservice.xml. Cada servio dever possuir sua prpria fila JMS para processamento da mensagem, comportamento necessrio para garantir os canais de processamento de cada servio. Isso feito por meio da configurao dos elementos <jms-listener> dentro de cada servio, e os elementos <jms-bus> na seo de providers, no incio do arquivo jboss-esb.xml. As filas JMS so declaradas na forma de MBeans no arquivo queue-service.xml, e cada fila dever ter um nome exclusivo dentro do JBoss ESB. Depois de configurar todos os servios do exemplo, gere uma nova verso do mdulo ESB (arquivo ativacaoPonto.esb) usando uma ferramenta de gerao de arquivos Jars de sua preferncia, como feito anteriormente no primeiro teste do mdulo. Copie o arquivo criado (ativacaoPonto.esb) para o diretrio <JBOSSESB_HOME>/server/default/deploy e espere at que o JBoss ESB reconhea a nova verso do mdulo e faa a atualizao do mesmo em tempo de execuo. Assim que o JBoss ESB terminar a atualizao, copie o arquivo Resources/pa_123456789.xml para o diretrio de leitura, definido no arquivo jboss-esb.xml na seo 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 servio do legado recebeu seu tipo complexo esperado. O comportamento esperado neste teste que os servios que representam os sistemas legados recebam mensagens contendo apenas os tipos
Referncias EAI Patterns, Point-to-Point Channel Pattern: http://www.eaipatterns.com/PointToPointChannel.html EAI Patterns, Pipes and Filters Pattern: http://www.eaipatterns.com/PipesAndFilters. html EAI Patterns, Message Translator Pattern: http://www.eaipatterns.com/MessageTranslator.html EAI Patterns, Content Enricher Pattern: http://www.eaipatterns.com/DataEnricher. html EAI Patterns, Splitter Pattern: http://www.eaipatterns.com/Sequencer.html Livro Enterprise Integration Patterns: http://www.amazon.com/exec/obidos/tg/ detail/-/0321200683 Download do servidor JBoss ESB: 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 Framework CodeHaus Smooks: http://milyn.codehaus.org/Smooks
19
Windows Communication Foundation Architecture Overview

http://msdn.microsoft.com/en-us/library/aa480210.aspx
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).

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.

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 oneway or request/reply. Each OperationDescription also describes the messages that make up the operation using a collection of MessageDescriptions.
3

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.

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.

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
6

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

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

//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:

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

sdII - Franca

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

sdII - Franca

Загружено:

Авторское право:

Доступные форматы

FACULDADE DE INFORMTICA LEMOS DE CASTRO

Nome da Disciplina (CD) COMPUTAO DISTRIBUDA

Carga Horria 120

Notas de Aula v4 Janeiro de 2012

Professor M. Frana professor@franca.pro.br http://www.franca.pro.br/prof

Esta pgina foi deixada propositadamente em branco.

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 2

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 3

Esta pgina foi deixada propositadamente em branco.

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 4

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 7

Esta pgina foi deixada propositadamente em branco.

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 8

Aula 1 Aspectos Estratgicos da Computao Distribuda

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 10

Padres para Aplicaes

EAI Enterprise Application Integration ou Integrao de Aplicaes Corporativas

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 12

A demanda por arquitetos est aumentando. Mais detalhes em http://www.slideshare.net/msavio/slideshows

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 14

desenvolvedores. Em vez disso

suporte de Sistemas de Middleware: localizados entre

Services/SOA. Denominaes Equivalentes: Modelos de Integrao de Objetos, Plataformas de Distribuio de Objetos.

Stubs vs. Skeletons

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 17

Queue VS. Topic

Method Invocation (RMI).

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 20

Aula 3 Objetos Distribudos (Java IDL) [ESTUDO DIRIGIDO]

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 21

interface Hello { string sayHello(); }

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 23

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

// Invoke remote service String hi = helloRef.sayHello(); System.out.println(hi); } catch(Exception e) { System.out.println(e); e.printStackTrace(System.out); } } }

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 24

public class HelloServer {

// Instantiate the servant object HelloServant helloRef = new HelloServant();

// Connect servant to the ORB orb.connect(helloRef);

class HelloServant extends _HelloImplBase {

public String sayHello() { return "\nHelloWorld!\n"; } }

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 25

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 26

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 28

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 29

Esta pgina foi deixada propositadamente em branco.

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 30

Aula 4 Balanceamento de Carga

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 34

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 35

Esta pgina foi deixada propositadamente em branco.

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 36

Aula 5 Algoritmos Distribudos

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 37

Atualmente, o termo cobre

algoritmos que so executados em redes locais e em

multiprocessadores de memria compartilhada.

Caractersticas dos Sistemas Distribudos

Recursos independentes (acostamento).

FILC 2012.1 - Notas de Aula de Computao Distribuda Prof. M. Frana Pgina: 38