ficar a infra-estrutura de montagem, empacotamento e implanta¸c˜ao atrav´es do ambiente
distribu´ıdo [34].
Como n˜ao h´a uma defini¸c˜ao padr˜ao para um modelo de componentes, diversas em-
presas, organiza¸c˜oes e centros de pesquisas propuseram o seu pr´oprio modelo. Entre os mais difundidos atualmente est˜ao o Enterprise JavaBeans (EJB) [6], o Component Ob-
ject Model (COM) [7] e o CORBA Component Model (CCM) [8], sendo que este ´ultimo ´
e o mais gen´erico, pois n˜ao est´a vinculado a nenhuma plataforma ou linguagem de pro-
grama¸c˜ao espec´ıfica.
2.3 CORBA COMPONENT MODEL - CCM
O CCM ´e a especifica¸c˜ao sobre componentes da OMG (Object Management Group),
cuja primeira vers˜ao surgiu em 2002 com o lan¸camento do padr˜ao CORBA 3.0. As caracter´ısticas de um componente CORBA s˜ao compat´ıveis com as definidas por Szyper-
sky [28]. De acordo com o CCM, um componente ´e um meta-tipo b´asico, que estende e especializa o meta-tipo objeto do padr˜ao CORBA. A linguagem de especifica¸c˜ao dos
componentes ´e a Interface Definition Language (IDL).
Os componentes CCM podem interagir com seus clientes atrav´es das seguintes portas:
• Facetas (facets) - interfaces nomeadas que s˜ao fornecidas pelo componente para intera¸c˜ao com os demais;
• Recept´aculos (receptacles) - pontos de conex˜ao identificados que descrevem a habil- idade do componente em usar uma referˆencia fornecida por um outro componente;
• Fontes de eventos (event sources) - pontos de conex˜ao identificados que emitem eventos de um tipo espec´ıfico para determinados consumidores de eventos ou para um canal de eventos;
• Consumidores de eventos (event sinks) - pontos de conex˜ao identificados aos quais eventos de um tipo espec´ıfico s˜ao enviados;
• Atributos (attributes) - valores identificados expostos atrav´es de opera¸c˜oes de acesso ou altera¸c˜ao.
O CORBA define em seu modelo dois tipos de componentes: b´asico e estendido. Um componente b´asico ´e apenas um meio de transformar um objeto em um componente e n˜ao
oferece nada al´em de seus atributos. Por outro lado, os componentes estendidos oferecem um conjunto maior de funcionalidades, podendo oferecer qualquer tipo de porta aos seus
clientes. O termo componente ser´a utilizado neste texto para se referir ao componente estendido. Em IDL, os componentes s˜ao declarados atrav´es da palavra-chave component
e devem possuir um nome para definir o seu tipo.
Para cada componente, ´e definido um component home, respons´avel por gerenciar as
instˆancias deste componente. O component home tamb´em ´e um meta-tipo e deve ser declarado para cada declara¸c˜ao de componente. Pode-se declarar mais de um tipo de
home para gerenciar o mesmo tipo de componente, por´em eles n˜ao podem gerenciar as mesmas instˆancias deste componente.
Figura 2.2. Pontos de conex˜ao de um componente de acordo com o CCM [2].
Para o CCM, as portas de um componente possuem um nome e um tipo definido, por
exemplo, um componente pode ter duas ou mais facetas de um mesmo tipo, por´em com nomes (identificadores) diferentes. Al´em disso, os componentes por si pr´oprios definem
tipos e podem ser herdados por outros componentes, isto ´e, ´e poss´ıvel um componente possuir as mesmas interfaces de outro componente atrav´es de uma rela¸c˜ao de heran¸ca.
2.3 corba component model - ccm 20
facetas (facets). Este tipo de porta ´e o principal meio de expor as funcionalidades do
componente durante a execu¸c˜ao. Um componente por ter zero ou mais facetas, as quais s˜ao declaradas atrav´es da palavra-chave provides.
Os recept´aculos (receptacles) s˜ao os pontos de conex˜ao atrav´es dos quais um compo- nente pode invocar opera¸c˜oes. Um tipo de componente pode ter zero ou mais recept´aculos,
os quais s˜ao declarados pela palavra-chave uses. Um recept´aculo pode ainda ser do tipo simplex ou multiplex. O tipo simplex permite apenas uma conex˜ao com o componente,
enquanto que o tipo multiplex pode permitir qualquer n´umero de conex˜oes ou at´e um certo limite, definido pela implementa¸c˜ao do componente. Se o limite de conex˜oes for
atingido, uma exce¸c˜ao ´e levantada durante a execu¸c˜ao.
As fontes de eventos (event sources) s˜ao portas utilizadas para gerar eventos de um
determinado tipo e podem ser classificadas em duas categorias: emitters e publishers. As fontes do tipo emitter podem enviar eventos para no m´aximo um consumidor de eventos.
Por outro lado, as fontes do tipo publisher podem estar conectadas, atrav´es de um canal, a v´arias consumidores, que se “inscrevem” (subscribe) para receber os eventos daquela
fonte. Um componente pode possuir zero ou mais publishers e emitters, os quais s˜ao declarados pelas palavras-chave publishes e emits, respectivamente.
Os consumidores de eventos (event sinks) s˜ao as portas utilizadas pelos componentes para receber eventos de um determinado tipo. Ao contr´ario das fontes, os consumidores de
eventos n˜ao s˜ao classificados em categorias e podem receber eventos de qualquer n´umero de fontes. Um tipo de componente pode ter zero ou mais consumidores de eventos, os
quais s˜ao declarados pela palavra-chave consumes.
O servi¸co de eventos ´e fornecido aos componentes e seus clientes atrav´es da imple-
menta¸c˜ao do container no qual o componente ´e executado. Dessa forma, ´e responsabil- idade deste container fornecer os mecanismos necess´arios para o funcionamento deste
servi¸co e determinar a qualidade de servi¸co e pol´ıticas de roteamento para a entrega dos eventos.
1 i n t e r f a c e I S e n s o r { 2 long r e a d v a l u e ( ) ; 3 } ; 4 e v e n t t y p e alarm { } ; 5 component C o n t r o l l e r { 6 u s e s I S e n s o r s e n s o r ; 7 p u b l i s h e s alarm d a n g e r ; 8 a t t r i b u t e long s e t p o i n t ; 9 } ; 10 home C o n t r o l l e r H o m e manages C o n t r o l l e r { } ;
O c´odigo 2.1 apresenta um exemplo de declara¸c˜ao de um componente em IDL. Nas linhas 1-3, h´a a declara¸c˜ao de um tipo de interface (ISensor) com a assinatura de um
m´etodo (read value). A declara¸c˜ao de um tipo de evento (alarm) ´e feita na linha 4. Nas linhas 5-9, encontra-se a declara¸c˜ao do componente Controller. Este componente possui
um recept´aculo do tipo ISensor (sensor - linha 6), uma fonte de eventos multiplex do tipo alarm (danger - linha 7) e um atributo (set point - linha 8). A declara¸c˜ao do home
respons´avel por criar as instˆancias do componente Controller est´a definida na linha 10.