Hi Jeff, On 9/21/07, Walker, Jeff <[EMAIL PROTECTED]> wrote: > 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.
I'm not talking about sessions - I'm not a believer when it comes to web services. Its why I mentioned generating the UUID on login and return it. I prefer to return it as one of the vars that a login returns. Its needs to be presisted for which I use ehcache so the client can send it back in. You say you are using handlers. I personally avoid those here - and just return an object with the uuid included. > > 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. > WS-ReliableMessaging and more interesting to me, WS-SecureConversation , is worth exploring. Keep in mind addressing already has an uuid. The problem I always run into with those are lacking implementations I trust on all the potential clients and servers. Hacking up a UUID solution is something any mid-level programmer can do in a few days, and every language supports UUID these days. > 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. Why give responsibilty to the client on something so important ? > 2. The service does not manipulate the messageId, just stores it. That's essential I think, though I'd generate it on the server. > 3. Fault semantics are simple. No messageId available in request header > -> Soap Fault. Soap Faults are a PITA. There have probably been 30 jira's on that in the two years of axis2's existence. They seem to work well now, thru much effort which of course is appreciated. Who knows how well all the other languages do there. I prefer to return 0 on success and define error codes on the rest. Simple and is fail proof. > 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. Again, why leave that up to the client ? > 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. You are depending on the MessageContext API which changes a lot on every release. That'll only work consistently, barring the frequent and often drastic changes, in axis2. The idea I try to implement in my code is an approach that'll work in any language independent of any standards, ie, .net clients and servers which I somehow end up having to at least co-exist with. > 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 > > Likewise, barring anything prime time its always intrigues me to see how people in the real world do this. What you are doing I'm sure works fine. Cheers, Robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
