Tecnologias de Middleware Rumo à Autoconfiguração e Reflexão

Tamanho: px
Começar a partir da página:

Download "Tecnologias de Middleware Rumo à Autoconfiguração e Reflexão"

Transcrição

1 Tecnologias de Middleware Rumo à Autoconfiguração e Reflexão MÁRCIO HENRIQUE DA COSTA PAIVA MARCOS ROBERTO MARCONDES EsAEx Escola de Administração do Exército, Rua Território do Amapá, 455, Pituba, Salvador-BA, Brasil Resumo. Este artigo de revisão estuda, através de método comparativo, o estado da arte das plataformas de middleware de objetos distribuídos disponíveis no mercado, cita os requisitos necessários as suas futuras gerações e propõe sua reestruturação baseada em: componentes reflexivos, autoconfiguração, reconfiguração dinâmica e uma arquitetura de aplicativo multicamada (que enfatiza a importância da camada de aplicação do modelo de referência RM-OSI), com o objetivo de contribuir com o avanço da tecnologia em epígrafe e com o esforço de padronização a ser realizado pela comunidade científica afim. O histórico tecnológico de cada plataforma de middleware, seu relacionamento com a tecnologia computacional disponível, suas principais características e, ainda, as atuais arquiteturas de aplicativo são brevemente comentadas. Palavras-chaves: Middleware, CBD, Web Services, CORBA3, J2EE,.NET. Abstract. This review article studies, through a comparative method, the state of the art of middleware platforms of distributed objects available in the market, cites necessary requisites for future genarations, and proposes its restructuring bases on: reflexive components, auto-setup, dynamic resetup and a multilayer program architecture (which emphasizes how important RM-OSI reference model program layer is), aiming at the contribution to the aforementioned technology advance as well as to patterning efforts to be made by the scientific community in question. Techonological history of each middleware platform, their relation to available IT technology, their principal characteristics and, yet, current program architecture are briefly commented on. Key-word: Middleware, CBD, Web Services, CORBA3, J2EE,.NET. 1. Introdução Os recentes avanços obtidos na infra-estrutura de redes distribuídas de comunicação têm permitido um avanço significativo dos ambientes computacionais, que passam a fazer uso eficiente das capacidades de processamento distribuído, provendo à camada de aplicação uma melhor transparência quanto ao seu ambiente de processamento, o que permite o surgimento de novas formas de se estruturar aplicações. Deixa-se para traz a arquitetura de duas camadas surgida com o advento do computador pessoal (PC) e dos Sistemas Gerenciadores de Banco de Dados (SGBD) que, a seu tempo, possibilitaram uma solução mais atrativa para a execução de regras de negócio e a padronização dos sistemas de armazenamento de dados. Hoje sabe-se que ao se pensar em arquiteturas de aplicação, deve-se considerar que qualquer aplicativo pode ser decomposto em, no mínimo, três camadas distintas, são elas: a interface com o usuário, as regras de negócio e a persistência das informações. Sendo assim, uma vez dividida a aplicação em camadas físicas, faz-se necessário uma tecnologia que torne fácil a comunicação intra-aplicação através da rede. Essa tecnologia é chamada de middleware de objetos distribuídos, tendo sido disponibilizada no mercado, inicialmente, através das siglas CORBA, RMI, DCOM e outras. Atualmente, ao observar-se o rumo das grandes especificações existentes no mercado, constata-se a consagração do desenvolvimento de softwares baseados em componentes (CBD Component Based Development), passando cada uma dessas especificações a adotar um modelo próprio de componentes, como o CORBA Component Model da OMG, o J2EE da Sun Microsystems e o.net da Microsoft Corporation (BOLONHA, 2002). No momento em que a internet começa a se tornar um meio de comunicação entre dispositivos, momento esse já anunciado por pesquisadores como ponto de mudança do uso da internet (FREIRE, 2002), e no meio da guerra de mercado travada principalmente pela SUN e Microsoft, surge a arquitetura Web Service para integrar os serviços propostos pelas duas tecnologias. Neste contexto introduz-se o estudo das plataformas de middleware de objetos distribuídos existentes, discorrendo-se brevemente sobre seus caminhos evolucionários e suas principais características, concluindo-se com a escolha de uma

2 das plataformas estudadas segundo critérios adotados pelo Modelo de Referência para Processamento Distribuído Aberto da ISO/IEC/ITU-T (RM-ODP) que normaliza a terminologia e o contexto para sistemas distribuídos em ambientes abertos. Na última parte do artigo enumera-se os requisitos necessários às futuras gerações de plataformas de middleware, propõem-se uma reestruturação baseada em componentes reflexivos e sugeri-se sua adoção sobre uma arquitetura de aplicativo multicamada que enfatiza as funcionalidades a serem providas pela camada de aplicação do modelo de referência RM- OSI, esperando-se, dessa forma, contribuir com o esforço de padronização dessa nova tecnologia de middleware que a partir de então, se tornará a base da revolução da internet e receberá a adesão em massa das organizações que necessitem de aplicações distribuídas. 2. Middleware: Conceitos Básicos Middleware é uma porção de software que situa-se entre as aplicações e seus sistemas operacionais adjacentes, fornecendo uma Interface de Programação de Aplicação (API) uniforme, conforme mostra a figura 1. Similarmente à definição de Sistema Operacional como O software que torna o hardware utilizável, podemos considerar o middleware como O software que torna um sistema distribuído programável (BAKKEN, 2001). Procedure Call) para conexão síncrona e assíncrona entre cliente e servidor; - De objetos distribuídos, que leva a tecnologia orientada a objetos para o ambiente distribuído na forma de ORBs (Object Request Brokers); - De RPCs, que fazem acesso a uma grande variedade de recursos de dados para utilização por um único aplicativo; - De monitores transacionais (TP), que permitem o uso de uma única API para a elaboração de aplicativos distribuídos. - De proprietários, que como o próprio nome diz, opera com a ferramenta ou um ambiente específico. Neste artigo estuda-se o Middleware de Objetos Distribuídos para o suporte à comunicação distribuída, que permite o aproveitamento dos benefícios do ambiente distribuído através do tratamento transparente, ao desenvolvedor, dos problemas advindos da distribuição das aplicações. Tal aproveitamento se dá através da possibilidade de particionamento dos componentes funcionais de uma aplicação (específicos de cada aplicação), de sua execução em paralelo através dos vários nós de computação e do gerenciamento da comunicação entre esses componentes, em nível de aplicação. Tratando-se questões como: heterogeneidade de hardware, sistemas operacionais e linguagens de programação; independência de falhas; concorrência e segurança. O que deixa o desenvolvedor livre para preocupar-se apenas com o desenvolvimento das rotinas funcionais da aplicação, ou seja, dos aspectos que fazem parte da lógica específica da aplicação. 2.1 Processamento Distribuído Aberto No processamento distribuído aberto os recursos computacionais encontram-se dispostos em localizações geográficas distintas, de forma transparente aos usuários. Estes enxergam aqueles recursos como um único sistema, no qual questões como heterogeneidade, interoperabilidade, disponibilidade, performance, concorrência e segurança surgem como limitantes às aplicações que utilizam este tipo de ambiente. Figura 1: O Contexto da camada de middleware (BAKKEN, 2001) Existem seis categorias de middleware: - De bases de dados, que ligam o servidor e o cliente em ambientes de bancos de dados específicos; - De mensagens (messaging), que se baseiam no procedimento RPC (Remote 2.2 Modelo de Referência ISO RM-ODP É um modelo de padronização da ISO, que objetiva uniformizar o desenvolvimento de arquiteturas de sistemas distribuídos abertos. Adota uma visão integrada e introduz um sistema orientado a objetos ao processo de desenvolvimento de sistemas distribuídos abertos Dentre os conceitos arquiteturais e terminologias do modelo RM-ODP estão os seguintes (SBRC, 2002): - Ponto de Vista: é uma projeção sobre o sistema como um todo, a qual considera apenas os apectos relevantes para um

3 determinado público de interesse, abstraindo-se outros aspectos que não contribuam para o entendimento da projeção. Cada ponto de vista introduz uma linguagem específica, a qual define os conceitos e regras a serem utilizados na modelagem e especificação do sistema ODP. - Transparência de Distribuição: representam o modelo de abstração fundamental em RM-ODP, permitindo que desenvolvedores de sistemas ODP se concentrem apenas nos aspectos relevantes (funcionais), sendo os demais aspectos mantidos de forma invisível. - Funções ODP: são funções comuns divididas em quatro grupos (gerenciamento, coordenação, repositório e segurança), que implementam a infraestrutura básica e as transparências especificadas e que, em geral, são realizadas através de objetos ou grupos de objetos. 2.3 Novas Arquiteturas de Aplicativo As atuais arquiteturas de aplicativo são disponibilizadas em várias camadas, incentivando a separação lógica dos seguintes elementos: - Camada do cliente, suporta os requisitos de acesso aos dados do usuário final. - Camada do aplicativo, lugar onde a lógica de negócio é implementada e o acesso aos dados é coordenado. - Camada de banco de dados, lugar onde os dados são armazenados e consultados, podendo conter links com outras fontes de dados e aplicativos externos, os quais podem ser membros da arquitetura geral (DORSEY, 2001). 2.4 Objetos Distribuídos É a utilização dos conceitos de Orientação a Objetos (OO) em ambientes distribuídos. Sobre a ótica da orientação a objetos, os objetos são ocorrências de alguma coisa estruturada a partir do espaço do problema ou do espaço da solução, que possuem identidade, estado, comportamento e que se comunicam através da troca de mensagens (BOOCH, 2000). A este conceito acrecenta-se o fato de, em ambientes distribuídos, a troca de mensagens ser realizada entre máquinas com localização geográfica distintas, necessitando-se assim de uma camada que vá mascarar as dificuldades destes ambientes. 2.4 Web Services São serviços fornecidos por aplicações Web a outras aplicações Web, que podem ser criados por qualquer linguagem de programação e executados em qualquer servidor Web que rode sob qualquer sistema operacional ou plataforma de hardware. Enquanto os objetos distribuídos são orientados a objetos, comportando-se como duas pessoas conversando, os Web services são orientados a documentos, comportando-se como duas pessoas trocando documentos em papel (MOLINARI, 2002). Trata-se do conceito de arquiteturas de aplicações distribuídas estendido à Internet, no qual métodos remotos podem ser invocados a partir de um cliente qualquer, utilizando mensagens SOAP e o protocolo HTTP (GUITIERREZ, 2002). O protocolo SOAP (Simple Object Access Protocol) permite acesso a métodos de um objeto remoto, usando o XML para representar as informações e o HTTP ou HTTPS como meio de transporte de conteúdo entre clientes e servidores (MOLINARI, 2002). O principal objetivo dos Web services é facilitar o acesso a informações dentro de um determinado sistema (URRESTI, 2002), aproveitando-se todo o código legado e transformando-o em uma funcionalidade pronta para ser utilizada por um outro programa escrito em qualquer lingagem (FREIRE, 2002). 3. Padrões Atuais de Middleware Nesta seção faz-se um resumo dos atuais padrões de middleware existentes no mercado e um breve histórico da evolução tecnológica de cada plataforma. 3.1 CORBA CORBA - Common Obhect Reques Broker Architeture é o resultado do esforço de padronização de tecnologias para objetos distribuídos feito por um conjunto de desenvolvedores e usuários de middleware, que juntos criaram o consórcio OMG -Object Management Group A especificação CORBA enfatiza os aspectos de interoperabilidade e portabilidade, especificando padrões para as interfaces e a semântica dos diversos componentes e serviços do middleware, não se limitando a uma plataforma de middleware em particular, mas define padrões para implementações particulares de diferentes fabricantes CORBA adota um modelo de objetos distribuídos baseado nos conceitos de cliente e servidor e de objetos remotos Onde um objeto possui um identificador único implementado pelo conceito de referência de objeto que permite que clientes chamem métodos de um objeto CORBA específico de forma transparente a sua localização O modelo de programação CORBA é composto por uma Linguagem de Definição de Interfaces (IDL) e por um conjunto de mapeamentos IDL para linguagens de programação específicas como C, C++, Java e outras A IDL é o núcleo do modelo de objetos, sendo usada para especificar as interfaces dos objetos, através do provimento de uma sintaxe precisa para a definição de aspectos das interfaces (operações,

4 parâmetros, atributos e exceções). Ela não especifica o funcionamento interno dos objetos, que fica a cargo do desenvolvedor A IDL permite a interoperabilidade entre clientes e objetos implementados em linguagens de programação diferentes, através da representação dos conceitos definidos em IDL, na linguagem de programação escolhida para os objetos e clientes, pelo programador. Para isso, utiliza-se de um compilador IDL específico para a geração do código fonte na linguagem escolhida Os compiladores IDL geram, ao serem utilizados, dois componentes principais: o stub ligado em tempo de compilação ao cliente que irá utilizar a interface e o skeleton que é ligado em tempo de compilação ao servidor que implementará a interface De posse desse modelo de programação, o programador fornece, do lado cliente, a implementação da aplicação, que usa os serviços disponíveis na interface do objeto e, do lado servidor, as implementações das características do objeto, conforme definidas em suas interfaces CORBA é parte da arquitetura para objetos distribuídos proposta pelo OMG, chamada OMA - Object Management Architeture (OMG). A Figura 2 provê uma visão geral desta arquitetura. Objetos de Aplicação Object Request Broker Facilidades Horizontais (Domínios específicos) Serviços de Objeto Facilidades Verticais (propósito geral) Figura 2: A arquitetura de gerenciamento de objetos do OMG Ao centro da OMA encontra-se o ORB - Object Request Broker, peça chave no suporte ao modelo de objetos CORBA, cuja definição é o objetivo principal da especificação O ORB é o responsável por implementar a comunicação entre os objetos distribuídos do sistema, tornando transparente as complicações advindas da distribuição física e da heterogeneidade do sistema. Os demais componentes da arquitetura CORBA são implementados por objetos CORBA, que se comunicam e oferecem serviços através de ORB Objetos de Aplicação são específicos de cada aplicação e representam os blocos funcionais que constituem as aplicações em um ambiente distribuído, tendo a necessidade de ter suas interfaces especificadas em CORBA IDL e de seus objetos serem instanciados como objetos CORBA (SBRC, 2002). Serviços de Objeto são os blocos básicos para a construção dos aspectos não-funcionais das aplicações sendo, portanto, independentes das mesmas. Além dos serviços de uso geral (Facilidade Verticais) como os serviços de Nomes, de Negociação (Trading), de Transações, de Persistência e de Segurança, a OMA também define uma série de interfaces para determinados domínios de aplicação específicos (Facilidades Horizontais). A especificação CORBA 3 pode ser dividida em três categorias (Jon Siegel 2002): - Integração com a Internet e Java, inclui mapeamento reverso Java para IDL (permite que objetos Java RMI interajam sobre a rede como objetos CORBA), um Serviço de Nome Interoperável (define uma referência a objeto no formato URL usado em programas para definir serviços em localizações remotas) e uma especificação de firewall (define as capacidades CORBA necessárias para assegurar a travessia de firewalls. - Controle de Qualidade de Serviço e Envio de Mensagens Assíncronas, define um número de modos de invocação assíncrono para CORBA e fornece estatísticas invocações dinâmicas a serem usadas em todos os modos. Políticas de controle de qualidade de invocação permite definir prioridades, tempo-devida (TTL), tempo de início e fim para invocações time-sensitve e controla a política de roteamento e contagem de saltos de roteamento de rede (Hop), MinimumCORBA, tolerância a falhas e tempo real. - O Modelo de Componentes CORBA (CCM), que incrementa o modelo de objetos de CORBA com o suporte padronizado para componentes de software. O CCM provê um modelo de programação baseado no conceito de componentes como elementos de software com alto potencial de reutilização, sendo uma tecnologia voltada para a implementação no lado servidor A especificação CCM se divide em cinco modelos e um meta-modelo (SBRC, 2002): - Modelo Abstrato, especifica meios para a definção de tipos de componentes e suas interfaces; - Modelo de programação, introduz o Framework de Implementação de Componentes (CIF), que permite definir a forma de interação dos aspectos funcionais de um componente com os

5 serviços providos pela plataforma (apecto não-funcionais); - Modelo de empacotamento, define a forma de empacotamento para distribuição de tipos e implementação de componentes; - Modelo de implantação, define o processo de implantação de componentes em um ambiente distribuído; - Modelo de execução, especifica um ambiente de execução para instaâncias de componentes, que se baseia no conceito de container; - Meta-modelo, define os conceitos utilizados nos modelos através da UML, as construções de linguagem e permite a geração automática de repositórios de tipos de componentes. O principal objetivo do modelo de programação do CCM é prover meios para descrever aspectos nãofuncionais dos componentes, permitindo sua geração automática, de forma que o desenvolvedor de componentes necessite codificar apenas a aparte funcional dos mesmos. A conclusão sobre o modelo é que CCM é um conjunto de frameworks para a definição, implementação, empacotamento, implantação e execução de componentes no ambiente CORBA, tendo a geração automática de implementações dos aspectos não-funcionais para as interfaces que definem os aspectos funcionais como sua grande vantagem. 1.1 J2EE A rede é o computador. Esta é a filosofia que direcionou o crescimento da Sun Microsystems desde sua fundação, em A plataforma Java possui inúmeras especificações, para a construção de pequenas applets para telefones celulares até poderosas aplicações distribuídas que rodam na Internet (AFONSO JÚNIOR, 2002). A mais poderosa das especificações é o J2EE - Java 2 Enterprise Edition que oferece em uma só arquitetura, todos os recursos necessários para a criação de uma aplicação distribuída e multi-camada (AFONSO JÚNIOR, 2002). A J2EE é uma extensão do modelo original de Java que provê suporte para o desenvolvimento de servidores de aplicações distribuídas, que introduz dois grupos de características (SBRC, 2002): - Uma infra-estrutura de tempo de execução para hospedar e gerenciar aplicações. - Um conjunto de APIs que estendem Java e são usadas na costrução de aplicações. Dentre as APIs de J2EE encontram-se (SBRC, 2002): - JDBC, para acesso a bancos de dados relacionais; - Enterprise Java Beans (EJB), o framework de componentes de J2EE; - Java Servlets, para a construção de aplicações web dinâmicas; - JavaServer Pages (JSP), para o desenvolvimento de aplicações web baseada em templates; - Java Message Services (JMS), provê serviços de middleware orientados a mensagens; - Java Transaction API (JTA), para suporte a transações distribuídas; - Java API for XML, parsing (JAXP); - Java Conector Architeture (JCA), para integração de aplicações legadas comcomponentes J2EE; - Java Authentication and Autorization Service (JAAS); - Java Interface Definition Language (IDL) API, permite que componenes java invoquem objetos CORBA via IIOP; - RMI-IIOP API: implementa Java RMI sobre IIOP para uso entre containers em J2EE; - Java Naming an Directory Interface (JNDI), provê padronização de acesso a serviços de nomes e de diretório distribuído. A plataforma J2EE provê suporte a vários containers que fornecem o ambiente de execução para os componentes da aplicação O container provê para seus componentes um ambiente com propriedades não-funcionais agregadas, através de interceptadores em nível de requisições (requests), podendo ser visto como wrappers de componentes, uma vez que as requisições são primeiro interceptadas pelos containers e depois repassadas aos componentesdestino O J2EE especifica quatro tipos de componentes (SBRC, 2002): - Web containers, que hospedam servlets e páginas JSP; - EJB conatiners, que hospedam componentes RJB e é o único que pode ser mapeados diretamente para CCM; - Applet containers, que hospedam applets de Java; - Containers de clientes de aplicação, que hospedam aplicações java convencionais. Componentes em um container acessam serviços externos através de APIs de J2EE, enquanto clientes fazem acesso a componentes através dos respectivos containers dos componentes Um container engloba um ou mais componentes de aplicação e seus respectivos descritores de

6 implantação, sendo constituído pelas seguintes partes (SBRC, 2002): - Contrato de componente: APIs especificadas pelo container e que devem ser implementadas ou estendidas pelo componente para que possam ser gerenciados no contexto do container. - APIs de serviço de container, provê acesso a serviços externos ao container, na forma de proxies; - Serviços declarativos, são interpostos entre cliente e componentes para agregar aspectos não-funcionais aos componentes sem a necessidade de programá-los; - Outros serviços de conatiner, como gerenciamento do ciclo de vida de componentes, pooling de recursos e clustering que permitem distribuir os componentes de um container em mais de uma máquina hospedeira, de modo a permitir o balanceamento de carga. J2EE utiliza dois tipos de componentes: componentes web e componentes EJB Componentes web são invocados através de HTTP e respondidos através de HTML ou XML e baseiam-se em duas tecnologias (SBRC, 2002): - Servlets, que permiem construir aplicações que rodam em servidores web, embutindo a parte lógica da aplicação no processo de requisição-resposta de HTTP; - JavaServer Pages, que permitem embutir componentes de aplicação em páginas web para permitir geração dinâmica de conteúdo. Componentes EJB são unidades de software reutilizáveis que contém a lógica da aplicação (aspectos funcionais) e representam uma tecnologia mais robusta e escalável para o desenvolvimento de aplicações distribuídas 1.2.NET É a mais nova proposta Microsoft de tecnologia orientada a objetos para web que promove uma mudança de paradigma, se comparada com as arquiteturas COM/DCOM que serviram de base para a sua criação. Os objetivos gerais desta tecnologia são o suporte à computação distribuída, componentização de software, suporte aos serviços corporativos e, principalmente, aos serviços web. A plataforma.net é baseada em um container chamado Common Language Runtime, ou CLR que gerencia a memória, a segurança e o acesso aos recursos do sistema operacional, definindo um modelo de objetos normalizado, no qual componentes e serviços são definidos A interoperabilidade entre componentes escritos em linguagens diferentes é suportado por.net e o protocolo SOAP (Simple Object Access Protocol é utilizado para a comunicação entre componentes Todo o código escrito em uma determinada linguagem são mapeados para o CLR que provê o ambiente de execução para os componentes. Em tese, este mapeamento permite que partes distintas de um mesmo componente seja implementado em linguagens diferentes desde que haja um respectivo mapeamento para o CLR. A construção de aplicações a partir de componentes faz uso intenso de meta-informações, em XML, para descrever explicitamente as dependências entre componentes relacionados 1.3 Análise Comparativa dos Padrões Atuais Os atuais padrões de middleware concentram-se principalmente no suporte ao rápido desenvolvimento de aplicações para internet, através da utilização de modelos de componentes distribuídos e da disponibilização de containers que permitem o provimento de ambientes de execução selecionáveis pelo desenvolvedor, definindo uma separação clara dos aspectos funcionais e não-funcionais para o desenvolvimento de aplicações, além de prover alta disponibilidade da plataforma e das aplicações por ela suportadas através da utilização de modelos de componentes robustos No entanto, o padrão que mais se aproxima do modelo de referência RM-ODP é o CORBA, sendo um exemplo claro da utilização de RM-ODP ao incorporar elementos deste modelo. Concorda-se aqui com as afirmações feitas por Fábio M. Costa e Fábio Kon em 1.4 Limitações dos Padrões Atuais A falta de flexibilidade dos padrões quanto a configurabilidade é uma das mais graves limitações dos modelos. Os cotainers são caixas pretas que se adequam a determinados tipos de aplicação genérica e prédeterminados, o que impossibilita uma construção mais específia e adequada a um determinado ambiente de execução, reduzindo o ganho de desempenho e performance que se teria com um melhor detalhamento do conteúdo dos containers que irão suportar a aplicação. Além das limitações supracitadas, que são comuns a todas as plataformas estudadas, adicionamse as seguintes particularidades: Em CCM, a definição estática de containers penaliza a flexibilidade do modelo, não sendo possível definir novas categorias de containers, além de o conjunto de aspectos não-funcionais suportados pelo container ser fixo Esta falta de flexibilidade reduz sua aplicabilidade fora de servidores.

7 Componentes CORBA são cmparáveis a componentes EJB, sendo a especificação CCM um super-conjunto de EJB. Em J2EE, os EJBs são dependentes de linguagem, uma vez que são suportados pelo modelo de objetos de Java. Em.NET a possibilidade teórica de parte dos componentes poderem ser implementados em linguagens diferentes não se confirma na prática, pois apenas um sub-conjunto da linguagem pode ser completamente mapeado para o CLR. Ressalta-se ainda a ausência de suporte para a interoperabilidade em ambientes heterogêneos no nível de sistema operacional, não somente pelo fato de não existirem implementações atuais de.net para outros sistemas operacionais fora do contexto Microsoft, mas também pelo fato de que o CLR e os serviços disponíveis neste ambiente serem fortemente vinculados aos sistemas operacionais da família Windows 4. Padrões de Middleware Futuros A evolução dos ambientes de execução e os novos tipos de aplicação surgidas atualmente (como por exemplo um telefone celular se integrando com um software de banco de dados) requerem um alto grau de flexibilidade e dinamismo. O que faz com que tecnologias tradicionais de middleware estáticas e monolíticas se tornem inadequadas. Surge a necessidade da aplicação de conceitos como multimídia distribuída, computação ubígua, adaptação dinâmica e reflexão computacional sobre um middleware cuja organização interna é baseada na tecnologia de componentes, permitindo um alto grau de flexibilidade na configuração de aplicações e na implementação da própria plataforma. 4.1 Mídias Contínuas São mídias de informação cujo conteúdo varia em função do tempo, sendo exemplos deste tipo de mídia: áudio, vídeo e animações gráficas. O uso deste tipo de mídia em sistemas distribuídos requer suporte para transferência de dados ininterruptas entre os produtores e consumidores da informação, por períodos de tempo relativamente longos (SBRC, 2002). 4.2 Computação Móvel Basea-se em transmissão sem fio (Espectro eletromagnético, Transmissão de rádio, trnasmissão Microondas, Ondas milimétricas e Infravermelhas e Transmissão de Ondas de Luz) e computadores móveis, sistemas embutidos e PDAs. 4.3 Computação Ubíqua É baseada na pluralidade dos recursos utilizados e das conexões aos ambientes de redes heterogêneas, formadas por segmentos Ethernet, ATM, FDDI e sem fio de curto, médio e longo alcance. 4.4 Middleware Baseado em Componentes Este modelo abandona a organização monolítica e estática dos middlewares tradicionais para ser implementado sobre componentes independentes e reutilizáveis. Sendo configurado a partir da combinação desses componentes em diferentes modos para contextos diferentes, que vão permitir a sintonia fina com o ambiente de execução, em busca da melhora de desempenho e de qualidade de serviço exigida por sistemas complexos. 4.5 Middleware Reflexivo A idéia central deste modelo é prover transparência para as aplicações que não estão interessadas nos detalhes das camadas inferiores (disponibilidade de memória e processador, estrutura de rede, etc.) e translucidez e controle fino para as que podem se beneficiar desses recursos. Para tal, o middleware é implementado com base em uma coleção de componentes configuráveis pela aplicação, que pode inspecionar a configuração interna do middleware e reconfiguá-las para adaptá-la a mudanças no ambiente. Desta forma, passa a ser possível selecionar protocolos de comunicação de rede, política de segurança, algorítimos de codificação e vários outros mecanismos de otimização de desempenho em diferentes contextos e situações. Sistemas de middleware reflexivo possuem metainterfaces que vão permitr a configuração em tempo de inicialização e a reconfiguração dinâmica em tempo de execução, quando ocorrerem mudanças na disponibilidade de recursos ou no padrão de acesso do sistema pelos seus usuários. O modelo de middleware reflexivo mantém uma representação explícita de sua estrutura interna que, ao ser modificada, causa mudanças na implementação do middleware e vice-versa (autorepresentação casualmente conectada) podendo se autoconhecer e refletir sobre si próprio. Sistemas de middleware reflexivo possuem cinco (05) conceitos fundamentais, a saber (SBRC, 2002): - Reificação, disponibilizar a estrutura interna de um sistema em entidades programáveis manipuláveis em tempo de execução; - Arquitetura de meta-níveis, estruturação de sistemas em um nível-base (funcionalidades do sistema) e um metanivel (processamento reflexivo); - Meta-Objeto e Protocolo de meta-objeto (MOP), denominação dada, respectivamente, à entidades presentes no meta-nível e ao protocolo de interação destas entidades;

8 - Reflexão Estrutural, habilidade de uma linguagem de programação de reificar completamente o programa em execução; - Reflexão Comportamental, habilidade de uma linguagem de representar completamente sua semântica, em termos dos aspectos internos do ambiente de execução (modo de processar o programa, gerência de recursos, etc.). Com base nos conceitos citados acima, duas aplicações práticas de middleware reflexivo foram desenvolvidas, são elas: - Dynamic TAO, foca o reaproveitamento do código escrito para TAO (implementação completa de um ORB CORBA modular e estático) e o adequa à reflexão. Permite a reconfiguração em tempo de execução do funcionamento interno do ORB (ver seção 3.1) e das aplicações executadas sobre ele, através da utilização de configuradores de componentes, para implementar a reflexão estrutural, e de interceptadores e um Escalonador Dinâmico de Tempo-Real Flexível (DSRT), para obter a reflexão comportamental. - Open ORB, foca a reflexão computacional desde seu planejamento, voltando-se para o desenho de middlewares configuráveis e reconfiguráveis. Provê uma separação clara entre o nível-base da plataforma (componentes que implementam serviços usuais de middleware) e seu meta-nível (mecanismos que expõem a implementação da plataforma, permitindo sua inspeção e adaptação dinâmicas). 5. Solução do Artigo A solução do presente artigo foi pensada com base nas limitações das plataformas monolíticas e estáticas de middleware discutidas anteriormente e, ainda, com base nos conceitos, necessidades e aplicações práticas descritos na seção quatro (04) deste artigo, tendo sido dividida em duas propostas: Proposta de Middleware e Proposta de arquitetura multicamada. 5.1 Proposta de Middleware A proposta de middleware de objetos distribuídos baseada em componentes, autoconfigurável e reflexivo, deste artigo, segue a idéia da arquitetura de Web Services, baseando-se em APIs e componentes específicos para as características de cada ambiente de execução existente (sistema operacional, protocolos de rede, meio de comunicação, tipo de aplicação, velocidade de conexão, controle de acesso, Hardware, etc.). Concordando com a idéia de sintonia fina citada em (SBRC, 2002, p. 49) como uma característica desejável às futuras gerações de Middleware. A criação e disponibilização de cada API e seus respectivos componentes seria da responsabilidade da equipe de pesquisadores responsável pela criação do novo ambiente de execução, no entanto, outros fornecedores poderiam criar e disponibilizar sua API e respectivos componentes, para o mesmo ambiente de execução. Os containers, como em J2EE, seriam wrappers de componentes que interceptariam as requisições, identificaria as características necessárias a aquele ambiente, selecionaria as APIs necessárias em uma matriz de localização e seriam montados na memória local da máquina solicitante, com referências aos endereços de cada servidor (provedor) de middleware responsável pelo provimento de cada API selecionada. O protocolo de atualização da matriz de localização, localizada no servidor de middleware, segueria os mesmos moldes dos protocolos de roteamento da internet, e teriam o formato de uma tabela de decisão, onde as diversas possibilidades de configuração seriam disponibilizadas e relacionadas às APIs de sua respectiva localização (Região Administrativa). Seria mantida uma segunda matriz, a matriz de configuração, responsável por manter a configuração interna dos Containers para possibilitar a inspeção e adaptação do middleware (reflexão). Os clientes fariam acesso aos componentes da aplicação através dos respectivos containers. Cada API conteria em sua definição, possibilidades de mapeamento para as principais linguagens de programação existentes. Com a criação da matriz de localização, a seleção das APIs que dariam suporte a montagem da aplicação e do middleware seria facilitada e flexibilizada, uma vez que as APIs e seus componentes poderiam estar disponíveis em qualquer localização geográfica da web, a transparência a localização seria atendida, e a complexidade do gerenciamento e os recursos necessários para tal tarefa estariam sob a responsabilidade dos servidores de middleware espalhados pela web. A matriz de localização proveria a flexibilidade de configuração necessária às aplicações, permitindo a seleção e montagem, em um container, de aspectos funcionais da aplicação disponíveis na web. Assim como proveria a flexibilidade de configuração necessária ao middleware, que poderiam ter seus containers montados com componentes específicos e necessários a um ambiente particular de execução, otimizando o desenpenho do sistema para aquele ambiente. A criação da matriz de localização implicaria na adição de uma estrutura de servidores de middleware, na web, reponsável por mantê-la. Porém o ganho tecnológico advindo com a flexibilidade de configuração e com os padrões abertos estabelecidos

9 para o fornecimento desta tecnologia superaria em muito os custos de sua implantação. 5.2 Proposta de Arquitetura Multicamada Sugere-se aqui uma arquietura de aplicação dividida em cinco (05) camadas, uma evolução de sua antecessora, a de quatro (04) camadas, ficando as camadas dispostas da seguinte forma: - Cliente, provê o acesso a aplicação por intermédio de um navegador, retirando as regras de negócio do cliente e centralizando-as em um servidor de aplicações; - Apresentação, a apresentação do cliente é retirada deste e centralizada em um servidor web, deixando o cliente de existir como um programa que precisa ser instalado em cada host da rede; - Lógica, são as regras de negócio do cliente, ou seja, as características funcionais da aplicação, onde reside o servidor de aplicação; - Dados, camada responsável pela persitência dos dados da aplicação, onde reside o servidor de Banco de Dados. - Middleware, camada responsável pelo provimento dos aspectos não-funcionais da aplicação como comunicação remota, modos de acesso, formatos de dados, recursos de hardware e software, etc., oferecendo uma interface de programação comum e independente do sistema operacional e da arquietura de hardware, onde reside o servidor de middleware; 6. Conclusão Este artigo abordou, de forma breve, alguns conceitos relacionados com a tecnologia de middleware. Em seguida comparou os padrões existentes no mercado e confrontou-os com as necessidades das próximas implementações. Isto levou a constatação que a tecnologia de middleware, monolítica e estática, existente atualmente, necessita ser revista para prover acesso personalizado aos vários aspectos internos de cada ambiente de execução, o que possibilitará a geração de aplicações distribuídas mais eficientes. Para atingir tal objetivo, necessita-se de uma padronização mundial para o desenvolvimento e provimento de tecnologias de middleware por parte de seus fabricantes, que na busca por mercado acabam por conduzir soluções isoladas, ou no máximo com alguma portabilidade para o ambiente de uma empresa parceira. O que se propõe aqui, não é uma solução individual que possua melhor ou pior aceitação no mercado, e sim um modelo de desenvolvimento aberto, como o RM-OSI para o ambiente de rede, sobre o qual os fornecedores poderiam se basear para o provimento dessas tecnologias de middleware, garantido a interoperabilidade e a livre concorrência em um mercado cada vez maior. Por outro lado, ganharia a ciência e os consumidores desta tecnologia que poderiam gerar suas aplicações baseadas em middlewares adaptáveis a cada ambiente de execução, sem que para isso fosse necessário escolher entre uma ou outra tecnologia proprietária. Encerra-se este artigo esperando-se contribuir, senão para o avanço desta nova tecnologia de middleware e seu respectivo esforço de padronização, para o alerta à comunidade científica da necessidade desta padronização, que já se faz tardia e, com isso, tem contido a revolução da internet que, a partir de então, receberá a adesão em massa das organizações que necessitem de aplicações distribuídas. Referências (AFONSO JÚNIOR, 2002) AFONSO JÚNIOR, CARÍCIO Cio Magazine setembro de (BAKKEN, 2001) BAKKEN, David E. Encyclopedia of Distributed Computing, Kluwer Academic Press, Universidade do Estado de Washington. (BOLONHA, 2002) BOLONHA, João Carlos Cio Magazine setembro de (BOOCH, 2000) BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar tradução de Fábio Freitas da Silva. Rio de Janeiro: Campus, (DORSEY, 2001) DORSEY, Paul ORACLE JDEVELOPER: o manual oficial ISBN (FREIRE, 2002) FREIRE, Herval Cio Magazine setembro de (GUITIERREZ, 2002) GUITIERREZ, Marco Antônio Cio Magazine setembro de (JON SIEGEL, 2001), JON SIEGEL CORBA 3 Released setembro de 2002 avaliado em. nfo.htm. (MOLINARI, 2002) MOLINARI, Leonardo; RIBEIRO, Ricardo Lopes Cio Magazine setembro de (SBRC, 2002) 20º SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES, Fábio M. Costa Instituto de Informática Universidade Federal de Goiás e Fábio Kon Departamento de Ciência da

10 Computação Universidade de São Paulo maio de (URRESTI, 2002) URRESTI, Hugo Ricardo Cio Magazine setembro de 2002.

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 5 Servidores de Aplicação

Leia mais

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br CORBA Common Object Request Broker Architecture Unicamp Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br Objetivos Apresentação Tecnologia CORBA Conceitos Básicos e Terminologia Considerações

Leia mais

UNIVERSIDADE. Sistemas Distribuídos

UNIVERSIDADE. Sistemas Distribuídos UNIVERSIDADE Sistemas Distribuídos Ciência da Computação Prof. Jesus José de Oliveira Neto Web Services Web Services Existem diferentes tipos de comunicação em um sistema distribuído: Sockets Invocação

Leia mais

Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Sumário. Java 2 Enterprise Edition. J2EE (Java 2 Enterprise Edition)

Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Sumário. Java 2 Enterprise Edition. J2EE (Java 2 Enterprise Edition) Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) J2EE () Sumário Introdução J2EE () APIs J2EE Web Container: Servlets e JSP Padrão XML 2 J2EE é Uma especificação para servidores

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Faculdades SENAC Análise e Desenvolvimento de Sistemas 28 de abril de 2010 Principais suportes de Java RMI (Remote Method Invocation), da Sun Microsystems DCOM (Distributed Component Object Model), da

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Web Services. Integração de aplicações na Web. Sistemas Distribuídos

Web Services. Integração de aplicações na Web. Sistemas Distribuídos Web Services Integração de aplicações na Web Integração de Aplicações na Web Interoperação entre ambientes heterogêneos desafios diversidade de componentes: EJB, CORBA, DCOM... diversidade de linguagens:

Leia mais

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira

ENTERPRISE JAVABEANS 3. Msc. Daniele Carvalho Oliveira ENTERPRISE JAVABEANS 3 Msc. Daniele Carvalho Oliveira Apostila Servlets e JSP www.argonavis.com.br/cursos/java/j550/index.html INTRODUÇÃO Introdução Enterprise JavaBeans é um padrão de modelo de componentes

Leia mais

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008.

Capítulo VI CORBA. Common Object Request Broker Architecture. [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. Common Object Request Broker Architecture [Cardoso2008] Programação de Sistemas Distribuídos em Java, Jorge Cardoso, FCA, 2008. From: Fintan Bolton Pure CORBA SAMS, 2001 From: Coulouris, Dollimore and

Leia mais

Componentes para Computação Distribuída

Componentes para Computação Distribuída Componentes para Computação Distribuída Conceitos Foi a partir do fenômeno da Internet (WWW), no início dos anos noventa, que a computação distribuída passou a ter relevância definitiva, a ponto de a Internet

Leia mais

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware.

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware. Camadas de Software - o Middleware Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas Modelos de Arquitecturas para sistemas distribuidos Interfaces e Objectos Requerimentos para Arquitecturas Distribuídas

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos 11 Objetivos Este capítulo apresenta uma introdução aos sistemas distribuídos em geral Arquiteturas de cliente servidor Características das arquiteturas de 2 e 3 camadas Ambiente

Leia mais

Padrões de Projeto Implementados em Infraestrturas de Componentes

Padrões de Projeto Implementados em Infraestrturas de Componentes Padrões de Projeto Implementados em Infraestrturas de Componentes Paulo Pires paulopires@nce.ufrj.br http//genesis.nce.ufrj.br/dataware/hp/pires 1 distribuídas baseadas em componentes Comunicação transparente,

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Soquetes Um soquete é formado por um endereço IP concatenado com um número de porta. Em geral, os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos

Leia mais

J2EE TM Java 2 Plataform, Enterprise Edition

J2EE TM Java 2 Plataform, Enterprise Edition CURSO DE GRADUAÇÃO J2EE TM Java 2 Plataform, Enterprise Edition Antonio Benedito Coimbra Sampaio Junior abc@unama.br OBJETIVOS DO CURSO Capacitar os alunos no desenvolvimento de aplicações para a WEB com

Leia mais

Web Technologies. Tópicos da apresentação

Web Technologies. Tópicos da apresentação Web Technologies Tecnologias de Middleware 2004/2005 Hugo Simões hsimoes@di.fc.ul.pt 1 A Web Tópicos da apresentação Tecnologias Web para suporte a clientes remotos (Applets,CGI,Servlets) Servidores Aplicacionais

Leia mais

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br

Tecnologia Java. Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Tecnologia Java Daniel Destro do Carmo Softech Network Informática daniel@danieldestro.com.br Origem da Tecnologia Java Projeto inicial: Oak (liderado por James Gosling) Lançada em 1995 (Java) Tecnologia

Leia mais

Princípios de Sistemas Distribuídos. Tecnologias utilizadas em sistemas distribuídos Aula 5

Princípios de Sistemas Distribuídos. Tecnologias utilizadas em sistemas distribuídos Aula 5 Princípios de Sistemas Distribuídos Tecnologias utilizadas em sistemas distribuídos Aula 5 Conceitos de comunicação entre processos Interprocess Communication (IPC) Sistemas distribuídos são construídos

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 10 Persistência de Dados

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

3 Serviços na Web (Web services)

3 Serviços na Web (Web services) 3 Serviços na Web (Web services) 3.1. Visão Geral Com base na definição do Word Wide Web Consortium (W3C), web services são aplicações autocontidas, que possuem interface baseadas em XML e que descrevem

Leia mais

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES

DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES DESENVOLVIMENTO COM JAVA EE E SUAS ESPECIFICAÇÕES Hugo Henrique Rodrigues Correa¹, Jaime Willian Dias 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil hugohrcorrea@gmail.com, jaime@unipar.br Resumo.

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

INE5380 - Sistemas Distribuídos

INE5380 - Sistemas Distribuídos INE5380 - Sistemas Distribuídos Object Request Broker e CORBA Por: Léo Willian Kölln - 0513227-4 Novembro de 2006 ORB Object Request Broker ORB aqui será tratado como um Middleware que permite a construção

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas

Linguagem de Programação JAVA. Professora Michelle Nery Nomeclaturas Linguagem de Programação JAVA Professora Michelle Nery Nomeclaturas Conteúdo Programático Nomeclaturas JDK JRE JEE JSE JME JVM Toolkits Swing AWT/SWT JDBC EJB JNI JSP Conteúdo Programático Nomenclatures

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

Serviços Web: Introdução

Serviços Web: Introdução Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do Maranhão Objetivos Nesta aula

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Basedos na Web Capítulo 12 Agenda Arquitetura Processos Comunicação Nomeação Sincronização Consistência e Replicação Introdução

Leia mais

4 Um Exemplo de Implementação

4 Um Exemplo de Implementação 4 Um Exemplo de Implementação Neste capítulo será discutida uma implementação baseada na arquitetura proposta. Para tanto, será explicado como a arquitetura proposta se casa com as necessidades da aplicação

Leia mais

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS

DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS DESENVOLVIMENTO WEB UTILIZANDO FRAMEWORK PRIMEFACES E OUTRAS TECNOLOGIAS ATUAIS Emanuel M. Godoy 1, Ricardo Ribeiro Rufino 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil godoymanel@gmail.com,

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Web Services. (Introdução)

Web Services. (Introdução) Web Services (Introdução) Agenda Introdução SOA (Service Oriented Architecture) Web Services Arquitetura XML SOAP WSDL UDDI Conclusão Introdução Comunicação distribuída Estratégias que permitem a comunicação

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Modelo Cliente-Servidor: Introdução aos tipos de servidores e clientes Prof. MSc. Hugo Souza Iniciando o módulo 03 da primeira unidade, iremos abordar sobre o Modelo Cliente-Servidor

Leia mais

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural

Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Resumo: Perguntas a fazer ao elaborar um projeto arquitetural Sobre entidades externas ao sistema Quais sistemas externos devem ser acessados? Como serão acessados? Há integração com o legado a ser feita?

Leia mais

Adriano Reine Bueno Rafael Barros Silva

Adriano Reine Bueno Rafael Barros Silva Adriano Reine Bueno Rafael Barros Silva Introdução RMI Tecnologias Semelhantes Arquitetura RMI Funcionamento Serialização dos dados Criando Aplicações Distribuídas com RMI Segurança Exemplo prático Referências

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

Intranets. FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO

Intranets. FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO Intranets FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO As intranets são redes internas às organizações que usam as tecnologias utilizadas na rede mundial

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS Pág. CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 2.1 A tecnologia de orientação a objetos 25 2.1.1 Projeto de software

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais

3 Arquitetura do Sistema

3 Arquitetura do Sistema 3 Arquitetura do Sistema Este capítulo irá descrever a arquitetura geral do sistema, justificando as decisões de implementação tomadas. Na primeira seção iremos considerar um conjunto de nós interagindo

Leia mais

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

SISTEMAS DISTRIBUÍDOS

SISTEMAS DISTRIBUÍDOS SISTEMAS DISTRIBUÍDOS Cluster, Grid e computação em nuvem Slide 8 Nielsen C. Damasceno Introdução Inicialmente, os ambientes distribuídos eram formados através de um cluster. Com o avanço das tecnologias

Leia mais

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio 32 3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio Este capítulo apresenta o framework orientado a aspectos para monitoramento e análise de processos de negócio

Leia mais

Sistemas Distribuídos. Introdução

Sistemas Distribuídos. Introdução Sistemas Distribuídos Introdução Definição Processos Um sistema distribuído é um conjunto de computadores independentes, interligados por uma rede de conexão, executando um software distribuído. Executados

Leia mais

Enterprise Java Bean. Enterprise JavaBeans

Enterprise Java Bean. Enterprise JavaBeans Enterprise Java Bean Introdução Elementos do Modelo Enterprise JavaBeans A especificação do Enterprise JavaBeansTM (EJB) define uma arquitetura para o desenvolvimento de componentes de software distribuídos

Leia mais

SOA Introdução. SOA Visão Departamental das Organizações

SOA Introdução. SOA Visão Departamental das Organizações 1 Introdução A Organização é a forma pela qual nós coordenamos nossos recursos de todos os tipos para realizar o trabalho que nos propusemos a fazer. A estrutura de nossas organizações manteve-se basicamente

Leia mais

Object Brokers. Tecnologias de Middleware 2004/2005 André Santos

Object Brokers. Tecnologias de Middleware 2004/2005 André Santos Object Brokers Tecnologias de Middleware 2004/2005 André Santos Resumo O que são Object Brokers? Como surgiu o conceito? CORBA Exemplos de utilização Comparação com Java RMI Actualidade (J2EE,.NET) O que

Leia mais

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador Sistemas de Informação Prof. Anderson D. Moura Um programa de computador é composto por uma seqüência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

Framework. Marcos Paulo de Souza Brito João Paulo Raittes

Framework. Marcos Paulo de Souza Brito João Paulo Raittes Framework Marcos Paulo de Souza Brito João Paulo Raittes Sobre o seu surgimento A primeira versão do spring foi escrita por Rod Johnson em 2002, quando ele estava Lancando o seu livro Expert One-on-One

Leia mais

Padrões Arquiteturais. Sistemas Distribuídos: Broker

Padrões Arquiteturais. Sistemas Distribuídos: Broker Padrões Arquiteturais Sistemas Distribuídos: Broker Sistemas Distribuídos Tendências: Sistemas Comp. com múltiplas CPUs Redes locais com centenas de hospedeiros Benefícios Economia Desempenho e escalabilidade

Leia mais

Computational viewpoint. Engineering Viewpoint

Computational viewpoint. Engineering Viewpoint Processamento Paralelo RM-ODP Prof. João Paulo A. Almeida (jpalmeida@inf.ufes.br) 2007/0 - INF02799 RM-ODP Reference Model for Open Distributed Processing Contém conceitos para a especificação de sistemas

Leia mais

Tipos de Sistemas Distribuídos (Cluster e Grid)

Tipos de Sistemas Distribuídos (Cluster e Grid) Tipos de Sistemas Distribuídos (Cluster e Grid) Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência

Leia mais

Desenvolvimento Cliente-Servidor 1

Desenvolvimento Cliente-Servidor 1 Desenvolvimento Cliente- 1 Ambiienttes de Desenvollviimentto Avançados Engenharia Informática Instituto Superior de Engenharia do Porto Alexandre Bragança 1998/99 Ambientes de Desenvolvimento Avançados

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com Projeto de Sistemas Distribuídos Prof. Andrêza Leite andreza.lba@gmail.com Exemplos de SD Quais podem ser? Ex. de SD: Internet Internet é um conjunto de redes de computadores, de muitos tipos diferentes,

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia mais

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1. Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3

INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1. Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3 INTEGRAÇÃO DE APLICAÇÕES UTILIZANDO WEB SERVICE 1 Kellen Kristine Perazzoli 2 ; Manassés Ribeiro 3 INTRODUÇÃO Atualmente empresas de diversos portes estão encontrando nos web services soluções para seus

Leia mais

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com Projeto de Sistemas Distribuídos Prof. Andrêza Leite andreza.lba@gmail.com Agenda Introdução Exemplos de Sistemas Distribuídos Compartilhamento de Recursos e a Web Principais Desafios para a Implementação

Leia mais

A utilização do JSWDP para construção de Web Services

A utilização do JSWDP para construção de Web Services A utilização do JSWDP para construção de Web Services Fabiana Ferreira Cardoso 1, Francisco A. S. Júnior 1, Madianita Bogo 1 1 Centro de Tecnologia da Informação Centro Universitário Luterano de Palmas

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 1 Conceitos da Computação em Nuvem A computação em nuvem ou cloud computing

Leia mais

Sistemas Distribuídos Comunicação entre Processos em Sistemas Distribuídos: Middleware de comunicação Aula II Prof. Rosemary Silveira F. Melo Comunicação em sistemas distribuídos é um ponto fundamental

Leia mais

} Monolíticas Aplicações em um computador centralizado. } Em Rede Aplicações com comunicação em rede. } Distribuídas Comunicação e cooperação em rede

} Monolíticas Aplicações em um computador centralizado. } Em Rede Aplicações com comunicação em rede. } Distribuídas Comunicação e cooperação em rede Prof. Samuel Souza } Monolíticas Aplicações em um computador centralizado } Em Rede Aplicações com comunicação em rede } Distribuídas Comunicação e cooperação em rede } Aplicações que são funcionalmente

Leia mais

A computação na nuvem é um novo modelo de computação que permite ao usuário final acessar uma grande quantidade de aplicações e serviços em qualquer

A computação na nuvem é um novo modelo de computação que permite ao usuário final acessar uma grande quantidade de aplicações e serviços em qualquer A computação na nuvem é um novo modelo de computação que permite ao usuário final acessar uma grande quantidade de aplicações e serviços em qualquer lugar e independente da plataforma, bastando para isso

Leia mais

Arquitetura Orientada a Serviço

Arquitetura Orientada a Serviço Arquitetura Orientada a Fabio Perez Marzullo IEEE Body of Knowledge on Services Computing Sponsored by Technical Committee on Services Computing, IEEE Computer Society 1 SOA e Web Services SOA é um modelo

Leia mais

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44

Etc & Tal. Volume 2 - Número 1 - Abril 2009 SBC HORIZONTES 44 Armazenando Dados em Aplicações Java Parte 2 de 3: Apresentando as opções Hua Lin Chang Costa, hualin@cos.ufrj.br, COPPE/UFRJ. Leonardo Gresta Paulino Murta, leomurta@ic.uff.br, IC/UFF. Vanessa Braganholo,

Leia mais

3 SCS: Sistema de Componentes de Software

3 SCS: Sistema de Componentes de Software 3 SCS: Sistema de Componentes de Software O mecanismo para acompanhamento das chamadas remotas se baseia em informações coletadas durante a execução da aplicação. Para a coleta dessas informações é necessário

Leia mais

OMA (Object Management Arquitecture): Application Interfaces. Domain Interfaces. Domain. Interfaces. Object Request Broker (ORB) Object Services

OMA (Object Management Arquitecture): Application Interfaces. Domain Interfaces. Domain. Interfaces. Object Request Broker (ORB) Object Services 1 Copyright 1998, 1999 Francisco Reverbel OMA (Object Management Arquitecture): Application Interfaces Domain Domain Interfaces Interfaces Object Request Broker (ORB) Object Services 2 Copyright 1998,

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Laboratório de Computação VI JAVA IDL. Fabricio Aparecido Breve - 981648-9

Laboratório de Computação VI JAVA IDL. Fabricio Aparecido Breve - 981648-9 Laboratório de Computação VI JAVA IDL Fabricio Aparecido Breve - 981648-9 O que é Java IDL? Java IDL é uma tecnologia para objetos distribuídos, ou seja, objetos em diferentes plataformas interagindo através

Leia mais

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO

SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO SISTEMA DE GESTÃO DE PESSOAS SEBRAE/TO UNIDADE: GESTÃO ESTRATÉGICA PROCESSO: TECNOLOGIA DA INFORMAÇÃO Competências Analista 1. Administração de recursos de infra-estrutura de tecnologia da informação 2.

Leia mais

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Conceitos Gerais Graça Bressan Graça Bressan/LARC 2000 1 Forças de marketing que conduzem à arquitetura cliente/servidor "Cliente/Servidor é um movimento irresistível que está reformulando

Leia mais

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES

INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES Sistema de Informação e Tecnologia FEQ 0411 Prof Luciel Henrique de Oliveira luciel@uol.com.br Capítulo 5 INFRAESTRUTURA DE TI E TECNOLOGIAS EMERGENTES PRADO, Edmir P.V.; SOUZA, Cesar A. de. (org). Fundamentos

Leia mais

UM FRAMEWORK PARA DESENVOLVIMENTO DE

UM FRAMEWORK PARA DESENVOLVIMENTO DE UNIVERSIDADE FEDERAL DE PERNAMBUCO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO CENTRO DE INFORMÁTICA UM FRAMEWORK PARA DESENVOLVIMENTO DE APLICATIVOS EM WINDOWS MOBILE. PROPOSTA DE TRABALHO DE GRADUAÇÃO Aluno:

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos LICENCIATURA EM COMPUTAÇÃO Prof. Adriano Avelar Site: www.adrianoavelar.com Email: eam.avelar@gmail.com Mecanismos de Comunicação Protocolos de Aplicação Mecanismos de comunicação

Leia mais

SOA: Service-oriented architecture

SOA: Service-oriented architecture SOA: Service-oriented architecture Roteiro Breve História O que é Arquitetura de Software? O que é SOA? Serviços Infraestrutura Composição Sua empresa está preparada para SOA? Breve História Uma empresa

Leia mais

O modelo de arquitetura CORBA e suas aplicações

O modelo de arquitetura CORBA e suas aplicações ABR. MAI. JUN. 2004 ANO X, N º 37 157-163 INTEGRAÇÃO 157 O modelo de arquitetura CORBA e suas aplicações ANA PAULA GONÇALVES SERRA* Resumo Nos últimos anos, os sistemas de informação nas empresas têm evoluído

Leia mais

PadrãoIX. Módulo II JAVA. Marcio de Carvalho Victorino. Servlets A,L,F,M

PadrãoIX. Módulo II JAVA. Marcio de Carvalho Victorino. Servlets A,L,F,M JAVA Marcio de Carvalho Victorino 1 Servlets 2 1 Plataforma WEB Baseada em HTTP (RFC 2068): Protocolo simples de transferência de arquivos Sem estado (não mantém sessão aberta) Funcionamento (simplificado):

Leia mais

Planejamento Estratégico de TI. Felipe Pontes felipe.pontes@gmail.com

Planejamento Estratégico de TI. Felipe Pontes felipe.pontes@gmail.com Planejamento Estratégico de TI Felipe Pontes felipe.pontes@gmail.com VPN Virtual Private Network Permite acesso aos recursos computacionais da empresa via Internet de forma segura Conexão criptografada

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

Cliente/Servidor. Objetos Distribuídos. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Objetos Distribuídos. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Objetos Distribuídos Graça Bressan Graça Bressan/LARC 2000 1 Objetos São entidades de software que encapsulam dados, ou atributos, e código e que são acessados através de funções ou métodos.

Leia mais

Associação Carioca de Ensino Superior Centro Universitário Carioca

Associação Carioca de Ensino Superior Centro Universitário Carioca Desenvolvimento de Aplicações Web Lista de Exercícios Métodos HTTP 1. No tocante ao protocolo de transferência de hipertexto (HTTP), esse protocolo da categoria "solicitação e resposta" possui três métodos

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

SISTEMA COMPUTACIONAL PARA ANÁLISES DE DADOS EM AGRICULTURA DE PRECISÃO

SISTEMA COMPUTACIONAL PARA ANÁLISES DE DADOS EM AGRICULTURA DE PRECISÃO UNIVERSIDADE FEDERAL RURAL DO RIO DE JANEIRO INSTITUTO DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA PROJETO SISTEMA COMPUTACIONAL PARA ANÁLISES DE DADOS EM AGRICULTURA DE PRECISÃO ALUNO RICARDO CARDOSO TERZELLA

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

RMI: Uma Visão Conceitual

RMI: Uma Visão Conceitual RMI: Uma Visão Conceitual Márcio Castro, Mateus Raeder e Thiago Nunes 11 de abril de 2007 Resumo Invocação de Método Remoto (Remote Method Invocation - RMI) trata-se de uma abordagem Java para disponibilizar

Leia mais

Sistemas Distribuídos e Paralelos

Sistemas Distribuídos e Paralelos Sistemas Distribuídos e Paralelos Objectos e Componentes Distribuídos Ricardo Mendão Silva Universidade Autónoma de Lisboa r.m.silva@ieee.org November 19, 2014 Ricardo Mendão Silva (UAL) Sistemas Distribuídos

Leia mais

Modelos e Arquiteturas de Sistemas Computacionais

Modelos e Arquiteturas de Sistemas Computacionais Modelos e Arquiteturas de Sistemas Computacionais Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas SUMÁRIO Importância da definição da Arquitetura

Leia mais

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4

Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Sistemas Distribuídos Capítulos 3 e 4 - Aula 4 Aula passada Threads Threads em SDs Processos Clientes Processos Servidores Aula de hoje Clusters de Servidores Migração de Código Comunicação (Cap. 4) Fundamentos

Leia mais

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB)

Uma Introdução à Arquitetura CORBA. O Object Request Broker (ORB) Uma Introdução à Arquitetura Francisco C. R. Reverbel 1 Copyright 1998-2006 Francisco Reverbel O Object Request Broker (ORB) Via de comunicação entre objetos (object bus), na arquitetura do OMG Definido

Leia mais

Integração de sistemas utilizando Web Services do tipo REST

Integração de sistemas utilizando Web Services do tipo REST Integração de sistemas utilizando Web Services do tipo REST Jhonatan Wilson Aparecido Garbo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil jhowgarbo@gmail.com jaime@unipar.br

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais