-
1. Re: Aren't web services supposed to be easy?
Dan Bracuk Jan 7, 2010 11:10 AM (in response to ilssac)My approach would be to use the this scope instead of the variables scope if I wanted to be able to change the value from the calling page.
-
2. Re: Aren't web services supposed to be easy?
ilssac Jan 7, 2010 11:52 AM (in response to Dan Bracuk)Unfortunatly using the this scope made no differenece.
-
3. Re: Aren't web services supposed to be easy?
ilssac Jan 7, 2010 1:19 PM (in response to Dan Bracuk)With the help of others, I have determined that the problem is that web services do not maintain state. The the this and variables scopes are not maintinaed from request to request.
-
4. Re: Aren't web services supposed to be easy?
Roland Frick Jan 7, 2010 1:35 PM (in response to ilssac)unsubscribe
--
GSN Global Signature Net AG
Bucheggstr. 107
CH-8057 Zürich
+41 (0)44 364 02 75
-
5. Re: Aren't web services supposed to be easy?
ilssac Jan 7, 2010 1:56 PM (in response to Roland Frick)Roland doesn't like me!
-
6. Re: Aren't web services supposed to be easy?
Adam Cameron. Jan 8, 2010 2:33 AM (in response to ilssac)Sorry to not reply to this earlier Ian, but I spotted it when I was in the pub, and was more inclined to focus on my pint than posts on the forums ;-). It's now the morning after the night before, hangover in place.
With the help of others, I have determined that the problem is that web services do not maintain state. The the this and variables scopes are not maintinaed from request to request.
This caught me out a while ago too. If one thinks about it, it makes sense. Despite using createObject() to stick an instance of the web service in a variable, it's not as if the web service object itself (which is on a remote computer) is stored in the variable: it's just the stub on the CF end that's in the variable. CF does not go and grab an instance of the actual web service and store it locally in your variable. How would it do that, for a start? And, really, is it desirable? Generally I'd say "no": you want to be hitting the remote system with each call.
Each call to a web service is its own request, and its own instantiation of [whatever] on the other end of the call. It's entirely possible that the web service is a facade for some other persisted object, in which case state and other scopes can be maintained between requests; but that's entirely down to how the web service is written, and nothing to do with how it is called.
--
Adam
-
7. Re: Aren't web services supposed to be easy?
Dan Bracuk Jan 8, 2010 5:39 AM (in response to Adam Cameron.)Regarding:
I spotted it when I was in the pub, and was more inclined to focus on my pint than posts on the forums ;-).
If you are on version 8 or higher, you can use cfthread in these situations.
-
8. Re: Aren't web services supposed to be easy?
Adam Cameron. Jan 8, 2010 5:42 AM (in response to Dan Bracuk)Regarding:
I spotted it when I was in the pub, and was more inclined to focus on my pint than posts on the forums ;-).
If you are on version 8 or higher, you can use cfthread in these situations.
Hahahahahahahahahahahaha. Nice one.
;-)
--
Adam
-
9. Re: Aren't web services supposed to be easy?
ilssac Jan 11, 2010 8:57 AM (in response to Adam Cameron.)Yup Adam, that is what I've had to learn yet again about this Client - Server world we live and work in.
As I am currently writing both the web service and the consuming service, I would like to pratice how one might create a web service that would maintain state. In my present need we are develping a client -server|client - server system. I.E Human users on their client desk|lap top clients will be using an web interface that will be talking to our external server which in turn will become a client invoking web services to our internal server through a small hole in our firewall that will only allow these two servers to comunicate.
What I'm struggling with is how to best approach this. Are the normal session cookies usable here? If so, can somebody point out how one might work with them in a web service sense.
If the automatic session cookies that I have so long relied on are not available and I have to roll my own state management. Some sugestions on how to structure a web service that will generatate and return a key when first used and then expect that key to be passed back on all future uses would be nice.
TIA
Ian
-
10. Re: Aren't web services supposed to be easy?
Adam Cameron. Jan 12, 2010 3:26 AM (in response to ilssac)I haven't had to do this for a while (like... 5-6yrs), but I found that a web service request can create a session, but each hit starts a new session. From memory we created a token with the first web service call, and passed it back; thereafter each subsequent request for that "session" needed to pass the token back, and we had some code to corelate the token with the correct session via the session factory, and replace the web service request's own session with the "correct" one. Or something like that.
I recall thinking it was a suboptimal approach, but it worked fine. I haven't needed to revisit it, so I have needed to refine it.
Hopefully someone else has a better approach.
--
Adam
-
11. Re: Aren't web services supposed to be easy?
ilssac Jan 13, 2010 3:17 PM (in response to Adam Cameron.)Just to confirm, yes calling the web serive from a system with session management enables, will generate the session data.
But as you allueded to Adam, the cookies that would normally maintain that session from request to request or not passed back and forth with the web service calls as a browser would do it.
What I'm curious about, is there some way to manually do this? I have not thought of how one would easily and cleanly do that.

