RE: [asap] WSDL corrections

[Keith Swenson <KSwenson@fsw.fujitsu.com>]

Thanks for asking the question.

 

Wf-XML 2.0 extends ASAP to a much more extensive state system.  We introduce the concept of an "activity".  The service instance state then is really the combination of the overall service state, and the states of all the activities.  It is the activities that define what events may be received at a point in time.  Wf-XML defines an operation to retrieve a list of all the enabled (or running) activities.  Typically, receiving an event will "complete" an activity, often causing a new activity to be enabled. Activities can also be enabled or completed by internal (invisible) event, such a the passing of a deadline, or the completion of one activity may cause others to become completed.  There is no limit on the number of activities, so state is represented by a collection of activities.  This maps into many system's requirements to represent state and transition to a new state.

 

Wf-XML is unique in the ability to respond to the question: "what events can be used now".  The list of enabled activities is effectively a list of the kinds of events that the asynchronous service can receive.  While BPEL defines the interaction of two services, it defines the messages that can be received in what order, there is no (standard) way to ask what the current state of a running service instance is in.  WF-XML provides this (on top of ASAP).

 

The result is that ASAP only needs to be concerned with the overall state of the entire service instance, usng a set of well defined universal states.

 

I would very much like to know more about the relationship between WS-Events or OGSI's service data elements and these kinds of "Activity oriented" exchanges.

 

-Keith

-----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Wednesday, December 24, 2003 4:52 AM
To: Keith Swenson
Cc: ASAP
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