RE: Myth of loose coupling

Maybe SOAP Web services advantage over CORBA/DCOM is:
1) Human understandable and widely deployed conceptually simple identifiers
(URIs)
2) Human understandable and widely deployable vocabularies and tools (XML)
3) Human understandable and widely deployed starting protocol (HTTP)

My kind of argument is just that it's way easier for a developer to look at
and understand the protocol, identifiers, and formats with Web services.

BTW, this does lead us to a really interesting discussion area.  If part of
being "on the Web" has to deal with XML, then I see that using XML is a new
"Constraint" on the Web architecture.  So now there is a trade-off (REST vs
whatever) between usage of XML and URI for service identification and usage.
The question is: what does XML have to do with Web architecture?  Is XML
simply a best practice, or is it more significant and indeed a new
constraint?  I think the latter.  Similar to following the uniform
interface, or stateless interaction constraints, following XML accrues
certain benefits.  And following SOAP accrues more benefits (like headers,
processing model).

Here's a way of looking at this that is new to me.  We could say that SOAP
and WSDL are "constraints" of Web services, and XML is a new constraint on
the Web.  If people don't follow those constraints, then they don't get
certain benefits.  So just because a Web site doesn't follow the stateless
constraint, that doesn't mean it's no longer "on the Web".

Back to the "loose-coupling" - this is turning out to be a low-cohesion
message :-)

I guess I'm just saying that I don't buy that the Web is "loosely-coupled".
Sure, you can change the data and the client doesn't break.  But how is this
any different from Word or Acrobat or Email?  Is Word "loosely-coupled"?
Change the format, the software breaks.

I think that marketing has polluted the computer science definition of loose
coupling.  And I'm trying to get us thinking about dealing with the fact
that we actually have highly-coupled systems, and our architecture should
help with that.

Should we start defining things like loose-coupling, applications,
constraints in our arch document?

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Monday, January 06, 2003 5:53 PM
> To: www-ws-arch@w3.org
> Subject: RE: Myth of loose coupling
>
>
>
>
>
> > -----Original Message-----
> > From: David Orchard [mailto:dorchard@bea.com]
> > Sent: Monday, January 06, 2003 4:20 PM
> > To: edwink@collaxa.com; 'Assaf Arkin'; 'Mark Baker'; 'Ugo Corda';
> > 'Champion, Mike'
> > Cc: www-ws-arch@w3.org
> > Subject: RE: Myth of loose coupling
> >
> >
> >
> > Hey, why don't we write a definition of loose-coupling and
> > coarse-grained
> > into our arch doc, and talk about the benefits from a "best
> practice"
> > application thereof?  I'm trying to figure out a way of
> > making this affect
> > the wsa arch documents.
>
> Definitely!  Loose coupling is a "principle" of the Web,
> according to most
> pundits (not sure about the Webarch document).  It's also a supposed
> advantage of SOAP web services over CORBA/DCOM (for reasons
> I'm a bit fuzzy
> about ... I guess because you could move your service from
> Windows to Linux
> or C++ to Python without breaking the client apps).
>
>

Received on Tuesday, 7 January 2003 15:52:35 UTC