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
- From: "Furniss, Peter" <Peter.Furniss@choreology.com>
- To: "Newcomer, Eric" <Eric.Newcomer@iona.com>,<ws-caf@lists.oasis-open.org>
- Date: Wed, 30 Jun 2004 00:58:05 +0100
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
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.
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]