Sistemas Distribuídos e Paralelos

Transcrição

1 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 e Paralelos November 19, / 53

2 Outline 1 Introdução 2 Objectos distribuídos 3 Dos objectos aos componentes 4 Caso de estudo: Enterprise JavaBeans Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

3 Introdução Uma solução de middleware completa deve apresentar uma abstracção tanto ao nível de programação de alto-nível, como ao nível do sistema distribuído. Neste capítulo vamos abordar duas das mais importantes abstracções na programação, nomeadamente: Objectos distribuídos Componentes distribuídos Para além da análise teórica, vamos ainda abordar um caso prático: Enterprise JavaBeans Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

4 Introdução Middleware de objectos distribuídos A característica chave dos objectos distribuídos é que permitem adoptar um modelo de programação totalmente orientado aos objectos, escondendo toda a complexidade dos sistemas distribuídos. Neste panorama as entidades são representadas por objectos. Os objectos comunicam maioritariamente utilizando o método de invocação remota de métodos. Porém, outros métodos como eventos distribuídos são também utilizados. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

5 Introdução Middleware de objectos distribuídos Esta abordagem simplista apresenta um conjunto de benefícios: O encapsulamento herdado das soluções baseadas em objectos é uma mais valia nos sistemas distribuídos. A abstracção de dados permite separar completamente o uso do objecto da sua implementação, permitindo que os programadores preocupem-se simplesmente em invocar os métodos fornecidos, ignorando totalmente os detalhes de implementação. Esta abordagem permite assim soluções dinâmicas e extensíveis, introduzindo, por exemplo, novos objectos ou substituir objectos por outros. Exemplo de soluções: Java RMI e CORBA. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

6 Introdução Middleware de componentes distribuídos As soluções baseadas em componentes têm sido desenvolvidas para resolver uma série de limitações que têm vindo a ser detectadas nos sistemas baseados em objectos distribuídos, nomeadamente: Dependências implícitas: As interfaces dos objectos não descrevem as dependências da implementação do objecto, tornando os sistemas baseados em objectos difíceis de desenvolver e gerir, principalmente para os third-party. Complexidade de programação: A programação de objectos distribuídos leva à necessidade de dominar vários detalhes de baixo nível associados com a implementação do middleware. Falha na separação dos detalhes da distribuições: Os programadores têm o dever de considerar detalhes como segurança, gestão de falhas e concorrência, o que não conseguem se não tiverem conhecimento da distribuição do sistema. Sem suporte de instalação: Os middlewares orientados a objectos fornecem pouca ou nenhuma informação sobre a instalação e configuração dos objectos. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

7 Outline 1 Introdução 2 Objectos distribuídos 3 Dos objectos aos componentes 4 Caso de estudo: Enterprise JavaBeans Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

8 Objectos distribuídos Os middleware orientados a objectos são desenhados para fornecer o nível de programação orientada a objectos e, como tal, trazer os benefícios da mesma para a programação distribuída. Os programadores deste tipo de sistemas têm ao seu dispor não só uma abstracção mais rica, mas também os princípios da orientação a objectos, ferramentas e técnicas, tais como UML. Por exemplo, o CORBA OMG incluí suporte para a norma UML. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

9 Objectos distribuídos Os objectos distribuídos fornecem uma abstração baseada nos princípios orientados a objectos. Os principais exemplos de middlewares que seguem esta lógica são o Java RMI, analisado anteriormente, e o CORBA.. Apesar de ambas as soluções partilharem bastante em comum, existe uma diferença importante: O uso de Java RMI está limitado à linguagem Java, enquanto que o CORBA é uma solução multi-linguagem permitindo objectos escritos numa variedade de linguagens interoperarem. (Ex: C++, Python, Java, etc...). Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

10 Objectos distribuídos Diferenças entre objectos e objectos distribuídos Objectos Objectos Distribuídos Referências Referências para objectos para objectos remotos. Interfaces Interface remotas. Acções Acções distribuídas. Excepções col- Garbage lection remoto (uso de IDL). Iniciadas pela invocação de um método, resultando possivelmente numa cadeia de invocações. Excepções distribuídas. Garbage collection distribuído. Descrição dos objectos distribuídos As referências para objectos remotos são únicas e globais, podendo ser passadas por parâmetro. Fornecem uma especificação abstracta dos métodos que podem ser invocados no objecto Excepções adicionais geradas pela natureza distribuída do sistema, incluinda mensagens perdidas ou falhas nos processos. Garante que um objecto continua a existir desde que uma referência ou uma referência remota para o objecto exista.requer um algoritmo de garbage collection distribuído. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

11 Objectos distribuídos Complexidade acrescida Para além das diferenças entre objectos e objectos distribuídos, os SD adicionam um nível de complexidade superior, nomedamente: Comunicação entre objectos: Um middleware de objectos distribuídos deve oferecer um ou mais mecanismos para que os objectos comuniquem no ambiente distribuído. Estes mecanismos são normalmente implementados via invocação remota, mas existem outras técnicas, por exemplo, baseadas na comunicação indirecta, que também são utilizadas. CORBA fornece um sistema de eventos e notificações implementados como serviços no topo do middleware. Gestão do tempo de vida: A gestão do tempo de vida aborda a criação, migração e eliminação de objectos, com cada etapa a ter de lidar com a questão distribuída. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

12 Objectos distribuídos Complexidade acrescida (continuação) Activação e desactivação: Num sistema não distribuído é assumido que os objectos estão activos durante todo o tempo de execução. Num sistema distribuído isto não pode ser assumido, uma vez que o número de objectos pode ser muito vasto, o que seria um desperdício de recrusos garantir a disponibilidade de todos simultaneamente. Para além disso, os nós "donos" dos objectos podem eles próprios não estarem disponíveis. Persistência: Os objectos tipicamente têm um estado que é importante manter independentemente dos ciclos de activação e desactivação ou mesmo de falhas do sistema. Como tal, os middleware orientados a objectos distribuídos devem oferecer gestão de persistência para o estado dos objectos. Seviços adicionais: Uma framework deste género deve ainda suportar uma série de serviços considerados importantes no âmbito dos sistemas distribuídos, tais como serviço de nomes, segurança e tolerância a falhas. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

13 Outline 1 Introdução 2 Objectos distribuídos 3 Dos objectos aos componentes 4 Caso de estudo: Enterprise JavaBeans Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

14 Dos objectos aos componentes Introdução Os middleware baseados em objectos distribuídos têm sido largamente utilizados nos mais variados cenários, incluindo os abordados no 1 o capítulo: finanças, banca, jogos, saúde, educação, etc... As técnicas incorporadas no CORBA e plataformas similares, provaram a sua eficiência em resolver pontos chave dos sistemas distribuídos: heterogeneidade, portabilidade, interoperabilidade dos softwares, segurança e fiabilidade. No entanto, uma série de questões têm surgido, o que levou ao desenvolvimento do que se conhece por abordagens baseadas em componentes. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

15 Dos objectos aos componentes Problemas nos middlewares orientados a objectos As abordagens baseadas em componentes surgiram de modo a resolver os problemas nas abordagens orientadas a objectos, nomeadamente: Dependências implícitas Como sabemos, os objectos distribuídos fornecem os seus métodos via interfaces, que abstraem completamente a implementação. Ao invocar cada método remoto, não existe conhecimento sobre o código que é executado e se esse código recorre ele próprio a outras chamadas remotas,ou seja, se tem dependências externas, sejam de serviços de nomes, controlo de concorrência, etc. Ao desconhecer estes detalhes, torna-se impossível garantir uma configuração segura do sistema como um todo, substituir um objecto por outro, ou ainda integrar com desenvolvimentos e terceiros. Requisito. Daqui existe um claro requisito no que toca não só à especificação das interfaces oferecidas por um objectos, mas também das dependências que esse objecto tem de outros objectos numa configuração distribuída. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

16 Dos objectos aos componentes Problemas nos middlewares orientados a objectos (continuação) Interacção com o middleware As plataformas de middleware baseadas em objectos, estão implementadas de uma forma que utilizam inúmeros processos de baixo nível que garantem a operação e manutenção do middleware ao longo do seu tempo de vida, como por exemplo, código para criar e gerir as referências de objectos, para gerir os ciclos de vida dos objectos, as políticas de acesso, etc.. Requisito Existe a necessidade clara de simplificar a programação das aplicações distribuídas, apresentando uma separação limpa entre código da aplicação (lógica de negócio) e código de gestão do middleware. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

17 Dos objectos aos componentes Problemas nos middlewares orientados a objectos (continuação) Falha na separação das preocupações da distribuição Quando se programa para sistemas distribuídos temos de nos preocupar não só com as questões funcionais da aplicação, mas também com questões não funcionais, tais como segurança, transacções, coordenação e replicação. Nas abordagens por objectos, estes pontos são alcançados com a inserção das chamadas apropriadas para cada serviço do sistema. Este método obriga a que os programadores conheçam muito bem os detalhes dos serviços e ferramentas disponíveis, aumentando a complexidade da programação distribuída. Requisito: A separação abordada no ponto anterior deve ser estendida aos serviços, abstraindo, sempre que possível, a complexidade em lidar com estes. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

18 Dos objectos aos componentes Problemas nos middlewares orientados a objectos (continuação) Sem suporte de implantação Apesar dos middlewares orientados a objectos, como CORBA ou RMI, possibilitarem configurações arbitrárias de objectos, não existe qualquer suporte na implantação dos mesmos, tendo esse passo que ser manualmente realizado. Esta questão torna-se critica quando o número de objectos envolvidos é grande, levando facilmente a que ocorram erros básicos. Requisito: As plataformas de middleware devem fornecer ferramentas que permitam a implantação do sistema distribuído, de forma fácil e transparente, tal como se de uma aplicação local se tratasse. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

19 Dos objectos aos componentes Problemas nos middlewares orientados a objectos (continuação) Com base nos quatro problemas apontados nos slides anteriores, surgiu o conceito de abordagens baseadas em componentes e, como resultado, middlewares baseados em componentes. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

20 Dos objectos aos componentes Componente Definição: Um componente de software é uma unidade de composição com interfaces contractualmente especificadas, com todas as dependências de contexto explicitas. Os componentes de software são como os objectos, na perspectiva em que ambos encapsulam unidades de composição. No entanto, os componentes especificam explicitamente, para além das interfaces, as suas dependências para com outros componentes, ao contrário dos objectos. As dependências são também representadas como interfaces. Um componente é especificado em forma de contrato, incluindo: um conjunto de interfaces fornecidas - as interfaces que o componente oferece como serviços aos outros componentes. um conjunto de interfaces requeridas - as dependências que este componente tem em relação aos outros componentes. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

21 Dos objectos aos componentes Componente Exemplo TinyOS - Arquitectura do Software Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

22 Dos objectos aos componentes Componente As interfaces podem ser de vários tipos. No geral, as abordagens baseadas em componentes oferecem dois estilos de interfaces, nomeadamente: interfaces com suporte para invocação remota de métodos, tal como CORBA e Java RMI. interfaces com suporte para eventos distribuídos. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

23 Dos objectos aos componentes Componente A programação de sistemas baseados em componentes assenta sobre o desenvolvimento de componentes e a sua composição. O objectivos é suportar um estilo de programação totalmente modular, permitindo conjugar diferentes componentes, de diferentes modos, desenvolvendo serviços mais sofisticados. Migrar do desenvolvimento de software para o assemblamento de software Com este estilo de desenvolvimento e estruturação de software, torna-se mais simples: a disponibilização/integração de/com código de terceiros. adaptar a configuração de sistemas em runtime, substituindo módulos, desde que disponham das mesmas interfaces. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

24 Dos objectos aos componentes Componentes e sistemas distribuídos Uma série de middlewares baseados em componentes têm surgido, sendo os mais populares o Enterprise JavaBeans (que vamos analisar mais à frente) e o CORBA Component Model (CCM). Estes sistemas não só suportam os conceitos abordados anteriormente, como também introduzem suporte para o desenvolvimento de sistemas distribuídos e respectiva implantação. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

25 Dos objectos aos componentes Componentes e sistemas distribuídos Container O conceito de containers é totalmente central nos middleware baseados em componentes. Os containers suportam um padrão comum, frequentemente encontrado neste tipo de middleware, que consiste em: um cliente front-end; um ou mais componentes que implementam a aplicação ou a lógica do negócio; um conjunto de serviços responsáveis pela gestão dos dados nas bases de dados persistentes. Assim, a função do container é a de fornecer um ambiente de gestão de componentes do lado do servidor, resolvendo um dos problemas das soluções orientadas a objectos, com os componentes a lidarem com as questões da aplicação e o container a lidar com as questões do sistema distribuído, do middleware e com todos os processos não-funcionais. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

26 Dos objectos aos componentes Componentes e sistemas distribuídos Container O container encapsula vários componentes. O acesso directo aos componentes é vedado, sendo que as invocações são interceptadas e processadas garantindo que as devidas propriedades do SD são mantidas. Middlewares com suporte de containers são conhecidos como Servidores Aplicacionais Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

27 Dos objectos aos componentes Suporte para implantação Os middleware baseados em componentes fornecem suporte para a configuração da implantação (deployment) dos componentes. As releases de software são empacotadas como arquitecturas de software, ou seja, incluindo os componentes e as suas inter-ligações, juntamente com a descrição da implantação, que define detalhadamente como a configuração deve ser implantada no ambiente distribuído. Note-se que os componentes são implantados nos containers, sendo estes responsáveis por interpretar os descritores da implantação, de modo a garantir as políticas requeridas pelo sistema (segurança, fiabilidade, etc.). Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

28 Dos objectos aos componentes Suporte para implantação Deste modo, um determinado container incluí um conjunto de componentes que requerem a mesma configuração em termos de sistema distribuído. Os descriptores de implantação são normalmente definidos em XML e incluem informação suficiente para garantir que: os componentes estão correctamente ligados utilizando os protocolos apropriados e com o devido suporte do middleware. o middleware é configurado para garantir determinado nível de suporte à configuração do componente. o sistema distribuído associado é configurado para fornecer determinado nível de segurança, suporte de transacções, fiabilidade, etc. Os middleware fornecem ainda ferramentas para interpretar os descriptores de implantação e garantir a correcta implantação numa determinada arquitectura física. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

29 Outline 1 Introdução 2 Objectos distribuídos 3 Dos objectos aos componentes 4 Caso de estudo: Enterprise JavaBeans Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

30 Caso de estudo: Enterprise JavaBeans Os desafios em desenvolver aplicações corporativas As aplicações corporativas apresentam diversos desafios, tais como portabilidade, reutilização, interoperabilidade e integração aplicacional. Desde a sua génese, o Java tinha tido, maioritariamente, maior foco nas aplicações cliente, não apostando na resolução dos problemas do lado do servidor. O desafio era então desenvolver aplicações servidor capazes de responder aos requisitos das corporações. Para isso era necessário o desenho de componentes pequenos e transparentes na localização que, operando em conjunto, respondessem aos requisitos. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

31 Caso de estudo: Enterprise JavaBeans Os desafios em desenvolver aplicações corporativas A computação empresarial está em constante mudança, tanto em termos de hardware como de software. Novas aplicações são constantemente requisitadas, garantindo, no entanto, interoperabilidade com os sistemas antigos. Não é viável deitar todo o esforço e dinheiro gasto no desenvolvimento de software que com os anos torna-se legacy, substituindo todo o sistema. É por isso importante desenvolver novos módulos possíveis de integrar nas aplicações já existentes, mesmo que desenvolvidas em linguagens de programação antigas. Hoje em dia, os software de servidor permitem que uma corporação repense a sua infraestrutura, não só para as necessidades actuais, mas também para a capacidade de crescimento e integração de novas funcionalidades. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

32 Caso de estudo: Enterprise JavaBeans Os desafios em desenvolver aplicações corporativas As aplicações corporativas são complexas e em muitos casos estão distribuídas por múltiplos domínios. As aplicações dos dias de hoje requerem tempos de resposta cada vez mais rápidos para preencher os requisitos dos utilizadores. Para além disso, a interoperabilidade com outros ambientes (hardware, software e rede) é cada vez mais importante nos ambientes corporativos e, como tal, um enorme desafio. Nesse âmbito, as arquitecturas de sistemas corporativos têm sofrido uma evolução bastante grande, que se iniciou com a arquitectura cliente-servidor (two-tier), seguindo para uma arquitectura three-tier e mais tarde web-based. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

33 Caso de estudo: Enterprise JavaBeans Introdução A arquitectura JEE (Java Enterprise Edition) é um conjunto de especificações, standards, frameworks e guias que fornecem capacidades Java nos servidores corporativos. O Enterprise JavaBeans (EJB) é o coração da arquitectura JEE. As restantes APIs são utilizadas como serviços pela API EJB. Existem inúmeras implementações de JEE, tais como o BEA s WebLogic Server, IBM s WebSphere ou o JBoss (open source). JEE oferece aplicações corporativas com alto nível de abstracção. Não oferece somente portabilidade das aplicações-servidor baseadas em componentes, como também oferece um conjunto de serviços que suportam todos os aspectos da infraestrutura. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

34 Caso de estudo: Enterprise JavaBeans Porquê EJB? A arquitectura EJB permite que as aplicações corporativas sejam portáveis ao correrem em servidores aplicacionais compatíveis com JEE. As aplicações EJB podem ser particionadas de um modo mais reutilizável, flexível e expansível. Os EJBs são componentes altamente reutilizáveis e representam a próxima geração no progresso do Java, permitindo desenvolver aplicações capazes de suportar aplicações corporativas críticas.. Os EJBs permitem assim que o desenvolvimento da lógica de negócio seja transversal a todas as aplicações corporativas e entre diferentes plataformas. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

35 Caso de estudo: Enterprise JavaBeans Porquê EJB? O modelo EJB é baseado em Java RMI, que permite a separação da execução de componentes entre múltiplos tiers. Esta separação permite maior flexibilidade na implementação e alta escalabilidade. O RMI permite o acesso a componentes remotos, como se estes fossem locais. Para além disso, a inclusão na infraestrutura de um service provider permite gerir e oferecer uma série de serviços aos EJBs implantados. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

36 Caso de estudo: Enterprise JavaBeans Porquê EJB? - Resumo Simplicidade Oferece uma série de serviços já pré-adicionados que facilitam no desenvolvimento das aplicações. Portabilidade Aplicações EJB podem ser instaladas em qualquer servidor que suporte JEE. Reutilização O EJB é construído em blocos altamente reutilizáveis. Particionamento A separação da lógica de negócio da sua apresentação permite que as equipas de desenvolvimento de negócio trabalhem independentes das equipas de front-end. Distribuição EJB permite facilmente criar aplicações distribuídas que, independentemente do número de servidores, parecem unificadas aos olhos dos utilizadores. Interoperabilidade A arquitectura EJB permite que os componentes EJB acedam a outros componentes desenvolvidos noutras linguagems, tais como CORBA ou.net. Integração Um dos objectivos do EJB foi facilitar a integração de aplicações, mesmo com sistemas legacy e non- Java. As especificações JCA (Java Connecter Architecrure) e JMS (Java Message Service) são utilizadas nesse sentido. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

37 Caso de estudo: Enterprise JavaBeans EJB Objectivos A arquitectura EJB foi desenvolvida com os seguintes objectivos: Ser o standard das arquitecturas baseadas em componentes para o desenvolvimento dos sistemas distribuídos orientados a objectos nas aplicações Java. Tornar mais fácil o desenvolvimento das aplicações corporativas, evitando a necessidade de conhecer transacções de baixo nível e detalhes de gestão de estados, multi-threading, pools de ligações e outras APIs de baixo-nível. Permitir que um EJB seja desenvolvido como um só, mas implantado em múltiplas plataformas sem necessidade de recompilação ou modificação de código. Para endereçar o desenvolvimento, implantação e aspectos de execução do tempo de vida das aplicações corporativas. Para ser compatível com plataformas servidor existentes e com outras APIs Java. Para fornecer interoperabilidade entre EJBs, componentes JEE e aplicações não-java. Para ser compatível com os protocolos CORBA. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

38 Caso de estudo: Enterprise JavaBeans Dentro do EJB Geralmente um EJB é constituído por duas interfaces e uma classe: as interfaces home e component e a classe bean. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

39 Caso de estudo: Enterprise JavaBeans Dentro do EJB A interface home lista os métodos para criar, remover e encontrar EJBs no container. O objecto home representa a implementação do objecto home que é gerado pelo container no momento da implantação. Durante a execução o objecto home vai ser utilizado pelo cliente em conjunto com um serviço de nomes para encontrar o componente e estabelecer a ligação à interface do seu componente. A interface do componente define os métodos do negócio oferecidos pela classe bean. A classe bean não implementa esta interface, mas utiliza uma classe EJBObject que faz a ligação entre as chamadas do cliente e o respectivo objecto bean. O container contem a implementação desta interface e o cliente utiliza-a. A interface componente pode tanto ser local como remota, dependendo da localização do EJB cliente relativamente ao EJB. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

40 Caso de estudo: Enterprise JavaBeans Dentro do EJB O cliente EJB localiza os containers EJB através do serviço JNDI (Java Naming and Directory Interface). Depois do cliente EJB localizar a referência para a interface home do EJB, pode requerer a interface componente, invocar um método do negócio e o container, por sua vez, invocar o respectivo bean. Os clientes EJB podem ser servlets, JSPs ou simples aplicações Java. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

41 Caso de estudo: Enterprise JavaBeans EJB Server - JEE Application Server Um EJB Server ou JEE Application Server é o container de topo que aglomera todos os containers e restantes elementos que compõem o ambiente EJB. O EJB Server gere um ou mais EJB containers e fornece o suporte a serviços requeridos, tais como gestão de transacções, persistência e acesso de clientes. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

42 Caso de estudo: Enterprise JavaBeans EJB Server - JEE Application Server Um EJB Server fornece ainda recursos operacionais, tais como, processos e execução de threads, memória, rede, gestão de recursos, pooling de ligações, caching, load balancing, fail-over, etc., aos containers e elementos nele inseridos. O EJB Server pode fornecer ainda funcionalidades especificas de vendedores, tais como, drivers de BD optimizados, interfaces para sistemas de backend e acessibilidade CORBA. Ex.: BEA s WebLogic Server, IBM s WebSphere ou o JBoss (open source). Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

43 Caso de estudo: Enterprise JavaBeans EJB Container - Serviços essenciais Todos os EJB correm dentro de um container, que lhes fornece uma série de serviços de sistema e controla os seus ciclos de vida. Uma vez que o container gere todas as questões ao nível do sistema, os programadores EJB só têm de se preocupar em desenvolver devidamente a lógica de negócio. Em geral os containers JEE definem três tipos principais de serviços, nomeadamente: serviços verticais comuns, serviços horizontais comuns e ferramentas de implantação comuns. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

44 Caso de estudo: Enterprise JavaBeans EJB Container - Serviços verticais comuns Estes serviços são herdados dos containers e não são especificados na API JEE. Contribuem para a performance e aspectos de runtime dos EJBs e dos serviços a estes prestados. Gestão do ciclo de vida Segurança RMI Gestão de transacções O container cria e destrói instâncias de bens com base nos requisitos dos clientes. O container pode multiplexar transparentemente uma pool de instâncias entre vários clientes e assim optimizar os recursos. Este serviço garante que apenas utilizadores autorizados acedem aos recursos. O JEE só fornece uma método simples de segurança para os beans e componentes web, sendo que na maioria das vezes são integradas soluções third-party, como LDAP. O container gere a comunicação de modo transparente entre os beans e os outros componentes. Assim, não é necessário implementar sockets, mensagens, empacotar, desempacotar ou outras questões de baixo nível. O programador somente implementa o negócio e ignora a comunicação. O serviço de transacções liberta o programador da preocupação em lidar com transacções complexas, que podem ocorrer em múltiplos beans ou recursos, tais como bases de dados. Assim, se um update ou delete falhar num os elementos, este serviços é responsável por fazer rollback e garantir a integridade dos dados no sistema. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53

45 Caso de estudo: Enterprise JavaBeans EJB Container - Serviços verticais comuns (continuação) Persistência O serviço de persistência simplifica a ligação entre a aplicação e os tiers de bases de dados. Passivação/Activação Este mecanismo é utilizado pelo container para guardar um bean inactivo no disco e restaura-lo para memória quando invocado. Deste modo é possível servir mais clientes libertando recursos, tais como memória, dinamicamente. Clustering Permite a replicação de EJBs e serviços por múltiplas aplicações servidor, instaladas na mesma máquina ou em máquinas distintas. Clustering envolve o balanceamento de carga de pedidos de serviços e EJBs entre as instâncias replicadas. Para além, disso suporte fail-over. Se uma instância falha, a outra assegura o serviço. Pooling de recursos dos clientes. Quando um instância é libertada, esta volta novamente Suporta a alocação de pools de instâncias, que atribuí aos pedidos para a pool. Existem pools, por exemplo, para as ligações JDBC. Ricardo Mendão Silva (UAL) Sistemas Distribuídos e Paralelos November 19, / 53