Transformação de Serviços Sensíveis ao Contexto para ... · contexto físico e computacional de...

Transformação de Serviços Sensíveis ao Contexto para

Serviços Web Usando o Padrão MOF QVT

Cléver Ricardo Guareis de Farias

Departamento de Física e Matemática – Faculdade de Filosofia Ciências e Letras de

Ribeirão Preto (FFCLRP) – Universidade de São Paulo (USP)

Av. Bandeirantes, 3900

CEP 14040-901 − Ribeirão Preto (SP)

[email protected]

Abstract� Model driven engineering is increasingly attracting interest in the

research community, due to its applicability in different application domains.

This paper discusses how MDA technology (metamodelling and the QVT

standard) can support the transformation of high-level models of context-

aware services onto the implementation of these services using web services.

Resumo� O desenvolvimento baseado em modelos tem se apresentado como

uma abordagem promissora para o desenvolvimento de sistemas em diferentes

domínios de aplicação. Neste sentido, este artigo discute a transformação de

modelos de aplicações móveis sensíveis ao contexto independentes de

plataforma em modelos de serviços web usando o padrão MOF QVT.

1. Introdução

Aplicações sensíveis ao contexto caracterizam-se pelo uso de informações sobre o

contexto físico e computacional de seus usuários nas tomadas de decisões, de modo a

produzir serviços mais flexíveis, adaptáveis, ricos em funcionalidade e centrados no

usuário. Neste sentido, as aplicações sensíveis ao contexto são programadas para reagir

e explorar as mudanças de contexto dentro de um domínio dinâmico.

O desenvolvimento dessas aplicações implica a superação de vários desafios teóricos e

tecnológicos, e requer a existência de uma infra-estrutura de suporte adequada ao seu

projeto e execução, particularmente para apoio à manipulação de modelos de contextos

diversos, provenientes de ambientes altamente distribuídos, heterogêneos e em

constantes mudanças. Nesse sentido, tem-se presenciado um grande esforço e o

surgimento de várias pesquisas relacionadas à construção de plataformas de serviços

com suporte à execução dessas aplicações [Dockhorn Costa et al. 2005].

Com o intuito de acelerar o desenvolvimento de aplicações sensíveis ao contexto,

devemos prover um suporte adequado à transformação de modelos de contexto e o

conjunto de serviços que fazem uso destes modelos. De forma específica, queremos

prover suporte à transformação de modelos de serviços móveis sensíveis ao contexto na

implementação destes serviços através de serviços web, usando a abordagem Model-

Driven Architecture (MDA) [OMG 2003].

Third Workshop on Ontologies and Metamodeling in Software and Data Engineering - WOMSDE 2008

119

Atualmente, o ciclo de vida de um sistema informatizado ainda é profundamente

condicionado ao ciclo de vida da plataforma tecnológica que o sustenta. A proposta da

MDA de promover um aumento do grau de abstração usado na especificação e no

desenvolvimento de um sistema está diretamente associada à busca de maior

independência quanto à plataforma tecnológica utilizada, com efeitos positivos sobre a

longevidade da aplicação.

A efetivação do conceito de independência de plataforma impõe mudanças no processo

de software: faz-se necessário o uso de metamodelos que suportem a definição dos

modelos independentes de plataforma (PIMs), bem como de metamodelos que

propiciem a representação de conceitos próprios às plataformas tecnológicas escolhidas

(PSMs). A elaboração de um PIM denota a ênfase sobre o domínio do problema,

enquanto que a obtenção de um PSM pode ser visto como o resultado de um processo

de transformação aplicável ao PIM.

No contexto de MDA, a transformação de modelos toma proporções mais significativas.

A transformação de modelos sustenta a premissa de níveis de abstração e contribui para

as expectativas de aumento de produtividade e de qualidade na produção de software

[Patrascoiu 2004]. A transformação de modelos é, portanto, recurso primordial para

viabilizar a abordagem de MDA [Sendall and Kozaczynski 2003].

Neste sentido, este trabalho investiga o uso de metamodelos e o padrão

Query/View/Transformation (QVT) [OMG 2005a] para realizar a transformação de

modelos de serviços móveis sensíveis ao contexto em modelos de serviços web. O

restante do artigo está organizado da seguinte forma: a seção 2 discute alguns aspectos

relacionados à transformação de modelos em MDA; a seção 3 apresenta uma visão geral

do metamodelo de serviços sensíveis ao contexto (PIM); a seção 4 apresenta uma visão

geral do metamodelo de serviços web (PSM); a seção 5 discute a transformação destes

modelos usando o padrão QVT; finalmente, a seção 6 apresenta algumas considerações

finais e perspectivas de trabalhos futuros.

2. Transformação de modelos em MDA

Uma transformação de modelos pode ser concebida como um conjunto de regras,

condições e ações que se aplicam a um modelo origem com o objetivo de produzir um

modelo destino. Em MDA, os modelos podem corresponder ao mesmo ou a distintos

níveis de abstração MOF, e o sentido da transformação pode variar [OMG 2001], como,

por exemplo, PIM � PSM, PIM� PIM, PSM� PIM e PSM� código.

A especificação MDA indica alguns caminhos válidos para o esforço de transformação,

que vão desde a definição e aplicação manual das regras de mapeamento, até a

construção de algoritmos que utilizem modelos de transformação, sejam parametrizados

e utilizem patterns para orientar sobre a definição do elemento de modelagem resultante

[OMG 2001].

Miller e Mukerji [OMG 2003] apresentam uma série de considerações acerca do

processo de transformação em MDA, com grande ênfase nos marcadores (marks) para

direcionar a transformação. Os marcadores têm por finalidade indicar características

relevantes e úteis para orientar a transformação de uma dada estrutura do modelo origem

em estruturas do modelo destino. Os marcadores podem ter diferentes origens:


120

estereótipos, quando do uso de um Perfil UML, tipos, quando em uso num modelo

genérico, elementos de modelagem, quando no contexto de um metamodelo, etc. Para

Miller e Mukerji, uma transformação tem como argumentos o PIM marcado e as

definições de mapeamento, e necessariamente deve registrar todos os seus passos,

através de um mapa de equivalências, com informe dos elementos utilizados.

Em [OMG 2003] são propostas duas categorias básicas como modalidades de

transformação: aquelas baseadas em modelos e aquelas baseadas em metamodelos.

Modalidades de transformação baseadas em modelos subtendem a utilização do mesmo

metamodelo para a especificação dos modelos de origem e de destino, havendo

identificação dos elementos de modelagem suportados especificamente para cada um

dos modelos. Assim, distinguem-se os elementos de modelagem independentes de

plataforma, daqueles que são dependentes de uma plataforma tecnológica específica. A

especificação da transformação, nesse caso, requer o mapeamento entre elementos do

mesmo metamodelo.

As modalidades de transformação baseadas em metamodelos são aplicadas quando os

modelos de origem e de destino podem ser originados de metamodelos distintos, caso

em que a especificação da transformação mapeia conceitos de uma linguagem a outra, e

pode se basear num terceiro metamodelo. Em ambas as modalidades, há a possibilidade

do emprego de patterns e de templates, além de informações adicionais acrescidas por

configuração ou de forma interativa ao longo do processo de transformação.

Em vista da proliferação de iniciativas de projetos para transformação de modelos, no

rastro da especificação MDA [OMG 2001], a OMG lançou uma RFP [OMG 2002],

iniciando um processo formal para o desenvolvimento de uma especificação que

padronizasse o modo como que se alcança um mapeamento entre modelos para fins de

transformação. Complementarmente, a RFP requisitava propostas de mecanismos

padronizados para a realização de ações de pesquisa e de criação de visões sobre

modelos MOF. Uma das preocupações centrais da OMG foi a definição dos esforços de

transformação sobre um metamodelo específico, aderente às especificações MOF.

A partir das propostas recebidas, consolidou-se a especificação MOF 2.0

Query/View/Transformation (QVT) [OMG 2005a]. A especificação QVT define

linguagens próprias para a especificação e o desenvolvimento de transformações entre

modelos. A especificação também prevê níveis de conformidade aos quais uma

ferramenta que dê suporte às transformações podem aderir.

A especificação QVT propõe um metamodelo, estruturado como uma extensão do MOF

Model, mais especificamente do pacote EMOF, para a definição dos modelos de

transformação. QVT possui uma natureza híbrida que contempla aspectos declarativos

com possíveis módulos imperativos em uma extensão de OCL [OMG 2005b].

3. Modelos Independentes de Plataforma

O desenvolvimento de modelos adequados à representação de domínios de aplicação

específicos é uma preocupação freqüente na engenharia de software. O uso de

metamodelos apropriados assegura precisão à sintaxe abstrata do modelo desenvolvido e

possibilita sua reutilização em distintas aplicações do mesmo domínio. Os metamodelos


121

encerram uma semântica muito particular a um domínio de aplicação, o que implica

forte especificidade na sua construção.

Para formular modelos específicos para o domínio das aplicações sensíveis ao contexto

foi definido um metamodelo de contexto usando a MOF. O uso do MOF não apenas

provê formalismo às informações de contexto, mas também possibilita explorar o amplo

suporte de ferramentas padronizadas para auxílio à confecção dos modelos e alcança

portabilidade entre diferentes ambientes de modelagem.

Os conceitos presentes no metamodelo de serviços sensíveis ao contexto (PIM) foram

identificados e agrupados em seis pacotes MOF, viz: core, services, services hierarchy,

subscription, context-services e quality. A Figura 1 ilustra a pacote services do nosso

metamodelo de contexto. Este pacote reúne os conceitos utilizados para caracterizar os

serviços envolvidos na geração, no tratamento e no uso das informações de contexto

modeladas.

cd MCW - serv ices

Message

+ name: string

Serv iceOperation

+ name: string

+ interaction: InteractionType

MessagePart

+ name: string

+ type: string

«enumeration»

InteractionType

+ one-way:

+ request-response:

Quality�tem

Service

+ name: string

Prov ider

+ name: string

+ host: string

+ port: integer

com��dbmware��

cwmetamodel��core��

CWClassifier

+ name: string

SimpleServ ice CompositeServ ice

1

façades

0..*

1..*

+component

0..*

0..*

refers to

0..1+classifier0..*+fault

1

1..*

+service provides

0..1

+output

1

0..1

+input

1

1..*+service_operation

publishes

1

0..*

{ordered}

+parthas1..*

0..*

instantiates

0..*

0..*

uses

0..*

Figura 1. Pacote Services do Metamodelo de Contexto

A metaclasse abstrata Service representa um serviço. Os serviços atuam sobre as

entidades e atributos (heranças da metaclasse abstrata core::CWClassifier) para mera

consulta (metaassociação uses) ou com a finalidade de instanciar ou modificar

informações de contexto (metaassociação instantiates). A metaclasse abstrata Service

possui um vínculo de composição com a metaclasse Provider, indicando o provedor que

oferece o citado serviço. Provider define três metaatributos pelos quais podemos

estruturar os parâmetros de conectividade: name, host e port.

Os serviços podem ser compostos por outros serviços, perfazendo uma seqüência

específica de acionamento, a partir de uma lógica própria. Para a representação do

vínculo de composição entre serviços utilizou-se de um composite pattern.


122

Um serviço pode ser simples (metaclasse SimpleService), o que implica a inexistência de

outros serviços a compor sua funcionalidade, ou composto (metaclasse

CompositeService), quando um serviço se componente de outros serviços (caracterizados

pelo role component). SimpleService e CompositeService são heranças de Service e

estabelecem vínculos de façade: todo serviço composto deve possuir um serviço simples

e único, mediante o qual se dá o acesso às funcionalidades do conjunto de um serviço

composto.

Um serviço é constituído por operações, representadas pela metaclasse ServiceOperation.

Através do atributo interaction é possível qualificar o mecanismo de interação previsto

para o serviço. Os tipos de interação possíveis estão enumerados em InteractionType.

InteractionType prevê duas formas de interação: request-response, com acionamento

explícito pelo demandante e com resposta sincronizada; e one-way, com interação

estimulada por um evento, caracterizado pela ocorrência de uma situação logicamente

descrita e que envolve os atores do contexto, como, por exemplo, o alcance de um

determinado estado por uma certa entidade no contexto modelado ou uma ocorrência

temporal.

As operações são compostas por mensagens de entrada, de saída ou de falha. As

mensagens são representadas pela metaclasse Message. As mensagens são constituídas

por partes, representadas no metamodelo através da metaclasse MessagePart.

MessagePart pode referenciar uma entidade ou atributo de contexto, heranças da

metaclasse abstrata core::CWClassifier.

Maiores informações sobre o metamodelo de serviços sensíveis ao contexto podem ser

encontradas em [Leite et al. 2006], [de Farias et al. 2007c] e [Leite 2007].

4. Modelos Específicos de Plataforma

O metamodelo específico de plataforma selecionado foi o metamodelo de Web Service

Description Language (WSDL) 1.1 [W3C 2001]. A representação do metamodelo de

WSDL também foi capturado usando MOF e foi baseada no próprio padrão e na

proposta apresentada em [Pavão Lopes 2005].

Os conceitos presentes no metamodelo WSDL foram identificados e agrupados

utilizando três pacotes MOF: WSDLCore, BindingExtension e XSD. O pacote

BindingExtension contém os conceitos associados ao protocolo SOAP [W3C 2000].

Associações do WSDL com os protocolos HTTP e MIME não foram consideradas. O

pacote XSD contém os principais conceitos associados à definição de esquemas XML.

O pacote WSDLCore contém a maior parte dos conceitos presentes no metamodelo de

WSDL, sendo o pacote mais relevante no contexto deste trabalho. A Figura 2 mostra os

conceitos presentes no pacote WSDLCore.

Este metamodelo está organizado em torno da metaclasse WSDLElement. Esta

metaclasse abstrata generaliza a maior parte dos conceitos presente em uma

especificação WSDL. WSDLElement possui um meta-atributo chamado documentation

que pode ser utilizado para representar informações legíveis para usuários humanos.


123

Figura 2. Pacote WSDLCore

A metaclasse Definition representa um documento WSDL. Um documento WSDL

basicamente funciona como um contêiner para a descrição de um service, consistindo de

um conjunto de definições de elementos WSDL, tais como tipos, mensagens, portas e

associações. Esta metaclasse possui dois meta-atributos opcionais, viz., name e

targetNameSpace, os quais podem ser utilizados para criar um espaço para a definição de

nomes, i.e., um apelido que pode ser utilizado neste documento.

A metaclasse Import representa a importação de elementos definidos de um determinado

espaço de nomes. Este elemento pode ser utilizado para incluir e agregar elementos de

uma definição de serviços descritos em um conjunto de documentos independentes. Esta

metaclasse tem dois meta-atributos, viz., namespace, o qual representa o espaço de

nomes sendo importado, e location, o qual representa a localização (Unified Resource

Identifier - URI) do espaço de nomes sendo importado.

A metaclasse Type representa uma definição de tipo de dados. Este elemento pode ser

utilizado nas definições de serviço para definir os tipos de dados utilizados nas


124

mensagens trocadas. Uma definição de tipo de dados normalmente contém zero ou mais

definições XSD, representadas pela metaclasse XSD::XSDElement.

A metaclasse Message representa uma definição abstrata dos dados trocados em uma

definição de serviço. Esta metaclasse possui um único meta-atributo chamado name, o

qual representa o identificador da mensagem. Uma mensagem consiste de zero ou mais

partes lógicas. A metaclasse Part representa um pedaço dos dados e está associado a

uma definição de tipos. Esta metaclasse tem os seguintes meta-atributos: name, que

representa o identificador da parte, e type, que é um meta-atributo derivado

representando a definição do elemento XSD associado.

A metaclasse PortType representa uma definição de porta, i.e., um conjunto de operações

abstratas implementadas por uma entidade associada ao serviço. Esta metaclasse é

similar a uma definição de interface em CORBA IDL. PortType tem um único meta-

atributo chamado name, o qual representa o identificador da metaclasse e provê um

identificador único entre todas as definições de porta no documento WSDL.

A metaclasse abstrata Operation representa uma definição abstrata de uma ação que pode

ser executada em um ponto de (acesso a um) serviço em termos de mensagens de

entrada, saída e falhas. Esta metaclasse possui um único meta-atributo chamado name, o

qual representa o identificador da metaclasse. WSDL define quarto diferentes tipos de

operações, os quais correspondem aos diferentes padrões de troca de mensagens.

A metaclasse RequestResponse representa uma operação de requisição-resposta, na qual

um ponto de serviço recebe uma mensagem de requisição e envia para o cliente

requisitante uma mensagem de resposta associada. A metaclasse SolicitResponse

representa uma operação de solicitação-resposta, na qual um ponto de serviço envia uma

mensagem de solicitação para um cliente requisitante e posteriormente recebe uma

mensagem de resposta relacionada deste cliente. Tanto a metaclasse ResquestResponse

quanto a metaclasse SolicitResponse possuem um meta-atributo opcional chamado

parameterOrder, o qual pode ser utilizado para capturar a ordem original dos parâmetros

em associações RPC. A metaclasse OneWay representa uma operação de sentido único,

na qual um ponto de serviço simplesmente recebe uma mensagem de um cliente

requisitante. Finalmente, a metaclasse Notification representa uma operação de

notificação, na qual um ponto de serviço simplesmente envia uma mensagem de

notificação para um cliente.

A metaclasse abstrata OperationElement representa os elementos de uma operação em

termos das mensagens de entrada, saída e falhas trocadas. Esta metaclasse possui um

único meta-atributo chamado name, o qual representa o parâmetro de identificação da

operação. OperationElement é especializada em três sub-metaclasses, viz., InputElement,

OutputElement e FaultElement, representando mensagens de entrada, saída e falha,

respectivamente. A metaclasse OneWay contém somente elementos de entrada. A

metaclasse Notification contém somente elementos de saída. A metaclasse

RequestResponse contém um elemento de entrada, um elemento de saída e zero ou mais

elementos de falha. A metaclasse SolicitResponse contém um elemento de saída, um

elemento de entrada e zero ou mais elementos de falha.

A metaclasse Binding representa a especificação de um protocolo concreto e de um

formato de dados para um determinado tipo de porta. Uma associação de mensagem


125

descreve como uma definição de mensagem abstrata é mapeada em um formato

concreto. Esta metaclasse tem um único meta-atributo chamado name, o qual define o

identificador da associação. A metaclasse Binding deve ser especializada através de um

conjunto de elementos de extensão de modo a especificar a gramática concreta para as

mensagens de entrada, saída e falha associadas ao conjunto de operações da porta.

A metaclasse Port representa um ponto de comunicação único obtido através da

associação de um único endereço com uma definição de associação. Esta metaclasse tem

um único meta-atributo chamado name, o qual representa o identificador da porta. A

metaclasse Port deve ser especializada através de um elemento de extensão de modo a

especificar o endereço associado à porta.

A metaclasse Service representa um conjunto de pontos de serviço relacionados. Esta

metaclasse possui um único meta-atributo chamado name, o qual representa o

identificador do serviço.

5. Mapeamento PIM-PSM

O mapeamento do metamodelo de contexto para o metamodelo de serviços web envolve

os seguintes aspectos: 1) mapeamento dos tipos de dados utilizados como entrada e

saída nas operações de serviço, os quais podem ser traduzidos para esquemas XML; e 2)

mapeamento de assinaturas de serviço, as quais podem ser traduzidas para definições de

WSDL. Para obtermos um mapeamento completo deveríamos também englobar o

mapeamento de comportamentos de serviço, os quais podem ser utilizados para gerar as

implementações de serviços web correspondentes. Contudo, o metamodelo de contexto

não considerou a especificação de comportamentos de serviço e, portanto, este aspecto

não será considerado no contexto deste trabalho.

De acordo com a especificação QVT [OMG 2005a], não há uma separação clara entre

os conceitos de mapeamento transformação. Uma transformação é definida em termos

de especificações de mapeamento, as quais podem ser especificadas utilizando-se

diferentes linguagens definidas a partir da arquitetura de metamodelos do QVT:

relacional, mapeamento operacional e core. Contudo, alguns autores fazem uma

distinção entre mapeamento e transformação (veja, e.g., [Lopes et al. 2005], [Lopes et

al. 2006]). De acordo com [Lopes et al. 2005], um mapeamento pode ser visto como a

correspondência entre os elementos de dois metamodelos, enquanto que uma

transformação pode ser definida como a atividade de transformar um modelo de origem

em um modelo destino de acordo com um conjunto de regras de transformação. A

vantagem desta abordagem reside na separação da definição do mapeamento da

especificação da transformação. Desta forma, várias definições (alternativas) de

transformação podem ser criadas para um mesmo mapeamento.

Neste trabalho adotamos a abordagem proposta em [Lopes et al. 2005], na qual o

mapeamento e a transformação são explicitamente separados. Desta forma, a

especificação da transformação dos tipos de dados foi realizada em duas etapas: 1)

definição do mapeamento de cada tipo de dado sensível a contexto para um ou mais

elementos de esquema XML utilizando a notação proposta em [Lopes et al. 2005]; e 2)

especificação da transformação propriamente dita utilizando o QVT. Dado que o foco

deste trabalho é a transformação das assinaturas de serviço, não discutiremos o

mapeamento dos tipos de dados no restante deste artigo. Maiores informações sobre o


126

mapeamento dos tipos de dados podem ser encontradas em [de Farias et al. 2007b, de

Farias 2007].

A especificação da transformação das assinaturas de serviço também foi realizada

utilizando-se a mesma abordagem da transformação dos tipos de dados, ao longo de

duas etapas: 1) definição do mapeamento de um serviço sensível a contexto para um

serviço WSDL equivalente; e 2) especificação da transformação propriamente dita

utilizando o QVT.

A definição do mapeamento de um serviço sensível a contexto para um serviço WSDL

equivalente foi realizada em duas etapas. Primeiramente, um serviço sensível ao

contexto, representado pela metaclasse SimpleService, foi mapeado para uma definição

de serviço WSDL, representado pela metaclasse Definition. Este mapeamento envolveu a

criação de elementos de definição de serviço WSDL básicos, bem como o mapeamento

das operações definidas por este serviço, suas mensagens e as partes que compõem estas

mensagens em seus equivalentes na definição WSDL. O mapeamento de um serviço

composto, representado pela metaclasse CompositeService, para um serviço equivalente

WSDL equivalente não é necessário, dado que todo serviço composto pode ser

representado por um serviço simples equivalente (metaassociação façades).

A Figura 3 ilustra o mapeamento de um serviço sensível a contexto para um serviço

WSDL utilizando a notação proposta em [Lopes et al. 2005]. Nesta figura, um círculo

representa uma correspondência, i.e., um elemento de modelagem utilizado para

especificar os relacionamentos entre dois ou mais elementos (à esquerda e à direita).

Cada relacionamento possui um elemento à esquerda (representado por uma seta

simples) e um ou mais elementos à direita (representado(s) por uma seta dupla). Uma

definição de mapeamento contém todas as correspondências entre os dois metamodelos.

Na seqüência, um provedor de serviço, representado pela metaclasse Provider, e sua

associação com um conjunto de serviços providos pelo mesmo são mapeados para uma

associação concreta das definições de serviço para o protocolo SOAP, incluindo a

definição concreta de um endereço (porta) a ser utilizado pelo protocolo SOAP para a

invocação do serviço. Este mapeamento complementa o mapeamento anterior, e deve

ser realizado separadamente para cada serviço provido pelo servidor. A especificação

completa deste mapeamento pode ser encontrada em [de Farias 2007].

A Figura 4 apresenta os principais pontos da especificação da transformação das

assinaturas de serviço sensível a contexto para definições de serviço WSDL usando o

padrão QVT. A especificação da transformação foi realizada utilizando-se a linguagem

de mapeamento operacional do QVT. Escolhemos esta linguagem porque a mesma

oferece um mecanismo poderoso para a especificação de transformações usando uma

abordagem imperativa.


127

S2WSDL

Definition

Message

ServiceOperation

SimpleService

MessagePart

Type

Message

Part

PortType

RequestResponse

OneWay

Operation

OperationElement

InputElement

OutputElement

FaultElement

M2M

MP2P

SO2O

Figura 3. Mapeamento de serviço sensível a contexto para WSDL

Esta especificação utiliza, via a cláusula access, a especificação das transformações dos

tipos de dados definidos na transformação CSW2WSDL [de Farias et al. 2007b] e incorpora

as definições das transformações das assinaturas de serviço. De acordo com esta

especificação, primeiramente são realizadas as transformações dos tipos de dados. Na

seqüência, cada serviço simples é mapeado para uma definição de serviço WSDL

equivalente através da definição de mapeamento Service to WSDL (S2WSDL). Por fim,

cada serviço provido por um servidor é transformado para uma definição concreta do

formato deste serviço utilizando-se o protocolo SOAP através da definição de

mapeamento Provider to Binding (P2B). A especificação completa desta

transformação pode ser encontrada em [de Farias 2007].


128

modeltype CWS uses ContextAwareMetamodel; modeltype WSDL uses WSDLMetamodel;

transformation CompleteCSW2WSDL (in cwsModel: CWS out, wsdlModel: WSDL)

access transformation CSW2WSDL (in cwsModel: CWS out, wsdlModel: WSDL);

main(){

-- first process CSW2WSDL transformation

-- for each CWEntity create a corresponding XSDElement

cwsModel.objectsOfType(CWEntity)->map E2XSD();

-- for each CWAttribute create a corresponding XSDElement

cwsModel.objectsOfType(CWAttribute)->map A2XSD();

-- then process service transformation

-- for each SimpleService create a corresponding WSDL definition element

cwsModel.objectsOfType(SimpleService)->map S2WSDL();

-- for each provided service create a corresponding binding

cwsModel.objectsOfType(Provider)->map P2B();

}

-- S2WSDL - Service to WSDL mapping

mapping SimpleService::S2WSDL(): result:Definition{

object result:Definition{

name := self.name;

-- create a type element

type := new Type();

type.element := resolve(#XSDElement);

-- create message elements

message := cwsModel.objectsOfType(Message)->map M2M();

-- create a (single) port type element

portType := new PortType();

portType.name := self.name+'_PortType';

portType.operation := self.service_operation->map SO2O(message);

-- create a null service

service := null;

-- create a null binding

binding := null;

}

}

-- P2B - Provider to Binding mapping

mapping Provider::P2B(): result:SOAPBindingExtension{

-- select provided service(s)

var wsdl_serv: Set(Definition) := self.service.resolve(#Definition);

-- for each provided service creates a corresponding binding

wsdl_serv->forEach(s){

-- update service definition

s.service := new Service();

s.service.name := s.name+'_Service';

s.service.port := new SOAPPortBinding(s.name, self.host, self.port);

-- update binding definition

s.binding := new SOAPBindingExtension(s.portType);

} }

Figura 4. Especificação da transformação das assinaturas de serviço

6. Conclusão

O processo de transformação está subjacente aos esforços empreendidos pela indústria

de software para elevar o nível de abstração e produtividade no desenvolvimento de

sistemas computacionais. Desde a criação dos montadores e o surgimento dos

compiladores, até o desenvolvimento de plataformas distribuídas, o que se obteve de

ganho na esfera de abstração no desenvolvimento de software foi basicamente

sustentado por sucessivas ações de interpretação e de transformação.


129

A transformação de modelos é um dos aspectos principais no desenvolvimento baseado

em modelos de sistemas computacionais. De maneira geral, as transformações

favorecem o desenvolvimento de abordagens nas quais modelos de alto nível são

(automaticamente) transformados em modelos concretos de um dado domínio. Neste

sentido, o padrão QVT desempenha um papel fundamental na abordagem MDA, dado

que este padrão define como transformações podem ser especificadas em uma

arquitetura declarativa.

Este artigo apresenta um estudo de caso envolvendo a definição de metamodelos

independentes de plataforma (metamodelo de serviços sensíveis ao contexto) e

específicos de plataforma (metamodelo de serviços web), bem como o uso do QVT para

especificar as transformações entre estes metamodelos. A especificação de uma

transformação é uma tarefa complexa que envolve o conhecimento dos domínios origem

e destino. Neste sentido, este trabalho reforça trabalhos anteriores [Lopes et al. 2005],

[Lopes et al. 2006], [de Farias et al. 2007b] nos quais a separação entre o mapeamento

entre metamodelos e a especificação de uma transformação auxilia na resolução desta

complexidade.

O trabalho apresentado neste artigo é parte de um esforço maior que visa prover uma

abordagem baseada em modelos para o desenvolvimento de aplicações sensíveis ao

contexto [Leite et al. 2006, de Farias et al. 2007a, de Farias et al. 2007b, de Farias et al.

2007c]. Neste sentido, investigações adicionais ainda são necessárias para incorporar ao

metamodelo de contexto a especificação de comportamento de serviços, antes de

definirmos como este metamodelo de comportamento de serviço poderá ser

transformado em um metamodelo da implementação de serviço.

Agradecimentos

Agradecemos o apoio do CNPq para a realização deste trabalho (processo número

50.6284/2004-2) e o apoio da FAPESP para a apresentação do mesmo.

Referências

de Farias, C. R. G. (2007). Especificação de transformações de modelos sensíveis ao

contexto para serviços web. Documento de projeto, DBMWare/CNPq/D2.2, v.1.0.

de Farias, C. R. G., Barbosa, C. B., Leite, M. M., Pessoa, R. M., Calvi, C. Z., Pereira

Filho, J. G. (2007a). Suporte ao Desenvolvimento Baseado em Modelos de

Aplicações Móveis Sensíveis ao Contexto. Proceedings of the Second Workshop on

Ontologies and Metamodeling in Software and Data Engineering (WOMSDE 2007),

pp. 21-31.

de Farias, C. R. G., Ferreira Pires, L. and van Sinderen, M. (2007b): A Case Study on

the Transformation of Context-Aware Domain Data onto XML Schemas. In

Proceedings of the 3rd International Workshop on Model-Driven Enterprise

Information Systems (MDEIS 2007), pp. 63-72.

de Farias, C. R. G., Leite, Marcos Medina, Calvi, Camilo Zardo, Pessoa, Rodrigo

Mantovaneli, Pereira Filho, José Gonçalves (2007c): A MOF Metamodel for the

Development of Context-Aware Mobile Applications. In Proceedings of the 2007

ACM Symposium on Applied Computing (SAC 2007), pp. 947-952.


130

Dockhorn Costa, P., Ferreira Pires, L., van Sinderen, M.J. (2005). Designing a

Configurable Ser-vices Platform for Mobile Context-Aware Applications.

International Journal of Pervasive Computing and Communications, 1(1), pp. 13-25.

Leite, M. M. (2007): Um Metamodelo MOF e um Perfil UML para o Suporte ao Desenvolvimento Baseado em Modelos de Aplicações Móveis Sensíveis ao Contexto. Dissertação de mestrado, Universidade Católica de Santos, 2007.

Leite, M. M., de Farias, C. R. G., Pessoa, R. M., Calvi, C. Z., Pereira Filho, J. G. Um

Metamodelo MOF para o Desenvolvimento de Aplicações Móveis Sensíveis ao

Contexto. Anais do First Workshop on Ontologies and Metamodeling in Software and Data Engineering (WOMSDE 2006), Florianópolis (SC), p. 21-31, 2006.

Lopes, D., Hammoudi, S., Bézivin, J., Jouault, F. (2005): Generating Transformation

Definition from Mapping Specification: Application to Web Service Platform. In

Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE'05), LNCS 3520, pp. 309-325.

Lopes, D., Hammoudi, S., Bézivin, J., Jouault, F. (2006): Mapping Specification in MDA: From Theory to Practice. In: Konstantas, D., Bourrières, J.-P., Léonard, M.,

Boudjlida, N. (Eds). Interoperability of Enterprise Software and Applications -

INTEROP-ESA. Springer, pp. 253-264.

OMG (2001). Model Driven Architecture (MDA). Object Management Group.

OMG (2002). MOF 2.0 Query/Views/Transformations Request For Proposal. Object Management Group.

OMG (2003). MDA Guide, Version 1.0. Object Management Group.

OMG (2005a). Meta Object Facility (MOF) 2.0 Query/View/Transformation Specification, OMG Adopted Specification. Object Management Group.

OMG (2005b). OCL 2.0 Specification, OMG Specification, version 2.0. Object Management Group.

Patrascoiu, O. (2004).YATL: Yet Another Transformation Language. In Proceedings of the 1st European MDA Workshop, MDA-IA. University of Twente, the Netherlands, January, pp. 83-90.

Pavão Lopes, D. C. (2005). Étude et application de l’approache MDA pour des plates-formes de Service Web. Thèse de Doctorat, Université de Nates.

Sendall, S. and Kozaczynski, W. (2003). Model Transformation: heart and soul of

Model-driven software development. IEEE Software, September/October, pp. 42-5.

W3C (2000). Simple Object Access Protocol (SOAP) 1.1. Available at

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

W3C (2001). Web Services Description Language (WSDL) 1.1. Available at

http://www.w3c.org/tr/wsdl.


131

Transformação de Serviços Sensíveis ao Contexto para ... · contexto físico e computacional de...

Documents

Transcript of Transformação de Serviços Sensíveis ao Contexto para ... · contexto físico e computacional de...