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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: Fwd: [ws-caf] [Bug 142] New: How does context service know the status ?




Begin forwarded message:

From: John Fuller <jfuller@wernervas.com>
Date: July 2, 2004 7:36:20 AM CDT
To: bugzilla-daemon@arjuna.com
Subject: Re: [ws-caf] [Bug 142] New: How does context service know the status ?

Does it look like the ASAP TC work could be used here?
In ASAP, a factory creates a service instance and returns an xsd:AnyURI which can then be queried or subscribed to
for state changes, when the instance completes, a CompletedRequest is sent to observers.
The creation request carries an xsd:Any contextdata element, the completed request carries an xsd:Any resultdata element.
In WfXML, the idea is that the ASAP service instance creates activities which have similar interfaces.

I know in CAF the idea is that an activity is being performed across different services,
but I wonder if the ASAP operations couldn't be used with CAF Header or ContextData/ResultData
to accomplish what you're looking for?

Just a thought.

On Jul 2, 2004, at 6:41 AM, bugzilla-daemon@arjuna.com wrote:

The context service reference (address) is not propagated in the context )
context service identifier is not dereferencable) and need not necessarily be
co-located with the context manager (otherwise why are they different
interfaces). Yet for all context types (?), the originating context service
knows the current status of the activity and invoking complete will cause a
status transition to Completing.

How do the activity participants know the state of the activity ?

How are the participants made aware of the transition to Completing ?

How does the context service know the transition from Completing to Completed
has occurred ?

Obviously, a referencing specification could be devised that provided
additional registration and status propagation facilities, and which imposed co-
location requirements (or at least common-knowledge requirements) on these
services and the ContextService. But the status mechanisms should be part of
that specification rather than the base context. This would allow the ref.
spec. to define the status mechanism it needed (e.g. combining the
activity.status and the completion status, if it so chose).



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