UM MODELO DE COMPOSIÇÃO DE POLÍTICAS DE QUALIDADE
DE PROTEÇÃO PARA SERVIÇOS WEB COMPOSTOS
Florianópolis Junho de 2008
UM MODELO DE COMPOSIÇÃO DE POLÍTICAS DE QUALIDADE
DE PROTEÇÃO PARA SERVIÇOS WEB COMPOSTOS
Trabalho de conclusão de curso apresentada como parte dos requisitos para obtenção do grau Bacharel em Ciências da Computação
Orientador:
Prof. Dr. Michelle Wangham
Co-orientador:
Prof. Dr. Frank Augusto Siqueira
UNIVERSIDADEFEDERAL DE SANTA CATARINA
CENTROTECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA EESTATÍSTICA
CURSO DEBACHARELADO EMCIÊNCIA DA COMPUTAÇÃO
Florianópolis Junho de 2008
Título: Um Modelo de Composição de Políticas de Qualidade Proteção para
Serviços Web Compostos
Autor: Davi da Silva Böger
Profa. Dra. Michelle Wangham (Orientadora)
Prof. Dr. Frank Augusto Siqueira (Responsável)
Os Serviços Web são uma tecnologia que visa promover a comunicação entre diferentes organi-zações. Por meio de interfaces auto-descritivas e da adoção de padrões bem aceitos, os Serviços Webfavorecem a formação de processos de negócio que transpassam os limites de uma única organização. No entanto, questões de interoperabilidade ainda surgem quando aspectos de se-gurança se tornam relevantes no contexto da composição de serviços. Cada organização possui um modelo de segurança independente e o conjunto de mecanismos de proteção exigido pode ser incompatível. As linguagens de descrição de composição de Serviços Web tratam especifi-camente da definição da lógica dos processos de negócio e não dão suporte a especificação dos aspectos de segurança dos Serviços Web envolvidos. Não há ainda especificações que tratem da verificação da compatibilidade dos requisitos de segurança dos diferentes participantes do processo de negócio. Este trabalho define um modelo que, com o auxílio do padrão WS-Policy e das linguagens WS-BPEL e WS-CDL, promove a verificação preliminar da compatibilidade das políticas de qualidade de proteção dos participantes de um processo de negócio. Dessa forma, é possível saber se um dado processo corre o risco de não ser terminado corretamente graças a um problema de interoperabilidade dos requisitos de segurança. Além disso, o modelo gera a política composta do processo de negócio, que permite a tomada de ações corretivas pre-ventivas nos casos em que incompatibilidades forem identificadas.
Palavras-chave: composição de Serviços Web. Segurança computacional. Arquitetura Orien-tada a Serviços. Políticas de qualidade de proteção
1 Interação entre as entidades da SOA. . . p. 17 2 Arquitetura dos serviços Web. . . p. 18 3 Exemplo de documento XML. . . p. 19 4 Exemplo de documento XML com definições de espaços de nomes. . . p. 20 5 Exemplo de mensagem SOAP (MITRA, 2003). . . p. 23 6 Esquema de um EPR (GUDGIN; HADLEY; ROGERS, 2006). . . p. 23
7 Esquema dos parâmetros de mensagem (GUDGIN; HADLEY; ROGERS,
2006). . . p. 24 8 Parte abstrata de uma descrição WSDL (BOOTH; LIU, 2007). . . p. 25 9 Parte concreta de uma descrição WSDL (BOOTH; LIU, 2007). . . p. 26 10 Exemplo de política expressa na forma normal definida na WS-Policy
(VE-DAMUTHU et al., 2007b). . . p. 28 11 Exemplos de anexação de política a um elemento XML de acordo com a
WS-PolicyAttachment(VEDAMUTHU et al., 2007a). . . p. 29 12 Exemplos de anexação de política a um EPR. . . p. 29 13 Esquema geral de uma definição de processo de negócio em WS-BPEL
(JOR-DAN; EVDEMON, 2007) (parte 1 de 2). . . p. 34 14 Esquema geral de uma definição de processo de negócio em WS-BPEL
(JOR-DAN; EVDEMON, 2007) (parte 2 de 2). . . p. 35 15 Esquema de uma definição WS-CDL (KAVANTZAS et al., 2005). . . p. 39 16 Esquema de tipo de canal (KAVANTZAS et al., 2005). . . p. 40 17 Esquema de coreografia (KAVANTZAS et al., 2005). . . p. 41 18 Esquemas de estruturas de ordenação de atividades (KAVANTZAS et al., 2005). p. 42 19 Esquema de workunit (KAVANTZAS et al., 2005). . . p. 43
21 Esquema das atividades básicas exceto interaction (KAVANTZAS et al., 2005). p. 44 22 Diferentes tipos de ataques (STALLINGS, 2000) . . . p. 47 23 Exemplo de assinatura digital segundo a XML-Signature (BARTEL et al.,
2002). . . p. 51 24 Exemplo de cifra segundo XML Encryption (IMAMURA; DILLAWAY;
SI-MON, 2002). . . p. 53 25 Exemplo de chave cifrada segundo a XML Encryption (IMAMURA;
DIL-LAWAY; SIMON, 2002). . . p. 54 26 Modelo de segurança da WS-Trust (CAMARGO, 2006, apud (NADALIN et
al., 2007c)). . . p. 56 27 Estrutura de um pedido de token ao STS (NADALIN et al., 2007c). . . p. 56 28 Estrutura de uma resposta a um pedido de token ao STS (NADALIN et al.,
2007c). . . p. 57 29 Processo de autenticação por pseudônimos da WS-Federation (LOCKHART
et al., 2006). . . p. 60 30 Padrões utilizados no modelo de composição de políticas de qualidade de
proteção . . . p. 62 31 Visão geral do serviço compositor de políticas . . . p. 62 32 Atividades realizadas pelo serviço compositor . . . p. 63 33 Exemplo de especificação de endpoint reference em uma atividade assign em
WS-BPEL . . . p. 65 34 Exemplo de uma anexação de uma política de qualidade de proteção ao
su-jeito participante cliente . . . p. 68 35 Atividades da etapa de composição de políticas . . . p. 68 36 Exemplo de interações em um processo WS-BPEL . . . p. 69 37 Exemplo de interações em uma coreografia WS-CDL (1 de 2) . . . p. 71 38 Exemplo de interações em uma coreografia WS-CDL (2 de 2) . . . p. 72
40 Diagrama de classes da biblioteca GWSPolicy . . . p. 77 41 Diagrama de classes da implementação de anexos em WSDL 1.1 . . . p. 78 42 Esquema das requisições para o serviço compositor . . . p. 79 43 Esquema das respostas geradas pelo serviço compositor . . . p. 80 44 Classes que representam um processo de negócio para o serviço compositor . . . p. 81 45 Diagrama de classes contendo a classe que implementa o serviço compositor . . p. 82 46 Diagrama de seqüência do método composePolicies . . . p. 83 47 Diagrama de seqüência do método computeAttachment . . . p. 84 48 Esquema do elemento que descreve um papel de um participante em um
pro-cesso WS-BPEL . . . p. 84 49 Esquema do elemento que descreve um papel de um participante em um
pro-cesso WS-BPEL . . . p. 85 50 Diagrama de classes do módulo para WS-BPEL . . . p. 86 51 Diagrama de atividades do método de busca de interações em uma atividade . . p. 86 52 Diagrama de atividades do método de busca de interações em um escopo . . . p. 87
1 INTRODUÇÃO . . . p. 10 1.1 OBJETIVOS . . . p. 12 1.2 JUSTIFICATIVA . . . p. 12 1.3 METODOLOGIA . . . p. 13 1.4 ESTRUTURA DO TRABALHO . . . p. 14 2 SERVIÇOS WEB . . . p. 16 2.1 ARQUITETURA ORIENTADA A SERVIÇOS . . . p. 16 2.2 O FORMATO XML . . . p. 18 2.2.1 Espaços de nomes em XML . . . p. 20 2.2.2 XML Information Set . . . p. 20 2.2.3 XML Schema. . . p. 22 2.3 PROTOCOLO DE COMUNICAÇÃO ENTRE SERVIÇOS WEB - SOAP . . . p. 22 2.4 WS-ADDRESSING . . . p. 23 2.5 DESCRIÇÃO FUNCIONAL DE SERVIÇOS WEB - WSDL . . . p. 24 2.6 POLÍTICAS EM SERVIÇOS WEB . . . p. 27 2.6.1 Anexos de política . . . p. 28 2.7 SERVIÇO DE REGISTRO E DIVULGAÇÃO DE SERVIÇOS WEB - UDDI . . . p. 30
3 COMPOSIÇÃO DE SERVIÇOS WEB E PROCESSOS DE NEGÓCIO . . . p. 32 3.1 ORQUESTRAÇÃO DE SERVIÇOS WEB . . . p. 32 3.1.1 WS-BPEL . . . p. 33 3.2 COREOGRAFIA DE SERVIÇOS WEB . . . p. 38
4 SEGURANÇA EM SERVIÇOS WEB . . . p. 46 4.1 INTRODUÇÃO À SEGURANÇA COMPUTACIONAL . . . p. 46 4.1.1 Propriedades de sistemas seguros . . . p. 46 4.1.2 Vulnerabilidades, ameaças e ataques . . . p. 47 4.1.3 Políticas de segurança . . . p. 48 4.1.4 Mecanismos de segurança e controles criptográficos . . . p. 49 4.2 ESPECIFICAÇÕES DE SECURANÇA PARA XML . . . p. 51 4.2.1 XML-Signature. . . p. 51 4.2.2 XML Encryption. . . p. 52 4.3 WS-SECURITY. . . p. 54 4.4 WS-TRUST. . . p. 55 4.5 WS-SECURECONVERSATION. . . p. 57 4.6 WS-SECURITYPOLICY. . . p. 58 4.7 WS-FEDERATION . . . p. 59
5 MODELO DE COMPOSIÇÃO DE POLÍTICAS DE QUALIDADE DE
PRO-TEÇÃO EM PROCESSOS DE NEGÓCIO . . . p. 61 5.1 VISÃO GERAL DO MODELO . . . p. 62 5.2 DESCOBERTA DOS PARTICIPANTES DA COMPOSIÇÃO . . . p. 64 5.2.1 Obtenção dos EPRs em uma orquestração WS-BPEL . . . p. 64 5.2.2 Obtenção dos EPRs em uma coreografia WS-CDL . . . p. 65
5.3 DESCOBERTA DAS INTERFACES WSDL E DAS POLÍTICAS WS-POLICY . . p. 66
5.4 COMPOSIÇÃO DAS POLÍTICAS DE QUALIDADE DE PROTEÇÃO . . . p. 66 5.4.1 Trocas de mensagens em uma orquestração WS-BPEL . . . p. 69 5.4.2 Trocas de mensagens em uma coreografia WS-CDL . . . p. 70 5.4.3 Anexação das políticas resultantes . . . p. 71
6 IMPLEMENTAÇÃO E RESULTADOS . . . p. 75 6.1 AMBIENTE DE DESENVOLVIMENTO . . . p. 75 6.2 PROCESSAMENTO DE POLÍTICAS DE QUALIDADE DE PROTEÇÃO . . . p. 76 6.3 PROTÓTIPO DO SERVIÇO COMPOSITOR DE POLÍTICAS . . . p. 79 6.3.1 Mensagens trocadas pelo serviço compositor de políticas . . . p. 79 6.3.2 Implementação do serviço compositor de políticas . . . p. 80 6.3.3 Implementação do módulo para WS-BPEL . . . p. 83 6.4 TESTES DE SOFTWARE . . . p. 87
7 CONCLUSÃO . . . p. 89
1
INTRODUÇÃO
A Internet provê uma poderosa infra-estrutura de comunicação e, devido a isto, a realiza-ção de negócios que usufruem desta cresceu muito nos últimos anos, significando um aumento no número de aplicações distribuídas que ultrapassam as fronteiras de uma única orgraniza-ção. Para que aplicações desenvolvidas por organizações diferentes pudessem interoperar, uma nova caracterização de sistemas distribuídos surgiu para possibilitar a troca de informações e a integração de sistemas heterogêneos - os Serviços Web (BOOTH et al., 2004).
Os Serviços Web seguem a Arquitetura Orientada a Serviços (SOA), apresentam uma visão abstrata e lógica dos recursos — programas, bases de dados, etc. —, auto-descrita e independente de plataforma. Além disso, são fortemente baseados nos padrões aceitos e am-plamente usados na Internet, como o XML (BRAY et al., 2006b) e o HTTP (FIELDING et al., 1999). Essas características viabilizam a interoperabilidade e tornam mais fácil a composição ou a combinação de diferentes serviços visando formar serviços mais complexos (CARMI-NATI; FERRARI; HUNG, 2005).
Devido à necessidade de uma rápida adaptação dos negócios para atender novos consu-midores e novas condições de mercado, cada vez mais as organizações procuram se unir para criar processos de negócios, que descrevem serviços complexos, que transpassam os seus li-mites organizacionais e que são providos por diferentes parceiros. Um Serviço Web representa uma função de negócio completa e pode ser usado individualmente, ou pode fazer parte de uma composição envolvendo diversos outros serviços providos por diferentes orgranizações, o que torna os Serviços Web uma tecnologia importante para empresas que desejam fazer negócios de forma dinâmica.
Tratando-se da composição de Serviços Web, já existem especificações que padronizam a forma de descrever processos de negócio. O padrão mais amplamente usado hoje é a Lingua-gem para Execução de Processos de Negócio de Serviços Web (Web Services Business Process Execution Language- WS-BPEL) (JORDAN; EVDEMON, 2007). Essa linguagem serve para descrever um processo de negócio executável, sob o ponto de vista de uma única organização.
Para uma composição construída de forma mais colaborativa, uma outra linguagem, a Lingua-gem de Descrição de Coreografia de Serviços Web (Web Services Coreography Description Language- WS-CDL) (KAVANTZAS et al., 2005), fornece uma visão distribuída do processo de negócio e representa mais um contrato de negócio do que um processo executável.
Apesar da tendência para trabalhos colaborativos, muitas organizações e profissionais ainda têm receios em compartilhar informações sensíveis, quando há a necessidade de cola-boração com parceiros desconhecidos (WANGHAM et al., 2005). Ainda mais em um sistema aberto, como a Internet, onde questões relacionadas à segurança das informações são de funda-mental importância para o desenvolvimento de aplicações.
Sempre com o objetivo de manter a interoperabilidade, os Serviços Web se baseiam em padrões também para solucionar questões de segurança. Há padrões para prover segurança às trocas de mensagens de Serviços Web (NADALIN et al., 2006b, 2007a), para estabelecer rela-ções e criar domínios de confiaça (NADALIN et al., 2007c; LOCKHART et al., 2006) e para ex-pressar requisitos de segurança (VEDAMUTHU et al., 2007b; NADALIN et al., 2007b). Essas especificações cobrem requisitos de segurança de serviços individuais ou de grupos definidos de serviços, mas se tratando de composições de Serviços Web desconhecidos, ou pertencentes a diferentes domínios, não há ainda soluções bem estabelecidas e padronizadas.
Em uma colaboração de Serviços Web, cada organização terá um conjunto de restrições quanto às características de segurança dos Serviços Web que irá disponibilizar e diferentes orga-nizações podem ou não concordar em trocar informações. Para que a colaboração possa atingir seu objetivo como função de negócio, é preciso que as organizações envolvidas aceitem as res-trições impostas umas às outras. Nos Serviços Web, diversos tipos de resres-trições de segurança podem ser descritas, seguindo um formato padrão, na forma de uma política (VEDAMUTHU et al., 2007b; NADALIN et al., 2007b) e, uma vez que todas as partes envolvidas em uma cola-boração tenham descrito suas restrições nesse formato, é possível realizar uma verificação a fim de identificar se há incompatibilidades nessas restrições que venham a impedir o cumprimento dos objetivos da colaboração.
O padrão WS-Policy, até o presente momento, não abrange todas as características de segurança que as organizações podem requerer, pois limitam-se à especificação de controles de confidencialidade, integridade e autenticidade de mensagens, não abrangendo aspectos de controle de acesso. Os mecanismos descritos nessas políticas dizem respeito à proteção das mensagens, e por isso serão chamadas, neste trabalho, de políticas de qualidade de prote-ção. Neste trabalho, propõe-se um modelo que realiza a verificação preliminar das restrições de segurança dos participantes de uma colaboração. Essa verificação está baseada na noção
de compatibilidade de políticas (VEDAMUTHU et al., 2007b) e tem como resultado a política composta da colaboração. A política composta expressa o que há de comum nas restrições de segurança dos participantes da colaboração e revela os pontos onde não há compatibilidade. Os participantes podem se basear nessas informações para assegurar que a colaboração não será interrompida por restrições de segurança ou tomar medidas para resolver as incompatibilidades reveladas na política composta. Por resultar na política composta, a verificação de compatibi-lidade de requisitos de segurança será denominada de composição de políticas de quacompatibi-lidade de proteção.
1.1
OBJETIVOS
O objetivo geral deste trabalho é desenvolver um modelo baseado nos padrões de Ser-viços Web que realize a composição das políticas de qualidade de proteção das entidades en-volvidas em um processo de negócio e que gere, como resultado, informações que permitam a solução de conflitos entre as políticas dos participantes.
Para alcançar esse objetivo geral, os seguintes objetivos específicos foram definidos:
• analisar os modelos, conceitos e especificações relacionados à composição de Serviços Web;
• estudar os conceitos de segurança e as especificações de segurança para Serviços Web, em especial as especificações de políticas de qualidade de proteção em Serviços Web; • definir um modelo de composição de políticas de qualidade de proteção para processos
de negócio em redes colaborativas;
• implementar um protótipo do modelo usando ferramentas e bibliotecas de código aberto; • testar o protótipo quanto ao cumprimento dos seus requisitos funcionais e não funcionais
(desempenho e segurança) e quanto à aderência aos padrões de Serviços Web;
• desenvolver um processo de negócio e integrar ao modelo proposto para avaliar a aplica-bilidade do protótipo implementado.
1.2
JUSTIFICATIVA
A composição de Serviços Web já está especificada em padrões bem aceitos ou propos-tas promissoras (JORDAN; EVDEMON, 2007; KAVANTZAS et al., 2005). Também existem
diversas especificações (NADALIN et al., 2006b; VEDAMUTHU et al., 2007b; NADALIN et al., 2007c, 2007a, 2007b) que definem como as propriedades de segurança devem ser atendidas nos Serviços Web básicos. No entanto, não há especificação que indique como tratar as políticas de qualidade de proteção dos participantes de um processo de negócio. As linguagens de des-crição para composição de Serviços Web são específicas para a definição da lógica de negócio e não dão suporte à especificação dos aspectos de segurança dos Serviços Web envolvidos.
Sem uma verificação anterior à execução do processo, cada Serviço Web fará a aplicação da sua política de forma independente, no momento da execução, o que não é adequado, a menos que os parceiros sejam descobertos durante a execução do processo. Toda a lógica de negócio pode ser colocada em risco se algum requisito de segurança não puder ser cumprido. Há casos ainda, como na formação de uma organização virtual, em que os parceiros de negócio são selecionados tendo como base seus requisitos e mecanismos de segurança. Nesses casos, se faz necessário um meio de identificar, antes da execução do processo, em quais pontos não há compatibilidade entre as políticas de qualidade de proteção dos participantes da colaboração.
Este trabalho aborda esse problema por meio da definição de um modelo, baseado nos padrões de Serviços Web e de processos de negócio, para a composição de políticas de qualidade de proteção dos Serviços Web envolvidos no processo de negócio. Tal modelo permite que as partes envolvidas no processo saibam se suas restrições de segurança são compatíveis com as restrições dos outros parceiros, de acordo com suas políticas de qualidade de proteção. Esse conhecimento permite que medidas corretivas sejam tomadas, o que facilita o desenvolvimento de processos de negócios em redes colaborativas, pois automatiza uma verificação necessária para a construção de uma colaboração segura.
1.3
METODOLOGIA
Este trabalho se enquadra como uma pesquisa aplicada, tendo como objetivo a solução de um problema específico, o acordo entre políticas de qualidade de proteção dos participantes de um processo de negócio que seguem uma arquitetura orientada a serviços.
A primeira etapa da pesquisa constitui de um levantamento bibliográfico sobre Serviços Web, segurança computacional e composição de serviços. As pesquisas foram feitas nas diver-sas fontes existentes sobre esses assuntos (livros, artigos, relatórios técnicos, especificações) para se estabelecer a fundamentação teória e conhecer o estado da arte. Na seqüência, o mo-delo proposto neste trabalho foi elaborado. Para tal, os padrões de Serviços Web relacionados a especificação de políticas de qualidade de proteção e processos de negócio foram estudados
em mais detalhes, a fim de compor o modelo. Além disso, alguns trabalhos atuais com escopo semelhante a este foram analisados e algumas características desses trabalhos foram incorpo-radas. Durante a elaboração do modelo, foram usadas ferramentas de modelagem para gerar diferentes visões do modelo e descrevê-lo de forma esquemática com diagramas.
A etapa de implementação do protótipo envolveu, inicialmente, um levantamento das ferramentas de código aberto existentes que implementam as especificações de Serviços Web e de composição. Após a análise e escolha das bibliotecas mais adequadas, o modelo foi im-plementado usando a linguagem de programação orientada a objetos Java1, seguindo a meto-dologia de desenvolvimento guiado por testes (BECK, 2001). O resultado dessa etapa foi um protótipo funcional, com testes de unidade para todos os módulos relevantes do sistema.
A etapa seguinte envolveu os testes de sistema e a avaliação do cumprimento dos re-quisitos não-funcionais. Os testes de sistema foram realizados por meio da integração de um processo de negócio completo ao protótipo. Além disso, foram realizadas avaliações dos ní-veis de segurança e de desempenho visando avaliar o impacto da introdução do protótipo e dos mecanismos de segurança subjacentes a este.
1.4
ESTRUTURA DO TRABALHO
O restante deste trabalho está estruturado da seguinte forma:
• o capítulo 2 apresenta a arquitetura orientada a serviços (seção 2.1) e depois descreve os padrões que compõem os Serviços Web, primeiro o formato XML (seção 2.2) e depois os padrões específicos dessa tecnologia (seções 2.3 a 2.7);
• o capítulo 3 trata da composição de Serviços Web. Nesse capítulo, orquestração e co-reografia são definidas dentro do contexto de processos de negócio (seções 3.1 e 3.2, respectivamente). Para cada uma dessas abordagens, a principal linguagem de descri-ção de processos de negócio é apresentada, WS-BPEL para orquestradescri-ção (sedescri-ção 3.1.1) e WS-CDL para coreografia (seção 3.2.1);
• o capítulo 4 descreve os principais padrões de segurança para Serviços Web. Inicialmente, o capítulo traz uma revisão dos conceitos básicos de segurança computacional (seção 4.1), então as especificações de seguraça para o formato XML são descritas (seção 4.2). Por fim, as principais especificações de segurança para Serviços Web são apresentadas (seções 4.3 a 4.7);
• o capítulo 5 contém a descrição do modelo proposto neste trabalho. Primeiro, uma visão geral do modelo é apresentada (seção 5.1). Depois, cada etapa do modelo é descrita em detalhes (seções 5.2 a 5.4.3). O capítulo termina com comparação do modelo com algumas propostas existentes na literatura (seção 5.5);
• o capítulo 6 descreve a implementação do protótipo do modelo proposto no capítulo an-terior. Inicialmente, as ferramentas e bibliotecas utilizadas no desenvolvimento do pro-tótipo são enumeradas (seção 6.1). Depois, é descrita a implementação da biblioteca GWSPolicy(seção 6.2). Por fim, a implementação do protótipo propriamente dito é apre-sentada (seção 6.3);
2
SERVIÇOS WEB
Serviços Web são uma relização da Arquitetura Orientada a Serviços (SOA). É co-mum as pessoas confundirem serviços Web com SOA, no entanto são duas coisas distintas. Enquanto a SOA define uma arquitetura genérica, um paradigma conceitual, que se preocupa com o fraco acoplamento e amarração dinâmica entre serviços (WEERAWARANA et al., 2005, p. 17), serviços Web formam uma tecnologia que se apóia nos padrões amplamente usados na Internet— os principais são o HTTP, um protocolo de transferência de dados (FIELDING et al., 1999), e o XML, um formato semi-estruturado de representação de informações (BRAY et al., 2006b) — para prover as características da SOA aos serviços. A definição da World Wide Web Consortium(W3C)1para serviços Web é a seguinte:
Um serviço Web é um sistema de software projetado para suportar interope-rabilidade na interação máquina-máquina sobre uma rede de computadores. Este possui uma interface descrita em um formato legível por um computador (WSDL, especificamente). Outros sistemas interagem com o serviço Web na forma prescrita na sua interface usando mensagens SOAP [. . . ] (BOOTH et al., 2004).
Inicialmente, neste capítulo, será feita uma introdução à SOA (seção 2.1), depois será descrito o bloco fundamental dos serviços Web, o formato XML (seção 2.2), e por fim serão contemplados os padrões que definem a intercomunicação (seção 2.3), a descrição (seções 2.5 e 2.6) e a publicação (seção 2.7) de serviços Web.
2.1
ARQUITETURA ORIENTADA A SERVIÇOS
Segundo Booth et al. (2004), um sistema distribuído seguindo a SOA é tipicamente caracterizado pelas seguintes propriedades:
• visão lógica: o serviço é uma visão abstrata e lógica dos programas, bases de dados, processos de negócios, etc..
• orientação à mensagens: o serviço é definido formalmente pelas mensagens trocadas entre o agente provedor e o agente requerente e não pelas propriedades internas desses agentes. A estrutura interna dos agentes é totalmente abstraída na SOA;
• orientação à descrição: um serviço é descrito por meta-dados processáveis por compu-tador e essa descrição deve incluir apenas os detalhes importantes para a utilização do serviço, como as operações que este executa e sua semântica;
• granularidade: serviços tendem a usar poucas operações com mensagens relativamente grandes e complexas;
• orientação à redes: serviços tendem a ser orientados para o uso em redes de computado-res, apesar de não ser um requerimento absoluto;
• independência de plataforma: as mensagens são enviadas em formato independente de plataforma (sistema subjacente ao serviço) e padronizado, especificado na interface des-critiva do serviço.
Figura 1: Interação entre as entidades da SOA.
Os princípios de funcionamento de um sistema que segue a SOA estão ilustrados na Fi-gura 1. Primeiramente, é necessário prover uma definição abstrata do serviço, permitindo que um cliente (agente requerente) possa fazer invocações adequadamente. Depois, o agente prove-dor deve publicar essas definições em um local acessível aos clientes, nos quais possam fazer buscas para encontrar serviços de forma dinâmica. Em terceiro lugar, um cliente deve localizar os provedores que disponibilizam o serviço que satizfaz suas necessidades, para posteriormente fazer a invocação ao serviço escolhido (WEERAWARANA et al., 2005).
Para que esse mecanismo publicar/localizar/invocar funcione corretamente, é necessário que se definam padrões que governem todas as interações entre as entidades. Nesse sentido, os
Figura 2: Arquitetura dos serviços Web.
serviços Web apresentam uma proposta de materialização da SOA (Figura 2). A seguir, serão apresentados os padrões utilizados por essa tecnologia.
2.2
O FORMATO XML
XML é um acrônimo para eXtensible Markup Language (Linguagem de Marcação Ex-tensível). É uma recomendação da W3C (BRAY et al., 2006b) que define um formato padrão independente de plataforma para a representação de dados e documentos estruturados. Foi projetada para ser amplamente utilizada na Web e atualmente é um padrão de facto. O formato XML impõe restrições à estrutura e layout dos dados, mas sem restringir quais entidades podem ser representadas, o que faz do XML uma linguagem flexível e extensível.
A sintaxe do XML é semelhante a de outras linguagens de marcação mais antigas, como HTML (RAGGETT; HORS; JACOBS, 1999). Um elemento possui uma marcação inicial e uma final (exceto por elementos vazios, que podem ter apenas uma marcação) e o que estiver aninhando entre essas marcações é o conteúdo do elemento. O conteúdo de um elemento pode ser constituído de outros elementos ou de texto plano. Na marcação inicial de um elemento, podem ser definidos atributos desse elemento na forma de pares nome-valor.
A Figura 3 mostra um exemplo de documento XML. Todo documento XML deve con-ter um elemento raiz, que não esteja contido em nenhum outro elemento. No exemplo dado, o elemento raiz é<acervo>. Além disso, todo elemento, exceto o elemento raiz, deve estar ime-diatamente contido em apenas um elemento, chamado de elemento pai. No exemplo,<titulo> é pai de<exemplares>, e o segundo é filho do primeiro. A sintaxe para a definição de
atribu-1 <?xml version="1.1"?>
2 <!-- Acervo da videolocadora -->
3 <acervo xmlns="http://livros.exemplos.com/"> 4 <titulo nome="Karate-Kid 3">
5 <exemplares> 6 <exemplar id="1132-3324"> 7 <dataCompra>2005-10-23</dataCompra> 8 <ultimaLocacao>2006-01-18</ultimaLocacao> 9 <disponivel /> 10 </exemplar> 11 <exemplar id="1132-3325"> 12 <dataCompra>2005-10-23</dataCompra> 13 <ultimaLocacao>2006-01-23</ultimaLocacao> 14 <locado>
15 <cliente>Luis I. L. da Silva</cliente> 16 <dataEntrega>2006-01-24</dataEntrega>
17 </locado>
18 </exemplar> 19 </exemplares>
20 <categoria>acervo</categoria> 21 <estilo>aventura</estilo> 22 <reservas />
23 </titulo> 24 </acervo>
Figura 3: Exemplo de documento XML.
tos é nome = “valor”, Como no atributonome do elemento <titulo>, na linha 4 do exemplo. Além dessas construções, o XML ainda possui comentários, colocados entre as marcas<!-- e --> (linha 2 do exemplo), e instruções de processamento são limitadas por sinais <? e ?> (linha 1 do exemplo).
Esse exemplo contém, além das construções básicas do XML, uma definição de espaço de nomes no atributoxmlns="..." (linha 3), de acordo com a extensão do XML chamada XML Namespaces(BRAY et al., 2006a). Essa extensão será explicada brevemente na seção 2.2.1.
Além da sintaxe XML, que define documentos bem-formados, um documento pode ainda passar por uma validação, que dirá se a estrutura contida no documento satisfaz alguma restrição. Restrições podem limitar a ordem e o aninhamento dos elementos, quais atributos devem aparecer em um elemento, quais os tipos de dados que devem estar contidos em um elemento ou atributo. Tais restrições podem ser definidas por meio de linguagens de criação de esquemas. As principais linguagens para a definição de esquemas de documentos XML são DTD (Document Type Definition) (BRAY et al., 2006b) e XML Schema (FALLSIDE; WALMS-LEY, 2004). O último, por ser mais utilizado, será apresentado na seção 2.2.3.
2.2.1 ESPAÇOS DE NOMES EM XML Segundo Bray et al. (2006a),
espaços de nomes em XML provêm um método simples para qualificar nomes de elementos e atributos usados em documentos XML associando esses nomes com espaços de nomes identificados por referências IRI2.
A especificação de espaços de nomes prevê a utilização de nomes expandidos, com-postos de um nome local e um espaço de nomes, a fim de tornar possível a construção de vocabulários de marcações. Esses nomes expandidos evitam que haja colisão de termos entre documentos de organizações diferentes (BRAY et al., 2006a).
1 <ns:doc xmlns:ns="http://exemplo.doc.com.br/ns" ns:tipo="exemplo"> 2 <name xmlns="http://exemplo.doc.com.br/nome">
3 Documento
4 </name> 5 </ns:doc>
Figura 4: Exemplo de documento XML com definições de espaços de nomes.
A sintaxe para a definição de um espaço de nomes é mostrada na Figura 4. Na linha 1, é definido o espaço de nomeshttp://exemplo.doc.com.br/ns e este é associado ao prefixo ns. O elemento <ns:doc> é qualificado por esse espaço de nomes. Na linha 2, é definido o espaço de nomes http://exemplo.doc.com.br/nome, porém este não está associado a nenhum prefixo. Nesse caso, os elementos e atributos sem prefixo estarão automaticamente qualificados por esse espaço de nomes (espaço de nomes padrão).
O escopo de uma declaração de espaço de nomes vai desde a marcação inicial do ele-mento, onde está sendo declarada, até a marcação final correspondente, exceto no escopo dos elementos que redefinem o prefixo utilizado (o mesmo vale para o espaço de nomes padrão) (BRAY et al., 2006a).
Apesar de serem usados IRIs nos nomes dos espaços de nomes, esses IRIs não precisam identificar nenhum outro recurso, são apenas usados para qualificar um vocabulário.
2.2.2 XML INFORMATION SET
A especificação XML Information Set (COWAN; TOBIN, 2004) é uma recomendação da W3C que define um conjunto abstrato de dados — chamado infoset — com o objetivo de prover
2Um IRI (Internationalized Resource Identifier - Identificador de Recursos Internacionalizado), é semelhante
a um URI, no entanto adota o conjunto de caracteres Unicode e permite que identificadores sejam escritos em diversos idiomas e sistemas de símbolos
um conjunto de definições consistente para o uso em outras especificações quando precisarem se referir à informação contida em um documento XML bem-formado.
Um documento XML possui um infoset se for bem-formado (mas não necessariamente válido) e se estiver em conformidade com a especificação dos espaços de nomes (BRAY et al., 2006a). Conforme (HOLLANDER; SPERBERG-MCQUEEN, 2000), nenhum nome de espaço de nomes pode conter uma URI relativa. Um infoset é constituído de diversos itens de informação, que podem ser de onze tipos distintos, cada tipo representando uma construção básica do XML. Cada item de informação possui um conjunto de propriedades derivadas da estrutura do documento XML. Os principais itens de informação são (COWAN; TOBIN, 2004):
• item de informação de documento: representa um documento XML como todo. Sua principais propriedades são: [children], um conjunto que contém o item de informação do elemento raiz do documento, os itens de informação de instrução de processamento e de comentário externos ao elemento raiz; e [document element], o item de informação do elemento raiz do documento;
• item de informação de elemento: representa um elemento. Suas principais propriedades são: [namespace name], o nome do espaço de nomes do elemento; [local name], o nome local do elemento; [prefix], o prefixo do espaço de nomes do elemento; [children], um conjunto ordenado de itens de informação que podem ser de elemento, instrução de pro-cessamento, referência de entidade não-expandida, caractere e comentário; [attributes], um conjunto de itens de informação de atributo; [namespace attributes], um conjunto de itens de informação de atributo que contém as declarações de espaços de nomes deste elemento; [in-scope namespaces], o conjunto de espaços de nomes em vigor neste ele-mento; e [parent], o item de informação do elemento ou do documento que contém este; • item de informação de atributo: representa um atributo de um elemento, incluindo declarações de espaços de nomes e os atributos implícitos definidos por um valor padrão. Suas principais propriedades são: [namespace name], [local name] e [prefix], similares ao item de informação de elemento; [normalized value], o valor do atributo normalizado (BRAY et al., 2006b, sec. 3.3.3); [specified], que define se o atributo foi especificado na marcação do elemento ou foi atribuído implicitamente pelo tipo do elemento; [attribute type], o tipo do atributo; e [owner element], o item de informação do elemento que contém este atributo;
Os outros são itens de informação de instrução de processamento, de referência de enti-dade não-expandida, de caractere, de comentário, de declaração de tipo de documento (DTD),
de entidade não analisada (unparsed), de notação, e de espaço de nomes.
2.2.3 XML SCHEMA
A XML Schema (FALLSIDE; WALMSLEY, 2004) é uma linguagem, desenvolvida pela W3C, para a definição de estruturas e tipos de documentos XML. O objetivo é similar ao DTD, porém o XML Schema usa sintaxe XML e é muito mais poderoso (WEERAWARANA et al., 2005). Enquanto o DTD apenas permite definir a estrutura de documentos, o XML Schema também permite especificar tipos de dados. Essa mistura torna o XML Schema mais complexo que o DTD, no entanto há muitas ferramentas que facilitam seu uso no desenvolvimento de esquemas.
2.3
PROTOCOLO DE COMUNICAÇÃO ENTRE SERVIÇOS WEB - SOAP
SOAP é uma recomendação da W3C que atualmente está na versão 1.2 e
“[. . . ] provê a definição da informação baseada em XML que pode ser usada na troca de informação estruturada e tipada entre servidores em um ambiente distribuído descentralizado” (MITRA, 2003).
Essa especificação diz como a informação deve ser formatada a fim de ser transportada de um ponto a outro, no entanto não define nenhum protocolo de transporte ou de roteamento. O protocolo SOAP define apenas um paradigma de troca de mensagens one-way sem estado. Essas mensagens podem ser combinadas para formar padrões complexos de comunicação e usar qualquer benefício de protocolos inferiores (MITRA, 2003).
A Figura 5 mostra um exemplo de mensagem SOAP. Uma mensagem SOAP é um elemento XML chamado Envelope (linhas 2-20), que contém dois subelementos: Header (ca-beçalho, linhas 3-16) e Body (corpo, linhas 17-19). O conteúdo do cabeçalho e do corpo é definido pela aplicação, no entanto a especificação SOAP diz como esses elementos devem ser manipulados. O cabeçalho é um mecanismo opcional de extensão, que deve ser usado para passar informações de controle, não inerentes à informação sendo transmitida — como infor-mações de segurança, por exemplo. Os subelementos imediatos do cabeçalho, como o elemento <p:oneBlock> do exemplo (linhas 4-7), são chamados de blocos de cabeçalho e podem ser endereçados a um nó específico no caminho percorrido pela mensagem entre o remetente e o destinatário final (MITRA, 2003). Cada bloco de cabeçalho pode possuir dois atributos que indicam a forma como devem ser processados. O atributomustUnderstand (linha 13) indica se o receptor do bloco deve saber como processá-lo ou pode ignorá-lo. O atributorole (linhas
1 <?xml version="1.0" ?>
2 <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 3 <env:Header> 4 <p:oneBlock xmlns:p="http://example.com" 5 env:role="http://example.com/Log"> 6 ... 7 </p:oneBlock> 8 <q:anotherBlock xmlns:q="http://example.com" 9 env:role="http://www.w3.org/2003/05/soap-envelope/role/next"> 10 ... 11 </q:anotherBlock> 12 <r:aThirdBlock xmlns:r="http://example.com" 13 env:mustUnderstand="true"> 14 ... 15 </r:aThirdBlock> 16 </env:Header> 17 <env:Body > 18 ... 19 </env:Body> 20 </env:Envelope>
Figura 5: Exemplo de mensagem SOAP (MITRA, 2003).
5 e 9) indica para quem é destinado o bloco de cabeçalho. O corpo da mensagem é um elemento obrigatório que contem a informação endereçada ao destinatário final.
2.4
WS-ADDRESSING
WS-Addressingé um padrão W3C (GUDGIN; HADLEY; ROGERS, 2006) que define endereçamento no nível de mensagem SOAP e referências a endpoints (EPRs). O objetivo é descrever, em um formato independente de qualquer protocolo subjacente, informações que são tipicamente providas por protocolos de transporte. De acordo com esse padrão, um endpoint é uma entidade, processador ou recurso ao qual uma mensagem pode ser endereçada e os EPRs contém todas as informações necessárias para enviar uma mensagem ao endpoint.
1 <wsa:EndpointReference>
2 <wsa:Address>xs:anyURI</wsa:Address>
3 <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters>? 4 <wsa:Metadata>xs:any*</wsa:Metadata>?
5 </wsa:EndpointReference>
Figura 6: Esquema de um EPR (GUDGIN; HADLEY; ROGERS, 2006).
Um EPR é expresso por um elemento XML<wsa:EndpointReference> (Figura 6), no qual wsa é o prefixo associado ao espaço de nomes da WS-Addressing (GUDGIN; HA-DLEY; ROGERS, 2006). Esse elemento deve, obrigatoriamente, conter um elemento filho
<wsa:Address>, cujo conteúdo é o endereço URI do endpoint. O EPR pode conter, ainda, um elemento
<wsa:ReferenceParameters>, contendo informações adicionais necessárias para enviar men-sagens ao endpoint, e um elemento<wsa:Metadata>, que deve conter metadados (comporta-mentos, políticas, etc.) do endpoint.
1 <wsa:To>xs:anyURI</wsa:To> ?
2 <wsa:From>wsa:EndpointReferenceType</wsa:From> ? 3 <wsa:ReplyTo>wsa:EndpointReferenceType</wsa:ReplyTo> ? 4 <wsa:FaultTo>wsa:EndpointReferenceType</wsa:FaultTo> ? 5 <wsa:Action>xs:anyURI</wsa:Action>
6 <wsa:MessageID>xs:anyURI</wsa:MessageID> ?
7 <wsa:RelatesTo RelationshipType="xs:anyURI"?>xs:anyURI</wsa:RelatesTo> * 8 <wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?
Figura 7: Esquema dos parâmetros de mensagem (GUDGIN; HADLEY; ROGERS, 2006). Além dos EPRs, a WS-Addressing define também um conjunto de elementos XML que podem ser incluídos nas mensagens para declarar informações a respeito da interação (Figura 7). Esses elementos são:
• <wsa:To>: contém o URI do destinatário da mensagem; • <wsa:From>: contém o EPR do remetente da mensagem;
• <wsa:ReplyTo>: contém o EPR para o qual o destinatário deve enviar a resposta; • <wsa:FaultTo>: contém o EPR para o qual o destinatário deve enviar uma mensagem
de falha;
• <wsa:Action>: identifica a semântica da mensagem; • <wsa:MessageID>: declara um identificador da mensagem;
• <wsa:RelatesTo>: declara relacionamentos entre a mensagem e outras mensagens en-viadas anteriormente;
• <wsa:ReferenceParameters>: contém os parâmetros contidos no EPR do destinatário.
2.5
DESCRIÇÃO FUNCIONAL DE SERVIÇOS WEB - WSDL
A Linguagem para Descrição de Serviços Web (WSDL) é uma linguagem XML que de-fine os serviços Web em dois níveis distintos (CHINNICI et al., 2007): o nível abstrato, no qual
o serviço é descrito em termos das mensagens que envia e recebe, e o nível concreto, no qual as mensagens são associadas a mecanismos de transporte e aos provedores que implementam o serviço.
1 <?xml version="1.0" encoding="utf-8" ?> 2 <description 3 xmlns="http://www.w3.org/2006/01/wsdl" 4 targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" 5 xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc" 6 xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc" 7 xmlns:wsoap= "http://www.w3.org/2006/01/wsdl/soap" 8 xmlns:soap="http://www.w3.org/2003/05/soap-envelope" 9 xmlns:wsdlx= "http://www.w3.org/2006/01/wsdl-extensions"> 10 <types> 11 <xs:schema 12 xmlns:xs="http://www.w3.org/2001/XMLSchema" 13 targetNamespace="http://greath.example.com/2004/schemas/resSvc" 14 xmlns="http://greath.example.com/2004/schemas/resSvc">
15 <xs:element name="checkAvailability" type="tCheckAvailability"/> 16 <xs:complexType name="tCheckAvailability">
17 <xs:sequence>
18 <xs:element name="checkInDate" type="xs:date"/> 19 <xs:element name="checkOutDate" type="xs:date"/> 20 <xs:element name="roomType" type="xs:string"/>
21 </xs:sequence>
22 </xs:complexType>
23 <xs:element name="checkAvailabilityResponse" type="xs:double"/> 24 <xs:element name="invalidDataError" type="xs:string"/>
25 </xs:schema> 26 </types>
27 <interface name = "reservationInterface" > 28 <fault name = "invalidDataFault"
29 element = "ghns:invalidDataError"/> 30 <operation name="opCheckAvailability"
31 pattern="http://www.w3.org/2006/01/wsdl/in-out" 32 style="http://www.w3.org/2006/01/wsdl/style/iri" 33 wsdlx:safe = "true">
34 <input messageLabel="In"
35 element="ghns:checkAvailability" /> 36 <output messageLabel="Out"
37 element="ghns:checkAvailabilityResponse" />
38 <outfault ref="tns:invalidDataFault" messageLabel="Out"/> 39 </operation>
40 </interface>
Figura 8: Parte abstrata de uma descrição WSDL (BOOTH; LIU, 2007).
No nível de descrição abstrato, as mensagens são descritas dentro do elemento<types>, usando um sistema de tipos como XML Schema (CHINNICI et al., 2007). Um conjunto de men-sagens podem ser associadas para formar padrões de troca de menmen-sagens (MEP) por meio de operações abstratas (elemento !<operation>!). Tais operações definem apenas quais as mensa-gens trocadas, mas não como (quais protocolos usar) e nem onde (para qual endereço enviar).
Uma interface (elemento<interface>) reune diversas operações, sem se preocupar com o pro-tocolos subjacentes usados para o transporte das mensagens. A Figura 8 apresenta um exemplo de definição abstrata de serviço. Nesse exemplo, uma interface de nome reservationIterface é definida (linhas 27-40). Essa interface contém apenas uma operação, chamada opCheckAvaila-bility(linhas 30-39). O MEP usado por essa operação, definido no atributopattern (linha 31), é in-out. Esse MEP indica que há uma mensagem de entrada, declarada no elemento<input> (linhas 34-35), e uma mensagem de saída, declarada no elemento<output> (linhas 36-37). O elemento<outfault> referencia a mensagem de falha declarada pelo elemento <fault> (li-nhas 28-29) e indica que a resposta da operação pode ser uma mensagem indicando que houve falha. Em todas as mensagens declaradas na operação, o atributoelement (linhas 29, 35 e 37) indicam o formato do elemento XML trocado na mensagem. Nesse caso, os elementos estão definidos no esquema contido no elemento<types> (linhas 10-26).
1 <binding name="reservationSOAPBinding" 2 interface="tns:reservationInterface" 3 type="http://www.w3.org/2006/01/wsdl/soap"
4 wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"> 5 <fault ref="tns:invalidDataFault"
6 wsoap:code="soap:Sender"/>
7 <operation ref="tns:opCheckAvailability"
8 wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/> 9 </binding>
10 <service name="reservationService"
11 interface="tns:reservationInterface"> 12 <endpoint name="reservationEndpoint"
13 binding="tns:reservationSOAPBinding"
14 address ="http://greath.example.com/2004/reservation"/> 15 </service>
16 </description>
Figura 9: Parte concreta de uma descrição WSDL (BOOTH; LIU, 2007).
No nível concreto, uma amarração (elemento <binding>) define os protocolos subja-centes para uma ou mais interfaces. Um elemento<endpoint> associa um endereço de rede a uma amarração. E finalmente, um serviço (elemento<service>) agrupa endpoints que im-plementam uma interface comum (CHINNICI et al., 2007). A Figura 9 ilustra a definição concreta de um serviço usando WSDL. Esse exemplo é a continuação da Figura 8. O elemento <binding> (linhas 1-9) descreve um conjunto de protocolos para ser usado com a interface re-servationIterface, indicada pelo atributointerface (linha 2). O elemento <service> (linhas 10-15) representa um Serviço Web que implementa a interface reservationIterface, indicada pelo atributointerface (linha 11). O elemento <endpoint> (linhas 12-14) declara o ende-reço onde o Serviço Web pode ser acessado no atributoaddress (linha 14) e a amarração que deve ser seguida no atributobinding (linha 13). A WSDL permite, como uma forma de
exten-sibilidade, que elementos e atributos de outros espaços de nomes sejam adicionados a elementos definidos na especificação. Essas extensões podem modificar a semântica dos elementos defi-nidos na WSDL ou simplemente prover descrições de outras capacidades dos serviços.
2.6
POLÍTICAS EM SERVIÇOS WEB
A WS-Policy foi desenvolvida em conjunto por diversas empresas e foi padronizada pela W3C (VEDAMUTHU et al., 2007b, 2007a). O objetivo desta especificação é fornecer uma forma simples de expressar requisitos não-funcionais de Serviços Web na forma de políticas. As entidades (endpoints, mensagens, operações, etc.) que podem ter uma política associada são chamados sujeitos de política.
A unidade básica para expressar um requisito é uma asserção de política, que possui se-mântica específica de domínio. Asserções podem ser combinadas em alternativas de política, cada alternativa define um conjunto de requisitos que devem ser satisfeitos em conjunto para satisfazer a alternativa. Uma política, por sua vez, é um conjunto de alternativas de política, e satisfazer a política significa satisfazer uma dessas alternativas (VEDAMUTHU et al., 2007b).
As políticas são expressas por meio de um XML infoset definido na especificação. Esse infosetnão descreve o formato das asserções de política, apenas limita que sejam elementos e define o tipo da asserção como o nome qualificado desse elemento. As asserções podem ser parametrizadas por atributos e sub-elementos e podem conter uma política aninhada. Além das asserções, a WS-Policy define dois tipos de operadores lógicos: conjunções (operadores Policy e All) e disjunções (operador ExactlyOne). Esses operadores podem ser compostos de formas arbitrárias e a especificação define outras construções, como asserções opcionais, identificação e referências para políticas, etc. com a finalidade de facilitar a escrita e o entendimento das políticas e permitir representações compactas das mesmas.
Para que uma política escrita de forma arbitrária se encaixe na forma de um conjunto de alternativas de políticas, a especificação define o conceito de política na forma normal. A Fi-gura 10 apresenta um exemplo de política na forma normal. Nesse exemplo há duas alternativas de política, cada uma encapsulada por um elemento<wsp:All> (linhas 5-7 e 8-10), indicando que todas as asserções filhas devem ser satisfeitas. As alternativas estão contidas no elemento <wsp:ExactlyOne> (linhas 4-11), indicando que uma das alternativas deve ser satisfeita. As políticas na forma normal seguem esse modelo e a WS-Policy define um procedimento por meio do qual é possível obter uma política na forma normal equivalente para qualquer política ex-pressa de forma compacta.
1 <wsp:Policy 2 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" 3 xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > 4 <wsp:ExactlyOne> 5 <wsp:All> 6 <sp:Basic256Rsa15 /> 7 </wsp:All> 8 <wsp:All> 9 <sp:TripleDesRsa15 /> 10 </wsp:All> 11 </wsp:ExactlyOne> 12 </wsp:Policy>
Figura 10: Exemplo de política expressa na forma normal definida na WS-Policy (VEDA-MUTHU et al., 2007b).
Apesar da WS-Policy não definir a semântica das asserções de política, a especificação provê uma forma de interseccionar políticas, isto é, confrontar duas políticas de forma a obter uma terceira que reúne as alternativas de política comum às duas. A interesecção de políticas é uma operação importante, porque permite que duas políticas sejam testadas quanto à com-patibilidade. Dessa forma, dois Serviços Web podem saber se uma mensagem gerada segundo a política de um será aceita pela política outro. Dessa forma, dada a intersecção das políticas dos serviços, basta que o serviço gerador adeque a mensagem que deseja enviar a uma das alternativas de política contida na intersecção (se houver).
A WS-Policy define um framework para se expressar requisitos e capacidades na forma de políticas. Cabe a outras especificações, no entanto, definir conjuntos de asserções que repre-sentem tais requisitos de forma concreta. Na seção 4.6 será apresenta a especificação que define as asserções de segurança em Serviços Web.
A especificação WS-Policy não define nenhum mecanismo para anexar uma política a um sujeito de política. Para isso existe a especificação WS-PolicyAttachment (VEDAMUTHU et al., 2007a), que será abordada na próxima seção.
2.6.1 ANEXOS DE POLÍTICA
A WS-PolicyAttachment define mecanismos gerais para se anexar uma expressão de política a um sujeito (uma operação, uma mensagem, etc.). No padrão, são propostos dois métodos parar tal: um método é específico para descrições em XML e prevê o uso de um atributo ou subelemento que referencia a expressão da política que se deseja associar; o outro método é mais genérico, e usa um formato XML para associar um política a um sujeito independente da sua definição ou representação (VEDAMUTHU et al., 2007a).
1 <MyElement wsp:PolicyURIs=" 2 http://www.fabrikam123.example.com/policies#RmPolicy 3 http://www.fabrikam123.example.com/policies#X509EndpointPolicy" /> 4 (a) 5 <MyElement> 6 <wsp:PolicyReference 7 URI="http://www.fabrikam123.example.com/policies#RmPolicy" /> 8 <wsp:PolicyReference 9 URI="http://www.fabrikam123.example.com/policies#X509EndpointPolicy" /> 10 <MyElement/> 11 (b)
Figura 11: Exemplos de anexação de política a um elemento XML de acordo com a WS-PolicyAttachment(VEDAMUTHU et al., 2007a).
A parte (a) da Figura 11 mostra um exemplo de anexação de uma política a um elemento XML usando o atributoPolicyURIs. O valor desse atributo são URIs separadas por espaço, e cada URI aponta para uma política. A parte (b) mostra a aplicação da mesma política sobre o mesmo elemento, porém por meio do elemento<PolicyReference>. Os dois exemplos são equivalentes quanto a política que será aplicada sobre o elemento<MyElement>.
1 <wsp:PolicyAttachment> 2 <wsp:AppliesTo>
3 <wsa:EndpointReference xmlns:fabrikam="..." >
4 <wsa:Address>http://www.fabrikam123.example.com/acct</wsa:Address> 5 <wsa:PortType>fabrikam:InventoryPortType</wsa:PortType>
6 <wsa:ServiceName>fabrikam:InventoryService</wsa:ServiceName> 7 </wsa:EndpointReference>
8 </wsp:AppliesTo> 9 <wsp:PolicyReference
10 URI="http://www.fabrikam123.example.com/policies#RmPolicy" /> 11 </wsp:PolicyAttachment>
Figura 12: Exemplos de anexação de política a um EPR.
A Figura 12 ilustra um exemplo de anexação de uma política a um Serviço Web por meio de um EPR (GUDGIN; HADLEY; ROGERS, 2006). O elemento<AppliesTo> contém os sujeitos que terão a política anexada. O conteúdo desse elemento é específico das aplicações, porém não podem contradizer a semântica da WS-Policy. Os elementos seguintes devem conter as expressões de política ou, como no exemplo, referências para estas. Depois da lista de po-líticas anexada, pode-se adicionar um elemento<Security> segundo definido na WS-Security (NADALIN et al., 2006b) (vide seção 4.3), que pode conter prover características de segurança ao anexo (VEDAMUTHU et al., 2007a). A WS-PolicyAttachment prevê meios para anexar políticas a documentos WSDL com o uso do mecanismo de extensibilidade dessa linguagem (VEDAMUTHU et al., 2007a). Para anexar uma política a uma construção WSDL, basta
adici-onar um elemento filho<wsp:Policy> ou <wsp:PolicyReference> à essa construção. Dessa forma, é possível anexar políticas a um serviço, endpoint, operação ou mensagem.
Cada um desses é um sujeito de política diferente, mas devem ser considerados como uma hierarquia para a obtenção da sua política efetiva. Por exemplo, para se chegar à política efetiva de uma mensagem, além da política anexada à própria mensagem, devem ser levadas em consideração as políticas da operação à qual a mensagem pertence, do endpoint que im-plementa a operação e do serviço ao qual o endpoint pertence. A forma como essas políticas devem ser unidas está descrita na WS-PolicyAttachment, como um operador chamado merge (VEDAMUTHU et al., 2007a):
1. serializa-se cada política para sua expressão em XML;
2. substitui-se os elementos<wsp:Policy> dessas políticas pelo operador <wsp:All>; 3. adiciona-se todas como filhas de um elemento<wsp:Policy> externo.
A política resultante desse processo é considerada como a representação combinada de todas as políticas unidas (VEDAMUTHU et al., 2007a).
2.7
SERVIÇO DE REGISTRO E DIVULGAÇÃO DE SERVIÇOS WEB
-UDDI
Um serviço Web tem sua funcionalidade expressa em WSDL, suas características não-funcionais como expressões de política e suas mensagens utilizam o padrão SOAP. Essa estru-tura é suficiente em muitas situações, no entanto, há casos em que se deseja também um meca-nismo para divulgar o serviço, fazer as suas descrições técnicas e não-técnicas alcançarem os clientes potencias. Para isso surgiu o UDDI (CLEMENT et al., 2004) (Universal Description, Discovery and Integration- Descição, Descoberta e Integração Universais), uma especificação da Organization for the Advancement of Structured Information Standards (OASIS)3, que for-nece um modelo de dados e diversas interfaces de serviços para a consulta e o gerenciamento das informações a respeito dos serviços Web e seus provedores.
O modelo de dados do UDDI define algumas entidades — estruturas de dados persis-tentes — que armazenam informações sobre os serviços Web e seus provedores. As principais entidades são (CLEMENT et al., 2004):
• businessEntity: descreve uma organização provedora de Serviços Web. Contém informa-ções não-técnicas, como nomes, informainforma-ções para contato e informação de classificação; • businessService: descreve um conjunto de Serviços Web relacionados, oferecidos pela mesma organização, descrita por uma businessEntity. Novamente, não contém informa-ções técnicas a respeito dos serviços, apenas nomes, descriinforma-ções e informainforma-ções de classi-ficação;
• bindingTemplate: descreve as informações técnicas necessárias para se utilizar um Ser-viço Web específico. Contém o ponto de acesso ao serSer-viço, ou um redirecionamento para algum local que levará ao ponto de acesso;
• tModel: descreve um “modelo técnico", um conceito reusável como um tipo de serviço ou um protocolo.
Os conjuntos de interfaces para manipulação dos dados, definidos para padronizar o comportamento e as comunicações entre as implementações do UDDI, são de dois tipos: con-juntos de interfaces de nó e concon-juntos de interfaces de clientes. Os concon-juntos de interfaces de nó definem como ocorre a manipulação dos dados sobre os serviços, e um conjunto de ser-viços Web que suporte pelo menos um desses conjuntos de interfaces é chamado de nó UDDI. Diversos nós UDDI podem ser combinados para formar registros UDDI e cada nó do registro tem acesso a uma cópia lógica completa dos dados contidos no registro.
3
COMPOSIÇÃO DE SERVIÇOS WEB E PROCESSOS DE
NEGÓCIO
Uma das principais características que tornam os Serviços Web uma tecnologia interes-sante é a facilidade de composição. Assim, problemas complexos podem ser resolvidos por aplicações criadas a partir da combinação, em uma ordem conveniente à solução do problema, de funcionalidades fornecidas por serviços básicos (MILANOVIC; MALEK, 2004). Essa abor-dagem facilita o desenvolvimento de aplicações e o reuso de serviços, diminuindo assim o custo e o tempo para a criação de soluções complexas.
Além disso, os Serviços Web envolvidos em uma composição podem ser providos por diversas organizações distintas, característica interessante por permitir um maior nível de in-tegração entre parceiros de negócio. Na verdade, a construção de processos de negócios é a principal área de aplicação da composição de serviços e a maioria dos esforços de pesquisa se concentram nessa direção. Neste trabalho, a mesma filosofia será seguida e Serviços Web compostos e processos de negócios serão usados com o mesmo significado. Segundo (JURIC, 2006): “um processo de negócio é uma coleção de invocações coordenadas a serviços e ativi-dades relacionadas que produzem o resultado de um negócio, seja dentro de uma organização, seja através de várias”.
Existem duas formas principais de se compor serviços: a orquestração e a coreografia (PELTZ, 2003). Enquanto na orquestração o controle sobre os passos do processo são reali-zados por um único participante, na coreografia todos os participantes possuem a visão global das trocas de mensagem. As duas seções a seguir descrevem melhor essas duas abordagens e apresentam, para cada uma, a principal linguagem de descrição de composição existente.
3.1
ORQUESTRAÇÃO DE SERVIÇOS WEB
A orquestração é a forma mais simples de composição e a mais bem estudada. Na orquestração, o controle sobre a composição é realizado pelo ponto de vista de apenas uma parte envolvida (PELTZ, 2003). As outras partes podem nem sequer saber que estão participando da
composição. O controlador da composição, chamado de motor de orquestração, realizará as invocações aos provedores de serviços e será visto por estes como um cliente qualquer.
A orquestração permite que, uma vez definido um processo de negócio, o mesmo possa ser disponibilzado na forma de um Serviço Web com uma WSDL comum. Esse serviço com-posto pode, então, ser usado como componente de outro processo. Essa transparência com relação à composição permite a criação de níveis de abstração na definição de processos de negócio e facilita a flexibilidade e o reuso de funcionalidades (PELTZ, 2003).
A orquestração, em certo nível, pode ser implementada por uma linguagem de progra-mação de uso geral (Java, C++, etc.), no entanto, é mais adequado o uso de um mecanismo que ofereça uma separação melhor entre a lógica de negócio e o fluxo do processo (JURIC, 2006). Além disso, há um conjunto de funcionalidades específicas de procesos de negócios — como suporte a múltiplas instâncias de um processo, processos de longa duração, compensação de faltas, etc. — que justificam o uso de uma linguagem específica.
A principal linguagem para a descrição de processos de negócio na forma de orquestra-ção é a Linguagem para Execuorquestra-ção de Processos de Negócios em Serviços Web (Web Services Business Process Execution Language - WS-BPEL) (JORDAN; EVDEMON, 2007). Por ser uma linguagem de fácil entendimento e suportada por uma grande quantidade de produtos para gerenciamento de processos no mercado, WS-BPEL está se tornando o padrão de facto para orquestração. A próxima seção apresenta esta linguagem em maiores detalhes.
3.1.1 WS-BPEL
A WS-BPEL é uma linguagem baseada em XML para descrever processos de negócios de uma perspectiva local, baseada no paradigma de workflow. Os processos podem ser executá-veis ou abstratos, os últimos sendo caracterizados por um certo nível de ocultação de informação (JORDAN; EVDEMON, 2007). Os processos abstratos fornecem um meio de descrever os pa-drões observáveis de troca de mensagens, se assemelhando em parte à filosofia da coreografia (JURIC, 2006). No entanto, a perspectiva continua sendo a de um único participante, e não há uma visão global do processo. Ou seja, os processos abstratos são processos executáveis com algumas informações ocultas, normalmente os detalhes internos específicos da implementação do processo.
A especificação de um processo WS-BPEL é divida em duas partes: uma parte declara os serviços envolvidos, as variáveis, tratadores de falhas e eventos e outros recursos a serem usados no contexto do processo; a outra parte declara o workflow por meio de atividades. As Figuras
13 e 14 mostram um esquema básico, retirado da especificação WS-BPEL 2.0 (JORDAN; EVDEMON, 2007), que demonstra os principais componentes de um processo definido em WS-BPEL.
1 <process name="NCName" targetNamespace="anyURI"
2 xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
3 ...
4 >
5 <extensions>? <extension ... />+ </extensions> 6 <import ... />*
7 <partnerLinks>?
8 <partnerLink name="NCName" partnerLinkType="QName" 9 myRole="NCName"? partnerRole="NCName"?
10 initializePartnerRole="yes|no"?>+
11 </partnerLink>
12 </partnerLinks> 13 <messageExchanges>?
14 <messageExchange name="NCName" />+ 15 </messageExchanges>
16 <variables>?
17 <variable name="BPELVariableName"
18 messageType="QName"? type="QName"? element="QName"?>+ 19 from-spec?
20 </variable>
21 </variables>
Figura 13: Esquema geral de uma definição de processo de negócio em WS-BPEL (JORDAN; EVDEMON, 2007) (parte 1 de 2).
O elemento raiz de uma especificação de processo é <process>. Os atributos desse elemento incluem o nome do processo, o espaço de nomes do processo e outros contendo con-figurações padrão a serem seguidas pelas atividades do processo.
O mecanismo de extensão da WS-BPEL exige que as extensões usadas no processo sejam declaradas dentro de um elemento<extensions> (linha 5, Figura 13) . Além disso, a WS-BPEL permite que esquemas XML ou definições WSDL sejam incluídas na definição de um processo por meio de elementos<import> (linha 6, Figura 13).
Os serviços Web envolvidos no processo, além do orquestrador, são declarados no ele-mento<partnerLinks> (linhas 7-12, Figura 13). Cada elemento <partnerLink> possui um nome e umpartnerLinkType. Este descreve a relação entre dois serviços Web por meio da definição dos papéis de cada serviço envolvido na relação, cada papel sendo associado a um portType1complementar (CHRISTENSEN et al., 2001). A definição de um
partnerLinkType pode estar dentro da WSDL do Serviço Web que provê as operações
usa-1Um portType é uma estrutura da versão 1.1 da WSDL semelhante à estrutura interface da WSDL 2.0, onde
das. Além dopartnerLinkType, um partnerLink deve deixar claro, por meio dos atributos myRole e partnerRole qual o papel do executor do processo e o papel do serviço envolvido.
Pode ocorrer de a mesma instância de processo invocar a mesma operação do mesmo serviço mais de uma vez. Nesse caso, os elementos<messageExchange> (linhas 13-15, Figura 13) fornecem um mecanismo de diferenciação das respostas.
1 <correlationSets>? <correlationSet ... />+ </correlationSets> 2 <faultHandlers>?
3 <catch faultName="QName"? faultVariable="BPELVariableName"? 4 ( faultMessageType="QName" | faultElement="QName" )? >*
5 activity
6 </catch>
7 <catchAll>? activity </catchAll> 8 </faultHandlers>
9 <eventHandlers>?
10 <onEvent partnerLink="NCName"
11 portType="QName"? operation="NCName" 12 ( messageType="QName" | element="QName" )?
13 variable="BPELVariableName"? messageExchange="NCName"?>*
14 ...
15 <scope ...>...</scope> 16 </onEvent>
17 <onAlarm>*
18 ( <for ...>duration-expr</for> 19 | <until ...>deadline-expr</until>)?
20 <repeatEvery ...>duration-expr</repeatEvery>? 21 <scope ...>...</scope>
22 </onAlarm> 23 </eventHandlers> 24 activity
25 </process>
Figura 14: Esquema geral de uma definição de processo de negócio em WS-BPEL (JORDAN; EVDEMON, 2007) (parte 2 de 2).
As variáveis de um processo são definidas dentro do elemento <variables> (linhas 16-21, Figura 13). Cada variável possui um nome, um tipo e uma inicialização opcional. O nome de uma variável deve ser único no seu contexto de definição e seu tipo pode ser um tipo de mensagem WSDL, um tipo XML Schema ou um elemento XML Schema. A inicialização de uma variável é semelhante à parte de uma atividade<assign> que indica o que será copiado (sub-elemento<from>) (JORDAN; EVDEMON, 2007).
Um mesmo processo pode ter várias instâncias que executam em paralelo. Nesse caso, é necessário um mecanismo que associe as mensagens à instância correta do processo. Isso é feito por meio de conjuntos de propriedades de correlação. Esses conjuntos são especificados no elemento<correlationSets> (linha 1, Figura 14) e as mensagens que lidam com o envio e
recebimento de mensagens usam esses conjutos para determinar a instância de processo à qual a mensagem pertence.
Um processo pode ter ainda tratadores de falhas e de eventos (linhas 2-8 e 9-23, 14, respectivamente) (JORDAN; EVDEMON, 2007) . Os primeiros declaram atividades que serão executadas caso alguma falha ocorra na execução do processo. Os tratadores de evento decla-ram atividades que serão executadas quando uma certa mensagem for recebida pelo processo, ou quando um temporizador sinalizar. A última parte da definição do processo são as ativida-des do mesmo (linha 24, Figura 14). As atividaativida-des podem ser relacionadas à interação com Serviços Web participantes (recebimento, resposta e invocação), manipulação de variáveis ou estruturação de fluxo de controle (condicionais, loops, etc.). As atividades de interação são for-temente dependentes das descrições WSDL dos Serviços Web envolvidos e a WS-BPEL faz uso da especificação WSDL 1.1 (CHRISTENSEN et al., 2001) nesses casos. A lista das atividades com uma breve descrição é dada a seguir (JORDAN; EVDEMON, 2007):
• receive: permite ao processo esperar por uma mensagem específica. A mensagem rece-bida pode ser armazenada em uma variável para uso posterior;
• reply: permite ao processo responder a uma mensagem recebida. Além do serviço e da operação, é necessário especificar a variável que contém a mensagem de resposta; • invoke: realiza uma invocação a um Serviço Web. Podem ser definidas variáveis para as
mensagens de entrada e saída (dependendo do MEP). Podem ser definidos, ainda nessa atividade, tratadores de falhas e compensação para atuarem caso alguma falha ocorra na invocação;
• assign: usada para alterar o valor de uma variável. O mais comum é copiar uma outra variável, ou partes dela;
• validate: serve para validar o conteúdo uma certa variável quanto ao seu tipo XML Schemaou WSDL;
• empty: é uma “não-operação”, mas pode ser útil em alguns casos; • sequence: executa uma lista de sub-atividades de maneira seqüencial;
• flow: usada para executar várias atividades em paralelo. Podem ser criadas associações para definir dependências de controle explícitas entre as atividades;
• scope: é um elemento que permite definir uma sub-atividade com suas próprias variáveis, correlações e tratadores que não serão visíveis fora dessa atividade;
• if: seleção de uma atividade para executar a partir de um conjunto, com base em uma expressão condicional;
• while: executa uma atividade até que uma condição se torne falsa. Se a condição for falsa já na primeira verificação, a atividade não é executada nenhuma vez;
• repeatUntil: semelhante a while, porém o teste da condição começa a ser feito após a primeira execução da atividade. Nesse caso, a atividade é executada ao menos uma vez, mesmo que a condição seja falsa desde o início;
• forEach: executa uma atividade um número determinado de vezes, possivelmente em paralelo;
• pick: com essa atividade, o processo fica esperando por mensagens ou alarmes de tempo. Cada alarme possui uma atividade como resposta, e a atividadepick termina quando uma de suas sub-atividades é executada;
• wait: permite ao processo aguardar por algum intervalo de tempo ou até um dado mo-mento;
• throw: usada para gerar uma falha de dentro do processo;
• rethrow: usada em tratadores de falhas para relançar uma falha capturada;
• compensate: é usada para compensar as conseqüências de todos os escopos internos que já foram completados com sucesso. Deve ser usada dentro de um tratador de falha, compensação ou terminação;
• compensateScope: semelhante à atividade compensate, porém específica a um único escopo interno;
• exit: termina a execução da instância de processo;
• extensionActivity: mecanismo de extensão para novas atividades.
A atividadescope tem um papel importante nas especificações de processos em WS-BPEL. Essa atividade provê o meio para a definição de contextos que influem na execução das atividades aninhadas. Novos contextos podem ser definidos dentro de outros e o contexto raiz é o próprio processo (JORDAN; EVDEMON, 2007). Como o processo define um contexto, este possui algumas construções internas comuns à atividadescope, no entanto não é considerado uma atividade.
