RE: [ws-caf] bug 135 - participating services list

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Title: Message

Eric,

 

It isn't me that is arguing in an imaginary world about a theoretical ref. spec that might one day come into existence and might find the p-s-list with its current element types exactly what it needed. I'm saying that the real (sort of) world of the current spec doesn't have a mechanism for it, and it is therefore devoid of effective meaning. I am not saying it could never have a use, or that a protocol to control its content cannot be devised. I am saying that, absent a mechanism for maintaining it, it has no purpose. And we are agreed, I believe, that the current spec should not contain such a mechanism. Thus, since it is broken as it is, the simplest way to progress is to remove the field.

 

If, on the contrary, you are sure it has a use, can you confirm what the datatype of the elements should be ?  It is currently a uri, but surely a list of participating services should be a list of service-refs. If we knew what the controlling mechanisms were, that question could be answered easily.

 

Peter 

 

 -----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: 30 June 2004 18:06
To: Furniss, Peter; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] bug 135 - participating services list

No but the list could be very important to another referencing specification.  We are arguing in an imaginary world here in which you say you don't see any purpose to the list and I say that I do.  In that case I belive the simplest and most effecient way to progress the spec toward committee draft (which is what we all want to do as soon as possible) is to leave things along that are not demonstrably and emprically broken.

 

Let's please stop these theoretical discussions and get on with what really needs to be settled in order to approve the committee draft at the F2F.

 

 

Thanks,

 

Eric

-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Wednesday, June 30, 2004 12:00 PM
To: Newcomer, Eric; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] bug 135 - participating services list

Eric,

 

The input versions of WS-CF and WS-TXM make no reference to the p-s list. If the revised versions were to define semantics and implementing actions for such a list, they ought to add it as part of their extension to the base context. To fill in semantics on an existing field is preposterous. Can some other spec (such as by-reference propagator using http, as you've hinted at) gave it significantly different semantics.

 

As it is, this is a junk field. It doesn't mean anything. It probably has the wrong constittuent type. Fixing it would be significant effort. Take it out.

 

Just because the original authors thought this field might be useful, and we haven't discussed it before because it's flaws were hidden among a lot of more significant problems is no argument for leaving it in. It is broken.

 

Peter

 

 

 

ps. getting such a list to work with ws-cf, ws-txm looks a doubtful starting point. Transaction context, as has been agreed i think, are "naturally" propagated by value. The registration mechanism of WS-CF means that the participation knowledge is accumulated at the coordinator (could be an interposed coordinator), which might help with the basic problem of p-s-list. But the propagated contexts were sent out before the participation was known. So now an entity wanting to know the list has to get an update - to which service - the coordinator or the context manager. So it must dereference a context it received by value. And do interposed coordinators have to deliver lists of their inferiors higher up. It looks like it might be better to be able to ask a coordinator "who is registered with you", and not use a list in the context itself. 

 

Also, a WS-CF identifies the participant by its own identifier (of some sort - obviously liable to change), which may not be the same as the service that received the propagated context. which belongs in a p-s-list ?

 

 

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: 30 June 2004 15:44
To: Furniss, Peter; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] bug 135 - participating services list

Peter,

 

You are arguing that we should change something in the current spec because we don't know yet what the referencing specs will do with it.  That is an argument to wait and see what impact, if any, the referencing spec(s) will have on the current spec.  Certainly when we start on the changes for WS-CF and WS-TXM we can revisit this question and at that time if a change is necessary to WS-Context then we can make it at that time, and be sure what it needs to be rather than guessing, which we are basically having to do now.

 

So - can we agree to revisit this when we are starting work on the referencing specs rather than trying to anticipate the situation?

 

Thanks,

 

Eric

-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Tuesday, June 29, 2004 7:58 PM
To: Newcomer, Eric; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] bug 135 - participating services list

It's not that difficult to define the concept in a hand-waving sort of way. But, as I hope I've made clear in the long messages I sent last week, it isn't a a reference point for anything unless there is a significant and mandatory protocol to maintain it. Information about which services are "participating" won't ooze into a single place by magic. It requires ALL the participating services to do their bit to register their participation (or all the invokers of all the services, which might or might not be simpler and would give a distinctly different semantic).

 

You've suggested that we discuss some lightweight sharing mechanism to handle this (I'm still not certain that is what you were talking about). I've put in two longish messages outlining possible mechanisms, which have various problems. Could you give some more details on how you think this will work ?

 

Or are you suggesting that we should keep a field in ws-context which is "sort of a participating services list", with no clear semantics ?  If a referencing specifcation is defined that gives it a well-defined meaning, that specification can put the field in an extension - it has no business in the base schema, any more than other fields whose semantics are defined by referencing specifications.

 

Hand-waving "specification" may work within a closed community, or between instances of the same implementation - informal communication between the programmers can deliver distributed communication sufficiently. But with supposedly interoperable specs an enormously greater level of detail has to be provided. You cannot just trust the other side to understand what you thought - you have to nail done the required behaviour of all the systems so their implementors know precisely what they must do and what they can expect others to do.

 

Peter

 

 

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: 29 June 2004 23:39
To: Furniss, Peter; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] bug 135 - participating services list

Peter,

 

No, I disagree.  It can be easily defined, that is, as a reference point for other services to find the list of other participating services.  It is an optional element in any case and therefore does not represent a problem in the spec.

 

Eric

-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Tuesday, June 29, 2004 12:56 PM
To: ws-caf@lists.oasis-open.org
Subject: [ws-caf] bug 135 - participating services list

I would like to formally propose, as a resolution of bug 135, that the participating-services-list element be removed from the WS-Context document and schema.

 

http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=135

 

As I think the discussion on this has shown, appreciable additional specification is required to make it work, and that specification would want to constrain the general flexibility of ws-context. It should therefore be considered as a candidate for a "referencing specification", and not part of the base ws-context.

 

 

Peter

 

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email: peter.furniss@choreology.com
phone: +44 870 739 0066
mobile: +44 7951 536168