APS 8º SEMESTRE

Prévia do material em texto

UNIP
UNIVERSIDADE PAULISTA
Desenvolvimento de Uma Aplicação Utilizando Web
	Aluno:
	Rodrigo de Oliveira Barboza
	RA:
	B8199C-5
Curso: Ciência da Computação
Matéria: APS
Turma: CC8P30
Brasília, 25 de Setembro de 2016
Objetivo do Trabalho
O principal objetivo deste trabalho é apresentar os elementos e tecnologias essenciais para o funcionamento dos Web Services, bem como também mostrar o impacto e os resultados que o Web Services vem causando nos negócios das empresas.
1. Introdução
Web Services (ou Serviços Web) tem se apresentado como uma nova e importante tecnologia de computação neste começo de século. Todas as maiores empresas de software do mundo estão desde o momento da especificação desta tecnologia promovendo seu uso, crescimento e até mesmo a adoção destes em suas plataformas de desenvolvimento de softwares. Através de sua proposta de funcionamento, que é de integrar funcionalidades e reutilizar rotinas, de tornar os aplicativos automatizados, distribuídos, gerenciáveis e escaláveis, o Web Services atingiu de maneira certeira a estratégia de muitos gerentes e diretores da área de TI: a de utilizar uma plataforma já existente de aplicativos, mas provendo sua integração e distribuição de uma maneira simples, utilizando conjuntos de hardwares e softwares existentes. O resultado é uma sinergia de esforços e redução de muitos custos. Este trabalho apresenta o que é uma arquitetura orientada a serviços, pois o Web Services nada mais é do que uma implementação desta. Além disto, são mostrados em detalhes os elementos utilizados como base para seu funcionamento. Comentários sobre o impacto do Web Services no mundo corporativo, alguns casos de uso da tecnologia e os principais benefícios e aspectos críticos (ou até problemáticos) dos serviços web também são colocados em questão
2.1 Conceitos Gerais
Web Services é um padrão de comunicação, que atende as necessidades de uma arquitetura baseada em serviços, e tem como principal objetivo promover a comunicação entre diferentes softwares e aplicações, rodando em uma variedade indeterminada de plataformas. Web Services contempla sozinho a implementação de uma arquitetura de SOA. A arquitetura básica do Web Services inclui tecnologias e padrões capazes de: trocarem mensagens, descrever Web Services e publicar e descobrir Web Services. A implementação de um Web Service é baseada em um conjunto de protocolos e linguagens padrões de Web, das quais podemos destacar: o HyperText Transfer Protocol (HTTP), o Simple Object Access Protocol (SOAP); Web Service Description Language (WSDL) e o UDDI (Universal Description, Discovery and Integration). O formato XML é a base dos três últimos elementos citados: SOAP, WSDL e UDDI.
2.2 A troca de mensagens entre clientes e servidores de Web Services
A troca de mensagens entre o agente solicitador de serviço (Web Service Requester) e o provedor de serviços (Web Service Provider) acontece através do padrão SOAP (Simple Object Access Protocol). SOAP é uma especificação com o objetivo de possibilitar a comunicação entre dois aplicativos, de maneira descentralizada, utilizando o XML como protocolo base, e adotando regras simples e leves. O conteúdo SOAP precisa transmitido por um canal de comunicação, como por exemplo, uma conexão sockets utilizando o protocolo HTTP ou mesmo através do protocolo RPC. Outra característica diferencial do SOAP é a de prover a integração entre plataformas heterogêneas de software, uma vez que detalhes inerentes à arquitetura de execução de cada plataforma são omitidos quando os dados são convertidos para XML.
2.3 Auto-descrição de serviços e o esquema de descobrimento de Web Service
Como a comunicação e troca de mensagens no ambiente Web é padronizada, tornou-se conseqüência a necessidade de existir a possibilidade de descrever estes padrões numa maneira estruturada. O padrão WSDL – Web Service Description Language foi desenvolvido para atender esta necessidade. No caso de Web Services, este sempre poderá se descrito programaticamente utilizando a sintaxe definida pelo padrão WSDL O WSDL define um serviço de rede de uma maneira abstrata, ou seja: as características de execução do serviço, como meios de transmissão, linguagem de programação, tipos de dados utilizados, etc., não estão representadas de modo que as relacionem somente a uma arquitetura, mas estão descritas de forma que seja possível a qualquer arquitetura implementar ou utilizar um serviço descrito através de um documento WSDL. Uma arquitetura SOA baseada em Web Service pode, além da capacidade de autodescrição do serviço, usufruir da funcionalidade de publicação de determinado serviço em uma rede. Esta rede pode ser pública, como Internet, ou privada, dentro de uma mesma empresa. Este registro é padronizado, e chamado de UDDI (Universal Description, Discovery and Integration), e também pode ser publico ou privado. Com o UDDI, as empresas que oferecem Web Services podem publicar seus serviços em listas, podem unir-se umas as outras, e por diante, definindo uma nova maneira sobre como os serviços ou aplicações de software interagem-se na Internet. Através de um repositório UDDI, é possível buscar Web Services de maneira programática. Com isto, um software pode automaticamente descobrir um serviço que atende sua necessidade, e após encontrar, utilizar o WSDL (descrição do serviço) para verificar como utilizá-lo.
2.4 Mudanças no ambiente de TI
Apesar de todo o trabalho executado por dezenas de profissionais das empresas de software que colaboraram com o desenvolvimento do padrão Web Services, e independentemente dos avanços tecnológicos conquistados, a sua implementação prática e bem sucedida precisa de uma certa estratégia para que seja atingida plenamente. Diversos fatores necessários para o sucesso da implementação de uma arquitetura de software orientada a serviços, mas as empresas que obtiveram êxito nesta tarefa tinham todas em comum o fato de terem desenvolvido um plano de Governança de TI para suportar o design, desenvolvimento, publicação e operacionalização de um framework de software baseado em SOA. Sem um plano de governança para dar suporte à implementação da arquitetura SOA, as chances de um projeto ser malsucedido são muito maiores.
3. Fundamentos Web Service
SOA é define um modelo de funcionamento de software orientado a serviços. Este divide a camada de negócio da arquitetura três camadas em duas partes: uma primeira, que seriam os processos, são as mesmas funcionalidades que já existiam na camada de negócio; e uma segunda, a de funções, permite a camada de negócio interagir com outras camadas de negócio de outros aplicativos, localizados no mesmo ambiente de execução ou até mesmo em ambientes de execução remotos, distribuídos na Internet ou na rede privada da companhia. Desta maneira, prova-se que uma arquitetura orientada a serviços vem a agregar funcionalidades a uma arquitetura três camadas, mas não substitui-la por completo. Numa visão objetiva, para existir uma arquitetura SOA, basta existirem as aplicações clientes, que são as entidades que buscam serviços e invocam sua execução, e os servidores responsáveis por prover estes serviços, gerenciarem sua execução e devolverem os resultados às solicitações dos clientes. Esta interação entre as aplicações clientes e os provedores de serviços deve ocorrer dentro de um canal de comunicação, e os dados transferidos são transcritos em um protocolo especifico do padrão SOA empregado. O modelo de funcionamento do SOA permite aos administradores de TI expandirem a oferta de serviços, para atenderem novas rotinas de negócios, ou mesmo melhorar a qualidade das aplicações, atualizando hardware e sistema operacionais, sem prejudicar o funcionamento de todo o conjunto já em funcionamento de aplicações.
Envelope: é o elemento que identifica o documento XML como sendo uma mensagem SOAP. O envelope pode conter declarações de namespaces como declarações de outros atributos, como por exemplo, o estilo de codificação.
Header: é um cabeçalhoopcional contendo informações adicionais como dados específicos de uma aplicação (por exemplo, autenticação). Se o header for utilizado em uma mensagem SOAP deve ser o primeiro elemento filho do elemento envelope.
Body: diferente do elemento header este elemento é obrigatório. Este elemento contém a informação (ou payload) a ser transportada para seu destino final.
Fault: é um elemento opcional usado para indicar mensagens de erro. Se o elemento fault é presente deve aparecer como um elemento filho do elemento body.
WSDL: É uma das linguagens mais importantes no cenário de Web Services e possui um papel fundamental. Originado do acrônimo em inglês Web Service Descriptor Language, um arquivo WSDL é um documento escrito em linguagem XML para descrever um Web Service. Um documento WSDL funciona semelhantemente a um contrato de serviço. O WSDL além de descrever minuciosamente o serviço também descreve a sua forma de acesso e a suas operações disponíveis. Segundo o W3C (W3C. WSDL, 2001), o WSDL descreve os serviços de rede como um conjunto de endpoints (endereços) sobre as mensagens contendo informações orientadas ao documento (document-oriented) ou orientadas a procedimento (procedure-oriented). 
UDDI: Acrônimo em inglês Universal Description, Discovery and Integration é um diretório para armazenamento de informações sobre Web Services, ou seja, é um diretório de interfaces de Web Services descritas em WSDL. Os provedores de serviços que desejam publicar seus Web Services podem utilizar um registro de serviço UDDI. Os usuários de serviços podem consultar um UDDI para localizar um serviço de interesse e obter as informações necessárias para sua utilização.
4. Plano de desenvolvimento da aplicação
Devido ao dinamismo proposto pela arquitetura SOA (Service Oriented Architeture) torna-se necessária uma proposta de teste e validação apropriada para os Web Services. Para Canfora e Di Penta (2006) este cenário dinâmico (publicação, vinculação, invocação e integração em tempo de execução) trás, sem dúvida, novos desafios para as técnicas de teste atuais. Os Web Services possuem características únicas justificando a necessidade de implantação de novos métodos e ferramentas de testes já que os métodos e ferramentas de testes atuais não trabalham com serviços. (CANFORA; DI PENTA, 2006). Como a adoção de interfaces gráficas não faz parte do conceito de Web Service, existe uma dificuldade para a realização de testes manuais tornando-os penosos e complexos. 
Desta forma, os Web Services são fortes candidatos a utilização de testes automatizados. Métodos de testes baseados no código fonte como testes de fluxo de dados, cobertura de código, teste de mutação e outros, ficam comprometidos visto a falta de acesso ao código fonte. A falta de acesso ao código fonte se dá uma vez que os Web Services são vistos como componentes de softwares encapsulados sendo acessíveis por uma interface de comunicação. Testar um Web Service assemelhasse a ao teste do tipo caixa preta onde as especificações são avaliadas, mas a estrutura do código fonte, que pode estar em C#, Java, etc., não é verificada. Como os Web Services utilizam fortemente um conjunto de tecnologias que fazem uso de padrão baseado em XML, técnicas de testes precisam ser ajustadas para trabalhar com este padrão, ou seja, casos de testes precisam ser gerados considerando o formato padrão baseado em XML.
A partir destas particularidades do cenário SOA, pesquisadores vem sugerindo algumas propostas que podem ser adotadas para testes de Web Services. Este artigo propõe a apresentação das propostas de testes citadas a seguir: 
a. Testes baseados em documento WSDL: Um documento WSDL descreve uma interface para a utilização de um Web Service contendo informações que auxiliarão os testadores a especificarem um plano de testes apropriado. As funcionalidades e características de um Web Service serão verificadas a partir de sua interface, ou seja, a partir do documento WSDL. 
b. Testes baseados em perturbação de dados: Esta abordagem tem como objetivo alterar mensagens SOAP fazendo uso de operadores de perturbação. As mensagens alteradas por estes operadores são utilizadas como base de testes para a interação entre pares de Web Services. 
c. Teste de mutação sobre documentos WSDL: Com o uso da técnica de testes conhecida como Análise de Mutantes, operadores de mutação são desenvolvidos e aplicados em documentos WSDL com o intuito de gerar interfaces modificadas para Web Services que serão utilizadas para testar os serviços. 
d. Testes de conformidade para Web Services: A aplicação de testes de conformidade procuram identificar problemas na implementação dos Web Services. 
O teste de conformidade visa responder a seguinte questão: A implementação do Web Service apresenta o comportamento especificado? Esta abordagem proporcionará aos utilizadores do Web Service garantias que sua implementação corresponde corretamente a descrição do serviço.
5. Modelagem
	Sem dúvida os estudos realizados por pesquisadores da área de testes de software colaboram com idéias e sugestões que auxiliam grandes empresas a produzirem ferramentas para testes automatizados. O grande benefício destas ferramentas é a geração e execução de inúmeros casos de testes proporcionando redução de custos, economia de tempo e maior controle e fluidez na execução dos testes. As ferramentas para testes automatizados podem prover uma melhoria na qualidade dos Web Services assim como para qualquer sistema de software.
A seguir uma breve descrição de algumas ferramentas para testes em Web Services disponíveis atualmente no mercado. Algumas das ferramentas citadas não utilizam as abordagens vistas neste artigo estando principalmente focadas na avaliação de performance, integração e segurança. Não é intuito desta seção fazer qualquer tipo de comparação entre as ferramentas nem descrever suas arquiteturas de funcionamento. 
soapUI: O soapUI (EVIWARE, 2010) é uma das ferramentas mais conhecidas para realização de testes automatizados em Web Services. Esta ferramenta além de realizar testes funcionais realiza outros tipos de testes como teste de carga, teste de qualidade e teste de conformidade. O soapUI é uma ferramenta open source produzida pela empresa Eviware e suporta diferentes tipos de protocolos entre eles SOAP, REST e HTTP. Possui como características a inspeção e invocação de serviço, simulação de serviço (Service Mocking), monitoramento de desempenho, etc. O soapUI é uma ferramenta feita em Java sendo independente de plataforma. 
SOAtest: O SOAtest (PARASOFT, 2010) da Parasoft é uma plataforma comercial de testes de ambientes SOA permitindo ao desenvolvedor criar cenários de testes para Web Services. Possui como principais características o teste funcional End-to-End (que valida aspectos críticos de transações complexas), virtualização do comportamento do serviço, teste de carga e performance, teste de segurança, testes de regressão, detecção de erros em tempo de execução e outras. 
TestMaker: O TestMaker (PUSHTOTEST, 2010) da PushToTest é um framework open source baseado na arquitetura SOA. Este ambiente de teste permite basicamente a realização de testes de funcionalidade, teste de regressão, teste de desempenho em aplicações RIA (Rich Internet Applications) e aplicações SOA. Uma das principais características é o Cloud Testing (Teste nas nuvens) que é uma forma de testar aplicações web que usam computação nas nuvens simulando situações reais de tráfego. A ferramenta possui recurso de gravação e reprodução de testes. 
Algumas das pesquisas realizadas nas abordagens de testes vistas neste artigo também contribuem com ferramentas experimentais para testes em Web Services.
7. Projeto do programa
Vamos adicionar o código abaixo na nossa classe AjusteSalarialRequest.
package cicero.ajuste.salarial.request;
 
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class AjusteSalarialRequest {
 
private String nomeFuncionario;
private Double salarioAtual;
private Double percentualAumento;public String getNomeFuncionario() {
return nomeFuncionario;
}
public void setNomeFuncionario(String nomeFuncionario) {
this.nomeFuncionario = nomeFuncionario;
}
public Double getSalarioAtual() {
return salarioAtual;
}
public void setSalarioAtual(Double salarioAtual) {
this.salarioAtual = salarioAtual;
}
public Double getPercentualAumento() {
return percentualAumento;
}
public void setPercentualAumento(Double percentualAumento) {
this.percentualAumento = percentualAumento;
}
}
Agora vamos adicionar um pacote para criarmos as classes de resposta do nosso Web Service, vamos dar o nome de cicero.ajuste.salarial.response , você pode seguir os mesmos passos que usamos para criar o pacote cicero.ajuste.salarial.request.
Com o pacote criado vamos agora adicionar a nossa classe de resposta, para isso basta clicar no pacote com o botão direito e ir no Menu New > Class e dar o nome de AjusteSalarialResponse.
Agora na nossa classe vamos adicionar o código abaixo.
package cicero.ajuste.salarial.response;
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class AjusteSalarialResponse {
 
private String nomeFuncionario;
private Double salarioAnterior;
private Double salarioAjustado;
private Double percentualAumentoRecebido;
 
 
public String getNomeFuncionario() {
return nomeFuncionario;
}
public void setNomeFuncionario(String nomeFuncionario) {
this.nomeFuncionario = nomeFuncionario;
}
public Double getSalarioAnterior() {
return salarioAnterior;
}
public void setSalarioAnterior(Double salarioAnterior) {
this.salarioAnterior = salarioAnterior;
}
public Double getSalarioAjustado() {
return salarioAjustado;
}
public void setSalarioAjustado(Double salarioAjustado) {
this.salarioAjustado = salarioAjustado;
}
public Double getPercentualAumentoRecebido() {
return percentualAumentoRecebido;
}
public void setPercentualAumentoRecebido(Double percentualAumentoRecebido) {
this.percentualAumentoRecebido = percentualAumentoRecebido;
}
 
}
Depois que o Web Service já estiver publicado no Tomcat vamos iniciar para vermos se não deu nenhum problema.
Após dar o play e tudo estiver certo, não deve aparecer nenhum erro no Console do Eclipse
Agora vamos testar a url do nosso Web Service, abra um browser e digitehttp://localhost:8080/AjusteSalarialService/paginaAjusteSalarialService , o resultado deve ser igual a imagem abaixo. 
Para acessar o wsdl basta clicar na linha que tem o rótulo WSDL:
Agora vamos testar nosso Web Service no Soap UI, se você não tiver basta baixar no sitehttp://www.soapui.org/
Com o SoapUI aberto vamos clicar no menu File -> New SOAP Project como mostra a imagem abaixo.
Na tela que foi aberta vamos dar um nome para o nosso projeto e informar a url do nosso WSDL.
Project Name : WebServiceCalculoAjusteSalarial
Initial WSDL: http://localhost:8080/AjusteSalarialService/paginaAjusteSalarialService?wsdl
O resultado deve aparecer do lado direito da ferramenta como mostra abaixo.
8. Conclusão
Web Services representa um novo e importante caminho alternativo para o desenvolvimento de softwares altamente escaláveis e flexíveis. Os resultados obtidos por empresas que tiveram sucesso na implementação de uma arquitetura orientada a serviço são evidentes: a transparente integração de softwares que rodam em plataformas heterogêneas, comunicação de sistemas através da Internet de maneira simples eficiente, os ganhos de tempo e qualidade no desenvolvimento de software através da reutilização de serviços, entre outros. Existem ainda diversos desafios para melhorar esta tecnologia, como por exemplo, a questão da segurança dos dados precisa de melhores definições, e também do consumo de banda de rede e de processamento computacional, já que grande parte da tecnologia é baseada em arquivos texto XML, que exigem tratamento diferenciado dos formatos binários. Em um trabalho futuro, talvez estas e outras questões já tenham novas resoluções que poderão ser exploradas em detalhes.
9. Bibliografia
https://projetos.inf.ufsc.br/arquivos_projetos/projeto_249/Desenvolvimento%20de%20Web%20Services%20com%20SOAP.
http://www.seer.ufrgs.br/reic/article/viewFile/22140/12928
http://www.leonardofreitas.eti.br/download/TCC-ARTIGO%20CIENTIFICO.pdf
KREGER, H. eBook – Web Services Conceptual Architeture (WSCA 1.0) . IBM. 2001 
WIEHLER, G. eBook - Computer - Service Oriented Architecture. Siemens. 2004.
https://www.google.com.br/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwi8lI6156rPAhUJPJAKHUP1BUkQFggpMAE&url=http%3A%2F%2Fwww.pgsskroton.com.br%2Fseer%2Findex.php%2Frcext%2Farticle%2Fdownload%2F2304%2F2204&usg=AFQjCNE_lJG7etRguvyiln3xukgfb5N6Uw&sig2=15OIIbzUI6WDuJP4J5MJFA&bvm=bv.133700528,d.Y2I