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

 


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

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


Subject: Re: [asap] WSDL corrections


Since all the events and states refer to the life of the service instance, it doesn't look bad.

I remember in LECIS: a statesystem definition for laboratory device control,
there was the superstate like open and closed and the subsystem got messy because
paused and operating were represented as a concurrent supersystem for the other states,
and resume would take you back to a historical selector in the subsystem.
I do agree ASAP is a simpler, cleaner representation.

The qualms I have are that if people want their instances to respond to arbitrary events
and express their statesystem as a subsystem of open.running, a request to change state
would have limitations over defining events: an event happens and shouldn't have to know the state
of the instance.
How do people deal with this in the workflow community?
Do WS-Events or OGSI's service data elements look like the way to deal with application events/transitions,
or should is it better to just let application messages/wsdl operations addressed to the instances
serve as the events?


On Dec 23, 2003, at 7:44 PM, Keith Swenson wrote:

We needed a set of states that are universally implemented and universally understood.  So, yes, both sides must have (at least partial) shared understanding of the state system.

If you have N states, and N*(N-1) potential transitions, clearly there are a lot more transitions to standardize.  We found that for all the universally implemented and understood transitions, these transitions can be suitably represented by the end state.  For example, a "Suspend" event goes into a "Open.Suspended" state, and there is no real need to have several different transitions that all end up in the suspended state.  The only thing of importance is that the system become suspended.  Similarly, "Resume" is a transition to the "Open.Running" state.

The real advantage of this is that two parties can agree on extending the set of states, without having to define all the new transitions.  Say they have a new state "Open.Running.DoubleSpeed" then the command exists to transition into that state without having to invent a new "SpeedUp" transition.

This does not mean that all N*(N-1) transitions are valid.  Attempting an invalid transition still produces an error message.  Transition to "Open.Suspended" from any Closed state is an error in all cases.  Whether you call this transition "Suspend" or "Transition to Open.suspended" is immateral.

I also am familiar with enumerating the transitions that are valid out of a given state.  We simply found that there was no case (from the universal set) where two different transitions were needed to go from any state to a given state.

The API can be extended with additional non-standard functions for particular transitions if desired.  Any such function may have the side effect changing the state.  But the standard states that every system must be able to receive the command "Transition to Open.Suspended" and either return a failure message, or else transition into that state.

I am not opposed to standardizing transitions, if any one wants to propose some I would be happy to help out.

-Keith

-----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Tuesday, December 23, 2003 5:56 AM
To: ASAP
Subject: [asap] WSDL corrections



the WSDL currently has notify and terminated requests and responses,
I believe in the specification these are instead implemented as
StateChanged requests.

***

As an aside, the specification is sort of interesting in that it
suggests events
like terminate, pause, resume, etc be represented as explicit requests
to change to a state
which can be rejected:  both sides are assumed to be aware of the
underlying state system,
or at least it's base (the supersystem).

I've always been used to enumerating events to run against a machine,
where the
behavior is specified for each state.
In the case of this supersystem, maybe we really do want explicit
changes in states,
but for broader applications sometimes the same event might be
represented as causing
a different resulting state given a different initial state.

Just informationally, part of wsmf HP suggests for managing
full-fledged services




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