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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Desenvolvimento de Aplicações. Desenvolvimento de Aplicações. Desenvolvimento de Aplicações. Dificuldades no uso de Bancos de Dados

Desenvolvimento de Aplicações. Desenvolvimento de Aplicações. Desenvolvimento de Aplicações. Dificuldades no uso de Bancos de Dados Desenvolvimento de Aplicações Desenvolvimento de Aplicações Dificuldades no uso de Bancos de Dados Um leigo não sabe o que é e como funciona um BD Mesmo um profissional da área de informática pode ter

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

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

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

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

Java 2 Enterprise Edition

Java 2 Enterprise Edition Java 2 Enterprise Edition Pablo Vieira Florentino 8/11/2006 Contexto Linguagem Java A linguagem Java é Orientada a Objetos Influenciada diretamente por C++ e Eiffel, a linguagem segue a grande tendência

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

CAPÍTULO 3 MIDDLEWARE. Para entender-se o aparecimento da tecnologia middleware é descrita a seguir, e, brevemente, a sua evolução.

CAPÍTULO 3 MIDDLEWARE. Para entender-se o aparecimento da tecnologia middleware é descrita a seguir, e, brevemente, a sua evolução. CAPÍTULO 3 MIDDLEWARE Para entender-se o aparecimento da tecnologia middleware é descrita a seguir, e, brevemente, a sua evolução. 3.1 ARQUITETURA CLIENTE/SERVIDOR Primeiramente, surgiu a arquitetura centralizada

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software

UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO. Contribuições do MDA para o desenvolvimento de software UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO Contribuições do MDA para o desenvolvimento de software Anna Carla Mohr Verner Helder Eugenio dos Santos Puia Florianópolis,

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

CORBA Common Object Request Broker Architecture. Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos

CORBA Common Object Request Broker Architecture. Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos CORBA Common Object Request Broker Architecture Carolina de Oliveira Cunha Lenita Martins Ambrosio Victor da Fonseca Santos Introdução OMG (Object Management Group): uma organização formada por empresas

Leia mais

J2EE. J2EE - Surgimento

J2EE. J2EE - Surgimento J2EE Java 2 Enterprise Edition Objetivo: Definir uma plataforma padrão para aplicações distribuídas Simplificar o desenvolvimento de um modelo de aplicações baseadas em componentes J2EE - Surgimento Início:

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

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

Usando Borland DELPHI para implementar aplicações CORBA

Usando Borland DELPHI para implementar aplicações CORBA Página 1 de 10 USANDO BORLAND DELPHI PARA IMPLEMENTAR APLICAÇÕES CORBA por Simone Vey Dutra e César Bridi Introdução A Arquitetura CORBA Criando uma Aplicação CORBA em Delphi Criando um Servidor CORBA

Leia mais

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013

ORDEM DE SERVIÇO OS 003/DINFO/2013 16/09/2013 A DIRETORIA DE INFORMÁTICA DINFO DA UNIVERSIDADE DO ESTADO DO RIO DE JANEIRO -UERJ, no uso de suas atribuições legais, estabelece: Art. 1º: Para fins de normatização do Desenvolvimento Tecnológico na UERJ

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Computação Aula 01-02: Introdução 2o. Semestre / 2014 Prof. Jesus Agenda da Apresentação Definição e surgimento de Sistemas Distribuídos Principais aspectos de Sistemas Distribuídos

Leia mais

3 Propostas de Travessias de Firewalls/NAT

3 Propostas de Travessias de Firewalls/NAT 3 Propostas de Travessias de Firewalls/NAT Este capítulo irá apresentar as propostas deste trabalho para que aplicações que utilizem CORBA como plataforma de comunicação possam atravessar firewalls/nat.

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

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

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

EXPLORE - UMA FERRAMENTA DE SOFTWARE PARA EXPERIMENTAÇÃO PRÁTICA COM TRANSAÇÕES DISTRIBUÍDAS EM SISTEMAS BASEADOS EM COMPONENTES

EXPLORE - UMA FERRAMENTA DE SOFTWARE PARA EXPERIMENTAÇÃO PRÁTICA COM TRANSAÇÕES DISTRIBUÍDAS EM SISTEMAS BASEADOS EM COMPONENTES TRABALHO DE GRADUAÇÃO EXPLORE - UMA FERRAMENTA DE SOFTWARE PARA EXPERIMENTAÇÃO PRÁTICA COM TRANSAÇÕES DISTRIBUÍDAS EM SISTEMAS BASEADOS EM COMPONENTES Aluno: Fábio Ottobeli Machado Orientador: Márcia Pasin

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

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

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

INTEROPERABILIDADE EM SISTEMAS UTILIZANDO WEB SERVICES COMO MIDDLEWARES

INTEROPERABILIDADE EM SISTEMAS UTILIZANDO WEB SERVICES COMO MIDDLEWARES INTEROPERABILIDADE EM SISTEMAS UTILIZANDO WEB SERVICES COMO MIDDLEWARES Bruno B. Boniati 1, Agner Q. Olson 1, Ms. Edson Luiz Padoin 2 2 Departamento de Tecnologia - 1 Curso de Informática: Sistemas de

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

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS

Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Prof. Marcelo de Sá Barbosa SISTEMAS DISTRIBUIDOS Objetos distribuídos e invocação remota Introdução Comunicação entre objetos distribuídos Chamada de procedimento remoto Eventos e notificações Objetos

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

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP

COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP COMPARANDO APLICAÇÃO WEB SERVICE REST E SOAP Cleber de F. Ferreira¹, Roberto Dias Mota¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil cleberferreirasi@hotmail.com, motaroberto@hotmail.com Resumo.

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

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

J2ME PLATAFORMA DE DESENVOLVIMENTO JAVA PARA DISPOSITIVOS MÓVEIS

J2ME PLATAFORMA DE DESENVOLVIMENTO JAVA PARA DISPOSITIVOS MÓVEIS J2ME PLATAFORMA DE DESENVOLVIMENTO JAVA PARA DISPOSITIVOS MÓVEIS Ana Paula Carrion 1, Késsia Rita da Costa Marchi 1, Jaime Willian Dias 1 1 Universidade Paranaense (Unipar) Paranavaí PR Brasil anapaulacarrion@hotmail.com,

Leia mais

Arquiteturas de Aplicações Distribuídas

Arquiteturas de Aplicações Distribuídas Arquiteturas de Aplicações Distribuídas Fernando Albuquerque 061-2733589 fernando@cic.unb.br www.cic.unb.br/docentes/fernando Tópicos Introdução. HTTP / CGI. API sockets. JDBC. Remote Method Invocation.

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

Middleware de Aplicações Paralelas/Distribuídas

Middleware de Aplicações Paralelas/Distribuídas Computação Paralela Middleware de Aplicações Paralelas/Distribuídas João Luís Ferreira Sobral Departamento do Informática Universidade do Minho Outubro 2005 Principais aspectos a gerir pelo Middleware

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

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

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

Sistemas Distribuídos. Introdução. Edeyson Andrade Gomes. www.edeyson.com.br

Sistemas Distribuídos. Introdução. Edeyson Andrade Gomes. www.edeyson.com.br Sistemas Distribuídos Introdução Edeyson Andrade Gomes www.edeyson.com.br SUMÁRIO Definições Características Desafios Vantagens Desvantagens 2 Definições DEFINIÇÕES Um sistema distribuído é uma coleção

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

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

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

Middleware Orientado a Mensagens Visão Geral Comunicação Gerenciamento de Filas Padrões e Produtos 1 Middleware Orientado a Mensagens RPC/RMI é inadequado para comunicação em alguns cenários de aplicação

Leia mais

Ambientes Visuais. Ambientes Visuais

Ambientes Visuais. Ambientes Visuais Ambientes Visuais Inicialmente, apenas especialistas utilizavam os computadores, sendo que os primeiros desenvolvidos ocupavam grandes áreas e tinham um poder de processamento reduzido. Porém, a contínua

Leia mais

Introdução aos Sistemas Distribuídos

Introdução aos Sistemas Distribuídos Material baseado no livro Distributed Systems: Concepts and Design, Edition 3, Addison-Wesley 2001. Introdução aos Sistemas Distribuídos Copyright George Coulouris, Jean Dollimore, Tim Kindberg 2001 email:

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

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

Daniel Berti Fonseca RA 0310096-8º semestre INTEGRAÇÃO DE SISTEMAS CORPORATIVOS COMPLEXOS COM JAVA EE

Daniel Berti Fonseca RA 0310096-8º semestre INTEGRAÇÃO DE SISTEMAS CORPORATIVOS COMPLEXOS COM JAVA EE Daniel Berti Fonseca RA 0310096-8º semestre INTEGRAÇÃO DE SISTEMAS CORPORATIVOS COMPLEXOS COM JAVA EE Jaguariúna 2006 Daniel Berti Fonseca RA 0310096-8º Semestre INTEGRAÇÃO DE SISTEMAS CORPORATIVOS COMPLEXOS

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

Programação Cliente em Sistemas Web

Programação Cliente em Sistemas Web Programação Cliente em Sistemas Web WEBSERVICES Cap 18. - Sistemas distribuídos e serviços web em Deitel, H.M, Sistemas Operacionais, 3 ª edição, Pearson Prentice Hall, 2005 Fonte: Rodrigo Rebouças de

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

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

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

Middleware. Camada Intermediária de Suporte a Sistemas Distribuídos

Middleware. Camada Intermediária de Suporte a Sistemas Distribuídos Middleware Camada Intermediária de Suporte a Sistemas Distribuídos Alternativas de comunicação entre processos (IPC) Mecanismos de IPC tradicionais (ou de baixo nível) Memória compartilhada, filas de mensagens,

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

Java Enterprise Edition. by Antonio Rodrigues Carvalho Neto

Java Enterprise Edition. by Antonio Rodrigues Carvalho Neto Java Enterprise Edition by Antonio Rodrigues Carvalho Neto Enterprise Edition Architecture O que é Java Enterprise Edition? Java EE é uma plataforma que reune diversas especificações relacionadas a computação

Leia mais

Estudo comparativo entre tecnologias Java: Applet e JWS.

Estudo comparativo entre tecnologias Java: Applet e JWS. Estudo comparativo entre tecnologias Java: Applet e JWS. Clara Aben-Athar B. Fernandes¹, Carlos Alberto P. Araújo¹ 1 Centro Universitário Luterano de Santarém Comunidade Evangélica Luterana (CEULS/ULBRA)

Leia mais

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento.

acoplamento Exprime o grau de conexão entre os módulos; os módulos de um software devemapresentar um baixo coeficiente de acoplamento. SOA Arquitetura Orientada a Serviços Conceitos e Aplicações Prof. MSc. Edilberto Silva edilms@yahoo.com/ http://edilms.eti.br Gestão de TI Conceitode SOA SOA - Service OrientedArchitecture (Arquitetura

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

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

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

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

Objetos Distribuídos - Programação Distribuída Orientado a Objetos. Luiz Affonso Guedes

Objetos Distribuídos - Programação Distribuída Orientado a Objetos. Luiz Affonso Guedes Objetos Distribuídos - Programação Distribuída Orientado a Objetos Luiz Affonso Guedes Introdução Conceitos básicos programação distribuída + programação orientada a objetos = Objetos distribuídos Motivação

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

FERRAMENTAS PARA DESENVOLVIMENTO EM C#

FERRAMENTAS PARA DESENVOLVIMENTO EM C# FERRAMENTAS PARA DESENVOLVIMENTO EM C# Camila Sanches Navarro 1,2, Wyllian Fressatti 2 ¹Universidade paranaense (Unipar) Paranavaí PR Brasil sanchesnavarro@gmail.com wyllian@unipar.br Resumo. Este artigo

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

SISTEMA DISTRIBUÍDO COM O PADRÃO DE ARQUITETURA CORBA

SISTEMA DISTRIBUÍDO COM O PADRÃO DE ARQUITETURA CORBA LEONARDO LINCOLN BIANCHETTI SISTEMA DISTRIBUÍDO COM O PADRÃO DE ARQUITETURA CORBA Trabalho de conclusão de curso apresentado ao Curso de Ciência da Computação. UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS Orientador:

Leia mais

Sumário. Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Paradigmas. Objetos Distribuídos. Tecnologias e Motivações

Sumário. Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Paradigmas. Objetos Distribuídos. Tecnologias e Motivações Sumário Sistemas Distribuídos na WEB (Plataformas para Aplicações Distribuídas) Tecnologias e Motivações Paradigmas e Tecnologias para Desenvolvimento de SDs Sistemas Distribuídos x Tecnologia da Informação

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

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

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Este capítulo apresenta trabalhos relacionados ao problema da travessia de firewalls/nat por aplicações CORBA, alguns dos quais tiveram grande influência no desenvolvimento desta

Leia mais

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS

SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS SISTEMA DE AGENDAMENTO E GERENCIAMENTO DE CONSULTAS CLÍNICAS Pablo dos Santos Alves Alexander Roberto Valdameri - Orientador Roteiro da apresentação Introdução Objetivos Motivação Revisão bibliográfica

Leia mais