Pessoal, meu Trabalho de Conclusão de Curso (TCC) foi implementado apartir do estudo de Web Services e Usabilidade de Interfaces de Computador. Área muito interessante para estudo para aqueles que gostam de desenvolvimento de sistemas distriuídos assim como eu. :)
Abaixo temos alguns cenários de utilização!
Apresentação de alguns cenários de utilização de SOAP com Web Services.
Cenário1: Acesso a Web Services através do Navegador
Os navegadores são as principais ferramentas utilizadas para a busca de informação na Internet. Portanto é interessante (pra não dizer necessário) que eles possam acessar Web Services com a mesma facilidade que qualquer outra aplicação desenvolvida no lado do servidor (escrita em linguagens como C++, PHP, JAVA) o faria. Nesta sessão, daremos uma visão geral das soluções que os browsers Mozilla e IE já trazem como resposta para este novo desafio, que é o acesso a Web Services, via browser, usando SOAP.
Interfaces do Mozilla
Interfaces do IE
A versão 1.0 do Mozilla trouxe uma grande novidade: o suporte nativo a SOAP em um browser, embora este suporte seja apenas parcial para a versão SOAP 1.0. Uma aplicação rodando no Mozilla, ou no Netscape 7.0 (já que ele utiliza o mesmo engine que o Mozilla) pode acessar um Web Service, usando chamadas em SOAP, diretamente do navegador, sem a necessidade de fazer uma chamada a uma aplicação no servidor. A resposta ou dados retornados pelas chamada podem ser acessados através dos métodos do DOM level 2, já que trata-se de uma resposta XML.
Fig 2. Aplicação JavaScript acessando Web Services através do browser Mozilla.
Esse novo suporte surgiu como uma nova API, que permite o acesso a Web Services, através de uma interface JavaScript. Através desta interface é possível criar, enviar e receber mensagens SOAP através do browser.
Referências
O Internet Explorer possui uma abordagem diferente para acessar Web Services. A Microsoft define os chamados: WebService behaviors. Um WebService behavior é definido como um componente HTML (HTC), e pode ser utilizado à partir da versão 5 do IE.
A característica fundamental de um WebService behavior é o fato deste se comunicar com WebServices usando SOAP e HTTP(para o transporte da mensagem).
Referências
Cenário 2: Cliente acessando Web Services no servidor.
Vamos apresentar agora um segundo cenário de utilização de SOAP e Web Sevices. Neste novo modelo, em vez de existir um browser realizando chamadas SOAP, temos uma aplicação cliente (definida em JAVA, C++, ou outra linguagem) enviando estas chamadas para um serviço no servidor.
Nossa aplicação cliente pode acessar diretamente um Web Service, seja ele um EJB (Enterprise Java Bean) ou mesmo uma aplicação JAVA. O Web Service processa a chamada (possivelmente acessando o seu Banco de Dados) e retorna uma resposta ao cliente.
A figura abaixo nos fornece uma visão geral deste processo: A aplicação cliente, após localizar o serviço remoto(definido por um documento WSDL), invoca os seus serviços através de RPC. O Web Service recebe a chamada, a processa e envia uma resposta. É válido lembrar, que ambos (cliente e Web Service) "conversam" usando SOAP em cima de HTTP.
Fig 3. Aplicação cliente acessando diretamente um Web Service.
JAX-RPC
A especificação J2EE da Sun Microsytems, define um conjunto de API's para acessar WebServices em um ambiente distribuído. Este conjunto de API's, conhecido como JAX-RPC, permite realizar chamadas de RPC, utilizando-se SOAP. JAX-RPC foi desenvolvido com o objetivo de “esconder” a complexidade de SOAP. Dessa forma, não é necessário escrever uma chamada SOAP explicitamente. Podemos usar esta API para montarmos as chamadas RPC, codificando em JAVA.
JAX-RPC baseia-se em um documento WSDL para a descrição de um Web Service. Dessa forma, um cliente pode acessar a descrição (WSDL) do serviço remoto, e realizar as chamadas.
JAX-RPC não limita que o cliente e o Web Service sejam desenvolvidos na plataforma JAVA. Um cliente JAVA pode fazer chamadas a um serviço desenvolvido em uma plataforma não-JAVA , assim como um serviço implementado em JAVA pode ser acessado por uma aplicação não-JAVA.
Referências
Cenário 3: Acessando Web Services no lado servidor
Neste último cenário temos um aplicação cliente acessando uma aplicação no servidor. Esta, por sua vez, faz chamadas a diversos Web Services em diferentes máquinas, processa as respostas destes serviços e, por fim, envia uma resposta ao cliente. Um exemplo interessante seria, por exemplo, um site que faz a cotação de preços de livros em várias lojas virtuais pela Internet. Vamos nos referir a este site, como site de cotações.
No nosso exemplo, supomos que cada loja virtual possua seu próprio Web Service. Este Web Service deve receber o pedido para uma determinada cotação(tipo de produto) e enviar uma resposta contendo o preço do produto.
Uma aplicação cliente (no caso o browser) acessa o site de cotações. Em seguida, o usuário do sistema preenche um formulário HTML contendo o dados sobre os livros a serem pesquisados. Ao terminar, os dados são enviados através de uma requisição (POST) ao servidor. No servidor, uma aplicação recebe a requisição, localiza os serviços disponíveis (Web Services), com base numa lista pré-estabelecida, e envia as mensagens (SOAP), contendo as requisições de preço do produto(livro).
O serviço(Web Service) da loja virtual, recebe o pedido e o processa. Caso seja um pedido válido, e a loja contenha aquele livro em seu estoque, o serviço retorna uma mensagem (SOAP) contendo a cotação do livro no corpo da resposta. A aplicação servidora recebe então as resposta das diversas lojas (subentende-se serviços), processa os dados recebidos e envia um formulário HTML para o browser do usuário, contendo todas as cotações para aquele determinado livro.
A figura abaixo ilustra o funcionamento deste sistema:
Fig 4. Sistema de pesquisa em lojas virtuais - Aplicação no servidor acessando diversos Web Services.
A grande vantagem desse modelo, portanto, é que a informação pode estar distribuída pela WEB, podendo facilmente ser acessada e filtrada de acordo com nossas necessidades. Sendo somente necessário localizarmos os diversos serviços (Web Services) e construirmos as chamadas de forma correta.
Nenhum comentário:
Postar um comentário