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 tornar-se a plataforma preferida pela maioria dos desenvolvedores de software. Os projetos de Software passaram a incluir requisitos tais como acesso via WWW a sistemas corporativos legados, desenvolvimento de aplicações tipo cliente/servidor sobre TCP/IP. A difusão dos Sistemas Distribuídos sobre a Internet trouxe consigo a necessidade crescente de comunicação entre ambientes computacionais heterogêneos. Por exemplo, como num sistema envolvendo um determinado fabricante, seus fornecedores, distribuidores e clientes, podendo formar uma rede distribuída de grandes dimensões, envolvendo cidades e, até mesmo, países. Todavia, a comunicação entre sistemas heterogêneos apresenta diversas dificuldades resultantes do fato de que estes não foram originalmente projetados para trabalhar em conjunto, a exemplo da heterogeneidade de sistemas operacionais, protocolos, equipamentos e banco de dados. Diante desse cenário, há uma série de requisitos do ponto de vista de engenharia de software, sem os quais não seria possível uma integração plena dos softwares desenvolvidos de forma independente e em contextos variados (geográficos e computacionais). Conseqüentemente, na Internet, faz-se necessária uma representação uniforme e abstrata de componentes de software que permita a um usuário interagir com tais componentes sem conhecer detalhes de sua implementação e localização. Além disso, os componentes devem ser desenvolvidos de forma a possibilitar que usuários exploram dinamicamente suas estruturas, comportamentos e estados (no caso de componentes já em execução). Essas características são fundamentais para que componentes possam ser modificados depois de disponibilizados na rede global e adaptados para ambientes distintos, criando condições para uma maior produtividade na construção de software distribuído. Há também outros serviços básicos necessários ao desenvolvimento de software distribuído, que devem ser oferecidos, preferencialmente de forma transparente, como segurança (autenticação e controle de acesso) e persistência (a capacidade de um objeto continuar a existir após a finalização da aplicação que o criou ou simplesmente o ativou). Todas essas facilidades e serviços deveriam, idealmente, estar disponíveis através de linguagens de alto nível com mecanismos de coordenação de dados e fluxo de controle, inspeção, adaptação e disponibilização de componentes, e um ambiente de programação e integração com Application Programming Interfaces (APIs) tanto para implementadores de componentes como para desenvolvedores de aplicações (de preferência interfaces gráficas com visualização de estruturas de componentes, com ferramentas para integração de componentes e composição de aplicações). Várias plataformas comerciais e experimentais desenvolvidas, principalmente nos anos noventa, resolvem boa parte desses problemas: Common Object Request Broker Architeture (CORBA), Distributed Component Object Model (DCOM), Remote Method Invalation (JAVA RMI). No entanto, nenhuma dessas infra-estruturas de desenvolvimento e gerenciamento de software distribuído visava primordialmente o ambiente Internet, que é Compilado por Luiz Sergio Rocha de Souza, 5ºA INFO Uninove 1/5

reconhecidamente o grande desafio dos dias atuais. Para atender a essa demanda, nos anos dois mil surgiram os chamados Serviços Web (Web Services) e as arquiteturas de software orientadas a serviço (no caso, serviços Web). Por utilizarem a infra-estrutura já disponível para a WWW (como o protocolo Hyper Text Transfer Protocol - HTTP), amplamente usada para armazenamento e recuperação de páginas Web, e também por incorporarem os conceitos de middlewares distribuídos, como o CORBA, os serviços Web nasceram com o intuito de possibilitar uma integração e disponibilização global das computações distribuídas. Entretanto, sendo uma infra-estrutura global para a implementação de sistemas distribuídos, os Serviços Web por si só não resolvem todos os desafios tecnológicos, necessitando de outras tecnologias complementares para a exploração plena da Computação Distribuída, como, a utilização de computação paralela, o compartilhamento de conteúdos e a colaboração de forma generalizada (denominaremos essas novas tecnologias de tecnologias integradoras). Nesse sentido, nos últimos anos têm aparecido algumas tecnologias integradoras que possibilitam a organização de recursos computacionais (computadores) dispersos na Internet de modo facilitar seu uso de forma transparente por usuários ou softwares na Rede. Dentre essas tecnologias, destacam-se os sistemas peer-to-peer, as grades computacionais (grid computing), os aglomerados (clusters) e os agentes móveis. Diante da enorme tendência de utilização dos serviços Web (como veremos adiante), essas tecnologias integradoras também estão cada vez mais sendo desenvolvidas com base na infra-estrutura disponibilizada pelos serviços Web. No que se segue, inicialmente descrevemos a infraestrutura de serviços Web e, em seguida, abordaremos brevemente essas tecnologias integradoras, seus potencias e desafios. Serviços Web Serviços Web são parecidos com plataformas ou middewares orientados a objetos. Nesses middlewares, objetos estão espalhados em diversos sites e interagem para comporem aplicações distribuídas, que, por sua vez, dispõem de serviços para o acesso remoto por parte de usuários. Localização, registro e comunicação entre os objetos distribuídos são realizadas por um Object Request Broker (ORB). Exemplos de middlewares para objetos distribuídos incluem CORBA da OMG, DCOM da Microsoft e Remote Method Invocation (RMI) da Sun Microsystems. Embora esses middlewares disponham da infra-estrutura básica para a construção de aplicações distribuídas, seu sucesso tem sido limitado por não utilizarem tecnologias amplamente disponíveis na Internet. Por exemplo, na comunicação entre clientes e servidores em CORBA utiliza-se o protocolo Internet Interoperable Protocol, o que impede a comunicação com servidores de corporações protegidas por firewalls. Serviços Web combinam as tecnologias Web e middlewares orientados a objetos numa infra-estrutura onde a interação entre componentes (ou objetos) e usuários é feita através de tecnologias padrões da Web, como o Extensible Markup Language (XML) para representação dos dados e HTTP para comunicação. Dessa forma, um componente de um Serviço Web pode ser demandado por um browser ou por outro componente de outro Serviço Web. Uma vez publicados ou disponibilizados com identificadores universais da Web (Uniform Resource Locators - URLs), os serviços são acessados por protocolos padrões como o HTTP. DCOM Distribuited Component Object Model (DCOM) é um padrão de técnicas para a computação distribuida da Microsoft baseado na tecnologia OLE (Object Linkind Embedding) e uma expansão dos padrões COM (Component Object Model). Compilado por Luiz Sergio Rocha de Souza, 5ºA INFO Uninove 2/5

A tecnologia OLE define um procedimento padronizado em que um módulo cliente e outro servidor podem se comunicar através de uma interface. Esses módulos podem ser executados em um mesmo computador ou em computadores diferentes. Usualmente OLE e COM são usados com o mesmo significado, porem COM é a implementação do OLE. Inicialmente os códigos COM foram escritos através de C e C++, hoje muitas outras linguagem aceitam objetos OLE, tais como Object Pascal(Delphi) e o Visual Basic. Com objetos COM, a aplicação cliente não precisa conhecer onde o objeto reside, simplesmente gera chamadas para interfaces de objetos. Um objeto COM executa os passos necessários para gerar a chamada para localizar o objeto desejado. Quando são utilizados dois arquivos executáveis é utilizado o conceito de marshaling para permitir ao cliente fazer chamadas às funções da interface para objetos remotos em outro processo ou em uma máquina diferente. Os passos para a localização dos objetos diferem, dependendo se o objeto está no mesmo processo no cliente ou em outras máquinas: Servidores in-process: uma DLL (Dynamic Link Library) executando no mesmo espaço da aplicação cliente. Um controle ActiveX embutido em uma página WEB, funciona dessa maneira: o controle ActiveX é baixado para a máquina do cliente e invocado com alguns processos do navegador. O cliente comunica in-process com o servidor usando chamadas da interface COM. Servidores out-of-process: outra aplicação executando em um espaço diferente de processo, mas na mesma máquina do cliente. Uma planilha Excel embutida em um documento do Word; duas aplicações separadas executando na mesma máquina. O servidor local usa a interface COM para comunicar com o cliente. Servidores remotos: uma DLL ou outra aplicação executando em uma máquina diferente do cliente. Um Banco de Dados em Delphi está conectado com uma aplicação servidora em outra máquina da rede. O servidor remoto usa a interface DCOM (Distributed COM) para comunicar com a aplicação servidora. Com o COM é possível a comunicação de aplicativos numa mesma máquina. O DCOM (Distributed Component Object Model) permite que objetos de diferentes computadores possam se comunicar através de protocolos comuns, incluindo protocolos baseados na Internet e na Web. Java RMI O RMI (Remote Method Invocation), da Sun Microsystems é uma plataforma Java que implementa a comunicação entre objetos distribuidos. Podemos sitar como caracteristicas básicas: Orientada a objetos Possui diversas APIs amigáveis Multi-plataforma: Java Virtual Machine (JVM) Integrada à Internet: applets, JavaScript, JSP e Servlets Suporte a componentes: JavaBeans e EJB De fácil aprendizagem Compilado por Luiz Sergio Rocha de Souza, 5ºA INFO Uninove 3/5

Bem aceita pelos programadores Suportada por diversos fabricantes de SW A ferramenta fornece um suporte simples para RPC (Remote Process Calling) e RMI. Permite que um objeto Java chame métodos de outro objeto Java rodando em outro JVM (Java Virtual Machine), apesar deseuas facilidades é uma solução específica para a plataforma Java. A arquitetura da ferramenta é composta de quatro camadas: Stub, Skeleton, camada de referência remota e camada de transporte. Stub Representa o servidor para o cliente. Efetua serialização e envio dos parâmentros. Recebe a resposta do servidor, desserealiza e entrega ao cliente. Skeleton recebe a chamada e dessentraliza os parâmetros enviados pelo cliente. Faz a chamada no servidor e retorna o resultado ao cliente. Camada de referencia remota responsável pela localização dos objetos nas máquinas da rede. Permite que referências para um objeto servidor remoto sejam usadas pelos clientes para chamar métodos Camada de transporte cria e ferencia conexões de rede entre objetos remotos, elimina a necessidade do código do cliente ou do servidor interagirem com o suporte de rede. As chamada RMI tem uma dinâmica próprias representada pelos sequinte passos: 1. O servidor, ao iniciar, se registra no serviço de nomes (RMI Registry ); 2. O cliente obtém uma referência para o objeto servidor no serviço de nomes e cria a stub; 3. O cliente chama o método na stub fazendo uma chamada Local; 4. A stub serializa os parâmetros e transmite a chamada pela rede para o skeleton do servidor; 5. O skeleton do servidor recebe a chamada pela rede, desserializa os parâmetros e faz a chamada do método no objeto servidor; 6. O objeto servidor executa o método e retorna um valor para o skeleton, que o desserializa e o envia pela rede à stub do cliente; 7. A stub recebe o valor do retorno serializado, o desserializa e por fim o repassa ao cliente. CORBA CORBA (Common Object Request Broker Architecture) é a arquitetura padrão criada pelo Object Management Group para estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogêneos. Em face da diversidade de hardware e software que encontramos atualmente, a CORBA atua de modo que os objetos (componentes dos softwares) possam se comunicar de forma transparente ao usuário, mesmo que para isso seja necessário interoperar com outro software, em outro sistema operacional e em outra ferramenta de desenvolvimento. CORBA é um dos modelos mais populares de objetos distribuídos, juntamente com o DCOM, formato proprietário da Microsoft. A arquitetura CORBA define o ORB (Object Request Broker) como um módulo intermediário entre cliente e objeto, sendo responsável em aceitar a requisição do Compilado por Luiz Sergio Rocha de Souza, 5ºA INFO Uninove 4/5

cliente, enviá-la para o objeto competente e, assim que disponível a resposta, entregá-la para o cliente. A CORBA utiliza a IDL (Interface Definition Language), uma linguagem baseada em C++ que não possui algoritmos nem variáveis, ou seja, é puramente declarativa, e, portanto, é independente da linguagem de programação utilizada para acessá-la. Há padrão de IDL definido pelo OMG para C, C++, Java, TTCN, COBOL, Smalltalk, Ada, Lisp, Python e IDLscript. Possibilita a interoperabilidade entre os diversos sistemas, visto a separação que é definida entre interface e execução. A interface de cada objeto é definida de forma bastante específica, enquanto sua execução (código fonte e dados) permanece oculta para o resto do sistema. Ao contrário dos objetos tradicionais, os objetos em sistemas distribuídos possuem uma característica de dualidade: um estado dinâmico, tipicamente alocado em memória volátil (em tempo de execução), e um estado persistente, que não pode ser destruído após o encerramento do programa que os criou e que pode ser usado para reconstruir o estado dinâmico, devendo ser armazenado em memória não volátil, seja em sistema de arquivos ou banco de dados. A arquitetura CORBA, para prover a persistência, define o Persistent Object Service (POS) como sendo responsável por armazenar o estado persistente dos objetos, utilizando quatro elementos: Objetos Persistentes (Persistent Object (POs)) Gerenciador de Objetos Persistentes (Persistent Objects Manager (POM)) Serviços de Persistência de Dados (Persistent Data Services (PDSs)) Base de Dados (Datastores) GLOSSÁRIO Middleware: neologismo criado para designar camadas de software que não constituem diretamente aplicações, mas que facilitam o uso de ambientes ricos em tecnologia da informação. A camada de middleware concentra serviços como identificação, autenticação, autorização, diretórios, certificados digitais e outras ferramentas para segurança. Aplicações tradicionais implementam vários destes serviços, tratados de forma independente por cada uma delas. As aplicações modernas, no entanto, delegam e centralizam estes serviços na camada de middleware. Ou seja, o middleware serve como elemento que aglutina e dá coerência a um conjunto de aplicações e ambientes. Sistema legado: termo utilizado em referência aos sistemas computacionais de uma organização que, apesar de serem bastante antigos, fornecem serviços essenciais. Geralmente utilizam bancos de dados obsoletos. Normalmente são aplicações complexas, de difícil manutenção e que pelo grau de criticidade e custo para modernização, continuam ativas. Fontes: RPN, Middleware. http://www.rnp.br/noticias/2006/not-060926.html, acessado em 5 de junho de 2009 SERRA, A. P. G. O modelo de arquitetura CORBA e suas aplicações. Revista Integração. Jun2004 ftp://ftp.usjt.br/pub/revint/157_37.pdf SILBERSCHATZ, A; Galvin, P; Gagne, G. Sistemas Operacionais. Rio de Janeiro:Campus, 2000. Compilado por Luiz Sergio Rocha de Souza, 5ºA INFO Uninove 5/5