Guy, all of what you say is accurate given the 0.2
draft. However, it is not accurate given the changes that were agreed at New
Orleans and minuted as such. Until we can get that draft out, I'd encourage you
to read the minutes of that meeting.
Mark.
---- Mark Little, Chief Architect,
Transactions, Arjuna Technologies Ltd. www.arjuna.com
----- Original Message -----
Sent: Thursday, May 27, 2004 9:21
AM
Subject: Re: [ws-caf] interesting
document
To me that seems like a good point.
The current specs
say that the application is responsible for terminating subcontexts first. So
that would eliminate a need for notification between CTX services.
But
what happens if a context is terminated where active subcontexts exist (for
the sake of this example, let's say these subcontexts are from another CTX
service). The draft now says that these subcontexts are to be set to
FAIL_ONLY (by the terminating CTX manager!), but where is the information that
allows the relevant services to be located?
Or, even simpler, how can
the active status of those subcontexts be determined at all? The only
available information is the URI to retrieve the context's content from, and
that content does not include the status... Or maybe I missed a section
that says that only _active_ subcontexts are to be included in the child
context list?
Again, this is with the 0.2 draft so it may be stale
information given the 0.3 changes.
Guy
It
would also be interesting to consider, in the light of Jim
and Guy's exchanges, what role activity completion plays, if any?
Activity completion can only be communicated to context recipients if they
are registered with the context service that knows that the activity is now
complete. WS-Context does not define such a registration-notification
mechanism. This continues to leave in question the independent value of
WS-Context context-by-value. This type of functionality must reside in
the surrounding protocol (session, coordination etc) that in my example is
denoted by the namespace URI indicated by the prefix "protocol" (the
"referencing specification"). An example of such a protocol is WS-CF, or in
truncated form,
WS-Coordination./smaller>/color>/fontfamily> As
there is no bundle of contexts specified by WS-Context (if my understanding
has kept pace with the spec changes), the argument that value is provided by
easing interception (simpler to identify the group of contexts that must be
processed by a set of interceptors), becomes a non-argument./smaller>/color>/fontfamily> Where
does this leave the independent value of WS-Context context-by-value?/smaller>/color>/fontfamily> These
points are orthogonal to the issue: header element in the raw, body element
in the raw, or element embedded in an address./smaller>/color>/fontfamily> Alastair/smaller>/color>/fontfamily>
-----Original
Message----- From: Mark Little
[mailto:mark.little@arjuna.com] Sent: 26 May 2004
16:45 To: ws-caf Subject: [ws-caf] interesting
document
http://forge.gridforum.org/projects/dais-wg/document/draft-ggf-dais-mappings-ggf11/en/1/color>/fontfamily>/smaller> And
Savas is a member of this TC (though I don't think he's ever attended any of
the teleconferences ;-)/smaller>/fontfamily> Mark./smaller>/fontfamily> ---- Mark
Little, Chief Architect, Transactions, Arjuna Technologies
Ltd. www.arjuna.com /color>/smaller>/fontfamily>
Dr.
Guy Pardon ( guy@atomikos.com ) Atomikos: Your Partner for Reliable
eBusiness Coordination http://www.atomikos.com/
The information in
this email is confidential and only meant for the addressee(s). The content of
this email is informal and will not be legally binding for Atomikos. /fontfamily>
|