- From: Jacobs,David B. <djacobs@mitre.org>
- Date: Mon, 6 Jan 2003 22:36:57 -1000
- To: "Assaf Arkin" <arkin@intalio.com>, "David Orchard" <dorchard@bea.com>
- Cc: <edwink@collaxa.com>, "'Mark Baker'" <distobj@acm.org>, "'Ugo Corda'" <UCorda@seebeyond.com>, "'Champion Mike'" <Mike.Champion@softwareag-usa.com>, <www-ws-arch@w3.org>
That is why Amazon puts human readable labels on their links :-). For a machine readable version, you would need appropriate machine understandable labels (URIs?) to help the computer figure out what the link was for. David ----- Original Message ----- From: "Assaf Arkin" <arkin@intalio.com> To: "David Jacobs" <djacobs@mitre.org>; "David Orchard" <dorchard@bea.com> Cc: <edwink@collaxa.com>; "'Mark Baker'" <distobj@acm.org>; "'Ugo Corda'" <UCorda@seebeyond.com>; "'Champion, Mike'" <Mike.Champion@softwareag-usa.com>; <www-ws-arch@w3.org> Sent: Monday, January 06, 2003 10:20 PM Subject: RE: Myth of loose coupling > Here is a test for you. Can you tell me what I have just bought: > > http://www.amazon.co.jp/exec/obidos/ASIN/B00006RT6E/ref=ed_ec_gw_cs_1_2/249- > 5515888-2202702 > > arkin > > > -----Original Message----- > > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > > Behalf Of David Jacobs > > Sent: Monday, January 06, 2003 5:43 PM > > To: David Orchard > > Cc: 'Assaf Arkin'; edwink@collaxa.com; 'Mark Baker'; 'Ugo Corda'; > > 'Champion, Mike'; www-ws-arch@w3.org > > Subject: Re: Myth of loose coupling > > > > > > > > I agree that web servers and browsers are tightly coupled at the HTTP, > > HTML, CSS, JPEG level. However, at the application level (and by > > application I mean something like Amazon's site) I would argue that the > > client and server are not tightly coupled. Amazon can make huge changes > > to its service offerings and layout without any changes being required > > of the client. I believe it is this flexibility for the application to > > change and grow without breaking existing clients that most folks are > > aiming for when they say "loosely coupled" > > > > David Jacobs > > > > David Orchard wrote: > > > > >I'm baffled that people consider the web to be "loosely-coupled" systems. > > >Guess what, when HTML changed versions, people had to upgrade their > > >browsers. The app (browser) changed whenever the user needed more > > >functionality. Say a new version of HTML comes out, maybe even > > XHTML! Then > > >a whack of servers upgrade to say they will produce according to the new > > >interface. And new apps (the updated browsers) come along and > > can grok the > > >xhtml. > > > > > >It just so happens that HTML, XHTML, CSS, JPEG, etc. have > > followed a fairly > > >lengthy centralized standardization process. And we've kind of > > settled down > > >to our current versions. To prove this point, the current angst over how > > >XHTML 2.0 should define link constructs CLEARLY indicates that the app > > >(browser) is tightly coupled to the interface schema. > > > > > >Maybe it will be the same with PurchaseOrders, Invoices, etc. > > But for now, > > >we actually want to have it where the interfaces are defined in a > > >decentralized manner, rather than through a centralized ever-speedy > > >standards process. > > > > > ><rant> > > >I think we should stop kidding ourselves that we are building loosely > > >coupled systems when we have well-defined interfaces and protocols. > > > > > >We certainly have loose coupling between the applications > > environments, like > > >Perl/Java/Python; OSes; app server environments; and the messages. Heck, > > >our software provides about a few different "mapping" layers between xml > > >and Java. But fundamentally, if the interface changes, software on both > > >sides has to change. It can sometimes be nicely isolated from the > > >application by the mapping layer, but more often than not it can't. I > > >highly doubt that I could change a purchase order schema, and > > not change the > > >application. Try just changing a string Name into a structure of > > >firstname/lastname and you are doomed. There are over 10 000 > > rules for how > > >to figure out firstnames from last names in a string, so the > > darned sending > > >software is going to be in hell trying to figure the separation rules in > > >this "mythical" mapping layer that's supposed to insulate it from change. > > >"Just put XSLT in between" doesn't cut it in any way. We are > > living through > > >the agony of this in all the darned infrastructure vocabularies > > - like the > > >changes that occur in the ws-security schemas - so why wouldn't the app > > >vocabs? > > > > > >The web isn't loosely coupled between the interface schema and the > > >implementations, it's just that the evolution has almost stopped and we > > >don't remember all the times we had to rev our browser. And > > we've now got > > >cool "auto-update" features that allow us to get the latest flash player > > >without much effort. The browser has been built to modularize > > the various > > >places that the changes can occur, so it doesn't appear as > > disruptive. But > > >it's all still tightly coupled. Change the interface=change a piece of > > >software. Nowhere to hide. The only question is: can you isolate the > > >change to a small piece of software that's on a faster rev cycle than the > > >bigger "container" software? > > > > > >Web services can't run from this problem either. At least we have some > > >great infrastructure pieces to help us deal with change, like > > soap headers, > > >xml and namespaces, WSDL. > > > > > ></rant> > > > > > >Cheers, > > >Dave > > > > > > > > > > > >>What we are seeing in practice is that all too often > > >>developers take the > > >>easy approach. Rather than defining an interface - whether > > >>RPC of document > > >>style - that is decoupled from the implementation, they use tools that > > >>produce a service definition directly from the implementation API. > > >>Obviously, as the implementation changes so would every > > >>application that > > >>needs to use this interface. Not a Good Thing(tm). > > >> > > >>However, nothing precludes you from following best practice, > > >>defining an > > >>interface that is decoupled from the implementation, > > >>performing mapping > > >>between the abstract interface and the particular > > >>implementation, and using > > >>RPC style to represent that abstract interface. WSDL does not > > >>say that RPC > > >>has to conform to an API, bad practice makes it happen. > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > >
Received on Tuesday, 7 January 2003 03:39:02 UTC