But can't each session can have multiple requests within it? (I'm thinking HTTP sessions here, is that not what you guys are thinking?) I think Ty said he wants unique ids on each request.
On our project, we waited for WS-ReliableMessaging to come to web services (in WebSphere 6.1), that would give us unique ids for each request and response, sequencing of requests, repeated requests that were lost and requests out of order. Lots of good stuff. But we cannot wait any longer. I ended up coding a very primitive message id reflection technique. Client creates a SOAP header called MessageId. Add into it the UUID generated id from, as you say, Java5 (or .NET). The service receives the request and MessageID header, opens the header in a request handler class and stores it in the MessageContext for safe keeping until the response is ready. On the way out, a response handler class creates a MessageId SOAP header, containing, you guessed it, the messageId it gets from the MessageContext. 1. The client is solely responsible for uniqueness. 2. The service does not manipulate the messageId, just stores it. 3. Fault semantics are simple. No messageId available in request header -> Soap Fault. No messageId available when the response is being handled on the way out - > Soap Fault. 4. Any call that times out before a response is received, means obviously that the request was invalid, and a new messageId is generated by the client and the client tries that call again. 5. Such a primitive messageID reflection technique doesn't need a session to work. (Perhaps you need a session for something else, but not for this). 6. Recommend you add in 'To:' and 'From:' addressee fields to the MessageID header, as well as the messageId string field. 7. Recommend that you avoid anything more sophisticated like keeping track of previous messageIds received and sent. It gets nasty, very quickly. (Leave that to WS-ReliableMessaging, when it is ready for primetime). Hope this helps. -jeff -----Original Message----- From: robert lazarski [mailto:[EMAIL PROTECTED] Sent: Friday, September 21, 2007 2:26 PM To: [email protected] Subject: Re: Axis2 Request Tracking I often do session handling this way. What I do is on login, return a token generated by the UUID class in java 5 and later. Then I force the users on subsequent calls to pass in the token or the invokation is rejected. Works great if you can control policy on both sides. HTH, Robert On 9/21/07, tyju tiui <[EMAIL PROTECTED]> wrote: > > I guess I'll do this with the session though it seems wrong ... I can't > think of any other way to handle it. > > I'm still open to suggestions if anyone has a good idea to share :-) > > Thanks, > > Ty > > ----- Original Message ---- > From: tyju tiui <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, September 21, 2007 3:25:48 AM > Subject: Request Tracking > > > I'd like to assign a unique ID to each request as it comes in so that I > might track it all the way through to the outFlow. In other words I want to > give each request a tracking ID so I can go back in my logs and follow a > request's path all the way through my system. > > What do you guys and gals think the best way to do this might be? > > I've thought about doing something with a session variable, but that seems > to go against the stateless nature of WS in general. > > I also thought I might inject the unique ID into the request after I've > received it, but that also seems like a bad idea ... I'm sure there are a > million things that could potentially go wrong doing something like this. > > Your ideas are much appreciated. > > Thanks, > > Ty > > ________________________________ > Boardwalk for $500? In 2007? Ha! > Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! > Games. > > ________________________________ > Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
