2. Gerar um arquivo XSD e referenciá-lo no WSDL, fazendo com que seja possível catalogar o XML Schema no catálogo de XML Schemas da e-ping;

Transcrição

1 Guia de Orientação para Implementação de Web Services Este documento apresenta alguns direcionamentos referentes à implementação de web services. É uma versão preliminar da construção do Guia de Orientação para Implementação de Web Services, resultante da discussão que está sendo realizada no âmbito da e-ping, com a participação do DSI/SLTI, SERPRO, COOPE, participantes e colaboradores do Grupo de Web services ( Além das orientações para implementação de web services, o documento contém, nos anexos, alguns questionamentos acerca do conteúdo do guia, conceitos e exemplos concernentes a web services e um mapa de orquestração de serviços da AR. Orientações para o a Implementação de Serviços Web Para promover a interoperabilidade entre os diversos sistemas estruturadores de Governo indicase o uso de uma abordagem única para implementação de serviços Web. Com este objetivo, propõem-se algumas orientações: 1. Seguir os padrões preconizados pela e-ping (vide Tabela 1); 2. Gerar um arquivo XSD e referenciá-lo no WSDL, fazendo com que seja possível catalogar o XML Schema no catálogo de XML Schemas da e-ping; 3. No arquivo XSD gerado os elementos de dados de saída (output) do serviço não devem conter o atributo minoccur=0, ou seja, deve retornar sempre o mesmo conteúdo (o mesmo vocabulário), mesmo que para algumas tags, não existam dados (tag vazia); 4. Disponibilizar duas interfaces para a visualização do XML Schema: Web e através de SOAP UI; a) A interface web tem um objetivo didático para que os Gestores possam entender o que o serviço Web está provendo; b) Nessas interfaces as operações devem ser documentadas. c) Exemplos de interfaces web:

2 5. No XML Schema devem-se criar comentários com breves descrições de seus objetivos; 6. Caso um atributo não seja apresentado diretamente de uma variável de arquivo, a regra que gera esse atributo deve ser descrita. Componente Especificação Observações SOAP v1.2, como definido pelo W3C Protocolo de troca de informações Especificações do protocolo SOAP podem ser encontradas em Infra-estrutura registro de Especificação UDDI v3.0.2 (Universal Description, Discovery and Integration) definida pela OASIS ebxml(electronic Business using extensible Markup Language) A especificação pode ser encontrada em linguagem de definição do serviço Perfil básico de interoperabilidade Portlets remotos WSDL 1.1 (Web Service Description Language) como definido pelo W3C. A especificação pode ser encontrada em WSDL 2.0 (Web Service Description Language) como definido pelo W3C. A especificação pode ser encontrada em Basic Profile 1.1 Second Edition, como definido pela WS-I WSRP 1.0 (Web Services for Remote Portlets) como definido pela OASIS A versão 1.2 do Basic Profile encontra-se como rascunho (Working Draft) em i.org/profiles/basicprofile- 1.2.html Tabela 1. Padrões preconizados pela e-ping 2

3 ANEXOS 3

4 ANEXO I Alguns questionamentos acerca do conteúdo do Guia. A partir de diversas reuniões no grupo de Web Services da e-ping e uma discussão entre as equipes da DSI/SLTI, COPPE e SERPRO, sugiram os seguintes questionamentos acerca do que deve constar no Guia de Orientação para a Implementação de Web Services: - Quais serão os níveis de granularidade? - Como consumir um WS em qualquer ambiente? - O que deve conter na descrição do WS? - Onde estará a descrição? No WSDL? Vamos usar um ESB para isso? - Qual o padrão das especificações de WS do GT? - Vamos usar REST para situações de implementação mais simplificada? - Quantos WS o ambiente pode suportar? - Terá monitoramento do WS? - Como será a segurança? o vamos usar certificados? o quem será o certificador?q o qual o modo de criptografia? - Onde vamos registrar e referenciar os schemas de tipos? - Para o repositório usaremos UDDI ou EbXML? - O processo de registro do schema será automático, ou seja, qualquer mudança na estrutura dos tipos o sistema deve encarregar-se de registrar essa informação no repositório? - Se o registro for feito de forma automática haverá um versionamento das alterações? 4

5 ANEXO II Alguns conceitos e exemplos Na primeira seção deste documento explica-se o que é um serviço web, quais são suas principais características e quais são os padrões ou tecnologias envolvidos. Na segunda seção apresentamse as razões para motivar a utilização desta tecnologia. Na terceira seção enumeram-se algumas orientações para o desenvolvimento de serviços Web para os sistemas informatizados de Governo, segundo os padrões estabelecidos pela e-ping. Na quarta seção explica-se como desenvolver serviços web utilizando o Framework AndroMDA. Na quinta seção exemplifica-se como é possível fazer uso de serviços web publicados. Os serviços Web são estruturados levando em consideração três aspectos de projeto[1]: o tecnológico, o legal e o organizacional. O aspecto tecnológico trata dos componentes de software necessários para a efetiva realização da interoperação entre os sistemas concorrentes ao serviço Web. O aspecto legal trata das políticas de utilização e de autorização de acesso ao serviço sob o ponto de vista do gestor do serviço. Finalmente, o aspecto organizacional estabelece a infraestrutura de recursos necessários para suporte ao projeto bem como os procedimentos e instruções necessárias, devidamente registradas no Catálogo de Serviços Web. Este documento enfatiza, inicialmente, o aspecto tecnológico do desenvolvimento de serviços Web. 1. Serviços Web Um serviço web [2] é um sistema de software projetado para permitir interoperabilidade na interação entre máquinas através de uma rede. É descrito através de uma interface padronizada que disponibiliza um serviço em uma rede de computadores, geralmente a Internet. Uma vez descrito na forma padrão e catalogado, o serviço se torna um componente de software totalmente reutilizável, permitindo a comunicação e a interoperabilidade entre aplicações e plataformas heterogêneas. Serviços web representam parte da lógica de negócio, executando em sistemas remotos que os hospedam e os mantém distribuídos na rede. Eles podem ser acessados através de protocolos padronizados da internet como HTTP (HiperText Transfer Protocol) [3]. Essa comunicação baseada em padrões permite que qualquer aplicação que utilize estes protocolos acesse e utilize serviços sem conhecer detalhes de implementação. As principais características dos serviços Web são: Baseado em XML: usado para representar os dados. Como transporte de dados, XML (extensible Markup Language) [4] elimina qualquer dependência com rede e sistema operacional. 5

6 Fracamente acoplado: a interface de um serviço Web pode mudar durante o tempo sem comprometer a habilidade do cliente de interagir com o serviço. Granularidade grossa: provê uma maneira natural de definir serviços de granularidade grossa que acessam a quantidade correta de lógica de negócio. Chamadas síncronas e assíncronas: um cliente pode invocá-lo de forma síncrona e assíncrona. Possibilitar chamadas assíncronas é a chave para permitir sistemas fracamente acoplados. Os serviços Web são descritos e acessados utilizando uma notação padronizada de XML que cobre todos os detalhes necessários para interagir com o serviço, descrevendo as funcionalidades, a localização, o modo de invocação e os protocolos utilizados para isso. O tripé XML que mantém a arquitetura de implementação dos serviços Web está focada em três elementos: WSDL (Web Service Description Language) [7]: um formato XML que permite que os serviços sejam descritos. Tipicamente usado para gerar código para o cliente e o servidor e para configuração. SOAP (Simple Object Access Protocol) [8]: protocolo para comunicação que encapsula os dados transferidos no formato XML. O protocolo SOAP estende o XML para que aplicações clientes possam enviar facilmente parâmetros para aplicações servidoras e então receber e entender o documento XML retornado. Graças à simplicidade de um arquivo XML (texto puro), dados são facilmente trafegados entre sistemas de computadores com arquiteturas e formatos de dados heterogêneos. O transporte é realizado pelos protocolocos: HTTP e HTTPS, também é possivel usar outros protocolos como SMTP e XMPP. UDDI (Universal Description, Discovery, and Integration) [9]: um catálogo de serviços para publicar e descobrir metadados sobre serviços Web, permitindo que aplicações descubramnos tanto em tempo de projeto quanto de execução. Uma vez que um serviço Web é definido usando WSDL, é necessária alguma forma de torná-lo conhecido para utilização. Isso é feito através do registro UDDI (Universal Description Discovery and Integration) que fornece métodos para publicar e encontrar descrições de serviços. Dessa forma, provedores de serviços podem publicar a existência de seus serviços para que potenciais usuários os encontrem. O registro UDDI armazena uma descrição do serviço (conforme o tipo de negócio, dividindo por categorias e organizado hierarquicamente) e a localização do mesmo (binding). O uso em conjunto de todas as tecnologias descritas acima permite a criação de sistemas de negócios distribuídos e dinâmicos: um objeto de software de orquestração de serviços 1 irá 1 No anexo I, mostra-se, em linhas gerais, como os serviços são orquestrados na Arquitetura Referencial. 6

7 descobrir, acessar, integrar e invocar serviços independentes, sem a intervenção humana. Este nível de orquestração requer o uso combinado de SOAP, WSDL e UDDI para prover uma infraestrutura dinâmica e transparente dos serviços Web. A arquitetura de serviços Web [9] é baseada na interação de três entidades: Provedor de serviços: cria e desenvolve o serviço Web que serve para expor alguma funcionalidade de negócio da sua organização para a invocação por outros usuários externos. Consumidor de serviços ou cliente: qualquer usuário que deseja utilizar algum serviço Web. Catálogo de Serviços (UDDI): um diretório central onde o provedor de serviços possa cadastrar e descrever seus serviços, e onde o consumidor possa procurar pelo serviço desejado. Figura 1. Arquitetura de Serviços Web A figura acima ilustra essa arquitetura, representando o uso de serviços Web. As três entidades interagem entre si através das operações de publicar (1), localizar (2, 3) e ligar (4, 5). O Provedor informa ao Catálogo a existência de um serviço Web, utilizando a interface de publicação do Catálogo, para tornar o serviço disponível aos clientes. A informação publicada descreve o serviço e especifica o local onde se encontra. Uma aplicação atuando no papel de cliente precisa localizar uma outra aplicação, contida em algum lugar na rede. O cliente consulta um registro UDDI pelo nome, categoria, identificador do serviço. Uma vez localizado, o cliente 7

8 obtém informação sobre a localização do WSDL. Este arquivo contém informações de como contatar o serviço Web e o formato das mensagens. Com todas estas informações o cliente pode enviar mensagens para o cliente via SOAP. Assume-se que exista uma descrição das operações suportadas pelo servidor escrito em WSDL. Esta descrição é um pré-requisito para a geração de código de comunicação no lado do cliente. 1.1 WSDL A interface de um serviço Web é descrita em uma linguagem chamada Web Service Description Language (WSDL). É a descrição WSDL que habilita qualquer programa a entender como interagir com o serviço Web, pois ela possui as informações sobre quais operações um serviço possui, quais os tipos de entrada e saída de cada operação e qual a localização e o tipo de protocolo utilizado para invocar o serviço. O uso do WSDL na arquitetura de serviços Web convencionalmente divide a descrição do serviço em duas partes: a interface do serviço e a implementação do serviço. A definição da interface do serviço é uma descrição abstrata que pode ser referenciada e utilizada por múltiplos serviços. É análoga à definição de uma classe abstrata em uma linguagem de programação orientada a objetos. Figura 2. Implementação e interface de um serviço em uma descrição WSDL. A interface do serviço é composta pelos elementos WSDL:binding, WSDL:portType, WSDL:message e WSDL:type. O elemento WSDL:portType define as operações do serviço, isto é, quais mensagens XML de entrada e saída serão utilizadas. Pense nesse elemento como a assinatura de um método em uma linguagem de programação. O elemento WSDL:message especifica o tipo de dado que irá aparecer nas operações de entrada e saída, ou seja, os parâmetros da operação. O uso de tipos de dados complexos nas mensagens é descrito no elemento WSDL:type. O elemento WSDL:binding descreve o protocolo, formato de dados, segurança e outros atributos de uma interface de serviço em particular. 8

9 A definição da implementação do serviço é um documento WSDL que descreve como uma determinada interface é implementada por algum provedor de serviço (service provider). O serviço Web é modelado (Figura 2) como um elemento WSDL:service que contém uma coleção (geralmente um) de elementos WSDL:port. Uma porta (port) associa um endpoint (por exemplo, um endereço de rede ou uma URL) com um elemento WSDL:binding da definição da interface do serviço. 1.2 XSD A linguagem XSD (XML Schema Definition) [11], padronizada pelo W3C, é uma alternativa ao DTD (Document Type Description) baseada em XML que visa à definição de regras de validação para um documento no formato XML. Deste modo, um documento XSD define a estrutura de um documento XML. No contexto de serviços Web, um XSD define a estrutura das mensagens trocadas como entrada ou saída para um serviço. Um documento XSD possui definições de elementos, atributos, elementos derivados, ordem e quantidade de elementos derivados, quando um elemento é vazio ou preenchido, tipos de dados para elementos e atributos e valores padronizados ou fixos para elementos ou atributos. O elemento <schema> é a raiz de qualquer esquema em um documento XSD. Este elemento pode conter algumas propriedades como namespaces de outros documentos referenciados ou namespace-padrão. Para definir elementos simples, utiliza-se a tag <element> com suas propriedades para definir nome do elemento e tipo, que pode ser string, decimal, integer, boolean, date, time. Também é possível atribuir valores fixos ou padrão para o elemento utilizando as propriedades default e fixed. Elementos complexos são aqueles que possuem outros elementos e/ou atributos associados e são identificados em um XSD com a tag <complextype>. Um atributo <attribute> é sempre declarado com tipos simples. Para definir atributos deve-se definir as propriedades name, type e, opcionalmente, default ou fixed. Atributos são normalmente opcionais, para especificar que um atributo é requerido deve-se utilizar a propriedade required. Restrições também podem ser utilizadas para especificar valores ou séries ou conjuntos de valores aceitáveis, tamanho, tipos de dados ou espaços em branco para um elemento ou atributo através da tag <restriction>, definindo-se suas propriedades. Existem quatro tipos de elementos complexos: elementos vazios, elementos que contém apenas outros elementos, elementos que contém apenas texto e elementos que contém tanto elementos como texto. Cada um destes tipos também podem conter atributos. 9

10 1.3 RPC x SOA Existem dois modelos de comunicação para serviços Web. São eles: Remote Procedure Call (RPC): representa uma chamada de método distribuída, neste caso a unidade básica é a operação definida no WSDL. Este método é criticado por não ser fracamente acoplado, pois é freqüentemente implementado mapeando serviços diretamente para chamadas de método especificas. Esta forma geralmente é a mais usada. Arquitetura Orientada a Serviço (Service Oriented Architecture - SOA): a unidade básica de comunicação é a mensagem. Este estilo também é conhecido como serviços orientados a mensagem. Este estilo é mais fracamente acoplado, pois o foco está no contrato que o WSDL fornece. 1.4 ebxml O ebxml (e-business XML) [12] tem o objetivo de prover uma infra-estrutura aberta, baseada em XML que possibilite o uso das informações do comércio eletrônico de maneira consistente, segura e interoperável através de um protocolo global para transações comerciais. É uma iniciativa de interação eletrônica que permite que participantes de negócios se encontrem, conduzam e estabeleçam parcerias para seus negócios. Por ser uma estratégia que faz uso de padrões da web semântica já estabilizados pelo W3C e por considerar a representação de processos de negócios envolvidos nas transações de negócios e a busca de serviços que representam estes negócios, a equipe do i3gov tem dispensado esforços na pesquisa que envolve o ebxml, visando a sua aplicabilidade nas soluções de interoperabilidade dos sistemas de Governo. Para registrar e descrever os procedimentos de negócio, definir o perfil e identificar o usuário participante, definir a troca de documentos e celebração de acordos e um canal de comunicação, além de estabelecer as mensagens associadas, o ebxml baseia-se nos seguintes mecanismos além do protocolo SOAP: Registro servidor central que armazena os dados necessários ao funcionamento do ebxml, como informações que estão relacionadas aos processos de negócio e meta modelos de informação. Quando um cliente quer iniciar uma transação ebxml, executa uma consulta neste registro. Processo de Negócio atividades que fazem parte de um negócio compartilhado entre parceiros comerciais. Descrito formalmente através do Business Process Specification Schema (DTD) e modelado em UML. 10

11 Collaboration Protocol Profile (CPP) Perfil preenchido pelo cliente que deseja participar de uma transação de negócio. Deve especificar alguns dos processos de negócio, assim como algumas interfaces de serviços para os quais oferece suporte. Business Service Interface representam o modo através do qual os participantes de uma transação de negócio irão interagir. Inclui tipos de mensagens suportadas pelo negócio e os protocolos de comunicação das mensagens. Business Messages mensagens que contém as informações relacionadas a uma transação de negócio. Esses dados estão distribuídos em múltiplas camadas que podem ser trafegadas via diferentes protocolos como, HTTP, SMTP ou SOAP, aceitando mecanismos de criptografia ou autenticação. Core Library um conjunto de componentes padronizados que podem ser utilizados por alguns elementos ebxml. Por exemplo, processos principais podem ser referenciados por alguns processos de negócio. Collaboration Protocol Agreement (CPA) um contrato entre dois ou mais participantes da transação de negócio que pode ser gerado automaticamente a partir dos CPPs dos respectivos participantes. 2 Por que utilizar Serviços Web? Serviços Web baseiam-se em XML, um padrão aberto promovido pelo W3C (World Wide Web Consortium) [10] e adotada pela e-ping. Uma das grandes vantagens da utilização desta tecnologia é que ela é extensível e consiste em uma boa alternativa para a descrição de dados semi-estruturados. Dessa forma, a informação fica organizada no arquivo de forma hierárquica, pode ser estendida conforme o domínio do problema e ainda pode ter o seu conteúdo validado segundo algum documento que contenha a definição do esquema da aplicação (utilizando um arquivo DTD ou XSD, por exemplo). A simplicidade desta arquitetura, baseada nos padrões XML, é que impulsiona todo o potencial deste modelo, ao atacar um dos principais pontos fracos dos sistemas distribuídos: a interoperabilidade entre as aplicações, independente de sistemas operacionais, linguagens de programação, modelos e ambientes proprietários. Os serviços podem ser implementados usando qualquer linguagem de programação (Java, C++, Visual Basic, etc.), e em qualquer plataforma. Um cliente de um serviço Web também pode ser escrito usando qualquer linguagem e em qualquer plataforma. Por exemplo, um cliente escrito em Delphi na plataforma Windows pode utilizar serviços de um serviço Web escrito em Java na 11

12 plataforma Linux. O cliente não precisa se preocupar como o serviço foi implementado. Ou seja, os serviços Web dependem da habilidade das partes para se comunicar mesmo que usem plataformas diferentes. Um serviço Web também poderá ser facilmente localizado na Internet, uma vez estando publicado na grande rede e registrado em um catálogo de serviços Web. A comunicação feita via HTTP também garante que a comunicação entre as aplicações acontecerá mesmo com a presença de firewalls ou proxies, já que a porta default 80 não é normalmente bloqueada. Desse modo, a reusabilidade, a interoperabilidade e a facilidade de uso são as grandes vantagens desta tecnologia. 3 Implementando um Serviço Web com AndroMDA Nesta seção será descrito como desenvolver um serviço Web utilizando o Framework AndroMDA. O Framework AndroMDA é uma plataforma livre para desenvolvimento de serviços na Web, com projetos de customização patrocinados pelo Ministério da Defesa e o pelo Ministério do Planejamento. Está disponível no endereço: Na criação de um projeto decidimos várias configurações do projeto, entre elas decidimos se iremos usar o JBOSS com versão igual ou anterior a versão 4.03 ou um superior. Isto é, se utilizaremos JWSDP ou JbossWS. Esta etapa inicial é importante para que sejam criados vários arquivos de configuração do projeto de maneira correta. A figura abaixo mostra esta escolha. Figura 3. Escolha da versão do JBOSS 12

13 3.1 Modelando um serviço Web Um serviço Web é modelado utilizando-se o estereótipo <<WebSrv>> em uma classe. Porém este é aplicável somente quando também existe um estereótipo <<Service>>. Portanto um serviço Web também é um serviço da aplicação. Quando o estereótipo <<Service>> é adicionado a uma classe indicamos que esta será um serviço da aplicação implementado na forma de Session Bean EJB. A adição do esteriótipo <<WebSrv>> indica que este serviço será exposto como serviço Web. A figura abaixo ilustra um exemplo de modelagem. Figura 4. Modelagem de um serviço Web Após o processamento do AndroMDA será gerada uma classe java com os métodos vazios para o preenchimento da implementação da classe. 13

14 Figura 5. Métodos do serviço Web gerados pela automatização Os serviços Web modelados serão agrupados com o uso do JBOSS com versão igual ou inferior ao 4.0.3, pois neste vários arquivos de configuração são necessários. O agrupamento vem para diminuir a quantidade de arquivos necessários à configuração, nas outras versões não ocorre o agrupamento. Na versão ou inferior, os serviços Web serão agrupados de modo diferente dependendo se o projeto for modularizado ou não. Quando uma classe é modelada com os estereótipos <<Service>> e <<WebService>> na verdade estamos especificando uma porta. Um projeto modularizado utilizará <NomeModulo>Handler como o serviço Web enquanto um projeto que não utilize módulos o serviço Web será <NomeProjeto>Handler. A URL do serviço Web pode ser vista durante o deploy da aplicação. A estrutura geral é a seguinte: para JBOSS ou inferior e O único cuidado que o modelador deve ter é em relação aos tipos de retorno e parâmetros, como estes serão transmitidos via XML, eles precisam ter mapeamentos pré-definidos. A especificação da Sun define todos os tipos, geralmente utiliza-se os tipo primitivos. Outros tipos definidos pelo usuário devem usar o estereótipo <<WebServiceData>> que é o tema da próxima seção. 3.2 Modelando tipos definidos pelo usuário Quando se deseja transmitir objetos definidos pelo usuário via serviço Web devemos usar uma classe com o estereótipo <<WebServiceData>>. Isto é necessário, pois a transmissão de classes requer alguns cuidados e configurações que são automatizadas com o uso do AndroMDA. A figura abaixo mostra um exemplo de modelagem. 14

15 Figura 6. Modelagem de tipos para serviços Web A classe gerada com este estereótipo tem o nome definido pelo nome modelado concatenado com WS e é gerado em <NomePacote>.ws, dentro da pasta core. Além disso, todas essas classes herdam de uma classe base chamada AbstractWS. Todo método de serviço Web que tem como retorno ou parâmetro um tipo definido pelo usuário, deve usar um tipo com este estereótipo. O estereótipo <<WebServiceData>> não precisa estar necessariamente associado ao <<Entity>>. Quando ambos estão presentes, duas classes serão geradas: A entidade e a classe utilizada para trafegar pelo serviço Web. A diferença entre elas é que a classe usada pelo serviço Web só tem os atributos (com métodos get e set) e possui estruturas de dados compatíveis com a especificação da Sun (por exemplo: array no lugar de Collection). O uso do estereótipo <<ExcludesWSD>> é utilizado para evitar ciclos em um relacionamento bidirecional. Um relacionamento entre entidades pode ser bidirecional enquanto nas classes WS devem ser unidirecionais por detalhes de implementação da especificação. O uso deste estereótipo vem para trazer unidirecionalidade para um relacionamento entre classes WS. Portanto, quando temos um relacionamento bidirecional entre entidades que também são classes WS este estereótipo é obrigatório. Quando ambos os estereótipos estão presentes, também possuímos métodos de conversão de um para outro. Um cenário para esta funcionalidade seria quando queremos transferir dados obtidos do banco de dados de uma aplicação e queremos enviar para outra. Como já foi dito não 15

16 podemos fazer isto de forma direta por detalhes de implementação durante a transferência via XML. Precisamos da classe gerada pelo estereótipo <<WebServiceData>>, portanto é de extrema utilidade fazer isto de forma simples. Estes métodos são gerados na entidade e a responsabilidade de conversão é desta. A figura abaixo mostra um exemplo de conversão de uma classe WS para uma Entidade. Figura 7. Método para conversão de uma classe WS em uma Entidade. Este método aceita como argumento uma classe WS como raiz do processamento e converte todos os relacionamentos, inclusive respeitando herança. Para evitar conversões cíclicas, é necessário armazenar todas as instâncias convertidas em um Map para controle. A classe WS ainda possui o id da entidade que o originou para fins de controle de transformação, mas depois do processo o id não está propagado na nova entidade. Na próxima seção será mostrado o método que faz a conversão contrária. 4 Como Utilizar? Para utilizar um serviço Web é necessário desenvolver um programa cliente, que acesse as operações do serviço Web publicado. Para modelar um cliente basta utilizar o estereótipo <<WebServiceClient>> junto com o valor Figura 8. Modelo do cliente para um serviço Web. 16

17 O conteúdo deste valor etiquetado pode ser uma URL ou um caminho relativo ao módulo, caso o projeto seja modularizado, caso contrário é relativo à pasta core. Se quisermos invocar um serviço Web dentro do mesmo projeto que foi modelado seguindo os passos já discutidos anteriormente (para fins de teste, ou até mesmo uma outra instância do mesmo projeto), não precisamos modelar o cliente, pois o cliente é automaticamente gerado quando criamos o servidor. A invocação de um serviço Web, tanto externo (como modelado nesta seção) como um do próprio projeto, ocorre de maneira semelhante. A figura abaixo ilustra para um projeto que use o JBOSS ou inferior, isto é, que use o JWSDP. Figura 9. Classe cliente para JBOSS ou JWSDP. Para o uso de JBOSS com versão superior, usamos o JbossWS e o código ficaria como abaixo. Figura 10. Classe cliente para JBOSS superior a

18 Referências [1] EGOVINTEROP September 2007, Paris, France TERREGOV [2] W3C. Web Services Architecture, Outubro de 2007 [3] The Internet Society, Network Working Group, RFC: Hypertext Transfer Protocol - HTTP/1.1. Disponível em ftp://ftp.rfc-editor.org/in-notes/rfc1945.txt, [4] W3C. Extensible Markup Language (XML) 1.0 (Second Edition). Disponível em [5] W3C. Web Services Description Language (WSDL) 1.1. Disponível em [6] W3C. Soap Version 1.2. Disponível em [7] UDDI Spec Technical Committee Specification Draft. UDDI Version Disponível em [8] IBM Software Group. Web Services Architect (WSCA 1.0). Disponível em [9] IBM Software Group. Brittenham. P., Curbera, F., Ehnebuske, D., Graham, S. Understanding WSDL in a UDDI Registry. Disponível em ibm.com/developerworks/webservices/library/ws-wsdl/, [10] W3C (World Wide Web Consortium). Disponível em: [11] W3C. XML Schema. Disponível em: [12] Especificações do ebxml. Disponíveis em: 18

19 ANEXO III MAPA DE ORQUESTRAÇÃO DE SERVIÇOS DA AR. 1. Mapa Geral de Orquestração de Serviços. 2. Mapa de detalhamento da Interface com Telas JSP e Interface com Web Services. 19

20 3. Mapa de detalhamento da Interface com Banco de Dados e Consultas. 4. Mapa de detalhamento de Geração dos Grupos de Informação. 20

21 5. Mapa de detalhamento do funcionamento da orquestração de serviços (parte 1). 6. Mapa de detalhamento do funcionamento da orquestração de serviços (parte 2). 21