RE: Myth of loose coupling

My first exposure to XML in the application sense was its use as a canonical message format in an enterprise application integration architecture.  It was only later I learned of its origins in SGML (with which I was familiar from my days at Digital as the corporate markup language standard).

The big thing here is that XML makes application integration affordable.  Web services provide the formats and conventions for using XML in that context, in other words you can of course apply XML yourself in your own way to solve the problem (as the pioneers did), but having standards in place for messaging, description, etc. tremendously helps lower the price since now everyone can learn the same things, and use multiple products in combination.

Eric

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Wednesday, January 08, 2003 9:05 PM
To: www-ws-arch@w3.org
Subject: RE: Myth of loose coupling



One of the reasons why the network effect worked well for XML, IMO, is that
XML is useful for many more things than distributed computing.  So there was
lots of innovation/implementations of XML because of the wide variety of
applications.  The very first implementations in fact had nothing to do with
distributed computing.  I remember the first XML vocabs were all about
interchanging documents, not for web-based protocols.  It was only some
wackos that were doing distributed computing with it.

The chain that I like is:
Wide applicability = lower costs, network effect = cheaper to plug into that
other network effect phenom, the web.

I think that is what Assaf is saying later on.

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Assaf Arkin
> Sent: Wednesday, January 08, 2003 5:44 PM
> To: Jean-Jacques Dubray; edwink@collaxa.com; 'David Orchard'; 'Mark
> Baker'; 'Ugo Corda'; 'Champion, Mike'
> Cc: www-ws-arch@w3.org
> Subject: 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 21:24:24 UTC