RE: Myth of loose coupling

> -----Original Message-----
> From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
> Sent: Monday, January 06, 2003 1:04 PM
> To: 'David Orchard'; 'Assaf Arkin'; 'Mark Baker'; 'Ugo Corda';
> 'Champion, Mike'
> Cc: www-ws-arch@w3.org
> Subject: RE: Myth of loose coupling
>
>
> David,
>
> Loose-coupling is not black or white. It is about minimizing the impact
> of change: when you start deploying system across a set of nodes, you
> have to assume that nodes will evolve. It would be difficult to argue
> that the web does not know how to adapt to change: the web is the only
> application that I know of that is always on and millions of pages are
> updated and structure of web sites are changes on a daily basis.

Indeed the Web observes my definition of loose coupling:

1) Changes to the interface (HTTP, HTML) are few and far inbetween and
relatively cheap (download a new browser)
2) Changes to the interface (the Web interface) do require a change to the
components the interact with it (the user)

#1 is achieved only because the interface of the software (Web browser, Web
server) is extremley generic. On the other hand, other protocols (IIOP,
TxRPC) also observe that and in fact have seen less changes in the past
decade compared to HTTP/HTML. So one may say that traditionally non-HTTP
protocols have a better track record, though IMHO the tables have already
turned.

#2 is achieved only because the component that interacts with Amazon or eBay
is not affected by changes to the interface. That may have something to do
with the superiority of carbon vs silicon.

Where we usually percieve the Web as more loosely coupled than CORBA it is
because the component that uses a CORBA message is written in software and
the component that uses an HTML page is a superior computational device that
cannot be matched by current day hardware/software.

That is why I find the word 'Myth' to be so fitting.

We are doing an Apples to Oranges comparison.

No compare an HTTP multimedia application with a multimedia application
using a C interface (and I have worked with some in the past). You will
observe that same loose coupling. The C interface (get document, update
document) has not changed in years.

arkin


> You are right that changes on data structures have deeper impacts and
> that building a system that can automatically adapt and understand these
> kind of changes is a little futuristic.
>
> But there are a lot of cases where you want to change the implementation
> without changing the input and output data structures. In those cases, I
> believe that Web services designed as a resource with a generic
> interface will be able to evolve with less impact, even more so if the
> service is designed to work asynchronously.
>
> The point here is that forcing developers to break down services with
> multiple methods into resources with unified interface will create
> applications and systems that are easier to evolve and adapt. I am happy
> to demonstrate this point further will a real world use case if you
> think that this assertion is far fetched.
>
> [Note: I am not claiming that the application is easier to develop: like
> I said earlier, RPC is the most developer-friendly abstraction and the
> one that fits the best into current programming languages].
>
> Edwin
>
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org
> > [mailto:www-ws-arch-request@w3.org] On Behalf Of David Orchard
> > Sent: Monday, January 06, 2003 11:22 AM
> > To: 'Assaf Arkin'; edwink@collaxa.com; 'Mark Baker'; 'Ugo
> > Corda'; 'Champion, Mike'
> > Cc: www-ws-arch@w3.org
> > Subject: Myth of loose coupling
> >
> >
> >
> > 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, 14 January 2003 22:20:15 UTC