RE: Myth of loose coupling

There is one point that I did not see brought up into the discussion (I
may have missed it too): "well formed" versus "valid" XML.

HTTP enables loose coupling in the sense that it is ubiquitous,
everybody has a system that can listen in. But from a pure technical
perspective it is not as less coupling as CORBA or DCOM.

The real difference between traditional "brittle" technologies and XML
technologies (XML, XSLT, XPATH amongst other) is that now one can think
building systems were the content of a message does not need to be
understood in its entirety in order to take action. This is very
different from the object world where you have to know a whole class or
interface structure before one can interact with the data set.

Another aspect of XML technologies it enables developing systems that
can serve up data in the format that the consumer of the information
want. This enables another degree of loose coupling by reducing the cost
of implementation of a server that can interact with a large variety of
clients.

(I know these two statements are trivial however they must be part of a
discussion on loose coupling).

All these technologies are completely standard, available on all
platforms. This is why you can get loose coupling if you want too (it
has a cost of course). It is too often that I see the web services
discussion entrenched into modeling an API. What is such a big deal
about modeling an API? What are you going to get that you can't get at
looking at a Java or C# class? All this is metadata. 

It is time to use XML for what it is really useful for: carrying complex
data sets, semantically accessible (as opposed to structurally
accessible), this approach has tremendous benefits when connecting 100s
to 1000s of entities together (how can you do it without loose
coupling?).

I wrote a couple papers back in 1999 on the subject in case anyone is
interested to read:

An eXtensible Object Model for Business-to-Business eCommerce Systems
(short)
http://jeffsutherland.com/oopsla99/Dubray/dubray.html

Business Object Modeling: An XML-based approach
http://www.odx.it/doc/businessobjectmodeling.pdf

Cheers,

Jean-Jacques Dubray____________________
Chief Architect
Eigner  Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com 
 
 

>>-----Original Message-----
>>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
On
>>Behalf Of Edwin Khodabakchian
>>Sent: Monday, January 06, 2003 11:22 PM
>>To: 'David Orchard'; 'Assaf Arkin'; 'Mark Baker'; 'Ugo Corda';
'Champion,
>>Mike'
>>Cc: www-ws-arch@w3.org
>>Subject: 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 Tuesday, 7 January 2003 10:37:15 UTC