INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA FLUMINENSEPÓS­GRADUAÇÃO LATO­SENSU EM ANÁLISE, PROJETO E GERENCIAMENTO...
DEIVISON LAMONICA BARRETOJULIANA DA SILVA CINDRAMARIANNA SIQUEIRA REISRAFAEL LEITE DE FREITASRAQUEL PEREIRA CRESPOSGE ­ SI...
DedicatóriaDedicado aos nossos colegas de turma.
Agradecemos a todos que contribuíram para a realização deste trabalho e, em especial: ao IFF Campus Campos­Centro, pela fo...
RESUMOSabemos que a tecnologia é algo que sofre mudanças constantemente. Tais mudanças trazem necessidades, que por sua ve...
ABSTRACTWe know that technology is something that changes constantly. Such changes bring needs, which in its turn need to ...
SUMÁRIO1. INTRODUÇÃO                                                                                                      ...
3.2.2 Rails                                                                                                               ...
7CAPÍTULO 1: INTRODUÇÃOCom   a   evolução   muito   rápida   das   tecnologias   utilizadas   no   desenvolvimento   de so...
8CAPÍTULO 2: WEB SERVICESEste capítulo mostra alguns conceitos e definições do tema deste trabalho, e um exemplo de Web Se...
9● Universal Discovery, Description, and Integration (UDDI) ­ O diretório do WS que está disponível para ser usado.Juntos ...
10Para Pulier (2006), WS funcionam em modo de “transparência de rede”, ou seja, como web sites na Internet, WS podem ser l...
11A XSD é uma implementação atual da linguagem XML;  schemas  são eles próprios documentos XML. Uma das mais importantes c...
12Cada prefixo é mapeado para uma URI (URI ­  Uniform Resource Identifier  ) da seguinte forma: xmlns:prefixo atributo. UR...
13O protocolo SOAP especifica as regras de uso da XML para empacotar mensagens, por exemplo, para suportar um protocolo de...
14Figura 01 Mensagem SOAP, Garcia, Matias e Garcia (2008)A figura acima mostra uma mensagem SOAP completa, com “envelope” ...
15documento WSDL para que você possa examinar o WS e certificar­se que ele era o que você queria.2.3.1.6. Arquitetura REST...
16processos, orquestação, e cenários onde serviços de leitura têm diferente granularidade do que serviços de escrita.2.3.1...
17Figura 02 ­ Como funciona o CobreDireto.Fonte: http://www.cobredireto.com.br/como­funciona/O Fluxo que um pagamento segu...
18Fonte: http://www.cobredireto.com.br/integracao/visao­geral/1. Criação do Pedido: A criação do Pedido no CobreDireto oco...
19Figura 04 – Fluxo do Pagamento – Bibliotecas / ConectoresFonte: http://www.cobredireto.com.br/integracao/visao­geral/1. ...
20O padrão utilizado pelo  webservice  do CobreDireto é o SOAP e existe apenas um método disponível: o método doService. O...
21      Informações do Comprador   </customer_data></payOrder>order_data: onde estarão todos os dados do pedido;behavior_d...
22         <payment>             <payment_method>Meio de pagamento</payment_method>             <installments>Quantidade d...
23      <id>Código do pedido no CobreDireto</id>   </bpag_data></payOrder>Após obter esse retorno, a loja deve redireciona...
24Ao   receber   a   campainha   você   deverá   fazer   uma   requisição   SOAP,   passando   no parâmetro  action o valo...
252 Inválido Este status acontece quando a transação não pode mais ser processada pelo CobreDireto. Esta mudança pode ocor...
26CAPÍTULO 3: SGE  SISTEMA DE GESTÃO DE ESCOLASPara uma melhor percepção sobre o assunto WEB Services, propôs­se criar um ...
27Figura 05 – Visualização da página do Servidor WEB SGEA princípio o Cliente pode ler (Método GET) as informações, editar...
28NASA Langley Research Center que utiliza Ruby para simulações; a Level 3 Communications em um sistema de Planejamento e ...
29exemplo o Twitter, o BlogBlogs, Git­Hub, Yellow Pages, SlideShare, Vote Bolsa, entre outros.3.2.3 RestREST ­ REpresentat...
30e DELETE, onde frequentemente são combinadas com operações CRUD para a realização de persistência de dados.REST tem uma ...
31CAPÍTULO 4: CONCLUSÕESCom este estudo pôde ser observado algumas vantagens do uso dos Web Services nos sistema distribuí...
32REFERÊNCIAS BIBLIOGRÁFICAS COULOURIS, G., DOLLIMORE, J., KINBERG. Sistemas Distribuídos: Conceitos e Projetos. 4ª. ediçã...
33MARTINS, Ricardo; ROCHA, Jorge; HENRIQUES, Pedro. “Segurança dos Web Services no Comércio Eletrônico Móvel”, Universidad...
34APÊNDICE: CÓDIGO DO SGE Cliente
Próximos SlideShares
Carregando em…5
×

Trabalho de Sistemas Distribuídos

1.268 visualizações

Publicada em

Trabalho sobre Web Services.

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.268
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Trabalho de Sistemas Distribuídos

  1. 1. INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA FLUMINENSEPÓ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 ServicesDEIVISON LAMONICA BARRETOJULIANA DA SILVA CINDRAMARIANNA SIQUEIRA REISRAFAEL LEITE DE FREITASRAQUEL PEREIRA CRESPOCampos dos Goytacazes/RJSetembro de 2010
  2. 2. DEIVISON LAMONICA BARRETOJULIANA DA SILVA CINDRAMARIANNA SIQUEIRA REISRAFAEL LEITE DE FREITASRAQUEL PEREIRA CRESPOSGE ­ SISTEMA DE GESTÃO DE ESCOLAS e SGE CLIENTE: Um Estudo Sobre Web ServicesMonografia 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 MouraCampos dos Goytacazes/RJSetembro de 2010
  3. 3. DedicatóriaDedicado aos nossos colegas de turma.
  4. 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. 5. RESUMOSabemos 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. 6. ABSTRACTWe 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. 7. SUMÁRIO1. 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. 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. 9. 7CAPÍTULO 1: INTRODUÇÃOCom   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. 10. 8CAPÍTULO 2: WEB SERVICESEste 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çõesOs  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. 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 servicesWeb 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 AcoplamentoEm 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. 12. 10Para 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 DefinitionPara 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. 13. 11A 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 NamespaceHarold (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. 14. 12Cada 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. 15. 13O 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. 16. 14Figura 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. 17. 15documento WSDL para que você possa examinar o WS e certificar­se que ele era o que você queria.2.3.1.6. Arquitetura RESTRecentemente 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● DELETEEstes 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. 18. 16processos, 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 – cobredireto2.4.1. Sobre o COBREDIRETOO 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. 19. 17Figura 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. 20. 18Fonte: 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. 21. 19Figura 04 – Fluxo do Pagamento – Bibliotecas / ConectoresFonte: 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. 22. 20O 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 CobreDiretoUser: o login da loja no CobreDiretoPassword: a senha da loja no CobreDiretoData: 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 PedidoPara 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. 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. 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. 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 PagamentoO 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 CobreDiretoCom 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. 26. 24Ao   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 PEDIDOCÓDIGO SIGNIFICADO DESCRIÇÃO0 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. 27. 252 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. 28. 26CAPÍTULO 3: SGE  SISTEMA DE GESTÃO DE ESCOLASPara 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 CLIENTEO 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. 29. 27Figura 05 – Visualização da página do Servidor WEB SGEA 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 UTILIZADAO 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 RubyA 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. 30. 28NASA 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 RailsO   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. 31. 29exemplo o Twitter, o BlogBlogs, Git­Hub, Yellow Pages, SlideShare, Vote Bolsa, entre outros.3.2.3 RestREST ­ 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. 32. 30e 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 RestfulieO 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. 33. 31CAPÍTULO 4: CONCLUSÕESCom 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. 34. 32REFERÊ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. 35. 33MARTINS, 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. 36. 34APÊNDICE: CÓDIGO DO SGE Cliente

×