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

["Murray, Bryan P." <bryan.murray@hp.com>]

Yes - you have the transition into the state which causes a
notification, and then the transition out of the state into the
"processing" state which causes another notification.

Bryan 

-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com] 
Sent: Thursday, August 12, 2004 9:05 AM
To: Murray, Bryan P.; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups - Request State Model Choices for WSDM.doc
uploaded

Then you'd need to emit notifications from both enter and exit of the
state. Otherwise you'd never know when the request was actually received
and completed.

This is why two boundary states were added.


-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: Murray, Bryan P. [mailto:bryan.murray@hp.com]
Sent: Thursday, August 12, 2004 11:50 AM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups - Request State Model Choices for WSDM.doc
uploaded

I was assuming the model where states take time and transitions are
instantaneous just as you were. This may have been just my
interpretation of the names of the defined states. Names such as
"request accepted" imply a point in time to me. Maybe a name such as
"Receiving message" might better imply a state that takes some time. A
similar name on concluding a request would also help.

Bryan

-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Wednesday, August 11, 2004 11:26 AM
To: Murray, Bryan P.; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups - Request State Model Choices for WSDM.doc
uploaded

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.




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.