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 tenalcostapaiva@esaex.mil.br mrmarcondes@hotmail.com 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.