RE: Myth of loose coupling

Edwin,

It would certainly be possible to build RESTful web services using
SOAP/WSDL, if they were modelled in a RESTful way.  Now, the rub of the
issue for our group is: Do we want to deal with non-RESTful web services?
As in, do we want to talk about solutions/problems in non-RESTful modelling?
I say that we do.

BTW, I'm not sure that a webQueue is really a RESTful modelling.  In the
same way that Roy has attacked many CGI scripts for mapping REST to
non-REST, I think that queues are kind of publicly exposed bad CGI scripts.
the "resource" being modelled should be more the resource that
representations are indicative of, like POs/stockquotes/invoices/etc.  Not
"processing" things like queues.  But I might be wrong on this.

Cheers,
Dave

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Edwin Khodabakchian
> Sent: Monday, January 06, 2003 8:22 PM
> To: 'David Orchard'; 'Assaf Arkin'; 'Mark Baker'; 'Ugo Corda';
> 'Champion, Mike'
> Cc: [email protected]
> 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
>
>