Dicas Técnicas BufaloInfo

WebServices : Utilizando parâmetros opcionais com REST no WCF

O atributo WebGet não suporta o uso de parâmetros opcionais, ou seja : Se você tiver parâmetros no seu método que não estejam explicitamente indicados no webGet, ele vai supor de forma errada que seriam parâmetros para POST e falha - afinal estamos falando de um GET.

Então o que acontece se você precisar de um parâmetro opcional ? Por exemplo :

http://meusite.com.br/blogs/listar/?f=rss

Onde f=rss é um parâmetro opcional de indicação do formato que deve ser utilizado na resposta ?

Para resolver isso podemos recuperar os parâmetros em código, ao invés de indica-los como parâmetro do método que faz parte do contrato WCF. Veja um exemplo :

F = WebOperationContext.Current.IncomingRequest.UriTemplateMatch.QueryParameters.Get("f")

Simples assim, no código resolvemos o problema dos parâmetros opcionais com webGet

WebServices : Configurando o Host de uma Classe de Negócio

O Visual Studio possui um template para criação de um serviços WCF que são "automaticamente" configurados para hospedagem em ambiente web (ou seja, o arquivo .svc já é criado automaticamente)

O problema é que se programarmos nosso serviço dentro deste projeto teremos pouca versatilidade na utilização da classe de negócio, ela ficará presa ao projeto web.

Assim sendo pode ser preferível programar o serviço em um projeto class library separado. Depois de haver criado o projeto web WCF Service faça o seguinte :

1) Crie um projeto de class library

2) Adicione a referência para o System.ServiceModel e System.Runtime.Serialization

3) No projeto web, adicione referência para o projeto class library

4) No projeto web, delete os 2 arquivos de código

5) Altere o arquivo .svc para se referir a classe do serviço e retire o atributo codebehind

6) Altere o arquivo web.config para se referir a classe e ao contrato do serviço

Pronto ! Sua classe de negócio está isolada em uma class library e o projeto web funciona como host para o serviço, mas sem limita-lo.

WebServices : Retornando dataTables em WebServices

A partir do framework 2.0 o dataSet e as dataTables sofreram algumas pequenas mudanças. Tais mudanças fizeram com que retornar uma dataTable a partir de um webService não seja algo mais tão simples como definir o valor de retorno de uma função.

A partir do framework 2.0, se desejarmos retornar uma única dataTable, precisamos fazer o seguinte :

Primeiramente preencher a dataTable que está no dataset normalmente
Criar uma dataTable desvinculada do dataset - uma nova possibilidade a partir da versão 2.0

Importar os dados para a nova dataTable desvinculada, o que pode ser feito da seguinte forma :

tabelaNova.load(tabelaAntiga.createdatareader())

Devolver pelo webService a nova dataTable, desvinculada do dataSet.

WebServices : WCF com TCP e o endereço de MEX

Quando criamos um serviço TCP precisamos de dois endpoints, um endpoint TCP e outro endpoint MEX, isso todos sabem.

Mas quando damos endereço aos endpoints, você sabia que o endereço MEX (que é anexado ao base address, óbvio) é considerado default ?

Se você usar o endereço MEX para o endpoint de MEX então ao fazer o service reference basta indicar o base address que o client se acha. Mas se você utilizar um endereço diferente de MEX, terá que apontar o endereço completo do endpoint de MEX....

WebServices : Fazendo webServices com WCF

Até o .NET 2.0 utilizavamos webServices na forma dos .ASMX criados em aplicações web.

A partir do .NET 3.0 passamos a utilizar serviços WCF, muito mais flexiveis que os antigos .ASMX.

Mas e se precisarmos produzir webServices que suportem interoperabilidade com ambientes mais antigos ?

Existem diferentes versões do protocolo SOAP e outros protocolos WS*, a questão é simplesmente fazer com que o WCF utilize as mesmas versões de protocolo que o antigo .ASMX.

Para isso a solução é muito simples : Ao invés de utilizar o wsHttpBinding, que é o default, devemos utilizar o basicHttpBinding, para a interoperabilidade. Isso permitirá que o serviço WCF seja acessado como se fosse um velho .ASMX.

Como os serviços WCF podem possuir diversos endpoints, podemos criar um endpoint para compatibilidade com o ambiente legado e outro para uso dos protocolos mais atuais.

WebServices : Controlando o TimeStamp com WSE

Quando utilizamos o WSE este insere um controle de timeStamp nos pacotes SOAP. Assim sendo a hora de transmissão é conhecida bem como a hora de recebimento. Se houver uma diferença de tempo muito grande em relação as duas o WSE recusará o pacote, pois pode se tratar de algum ataque de repetição de pacotes.

Se o relógio das máquinas não estiver sincronizado, este controle adicional inserido pelo WSE pode gerar problemas. Para resolver você pode corrigir uma configuração no web.config.

Veja :

<microsoft.web.services2>
<security>
<timeToleranceInSeconds>Timeout em segundos</timeToleranceInSeconds>
</security>
</microsoft.web.services2>

O timeout default é de 5 minutos. Isso pode ser aumentado, para reduzir a segurança ou reduzido, para aumentar a segurança.

WebServices : Transferindo datas via WebServices

A comunicação HTTP nos sugere a possibilidade de estarmos fazendo troca de dados entre aplicações espalhadas por diversos locais em todo o mundo.

Porém a transmissão de datas de forma tão distribuida guarda algumas particularidades interessantes, que devem ser observadas.

Imaginemos que desejamos trocar informações - e um campo data entre elas - entre uma aplicação em Londres e uma aplicação em Brasilia.

Em Londres o WebService envia uma data : 02/09/71 . Como essa data chegará a Brasilia ?

Simples : 01/09/71 21:00

Isso por causa da diferença de fuso horário. A data enviada pela aplicação em Londres é enviada com informação data e hora e com identificação de fuso horário, o que causa essa mudança.

Acrescente a isso as seguintes complicações :

Dentro do Brasil mesmo temos vários fusos horários, especialmente em época de horário de verão

As máquinas podem estar com configuração de fuso horário errada

Para resolver este problema podemos lidar com a serialização do webService para determinar que a informação seja transmitida apenas na forma de data, sem informação de hora agregada a ela. Veja como fica :

<WebMethod> Public Sub AlteraDataNascimento ( _ codigoPessoa As Int32, _ <XmlElement(DataType:="date")> novaDataNascimento As DateTime)

Simples assim, problema resolvido.

Esta dica foi criada por Gilberto Uchoa em seu blog que fica em http://br.thespoke.net/MyBlog/Ninguem/MyBlog.aspx

WebServices : Melhorando os recursos de cache em WebServices

Quando utilizamos WebServices podemos configurar o cache de resposta dos webServices através do atributo cacheDuration. Este atributo é configurado em segundos, assim sendo durante este tempo o webService não será processado, seu resultado será devolvido a partir do cache.

Porém em determinados casos não desejaremos manter informações em cache com base em tempo. Desejaremos manter a informação em cache até que os dados sofram alguma alteração e, quando isso acontecer, invalidar o cache imediatamente. Se utilizarmos apenas o atributo cacheDuration quando os dados forem alterados ainda assim a resposta continuará sendo a do cache, até que o tempo do cacheduration passe.

O mesmo problema também ocorre com páginas e sugeri uma solução no artigo que encontra-se em http://www.bufaloinfo.com.br/artigos/coluna11.asp , mas como resolver o problema em um WebService ?

Através do objeto httpCachePolicy que pode ser acessado através de context.response.cache, podemos controlar os critérios para que o cache seja mantido ou não, e assim ter um maior controle sobre o processo de cache.

<WebMethod(cacheduration:=360)> _
Public Function HelloWorld() As String

Context.Response.Cache.AddValidationCallback(AddressOf Validate, Nothing)

'aqui continua o processamento

End Function

Public Sub Validate(ByVal context As HttpContext, ByVal data As Object, ByRef status As HttpValidationStatus)

If Not IsNothing(context.Cache("dados")) Then
status = HttpValidationStatus.Valid
Else
'Pode-se carregar o dataset aqui
'em seguida insere-se o dataset no cache
context.Cache.Insert("dados", ds1, New Caching.CacheDependency("c:\dados\arquivo.xml"))
End If
End Sub

Utilizamos o método AddValidationCallBack para adicionar no httpcachepolicy uma referência para o método validate. Desta forma o método validate será chamado para verificar se o cache deve ou não ser mantido.

Com isso ganhamos dos dois lados : mantemos os dados em cache, evitando ir ao banco e invalidamos o cache quando ocorrer mudança, ao mesmo tempo que também mantemos a página em cache, evitando fazer o processamento de retorno e obtendo o máximo em performance e escalabilidade.

WebServices : Utilize o atributo OneWay em WebMethods que não tenham retorno

Algumas vezes utilizamos webMethods sem retorno, como por exemplo, para inserção ou atualização de dados.

Para estes casos existe um truque bem simples para otimização de performance : Podemos utilizar uma atributo junto ao WebMethod chamado OneWay. Com isso estamos informando que este método não gera um retorno.

Essa informação faz com que o client possa disparar o método e não ficar esperando um retorno, continuando o processamento imediatamente após o disparo do método. Desta forma temos uma otimização da chamada ao método, ganhando performance.

Na verdade OneWay é um parâmetro do atributo SoapRPCMessage. Este atributo é usado para formatar a mensagem SOAP de acordo com o padrão RPC, portanto poderia ser usado com outras finalidades, mas em nosso exemplo podemos utilizar apenas para definir que o webMethod é OneWay. Veja como fica :

<WebMethod(Description:="Um Método Qualquer"), SoapRpcMethod(oneway:=True)> _
Public Sub UmMetodo

End Sub

Observe que trata-se de uma Sub. Sendo OneWay, não poderia haver retorno.

WebServices : Acessando um WebService através de um proxy com senha

Não é raro que precisemos criar aplicações em nossa empresa para acessar WebServices externos. Mas normalmente, dentro da empresa, precisamos fazer uso de servidores de proxy para acessar a web.

Algumas vezes o servidor de proxy exige login do usuário e senha para permitir o acesso a internet. A questão é como transmitir isso via código ?

Para fazer isso devemos utilizar algumas classes adicionais do Framework. Devemos utilizar a classe NetworkCredentials para identificar a identidade do usuário e a classe WebProxy para identificar a localização do ProxyServer.

Devemos usar a classe de acesso ao webService (gerada pelo webReference) da mesma forma como sempre fazemos, mas ligaremos o objeto webproxy na propriedade proxy antes de chamar qualquer método.

Veja como fica :

'Put user code to initialize the page here
Dim obj As srvCadastro.devCadastro
Dim usuario As New Net.NetworkCredential("administrator", "senha")
Dim proxy As Net.IWebProxy

proxy = New Net.WebProxy("http://servidorproxy:80")

proxy.Credentials = usuario

obj.Proxy = proxy

Feito isso podemos utilizar os métodos do WebService normalmente.