WILCILENE MARIA KOWAL SCHRATZENSTALLER … · 1 wilcilene maria kowal schratzenstaller integraÇÃo semÂntica via enterprise service bus em ambientes de criaÇÃo de organizaÇÕes

1

WILCILENE MARIA KOWAL SCHRATZENSTALLER

INTEGRAÇÃO SEMÂNTICA VIA ENTERPRISE SERVICE BUSEM AMBIENTES DE CRIAÇÃO DE ORGANIZAÇÕES

VIRTUAIS

Dissertação apresentada ao Programade Pós-graduação em ComputaçãoAplicada, da Universidade do Estadode Santa Catarina, como requisitoparcial para obtenção do grau deMestre em Computação Aplicada.

Orientador: Dr. Fabiano BaldoCo-orientador: Dr. Ricardo J. Rabelo

JOINVILLE, SC2015

2

3

4

5

Ao meu orientador FabianoBaldo por acreditar em mim.

6

7

AGRADECIMENTOS

Aos professores Carla D. M. Berkenbrock,Cristiano D. Vasconcellos, Marcelo da S. Hounsell,Moisés Lima Dutra, Rui J. Tramontin Junior,principalmente aos orientadores deste trabalho FabianoBaldo e Ricardo J. Rabelo pelo apoio no processo deaquisição do conhecimento.

Aos amigos Adriano Pessini, Alcemir N. Kowal,Alyni Santos, Andre Pizzato, Claudir de J. Kowal, DiegoBuchinger, Felipe M. Scanhoela, Glaucio Scheibel,Gilsilene G. Kowal, Jucilane R. Citadin, MarceloStanislaski, Márcio G. Jasinski, Marcos A.Schratzenstaller e Mauro Hinz pelo apoio e companhianos estudos dos últimos semestres.

À CAPES e à FAPESC, pelo apoio financeiro.

8

9

“A menos que modifiquemos anossa maneira de pensar, nãoseremos capazes de resolver osproblemas causados pela formacomo nos acostumamos a ver omundo.”

Albert Einstein

10

11

RESUMO

Com intuito de atenderem demandas de forma maisrápida e com menor custo, pequenas e médiasempresas (PME) se unem em ambientes de criação deorganizações virtuais (ACVs) onde compartilhamrecursos para atuarem de forma colaborativa. O trabalhonestes ambientes é facilitado pelo uso de arquiteturasorientadas a serviços. Mais especificamente, com o usode barramentos de serviços empresariais (ESBs). ESBspossibilitam que os sistemas das PME envolvidas sejamintegrados e mensagens sejam trocadas. A tarefa deintegrar os sistemas é complexa devido àheterogeneidade de dados existente. Para resolver esteproblema, os ESBs poderiam ser munidos de um suportesemântico que mediasse as divergências existentesentre os dados fornecidos pelas PME. Mas, comoadicionar suporte semântico aos ESBs para facilitar aidentificação dos dados das PME a fim de integrá-las aoACV? Este trabalho propõe a criação de uma ontologia eum método que adiciona semântica aos dados no intuitode resolver as incompatibilidades semânticas. Paravalidar a proposta foram aplicadas métricas que avaliama cobertura dos termos buscados, a riqueza derepresentação do conhecimento e o detalhamento denível da ontologia, bem como foram realizados testes noprotótipo de mapeador semântico desenvolvido.

Palavras-chave: Processo de mapeamento. Ontologia.Mapeador Semântico. Ambiente de Criação deOrganizações Virtuais.

12

ABSTRACT

In order to attend demands faster and at lower cost, smalland medium enterprises (SME) are joined in virtualorganizations breeding environments (VBEs) where theycan share resources to work collaboratively. The work inthese environments is facilitated by using of service-oriented architectures (SOA) and enterprise servicebuses (ESBs). Although SOA and ESBs help the processof systems integration, it still remaining a complex taskdue to the heterogeneity of existing data. To solve thisproblem ESBs could be improved with a semanticsupport to mediate differences between the data providedby SME. But, how to add semantic support to ESBs tofacilitate data mapping for SMEs to integrate them intothe VBEs? This work proposes the creation of anontology and a method that adds semantics to the data inorder to solve semantic incompatibilities. To validate theproposal, metrics were applied to evaluate the ontologyaccording to its coverage of searched terms, the wealthof knowledge represented and the level detail. Besidesthat, tests were performed on the developed semanticmapper prototype.

Keywords: Matching process. Ontology. SemanticMapper. Virtual breeding environment.

13

LISTA DE ILUSTRAÇÕES

Quadro 1 – Ferramentas ESB.....................................48Figura 1 – Representação de uma ontologia............52Quadro 2 – Características das pesquisas.................58Figura 2 – Ontologia do processo de produção........66Figura 3 – Classe “serviços”......................................67Figura 4 – Classe “objetos” com os sinônimos.........68Figura 5 – Serviço “consultarProducao” associado aos

parâmetros da classe Objetos..................70Figura 6 – Processo de comunicação.......................72Figura 7A – BPMN do processo (ACV)........................76Figura 7B – BPMN do processo (organizações).........78Figura 8 – Ambiente de simulação............................80Figura 9 – Identificação de parâmetros sinônimos....88

14

15

LISTA DE ABREVIATURAS

ACVBPELBPMBPMNCtdNdNEdNGebXMLESBEVJBIOSGiOVPBPMErARCORDFrRSOASPARQLTICUBLUMLXML

Ambiente de Criação de Organizações VirtuaisBusiness Process Execution LanguageBusiness Process ManagementBusiness Process Model and NotationCobertura dos TermosDetalhe de NívelDetalhe de Nível EspecíficoDetalhe de Nível GlobalEletronic business XMLEnterprise Service BusEmpresa VirtualJava Business IntegrationOpen Service Gateway InitiativeOrganização VirtualPesquisa BibliográficaPequenas e Médias EmpresasRiqueza dos AtributosRede Colaborativa de OrganizaçõesResource Description FrameworkRiqueza das RelaçõesService-Oriented ArchitectureSPARQL Protocol and RDF Query Language Tecnologia da informação e comunicaçãoUniversal Business LanguagesUnified Modeling Language eXtensible Markup Language

16

17

SUMÁRIO

1 INTRODUÇÃO E JUSTIFICATIVA.......................19

1.1 OBJETIVOS..........................................................26

1.2 METODOLOGIA....................................................28

1.2.1 Enquadramento Metodológico..............................28

1.2.2 Metodologia de Pesquisa......................................30

1.2.3 Organização do Documento.................................32

2 REVISÃO BIBLIOGRÁFICA................................35

2.1 REDE COLABORATIVA DE ORGANIZAÇÕES....36

2.2 MODELAGEM DE PROCESSO DE NEGÓCIOS

PARA ACVS..........................................................39

2.3 INTEGRAÇÃO DE SISTEMAS BASEADA EM SOA COM SUPORTE A ESB................................42

2.4 ONTOLOGIAS PARA REPRESENTAR E

COMPREENDER O CONHECIMENTO..............50

2.5 TRABALHOS RELACIONADOS...........................55

3 SOLUÇÃO PROPOSTA.......................................61

3.2 ONTOLOGIA DE MAPEAMENTO DE

SERVIÇOS............................................................65

3.3 MÉTODO DE BUSCA E MAPEAMENTO.............71

4 AVALIAÇÃO DOS RESULTADOS.......................75

4.2 AMBIENTE DE SIMULAÇÃO...............................79

4.3 AVALIAÇÃO DA ONTOLOGIA..............................82

4.4 EXECUÇÃO DO PROTÓTIPO.............................86

18

5 CONCLUSÃO.......................................................91

5.1 TRABALHOS FUTUROS......................................94

REFERÊNCIAS..............................................................97

19

1 INTRODUÇÃO E JUSTIFICATIVA

As relações de comércio têm sofrido profundasmudanças nas últimas décadas, impulsionadasprincipalmente pelo aumento da exigência dos clientesque gradativamente buscam por produtos e serviçospersonalizados, de alta qualidade e baixo custo. Dessaforma, apenas organizações capazes de antecipar novastendências e responder de forma ágil a elas conseguemse manter no mercado (LACKENBY e SEDDIGHI, 2002).

Para enfrentar essa realidade, encurtar o tempode resposta e diminuir o custo dos processos, pequenase médias empresas (PME) têm investido na formação dealianças estratégicas de trabalho colaborativo para odesenvolvimento de novos produtos e serviços (LOSS,RABELO e PEREIRA-KLEN, 2007). Uma alternativaeminente ao se abordar a criação de aliançasestratégicas entre empresas, é a adoção do conceito derede colaborativa de organizações (RCO).

Uma RCO é uma agregação dinâmica, temporáriae lógica de instituições e pessoas que interagem ecompartilham recursos, competências e informações, pormeio das redes de computadores, em busca de umobjetivo comum (RABELO et al., 2004). As RCOs sãoclassificadas em redes estratégicas de longa duração ouredes orientadas a metas (CAMARINHA-MATOS et al.,2009).

As redes orientadas a metas são dissolvidas apósatingirem o objetivo, fazem parte desse grupo asorganizações virtuais (OVs) e as empresas virtuais (Evs)Uma EV se caracteriza por ser uma aliança estratégica,

20

temporária e dinâmica, entre empresas que trabalham deforma colaborativa por meio do suporte das redes decomputadores para atingir um objetivo comum e obterlucro (CAMARINHA-MATOS e AFSARMANESH, 1999).

O conceito por trás das OVs é similar ao aplicadoàs EVs, entretanto, as OVs não visam exclusivamente olucro, caso dominante nas EVs. Como esta característicaé irrelevante para o âmbito deste trabalho, assume-se nodecorrer do texto que o termo OV representa ambos ostipos de manifestação de RCO.

Para evitar a dispersão ao final do projeto, asPME interessadas em participar da formação de OVs sereúnem inicialmente em um Ambiente de Criação deOrganizações Virtuais (ACV).

Classificado como uma RCO de longa duração umACV busca por meio da preparação das PMEs e do usointensivo de tecnologias da informação e comunicação(TICs), oferecer as condições necessárias para permitiruma resposta ágil às oportunidades de negócios(BALDO e RABELO, 2010). Ou seja, o ACV pode servisto como um conjunto de PMEs conectadas umas comas outras e aptas a atenderem uma oportunidade denegócio por meio do trabalho realizado de formacolaborativa.

Quando uma oportunidade de negócio éidentificada pelo ACV, uma OV é imediatamente criadapara atender a demanda. Essa OV pode ser formada poralgumas ou por todas as PMEs que participam do ACV.E, ao atingirem o objetivo, apesar da OV se dissolver asPMEs envolvidas não perdem o vinculo umas com asoutras, pois, permanecem conectadas no ACV.

Dessa forma, além de tornar as operações maiseficientes com relação ao custo e ao tempo, uma

21

abordagem com base em RCOs contribui para oacúmulo de conhecimento com as lições aprendidas e oestreitamento dos laços culturais entre as PMEparticipantes (KARVONEN et al., 2004).

A preparação realizada dentro do ACV permiteque o processo de criação de OVs se torne mais rápidoe menos suscetível a falhas se comparado ao mesmoprocesso sem apoio do ACV. Quando uma oportunidadede negócio é identificada, uma OV é imediatamentecriada para atender a demanda. Essa OV pode serformada por algumas ou por todas as PMEs queparticipam do ACV.

Após a criação da OV, as PMEs escolhidasinteragem de acordo com as regras predefinidas nomodelo de governança, com objetivo principal de atendera demanda com a qualidade, o prazo e o custoestabelecidos no pedido. Para atender essasexpectativas o ACV deve prover uma infraestrutura deTIC flexível e adaptável, capaz de gerenciar diferentesníveis de segurança e acesso às informações conformea necessidade de cada participante da OV.

Quando um cliente entra em contato com uma OV,ele acredita se tratar de uma única empresa. Porém,como o próprio nome sugere, uma OV não é umaempresa fisicamente constituída, mas sim um grupo dePMEs que colaboram de forma coordenada por meio degovernanças e processos de negócios comuns, e pelaintegração de seus sistemas computacionais.

A governança cooperativa é o resultado danegociação entre as PMEs participantes do ACV e seusrespectivos gestores, onde cada gestor considera osbenefícios de fazer parte da cooperação para atingirseus objetivos individuais (ROTH, WEGNER e PADULA,

22

2012). Ela prevê os diferentes direitos e deveres dosenvolvidos conforme perfil do negócio para as regrasestabelecidas (RABELO, COSTA e ROMERO, 2014). Agovernança não gerencia, mas delimita as ações dosgestores da rede que usam seus conhecimentos ehabilidades para planejar e executar estratégias embusca dos objetivos estabelecidos (ROTH, WEGNER ePADULA, 2012).

A definição clara e a representação das atividadesdo processo de negócio adotado, permite que asdiversas PMEs envolvidas realizem a análise doprocesso ao qual estão inseridas e facilita adisseminação dos conhecimentos organizacionaisexistentes (AZEVEDO e SOARES JÚNIOR, 2014).

A integração dos sistemas é uma tarefa complexadevido à heterogeneidade de softwares e dadosexistentes, porém essencial para que as OVs possamoperar com eficiência. Entre os problemas encontradosna integração dos dados de sistemas de diversas PMEsdestacam-se: 1) diferentes unidades de medidas; 2)diferença na formatação dos dados trocados; 3)parâmetros insuficientes ou demasiados; e 4) diferentesnomes encontrados para parâmetros equivalentes.Esses problemas ocorrem devido à heterogeneidade dosbancos de dados das empresas (KASHYAP, BUSSLER eMORAN, 2008).

Uma forma de solucionar o problema de diferentesunidades de medidas é utilizar funções que identifiquemas medidas e realizem as devidas conversões. Umaalternativa para solucionar o problema de diferença naformatação dos dados é a aplicação de transformaçõesnas mensagens com regras pré-determinadas. Umasolução para os problemas de parâmetros insuficientes

23

ou demasiados é predeterminar regras e criar funçõespara reunir dois ou mais serviços que atendam arequisição com os parâmetros enviados. Para solucionaro problema de identificação e associação dos diferentesnomes encontrados para parâmetros equivalentes énecessária uma solução que proveja suporte àrepresentação semântica da informação. Este é o focodeste trabalho e como solução propõe-se a utilização deuma ontologia para realizar o mapeamento dosparâmetros utilizados.

O problema de diferentes nomes encontradospara parâmetros equivalentes consiste em, por exemplo,um dos participantes da OV invoca o serviço“SolicitaPag” e envia os parâmetros “customerId”,“invoiceId”, “qtd_prod” enquanto o serviço invocado podeesperar pelos parâmetros “idCliente”, “IdPedido”,“qtdPecasProduzidas”. Para que a comunicação possaser estabelecida é necessário que os dados equivalentessejam mapeados. A forma para localizar esses dadossimilares, proposta neste trabalho é a busca semânticacom auxílio de uma ontologia.

A ontologia desenvolvida representa os serviços eseus respectivos objetos passados como parâmetrosentre as PMEs participantes do ACV. Esses serviços eparâmetros são utilizados na troca de mensagens feitaspara a comunicação e integração entre os participantes.

A infraestrutura também deve possibilitar que aconfiguração das transações computacionaisnecessárias seja realizada de forma ágil e sejaconsoante com os objetivos de cada OV. Entre asarquiteturas utilizadas atualmente, a que mais sedestaca para implementação e gerenciamento dos ACVsé a arquitetura orientada a serviços (service-oriented

24

architecture – SOA). SOA é uma arquitetura que provêcomponentes de software como serviços que utilizamuma linguagem padrão para a especificação deinterfaces que facilitam a integração e reutilização desoftware (HEWITT, 2009).

Para dotar esses serviços de segurança,confiabilidade, gerenciamento de transações eorquestração de processos são utilizadas tecnologiastais como os barramentos de serviços corporativos(Enterpise Service Bus – ESB). O ESB é baseado empadrões que combinam transformação de dados eroteamento inteligente de mensagens para conectar ecoordenar com segurança a interação de aplicações emempresas estendidas com integridade transacional(CHAPPELL, 2004).

As características do ESB permitem reunirserviços e aplicativos para possibilitar a operação denegócios distribuídos de forma colaborativa de modoseguro e coordenado. Porém, apesar das vantagensadvindas da utilização do ESB junto à arquitetura SOA,existem alguns pontos desta combinação que aindaprecisam ser melhorados.

Uma carência identificada nos ESBs diz respeito àpossibilidade de transformar os dados necessários àintegração de serviços. Atualmente este processo érealizado manualmente através da utilização decomponentes chamados de mapeadores (CHEN, 2012).Entretanto, a integração feita de forma manual podelevar à ocorrência de erros e à redução da agilidade doprocesso, visto que é necessária a intervenção humana,a qual está sujeita a falhas ou indisponibilidade nomomento necessário.

25

Esses problemas podem ser resolvidos com autilização de meios automáticos de integração. Paradotar o ESB desta característica, é necessário incorporara ele o conhecimento necessário para realizar aintegração. Como mencionado, esse conhecimento podeser representado em forma de ontologia. Já aautomatização do processo pode ser feita através de ummecanismo de consulta à ontologia que realiza osmapeamentos necessários à integração dos serviçoscontidos no processo de negócio.

Sward e Whitacre (2008) destacam essa ausênciade suporte semântico na integração de serviçosgerenciados pelo ESBs. A adição de suporte semânticopode oferecer a flexibilidade e autonomia necessárias aomapeamento e integração dos processos do ACV eassim facilitar e acelerar a integração dos sistemasenvolvidos na criação de OVs. Chen (2012) ressalta queé fundamental a realização de pesquisas com intuito deampliar a capacidade dos ESBs conectarem sistemas eserviços com maior facilidade e rapidez.

Dados os benefícios que a utilização de semânticapode proporcionar à integração de serviços, estetrabalho aborda o seguinte problema de pesquisa: Comoadicionar semântica ao processo de integração desistemas via ESB para flexibilizar e automatizar aatividade de mapeamento dos dados, de forma a facilitare acelerar a fase de criação de OVs?

Dentre os mecanismos disponíveis que auxiliamna representação semântica de um determinado domíniose destacam as ontologias. Utilizadas pela área deinteligência artificial desde os anos 1970, as ontologiasse tornaram populares apenas a partir de 2001 após a

26

proposta da web semântica por Tim Berners-Lee(ALMEIDA e BARBOSA, 2009).

As ontologias são, atualmente, uma das formasmais utilizadas para representar, compreender erecuperar o conhecimento humano (BEM e COELHO,2013). Ela é constituída basicamente por três elementos,que são os conceitos, suas propriedades e inter-relacionamento (KASHYAP, BUSSLER e MORAN, 2008).

Berners-Lee propôs utilizar ontologias paraadicionar metadados aos recursos publicados na Web, oque possibilita o uso de termos de referência na troca deinformações online (KASHYAP, BUSSLER e MORAN,2008). Com apoio das ontologias é possível realizar aconexão entre os dados disponíveis na web para facilitar,agilizar e melhorar os resultados das buscas.

Dessa forma, a hipótese formulada para estetrabalho assume que a criação de uma ontologia pararepresentar os processos do ACV pode auxiliar naincorporação de semântica ao ESB. Espera-se que autilização desta ontologia possibilite flexibilizar eautomatizar a fase de mapeamento dos serviços dasPMEs que participam do ACV. Com isso busca-sealcançar a identificação dos dados similares para realizara integração de sistemas necessária para a formação eoperação das Ovs.

1.1 OBJETIVOS

Este trabalho tem por objetivo propor um métodopara dotar os ESBs de suporte semântico e possibilitar o

27

mapeamento automático dos parâmetros de serviçosdisponibilizados por diferentes PMEs. O intuito dessemétodo é capacitar os ESBs para que possam oferecer aflexibilidade no mapeamento de dados e integração desistemas requeridos pelos ACVs na formação eoperação de OVs. Assume-se como hipótese que oapoio semântico pode ser adicionado com a criação deuma ontologia para representar os conceitos emetadados disponibilizados pelas PMEs participantes doACV.

A fim de alcançar o objetivo geral os seguintesobjetivos específicos foram especificados:

1. Definir a arquitetura de operação do ACV eimplementar um processo de negócios deexemplo em BPMN (linguagem gráfica) composterior exportação para BPEL (linguagem deexecução)

2. Criar uma ontologia para representar os processosenvolvidos na criação, operação, evolução edissolução de OVs;

3. Desenvolver um método capaz de: identificar osparâmetros (metadados) trafegados nasmensagens trocadas pelos serviços invocados viaESB; consultar a base de conhecimento(ontologia) para localizar a classe a que pertencecada parâmetro; mapear cada parâmetro contidonas mensagens do emissor para os esperadospelo receptor e vice-versa.

28

1.2 METODOLOGIA

A seção 1.2.1 apresenta o enquadramentometodológico deste trabalho, enquanto a seção 1.2.2descreve a metodologia de pesquisa utilizada paraalcançar o objetivo proposto.

1.2.1 Enquadramento Metodológico

A classificação da pesquisa de acordo com aliteratura provê ao pesquisador instrumentos científicosjá difundidos que auxiliam no desenvolvimento dotrabalho. Para classificação desta pesquisa foramconsideradas as propostas de Filippo, Pimentel e Wainer(2012), Eden (2007) e Wazlavick (2010), conformesegue.

Quanto ao método de pesquisa, adotou-se ométodo experimental. Este método sugere aidentificação de um problema, formulação de umaquestão de pesquisa e proposta de uma solução a sercomprovada com base na aplicação e análise de algumexperimento. Para avaliar a proposta foram realizadasanálises e aplicação de métricas na ontologia bem comoforam realizadas execuções do protótipo computacionaldesenvolvido para validar a eficiência do métodoproposto, conforme apresenta o capítulo 4.

Quanto ao tipo de ciência, a pesquisa pode serclassificada como ciência inexata, devido ao fato de que

29

para cada execução do método podem haver variaçõesno resultado quantitativo obtido. Essa variação ocorreem todo o resultado do mapeamento dos processos, poisdepende da identificação de correspondências entre osprocessos definidos pelo ACV e os serviços eparâmetros disponibilizados pelas PMEs quefrequentemente são diferentes.

Quanto à abordagem, esta pesquisa pode serconsiderada quantitativa, pois os resultados geramvalores que podem ser analisados estatisticamente. Aapresentação desses resultados ocorre no capítulo 4.

Quanto à finalidade, pode-se concluir que apesquisa possui finalidade exploratória, pois ela identificaoportunidades de pesquisa e esboça possíveisinterpretações tanto sobre o problema quanto sobre asolução proposta.

Quanto as técnicas de coleta de dados, opresente trabalho pode ser classificado como pesquisabibliográfica, e análise e aplicação de experimentos emum ambiente simulado. A pesquisa bibliográfica forneceuconhecimento necessário para propor e desenvolveruma solução viável para o problema de identificação desinônimos na base de conhecimento da ontologia deprocessos do ACV.

Quanto às técnicas de análise de dados, foiadotada a análise do discurso por se tratar de umaabordagem onde as informações são obtidas em umcurto período de tempo por meio de análise do objeto emum ambiente simulado.

Quanto à maturidade, a pesquisa encontra-se nonível 2 com paradigma tecnocrático predominante.Embora a pesquisa tenha seguido rigorosos métodos, oexperimento é considerado pouco rigoroso se

30

considerado o paradigma científico conforme descrito naliteratura. Para que a pesquisa seja elevada a nível 1 epossa se enquadrar no paradigma científico, énecessário executar o experimento de forma exaustivacom uma grande e variada base de dados de forma agarantir que os aspectos sejam testados e apossibilidade de imprevistos seja reduzida.

1.2.2 Metodologia de Pesquisa

Conforme definido na literatura, uma pesquisacientífica deve ser baseada em um conjunto deprocedimentos executados rigorosamente de forma aproduzir algum conhecimento novo (FILIPPO,PIMENTEL e WAINER, 2012). Portanto, para que oavanço ocorra na pesquisa é necessário que opesquisador planeje e execute determinados passos.

Neste trabalho, o procedimento metodológicoadotado define o seguinte conjunto de passos.Primeiramente foi identificado um problema real dentrodos ACVs, para o qual uma questão de pesquisa foiformulada.

Após a identificação do problema e formulação dapergunta de pesquisa, iniciou-se a realização depesquisa bibliográfica (PB). A PB foi realizada com intuitode identificar possíveis alternativas para responder aquestão de pesquisa e solucionar o problemaidentificado inicialmente. Além de prover ao pesquisadorreferências para documentar a proposta e conhecimentoreferente às ferramentas disponíveis.

31

Em paralelo à PB, foram instaladas e testadasferramentas de apoio, com intuito de definir qual melhoratenderia aos requisitos necessários. A realização da PBpossibilitou a proposição de uma solução para oproblema inicialmente identificado e a identificação dasferramentas possibilitou a configuração de um ambientede simulação e início do desenvolvimento de umprotótipo para validar a solução.

Para o desenvolvimento da solução foinecessário:

1. Definir a arquitetura de operação do ACV;2. Identificar as principais atividades (serviços) dos

processos de negócio utilizados na criação,operação, evolução e dissolução de OVs;

3. Simular os serviços e parâmetros identificados nosprocessos de negócio levantados na literatura;

4. Com base nos processos de negócio identificados,criar uma ontologia que representeadequadamente os conceitos e informaçõesnecessárias para mapear os serviços e assimpossibilitar a integração para os sistemas dasPMEs participantes do ACV;

5. Modelar e desenvolver um componente que possaser utilizado por ferramentas ESBs de códigoaberto. Este componente deve possibilitar omapeamento automático, por meio de consultas aontologia, dos parâmetros contidos nasmensagens trocadas entre os serviços das PMEsenvolvidas na OV. Para validar a solução, foram realizados

experimentos sobre a aplicação desenvolvida e sobre aontologia proposta. Primeiramente, a cobertura, ariqueza e o nível de detalhamento da ontologia foram

32

avaliados. Posteriormente, o protótipo foi executado emambiente simulado para demonstrar o funcionamento dométodo proposto. O capítulo 4 apresenta a avaliaçãorealizada com descrição das métricas e resultadosobtidos.

1.2.3 Organização do Documento

O restante do documento está estruturado daseguinte forma: O capítulo 2 apresenta a revisãobibliográfica dos conceitos relacionados, o estado da artee as ferramentas disponíveis para auxiliar no processode criação e gestão de ACVs. Os conceitos revisadosestão relacionados à operação dos ACVs, à atividade demodelagem de processos de negócio para ACVs, àsdiferentes tecnologias disponíveis para auxiliar noprocesso de integração de sistemas entre diferentesPMEs e à representação e busca de conhecimento.

O capítulo 3 apresenta a solução. Neste capítulodescreve-se um cenário projetado para fins dedesenvolvimento e testes da solução. Também éapresentada a ontologia desenvolvida com base nosprocessos de negócio utilizados na criação e operaçãode OVs. Por fim, o método desenvolvido paraautomatizar o processo de mapeamento de parâmetrosdos serviços necessários para a integração das PMEsparticipantes de uma OV.

O capítulo 4 apresenta os passos seguidos nacoleta e análise de dados para validação da proposta pormeio da avaliação da ontologia e do protótipo de

33

mapeador semântico desenvolvido. A avaliação permiteapresentar os resultados de forma a validar a soluçãoinicialmente proposta. Trata-se da avaliação da ontologiaproposta com a aplicação de métricas de avaliação queestabelecem o grau de cobertura dos resultados, deriqueza na representação do conhecimento e dedetalhamento de nível da ontologia, bem como aexecução da aplicação protótipo de mapeador semânticoque realiza as consultas na ontologia definida.

Por fim, o capítulo 5 apresenta as conclusões esugestões de trabalhos futuros.

34

35

2 REVISÃO BIBLIOGRÁFICA

Uma rede colaborativa de organizações (RCO) écaracterizada por uma agregação dinâmica, temporária elógica entre instituições e pessoas que compartilhamcompetências, recursos e informações para atenderemuma demanda específica com trabalho de formacolaborativa (RABELO et al., 2004). Entre as diversasformas de materialização das RCOs destacam-se comoalianças de longa duração os ACVs e de curta duraçãoas EVs e as OVs.

As próximas seções deste capítulo descrevem osACVs e caracterizam seu papel na preparação e criaçãode OVs. Também evidenciam o propósito de utilização damodelagem de processos de negócios como meio paraauxiliar a especificação e compreensão dos processosnecessários ao ACV. Além disso, são apresentadastambém as formas de integração entre os sistemasenvolvidos na formação de OVs, dado que estas formasde colaboração necessitam de intensa troca deinformações durante o processo de produção.

Para finalizar o capítulo de revisão, sãoapresentados os trabalhos relacionados. Foramconsiderados relacionados, os trabalhos que aplicamtécnicas de integração semântica para identificar osdados envolvidos na integração de sistemasheterogêneos e distribuídos.

36

2.1 REDE COLABORATIVA DE ORGANIZAÇÕES

Um ACV representa uma associação deorganizações que adotam regras e princípios comunspara trabalharem de forma colaborativa em umainfraestrutura operacional. Trata-se de uma aliança delonga duração (entre diversas PMEs), que oferececondições necessárias para suportar respostas maiságeis quando surgem oportunidades de negócios – naforma de criação de OVs – por meio da utilização dasTICs (BALDO e RABELO, 2010).

Um ACV é formado por várias PMEs quecompartilham os mesmos interesses e buscam novasoportunidades de negócio. O objetivo principal de umACV é aumentar a preparação para colaboração entre asPMEs, o que resulta na criação de uma OV de formamais rápida (CAMARINHA-MATOS e AFSARMANESH,2005). Dessa forma, quando o ACV identifica umaoportunidade, algumas ou todas as PMEs integrantes seorganizam e formam uma OV para suprir a demandaencontrada.

O termo OV define um conjunto de PMEsindependentes que compartilham recursos e habilidadescom objetivo de realizarem uma determinada ação emconjunto (CAMARINHA-MATOS, AFSARMANESH,2005). O trabalho de forma colaborativa em OVs permiteque os participantes realizem ações em menos tempo,com menor custo e maior qualidade do que se cada PMErealizasse o mesmo trabalho de forma isolada.

37

O ciclo de vida das OVs é composto pelas fasesde criação, operação/evolução e dissolução (YASSA,HASSAN e OMARA, 2014) conforme descritas a seguir.

A fase de criação inicia-se após a identificação deuma oportunidade de negócio pelo ACV e é compostapelas atividades de detalhamento da oportunidade denegócios, busca e seleção de parceiros, negociação eassinatura de contratos, e setup e integração dossistemas computacionais de todas as PMEsparticipantes. Ao final da fase de criação, tem-se a OVcriada e pronta para operar.

A fase de operação inicia-se após a criação da OVe constitui a execução das atividades planejadas, bemcomo as adaptações necessárias ao planejamento nodecorrer da execução do mesmo. Se durante a operaçãoforem necessárias adaptações na formação da OV, sejapela identificação de atraso ou não conformidade com opedido, a OV passa pela fase de evolução. Durante estafase podem ser realizados realocações de tarefas entreas PMEs participantes, assim como, em casos extremos,a substituição de um ou vários participantes. Ao final dafase de operação tem-se o objetivo cumprido.

A fase de dissolução ocorre após a fase deoperação e consiste na divisão dos lucros (se houver) eliberação dos participantes. Ao final da fase dedissolução da OV os participantes encontram-sedisponíveis para colaborarem em outras demandasidentificadas pelo ACV.

Assim como um projeto, a OV épreponderantemente temporária e finita (JÄGERS et al.1998). Ou seja, toda OV passa pela fase de dissoluçãoao atingir o objetivo inicialmente proposto. Se outrademanda for identificada, a fase de criação de uma nova

38

OV deve ser iniciada, mesmo que o objetivo seja similare sejam os mesmos participantes. Portanto, asatividades de planejar o processo, estabelecer oambiente de colaboração, constituir a OV, integrar ossistemas, executar as atividades, realizar a entrega,dividir o lucro (se houver) e liberar os participantes aofinal deverão ser executadas em todos os projetos.

É comum que as PMEs envolvidas na OV estejamdispersas geograficamente de forma regional ou global(AFSARMANESH e CAMARINHA-MATOS, 2005). Adivisão de tarefas e colaboração entre as PMEsdispersas geograficamente é possível porque as TICspossibilitam a comunicação instantânea entre osenvolvidos, assim como o monitoramento e a gestão doprocesso de colaboração.

Os participantes da OV se tornam dependentesuns dos outros durante a colaboração, pois compartilhamrecursos e habilidades para atingir objetivos comuns(JÄGERS et al. 1998). Para que esta dependência nãose torne um problema é fundamental planejar umambiente adequado antes da formação da OV. Dentre ascaracterísticas desejadas, o ambiente deve prover aosparticipantes a possibilidade de compartilharem recursose competências de forma dinâmica, mesmo à distância, etambém suportar a entrada e saída de participantesdurante a fase de evolução da OV.

Os ambientes de operação das OVs sãofortemente alicerçados nas TICs (BALDO e RABELO,2010). Elas são consideradas fundamentais para odesenvolvimento da infraestrutura para a criação de umacultura organizacional onde a colaboração se torna partedo processo e não apenas uma opção de trabalho(RABELO, 2008).

39

Por meio da infraestrutura comum de TIC asPMEs envolvidas compartilham informações, serviços,recursos de produção, entre outros elementosnecessários à execução do trabalho de formacolaborativa.

O gerenciamento de sessões colaborativas devefacilitar a entrada e saída de participantes, a localizaçãoe inclusão de indivíduos e a criação de novas sessões(HIRATA, BERKENBROK e PICHILIANI, 2011). Uma boaestrutura para gerenciamento da comunicação possibilitatambém a criação de laços culturais e compartilhamentode novas experiências e lições aprendidas no processo(AFSARMANESH e CAMARINHA-MATOS, 2005).

2.2 MODELAGEM DE PROCESSO DE NEGÓCIOS PARA ACVS

A modelagem de processos de negócios éresponsável pela representação de todo o processo comsuas atividades (relações causais e temporais); regrasde negócio; condições (ações que geram reação) eprodutos/saídas (AALST, HOFSTEDE e WESKE, 2003).Embora a modelagem de processos de negócio já fosseutilizada por outras áreas, foi a área de engenharia desistemas que formalizou o termo BPM (business processmanagement) em 1960 (CHINOSI, TROMBETTA, 2012).

Atualmente, BPM pode ser caracterizado como ouso de software, métodos e técnicas para projetar,aprovar, controlar e analisar processos operacionais queenvolvem organizações, pessoas, aplicações,

40

documentos e outras fontes de informação (AALST,HOFSTEDE e WESKE, 2003).

A modelagem formal para os processos denegócio evita interpretações diferentes por parte dosdiversos participantes, mesmo em atividades complexas(MAZANEK e HANUS, 2011). Além disso, quandobaseada em padrões facilita a interpretação dasatividades a serem realizadas, permite que cadaparticipante compreenda o processo como um todo eainda possibilita que menos sistemas sejam construídosa partir do zero (AALST, HOFSTEDE e WESKE, 2003).

Para auxiliar na fase de modelagem dosprocessos, a notação de modelagem de processos denegócios (Business Process Model and Notation -BPMN) foi publicada em 2004 pela Business ProcessModeling. Parcialmente inspirados no diagrama deatividades da UML (Unified Modeling Language), osmodelos BPMN são fluxogramas que representamgraficamente o processo (BPM) por meio daespecificação das suas atividades e relações (MAZANEKe HANUS, 2011).

A linguagem de execução de processos denegócios (Business Process Execution Language -BPEL), embora atualmente mantida pela OASIS, foicriada em 2002 pelas instituições IBM, BEA e Microsoft.A linguagem BPEL é baseada nas linguagens WSFL(Web Services Flow Language da IBM) e XLANG (XMLlanguage da Microsoft) (ALVES et al., 2007) e é utilizadapara executar as atividades representadas pelo BPMNde forma orquestrada (em ordem).

Além do BPMN existem outros formalismospropostos para a especificação de processos denegócios. Dentre eles, destacam-se o RosettaNet (1998),

41

o ebXML (2002) e o UBL (2004), conforme apresentadosa seguir.

O padrão RosettaNet é desenvolvido e atualizadodesde 1998 por um grupo de empresas provenientesprincipalmente do setor de tecnologia (KAUREMAA,NURMILAAKSO e TANSKANEN, 2010). O RosettaNetvisa ser global e aberto para agilizar e facilitar a criaçãode comunicação empresarial eficiente entre múltiplasplataformas, aplicativos e redes por meio da definição dediretrizes e especificações com base em protocolosexistentes. Para isso, o RosettaNet estabelece umvocabulário comum baseado em linguagem de marcaçãoextensível (eXtensible Markup Language - XML) paracomunicação, assim como protocolos para garantir asegurança, o transporte e o roteamento dos dadostransmitidos (CHONG e KENG-OOI, 2008).

O ebXML é uma iniciativa que utiliza a linguagemde marcação extensível (electronic business usingeXtensible Markup Language – ebXML) para aespecificação de negócios eletrônicos, lançado no anode 2000, mas registrado pela OASIS apenas em 2002(GEYER, 2006). O ebXML atua como um padrão de XMLque auxilia na construção da documentação de negóciocom base em um conjunto comum de componentesreutilizáveis (PATIL e NEWCOMER, 2003). Ele se baseiaem três conceitos que visam estabelecer: I) umainfraestrutura que garante a interoperabilidade decomunicação de dados; II) uma estrutura que garanteinteroperabilidade comercial e III) um mecanismo quepermite às empresas encontrarem umas as outras,estabelecerem acordos e tornarem-se parceiras.

Por fim, a linguagem universal de negócios(Universal Business Language - UBL) objetiva codificar e

42

personalizar processos de negócios por meio dadisponibilização de um conjunto manipulável dedocumentos de negócios compatível com asespecificações ebXML (LIU, 2010). O padrão UBL foipublicado em 2004 pela OASIS (MEADOWS eSEABURG, 2004). Ele atua como uma biblioteca deobjetos e define um formato de intercâmbio XMLgenérico para os documentos de negócio.

Percebe-se com a apresentação dessaslinguagens que a modelagem de processos, se baseadaem padrões, facilita a integração das PMEs queobjetivam trabalhar de forma colaborativa. Isso ocorreporque a aplicação de padrões tem o poder de aumentaro grau de entendimento dos processos e serviçosenvolvidos na colaboração.

A definição e uso de padrões também possibilita areutilização de processos ou de parte de suas atividades.Essa reutilização permite uma redução no tempo e nocusto do desenvolvimento da integração dos sistemas,para processos de negócios semelhantes.

2.3 INTEGRAÇÃO DE SISTEMAS BASEADA EM SOA COM SUPORTE A ESB

No cenário de integração de sistemas paraformação de OVs é comum existir heterogeneidade entreos sistemas a serem integrados, tanto sob o ponto devista de hardware, quanto de software. Isso ocorreporque existem centenas de diferentes linguagens deprogramação e componentes de hardware disponíveis,e, devido à autonomia entre as organizações

43

participantes, nada garante que elas utilizem os mesmossistemas e equipamentos.

Além da escolha de diferentes softwares ehardwares, há também o fato de que algumasorganizações evoluem seus sistemas no decorrer dotempo enquanto outras os mantêm inalterados. Ossistemas que permanecem por um longo período detempo sem evolução e, mesmo assim, a organização osutiliza, são comumente chamados de sistemas legados.

No momento em que a comunicação éestabelecida entre os sistemas envolvidos é necessáriolevar em consideração que o modo como a interação érealizada afeta as possibilidades de comunicação,coordenação e cooperação entre os participantes deforma que tudo deve ser planejado e integrado com focono objetivo a ser alcançado (HIRATA, BERKENBROK ePICHILIANI, 2011).

Uma das tecnologias mais utilizadas na integraçãode sistemas recentemente é a arquitetura orientada aserviços (Service Oriented Architecture – SOA). SOArepresenta uma arquitetura que orienta a criação,gerenciamento e utilização de serviços. Ela provêsuporte à integração de aplicações distribuídas emambientes heterogêneos de forma rápida, com baixocusto e complexidade (BREOVOLD e LARSSON, 2007).

A arquitetura SOA propõe a utilização de serviçoscomo blocos de construção para facilitar acomponentização dos sistemas e posterior reutilizaçãode código (HEWITT, 2009). Nela, os serviços são criadose disponibilizados em servidores para que clientesdispersos fisicamente e com diferentes características dehardware e software possam invocá-los e utilizá-los. Ainvocação e utilização ocorre por meio da identificação

44

(dinâmica ou fixa) do serviço a ser utilizado e dapassagem dos parâmetros.

Um serviço é uma representação lógica de umaatividade de negócios repetível com resultado específico(por exemplo, verificar o crédito do cliente ou fornecerdados da produção). Um serviço pode serautossuficiente ou composto por outros serviços. Emambos os casos o código é uma “caixa-preta” para osconsumidores finais (THE OPEN GROUPS).

Conforme ERL (2009) especifica, o uso adequadode serviços permite à SOA promover algumascaracterísticas como:

1. Baixo acoplamento: serviços podem manterrelacionamentos que minimizam as dependênciase requerem apenas o conhecimento um do outropara utilização.

2. Definição de contrato: contratos permitem definircoletivamente uma ou mais descrições deserviços relacionados para estabelecer acomunicação.

3. Autonomia: serviços detêm o controle sobre alógica de programação que os constitui.

4. Abstração: a lógica de programação aplicada nacriação do serviço não precisa ser compreendidapelos clientes que o utilizam.

5. Reutilização: uma vez criado, um serviço pode serinvocado por diversas aplicações diferentes semnecessidade de nova codificação.

6. Modularidade: diversos serviços existentes podemser coordenados para formar um serviçocomposto.

45

7. Descoberta: os serviços são descritos para quepossam ser encontrados e invocados por meio demecanismos de descoberta disponíveis.Apesar de fornecer um mecanismo flexível para

integração de sistemas, SOA foca no desenvolvimentode novos serviços e negligencia aspectos comosegurança, confiabilidade, gerenciamento de transaçõese orquestração de processos de negócio (LI et al., 2010),importantes ao ACV. Embora seja possível implementartais opções na arquitetura, recomenda-se o uso de umESB para evitar a recodificação de tecnologias jáexistentes, testadas e otimizadas (HEWITT, 2009).

Os ESBs são baseados em padrões e combinammensagens, serviços, transformação e roteamentointeligente de dados. O ESB atua como uma camada decomunicação intermediária entre servidores/serviços eaplicações heterogêneas na arquitetura SOA (GARCÍA-JIMÉNEZ, MARTÍNEZ-CARRERAS e GÓMEZ-SKARMETA, 2010).

ESBs possibilitam que conexões sejam criadascom segurança e que a interação de um númerosignificativo de aplicações em empresas estendidas comintegridade transacional sejam coordenadas(CHAPPELL, 2004), sem a necessidade de criar ligaçõesvisíveis aos clientes (HEWITT, 2009). Estascaracterísticas proveem ao ESB a flexibilidadenecessária na reunião dos serviços e aplicativos quepermitem a operação de negócios distribuídos ecolaborativos de forma segura e coordenada.

Como visto, o ESB fornece um conjunto decapacidades que permitem transformar, mediar e rotearmensagens, assim como invocar e mediar serviços parafacilitar a interação entre recursos de TIC (aplicações,

46

serviços, informações, plataformas, etc.) de formacoordenada e confiável (GARCÍA-JIMÉNEZ, MARTÍNEZ-CARRERAS e GÓMEZ-SKARMETA, 2010).

Por agregar diversas funcionalidades em umaúnica plataforma, o ESB é considerado a tecnologia deintegração de sistemas mais adequada para ser utilizadana criação e configuração de ACVs que criam egerenciam OVs. Dentre as características já indicadas, ouso de ESB se destaca em comparação às demaistecnologias, para uso pelas RCOs, principalmente porapresentar menor dificuldade de integração e maiorsegurança no roteamento das mensagens trocadaspelas PMEs participantes.

Existe uma relevante quantidade de ferramentasESB disponíveis. Na pesquisa efetuada neste trabalhoforam consideradas apenas as ferramentasdisponibilizadas de forma free (sem custo de aquisição)e open source (com possibilidade de edição do códigoda ferramenta para adicionar ou remover funcionalidadesdesejadas).

Entre as funcionalidades esperadas de umaferramenta ESB destacam-se: 1) Facilidade deinstalação e configuração para uso da ferramenta; 2)Transparência de localização para o cliente; 3)Transformação de mensagens com diferentes padrõesde identificação dos dados; 4) Roteamento eaprimoramento de mensagens como formas dedeterminar o destino das mesmas e adicionarinformações necessárias e ausentes com base nosdados de entrada e regras pré-definidas; 5) Segurança;6) Monitoramento e gestão do processo em execução; 7)Interface gráfica; 8) Extensibilidade; 9) Licença sob aqual a versão foi desenvolvida; 10) Data de lançamento

47

da versão avaliada e 11) Suporte relacionado ao padrãoseguido (STRAUCH et al., 2012 e RADEMARKES eDIRKSEN, 2009).

Após a determinação das característicasfundamentais para atingir os objetivos desejados nestetrabalho e estudo da documentação das ferramentasdisponíveis, o Quadro 1 foi criado e sintetiza asferramentas (colunas) consideradas mais relevantes esuas respectivas funcionalidades (linhas).

A arquitetura definida para cada ferramenta ESBestá relacionada aos padrões definidos que devem serlevados em consideração para facilitar a reusabilidadede código entre diferentes provedores de serviços ouferramentas ESB.

As três ferramentas apresentadas possuem emcomum, conforme observado no Quadro 01, conversãodos protocolos mais comuns com possibilidade deexpansão, são free, open source e realizamgerenciamento multiusuário.

A ferramenta Apache ServiceMix 4.5.3 atendetodos os requisitos considerados importantes para estapesquisa e suporta tanto o padrão OSGi quanto o JBI.Porém, ao avaliar a facilidade de aprendizagem emanuseio da ferramenta as dificuldades encontradas sãomaiores se comparada às demais ferramentas.

Apache serviceMix 4.5.3 não possui interfacegráfica, o que limita todo o desenvolvimento à digitaçãode código (prompt, fuse ou eclipse). A ausência de umainterface gráfica na ferramenta cria dificuldades tanto deaprendizagem quanto de desenvolvimento, pois autilização de código demanda mais tempo pararealização destas atividades. Além disso, embora aferramenta Apache serviceMix 4.5.3 possua uma

48

documentação abrangente, esta documentação foiconsiderada dispersa e de difícil manuseio no momentode avaliação da ferramenta.

Quadro 1 – Ferramentas ESB Funcionalidade/ Ferramenta

ApacheServiceMix4.5.3

Mule ESBCommunity 3.4.0

WSO2 ESB4.8.0

Instalação Descrita Descrita Descrita

Transparência Sim Sim Sim

Transformação XSLT Gráfica – clicar emover (XSLT,XPath e XQuery)

XSLT, XPath,Xquery eSmooks

Roteamento eAprimoramento

NormalMessage theRouter

Componentevisualconfigurável

EnterpriseIntegrationPattern

Segurança Ws-Security Acoplável Ws-Security

Monitoramento Acoplado Acoplável Web-Based

Interfacegráfica

Prompt, fuseou eclipse

Própria com clicare mover

Netbeans ouEclipse

Extensibilidade Java, Springe LinguagemScript

Java Java, Pojo,Spring elinguagensScript

Licença Apache v2 CPAL Apache v2

Lançamento 10/2013 08/2013 12/2013

Arquitetura OSGi comsuporte a JBI

Própria comsuporte a JBI(Mule JBI)

OSGi

Fonte: Produção da própria autora

49

A ferramenta Mule ESB Community 3.4.0 ganhadestaque entre as demais por apresentar umaplataforma de integração flexível e visual que agiliza efacilita tanto a aprendizagem quanto a utilização daferramenta por parte da equipe de desenvolvimento egerenciamento. Além da facilidade de aprendizagem emanuseio da ferramenta, a documentação foiconsiderada mais organizada. A classificação eorganização do conteúdo disponível na documentaçãotorna as buscas pelas informações necessárias menoscomplexas e demoradas se comparada às demaisferramentas avaliadas.

Apesar da ferramenta WSO2 ESB 4.8.0 atenderos pré-requisitos considerados importantes paraimplementação dessa pesquisa, o monitoramento doprocesso nessa ferramenta ocorre apenas em suaplataforma Web-based. Além da limitação nomonitoramento do processo, essa ferramenta, assimcomo a ferramenta Apache ServiceMix 4.5.3, não possuiuma interface amigável que facilite a aprendizagem,desenvolvimento e gerenciamento dos processos denegócio.

Dessa forma, opta-se por trabalhar com aferramenta Mule ESB Community 3.4.0 que se apresentacompleta para implementação dessa pesquisa, bemcomo possui características adicionais com relação asdemais ferramentas que ampliam a possibilidade de usodela em projetos futuros.

50

2.4 ONTOLOGIAS PARA REPRESENTAR ECOMPREENDER O CONHECIMENTO

Devido à complexidade e heterogeneidade dossistemas atuais, torna-se cada vez mais difícil integrá-losa fim de torná-los aptos a trabalharem de forma conjuntae coordenada (KASHYAP, BUSSLER e MORAN, 2008).A abundância de informações disponíveis provoca aocorrência de ambiguidades que dificultam a busca erecuperação de informações quando desejadas emdeterminados momentos.

A dificuldade para encontrar determinadasinformações armazenadas em computadores criaram anecessidade de adição explícita do significado dessesdados. Com base nessa necessidade, foram propostosmecanismos de indexação de informações para facilitara localização e, por consequência, o processamento dasinformações desejadas. Dentre esses mecanismos,destaca-se o uso de ontologias para representar ecompreender o conhecimento armazenado.

Uma ontologia pode ser vista como umaabstração para representar, compreender e recuperar oconhecimento humano (BEM e COELHO, 2013) por meiode um conjunto de conceitos com suas propriedades einter-relações (KASHYAP, BUSSLER e MORAN, 2008).O conceito de ontologia é aplicado por diversas áreascomo gestão do conhecimento, recuperação deinformação, sistemas de informação, etc.

Na área de ciência da computação o uso deontologias foi intensificado com a proposta de websemântica, surgida devido a popularização da internetque desencadeou a necessidade de novas abordagens

51

para representar, armazenar, processar, organizar,acessar e compartilhar informações de diversas formas(ALMEIDA e BARBOSA, 2009 e DUTRA et al., 2013).

A web semântica foi proposta em 2001 por TimBerners-lee e outros pesquisadores com intuito desolucionar o problema de falha na interpretação doscomputadores e reduzir o tempo de busca dasinformações (BERNERS-LEE, HENDLER e LASSILA,2001 e SALES, CAMPOS e GOMES, 2008). A intençãoda proposta é adicionar metadados aos recursos jápublicados na web por meio do uso de ontologias. Umavez que metadados sejam adicionados aos recursos,eles possibilitam o uso de termos de referência empublicações, documentos ou outras formas de troca deinformações entre sistemas de diversas empresas, sejapela web ou outra forma definida para buscar oconhecimento disponível (KASHYAP, BUSSLER eMORAN, 2008).

Ontologias podem ser representadas por meio detextos, tabelas, gráficos ou linguagens específicas. Entreas linguagens de representação destacam-se: RDF(Resource Description Framework) que possui boaflexibilidade de representação por ser equivalente aoparadigma de redes semânticas; OIL (OntologyInference Layer), derivada da RDF, que ampliou acapacidade de representação da primeira e, por fim,OWL (Ontology Web Language) recomendada pela W3Cpara representação de ontologias na web (ABEL eFIORINI, 2013). As diferenças entre as linguagens estãona facilidade, expressividade e propriedadescomputacional que cada uma oferece (NAZÁRIO,DANTA e TODESCO, 2012).

52

A Figura 1 apresenta um exemplo de aplicação douso de uma ontologia para representação e busca dedeterminada informação. Observa-se nela o retângulo naparte superior que representa uma informação, aselipses preenchidas que representam a ontologia criadae as elipses tracejadas e sem preenchimento querepresentam a base de conhecimento usada para anotare enriquecer semanticamente o texto contido noretângulo superior.

Figura 1 – Representação de uma ontologia

Fonte: Adaptado de Tramontim Junior e Rabelo, 2007

Com base nas informações providas pelaontologia, é possível extrair do texto “Comarch concluiu aimplementação do seu Sistema de Gestão derevendedor no Vivatel, a terceira maior operadora GSM

53

da Bulgária” os seguintes significados: Vivatel é umacompanhia de telecomunicações; Comarch é umacompanhia de TI localizada na cidade Krakow, que fazparte do país Polônia, que é parte do continente Europa.

Com a representação explícita e formal doconhecimento provido pelas ontologias, tanto o serhumano quanto as máquinas podem interpretarsemanticamente que "Comarch" é uma Companhia de TIlocalizada na Polônia e que faz parte da Europa(TRAMONTIN JUNIOR e RABELO, 2007). Dessa formaquando for necessário, por exemplo, buscar textos quecontenham informações sobre empresas de TIlocalizadas na Europa, o texto apresentado no retângulosuperior da Figura 1 será parte do resultado.

A utilização de ontologias na representação ebusca do conhecimento permite: I) estabelecerhierarquia de classes, instâncias e relacionamentos; II)adicionar regras de inferência; III) representar asinformações no nível semântico dos recursos; IV)recuperar informações com maior significado(semântica); V) enriquecer a descrição de serviços e VI)auxiliar na automatização de serviços que precisaminterpretar informações (AKKIRAJU et al., 2005).

O uso de ontologias permite adicionarrelacionamentos e regras entre os termos paraformalizar, descrever e organizar o conhecimento. Dessaforma, se comparada a outras abordagens derepresentação, a ontologia possibilita melhor definiçãoda semântica do conhecimento, da formalização e dalegibilidade tanto por humanos quanto por computadores(NAZÁRIO, DANTAS e TODESCO, 2012).

O conceito de representação permite aidentificação automática de parâmetros sinônimos,

54

mesmo que armazenados com diferentes denominações.Os recursos (serviços e parâmetros) das PMEsparticipantes do ACV podem ser representadas em umaontologia por meio de um conjunto de conceitos comsuas propriedades e possíveis relacionamentos de formaque os computadores se tornem capazes decompreender as informações ali contidas.

O maior diferencial no uso de ontologias é apossibilidade de busca semântica com foco nosresultados. Por exemplo, ao realizar uma busca naontologia pela “cidade” de “São Paulo” o resultadodeverá omitir informações sobre o “time de futebol”, o“santo” ou o “estado” como um todo se não estiveremrelacionadas diretamente à cidade buscada. Assimcomo, em uma busca por fotografias de casas podemretornar imagens salvas no banco de diversos paísescom diferentes denominações como “house” (Inglês),“casa” (Português), “haus” (Alemão) ou “dom” (Polonês)desde que relacionadas corretamente na ontologia.

Pesquisadores têm identificado a importância dasontologias para representação e busca do conhecimento,de forma que direcionam suas pesquisas para esta áreacom objetivos de automatizar cada vez mais aidentificação semântica. A seção 2.5 apresentapesquisas consideradas relacionadas por abordarem autilização de ontologias com foco na integração desistemas que possuem dados heterogêneos.

55

2.5 TRABALHOS RELACIONADOS

Com o aumento da necessidade de interpretaçãosemântica por parte dos computadores para diversosfins, as técnicas de recuperação semântica deinformações baseadas no uso de ontologias têm seexpandido cada vez mais. Os ACVs não ficam fora dessaevolução, pois para estabelecer a comunicação entre osparticipantes é necessária uma intensa troca demensagens em diferentes formatos.

Dessa forma, são analisados trabalhos queutilizam representação semântica de modo que aproposta possa ser replicada no contexto de ACVs,mesmo quando não desenvolvidas para esse fim. Aseguir são descritas as implementações dos trabalhosrelacionados.

Duo, Juan-Zi e Bin (2005) propõem a traduçãodos esquemas XML por meio de regras para umaontologia temporária que deve ser mapeada para aontologia geral por meio da análise morfológica eestrutural de ambas as ontologias envolvidas. Ou seja,neste caso o esquema XML utilizado pelas PMEs parainvocação dos serviços deve ser lido e traduzido parauma ontologia temporária, para então ocorrer omapeamento com a ontologia geral e possibilitar acompreensão dos sinônimos envolvidos e estabelecer acomunicação.

Wang, Wong e Wang (2010) propõem a criação deuma ontologia para cada PME participante com posteriormapeamento para uma ontologia pública como forma deautomatizar a comunicação entre elas. As ontologias são

56

criadas para representar cada uma das PMEs e umaontologia genérica é criada para representar asinformações do ACV. Dessa forma, no momento deestabelecer a comunicação entre as PMEs, ospesquisadores propõem que as ontologias individuaissejam mapeadas para a ontologia pública.

Tramontin Junior, Rabelo e Hanachi (2010)apresentam um modelo baseado no uso de ontologiaspara representar o contexto de cada usuário em umaRCO. A proposta foi idealizada sobre um arcabouço debusca semântica e consiste no relacionamento dosconceitos da ontologia com os elementos de contextoidentificados, o que permite a realização de umafiltragem baseada em regras para sugerir novos tópicosde busca. A aplicação de semântica na representação docontexto e busca de informações das PMEs do ACVpode ser replicada para a busca e identificação dosparâmetros definidos pelos participantes de formaindividual.

Santos (2011) estabelece um modelo deinteroperabilidade similar à proposta de Wang, Wong eWang (2010), porém entre sistemas de uma mesmaempresa. A proposta de Santos (2011) consiste em criaruma ontologia para representar cada sistema e umaontologia geral na qual as demais ontologias devem sermapeadas. Embora este modelo não tenha sidoidealizado para ACVs é possível correlacionar aproposta, se cada sistema da empresa representar umaPME participante e a ontologia geral representar o ACV.No momento de iniciar a comunicação, os atributos detodas as ontologias devem ser relacionados à ontologiado ACV.

57

Li, Xie e Tang (2012) abordam a criação deontologias por participante e interligação delas por meiode regras de inferência. As ontologias são criadas emnível de tarefa, serviços e recursos utilizados paraprodução de um determinado produto. Elas representamuma rede virtual estática, de forma que a produção dediferentes tipos de produtos envolve a criação dediferentes ontologias. Após a criação das ontologias asregras de negócio são transformadas em regras deraciocínio que permitem a organização e descoberta doconhecimento. Essa abordagem torna-se trabalhosa emambientes dinâmicos como as OVs que mudam deobjetivos e participantes constantemente.

Tu, Zacharewicz e Chen (2014) propuseram acriação de uma ontologia para cada sistema a serintegrado que deve ser enviada com a mensagem nomomento de estabelecer a comunicação. Ao receber amensagem e a ontologia do emissor, o receptor precisacorrelacionar ambas para compreender o significado. Oreceptor poderá, de acordo com regras definidas, incluiras novas informações em sua própria ontologia edescartar a ontologia recebida. Ou seja, no contexto doACV, cada PME teria sua própria ontologia que seriaenviada junto com a mensagem e de acordo com regrasdefinidas seria compreendida pelo receptor quemapearia a ontologia recebida à ontologia própria ecompreenderia a mensagem.

O Quadro 2 exibe de forma resumida ascaracterísticas (colunas) listadas para cada trabalho(linhas) analisado.

58

Quadro 2 – Características das pesquisasPesquisa /Característica

Suportaserviços

SuportaESB

Ontologia

Duo, Juan-Zi, Bin Sim Não Por XML + 1geral

Wang, Wong e Wang(2010)

Sim Não Por participante+ 1 pública

Tramontin Jr, Rabelo eHanachi (2011)

Sim Não Por contexto

Santos (2011) Nãoencontrado

Não Por sistema + 1geral

Li, Xie e Tang (2012) Sim Não Por participante(tarefa, serviçose recursos)

Tu, Zacharewicz e Chen(2014)

Sim Não Por sistema

Fonte: Produção da própria autora.

Nota-se que as abordagens apresentadas, seaplicadas no âmbito de ACVs, adicionam o tempo e otrabalho necessário para relacionar as ontologias decada PME na fase de criação da OV. Quanto mais tempoa fase de criação da OV demorar, mais tempo as PMEsficam à espera do início das atividades. Dado que oinício da produção impacta diretamente na data deentrega do pedido e liberação dos participantes paraatenderem outras demandas, o custo e o trabalho darealização dessa atividade precisam ser reduzidos.

Outro ponto relevante é que as pesquisasdescritas não mencionam o uso de ferramentas ESBs

59

como auxiliares no processo de integração ecomunicação entre os sistemas. Conforme expostoanteriormente, o ESB apoia a arquitetura SOA comrequisitos fundamentais para formação de OVs comosegurança, confiabilidade, gerenciamento de transaçõese orquestração dos processos de negócio.

Neste trabalho, diferente dos trabalhosanalisados, propõe-se criar uma única ontologia para oACV. Essa ontologia representa os recursosdisponibilizados pelas PMEs participantes do ambiente.Ao ser aceita pelo ACV, os metadados da PME precisamser inseridos na ontologia.

Assim, no momento em que uma demanda éidentificada e inicia-se a criação da OV, a semântica dosparâmetros dos serviços das PMEs escolhidas já éconhecida. Ou seja, a identificação dos parâmetrossimilares se torna automática. Para mapeá-los énecessário apenas identificar as mensagens trafegadasna rede. Se alguma PME alterar as denominações emsua(s) base(s) de dados, deve-se atualizar a ontologia.

60

61

3 SOLUÇÃO PROPOSTA

Para facilitar a criação de OVs, o ACV forneceuma série de elementos de ordem organizacional, legal,técnica, tecnológica, financeira, tributária, etc. Entretanto,estes elementos precisam ser discutidos e acordadospelos participantes, antes que eles estejam prontos paraformação de OVs. Dentre os elementos mencionadosacima, neste trabalho recebem destaque: I) ainfraestrutura de TIC que suporta a comunicação entreas organizações e II) os processos de negócios quedefinem as regras de trabalho dentro das OVs.

Sobre a infraestrutura de TIC, como mencionadono capítulo 2, foram apresentadas algumas propostas aolongo das últimas décadas, entretanto, a mais utilizadarecentemente é a arquitetura SOA com apoio deferramentas ESB. O objetivo da infraestrutura é proversuporte a interconexão entre as PMEs para que assimelas possam executar os processos de negóciosutilizados na realização do trabalho da OV.

Sobre os processos de negócio, é importantedestacar que eles envolvem a invocação de processosinternos das PMEs da OV. Neste ponto é que acontecemos problemas mencionados no capítulo 1 e que fazemparte do objetivo deste trabalho. Estes problemas estãorelacionados às incompatibilidades semânticasexistentes entre as interfaces de comunicação dosprocessos internos das diferentes PMEs e dos processosde negócio do ACV.

Assume-se neste trabalho que as PMEsselecionadas para participar de uma OV têm uma

62

interface pública orientada a serviço de seus processosinternos necessários a operação da OV. Ou seja, asPMEs têm capacidade de disponibilizar serviços paraque os demais participantes acessem. Esses serviçosestão relacionados principalmente ao processo deprodução, como consultar estado do pedido, verificarquantas peças foram produzidas por determinada PMEou por todas elas, atividades em execução, etc.

Sob o ponto de vista de integração, o problemaatacado neste trabalho está na mediação e resoluçãodas incompatibilidades semânticas existentes naintegração dos processos das PMEs participantes doACV.

Para mediar e resolver situações associadas àincompatibilidade semântica, a literatura destaca o usode ontologias como uma ferramenta capaz derepresentar formalmente a semântica de um domínio (vercapítulo 2). A representação semântica permite mapearde forma automática as correspondências entreconceitos com diferentes denominações consideradossinônimos dentro do domínio representado.

A identificação dos diferentes conceitos utilizadospara representar operações e parâmetros com mesmosignificado por diversas PMEs é uma atividade queprecisa ser realizada para que os sistemas sejamintegrados. Dessa forma, a propriedade de mapearcorrespondências entre conceitos sinônimos éfundamental para o propósito de integração de sistemas.

A inserção de suporte semântico permite que omapeamento de parâmetros seja realizado de formaautomática na fase de integração dos sistemas. Comisso as PMEs se tornam aptas a cooperarem entre si deforma acelerada se comparado ao processo realizado de

63

forma manual e, portanto, os prazos de entrega sãoantecipados. Ao antecipar a entrega, antecipa-setambém a obtenção de lucro (se houver) e a liberaçãodas PMEs envolvidas para colaborarem em outrademanda.

Para isso é necessário que ao aceitar participar doACV, os recursos disponibilizados pela nova PME sejaminseridos na ontologia e consequentemente atualizadoscaso a PME realize alterações no(s) banco(s) de dados.Com os recursos já conhecidos e relacionados, nomomento em que for preciso mapear os dadosnecessários para integração dos sistemas entrequaisquer PMEs para formação de uma OV, bastaráincluir o mapeador semântico no processo.

Com o mapeador semântico adicionado noprocesso, a atividade de identificar os dados e mapeá-los manualmente torna-se automática. A redução dotempo da atividade de integração dos sistemas estádiretamente relacionada à quantidade de dados erespectivos sinônimos envolvidos, bem como, aoconhecimento tácito da equipe de desenvolvedoresresponsáveis pela integração em reconhecer os dados.Pois, a dificuldade em identificar os sinônimos de formamanual para a atividade de mapeamento, pode variar deacordo com o conhecimento adquirido pelosdesenvolvedores ao longo do período de experiência dotrabalho desenvolvido no contexto, enquanto omapeamento semântico dependerá apenas de umaontologia preenchida de forma concisa, antes danecessidade de integrar os sistemas.

Cada vez que a OV atinge o objetivo especificado,ela é dissolvida e as PMEs são liberadas paraparticiparem em outras demandas. Dessa forma, cada

64

vez que uma OV é criada, há necessidade de mapear osdados envolvidos, que dizem respeito a diferentes PMEse diferentes processos/objetivos.

Como mencionado no capítulo 1, o suporte aintegração semântica é desenvolvido para apoiar umaferramenta de comunicação que gerencia a troca demensagens entre as organizações participantes e quepara esta pesquisa é um ESB.

Com base no raciocínio apresentado, a soluçãoproposta para integração dos sistemas das PMEsenvolvidas em OVs é composta por dois elementos:

1. A ontologia que define os serviços contidos nosprocessos de negócios utilizados para gerenciaras OVs e seus respectivos parâmetros. Alémdisso, a ontologia também armazena as instânciasdestes serviços disponibilizados pelas interfacesde cada uma das PMEs pertencentes ao ACV. Oobjetivo desta ontologia é suportar o processo demapeamento de serviços e assim permitir aintegração entre as PMEs contidas no ACV. Ocadastro das instâncias dos serviçosdisponibilizados pela PME, na ontologia, deve serrealizado antes que ela seja selecionada paratrabalhar de forma colaborativa em uma OV;

2. O método de integração de sistemas que realiza omapeamento do serviço invocado pelo cliente(uma PME participante da OV) ao serviçoimplementado pelo servidor (outra PMEparticipante da OV), inclusive seus respectivosparâmetros. Este mapeamento é feito por meio daidentificação dos nomes e parâmetros dosserviços enviados, e após consulta a ontologia,mapeamento destes aos respectivos nomes e

65

parâmetros dos serviços implementados pelaempresa que está sendo invocada. Desta forma, aontologia realiza o papel de um dicionário ondesão consultados sinônimos (conceitos comdiferentes denominações mas que possuem omesmo significado) dos parâmetros de cadaserviço representado na ontologia.

3.2 ONTOLOGIA DE MAPEAMENTO DE SERVIÇOS

A ontologia foi estruturada em formato RDF (verApêndice A) para representar os serviços e parâmetrosutilizados no processo de negócios definido por um ACVde forma genérica para criação e operação de OVs. Pormeio da inserção das denominações dos serviçosdisponíveis e dos relacionamentos definidos entre osparâmetros é possível identificar a semântica envolvidano ambiente. Dessa forma, para aplicação em diferentesACVs é necessário cadastrar os diferentes serviços eparâmetros utilizados pelas PMEs envolvidas mantendoa estrutura proposta para a ontologia conforme descrito eavaliado a seguir.

A Figura 2 apresenta a ontologia desenvolvidapara automatizar o processo de mapeamento dos dadosna fase de criação da OV. Para facilitar a compreensão,a Figura 3 mostra os serviços e suas relaçõeshierárquicas, a Figura 4 apresenta os objetos e suasrelações hierárquicas e a Figura 5 apresenta o exemplode um serviço chamado “ConsultaProducao” e asrelações com seus objetos e possíveis sinônimos.

66

Figura 2 – Ontologia do processo de produção


67

Conforme visualizado a classe OWL “Thing”, raizda ontologia, tem duas subclasses a “Serviços” e a“Objetos”, as quais têm subclasses e relacionamentosnão hierárquicos que identificam a semântica doambiente. A Figura 3 apresenta a classe “Serviços”.

Figura 3 – Classe “serviços”


Observa-se na Figura 3 que a classe denominada“Serviços” possui como subclasses os serviços utilizados

68

pelas PMEs que compõem o ACV. A Figura 4 apresentaa classe “Objetos”.

Figura 4 – Classe “objetos” com os sinônimos


Conforme visto na Figura 4, a classe “Objetos”representa os dados trafegados na invocação dos

69

serviços. Ela possui os parâmetros e os sinônimosutilizados pelas PMEs para referenciar os objetos.

A ontologia (Figura 2) contempla os serviçosdisponíveis (Figura 3) e os sinônimos necessários(Figura 4). Isso permite localizar e associar osparâmetros (e seus respectivos sinônimos de formaautomática) aos serviços. A Figura 5 exibe uma parte daontologia onde é possível visualizar apenas as classesque representam os parâmetros e possíveis sinônimosassociados ao serviço “consultarProducao”.

Observa-se na Figura 5 que o serviço“consultarProducao” (da classe Serviços) espera recebercomo parâmetros os dados (da classe Objetos) “idPeca”,“idPedido”, “nomePeca”, “qtdPecasRetrabalhadas”,“statusPeca”, “qtdPecasProduzidas” e “idCliente”.Entretanto, pode receber qualquer um dos sinônimoscadastrados na ontologia, pois o método demapeamento saberá identificar cada um de acordo comsua necessidade de processamento.

Sempre que uma nova PME for incluída no ACVou realizar modificações em sua(s) base(s) de dadose/ou serviços disponíveis após ter sido incluída, a equipede desenvolvedores responsáveis pela integração delano ambiente deve analisar as interfaces dos seusserviços e, se necessário, deve inserir na ontologia, osnovos conceitos, dados e sinônimos identificados. Assim,quando uma nova OV for criada todos os sinônimosnecessários serão encontrados na ontologia de forma afacilitar o mapeamento e agilizar a integração dossistemas para que as atividades sejam iniciadas.

70

Figura 5 – Serviço “consultarProducao” associado aos parâmetros da classe Objetos


71

Com os objetos e serviços incluídos na ontologia épossível interceptar a comunicação entre osparticipantes da OV e, por meio da consulta a ontologiadesenvolvida, transformar a invocação enviada peloemissor em uma chamada no formato esperado peloreceptor. Assim, após o mapeamento, a solicitação seráentendida adequadamente pelo receptor, semnecessidade de adaptações nas interfaces dos serviçosde ambos os lados.

3.3 MÉTODO DE BUSCA E MAPEAMENTO

O método de integração proposto se baseia nouso de uma ontologia para realizar o mapeamento dosparâmetros das mensagens enviadas pelo emissor parao formato de invocação esperado pelo receptor.Entretanto, para que o método funcione adequadamente,tanto os parâmetros definidos na chamada quanto osesperados pelo receptor devem estar especificados naontologia e conter relacionamentos do tipo sinônimo.

Para realizar o processo de mapeamento ométodo desenvolvido deve realizar as seguintes ações:1) analisar o arquivo de comunicação enviado paraidentificar a empresa e o serviço invocados, assim comoos parâmetros enviados para o referido serviço; 2)consultar a ontologia proposta para identificar como oserviço solicitado é disponibilizado pela referidaempresa; 3) identificar os parâmetros esperados peloserviço solicitado por meio de consulta a ontologiacriada (relacionamentos do tipo sinônimo entre os

72

parâmetros) e os enviados na invocação; 4) Construir achamada para invocação correta do serviço solicitado.

A Figura 6 apresenta um exemplo de umainvocação realizada pela PME1 de um serviçoimplementado no servidor da PME2, conformefuncionamento do método de integração proposto.

Figura 6 – Processo de comunicação

Fonte: Produção da própria autora.

Os passos apresentados na Figura 6 podem sercompreendidos da seguinte forma.

1. A PME1 (emissora) faz a invocação, via ESB, deum serviço específico que a PME2 (receptora)deve fornecer por fazer parte da OV. Dentre osparâmetros enviados pela PME1, é possível

73

verificar “ID_PED” e “ID_PECAS” e entre osparâmetros esperados pela PME2 os parâmetroscorrespondentes “idPedido” e “idPeca”;

2. O ESB invoca o mapeador disponível em umservidor próprio com a ontologia (base deconhecimento) e solicita que ele verifique achamada correspondente à implementação naPME2 (receptora) do serviço requisitado pelaPME1 (emissora).

3. O mapeador identifica o serviço invocado e buscana ontologia informações de como o serviçosolicitado pela PME1 (emissora) foi implementadopela PME2 (receptora), e se encarrega deidentificar os parâmetros enviados e mapeá-losconforme especificado na ontologia.

4. O mapeador retorna ao ESB o serviço solicitadodevidamente mapeado para a invocação dele.

5. Finalmente, o ESB faz a invocação do serviço daPME2, que após executado, é mapeado pelomapeador para o resultado esperado pela PME1.A inserção dos dados na ontologia é um aspecto

fundamental no sucesso do processo de integração, poisse ela não contemplar os serviços e parâmetrosutilizados pelas PMEs contidas no ACV ocorrerá erro noprocesso de mapeamento. Portanto, a ontologia deve seratualizada sempre que uma nova PME passar a integraro ACV ou que alguma PME realizar alterações em sua(s)base(s) de dados e/ou serviços disponíveis.

O protótipo desenvolvido pode ser disponibilizadocomo um serviço em um servidor junto com a ontologia(base de conhecimento) que será consultada. Assimquando ocorrer a invocação de um serviço o ESB deve

74

primeiro invocar o mapeador e indicar-lhe qual serviçoserá utilizado e entregar-lhe o objeto XML recebido.

As triplas RDF da ontologia contemplam osrelacionamentos necessários (conforme seção 3.2) paraque o método de busca seja capaz de identificar osparâmetros e sinônimos procurados. O Métododesenvolvido em linguagem Java verifica na ontologia,por meio de buscas SPARQL, quais parâmetros oserviço invocado – e já conhecido – espera receber. Emseguida, realiza outra consulta SPARQL para identificarquais são os relacionamentos de sinônimos existentesentre os parâmetros enviados pelo emissor e osparâmetros esperados pelo receptor para então realizaro mapeamento.

75

4 AVALIAÇÃO DOS RESULTADOS

A avaliação deste trabalho é fundamentada naanálise e consultas realizadas na ontologia concebidapara validação do método proposto. A ontologia éavaliada através da aplicação de métricas proposta porBachir Bouiadjra e Benslimane (2011) que medem o graude cobertura dos resultados, de riqueza narepresentação do conhecimento e de detalhamento denível da ontologia.

O método proposto é avaliado por meio darealização de experimentos no protótipo desenvolvidoonde o objetivo é identificar se ele provê automação eflexibilidade ao processo de integração de PMEsenvolvidas em OVs.

A seguir, a seção 4.1 apresenta o processo denegócio que exemplifica o cenário de teste utilizado naavaliação deste trabalho, a seção 4.2 mostra o ambientecriado para simular este cenário e, por fim, as seções 4.3e 4.4 detalham a avaliação da ontologia e do método,respectivamente.

4.1 PROCESSO DE NEGÓCIO DE EXEMPLO

O BPMN de referência foi definido de formagenérica e pode ser aplicado em vários tipos de ACV ou,se necessário, pode ser especializado para um domínioparticular. O exemplo utiliza como cenário o pedido deum cliente que pretende abrir um novo restaurante eprecisa de mesas e cadeiras personalizadas.

76

Um ACV pode, por exemplo, identificar aoportunidade e buscar entre seus participantes umaPME que produza as partes de madeira, outra queproduza o tampo de vidro, uma terceira que faça oestofamento das cadeiras e uma quarta que realize amontagem e entrega dos itens.

A Figura 7A apresenta as atividades realizadaspelo ACV enquanto a Figura 7B apresenta as atividadesrealizadas pelas PMEs participantes.

Figura 7A – BPMN do processo (atividades do ACV)


Conforme o BPMN apresentado na Figura 7A,após a solicitação do cliente, o ACV recebe asinformações do pedido e avalia a possibilidade de

77

atendê-lo. Se for possível atender a demanda, o ACVretorna ao cliente com uma resposta informando que opedido foi aceito conforme proposto. Se o pedidonecessitar de alguns ajustes para que o ACV possaatendê-lo, o ACV pode modificar o pedido e enviar aocliente uma resposta mais detalhada que informe sobreas alterações propostas. Se não for possível atender asolicitação, o ACV pode enviar ao cliente uma respostasimples para informar que o pedido foi rejeitado ou umaresposta detalhada para informar também os motivos darejeição.

Se o cliente confirmar o pedido, o ACV deveráselecionar os participantes aptos e interessados ematender a solicitação. Nessa fase o ACV entra em umlaço de repetição até que as PMEs necessárias paracada parte do pedido sejam selecionadas.

No momento em que o ACV forma a OV, estapassa ao processo de produção e as PMEs selecionadasinteragem entre si como se fossem uma únicaorganização. Após iniciar a OV, o ACV aguarda até que opedido seja totalmente atendido e a OV notifique suaconclusão. Após receber a notificação de conclusão oACV encerra a OV.

A Figura 7B apresenta o fluxo que deve serexecutado pelas PMEs selecionadas que participam daOV criada. Após a formação da OV, a comunicação entreas PMEs inicia-se com a distribuição das tarefas a seremexecutadas. Nesse momento, as tarefas são listadas edistribuídas entre as PMEs selecionadas de acordo como pedido realizado pelo cliente e com a capacidade deprodução de cada organização participante, para queestas iniciem a produção.

78

Figura 7B – BPMN do processo (organizações)


Imediatamente após receber as tarefas a seremrealizadas as PMEs participantes iniciam suasatividades. Uma das informações mais compartilhadasentre os participantes da OV diz respeito ao status deprodução dos itens alocados a cada PME. Cadaparticipante é responsável por gerenciar suas atividadesinternas a fim de realizar as tarefas incumbidas e estarapto a informar o status da produção a qualquermomento. As PMEs permanecem nessa atividade atéque a produção dos itens alcance 100%.

A comunicação entre as PMEs participantes e oACV no intuito de atualizar o status da produção éessencial para que a OV possa monitorar os prazos e asentregas. Ao considerar a produção de mesas e cadeirascomo exemplo, nesta fase as PMEs executam as tarefas

79

de produção das estruturas de madeira, dos tampos devidro, dos estofamentos e da montagem dos itens.

Esta produção precisa ser monitorada, pois, porexemplo, os estofados só poderão ser feitos depois queas cadeiras estiverem prontas e forem entregues aoestofador. Qualquer atraso na liberação das cadeirascomprometerá o planejamento do estofador. Issotambém deve ser resolvido pela OV, que monitora arealização do processo de negócio.

Após a conclusão das tarefas, a entrega érealizada ao cliente e a OV notifica o ACV para quepossa dissolvê-la. Com a dissolução da OV as PMEsparticipantes são liberadas para participarem naformação de outras OV, pois o objetivo é consideradoatendido.

Após a definição dos diagramas BPMNapresentados nas Figuras 7A e 7B, o processo foiexportado para BPEL para ser executado por um motorde execução de processos, que no caso deste trabalho éuma ferramenta ESB. A definição do BPMN e aexportação para BPEL foram realizadas com auxílio daferramenta TIBCO Studio Community-3.5 (TIBCO).

4.2 AMBIENTE DE SIMULAÇÃO

Para simular a arquitetura de aplicação da soluçãoproposta foi projetado um ambiente composto por 5máquinas virtuais, conforme apresentado na Figura 8,onde se destacam dois tipos de servidores, um querepresenta o ACV e os outros que representam as PMEs

80

que fazem parte do ACV. Cada um destes dois tipos édetalhado a seguir.

Figura 8 – Ambiente de simulação


O Servidor1, apresentado na parte central daFigura 8, é utilizado no gerenciamento do ACV e contémos seguintes componentes:

81

1. Os dados de entrada do cliente seja por meio dainterface do sistema do ACV ou por sitedisponibilizado (não desenvolvido);

2. A suíte de aplicações utilizadas pelo ACV para ogerenciamento dos processos de negócioenvolvidos na criação e operação de OVs;

3. O ESB que possibilita a comunicação entre asPMEs participantes, por meio da execução doBPMN expresso em BPEL que coordena oprocesso de negócio e invoca os serviçosnecessários;

4. O componente desenvolvido como parte dasolução proposta neste trabalho para facilitar omapeamento dos dados envolvidos nacomunicação e

5. A base de conhecimento que contém a ontologia esuas instâncias. Cada um dos servidores 2 a 5 representam uma

PME que faz parte do ACV e que para participarem daOV precisam se conectar umas com as outras.

Para simular as incompatibilidades semânticas naintegração entre as PMEs envolvidas, cada umadisponibiliza, em seu servidor de aplicações, serviçosque atendem as atividades contidas no processo denegócio do ACV, porém com diferentes parâmetros.Dessa forma, sempre que um serviço de uma PME forinvocado pelo ACV ou por outra PME é necessárioprimeiramente mapear os parâmetros envolvidos pararealizar a correta chamada do serviço solicitado.

O ambiente configurado possibilita – para fins dedesenvolvimento e teste do protótipo de solução deintegração proposta – a inclusão do pedido do cliente noACV e o gerenciamento das atividades das OVs. Para

82

que as PMEs consigam trabalhar de forma coordenada énecessário que elas conheçam o fluxo definido paraexecução do processo definido na seção 4.1.

4.3 AVALIAÇÃO DA ONTOLOGIA

Bachir Bouiadjra e Benslimane (2011) sugerem aaplicação de um método denominado FOEval comdefinição de algumas métricas consideradas relevantespara avaliação adequada de uma ontologia. Os autoresdefinem primeiramente algumas questões que devemser levadas em consideração para aplicação daavaliação em uma ontologia qualquer. Estas questõessão apresentadas a seguir:

1. O que avaliar? Se deseja avaliar a ontologia comoum todo ou apenas parte dela. No caso daavaliação realizada neste trabalho, deseja-seavaliar a ontologia completa, pois trata-se de umaontologia que será explorada de forma ampla nomomento de sua utilização.

2. Por que avaliar a ontologia? Busca-se com essaavaliação identificar se a ontologia desenvolvidapossui boa cobertura, riqueza e nível de detalhes,ou seja, se ela consegue responder as questõesbuscadas e se foi bem projetada com relação asuas classes e propriedades.

3. Quando deve ser avaliada? A ontologia passa pordiversas avaliações em seu ciclo de vida: a) antesda criação para definição dos recursos a seremutilizados; b) durante o processo de construção

83

para localizar e corrigir possíveis falhas; c) quandohá evolução para verificar se a qualidade não foiafetada com as alterações; d) antes de utilizar aontologia fora do ambiente de testes para verificarse está adequada às necessidades para as quaisfoi projetada. Apresenta-se nesta seção aavaliação realizada na fase “d”, para validação daproposta que poderá ser aplicada em ambientesreais de ACV posteriormente.

4. Deve ser avaliada com base em quê? Define-secomo a ontologia deve ser avaliada, pela estruturade criação, por um padrão definido, pelas tarefasa serem executadas, pela opinião de especialistasou por quaisquer critérios desejáveis. Nestaavaliação busca-se verificar se a estrutura decriação foi bem definida, se é capaz de executaras tarefas necessárias e se atende aos critériosesperados.Após a definição da metodologia, as métricas

definidas por Bachir Bouiadjra e Benslimane (2011)consideradas aplicáveis ao propósito de avaliação forammedidas e os resultados são apresentados a seguir.

A cobertura dos termos (Ct) reflete a identificaçãode determinadas classes na ontologia a partir deparâmetros de busca considerados chave. Por exemplo,se o termo de busca for “dataEntrega” e a ontologiapossuir uma classe com esse nome, ela será retornada.A Ct é representada pelo somatório das classesexistentes na ontologia para as quais existemcorrespondências entre os termos buscados e nomedefinido para a classe.

Para a ontologia avaliada, o valor obtido para amétrica de Ct é de 100% de cobertura, visto que para

84

todos os parâmetros buscados foram encontradasclasses correspondentes cadastradas. Isso ocorredevido ao fato de que quando uma nova PME passa aintegrar o ACV, os dados da mesma devem sercadastrados na ontologia para que possam serlocalizados quando necessária realização de buscas emapeamentos. A classe correspondente ao parâmetrobuscado não será localizada somente se houver falhahumana no momento de inclusão do novo participante e,nesse caso, ocorrerá falha no processo de comunicação.

A riqueza das relações (rR) reflete a diversidadedas relações na ontologia. A rR é representada pelarazão entre o número de relações não hierárquicas daontologia e o número de todas as relações. Para aontologia avaliada, o valor obtido para a métrica de rR éde 0,63, ou seja, 63% das relações existentes naontologia são não hierárquicas e apenas 37% sãorelações de hierarquia. A ontologia avaliada é rica emrelações pois, quanto mais próximo de 1 for o resultado,maior é a quantidade de relações não hierárquicas, ouseja, mais rica é considerada (SICILIA et al., 2012).

A riqueza dos atributos (rA) reflete a qualidadereferente à quantidade de informações relativas nasinstâncias. A rA é calculada com a divisão das relaçõesnão hierárquicas pelo número de classes na ontologia.Para a ontologia avaliada, o valor obtido para a métricade rA é de 1,68, ou seja, cada classe possui em média1,68 relações não hierárquicas com outras classes.Quanto maior o número de atributos definidos, maior oconhecimento transmitido (MOURA et al., 2013), dessaforma considera-se que a ontologia possui boa rA, pois,possui em média mais de um atributo por classe.

85

A métrica de riqueza da ontologia é composta pelasoma do resultado obtido no cálculo da rR com o obtidona rA. Dessa forma, o resultado obtido pela riqueza daontologia é 2,31. Com a riqueza das relações em 63% euma média de 1,68 relações por classe.

A riqueza da ontologia demonstra que há maisrelações entre as classes que identificam sinônimospara mapeamentos do que o próprio número de classescadastradas, isso ocorre devido ao reaproveitamento doconhecimento inserido na ontologia, por meio da adiçãode atributos e relações. Para o mapeamento dosparâmetros na formação de OV é importante que hajammais relações não hierárquicas que indicam quaisparâmetros/classes podem ser considerados sinônimosdo que hierárquicas que apenas classificam as classescadastradas. Dessa forma, a ontologia desenvolvidapode ser considerada rica tanto em termos derelacionamento quanto em termos de atributos.

A métrica de detalhe de nível global (dNG) refleteo quão bem agrupado o conhecimento se encontra entreas diversas classes e subclasses da ontologia. A dNG érepresentada pelo número médio de subclasses porclasse existente na ontologia.

Para a ontologia avaliada, o valor obtido para amétrica de dNG é de 0,95. Valores próximos de zeroindicam uma ontologia horizontal enquanto valores maispróximos de 1 indicam uma ontologia vertical (SICILIA etal., 2012). A ontologia avaliada é considerada verticaltanto pelo resultado da métrica quanto pelo seu objetivoprincipal de representar detalhes de um domínio - ACV -específico (SICILIA et al., 2012 e DAVID et al., 2014).

A métrica de detalhe de nível específico (dNE)indica o nível médio em que os termos pesquisados se

86

encontram na ontologia. A métrica de dNE é formalmentedefinida como a razão entre a soma do número médio desubclasses e superclasses para a classe buscada e onúmero de classes buscadas.

Para a ontologia avaliada o valor obtido para amétrica de dNE é de 3, visto que os parâmetrosbuscados encontram-se após descer ao terceiro nívelhierárquico da ontologia. Esse resultado mostra que abusca pode ser considerada simples e rápida, pois épreciso percorrer, em média, apenas 3 níveishierárquicos para encontrar o termo buscado.

A métrica de detalhe de nível (dN) é compostapela soma do resultado obtido para dNG e dNE. Dessaforma, o dN da ontologia avaliada é de 3,95. Esse valorindica que os resultados são obtidos em média noterceiro nível da ontologia e que se trata de umaontologia vertical criada para um domínio específico.

Os resultados obtidos com a aplicação dasmétricas na avaliação da ontologia indicam que aontologia proposta foi bem definida para os finsdesejados. A ontologia possui uma cobertura precisasobre os termos buscados, boa riqueza tanto de relaçõesquanto de atributos na representação do conhecimento eum nível de detalhe que atende as expectativas para aqual a ontologia foi projetada.

4.4 EXECUÇÃO DO PROTÓTIPO

Esta seção apresenta a utilização da ontologiapelo método de mapeador semântico desenvolvido. A

87

execução consiste em simular a complexidadeencontrada na comunicação entre PMEs de uma OV,onde comumente ocorre invocação de serviços comincompatibilidade semântica entre os objetos trocadoscomo parâmetros entre o emissor e o receptor.

Para isso foram criados 32 documentos XML quesimulam a troca de informações entre as PMEsparticipantes. Os dados contidos nestes documentosrepresentam dados contidos nas bases de dados dasPMEs, ou seja, já adicionados à ontologia no momentoem que foram aceitas no ACV. Assim, é possívelexecutar o método de forma que cada PME simuladainvoque todos os serviços disponíveis no ambiente commapeamento automático entre os parâmetros utilizadosque já se encontram na ontologia.

Com os documentos XML criados e o ambienteconfigurado foi possível simular o processo decomunicação entre as PMEs envolvidas na OV. Nesteprocesso de comunicação o mapeador semânticodesenvolvido precisa encontrar os parâmetros utilizadospelo emissor, identificar por meio de buscas na ontologiaos parâmetros correspondentes (sinônimos) utilizadospelo receptor e criar a mensagem traduzida para oreceptor no mesmo formato de documento.

A Figura 9 exibe o documento XML enviado peloemissor no lado esquerdo e o documento XML entregueao receptor com os parâmetros já mapeados no ladodireito. Para cada um dos campos identificados nodocumento XML enviado pelo receptor, o mapeadorsemântico realiza uma busca na ontologia e identifica oparâmetro correspondente esperado pelo receptor paraentão realizar as trocas e entrega do documento.

88

É possível observar na Figura 9 que algunsparâmetros enviados são equivalentes aos esperadosenquanto outros precisam encontrar diferentescorrespondências no receptor. Todos os parâmetros sãobuscados na ontologia, pois somente após a busca naontologia o mapeador semântico pode saber se oparâmetro enviado é equivalente ao esperado ou não.

Figura 9 – Identificação de parâmetros sinônimos


Os documentos XML criados representam asPMEs, de forma que as invocações simuladas possuemparâmetros com denominações diferentes ou similares

89

às esperadas. Todos os serviços representados naontologia receberam pelo menos uma simulação deinvocação de cada PME participante do ambiente (vermais exemplos em Apêndices B, C e D).

Os resultados obtidos com a aplicação dasmétricas de avaliação indicam que a ontologia propostaprovê a cobertura esperada sobre os termos buscados,se o processo de inserção de dados for realizado deforma adequada; boa riqueza tanto de relações quantode atributos na representação do conhecimento, pois hárelacionamentos e atributos suficientes para que obuscador semântico possa percorrê-la para encontrar asclasses necessárias; assim como, nível de detalhesuficiente para classificar o conhecimento representadoe possibilitar que o buscador percorra poucos níveis embusca do resultado esperado, o que possibilita que asbuscas encontrem resultados de forma ágil.

Os resultados obtidos com a execução doprotótipo confirmam que a busca de sinônimos em umaontologia possibilita a aplicação do conceito de buscasemântica em ESBs. Observa-se nas seções 4.3 e 4.4que é possível automatizar o processo de integração dossistemas pertencentes às PMEs envolvidas em OVs viaESBs. Para tal, é necessário provê-lo de um componenteque utilize uma ontologia construída e preenchida comdados para realizar o mapeamento de parâmetros entreserviços.

Conforme os resultados obtidos com a aplicaçãode métricas e execução do plugin, observa-se que oprotótipo construído para avaliar a proposta se mostroucapaz de oferecer a necessária flexibilidade demapeamento de serviços e e integração de sistemasrequerido pelos ACVs devido à volatilidade das OVs.

90

91

5 CONCLUSÃO

Com objetivo de aumentar a quantidade e aqualidade, bem como reduzir os custos e o tempo deprodução, pequenas e médias empresas (PMEs)compartilham recursos e competências por meio daunião de suas habilidades em redes colaborativas deorganizações (RCOs). As formas mais comuns detrabalho neste tipo de rede são as empresas virtuais(EVs) e as organizações virtuais (Ovs) formadas emambientes de criação de organizações virtuais (ACVs).

Um ACV é responsável por reunir PMEs comobjetivos similares e competências complementares quedesejam atuar de forma colaborativa. Após reunidas,quando uma demanda é encontrada, o ACV inicia a fasede criação de uma OV ou EV com alguns ou todos osseus participantes.

Tanto as EVs quanto as OVs se caracterizam pelareunião de várias PMEs em um ambiente virtual comobjetivo de colaborarem umas com as outras paraatingirem um objetivo comum, entretanto, as EVsobrigatoriamente visam o lucro, enquanto as OVs podemse tratar de instituições beneficentes ou outros projetossem obtenção de lucro. Como a obtenção de lucro éirrelevante para esta pesquisa, EV e OV são tratadascomo similares, pois ambas apresentam necessidade deintegração dos processos para operarem de formacolaborativa.

Para possibilitar a integração dos processos denegócio de forma que as PMEs possam trabalhar deforma colaborativa faz-se necessário utilizar ferramentas

92

e tecnologias que facilitem e auxiliem no gerenciamentoda comunicação entre elas. Como principal tecnologiaapresentada na literatura destaca-se o uso de SOA,enquanto como principal ferramenta para gerenciar acomunicação são destacados os barramentos deserviços corporativos (ESBs).

Embora o ESB promova uma integração segura ecoordenada para integração de sistemas, ele não possuium suporte semântico que ofereça flexibilidade eautonomia no mapeamento dos processos e integração,necessários aos ACVs na formação de OVs. O problemaidentificado e tratado por este trabalho está naintegração dos sistemas das PMEs envolvidas quepossuem diferentes padrões para denominação dosparâmetros utilizados pelas mesmas.

O problema dos parâmetros com diferentespadrões de denominação ocorre porque diferentes PMEspossuem diferentes sistemas construídos por diferentesprofissionais que possuem diferentes conhecimentostácito. Para que a comunicação seja estabelecida entreas PMEs os parâmetros similares precisam sermapeados de forma que os parâmetros enviados peloemissor sejam compreendidos pelo receptorindependente de padrões adotados para definição dosnomes dos parâmetros em ambos os envolvidos.

O processo de mapeamento dos parâmetrosutilizados pelas PMEs costuma ocorrer de forma manual.Com a identificação dos parâmetros envolvidos eassociação destes com possíveis sinônimos no momentode criar uma OV. Para automatizar essa atividadeassumiu-se como hipótese que a criação de umaontologia para representar os conceitos e metadadosdisponibilizados pelas PMEs participantes do ACV,

93

poderia adicionar semântica ao ambiente e facilitar acompreensão e identificação dos parâmetros envolvidos.

Para agilizar esse processo de mapeamento dosparâmetros para criação de OVs, foi proposto nestetrabalho o uso de uma ontologia na representação dasinformações contidas no ACV. Com a concepção daontologia foi possível desenvolver um método a serexecutado pelo ESB de forma que a realização doprocesso de identificação e mapeamento de parâmetrosconsiderados sinônimos seja realizado de formaautomática e agilize o início da comunicação entre asPMEs participantes da OV.

Com intuito de validar a solução proposta foramrealizados testes de validação na ontologia através daaplicação das métricas indicadas por Bachir Bouiadjra eBenslimane (2011). As métricas definidas estabelecemvalores para avaliação da cobertura dos termosbuscados, da riqueza de representação do conhecimentoe do detalhamento de nível da ontologia.

Os resultados indicam que a ontologia apresenta100% de cobertura, ou seja, todos os resultadosesperados retornaram corretamente, quando existentesna ontologia. Também indicam que a riqueza daontologia é de 2,31, ou seja, a ontologia representa oconhecimento com mais relações que classes o quepermite que ela seja considerada rica tanto em termos derelacionamento quanto em termos de atributos. Aontologia apresenta detalhamento de nível de 3,95, ouseja, é classificada como vertical (representa um domínioespecífico de forma detalhada) e as buscas obtêmresultados em média no terceiro nível da ontologia.

Após análise e avaliação da ontologia, o protótipode mapeador semântico desenvolvido foi executado para

94

validação do funcionamento do método proposto. A partirda análise das execuções do protótipo foi possívelobservar que o mapeamento automático dos parâmetrosutilizados pelas PMEs participantes do ACV, conformeproposto, permite que o processo de criação de uma OVse torne mais ágil e com menor ocorrência de falhas.Isso ocorre devido ao fato de que os dados dasempresas são adicionados na ontologia apenas nomomento em que estas passam a fazer parte do ACV,sem a necessidade de realizar mapeamento manual dosdados envolvidos cada vez que uma OV é criada.

Com o processo de mapeamento realizado deforma automática e com maior agilidade, conformeproposto, as atividades da OV podem ser iniciadas emmenor tempo e assim concluídas e entregues em dataantecipada. A entrega de um projeto possibilita que asempresas envolvidas fiquem disponíveis para início denovos projetos, ou seja, quanto menos tempo for gastono mapeamento e criação da OV, maior o tempodisponível para que as PMEs envolvidas produzam.

5.1 TRABALHOS FUTUROS

Com os resultados obtidos com esta pesquisa,observou-se que outras características relacionadas aoproblema em questão podem ser exploradas com oobjetivo de melhorar a solução proposta. A seguir sãoapresentadas algumas propostas de trabalhos futuros.

Primeiramente é importante mencionar que aquestão relacionada a sinonímia e homonímia e não

95

foram abordadas neste trabalho. Portanto, um dostrabalhos futuros tem por objetivo criar uma extensão aométodo proposto, que consiga identificar esses termosna ontologia e resolver a ambiguidade entre eles, paraassim poder realizar as respectivas associações entre ostermos que representem corretamente os parâmetrosdos serviços.

Outro exemplo de trabalho futuro está relacionadoa diferença de unidades de medidas e ausência ouexcesso de parâmetros na troca de mensagens. Issoocorre quando a PME emissora envia uma mensagemcom número de parâmetros diferentes (a mais ou amenos) do esperado pela PME receptora ou com valoresem diferentes unidades (quilo para grama, metro paracentímetro, etc.). Indica-se assim a necessidade deacrescentar funções ao método proposto paratratamento dessas diferenças.

96

97

REFERÊNCIAS

AALST, W. M.P. V. D.; HOFSTEDE, A. H. M. T.; WESKE,M. Business process management: A survey. LectureNotes in Computer Science. V. 2678, 2003.

ABEL, M.; FIORINI, S. R. Uma revisão da engenhariado conhecimento: evolução, paradigmas eaplicações. International Journal KnowledgeEgngineering and Management – IJKEM. V2, 2013.

AFSARMANESH, H.; CAMARINHA-MATOS, L. M. AFramework For Management Of Virtual OrganizationBreeding Environments. Em collaborative networks andtheir breeding environments. Valencia, Espanha, 2005.

AKKIRAJU, R. et al. Web Service Semantics: WSDL-S.W3C Member Submission. 2005.

ALMEIDA, M. B.; BARBOSA, R. R. Ontologies inknowledge management support: A case study. .Journal Of The American Society For Information Science& Technology 60. V. 10, 2009.

ALVES, A.; et al. Web Services Business ProcessExecution Language (WSBPEL) TC. OASIS Standard.2007. Disponível em <http://docs.oasis-open.org/wsbpel/2.0/ wsbpel-v2.0.html>. Último acessoem 18-Abr-2014.

98

APACHE. ServiceMix 4.5.3 released. Disponível em<http://servicemix.apache.org/docs/4.4.x/quickstart/quickstart.pdf>. Último acesso em 10-Jan-2015

AZEVEDO, A. C.; SOARES JÚNIOR, L. Modelagem deprocessos de negócios como ferramenta de auxílio àauditoria interna. Revista PREX.2011.PB.0206, 2014.

BACHIR BOUIADJRA A.; BENSLIMANE S. FOEval: FullOntology Evaluation: Model and Perspectives. IEEENatural Language Processing and KnowledgeEngineering (NLP-KE), 7th International Conference onTokushima. 2011.

BALDO, F.; RABELO, R. J. Uma AbordagemEstruturada para Implementação de Ambientes deCriação de Empresas Virtuais. Anais SIMPOI. 2010.

BEM, R. M.; COELHO, C. C. de S. R. Instrumentos deRepresentação do Conhecimento para práticas deGestão do Conhecimento: taxonomias, tesauros eontologias. InCID: Revista de Ciência da Informação eDocumentação. Brasil. V. 4, 2013.

BERNERS-LEE, T.; HENDLER, J.; LASSILA, O.; TheSemantic Web. Em Scientific American, . 2001.

BREOVOLD, H. P.; LARSSON, M. Component-Basedand Service Oriented Software Engineering: KeyConcepts and Principles. Software Engineering andAdvanced Applications. EUROMICRO. 2007

99

CAMARINHA-MATOS, L. M.; AFSARMANESH, H. TheVirtual Enterprise Concept. IFIP Working Conf. onInfrastructures for Virtual Enterprises. . 1999.

______. Collaborative networks: a new scientificdiscipline. Journal of Intelligent Manufacturing.Netherlands. V. 16, 2005.

CAMARINHA-MATOS, L. M. et al. Collaborativenetworked organizations – Concepts and practice inmanufacturing enterprises. Computers & IndustrialEngineering. 2009.

CHAPPELL, D. A. Enterprise Service Bus: Theory inPractice. O'Reilly Media, Inc. 2004.

CHEN, L. Integrating Cloud Computing ServicesUsing Enterprise Service Bus (ESB). Business andManagement Research. DOI: 10.5430/bmr.v1n1p26.2012.

CHINOSI, M.; TROMBETTA, A. BPMN: An introduction tothe standard. Computer Standards & Interfaces. V. 34,2012.

CHONG, A. Y.; OOI, K. Adoption of interorganizationalsystem standards in supply chains: An empiricalanalysis of RosettaNet standards. Industrial Management& Data Systems. V. 108, 2008.

100

DAVID, P. B.; et al. Análise da Afetividade em FórunsVirtuais: Construção de uma Ontologia de Domínio.Nuevas Ideas en Informática Educativa TISE, 2014.

DUTRA, M. L.; et al. Uma abordagem baseada emontologias para a área da logística. Coletânea Luso-Brasileira IV – Gestão da Informação, Inovação eLogística. 2013.

DUO, Z.; JUAN-ZI, L.; BIN, X. Web service annotationusing ontology mapping. Service-Oriented SystemEngineering - SOSE 2005. IEEE International Workshop.20-21 Oct. 2005.

EDEN, A. H. Three Paradigms of Computer Science. Minds and Machines, Special Issue on the Philosophy of Computer Science, Vol. 17, No. 2, 2007.

ERL, T.; SOA Design Patterns. New Jersey: Prentice Hall, 2009.

FILIPPO, D.; PIMENTEL, M.; WAINER, J. Metodologiacientífica em sistemas colaborativos. Cap. 24 emSistemas Colaborativos. - PIMENTEL e FUKS. Rio deJaneiro. Elsevier, 2012.

GARCÍA-JIMÉNEZ, F.J.; MARTÍNEZ-CARRERAS M.A;GÓMES-SKARMETA, A. F. Evaluating Open SourceEnterprise Service Bus. e-Business Engineering(ICEBE), IEEE 7th International Conference on. 2010

101

GEYER, C. ebXML Milestones. ebXML overview. 2006.Disponível em <http://ebxml.xml.org/overview> Últimoacesso em 15-Mar-2014.

HEWIT, E. SOA Implementation Recipes, Tips, andTechniques: Java SOA Cookbook. O’Reilly Media, Inc.Sebastopol. 2009.

HIRATA, C. M.; BERKENBROCK, C. D. M.; PICHILIANI,M. C. Hardware para Colaboração. Cap. 19 emSistemas Colaborativos. - PIMENTEL e FUKS. Rio deJaneiro: Elsevier. 2011.

JÄGERS, H. P. M.; JANSEN, W.; STEENBAKKERS, G.C. A. Characteristics of Virtual Organizations.Primavera working paper. V. 98, 1998.

JBI. JSR 208: JavaTM Business Integration (JBI). 2005.Disponível em <https://jcp.org/en/jsr/detail?id=208>.Último acesso em 20-Mai-2014.

______. JSR 312: JavaTM Business Integration 2.0 (JBI2.0). 2010. Disponível em <https://jcp.org/en/jsr/detail?id=312>. Último acesso em 20-Mai-2014.

KARVONEN, I. et al. Challenges in the management ofvirtual organizations. Em Camarinha-Matos, [S.l.;s.n.].2004.

KASHYAP, V.; BUSSLER, C.; e MORAN, M. TheSemantic Web: Semantics for Data and Services on theWeb. 2008.

102

KAUREMAA, J.; NURMILAAKSO, J.-M.; TANSKANEN,K. E-business enabled operational linkages: The roleof RosettaNet in integrating the telecommunicationssupply chain. International Journal of ProductionEconomics. V. 127, 2010.

LACKENBY, C. e SEDDIGHI, H. A dynamic model ofvirtual organisations: Formation and development. EmCollaborative Business Ecosystems and VirtualEnterprises - CAMARINHA-MATOS. . V. 1, 2002.

LI, C.; XIE, T.; TANG, Y. GMVN oriented S-BOXknowledge expression and reasoning framework. JIntell Manuf, DOI 10.1007/s10845-012-0722-x. 2012.

LI, Q. et al. Business processes orientedheterogeneous systems integration platform fornetworked enterprises. Computers in Industry, V. 61,2010.

LIU, Y. The Implement of UBL in the E-Business.Pervasive Computing Signal Processing and Applications(PCSPA), First International Conference. 2010.

LOSS, L.; RABELO, R. J.; PEREIRA-KLEN, A. A.;Towards Learning Collaborative NetworkedOrganizations. 8th Working Conference on VIRTUALENTERPRISES, Springer: V. 243, 2007.

MAZANEK, S.; HANUS, M. Constructing abidirectional transformation between BPMN andBPEL with a functional logic programming language.

103

Journal of Visual Languages and Computing. V. 22,2011.

MEADOWS, B.; SEABURG, L. Universal BusinessLanguage 1.0. cd-UBL-1.0. 2004. Disponível em<http://docs.oasis-open.org/ubl/cd-UBL-1.0/> Últimoacesso em 29-Abr-2014.

MOURA, H. et al. Developing a Ubiquitous TouristGuide. ACM WebMedia’13, November, Salvador, Brazil,2013.

MULESOFT. Mule Documentation. 2012. Disponível em<http://www.mulesoft.org/documentation> Último acessoem 20-Dez-2014.

NAZÁRIO D. C.; DANTA M. A. R.; TODESCO J. L.Representação de Conhecimento de Contexto eQualidade de Contexto. Jornada Iberoamericana deIngeniería del Software e Ingeniería del Conocimiento.2012.

OsGI. OSGi Core Release 5 Specification. 2012.Disponível em<http://www.osgi.org/Download/Release5>. Últimoacesso em 20-Mai-2014.

PATIL, S.; NEWCOMER, E. ebXML and Web services.Internet Computing, IEEE. V. 07, 2003.

RABELO, R. Advanced Collaborative Business ICTInfrastructures. Em CAMARINHA-MATOS,

104

AFSARMANESH e OLLUS. Methods and Tools forCollaborative Networked Organizations. 2008.

RABELO, R. J. et al. Smart Configuration of DynamicVirtual Enterprises. IFIP International Federation forInformation Processing. V. 149, 2004.

RABELO, R. J.; COSTA, S.; ROMERO, D. AGovernance Reference Model for Virtual Enterprises.Proc. 15th Working Conference on Virtual Enterprises.Amsterdam. Springer, 2014.

RADEMAKERS, T.; DIRKSEN, J. Open Source ESBs inAction. Manning Publications Co. 2009.

ROTH, A. L. et al. Diferencias e interrelaciones de losconceptos de gobierno y gestión de redeshorizontales de empresas: contribuciones al campo deestudio. Rev. Adm. ISSN 0080-2107, V.47, n.1. 2012.

SALES, L. F.; CAMPOS, M. L. A.; GOMES, H. E.Ontologias de domínio: um estudo das relaçõesconceituais. Perspect. ciênc. inf. [online]. v.13, n.2 2008.

SANTOS, K. C. P. Utilização de ontologias dereferência como abordagem para interoperabilidadeentre sistemas de informação utilizados ao longo dociclo de vida dos produtos. Dissertação (EngenhariaMecânica e de Materiais) Universidade Tecnológica doParaná, Curitiba, 2011.

SICILIA, M. A. et al. Empirical findings on ontologymetrics. Expert Systems with Applications 39. 2012.

105

STRAUCH, S. et al. ESBMT: Enabling Multi-Tenancy inEnterprise Service Buses. Institute of Architecture ofApplication Systems, Center of Excellence F&R. 2012.

SWARD, R. E.; WHITACRE, K. J. A multi-languageservice-oriented architecture using an enterpriseservice bus. Proceedings ACM annual internationalconference on SIGA, 2008.

TIBCO. Tibco Documentation. Disponível em<http://www.tibco.com.br/> Último acesso em 3-Fev-2015.

TRAMONTIN JR., R. J., RABELO, R. J. A KnowledgeSearch Framework for Collaborative Networks. EmEstablishing the Foundation of Collaborative Networks.IFIP — The International Federation for InformationProcessing V. 243, 2007.

TRAMONTIN JR., R. J., RABELO, R. J., e HANACHI, C.Customising knowledge search in collaborativenetworked organisations through context-basedquery expansion. Production Planning and Control. V.21, 2010.

TU, Z.; ZACHAREWICZ, G.; CHEN, D. A federatedapproach to develop enterprise interoperability. JIntell Manuf, DOI 10.1007/s10845-013-0868-1. 2014.

WANG, X.; WONG, T. N.; WANG G. Service-orientedarchitecture for ontologies supporting multi-agent

106

system negotiations in virtual enterprise. J IntellManuf, DOI 10.1007/s10845-010-0469-1. 2010.

WAZLAWICK, R. S. Uma Reflexão sobre a Pesquisaem Ciência da Computação à Luz da Classificaçãodas Ciências e do Método Científico. Revista deSistemas de Informação da FSMA. n.6, 2010.

WSO2. WSO2 Enterprise Service BusDocumentation: About WSO2 ESB. Disponível em<https://docs.wso2.org/display/ESB481/WSO2+Enterprise+Service+Bus+Documentation>. Último acesso em 15-Dez-2014.

YASSA, M. M.; HASSAN, H. A.; OMARA, F. A. UtilizingCommonKADS as Problem-Solving and Decision-Making for Supporting Dynamic Virtual OrganizationCreation. IAES International Journal of ArtificialIntelligence (IJ-AI). Vol. 3, No. 1, 2014.

107

APÊNDICE A – ONTOLOGIA

(…)

(…)

(…)

108

APÊNDICE B – PARÂMETROS SINÔNIMOS

109

APÊNDICE C – PARÂMETROS SINÔNIMOS

110

APÊNDICE D – PARÂMETROS SINÔNIMOS

Documents

WILCILENE MARIA KOWAL SCHRATZENSTALLER … · 1 wilcilene maria kowal schratzenstaller integraÇÃo semÂntica via enterprise service bus em ambientes de criaÇÃo de organizaÇÕes