Re: Abstraction and interoperability (was RE: Straw-man Proposal for our mission statement)

Champion, Mike wrote:

>
>  
>
>>-----Original Message-----
>>From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>Sent: Monday, May 19, 2003 6:50 PM
>>To: Assaf Arkin; Jean-Jacques Dubray
>>Cc: 'Burdett, David'; Daniel_Austin@grainger.com; 
>>public-ws-chor@w3.org
>>Subject: RE: Straw-man Proposal for our mission statement
>>
>>
>>
>>The only way to 'abstract' away dependency on 
>>something is to completely re-invent the thing being depended on and then 
>>define how your re-invention maps to the original. This is an extremely 
>>expensive process that causes significant harm to interoperability 
>>and should only be undertaken when there is no other choice.
>>    
>>
>
>I think that's an important consideration and that there are definitely
>tradeoffs. On the other hand, the cost of NON-abstraction is fragility --
>things can break when "insignificant" changes are introduced.  For example,
>XSLT very wisely IMHO builds on an abstraction of XML, the "XPath data
>model" (a precursor to the Infoset) so that the user can ignore
>"insignificant" syntactical differences in the input document (such as
><empty attr='val' /> vs <empty attr="val"></empty>, which are identical as
>far as XPath and DOM and the Infoset are concerned).
>  
>
The ultimate in abstraction would be to agree that a choreography 
definition is some form of an XML document that we can exchange and not 
specify what the schema looks like. I'm sure that would meet all our 
conflicting requirements and all our use cases except one 
(interoperability) ;-)

I think the point here is not against abstraction per se. Definitely not 
in the sense that David described it in his use cases. That form of 
abstraction is good and we can't live without it. And all the examples 
you gave are valid and cases where abstraction does pay in dividends.

It's just that in some places the abstraction doesn't buy and ends up 
costing a lot of cycles. So then you have to ask yourself why? The risk 
here is that if we spend a lot of time abstracting the hell out of WSDL, 
we would end up redoing WSDL in a different language, and then spend a 
lot of energy trying to make that abstraction work with WSDL. Obviously 
there needs to be some benefit.

I've asked before what abstraction from WSDL would buy us technically 
speaking. I wanted to see some list of specifications we would like to 
support that we can't unless we abstract choreography from WSDL. It's a 
very simple question and so far I received no answer. So I just percieve 
that there's a risk and no reward, and I interpret Yaron's statement not 
as being anti-abstraction but being in favor of steering clear of ratholes.

All the concrete arguments I heard so far are problems that WSDL is 
already solving, in fact all of them are for problems that WSDL should 
be solving in any scope, not just choreography. So I think we should ask 
people to submit more precise issues that would come up if we decide to 
standardize on WSDL (1.2) and if by the end of the day we can't solve 
all these issues we should consider abstracting the hell out of WSDL. 
But until we get some concrete evidence, I for one am very comfortable 
with a decision to base the language on WSDL.

arkin

>  
>
>>The 'abstractions' 
>>introduced between WSDL and SOAP have caused so much interoperability 
>>pain that two different organizations had to be formed to sort out the 
>>resulting mess. 
>>    
>>
>
>Could you elaborate on how the abstractions between WSDL and SOAP caused
>interoperability problems?  And what organization besides WS-I had to be
>formed to deal with them?
>
>  
>
>>What we need is a little less abstraction and a lot more 
>>interoperability.
>>    
>>
>
>For what very little this observation may be worth, I think the worst
>mistake we made when designing the DOM API was *not* abstracting away the
>different target programming language's conception of the fundamental data
>structures. DOM invented its own types, which forced the user to do the
>mapping between, for example, a DOM NodeList and the Java collection types.
>In 20:20 hindsight, I think that defining a mapping from some abstract
>NodeList interface and the Java List type in the language binding would have
>been a better idea than asking implementers to invent (and users deal with)
>a DOM-specific class. DOM applications are *theoretically* interoperable,
>but as a practical matter the user community and implementations are
>fragmented across alternatives such as JDOM that *do* put the Java types
>into the DOM core.
> 
>Others would do it by just giving up on the abstraction and interoperability
>altogether (e.g. JDOM is defined with classes rather than interfaces, and
>makes no bones about being Java specific rather than language-neutral).  I
>think that's basically what BPEL is doing, e.g. by defining their own
>concrete execution language rather than dealing with abstractions and
>mappings and bindings, which definitely *are* harder to do properly and are
>difficult for ordinary business programmers to grasp.  But for better or
>worse, BPEL has grabbed the "easy" space, and we (if we choose to grapple
>with it) are left with the harder problem of finding the conceptual
>similarity in diverse implementation approaches and developing bindings. 
>
>Finding the appropriate level of abstraction is probably the hardest but
>most universal problem in software design. If nobody has cited this article
>http://www.joelonsoftware.com/articles/LeakyAbstractions.html yet, I
>recommend it.  I'm not sure what it implies for the problem at hand, but I
>doubt if there is a simple answer.
>  
>

Received on Monday, 19 May 2003 22:19:01 UTC