OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Or you introduce boundary states. Either way is fine.

The problem with the transitions is that how do you identify "enter to the first state" and "exit from the last state". This would require either naming/identifying ALL transitions or naming/identifying the unique StartOfLife and EndOfLife states which may not be very meaningful for everything.

This is why the explicitly named no-duration states were introduced in the WSLC model. Once you do that and assume all transitions are instantaneous you could just say that notifications are emited from the enter state. This way you get all the information necessary.


-- 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 12:08 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] Groups - Request State Model Choices for WSDM.doc uploaded

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.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]