Fita crepe: existe problema que você não seja solução?

solução universitária.

Wolverine: uma boa adaptação.

É isso mesmo. Gostei de Wolverine. A opinião geral é que o filme é confuso, cheio de cenas que nada acrescentam e com personagens mal desenvolvidos. Tais "qualidades" são encontradas facilmente em boa parte das histórias em quadrinhos do personagem. Então, uma boa adaptação, conseguiu adaptar a confusão que Marvel sempre fez com o personagem, imitando até mesmo as intervenções editorias (o filme que teve refilmagens poucos meses antes do lançamento).

Nos quadrinhos, durante um bom tempo, não sabíamos a origem do Wolverine. Lembro até de uma edição da editora abril (acho que era Wolverine 28) que mostrava a infância de Wolverine no Canadá como um índio. Também sabíamos que as garras eram de adamantium, nada havia sido mostrado sobre um passado com garras de osso. Depois que Magneto arrancou o adamantium de Logan pelos poros da pele, deram um jeito de surgir com as garras de osso, pois o personagem não podia perder o seu principal appeal. Adeus a continuidade com Arma X, uma de suas melhores histórias. Inventaram então uma minissérie para criar um Wolverine com garras de osso, o que acabou na tela em poucos minutos de projeção. Veja só, é confuso mesmo. A Marvel não teve colhões para criar uma origem simples para um personagem que era bom por ser simples, qualquer escritor que assumia fazia o que quisesse. Era bom quanto tínhamos uma dupla como Claremont e Miller, mas o descontrole acabou nesse samba maluco que é a vida de Wolverine. Um filme para adaptar isso aí só podia acabar no caos mesmo. Essa explicação também serve para explicar porque Batman teve esses dois ótimos últimos filmes. A DC, apesar de vender menos, é bem mais organizada na manutenção de sua continuidade. A famosa Crise das Infinitas Terras ocorreu justamente para manter um controle sobre o universo dos personagens, enquanto a Marvel faz crossovers para vender revista. Um personagem mais organizado e estruturado nos quadrinhos facilita na hora de querer fazer um filme com as mesmas qualidades.

Talvez o principal problema, já evidente em X-Men 3 e exacerbado em Watchmen, é o vômito de fatos. Muita coisa em pouco tempo, péssimos ganchos, sensação de artificialidade. Quem já acompanhou alguma série mensal da Marvel sabe o que é isso. A maioria não está acostumada, daí as críticas negativas. Pelo menos as ótimas cenas de ação estão redendo uma boa bilheteria. E a surpresa no final garante que eles pretendem adaptar um arco de histórias mais integrado, Wolverine no Japão, apanhando dos samurais com espadas de pau. Não há mais necessidade de introduzir o personagem, já fizeram isso duas vezes. Talvez daqui a dois anos seja a vez de ver um Wolverine um pouco menos confuso. Infelizmente que é fã sabe que um filme do Wolverine com classificação menor do que 17 anos não tem como ser perfeito!!!!

Belezas do Interior

Meio atrasado, abaixo algumas fotos da viagem pelo Cariri. Um região muito bonita que o tempo chuvoso só tornou mais verde e bela.



As fotos foram tiradas em Santana do Cariri. A primeira mostra o momento exato em que a chuva vem da esquerda, expulsando o sol na direita. Algo cotidiano nesses dias chuvosos, mas capturado tão mais perto, ganha outra magnitude.



Agora na segunda, o mesmo momento, com a cidade em foco.



Essa terceira mostra como a nuvem carregada chega a tocar o solo. Um lugar fora de série, muito simples e bonito, com bastante natureza intocada. Europa, EUA, etc. Com certeza ótimos lugares para se conhecer. Agora é interessante descobrir também as belezas que estão bem ali, pertinho, no nosso próprio estado.

Situação do Trânsito

http://diariodonordeste.globo.com/materia.asp?codigo=621197

acho que essa já é a segunda reportagem que o diário está fazendo sobre o nosso caos de todo dia. Quem conhece a avenida Dr. Thembergue (é assim?), que liga a leste-oeste a bezerra de menezes, sabe que o verdadeiro caos está bem longe da aldeota. Entre as medidas sugeridas pelo ministério público, duas não foram consideradas: rodízio e ajuda dos PM's na fiscalização. Justamente as duas que considero com mais efeito. Afinal, se você vai ter que se explicar com um truculento PM, acho que se pensa duas vezes antes de comentar uma infração. E o rodízio, se São Paulo faz, porque nós temos que temer o prejuízo econômico? Agora uma que está faltando até mesmo em nível federal é alguma legislação contra carro velho. Já vi caminhão andando por aí que com certeza tem mais idade do que eu. Vai tirar o sustento de alguém? Com certeza, mas será que uma redução de impostos para a troca de veículos não aliviaria a situação? Enquanto essas três medidas não forem consideradas, o trânsito de fortaleza vai continuar uma merda, com políticos medrosos sem força para implantar medidas impopulares, mas necessárias.

O Vaticano comemora o dia Internacional da Mulher

http://www1.folha.uol.com.br/folha/mundo/ult94u531557.shtml

Depois do bispo maluco de recife, temos que agüentar mais essa. Com certeza, esses padres idosos só falam tais absurdos porque não precisam se explicar para as digníssimas em casa. Por essas e outras é que igrejas evangélicas estão quase do mesmo nível que Pague Menos aqui em Fortaleza, toda esquina tem uma. Reduzir a mulher a um reles eletrodoméstico de carne? Não tem um pingo de sentido nos dias de hoje.....

Poder com estilo

Vou começar a fazer posts mais informais. Vejam a seguinte fonte da nossa querida prefeita se reunindo com o mais querido governador. Assunto? Provavelmente a Copa de 2014. Não sei como a prefeita se reúne na maior paz com o governador cujo primo foi responsável pelo golpe da Assembléia. Mas esqueçam o parte chata, observem os notebooks. Todos do governo são Apple, inclusive um air nas mãos daquele senhor no canto, sejam quem for. E nossa prefeita de LG. Realmente, esse governo é um estilo só.

Description: Semantic Annotation for Web Services

Autores: Holger Hausen, Rubén Lara, Axel Polleres, Jos de Brujin e Dumitru Roman
Publicado em: Semantic Web Services – Concepts, Technologies and Applications – Ed. Rudi Studer, Stephan Grimm and Andreas Abecker - Springer-Verlag Berlin Heidelberg 2007

Tecnologias de Web Services são um conjunto de padrões que formam um encapsulamento sobre componentes de software pré-existentes. A Web Services Description Language (WSDL) fornece meios de descrever operações que podem ser invocadas com suas saídas e entradas, seus nomes e seus pontos de ligação. Essas informações são suficientes para abstrair questões relativas ao sistema operacional e a linguagem de implementação utilizados em um componente específico. Porém, com essa tecnologia é possível apenas modelar a funcionalidade de um componente atribuindo a sua operação um identificador e aos seus dados um tipo definido por um schema XML. O modo de descrição atual de web services podem ajudar um desenvolvedor humano na utilização do serviço, mas para computadores a interpretação é limitada. Aspectos semânticos adicionais precisam ser modelados para permitir uma automação maior no uso de web services.

As principais tecnologias propostas para descrição semântica de web services são:

• Web Service Modeling Ontology (WSMO): uma iniciativa que busca criar uma ontologia para descrever vários aspectos relacionados a web services semânticos, com foco no problema de integração.

• OWL-S: busca permitir a automatização da descoberta, invocação, composição, inter-operação e monitoramento da execução de web services fornecendo descrições semânticas apropriadas de serviços.

• Semantic Web Services Framework (SWSF): um projeto recente que une aspectos da OWL-S e da Process Specification Language (PSL).

• WSDL-S: uma proposta minimalista que adiciona descrições semânticas em interfaces WSDL tradicionais.

Das propostas acima, WSMO e OWL-S são as mais maduras, ambas possuindo implementações reais de qualidade.

A WSMO descreve todos os aspectos relevantes relacionados a serviços gerais que são acessíveis através de uma interface web service com o objetivo principal de permitir a automatização (parcial ou total) das tarefas envolvidas (descoberta, invocação, composição, inter-operação e monitoramento da execução) nos escopos intra-institucionais e inter-institucionais da integração de web services. Possui quatro elementos principais: ontologias, serviços, objetivos e mediadores. Para definir a WSMO, foi utilizada a especificação Meta Object Facility (MOF), que define uma linguagem e framework abstratos para construção e gerência de meta-modelos neutro em relação a tecnologia de implementação. Existem quatro camadas arquiteturais na MOF: informação, modelo, meta-modelo e meta-meta-modelo. A WSMO corresponde a uma camada meta-modelo, enquanto todos os seus elementos constituintes são parte da camada de modelo e os dados atuais das instâncias são da camada de informação. Na definição do WSMO, foi assumido que cada atributo tem sua multiplicidade configurada para aceitar vários valores por padrão. Também foi considerado que alguns elementos da WSMO recebem atributos originados da união de vários tipos. O artefato de meta-modelagem MOF mais utilizado na definição de WSMO é o artefato Class (e por conseguinte, SubClass), em conjunto com seus atributos, os tipos dos atributos e sua multiplicidade.

Uma ontologia é uma especificação formal e explícita de uma conceitualização compartilhada. Apesar de existirem vários esforços de padronização para linguagens de ontologia, nenhuma delas tem a expressividade e propriedades computacionais desejadas para descrever web services em um nível de granularidade suficiente. O elemento WSMO designado por ontologia pode ter propriedades não-funcionais, outras ontologias importadas, mediadores, conceitos, relações, funções, instâncias e axiomas. Propriedades não-funcionais são utilizadas para descrever aspectos tais como autor, data de criação, linguagem de descrição, etc. Ontologias importadas permitem uma abordagem modular para o projeto de ontologias e podem ser empregadas sempre que não houver conflitos entre as fontes importadas. Quando existem conflitos, o uso de mediadores se torna necessário. Conceitos constituem os elementos básicos de uma terminologia acordada para algum domínio de problema. De uma perspectiva de alto nível, um conceito – descrito por uma definição de conceito – fornece atributos com nomes e tipos. Relações são utilizadas para modelar interdependências entre vários conceitos. Funções são relações especiais, com uma amplitude unária e um domínio n-ário, onde a amplitude especifica um valor de retorno. Instâncias são definidas explicitamente ou com uma ligação a uma base de dados. Axiomas são considerados expressões lógicas unidas com seus valores não-funcionais.

O elemento serviço da WSMO fornece um modelo conceitual para descrição em uma maneira explícita e unificada todos os aspectos para um serviço, incluindo suas propriedades não-funcionais, funcionalidade e interfaces. A palavra serviço é usada como a provisão de valor em algum domínio, como uma entidade de software capaz de recuperar algo de valor em meios de interação online com um provedor de serviços. WSMO permite uma visão unificada de um serviço; o valor que o serviço pode fornecer é capturado por sua capacidade e os meios de interação com o provedor de serviço para a execução do serviço, ou para negociação, são capturados pelas interfaces. Podemos então considerar que os principais elementos da descrição de um serviço são sua capacidade e o conjunto de interfaces onde estão descritas as coregrafias e orquestrações. A coreografia descreve como o serviço atinge sua capacidade através da interação com seu cliente; a orquestração especifica como o serviço atinge sua capacidade fazendo uso de outros serviços. O definição do elemento serviço ainda contém ontologias importadas, propriedades não-funcionais e mediadores que resolvem conflitos entre ontologias e serviços coordenados.

A funcionalidade fornecida por um dado serviço é descrita por sua capacidade; sendo expressa pelo estado do mundo antes da execução do serviço e o estado do mundo após a execução com sucesso do serviço. A capacidade como elemento possui os atributos comuns como propriedades não-funcionais, ontologias importadas e mediadores. Além desses, em especial existem as pré-condições, fatos assumidos, pós-condições e efeitos. Pré-condições especificam o estado necessário do espaço de informações antes da execução do serviço. Fatos assumidos descrevem o estado do mundo que é assumido antes da execução do serviço, mas ao contrário das pré-condições, fatos assumidos não são necessariamente checados pelo ambiente de execução. Pós-condições descrevem o estado do espaço de informação que é garantido ser atingido após a execução com sucesso do serviço. Efeitos descrevem o estado do mundo que é garantido ser atingido após execução de sucesso do serviço, sendo que novamente o serviço não fica encarregado de verificar.

Uma interface descreve como a funcionalidade de um serviço pode ser completada ao prover uma visão dual na competência operacional do serviço: coregrafia decompõe a capacidade em termos de interação com o serviço; orquestração decompõe a capacidade em termos de funcionalidade requiridas por outros serviços. A coregrafia define como se comunicar com o serviço para consumir sua funcionalidade. A orquestração define como a funcionalidade global é atingida pela cooperação de provedores de serviços mais elementares.

Objetivos são representações de metas que são atingidas através da execução do web service, eles podem ser descrições de serviços que potencialmente satisfazem as necessidades do usuário. Objetivos devem ser resolvidos pela seleção de serviços disponíveis que descrevem a provisão de serviço que satisfazem o objetivo. A descrição de objetivos possuem propriedades não-funcionais, ontologias importadas, mediadores, capacidades requisitadas e interfaces requisitadas. As capacidades requisitadas descrevem a capacidade que o usuário espera do serviço.

Mediadores lidam com a heterogeneidade, resolvendo possíveis incongruências entre recursos que devem ser inter-operáveis. Heterogeneidade geralmente surge em ambientes distribuídos. A abordagem adotada para mediação se baseia na descrição declarativa de recursos onde mecanismos para resolução de incongruências trabalham no nível semântico estrutura, permitindo a criação de meios de mediação genéricos e independentes de domínio. Existem quatro tipos de mediadores na WSMO. Mediadores OO resolvem incongruências entre ontologias e fornecem conhecimento do domínio mediado para o componente alvo. Um mediador GG liga objetivos, permitindo a criação de um novo objetivo a partir de objetivos pré-existentes, definindo assim ontologias de objetivos. Um mediador WG liga um web service a um objetivo, resolvendo incongruências terminológicas e declarando diferenças funcionais entre ambos. Um mediador WW é usado para estabelecer interoperabilidade entre web services que não são inter-operáveis a priori.

Um framework para descrição da semântica de web services precisa de uma base sólida em algum formalismo lógico. A Web Service Modeling Language (WSML) fornece uma especificação de uma família de linguagens para formalização de ontologias e web services, baseada no modelo conceitual WSMO. Existem cinco diferentes variantes na WSML. WSML-Core é baseada em lógica descritiva e a lógica de Horn, sendo a menos expressiva. WSML-DL é semelhante a OWL-DL. WSML-Flight é uma extensão de WSML-Core que adiciona uma linguagem de regras. WSML-Rule é uma extensão mais completa de WSML-Flight. WSML-Full é a mais completa, adicionando todas as características das lógicas de primeira ordem. Existem sua alternativas de criação de camadas, WSML-Core → WSML-DL → WSML-Full e WSML-Core → WSML-Flight → WSML-Rule → WSML-Full. Ambas alternativas existem para suportar exigências de sistemas mais orientados a lógica descritiva ou aqueles mais adequados a sistemas de regras.

OWL-S define uma ontologia superior para serviços composta por quatro elementos principais:

• Serviço: esse conceito serve como um ponto de referência para a declaração de web services; cada serviço é declarado criando uma instância de um conceito serviço.

• Perfil de Serviço: o perfil descreve o que o serviço faz em alto nível, descrevendo sua funcionalidade e outras propriedades não funcionais que são usadas para localizar serviços baseado na suas descrições semânticas.

• Modelo de Serviço: o modelo de um serviço descreve como ele atinge sua funcionalidade, incluindo a descrição detalhada dos seus processos constituintes.

• Ligação de Serviço: a ligação descreve como usar o serviço, isto é, como um cliente pode invocar o serviço.

O conceito serviço conecta o perfil, o modelo e a ligação de um dado serviço através das propriedades presents, descbribedBy e supports, respectivamente. WSMO explicitamente desconecta o ponto de vista do provedor e o ponto de vista do cliente; objetivos são definidos independentemente dos web services e são ligados através de mediadores WG.

Em OWL-S, o modelo de serviço representa como serviços funcionam, isto é, como inter-operar com o serviço. O serviço é visto como um processo e a classe ProcessModel é a raiz da definição. O modelo de processo descreve as propriedades funcionais do serviço, juntamente com detalhes dos seus processos constituintes (se o serviço for composto), descrevendo como interagir como o serviço. A descrição de funcionalidade é dividida em transformação de informação e mudança de estado, sendo expressa em termos de IOPE (input, output, preconditions, effects). A descrição de funcionalidade está em parte definida no perfil do serviço e o restante no modelo. Na WSMO, essa descrição se concentra apenas na capacidade do web service. Existem processos atômicos, simples e compostos. Os atômicos podem ser invocados, não possuem subprocessos e são executados em um único passo no ponto de vista do cliente. Processos simples não são invocáveis e são vistos como também executados em um único passo. Processos compostos são criados a partir da organização de outros processos, são utilizados estruturas de controle para definir seqüências de invocação e também controlar o fluxo de dados entre os serviços constituintes. Uma importante diferença entre OWL-S e WSMO é que a primeira apenas define o comportamento externamente visível dos web services, enquanto WSMO também modela como o serviço faz uso de outros serviços para fornecer sua funcionalidade.

O perfil do serviço descreve o propósito do serviço, tanto descrevendo o serviço fornecido pelo provedor e o serviço desejado pelo cliente. O perfil de um web service pode ser inserido em uma hierarquia, sendo essa classificação opcional. Serviços OWL-S podem ser posicionados em uma hierarquia pré-definida, enquanto serviços WSMO podem ser ligados a um objetivo usando um mediador WG. As propriedades não-funcionais são informadas no perfil. Na WSMO, qualquer um dos elementos principais podem ter propriedades não-funcionais, enquanto na OWL-S esse tipo de informação está apenas no perfil. A informação sobre funcionalidade presente no perfil também é dividida em transformação de informação e mudança de estado em conseqüência. O primeiro tipo é estudado ao se definir as entradas e saídas de um serviço, enquanto o segundo tipo é definido em termos de pré-condições e efeitos. Entradas e saídas em OWL-S descrevem que informações são requisitadas e qual informação é produzida pelo serviço. Entradas e saídas são modeladas como subclasses de um parâmetro, que por sua vez é um subclasse de uma variável SWRL com uma propriedade indicando a classe ou tipo de dados onde se encaixam os valores do parâmetro. Pré-condições são condições no estado do mundo que precisa ser verdadeiro para a execução com sucesso do serviço. Efeitos descrevem condições no estado do mundo que são verdadeiros após a execução do serviço. Eles são modelados como parte de um resultado. Um resultado tem inCondition, ResultBar, OutputBinding e Effect. O resultado é declarado no processo do serviço, sendo parte de um processo atômico. A mudança de estado é descrita em WSMO utilizando fatos assumidos e efeitos. O objetivo apenas define efeitos como o estado do mundo que é desejado. A relação entre entrada e saída, pré-condições e efeitos de um web service precisa ser capturada para descrever com precisão a funcionalidade.

A ligação em OWL-S fornece os detalhes de como acessar o serviço, mapeando de uma especificação de serviço abstrata para uma concreta. Essas ligações são associadas com processos atômicos definidos no modelo de serviço, apesar dessa associação não ser descrita no modelo apenas na ligação.

Pode-se afirmar que a linguagem OWL em conjunto com o vocabulário OWL-S formam a linguagem de especificação de web services OWL-S. Entretanto, é fato que OWL sozinha não é suficiente para a especificação do comportamento de web services. O maior problema é que OWL não permite encadear variáveis sobre predicados, o que torna impossível especificar o relacionamento entre a entrada e a saída, o que é necessário para descrever formalmente o comportamento de qualquer componente de software. Assim, OWL-S permite que o usuário escolha uma linguagem diferente para a especificação das pré-condições e efeitos. Entre as opções, estão SWRL, KIF e DRS.

Comentários:

O importante a ser levado desse capítulo é a relevância da utilização dos conceitos de entrada, saída, pré-condições e efeitos na descrição semânticas de web services. É uma idéia até intuitiva, sendo que as duas abordagens são bem semelhantes nesse quesito. WSMO pareceu mais completa e estrutura, mas talvez pela forma que foram apresentadas, acho que OWL-S aparenta ser mais fácil de utilizar. A sintaxe XML fez me sentir em casa, com muitas familiaridades. O fato de OWL-S ser definida pela mesma comunidade da DAML-OIL também ajuda. Os mediadores propostos pela WSMO é que são seu verdadeiro trunfo, pois combinam muito bem com o requisito de baixo acoplamento, levando a um modelo bem mais orientado a serviços. Fica para depois a decisão de qual usarei, se for usar um.

Goals and Vision: Combining Web Services with Semantic Web Technology

Autor: Chris Preist
Publicado em: Semantic Web Services – Concepts, Technologies and Applications – Ed. Rudi Studer, Stephan Grimm and Andreas Abecker - Springer-Verlag Berlin Heidelberg 2007

As tecnologias de web semântica trabalham em direção à uma web que seja interpretável por máquinas. Web Services, por outro lado, estão trabalhando em direção a um ambiente onde organizações podem fazer algumas de suas atividades acessíveis pela Internet. Os web services semânticos combinam essas duas tecnologias para possibilitar interação automática e dinâmica entre sistemas de software. É um meio de descrever serviços, possuindo habilidades em sua infra-estrutura para a descoberta dos serviços possibilitando a inter-operação. Entretanto, não é fornecido o raciocínio para decidir qual serviço é o procurado, qual fornecedor é o melhor, como negociar os parâmetros de um serviço e quais ações devem tomar quando um serviço é selecionado. Só é possível total automatização dessas tarefas com o uso de outras disciplinas da ciência da computação.

Formalmente, podemos definir serviço como o desempenho de algumas ações por uma entidade para fornecer algum valor ou ganho para outra entidade. O contexto de atuação do serviço determina o domínio de valor do serviço. A entidade que executa o serviço é denominada provedor enquanto a que recebe o benefício é chamada de consumidor. Um serviço concreto é um desempenho específico de ações em um intervalo de tempo determinado. Um serviço abstrato corresponde para algum conjunto ou classe de serviços concretos e nos permite discutir serviços hipotéticos sem precisão sobre todos os aspectos de implementação.

Um objetivo dos web services semânticos é fornecer uma representação processável por máquinas do serviço, em termos dos valores que ele possibilita. Isso é chamado de descrição do serviço. Algumas questões são levantadas para atingir tal objetivo. Primeiro, que linguagem formal será usada para descrever serviços? Segundo, que conceitos específicos e relações serão permitidas nas descrições e quais serão seus significados? É importante que os termos da ontologia permitam a especificação das ações do serviço, incluindo seus resultados, na terminologia do domínio de valor do serviço. Componentes de software que representam entidades são conhecidos como agentes, com um agente provedor representando um provedor de serviços e um agente consumidor representando um consumidor de serviços. Eles são chamados de agente em um sentido bem preciso, pois agem como representantes online de alguma entidade. É fácil confundir com agentes inteligentes, mas nesse contexto o termo agente englobam os inteligentes e qualquer outra representação em software de entidades.

O protocolo de comunicação entre entidades diferentes é geralmente chamado de coreografia. Uma coreografia determina restrições na ordenação das mensagens trocadas entre o provedor do serviço e o consumidor do serviço .Temos que quando a troca de mensagens ocorre de acordo com restrições de alguma coreografia, podemos concluir que se trata de uma conversação entre entidades que satisfaz a coreografia. Um dos objetivos dos web services semânticos é descrever diferentes coreografias que entidades podem utilizar para interagir em um formato processável por máquinas.

Uma orquestração é uma especificação interna ao agente que determina qual mensagem deve ser enviada em determinado momento, não necessariamente destinada a mesma entidade da mensagem anterior. Assim, a coreografia especifica o que é permitido às entidades, enquanto a orquestração especifica o que cada entidade irá de fato realizar. O ato de combinar e coordenar um conjunto de serviços é conhecido por composição de serviços. Quando um agente cliente está interagindo simultaneamente com vários provedores de serviços, uma orquestração pode especificar a seqüencia de mensagens com todos eles, incluindo dependências apropriadas. Há duas maneiras de especificar a orquestração. A mais direta, e menos flexível, é tomar decisões em tempo de projeto sobre quais provedores serão utilizados, codificando a lógica de integração no agente cliente. Uma maneira mais flexível é utilizar uma linguagem de workflow declarativa para descrever o processo de integrar as interações com os provedores escolhidos. Ter uma descrição explícita da orquestração de serviços em termos de alguma linguagem de processos tem uma vantagem extra. Significa que a orquestração pode existir independente do agente cliente, sendo transportada entre agentes como uma estrutura de dados. Não só o agente cliente pode ser capaz de gerar uma orquestração, qualquer entidade pode produzir uma, mostrando como vários serviços podem ser combinados para produzir um serviço mais complexo.

Em uma interação entre duas entidades, pode ser necessário alguma mediação. Há quatro tipos de mediação disponíveis: dados, ontologia, protocolo e processo. A mediação de dados consiste em transformações sintáticas entre os dados trocados pelo provedor e cliente. A mediação de ontologia consiste na resolução de ambigüidades e termos diferentes com o mesmo valor semântico, lembrando em parte o problema de merging. A mediação de protocolo consiste na mediação de coreografias, traduzindo as seqüências de mensagens das entidades até que estejam sincronizadas e de acordo com o objetivo. A mediação de processo é a mais complexa, pois consiste de mediar os interesses das entidades e dos processos internos. Seja qual for o tipo de mediação, ela será fortemente ligada ao grau de anotação semântica das mensagens e coreografias. Quanto maior a qualidade da anotação, maior a possibilidade de automatização das mediações.

O ciclo de vida do relacionamento entre o cliente e o provedor atravessa quatro fases: modelagem, descoberta, definição e entrega. Na fase de modelagem, tanto o cliente cria uma definição abstrata do serviço procurado como o provedor também estabelece uma definição abstrata dos serviços que oferece. Na fase de descoberta, se a descrição abstrata do cliente e a descrição do provedor são compatíveis de alguma forma, então ambas entidades podem prosseguir para a fase de definição do serviço. A fase de definição envolve capturar uma descrição abstrata do serviço de um provedor e refiná-la até que ela descreva um serviço específico que cumpre as necessidades do cliente. A entrega do serviço pode ocorrer de várias formas, correspondendo a realização de fato do serviço. Vários tipos de interações podem ocorrer nessa última fase, sendo que várias coreografias estão associadas. Uma coreografia de entrega de serviço cobre a troca de mensagens associada diretamente com a entrega do serviço, sendo muitas vezes o serviço sendo fornecido pela própria troca de mensagens. Uma coreografia de monitoramento cobre a troca de mensagens que permitem ao cliente receber informações do provedor sobre o progresso do serviço. Uma coregrafia de cancelamento/renegociação permite ao cliente cancelar ou alterar o serviço que está recebendo do provedor.

Uma micro-arquitetura é a arquitetura interna baseada em componentes de um entidade individual dentro de uma comunidade. Uma macro-arquitetura é a estrutura da comunidade, considerando cada entidade interna como uma caixa preta. Na macro-arquitetura, uma entidade de software pode desempenhar três papéis: agente cliente, agente provedor e agende provedor de descoberta. O agente cliente possui um modelo, em uma ontologia, do domínio do serviço e também tem um modelo do tipo de ações que podem ser tomadas (através de troca de mensagens) nesse domínio. O agente provedor fornece uma descrição dos serviços que hospeda em uma ontologia de domínio, também possuindo meios de gerar descrições mais concretas dos serviços precisos que ele pode entregar. O agente provedor de descoberta tem acesso as descrições dos serviços ofertados, juntamente com referências a agentes provedores capazes de fornecer tais serviços.

As interações na macro-arquitetura seguem a orientação do ciclo de vida.

1. Agente do provedor registra uma nova descrição de oferta de serviço: o agente provedor envia uma mensagem para o agente provedor de descoberta contendo uma oferta de serviço descrita na ontologia do agente de descoberta.

2. Agente do cliente descobre possíveis provedores: o agente cliente envia uma mensagem ao agente provedor de descoberta contendo uma descrição dos serviços procurados na ontologia do agente de descoberta.

3. O cliente e o provedor definem o serviço.

4. O serviço é entregado.

Devido a grande variedade de coregrafias possíveis durante a entrega, nesse estágio a mediação terá o papel mais importante. Para o propósito da arquitetura descrita, todo protocolo de coregrafia aplicado terá lugar no agente cliente.

A micro-arquitetura de cada agente não precisa seguir uma arquitetura padrão em toda a comunidade. No núcleo do agente cliente, temos a lógica da aplicação responsável pela tomada de decisão relacionada a qual serviço selecionar e como utilizá-lo. Seu primeiro papel é definir a descrição de requisitos do serviço que precisa. O componente de definição e descoberta é responsável por gerenciar a descoberta e coregrafias definidas dos serviços. O componente de abstração da mensagem realizar mediação de dados. Quando recebe uma mensagem, traduz seu conteúdo em informação semântica de acordo com uma ontologia e o armazena na base de conhecimento. Também acessa a mesma base para gerar mensagens de saída de acordo com a ontologia. O componente de entrega fica responsável pela mediação de protocolo, lidando com as coregrafias de acordo com instruções da lógica de aplicação. No agente provedor, como já foi definido que ele não tratará mediação, podemos ter uma estrutura mais simples. Não temos a abstração de mensagens e nem a base de conhecimento, sendo que por não lidar com mediações, seus componentes podem ser bem mais restritos.

Comentários:

Um pouco vago, porém o final valeu a pena pela definição da arquitetura. Com certeza, os conceitos levantados nesse capítulo serão importantes nos posteriores.