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: RE: [ws-caf] bug 135 - participating services list


Title: Message
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
 


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