RE: Issue 5; GET vs GetLastTradePrice

Remember that this is a "reference architecture" more  than an actual
architecture.  The purpose is more to a) identify the key architectural
components, b) describe various relationships among them that one sees in
the real world of web services, and c) [maybe] provide some guidance as to
best practices.  Clearly c) is not something we've really addressed yet,
hence the lack of SHOULD, MUST, etc.  (I for one doubt if there will be any
MUSTs in the eventual document...).  The ultimate hope is more that the
various web services stacks will line up with one another (horizontally and
vertically, so to speak) than to prescribe the One True Web Services Stack.
For example, it would be nice for SOAP, WSDL, the various security and
choreography specs, some sort of reliability features, etc. to be able to be
"mixed and matched" with one another rather than forcing one to use a
specific protocol stack in order to get one low-level feature (c.f. COM and
CORBA).  That requires us (as an industry) to sort out some things up front,
e.g. where to draw the line between WS description and choreography, whether
some feature such as transaction management depends on a lower-level
feature such as reliable messaging, etc.

The "generic interface constraint" has been discussed, uhh, once or twice
:-) We have a formal Issue against the current draft that asks us to take a
position  on it.  I (speaking for myself) envision an eventual resolution
that describes the rationale for the "generic interface constraint" and why
some believe it to be so important, and then assesses the situations in
which it is most likely to be useful.  I can more or less guarantee that the
WSA document won't prescribe it as a MUST.

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Friday, January 03, 2003 2:26 PM
> To: Katia Sycara; Newcomer, Eric
> Cc: www-ws-arch@w3.org
> Subject: 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:44:27 UTC