Desenvolvimento de serviços web para usarem outros serviços

A figura 14 ilustra a comunicação de um serviço com outro serviço, sendo neces- sário um intermediário para controlar as requisições e respostas trocadas entre ambos os serviços.

Figura 14: Comunicação entre dois serviços web

Toda aplicação cliente segue certos passos para usar serviços web. Em resumo, elas devem primeiro localizar o serviço, fazer uma chamada ao serviço e processar qualquer informação retornada. No caso de serviços web consumindo outros serviços web, temos um serviço cliente, que irá requerer algo a um outro serviço já conhecido e temos um ou mais serviços que irão fazer parte do corpo do serviço servidor.

Os serviços que estabelecem comunicação entre si necessitam de ter uma camada de interação bem definida, garantindo assim a forma que eles irão trabalhar em con- junto. Tal camada para o cliente, servirá para garantir que sua requisição não estará em segundo plano quando uma nova requisição chegar ao serviço servidor, e servirá para o servidor para que o mesmo detenha um maior controle de todas as requisições que estarão chegando.

A comunicação de um cliente para um serviço, na forma de serviço para serviço, dá-se obedecendo aos seguintes passos.

Do lado do cliente:

1. O serviço cliente procura pelo serviço servidor;

2. Depois de encontrado, o cliente irá montar sua requisição para o servidor, sendo que esta pode ser por meio de uma chamada passando somente atributos como parâmetro, ou pode ainda passar arquivos xml como parâmetros;

3. Se o parâmetro a ser passado é um arquivo xml, o cliente precisa montar o ar- quivo xml em conformidade com o schema usado pelo servidor, a fim de garantir

a integridade do processamento das informações. Se os parâmetros são atribu- tos, o cliente não necessita de efetuar nenhuma operação antes de enviá-los; 4. Cliente envia a chamada ao serviço e envia os parâmetros para o servidor; 5. Cliente aguarda a resposta.

Do lado do servidor:

1. Servidor recebe a requisição e os parâmetros;

2. Se o parâmetro passado é um arquivo xml (ou arquivos xml), estes são validados. Se forem atributos, não passam por nenhum processo de validação;

3. À camada de interação delega os parâmetros ao método específico, que irá pro- cessar a requisição do cliente. Tal processamento dar-se-á na camada de pro- cessamento;

4. Processa a requisição;

5. Se o tipo do parâmetro de resposta for um arquivo xml, o serviço servidor irá construir o arquivo xml a ser enviado de acordo com o seu schema. Caso não seja, nenhuma atividade é executada, somente os resultados são guardados; 6. Envia a resposta para o cliente, seja ela um arquivo xml ou somente um resultado

comum, como um atributo.

Um exemplo desse tipo de comunicação pode ser visto na figura 15.

Tais passos se deram na comunicação entre um serviço cliente que realizou uma requisição a um outro serviço. Nesse caso, a comunicação entre os dois pode se dar de duas formas. São elas: síncrona e assíncrona.

Na forma síncrona, o serviço servidor após efetivamente receber a requisição do serviço cliente, bloqueia-se para não mais processar requisições antes de completar a requisição já recebida.

Figura 15: Ilustração da comunicação entre um serviço cliente e um serviço servidor Na forma assíncrona, o oposto acontece. O serviço servidor pode continuar rece- bendo as requisições, enquanto aguarda um possível processamento, seja ele externo ou interno. Pode iniciar um outro processamento, introduzindo assim o conceito de th-

reads nos serviços web.

3.3.2 Desenvolvimento de aplicações clientes para usarem servi-

ços web

A figura 16 ilustra a comunicação de uma aplicação cliente com um serviço.

Da mesma forma que serviços clientes consomem serviços servidores, aplica- ções clientes também seguem certos passos para usarem os serviços web, tendo que primeiro localizar o serviço, fazer uma chamada ao serviço e processar qualquer infor- mação retornada. A escolha do modo de comunicação determina muito dos detalhes para a realização de tais tarefas para este tipo de iteração.

Uma aplicação pode se comunicar com um serviço usando stubs, proxies dinâ- micos ou interfaces de invocação dinâmica (Dinamic Invocation interface - DII). Com esses modos, um desenvolvedor depende de alguns moldes do lado cliente para re- presentar um serviço web a fim de acessar suas funcionalidades. O desenvolvedor dos serviços decide qual representação usar baseadas na disponibilidade do WSDL, o endereço do ponto final do serviço e os casos de uso para este serviço.

A aplicação exemplificada para demonstrar o uso do serviço web usará stubs, pois o mesmo se dá de forma mais simplória, excluindo a necessidade de um software específico de proxy e o uso de interfaces dinâmicas que tornariam o desenvolvimento obsoleto para o exemplo apresentado.

Após decidir o modo de comunicação, os desenvolvedores necessitam seguir no projeto e no desenvolvimento de uma aplicação cliente:

1. Avaliar a natureza e a disponibilidade do serviço e a descrição do serviço - ge- ralmente, o primeiro passo é determinar a localização do documento WSDL do serviço web e escolher o modo de comunicação. Usando stubs ou proxies dinâ- micos, deve-se primeiro localizar e conseguir acesso total ao documento WSDL representante do serviço web, desde que se desenvolva a aplicação cliente a partir de stubs e suporte de arquivos gerados a partir do WSDL. Se possuir o acesso somente a uma parte do documento WSDL, então usa-se o DII, desde que a DII permita localizar o serviço em tempo de execução.

2. Criar a delegação do lado do cliente:

(a) Se aplicável, gerar o stub necessário e o suporte de classes - gerar clas- ses pode não ser portável através da implementação. Portabilidade está diretamente ligada ao uso de limitação do uso de métodos específicos de

chamadas nas classes do stub. Quanto menos, mais portável por se des- prender da plataforma que o cliente está sendo executado.

(b) Localizar o serviço - dependendo do modo de comunicação, existem dife- rentes modos de se localizar um serviço.

(c) Configurar o stub ou objetos de chamada. 3. Invocar o serviço:

(a) No uso de stubs e de proxies dinâmicos, invocações são síncronas. Usa-se o DII se desejar ter uma chamada de caminho único.

(b) Trabalho com parâmetros, valores de retorno e exceções. 4. Apresentar a interface (view).

Geralmente o cliente pode precisar gerar sua interface para usuários finais. Exis- tem diferentes modos com que clientes podem lidar com apresentações das respostas a usuários do serviço web. Em alguns casos, um serviço envia sua resposta, sendo este um documento XML, e este documento poderá vir a ser transformado ou, ainda, mapeado a um formato compatível para apresentação.

Modelos de comunicação para acessar um serviço

Para melhor determinar o modo de comunicação para a aplicação cliente, é pre- ciso saber as respostas de questões como: o documento WSDL do serviço web é totalmente conhecido? O endereço do ponto final é conhecido pelo serviço web?

Como indicado, existem três modo principais para a comunicação de uma aplicação cliente com um serviço web: stub, proxies dinâmicos e interface de invocação dinâmica (Dinamic Invocation interface - DII).

Clientes usando tanto stub quanto proxies dinâmicos para acessar um serviço requer, por regra, uma definição de interface de um ponto final do serviço. Quando referenciado à interface de ponto final do serviço, esta é a interface entre o stub e o proxy dinâmico do cliente.

O stub, o qual está entre o cliente e a representação do cliente à interface do serviço do ponto final, é responsável por converter uma requisição de um cliente em uma mensagem SOAP e enviá-la ao serviço. O stub também converte respostas de serviços de ponto final, as quais são recebidas como mensagem SOAP em um formato que será compreendido pelo cliente.

Por outro lado, os proxies dinâmicos fornecem a mesma funcionalidade como os

stubs, mas isso é feito de uma forma mais dinâmica. O modelo de proxy dinâmico di-

fere do modelo de stub principalmente por ele não requerer geração de código durante o desenvolvimento.

Já DII é uma interface de chamada que suporta invocação programática e, usando- a, um cliente pode chamar um serviço ou um procedimento remoto sem conhecer em tempo de compilação o exato nome do serviço ou a assinatura do procedimento. Um cliente DII pode descobrir esta informação em tempo de execução e pode dinamica- mente procurar pelos serviços e seus procedimentos remotos, diferindo dos stubs, que dependem de uma ferramenta que usam arquivos WSDL para criar a interface do serviço de ponto final, assim gerando o stub e outras classes necessárias.

Localizando e acessando serviços

Localizar um serviço difere de tecnologia para tecnologia. Assim, um cliente pode acessar um serviço de várias formas. Sua dependência é dada pela geração das classes do stub, que é baseada na tecnologia em que o cliente é desenvolvido.

Acessar um serviço independe da utilização de stubs ou de proxies dinâmicos. Um cliente, após procurar pela porta de acesso ao serviço, poderá fazer qualquer chamada desejada pela aplicação. Deve ser assumido que a instância da porta utili- zada pelo serviço não será a mesma para as chamadas do serviço, pois portas são independentes de estado.

Configuração de stubs e chamadas

Desenvolvedores podem querer configurar uma instância do stub ou uma interface de chamada priorizando a invocação do serviço ou podem preferir permitir a configu-

ração a tomar lugar dinamicamente em tempo de execução. Geralmente, o desenvol- vedor configura o stub ou a interface de chamada priorizando a invocação do serviço quando o serviço requer uma autenticação básica.

Stubs podem ser configurados estaticamente ou dinamicamente. A configuração

de um stub estático é feita a partir da descrição do documento WSDL na hora em que o stub é gerado; já a configuração de um stub dinâmico é feita através de dados de entrada processados em uma regra programada pelo desenvolvedor em classes específicas para o mesmo.

Tratamento de exceções

Há dois tipos de exceções em aplicações clientes que acessam serviços web: exceções de sistema e exceções específicas do serviço, as quais são lançadas pelo ponto final do serviço. Exceções de sistema são lançadas por condições como uma passagem incorreta de parâmetro na invocação de um método de um serviço, por um serviço estar inacessível, por erro de rede, ou por algum outro erro além do controle da aplicação. Exceções de serviços, as quais são mapeadas a partir de falhas, são lançadas quando um erro específico do serviço é encontrado. A aplicação cliente deve lidar com os dois tipos de exceção.

3.3.3 Design de serviço de ponto final

Serviços web interagem com clientes a fim de receberem suas requisições e retornar- lhes uma resposta. Entre a requisição e a resposta, um serviço aplica uma lógica de negócio apropriada e responde a requisição do cliente. A efetiva elaboração de um serviço web começa no entendimento da natureza do serviço a fim de ser fornecido - que é como o serviço irá interagir com o cliente e como irá responder a suas requi- sições - acompanhado de como os usuários do serviço encontram e realizam suas requisições.

A maior parte das decisões que devem ser feitas no desenvolvimento e implemen- tação de serviços web será abordada, incluindo a identificação de diferentes possi- bilidades que oferecem uma gama de diferentes soluções. Além disso, serão apre- sentados os conceitos de como receber requisições, delegar requisições de lógica

de negócio, formular respostas, publicar um serviço e como lidar com uma interação baseada em documentos.

Serão abordados três tipos diferentes de serviços web:

1. Um serviço web provedor de informação que oferece informação que é mais lida do que atualizada - clientes leem a informação mais do que eles podem atualizá- la.

2. Um serviço web que atualmente completa as requisições de clientes enquanto lida com uma alta proporção de informações compartilhadas que frequentemente é atualizada e que sofre pesadas requisições que utilizam sistemas de integra- ção (EIS) ou transações de banco de dados.

3. Serviços web de processamento de negócio, o quais processam requisições de clientes incluindo uma serie de longos processamentos de dados das regras de negócio, mas, sendo o último caso, usado no desenvolvimento da aplicação exemplo.

Decisões chaves no design de serviços web

Tecnologias voltadas para serviços web basicamente ajudam a expor uma inter- face a fim de se obter interoperabilidade para aplicações existentes ou novas, ou seja, você pode adicionar uma interface de um serviço web a uma aplicação existente a fim de torná-la interoperável com outras aplicações, ou você pode desenvolver uma apli- cação completamente nova que será interoperável a partir da interceptação do novo serviço.

É importante citar que a capacidade de design de serviços web é separada do de- sign da lógica de negócio da aplicação, ou seja, quando se planeja o design de uma interface de um determinado serviço, devem-se considerar tais problemas que podem ser provenientes especialmente da interoperabilidade, e não problemas provenientes da lógica de negócio, e assim, toma-se decisões de design do serviço baseadas nes- tes problemas.

No design de serviços web deve ser considerado o fluxo para um típico serviço e os problemas que os mesmos levam. Em geral, um serviço web:

1. Expõe uma interface que clientes usam para criarem requisições a um serviço. 2. Torna um serviço disponível a parceiros e clientes interessados em publicarem

os detalhes do serviço.

3. Recebe requisições de clientes.

4. Delega requisições feitas a uma apropriada lógica de negócio e processa essas requisições.

5. Formula e envia resposta ao requisitante.

Dado o fluxo lógico, segue passos típicos no projeto de serviços web.

1. Decisão da interface para os clientes. Decidir quando e como publicar esta inter- face - o desenvolvimento de um serviço web começa decidindo qual interface o serviço tornará pública a clientes. A interface deve refletir o tipo e a natureza das chamadas que clientes irão realizar a fim de usar o serviço. Deve ser conside- rado o tipo de ponto final que se deseja usar. Deve ser decidido onde trabalhar o arquivo SOAP e deve-se, ainda, certificar-se de que estas decisões não afetarão a interoperabilidade do serviço como um todo.

2. Determinar como receber e processar requisições - será necessário que o pro- jeto do serviço web permita não somente receber chamada de um determinado cliente, mas também realizar qualquer processamento necessário a tal requi- sição, como traduzir o conteúdo da mesma para um formato interno antes da aplicação da lógica de negócio.

3. Determinar como delegar requisições à lógica de negócio - uma vez que a re- quisição tenha sido recebida e processada, então o serviço se encontra pronto para delegá-la à lógica de negócio.

4. Decidir como processar a requisição - se o serviço oferece uma interface de um serviço web a uma lógica de negócio existente, então o trabalho para este passo pode ser simplesmente determinar como interfaces de lógicas de negócio existentes podem ser usadas para tratar a requisição do serviço.

5. Determinar como formular e enviar respostas - como os serviços web formularão e enviarão respostas de volta para o cliente. É melhor manter estas operações logicamente juntas. Existem ainda outras considerações a serem feitas neste contexto antes de enviar respostas para os clientes.

6. Determinar como reportar problemas - serviços web não serão imunes a erros; deve ser decidido como tratar esses erros que podem ocorrer. Será necessário endereçar tais problemas como quando lançar específicas exceções de sistema ou quando permitir que um sistema base lance uma exceção específica de sis- tema. Deve ser formulado também um plano de recuperação de exceção em tais situações que exigirem uma recuperação.

Após considerar tais passos, as seguintes questões devem ser feitas a fim de se determinar diretivas para o projeto do serviço web desejado.

1. Como clientes fazem uso dos serviços? Considerar quais tipos de chamadas clientes irão fazer e quais podem ser os parâmetros destas chamadas.

2. Como o serviço web irá receber as requisições dos clientes? Considerar qual tipo de ponto final irá usar o serviço.

3. Processamentos comuns como transformações, traduções e logins precisarão ser realizados?

4. Como a requisição será delegada para a lógica de negócio? 5. Como será formulada a resposta e enviada para o cliente?

6. Quais tipos de exceções o serviço irá tratar e quando podem ocorrer?

7. Como clientes saberão do serviço web? Será publicado em registros públicos, em registros privados ou em outro tipo de registro?

Essencialmente, a implementação de um serviço web pode ser vista como duas camadas: uma camada de interação e outra de processamento.

A camada de interação consiste na interface do ponto final que o serviço web expõe aos clientes através da qual o mesmo recebe suas requisições.

Quando o mesmo recebe requisições dos clientes, a camada de interação define qualquer processamento necessário antes de delegar requisições à lógica de negócio. Quando o processamento da lógica de negócio se completa, a camada interação envia de volta a resposta para o cliente.

A camada de processamento envolve toda a lógica de negócio usada para pro- cessar as requisições de clientes. É também responsável por integrar-se a sistemas de integração existentes e a outros serviços web. No caso de aplicações existen- tes adicionando a interface do serviço, a aplicação tipicamente formula a camada de processamento por si só.

Visualizar a implementação do serviço web em termos de camadas, ajuda a: 1. Facilmente dividir responsabilidades.

2. Prover uma localização comum ou única para processamento lógico de requisi- ções (ambas, pré e pós processamento) na camada de interação.

3. Expor toda lógica de negócio como um serviço web.

No entanto existem vantagens, como se nota na descrição anterior, em visualizar um serviço em termos de camadas de interação e processamento. Um serviço pode optar por juntar estas duas camadas em uma única. Há vezes em que múltiplas ca- madas tornam um serviço desnecessariamente complicado e, nestes casos, o serviço poderia ser mais simples se o seu projeto fosse feito em uma camada. Tipicamente, isto acontece em cenários onde a lógica nas duas camadas é muito pequena para necessitar de camadas separadas.

Projeto da camada de interação

A camada de interação de um serviço possui muitas responsabilidades. Clientes acessam o serviço web através de serviços específicos, e a interface é o ponto de partida da interação de um cliente com o serviço web. A camada de interação também lida com outras responsabilidades, tais como receber requisições de clientes, delegar requisições a apropriadas lógicas de negócio e a criação e o envio de respostas.

Desenvolvendo a interface - existem algumas considerações que devem ser leva- das em conta, como problemas de sobrecarga de métodos, escolha do tipo de ponto final, e assim por diante.

Escolha do tipo de interface do ponto final - quando você desenvolve um novo serviço web que não usa uma lógica de negócio existente, a escolha de tipo de ponto final para usar a interface de um determinado serviço web é de extrema cautela.

Quando se adiciona uma interface de um serviço web a uma aplicação existente ou a um serviço, deve-se considerar onde a aplicação existente ou serviço processa requisições antes de delegá-las à lógica de negócio. Além disso, deve-se escolher o tipo de ponto final que se adapte à camada onde a lógica de processamento ocorre na aplicação existente.

Se a aplicação ou serviço existente não requer processamento de requisições, escolhe-se o ponto final apropriado que está presente na mesma camada que a lógica de negócio.

Na escolha de um ponto final ideal seria necessário levar em conta alguns tópicos: 1. Considerações de acesso multi-thread - sincronizações no código fonte podem ser necessárias dependendo da tecnologia empregada no desenvolvimento do serviço web.

2. Considerações de transação - o contexto de transação de implementação do ser- viço determina o contexto transacional no qual a implementação é executada. Se a lógica do serviço requer o uso de transações, será necessária a implementa- ção do gerenciamento lógico das transações.

3. Considerações para as permissões de acesso de métodos - um método de um serviço web pode ser acessado por uma gama de clientes diferentes, e será ne-