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.

> 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