public class HelloImpl {
public String sayHelloWorld()
{
return "Hello World Web Service ";
}
}[/code]
para
[code]public class HelloWorld {
private int i=0;
public String sayHelloWorld(String x)
{
return x + "Hello World Web Service " + ++i;
}
}
Porém ao invocar o método pelo “Web Services Test Client”, ao invés de obter um incremento na variável “i” a cada chamda do método, ele sempre retorna o número 1…
Estou com um pressentimento que estou com alguma falha grave na teoria da coisa, se alguém puder dar alguma luz eu agradeço.
Provavelmente para cada chamada ao WS é instanciado um novo objeto da classe HelloWorld. Não é recomendado que o WS mantenha estado.
Grave o “i” em algum banco ou arquivo texto.
A teoria diz que web services, num mundo ideal, são sem estado, ou seja,variáveis de instância não deveriam ser usadas. Acredito que isso varie de conteiner pra conteiner (e de linguagem pra linguagem… ), mas acho que você não deveria considerar variáveis de instância no seu web service, já que o estado dele poderia afetar as requisições de outros clientes (o que não é legal).
Quanto à frase “o que é disponibilizado, o método ou a classe?” : lembre-se , web services são independentes de linguagem de programação. Nem todas as linguagens têm classes, certo? (acho que você entendeu onde eu quero chegar…)
Eu estava querendo usar o WS da maneira incorreta.
Por exemplo: se eu fizesse um software de jogo de truco onde cada um dos jogadores será implementado via webservice, eu não posso ter um método jogador.recebeCartas(cartas) pensando em utilizar essas mesmas cartas em um outro método (por exemplo jogasor.jogar()). Quem deveria fazer esta lógica de quais cartas cada jogador tem deve ser o CLient do WS, correto?
Então, se eu tivesse projetado um software de truco local e quisesse agora fazer com que ele utilizasse um “objeto remoto”, a mudança não é simples como simplesmente usar os métodos de um WS.
Resumindo: se eu quiser utilizar os métodos como se eu tivesse um objeto instanciado localmente eu devo usar banco de dados no cliente do WS para persistir o que eu usaria como atributos da classe.
Tudo o que está escrito aí em cima é um monte de besteiras. :-o
O WebService pode sim manter estado, estou usando o plugin Axis no Eclipse e existe um parâmetro que diz qual é o escopo do WS, ou seja você pode escolher quando será criado um novo Objeto ou não.
Portanto, como na minha mensagem anterior, para criar um jogador de truco remoto bastaria criar o WS e fim de papo, bastando deixar o escopo como “Session”. 8)
Pra bom entendedor, meia palavra basta. Se você acha que Web Services se resumem ao Axis, vá em frente. Pra quem desenvolve essa $%$& todos os dias, o que você está dizendo não é nenhuma novidade. Agora, tentar fazer com que os outros evitem fazer cagadas não é nada fácil.
Quem disse que não “pode”? Disseram que não “deve”… é totalmente diferente… um WebService por conceito é um serviço, que recebe dados, e retorna dados processados, independentemente dos outros acessos que o mesmo venha a receber… ele foi concebido tendo em mente uma abordagem “Stateless”, que não grava estados, justamente pra garantir essa independência de acessos… no caso de um jogo de truco, você acaba criando uma aplicação na arquitetura cliente-servidor, onde existe o servidor de truco, e os clientes, e o servidor é “statefull” pois precisa manter o controle das cartas, pontuação, etc…
Pra bom entendedor, meia palavra basta. Se você acha que Web Services se resumem ao Axis, vá em frente. Pra quem desenvolve essa $%$& todos os dias, o que você está dizendo não é nenhuma novidade. Agora, tentar fazer com que os outros evitem fazer cagadas não é nada fácil.
Mas vá em frente com seu jogadorzinho de truco.[/quote]
Ei ei ei, sem ficar nervosinho. Desculpe se eu ofendi, peguei pesado com “um monte de besteiras”. :roll:
Como deve ter percebido pela mensagem eu sou iniciante no assunto, não desenvolvo WS todos os dias, e demorei um certo tempo para descobrir como manter os parâmetros entre as chamadas.
Quanto ao jogo de truco, só usei por ser um exemplo bastante usado em OO.
[quote=_Renan]
Quanto ao jogo de truco, só usei por ser um exemplo bastante usado em OO.[/quote]
Pois é, então, você tem um problema sério, porque Web Services são, em alguns aspectos, conflitantes com OO. Então, não tente imaginar serviços como objetos.
EDIT - Só pra você saber, sabe qual é a maneira enterprise de fazer web services manterem estado? Transforme-os em Session Beans.