Re: On the desirable characteristics of standards.

Geoff,

I agree with everything except the last point.

What I'm trying to do is get a definition of synch/asynch for a WSDL 
operation not at SOAP MEP. At the choreography level I would like to 
work in terms of WSDL operations allowing a variety of protocols to be 
used, including but not just limited to current SOAP MEPs.

I fear that if we associate an input-only WSDL operation with a SOAP 
one-way MEP, and determine whether the WSDL operation is sychronous 
based on some SOAP MEP we happen to prefer to use today, we risk not 
being future proof. Someone may come in the future and propose other 
interesting protocols. For example, a four-message exchange (see WS-RM) 
to send the one and only message of a WSDL input operation, or 
alternatively a one-message exchange (e.g. IP multicast) to send that 
one message, or they may put multiple messages in the same bucket and 
send them together (e.g. DIME).

In my opinion for the semantic of WSDL operations to become 
"future-proof" they must be independent from any particular choice of 
SOAP MEPs used to implement them, including the best practices of today. 
In other words, the function synchronous(WSDL_MEP) should not be defined 
in terms of synchronous(SOAP_MEP), but defined on its own.

If you say that a WSDL operation is synchronous because the 
request/response are sent over the same communication channel that may 
hold true when using SOAP over HTTP but not if you decided to use IP 
multicast with some fancy synchronization mechanism (since IP has no 
notion of connection). The fact of the matter is that some protocols can 
do synchronous operations over multiple connections or even without 
requiring connections at all.

Whenever I read a definition of WSDL operations that is written in terms 
of the underlying SOAP MEP I cringe because it assumes that there is 
only one way to perform that operation based on current best practices. 
And while current best practices are good and most likely here to stay, 
some future innovations would provide other usable mechanisms to perform 
these operations.

That's why I would like to see a synch/asynch definition for WSDL 
operations that is not associated with any particular protocol, and a 
synch/asynch SOAP MEP definition that is not dependent on which WSDL 
operation is being performed. I firmly believe this level of separation 
is required for the architecture document to stand the trials of time.

Alternatively, we can just come up with a WSDL definition based on SOAP 
1.2 and rewrite it each time a new protocol is proposed.

arkin


Geoff Arnold wrote:

>
> I would like to propose that one of the desirable characteristics of a 
> Standard
> is "durability", which to me is synonymous with "future-proof". It 
> means that
> the document is constructed in such a way that it requires *no* 
> significant
> changes in the face of anticipated future developments, and  *minimal* 
> changes
> in the face of unanticipated developments. The core TCP/IP RFCs are 
> excellent
> examples of this; the POSIX spec slightly less so.
>
> In the area of web services, we start from a simple base with two models:
> REST, and SOA SOAP+HTTP. Right now there are three developments that 
> we can
> anticipate:
> - multiple types of message transports
> - choreography (which I interpret as MEP composition)
> - multiparty interactions
> Each of these developments will affect the web services model(s) in 
> interesting
> ways; taken together, the consequences are hard to imagine at this point.
> One thing is clear (to me, anyway): the semantics of synchronization and
> coordination will change significantly from what we are discussing today.
> (Consider for example the use cases of an auction, checking 
> creditworthiness,
> and credit card purchase, as well as the various ways these may be way
> composed.)
>
> All of the examples suggested by Assaf, Roger, Suresh, Ugo, and Mike 
> seem to
> me to fail the "durability" test. They seem to derive properties from
> certain existing technologies or interactions and project them as 
> intrinsic
> properties of web services. This appears to conflict with our cautious 
> approach
> to defining web services in a maximally inclusive and fairly abstract 
> way,
>
> Geoff

Received on Sunday, 4 May 2003 23:53:13 UTC