Steve Graham wrote:
Maybe I misunderstand your point
(wouldn't
be the first time). The architectural notion is that we have
references
to resources.
Not in WSN. Remember, we also use endpoints to refer to
NotificationConsumers, which may or may not be resources.
The architectural notion is thus "destination for sending messages."
In the case of the endpoint returned in SubscribeResponse, we have an
additional constraint: Sending messages to that endpoint must affect
only the newly-created subscription. This may seem too trivial to
mention, but there is no similar constraint on NotificationConsumer.
There might be some sort of multicast semantics behind a consumer
endpoint, such that subscription 1 sends messages to A, B and C, while
subscription 2 sends messages to B, C and D. Why not? We don't really
care. It's up to the subscriber to decide whether a subscription makes
sense.
As far as I can tell, this uniqueness constraint -- that sending
messages to the Subscription[Manager] endpoint will apply to the state
of exactly one subscription -- is precisely what the IRP is trying to
capture.
This discussion boils down to the
syntax.
Does the syntax allow only 1 pointer mechanism (my proposal) or does it
allow n different
pointer mechanisms and the ensuing
chaos
to figure out which pointer mechanism to use for any given Web service.
It's not at all clear to me chaos would ensue. We already have several
issues -- where is the NP anyway, what topics do I want to subscribe
to, should I UseNotify or not, and of course dialectable topic,
precondition and selector -- which seem at least as likely to cause
chaos as dialectable endpoints. If dialecting endpoints is going to
cause problems, there would seem to be a lot more to reconsider.
So from my standpoint, I see this as
only a compatibility issue and syntax issue, a single standard
reference
mechanism to embody
the implied resource pattern.
OK . . . but again this seems to run directly counter to the statement
that IRP is too tightly tied to WSA, and that a WSRF subgroup was going
to look for a way to disentangle the two.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
David Hull <dmh@tibco.com> wrote on
08/10/2004
04:32:15 PM:
> +1
>
> I believe there are two issues here: architecture and
compatibility
with
> existing implementations.
>
> Architecturally, we should generally try to say as little as
possible.
> As has been discussed, the architectural function of an endpoint
is
to
> provide a unique destination for messages. This in itself is
inherently
> future-proof. Any spec that provides a unique destination for
messages
> will work.
>
> While compatibility is a legitimate issue (particularly for those
with
> existing customers using older versions :-) I don't believe it
should
> override architecture. If there are not many more users of the
adopted
> standard than there are of pre-standardized incarnations, we're
doing
> something seriously wrong. In any case, I would think that making
WS-A
> the default dialect would handle many (but not all) compatibility
issues.
>
> Regardless of the final weight we put on compatibility,
architecture
> should be driving the discussion at this point. If we get the
> architecture right, but decide we ultimately want to publish a
less
> abstract standard, that should not present a great problem. On
the
> other hand if we create a specialized document from the beginning
and
> later discover a demand for greater abstraction, we'll have quite
a bit
> of work to do at a bad time.
>
>
> Anish Karmarkar wrote:
>
> > Steve Graham wrote:
> >
> >>
> >> Folks:
> >> Please see: http://www.w3.org/Submission/2004/05/.
> >> This is a submission request to the W3C by BEA, IBM,
Microsoft,
SAP
> >> and Sun to submit WS-Addressing to W3C as input to the
> >> standardization process.
> >>
> >> I would like to recommend that we consider using
WS-Addressing
as
> >> submitted to the W3C in our work in WS-RF and WS-N.
Note,
our use of
> >> WSDL 1.1 (which was a submission to W3C, just like
WS-Addressing
is
> >> now) is a precedence for this sort of pre-requisite.
> >>
> >> I formally move that we use WS-Addressing as our only
means
of
> >> reference mechanism. In particular, I propose that we
avoid
> >> abstracting the reference mechanism, such as BPEL has
done,
in light
> >> of this submission of WS-Addressing to W3C. Note, this
minimizes the
> >> perturbation to the currently specified message
exchanges,
and
> >> reduces migration impediments for implementations that
are
building
> >> to the 1.1 and 1.2 versions of our specifications.
> >>
> >
> > I think this is a very good first step.
> > But I don't see how this changes things for us in the short
term.
> > There are now two submissions made to W3C [1] [2] that
"address"
the
> > same problem domain. There is also an effort to get a charter
> > [3][4][5][6][7] (pl. note that references [5], [6] and [7]
are
> > accessible to W3C member only) for a W3C Working Group. Given
that
> > there are two submissions and that there *may* be a W3C WG,
it
would
> > in fact make more sense to abstract the reference mechanism.
This will
> > also future proof our specs to what ever comes out of a W3C
WG
(if it
> > happens).
> >
> > -Anish
> > --
> >
> > [1] http://www.w3.org/Submission/2004/02/
> > [2] http://www.w3.org/Submission/2004/05/
> > [3]
http://lists.w3.org/Archives/Public/www-ws/2004Jun/0000.html
> > [4]
http://lists.w3.org/Archives/Public/www-ws/2004Aug/0003.html
> > [5]
http://lists.w3.org/Archives/Member/member-ws/2004May/0001.html
> > [6]
http://lists.w3.org/Archives/Member/member-ws/2004May/0002.html
> > [7]
http://lists.w3.org/Archives/Member/member-ws/2004May/0003.html
> >
> >
> >
>
|