anÁlise de linguagens de composiÇÃo para web … · de software e um quebra-cabeça. cada...
TRANSCRIPT
DALTON LUIZ MARCÍLIO
ANÁLISE DE LINGUAGENS DE COMPOSIÇÃO PARA WEB SERVICES
Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Informática, Curso de Pós-Graduação em Informática, Setor de Ciências Exatas, Universidade Federal do Paraná. Orientadora: Profa. Dra. Maria Salete Marcon Gomez Vaz
CURITIBA
JANEIRO 2006
II
SUMÁRIO
1 Introdução................................................................................................................................... 1
2 Componentes de Serviços e Software ....................................................................................... 3
3 Web Services.............................................................................................................................. 8
3.1 SOAP - Simple Object Access Protocol ............................................................................ 9
3.2 WSDL - Web Services Description Language ................................................................. 12
3.3 UDDI - Universal Description, Discovery and Integration................................................ 12
3.4 Entidades Regulamentadoras dos Web Services ........................................................... 16
3.4.1 OASIS - Organization for the Advancement for Structured Information Standards 16
3.4.2 W3C - World Wide Web Consortium....................................................................... 16
3.4.3 WS-I - Web Services Interoperability Organization................................................. 16
3.5 Composição de Web Services......................................................................................... 17
3.6 Linguagens de Composição para Web Services............................................................. 19
3.6.1 Requisitos de uma Linguagem de Composição...................................................... 21
3.6.2 Processo de Negócio no Contexto das Linguagens de Composição ..................... 22
3.6.3 Metadados e Padronização .................................................................................... 23
3.6.4 BPML – Business Process Modelling Language .................................................... 26
3.6.5 XLANG – X Language............................................................................................. 28
3.6.6 WSFL - Web Service Flow Language ..................................................................... 30
3.6.7 BPEL4WS - Business Process Execution Language for Web Services ................. 32
3.6.8 WSCI - Web Service Choreography Interface ........................................................ 35
3.6.9 WS-CDL - Web Service Choreography Description Language .............................. 38
4 Estudo de Caso e Análise ........................................................................................................ 40
4.1 Exemplo de um Processo interorganizacional................................................................. 40
4.2 Implementação WS-CDL da Coleta de Taxas Municipais............................................... 43
4.3 Implementação BPEL4WS da Coleta de Taxas Municipais. ........................................... 47
4.4 Características de Comparação dos Padrões de Linguagens de Composição .............. 49
4.5 Resultados Obtidos na Análise dos Padrões de Linguagens de Composição ............... 53
5 Conclusões e Trabalhos Futuros.............................................................................................. 57
Referências ....................................................................................................................................... 59
Anexos............................................................................................................................................... 63
A. Exemplo de uso dos Web Services ..................................................................................... 63
A.1. Código.............................................................................................................................. 63
A.2. Resultado final em XML................................................................................................... 63
A.2.1. Url que chama o WebService...................................................................................... 63
III
A.2.2. Retorno em XML.......................................................................................................... 64
A.3. Arquivo de publicação – WSDL ....................................................................................... 64
A.4. Arquivo envelope para WebService - SOAP ................................................................... 68
IV
ÍNDICE DE FIGURAS
FIGURA 1 – DEFINIÇÃO DE SERVIÇO ATRAVÉS DE UMA APLICAÇÃO ............................. 5
FIGURA 2 – CENÁRIOS DE WEB SERVICES............................................................................... 9
FIGURA 3 – ELEMENTOS DE UMA MENSAGEM SOAP.......................................................... 11
FIGURA 4 – UDDI DENTRO DA ESTRUTURA DE WEB SERVICES....................................... 14
FIGURA 5 – CENÁRIO DE PADRÕES DE WEB SERVICES...................................................... 15
FIGURA 6 – CENÁRIO DETALHADO DE PADRÕES DE WEB SERVICES ............................ 15
FIGURA 7 – EXEMPLO DE COMPOSIÇÃO DE SERVIÇOS ...................................................... 18
FIGURA 8 – LINGUAGENS DE COMPOSIÇÃO DE WEB SERVICES AO LONGO DO
TEMPO...................................................................................................................................... 20
FIGURA 9 – EXEMPLO DE CODIFICAÇÃO BPML.................................................................... 28
FIGURA 10 – EXEMPLO DE CODIFICAÇÃO XLANG............................................................... 30
FIGURA 11 – EXEMPLO DE CODIFICAÇÃO WSFL.................................................................. 31
FIGURA 12 – EXEMPLO DE CODIFICAÇÃO BPEL4WS........................................................... 34
FIGURA 13 – EXEMPLO DE CODIFICAÇÃO WSCI................................................................... 37
FIGURA 14 – EXEMPLO DE CODIFICAÇÃO WS-CDL ............................................................. 39
FIGURA 15 – DIAGRAMA DE ATIVIDADES – COLETA DE TAXAS MUNICIPAIS ............. 42
V
ÍNDICE DE TABELAS
TABELA 1 – PROTOCOLOS............................................................................................................ 14
TABELA 2 – PADRÕES DE METADADOS...................................................................................... 25
TABELA 3 – PADRÕES DE METADADOS E AMBIENTE DE DESENVOLVIMENTO ................. 26
TABELA 4 – COMPARAÇÃO DAS LINGUAGENS DE COMPOSIÇÃO ......................................... 53
VI
RESUMO
Web Services são componentes de software que podem ser acessados através da
Internet por outros softwares. O objetivo principal dos Web Services é a
interoperabilidade total entre aplicações. Como a integração entre sistemas requer
mais do que a habilidade de manipular simples operações, há a necessidade de
ferramentas para a modelagem de complexos processos de negócio, visando
assim maior qualidade nas informações a serem analisadas. Essas ferramentas
são linguagens de composição baseadas em Metadados, que apresentam
características próprias de descrição de serviços, composição, orquestração,
execução e interpretação. Neste trabalho são abordados os conceitos, descrições
e uma análise entre as mais importantes linguagens de composição para Web
Services com o objetivo de apresentar um entendimento do panorama relativo a
padronização dos componentes da referida tecnologia, com foco especial às
linguagens de composição.
Palavras-chave: Web Services, Metadados, Linguagens de Composição de
Web Services.
VII
ABSTRACT
Web Services are software components that can be accessed through the Internet
by other softwares. The main goal of Web Services is the full interoperability
among applications. Since the integration among systems requires more work than
the ability of manipulating simple operations, it’s necessary to use tools for
modeling complex business processes, aiming more quality of information that is to
be analyzed. These tools are language compositions based on Metadata that
presents its own features of description services, compositions, orchestration,
execution and interpretation. In this work, the concepts, descriptions and an
analysis among the most important composition languages for Web Services are
broached, with the objective to present an agreement of the relative overview the
standardization of the components of the related technology, with special focus to
the composition languages.
Keywords: Web Services, Metadata, Web Services Composition Languages.
1
1 Introdução
No cenário mundial atual a Internet é utilizada por muitas organizações para a
geração de negócios e troca de informações. Devido a esses fatores as
tecnologias de sistemas empregados por essas empresas muitas vezes precisam
passar por um processo de adaptação e re-implementação dos recursos
existentes a fim de fornecer subsídios para a divulgação dos seus serviços e o
intercâmbio de informações, levando assim ao ganho de vantagens competitivas.
É neste ambiente que a tecnologia de Web Services promete ser uma das
soluções viáveis a serem analisadas, pois seu objetivo principal é a integração de
sistemas, onde padrões web podem oferecer interoperabilidade total entre
aplicações. A tecnologia foi desenvolvida levando-se em consideração os
problemas e limitações encontradas em outras plataformas, a reutilização de
soluções previamente desenvolvidas nas empresas, servidores Web e protocolos
de comunicação, entre outras características.
Este documento envolve um estudo analítico das linguagens de
composição e seus Metadados referentes à gama de serviços Web Services, que
é um gabarito de tecnologias que permite que diferentes aplicações, em diferentes
plataformas e linguagens, conversem entre si através da Internet.
De acordo com esse contexto e com o advento das linguagens de
composição para Web Services, que envolvem estruturas que permitem a
execução e o gerenciamento de complexos processos de negócio em uma
organização, vêm à tona a necessidade de analisar tais linguagens a fim de
perceber suas características de adaptação às diversas situações que podem
existir tanto para uso acadêmico quanto comercial além de discutir as várias
padronizações de composição para auxiliar as diversas entidades na
compreensão das linguagens.
Este trabalho está estruturado como se segue: O capítulo 2 discute os
aspectos relacionados a composição de serviços e sistemas bem como a
contextualização sobre Web Services, apresentando assim os padrões já
estabelecidos para tal tecnologia.
2
O capítulo 3 relaciona a fundamentação e padronização existente na tecnologia
Web Services. Neste mesmo capítulo são apresentadas as principais entidades
reguladoras de Web Services e das linguagens de composição; uma abordagem
em relação a questão da composição de Web Services incorporada à composição
de sistemas; as características desejáveis de toda linguagem de composição e a
inserção da tecnologia na esfera pertinente aos processos de negócio bem como
a descrição das principais linguagens de composição em relação aos próprios
Metadados ao longo do tempo.
Um estudo de caso sendo ilustrado pelas linguagens de composição que
estão em contínuo processo de evolução é demonstrado no capítulo 4. No mesmo
capítulo é apresentada uma análise comparativa entre as linguagens abordadas,
levando em consideração características comuns e comportamentos analisados
em suas especificações. Finalmente, o capítulo 5 apresenta as conclusões deste
trabalho e questões a serem pesquisadas em um trabalho futuro.
3
2 Componentes de Serviços e Software
O conceito de transformação de desenvolvimento de aplicações em um
desenvolvimento baseado em componentes já possui vários anos de discussões.
Entretanto, sua adoção em grande escala ainda depende do desenvolvimento de
tecnologias e padrões que sejam aptos a descrever essas “peças” de software de
forma independente de sua codificação e implementação.
É possível estabelecer uma comparação entre a utilização de componentes
de software e um quebra-cabeça. Cada componente pode ser, de forma análoga,
como uma peça do quebra-cabeça que deve ser encaixada com as outras para
formar uma estrutura complexa (ou, no caso do software, a aplicação final).
Em se tratando de desenvolvimento de software, esta composição ainda
ganha mais uma dimensão, pois a questão abstrata dos componentes de software
permite uma dinâmica ainda maior no agrupamento, o que resulta em uma enorme
gama de criação de diferentes aplicações a partir dos mesmos componentes, o
que no caso do quebra-cabeça não é verdadeiro.
De acordo com esse contexto, um aspecto muito importante é a capacidade
de composição dinâmica destes componentes, que deve ser feita de forma
automatizada por alguma espécie de software responsável pela composição e
coordenação destes serviços. Com o advento da Web e a grande quantidade de
fontes de informação e de serviços disponíveis na rede, existe um fator
determinante que dificulta ainda mais essa composição, que é a semântica das
informações envolvidas. É sabido que não existe uma forma única de descrever os
recursos na Internet ou rede, então as inconsistências e ambigüidades que
fatalmente aparecerão precisam ser tratadas de alguma forma.
Por conta dos fatos descritos acima, o desenvolvimento de aplicações
baseadas em serviços distribuídos na Internet envolve a composição de serviços
tanto em relação as funcionalidades dos mesmos como a estruturação e
integração dos dados trocados entre os diferentes serviços que compõem o
sistema.
4
Assim, existe a necessidade da introdução de semânticas nos dados
trocados entre os módulos do sistema, permitindo que os computadores possam
“raciocinar” e executar tarefas complexas utilizando componentes de software que
não foram projetados para trabalhar juntos a princípio.
De uma forma genérica, um serviço pode ser definido como toda e qualquer
fonte de informações disponibilizada através da Internet. Estas fontes podem estar
conectadas diretamente a componentes de software (como sistemas de bancos de
dados) ou a tarefas que são executadas por pessoas intermediadas por algum
meio de comunicação (como uma reserva sendo feita através de e-mail em um
hotel).
Uma questão fundamental no desenvolvimento de aplicações orientadas a
serviços é a definição de uma forma única de acesso e gerenciamento dos
serviços. Isto pode ser feito através de um padrão para definição e descrição dos
serviços e de tecnologias de middleware para o desenvolvimento de software.
Componentes podem ser definidos como unidades de composição com
interfaces especificadas através de contratos e com dependências de contexto.
Um componente de software pode ser apresentado de forma independente e é
passível de composição por terceiros [30].
Uma outra definição apresenta componentes de software como unidades
reutilizáveis de uma solução, que devem ser integradas a um todo para que
efetuem um papel na solução [31].
De acordo com a definição de serviço apresentada anteriormente, um
Componente de software pode ser entendido como uma unidade de software
responsável por apresentar ao sistema as informações relativas a uma tarefa
atômica, que pode ser executada por uma máquina ou por uma pessoa. A Figura
1 representa os serviços compostos por componentes em um sistema.
5
FIGURA 1– DEFINIÇÃO DE SERVIÇO ATRAVÉS DE UMA APLICAÇÃO
A utilização plena destes componentes de software pode trazer como
conseqüência um substancial incremento na qualidade das soluções resultantes,
um aumento da produtividade da equipe e do processo de desenvolvimento
utilizado e incremento da confiança e segurança dos componentes propriamente
ditos, pois estes podem ser devidamente testados e validados.
A partir deste ponto, a solução de problemas através da decomposição de
uma solução em unidades relevantes, ou seja, dividir para conquistar, pode vir a
facilitar o entendimento do problema, além de contribuir para a redução dos custos
associados ao desenvolvimento e evolução da solução. Além de decompor, é
preciso documentar e evitar possíveis acoplamentos entre as unidades geradas,
para que o processo de evolução dos componentes da solução possa ser feito
com o menor impacto possível.
Como exemplos de componentes pode-se citar desde funções, classes,
pacotes, componentes CORBA, subsistemas, processos distribuídos, Web
Services até agentes de software. A taxa de complexidade e os serviços
oferecidos por cada uma dessas tecnologias variam bastante, acarretando com
6
isso uma inexistência de uma tecnologia que de fato possibilite a unificação entre
as mais diversas abordagens.
Além de todos estes aspectos, o desenvolvimento de software baseado em
componentes precisa ser analisado sobre duas perspectivas. A primeira diz
respeito a como desenvolver um componente e está interessada em definir
claramente o escopo, limitações e características oferecidas pela unidade. A
segunda se preocupa em como reutilizar e compor diferentes componentes para
solucionar determinado problema.
De acordo com esta visão sobre desenvolvimento orientado a
componentes, uma aplicação baseada em serviços tem como ponto principal a
escolha de uma tecnologia de componentes que permita o desmembramento e a
distribuição das partes através de uma rede. Uma vez escolhida, cabe ao analista
da aplicação determinar qual a melhor forma de realizar a composição dos dados
e das funcionalidades destes componentes de software. Como exemplo de
tecnologia de componentes para a realização de tais serviços, podemos citar Web
Services, tecnologia que é o escopo deste trabalho e é apresentada no capítulo
seguinte.
Como forma de entender o mecanismo de componentes no contexto de
uma aplicação baseada em serviços, é importante entender a arquitetura típica da
tecnologia de componentes. Tomando Web Services como base, é possível definir
três tipos básicos de entidades: Service Provider (Provedor de Serviço ou Área de
Publicação), Service Broker (Serviço de Busca e Registro) e Service Requester
(Serviço de Requisições e Gerenciamento). O comportamento desses serviços é
ilustrado na Figura 2.
Um serviço distinto é fornecido por um Provedor de Serviço. Este publica
suas funcionalidades em algum sistema de busca por serviços, que recebe o
nome de Serviço de Busca. Um Serviço de Requisições é uma classe que irá
utilizar alguma funcionalidade de um Web Service para realizar alguma tarefa mais
completa. Para tal, ela entra em contato com algum Broker de Serviços através de
algum padrão para descoberta (por exemplo, UDDI). Ao receber a resposta, o
7
Serviço de Requisições terá as interfaces padrão para acesso aos serviços que
atendem às suas necessidades.
Essas interfaces fazem parte da descrição do serviço, que normalmente é
feita em uma linguagem específica para isso, a WSDL (Web Services Description
Language). A partir deste ponto, os serviços fornecidos pelos Provedores de
Serviço poderão ser acessados utilizando um protocolo de acesso a objetos
remotos (como por exemplo, SOAP).
De acordo com os fatos apresentados, fica claro que são necessários três
padrões para a definição de uma tecnologia de componentes. Estes permitem que
componentes sejam descritos, acessados e publicados de uma forma homogênea.
Como forma de contextualizar estes três padrões e apresentar as suas
características mais comuns serão detalhados a seguir os conceitos comuns
utilizados na tecnologia de Web Services.
8
3 Web Services Recomendada pela W3C, uma das entidades regulamentadoras para Web
Services, o conceito de Web Services permite que aplicações criadas possam ser
publicadas e invocadas através da Internet. Esta tecnologia tornou-se rapidamente
um padrão porque tem como base a linguagem XML, que utiliza os protocolos
padrões da Internet, como o HTTP/SMTP, que já são amplamente utilizados
[26,27].
Sendo aplicações modulares, autodescritivas, acessíveis através de uma
URL, independentes das plataformas de desenvolvimento e que permitem a
interação entre aplicações sem intervenção humana, os Web Services
apresentam-se como a solução para os atuais problemas de integração de
aplicações.
Os componentes básicos de sistemas que utilizam Web Services,
independente de qualquer linguagem de programação, são os seguintes:
1. Protocolo de comunicação (SOAP – Simple Object Access Protocol);
2. Linguagem para a descrição dos seus serviços e tipo dos dados
utilizados (WSDL - Web Services Description Language);
3. Mecanismo de publicação e busca dos serviços (UDDI - Universal
Description, Discovery and Integration).
A Figura 2 ilustra o cenário de trabalho de um Web Services e as tecnologias
envolvidas.
9
FIGURA 2 – CENÁRIOS DE WEB SERVICES
Nas seções seguintes são descritas as tecnologias envolvidas e apresentadas na
Figura 2.
3.1 SOAP - Simple Object Access Protocol SOAP originou-se da idéia de um mecanismo de RPC (Remote Procedure Calls)
baseado em XML originalmente proposto por Dave Winer em 1998. SOAP é uma
especificação da W3C proposta por organizações como Userland®, Ariba®,
Microsoft®, IBM®, Compaq®, HP®, Lotus®, SAP® entre outras. É um protocolo
elaborado para facilitar a chamada remota de funções via Internet, permitindo que
dois programas se comuniquem de uma maneira muito semelhante às páginas
Web [28].
A comunicação entre clientes e servidores é feita através do protocolo
SOAP. Dessa maneira, as RPC (Remote Procedure Calls - Chamadas Remotas
de Procedimento) são codificadas em XML e operam sobre HTTP. Com isso,
pode-se acessar os serviços de um objeto localizado em um outro local da rede,
através de uma chamada local a este objeto. Para o transporte de mensagens é
Repositório Remoto de Web Services
Web Services Remotos
Web Services Remotos
Web Services Remotos
Execução
Composição
Invocação
Busca
Registro de Serviços
Publicação de Web Services
Composição e Execução
Execução
Web Service
Proc. Abs.
Individual
Lookup
Invocar WS
Gerenciador de Serviços
10
usado o HTTP, que torna o SOAP um protocolo leve, elimina inúmeros problemas
de outras tecnologias com proxys.
Antes de serem enviadas pela rede, as chamadas de RPC (emitidas pela
aplicação cliente) são encapsuladas segundo o Padrão SOAP. Ao receber a
mensagem ocorre o processo contrário, desencapsulando-as e extraindo as
chamadas de método. A aplicação servidora então processa esta chamada, e
envia uma resposta ao cliente. O processo então se repete: a resposta é também
encapsulada e enviada pela rede. Na máquina cliente, esta resposta é
desencapsulada e repassada para a aplicação cliente.
Uma grande vantagem do SOAP é a de que não tem que contornar os
esquemas de segurança para realizar a comunicação entre clientes e servidores.
Como o SOAP usa o HTTP como camada de transporte ele opera na porta 80,
que na maioria dos casos está liberada pelo proxy/firewall. Conceitualmente não
existe diferença entre uma requisição a um método e a uma página HTML.
A especificação SOAP (definida pela W3C) define as seguintes
informações, como necessárias em toda chamada de RPC:
• A URI, equivalente à URL, do HTTP do objeto alvo;
• Nome do método;
• Os parâmetros do método (requisição ou resposta);
• Uma assinatura do método opcional;
• Um cabeçalho opcional.
Uma mensagem SOAP consiste basicamente em uma estrutura com os elementos
apresentados na Figura 3:
11
FIGURA 3 – ELEMENTOS DE UMA MENSAGEM SOAP
Envelope: Toda mensagem SOAP deve ter um. É o elemento raiz do
documento XML. O Envelope pode conter declarações de namespaces e também
atributos adicionais, como o que define o estilo de codificação, que define como os
dados são representados no documento XML.
Cabeçalho (Header): É um cabeçalho opcional. Ele carrega informações
adicionais, como por exemplo, se a mensagem deve ser processada por um
determinado nó intermediário. Quando utilizado, o cabeçalho deve ser o primeiro
elemento do Envelope.
Corpo: O corpo é um elemento obrigatório e contém o payload, ou seja, a
informação a ser transportada para o seu destino final.
Fault: É um elemento opcional do corpo, usado para carregar mensagens
de status e erros retornadas pelos "nós" ao processarem a mensagem.
A segurança no envio de mensagens SOAP pode ser trocada pela rede utilizando
HTTPS ao invés de HTTP. Como HTTPS utiliza SSL no seu transporte, fica
garantida a proteção contra possíveis intervenções. Além disso, o cliente e
servidor podem verificar cada um suas respectivas identidades. Apesar de garantir
a segurança quanto a intrusos, em muitos casos é necessária a autenticação de
usuários de Web Services. Estes serviços irão fornecer algum tipo de combinação
de usuário/senha durante a fase inicial de registro no serviço e então será utilizada
para acessos futuros [28].
12
3.2 WSDL - Web Services Description Language A descrição de um Web Service se dá através de um arquivo WSDL cujo formato
está em XML. Este arquivo tem como objetivo descrever a interface do serviço, ou
seja, os métodos que são disponibilizados pelo Web Service, parâmetros
recebidos, a resposta enviada e ainda o processo de comunicação com o servidor
SOAP. É através do WSDL que o UDDI (Universal Description, Discovery and
Integration) descreve os detalhes de localização e chamada ao Web. Em outras
palavras, o WSDL é para o SOAP o que o IDL (Interface Definition Language) é
para o CORBA ou DCOM [29].
Um cliente SOAP vai ler a estrutura do arquivo WSDL e, a partir dos dados
referenciados, se comunicar com o servidor SOAP para acesso ao serviço
descrito.
O WSDL é extensível para permitir a descrição de serviços e suas
mensagens independentemente dos formatos de mensagem e dos protocolos de
rede que sejam usados.
Esse padrão possui cinco elementos importantes, divididos em duas
camadas: abstrata e concreta. A definição abstrata é composta por tipos,
mensagens e port (portas). Os tipos de dados são aqueles que são enviados e
recebidos dentro da mensagem. Depois de definidos os tipos, são definidos os
dados que serão enviados pelo sistema através da definição de mensagem. Já
port trata-se de uma série de operações relacionadas à mensagem, como entrada,
saída e tratamento de exceções.
A Definição concreta é composta das ligações e dos serviços. As ligações fazem
mapeamento da implementação com a interface descrita em XML. Já o serviço
está relacionado ao port. O serviço indica se o elemento, um nome ou um sub-
elemento que aparece várias vezes.
3.3 UDDI - Universal Description, Discovery and Integration O UDDI é um grande cadastro global. São as páginas amarelas dos Web
Services. Como as páginas amarelas tradicionais, pode-se procurar por uma
13
companhia que ofereça os serviços necessários, ler sobre o serviço oferecido ou
contatar alguém para obter mais informações.
Um diretório UDDI é um arquivo XML que descreve o negócio e os serviços.
O registro tem três partes:
Páginas brancas: descrevem a companhia: nome, endereço e contatos;
Páginas amarelas: incluem as categorias, baseada em taxonomias padrões.
Páginas verdes: descrevem a interface para o serviço, em nível de detalhe
suficiente para se escrever uma aplicação que use o Web Service.
A forma como os serviços são definidos no documento UDDI é chamado
Type Model ou tModel. Em muitos casos, o tModel contém o arquivo WSDL que
descreve a interface SOAP do Web Service.
O diretório UDDI também inclui várias maneiras de procurar os serviços.
Por exemplo, pode-se procurar por fornecedores de um serviço em uma locação
geográfica específica ou por negócios de um tipo específico. Os provedores de
serviço registram ou publicam seus Web Services nesse diretório e um
mecanismo de descoberta localiza o Web Service para um cliente, mediante uma
pesquisa. A pesquisa pode ser por tipo de serviço ou por fornecedor.
A versão atual do UDDI é a Versão 2(2002), mas a Versão 3 já se encontra
em discussão no W3C. Um aspecto importante na Versão 3 é o suporte a
assinaturas digitais. Isso vem ao encontro de questões relevantes de segurança
existentes até então. Através desse mecanismo passa a ser possível ter uma
maior certeza de que o serviço oferecido pelo fornecedor é realmente o esperado,
podendo-se ter mais confiança na sua integridade.
A Figura 4 ilustra o contexto do UDDI dentro da estrutura de um Web
Service, localizado em conexão direta com o servidor Web.
14
FIGURA 4 – UDDI DENTRO DA ESTRUTURA DE WEB SERVICES
Um Web Service é composto por vários protocolos, a grande maioria
padronizados, apresentados na Tabela 1. Nesta tabela, os protocolos
referenciados e a linguagem de marcação XML fazem parte da comunicação que
envolve o protocolo SOAP. WSDL e UDDI já foram explanados por este trabalho.
As linguagens de composição pertencem a área de “Outros padrões ainda não
definidos”, onde a discussão desses padrões é o foco deste trabalho.
Outros padrões ainda não definidos
Universal Description Discovery Integration ( UDDI )
Web Services Description Language ( WSDL )
Simple Object Access Protocol ( SOAP )
Extensible Markup Language ( XML )
Protocolos Internet ( TCP/IP , HTTP, SMTP )
TABELA 1 – PROTOCOLOS
A Figura 5 indica as linguagens de descrição de Web Services em um contexto
global, incluindo exemplos de linguagens de composição.
15
FIGURA 5 – CENÁRIO DE PADRÕES DE WEB SERVICES
FIGURA 6 – CENÁRIO DETALHADO DE PADRÕES DE WEB SERVICES
A Figura 5 detalha os principais componentes de uma estrutura de Web
Services, onde a sua camada de composição e os Metadados relacionados são
tratados nas seções seguintes. A Figura 6 apresenta o cenário de padrões para
Web Services de uma forma mais detalhada, desde os componentes dos
protocolos de comunicação SOAP (TCP/IP, HTTP e XML), os protocolos de
definição, busca e divulgação (WSDL e UDDI) e as linguagens de composição no
nível mais elevado da hierarquia, que são responsáveis pela segurança, a
qualidade de serviço (QoS) e gerenciamento dos Web Services.
Composição de Web Services BPEL4WS, WSFL, etc
Publicação e Busca UDDI
Camada de Descrição dos Serviços - WSDL
Camada de Comunicação XML - SOAP
Camada de Transporte: HTTP,SMTP, etc
16
3.4 Entidades Regulamentadoras dos Web Services
Algumas entidades que regulamentam o uso, padronização e divulgação dos
Web Services estão descritas neste capítulo.
3.4.1 OASIS - Organization for the Advancement for Structured Information Standards
A OASIS foi criada para estabelecer padrões para Web Services. É formada
por um Comitê Técnico criado para desenvolver um Modelo de Componentes para
Serviços em Web (WSCM). Dentro do Comitê Técnico WSCM existe o grupo de
trabalho "Working Group Web Services User Interface" (WSUI) que submeteu as
primeiras especificações ao OASIS para considerações do WSCM.
O novo comitê tem duas metas principais:
• Habilitar negócios para distribuir aplicações na Web através de múltiplos
canais de revenda;
• Habilitar novos serviços ou aplicações a serem criados ou liberar as
aplicações existentes através da Web.
Isto deve permitir que as companhias possam transferir Web Services
através de portais e plataformas independente de produtos proprietários.
3.4.2 W3C - World Wide Web Consortium A W3C, entidade criada em 1994 tem o objetivo de guiar a Internet de forma
concisa e padronizada. Para isto o W3C, desenvolve protocolos, especificações
(como HTML e CSS) e ferramentas que garantem a inter-operacionalidade da
Internet. É composta de vários subgrupos de estudo.
3.4.3 WS-I - Web Services Interoperability Organization A WS-I é uma organização que promove a divulgação dos Web Services, a
interoperabilidade entre plataformas, sistemas operacionais e linguagens de
17
programação. Tem o objetivo de criar protocolos genéricos e independentes para
a segurança e eficiência na entrega de mensagens, capaz de manter a
compatibilidade entre as plataformas. Promove também a educação e divulgação
de como os Web Services podem ser utilizados, suas potencialidades e
perspectivas de uso.
3.5 Composição de Web Services
A composição de Web Services envolve as mesmas dificuldades levantadas na
composição de componentes. Entre os maiores desafios para uma correta
coordenação de componentes, é possível citar três itens importantes:
• Em relação a dificuldade em garantir que os componentes efetuem as diferentes
tarefas de acordo com os contratos estabelecidos pela coordenação;
• A questão da necessidade de mecanismos de autenticação e segurança que
possam garantir uma não repudiação e sigilo nas transações descritas no
contrato;
• A importância da criação de módulos para controle de transações e tolerância a
falhas, dado que o fraco acoplamento entre os componentes faz com que os
mecanismos de tratamento de erros e controle de execução também sejam
fragmentados.
No entanto, o desenvolvimento de sistemas baseados em serviços permite
a criação de software sem que os desenvolvedores saibam que componentes irão
utilizar a princípio, sua localização e sua implementação. Esta característica
permite que os componentes sejam escolhidos de forma dinâmica em tempo de
execução. Essa propriedade garante maior poder de adaptação, distribuição e
tolerância a falhas por parte das aplicações. De acordo com esses princípios, uma
aplicação orientada a serviços é uma composição de componentes fracamente
acoplados.
Tomando como base às aplicações orientadas a serviços, é possível
imaginar a seguinte situação como exemplo: Um sistema de pacote de viagens,
18
detalhado na Figura 7, onde um cliente solicita reservas para um determinado
pacote turístico. Neste sistema, é possível realizar reservas para avião, hotel e
aluguel de carro. A partir do pedido de reserva, é então definido um processo para
reserva do itinerário. Esta especificação e definição podem definir ordens de
precedência e prioridade para chamada dos componentes do sistema bem como
critérios de parada em caso de erros e caminhos alternativos em função dos
resultados parciais.
FIGURA 7 – EXEMPLO DE COMPOSIÇÃO DE SERVIÇOS
Para a execução de todas as partes deste processo, é possível utilizar um
conjunto de componentes totalmente diferentes e de serviços distintos na Internet,
19
desde que estes atendam às especificações definidas de acordo com alguma
linguagem de especificação (por exemplo, WSDL).
Dessa forma, dois serviços distintos podem representar diferentes
entidades no mundo real (cada hotel ou companhia aérea pode representar um
serviço diferente) ou implementações independentes de uma mesma entidade
física (serviços e rotinas redundantes de um mesmo provedor).
3.6 Linguagens de Composição para Web Services
Embora os Web services terem estabelecido a base de mensagens e protocolos
para integração e são eficientes para algumas interações, eles não são suficientes
para a integração de processos de negócio que envolvem múltiplas empresas.
A integração de processos de negócio em cenários reais de negócio
envolvem interações de longa duração, gerenciamento de transações e invocação
de estados e são dirigidos por um motor de workflow que executa um processo
específico de negócio para automatizar o fluxo de informações e as operações de
negócio. Isso acarreta na necessidade de linguagens de composição de Web
Services, que provêm mecanismos que executarão a complexidade da execução
de processos de negócio.
A composição de Web Services é relacionada a agregação e composição
de Web Services para criar processos de negócio. Enquanto apenas uma única
linguagem padronizada é desejada para a especificação da composição de Web
Services, os esforços de organizações e indústrias têm resultado em duas idéias
principais:
• Vários trabalhos relacionados ao tema, como execuções de Web services,
orquestração de Web Services e coreografia de Web Services que
contribuem para a criação de processos de negócio baseados em Web
Services.
20
• Várias linguagens de composição de Web Services, como WSFL,
BPEL4WS e WS-CDL para a modelagem de processos de negócio com
Web Services.
As linguagens de composição para Web Services constituem o topo da
pirâmide dos padrões de Web Services, e são utilizadas para promover a
orquestração e coreografia de Web Services. A orquestração descreve os
processos de negócio que interagem com Web Services internos e/ou externos
em uma ordem pré-definida para realização do negócio lógico. A coreografia
descreve a colaboração entre os parceiros no processo de negócio, onde as
colaborações envolvem as trocas de mensagens que são realizadas entre os Web
Services.
De acordo com a complexidade dos processos de negócio, uma linguagem
de composição deve prover certos mecanismos para facilitar a modelagem e
execução de processos de negócio baseados em Web Services.
A composição de Web Services promete a interoperabilidade e reusabilidade de
vários processos de negócio, onde diversas empresas como IBM, Microsoft e Sun
desenvolveram vários padrões para essas linguagens. Os processos de
refinamento e convergência desses padrões ainda estão acontecendo.
FIGURA 8 – LINGUAGENS DE COMPOSIÇÃO DE WEB SERVICES AO LONGO DO TEMPO.
21
A Figura 8 mostra a evolução e as entidades envolvidas na criação desses
padrões através dos últimos anos.
3.6.1 Requisitos de uma Linguagem de Composição
Os requisitos para uma linguagem de composição para Web Services são os que
seguem:
• Deve ser auto-suficiente para expor detalhes de um serviço como seu
perfil, modelos de processos e mecanismos binding;
• Deve ser capaz de especificar interfaces de componentes em uma
implementação de maneiras independentes;
• Deve dar suporte ao desenvolvimento de componentes reutilizáveis em
um framework usando programação básica de controle de
construções;
• Deve prover suporte para processos baseados em construção e controle
de modelagens. O modelo deve ser capaz de manipular composições
seqüenciais, construções concorrentes como split, fork, split+join,
construções em loop como iterações, repeat and while e construções
não-determinísticas como choice e switch. Isso também implica em
prover suporte à modelagem de subprocessos.
• Deve ser capaz de especificar descrições de processos de uma maneira
abstrata sem amarrá-la a detalhes da execução atual para habilitar
descrições reutilizáveis e também ser capaz de modelar processos
executáveis que encapsulam o comportamento interno de um serviço.
• Deve expor a construção de modelagens que especificam
responsabilidades definidas pelos agentes envolvidos no processo de
composição, isto é, agentes de pedidos, agentes provedores e o
casamento de padrões;
• Deve fornecer tolerância a falhas, deadlocks, livelocks e mecanismos de
manipulação de exceções;
22
• Deve estar apta a modelar especificações de componentes, como
abstrações de comportamentos de componentes.
• Ser adequadamente expressiva tendo semântica de definição e uma
robusta base composta de modelos formais, para facilitar descrições
composições automatizadas de serviços através de agentes de
software;
• Deve ser capaz de modelar restrições, na forma de regras, para inibir
interações indesejadas entre os serviços. Isso também inclui suporte
para modelos transacionais e a qualidade do serviço.
• Segurança e Privacidade formam uma parte integral de qualquer serviço
de uma linguagem de composição. A linguagem deve estar apta a
modelar a segurança como uma requisição funcional do sistema.
3.6.2 Processo de Negócio no Contexto das Linguagens de Composição
Para o entendimento das linguagens de composição de Web Services, torna-se
necessário estabelecer alguns conceitos relacionados ao termo processo de
negócio.
• Processo de negócio da empresa: é a descrição dos passos
necessários à execução das atividades sem considerar o sistema
envolvido.
• Processo de negócio executável: esses sistemas são chamados de
BPMS (Business Process Management System). Limita-se a execução
dentro de uma única corporação. Sua execução não é limitada a
minutos ou horas, ao invés disso, ele pode demorar dias, meses ou
anos. BPML, XLNG e WSFL definem essa categoria de processo de
negócio.
• Processos de negócio ebXML: é uma especificação de colaboração a
qual pode ser usada para descrever como dois processos de negócio
concorrentes interagem no nível de negócio.
23
• Atividades do processo de negócio: representa uma interação de curta
duração entre usuários ou sistemas. Um exemplo típico é uma aplicação
OLTP (On Line Transaction Processing) J2EE.
• Workflow ou Workflow do processo de negócio: sistemas de workflow
são associados à gerência automatizada de documentos, os quais
requerem revisões e aprovações. Esses sistemas têm pouca ou
nenhuma integração com sistemas da empresa
No capítulo seguinte são apresentados os principais conceitos e os padrões
já estabelecidos de Metadados bem como as linguagens de composição e os
paradigmas de representação de processos de Web Services e seus respectivos
Metadados através de processos de negócio. São abordadas as linguagens de
composição WSFL, XLANG, WSCI, BPML, BPELW4S e WS-CDL, suas principais
características e a forma com que tratam os Metadados para a manipulação nos
Web Services.
3.6.3 Metadados e Padronização As pessoas que têm contato com ferramentas de Tecnologia da Informação
utilizam alguma forma de Metadados, mesmo eventualmente sem saber quem as
usam ou o seu significado.
A definição mais comum de Metadados é “dados sobre dados”. Embora
esta definição seja uma expressão da verdade e englobe todas as tentativas de
definição, ela não dá a verdadeira dimensão de todos os aspectos que a
envolvem.
Os Metadados não fornecem somente o formato e o nome dos itens de
dado, ele fornece o contexto em que o elemento de dado existe. Fornecem
também informações tais como o domínio dos possíveis valores, a relação do
elemento de dados com outros, regras de negócio do dado e mesmo a origem do
dado. A seguir são apresentados alguns conceitos formais de Metadados:
24
“São dados que descrevem os atributos de um recurso. Eles suportam funções
como: localização, descoberta, documentação e outros.”UKOLN(2000)”.
“Fornecem o contexto para entender os dados através do tempo”. Inmon (1998)
“São o instrumental para transformar dados brutos em conhecimento”.
ComputerWire(2000).
“É todo dado físico (contido em software ou outra mídia) e conhecimento
(adquirido pelos empregados e outras mídias) de dentro e fora da organização,
incluindo informação sobre dados físicos, processos técnicos e de negócio, regras
e restrições dos dados, e estrutura dos dados usados pela organização”. Marco
(2000, p. 4-5).
A finalidade principal dos Metadados é documentar e organizar de forma
estruturada os dados das organizações com o objetivo de minimizar duplicação de
esforços e facilitar a manutenção dos dados.
Segundo Terry Moriarty (1997, p. 57-59) estas diferentes interpretações
estão relacionadas ao estágio da organização dentro da hierarquia evolucionária
de gestão do conhecimento. Nesta abordagem, organizações no nível mais baixo
da hierarquia gerenciam dados brutos. Organizações mais avançadas são
capazes de administrar seus recursos de informação ao nível de Informação,
Conhecimento ou Sabedoria.
No nível de informação, o foco é nos relacionamentos entre todos os
componentes do sistema e os papéis individuais que eles assumem no sistema.
Uma organização que está envolvida ao ponto em que pode mostrar
explicitamente as regras de negócio governando seu comportamento está
atingindo o nível mais avançado da hierarquia. Neste patamar, a organização
monitora ativamente seus sistemas para garantir que seu comportamento esteja
como planejado, e dessa forma são possíveis as detecções e diagnósticos de
qualquer comportamento anormal do sistema.
25
Existem diversos padrões de Metadados para finalidades distintas de
informações. Para se ter uma idéia da variedade de esforços é mencionado alguns
destes padrões segundo a pesquisa de Souza (2000) na Tabela 2.
Padrão de Metadados Descrição
Directory Interchance Format (DIF) Cria entradas de diretórios que
descrevem um grupo de dados.
Government Information Locator Service (GILS) Informações governamentais.
Federal Geographic Data Committee (FGDC) Descrição de dados geo-espaciais.
Machine Readable Card (MARC) Catalogação bibliográfica.
Dublin Core (DC) Dados sobre páginas da web.
Consortium for the Interchange of Museum
Information (CIMI)
Informações sobre museus.
TABELA 2 – PADRÕES DE METADADOS
Para efeito deste estudo são considerados os principais padrões de
Metadados relacionados com o ambiente de desenvolvimento de aplicações
conforme Tabela 3.
Órgão Padrão Descrição Tipo
ISO ISO/IEC 11179
Especificação e padronização de
elementos de dados.
Jure
ISO IRDS - Information Resource
Dictionary System
Controle de um ambiente de
gerenciamento de recurso da
informação.
Jure
EIA CDIF - CASE Data Interchange
Format
Definição de metamodelos para
integração de ferramentas.
Facto
ECMA PCTE - Portable Common Tool
Environment
Trata de interfaces de
ferramentas/repositório.
Jure
W3C XML - eXtensible Mark-up
Language
Define e estrutura páginas da web.
Facilita a troca de Metadados na
Internet.
Facto
MDC MDIS - Meta Data Interchange
Specification
Padrão para troca de Metadados entre
Ferramentas da Tecnologia de
Informação.
Facto
26
MDC OIM - Open Information Model
Facilita compartilhamento e reuso no
desenvolvimento de aplicações e data
warehouse.
Facto
TABELA 3 – PADRÕES DE METADADOS E AMBIENTE DE DESENVOLVIMENTO
Deste conjunto (Tabela 3) a ser estudado, somente os trabalhos da ISO (11179 e
IRDS) e da ECMA (PCTE) são padrões “de jure”, ou seja, desenvolvidos por
representações nacionais e oficiais. Todos os outros são padrões “de facto”, ou
seja, conduzidas por consórcios de empresas do mercado.
3.6.4 BPML – Business Process Modelling Language
BPML é um padrão proposto pela BPMI.org (Business Process
Management Initiative), uma organização independente consorciada pela Sun,
Intalio, Sterling Commerce e outras. BPML pode ser visto como uma linguagem
que compete com outros standards como WSFL da IBM a XLANG da Microsoft, o
qual recentemente gerou uma fusão criando o BPEL4WS.
BPML foi originalmente desenvolvida para habilitar o gerenciamento
baseado em padrões para processos de e-business usados com a tecnologia
BPMS (Business Process Management System). Ela pode ser aplicada a uma
variedade de cenários, incluindo integração de aplicações empresariais e
composição de Web Services.
A linguagem BPML é uma especificação dedicada a processos de negócio
executáveis. A especificação inclui suporte compreensivo em controles de fluxos,
fluxo de dados e fluxo de eventos com estruturas de envio, recebimento e
execução paralela e sincronização.
Os principais ingredientes do BPML relacionados a Metadados são:
atividades, processos, contextos, propriedades e sinais. As atividades são
componentes que realizam funções específicas. Existem dois tipos de atividades:
simples e complexas. Atividades simples são atômicas enquanto que as
complexas são decompostas em atividades menores.
27
Um processo é uma atividade complexa que pode ser invocada por outros
processos. Um processo que é definido independentemente de outros processos é
chamado um processo top-level. Um processo que é definido para executar dentro
de outro processo é chamado de processo aninhado. Além disso, existem dois
tipos de processos especiais: processos de exceção e de compensação.
FIGURA 9 – EXEMPLO DE CODIFICAÇÃO BPML
A Figura 9 apresenta um exemplo de codificação em BPML, onde é
demonstrado um processo composto por uma ou mais seqüências, que por sua
vez são compostas por uma ou mais atividades.
Contextos são muito importantes em BPML. Um contexto define um
ambiente para execução de atividades relacionadas. O contexto pode ser usado
para trocas de informação e execuções coordenadas. Um contexto contém
definições locais que só são aplicadas dentro do escopo daquele contexto.
Definições locais incluem propriedades, processos e sinais, entre outros.
Contextos podem ser aninhados em um contexto filho (recursivamente) que herda
definições de seus contextos pai e podem sobrepor características. Um processo
pode ter um contexto no qual ele pode ser compartilhado por todas as atividades
que o executam como parte daquele processo.
Propriedades são usadas para trocas de informação e podem existir
somente em um contexto.
Uma definição de propriedade tem um nome e um tipo enquanto cada
instância da propriedade tem um valor no alcance dos tipos de uma definição
correspondente. Pode-se pensar em propriedades como atributos (ou variáveis de
28
instanciação) de um processo. Sinais são usados para coordenar a execução de
atividades que são executadas dentro de um contexto comum para sincronizar
atividades paralelas. Dessa forma, Sinais podem ser entendidos como
mensagens, e há construções a serem enviadas como uma mensagem (sinais
raise) e esperar uma mensagem sincronizar o sinal.
A notação das atividades é utilizada para especificar a execução de funções
com seus comportamentos especificados por atributos. Tipos suficientes de
atividades são contemplados, com 10 atividades simples e 7 complexas que
modelam a execução estruturada de processos de negócio. A definição de um
processo é um template que instancia instâncias de processos. Ela é construída
para modelar a execução de processos de negócio. As exceções são manipuladas
através de processos de exceção e manipuladores de falhas. A compensação
também é suportada para reverter o efeito das atividades em processos.
As transações de operações de negócio são suportados com três maneiras
através de declaração de atividades: Como atividades atômicas, processos
persistentes e transações aninhadas. A notação de agendamento é utilizada para
gerar eventos por tempo que podem ser disparados na instanciação de processos.
BPML foi construída no topo da descrição de serviço WSDL.
O padrão oferecido pela BPMI é muito similar a BPEL. Como diferenças
principais BPML habilita a especificação de múltiplos processos em um único
documento XML e relações de comunicação entre esses processos. Além disso,
BPML não está amarrada com WSDL. Conseqüentemente, o protocolo de
comunicação de BPML é concordante.
3.6.5 XLANG – X Language Originada pela Microsoft, XLANG é o segundo predecessor de BPEL. É uma
linguagem que torna possível formalizar processos de negócios como longas
interações em uma organização. As interações entre serviços podem ocorrer
através de trocas de mensagens expressas em forma de operações WSDL.
29
A especificação define extensões WSDL para descrever comportamentos
de processos de um Web Service similar a WSCI. De forma adicional, provê meios
de definir correlação de mensagens, regras, eventos e manipulação de exceções
bem como declaração de transações.
Um serviço de descrição XLANG é definido como um serviço de descrição
WSDL com elementos de extensão que descrevem o comportamento do serviço
como parte do processo de negócio. XLANG foca no comportamento público e
visível na forma de trocas de mensagens.
Uma interação em XLANG é uma instanciação de um serviço. Dessa forma
as mensagens trocadas não necessariamente precisam ser entregues para a
correta porta de destino, mas também para a instância correta do serviço que
define a porta, onde cada mensagem contém um “token de correlação”. Um
conjunto de tokens de correlação (chamado “conjunto de correlação”) é definido
como um conjunto de propriedades compartilhadas por todas as mensagens no
grupo de correlação.
XLANG assume que determinadas port types, usadas na definição de
serviços de descrição XLANG, são restrições que contém somente operações de
entrada, ou somente operações de saída. Um comportamento de um serviço
XLANG é composto por ações.
Essas ações podem ser operações WSDL, delays (por exemplo, uma
thread tem que ser pausada para outros processos serem executados), e “ações
raise” (isto é, a notificação de condições excepcionais).
Em um serviço XLANG, as ações são combinadas usando processos
básicos de controle, como ‘while’, ‘sequence’, ‘empty’, ‘switch’, ‘all’, ‘pick’ e formas
avançadas ‘context’ e ‘compensate’. O processo de ‘context’ provê um framework
para declarações locais, manipulação de exceções e comportamentos
transacionais. Contextos podem ser usados para delinear o escopo de parte de
um comportamento que tem propriedades de transação. Um exemplo de uma
codificação XLANG está na Figura 10, que demonstra o operador all, que compõe
toda a seqüência de atividades do processo de negócio.:
30
<all>
<sequence>
<!—realizar reserva de avião -->
</sequence>
<sequence>
<!-- realizar reserva de veículo-->
</sequence>
<sequence>
<!—realizar reserva de hotel-->
</sequence>
</all>
FIGURA 10 – EXEMPLO DE CODIFICAÇÃO XLANG
Internamente XLANG sinaliza que um processo de compensação implícito
ou explícito está associado com um contexto, e isso pode ser invocado usando o
processo de compensação. XLANG não informa a respeito de ações de
compensação, mas sobre processos de compensação.
3.6.6 WSFL - Web Service Flow Language A linguagem proposta pela IBM é um dos predecessores de BPEL. É uma
linguagem completa e neutra e está integrada com UDDI e WSDL para seleção
dinâmica de Web Services. WSFL habilita desenvolvedores a criar, executar e
combinar Web Services em complexos processos e fluxos de trabalhos.
Em um ambiente WSFL são inclusos os conceitos de suporte de transação,
informação gráfica de posições, e dados estatísticos. O controle de fluxo em
WSFL é modelado via grafos direcionados.
WSFL por si só não negocia com modelos de processos de negócio;
particularmente é uma especificação de como implementar um modelo de
processo de negócio usando a arquitetura de Web Services. WSFL pode ser
usado para criar uma representação em XML de um modelo de negócio, e então
suprir a representação XML em uma aplicação middleware desenvolvida para
invocar e gerenciar os processos.
Um documento WSFL usa elementos de Metadados como ‘Tipos
Provedores de Serviço’ para identificar as regras dos implementadores de
31
atividades específicas dentro do contexto de um dado modelo de processo de
negócio. O ‘Tipo Provedores de Serviço’ é definido por um documento interface de
Web Service usando WSDL.
Provedores de serviço devem oportunamente implementar a interface de
Web Service apropriada em razão de classificar os tipos apropriados de
provedores de serviço para manipular uma atividade em particular nos processos
de negócios. Cada processo é representado em um modelo XML chamado
modelo de fluxo. O modelo de fluxo é uma definição abstrata do processo de fluxo
de trabalho. O modelo contém elementos ‘Ativos’, que definem atividades que
serão implementadas na forma de um Web Service definido pela WSDL. Ligações
de controle e ligações de dados também são partes do modelo de fluxo. O
primeiro descreve a seqüência de atividades, enquanto que o último define o fluxo
de dados de uma atividade para outra.
Além do modelo de fluxo há um ‘Modelo Global’ que detalha como um dado
processo é implementado. O “modelo global” define a identidade, a locação e a
implementação do provedor de serviço que implementa uma regra específica.
Uma vez que o global e o modelo de fluxo de um dado processo de negócio está
definido, todo o processo de negócio pode ser definido como um único Web
Service, que dever ser usado por outros processos de negócio.
FIGURA 11 – EXEMPLO DE CODIFICAÇÃO WSFL
32
Um exemplo de codificação WSFL se encontra na Figura 11, onde é ilustrada uma
atividade com suas variáveis de entrada e saída bem como chamadas a funções
(no caso, a operação “checar”).
3.6.7 BPEL4WS - Business Process Execution Language for Web Services
A especificação BPEL4WS (ou comumente chamada de BPEL), é um esforço
combinado da IBM e Microsoft. Ela foi construída combinando as características
de WSFL e XLANG, através de blocos de linguagem estruturada herdada de
XLANG com grafos direcionados originário da WSFL.
BPEL é especificada como um formato de trocas somente via esquemas
XML, que é capaz de modelar tarefas como chamadas a Web Services onde as
entradas e as saídas são especificadas por mensagens e os endereços são
identificados via URI (Uniform Resource Identifiers) através de port types WSDL.
SOAP é utilizado como o protocolo de comunicação. A intenção da linguagem é
dar suporte tanto a modelagem de processos executáveis como abstratos.
O fluxo de controle de BPEL pode ser modelado orientado a blocos ou
orientado a grafos, e a manipulação de dados é expressa via variáveis e
operações relacionadas. A identificação de instanciação de processos é
executada via conjuntos de correlações. Regras de processos participantes são
definidas via chamadas a links de parceiros.
Um processo abstrato é um protocolo de negócio que especifica o
comportamento de trocas de mensagens entre diferentes parceiros sem revelar
seu comportamento interno.
Um processo executável especifica a ordem de execução entre um número
de atividades que constituem o processo, os parceiros envolvidos no processo, as
trocas de mensagens entre esses parceiros e as falhas e manipulação de
exceções que especificam o comportamento a ser adotado em casos de erros e
exceções.
O processo BPEL4WS é um tipo de fluxograma, onde cada elemento no
processo é chamado de atividade. Uma atividade pode ser tanto primitiva ou
33
estruturada. O conjunto de atividades primitivas contém: invocações ou chamadas,
as quais são utilizadas para invocar uma operação em algum Web Service;
atividade de receber, que é utilizada para esperar por uma mensagem de uma
fonte externa; atividade de responder, que é usada quando é necessária uma
resposta a uma fonte externa; atividade de esperar, quanto é necessário esperar
por algum tempo; atividade de designar ou atribuir, para copiar dados de um lugar
para outro; atividade de informar, para indicar erros na execução; atividade de
finalização, quando é necessário finalizar toda a instância do serviço; e atividade
de verificação, quando o processo está ocioso.
Algumas atividades estruturadas baseadas em Metadados são definidas
para habilitar a apresentação de estruturas complexas. Elas são: sequence, que é
usada para definir uma ordem de execução; switch, usada para roteamentos
condicionais; while, usado para loopings, pick, para saída de condições baseadas
em tempo ou triggers externas; flow, usada para execução paralela de atividades
para roteamentos paralelos; scope, para agrupamento de atividades a serem
tratadas pelo mesmo manipulador de falhas; e compensate, que é usado para
desfazer os efeitos de atividades já completadas.
Um exemplo da codificação BPEL se encontra na figura 12, onde o
operador sequence determina o fluxo de negócio como um todo; o operador
partner, que indica os parceiros e regras de um processo; container, que
estabelece as entidades para validação do processo; invoke, responsável por
executar um Web Service e reply, que envia uma resposta.
34
FIGURA 12 – EXEMPLO DE CODIFICAÇÃO BPEL4WS
Atividades estruturadas podem ser aninhadas e combinadas de diferentes
maneiras. Atividades internas que são executadas em paralelo o uso dos links
podem facilitar o controle da ordem de execução. Há alguns casos chamados
controle de ligações que permitem a definição de grafos direcionados. Os grafos
podem ser aninhados, mas devem ser acíclicos.
Além disso, BPEL suporta manipulação de erros e falhas bem como
compensações de transações. BPEL pode ser usada para descrever composição
e coreografia de Web Services.
BPEL também faz uso de duas especificações significantes e
complementares, as quais são Coordenação-WS e Transação–WS e foram
também desenvolvidas juntamente por IBM e Microsoft. Eles tratam em como
coordenar a dependência de resultado de curtos e longos processos de negócio. A
Transação-WS especifica um framework que permite que um Web Service
monitore o sucesso ou fracasso de cada atividade individual e coordenada.
<partners> <partner name = “customer” serviceLinkType = “Ins:loanApproveLinkType” myRole=”approver”/> <partner name = “approver” serviceLinkType = “Ins:loanApproveLinkType” partnerRole = “approver”/> </partners> <containers> <container name = “request” messageType=”loandef:CreditInformationMessage”/> <container name = “approvalinfo” messageType=”apns:approvalMessage”/> </containers> <sequence> <receive name = “receive1” partner = ”customer” portType = “apns:loanApprovalPT” operation = “approve” container = “request” createInstance = “yes”> </receive> <invoke name = “invokeapprover” partner = “approver” portType = “apns:loanApprovalPT” operation = “approve” inputContainer = “request” outputContainer = “approvalInfo”></invoke> <reply name=”reply” partner = “customer” portType = “apns:loanApprovalPT” operation = “approve” container= “approvalinfo”></reply> </sequence>
35
Também provê o monitoramento de processos e, de forma confiável, cancelar o
processo em caso de alguma coisa dar errado durante o trajeto da informação. A
especificação de Coordenação-WS por outro lado define um framework pelo qual
os serviços podem trabalhar em um “contexto de coordenação” compartilhado.
Esse contexto contém a informação necessária para conectar várias atividades
conjuntas.
BPEL4WS emprega o conceito de parceiros para modelar diretamente a
colaboração peer-to-peer entre processos de negócio e serviços parceiros. Uma
instância de processo de negócio pode somente ser criada quando uma
mensagem ou evento são recebidos pelo link de parceiros. Os links parceiros
definem as relações estáticas e abstratas com outro parceiro baseados em Web
Services port types utilizados na interação.
O primeiro working draft de BPEL4WS foi lançado em Abril de 2004 pela
OASIS BPEL TC, na qual foi baseada na especificação de BPEL4WS que foi
originalmente desenvolvida juntamente com IBM, Microsoft e BEA em Agosto de
2002, e então posteriormente modificada na v.1.1 em Abril 2003 com participação
adicional da SAP e Siebel Sistemas.
3.6.8 WSCI - Web Service Choreography Interface
WSCI foi desenvolvida juntamente com Sun, SAP, BEA e Intalio em Junho
de 2002, dirigido a descrever uma linguagem de definição de interface para
coreografar o fluxo de mensagens entre Web Services. A linguagem foi concebida
no topo de WSDL que define as operações Web Services envolvidas em
atividades WSCI.
Essa especificação foi a primeira em se tratando de composição de Web
Services baseada em XML que provê um padrão para especificação de toda a
colaboração entre Web Services provedores e usuários de serviços, descrevendo
dessa forma as trocas de mensagens que acontecem entre as partes envolvidas.
WSCI especifica apenas “processos de negócio abstratos” que são
observados entre Web Services modelados. Ações são utilizadas para definir um
36
pedido básico e mensagens de resposta. Serviços externos são invocados através
de chamadas. WSCL também suporta transações e manipulação de exceções.
Os conceitos fundamentais do modelo são a interface de definição,
coreografia de atividades, definição de processos e suas propriedades, correlação
de mensagens, manipulação de exceções, transação, descrição de compensação
e participação dinâmica. Os detalhes do comportamento dos Web Services são
descritos nos processos que estão contidos na interface. Um Web Service pode
expor múltiplas interfaces para suportar múltiplos cenários.
A especificação WSCI endereça a coreografia de Web Services em dois
níveis primários. No primeiro nível, WSCI constrói no topo das port types WSDL
capacidades de descrever o fluxo de mensagens trocadas por um Web Service no
contexto de um processo.
A construção introduzida por WSCI permite a descrição de
“comportamentos observáveis” externamente de um Web Service, facilitando a
expressão de dependências seqüenciais e lógicas de trocas em diferentes
operações em port types WSDL.
As atividades podem ser atômicas representando a unidade básica de
comportamento de um Web Service, como atividades complexas nos quais são
compostas recursivamente de serviços atômicos. WSCI suporta execuções
seqüenciais, paralelas, loopings e execuções condicionais. WSCI suporta a
definição de dois tipos de processos, em outras palavras, Níveis Top e processos
aninhados podem ser referenciados usando-se expressões Call ou Spawn.
Propriedades são introduzidas no WSCI como modelagem de artefatos
usados para referenciar um “valor” dentro da definição da interface. São
equivalentes a variáveis em outras linguagens. Contexto é um conceito WSCI que
descreve o ambiente no qual um conjunto de atividades é executado. Uma
definição de contexto pode conter dois diferentes tipos de declarações:
propriedades locais e definições de processos locais. O conceito de correlação
descreve como as conversações estão estruturadas e quais as propriedades
devem ser trocadas para reter a consistência semântica da conversação. A
37
correlação não está limitada a uma simples conversação entre dois participantes;
ela pode se multiplicar em várias conversações entre diferentes participantes.
A especificação também suporta declarações de comportamentos
excepcionais que são exibidas por um Web Service num dado ponto da
coreografia.
A declaração de comportamentos excepcionais é parte da definição de
contexto. A transação descreve, através de uma perspectiva de interface, as
propriedades transacionais das atividades que são executadas nesse contexto.
Uma transação pode ser tanto atômica como aninhada. WSCI suporta também a
descrição de visões multi-participantes de todo o processo de trocas de
mensagens do Modelo Global WSCI. WSCI também dá suporte a extensibilidade
de construção de linguagens.
Como características adicionais, WSCI incorpora a correlação de trocas
relacionadas, agrupamento de trocas em transações, manipulação de exceções e
aspectos comportamentais dinâmicos de um Web Service.
FIGURA 13 – EXEMPLO DE CODIFICAÇÃO WSCI
Na Figura 13 se encontra um exemplo da codificação WSCI, no qual
apresenta uma operação de recebimento de mensagens por um Web Service,
através da função Receive Order, e a confirmação, através do operador action e
da função Confirm.
WSCI foi submetido ao W3C em Agosto de 2002. A W3C formou um novo
grupo de trabalho chamado Web Services Choreography Working Group dentro
38
das atividades de Web Services, A especificação WSCI é uma das idéias
primárias para a formação de WS-CDL que o W3C está trabalhando atualmente.
3.6.9 WS-CDL - Web Service Choreography Description Language
WS-CDL é uma especificação da W3C cujo principal objetivo é a
interoperabilidade em composições, longas interações e colaboração peer-to-peer
entre os Web Services participantes. A especificação descreve uma visão global
do comportamento de trocas de mensagens de todos os Web Services
participantes que estão envolvidos na colaboração do negócio. WS-CDL é
puramente uma especificação para processos de negócio abstratos, independente
de plataforma e linguagens de programação que são utilizadas para implementar a
participação dos Web Services.
Os modelos WS-CDL na colaboração peer-to-peer entre participantes com
diferentes regras utilizam coreografia. A coreografia faz uso de interações e
notações de atividades para definir os relacionamentos, que representam as
trocas de mensagens entre dois Web Services participantes descritos em WSDL.
A coreografia suporta exceções e compensações com Exception Block e
Finalizer Block. As mensagens que são trocadas entre os participantes são
modeladas com variáveis e tokens, onde tipos podem ser especificados em XML
Schema ou WSDL. Canais são utilizados para especificar como e onde as trocas
de mensagens podem ter lugar. Atividades realizam o trabalho de interação com
os operadores de interação, bem como os resultados nas trocas de mensagens.
Operadores Perform invocam outras coreografias, e Assigns associam os valores
as variáveis. Control são estruturas que modelam atividades combinadas simples,
incluindo Sequence, Parallel e Choice. A sincronização entre atividades pode ser
ativada via WorkUnit, que define a condição que deve ser satisfeita para a
atividade ter progresso. A Figura 14 apresenta um exemplo de um trecho de
codificação em WS-CDL, onde é apresentado o operador de seqüência, as suas
operações e os relacionamentos participantes.
39
FIGURA 14 – EXEMPLO DE CODIFICAÇÃO WS-CDL
O primeiro working draft da especificação WS-CDL foi lançado em Abril de
2004. A situação atual do padrão é “Candidato a Recomendação”, com sugestões
a serem enviadas até 31 de Março de 2006 para a W3C.
40
4 Estudo de Caso e Análise
4.1 Exemplo de um Processo interorganizacional
O processo a ser analisado ilustra vários aspectos dos relacionamentos
entre coreografias externas e orquestrações internas dos parceiros da
colaboração. As linguagens de composição escolhidas para a análise deste caso
são WS-CDL e BPEL4WS, por serem standards mais recentes e em constante
processo de atualização e evolução. A codificação em BPEL4WS foi feita com o
estudo da ferramenta ORACLE BPEL Process Manager, e a codificação em WS-
CDL foi realizada de acordo com especificação própria, pois a linguagem ainda
não possui interface gráfica.
O exemplo utilizado é um cenário de workflow chamado de “Coleta de
Taxas Municipais” que descreve um Web Services com uma interação entre três
participantes: o pagador(Cliente), o agente de negócio ou administrador de taxas
(o responsável pela coleta das taxas) e o provedor público de serviços (o poder
local).
De acordo com o processo tradicional, as empresas estão sujeitas as taxas
municipais, e as mesmas devem enviar uma situação anual via responsável para o
poder público, que é o responsável por coletar as taxas. O município checa a
declaração de estado anual das empresas, calcula as taxas e retorna uma
avaliação ao responsável.
Neste caso os administradores públicos concordaram em implementar um
novo serviço online, no qual oferecem ao público e companhias a submissão de
seus status e informações para as tarifas anuais via internet. Devido a várias
considerações legais, o processo deve ser realizado de uma maneira peer-to-peer
e deve integrar requerimentos de segurança como integridade, confidencialidade e
não repudiação.
De uma forma bastante condensada são apresentados os passos chave
que descrevem os fundamentos da colaboração de como a se chegar nos
objetivos comuns do negócio:
41
1) O cliente envia seu estado anual ao administrador público;
2) O administrador checa a informação para validação e completude e
rejeita a documentação em algum caso onde alguma informação chave esteja
ausente e notifica o Cliente. Nesse caso o cliente complementará a informação e
reenviará o documento;
3) O administrador realiza algumas complementações para o
processamento do documento (por exemplo, formatação, complementar dados
legais, etc);
4) O administrador encaminha o processo de situação anual do seu
Cliente para o poder público e envia a ele uma confirmação de aceitação;
5) O município calcula os impostos;
6) O município retorna o valor dos tributos a administrador de taxas;
7) O administrador processa a avaliação do município;
8) O administrador informa seu cliente sobre as taxas resultantes.
A Figura 15 mostra o modelo da coreografia como um Diagrama de
Atividades UML. Ele descreve a colaboração de três serviços em termos das
interações no qual os participantes estão envolvidos. A informação do modelo está
delimitada para os comportamentos da colaboração, correspondendo assim ao
fluxo de mensagens entre os participantes, a interação lógica – ou as interfaces
requeridas que são chamadas pelos participantes – e o fluxo de controle entre as
ações como o envio ou recebimento das interações resultantes em mensagens
enviadas de um dos participantes para outro.
42
Cliente Administrador de Taxas Município
FIGURA 15 – DIAGRAMA DE ATIVIDADES – COLETA DE TAXAS MUNICIPAIS
Enviar Situação Anual
Receber Situação Anual
Checar Situação Anual
SA
Receber Rejeição
Receber Confirmação de Aceitação
Receber Pedido de Taxa Processada
Enviar Rejeição
[Dados incompletos] [Dados Completos]
Enviar Confirmação de Aceitação
Enviar Situação Anual Processada
Receber Situação Anual Processada
Enviar Pedido de Cobrança de Taxa
Receber Pedido de Taxa
Enviar Pedido de Taxa Processada
R
A
PTP
PT
SA
43
4.2 Implementação WS-CDL da Coleta de Taxas Municipais
WS-CDL é uma linguagem declarativa em XML para a especificação de
protocolos de colaboração baseados em Web Services. Esta especificação prevê
uma visão global ou pública dos participantes de uma colaboração em um modelo
peer-to-peer de Web Services distribuídos de forma a se chegar em um objetivo
comum no negócio. O protocolo descreve seus comportamentos através de
mensagens que são trocadas bem como as operações que são oferecidas.
Levando em consideração o exemplo da “Coleta de Taxas Municipais”, a
codificação abaixo mostra duas partes de um documento WS-CDL: a informação
de pacotes e a definição de coreografia, conceitos cuja definição se encontra
abaixo.
Definição do Processo em WS-CDL Informação do Pacote 1 <package name="ServicodeSituacaoAnual" ...> 2 <informationType 3 name="correlationId" 4 type="string"/> 5 <informationType 6 name="SituacaoAnual " 7 type="SituacaoAnual.xsd"/> … 8 <roleType name="RegrasServicoProvedor"> 9 <behavior name="ReceberSituacaoAnual " 10 interface="AdministradordeTaxa.wsdl"/> 11 </roleType> 12 <roleType name="RegrasServicoRequisitor"> 13 <behavior name="ReceberPedidodeTaxa" 14 interface="AdministradordeTaxa.wsdl"/> 15 </roleType> … 16 <relationshipType name ="AdministradorTaxasCliente"> 17 <role type="RegraCliente" /> 18 <role type="RegraServicoProvedor "/> 19 </relationshipType > … 20 <participantType name ="AdministradordeTaxa"> 21 <role type="RegradoServicoProvedor "/>
44
22 <role type="RegradoServicoRequisitor "/> 23 </participantType> ... 24 <channelType 25 name="SubmeterSituacaoAnualdeTaxa " 26 action="request "> 27 <passing 28 action= "respond" 29 channel= " SubmeterSituacaoAnualdeTaxaProcessada "/> 30 <reference> 31 <token name="taxAdvisorRef"/> 32 </reference > 33 <identity> 34 <token name="processId"/> 45 </identity> 36 </channelType> ... 37 <choreography > ...</choreography > 38 </package> Definição de Coreografia 1 <choreography name="SubmissaodeSituacaoAtual " 2 root="true"> 3 <relationship type="tns:AdministradorTaxasCliente"/> 4 <relationship type="tns:MunicipioTaxasCliente "/> ... 5 <variableDefinitions > 6 <variable name= "AS" 7 mutable= "true" 8 free= "false" 9 informationType = "SituacaoAnual " 10 silent= "false"/> 11 roleTypes =“Cliente, AdministradordeTaxas^“ ... 12 </variableDefinitions > 13 <sequence> 14 <interaction name="SubmissaoSituacaoAnual " 15 channelVariable ="tns:SubmeterSituacaoAnual " 16 operation ="ReceberSituacaoAnual " initiate="true"> 17 <participate relationshipType =" AdministradorTaxasCliente" 18 fromRole="tns:RegraCliente" 19 toRole="RegraServicoProvedor "/> 20 <exchange name = "EnvioeTrocadeSituacaoAnual "
45
21 action= "request" 22 informationType = "SituacaoAnual " > 23 <send variable = "AS"/> 24 <receive variable= "AS"/> 25 </exchange> 26 </interaction> … 27 </sequence> ...
28 </choreography >
Informação de Pacotes: O elemento pacote é a raiz de toda a definição de
coreografia e contém definições de informationType para as mensagens e
variáveis, por exemplo, o documento “SituacaoAnual” enviado do Cliente para o
Administrador de Taxas (linhas 5 a 7), que processa instâncias de dados
correlacionados (linhas 2-4). Esses tipos de dados são utilizados dentro da parte
da definição da coreografia. Um roleType representa um ator da colaboração
como a “RegrasdeProvedordeServico” nas linhas 8-11. Esse elemento associa
nomes de operações a suas respectivas interfaces WSDL via elemento behavior
(comportamento). Por exemplo, a “RegrasdeProvedordeServico” é esperada para
implementar a operação “ReceberSituacaoAnual”, o qual é especificada no
arquivo WSDL correspondente.
O elemento relationshipType casa duas regras e opcionalmente um
subconjunto do comportamento que eles exibem. Por exemplo, o relationshipType
“AdministradorTaxaCliente” associa uma “RegraCliente” para uma
“RegraServicoProvedor”, que por sua vez é uma das duas regras onde um
“AdministradordeTaxas” é esperado para a implementação (linhas 16 a 19).
Um participantType representa um grupo lógico de regras. Por exemplo, o
participantType “AdministradordeTaxa” implementa duas regras: de um lado o
“RegrasdeProvedordeServiço” e do outro lado o “RegrasdoRequisitordoServiço”.
Um channelType indica a regra que um recebedor de uma mensagem que está
sendo executada e opcionalmente quais comportamentos são esperados para a
implementação: o channelType “SubmeteSituacaoAnual” especifica um canal de
46
retorno para respostas para a submissão de um documento (linhas 24-26).
Finalmente, cada pacote contém uma ou mais definições de coreografia (linha 37).
Definição de Coreografia: O centro de uma colaboração é definido pelo
elemento choreography. Ele especifica um conjunto de interações peer-to-peer.
Um pacote pode conter uma ou mais coreografias, uma é declarada como a
coreografia raiz (linhas 1-2). A coreografia em primeiro lugar especifica os
relacionamentos. Neste caso existem dois relacionamentos: um entre um
Administrador de Taxas e seu Cliente, e outro entre o Administrador de Taxas e o
Município (linhas 3-4). Em segundo lugar, as variáveis são declaradas, por
exemplo, a variável “AS” do tipo “SituacaoAnual” somente será usada pela
“RegradoCliente” e a “RegradoServicoProvedor”.
O elemento interaction é ao bloco básico de construção da comunicação.
Ele participa em um relationshipType e especifica a direção do fluxo de mensagem
em um padrão de interação: a mensagem flui do remetente(especificado pelo
FromRole) para o destinatário (ToRole) se o atributo action do elemento exchange
estiver atribuído para request. O elemento exchange também captura o nome da
operação associada com essa interação. Elementos de interação podem ser
aninhados internamente por atividades de controle de fluxo (por exemplo, linhas
13-27).
47
4.3 Implementação BPEL4WS da Coleta de Taxas Municipais.
A codificação abaixo mostra um exemplo de um processo BPEL para um
dos participantes da coreografia. Com o intuito de implementar essa parte da
coreografia, o Administrador de Taxas orquestra a seqüência de chamadas para
serviços internos e externos através de um processo BPEL chamado
“ProcessoAdministradorTaxas”.
Definição do Processo em BPEL 1 <process name="ProcessoAdministradorTaxas" …> 2 <partnerLinks > 3 <partnerLink name="SubmissaoSituacaoAnual " 4 myRole="RegradoProvedordeServico" partnerRole ="RegraCliente"/> 5 partnerLinkType =“SubmissaoSituacaoAnual “ ... 6 </partnerLinks > 7 <partners > 8 <partner name ="RegraCliente"> 9 </partner > 10 <partner name ="RegraServicoProvedor "> … 11 </partners > 12 <variables > 13 <variable name="AS" messageType="SituacaoAnual"/> …. 14 </variables> 15 <sequence name ="1st level"> 16 <receive name="ReceberSituacaoAnual" 17 partnerLink ="SubmeterSituacaoAnual " 18 portType="PTReceberSituacaoAnual" 19 operation="ReceberSituacaoAnual " 20 variable="AS" createInstance="yes"> 21 <correlations > 22 <correlation set="tax:processId" initiate="yes"/> 23 </correlations > 24 </receive> 25 <invoke name="ChecarSituacaoAnualLocal " 26 partnerLink="Local" operation ="ChecarSituacaoAnual "
48
27 inputVariable="CheckASLocalVar"> 28 <correlations > 29 <correlation set="tax:processId" initiate="yes"/> 30 </correlations > 31 </invoke> ... 32 </sequence> 33 </process>
A composição dos serviços orquestrados é oferecida através de uma
interface de acordo com a especificação da coreografia. Um partnerLink define
partes internas e externas (myRole e partnerrole) que interagem com as instâncias
do processo e os port types que são necessitam ser implementados (linhas 2-6).
Um partnerLinkType é uma extensão BPEL, o qual é utilizada na definição
WSDL. Ela define duas regras de uma troca bilateral de mensagens e suas port
types.
Um elemento partner (linhas 7-9) pode ser utilizado para agrupar múltiplos
partnerLinks.
Variables (12-14) descrevem os tipos de mensagens utilizadas em um
processo BPEL. Uma variable é identificada por um único nome e está associado
com um tipo de mensagem.
Variáveis armazenam mensagens recebidas e gerenciam mensagens a
serem enviadas para outras partes. Um processo BPEL descreve a ordem de
execução das operações Web Services via atividades básicas e estruturadas. Um
exemplo de atividade é o receive (17-25). A atividade bloqueia o processo até a
mensagem correta chegar. Invocações de operações de web service remotos são
modelados como atividades invoke. As linhas 26-32 ilustram uma invocação one-
way assíncrona, isto é, apenas uma variável de entrada, mas nenhuma variável de
saída é declarada. Interações de pedido/resposta síncronas podem ser expressas
incluindo uma variável de saída para armazenar a sincronia da mensagem de
resposta enviada.
O controle de fluxo lógico de um processo BPEL é definido através de
atividades estruturadas. No exemplo é utilizado um sequence para a execução
seqüencial. Um correlationSet descreve partes das mensagens que são únicas
49
para uma instância do processo. Os apelidos para essas partes das mensagens
são chamados de propriedades.
4.4 Características de Comparação dos Padrões de Linguagens de Composição As linguagens de composição para especificações de Web Services têm um
importante papel na habilitação de serviços dinâmicos e composição por usuários
e agentes de software.
De acordo com as características apresentadas e descritas na Seção 3.6,
existem várias linguagens de composição, propostas por pesquisas acadêmicas e
grupos industriais para descrição de serviços, composição, execução e
interpretação com XML sendo a base para a tecnologia de composição de Web
Services.
Algumas das linguagens de composição para Web Services possuem
semânticas bem definidas, outras são baseadas em padrões de fluxo de trabalho,
enquanto algumas são a combinação de outras linguagens independentes.
Esta seção apresenta as características das linguagens para composição
de serviços de Web Services (também chamada de linguagens de execução de
Web Services ou ainda linguagens de Orquestração de Web Services) e a lista de
especificações comuns a todas as linguagens.
Outra motivação para este trabalho é não só mostrar uma comparação
entre as linguagens, mais ainda ressaltar os pontos fortes e fracos de cada
implementação.
Através de uma análise das especificações obteve-se uma lista com 13
conceitos de alto nível comuns as linguagens de composição relacionados a
metamodelos(modelo de representação de dados/Metadados de cada linguagem,
ou seja, a sua especificação propriamente dita):
1 –Tarefas de Entrada e Saída – Utiliza-se o termo tarefa para referenciar
as unidades básicas de trabalho em como os relacionamentos lógicos e temporais
são modelados em um processo. As entradas e saídas dessas tarefas podem ser
modeladas usando tipos XML simples ou complexos.
50
2 – Endereço das Tarefas – O endereço especifica onde ou como um
serviço pode ser localizado para realizar uma tarefa. O endereço pode ser
modelado diretamente via uma referência de serviço ou indiretamente via uma
consulta que identifica um endereço de serviço.
3 – Atributos de Qualidade – Quando um conjunto de serviços potenciais
são gerados por uma consulta, os atributos de qualidade podem ser utilizados
para identificar o melhor serviço.
4 – Protocolo de tarefas – O protocolo define um conjunto de convenções
para controlar as interações com um serviço realizando uma tarefa. Web Services
utilizam SOAP como esse protocolo.
5 – Controle de Fluxo – O controle de fluxo define os relacionamentos
temporais e lógicos entre diferentes tarefas. O fluxo de controle pode ser
especificado via grafos direcionados, blocos aninhados de instruções de controle
ou processos de álgebra.
6 – Manipulação de Dados – especifica quais variáveis serão utilizadas em
uma instância de um processo e como os valores atuais dessas variáveis serão
calculados.
7 – Identidade de instâncias – Esse conceito endereça como uma instância
de um processo e as mensagens relacionadas são identificadas. A correlação
utiliza um conjunto de elementos de mensagem que são únicos para uma
instância de um processo para rotear as mensagens para instâncias de processos.
A geração de um identificador único que é incluído nas trocas de mensagens pode
ser uma abordagem alternativa.
51
8 – Regras – As regras provém de uma abstração dos participantes em um
processo. Regras são assinaladas para tarefas e usuários para regras. Um
mecanismo de resolução pode alocar tarefas de um processo instanciado para
usuários.
9 – Eventos – Eventos representam mudanças no mundo real. Eventos
manipuladores fornecem os meios para responder a eles através de uma forma
predefinida.
10 – Exceções – exceções ou faltas são erros durante a execução de um
processo. Em caso de exceções dedicadas manipuladores de exceções irão
desfazer tarefas com insucesso ou terminar a instância do processo.
11 – Transações – transações ACID definem um conjunto de operações
que tem semântica do “tudo ou nada”. Eles têm que efetuar rollbacks quando uma
operação parcial falha. Transações de Negócio representam transações de longa
duração. Em caso de falha os efeitos de uma transação de negócio devem ser
apagadas por um processo de compensação.
12 - Apresentação Gráfica – A representação gráfica de um modelo de
processo de negócio contribui para a sua compreensibilidade. Os anexos de uma
representação gráfica pode ser uma parte explícita do metamodelo.
13 – Dados estatísticos: Análise de Performance de um processo de
negócio em dados estatísticos como custo de duração das tarefas.
Os 13 conceitos ainda possuem formatos que são utilizados em pelo menos
quatro áreas de aplicação:
52
Composição: Refere-se a definição da implementação interna de processos
executáveis de negócio. Composição de Web Services definem processos de
negócio executáveis que são construídos por um conjunto de Web Services.
Coreografia: Define externamente o comportamento de um processo de
negócio. A coreografia de Web Services se refere ao correto contento e ordem de
mensagens de trocas de duas partes em um processo de negócio.
Análise de Negócio: Análise de Negócio se refere a apresentação de
processos de negócio a gerentes. É construído na visualização de processos e
anotações com estatísticas.
Análise Formal: Refere-se a verificação de diferenças formais de critérios
de qualidade. Como exemplo, pode-se citar a característica “prazo de validade”.
Recentemente, a modelagem de processos de negócio vêm se tornando
assunto de várias especificações e esforços de padronização. Diferentes
consórcios incluindo a OMG(Object Management Group), OASIS(Organization for
the Advancement of Structured Information Standards), BPMI(Business Process
Management Initiative, UM/CEFACT (United Nation Centre for Trade Facilitation
and Electronic Business), W3C (World Wide Web Consortium), e a WfMC
(Workflow Management Coalition), e também instituições comerciais e grupos
acadêmicos já tem ou irão propor metamodelos e formatos para a modelagem de
processos de negócio.
Dessa forma as 13 características comuns ao estudo de cada linguagem
apresentadas na descrição acima foram estudadas, sugerindo assim informações
que possam contribuir para um processo de padronização das linguagens de
composição explanadas, sejam na forma de salientar características com
comportamentos ideais bem como a sugestão de uma nova linguagem de
composição para Web Services.
53
4.5 Resultados Obtidos na Análise dos Padrões de Linguagens de Composição
De acordo com as especificações de cada linguagem e análise das
características apresentadas na seção anterior é apresentado um quadro
comparativo das linguagens de composição analisadas, onde um “Sim” indica que
a linguagem suporta a característica apresentada, e o “X” indica que a linguagem
não suporta a característica analisada.
WSFL XLANG WSCI BPML BPEL4WS WS-CDL
Tarefas de Entrada e Saída Sim Sim Sim Sim Sim Sim
Endereço das Tarefas Sim Sim Sim Sim Sim Sim
Atributos de Qualidade Sim X X X X X
Protocolos de Tarefas Sim Sim Sim X Sim Sim
Controle de Fluxo Sim Sim Sim Sim Sim Sim
Manipulação de Dados Sim X X Sim Sim Sim
Identidade de Instâncias Sim Sim Sim Sim Sim X
Regras Sim Sim Sim Sim Sim Sim
Eventos Sim Sim X Sim Sim X
Exceções Sim Sim Sim Sim Sim Sim
Transações X Sim Sim Sim Sim Sim
Apresentação Gráfica X X X X X X
Dados Estatísticos X X X X X X
TABELA 4 – COMPARAÇÃO DAS LINGUAGENS DE COMPOSIÇÃO
Tendo em vista as informações acima apresentadas e o estudo formal de
cada linguagem, observa-se que as linguagens WS-CDL, BPML e BPEL4WS são
as únicas que possuem um mínimo de evolução ao longo dos últimos anos (de
acordo com a Figura 8). Por essa razão, um resultado mais aprofundado dessas
linguagens é apresentado.
WS-CDL provê mecanismos suficientes para modelar comportamentos de
trocas de mensagens, BPML facilita a modelagem de execução de processos
enquanto BPEL4WS se atém a cobrir ambos os aspectos. BPML possui uma
54
semântica mais abrangente às necessidades de suporte às empresas,
principalmente em se tratando de aplicações de integração, enquanto WS-CDL é
mais natural para modelagem de colaborações business-to-business.
A colaboração peer-to-peer é uma característica essencial que precisa ser
modelada. Tanto BPEL4WS como WS-CDL modelam a colaboração em notações
de interações entre serviços descritos em WSDL.
WS-CDL possui alternativas mais flexíveis para representar regras que
parceiros pretendam utilizar, enquanto BPEL4WS facilita a ligação de processos
de colaboração para privar os processos via padrões de recebimento e resposta.
Colaborações de negócio requerem o estabelecimento e aplicação de
acordos para a qualidade dos serviços, porém todas as linguagens analisadas não
endereçam isso.
Todas as especificações suportam a parte imperativa de composição de
serviços, que inclui a manipulação de exceções, compensação, estados de
contexto e todas as capacidades para compor estruturas mais complexas e
atividades. As estruturas de controle dessas linguagens são suficientes o bastante
para modelar seqüências, paralelos, sincronização, escolhas exclusivas e
escolhas simples, enquanto que BPEL4WS tem a capacidade de modelar
escolhas múltiplas e merges de sincronização. BPEL4WS tem mais poder
semântico em manipulação de eventos que BPML. Em transações e suporte a
alinhamentos de estados, WS-CDL está à frente de BPEL4WS.
Questões de segurança e mensagens confiáveis não são bem manipuladas
em todas essas linguagens embora WS-CDL e BPEL4WS possuem algumas
estruturas de controle para tais finalidades. O suporte a representações
semânticas e a descrição não está presente, com exceção de um suporte simples
de WS-CDL em descrições textuais ou referências a documentos para propósitos
de documentação.
Em se tratando de ferramentas de desenvolvimento, BPEL4WS tem um
maior suporte da indústria. Os maiores fabricantes de software aliaram BPEL4WS
em seus produtos, incluindo IBM, Microsoft, SeeBeyound, Intalio, Popkin,
FiveSight, Collaxa e Proforma. BPWS4J da IBM é a engine que executa os scripts
55
da linguagem. A Microsoft construiu o BPEL4WS suport para o Biztalk Server
2004 e a Oracle possui suporte ao BPEL4WS através de módulos em sua suíte de
desenvolvimento - Oracle BPEL Process Manager, que utiliza a ferramenta
JDeveloper. Alguns produtos suportam BPML e são encontrados em alguns
produtores de software como a InfoSys.
O fato é que existe mais suporte no mercado para BPEL4WS. Atualmente
não há suporte para WS-CDL, e ainda não está claro se o mercado aceitará o WS-
CDL. Contudo, essa é uma alternativa dirigida pelo W3C agora, que pode emergir
num futuro proeminente.
O estudo comparativo mostra que BPEL4WS, BPML e WS-CDL se
sobrepõem em muitos aspectos. BPEL4WS é mais expressivo e completo se
comparado a BPML, especialmente no aspecto de modelagem de colaboração. A
modelagem de processos de negócio com Web Services no aspecto de
colaboração de negócio e ligação com processos internos executáveis vem se
tornando o foco principal. Por razões históricas de desenvolvimento de padrões os
grandes produtores de software vêm atuando de acordo com os seus produtos,
onde complexidades desnecessárias existem e semânticas incompletas precisam
se tornar claras.
A ausência na promoção de desenvolvimentos relacionados ao BPML
desde 2002 e o desvio dos maiores suportes de desenvolvimento do BPML para o
campo do BPEL4WS, tem tornado este último mais promissor. BPEL4WS também
cobre a modelagem de comportamentos de trocas de mensagens, chamados
“protocolos de negócio”, que também é domínio para WS-CDL.
É difícil prever se a convergência da composição de Web Services
acarretará em uma linguagem única e padronizada. Isso acontece devido
principalmente as diferentes escolas de pensamento das produtoras de software.
A grande carência de definições formais e semânticas de estruturas das
linguagens também atrasa esse processo. A continuidade da padronização pode
conduzir a alguns níveis de convergência nos conceitos atrás dos padrões. Com a
maturidade dos padrões, cada vez mais as ferramentas de software estão
incorporando novas atividades para a execução de processos.
56
É interessante notar particularmente o desenvolvimento tanto de BPEL4WS
como de WS-CDL, pois eles foram especificados por duas grandes organizações
de padronização – OASIS e W3C, respectivamente. O suporte dos fornecedores
não pode ser negligenciado pela influência e formação de padrões abertos.
No mundo acadêmico, a pesquisa em composição de Web Services está
focada na descoberta e composição de Web Services automatizados e dinâmicos.
É esperado então que o trabalho em Web Services semânticos auxiliará na
criação de um framework de composição para a composição de processos de
negócio baseados em Web Services.
57
5 Conclusões e Trabalhos Futuros
Este trabalho procurou levantar os principais esforços existentes na área de
tratamento da composição de serviços em sistemas baseados em linguagens para
Web Services.
Os Web Services se tornarão em pouco tempo ferramentas consideradas
indispensáveis em novas aplicações, principalmente aquelas em que existam
implementações complexas para validação e recuperação das informações, a fim
de aumentar a agilidade e segurança dos dados e diminuir a intervenção do ser
humano.
Embora de forma bastante condensada, foi demonstrado o estado da arte
relacionado à questão dos protocolos já padronizados na arquitetura de Web
Services, assim como o levantamento das questões relacionadas à composição
de serviços e um panorama das principais linguagens de composição ao longo do
tempo.
Enquanto ainda há um longo caminho a ser alcançado para se estabelecer
um padrão de um protocolo para a composição de Web Services, os usuários e os
analistas de sistemas têm que escolher uma linguagem apropriada que vai de
encontro aos seus objetivos de negócio sem esperar por padronizações maduras.
Os usuários estão em face de um desconhecimento das capacidades de vários
padrões e ferramentas disponíveis para composição de Web Services. Um dos
propósitos deste trabalho foi discutir as várias padronizações para auxiliar as
diversas entidades na compreensão das linguagens.
Supondo que o mercado adote uma realidade onde a maioria das
linguagens a serem analisadas se tornem padrões a serem estabelecidos. De
acordo com tal afirmação, isto acarretaria uma perspectiva onde serviços
independentes estariam sendo descritos em diferentes linguagens.
Um dos problemas que vêm à tona em conseqüência disto seria a
interoperabilidade entre os agentes de software tentando compor serviços de
composição diferentes, onde seriam necessários, por exemplo, ontologias para se
estabelecerem mapeamentos entre essas linguagens. Frente a esse possível
58
cenário, é necessário estabelecer uma alternativa para a padronização das
linguagens de descrição e composição de Web Services.
Com o surgimento dessa variedade de linguagens, onde cada uma se
propõe a ser o padrão, se tornou necessário a avaliação de tais linguagens e uma
análise crítica dos méritos e deméritos das mesmas, com o intuito de facilitar o
entendimento e aumentar um possível escopo que leve a uma linguagem
padronizada e universal de composição para Web Services, além de enfatizar as
principais características de tais linguagens.
Dessa forma, chega-se como resultado que as linguagens WS-CDL e
BPEL4WS estão em vantagem na disputa das ferramentas de desenvolvimento
para Web Services, pois são standards que estão em constante atualização, com
vantagem para BPEL devido, sobretudo, por este estar presente no mercado
sendo utilizado em muitas suítes de desenvolvimento, por apresentar a maioria
das características pesquisadas e a ausência de uma especificação mais
elaborada por parte da W3C.
Sendo assim acredita-se que foi imprescindível uma análise aprofundada
das linguagens de composição para Web Services, contribuindo também para um
melhor tratamento dos Metadados relacionados ao trâmite de dados na Web e
gerando, conseqüentemente, maior rapidez e qualidade no fluxo das informações.
Este trabalho pretendeu se tornar um ponto de partida para futuros desafios
que pretendam usufruir das arquiteturas aqui apresentadas, seja na
implementação de protótipos, a criação de uma nova linguagem utilizando as
principais características expostas ou até mesmo na criação de novas extensões
para as linguagens de composição de Web Services existentes.
59
Referências
[1] Borden, R. The metadata interchange specification. Disponível em:
<http://www.tdan.com/i001fe11.htm>. Acesso em: Março. 2005.
[2] Business Rules Group. What is a Business Rule?. Disponível em:
<http://www.businessrulesgroup.org/brgdefn.htm>. Acesso em: Março 2005.
[3] Computerwire. What is metadata? Disponível em:
<http://it.civil.auc.dk/it/education/thesis/broendsted_larsen_2002/html/metadatadefi
nitioner/computerwire.html>. Acesso em: Março 2005
2000.
[4] Ikematu, R.S. A Importância De Um Repositório De Metadados Para A
Celepar. CURITIBA: FESP, 2001.
[5] Heb, A; Kushmerick, N. Learning to Attach Semantic Metadata to Web
Services. Computer Science Department, University College Dublin, Ireland.
[6] Mendling, J. Metadata Relationships for the Comparison of BPML and
BPEL4WS. University of Trier, Business Information Systems, Germany.
[7] Mendling, J; Müller, M. A Comparison of BPML and BPEL4WS. Universität
Trier, D-54286 Trier, Germany.
[8] BPEL4WS(2005) Disponível em <http://dev2dev.bea.com/technologies/Web
Services/BPEL4WS.jsp>. Arquivo consultado em Janeiro 2005.
60
[9] BPEL4WS(2005) Disponível em < http://www-
106.ibm.com/developerworks/Web Services/library/ws-bpel/>. Arquivo consultado
em Janeiro 2005.
[10] Wohed, P; M.P. Van der Aalst, W; Dumas, M. Analysis of Web Services
Composition
Languages: The Case of BPEL4WS
[11] Lazovik, A; Aiello, M; Papazoglou, M. Planning and monitoring the
execution of web service requests. Department of Information and
Telecommunication Technologies
University of Trento
[12] Woodman, S.J.; Palmer, D.J.; Shrivastava, S.K.; Wheater, S.M. Notations for
the Specification and Verification of Composite Web Services. School of
Computing Science,
University of Newcastle. June 2004. Technical Report Series
[13] M.P. Van der Aalst; Dumas, M. Web Service Composition Languages: Old
Wine in New Bottles?. Department of Technology Management Eindhoven
University of Technology, Centre for Information Technology Innovation
Queensland University of Technology
[14] Benatallah, B; Casasti, F; Toumani, F.; Hamadi, R. Conceptual Modeling of
Web Service Conversations. Intelligent Enterprise Technologies Laboratory
HP Laboratories Palo Alto. March 27th , 2003*
[15] Srivastava, S.; Koehler, J. Web Service Composition - Current Solutions
and Open Problem. IBM India Research Laboratory, IBM Zurich Research
Laboratory
61
[16] Maciel Pereira, D. Uso do XML na Representação de Processos.
Universidade Federal do Rio de Janeiro – IM-DCC/NCE, Dezembro de 2002
[17] Shapiro, R. A Comparison of XPDL, BPML and BPEL4WS, Cape Visions.
[18] J. Feijó Lopes, C; Carlos Ramalho, J. Web Services: Metodologias de
Desenvolvimento, Fevereiro de 2004.
Chandrasekaran, S.; A. Miller, J; S. Silver, G; Arpinar, B; P. Sheth, A.
Composition, Performance Analysis and Simulation of Web Services.
Department of Computer Science/LSDIS Lab The University of Georgia .
[19] Leymann, F.; Web Services Flow Language (WSFL 1.0). Member IBM
Academy of Technology IBM Software Group.
[20] M.P. Van der Aalst; Dumas, M.; H.M. ter Hofstede, A; Wohed, P. Pattern
Based Analysis of BPML (and WSCI)
[21] Ukoln Metadata Group. An overview of resource description issues.
Disponível em: <http://www.ukoln.ac.uk/metadata/desire/overview/rev_01.htm>.
Acesso em: Dez. 2004.
[22] Inmon, William H. Enterprise meta data. DM Review Magazine, v. 8, n. 10,
Nov.
1998. Disponível em: <http://www.dmreview.com/master.cfm?NavID=1>.
Acesso em: Dez. 2004.
[23] Marco, David. Building and managing the meta data repository – a full
lifecycle
guide. New York: J. Wiley & Sons, 2000.
62
[24] Souza, Terezinha B. et al. Metadados: catalogando dados na internet.
Disponível
em: <http://www.puccamp.br/~biblio/tbsouza92.html>. Acesso em: Jan. 2005.
[25] Moriarty, Terry. A metadata management how-to. Disponível em:
<http://www.inastrol.com/Articles/9702.htm>. Acesso em: Fev. 2005.
[26] World Wide Web Consortium ( W3C ) – XML. Disponível em:
http://www.w3.org/XML/. Acessado em Fevereiro/2005
[27] Object Management Group ( OMG ) - XML Technology. Disponível em:
http://www.omg.org/technology/xml/index.htm. Acessado em Fevereiro/2005
[28] Becker, A. K. e Sobral, D. B. C. J. B. S. Web Services e XML - Um Novo
Paradigma da Computação Distribuída - Universidade Federal de Santa
Catarina
[29] <http//:www.develop.com/downloads/Web ServicesLGFLN.pdf>. Disponível na
Internet em 01/8/2003
[30] SZYPERSKI, C. Component software : beyond object-oriented programming.
New York : Addison-Wesley, 1998.
[31] Sametinger, J. Software Engineering with Reusable Components.
Springer-Verlag, 1997
63
Anexos
A. Exemplo de uso dos Web Services
Este capítulo apresenta um exemplo que converte graus Celsius em
Fahrenheit. Foi desenvolvido utilizando a plataforma Visual Studio.
A.1. Código
O código apresentado abaixo possui um método que recebe o valor, que é
utilizado no cálculo e retorna o valor em XML que será utilizado na exibição no
browser do usuário.
<%@ WebService Language="VB" Class="MathService" %>
Imports System
Imports System.Web.Services
Public Class MathService : Inherits WebService
<WebMethod()> Public Function Conversao(a As Integer) As Integer
Return((a -32) * 5) / 9
End Function
End Class
A.2. Resultado final em XML
O resultado ao se consumir um WebService, é o retorno ao brownser do
resultado, sempre em formato XML, o qual é interpretado e exibido para o usuário.
A.2.1. Url que chama o WebService
Url que informa o valor do parâmetro A, para o arquivo conversão.asmx,
passando 50 como valor.
HTTP://localhost:8081/conversao.asmx/Conversao?a=50
64
A.2.2. Retorno em XML
Este é o código enviado em formato XML para o brownser do usuário, o qual
interpreta e mostra o resultado na tela.
<?xml version="1.0" encoding="utf-8" ?>
<int xmlns="HTTP://tempuri.org/">10</int>
A.3. Arquivo de publicação – WSDL
Este é o arquivo de publicação dos Web Services, para facilitar a sua
localização.
<?xml version="1.0" encoding="utf-8" ?>
- <definitions xmlns:HTTP="HTTP://schemas.xmlsoap.org/wsdl/HTTP/"
xmlns:soap="HTTP://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="HTTP://www.w3.org/2001/XMLSchema"
xmlns:s0="HTTP://tempuri.org/"
xmlns:soapenc="HTTP://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="HTTP://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="HTTP://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="HTTP://tempuri.org/"
xmlns="HTTP://schemas.xmlsoap.org/wsdl/">
- <types>
- <s:schema elementFormDefault="qualified"
targetNamespace="HTTP://tempuri.org/">
- <s:element name="Conversao">
- <s:complexType>
- <s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="a" type="s:int" />
</s:sequence>
</s:complexType>
65
</s:element>
- <s:element name="ConversaoResponse">
- <s:complexType>
- <s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="ConversaoResult"
type="s:int" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="int" type="s:int" />
</s:schema>
</types>
- <message name="ConversaoSoapIn">
<part name="parameters" element="s0:Conversao" />
</message>
- <message name="ConversaoSoapOut">
<part name="parameters" element="s0:ConversaoResponse" />
</message>
- <message name="ConversaoHttpGetIn">
<part name="a" type="s:string" />
</message>
- <message name="ConversaoHttpGetOut">
<part name="Body" element="s0:int" />
</message>
- <message name="ConversaoHttpPostIn">
<part name="a" type="s:string" />
</message>
- <message name="ConversaoHttpPostOut">
<part name="Body" element="s0:int" />
</message>
- <portType name="MathServiceSoap">
66
- <operation name="Conversao">
<input message="s0:ConversaoSoapIn" />
<output message="s0:ConversaoSoapOut" />
</operation>
</portType>
- <portType name="MathServiceHttpGet">
- <operation name="Conversao">
<input message="s0:ConversaoHttpGetIn" />
<output message="s0:ConversaoHttpGetOut" />
</operation>
</portType>
- <portType name="MathServiceHttpPost">
- <operation name="Conversao">
<input message="s0:ConversaoHttpPostIn" />
<output message="s0:ConversaoHttpPostOut" />
</operation>
</portType>
- <binding name="MathServiceSoap" type="s0:MathServiceSoap">
<soap:binding transport="HTTP://schemas.xmlsoap.org/soap/HTTP"
style="document" />
- <operation name="Conversao">
<soap:operation soapAction="HTTP://tempuri.org/Conversao"
style="document" />
- <input>
<soap:body use="literal" />
</input>
- <output>
<soap:body use="literal" />
</output>
</operation>
</binding>
67
- <binding name="MathServiceHttpGet" type="s0:MathServiceHttpGet">
<HTTP:binding verb="GET" />
- <operation name="Conversao">
<HTTP:operation location="/Conversao" />
- <input>
<HTTP:urlEncoded />
</input>
- <output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
- <binding name="MathServiceHttpPost" type="s0:MathServiceHttpPost">
<HTTP:binding verb="POST" />
- <operation name="Conversao">
<HTTP:operation location="/Conversao" />
- <input>
<mime:content type="application/x-www-form-urlencoded" />
</input>
- <output>
<mime:mimeXml part="Body" />
</output>
</operation>
</binding>
- <service name="MathService">
- <port name="MathServiceSoap" binding="s0:MathServiceSoap">
<soap:address location="HTTP://localhost:8081/conversao.asmx" />
</port>
- <port name="MathServiceHttpGet" binding="s0:MathServiceHttpGet">
<HTTP:address location="HTTP://localhost:8081/conversao.asmx" />
</port>
68
- <port name="MathServiceHttpPost" binding="s0:MathServiceHttpPost">
<HTTP:address location="HTTP://localhost:8081/conversao.asmx" />
</port>
</service>
</definitions>
A.4. Arquivo envelope para WebService - SOAP
O arquivo descrito abaixo é o envelope para os Web Services que permite
aos mesmos circularem sob o protocolo HTTP.
POST /conversao.asmx HTTP/1.1
Host: localhost
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "HTTP://tempuri.org/Conversao"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="HTTP://www.w3.org/2001/XMLSchema-
instance" xmlns:xsd="HTTP://www.w3.org/2001/XMLSchema"
xmlns:soap="HTTP://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Conversao xmlns="HTTP://tempuri.org/">
<a>int</a>
</Conversao>
</soap:Body>
</soap:Envelope>HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="HTTP://www.w3.org/2001/XMLSchema-
instance" xmlns:xsd="HTTP://www.w3.org/2001/XMLSchema"
xmlns:soap="HTTP://schemas.xmlsoap.org/soap/envelope/">
69
<soap:Body>
<ConversaoResponse xmlns="HTTP://tempuri.org/">
<ConversaoResult>int</ConversaoResult>
</ConversaoResponse>
</soap:Body>
</soap:Envelope>