Objetos e Componentes Distribuídos: EJB e CORBAdai.ifma.edu.br/~mlcsilva/aulas_sisdistribuidos/Aula...

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

Sistemas Distribuídos – 8º Período

Sistemas Distribuídos


Objetivos

• Nesta aula iremos apresentar a solução baseada em

middleware para programação em um ambiente

distribuído usando componentes.


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


• Arquitetura CORBA

Objetos e Componentes Distribuídos



– 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.



• 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;




– 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;



• 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

pelo desenvolvedor ao usar o CORBA;




– 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.




– 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)

• Suporte para a distribuição.



• 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

de segurança correto, suporte para transações, etc.



• 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.




– 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).



Dúvidas

Página do Professor Mauro:http://www.dai.ifma.edu.br/~mlcsilva


Próxima Aula

• Web Services: Introdução e Arquitetura.


Referências

• Sistemas Distribuídos - Conceitos e Projeto, George

Coulouris, 4ª Edição - Editora Bookman, 784

páginas.

Objetos e Componentes Distribuídos: EJB e CORBAdai.ifma.edu.br/~mlcsilva/aulas_sisdistribuidos/Aula...

Documents

Transcript of Objetos e Componentes Distribuídos: EJB e CORBAdai.ifma.edu.br/~mlcsilva/aulas_sisdistribuidos/Aula...