RE: [wsdm] Groups - Request State Model Choices for WSDM.doc uploaded

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

I think what is bothering me about the request state models is that we are trying to combine the request processing system of a web service with the execution of a single request. 

<IS>I'm not sure why you think so... The states are of a request being processed by the web service endpoint. There is no mix and the definition is fairly precise, IMO.
In other words I can say "endpoint A accepted a request B" or "request B was accepted by an enpoint A". What is the problem?
</IS>

Also we have mixed the "states"
such that some of them represent a point in time and others represent an ongoing activity.

<IS>Not necessarily. It depends on the interpretation of states. E.g. Request Completed, could be customized into, for example, open socket -> send -> close socket. That is Request Completed itself is not anymore instantaneous. The thing is anyway you model states you'd likely to have initial and end states (start of life/end of life) which are boundaries and cannot have duration.</IS>

A request processing system (part of a web service) might have states such as: waiting for request, deserializing message, authenticating/authorizing sender, dispatching to business logic. I would expect that the transition from one state to the next might produce a notification. Some request processing systems will execute requests in-line one by one so their states could be included here.

<IS>Yes... Ok. That is what we're NOT modeling with those states.</IS>

Other request processing systems will parallelize the execution of several requests at once and individual request process would not make sense here.

<IS>Yes... But it does not change the fact that every request is being accepted and then completed by the system. So it does not affect the model that was described. And it is good, because endpoint implementation choices are not restricted and do not get in our way for defining the manageability capabilities.</IS>

The states involved in a single request become a little more difficult to define precisely because different request processing systems might be less capable and thus the request itself will need to handle some of the tasks that might otherwise have been handled by the app-server. 

<IS>The "request itself will need to handle some tasks"?? I'm not sure I'm following this. How could "request" handle anything? It is just a piece of information -- a message?</IS>

If we assume support from an app-server, all requests will have a state for executing business logic. Transitions to that state would be request received. Transitions out of that state would be business processing complete. But these would not be states of themselves - they are just transitions. Some requests might have additional states for generating response, serializing response, sending response and a similar set for failures. Transitions between these might produce notifications. Not all requests will result in either a response or a fault message being sent (one-way messages) so the state model needs to allow for bypassing these states.

<IS>Yes, ok on the one-way messages part. There has to be processing->EOL transition.
In the current model, notifications ARE generated against the transitions, only that to identify such notifications we use states which such transitions point to. That is why SOL and EOL are not "notifiable" and need explicit boundary states on the UML diagram.</IS>
</IS>

I have assumed that notifications are sent on transitions from one state to another and have tried to name states as if they take some time and are not an instant in time.

<IS>There are basically two ways to model states: 1) transitions have duration and states are instantantaneous and 2) states have duration and transitions are instantaneous. The mix does not make much sense as it can be "expaned" to either of the models for consistency. 1) and 2) could be converted to each other without any loss.
So, in this doc I've used 2) </IS>

I am not sure whether we are trying to model the request processing system or just a request. Maybe we can combine them somehow. Whatever is done we need to allow for one-way messages in our model.

Bryan

-----Original Message-----
From: Igor.Sedukhin@ca.com [mailto:Igor.Sedukhin@ca.com]
Sent: Thursday, August 05, 2004 4:50 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] Groups - Request State Model Choices for WSDM.doc uploaded

The document Request State Model Choices for WSDM.doc has been submitted by Igor Sedukhin (Igor.Sedukhin@ca.com) to the OASIS Web Services Distributed Management TC document repository.

Document Description:


Download Document:  
http://www.oasis-open.org/apps/org/workgroup/wsdm/download.php/8491/Requ
est%20State%20Model%20Choices%20for%20WSDM.doc

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsdm/document.php?document_
id=8491


PLEASE NOTE:  If the above links do not work for you, your email application may be breaking the link into two pieces.  You may be able to copy and paste the entire link address into the address field of your web browser.



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou
p.php.