Passando parametros transparentes para o webservice

bump

Bom eu acho que achei uma solução, mas não tenho certeza de como fazer...descobri que posso setar parâmetros no request/response dos servlets

Minha idéia é:

//lado do JSP em um servlet filter
request.getParameterMap().put("MyObject", myObject);

//lado do webservice em um servlet filter
myObject = (MyObject)request.getParameter("MyObject");

Mas, não tenha certeza quanto a como setar o filtro, eu preciso de um filtro de saída (JSP enviando request para o webservice) e não tenho idéia se o filtro esta setado pra isso. Meu filtro no JSP esta assim:

<!-- FILTERS -->
    <filter>
        <filter-name>ServletParameterFilter</filter-name>
        <filter-class>br.com.teste.ServletParameterFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>ServletParameterFilter</filter-name>
        <url-pattern>*.jsp</url-pattern>
    </filter-mapping>
    <!-- FILTERS -->

No webservice é parecido, mas o url-pattern é /WebServices/*

Estou no caminho certo? alguma comentario?

Duvida conceitual: usando REST eu poderia passar algumas informações (como os do exemplo usuário, modulo, rotina) no cabeçalho HTTP?

Odeio fazer manutenção de programas que têm esses recursos mágicos, como o que você está tentando criar. Isso faz com que seu sistema só funcione em uma determinada versão do seu application server, e em determinadas condições de temperatura e pressão (ou seja, ele fica muito “frágil” e pode até ser que não funcione em produção porque a versão do application server em produção não suporte essas gambiarras que podem ser feitas no application server na versão de desenvolvimento.)
Eu prefiro:

• Que nunca seja usado a sessão do web container em web services (já vi isso sendo usado, mas acho coisa muito porca e difícil de portar para outros web containers, ou mesmo para outros ambientes como .NET ou PHP);
• Que todos os parãmetros que devam ser passados sejam explícitos;
• Que parâmetros que não estejam previstos na especificação original sejam passados em um XML ou outra coisa que permita expansão.

@peczenyj: Eu li um pouco sobre REST agora, mas parece que teria que fazer uma mudança grande demais no sistema e nesse caso seria simplesmente melhor alterar a assinatura dos métodos dos webservices para receber os parâmetros que eu preciso

@thingol: concordo com você, tem seu lado ruim. O problema não esta na minha mão, mas estou tentando achar uma solução que de o menor impacto possível no sistema, sair alterando todos os 150 webservices que tenho aqui. Estou aberto a qualquer idéia…Só não quero meu pessoal gastando 1-2 semanas pra fazer isso, pois tem coisas mais importantes no momento a serem feitas.

Sérgio

Yeap, no cabeçalho ou no body, dependendo de qual método HTTP você pretende utilizar.

Quanto ao problema do tópico, o mais prático seria enviar por debaixo dos panos mesmo, mas como o thingol disse, eu já fiz isso e, na hora da manutenção isso fica sacal de descobrir os parâmetros mágicos que estão sendo passados.

Uma divagação, se você não quer alterar os trocentos webservices que já existem, por que num cria um tipo de identificação de sessão?
Cada requisição agora vira duas, a primeira solicitação envia os dados que você quer, o websevice cria um tipo de pseudo-session e retorna uma identificação pra ela, e a segunda requisição executa realmente o webservice que se quer, mas com a identificação da sessão anterior.
Bem, só uma idéia que tive agora, tem que analisar o overhead da requisição a mais, como enviar a identificação depois(com esse filter que você criou por exemplo), etc…

Rafael, não tenho idéia de como fazer uma pseudo-sessão em um webservice que é stateless. De qualquer maneira acho que sua idéia não foge muito da idéia dos “parâmetros mágicos”, agora parece que virou uma “sessão mágica” hehehe .

Vou testar melhor o código dos “parâmetros mágicos” pois deu um problema do ParameterMap estar com “locked”, creio que vou ter que criar um wrapper pro servletrequest para poder alterar o ParameterMap, só vou ter tempo pra fazer isso segunda-feira, dae eu dou um retorno pra voces.