RE: Myth of loose coupling

Dave,

> 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.

Then you are correct.

> 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.

I agree that coarse-grained has much to do we
performance/reliability/efficiency/latency. My definition of
coarse-grained though is more about combining multiple operations into
one call and passing in as much data as possible ( a.foo( A ); a.goo( B
) -> a.foogoo( A union B ).

My point was slightly different here:
Imagine that Verisign is publishing a MerchandRegistration service to
allow merchands to register to their online payment service.
Registration is slightly different for merchants that want to offer Visa
only compared to merchants that want to offer Visa + Mastercard. There
are difference in the XML form that needs to be submitted and the back
end process Verisign goes through.

DESIGN OPTION A
As a developer, I can decide to design the application as one service
with 2 operations:
Operation #1: processVisaRegistration( xmlVisaOnlyForm )
Operation #2: processVisaAndMasterCard( xmlVisaAndMasterCard )
This is what most developers using today's web services toolkit would be
encouraged to do.

DESIGN OPTION B
As a developer, I create 2 Web Queue resources with a generic interface:
WebQueue #1: https://www.verisign.com/payflow/visaOnly
WebQueue #2: https://www.verisign.com/payflow/visaAndMasterCard
Get on those resources returns the meta information regarding the XML
data required by each queue. POSTing the correct XML document initiates
an asynchronous process.

Let's imagine that Intuit is using versign service for visaOnly and eBay
is using Verisign for visaAndMasterCard.

Let's imagine that a new regulation comes and the visaAndMasterCard XML
data structure changes and you need to deploy a new version of the
service. [Note: given that both services are asynchronous you cannot
simply overwrite the old version. You need side by side versioning for a
period of time.]

In design A, this simple change impacts both Intuit and eBay. In design
B only Intuit is impacted.

This could be a design pattern or best practice that developers could
adopt. But please not that if Web service were forced to be good web
citizen and expose a generic interface, then developers would be
constrained (good) to design applications using B. I believe that it
would also help a lot of developers while decomposing complex
interactions into resources.

Finally, as described in this example and Mike's previous expense report
use case, I think that generic interface (REST) and extensible envelope
and metadata (SOAP/WSDL) could be orthogonal rather than conflicting:
Web services could be built on top of RESTFul resources and still
provide all the benefits SOAP Features and XML Schema provide. No?

Edwin

Received on Monday, 6 January 2003 23:21:57 UTC