Re: Issue 5; GET vs GetLastTradePrice

Katia,

>  it would help me if you could mention examples of the constraints that
> would be needed in the architecture specifications, as well as the
pitfalls
> these constraints could avoid. Also, some examples of well known pitfalls
> would be helpful too.

I think an architecture specification should constrain the runtime behaviors
and properties of systems, whereas the "pitfall" I described (below) was
really about a design and development process.  Frankly, I think the
architecture document is the wrong place to look for direct guidance in
that area, although I'll admit that some clues might be found.

For example, on the project I mentioned, we adopted a "generic
interface" constraint for the second phase, namely that all information
retrievals must use http GET.  This did a couple of significant things.
First, it got our group, mostly with very little experience in distributed
systems or messaging, out of the custom protocol design arena.  Although
it occurs to me now that there was nothing preventing them from
piling on the "reliability" protocol stuff from the first phase, all
incentive
to do that was absent.  I can only guess as to how that worked.

The other major benefit was being able to test all of those retrieval
functions without having to write any custom client test software.

It sounds as if you're looking for guidance from my experience in writing
the architecture spec, but I believe my experience can only feed that
process indirectly, if at all, as explained above.  But I will continue to
review
the specification.

A general observation is that I haven't yet encountered the terms "MUST"
or "MUST NOT", although the front matter of the document suggests
they are coming, and without words like that, I'd find it hard to determine
whether some web service conformed to the architecture or not.  Is
that an intended purpose of the document, do you know?

Walden

>  Thanks, Katia
>
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Walden Mathews
> Sent: Friday, January 03, 2003 11:00 AM
> To: Newcomer, Eric
> Cc: www-ws-arch@w3.org
> Subject: Re: Issue 5; GET vs GetLastTradePrice
>
>
>
> Eric,
>
> At your invitation below, I've started to review the current editor's
draft
> of the
> architecture document.  I'm just a little way into the "Extended Web
> Services
> Architecture" section.  My comment at this point is that I don't think the
> architecture
> document I'm reading would have provided the kind of guidance needed to
> avoid the pitfalls I mention below.*  I was dismayed to find that the
"Basic
> Architecture" section accomplishes little more than describing what most
of
> us would readily recognize as client-server, plus a directory function.
Why
> the
> directory function is so prominently featured in the basic architecture, I
> don't
> understand at all.  Most notably, there seem to be no constraints to speak
> of
> in this document.  How do you avoid pitfalls without constraints?
>
> Not to get too far off the track. I'd be happy to give further comments
and
> suggestions on the applicability of the architecture document to projects
> like
> the one I experienced last year.  But there is still this claim you have
> made
> about document mode "middle ground", which I would like to better
> understand.
>
> Walden
>
> * On proofreading this before sending, I'm wondering at this point if the
> arch
> document is intended for that purpose.  One reason it wouldn't have helped
> is
> that I don't think I could have convinced anyone on the project to read
it.
> It's
> very wordy, and frankly quite contradictory and confusing in many places.
>
> ----- Original Message -----
> From: "Newcomer, Eric" <Eric.Newcomer@iona.com>
> To: "Walden Mathews" <waldenm@optonline.net>
> Cc: <www-ws-arch@w3.org>
> Sent: Thursday, January 02, 2003 11:00 AM
> Subject: RE: Issue 5; GET vs GetLastTradePrice
>
>
> >
> > Walden,
> >
> > I hope the WS Architecture work will clarify the picture and provide
some
> "best practices" information that will help avoid pitfalls.  If you get a
> chance, please review the current editor's drafts and give us your
comments:
> >
> > http://www.w3.org/2002/ws/arch/
> >
> > Regarding tools, I only intended to refer to standard tools such as
XSLT,
> DOM, and Sax...sorry if I wasn't clear on that point.
> >
> > Eric
> >
> > -----Original Message-----
> > From: Walden Mathews [mailto:waldenm@optonline.net]
> > Sent: Thursday, January 02, 2003 10:37 AM
> > To: Newcomer, Eric
> > Cc: www-ws-arch@w3.org
> > Subject: Re: Issue 5; GET vs GetLastTradePrice
> >
> >
> > Eric,
> >
> > > Yes, I was trying to draw a distinction between the case where
> > applications share semantic information totally out of band, and the
case
> in
> > which applications rely totally on automatic discovery mechansisms to
> share
> > semantics.  I think there's a middle ground that we sort of avoid when
we
> > polarize the discussion as "REST vs RPC/SOAP" or "specific interfaces vs
> > generic" or whatever.
> >
> > I'd like to get clearer on what that middle ground is.  Last summer I
got
> > involved in a project that
> > had already decided to use XML in a "document" mode as opposed to a
"RPC"
> > mode, but the
> > distinction was only skin deep, at least according to my analysis.  The
> > approach was still leading
> > these developers in the direction of inventing a ton of new protocol,
when
> > very little new protocol
> > was actually needed.  In effect, they were doing the work that the
> > RPC-framework tools do, so
> > they were getting the worst of both worlds.  I wonder if the WWW
> > architecture will provide the
> > guidance they would need for avoiding that pitfall.
> >
> > >
> > > What I was trying to say is that XML tools can help reduce the custom
> > coding effort, not eliminate it altogether.
> > >
> >
> > Oh, I didn't realize this was about tools.  Would it be feasible to have
> the
> > discussion sans the
> > mention of tools?  Are tools really central to the problem of getting
two
> > applications to understand
> > each other, or are they an optimization to apply deeper solutions to
that
> > problem?
> >
> > Does the inclusion/exclusion of tools affect your view of what that
> "middle
> > ground" is?
> >
> > Walden
> >
>
>

Received on Friday, 3 January 2003 14:26:11 UTC