Como vários elementos da ontologia OWL-SOA já foram capturados através da fusão das ontologias OWL-S e WSMO, esta atividade visa capturar os elementos complementares para responder a todas as questões de competência.
Analisando as questões de competência provenientes da atividade de identificação de propósito e especificação de requisitos, as questões de competência 4 e 6 sobre os artefatos que compõem um serviço e as plataformas tecnológicas para a implementação de um serviço não foram respondidas completamente pela fusão das ontologias OWL-S e WSMO. Portanto, nesta fase é realizada a captura da ontologia visando responder a essas duas questões de competência.
4.2.3.1 Artefatos de desenvolvimento – Padrão RAS 2.2
Para responder totalmente à questão de competência 6, sobre os ativos de desenvolvimento associados a um serviço, foi utilizado o padrão RAS (Reusable Asset Specification). Segundo OMG (2005A), um ativo é um conjunto de artefatos que fornece uma solução para um problema em um determinado contexto. A especificação de ativos reutilizáveis RAS endereça os elementos de engenharia do reuso. Todo ativo possui um conjunto de artefatos que constituem o ativo (OMG, 2005A). Sendo assim, a classe Asset é a classe central da especificação RAS.
Conforme apresentado na seção 2.4, a especificação RAS define 4 grandes seções para descrever um ativo de software: Classification, Solution, Usage e Related Assets, conforme Figura 31.
No contexto da implementação de um repositório de serviços em uma arquitetura SOA, um serviço da ontologia OWL-SOA pode ser considerado um ativo da especificação RAS, dado que a própria especificação RAS realiza o mapeamento de um ativo com um Web Service em um de seus Profiles. Uma vez que, para o propósito desta ontologia, o ativo é um serviço, cada serviço é composto de uma solução assim como na especificação RAS um ativo é composto de uma solução (Solution). A especificação RAS atua como insumo para a identificação dos artefatos e seus tipos para serem incorporados à ontologia OWL-SOA.
Utilizando-se como base a especificação RAS 2.2, todo ativo (Asset) é composto por uma solução. Uma solução, por sua vez, é um conjunto de artefatos. Cada artefato (Artifact) é classificado em 4 tipos, de acordo com as disciplinas do processo de desenvolvimento de software. São eles: Requirements, Design, Implementation e Test. Dentre os possíveis tipos de artefatos de implementação, um tipo merece destaque devido à sua ampla ocorrência em arquitetura orientadas a serviço: os componentes (Component). Na operação de fusão 7 o conceito Interface foi incorporado à ontologia OWL-SOA. Sendo assim, a partir do enfoque do repositório em tempo de desenvolvimento, toda interface é implementada em um arquivo. Esse arquivo contém o código fonte da interface. A partir dessa análise, o conceito Interface foi incorporado como um sub-tipo do conceito ImplementationArtifact.
A Figura 32 apresenta o modelo da ontologia referente à questão de competência 6. Os conceitos contidos no retângulo cinza foram os conceitos provenientes na especificação RAS 2.2.
Figura 32 – Modelo ontológico para tratar os artefatos de desenvolvimento de um serviço
Além do conceito Artifact, todos os atributos referentes a um artefato na especificação RAS 2.2 foram incorporados como propriedades do conceito Artifact na ontologia OWL- SOA.
A partir desse modelo da ontologia OWL-SOA é possível definir o axioma apresentado no Quadro 8.
Quadro 8 – Axioma A11
Descrição do Axioma (A11) Todo serviço possui pelo menos um artefato do tipo ImplementationArtifact que o implemente
Expressão <owl:Class rdf:about="#Service"> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom> <owl:Class rdf:about="#ImplementationArtifact"/> </owl:someValuesFrom> <owl:onProperty> <owl:InverseFunctionalProperty rdf:ID="hasArtifacts"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf>
</owl:Class>
Conceitos Service, ImplementationArtifact
Relações hasArtifact
Portanto para responder totalmente à questão de competência número 6, foram utilizados os conceitos e propriedades, representados na Figura 32, e os axiomas A11.
4.2.3.2 Plataformas tecnológicas - Inclusão dos conceitos da literatura
Para responder totalmente à questão de competência 3, em qual tecnologia um determinado serviço esta disponível, foi pesquisado na literatura para verificar possíveis tecnologias para implementação dos serviços em uma arquitetura SOA.
Acerca do suporte da ontologia para várias linguagens de implementação dos serviços foram utilizadas as seguintes referências bibliográficas destacando a possibilidade da implementação de serviços em uma arquitetura SOA utilizando as linguagens FIX (Financial Information Exchange) (DUAN et al., 2005), JMS (Java Message Service) (SUN MICROSYSTEMS, 2002), Web Services, REST (Representational State Transfer) (PAUL e GOSH, 2006), CORBA (Common Object Request Broker Architecture) (OMG, 2000), EJB (Enterprise Java Beans) (SUN MICROSYSTEMS, 2005) e SBA (Space-Based Architecture) (XU et al., 2006).
Além da tecnologia de Web Services, outra tecnologia amplamente utilizada para implementação de serviços em uma arquitetura SOA é a tecnologia JMS (Java Message Service). JMS é uma API para suportar troca de mensagens entre dois clientes em uma arquitetura JAVA (SUN MICROSYSTEMS, 2002). Vários midleware de mercado suportam a tecnologia JMS para implementação de uma arquitetura SOA, tais como: WebSphere Application Server, BEA Weblogic e Oracle AQ, dentre outros.
A tecnologia FIX (Financial Information Exchange), por sua vez, é uma tecnologia para construção de serviços em uma arquitetura SOA específica para o mercado financeiro. Conforme Duan et al. (2005), é possível implementar SOA sem Web Services. Eles exemplificam esta implementação através da tecnologia FIX. O protocolo FIX foi projetado para fornecer um padrão que suporte à comunicação eletrônica de mensagens relativas a investimentos (DUAN et al., 2005).
A tecnologia de EJB (Enterprise Java Beans) foi projetada para suportar a construção de aplicações corporativas através de uma arquitetura de componentes processados e gerenciados no lado servidor (SUN MICROSYSTEMS, 2005). A tecnologia de EJB tem sido
utilizada para a construção de serviços em uma arquitetura SOA. Esses serviços podem ser expostos segundo a própria especificação EJB 3.0 (SUN MICROSYSTEMS, 2005).
CORBA (Common Object Request Broker Architecture) é um padrão de arquitetura definido pela OMG (Object Management Group) que possibilita que componentes de software construídos em múltiplas linguagens computacionais e sendo executados em múltiplos computadores, trabalhem em conjunto (OMG, 2000). Cada um desses componentes também pode ser visualizado como serviço, de acordo com OMG (2000).
O estilo arquitetural REST (Representational State Transfer) foi desenvolvido para tratar sistemas distribuídos através da Internet. A tecnologia REST refere-se estritamente a uma coleção de princípios de arquitetura em rede que definem como cada um dos recursos é definido e endereçado (PAUL e GOSH, 2006).
A tecnologia SBA (Space-Based Architecture) define um padrão de arquitetura de software para obter escalabilidade linear e statefull de aplicações de alto desempenho, utilizando o paradigma de tuplas espaçadas (XU et al., 2006). Essa tecnologia tem sido amplamente utilizada para implementação de arquiteturas orientadas a serviço que requerem alto desempenho e escalabilidade.
Na especificação OWL-S o conceito ServiceGrounding inclui as informações referentes à invocação dos Web Services. Como a ontologia OWL-SOA é independente de linguagem de implementação do serviço, o conceito ServiceGrounding se torna um super-tipo de conceitos específicos para cada uma das plataformas tecnológicas. Conforme definido por Duan et al. (2005), a implementação de uma arquitetura orientada a serviços independe da tecnologia de Web Services, apesar desta ser a mais utilizada atualmente. A Figura 33 apresenta o modelo da ontologia sobre a tecnologia de implementação dos serviços.
Todo serviço cujo ServiceGrounding é do tipo FIX é um serviço da área financeira, pois a plataforma tecnológica FIX é um padrão exclusivo do mercado financeiro. O axioma (A16) denota que toda instância de ServiceGrounding FIX possui um serviço associado a ele e este serviço possui uma relação do tipo importsOntology para uma metodologia do domínio financeiro4. Além disso, também foi definida uma propriedade supportedByFix que é específica entre os serviços e o ServiceGrounding FIX. Essa propriedade foi utilizada para a formalização do axioma A16.
Quadro 9 – Axioma A16 Descrição do
Axioma
(A16) Todo serviço associado ao ServiceGrounding do tipo FIX possui o conceito FinancialOntology associado
Expressão <owl:Class rdf:about="#FIX"> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="supportedByFix"/> </owl:onProperty> <owl:someValuesFrom> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="importsOntology"/> </owl:onProperty> <owl:allValuesFrom> <owl:Class rdf:ID="FinancialOntology"/> </owl:allValuesFrom> </owl:Restriction> </owl:someValuesFrom> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf> <owl:Class rdf:about="#ServiceGrounding"/> </rdfs:subClassOf> </owl:Class>
Conceitos FIX, Service, FinancialOntology Relações importsOntology, supportedByFix
Outra tecnologia específica para implementação dos serviços em uma arquitetura SOA é a tecnologia SBA. Conforme apresentado, um serviço implementado na tecnologia SBA
4 Na definição do axioma A16 assume-se a existência de uma ontologia de domínio do mercado financeiro,
deve suportar alta escalabilidade. Portanto, para um serviço possuir tecnologia de implementação SBA este deve possuir escalabilidade alta, que é uma propriedade não funcional, com valor igual à alta. O axioma de fechamento A17 suporta esta restrição para um serviço possuir implementação na tecnologia SBA. Esse axioma só se aplica para os serviços com ServiceGrounding na tecnologia SBA.
Quadro 10 – Axioma A17 Descrição
do Axioma
(A17) Uma instância do conceito Service implementado com o ServiceGrounding SBA deve ter associado uma instância do conceito NonFunctionalProperty com a propriedade Scalability igual a High.
Expressão <owl:Class rdf:about="#SBA">
<rdfs:subClassOf rdf:resource="#ServiceGrounding"/> <owl:equivalentClass> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:someValuesFrom> <owl:Class rdf:about="#Service"/> </owl:someValuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:ID="supportedBy"/> </owl:onProperty> </owl:Restriction> <owl:Restriction> <owl:allValuesFrom> <owl:Class rdf:about="#High"/> </owl:allValuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:ID="hasNonFunctionalProperties"/> </owl:onProperty> </owl:Restriction> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#supportedBy"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Service"/> </owl:someValuesFrom> </owl:Restriction> <owl:Restriction> <owl:allValuesFrom> <owl:Class rdf:about="#High"/> </owl:allValuesFrom>
<owl:onProperty> <owl:ObjectProperty rdf:about="#hasNonFunctionalProperties"/> </owl:onProperty> </owl:Restriction> </owl:intersectionOf> </owl:Class> </owl:intersectionOf> </owl:Class> </owl:equivalentClass> </owl:Class>
Conceitos SBA, Service, NonFunctionalProperty, High Relações hasNonFunctionalProperties, supportedBy
O axioma { incomplete } presente na Figura 33 denota que podem existir ou surgir outras tecnologias para implementação dos serviços. Através deste axioma a ontologia OWL- SOA esta aberta à incorporação de novas tecnologias de implementação dos serviços.
O modelo da ontologia completo está apresentado na Figura 34. A meta-ontologia de domínio associada à ontologia OWL-SOA esta representada na Figura 35. Por questão de simplificação não foram apresentadas as propriedades dos conceitos. O Apêndice B apresenta a ontologia completa com as propriedades. Como pode ser visualizada na Figura 34, a ontologia é constituída por um conceito central denominado Service. Este conceito contém as propriedades básicas de um serviço. Um serviço composto é constituído por outros serviços. A partir dessas relações e seus axiomas é possível responder a questão de competência 1, acerca da decomposição do serviço.
Cada serviço é exposto e acessado a partir de uma interface, representado a partir da relação entre o conceito Service e o conceito Interface. Através dessa relação e seus axiomas é possível responder a questão de competência 3.
Além disso, cada serviço pode fazer parte de um ou mais processos de negócio, e cada processo de negócio pode estar associado a um ou mais serviços. A relação do conceito Service com o conceito BusinessProcess acrescida de seus axiomas endereça a questão de competência 5.
Figura 35 – Meta-ontologia de domínio incorporada à ontologia OWL-SOA
Um serviço pode estar associado a conceitos do domínio ao qual o serviço faz parte. Através da relação entre o conceito Service e o conceito Ontology temos o ponto de integração fundamental da ontologia OWL-SOA com ontologias de domínio. A relação entre Service e Ontology e seus axiomas também podem ser utilizados para responder à questão de competência 5.
Um serviço é implementado em um ServiceGrounding. O ServiceGrounding pode ser de vários tipos: FIX, WebServices, REST, EJB, JMS, SBA e CORBA. Através da relação entre os conceitos Service e ServiceGrounding, é possível identificar em qual plataforma tecnológica determinado serviço é implementado. A relação entre os conceitos Service e ServiceGrounding e seus axiomas responde à questão de competência número 4.
Um serviço é composto por um ou mais artefatos. Dentre esses artefatos, é necessário existir pelo menos um artefato do tipo artefato de implementação. Através da relação entre os conceitos Service e Artifact, incluindo seus sub-tipos RequirementsArtifact, DesignArtifact, ImplementationArtifact e TestArtifact, e seus axiomas, é possível responder à questão de competência 6.
Dicionário de Termos
Segundo a metodologia SABiO, na atividade de captura da ontologia, é sugerida a construção de um dicionário de termos para definir claramente o significado de cada um dos
termos utilizados para identificar e nomear conceitos, propriedades e papéis na captura da ontologia. O Quadro 23 apresenta o dicionário de termos da ontologia OWL-SOA. O Apêndice C apresenta o dicionário das propriedades de todos os conceitos.
Quadro 11 - Dicionário de termos da ontologia OWL-SOA.
Termo Descrição
Service (Serviço) Serviços são componentes abertos e padronizados com características de independência e autodescrição, que possuem a capacidade de apoiar a composição de aplicações distribuídas de forma rápida, com alto grau de confiabilidade e baixo custo (PAPAZOGLOU, 2003).
BusinessProcess (Processo de Negócio)
O processo de negócio define um conjunto de atividades que precisam ser realizadas para atender a determinada necessidade de negócio.
ServiceProfile (Perfil do Serviço)
Descrição de alto nível do serviço. Esta descrição contém os parâmetros de entrada, de saída, precondições e efeitos no serviço.
ServiceCategory (Categoria do Serviço)
Representa a categoria que o serviço faz parte. A definição das categorias é flexível, onde podem ser definidas quantas categorias forem necessárias. As categorias representam classificações do serviço. O critério de categorização é definido pelo centro de excelência como um dos mecanismos de governança em SOA. Por exemplo, Ouro, Prata, Bronze, etc. ServiceGrounding
(Infraestrutura do Serviço)
Especificação dos detalhes de como um agente pode acessar um serviço. Tipicamente especifica o protocolo de comunicação, formato da mensagem, número da porta de comunicação e outros detalhes específicos do serviço.
NonFunctionalProperty (Propriedades Não Funcionais)
As propriedades não funcionais representam o status e atributos de um serviço em tempo de execução. Além disso, as propriedades não funcionais podem apresentar atributos de qualidade do serviço.
Quadro 23 (cont.) - Dicionário de termos da ontologia OWL-SOA.
Termo Descrição
ServiceParameter (Parametro do Serviço)
Define os parâmetros que serão utilizados no perfil de um serviço. Esses parâmetos definem atributos que serão tratados pelo serviço como parâmetros de entrada, saída, pré-condições e efeitos. Os parâmetros do serviço podem ser de vários tipos, dentre eles destacam-se strings, inteiros, ponto flutuante e booleanos.
Interface (Interface) Identifica como determinado serviço pode ser invocado. A interface representa as informações públicas para acesso a um serviço. A interface do serviço é um tipo abstrato que é utilizado para especificar interface que o serviços deve implementar.
Orchestration (Orquestração) Define o perfil do serviço em termos da funcionalidade requerida pelo serviço e que é fornecida por outros Web Service. Representa o ponto de vista consumidor.
Choreography (Coreografia) Define o perfil do serviço em termos da interação com o Web Service. Representa o ponto de vista provedor do serviço
Component (Componente) Componentes são elementos de sistemas de informação que implementam funcionalidades ou eventos, e podem se comunicar com outros componentes. Os componentes se referem aos artefatos de implementação do serviço.
Artifact (Artefato) Os artefatos são um dos vários produtos tangíveis produzidos ao longo de um processo de desenvolvimento de software. Artefatos são elementos lógicos e físicos de um ativo.
RequirementsArtifact (Artefato de Requisitos)
Artefatos de requisitos que o serviço pretende implementar. Corresponde aos artefatos produzidos na disciplina de requisitos de software de um processo de desenvolvimento. Por exemplo: diagrama de caso de uso, documento de visão, especificação suplementar, dentre outros.
DesignArtifact (Artefato de Projeto)
Artefatos de projeto necessários para o consumidor de serviço entendê-lo e invocá-lo. Esses artefatos descrevem a arquitetura interna do serviço. Corresponde aos artefatos produzidos na disciplina de Análise e Projeto de um processo de desenvolvimento. Por exemplo: documento de arquitetura, diagrama de classes, diagrama de seqüência, dentre outros.
ImplementationArtifact (Artefato de Implementação)
Código binário e código fonte que fornecem a implementação do componente e do serviço. Corresponde aos artefatos produzidos na disciplina de implementação de um processo de desenvolvimento. Por exemplo: código fonte, código executável, dentre outros.
TestArtifact (Artefato de Teste)
Artefatos descrevendo os casos de teste e scripts de teste executados no serviço. Corresponde aos artefatos produzidos na disciplina de testes de software de um processo de desenvolvimento. Por exemplo: caso de teste, script de teste, dentre outros.
FIX Financial Information Exchange - Linguagem para
implementação de serviços específicos para o mercado financeiro.
JMS Java Message Service - Tecnologia que fornece a programas Java a capacidade de criar, enviar, receber e ler mensagens de um sistema de mensageria corporativo. Web Service (Serviço Web) Sistema de software projetado para suportar
interoperabilidade na interação máquina-a-máquina através da rede, através de uma interface comum fornecendo uma descrição no formato WSDL (Web Services Description Language).
CORBA Common Object Request Broker Architecture – Tecnologia que possibilita as aplicações se comunicarem umas com as outras independentemente de onde elas estejam localizadas e quem as projetou. O padrão CORBA é um padrão definido para OMG (Object Management Group) para uma
arquitetura de objetos distribuídos.
Quadro 23 (cont.) - Dicionário de termos da ontologia OWL-SOA.
Termo Descrição
EJB Enterprise Java Beans - A tecnologia projetada para suportar a construção de aplicações corporativas através de uma arquitetura de componentes processados e gerenciados no lado servidor.
SBA Space-Based Architecture - Tecnologia para transformar aplicações desenvolvidas em múltiplas camadas em serviços lineares e dinamicamente escaláveis.
REST Representational State Transfer - Estilo arquitetural REST para sistemas distribuídos através da Internet.
Ontology (Ontologia) Ontologias de domínio associadas à ontologia de serviços.