1. O documento apresenta um estudo sobre o SGE - Sistema de Gestão de Escolas e o SGE Cliente, sistemas desenvolvidos para demonstrar o funcionamento de um Web Service. 2. O trabalho discute conceitos e características de Web Services como baixo acoplamento, transparência de rede, XML, SOAP, WSDL e UDDI. 3. É apresentado também um exemplo prático de um Web Service chamado COBREDIRETO para pagamentos online para melhor entendimento do assunto.

1. INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA FLUMINENSE
PÓS­GRADUAÇÃO LATO­SENSU EM ANÁLISE, PROJETO E GERENCIAMENTO
DE SISTEMAS DE INFORMAÇÃO
SGE ­ SISTEMA DE GESTÃO DE ESCOLAS e SGE CLIENTE: Um Estudo Sobre Web
Services
DEIVISON LAMONICA BARRETO
JULIANA DA SILVA CINDRA
MARIANNA SIQUEIRA REIS
RAFAEL LEITE DE FREITAS
RAQUEL PEREIRA CRESPO
Campos dos Goytacazes/RJ
Setembro de 2010

2. DEIVISON LAMONICA BARRETO
JULIANA DA SILVA CINDRA
MARIANNA SIQUEIRA REIS
RAFAEL LEITE DE FREITAS
RAQUEL PEREIRA CRESPO
SGE ­ SISTEMA DE GESTÃO DE ESCOLAS e SGE CLIENTE: Um Estudo Sobre Web
Services
Monografia apresentada ao Instituto Federal
de Educação, Ciência e Tecnologia
Fluminense Campus Campos­Centro como
requisito parcial para aprovação na
disciplina de Sistemas Distribuídos, do
Curso de Pós Graduação em Análise,
Projeto e Gerenciamento de Sistemas de
Informação.
Professor: Dr. Luís Gustavo Moura
Campos dos Goytacazes/RJ
Setembro de 2010

3. Dedicatória
Dedicado aos nossos colegas de turma.

4. Agradecemos a todos que contribuíram para a realização
deste trabalho e, em especial: ao IFF Campus Campos­
Centro, pela formação propiciada; ao professor Dr. Luís
Gustavo pela orientação; aos colegas de turma, pelo
companheirismo e amizade; à família, pelo carinho e
incentivo; e, acima de tudo, a Deus.

5. RESUMO
Sabemos que a tecnologia é algo que sofre mudanças constantemente. Tais mudanças trazem
necessidades, que por sua vez, precisam ser atendidas de alguma maneira. Imagine por
exemplo, quantas aplicações presentes na Internet foram desenvolvidas utilizando diferentes
linguagens de programação. Como realizar a comunicação entre elas, quando necessário? A
resposta para este tipo de questionamento é a tecnologia do Web Services. Tal tecnologia será
estudada neste trabalho, que abordará assuntos como seus conceitos, características e
arquitetura. Além desse estudo, o presente trabalho consiste no desenvolvimento do SGE –
Sistema de Gestão de Escolas e SGE Cliente, sistemas através dos quais mostraremos na
prática, o desenvolvimento e funcionamento de um Web Service.
Palavras­Chave: Web Service. Tecnologia. Integração.

6. ABSTRACT
We know that technology is something that changes constantly. Such changes bring needs,
which in its turn need to be supplied somehow. Imagine for example, how many applications
on the internet were developed using different programming languages. How to perform the
communication between them when necessary? The answer to this kind of questioning is the
technology of Web Services. Such technology will be studied in this work, broaching issues
such as its concepts, characteristics and architecture. Besides this study, this work consists in
the development of SGE ­ Sistema de Gestão de Escolas e SGE Cliente. These systems will
show in practice the development and operation of a Web Service.
Key words: Web Service, techonology, integration.

7. SUMÁRIO
1. INTRODUÇÃO 07
2. WEB SERVICES 08
2.1. CONCEITOS E DEFINIÇÕES 08
2.2. Características dos Web Services 09
2.2.1. Baixo Acoplamento 09
2.2.2. Transparência de Rede 10
2.3. Extensible Markup Language (XML) 10
2.3.1. XML Schema Definition 10
2.3.1.1 XML Namespace 11
2.3.1.2. Extensible Stylesheet Language (XSLT) 12
2.3.1.3 Simple Object Access Protocol (SOAP) 12
2.3.1.4 Web Services Description Language (WSDL) 14
2.3.1.5 Universal Description, Discovery and Integration (UDDI) 14
2.3.1.6. Arquitetura REST 15
2.3.1.6.1. REpresentational State Transfer (REST) 15
2.3.1.6.2. Web Application Description Language (WADL) 16
2.4. um exemplo de web service – cobredireto 16
2.4.1. Sobre o COBREDIRETO 16
2.4.2. Fluxo do Pagamento – Padrão (WEB SERVICES) 18
2.4.3. Fluxo do Pagamento – Bibliotecas/Conectores 19
2.4.3.1 Integração do COBREDIRETO com o WEB SERVICE 20
2.4.3.2 Criando o Pedido 21
2.4.3.3 Retorno do Pagamento 23
2.4.3.4. Probe 24
3. SGE – SISTEMA DE GESTÃO DE ESCOLAS 26
3.1. ESTUDO DE CASO SGE e SGE CLIENTE 26
3.2. ARQUITETURA UTILIZADA 27
3.2.1 Ruby 27

8. 3.2.2 Rails 28
3.2.3 Rest 29
3.2.4 Restfulie 30
4. CONCLUSÕES 31
REFERÊNCIAS BIBLIOGRÁFICAS 32
APÊNDICE: CÓDIGO DO SGE CLIENTE 34

9. 7
CAPÍTULO 1: INTRODUÇÃO
Com a evolução muito rápida das tecnologias utilizadas no desenvolvimento de
software, muitos dos softwares existentes hoje vêm sendo criados sem utilização de padrões e
metodologias bem definidas. Com o passar do tempo e o grande crescimento de empresas que
utilizam tais softwares, começou a surgir uma necessidade de integração da grande massa de
software existente. Entretanto, por tamanha falta de padrões, tais softwares não conseguem
comunicar­se entre si de maneira eficiente, independente e escalável. Baseando­se nesse
problema, começaram a ser propostas soluções que pudessem integrar tais sistemas. A
necessidade da integração entre aplicações, a utilização unificada de processos encontrados
em diferentes sistemas e escritos em diferentes linguagens são alguns exemplos. A fim de
sanar estas questões, a tecnologia dos Web Services foi criada, permitindo assim,
disponibilizar formas de integrar sistemas distintos, modularizar serviços e capacitar a
integração e consumo de informações.

10. 8
CAPÍTULO 2: WEB SERVICES
Este capítulo mostra alguns conceitos e definições do tema deste trabalho, e um
exemplo de Web Service que tem como objetivo facilitar o entendimento do assunto.
2.1. Conceitos e Definições
Os Web Services constituem um novo modelo de partilha de dados que permite
publicação de rotinas e métodos acessíveis pela Internet. Com uma interface transparente para
o Cliente e facilidade de integração de diferentes aplicações, os Web Services são uma
poderosa ferramenta para promover a integração dos dados em diferentes plataformas e
fornecem uma infra­estrutura para manter uma forma mais rica e mais estruturada de
interoperabilidade entre clientes e servidores.
Pulier (2006) define Web Service (WS) como um sistema de software que segue um
conjunto de padrões abertos de interoperabilidade. Estes padrões permitem a interoperação
mundial de computadores independentemente da plataforma de hardware, sistema
operacional, infra­estrutura de rede ou linguagem de programação. Pulier (2006) ainda afirma
que a grande utilidade do WS é baseada no fato de que ele usa protocolos abertos de
comunicação na Internet e XML para transacionar o seu negócio. Um WS é, portanto, um
sistema de software que pode agir a pedido de qualquer computador conectado à rede no
mundo, que se comunica usando padrões XML.
Um WS depende principalmente, segundo Pulier (2006), de três padrões
interrelacionados baseados no XML para funcionar corretamente:
● Simple Object Access Protocol (SOAP) ­ O formato da mensagem.
● Web Services Description Language (WSDL) ­ O documento que descreve exatamente
o que um WS faz e como invocá­lo.

11. 9
● Universal Discovery, Description, and Integration (UDDI) ­ O diretório do WS que
está disponível para ser usado.
Juntos estes três padrões se combinam para oferecer ao WS a habilidade de funcionar,
de descrever a si próprio e de ser localizado em uma rede.
2.2. Características dos web services
Web Services se comportam diferentemente de software tradicionais. Eles são baseados
em padrões abertos, considerando que a maioria dos softwares em uso hoje se conectam
através de uma tecnologia proprietária. Além disso, Pulier (2006) diz que WS são 'fracamente
acoplados' quando comparado aos tradicionais sistemas distribuídos de computadores.
E, como a Internet, WS oferecem total transparência na sua implementação e
utilização.
2.2.1. Baixo Acoplamento
Em contraste com os computadores cuja interoperação é “fortemente acoplada” através
de interfaces proprietárias, WS são 'fracamente acoplados'. Pulier (2006) destaca que essa
qualidade permite aos administradores de sistema substituir ou mover os computadores que
contêm os WS com relativa facilidade. Baixo acoplamento também significa que as mudanças
no provedor não conduzem necessariamente a mudanças no consumidor de um WS. Por estas
e outras razões, o baixo acoplamento tem o potencial de poupar tempo e dinheiro na criação de
interoperação entre computadores, e de aumentar drasticamente a produtividade de uma
organizacão, permitindo que os processos empresariais sejam mais ágeis.
2.2.2. Transparência de Rede

12. 10
Para Pulier (2006), WS funcionam em modo de “transparência de rede”, ou seja, como
web sites na Internet, WS podem ser localizados em qualquer lugar de uma rede, ou grupo de
redes conectadas. Como resultado, WS podem ser movidos de lugar na rede sem impacto na
acessibilidade.
2.3. Extensible Markup Language (XML)
A representação de dados externa e o empacotamento das mensagens trocadas entre
clientes e serviços web são feitos em XML.
A Extensible Markup Language (XML) é um padrão apoiado pela W3C para marcação
de documentos. Segundo Harold (2004), ela define uma sintaxe genérica usada para marcar
dados com simples tags que humanos possam ler. Ela provê um formato padrão para
documentos de computador, e é flexível o suficiente para ser customizada para os mais
diversos fins. Por exemplo, sítios web, troca eletrônica de dados, gráficos vetoriais,
serialização de objetos, chamadas a funções remotas e muito mais.
Erl (2004) complementa a definição de Harold (2004) adicionando a importância da
XML. Sem ela, a informação trocada na Internet teria pouco significado ou contexto além do
seu valor de apresentação. A XML adiciona uma camada de inteligência a informação,
proporcional a inteligência com que ela é aplicada.
2.3.1. XML Schema Definition
Para Harold (2004), a XML Schema Definition (XSD) é um documento XML contendo
uma descrição formal do que compreende a validade de um documento XML.
Erl (2004) ainda define a XSD como uma linguagem de modelagem de dados
compreensiva para documentos XML, e é a especificação de schema para XML que tem
recebido um amplo suporte da indústria através das tecnologias XML e Web Services.

13. 11
A XSD é uma implementação atual da linguagem XML; schemas são eles próprios
documentos XML. Uma das mais importantes características introduzidas pela especificação
XSD é o amplo suporte a tipos de dados. Isto refina a qualidade da representação de dados em
XML, além de proporcionar suporte para name spaces. Isto possibilita ao autor do schema
estabelecer domínios lógicos com os quais algumas ou todas as partes de um schema pode ser
aplicado.
Erl (2004) ainda destaca os seguintes pontos:
● O formato do documento XSD é muito flexível e altamente extensível. Cada definição
de schema é capaz de conter múltiplos documentos de schema. Isto permite a criação de
schemas modulares que podem ser combinados ou individualmente processados.
● Cada schema pode ser dinamicamente estendido com construções suplementares. Isto
permite aos schemas se adaptarem a diferentes requisitos de representação de dados.
● Partes de uma definição de schema pode ser redefinida por outra definição de schema.
Isto permite que se crie uma série de classes de schemas.
2.3.1.1 XML Namespace
Harold (2004) afirma que Namespaces em XML, permitem a marcação de diferentes
aplicações XML para serem usadas no mesmo documento, sem conflito. Assim, uma página
da web sobre livros poderia ter um elemento título que se refere ao título da página e
elementos títulos que se referem ao título de um livro, e os dois não entrariam em conflito.
De acordo com Harold (2004) Namespaces tem dois propósitos em XML:
1. Distinguir entre os elementos e os atributos de diferentes vocabulários com
diferentes significados que compartilham o mesmo nome.
2. Agrupar todos os elementos e atributos relacionados de uma única aplicação XML
juntos de maneira que o software possa facilmente reconhecê­los.
Namespaces são implementados anexando um prefixo a cada elemento e atributo.

14. 12
Cada prefixo é mapeado para uma URI (URI ­ Uniform Resource Identifier ) da
seguinte forma: xmlns:prefixo atributo. URIs padrões podem também serem fornecidas para
elementos que não têm prefixos. Namespaces padrão são declarados por atributos xmlns.
Elementos e atributos que são anexados a mesma URI estão na mesma namespace.
Elementos de muitas aplicações XML são identificados pelas URIs padrões.
2.3.1.2. Extensible Stylesheet Language (XSLT)
Harold (2004) define a Extensible Stylesheet Language Transformations (XSLT) como
uma linguagem de programação funcional usada para especificar como um documento XML
de entrada é convertido em um outro documento­texto ­ possivelmente, embora não
necessariamente, um outro documento XML.
Erl (2004) faz uma consideração importante sobre o conceito:
A XSLT permite a conversão eficiente de documentos XML em um número de
diferentes formatos de saída. O conjunto de recursos XSLT facilitam a manipulação,
ordenação, e filtragem dos dados do documento XML para fornecer visões e extrações
alternativas da informação para qualquer número de cenários de transformação de
documentos.
Segundo Harold (2004), um processador XSLT lê tanto um documento XML de
entrada como uma XSLT stylesheet (que é em si um documento XML porque XSLT é uma
aplicação XML) e produz uma árvore de resultado como saída. Esta árvore de resultado pode
então ser serializada em um arquivo ou ser escrita sobre um stream. Os documentos podem ser
transformados usando um programa autônomo ou como parte de um programa maior que se
comunica com o processador XSLT através da sua API.
2.3.1.3 Simple Object Access Protocol (SOAP)

15. 13
O protocolo SOAP especifica as regras de uso da XML para empacotar mensagens, por
exemplo, para suportar um protocolo de requisição e resposta.
De acordo com Josuttis (2007), SOAP foi o primeiro padrão real de WS que foi
desenvolvido. Originalmente SOAP era acrônimo de “Simple Object Access Protocol”.
Entretanto, notou­se que SOAP não era simples e que não se tratava de acesso a objetos.
Mesmo assim o acrônimo tem resistido.
Pulier (2006) afirma que SOAP é a linguagem mais usada em WS, a estrutura XML na
qual todas as mensagens dos WS são construídas. Quando se diz que WS são baseados no
XML, na verdade se quer dizer que WS são baseados em mensagens SOAP, que são escritas
em XML. O que torna SOAP especial e o difere do simples XML é que cada mensagem SOAP
segue um padrão que foi especificado pelas normas da W3C.
SOAP é algumas vezes referida como um “envelope de dados”. Cada mensagem SOAP
começa com uma tag que lê <SOAP­ENV:envelope>. A tag envelope sinaliza a mensagem ao
destinatário que ele está prestes a receber uma mensagem SOAP. O que se segue é um
cabeçalho, que contem a informação crítica sobre onde as mensagens estão indo e de quem
elas vem. E depois, há o corpo da mensagem SOAP, que define o dado atual ou instruções de
operação exigidos pelo computador consumidor.
Uma mensagem SOAP é formatada como um “envelope” de código XML que define o
seu início e fim. O “cabeçalho” descreve de onde a mensagem veio, para onde ela está indo, e
como ela está indo. O “corpo” da mensagem SOAP contém os dados pertinentes ou instruções
processuais do pedido de resposta SOAP.

16. 14
Figura 01 Mensagem SOAP, Garcia, Matias e Garcia (2008)
A figura acima mostra uma mensagem SOAP completa, com “envelope” e corpo,
viajando através da rede de um computador consumidor de um WS para um computador
provedor, nesse caso, um mainframe.
2.3.1.4 Web Services Description Language (WSDL)
Segundo Pulier (2006), para descrever­se para o mundo exterior, cada WS tem um
documento WSDL que fornece ao potencial consumidor do serviço uma explicação de como o
serviço funciona e como acessá­lo. O WSDL descreve como criar uma solicitação SOAP que
irá invocar aquele WS específico. Se um desenvolvedor de software pretende criar um
programa do software consumidor de WS, tudo que ele necessita é este documento descritivo.
A WSDL fornece todas as informações que o desenvolvedor necessita para criar um programa
que requisite um WS. Isto significa que os desenvolvedores podem criar WS consumidores
sem nunca ter conhecido ou falado com o desenvolvedor que criou o WS em questão.
2.3.1.5 Universal Description, Discovery and Integration (UDDI)
UDDI foi como afirma Josuttis (2007), parte de um conceito ainda mais amplo,
“Universal Description, Discovery, and Integration Business Registry” (UBR). A idéia
original era a de introduzir os três papéis de um mercado de trabalho: provedores de serviços,
os consumidores que necessitam de serviços, e corretores que os juntam os dois anteriores
através da publicidade e localização de serviços.
Pulier (2006) exemplifica o conceito dizendo que o UDDI seria como uma espécie de
“páginas amarelas” dos WS. Se você quer encontrar um serviço web em sua empresa, você
deve olhar no UDDI. O UDDI iria dizer­lhe onde encontrar esse serviço, e ele ligaria você ao

17. 15
documento WSDL para que você possa examinar o WS e certificar­se que ele era o que você
queria.
2.3.1.6. Arquitetura REST
Recentemente veio à atenção pública uma alternativa aos Web Services, o chamado
REST (Reprensentational State Tranfer). Segundo Josuttis (2007), ele se refere a uma coleção
de princípios de arquitetura de rede que foca no acesso simples e sem armazenar o estado aos
recursos, o que pode ser considerado como um princípio chave de design que ajudou a
Internet a crescer.
2.3.1.6.1. REpresentational State Transfer (REST)
RESTful HTTP, o que é geralmente usado como sinônimo de REST, usa os quatro
métodos fundamentais do protocolo HTTP:
● GET
● PUT
● POST
● DELETE
Estes métodos são utilizados para ler, escrever, criar e deletar recursos identificados
por URLs. Devido a seu uso nativo do protocolo HTTP, REST é simples e rápido. Esta
característica se mostra uma boa maneira de prover acesso a dados ou recursos
disponibilizados por web servers, incluindo suporte técnico inerente para requisitos típicos,
como o caching.
Entretanto, Josuttis (2007) conclui que devido a sua falta de suporte para aspectos de
segurança, atributos não funcionais, composição, entre outros, dificilmente REST pode ser
usado como protocolo principal para uma infraestrutura sofisticada de SOA com serviços de

18. 16
processos, orquestação, e cenários onde serviços de leitura têm diferente granularidade do que
serviços de escrita.
2.3.1.6.2. Web Application Description Language (WADL)
A WADL (Web Application Description Language) é um vocabulário XML usado para
descrever web services RESTful. Como a WSDL, um cliente genérico pode carregar um
arquivo WADL e ser imediatamente equipado para acessar todas as funcionalidades do
correspondente web service.
Como os serviços RESTful têm interfaces simples, aWADL quase não é necessária
para estes serviços em comparação como uma WSDL é para serviços SOAP RPC.
2.4. Um exemplo de web service – cobredireto
2.4.1. Sobre o COBREDIRETO
O CobreDireto é um gateway de pagamentos on­line, ou seja, um sistema que integra
lojas virtuais com instituições financeiras para que tais lojas possam receber pagamentos de
seus clientes por diversos meios: cartões de crédito e débito, boleto bancário etc, sem
intermediação financeira.
Os valores pagos pelos clientes são transferidos para a conta bancária da loja virtual,
sem a necessidade de realizar saques nem pagar por operações de resgate.
A figura abaixo mostra de maneira geral, como ocorre esse funcionamento:

19. 17
Figura 02 ­ Como funciona o CobreDireto.
Fonte: http://www.cobredireto.com.br/como­funciona/
O Fluxo que um pagamento segue no CobreDireto está descrito abaixo. O fluxo padrão
é determinado pela integração via Webservice.
Para simplificar a integração entre a loja virtual e o CobreDireto, são disponibilizadas
Bibliotecas e Conectores para plataformas de e­commerce. Ao fazer uso desses bibliotecas/
conectores, o fluxo do pagamento fica reduzido conforme quadro abaixo, facilitando a
comunicação entre a loja e o gateway de pagamentos.
2.4.2. Fluxo do Pagamento – Padrão (WEB SERVICES)
Figura 03 – Fluxo de Pagamento – PADRÃO (Web Services).

20. 18
Fonte: http://www.cobredireto.com.br/integracao/visao­geral/
1. Criação do Pedido: A criação do Pedido no CobreDireto ocorre quando o cliente
terminou de preencher o carrinho de compras da loja e decide pagar. Nesse momento, a
loja virtual envia para o CobreDireto os dados da compra (dados do pedido e dados do
usuário). Esse envio é feito usando o webservice do CobreDireto.
2. URL hash: A resposta para Criação do Pedido é uma URL para a qual a Loja Virtual
deve redirecionar o cliente para continuar o processo de compra no ambiente do
CobreDireto.
3. Redirecionamento do Usuário: Uma vez que a loja virtual redirecionou o cliente, este
insere os dados de pagamento da sua compra. O CobreDireto captura esses dados e os
envia à Instituição Financeira.
4. Processamento e Retorno do Pagamento: A Instituição Financeira recebe os dados da
transação (Dados do Pedido, dados do usuário e dados do pagamento). Em seguida, é
dada ao CobreDireto a resposta com o status e identificação do pagamento.
5. Campainha: Após o processamento do pagamento e retorno da Instituição Financeira, o
CobreDireto avisará através de uma campainha (chamada POST) que houve uma
mudança de status do pedido.
6. Consulta do Pedido: Até a efetivação do pagamento, o status do pedido pode mudar
diversas vezes. A cada toque da campainha, a loja deve acessar o webservice do
CobreDireto para verificar o novo status do pedido. Esse status é importante porque ele
é o indicador do sucesso ou do fracasso da compra.
7. Redirecionamento do usuário: Ao final do processo de compra o usuário é enviado
novamente à loja que, tendo recebido o status através do processo de atendimento da
campainha, exibirá um recibo da compra ou, caso o status não seja “PAGO”, uma
mensagem de erro.
2.4.3. Fluxo do Pagamento – Bibliotecas/Conectores

21. 19
Figura 04 – Fluxo do Pagamento – Bibliotecas / Conectores
Fonte: http://www.cobredireto.com.br/integracao/visao­geral/
1. Criação do Pedido: A criação do Pedido no CobreDireto ocorre quando o cliente
termina de preencher o carrinho de compras da loja e decide realizar o pagamento.
Nesse momento, a loja virtual envia para o CobreDireto os dados da compra (dados do
pedido e dados do usuário). O envio dessas informações deve ocorrer dentro do padrão
especificado para cada biblioteca ou conector da loja virtual.
2. Processamento do Pagamento: após a coleta dos dados de pagamento no CobreDireto,
o gateway de pagamentos envia os dados para a Instituição Financeira. Em seguida, é
dada ao CobreDireto a resposta com o status e identificação do pagamento.
3. Status do Pedido e Redirecionamento do usuário: O retorno para a loja é facilitado com
a utilização das bibliotecas/conectores. Após receber o status do pedido, conforme
configurações inseridas na biblioteca/conector da loja, será exibido ao usuário um
recibo da compra ou, caso o status não seja “PAGO”, uma mensagem de erro.
2.4.3.1 Integração do COBREDIRETO com o WEB SERVICE

22. 20
O padrão utilizado pelo webservice do CobreDireto é o SOAP e existe apenas um
método disponível: o método doService. Os parâmetros que ele recebe são:
Version: a versão do webservice utilizado pela loja virtual. A instrução do CobreDireto
é que se use “1.1.0”.
Action: “payOrder” para criar um pedido e “probe” para consultar o status..
Merchant: o código da loja no CobreDireto
User: o login da loja no CobreDireto
Password: a senha da loja no CobreDireto
Data: um XML com os dados necessários para a ação solicitada.
O método doService retorna uma variável doServiceReturn com uma string XML.
Detalharemos mais a frente o XML enviado no parâmetro “Data” e recebido no retorno do
método.
2.4.3.2 Criando o Pedido
Para a criação do pedido, na chamada do SOAP o action deve ser “payOrder” e o XML
a ser enviado no parâmetro Data.
O XML deve seguir uma estrutura pré­definida, conforme demonstrado abaixo:
<payOrder>
<order_data>
Informações do Pedido
</order_data>
<behavior_data>
Configuração de URLs para retorno
</behavior_data>
<payment_data>
Informações sobre o Pagamento
</payment_data>
<customer_data>

23. 21
Informações do Comprador
</customer_data>
</payOrder>
order_data: onde estarão todos os dados do pedido;
behavior_data: possui as configurações das URL’s de recibo, erro e retorno;
payment_data: possui as configurações de pagamento;
customer_data: possui as informações do consumidor, entrega e cobrança.
Sendo assim, o XML deve ficar de maneira semelhante a esta:
<payOrder>
<order_data>
<merch_ref>número do pedido</merch_ref>
<tax_freight>Valor do frete</tax_freight>
<order_subtotal>Subtotal do pedido</order_subtotal>
<order_total>Total do pedido</order_total>
<order_items>
<!­­ Os items do pedido serão descritos aqui,
e cada um deles deve ser separado dentro de uma tag
'order_item' ­­>
<order_item>
<code>Código do item</code>
<description>Descrição do item</description>
<units>Quantidade do item</units>
<unit_value>Valor unitário do item</unit_value>
</order_item>
</order_items>
</order_data>
<behavior_data>
<url_post_bell>URL de retorno, para onde será enviada a
campainha</url_post_bell>
<url_redirect_success>URL em caso de sucesso,normalmente o
recibo</url_redirect_success>
<url_redirect_error>URL para o caso de algum erro durante a
transação</url_redirect_error>
</behavior_data>
<payment_data>

24. 22
<payment>
<payment_method>Meio de pagamento</payment_method>
<installments>Quantidade de Parcelas</installments>
</payment>
</payment_data>
<customer_data>
<customer_info>
<first_name>Primeiro nome</first_name>
<middle_name>Nome do meio</middle_name>
<last_name>Último nome</last_name>
<email>Email válido</email>
<document>Documento, normalmente o CPF</document>
<phone_home>
<area_code>Código DDD</area_code>
<phone_number>O telefone sem o hifen</phone_number>
</phone_home>
<address_zip>CEP sem o hifen</address_zip>
</customer_info>
<billing_info>
Informações de cobrança
</billing_info>
<shipment_info>
Informações de entrega
</shipment_info>
</customer_data>
</payOrder>
Com toda a estrutura do payOrder montada, basta requisitar o SOAP passando o
payOrder no campo data. Feito isso, o webservice do CobreDireto retornará a variável
doServiceReturn. Nela estará contida um XML com a seguinte estrutura:
<payOrder>
<status>Status da comunicação, o status do pedido deve ser
visto dentro de bpag_data.status</status>
<msg></msg>
<bpag_data>
<status>Status do Pedido</status>
<msg></msg>
<url>URL para redirecionamento</url>

25. 23
<id>Código do pedido no CobreDireto</id>
</bpag_data>
</payOrder>
Após obter esse retorno, a loja deve redirecionar o cliente para a URL recebida. Lá ele
verá a tela de pagamento. A cada mudança de status do pagamento, a loja será avisada pelo
CobreDireto através da campainha.
2.4.3.3 Retorno do Pagamento
O CobreDireto a cada mudança da transação irá chamar a campainha para verificar se o
produto ainda está disponivel. Através da URL configurada no ‘behavior_data’ em
‘url_post_bell’ o CobreDireto envia via POST as seguintes informações:
● merchant ­ O código da loja no CobreDireto
● merch_ref ­ O código do pedido na loja
● id ­ O código do pedido no CobreDireto
Com essas informações, deve ser gerado um XML avisando ao CobreDireto se está
tudo em ordem com os itens do pedido. Caso contrário, o CobreDireto irá cancelar o
pagamento. No retorno deverá ser enviado um numero inteiro no status, onde 1 indica
’sucesso’ e qualquer outro número indicará falha.
Segue o XML:
<bell>
<status>Numero inteiro</status>
<msg>Uma mensagem curta de até 256 caracteres</msg>
</bell>
2.4.3.4. Probe

26. 24
Ao receber a campainha você deverá fazer uma requisição SOAP, passando no
parâmetro action o valor ‘probe’. O XML a ser enviado no parâmetro data terá o seguinte
formato:
<probe>
<merch_ref>Numero do pedido na loja</merch_ref>
<id>Numero do pedido no CobreDireto</id>
</probe>
O webservice retornará um XML, contendo o status do pedido naquele momento.
<probe>
<status>Status da comunicação, o status do pedido deve ser
visto dentro de order_data.bpag_data.status</status>
<msg></msg>
<order_data>
<bpag_data>
<status>Status do Pedido</status>
<msg></msg>
<url>URL para redirecionamento</url>
<id>Número do pedido no CobreDireto</id>
</bpag_data>
</order_data>
</probe>
STATUS DO
PEDIDO
CÓDIGO SIGNIFICADO DESCRIÇÃO
0 Pago Pedido pago com sucesso.
1 Não Pago Comprador finaliza pagamento sem sucesso e o
pedido é dado como terminado pela instituição
financeira.

27. 25
2 Inválido Este status acontece quando a transação não pode
mais ser processada pelo CobreDireto. Esta mudança
pode ocorrer por regras da própria loja ou por ação
manual via painel de controle do CobreDireto.
3 Cancelado (Estornado) Pagamento cancelado.
4 Não Efetivado Este é o status inicial do pedido.
5 Pendente de Saldo Ocorre quando o comprador não tem saldo suficiente
em sua conta bancária.
7 Pendente de Pagamento Ocorre quando a instituição financeira está
aguardando o pagamento. Ocorre para métodos de
pagamento via boleto ou para débito Real entre as 0h
e 7h.
10 Pago Parcialmente Ocorre quando o comprador pagou valor inferior ao
valor total do pedido. Geralmente isto ocorre quando
o usuário tenta fraudar o pagamento de boletos ou
quando o usuário capturar a transação para ele seja
efetivamente cobrada.
Tabela 01 – Status do Pedido no CobreDireto.
Fonte: http://www.cobredireto.com.br/integracao/integracao­via­webservices/retorno­
do­pagamento/

28. 26
CAPÍTULO 3: SGE SISTEMA DE GESTÃO DE ESCOLAS
Para uma melhor percepção sobre o assunto WEB Services, propôs­se criar um projeto
para exemplificação. Este capítulo irá abordar o tema no Estudo de Caso proposto: SGE e SGE
Cliente, e explicar a arquitetura utilizada no mesmo.
3.1. ESTUDO DE CASO SGE e SGE CLIENTE
O projeto do Estudo de Caso é o serviço de fornecimento de informações sobre as
escolas da Rede Municipal de Campos dos Goytacazes / RJ, provido pelo SGE – Sistema de
Gestão de Escolas.
O SGE é um WEB Service que provê dados reais sobre as escolas da Rede Municipal
da cidade de Campos, como nome das mesmas e endereço. As informações contidas neste
sistema podem ser acessadas pelo cliente SGE Cliente que é um software que lê as
informações fornecidas pelo SGE.
A figura abaixo demonstra a visão do servidor de informações das escolas, o SGE.

29. 27
Figura 05 – Visualização da página do Servidor WEB SGE
A princípio o Cliente pode ler (Método GET) as informações, editar (Método PUT), ou
até mesmo excluir (Método DELETE) no SGE.
3.2. ARQUITETURA UTILIZADA
O SGE e o SGE Cliente foram desenvolvidos utilizando a seguinte arquitetura: Ruby,
Rails, Rest e Restfulie, que serão explicados a seguir.
3.2.1 Ruby
A linguagem utilizada no SGE e no SGE Cliente é a linguagem Ruby. De acordo com
os sites oficiais do Ruby: http :// www . ruby ­ lang . org / pt / sobre ­ o ­ ruby e
http :// www . rubyonbr . org / articles /2006/08/24/ o ­ que ­ ruby / , essa linguagem foi criada em 1994 por
Yukihiro Matsumoto (Matz) e tornada pública em 1995. Ruby é uma linguagem de código
aberto, é orientada a objetos e possui tipagem dinâmica e forte. Esta linguagem está disponível
para várias plataformas, e ainda pode ser executada sobre a máquina virtual java através do
JRuby.
Algumas características importantes da linguagem Ruby: todas as variáveis e “tipos
primitivos” são objetos; de forma parecida ao comando APT do Debian Linux, pode­se
instalar e atualizar bibliotecas da linguagem através do RubyGems, que é um gerenciador de
pacotes para Ruby; tipagem dinâmica, porém forte; blocos de códigos que podem ser passados
como parâmetros para os métodos; Mixins, para herança múltipla; entre outras.
Atualmente várias histórias de sucessos de grandes empresas e organizações que
utilizam Ruby em suas aplicações, como por exemplo: a Motorola, que utilizou Ruby para
escrever um simulador para gerar casos de cenário e para processar esses mesmos dados; a

30. 28
NASA Langley Research Center que utiliza Ruby para simulações; a Level 3 Communications
em um sistema de Planejamento e Capacidade Unix que recolhe estatísticas de performances
de servidores Unix espalhados ao redor do mundo; entre outras empresas e organizações.
(referência: http :// www . ruby ­ lang . org / pt / documentacao / historias ­ de ­ sucesso / )
3.2.2 Rails
O Rails, ou Ruby on Rails, também conhecido por RoR, é um Framework de
Desenvolvimento Web gratuito e Open Source. Este Framework é escrito na linguagem Ruby,
e utiliza a estrutura do padrão MVC – Model­View­Controller. Um dos destaques do Rails é a
facilidade de desenvolvimento e compreensão, pois favorece a convenção ao invés da
configuração aumentando assim a produtividade. O Rails também é definido como um meta­
framework, pois é a junção de 5 frameworks, que são: Active Records, camada responsável
pela interoperabilidade entre o banco e a aplicação; Action Pack, que compreende a geração de
visualização (Action View) e o controle de fluxo de negócio (Action Controller); Action
Mailer, que é o serviço responsável pelo envio e o recebimento de emails; Active Support, que
é uma coleção de classes e bibliotecas úteis ao desenvolvimento em Ruby on Rails; e Action
Web Services, que é um facilitador para a publicação de APIs interoperáveis com Rails,
implementa WSDL e SOAP. A partir da versão 2.0 do Rails, este módulo foi retirado devido a
implementação do modelo Rest, mas ainda há a possibilidade de se obter este recurso através a
instalação de um plugin.
Baseado em um dos projetos de David Heinemeier Hansson, o Rails foi criado por ele
em 2003, e lançado a público em julho de 2004. A partir de então passou a ser expandido pelo
time central do Rails (http :// rubyonrails . org / core ), e hoje conta com mais de 1400 contribuidores
pelo mundo.
Nos últimos anos houve um grande crescimento de adeptos ao uso do framework Rails,
e hoje já é possível encontrar diversas aplicações em todo o mundo que o utilizam, desde
pequenas operações até mesmo grandes corporações (http :// www . rubyonrails . pro . br / ). Como por

31. 29
exemplo o Twitter, o BlogBlogs, Git­Hub, Yellow Pages, SlideShare, Vote Bolsa, entre
outros.
3.2.3 Rest
REST ­ REpresentational State Transfer, ou Transferência de Estado Representacional.
Este termo foi proposto por Roy Fielding, um dos “criadores” do REST, em 2000 em uma tese
de doutorado. Originalmente este termo se referia a um conjunto de princípios de arquitetura,
porém atualmente é utilizado em sentido mais amplo para descrever qualquer interface web
mais simples que utiliza HTTP e XML. De uma maneira geral, são utilizados para integração
de aplicações diferentes, e pode ser entendido também como qualquer Web Service que pode
ser acessado através de uma requisição simples HTTP GET.
Nos últimos anos com os avanços da Web 2.0 o REST tem ganhado mais popularidade,
principalmente pelo uso de AJAX e Mashups. Estes serviços são normalmente acessados por
Javascript e como mecanismo de serialização utilizam o JSON. O REST tem como uma das
principais características utilização de vários recursos do HTTP para elaboração de protocolo
de comunicação claro e conciso. Pode­se citar alguns exemplos que motivam a implementação
de serviços com a utilização do REST, como protocolos menos complexos, mais poder e
flexibilidade nas comunicações, arquitetura amplamente disponível nas empresas, entre outros.
Mas também em alguns momentos pode ser aconselhável não utilizar o REST, como nas
integrações com produtos fechados WS­*, quando WS­Transaction fizer sentido, quando WS­
Security fizer sentido, ou quando não houver API HTTP razoável no servidor e/ou clientes­
alvo.
Estes são alguns dos princípios do REST: protocolo de Cliente­Servidor sem estado;
uso de hipermídia para transição de estado e para informação da aplicação, onde são utilizados
HTML ou XML para representação de estado de um sistema REST; sintaxe universal para
identificação de recursos, e direcionamento destes através de sua URI; aplicação, em todos os
recursos de informações, de um conjunto de operações bem definidas, como POST, GET, PUT

32. 30
e DELETE, onde frequentemente são combinadas com operações CRUD para a realização de
persistência de dados.
REST tem uma definição ampla e por isso pode­se dizer que existem várias aplicações
que utilizam esta estrutura na rede mundial de computadores, sendo possível encontrar­lo em
diferentes área da web. Alguns sites que utilizam conceitos de REST são: Amazon.com, aBay,
Bloglines, e ainda tem o Ruby on Rails que suporta REST com MVC, e o publicador de
objetos do Zope que também se baseia na arquitetura REST, entre outros.
3.2.4 Restfulie
O Restfulie foi criado e é mantido pela Caelum, tendo Guilherme Silveira como
fundador do projeto, e Lucas Cavalvanti e Adriano Almeida como os principais colaboradores.
O Restfulie foi originalmente criado como uma gem (biblioteca) para utilização com a
linguagem Ruby on Rails, mas também encontra­se disponível para utilização com outras
linguagens, como Java e C#, como mostra o site oficial do projeto.
Nem sempre é possível ter acesso a informação certa das possíveis utilizações de um
determinado recurso em seu estado atual. Pode ser necessário realizar várias requisições,
análise dos vários estados de um recurso, análise de parâmetros, entre outros. Caso seja
possível o acesso a informação mais exata sobre um recurso, o trabalho, ou seja, várias
análises e requisições seriam evitadas, pois seriam utilizadas apenas as operações relevantes
no momento. De acordo com estas observações, o Restfulie tem como função adicionar
informações em tempo real sobre o estado de um objeto solicitado, sobrescrevendo a geração
do XML padrão do Rails.

33. 31
CAPÍTULO 4: CONCLUSÕES
Com este estudo pôde ser observado algumas vantagens do uso dos Web Services nos
sistema distribuídos, assim como algumas desvantagens. Também foi desenvolvido um estudo
de caso do SGE e SGE Cliente, onde pode­se obter uma experiência real da aplicação de um
Web Service.
Pôde ser observada nesta pesquisa que atualmente os Web Services estão presentes em
aplicações de várias empresas visto a facilidade de comunicação entre aplicativos em
diferentes linguagens e/ou plataformas, o que facilita a interoperabilidade entre clientes e
servidores.
Como padrão mais utilizado, o SOAP apresenta como vantagem a sua independência
de plataforma, a facilidade de decodificação das mensagens trocadas, e possibilidade de ser
veiculado pela porta 80, entre outros. Mas também apresenta algumas desvantagens que
puderam ser percebidas, como não definir mecanismo para a criptografia do conteúdo de uma
mensagem, e não garantir a entrega da mensagem na transferência.
Já o REST é um padrão mais recente que o anterior e seu uso vem crescendo. Como
vantagem este padrão apresenta variados formatos para troca de informação de um mesmo
recurso, suporte a cache, uma arquitetura cliente­servidor com poucos requerimentos para o
lado cliente, entre outros. E algumas desvantagens identificadas no REST são o fato de seus
conversores serem considerados difíceis de implementar e menos flexíveis, por utilizar
requisições PUT a maioria dos proxies podem bloquear essas requisições.

34. 32
REFERÊNCIAS BIBLIOGRÁFICAS
COULOURIS, G., DOLLIMORE, J., KINBERG. Sistemas Distribuídos: Conceitos e Projetos.
4ª. edição. Bookmann, 2007.
SALES, Fábio de O., BARROS Kecyo S., “Solução de Integração entre Java, WEB
SERVICES E ANDROID, utilizando a arquitetura SOA”, Projeto Final de Graduação,
Universidade Católica de Salvador, BA, 2008.
SILVA, Alexandro N. da, “Composição Automática de Web Services: Avaliando os
planejadores JSHOP2 e JESS”, Projeto Final de Graduação, Universidade Federal da Bahia,
BA, 2007.
LINS, Fernando Antonio Aires, “Requisitos Não­Funcionais em WEB SERVICES”, Projeto
Final de Graduação, Universidade Federal de Pernambuco, 2008.
OLIVEIRA, Alex de, “Web Service para integração de aplicações que utilizam troca de
mensagens e controle de comunicação entre usuários”, Universidade Regional de Blumenau,
2007.
GARCIA, Leonardo Alvarenga; MATIAS, Thiago F. de M.; GARCIA, Tiago R. “Suporte da
Arquitetura Orientada a Serviços na Integração de Sistemas Médicos”, Universidade Federal
de Itajubá – UNIFEI, 2008.
MORO, Tharcis Dal,; DORNELES, Carina F,; REBONATTO, Marcelo T. “Web services WS­
* versus Web Services REST”, Instituto de Ciências Exatas e Geociências ­ Universidade de
Passo Fundo (UPF), RS.

35. 33
MARTINS, Ricardo; ROCHA, Jorge; HENRIQUES, Pedro. “Segurança dos Web Services no
Comércio Eletrônico Móvel”, Universidade do Minho – Departamento de Informática –
Campus de Gualtar – Braga.
AGUIAR, Alexandra C. P. de, et. al. “Implementação de exemplos de uso de Web Services
como um tutorial”, Pontifícia Universidade Católica do Rio Grande do Sul ­ PUCRS, Porto
Alegre, RS.
http://www.cobredireto.com.br/#rmcl. Acessado em 13/09/2010.
http://www.cobredireto.com.br/integracao/visao­geral/. Acessado em 13/09/2010.
http://www.cobredireto.com.br/integracao/integracao­via­webservices/integracao/. Acessado
em 13/09/2010.
http://www.cobredireto.com.br/integracao/integracao­via­webservices/retorno­do­pagamento/.
Acessado em 13/09/2010.

36. 34
APÊNDICE: CÓDIGO DO SGE Cliente