RE: Issue 5; GET vs GetLastTradePrice

Walden,
 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.
 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 11:23:30 UTC