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.

I am not sure that the XML approach is technolgically superior to the
IIOP/CDR approach. Afterall, you do have a uniform way to represent the data
(CDR) and you can propose tools that perform the same functionality as with
XML: transformation, extraction, even human-readable representation.

Where XML seems to excel over IIOP, DCOM, TxRPC, RMI, DCE, IDE and a variety
of other protocols/formats is in the network effect. You have cheap (free)
accessible technology to transform a document or extract pieces of it. Even
if it was invented for styling HTML pages, you can use it to transform
invoices. At the very least you can edit a document using NotePad or vi.

You can have the same set of services for IIOP, but they are not readily
accessible, they don't work for DCOM or IDE, and usually they are task
specific, so you can look at IDLs and network packets, but you can look at
content or persisted data.

I wouldn't say IIOP is brittle, I would just point out that the network
effects plays to the advantage of XML is giving an overall better value
proposition with a ready made solution to many of the problems that with
IIOP would actually require you to buy or develop very specific solutions.


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

You can build a service that creates data in the form of an object model
given in Java. You can then serve it in binary form (e.g. CDR) or in textual
form (e.g. XML). You can have multiple CDR representations, you just need a
toolkit that lets you support multiple representations. You can have
multiple XML representations, again you need a toolkit that lets you support
multiple representations. I don't know where you could get the former, but I
know where you can download multiple tools to do the later.

Because XML transformation tools are readily available, and they all support
the same transformation languages, and there are hundred of books and
articles telling you how to use them, that's something we do on a daily
basis. Not something we do with IIOP. So you get XML deployed in more
places, which results in more tools and more information on how to use this
tools, which further increases the network effect.

That's actually how we got to be here in the first place. It wasn't the
superiority of HTTP/HTML/XML over other solutions, but the ubiquity of it
all.


> (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?).

The question that one would ask is: if XML is so great why can't I use it
everywhere?

On the one hand I have these loosely coupled services, where I don't want to
work at the API level. I want to carry complex data sets that are
semantically accessible. Like purchase orders and invoices. I want to
decouple the service definition from the actual implementation, so I can
gain considerable benefits.

On the other hand I have these tightly coupled services. Two components in
the same system, two separate layers in the same stack that are decoupled by
some low-level interface. Am I forever destined to use IIOP or RMI? Or can I
also consider using XML for these scenarios?

One approach would be to say: XML is only good for loosely coupled services,
for everything else use IIOP/DCOM/DCE/whatever. Another apporach would be to
say: services should only be loosely coupled. The concept of distributed
components does not exist outside the domain of network interactions. Your
services are either loosely coupled, or they do in-process calls. Yet
another approach would be to say: go right ahead and use XML wherever you
see fit, even if all you are doing are out-of-process calls to two
components that are part of the same application (at least IIOP and DCOM let
you do that).

I personally believe that XML would benefit more for the network effect, and
the network effect would greatly increase, if we could use XML everywhere.
Between loosely coupled systems that exchange data that is semantically
accessible, and between components that are tightly designed but separated
by boundaries of their containers. In some cases I worry a lot about having
the proper form of abstraction, in other places I worry a lot about not over
engineering the solution with too much abstraction. In both cases I use XML
for its obvious benefits without passing judgment that one approach is
radically differen from the other.

arkin

>
> 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 Wednesday, 8 January 2003 20:48:40 UTC