wsn message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsn] WS-Addressing submitted to W3C as input
- From: Steve Graham <sggraham@us.ibm.com>
- To: David Hull <dmh@tibco.com>
- Date: Wed, 11 Aug 2004 17:18:47 -0400
<sgg>comments</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>
08/10/2004 05:09 PM
|
To
|
|
cc
| wsn@lists.oasis-open.org
|
Subject
| Re: [wsn] WS-Addressing submitted
to W3C as input |
|
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.<sgg>correct,
I misspoke, or mis typed, we have references to Web services, some of the
references will be to ws-resources.</sgg>
The architectural notion is thus "destination for sending messages."
<sgg>the architectural
notion is a reference to something that can receive
Web services messages yes.
That leaves the choice of WS-Addressing to be syntactical, not architectural.</sgg>
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.
<sgg>right, because
the EPR returned in subscribeResponse is, by definition, refers to a Subscription
ws-resource. A NC can be any Web service, including a Web service
that happens to be part of a Ws-Resource.</sgg>
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.
<sgg>by "behind
a consumer endpoint" do you mean that the consumer endpoint, once
receiving the notification further distributes it? </sgg>
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. <sgg>true.
but I don't see why this is important to the notion of lets use WS-Addressing
directly, as opposed to wrappering it with some sort of dialect-qualified
expression wrapper.</sgg>
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.
<sgg>the chaos I mean
is that any given requestor needs yet another thing to determine, what
bloody pointer mechanism is being used. no programming language (that
I am aware of) has multiple different kinds of pointer mechanisms. Why
should WSN encourage having multiple kinds of references? lets use WS-Addressing
and at least eliminate one point of needless variability.</sgg>
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>We can still separate
the concept of IRP from the embodiment in EPRs, in particular, to clarify
that the role of reference properties to disambiguate the resources is
ONE way to do it. The current wording gives the strong impression
that using reference properties is REQUIRED. URL encoding the disambiguator
in the http address is perfectly acceptable embodiment of IRP, this is
one thing that will be spelled out in the IRP clarification paper.</sgg>
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
> >
> >
> >
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]