ANÁLISE DE LINGUAGENS DE COMPOSIÇÃO PARA WEB SERVICES

Transcrição

1 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

2 II SUMÁRIO 1 Introdução Componentes de Serviços e Software Web Services SOAP - Simple Object Access Protocol WSDL - Web Services Description Language UDDI - Universal Description, Discovery and Integration Entidades Regulamentadoras dos Web Services OASIS - Organization for the Advancement for Structured Information Standards W3C - World Wide Web Consortium WS-I - Web Services Interoperability Organization Composição de Web Services Linguagens de Composição para Web Services Requisitos de uma Linguagem de Composição Processo de Negócio no Contexto das Linguagens de Composição Metadados e Padronização BPML Business Process Modelling Language XLANG X Language WSFL - Web Service Flow Language BPEL4WS - Business Process Execution Language for Web Services WSCI - Web Service Choreography Interface WS-CDL - Web Service Choreography Description Language Estudo de Caso e Análise Exemplo de um Processo interorganizacional Implementação WS-CDL da Coleta de Taxas Municipais Implementação BPEL4WS da Coleta de Taxas Municipais Características de Comparação dos Padrões de Linguagens de Composição Resultados Obtidos na Análise dos Padrões de Linguagens de Composição Conclusões e Trabalhos Futuros Referências Anexos A. Exemplo de uso dos Web Services A.1. Código A.2. Resultado final em XML A.2.1. Url que chama o WebService... 63

3 III A.2.2. Retorno em XML A.3. Arquivo de publicação WSDL A.4. Arquivo envelope para WebService - SOAP... 68

4 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 FIGURA 4 UDDI DENTRO DA ESTRUTURA DE WEB SERVICES FIGURA 5 CENÁRIO DE PADRÕES DE WEB SERVICES FIGURA 6 CENÁRIO DETALHADO DE PADRÕES DE WEB SERVICES FIGURA 7 EXEMPLO DE COMPOSIÇÃO DE SERVIÇOS FIGURA 8 LINGUAGENS DE COMPOSIÇÃO DE WEB SERVICES AO LONGO DO TEMPO FIGURA 9 EXEMPLO DE CODIFICAÇÃO BPML FIGURA 10 EXEMPLO DE CODIFICAÇÃO XLANG FIGURA 11 EXEMPLO DE CODIFICAÇÃO WSFL FIGURA 12 EXEMPLO DE CODIFICAÇÃO BPEL4WS FIGURA 13 EXEMPLO DE CODIFICAÇÃO WSCI FIGURA 14 EXEMPLO DE CODIFICAÇÃO WS-CDL FIGURA 15 DIAGRAMA DE ATIVIDADES COLETA DE TAXAS MUNICIPAIS... 42

5 V ÍNDICE DE TABELAS TABELA 1 PROTOCOLOS TABELA 2 PADRÕES DE METADADOS TABELA 3 PADRÕES DE METADADOS E AMBIENTE DE DESENVOLVIMENTO TABELA 4 COMPARAÇÃO DAS LINGUAGENS DE COMPOSIÇÃO... 53

6 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.

7 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.

8 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.

9 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.

10 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.

11 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 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.

12 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

13 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

14 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.

15 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.

16 Gerenciador de Serviços Registro de Serviços 9 Individual Lookup Busca Repositório Remoto de Web Services Invocar WS Invocação Composição e Execução Proc. Abs. Web Service Composição Execução Web Services Remotos Web Services Remotos Publicação de Web Services Execução Web Services Remotos FIGURA 2 CENÁRIOS DE WEB SERVICES Nas seções seguintes são descritas as tecnologias envolvidas e apresentadas na Figura 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 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 é

17 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:

18 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].

19 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 subelemento 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

20 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.

21 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.

22 15 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 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.

23 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 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 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 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

24 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,

25 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,

26 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.

27 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.

28 21 A Figura 8 mostra a evolução e as entidades envolvidas na criação desses padrões através dos últimos anos 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;

29 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 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.

30 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 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:

31 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 ) 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.

32 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 Informações sobre museus. Information (CIMI) 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 Especificação e padronização de elementos de dados. ISO IRDS - Information Resource Controle de um ambiente de Dictionary System gerenciamento de recurso da informação. EIA CDIF - CASE Data Interchange Definição de metamodelos para Format integração de ferramentas. ECMA PCTE - Portable Common Tool Environment Trata de interfaces de ferramentas/repositório. W3C XML - extensible Mark-up Define e estrutura páginas da web. Language Facilita a troca de Metadados na Internet. MDC MDIS - Meta Data Interchange Padrão para troca de Metadados entre Specification Ferramentas da Tecnologia de Informação. Jure Jure Facto Jure Facto Facto

33 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 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.

34 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

35 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 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.

36 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.:

37 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 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