Ferramenta de Implementação Física CCM-tel

A Figura 4.7 ilustra os elementos da implementação física da plataforma CCM-tel (ferramenta CCMtel-Builder). CCMtel-Builder realiza o modelo de implementação física descrito na Seção 3.5 e consiste, basicamente, de uma máquina de transformações e de uma máquina de construção de código.

Serviços e Facilidades CORBA ORB CORBA

Código Java

Máquina Virtual Java

Classes Java (JAR)

Classes Java (JAR)

Objetos Java

Stubs e Skeletons CORBA

SUPORTE DE EXECUÇÃO FRAMEWORK DE COMPONENTE COMPONENTE CM−TEL FRAMEWORK DE AGENTE DE INTEGRAÇÃO FRAMEWORK AGENTE CM−TEL

Fig. 4.6: Arquitetura da plataforma CCM-tel.

Máquina de Transformações

A máquina de transformações, que implementa as transformações descritas na Seção 4.2.3, con- siste de dois subsistemas de software: um analisador XML e um processador XSLT. A máquina de transformações opera da seguinte maneira. O analisador XML valida o documento de entrada de acordo com o XML Schema estabelecido para este documento. Se a validação for bem sucedida, a ár- vore do documento associada ao arquivo de entrada XML é percorrida pelo analisador. O analisador seleciona, para cada nó na árvore, o conjunto de folhas de estilo assinalados a este nó. Esta seleção se dá com o auxílio de um arquivo de configuração em forma de tabela. A chave de acesso da tabela é o nome do nó (marcação XML) e os valores associados à chave são os arquivos correspondentes às folhas de estilo. Para cada folha de estilo associada ao nó, o analisador invoca o processador XSLT para transformar o documento XML de entrada de acordo com as regras de transformação presentes na folha de estilo. A título de exemplo, suponha o processamento de um documento XML especifi- cando um componente CM-tel que define uma porta transmissora de mídia contínua. O analisador XML ao encontrar o nó de nome transmitter invoca duas transformações no documento XML, uma para gerar a implementação e outra para gerar a fábrica da porta transmissora.

As transformações são conduzidas em duas etapas. Na primeira etapa, a máquina de transfor- mação determina se o arquivo de entrada é um arquivo XMI. Caso seja, o conjunto de folhas de estilo referentes à transformação especificação-projeto (Seção 4.2.3) é aplicado ao documento de entrada. Como resultado, tem-se um arquivo XML de saída contendo a representação do componente ou con-

Java, IDL XML HTML, BAT Processador Analisador XML XSLT Código Fonte Construção XMI Especfição−Projeto Folhas de Estilo XSLT Projeto−Impl. Fisica XML Schema Arquivos de Instalação Arquivos de Instalação Máquina de Transformações de Código (Ant) Compilador e Utilitários Java (IDL Java) ORB CORBA Serviços CORBA Máquina de Comuns Serviços (Xerces) (Xalan) de Entrada Especificação Arquivo de Construção JAR

Fig. 4.7: Elementos da ferramenta CCMtel-Builder.

têiner CM-tel. Tendo este arquivo como entrada (ou o arquivo original, caso o mesmo não seja um arquivo XMI), a máquina de transformações inicia a segunda etapa, aplicando o conjunto de folhas de estilo referentes às transformações projeto-implementação física (Seção 4.2.3) ao documento de entrada. Esta etapa produz arquivos contendo código fonte, arquivos de construção e arquivos de distribuição JAR. Adicionalmente, na segunda etapa, o descritor de distribuição no formato XML é transformado para um formato adequado para a tecnologia, no caso HTML e BAT.

A plataforma CCM-tel utiliza em sua máquina de transformações o analisador XML Xerces2 e o transformador XSLT Xalan, ambos disponibilizados pelo projeto Apache2. Xerces2 e Xalan são es- critos em Java e considerados como as ferramentas mais versáteis para processamento de documentos XML.

Máquina de Construção de Código

A máquina de construção de código processa o código fonte gerado pela máquina de transfor- mação. Este processamento consiste na compilação, empacotamento e assinatura de código. A Figura 4.8 ilustra o processo de construção de código.

A plataforma CCM-tel utiliza a ferramenta de construção Ant do projeto Jakarta3_{, um sub-projeto}

do projeto Apache. Ant é ferramenta tipo make escrita em Java e independente do shell do sistema

2_{http://www.apache.org/}

build.xml Empacotador (jar) Stubs e Skeletons Portáveis (Fábricas e Portas) Implementações (IDL) Componente Interfaces do (javac) Compilador Compilador IDL (idlj) Implementações das Facetas (Java) (Java) Máquina de Código Geração de Framework de Componentes desenvolvedor suprido pelo ANT

Fig. 4.8: Processo de construção do código executável.

operacional. Ant utiliza um arquivo XML para conduzir o processo de construção de código (de- pendências, parâmetros de compilação e empacotamento, etc.).

A máquina de construção de código utiliza ainda um compilador IDL (idlj), um compilador Java (javac), um empacotador (jar) e um assinador de código (jarsigner). Todas estas ferramentas fazem parte da plataforma Java (J2SE). Além do código gerado, a máquina de construção de código emprega ainda pacotes Java que implementam o ORB, os serviços comuns e os serviços e facilidades CORBA.

Código Gerado

A Figura 4.9 ilustra a interface da ferramenta CCMtel-Builder com arquivos de entrada de com- ponentes, contêineres e descritores de distribuição especificados em XML ou XMI, a partir dos quais o código é gerado.

A ferramenta CCMtel-Builder gera os seguintes artefatos de software para suporte a componentes:

1. interfaces IDL que especificam:

• a interface equivalente do componente;

Fig. 4.9: Interface da ferramenta CCMtel-Builder [2].

• a fábrica do componente (ComponentHome);

2. classes Java que implementam:

• as interfaces IDL citadas acima, denominadas serventes (servants) CORBA (interface equivalente, portas, elemento de configuração e fábrica do componente);

• as fábricas para cada um dos serventes CORBA;

• facilidades para manipulação das propriedades definidas pelos elementos de configuração do componente;

• facilidades para localizar instâncias do componente especificado em contêineres (classe tipo Finder que retorna a referência da interface equivalente de um componente dado o seu contêiner e chave primária).

Para o suporte a contêineres CCM-tel, a ferramenta CCMtel-Builder gera os seguintes artefatos de software:

1. interfaces IDL que especificam:

• a fábrica (agência) do agente móvel (AgentHome).

2. classes que implementam:

• as interfaces IDL citadas acima (serventes CORBA);

• facilidades para manipulação das propriedades de configuração do contêiner;

• o contêiner especificado na forma de processo ou applet Java.

Estes artefatos uma vez compilados e empacotados formam o framework de componentes para o componente especificado.

A ferramenta CCMtel-Builder gera dois tipos de arquivos para a instalação de contêineres CCM- tel:

• arquivo de lote (shell scripts), para instalar contêineres baseados em processos;

• arquivo HTML, para instalar contêineres baseados em applets Java.

Finalmente, a ferramenta CCMtel-Builder gera um arquivo XML (build.xml) utilizado pela ferra- menta Ant para a construção do código gerado.

Nomenclatura para o Código Gerado

As regras para a convenção de nomes para os artefatos de software gerados a partir da especifi- cação de componentes, contêineres e descritores de distribuição em XML fazem parte da especifi- cação do mapeamento CCM-tel. Tais regras estipulam como interfaces e classes são nomeadas.

Interfaces IDL

Para um componente CCM-tel são especificadas interfaces IDL para a fábrica, as portas, ele- mento de configuração e interface equivalente do componente. Tais interfaces são definidas no es- copo de um módulo cujo nome é formado acrescentando-se o sufixo Component ao tipo do compo- nente (dado pelo atributo type da especificação XML do componente). O nome da fábrica é formado acrescentando-se o sufixo Home ao tipo do componente. Excetuando-se os receptáculos, as interfaces das portas e elementos de configuração são nomeados com o próprio nome destes elementos (dados pelo atributo name da especificação XML). Finalmente, o nome da interface equivalente coincide com o tipo do componente.

As operações para estas interfaces são definidas conforme o modelo de projeto CM-tel descrito na Seção 3.3. Uma pequena alteração foi introduzida na definição das operações. Esta alteração consiste

em “tipificar” as operações de navegação (provide) e de conexão entre portas (connect, disconnect, etc.). A estas operações é acrescentado o nome da interface (separado pelo caractere _). Esta mo- dificação contribui para a robustez do código gerado (a manipulação incorreta destas operações são detectadas em tempo de compilação) além de eliminar o parâmetro das operações tipo provide.

Por exemplo, associando as regras aos valores obtidos da especificação XML para o componente CM-tel de tipo C_Comp, conforme descrito na Seção 3.3.2 e que define a porta transmissora de vídeo

TR_VideoCamera com padrão de interação ponto-ponto, são proporcionadas as seguintes interfaces

IDL e operações:

module C_CompComponent {

interface C_CompHome { ... }; // fábrica do componente

interface C_Comp { // interface equivalente

TR_VideoCamera provide_TR_VideoCamera(); };

interface TR_VideoCamera { // porta transmissora de vídeo

connect_TR_VideoCamera ( ... ); disconnect_TR_VideoCamera ( ... ); };

};

Adicionalmente, construções IDL são geradas para os tipos de eventos e propriedades declarados na especificação do componente. Eventos declarados pelas portas de sinal são mapeados em objetos por valor (valuetypes) IDL com os mesmos atributos definidos na especificação dos eventos. No caso de elementos de configuração, as propriedades tipo struct e sequence são mapeadas para IDL utilizando-se as construções IDL struct e sequence. Propriedades tipo simple são mapeadas para os tipos IDL correspondentes (octet, long, etc.).

Classes Java

As convenções de nomes para as classes Java geradas a partir da especificação em XML de um componente são:

• implementações das interfaces têm o sufixo Servant.java, acrescentado ao nome da interface;

• implementações da interface equivalente têm o sufixo Servant.java, acrescentado ao tipo do componente;

• implementações das fábricas de componentes têm o sufixo HomeServant.java, acrescentado ao tipo do componente;

• fábricas de componentes, portas e elemento de configuação têm o sufixo Factory.java, acres- centado ao tipo do componente, nome da porta ou nome do elemento de configuração;

• localizadores de componentes têm o sufixo Finder.java, acrescentado ao tipo do componente;

• classes de manipulação de propriedades de componentes têm o sufixo Properties.java, acres- centado ao nome do elemento de configuração.

As operações de manipulação de propriedades do componente também foram “tipificadas” acres- centando-se o nome da propriedade a estas operações. Por exemplo, associando as regras aos valores obtidos da especificação XML para o componente CM-tel de tipo C_Comp, que define o elemento de configuração Conf e a propriedade background de tipo string, conforme descrito na Seção 3.3.2, é apresentado:

public class ConfProperties { String getbackground() { ... }

void setbackground(String _value) { ... } }

As convenções de nomes para as classes Java geradas a partir da especificação em XML de um contêiner são:

• a classe que implementa as funcionalidades do contêiner tem o sufixo Container.java, acres- centado ao tipo do contêiner.

• a classe executável para o caso do contêiner ser instalado como processo tem o sufixo Server.java, acrescentado ao tipo do contêiner.

• a classe executável para o caso do contêiner ser instalado como applet tem o sufixo Server-

App.java, acrescentado ao tipo do contêiner.

As convenções de nomes para os arquivos de instalação gerados a partir da especificação em XML de um descritor de distribuição são:

• arquivo de instalação para o caso do contêiner executar como um processo tem o nome do campo de extensão bat acrescentado ao nome do arquivo especificado em XML.

• arquivo de instalação para o caso do contêiner executar como uma applet tem o nome do campo de extensão html acrescentado ao nome do arquivo especificado em XML.