Implementação do Módulo da Federação

Embora o desenvolvimento da federação não seja o foco principal do trabalho, foi necessário implementar algumas funcionalidades básicas para garantir a operação da mesma e, consequentemente, a operacionalização completa do protótipo computacional. As subseções a seguir descrevem este conjunto mínimo de funcionalidades desenvolvidas.

5.2.6.1 Repositório de Ontologias

Fazem parte do repositório de ontologias, a ontologia de QoS e a ontologia de processos UBL. Conforme comentado no Capítulo 4, conceitualmente a construção da ontologia de processos UBL foi baseada na especificação Universal Business Language v. 2 (OASIS, 2006) e ocorreu em três etapas macros. A primeira compreendeu o estudo e análise da especificação UBL. A segunda contemplou a identificação dos atores e a interpretação dos diagramas responsáveis pelo detalhamento dos processos de negócios UBL.

Na terceira etapa, da construção da ontologia UBL, a ferramenta usada para edição foi o Protégé v. 4.0.2. A escolha do uso do Protégé recaiu sobre três fatores. O primeiro por ser um editor com funcionalidades intuitivas e estáveis. O segundo por ser um editor open source, gratuito e largamente usado na construção de ontologias. O terceiro por fornecer suporte à linguagem OWL 2 (Web Ontology Language) (W3C, 2009), padrão usado para descrição de ontologias.

Figura 57 - Classificação criada a partir do padrão UBL e escrita através do

Protégé.

A Figura 57 mostra a classificação criada a partir da especificação UBL. Nela, a classe UBL representa o nome da especificação de processos de negócio usada. A partir da classe UBL, diversas subclasses foram definidas (Ordering e Biling, por exemplo), representando a categoria do processo dentro da ontologia, conforme comentado na Seção 4.2.3.3.1. Para cada classe que define a categoria de um processo, criou-se uma subclasse que representa o nome do processo (OrderingProcess). Dentro de um processo, há atores que representam as partes que interagem com as atividades de um processo de negócios. Por exemplo, no processo OrderingProcess há dois atores BuyerParty e SellerParty, também representados por uma classe dentro da ontologia. No último nível hierárquico, há classes que representam as atividades executadas dentro de um processo, como por exemplo: AcceptOrderBuyerParty dentro do processo OrderingProcess.

A definição da subclasse OrderingProcess, que tem como super- classe Ordering, é exemplificada em OWL 2, conforme mostra a Figura

58. Para mais detalhes da versão da ontologia UBL em OWL, consultar o Apêndice A deste documento.

Figura 58 - Definição das classes Ordering e OrderingProcess em OWL 2. Como comentado na Seção 4.2.3.3.1, a construção da ontologia de QoS foi inspirada na ontologia proposta por Tondello (2008), a qual teve como base a definição de QoS (OMG, 2006).

Figura 59 – Ilustração da edição da ontologia de QoS usando Protégé.

A Figura 59 ilustra a edição da ontologia de QoS através do Protégé. No lado esquerdo, tem-se um conjunto de classes que formam a hierarquia da ontologia de QoS. No lado direito, mostra-se um exemplo de relacionamento entre a classe QoSCharacteristic e a classe QoSCharacteristicAttribute. O relacionamento hasCharacteristic faz a

associação de uma característica de QoS (no caso Performance) com os atributos que a formam (ExecutionTime, LatencyAttribute, ResponseTime, ThroughputAttribute e TransactionTime). Cabe salientar que, conforme já mencionado na Seção 4.2.3.3.1, há outros tipos de relacionamentos existentes que definem a ontologia de QoS. Por exemplo, o relacionamento que permite ligar um atributo de QoS a uma unidade de medida (segundos, percentual, etc).

A definição completa em OWL 2 da ontologia de QoS 2 pode ser consultada no Apêndice B deste documento.

5.2.6.2 Repositórios de Serviços

Os repositórios de serviços foram instanciados na forma de UDDIs. Concretamente, o projeto jUDDI da Apache (APACHE, 2010a) foi usado como implementação dos repositórios de serviços.

Além das informações sobre serviços, cada uma das jUDDIs criadas armazenam informações sobre os aspectos de qualidade (descritos na ontologia de QoS) dos serviços e informações sobre o contexto dos serviços (através da ontologia UBL). Na prática, foram criadas instâncias do elemento <tModel>, presente na estrutura de dados das jUDDIs, para representar e armazenar aspectos de QoS e o contexto associado aos serviços.

A Figura 60 descreve como estas instâncias representam valores de QoS. A primeira instância do elemento <tModel> armazena informações sobre uma dada característica de QoS (Accuracy). Dentro dele, tem-se o elemento <name> que informa o nome da característica, o elemento <description> que registra uma breve descrição da característica e o elemento <keyedReference> que armazena informações de controle usadas para representar informações de QoS.

A segunda instância do elemento <tModel>, ainda na Figura 60, armazena informações sobre o atributo GeneratedError, usado para determinar a característica Accuracy. As instâncias do elemento <tModel> se conhecem através da existência de um propriedade (keyvalue=”Accuracy”) presente no elemento <keyedReference > do elemento <CategoryBag>.

No elemento <CategoryBag>, da segunda instância do elemento <tModel> (Figura 60), agrupam-se os atributos que definem a característica Accuracy, determinada a partir do valor armazenado no

atributo GeneratedError (erros gerados) que, por sua vez, tem como unidade ErrorNumber (número de erros gerados).

Figura 60 - Exemplo de representação de QoS em uma jUDDI.

A Figura 61 ilustra valores da ontologia UBL representados em uma jUDDI através de instâncias do elemento <tModel>. O elemento <name> armazena e descreve a classificação UBL para um dado serviço. O elemento <description> representa esta mesma classificação em um formato que humanos podem compreender. O elemento <overviewDoc> informa a localização da interface que descreve o serviço e o elemento <categoryBag>, além das informações de controle, informa o contexto do serviço através do elemento <keyedReference> que representa e informa os efetivos valores que determinam a funcionalidade do serviço em relação à ontologia UBL.

Figura 61 - Exemplo de valores da ontologia UBL em uma jUDDI.

Definida a forma de armazenamento dos valores de QoS e dos valores da ontologia UBL nas jUDDIs, o passo posterior foi em direção a como representar os vários repositórios de serviços presentes na federação. A estratégia usada foi a de criar um arquivo no formato XML com nome de uddifederation_BusinessEntity.xml. O arquivo fica armazenado na jUDDI identificada por ubl-uddi, porque ela é a primeira jUDDI a ser criada e disponibilizada pela federação. A Figura 62 ilustra uma típica entrada no arquivo. Nele, cada elemento <businessService> contém informações sobre uma específica jUDDI. Além do nome e de uma breve descrição do repositório, o elemento <bindingTemplate> e <accessPoint> informam, respectivamente, o endereço e a porta de acesso à WSDL que especifica a interface dos serviços ofertados pela API da jUDDI, já que todas as jUDDIs são disponibilizadas como serviços web.