As this is to track each request till the response and
does not have any relevance to the requestor, this
need not be part of the SOAP message.
This can be achieved using ThreadLocal - every request
can be assigned a Unique generated ID that can be
stored in a Context assigned to the ThreadLocal.
--- "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.
>
> 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: axis-user@ws.apache.org
> 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: axis-user@ws.apache.org
> > 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]
>
>
_
