Faculdade de Engenharia Eletrica e de Computac~ao
Uma Ferramenta Para Suporte ao
Desenvolvimento de Software
Orientado a Componente
Autor: Carlos Alexandre Miglinski
Orientador: Prof. Eleri Cardozo, Ph.D.
Dissertac~ao de Mestrado apresentada a F
a-culdadede Engenharia Eletricae de Computac~ao
como partedos requisitosparaobtenc~aodottulo
de Mestre em Engenharia Eletrica.
Area de
con-centrac~ao: Engenharia de Computac~ao.
Banca Examinadora
IvanLuiz Marques Ricarte,Ph.D. ... DCA/FEEC/UNICAMP
MariaBeatriz Felgarde Toledo, Ph.D. ... DSC/IC/UNICAMP
Ricardo Ribeiro Gudwin,Dr. ... DCA/FEEC/UNICAMP
FICHACATALOGRAFICAELABORADA PELA
BIBLIOTECA DA
AREA DE ENGENHARIA -BAE -UNICAMP
Miglinski,Carlos Alexandre
M588f Umaferramenta para suporte aodesenvolvimento de
software orientado a componente/ Carlos Alexandre
Miglinski. {Campinas, SP: [s.n.], 2003.
Orientador: EleriCardozo.
Dissertac~ao(mestrado) - Universidade Estadualde
Campinas, Faculdade de Engenharia Eletrica ede
Computac~ao.
1. Java(Linguagem de programac~aode computador).
2. CORBA (Arquiteturade computador). 3. JavaBeans.
4. XML (Linguagem de marcac~ao de documentos). I.
Cardozo, Eleri. II. Universidade Estadualde Campinas.
Faculdade de Engenharia Eletrica e de Computac~ao. III.
Miglinski,CarlosAlexandre,\UmaFerramentapara SuporteaoDesenvolvimentode
Soft-ware Orientado a Componente". Dissertac~ao de Mestrado - DCA/FEEC/UNICAMP,
Campinas, SP. Outubro 2003.
A complexidade dos atuais sistemas de software e a necessidade de ferramentas que
auxiliemnasua construc~ao motivarama pesquisa eodesenvolvimentode umaferramenta
de gerac~aoautomaticade codigo. Istotornou-seviavelgracasaos recentes avancos obtidos
pela engenharia de software principalmente no desenvolvimento de software baseado em
componentes. O objetivo e meta dessa dissertac~ao e a construc~ao de uma ferramenta
para suporte ao desenvolvimento de software orientado a componente. Esta ferramenta
denomina-se ccmBuilder e vem para complementar o modelo de componentes CM-Tel
tornandopossvelmodelarumprojetousando-seomodeloCM-Teleimplementa-lousando
a ferramentaccmBuilder.
Constatou-se que o uso do conjunto CM-Tel/ccmBuilder facilita o desenvolvimento,
pois a modelageme feita usando ferramentas CASE tradicionais no mercado. Ja na
im-plementac~ao as partes n~ao funcionais e funcionais s~ao gerados na sua totalidade, cando
somente a parte logica da aplicac~ao a cargo do desenvolvedor. Obtem-se com isto uma
agilidadee maiorcon abilidade dosoftware.
Palavras-chave: Gerac~ao Automatica de Codigo, Componentes, CCM, EJB, XML,
Miglinski,CarlosAlexandre,\AToolforComponentBasedSoftwareDevelopment.".
Mas-ters Thesis - DCA/FEEC/UNICAMP, Campinas, SP. October2003.
Thecomplexityofthesoftwaresystemsandtheneedoftoolsthathelpintheir
construc-tion motivated us the development of an automatic code generation tool. This tool take
advantageoftherecentadvancesinsoftwareengineering,mainlyintheareaof
component-based software development. The main objective of this master thesis is the construction
of a tool that supports the development of component-oriented software. This tool is
called ccmBuilder and complements the CM-Tel component model by providing a code
generation facility tothis model.
It was noticed that the combination CM-Tel/ccmBuilder improves the development
process. While the modeling is conducted using tradicional CASE tools. The functional
and non-functional parts are generated in their totality, being only the logical part of the
aplication left to the developer. As a result speed up in development and more reliable
software are achieved.
Keywords: Automated Code Generation, Components,CCM, EJB, Parser XML,
meus lhos Marcelo e Fernanda
\Um dia me disseram que as nuvens n~ao eram de algod~ao
Sem querer eles me deram as chaves que abrem esta pris~ao
Quem ocupa o trono tem culpa, quem oculta o crime,
tambem
Quem duvida da vida tem culpa, quem evita a d uvida,
tambem tem
Somos quem podemos ser
Sonhos que podemos ter"
Ao Prof. Eleri Cardozo, sou grato pela orientac~ao, dedicac~ao e carinho que me foram
ofertados.
Aos meus avos, \Nico" (in memorian) e Rosa, por terem me mostrado o valor da
perse-veranca.
Aos meus pais, Alexandre eMarilda, peloapoioeincentivo.
A minha esposa, Joseane de Carvalho Risardi Miglinski, pela compreenc~ao das minhas
aus^encias.
A minha colega de trabalho, Raquel Santos Schulze, pela inestimavel ajuda na leitura da
minha dissertac~ao.
Aos companheirosde trabalho, Eliane G. Guimar~aes, Ant^onio T. Ma eis.
AosamigosecolegasdoLaboratoriodeComputac~aoeAutomac~ao,pelosvaliososmomento
de convvio e calorosas discuss~oes, Rossano P. Pinto, Eduardo Nicola F. Zagari, Naur
JanzanttiJr,RodrigoC.M.Prado,TomasA.C. Badan,LuisF.Faina,BenitoT.Giordani
e Luiz G.da Silveira Jr.
Ao Departamento de Engenharia de Computac~ao e Automac~ao Industrial da Faculdade
de Engenharia Eletrica e de Computac~ao da UNICAMP por ter proporcionado a
infra-estrutura necessariaa realizac~aodeste trabalho.
Ao Centro Regional Universitario de Pinhal (CREUPI), a quem devo minha formac~ao
BOA: Basic Object Adapter
CCM: CORBA Components Model
CM-Tel: Component Model forTelematic Application
CIDL: Component Implementation De nition Language
CIF: Component Implementation Framework
CORBA: Common Object Request Broker Architecture
CPU: Central Processing Unit
DCOM: Distributed ComponentObject Model
DTD: DocumentType De nition
EJB: Enterprise JavaBeans
HTML: HyperText Markup Language
HTTP: Hypertext Transfer Protocol
IDL:Interface De nition Language
IDL2: Interface De nition Language- vers~aoatual
IDL3: Interface De nition Language- vers~aocom extens~oes
J2EE: Java 2 Platform, Enterprise Edition
JSP: JavaServer Pages
MOF: MetaObject Facility
ORB: Object Request Broker
POA: Portable Object Adapter
QoS: Quality of Service
RMI: Remote Method Invocation
RM-ODP: Reference Model forOpen Distributed Processing
UML: Uni ed Modeling Language
URL: Uniform Resource Locator
XML: Extensible Markup Language
XSL: Extensible Stylesheet Language
Lista de Acr^onimos vii
1 Introduc~ao 1
1.1 Objetivose Contribuic~oes doTrabalho . . . 2
1.2 Apresentac~ao doTrabalho . . . 3
2 Modelos de Componentes 4 2.1 Introduc~ao aoEnterprise JavaBeans . . . 4
2.1.1 Componentes J2EE . . . 4
2.2 Introduc~ao aoModelo de Componentes CORBA . . . 8
2.2.1 De nic~ao de Componentes CCM . . . 10 2.2.2 Implementac~aode Componentes . . . 13 2.2.3 Empacotamentode Componentes . . . 13 2.2.4 Montagem de Componentes . . . 14 2.2.5 Distribuic~aode Componentes . . . 15 2.2.6 Execuc~ao de Componentes . . . 15
2.3 Introduc~ao aoModelo de Componentes CM-Tel . . . 15
2.4 Resumodo Captulo . . . 19
3 Projeto da Ferramenta ccmBuilder 20 3.1 Arquiteturade Suporte do Modelo CM-Tel . . . 20
3.2 Implementac~ao das Interfaces de Componentes . . . 22
3.2.1 Exemplo de Componente . . . 38
3.3 Container . . . 39
3.3.1 Container e o Componente . . . 40
3.4 Distribuic~ao(Deployment) . . . 40
3.5 Resumodo Captulo . . . 43
4 Implementac~ao da Ferramenta ccmBuilder 44 4.1 Representac~ao de um Componente emXML . . . 44
4.1.1 OParser xml4j . . . 45
4.2 Estrategia de Gerac~ao de Codigo . . . 48
4.3 CORBAe Adaptadores de Objetos . . . 49
SUMARIO x
4.4.1 Servico A/V Streams . . . 51
4.4.2 Servico de Eventos . . . 51
4.4.3 Servico de Propriedades . . . 52
4.5 A FerramentaAnt . . . 54
4.6 Resumodo Captulo . . . 55
5 Utilizac~ao da Ferramenta ccmBuilder 56 5.1 Suporte para aImplementac~aodoccmVF . . . 56
5.2 Exemplo de Uso doccmVF . . . 56
5.3 Passos Para a Construc~aodo ccmVF . . . 57
5.3.1 PrimeiroPasso . . . 59
5.3.2 Segundo Passo . . . 62
5.4 Vantagens daGerac~ao Automatica de Codigo . . . 65
5.5 Resumodo Captulo . . . 66
6 Conclus~oes e Trabalhos Futuros 67 6.1 Contribuic~oes . . . 67
6.2 Resultados Obtidos . . . 68
6.3 TrabalhosFuturos. . . 68
A Componentes, Container e Deployments do ccmVF 73 A.1 Audio Player . . . 73 A.1.1 XML doComponente Audio Player . . . 73
A.1.2 XML doContainer para o Componente Audio Player . . . 73
A.1.3 Descritor de Distribuic~aodoComponente Audio Player . . . 74 A.2 Audio Transmitter . . . 75 A.2.1 XML doComponente Audio Transmitter . . . 75
A.2.2 XML doContainer para o Componente Audio Transmitter . . . 75
A.2.3 Descritor de Distribuic~aodoComponente Audio Transmitter . . . . 76
A.3 Consumidorde Eventos. . . 77
A.3.1 XML doComponente Consumidorde Eventos . . . 77
A.3.2 XML doContainer para o Componente Consumidor de Eventos . . 77
A.3.3 Descritor de Distribuic~aodoComponenteConsumidor de Eventos . 78 A.4 Originadorde Eventos . . . 78
A.4.1 XML doComponente Originador de Eventos . . . 78
A.4.2 XML doContainer para o Componente Originador de Eventos . . . 79
A.4.3 Descritor de Distribuic~aodoComponenteOriginador de Eventos . . 79
A.5 Vdeo Player . . . 80
A.5.1 XML doComponente Vdeo Player . . . 80
A.5.2 XML doContainer para o Componente Video Player . . . 80
A.5.3 Descritor de Distribuic~aodoComponenteVideo Player . . . 81
A.6 Vdeo Transmitter . . . 82
SUMARIO xi
A.6.3 Descritor de Distribuic~aodoComponenteVdeo Transmitter . . . . 83
B Alterac~oes Necessarias aos Arquivos Java e IDLs do ccmVF 85 B.1 Consumidorde Audio. . . 85
B.1.1 Fabrica doComponente Conmsumidorde Audio . . . 85
B.1.2 Container do ComponenteConsumidor de Audio . . . 85
B.2 Produtor de Audio . . . 86
B.2.1 Fabrica doComponente Produtor de Audio . . . 86
B.2.2 Container do ComponenteConsumidor de Audio . . . 87
B.3 Consumidorde Eventos . . . 87
B.3.1 IDLdo Evento . . . 87
B.3.2 Implementac~aodoObjetoporValordoEventos . . . 87
B.3.3 Fabrico doComponente Consumidor de Eventos . . . 88
B.3.4 Container do ComponenteConsumidor de Eventos . . . 88
B.3.5 Aplicac~aoque Utilizao Evento . . . 89
B.4 Produtor de Evento . . . 90
B.4.1 IDLdo Evento . . . 90
B.4.2 Fabrica doComponente Produtor de Eventos . . . 90
B.4.3 Container do ComponenteProdutor de Eventos . . . 91
B.4.4 Classe queUtiliza oEvento . . . 91
B.5 Consumidorde Vdeo . . . 92
B.5.1 Fabrica doComponente Consumidor de Vdeo . . . 92
B.5.2 Container do ComponenteConsumidor de Vdeo . . . 92
B.6 Produtor de Vdeo . . . 93
B.6.1 Fabrica doComponente Produtor de Vdeo . . . 93
2.1 Aplicac~aoMulticamada [1]. . . 5
2.2 Cliente/Servidor no EJB.. . . 7
2.3 Mapeamentode IDL3para IDL2. . . 10
2.4 Estrutura de um elementoXML. . . 18
3.1 Arquiteturade 3camadas para suportar o modelo de componentes. . . 21
3.2 Arquiteturade uma interface. . . 22
3.3 Arquivos geradospeloccmBuilderpara um componente. . . 23
3.4 Arquiteturada interface equivalente. . . 24
3.5 Arquiteturada interface PropertyService. . . 27
3.6 Arquiteturada interface transmitter. . . 28
3.7 Arquiteturada interface broadcaster. . . 29
3.8 Arquiteturada interface player. . . 30
3.9 Arquiteturada interface emitter. . . 31
3.10 Arquiteturada interface publisher. . . 33
3.11 Arquiteturada interface consumer. . . 35
3.12 Arquiteturada uma faceta. . . 36
3.13 Arquiteturade um receptaculo. . . 37
3.14 Classescriadas para um componente consumidor de eventos. . . 38
3.15 Classese interfaces geradas para um container. . . 40
3.16 Container contendo um componente. . . 41
4.1 Arquiteturade um programa XML. . . 45
4.2 Criac~aode arquivoJava/IDL a partir de um arquivo XML. . . 47
4.3 Processo de gerac~ao de codigo para aarquitetura proposta. . . 48
4.4 Diagramade classes doccmBuilder. . . 49
4.5 Diagramade sequ^encia do ccmBuilder. . . 50
4.6 Servico de eventos: modelo push e pull. . . 53
4.7 UML para oservicode propriedades. . . 54
5.1 Telado ccmVF. . . 57
5.2 Interface do componentede eventos. . . 58
5.3 Janela de convite. . . 58
5.4 Passos para a construc~ao doccmVF. . . 58
Introduc~ao
A complexidade dos servicos oferecidos atraves da Internet tem aumentado
rapida-mente. Servicos de telecomunicac~oes que no passado demandavam redes especializadas
s~ao hoje oferecidos atraves da Internet. Estes novos servicos utilizam comunicac~ao
mul-timdia,como nocaso de videoconfer^encia, vdeo sob demanda e tele-robotica.
Atualmente,amaioriadascomplexasaplicac~oesdistribudass~aoconstrudas sobreuma
plataformademiddlewarecomoCORBA(CommonObjectRequestBrokerArchitecture)do
OMG(ObjectManagementGroup)[2],DCOM(DistributedComponentObjectModel)[3]da
MicrosoftouRMI(Java Remote MethodInvocation)[4]daSunMicrosystems. Amotivac~ao
paraoempregodetaisplataformaseacelerarodesenvolvimentodeaplicac~oesdistribudas.
Modelar, projetar e implementar aplicac~oes distribudas t^em-se revelado atividades
bastante complexas. CORBA fornece aodesenvolvedor uma mirade de escolhas e requer
um vasto numero de detalhes a serem especi cados, tornando a tarefa do desenvolvedor
extremamentecomplexa, lenta e pouco e ciente.
Devido a estas di culdades, tem-se procurado aprimorar a construc~ao de aplicac~oes
distribudas. Com avancos recentes na engenharia de software, principalmente no
desen-volvimentodesoftware baseadoemcomponentes,veri cou-sequeumnumerobempequeno
de regrasde projetot^em aplicabilidadecomum. Noescopode projeto,estas poucasregras
poderiam ser realizadas por ferramentas de gerac~ao de codigo. Isto e analogo ao servico
realizadopelos atuais compiladores IDL que geram todos os stubs e skeletons necessarios
a distribuic~ao de objetos. Empregando-se componentes, alem de gerar stubs e skeletons,
sera possvelgerar um volume maior docodigo daaplicac~ao.
Segundo D'Souza eWills [5], um componenteeuma unidade de software quepode ser
desenvolvidoeinstaladoindependentemente, cominterfaces explcitasebemespeci cadas
tantoparaos servicos queeleproporcionaquantoparaosservicos queelenecessita de
ou-troscomponentes, epodeser compostocomoutroscomponentes paraformarumaunidade
maior.
O conceito de componentes de software n~ao pode ser considerado uma inovac~ao, pois
ja era conhecida a possibilidade de desenvolver sistemas grandes e complexos, atraves da
interconex~aodeblocosdeconstruc~aomenores,quetantopoderiamserdesenvolvidos,
apro-veitados de desenvolvimentos anteriores ou adquiridos de terceiros. Entretanto, gracas a
efetiva-menteimplementadas.
Osbenefcios comautilizac~aode componentes desoftware incluemcriac~aode software
emumperodomenor,comcustodedesenvolvimentoreduzido, dealtaqualidadeede facil
manutenc~ao.
Este novo paradigma, que combina novas tecnologias orientadas a componentes com
tecnologias tradicionais de plataforma de middleware, prov^e um melhorsuporte a
intero-perabilidade, portabilidade ,extensibilidade e coexist^encia com sistemas legados.
Oscomponentes necessitam de padr~oes para interac~aoecomposic~ao,comotambemde
infra-estrutura e servicos padronizados. Portanto, existe a necessidade de de nirmodelos
de componentes com tais padr~oes e proporcionar implementac~oes deste modelo de
com-ponentes de forma a permitir que componentes e infra-estrutura de componentes sejam
projetadas, implantadase instaladas.
A composic~ao de componentes de software somente e possvel se um modelo de
com-ponentes fornecer padr~oes para a interac~ao entre componentes de diferentes fornecedores
e,eventualmente, que foramimplementados emdiferentes linguagens de programac~ao.
Otermo composic~ao,utilizadonestetrabalhoe naliteraturade tecnologiasde
compo-nentes de software, refere-se a descric~ao de como os sistemas s~ao montados. Atraves da
composic~ao pode-se formar parte, ouuma aplicac~aocompleta, combinando as
funcionali-dades que o componente possui com as funcionalidades fornecidas por outros
componen-tes. Para permitircomposic~ao,um componente, alemde encapsularasua implementac~ao,
tambemdeveinteragircomoseuambientedeexecuc~aoatravesdeinterfacesbemde nidas.
Adicionalmente,uma outracaractersticaimportanteeapossibilidade de \customizar"as
propriedades de um determinado componente para uma aplicac~ao, tanto em tempo de
instalac~aoquanto dinamicamenteemtempode execuc~ao.
1.1 Objetivos e Contribuic~oes do Trabalho
Esta dissertac~ao apresenta uma ferramenta para construc~ao de aplicac~oes aderentes
ao modelo de componentes CM-Tel[6]. O modelo de componentes CM-Tel foi inspirado
no Modelo de Componentes CORBA (CCM) sendo uma vers~ao simpli cada deste com
algumas extens~oes para suporte a aplicac~oes telematicas, como, por exemplo, suporte a
mdias contnuas.
O modelo de componentes CM-Tel permite agilizaro processo de gerac~ao de sistemas
distribudos. Taissistemas requerem:
desenvolvimento rapido;
integrac~aode codigo legado;
altacon abilidadedo software;
baixocusto nodesenvolvimento.
software tambem aumenta,pois ocodigoegerado a partirde padr~oes (templates)
ampla-mentetestados. Ao se gerar codigo de forma mais rapida e con avel, diminui-se tambem
seu custo.
Todooprocessodedistribuic~aodecomponentestambemegeradopeloccmBuilder. Em
suma,o desenvolvedor iraseconcentrar nas func~oes espec cas de sua aplicac~ao,deixando
a cargo do ccmBuilder toda a gerac~ao do codigo referente a interac~ao e instalac~ao dos
componentes da aplicac~ao.
Seriadesejavelquetodooprocessofosseautomatizado,nosentido queodesenvolvedor
pudessecriar umprojetousandoferramentasCASE aderenteaopadr~aoUML[7]e,apartir
deste, a ferramenta ccmBuilder pudesse gerar os componentes, containers e arquivos de
distribuic~ao. No momento, e necessario que o desenvolvedor transforme manualmente o
projeto modelado atraves de diagramas UML para arquivos XML[8 ][9] que por sua vez
ser~ao submetidos aferramentaccmBuilder para agerac~ao de codigo.
Para que pudessemos validar a ferramenta ccmBuilder,foi construdo um software de
vdeo-confer^encia,ccmVF. Atraves dodesenvolvimento deste software pode-se comprovar
as vantagens queo desenvolvimento orientado acomponente oferece.
1.2 Apresentac~ao do Trabalho
O trabalhoesta dividido daseguintemaneira:
No Captulo 2 e apresentada uma discuss~ao sobre os principais modelos de
compo-nentes comoEnterpriseJava Beans (EJB)eCORBA ComponentsModel (CCM).O
modelo CM-Tele apresentado neste captulo.
No Captulo 3 s~ao caracterizados os principais requisitos para uma ferramenta de
gerac~aode codigo para o modelo de componentes CM-Tel.
No Captulo 4 s~ao apresentados os detalhes de implementac~ao da ferramenta de
gerac~aoautomatica de codigo para o modelo CM-Tel.
No Captulo 5 s~ao apresentados os aspectos de implementac~aode um prototipo
ge-radoa partirdaferramentaccmBuilder,com opropositode validaralgunsconceitos
expostos nos captulos 3e 4.
NoCaptulo 6s~aoapresentadasas principaisconclus~oes econtribuic~oesdotrabalho,
Modelos de Componentes
Este captulo apresenta uma vis~ao geral sobre os modelos de componentes Enterprise
JavaBeans (J2EE) e CORBA Component Model (CCM). O captulo apresenta, ainda, o
modelo CM-Tel parao qualfoi construdaaferramentade gerac~aode codigoobjetodesta
dissertac~ao.
2.1 Introduc~ao ao Enterprise JavaBeans
O modelo de componentes J2EE (Java 2, Enterprise Edition) e um dos primeiros
modelos de componentes n~ao proprietario e in uenciou na especi cac~ao do modelo de
componentes CORBA (CCM) doqual nosso modelo CM-Telse originou.
Segundo a refer^encia [1], aplicac~oes J2EE tipicamente consistem de tr^es camadas que
s~ao distribudas em tr^es diferentes localidades: maquina do cliente, maquina servidora
J2EEe maquina servidorade basede dados oumaquinas legadascomtarefas secundarias
( gura 2.1). Aplicac~oes que utilizam desta forma estendem o modelo cliente servidor de
duas camadas colocando um servidor multithreaded entre a aplicac~ao cliente e o
armaze-namento de informac~oes (arquitetura 3-tier).
2.1.1 Componentes J2EE
Aplicac~oes J2EE[10][11] s~ao construdas a partir de componentes J2EE. Um
compo-nente J2EE e uma unidade de software funcional autocontido que e construda em uma
aplicac~ao J2EE que esta relacionada com classes e arquivos e se comunica com outros
componentes. A especi cac~aoJ2EE de ne osseguintes componentes:
Aplicac~oes clientes e applets: s~ao componentes que executamno lado docliente.
JavaServleteJavaServerPages(JSP):s~aocomponentesWebeexecutamnoservidor.
ComponentesEnterpriseJavaBeans(EJB):s~aocomponentesdenegocioseexecutam
noservidor.
Componentes J2EE s~ao escritos em linguagem de programac~aoJava[12] e compilados
J2EE
Aplicação 2
J2EE
Aplicação 1
Camada
Sistema de
Enterprise
Cliente
Páginas HTML
Aplicação Máquina
Cliente
Máquina
Servidora
J2EE
Máquina
Servidora
de Banco
de Dados
Informação
Dinâmicas
Enterprise
Beans
Páginas JSP
Enterprise
Beans
Base de
Dados
Base de
Dados
Negócios
Camada
WEB
Camada
Cliente
Camada
Figura2.1: Aplicac~aoMulticamada [1].
Principais Vantagens do Modelo EJB
EJB fornece ao desenvolvedor independ^encia de arquitetura de hardware - EJB
se-para o desenvolvedor da camada de middleware dado que o unico ambiente que o
desenvolvedor EJB v^eeo ambiente Java. Tambem auxiliaos fornecedores de
servi-dores/container EJB a realizar mudancas na camada de middleware sem afetar as
aplicac~oes existentes.
DevidoaoEJBserbaseadonatecnologiaJava,egarantidotantoparaodesenvolvedor
quanto ao usuario que seus componentes, uma vez escritos, executam em qualquer
lugar ("Write Once,Run Anywhere").
A especi cac~ao EJB associa regrasespec cas para participantes de projetos
coope-rarem entre si. Porexemplo, desenvolvedores da logica daaplicac~aofocam somente
na logica do negocio. Desenvolvedores de aplicac~oes para distribuic~ao se
preocu-pam com as tarefas de distribuic~ao emuma forma simplese portavel. O fornecedor
de servidores EJB pode cuidar do suporte para servicos complexos de sistemas e
tornar disponvel um framework para um EJB ser executado, sem a assist^encia do
desenvolvedor de aplicac~oes EJB.
Erequeridodofornecedorde container EJBfornecer suporte atransac~oes. O
desen-volvedor de EJB que escreve a funcionalidade do negocio n~ao precisa se preocupar
pode envolvercomponentes EJB instaladosem containers executando emmaquinas
distintas.
EJB e CORBA s~ao uma combinac~ao natural que se complementam mutuamente.
Por exemplo, EJB pode fornecer CORBA/IIOP para um mecanismo de transporte
robustoouclientes CORBA podem acessarcomponentes EJB comose fossem
servi-dores CORBA.
Componente Enterprise JavaBeans
Um componente EJB e um componente quee executado dentro de um container que
por sua vez executa dentro de um servidor. Qualquer servidor que possa hospedar um
container EJB efornecer osservicos necessarios pode ser um servidor EJB.
Um componenteEJB euma classe Java queimplementaa logica donegocio.
Container Enterprise JavaBeans
O container EJBeonde ocomponente EJB \vive". Ocontainer EJB fornece servicos
como transac~oes e gerenciamento de recursos, escalabilidade, mobilidade, persist^encia e
seguranca para os componentes EJB. Uma vez que o container cuida destas func~oes, o
desenvolvedor pode concentrar-se somente nalogica daaplicac~ao.
Objeto de Acesso e a Interface Remota
O objeto de acesso implementaainterface remota docomponenteEJB noservidor. A
interface remotarepresentaosmetodosdonegociodocomponenteEJB.Objetosdeacesso
e componentes EJB s~ao classes separadas, porem implementando a mesma interface (a
interface remotadocomponenteEJB).Entretanto,estas implementac~oes realizamfunc~oes
distintas. Um componente EJB executa em um container EJB dentro de um servidor
EJB e implementa a logica do negocio. O objeto de acesso EJB executa no cliente e,
remotamente, executaosmetodosdocomponenteEJB. Aimplementac~aode umobjetode
acesso EJB e criadaporuma ferramenta supridacomo container EJB.
QuandoumclientechamaummetodoemumobjetodeacessoEJB,ometododoobjeto
deacessoEJBsecomunicacomocontainer EJB,solicitandoainvocac~aodomesmometodo
com os mesmosargumentos supridos pelo cliente. A gura 2.2 demonstra como funciona
o sistemacliente/servidor no EJB.
Tipos de Enterprise JavaBeans
Existem dois tipos basicos de componentes EJB, session beans e entity beans, que
executamdiferentes regrasem uma aplicac~aodistribudaEJB.
Session bean e uma inst^ancia de um EJB associada com um unico cliente. Session
bean tipicamentes~aotransientes e podem oun~aoparticipar de transac~oes. Emgeral
Bean EJB
Cliente
Container EJB
Servidor EJB
Interface
Interface
EJB Home
do Componente
Figura 2.2: Cliente/Servidor no EJB.
paginas HTML em uma sess~ao HTTP. Quando um usuario abandona a pagina, o
objeto de sess~aoe destrudo.
Entity bean representainformac~oespersistentes armazenadasemumabasede dados.
Entity beans s~ao associados com transac~oes em banco de dados e podem fornecer
acesso a multiplos usuarios. Um entity bean e persistente no sentido que
sobre-vive a falhas no servidor. Um entity bean tambem permite o compartilhamento de
informac~oes.
Message-drivenbean eum enterprise bean quepermiteque aplicac~oes J2EE
proces-sem mensagens assincronamente. Ele atua comoum listener querecebemensagens.
Aprincipaldiferencaentre message-driven e session/entity equeo clienten~aopode
acessar ocomponente atravesde uma interface.
Um cliente EJB cria objetos EJB no servidor e os manipula como se fossem objetos
locais. Isto torna o desenvolvimento de clientes EJB semelhante ao desenvolvimento de
clientes que executam localmente. Session bean gerencia informac~oes relacionadas com a
interac~ao entre o cliente e o servidor, enquanto entity bean representa e manipula dados
persistentes nodomniodaaplicac~ao.
Interface home
Operac~oes envolvendo o ciclo de vida de um componente no lado do servidor s~ao
res-ponsabilidade do container EJB. O cliente contata o container e solicita que um tipo
particular de objeto sejacriado, eo container retornaum objeto EJB quepode ser usado
para manipular o novo componente EJB.
um contratoentre ocomponente EJB eseu container, que de neconstruc~ao, destruic~ao e
localizac~aode inst^ancias de EJB.
Umainterfacehomeestendeainterfacejavax.ejb.EJBHome,quede nefuncionalidades
basicasparauma interfacehome. Todos osmetodosnestainterfacedevemser compatveis
com RMI. A interface home do EJB tambem de ne um ou mais metodo create(), cujo
nome sempre sera create,mas com assinaturas diferentes. O valor retornado pelometodo
create ea interface remota para oEJB.
Quando um cliente deseja criar um componente no lado do cliente, ele usa o Java
Naming and Directory Interface (JNDI) para localizar a interface home do componente
que deseja.
Uma vez que o cliente possui a interface home do EJB que deseja criar, ele chama
um dos metodos create() da interface home para criar o objeto no lado do servidor. A
interface home nolado doclientefaz umachamadaremotaaocontainer EJBnoservidor,
que, ent~ao, cria o componente EJB e retorna um objeto EJB para o cliente. O cliente
pode, ent~ao, chamar o metodo do objeto EJB, que ira ser encaminhado ao container. O
container delega a implementac~aodometodopara o componente EJB.
Entity beans tambem tem um metodo adicional nder na interface home que localiza
o JavaBean persistente, baseado nachave primariado componente.
Descritor de Distribuic~ao
As regras do descritor de distribuic~ao s~ao obtidas de informac~oes declarativas (ex.
informac~oes que n~aos~aoincludas diretamente nocodigo doenterprise bean).
Existem dois tiposbasicos nodescritor de distribuic~ao:
Informac~oes estruturais do enterprise bean. Informac~oes estruturais descrevem a
estrutura de um EJB e declara suas depend^encias externas. Prov^eem informac~oes
estruturais que n~ao podem ser, em geral, alteradas pois, poderiam prejudicar as
funcionalidadesdo EJB.
Informac~oes do montador da aplicac~ao descrevem como o EJB no arquivo ejb-jar e
composto em uma grande unidade. Prover informac~oes de montagem no descritor
de distribuic~aoeopcionalparaoarquivoejb-jarprodutor. Informac~oesdomontador
podem ser mudadas sem prejudicaras funcionalidadesdo EJB.
As informac~oes do descritor de distribuic~aos~ao escritos em XML e apresentam um DTD
para validar o arquivo XML.
O utilitariodeploytool presente na plataforma J2EEe utilizado para criar pacotes de
componentes e para distribuir a aplicac~ao. O utilitarioe apresentado em duas vers~oes:
uma em linha de comando ea outra utilizandointerface gra ca (GUI).
2.2 Introduc~ao ao Modelo de Componentes CORBA
Mana-tribuic~aode componentes CORBA.CCM adiciona aIDL (Interface De nition Language)
a capacidade de de nir componentes CORBA. CCM tambem introduz CIDL
(Compo-nent Implementation De nition Language) com a nalidade de descrever detalhes de
im-plementac~ao permitindo um completo framework no lado do servidor, que sera gerado,
montado edistribudo. Apesar doCCM de nir um framework de componentes focado no
lado do servidor, nada impede sua utilizac~ao no lado cliente. CCM e dividido em dois
nveis distintos: nvel basico que componentiza objetos CORBA e um modelo mais rico
quepossui extens~oes aomodelo CORBA.A especi cac~aodoCCM eestruturada emcinco
modelos eum meta modelo.
1. O modelo abstrato fornece uma maneira de de nir as varias interfaces fornecidas e
usadaspelocomponente, bem comosuaspropriedades. Foramadicionadasextens~oes
a IDLpara acomodar os novosconceitos introduzidos peloCCM, especialmente
de- nic~ao de portas (ports). O modelo abstrato tambem permite ao projetista de nir
gerentes para inst^ancias de componentes.
2. O modelo de programac~ao inclui o framework de implementac~ao de componentes
(ComponentImplementationFramework -CIF) quede necomoaspartesfuncionais
(logica de aplicac~ao) e n~ao funcional (codigo gerado automaticamente) devem
coo-perar. CIF tambem de ne uma forma de a inst^ancia do componente interagir com
o container que a hospeda. Este frameworkconta com o uso de uma Linguagem de
De nic~ao eImplementac~aode Componentes (CIDL).
3. O modelo de empacotamento especi ca como os componentes e as implementac~oes
devemser agrupadasempacotesde software (empacotadas). Estaassociadocomum
conjunto de descritores escrito emXML (Extended Markup Language)
4. Omodelodedistribuic~ao de neumprocesso quepermitedistribuirumaaplicac~aode
forma simples e automatizada. Este processo usa pacotes de software para instalar
implementac~oes de componentes, criarinst^anciasde componentes einterconecta-los.
5. O modelo de execuc~ao descreve inst^ancias de componentes em tempo de execuc~ao.
Estemodelodescreveoambientede execuc~ao paracomponentesdenominado
contai-ner. A caracterstica principalde um container eesconder e gerenciar aspectos n~ao
funcionaisde um componente, como ciclo de vidae persist^encia.
6. O meta-modelo e de nido atraves de esquemas UML (Uni ed Modeling Language)
e MOF (MetaObject Facility). Este meta-modelo inclui extens~oes a IDL2 (vers~ao
atual da IDL) e o repositorio de interfaces bem como o modelo de distribuic~ao de
componentes. Este meta-modelon~ao requer mudancas no UML.
CCM tambem de ne um mapeamento para Enterprise JavaBeans 1.1, que permite
2.2.1 De nic~ao de Componentes CCM
O modelo abstrato de Componentes CORBA permite ao projetista de nir interfaces
funcionaisdocomponenteusandoalinguagemIDL3doOMG.Estas de nic~oes s~aousadas
somente com oproposito de projeto. Para implementarum componente, as de nic~oes em
IDL3s~ao mapeadas para IDL2 e, a partir delas, o desenvolvedor iraimplementara parte
funcional docomponente.
+
Definição
IDL3
IDL2
Programação
skels
SRC
Projetista
Desenvolvedor
Mapeamento
Compilação
Figura2.3: Mapeamentode IDL3para IDL2.
O Tipo Componente
Um tipo componente agrupa de nic~oes de atributos e portas (ports). Atributos s~ao
propriedades con guraveis de um componente e s~ao usados, a princpio, com o proposito
de con gurac~ao. Portas de nem interfaces ques~aofornecidasouusadas pelocomponente.
Portas s~aonovasconstruc~oes quesuportamformas dese\conectar" componentes. Quatro
tiposde portas s~aode nidos peloCCM:
Facetas: s~ao interfaces fornecidas pelocomponente eusadas pelos clientes.
Receptaculos: estipulamasinterfaces de outros componentes queo componente
ne-cessita para arealizac~aode suas func~oes.
Consumidores de Eventos: s~ao pontos de conex~oes onde noti cac~oes assncronas
(eventos) de um tipo espec co s~ao consumidas.
Emissores de Eventos: s~ao pontos de conex~oes que emitem eventos de um
determi-nado tipopara um consumidorconectado ou um canal de distribuic~aode eventos.
Componentes s~ao de nidos em IDL3 usando a palavra reservada component. Esta
pala-vra reservada representa um novo meta-tipo, que e uma especializac~aode uma interface.
A de nic~ao de um tipo componente e muito similar a de nic~ao de interface. Como na
interface, tipos componentes podem ser de nidos usando um relacionamento de heranca.
Compo-Facetas
Umafaceta(facet)representa determinadoaspectofuncionaldeum componente. Uma
facetadeve serespeci cada porumainterfaceIDLvalida. Asfacetasn~aopodem ser
disso-ciadas de um componente ao qual pertencam. Muitas copias da refer^encia de uma faceta
podem existir ao mesmo tempo, por exemplo, quando multiplos clientes usam a mesma
faceta de um componente. A palavra reservada provides e usada para de nir uma faceta.
Para permitir a navegac~ao, uma interface base e fornecida: Components::CCMObject,
que e herdada de Components::Navigation. Componentes::Navigation prov^e operac~oes
genericasdisponveiseusadasemqualquertipocomponente. Suasoperac~oesprincipaiss~ao:
operac~oes de introspecc~ao(describe facets()) erecuperac~aode faceta(provide all facets(),
provide named facets() eprovide facet()). Finalmente, umaoperac~aotesta seduasfacetas
s~aoparte do mesmocomponente.
Receptaculos
Um receptaculo permite que um componente aceite uma refer^encia (por exemplo
re-fer^enciade umafaceta,refer^enciadeum componenteourefer^enciade umobjeto)para que
possa usar as operac~oes fornecidas pela refer^encia. O receptaculo e um ponto conceitual
de conex~ao. Esta abstrac~ao e materializada em um componente atraves de um conjunto
de operac~oes para agrupar e gerenciar conex~oes. Receptaculos podem ser de dois tipos:
receptaculos simples (somente uma refer^encia pode ser conectada por vez) e receptaculos
multiplos(varias refer^encias podem ser conectadas simultaneamente). Para ambos os
ca-sos, receptaculoss~aode nidosusando-se apalavrareservadauses. Nocasode receptaculos
multiplos,apalavrareservada multiple eassociadacom apalavrareservadauses. No
con-texto de receptaculos multiplos, uma chave e de nida para gerenciar multiplas conex~oes.
Para cadaconex~aouma chaveecriadaassimqueamesmaeestabelecida. Esta chave
iden-ti cade modounico aconex~aoeeusadaparaqualquer operac~aorealizadasobreamesma.
Para ambosos tiposde receptaculos, operac~oes de conex~aoe desconex~ao s~aode nidas.
Conex~oes - As operac~oes do tipo connect() s~ao geradas em parte pela ferramenta
de gerac~ao de codigo e emparte implementadas pelo desenvolvedor. Quando se usa
receptaculo multiplo,odesenvolvedor tem queimplementarogerenciamentodas
re-fer^enciasconectadas. Umavez queasoperac~oesde conex~aotenhamsidoexecutadas,
osreceptaculos as mant^em ate queuma requisic~ao de desconex~ao sejarecebida.
Desconex~ao - As operac~oes do tipo disconnect() removem o relacionamento entre
a inst^ancia do componente e a refer^encia conectada. Em receptaculos simples, a
operac~aoretornaarefer^enciaqueestavaconectadaaoreceptaculo,oulancaaexcec~ao
NoConnection. Usando-se receptaculos multiplos, e necessario identi car a chave
para nalizaraconex~ao. Se achave n~aofor valida aexcec~aoInvalidConnection sera
lancada.
como par^ametro. A operac~ao get connections() fornece uma lista de facetas conectadas
para um dado receptaculo.
Eventos
O modelo de eventose um modelo classicoprodutor/consumidor. Este modeloe
com-patvel com a especi cac~ao de servicos CORBA de eventos e noti cac~ao. Para receber
eventos, um cliente tem que se subscrever a um originador de eventos. No CCM somente
o modelo push e utilizado. Operac~oes para processar eventos s~ao de nidas na interface
do consumidor. Servicos para gerenciar eventos s~ao fornecidos pela implementac~ao do
container. Existem ainda dois tipos de portas que manipulam eventos: originadores de
eventos e consumidores de eventos. Existem dois tipos de originadores de eventos. Um
emissoreum originador de eventos que opera na formade um-para-um,ou seja,somente
um consumidor pode ser conectado por vez. Neste modelo n~ao existe canal de eventos,
sendo a conex~ao realizada diretamente entre o produtor e o consumidor. Um publicador
e um originador de eventos que opera na forma um-para-muitos, ou seja, muitos
consu-midores podem ser conectados ao originador de eventos ao mesmo tempo. A subscric~ao
de um consumidor a um tipo de evento e delegada a um canal de eventos fornecido pelo
container. Umconsumidordeeventos permiteaumainst^anciade umcomponentereceber
eventos de um determinadotipo. Ade nic~aode originadoresde eventos ebaseada nouso
de palavras reservadas emits e publishes. Neste caso, operac~oes de connect/disconnect e
subscribe/unsubscribe s~aoadicionadasainterfacedocomponente. Quandoumasubscric~ao
ocorre, uma chavee geradapara identi car a subscric~ao doconsumidor. Esta chave e
ne-cessaria para encerrar uma subscric~ao. Consumidores de eventos s~ao de nidos usando-se
a palavra reservada consumes. Cada porta especi ca o tipo de evento (event type)
pro-duzidoou consumido. Ostipos de eventos s~ao valuetypes (objetos porvalor) herdados da
interface Components::EventBase. Os eventos s~ao \empurrados" ao cliente, por isso, os
consumidoresde nem somente uma operac~aotipo push().
Componente Home
A meta principal de componente tipo home e prover o equivalente ao operador new
em linguagens orientadas a objetos. Home e um novo meta-tipo de nido em IDL3. Um
componente home e um gerente para inst^ancias de um dado componente. Ele gerencia
o ciclo de vida do componente usando chaves primarias para indexac~ao. De fato, ele
oferece fabricas para inst^ancias de componentes e operac~oes de busca que usam chave
primaria. Interfaces home s~ao de nidas usando-se heranca simples do tipo base
Compo-nents::CCMHome. Chaves primariass~aoidenti cadoresunicos deinst^anciade
componen-tes. As de nic~oes s~aoassociadas com as palavrasreservadas factory e nder. A interface
home explcita agrupa operac~oes declaradas pelo projetista. A interface home implcita
agrupa operac~oes genericas docomponente home para este tipohome. Quando um home
n~ao possui chave, a unica operac~ao gerada e o metodo create. Nos homes com chaves
in-usadasparaencontrarumainst^anciadeumcomponente. Umhome nder eobtidofazendo
uma chamada a CORBA::ORB::resolve initial references usando ComponentHomeFinder
como argumento.
2.2.2 Implementac~ao de Componentes
Modelo de Programac~ao
A meta principaldo modelo de programac~aoe descrever aspectos n~ao funcionaispara
gerar automaticamente esta parte da implementac~ao,deixando a cargo do desenvolvedor
somente a codi cac~ao da parte funcional do componente. Para que estas duas partes
sejamintegradas de formaharm^onica,omodelo CCM prov^e um framework,o Component
ImplementationFramework(CIF),quedescrevecomoaspartesfuncionaisen~aofuncionais
ir~ao interagir. Para se gerar skeletons de um componente, CIF conta com a linguagem
Component Implementation De nition Language (CIDL), que prop~oe extens~oes a IDL2
do CORBA. Skeletons de componentes automatizam o gerenciamento de func~oes basicas
como gerenciamentode portas, navegac~aoentre facetas eciclo de vida docomponente.
2.2.3 Empacotamento de Componentes
Para que um componente possa ser distribudo, elenecessita ser empacotado. No
mo-delo CCM um pacote e um arquivo agrupando um componenteouvarias implementac~oes
de componentes e um conjuntode descritores. Osdescritores s~ao especi cados atraves de
Data Type De nition (DTD). Osdescritores s~aouma boamaneirade sede nir a
arquite-tura de uma aplicac~ao.
Pacotes de Software
Umpacotede software econstitudode um descritor eumconjuntode arquivos. Estes
varios elementoss~aoagrupados emarquivosusando-seoformato"ZIP". NomodeloCCM
umpacoteincluiimplementac~oesdecomponentesCORBA.Umdescritorde neoconteudo
dopacote. Elefornece asprincipaisinformac~oes sobreosoftware (autor,descric~oes,
inter-faces, etc) bemcomo asdescric~oes de implementac~ao(nome, sistema operacionaldestino,
linguagem de implementac~ao,localizac~aodocodigo, etc). Estas informac~oes s~ao descritas
atraves dalinguagem XML.
Descritor de Pacotes de Componentes
Um descritor de pacotes de componentes especi ca caractersticas dos componentes
de nidas nas fases de projeto e desenvolvimento. Parte e gerada pelo compilador IDL3 e
partemodi cadapelaferramentadeempacotamento(algunselementoscomopersist^encia,
Descritor das Funcionalidades
Este descritor e usado atraves de uma ferramenta de projeto para apresentar
in-formac~oes a respeito do componente. Ele descreve a estrutura do componente: interfaces
herdadas,interfacessuportadas,portas, dentre outrasinformac~oes. Asvarias interfacesdo
componente s~ao descritas e referenciadas pelo seu Repository ID. Este descritor permite
a uma ferramenta conectar componentes em tempo de distribuic~ao para construir uma
aplicac~aoem parteouporcompleto. Estas informac~oess~aodescritasatravesdalinguagem
XML.
Informac~oes de Distribuic~ao
No momento da distribuic~ao, o descritor de distribuic~ao e usado para escolher o tipo
de container a serusadopelocomponenteepara fornecerparaocontainer asinformac~oes
arespeito das propriedadesdocomponente, como persist^encia einformac~oes arespeito de
polticas de thread a serem usadas. Estas informac~oes s~aodescritas atraves dalinguagem
XML.
2.2.4 Montagem de Componentes
Umpacotede montagemdecomponentes forneceuma formafacilde distribuir
compo-nentes.
E um modelo/padr~aopara instanciar um conjuntode componentes econecta-los.
Opacote de montador tambeme um arquivo "ZIP".
Descritor do Montador
Este descritor especi ca a montagem do componente (por exemplo: a descric~ao do
componente, conex~oes e o particionamento logico das inst^ancias). Inst^ancias dos
compo-nentes s~aoconectadas usando portas complementares. Odescritor referencia oarquivo de
cada componente e especi ca suas conex~oes atraves de asserc~oes como connectinterface e
connectevent (que est~ao contidas na declarac~ao connection). Isto representaa informac~ao
basica doprocesso de distribuic~ao.
Descritor de Propriedades
De ne os par^ametros de con gurac~ao do componente e do home.
E usado para
con- gurar uma inst^ancia do componente ou uma inst^ancia de um home, con gurando seus
atributos. Fornece propriedades padr~oes que podem ser substitudas pelo usuario. O
des-critor de propriedades pode conter quantas entradas forem necessarias. Estas entradas
podem ser de tr^es tipos: simple para con gurar um atributo do tipo simples; sequence
para con gurar um atributo de nido como uma sequ^encia de determinado tipo; e struct
2.2.5 Distribuic~ao de Componentes
Modelo de Distribuic~ao
Omodelodedistribuic~aoeoutracontribuic~aoimportantedomodeloCCM.Elefornece
uma forma de automatizar o espalhamento e instanciac~aode aplicac~oes distribudas. Ele
contribui para aumentar o reuso de software numa forma facil de uso e integrac~ao de
componentes existentes.
O processo de distribuic~aoe executado por uma ferramenta fornecida por uma
plata-forma CCM. Esta ferramenta distribui componentes e monta-os em um computador de
destino. Esta aplicac~aode distribuic~aoeum clientequeusaservicos oferecidospelos
obje-tos existentes emum stiode execuc~ao parainstalar, instanciar e con gurar componentes
e conex~oes. Os cincopassos basicos de distribuic~aos~ao:
1. De nire escolher um stio de execuc~ao,
2. Instalar implementac~oes onde foremrequeridas,
3. Instanciarservidores e container,
4. Instanciarhome ecomponentes, e
5. Conectar e con gurar componentes.
2.2.6 Execuc~ao de Componentes
Modelo de Execuc~ao
Um container e um ambiente de execuc~ao para inst^ancias de componentes CORBA.
Elefornecerecursos comomemoriaeCPU, bemcomorecursos de altonvelcomoservicos
de suporte. Inst^ancias de componentes s~aogerenciadas porum container. Uma inst^ancia
de um componente n~ao pode existir sem um container para suporta-la. Alem disso, um
tipo de container pode somente hospedar um unico tipo de componente para o qual foi
designado. Duas categorias de containers foramde nidas: transientes epersistentes.
2.3 Introduc~ao ao Modelo de Componentes CM-Tel
Do modelo CCM derivou-se um modelo de componentes mais simpli cado, chamado
CM-Tel. CM-Telmantem as principaisideias do modelo CCM eadiciona algunsservicos,
como suporte a mdias contnuas (Streams). O modelo proposto e similar ao CCM nos
seguintes aspectos:
Componentes podem de nirpropriedades;
Contudo, algumasdiferencas devemser mencionadas:
Componentes s~ao especi cados emXML;
AIDLepreservada,comistoaarquiteturadesuporteparaomodelodecomponentes
pode ser construdacom implementac~oes CORBAatuais;
Componentes podem manipular uxos de mdiacontnua;
Umaestrutura simpli cada para o container foi adotada.
Os elementosprincipaisdos componentes CM-Tel s~ao descritos a seguir:
Propriedades: de nem um conjunto de variaveis de estado usualmente relacionadas
com oestado econ gurac~aodocomponente. Propriedadespodem ser inspecionadas
e,caso haja privilegio, alteradas poroutro componente;
Produtoreseconsumidoresdeeventos: suportamatrocademensagensdenoti cac~ao
de formaassncrona com outroscomponentes;
Facetas: comonomodeloCCM,representamosaspectosfuncionaisdoscomponentes;
Receptaculos: como no modelo CCM, permitem armazenar refer^encias de
compo-nentes e objetos que um componenterequer;
Produtores e consumidores de uxo de mdias: suportam a troca de uxo de mdia
com outros componentes.
Oselementosacimalistadospodemseracessados atravesdasinterfacesdocomponente
especi cadas nalinguagem IDL convencional.
Propriedades permitem con gurac~oes din^amicas do componente. Por exemplo, um
componente apresentando vdeo pode de nir propriedades como formato da mdia, taxa
de quadros, tamanho dos quadros eo protocolo de transporte.
Eventoss~aoimplementadosde acordo como modelopush, onde componentes que
pro-duzemeventostomam aac~aode noti carcomponentes queatuam comoconsumidores do
mesmo evento. CM-Tel utilizao mesmo modelo proposto pelo CCM: emissor-consumidor
(emitter-consumer) e publicador-consumidor (publisher-consumer). No modelo
emissor-consumidor um relacionamento um-a-um conecta um objeto produtor a um unico objeto
consumidor. No modelo publicador-consumidor um relacionamento um-para-muitos
co-necta um objeto produtor a zero ou mais objetos consumidores. Neste modelo um canal
de eventos faz a intermediac~ao. O publicador envia seu evento ao canal de eventos que
distribuieste evento para cada consumidorconectado.
Fluxos de mdia contnua foramimplementados damesma formaque eventos. O
CM-Tel de ne dois esquemas para transmiss~ao de mdias contnuas: transmissor-apresentador
(transmitter-player)e difusor-apresentador (broadcaster-player). Otransmissor permite a
conex~aode um unicoapresentador de mdia. Odifusor permiteaconex~aode zerooumais
De nic~ao do Componente em XML
UmcomponentenoCM-Teleespeci cadoemXMLatravesdealgumasmarcac~oes(tags
XML),quepermitemade nic~aodeinterfacesdocomponentebemcomosuaspropriedades,
evitandocomissoousodeIDLsestendidasparaacomodarasnovasconstruc~oesnecessarias
para se especi car um componente. As marcac~oes XML s~ao:
componentfeatures - nomedocomponenteeseu identi cadornorepositoriode
inter-faces(Repository ID);
ports -composto das marcac~oes a seguir:
{ provides - facetas querepresentam os aspectos funcionais dos componentes;
{ uses-receptaculosqueprov^eemconex~oes paraousoderefer^encias(tipicamente
refer^encias de facetas);
{ transmits - produtor de uxo unicast de audio/vdeo;
{ broadcasts -produtor de uxo multicast de audio/vdeo;
{ plays - consumidorde uxo de audio/vdeo;
{ emits -produtores de eventos na formaum-para-um;
{ publishes - produtores de eventos na formaum-para-muitos;
{ consumes - consumidoresde eventos de um determinado tipo;
interface prov^eem interfaces CORBApadr~ao;
properties -de nic~ao de propriedades.
A partir das marcac~oes acima relacionadas podemos especi car um componente em
XMLesubmeterestaespeci cac~aoaumaferramentadegerac~aodecodigoqueiraproduzir
classes em Java, arquivos IDLs e um arquivo XML aderente ao padr~ao ant[15][16] para
compilac~ao. Com isso, o desenvolvedor n~ao necessita codi car a parte n~ao-funcional da
aplicac~ao,concentrando-se somentena logicarealizadapelocomponente.
XML
XML[17]e uma linguagem de marcac~aopara documentoscontendoinformac~oes
estru-turadas. Informac~oes estruturadascont^emtantoconteudo(palavras, guras, etc.) quanto
regras queindicam como oconteudo deve ser interpretado (porexemplo, conteudo de um
cabecalhopossui signi cado diferente de um conteudo em uma nota de rodape).
Uma linguagem de marcac~aoe um mecanismo para identi car estruturas em um
do-cumento. A especi cac~ao XML de ne uma formapadronizada de adicionarmarcac~oes ao
documento.
XML fornece uma forma de de nir marcac~oes (tags) e o relacionamento estrutural
NalinguagemHTML,tantoasem^anticadasmarcac~oesquantooconjuntodasmarcac~oes
s~ao xas. OW3C,emconjuntocomosvendedoresdenavegadoreseacomunidadeWWW,
trabalhaconstantementepara ampliar ade nic~ao doHTML e viabilizarnovasmarcac~oes
para acomodar as novas tecnologias emergentes naWeb.
HTML teve e tem um papel muito importante na disponibilizac~ao de informac~oes na
Web. Contudo, HTML possui algumas limitac~oes. Com a chegada de XML novas
carac-tersticas foram introduzidas, garantindo uma maior exibilidade, pois osdocumentos em
XML s~ao autodescritivos. Um exemplo de aplicabilidade do XML e o seu uso em
ferra-mentas de busca, quepermitecriteriosde selec~aomais re nados. XML pode ser utilizado
em navegadores que tenham a habilidade de entender as marcac~oes XML, utilizando
eX-tensible Stylesheet Language (XSL) para formatar os documentos. Tambem e possvel o
usodoXMLemtransac~oesbusiness-to-business,poremissorequerummecanismoqueleia
e interprete o documentoXML extraindoseus dados.
CadadocumentoXMLconsistedeelementosespec cosparaaqueletipodedocumento.
A gura 2.4 mostra a estrutura de um elemento XML. Um elemento contem uma marca
(tag) de incioe uma marca de nalizac~aoeo conteudo entre as marcas.
<primeiro_nome> Carlos </primeiro_nome>
Elemento
conteudo
tag final
tag inicial
Figura 2.4: Estrutura de um elemento XML.
Qualquer elemento pode conter atributos. Atributos s~aode nidos dentro damarca de
inciodoelemento como sepode verno exemplo aseguir.
<primeiro_nome sexo = "masculino"> Carlos </primeiro_nome>
|---|
Atributo
Cadaatributoeumpar nome-valor. Ovalordoatributodeveser usadoentreaspas duplas
(").
DTD
Um Documento de De nic~aode Tipo - DTD(Document Type De nition)deve
acom-panharumdocumentoXMLparavalida-lo. ODTDcontemaestruturade umdocumento
XMLetodasasregrasarespeito dosrelacionamentosentre elementoseregrasparticulares
para os elementos. O DTD expressa a hierarquia e o aninhamento dos elementos dentro
Um elementoe de nido no seguinteformato <!ELEMENT nome do elemento>.
Umelementopode conter subelementos queser~ao colocadosentre par^enteses e
lista-dos aposo nome doelemento.
Cada subelementodeve obedecer asseguintes regras:
{ sem caractere especial -deve ocorrersomenteuma vez;
{ asterisco(*) - ocorre zero oumais vezes;
{ interrogac~ao(?) - pode ocorrer zero ouuma vez;
{ mais (+) -deveocorrerpelomenos uma vez oumais vezes.
Os atributos s~ao de nidos em uma lista usando o seguinte formato <!ATTLIST>.
Um atributoeusado para adicionarsigni cado a uma marcac~ao emparticular e deve ser
de nido no DTD.
<!ELEMENT catalogo (nome,item*)>
<!ATTLIST catalogo estacoes
(inverno|primavera|verao|o uton o) #REQUIRED>
...
No exemplo acima, o catalogo possui um atributo estac~oes que pode ter os valores
inverno, primavera, ver~ao ou outono. Neste caso em particular, um valor e obrigatorio
devido a palavra reservada #REQUIRED. #PCDATA (Parsed Character Data) indica
que osdados ser~ao dotipocaractere (texto).
2.4 Resumo do Captulo
Neste captulo foram apresentados de forma resumida os principais modelos de
com-ponentes n~ao proprietarios que nortearam nossa pesquisa, como, Enterprise JavaBeans,
CORBA Component Model e omodelo CM-Tel queoriginouaferramentaccmBuilder
ob-jeto desta dissertac~ao. No captulo seguinte iremos abordar a arquitetura de suporte do
modeloCM-Tel,a implementac~aodas interfacesdos componentes, ocontainer eomodelo
Projeto da Ferramenta ccmBuilder
Este captulo descreve a arquitetura de suporte do modelo de componentes CM-Tel,
seus elementos funcionaise aestrategia de gerac~ao de codigopara este modeloatraves da
ferramenta ccmBuilder.
3.1 Arquitetura de Suporte do Modelo CM-Tel
Arquitetura de suporte do modelo de componentes CM-Tel segue um padr~ao de
ar-quitetura de n-camadas sugerido por Szyperski[18 ][19] e representado na gura 3.1. A
ideia e posicionar os componentes na primeira camada e adicionar quantas camadas
fo-rem necessarias para suportar a integrac~ao entre os componentes. Umcomponente exp~oe
um conjunto de interfaces com operac~oes para manipular seus metodos, suas
proprieda-des, eventose uxos de mdia. Operac~oes nas interfaces s~aofornecidas atraves de objetos
CORBA. Com excec~ao dos metodos contendo alogica da aplicac~ao, todos os objetos
res-tantesquesuportamasinterfacesdoscomponentess~aogeradospelaferramentaccmBuilder
a partirda especi cac~ao docomponente.
A segunda camada e o framework de componentes que ira fornecer toda a
infra-estrutura necessaria para o componente posicionado na primeira camada. Por exemplo,
umcomponentequepossuiumainterfacequedifunde eventos(Publisher)iranecessitarde
umservicoquerealizeadifus~ao(canalde eventos) sendoqueeste servicoedisponibilizado
no framework de componentes. Os servicos suportados pelo framework de componentes
s~ao:
Fabricas para instanciar os componentes;
Localizadores( nders)queir~aoretornararefer^enciadasinterfacesdoscomponentes;
Facilidadespara manipular aspropriedades de componentes;
Infra-estrutura para a interconex~ao de componentes.
Asfacilidadesparaainterconex~aodecomponentess~aofornecidaspelosservicosCORBA
correspondentes. OsseguintesservicosCORBAs~aofornecidosnasegundacamada: Servico
de Propriedades, Servico de Eventos eServicode Stream de
Integraçao
Framework de
Suporte de
Runtime
Componente
Componentes
Framework de
Figura 3.1: Arquiteturade 3camadas para suportar omodelo de componentes.
A segunda camada consiste de varias bibliotecas (arquivos jar), onde cada servico
CORBA esta disponvel, ou seja, todas as classes necessarias para a implementac~ao
des-tes servicos. Adicionalmente, uma biblioteca gerada para cada componente armazena a
implementac~aodas fabricas dos componentes eseus localizadores.
Finalmente, a terceira camada consiste de um framework de integrac~ao fornecendo
funcionalidade de interoperac~ao entre as outras camadas. Um ORB CORBA ira realizar
estas func~oes de interoperabilidade.
Diferentemente do modelo CCM, CM-Tel de ne um DTD (Document Type
De ni-tion) paraespeci car componentes CORBAemXML. A especi cac~aode um componente
comeca com o elemento raiz corbacomponent. Em seguida o nome do componente e
de- nido no elemento componentfeatures. O elemento componentfeatures tem um elemento
lho importante, chamado de porta (port). O elemento porta ira especi car as interfaces
do componente. A seguir, e mostrado um fragmento de um arquivo XML utilizado para
especi carum componentesegundo omodelo CM-Tel.
<?xml version="1.0"?>
<!DOCTYPE corbacomponent SYSTEM "ccm.dtd">
<corbacomponent>
<componentfeatures name = "ccmVideoFone"/>
Emseguidairemos detalhara implementac~aodasinterfacesde componentes utilizados
3.2 Implementac~ao das Interfaces de Componentes
As interfaces de componentes s~ao referenciadas como portas, e s~ao dividas em tr^es
grandes classes: interfaces operacionais, interfaces de sinalizac~ao e interfaces de uxos
de mdias, tal como de nidas no Reference Model for Open Distributed Processing
(RM-ODP). Onosso modeloapresenta oitotiposde portas: facetas, receptaculos, originadores
de eventos, consumidoresde eventos, produtoresde uxo de mdia, consumidoresde uxo
de mdia, interface equivalentee elementos de con gurac~ao (propertyset).
Dentrodeste modelo, o suporte as interfaces possui um padr~ao onde uma fabrica
ins-tancia o servant CORBA que implementa a interface. O servant podera usar servicos
CORBA e podera interagir com objetos da aplicac~ao atraves de metodos locais para a
interac~ao com a porc~ao da aplicac~ao executando no mesmo espaco de enderecamento do
servant (container) . A gura3.2 exempli caomodelode uma interface.
Aplicação
Servant
CORBA
Serviço
instancia
interface
usa
interage
Fábrica
Figura 3.2: Arquiteturade uma interface.
A ferramenta ccmBuilder gera varias classes Java, interfaces IDL e um arquivo XML
que sera utilizadopelaferramentaAnt[15][16]. Na gura 3.3podemos notar tr^es tipos de
arquivos: IDL,Javae XML.
Os arquivos geradosem IDL s~ao:
interface equivalente - de ne operac~oes comuns a todos os componentes, como por
exemplo, obter a refer^encia das demais portas. Esta interface e a propria refer^encia
docomponente;
interface das portas - facetas, receptaculos, originadores de eventos, consumidores
de eventos, produtores de uxo de mdia e consumidores de uxo de mdia. Estas
interfaces viabilizama composic~aoentre componentes;
Makefile
(Ant)
Componente
(XML)
Java
XML
IDL
Fábrica do componente
Fábrica das portas
Servants das interfaces
Classes utilitárias
(Manipulação de propriedades
localizador do componente)
Interface equivalente
Interfaces das portas
Interfaces dos elementos
de configuração
Figura3.3: Arquivosgerados peloccmBuilder para um componente.
propriedadesdeclaradas para o componente.
Os arquivos geradosem Java consistem de:
fabricadocomponente-afabricadocomponenteeresponsavelpelociclode vidado
componente atravesde operac~oes de criac~ao,destruic~ao eo registro do componente
nainterface equivalente;
servants das interfaces IDL -implementam os metodos das portas;
fabricas das portas - instanciam os servants das portas de um componente;
classesutilitarias-s~aoutilizadaspeloclientedocomponente. Olocalizadordo
com-ponentedescobre arefer^enciadocomponenteatravesde umachave. Os
manipulado-resde propriedadess~aoclassesquepermitemamanipulac~aodepropriedades(leitura
e alterac~ao dos valores das propriedades).
OscodigosgeradospelaferramentaccmBuilderobedecemaumaregradenomenclatura
queconsistenaobtenc~aodonomedocomponenteenomedaporta apartirde umarquivo
XML. Os codigos s~ao compostos de nome do componente mais tipo de operac~ao a ser
realizada, ou nome da porta mais o tipo de ac~ao que a porta ira realizar. Observemos o
exemplo aseguir para uma melhor compreens~ao:
<componentfeatures
name = "VideoTransmitter"
repid = "IDL:VideoTransmitter:1:0 ">
<ports>
transmitsname = "videoTr"
mediatype = "video">
</transmits>
</ports>
</componentfeatures>
OarquivoXMLanteriormenteilustradoespeci caumcomponentequeiraimplementar
uma porta originadora de vdeo. O nome do componente ilustrado e VideoTransmitter
que sera composto com CCM.idl, Factory.java, Finder.java, Home.idl, HomeServant.idl,
Servant.java. Da mesma formaocorre com o nome daporta que neste exemplo e videoTr
e sera composto com Factory.java e <tipo da porta>Servant.java. Por exemplo, afabrica
do componentepara este exemplo seria VideoTransmitterFactory.java e a implementac~ao
daporta teria onome de videoTrTransmitterServant.java.
A seguir ser~ao detalhadas as interfaces (portas) propostas neste modelo.
Interface Equivalente
A interface equivalentee uma interface especial que de ne operac~oes comuns a todos
os componentes, como por exemplo obter a refer^encia de uma porta (provide<nome da
porta>), obter uma chave primaria (get primary key), obter o home de um componente
(get ccm home) e obter um indicativo de que a con gurac~ao esta completa (con gur
a-tion complete). A fabrica da interface equivalente e a propria fabrica do componente. A
gura 3.4 ilustra aarquitetura de uma interface equivalente.
instancia
videoTr
videoTrHomeServant
videoTrServant
Figura3.4: Arquitetura dainterface equivalente.
A seguir, pode-se observar um arquivo IDL gerado pelo ccmBuilder onde a interface
// Sun Aug 04 17:42:48 PDT 2002
// the component's equivalent facet
interface VideoTransmitter: Components::CCMObject{
// ports
videoTrTransmitter provide_videoTr();
};
Porta PropertySet
A porta PropertySet e um elemento de con gurac~ao, que permite que determinadas
propriedades possam ser con guradas em tempo de execuc~ao. A porta de propriedadese
especi cada emXML epode ser composta de tr^estiposbasicos: simple, sequence estruct.
Otiposimple iraespeci carumapropriedadede umdeterminadotipo,comoporexemplo:
<simple name = "Enabled" type = "boolean" rigths = "normal">
Neste exemploestamoscriandouma propriedadechamadaEnabled dotipoboleanaecom
direito de escrita e leitura (a opc~ao rights pode assumir os valores normal para leitura e
escrita oureadonly somente para leitura).
O tipo sequence especi ca uma propriedade que consiste de uma sequ^encia de um
determinadotipo,como porexemplo:
<sequence name = "RGB_Cor" type = "sequencia de cores"
rights = "normal">
<simple name = "red" type = "float"> <value> 0.0</value> </simple>
<simple name = "green" type = "float"> <value>10.0</value> </simple>
<simple name = "blue" type = "float"> <value>20.0</value> </simple>
</sequence>
Como podemos ver no exemplo anterior, o arquivo XML especi ca uma propriedade
chamada RGB Cor, que consiste emuma sequ^encia de numeros emponto utuante, com
direito de leitura eescrita.
O tipo struct ira especi car uma estrutura que podera ser composta de varios tipos
simple. A seguir podemos observar um fragmento de um arquivo XML exempli cando o
tipostruct.
<struct name="Estat" type="EstatStruct" rights="normal">
<description>Estatistica s</ desc ript ion>
<simple name="uso" type="float"><value>0.0 </va lue> </si mpl e>
<simple name="erros" type="short"><value>0</va lue> </si mpl e>
Neste exemplo, foi especi cada uma estrutura chamada Estat composta de um tipo
EstatStruct agregando um tipo oat (uso), um tiposhort (erros)e um tipostring
(arqui-vos). Amarcac~ao<description>permiteumabrevedescric~aodaestruturaqueestasendo
gerada.
Um exemplo completo de uma especi cac~ao em XML para uma propriedade do tipo
simple eapresentado a seguir.
<componentfeatures
name = "ChatInterface"
repid = "IDL:ChatInterface:1.0">
<properties propertiesname = "ChatIntProps">
<simple name = "Enabled" type = "boolean" rights = "normal">
<description>Enables the chat interface when set to true</description>
<value>false</value>
</simple>
</properties>
</componentfeatures>
A gura 3.5 exempli ca a arquitetura de uma porta de propriedades (PropertySet)
mostrando seu processo de criac~ao. A fabrica da porta (ChatIntPropsFactory) utiliza
a interface PropertySetFactory para instanciar a interface PropertySetFactory, ambas do
servico de propriedades CORBA. Na instanciac~ao s~ao passadas as propriedades iniciais
de nidas para o componenteobtidas naclasse InitialPropertySet. A interface PropertySet
e a porta de propriedades oferecida pelo componente. Para manipular as propriedades a
aplicac~aonecessita de metodos get/set fornecidos pelaclasse ChatIntProperties.
A seguir apresentaremos um fragmento docodigo Java geradopara manipular as
pro-priedades. S~ao criados dois metodos getEnabled e setEnabled; o primeiropermiteobter o
valorda propriedade,enquanto o segundo possibilitaalterar ovalor dapropriedade.
public class ChatInterfaceProperties {
... boolean getEnabled () throws PropertyNotFound, InvalidPropertyName { try { org.omg.CORBA.Any value;
value = ps.get_property_value("Ena bled ");
return (value.extract_boolean( ));
}
Aplicação
Serviço de
Propriedades
CORBA
InitialPropertySet
ChatIntPropsFactory
PropertySet
PropertySetFactory
usa
ChatIntProps
instancia
usa
Figura 3.5: Arquiteturada interface PropertyService.
void setEnabled (boolean _value)
{
org.omg.CORBA.Any value =
ORB.init().create_any();
value.insert_boolean((boo lea n) _value);
ps.define_property("Enabl ed" , value);
}
}
Porta Transmitter
A porta Transmitter e uma porta produtora de uxo de mdia, que permite a
trans-miss~ao de audio/vdeo para uma porta receptora de nida emoutro componente.
A seguire apresentado um fragmentode codigo XML que ilustra as marcac~oes (tags)
necessarias para representar uma porta transmitter. O atributo transmitsname ira
for-necer o nome da porta, enquanto o atributo mediatype indica o tipo de mdia que sera
transmitida.
<ports>
<!-- video transmitter port -->
