Objetos e Componentes Distribuídos: EJB e CORBA
Mauro Lopes Carvalho Silva
Professor EBTT
DAI – Departamento de Informática Campus Monte Castelo
Instituto Federal de Educação Ciência e Tecnologia do Maranhão
Objetivos
• Nesta aula iremos apresentar a solução baseada em
middleware para programação em um ambiente
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
• Arquitetura CORBA
• 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);
• 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;
• 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;
• 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.
• 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;
• 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;
• Arquitetura CORBA
• 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;
• 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
• 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
• 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
.
• 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.
• 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)
• 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.
• Contêineres
• 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.
• 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
• 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.
• 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.
• 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 Locais:
@Remote public interface Pedidos{...} @Local public interface Frete{...}
– Vamos perceber na implementação que anotações são usadas por todo o EJB.
• 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
• Contêineres EJB
Dúvidas
Página do Professor Mauro: http://www.dai.ifma.edu.br/~mlcsilva
