Objetos e Componentes Distribuídos: EJB e CORBA

Transcrição

1 : EJB e CORBA 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

2 Objetivos Nesta aula iremos apresentar a solução baseada em middleware para programação em um ambiente distribuído usando componentes.

3 Plano de Aula Objetos e Componentes Distribuídos: EJB Arquitetura CORBA De Objetos a Componentes Essência dos Componentes Componentes e Sistemas Distribuídos Enterprise JavaBeans Modelo de Componentes EJB POJOs e anotações Contêineres EJB

4 Arquitetura CORBA

5 Arquitetura CORBA Projetada para suportar a função do ORB agente de requisição de objeto; O ORB permite aos clientes invocar métodos em objetos remotos; Essa invocação ocorre em um contexto em que clientes e servidores podem ser implementados em uma variedade de linguagens de programação; Importante: O CORBA fornece invocações estáticas e dinâmicas: Estáticas: quando a interface remota do objeto CORBA é conhecida no momento da compilação (mais utilizada); Dinâmicas: caso contrário.

6 Arquitetura CORBA Núcleo ORB Responsável por todo o processo de comunicação entre clientes e servidores; O Núcleo ORB fornece ainda: Operações que o permitem ser iniciado e parado; Operações para fazer a conversão entre referências de objeto remoto e strings; Operações para fornecer listas de argumentos para requisições usando invocação dinâmica;

7 Arquitetura CORBA Adaptador de Objeto Faz a ligação entre objetos CORBA com interfaces IDL e as interfaces da linguagem de programação das classes serventes correspondentes; Suas tarefas: Criar referências de objetos remoto para objetos CORBA; Enviar cada RMI, por meio de um esqueleto, para o servente apropriado; Ativa e desativa serventes; Um adaptador de objeto fornece para cada objeto CORBA um nome de objeto exclusivo; Cada objeto CORBA é registrado em seu adaptador de objetos, o qual mantém uma tabela de objetos remotos;

8 Arquitetura CORBA Esqueleto As classes de esqueleto são geradas na linguagem de programação do servidor por um compilador de IDL; Assim como no RMI JAVA, ele faz: Envia as invocações remotas a serventes apropriados; Desempacota os argumentos nas mensagens de requisição; Empacota as exceções e os resultados nas mensagens de resposta; Stub/proxies de cliente São escritos na linguagem do cliente; As classes de um proxy (para LP O. O) ou um conjunto de procedimentos stub (para LP procedurais) é gerada a partir de uma interface IDL por um compilador de IDL; O que ele faz: Empacota e desempacota, assim como o Esqueleto.

9 Arquitetura CORBA Repositório de Implementações É responsável por ativar servidores registrados sob demanda e por localizar servidores em execução; Armazena um mapeamento dos nomes de adaptadores de objeto para nomes de caminho de arquivos contendo implementações de objeto; As implementações e os adaptadores de objetos são registrados nos repositórios de implementações quando os programas servidores são instalados; Quando as implementações de objeto são ativadas nos servidores, o nome do computador (hostname) e o número da porta são adicionados;

10 Arquitetura CORBA Repositório de Interfaces É responsável por fornecer informações sobre as interfaces IDL registradas para clientes e servidores que as exigirem; Usado por exemplo quando um cliente recebe uma referência remota de um objeto para o qual ele não possui o proxy; Usado em invocações dinâmicas; Nem todos os ORBs fornecem repositórios de interfaces;

11 Arquitetura CORBA

12 Serviços CORBA O CORBA inclui especificação de serviços que podem ser exigidos por objetos distribuídos; O Serviço de Nomes é uma adição essencial em qualquer ORB; Alguns outros serviços: Serviço de negócio: funciona como um Trading Service, permitindo localizar objetos pelos atributos; Serviço de eventos: permite que objetos transmitam notificações para assinantes; Serviços de Segurança: suporta vários serviços de segurança como autenticação, controle de acesso, comunicação segura, etc;

13 De Objetos a Componentes O CORBA tem um papel fundamental na história dos Sistemas Distribuídos; Ele apresentou uma solução viável para os principais problemas na programação de Sistemas Distribuídos: Heterogeneidade; Portabilidade e operação conjunta de software de sistemas distribuídos; A definição de vários Serviços CORBA também foi fundamental (segurança, confiabilidade, etc); Porém apontamos alguns problemas enfrentados pelo desenvolvedor ao usar o CORBA;

14 De Objetos a Componentes Problemas do Middleware Orientado a Objetos Dependências Implícitas Requisito: Há necessidade clara de não apenas especificar as interfaces oferecidas por um objeto, mas também as dependências desse objeto com relação a outros na configuração distribuída. Interação com o Middleware Requisito: Há uma necessidade evidente de simplificar a programação de aplicações distribuídas para apresentar uma clara separação de preocupações entre código relacionado à operação em uma estrutura de middleware e código associado a aplicação, e de permitir que o programador se concentre exclusivamente neste último. Falta de separação de aspectos relacionados à distribuição Requisito: A separação de aspectos mencionados anteriormente também devem abranger o tratamento dos diversos serviços do sistema distribuído e, quando possível, as complexidades do tratamento de tais serviços devem ficar ocultas do programador. Falta de suporte para distribuição Requisito: As plataformas de middleware devem fornecer suporte intrínseco para a distribuição, para que o software distribuído possa ser instalado e implantado da mesma maneira que um software para uma máquina, com as complexidade de distribuição ocultas ao usuário. Objetos e Componentes Distribuídos

15 De Objetos a Componentes Esses quatro requisitos levam ao surgimento de estratégias baseadas em componentes para o desenvolvimento de sistemas distribuídos, junto ao surgimento de middleware baseado em componentes, incluindo o estilo de middleware chamado de servidores de aplicação.

16 Essência dos Componentes Definição de componentes segundo Szyperki: Um componente de software é uma unidade de composição com interfaces especificadas por contratos e somente dependências contextuais explícitas. Importante: Toda dependência contextual deve ser explícita; As dependências também são representadas como interfaces; Um componente de software é especificado em termos de um contrato, o qual inclui: Um conjunto de interfaces fornecidas As interfaces que o componente oferece como serviços para outros componentes; Um conjunto de interfaces exigidas As dependências que esse componente tem em termos de outros componentes que devem estar presentes e conectados a ele para que ele funcione corretamente.

17 Componentes e Sistemas Distribuídos Diversas tecnologias baseadas em componentes vem surgindo: Enterprise JavaBeans CCM (CORBA Component Model) O Middleware baseado em componentes adiciona suporte significativo para o desenvolvimento e implementação de sistemas distribuídos; Na visão dos middlewares baseados em componentes dois pontos são fundamentais: O conceito de Contêineres (fundamental para Middlewares baseados em Componentes) Suporte para a distribuição.

18 Contêineres Os contêineres suportam um padrão comum, geralmente encontrado em aplicações distribuídas: Um cliente front-end (frequentemente web) Um contêiner contendo um ou mais componentes que implementam a lógica de negócio/aplicação; Serviços de sistema que gerenciam os dados associados no armazenamento persistente. As tarefas de um contêiner são: Fornecer um ambiente hospedeiro no lado do servidor gerenciado para os componentes; Fornecer a separação de aspectos, isto é os componentes tratam das necessidades da aplicação e o contêiner trata de problemas dos sistemas distribuídos e do middleware.

19 Contêineres

20 Contêineres O Middleware que suporta o padrão contêiner e a separação de aspectos por esse padrão é conhecido como servidor de aplicação; Esse estilo de programação distribuída esta sendo amplamente utilizada no ambiente corporativo; Atualmente existem diversos servidores de aplicativos: IBM WebSphere Application Server (EJB) Red Hat Jboss (EJB) Oracle GlassFish (EJB) Apple WebObjects para MacOS Zope Application Server para Python.

21 Suporte para Distribuição O Middleware baseado em componentes fornece suporte para a distribuição de configurações de componentes; São usados descritores de distribuição (DD) (geralmente em XML), que descrevem completamente como a configuração deve ser implantada em um ambiente distribuído. Atualmente há um uso maior das anotações; Lembrando: Os componentes são distribuídos em contêineres; Os contêineres interpretam os DDs, geralmente usando alguma ferramenta associada; Os DDs auxiliam na conexão dos componentes, a fornecer o nível de segurança correto, suporte para transações, etc.

22 Enterprise JavaBeans EJB é uma especificação de arquitetura de componentes gerenciada no lado do servidor; Os componentes conhecidos como beans do EJB, oferecem suporte direto a arquitetura de três camadas apresentadas anteriormente; O EJB é gerenciado. O Contêiner responde por vários serviços, tais como: Transação, Segurança e Ciclo de Vida; O EJB é uma arquitetura de componente pesada : Sobrecarga de complexidade pelo gerenciamento do contêiner; Tem como objetivo, manter uma forte separação entre as várias funções envolvidas no desenvolvimento de aplicações distribuídas. Objetos e Componentes Distribuídos

23 Modelo de Componentes do EJB No EJB um bean é um componente que oferece um ou mais interfaces de negócio para clientes; Estas interfaces podem ser remotas ou local; Esta interface de negócio é nossa interface fornecida; As interfaces exigidas são apresentadas através de injeção de dependências; Um bean é representado pelo conjunto de interfaces de negócio remotas e locais, junto a uma classe de bean associada que implementa as interfaces; Inicialmente vamos discutir dois estilos de bean: Bean de Sessão: usam a invocação remota ou local. Bean baseado em mensagem: usam JMS.

24 POJOs e anotações Programar em EJB ficou mais fácil devido ao uso EJBs POJOs (Plain Old Java Objects objetos Java puros) junto a anotações EJB; As anotações foram introduzidas no Java 1.5 como um mecanismo para associar metadados a pacotes, classes, métodos, parâmetros e variáveis; Por exemplo, anotações são usadas para indicar se as interfaces de negócio de um EJB são Remotas ou public interface public interface Frete{...} Vamos perceber na implementação que anotações são usadas por todo o EJB.

25 Contêineres EJB O gerenciamento do EJB como sistema distribuído é feito de forma implícita usando interceptação; Os contêineres fornecem políticas em áreas que incluem: Gerenciamento de Transação; Segurança; Persistência; Ciclo de Vida, etc. Geralmente os contêineres são previamente configurados com as políticas padrões; O Contêiner usa a injeção de dependência, com a qual um agente externo (contêiner) é responsável por gerenciar e solucionar as relações entre um componente e suas dependências (interfaces exigidas).