Maybe I misunderstand your point (wouldn't
be the first time). The architectural notion is that we have references
to resources.
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.
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.
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
David Hull <> 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
> >
> >
> >
>
