1

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 indica-
se 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
2

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 Especificao Observaes
Protocolo de troca de
informaes
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

Infra-estrutura de
registro
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

linguagem de definio
do servio
WSDL 2.0 (Web Service Description Language) como definido
pelo W3C.
A especificao pode ser encontrada em
http://www.w3.org/TR/wsdl20/

Perfil bsico de
interoperabilidade
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.ws-
i.org/Profiles/BasicProfile-
1.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
3
ANEXOS
4
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?
5
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 apresentam-
se 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 infra-
estrutura 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.
6
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 descubram-
nos 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 servios
1
ir

1
No anexo I, mostra-se, em linhas gerais, como os servios so orquestrados na Arquitetura Referencial.
7
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 infra-
estrutura 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
8
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.
9
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.
10
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.
11
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
12
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
13
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.

14

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

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

17
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

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

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



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




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




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