Re: Myth of loose coupling

I don't know, but you paid too much for it!!

On Tuesday, January 7, 2003, at 12:20  AM, Assaf Arkin wrote:

>
> Here is a test for you. Can you tell me what I have just bought:
>
> http://www.amazon.co.jp/exec/obidos/ASIN/B00006RT6E/ 
> ref=ed_ec_gw_cs_1_2/249-
> 5515888-2202702
>
> arkin
>
>> -----Original Message-----
>> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
>> Behalf Of David Jacobs
>> Sent: Monday, January 06, 2003 5:43 PM
>> To: David Orchard
>> Cc: 'Assaf Arkin'; edwink@collaxa.com; 'Mark Baker'; 'Ugo Corda';
>> 'Champion, Mike'; www-ws-arch@w3.org
>> Subject: Re: Myth of loose coupling
>>
>>
>>
>> I agree that web servers and browsers are tightly coupled at the HTTP,
>> HTML, CSS, JPEG level.  However, at the application level (and by
>> application I mean something like Amazon's site) I would argue that  
>> the
>> client and server are not tightly coupled.  Amazon can make huge  
>> changes
>> to its service offerings and layout without any changes being required
>> of the client.  I believe it is this flexibility for the application  
>> to
>> change and grow without breaking existing clients that most folks are
>> aiming for when they say "loosely coupled"
>>
>> David Jacobs
>>
>> David Orchard wrote:
>>
>>> I'm baffled that people consider the web to be "loosely-coupled"  
>>> systems.
>>> Guess what, when HTML changed versions, people had to upgrade their
>>> browsers.  The app (browser) changed whenever the user needed more
>>> functionality.  Say a new version of HTML comes out, maybe even
>> XHTML!  Then
>>> a whack of servers upgrade to say they will produce according to the  
>>> new
>>> interface.  And new apps (the updated browsers) come along and
>> can grok the
>>> xhtml.
>>>
>>> It just so happens that HTML, XHTML, CSS, JPEG, etc. have
>> followed a fairly
>>> lengthy centralized standardization process.  And we've kind of
>> settled down
>>> to our current versions.  To prove this point, the current angst  
>>> over how
>>> XHTML 2.0 should define link constructs CLEARLY indicates that the  
>>> app
>>> (browser) is tightly coupled to the interface schema.
>>>
>>> Maybe it will be the same with PurchaseOrders, Invoices, etc.
>> But for now,
>>> we actually want to have it where the interfaces are defined in a
>>> decentralized manner, rather than through a centralized ever-speedy
>>> standards process.
>>>
>>> <rant>
>>> I think we should stop kidding ourselves that we are building loosely
>>> coupled systems when we have well-defined interfaces and protocols.
>>>
>>> We certainly have loose coupling between the applications
>> environments, like
>>> Perl/Java/Python; OSes; app server environments; and the messages.   
>>> Heck,
>>> our software provides about a few  different "mapping" layers  
>>> between xml
>>> and Java.  But fundamentally, if the interface changes, software on  
>>> both
>>> sides has to change.  It can sometimes be nicely isolated from the
>>> application by the mapping layer, but more often than not it can't.   
>>> I
>>> highly doubt that I could change a purchase order schema, and
>> not change the
>>> application.  Try just changing a string Name into a structure of
>>> firstname/lastname and you are doomed.  There are over 10 000
>> rules for how
>>> to figure out firstnames from last names in a string, so the
>> darned sending
>>> software is going to be in hell trying to figure the separation  
>>> rules in
>>> this "mythical" mapping layer that's supposed to insulate it from  
>>> change.
>>> "Just put XSLT in between" doesn't cut it in any way.  We are
>> living through
>>> the agony of this in all the darned infrastructure vocabularies
>> - like the
>>> changes that occur in the ws-security schemas - so why wouldn't the  
>>> app
>>> vocabs?
>>>
>>> The web isn't loosely coupled between the interface schema and the
>>> implementations, it's just that the evolution has almost stopped and  
>>> we
>>> don't remember all the times we had to rev our browser.  And
>> we've now got
>>> cool "auto-update" features that allow us to get the latest flash  
>>> player
>>> without much effort.  The browser has been built to modularize
>> the various
>>> places that the changes can occur, so it doesn't appear as
>> disruptive.  But
>>> it's all still tightly coupled.  Change the interface=change a piece  
>>> of
>>> software.  Nowhere to hide.  The only question is: can you isolate  
>>> the
>>> change to a small piece of software that's on a faster rev cycle  
>>> than the
>>> bigger "container" software?
>>>
>>> Web services can't run from this problem either.  At least we have  
>>> some
>>> great infrastructure pieces to help us deal with change, like
>> soap headers,
>>> xml and namespaces, WSDL.
>>>
>>> </rant>
>>>
>>> Cheers,
>>> Dave
>>>
>>>
>>>
>>>> What we are seeing in practice is that all too often
>>>> developers take the
>>>> easy approach. Rather than defining an interface - whether
>>>> RPC of document
>>>> style - that is decoupled from the implementation, they use tools  
>>>> that
>>>> produce a service definition directly from the implementation API.
>>>> Obviously, as the implementation changes so would every
>>>> application that
>>>> needs to use this interface. Not a Good Thing(tm).
>>>>
>>>> However, nothing precludes you from following best practice,
>>>> defining an
>>>> interface that is decoupled from the implementation,
>>>> performing mapping
>>>> between the abstract interface and the particular
>>>> implementation, and using
>>>> RPC style to represent that abstract interface. WSDL does not
>>>> say that RPC
>>>> has to conform to an API, bad practice makes it happen.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>>
>

Received on Tuesday, 7 January 2003 12:08:53 UTC