Guia de Orientao para Implementao de Web Services

Este documento apresenta alguns direcionamentos referentes implementao de web services. uma verso preliminar da construo do Guia de Orientao para Implementao de Web Services, resultante da discusso que est sendo realizada no mbito da e-PING, com a participao do DSI/SLTI, SERPRO, COOPE, participantes e colaboradores do Grupo de Web services (http://i3gov.softwarepublico.gov.br/wikiws/wikka.php?wakka=ListaGrupo). Alm das orientaes para implementao de web services, o documento contm, nos anexos, alguns questionamentos acerca do contedo do guia, conceitos e exemplos concernentes a web services e um mapa de orquestrao de servios da AR.

Orientaes para o a Implementao de Servios Web

Para promover a interoperabilidade entre os diversos sistemas estruturadores de Governo indicase o uso de uma abordagem nica para implementao de servios Web. Com este objetivo, propem-se algumas orientaes: 1. Seguir os padres preconizados pela e-PING (vide Tabela 1); 2. Gerar um arquivo XSD e referenci-lo no WSDL, fazendo com que seja possvel catalogar o XML Schema no catlogo de XML Schemas da e-PING; 3. No arquivo XSD gerado os elementos de dados de sada (output) do servio no devem conter o atributo minOccur=0, ou seja, deve retornar sempre o mesmo contedo (o mesmo vocabulrio), mesmo que para algumas tags, no existam dados (tag vazia); 4. Disponibilizar duas interfaces para a visualizao do XML Schema: Web e atravs de SOAP UI; a) A interface web tem um objetivo didtico para que os Gestores possam entender o que o servio Web est provendo; b) Nessas interfaces as operaes devem ser documentadas. c) Exemplos de interfaces web: http://www.siorg.redegoverno.gov.br/gestao/webservice/wssiorg.asmx http://www.consultacpf.com/webservices/consultacpf.asmx https://homsigplan.serpro.gov.br/xml/CargaAcompanhamento.asmx

5. No XML Schema devem-se criar comentrios com breves descries de seus objetivos;

6. Caso um atributo no seja apresentado diretamente de uma varivel de arquivo, a regra que
gera esse atributo deve ser descrita.

Componente
Protocolo de troca de informaes

Especificao
SOAP v1.2, como definido pelo W3C http://www.w3.org/TR/soap12-part1/ http://www.w3.org/TR/soap12-part2/ Especificaes do protocolo SOAP podem ser encontradas em http://www.w3.org/TR/soap12-part0/ Especificao UDDI v3.0.2 (Universal Description, Discovery and Integration) definida pela OASIS http://uddi.org/pubs/uddi_v3.htm ebXML(Electronic Business using eXtensible Markup Language) A especificao pode ser encontrada em http://www.ebxml.org/specs/index.htm WSDL 1.1 (Web Service Description Language) como definido pelo W3C. A especificao pode ser encontrada em http://www.w3.org/TR/wsdl WSDL 2.0 (Web Service Description Language) como definido pelo W3C. A especificao pode ser encontrada em http://www.w3.org/TR/wsdl20/

Observaes

Infra-estrutura registro

de

linguagem de definio do servio

Perfil bsico interoperabilidade

de

Basic Profile 1.1 Second Edition, como definido pela WS-I http://www.ws-i.org/Profiles/BasicProfile-1.1.html

A verso 1.2 do Basic Profile encontra-se como rascunho (Working Draft) em http://www.wsi.org/Profiles/BasicProfile1.2.html

Portlets remotos

WSRP 1.0 (Web Services for Remote Portlets) como definido pela OASIS http://www.oasis-open.org/committees/wsrp

Tabela 1. Padres preconizados pela e-PING

ANEXOS

ANEXO I Alguns questionamentos acerca do contedo do Guia.

A partir de diversas reunies no grupo de Web Services da e-Ping e uma discusso entre as equipes da DSI/SLTI, COPPE e SERPRO, sugiram os seguintes questionamentos acerca do que deve constar no Guia de Orientao para a Implementao de Web Services:

Quais sero os nveis de granularidade ? Como consumir um WS em qualquer ambiente? O que deve conter na descrio do WS? Onde estar a descrio? No WSDL? Vamos usar um ESB para isso? Qual o padro das especificaes de WS do GT? Vamos usar REST para situaes de implementao mais simplificada? Quantos WS o ambiente pode suportar? Ter monitoramento do WS? Como ser a segurana? 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 repositrio usaremos UDDI ou EbXML ? O processo de registro do schema ser automtico, ou seja, qualquer mudana na estrutura dos tipos o sistema deve encarregar-se de registrar essa informao no repositrio? Se o registro for feito de forma automtica haver um versionamento das alteraes?

ANEXO II Alguns conceitos e exemplos

Na primeira seo deste documento explica-se o que um servio web, quais so suas principais caractersticas e quais so os padres ou tecnologias envolvidos. Na segunda seo apresentamse as razes para motivar a utilizao desta tecnologia. Na terceira seo enumeram-se algumas orientaes para o desenvolvimento de servios Web para os sistemas informatizados de Governo, segundo os padres estabelecidos pela e-Ping. Na quarta seo explica-se como desenvolver servios web utilizando o Framework AndroMDA. Na quinta seo exemplifica-se como possvel fazer uso de servios web publicados. Os servios Web so estruturados levando em considerao trs aspectos de projeto[1]: o tecnolgico, o legal e o organizacional. O aspecto tecnolgico trata dos componentes de software necessrios para a efetiva realizao da interoperao entre os sistemas concorrentes ao servio Web. O aspecto legal trata das polticas de utilizao e de autorizao de acesso ao servio sob o ponto de vista do gestor do servio. Finalmente, o aspecto organizacional estabelece a infraestrutura de recursos necessrios para suporte ao projeto bem como os procedimentos e instrues necessrias, devidamente registradas no Catlogo de Servios Web. Este documento enfatiza, inicialmente, o aspecto tecnolgico do desenvolvimento de servios Web.

1. Servios Web
Um servio web [2] um sistema de software projetado para permitir interoperabilidade na interao entre mquinas atravs de uma rede. descrito atravs de uma interface padronizada que disponibiliza um servio em uma rede de computadores, geralmente a Internet. Uma vez descrito na forma padro e catalogado, o servio se torna um componente de software totalmente reutilizvel, permitindo a comunicao e a interoperabilidade entre aplicaes e plataformas heterogneas. Servios web representam parte da lgica de negcio, executando em sistemas remotos que os hospedam e os mantm distribudos na rede. Eles podem ser acessados atravs de protocolos padronizados da internet como HTTP (HiperText Transfer Protocol) [3]. Essa comunicao baseada em padres permite que qualquer aplicao que utilize estes protocolos acesse e utilize servios sem conhecer detalhes de implementao. As principais caractersticas dos servios Web so: Baseado em XML: usado para representar os dados. Como transporte de dados, XML (eXtensible Markup Language) [4] elimina qualquer dependncia com rede e sistema operacional.

Fracamente acoplado: a interface de um servio Web pode mudar durante o tempo sem comprometer a habilidade do cliente de interagir com o servio.

Granularidade grossa: prov uma maneira natural de definir servios de granularidade grossa que acessam a quantidade correta de lgica de negcio.

Chamadas sncronas e assncronas: um cliente pode invoc-lo de forma sncrona e assncrona. Possibilitar chamadas assncronas a chave para permitir sistemas fracamente acoplados.

Os servios Web so descritos e acessados utilizando uma notao padronizada de XML que cobre todos os detalhes necessrios para interagir com o servio, descrevendo as funcionalidades, a localizao, o modo de invocao e os protocolos utilizados para isso. O trip XML que mantm a arquitetura de implementao dos servios Web est focada em trs elementos: WSDL (Web Service Description Language) [7]: um formato XML que permite que os servios sejam descritos. Tipicamente usado para gerar cdigo para o cliente e o servidor e para configurao. SOAP (Simple Object Access Protocol) [8]: protocolo para comunicao que encapsula os dados transferidos no formato XML. O protocolo SOAP estende o XML para que aplicaes clientes possam enviar facilmente parmetros para aplicaes servidoras e ento receber e entender o documento XML retornado. Graas simplicidade de um arquivo XML (texto puro), dados so facilmente trafegados entre sistemas de computadores com arquiteturas e formatos de dados heterogneos. O transporte realizado pelos protocolocos: HTTP e HTTPS, tambm possivel usar outros protocolos como SMTP e XMPP. UDDI (Universal Description, Discovery, and Integration) [9]: um catlogo de servios para publicar e descobrir metadados sobre servios Web, permitindo que aplicaes descubramnos tanto em tempo de projeto quanto de execuo. Uma vez que um servio Web definido usando WSDL, necessria alguma forma de torn-lo conhecido para utilizao. Isso feito atravs do registro UDDI (Universal Description Discovery and Integration) que fornece mtodos para publicar e encontrar descries de servios. Dessa forma, provedores de servios podem publicar a existncia de seus servios para que potenciais usurios os encontrem. O registro UDDI armazena uma descrio do servio (conforme o tipo de negcio, dividindo por categorias e organizado hierarquicamente) e a localizao do mesmo (binding). O uso em conjunto de todas as tecnologias descritas acima permite a criao de sistemas de negcios distribudos e dinmicos: um objeto de software de orquestrao de servios1 ir
1

No anexo I, mostra-se, em linhas gerais, como os servios so orquestrados na Arquitetura Referencial.

descobrir, acessar, integrar e invocar servios independentes, sem a interveno humana. Este nvel de orquestrao requer o uso combinado de SOAP, WSDL e UDDI para prover uma infraestrutura dinmica e transparente dos servios Web. A arquitetura de servios Web [9] baseada na interao de trs entidades: Provedor de servios: cria e desenvolve o servio Web que serve para expor alguma funcionalidade de negcio da sua organizao para a invocao por outros usurios externos. Consumidor de servios ou cliente: qualquer usurio que deseja utilizar algum servio Web. Catlogo de Servios (UDDI): um diretrio central onde o provedor de servios possa cadastrar e descrever seus servios, e onde o consumidor possa procurar pelo servio desejado.

Figura 1. Arquitetura de Servios Web

A figura acima ilustra essa arquitetura, representando o uso de servios Web. As trs entidades interagem entre si atravs das operaes de publicar (1), localizar (2, 3) e ligar (4, 5). O Provedor informa ao Catlogo a existncia de um servio Web, utilizando a interface de publicao do Catlogo, para tornar o servio disponvel aos clientes. A informao publicada descreve o servio e especifica o local onde se encontra. Uma aplicao atuando no papel de cliente precisa localizar uma outra aplicao, contida em algum lugar na rede. O cliente consulta um registro UDDI pelo nome, categoria, identificador do servio. Uma vez localizado, o cliente

obtm informao sobre a localizao do WSDL. Este arquivo contm informaes de como contatar o servio Web e o formato das mensagens. Com todas estas informaes o cliente pode enviar mensagens para o cliente via SOAP. Assume-se que exista uma descrio das operaes suportadas pelo servidor escrito em WSDL. Esta descrio um pr-requisito para a gerao de cdigo de comunicao no lado do cliente.

1.1

WSDL

A interface de um servio Web descrita em uma linguagem chamada Web Service Description Language (WSDL). a descrio WSDL que habilita qualquer programa a entender como interagir com o servio Web, pois ela possui as informaes sobre quais operaes um servio possui, quais os tipos de entrada e sada de cada operao e qual a localizao e o tipo de protocolo utilizado para invocar o servio. O uso do WSDL na arquitetura de servios Web convencionalmente divide a descrio do servio em duas partes: a interface do servio e a implementao do servio. A definio da interface do servio uma descrio abstrata que pode ser referenciada e utilizada por mltiplos servios. anloga definio de uma classe abstrata em uma linguagem de programao orientada a objetos.

Figura 2. Implementao e interface de um servio em uma descrio WSDL.

A interface do servio composta pelos elementos WSDL:binding, WSDL:portType, WSDL:message e WSDL:type. O elemento WSDL:portType define as operaes do servio, isto , quais mensagens XML de entrada e sada sero utilizadas. Pense nesse elemento como a assinatura de um mtodo em uma linguagem de programao. O elemento WSDL:message especifica o tipo de dado que ir aparecer nas operaes de entrada e sada, ou seja, os parmetros da operao. O uso de tipos de dados complexos nas mensagens descrito no elemento WSDL:type. O elemento WSDL:binding descreve o protocolo, formato de dados, segurana e outros atributos de uma interface de servio em particular.

A definio da implementao do servio um documento WSDL que descreve como uma determinada interface implementada por algum provedor de servio (service provider). O servio Web modelado (Figura 2) como um elemento WSDL:service que contm uma coleo (geralmente um) de elementos WSDL:port. Uma porta (port) associa um endpoint (por exemplo, um endereo de rede ou uma URL) com um elemento WSDL:binding da definio da interface do servio.

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 definio de regras de validao para um documento no formato XML. Deste modo, um documento XSD define a estrutura de um documento XML. No contexto de servios Web, um XSD define a estrutura das mensagens trocadas como entrada ou sada para um servio. Um documento XSD possui definies 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-padro. 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. Tambm possvel atribuir valores fixos ou padro para o elemento utilizando as propriedades default e fixed. Elementos complexos so aqueles que possuem outros elementos e/ou atributos associados e so 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 so normalmente opcionais, para especificar que um atributo requerido deve-se utilizar a propriedade required. Restries tambm podem ser utilizadas para especificar valores ou sries ou conjuntos de valores aceitveis, tamanho, tipos de dados ou espaos em branco para um elemento ou atributo atravs da tag <restriction>, definindo-se suas propriedades. Existem quatro tipos de elementos complexos: elementos vazios, elementos que contm apenas outros elementos, elementos que contm apenas texto e elementos que contm tanto elementos como texto. Cada um destes tipos tambm podem conter atributos.

1.3

RPC x SOA

Existem dois modelos de comunicao para servios Web. So eles: Remote Procedure Call (RPC): representa uma chamada de mtodo distribuda, neste caso a unidade bsica a operao definida no WSDL. Este mtodo criticado por no ser fracamente acoplado, pois freqentemente implementado mapeando servios diretamente para chamadas de mtodo especificas. Esta forma geralmente a mais usada. Arquitetura Orientada a Servio (Service Oriented Architecture - SOA): a unidade bsica de comunicao a mensagem. Este estilo tambm conhecido como servios 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 informaes do comrcio eletrnico de maneira consistente, segura e interopervel atravs de um protocolo global para transaes comerciais. uma iniciativa de interao eletrnica que permite que participantes de negcios se encontrem, conduzam e estabeleam parcerias para seus negcios. Por ser uma estratgia que faz uso de padres da web semntica j estabilizados pelo W3C e por considerar a representao de processos de negcios envolvidos nas transaes de negcios e a busca de servios que representam estes negcios, a equipe do i3Gov tem dispensado esforos na pesquisa que envolve o ebXML, visando a sua aplicabilidade nas solues de interoperabilidade dos sistemas de Governo. Para registrar e descrever os procedimentos de negcio, definir o perfil e identificar o usurio participante, definir a troca de documentos e celebrao de acordos e um canal de comunicao, alm de estabelecer as mensagens associadas, o ebXML baseia-se nos seguintes mecanismos alm do protocolo SOAP: Registro servidor central que armazena os dados necessrios ao funcionamento do ebXML, como informaes que esto relacionadas aos processos de negcio e meta modelos de informao. Quando um cliente quer iniciar uma transao ebXML, executa uma consulta neste registro. Processo de Negcio atividades que fazem parte de um negcio compartilhado entre parceiros comerciais. Descrito formalmente atravs do Business Process Specification Schema (DTD) e modelado em UML.

10

Collaboration Protocol Profile (CPP) Perfil preenchido pelo cliente que deseja participar de uma transao de negcio. Deve especificar alguns dos processos de negcio, assim como algumas interfaces de servios para os quais oferece suporte. Business Service Interface representam o modo atravs do qual os participantes de uma transao de negcio iro interagir. Inclui tipos de mensagens suportadas pelo negcio e os protocolos de comunicao das mensagens. Business Messages mensagens que contm as informaes relacionadas a uma transao de negcio. Esses dados esto distribudos em mltiplas camadas que podem ser trafegadas via diferentes protocolos como, HTTP, SMTP ou SOAP, aceitando mecanismos de criptografia ou autenticao. 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 negcio. Collaboration Protocol Agreement (CPA) um contrato entre dois ou mais participantes da transao de negcio que pode ser gerado automaticamente a partir dos CPPs dos respectivos participantes.

2 Por que utilizar Servios Web?

Servios Web baseiam-se em XML, um padro aberto promovido pelo W3C (World Wide Web Consortium) [10] e adotada pela e-PING. Uma das grandes vantagens da utilizao desta tecnologia que ela extensvel e consiste em uma boa alternativa para a descrio de dados semi-estruturados. Dessa forma, a informao fica organizada no arquivo de forma hierrquica, pode ser estendida conforme o domnio do problema e ainda pode ter o seu contedo validado segundo algum documento que contenha a definio do esquema da aplicao (utilizando um arquivo DTD ou XSD, por exemplo). A simplicidade desta arquitetura, baseada nos padres XML, que impulsiona todo o potencial deste modelo, ao atacar um dos principais pontos fracos dos sistemas distribudos: a interoperabilidade entre as aplicaes, independente de sistemas operacionais, linguagens de programao, modelos e ambientes proprietrios. Os servios podem ser implementados usando qualquer linguagem de programao (Java, C++, Visual Basic, etc.), e em qualquer plataforma. Um cliente de um servio Web tambm pode ser escrito usando qualquer linguagem e em qualquer plataforma. Por exemplo, um cliente escrito em Delphi na plataforma Windows pode utilizar servios de um servio Web escrito em Java na

11

plataforma Linux. O cliente no precisa se preocupar como o servio foi implementado. Ou seja, os servios Web dependem da habilidade das partes para se comunicar mesmo que usem plataformas diferentes. Um servio Web tambm poder ser facilmente localizado na Internet, uma vez estando publicado na grande rede e registrado em um catlogo de servios Web. A comunicao feita via HTTP tambm garante que a comunicao entre as aplicaes acontecer mesmo com a presena de firewalls ou proxies, j que a porta default 80 no normalmente bloqueada. Desse modo, a reusabilidade, a interoperabilidade e a facilidade de uso so as grandes vantagens desta tecnologia.

3 Implementando um Servio Web com AndroMDA

Nesta seo ser descrito como desenvolver um servio Web utilizando o Framework AndroMDA. O Framework AndroMDA uma plataforma livre para desenvolvimento de servios na Web, com projetos de customizao patrocinados pelo Ministrio da Defesa e o pelo Ministrio do Planejamento. Est disponvel no endereo: http:// .. Na criao de um projeto decidimos vrias configuraes do projeto, entre elas decidimos se iremos usar o JBOSS com verso igual ou anterior a verso 4.03 ou um superior. Isto , se utilizaremos JWSDP ou JbossWS. Esta etapa inicial importante para que sejam criados vrios arquivos de configurao do projeto de maneira correta. A figura abaixo mostra esta escolha.

Figura 3. Escolha da verso do JBOSS

12

3.1

Modelando um servio Web

Um servio Web modelado utilizando-se o esteretipo <<WebSrv>> em uma classe. Porm este aplicvel somente quando tambm existe um esteretipo <<Service>>. Portanto um servio Web tambm um servio da aplicao. Quando o esteretipo <<Service>> adicionado a uma classe indicamos que esta ser um servio da aplicao implementado na forma de Session Bean EJB. A adio do esteritipo <<WebSrv>> indica que este servio ser exposto como servio Web. A figura abaixo ilustra um exemplo de modelagem.

Figura 4. Modelagem de um servio Web

Aps o processamento do AndroMDA ser gerada uma classe java com os mtodos vazios para o preenchimento da implementao da classe.

13

Figura 5. Mtodos do servio Web gerados pela automatizao

Os servios Web modelados sero agrupados com o uso do JBOSS com verso igual ou inferior ao 4.0.3, pois neste vrios arquivos de configurao so necessrios. O agrupamento vem para diminuir a quantidade de arquivos necessrios configurao, nas outras verses no ocorre o agrupamento. Na verso 4.0.3 ou inferior, os servios Web sero agrupados de modo diferente dependendo se o projeto for modularizado ou no. Quando uma classe modelada com os esteretipos <<Service>> e <<WebService>> na verdade estamos especificando uma porta. Um projeto modularizado utilizar <NomeModulo>Handler como o servio Web enquanto um projeto que no utilize mdulos o servio Web ser <NomeProjeto>Handler. A URL do servio Web pode ser vista durante o deploy da aplicao. A estrutura geral a seguinte: http://<servidor>:<porta>/<NomeProjeto>-services/<NomeClasse>Srv para JBOSS 4.0.3 ou inferior e http://<servidor>:<porta>/<NomeProjeto>-services/<NomeClasse>Srv?wsdl O nico cuidado que o modelador deve ter em relao aos tipos de retorno e parmetros, como estes sero transmitidos via XML, eles precisam ter mapeamentos pr-definidos. A especificao da Sun define todos os tipos, geralmente utiliza-se os tipo primitivos. Outros tipos definidos pelo usurio devem usar o esteretipo <<WebServiceData>> que o tema da prxima seo.

3.2

Modelando tipos definidos pelo usurio

Quando se deseja transmitir objetos definidos pelo usurio via servio Web devemos usar uma classe com o esteretipo <<WebServiceData>>. Isto necessrio, pois a transmisso de classes requer alguns cuidados e configuraes que so automatizadas com o uso do AndroMDA. A figura abaixo mostra um exemplo de modelagem.

14

Figura 6. Modelagem de tipos para servios Web

A classe gerada com este esteretipo tem o nome definido pelo nome modelado concatenado com WS e gerado em <NomePacote>.ws, dentro da pasta core. Alm disso, todas essas classes herdam de uma classe base chamada AbstractWS. Todo mtodo de servio Web que tem como retorno ou parmetro um tipo definido pelo usurio, deve usar um tipo com este esteretipo. O esteretipo <<WebServiceData>> no precisa estar necessariamente associado ao <<Entity>>. Quando ambos esto presentes, duas classes sero geradas: A entidade e a classe utilizada para trafegar pelo servio Web. A diferena entre elas que a classe usada pelo servio Web s tem os atributos (com mtodos get e set) e possui estruturas de dados compatveis com a especificao da Sun (por exemplo: array no lugar de Collection). O uso do esteretipo <<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 implementao da especificao. O uso deste esteretipo vem para trazer unidirecionalidade para um relacionamento entre classes WS. Portanto, quando temos um relacionamento bidirecional entre entidades que tambm so classes WS este esteretipo obrigatrio. Quando ambos os esteretipos esto presentes, tambm possumos mtodos de converso de um para outro. Um cenrio para esta funcionalidade seria quando queremos transferir dados obtidos do banco de dados de uma aplicao e queremos enviar para outra. Como j foi dito no

15

podemos fazer isto de forma direta por detalhes de implementao durante a transferncia via XML. Precisamos da classe gerada pelo esteretipo <<WebServiceData>>, portanto de extrema utilidade fazer isto de forma simples. Estes mtodos so gerados na entidade e a responsabilidade de converso desta. A figura abaixo mostra um exemplo de converso de uma classe WS para uma Entidade.

Figura 7. Mtodo para converso de uma classe WS em uma Entidade.

Este mtodo aceita como argumento uma classe WS como raiz do processamento e converte todos os relacionamentos, inclusive respeitando herana. Para evitar converses cclicas, necessrio armazenar todas as instncias convertidas em um Map para controle. A classe WS ainda possui o id da entidade que o originou para fins de controle de transformao, mas depois do processo o id no est propagado na nova entidade. Na prxima seo ser mostrado o mtodo que faz a converso contrria.

4 Como Utilizar?
Para utilizar um servio Web necessrio desenvolver um programa cliente, que acesse as operaes do servio Web publicado. Para modelar um cliente basta utilizar o esteretipo <<WebServiceClient>> junto com o valor etiquetado @andromda.web.service.client.wsdl.location.

Figura 8. Modelo do cliente para um servio Web.

16

O contedo deste valor etiquetado pode ser uma URL ou um caminho relativo ao mdulo, caso o projeto seja modularizado, caso contrrio relativo pasta core. Se quisermos invocar um servio Web dentro do mesmo projeto que foi modelado seguindo os passos j discutidos anteriormente (para fins de teste, ou at mesmo uma outra instncia do mesmo projeto), no precisamos modelar o cliente, pois o cliente automaticamente gerado quando criamos o servidor. A invocao de um servio Web, tanto externo (como modelado nesta seo) como um do prprio projeto, ocorre de maneira semelhante. A figura abaixo ilustra para um projeto que use o JBOSS 4.0.3 ou inferior, isto , que use o JWSDP.

Figura 9. Classe cliente para JBOSS 4.0.3 ou JWSDP.

Para o uso de JBOSS com verso superior, usamos o JbossWS e o cdigo ficaria como abaixo.

Figura 10. Classe cliente para JBOSS superior a 4.0.3

17

Referncias
[1] EGOVINTEROP September 2007, Paris, France TERREGOV [2] W3C. Web Services Architecture, Outubro de 2007 [3] The Internet Society, Network Working Group, RFC: 2616. Hypertext Transfer Protocol HTTP/1.1. Disponvel em ftp://ftp.rfc-editor.org/in-notes/rfc1945.txt, 1996. [4] W3C. Extensible Markup Language (XML) 1.0 (Second Edition). Disponvel em http://www.w3.org/TR/REC-xml, 2000. [5] W3C. Web Services Description Language (WSDL) 1.1. Disponvel em

http://www.w3.org/TR/wsdl.html, 2001. [6] W3C. Soap Version 1.2. Disponvel em http://www.w3.org/TR/soap12-part1/, 2007. [7] UDDI Spec Technical Committee Specification Draft. UDDI Version 3.0.2. Disponvel em http://uddi.org/pubs/uddi_v3.htm, 2004. [8] IBM Software Group. Web Services Architect (WSCA 1.0). Disponvel em http://www.ibm.com/developerworks/webservices/library/ws-arc1/ [9] IBM Software Group. Brittenham. P., Curbera, F., Ehnebuske, D., Graham, S. Understanding WSDL in a UDDI Registry. Disponvel em http://www-

106.ibm.com/developerworks/webservices/library/ws-wsdl/, 2002. [10] W3C (World Wide Web Consortium). Disponvel em: http://www.w3c.org [11] W3C. XML Schema. Disponvel em: http://www.w3.org/XML/Schema [12] Especificaes do ebXML. Disponveis em: http://www.ebxml.org

18

ANEXO III MAPA DE ORQUESTRAO DE SERVIOS DA AR.

1 . Mapa Geral de Orquestrao de Servios.

2. Mapa de detalhamento da Interface com Telas JSP e Interface com Web Services.

19

3. Mapa de detalhamento da Interface com Banco de Dados e Consultas.

4. Mapa de detalhamento de Gerao dos Grupos de Informao.

20

5. Mapa de detalhamento do funcionamento da orquestrao de servios (parte 1).

6. Mapa de detalhamento do funcionamento da orquestrao de servios (parte 2).

21