Aren't web services supposed to be easy?

[ilssac]

my web service.

<cfcomponent>
    <cfproperty name="id" default="10" type="numeric">
  
  <cfset variables.id = 10>
  
    <cffunction name="setId" access="remote" returntype="void">
        <cfargument name="id" type="numeric" required="yes">
        <cfset variables.id = arguments.id>
    </cffunction>
  
  <cffunction name="getId" access="remote" returntype="numeric">
      <cfreturn variables.id>
  </cffunction>
</cfcomponent>

my test page.

  <p>Call component as web service</p>
  <cfset myWS = createObject("webservice","http://10.104.106.39:8080/ian.cfc?wsdl")>
  <cfoutput>#myWS.getId()#</cfoutput>
  <cfset myWS.setId(888)>
  <cfoutput>#myWS.getId()#</cfoutput>
  <cfdump var="#myWS#">

Both outputs are outputing the same value of 10.  The web service does not seem to be maintaining state from one method call to another.

[Dan_Bracuk]

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.

[ilssac]

Unfortunatly using the this scope made no differenece.

[Guest]

unsubscribe

--

GSN Global Signature Net AG

Bucheggstr. 107

CH-8057 Zürich

http://www.signaturenet.org

+41 (0)44 364 02 75

roland.frick@signaturenet.org

[ilssac]

Roland doesn't like me!

[ilssac]

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.

[Adam Cameron.]

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

[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.

[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.

Hahahahahahahahahahahaha.  Nice one.

😉

--

Adam

[ilssac]

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

[Adam Cameron.]

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

[ilssac]

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.