RE: Myth of loose coupling

> > 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.
> >
>
> Edwin, I completely agree with this point.  But this is separate
> from what I
> was raising.
>
> Point #1 (my point): Changes to input/output data structures almost
> invariably change some portion of implementation software
>
> Point #2( your point): Changes to implementation don't necessarily affect
> input/output data structures.
>
> There are kind of 2 different definitions of loose coupling:
> 1) Changes to the interface do not affect software
> 2) Changes to the software do not necessarily affect the interface.
>
> I'm focusing on #1, not #2.

David,

There is always a change to the interface that would require a change to the
software and vice versa, unless the interface is either extremley abstract
(interface = any data) or extremley simple (interface = no op), but all
software supports these two interfaces anyway.

So what we have is actually a basis to prove the impossibility of loose
coupling, that is, loose coupling can never be achieve (much like
reliability).

So perhaps a better definition would be to define loose coupling such that
it can be achieved by defining it as:

1) Loose coupling is the minimization of tight coupling such that no
predictable change to the interface would require a change to the software
and no predictable change to the software would require a change to the
interface

Where tight coupling is:

1) Changes to the interface will affect the software
2) Changes to the software will affect the interface

If you can determine that the interface/software would change then you have
not achieved loose coupling. However, if you can determine that the
interface/software would not change, then you have achieved loose coupling
even if such a change is technically possible, though not probable.

Corase-grained becomes one way to achieve loose coupling, but in more than
one case coarse-grained is not required to achieve loose coupling.

This also answers the question of best practice. To achieve loose coupling:

1) Determine all the probable changes to the interface/software
2) Define the interface/software such that such changes would not affect the
interface/software
3) Use WSDL/SOAP/HTTP/XHTML/SVG/JPG/etc such that it allows you to achieve
#2


arkin


>
> > 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.
>
> I also 100% agree with having "coarse-grained" or "document-oriented" web
> services.  But I don't think this has much to do with loose
> coupling.  It's
> much more to deal with
> performance/scalability/efficiency/latency.  Changing
> the name structure in a PO versus changing the PO.setName()
> structure causes
> a software break no matter which way you build it.  So Coarse-grained and
> loose coupling are separate things, imo.
>
> 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.
>
> Cheers,
> Dave
>
>