OK. Apologies to you and the TC that we haven't got
the next release out yet, but it's taken a little longer than expected.
Hopefully next week (though my fellow editors may hit me for putting such a
stake in the ground ;-)
Mark.
---- Mark Little, Chief Architect,
Transactions, Arjuna Technologies Ltd. www.arjuna.com
----- Original Message -----
Sent: Thursday, May 27, 2004 10:32
AM
Subject: Re: [ws-caf] interesting
document
Mark,
Thanks, I thought I read those minutes. I am
looking forward to the new draft.
Guy
On donderdag, mei 27,
2004, at 11:16 Europe/Brussels, Mark Little wrote:
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./smaller>/fontfamily> Mark./smaller>/fontfamily> ---- Mark
Little, Chief Architect, Transactions, Arjuna Technologies
Ltd. www.arjuna.com /color>/smaller>/fontfamily> -----
Original Message ----- From: Guy
Pardon/color> To: Green,
Alastair J./color> Cc:
Mark Little/color> ; ws-caf/color> 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. 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. Where does this
leave the independent value of WS-Context
context-by-value? These points are orthogonal to the issue:
header element in the raw, body element in the raw, or element
embedded in an address. Alastair
-----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 And
Savas is a member of this TC (though I don't think he's ever attended any of
the teleconferences ;-) Mark. ---- Mark
Little, Chief Architect, Transactions, Arjuna Technologies
Ltd. www.arjuna.com
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.
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>
|