SlideShare uma empresa Scribd logo
1 de 36
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
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
Dedicatória
Dedicado 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 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.
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.
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.
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   
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   
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.
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.
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
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.
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.
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)
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.
                        
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 
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 
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:
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).
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
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
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>
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>
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>
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
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.
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/
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.
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 
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 
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 
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.
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.
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.
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.
34
APÊNDICE: CÓDIGO DO SGE Cliente

Mais conteúdo relacionado

Mais procurados

Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)Leinylson Fontinele
 
Gerencia e Administração de Redes
Gerencia e Administração de RedesGerencia e Administração de Redes
Gerencia e Administração de RedesAllan Piter Pressi
 
Sistemas Distribuídos - Aula 07 - Servicos Web
Sistemas Distribuídos - Aula 07 - Servicos WebSistemas Distribuídos - Aula 07 - Servicos Web
Sistemas Distribuídos - Aula 07 - Servicos WebArthur Emanuel
 
Redes de computadores
Redes de computadoresRedes de computadores
Redes de computadoresJakson Silva
 
Arquitetura de software : Cliente-Servidor
Arquitetura de software : Cliente-ServidorArquitetura de software : Cliente-Servidor
Arquitetura de software : Cliente-ServidorAlexsandro Oliveira
 
Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)
Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)
Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)Leinylson Fontinele
 
Multimídia: Protocolos de transmissão de áudio e vídeo
Multimídia:  Protocolos de transmissão de áudio e vídeoMultimídia:  Protocolos de transmissão de áudio e vídeo
Multimídia: Protocolos de transmissão de áudio e vídeoFernando Costa
 
Apresentação de Redes
Apresentação de RedesApresentação de Redes
Apresentação de RedesCDP_Online
 
222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidores222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidoresMarco Guimarães
 
Redes de Computadores
Redes de ComputadoresRedes de Computadores
Redes de ComputadoresFábio Eliseu
 
Sistemas operacionais
Sistemas operacionaisSistemas operacionais
Sistemas operacionaisAbnel Junior
 
Sistema operacional introdução
Sistema operacional introduçãoSistema operacional introdução
Sistema operacional introduçãoCleber Ramos
 

Mais procurados (20)

Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
 
Gerencia e Administração de Redes
Gerencia e Administração de RedesGerencia e Administração de Redes
Gerencia e Administração de Redes
 
Sistemas Distribuídos - Aula 07 - Servicos Web
Sistemas Distribuídos - Aula 07 - Servicos WebSistemas Distribuídos - Aula 07 - Servicos Web
Sistemas Distribuídos - Aula 07 - Servicos Web
 
Redes de computadores
Redes de computadoresRedes de computadores
Redes de computadores
 
Projeto de Rede Local (LAN)
Projeto de Rede Local (LAN)Projeto de Rede Local (LAN)
Projeto de Rede Local (LAN)
 
Arquitetura de software : Cliente-Servidor
Arquitetura de software : Cliente-ServidorArquitetura de software : Cliente-Servidor
Arquitetura de software : Cliente-Servidor
 
Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)
Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)
Sistemas Operacionais - Aula 08 (Sincronização e Comunicação entre Processos)
 
Virtualização
VirtualizaçãoVirtualização
Virtualização
 
Roteadores e roteamento
Roteadores e roteamentoRoteadores e roteamento
Roteadores e roteamento
 
Sistemas operacionais
Sistemas operacionaisSistemas operacionais
Sistemas operacionais
 
Computação em nuvem
Computação em nuvemComputação em nuvem
Computação em nuvem
 
Multimídia: Protocolos de transmissão de áudio e vídeo
Multimídia:  Protocolos de transmissão de áudio e vídeoMultimídia:  Protocolos de transmissão de áudio e vídeo
Multimídia: Protocolos de transmissão de áudio e vídeo
 
Apresentação de Redes
Apresentação de RedesApresentação de Redes
Apresentação de Redes
 
222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidores222097384 aulas-de-rede-tipos-de-servidores
222097384 aulas-de-rede-tipos-de-servidores
 
Computação em Nuvem
Computação em NuvemComputação em Nuvem
Computação em Nuvem
 
Apresentação redes
Apresentação redesApresentação redes
Apresentação redes
 
Redes de Computadores
Redes de ComputadoresRedes de Computadores
Redes de Computadores
 
Virtualização - Máquinas Virtuais
Virtualização - Máquinas VirtuaisVirtualização - Máquinas Virtuais
Virtualização - Máquinas Virtuais
 
Sistemas operacionais
Sistemas operacionaisSistemas operacionais
Sistemas operacionais
 
Sistema operacional introdução
Sistema operacional introduçãoSistema operacional introdução
Sistema operacional introdução
 

Destaque

Aula 2 introdução a sistemas distribuídos
Aula 2   introdução a sistemas distribuídosAula 2   introdução a sistemas distribuídos
Aula 2 introdução a sistemas distribuídosEduardo de Lucena Falcão
 
Sistemas distribuidos intro
Sistemas distribuidos  introSistemas distribuidos  intro
Sistemas distribuidos introOscar Quiroz
 
Performance Management of IT Service Processes Using a Mashup-based Approach
Performance Management of IT Service Processes Using a Mashup-based ApproachPerformance Management of IT Service Processes Using a Mashup-based Approach
Performance Management of IT Service Processes Using a Mashup-based ApproachCarlos Raniery
 
Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...
Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...
Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...Carlos Raniery
 
De Web Services RESTful a Aplicações Mashup
De Web Services RESTful a Aplicações MashupDe Web Services RESTful a Aplicações Mashup
De Web Services RESTful a Aplicações MashupWagner Roberto dos Santos
 
Sistemas Distribuidos Arquitectura XML SOA Middleware Web Services
Sistemas Distribuidos Arquitectura XML SOA Middleware Web ServicesSistemas Distribuidos Arquitectura XML SOA Middleware Web Services
Sistemas Distribuidos Arquitectura XML SOA Middleware Web ServicesJulio Pari
 
Sistemas de Informações Gerenciais - Aula4
Sistemas de Informações Gerenciais - Aula4Sistemas de Informações Gerenciais - Aula4
Sistemas de Informações Gerenciais - Aula4Leandro Rezende
 
Sistemas Distribuídos - Comunicação Distribuída – Middleware
Sistemas Distribuídos - Comunicação Distribuída – MiddlewareSistemas Distribuídos - Comunicação Distribuída – Middleware
Sistemas Distribuídos - Comunicação Distribuída – MiddlewareAdriano Teixeira de Souza
 
Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Arthur Emanuel
 
Sistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na WebSistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na WebRafael Chagas
 
1ª lista de exercícios de pesquisa operacional com gabarito
1ª lista de exercícios de pesquisa operacional   com gabarito1ª lista de exercícios de pesquisa operacional   com gabarito
1ª lista de exercícios de pesquisa operacional com gabaritoAntonio Rodrigues
 
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...Marcelo Schumacher
 

Destaque (14)

Aula 2 introdução a sistemas distribuídos
Aula 2   introdução a sistemas distribuídosAula 2   introdução a sistemas distribuídos
Aula 2 introdução a sistemas distribuídos
 
Mashups - SOA
Mashups - SOAMashups - SOA
Mashups - SOA
 
Sistemas distribuidos intro
Sistemas distribuidos  introSistemas distribuidos  intro
Sistemas distribuidos intro
 
Performance Management of IT Service Processes Using a Mashup-based Approach
Performance Management of IT Service Processes Using a Mashup-based ApproachPerformance Management of IT Service Processes Using a Mashup-based Approach
Performance Management of IT Service Processes Using a Mashup-based Approach
 
Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...
Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...
Mashups e Modelagem Quantitativa Usando Padrões de Mashup com foco no Gerenci...
 
De Web Services RESTful a Aplicações Mashup
De Web Services RESTful a Aplicações MashupDe Web Services RESTful a Aplicações Mashup
De Web Services RESTful a Aplicações Mashup
 
Sistemas Distribuidos Arquitectura XML SOA Middleware Web Services
Sistemas Distribuidos Arquitectura XML SOA Middleware Web ServicesSistemas Distribuidos Arquitectura XML SOA Middleware Web Services
Sistemas Distribuidos Arquitectura XML SOA Middleware Web Services
 
Sistemas de Informações Gerenciais - Aula4
Sistemas de Informações Gerenciais - Aula4Sistemas de Informações Gerenciais - Aula4
Sistemas de Informações Gerenciais - Aula4
 
Sistemas Distribuídos - Comunicação Distribuída – Middleware
Sistemas Distribuídos - Comunicação Distribuída – MiddlewareSistemas Distribuídos - Comunicação Distribuída – Middleware
Sistemas Distribuídos - Comunicação Distribuída – Middleware
 
Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02Sistemas Distribuídos - Aula 02
Sistemas Distribuídos - Aula 02
 
Aula 6 - Gerenciamento de Escopo
Aula 6 - Gerenciamento de EscopoAula 6 - Gerenciamento de Escopo
Aula 6 - Gerenciamento de Escopo
 
Sistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na WebSistemas Distribuídos baseados na Web
Sistemas Distribuídos baseados na Web
 
1ª lista de exercícios de pesquisa operacional com gabarito
1ª lista de exercícios de pesquisa operacional   com gabarito1ª lista de exercícios de pesquisa operacional   com gabarito
1ª lista de exercícios de pesquisa operacional com gabarito
 
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
 

Semelhante a Trabalho de Sistemas Distribuídos

A expansão do PHP no governo brasileiro
A expansão do PHP no governo brasileiroA expansão do PHP no governo brasileiro
A expansão do PHP no governo brasileiroFlávio Lisboa
 
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...João Gabriel Lima
 
APRESETACAO Tratibo.ppt
APRESETACAO  Tratibo.pptAPRESETACAO  Tratibo.ppt
APRESETACAO Tratibo.pptSaryfa
 
201406Carvalho
201406Carvalho201406Carvalho
201406CarvalhoAfonso Pra
 
TCC Tecnologia em Sistemas para Internet
TCC Tecnologia em Sistemas para InternetTCC Tecnologia em Sistemas para Internet
TCC Tecnologia em Sistemas para InternetClaudeir Novais
 
Intranet Social na Aprendizagem organizacional: um estudo de caso na ANS
Intranet Social na Aprendizagem organizacional: um estudo de caso na ANSIntranet Social na Aprendizagem organizacional: um estudo de caso na ANS
Intranet Social na Aprendizagem organizacional: um estudo de caso na ANSColaborativismo
 
Relatório Semestral - PIBITI - Allan Victor
Relatório Semestral - PIBITI - Allan Victor Relatório Semestral - PIBITI - Allan Victor
Relatório Semestral - PIBITI - Allan Victor allannvictor
 
UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...
UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...
UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...Eder Nogueira
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREKéllyson Gonçalves da Silva
 
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC. ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC. Maurício Mau
 
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...Felipe Nascimento
 
Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...
Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...
Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...Mauricio Cesar Santos da Purificação
 
2 sis cai sistema de controle de acesso a internet
2 sis cai sistema de controle de acesso a internet2 sis cai sistema de controle de acesso a internet
2 sis cai sistema de controle de acesso a internetricardo17754
 
Métricas - Lidec - Escola do Futuro
Métricas - Lidec - Escola do FuturoMétricas - Lidec - Escola do Futuro
Métricas - Lidec - Escola do FuturoDrica Guzzi
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalhoRuan Pozzebon
 
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...Rogério Batista
 

Semelhante a Trabalho de Sistemas Distribuídos (20)

A expansão do PHP no governo brasileiro
A expansão do PHP no governo brasileiroA expansão do PHP no governo brasileiro
A expansão do PHP no governo brasileiro
 
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
SISTEMA WEB PARA ADMINISTRAÇÃO, GERENCIAMENTO E SUPORTE À DECISÃO EM PROJETOS...
 
APRESETACAO Tratibo.ppt
APRESETACAO  Tratibo.pptAPRESETACAO  Tratibo.ppt
APRESETACAO Tratibo.ppt
 
Introdução a Programação Web
Introdução a Programação WebIntrodução a Programação Web
Introdução a Programação Web
 
201406Carvalho
201406Carvalho201406Carvalho
201406Carvalho
 
Petic Software
Petic SoftwarePetic Software
Petic Software
 
TCC Tecnologia em Sistemas para Internet
TCC Tecnologia em Sistemas para InternetTCC Tecnologia em Sistemas para Internet
TCC Tecnologia em Sistemas para Internet
 
Intranet Social na Aprendizagem organizacional: um estudo de caso na ANS
Intranet Social na Aprendizagem organizacional: um estudo de caso na ANSIntranet Social na Aprendizagem organizacional: um estudo de caso na ANS
Intranet Social na Aprendizagem organizacional: um estudo de caso na ANS
 
Relatório Semestral - PIBITI - Allan Victor
Relatório Semestral - PIBITI - Allan Victor Relatório Semestral - PIBITI - Allan Victor
Relatório Semestral - PIBITI - Allan Victor
 
UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...
UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...
UTILIZANDO O FRAMEWORK JBOSS SEAM PARA ACELERAR O DESENVOLVIMENTO DE APLICAÇÕ...
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
 
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC. ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
ESTUDO PARA FUTURA IMPLANTAÇÃO DO PACOTE DE APLICATIVOS BROFFICE.ORG NO TRE-SC.
 
Artigo jad utfpr
Artigo jad utfprArtigo jad utfpr
Artigo jad utfpr
 
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
TCC - Utilização de Metodologias Ágeis para Adaptação de um Processo de Desen...
 
Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...
Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...
Projeto SIAC 2.0 Uma aplicação do framework Demoiselle para o desenvolvimento...
 
2 sis cai sistema de controle de acesso a internet
2 sis cai sistema de controle de acesso a internet2 sis cai sistema de controle de acesso a internet
2 sis cai sistema de controle de acesso a internet
 
Métricas - Lidec - Escola do Futuro
Métricas - Lidec - Escola do FuturoMétricas - Lidec - Escola do Futuro
Métricas - Lidec - Escola do Futuro
 
Projeto 5 Doc
Projeto 5 DocProjeto 5 Doc
Projeto 5 Doc
 
Metodologias ágeis de desenvolvimento trabalho
Metodologias ágeis de desenvolvimento   trabalhoMetodologias ágeis de desenvolvimento   trabalho
Metodologias ágeis de desenvolvimento trabalho
 
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
O uso de frameworks em aplicações desktop baseadas na metodologia de desenvol...
 

Mais de Juliana Cindra

Dru - Desenvolvimento para Reuso
Dru - Desenvolvimento para ReusoDru - Desenvolvimento para Reuso
Dru - Desenvolvimento para ReusoJuliana Cindra
 
Trabalho de Reengenharia de Software
Trabalho de Reengenharia de SoftwareTrabalho de Reengenharia de Software
Trabalho de Reengenharia de SoftwareJuliana Cindra
 
Fermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.BrFermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.BrJuliana Cindra
 
AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...
AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...
AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...Juliana Cindra
 
Exercicio de UML - Documentacao Restaurante
Exercicio de UML  - Documentacao RestauranteExercicio de UML  - Documentacao Restaurante
Exercicio de UML - Documentacao RestauranteJuliana Cindra
 
Padrões de Projeto - Observer
Padrões de Projeto - ObserverPadrões de Projeto - Observer
Padrões de Projeto - ObserverJuliana Cindra
 
Padrão de Projeto - Adapter
Padrão de Projeto - AdapterPadrão de Projeto - Adapter
Padrão de Projeto - AdapterJuliana Cindra
 
Fermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.BrFermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.BrJuliana Cindra
 

Mais de Juliana Cindra (12)

UM ESTUDO SOBRE SOA
UM ESTUDO SOBRE SOAUM ESTUDO SOBRE SOA
UM ESTUDO SOBRE SOA
 
Dru - Desenvolvimento para Reuso
Dru - Desenvolvimento para ReusoDru - Desenvolvimento para Reuso
Dru - Desenvolvimento para Reuso
 
Trabalho de Reengenharia de Software
Trabalho de Reengenharia de SoftwareTrabalho de Reengenharia de Software
Trabalho de Reengenharia de Software
 
Fermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.BrFermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.Br
 
Trabalho Web Services
Trabalho Web ServicesTrabalho Web Services
Trabalho Web Services
 
AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...
AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...
AVALIAÇÃO DA QUALIDADE DE UM SISTEMA DE GESTÃO ACADÊMICA ATRAVÉS DA MINERAÇÃO...
 
Exercicio de UML - Documentacao Restaurante
Exercicio de UML  - Documentacao RestauranteExercicio de UML  - Documentacao Restaurante
Exercicio de UML - Documentacao Restaurante
 
Padrões de Projeto - Observer
Padrões de Projeto - ObserverPadrões de Projeto - Observer
Padrões de Projeto - Observer
 
Padrão de Projeto - Adapter
Padrão de Projeto - AdapterPadrão de Projeto - Adapter
Padrão de Projeto - Adapter
 
Fermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.BrFermine como ferramenta de apoio à implantação do nível G do MPS.Br
Fermine como ferramenta de apoio à implantação do nível G do MPS.Br
 
Torre de Hanoi
Torre de HanoiTorre de Hanoi
Torre de Hanoi
 
Rail road
Rail roadRail road
Rail road
 

Trabalho de Sistemas Distribuídos