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

["Newcomer, Eric" <Eric.Newcomer@iona.com>]

Actually, since Monday is a holiday in the U.S., John may not be able to join us.  We may have to schedule the discussion for another time, perhaps during the face to face.

 

Let's focus Monday's call on getting ourselves organized for processing issues at the face to face.

 

Eric

-----Original Message-----
From: Newcomer, Eric
Sent: Friday, July 02, 2004 2:28 PM
To: John Fuller; WS-CAF
Subject: RE: [ws-caf] [Bug 142] New: How does context service know the status ?

Let's discuss this during Monday's call (if we have enough time).

 

Thanks,

 

Eric

-----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Friday, July 02, 2004 8:38 AM
To: WS-CAF
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).