Sanjiva Weerawarana wrote: >> Furthermore, the semantics do not >> currently accommodate programming models where the delivery of a >> response is not directly linked to the completion of a method invocation >> (i.e. if the programming model allows for a response to be sent >> explicitly and then processing to continue in the operation >> implementation, the current mechanisms would not provide the same >> semantics in all cases.) >> > > Um why not? If you want to send a response and continue then you can > fire the response off in another thread (or the remaining work in > another thread). I don't think your approach makes sense as a solution > for this scenario at all: you're saying block everything until the > message is gone. > servlet writes response (201 OK) and servlet thread can be recycled/terminated by servlet container. > Also I believe there are issues in realizing your approach with the > servlet thread model as the flow is not really complete until the > response is written and the response doesn't get written until you > relinquish control to the servlet. Seems like a chicken and egg problem > to me. > if response should be sent i think a separate thread should be started (or pooled) to process actual invocation and response message to wsa:ReplyTo/FaulTo and this thread is independent from the servlet thread. > In any case, there's no way to consider this type of a change in time > for 1.0 at this point. I'm happy to continue the discussion on the list > for possible inclusion in a future version, but realistically with the > proposed 1.0 timeframe being like a week away (or even if it was a month > away!) this kind of a change is not an option at this time. > is the way it is done in AXIS2 is= not how it has to be done to handle async WSA? is there any other way?
best, alek -- The best way to predict the future is to invent it - Alan Kay
