RE: Myth of loose coupling

Mike,

+1,

PS: The question is when we will start moving fwd on the documents.

From the discussions on the list, it seems that we are stuck in the sand....


abbie


> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
> Sent: Wednesday, January 08, 2003 9:47 AM
> To: www-ws-arch@w3.org
> Subject: RE: Myth of loose coupling
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Walden Mathews [mailto:waldenm@optonline.net]
> > Sent: Wednesday, January 08, 2003 9:09 AM
> > To: David Orchard; www-ws-arch@w3.org
> > Subject: Re: Myth of loose coupling
> > 
> > 
>  
> > The crux of the matter lies in this statement (from above): "These 
> > parameters have to be sent somehow."  There's a paradigm shift in 
> > understanding why that's not quite true when you use a web of 
> > resources
> more 
> > optimally to solve your problem.  I'm not saying you never need to 
> > send
> > parameters, so please avoid an absolute interpretation here.  
> > I'm saying that long lists of
> > parameters in queries is a symptom of the client taking too 
> much risk in
> > second-guessing the capabilities of the service, a practice 
> which can
> backfire under
> > internet conditions.  I'll stop here and see if there is any comment
> > or question.
> 
> 
> Hmmm.  I've been trying to reconcile the RESTful and 
> SOAP/WSDL web services
> perspectives by asserting that it's NOT a paradigm shift, but 
> an engineering
> decision about optimizing specific scarce resources in 
> specific scenarios.
> SOAP/WSDL tends to optimize programmer resources when there 
> is existing code
> on both sides to integrate over the Web (the most typical 
> business case for
> this technology today), REST tends to optimize re-use of exisiting Web
> resources, integration with Web technologies, and discovery 
> in much more
> loosely coupled (and written for the Web) applications. I 
> think that's close
> to the position I thought you were taking at the beginning of this
> incarnation of the thread, i.e., that there was a big middle 
> ground between
> the REST and SOAP/WSDL approaches.
> 
> Sure, the *extremes* of a pure SOAP-RPC and a pure hypermedia/SW REST
> architecture could be thought of as different "paradigms". 
> Still, as several
> of us point out repeatedly, even hard-core WS people acknowledge the
> scalability problems and fragility of the pure RPC approach. 
> Likewise (ahem)
> the pure hypermedia/Semantic Web approach to addressing the 
> use cases that
> Web services people talk about [as opposed to spiders, cows, and
> circles/rectangles :-) ] looks a bit vaporous when it comes 
> down to actual
> implementations in the field.   So as a practical matter 
> today, we're all
> somewhere in the middle.
> 
> So, I (if that was me who said "these parameters have to be 
> sent somehow")
> was referring to "parameters" in a very abstract sense, not 
> as arguments to
> a remote procedure call, e.g. "query parameters", "business process
> parameters", etc. I do agree that as a best practice 
> guideline, "long lists
> of parameters in queries" is a symptom of a too-tight  coupling or a
> too-desperate attempt to throw some stuff at the service and 
> hope it can
> make sense out of it. 
> 
> So, my bottom line remains: let's mine REST for best practice 
> guidelines and
> suggestions how to build web services that scale to the Web.  
> Let's not get
> caught up ideological struggles between contending paradigms.
> 
>